"We are ISO 27001 certified, so the CRA is ticked off for us." This sentence comes up surprisingly often in conversations with larger manufacturers, especially where a lot of money and effort has gone into the certification. The hope is understandable. It is still wrong, for a structural reason: the two regimes look at different objects.
What does ISO 27001 mean and what does it check?
ISO 27001 is the international standard for information security management systems (ISMS). What is certified is the organisation: its risk analysis, its security processes, its responsibilities, its continuous improvement. The auditor checks whether the company manages information security systematically.
What the auditor does not check: whether a specific product was designed securely, which software components it contains, whether it receives security updates across its lifecycle. A company with an exemplary ISMS can ship a product with outdated encryption and unmaintained open-source components without the certificate being affected in the slightest.
The Cyber Resilience Act starts exactly there. It follows the New Legislative Framework (NLF), the EU legal framework for product safety, and regulates the individual product with digital elements: security by design, that is, security anchored in the development process from the start, vulnerability management across the lifecycle, technical documentation, conformity assessment, and CE marking. For an overview, see our CRA summary.
Why the shortcut "certificate = compliance" is dangerous
Anyone who plans to use the ISO certification as CRA evidence overlooks at least four blocks of requirements that an ISMS audit does not deliver:
- Conformity assessment per product: the CRA requires a conformity assessment procedure for every product model, completed with an EU declaration of conformity and CE marking. Depending on the product category, for instance important products of class I or II, different procedures apply. Details are in the article on CE marking under the CRA.
- SBOM per product: the CRA requires an SBOM (Software Bill of Materials), that is, a complete inventory of all software components, as part of the technical documentation. ISO 27001 does not know this requirement. How to build SBOMs is shown in the SBOM guide.
- Support period with free security updates: manufacturers have to provide security updates over the defined support period for every product placed on the market (that is, every product made available on the EU market for the first time). That is a product duty, not an organisational process.
- Reporting duties in hours, not audit cycles: actively exploited vulnerabilities must be reported within 24 hours via the ENISA Single Reporting Platform from 11 September 2026. An ISMS audit takes place once a year. The CRA deadline runs in hours.
An example: the CISO of a large group files the ISO certificate in the CRA project plan as evidence for the product line. After the deadline, a major customer asks in a supplier audit for the SBOM for model X and the defined support period. Neither is on any ISMS certificate in the world.
Myth vs. Fact
Myth: An ISO 27001 certification covers the requirements of the Cyber Resilience Act.
Fact: ISO 27001 certifies the organisation's management system. The CRA regulates the individual product. Conformity assessment, CE marking, SBOM, support period, and the 24-hour reporting duty cannot be replaced by any ISMS certificate. A lived ISMS is, however, a strong foundation for the CRA build-out.
Concrete consequences for your CRA project
1. Run a structured gap assessment. Lay the CRA requirements next to your ISMS processes and mark three categories: already covered (such as risk-management methodology), adaptable (such as incident response as a basis for the reporting process), and new (such as SBOM, conformity assessment, support period). That turns the diffuse "CRA project" into a concrete work list.
2. Use your ISO structures as an accelerator. Your advantage over companies without an ISMS is real: you have responsibilities, documentation discipline, and an incident process. Extend the incident process with the CRA reporting path and its staged deadlines, rather than building something new in parallel. The same logic applies to supplier management and risk assessment.
3. Treat the product level as its own work package. Everything that arises per product needs its own owners, usually closer to development and product management than to information security: SBOM per product line, security-by-design evidence, conformity assessment, update processes. The most common mistake is to push these tasks onto the ISMS organisation, which has neither the tools nor the product proximity for them.
What does this mean for your CRA roadmap?
On 11 September 2026 the reporting duties enter into force. Your ISMS incident process is the best starting point for the reporting path, but it has to be extended with the CRA deadlines and the ENISA report.
On 11 December 2027 full CRA applicability follows. From then on, every product newly placed on the market needs full conformity, including CE marking.
How to translate both deadlines into realistic planning is shown in the CRA compliance roadmap 2026/2027. What is at stake for non-compliance is in the article on CRA fines and penalties.
Frequently asked questions
Does ISO 27001 do nothing at all for the CRA? It does, quite a lot. Risk management, incident processes, documentation discipline, and audit experience shorten the CRA build-out considerably. The ISMS simply does not replace the product-related duties.
Is there a certification that creates a CRA presumption of conformity? The CRA works with harmonised standards: products developed and assessed against them benefit from a presumption of conformity. These standards are currently being drafted by the European standardisation organisations. ISO 27001 is not among them, because it concerns the organisation and not the product.
We are also IEC 62443 certified. Is the combination enough? The combination is strong, but IEC 62443 too currently does not create automatic CRA conformity. Why that is the case is something I cover in a dedicated post in this series.
Do I have to extend my ISMS for the CRA? Formally no, in practice yes. It makes sense to integrate the CRA processes (reporting paths, vulnerability management, update delivery) into the existing process landscape rather than building a parallel organisation.
Who in the company should own the CRA, the CISO or the product side? Both, with a clear division of tasks. Reporting paths and monitoring often sit well with the CISO, while the product-related duties (SBOM, conformity assessment, updates) belong in development and product management. What matters is that the interface is defined.
Conclusion
ISO 27001 is a quality credential for your organisation and a genuine foundation for the CRA build-out. It is not CRA evidence. The product-related duties, from the SBOM through conformity assessment to the 24-hour report, only come about through your own work at product level.
A structured CRA roadmap, supported by a platform like Kunnus, helps you work through the gaps between the ISMS and the product duties systematically, before the deadline tips from theory into practice. A starting point is our free CRA compliance check.
Every Friday I debunk a CRA myth here.