A mid-sized provider of industrial control software sells its products across the EU but has no product-specific vulnerability management, no SBOM and no documented update process over the lifespan. From December 2027, that will no longer be enough for the CE marking — and without the CE marking the product may not be sold on the EU single market. Preparation time for a complete product security programme is at least 18 months for most manufacturers.
The Cyber Resilience Act is the first horizontal EU regulation that imposes cybersecurity requirements on products with digital elements. It shifts responsibility from the end customer to the manufacturer and turns cybersecurity into a CE-relevant product property — comparable to electrical safety or electromagnetic compatibility.
Who is affected?
Practically everyone who sells network-capable hardware or software in the EU. The CRA follows the classic product law model with clearly delineated economic operators:
- Manufacturers — carry full conformity responsibility. Even those who only put their logo on an OEM product count as manufacturers.
- Authorised representatives — representatives in the EU appointed by manufacturers in third countries.
- Importers — place products from third countries on the EU market and must check that the conformity assessment is in place.
- Distributors — must exercise due care and withdraw non-conforming products from the market.
Three risk classes determine the conformity assessment:
- Default products (around 90% of all products) — self-assessment by the manufacturer.
- Important products Class I — e.g. identity management systems, browsers, VPN software, network management tools — self-assessment with stricter requirements or third-party assessment.
- Important products Class II — e.g. hypervisors, firewalls, tamper-resistant microprocessors — mandatory third-party assessment.
- Critical products — e.g. hardware security modules, smart meter gateways, smartcards — mandatory European cybersecurity certification.
What does the law require?
The CRA sets requirements on the product itself and on the processes across the entire lifecycle. The essential points:
- Security by design (Annex I, Part I) — products are delivered without known exploitable vulnerabilities, with secure default configurations, mechanisms for authentication, confidentiality and integrity, and logging of security-relevant events.
- Vulnerability handling (Annex I, Part II) — coordinated disclosure process (CVD), free security updates over the expected product lifespan (at least five years, often longer), SBOM in a machine-readable format.
- Conformity assessment (Art. 32) — depending on the risk class, self-assessment or involvement of a notified body. Result: EU declaration of conformity and CE marking.
- Technical documentation (Annex VII) — risk analysis, architecture, components used, test reports, vulnerability management process. Retention for at least ten years.
- Reporting obligations (Art. 14) — actively exploited vulnerabilities and serious security incidents within 24 hours (early warning), 72 hours (incident notification) and one month (final report) to ENISA and the competent national CSIRT.
- Labelling obligations — CE marking, user information with security notices, clear communication of the supported security update period at the point of sale.
In practice
Take the SBOM obligation seriously — even for in-house developments. Without a machine-readable software bill of materials, no meaningful vulnerability assessment is possible. CycloneDX and SPDX are the established formats. Anyone with a product on the market needs the SBOM as a continuously maintained artefact, instead of a one-off annex to the conformity assessment.
Operationalise Coordinated Vulnerability Disclosure (CVD). A security.txt on the website, a clear intake channel (e.g. PGP-encrypted mailbox), defined response times and an internal escalation path are the minimum kit. Anyone who ignores or litigates vulnerability reports goes against the spirit of the CRA and risks reputational damage.
Factor the update obligation into product pricing. Security updates over five to ten years cost money — backports, testing, distribution, customer notification. If this is not built into total cost of ownership, the economic squeeze starts as soon as the products are in the field.
Mapping to ISO 27001
The CRA extends the ISMS with a product-focused view. Many ISO 27001 controls map directly to the CRA lifecycle, especially in secure development and vulnerability management.
Directly relevant controls:
- A.5.7 — Threat intelligence: basis for vulnerability assessment in the product.
- A.5.8 — Information security in project management: security requirements from project start.
- A.5.21 — Managing information security in the ICT supply chain: prerequisite for a robust SBOM.
- A.5.24 — Information security incident management planning and preparation: prerequisite for the 24-hour report.
- A.5.37 — Documented operating procedures: update and patch processes across the lifecycle.
- A.6.3 — Information security awareness, education and training: secure development practices in the team.
- A.8.8 — Management of technical vulnerabilities: core discipline for CRA compliance.
- A.8.9 — Configuration management: secure default configuration as a CRA obligation.
- A.8.25 — Secure development life cycle: bridge to CRA Annex I Part I.
- A.8.26 — Application security requirements: functional and non-functional security requirements.
- A.8.27 — Secure system architecture and engineering principles: security-by-design evidence.
- A.8.28 — Secure coding: code quality as a prerequisite for products with few vulnerabilities.
- A.8.29 — Security testing in development and acceptance: mandatory component of the conformity assessment.
- A.8.30 — Outsourced development: responsibility stays with the manufacturer, even for external development.
Typical audit findings
- No maintained SBOM — either none at all, or created once and never updated. Dependency updates cannot be traced.
- Update period not communicated — at the point of sale and in the documentation, the statement on supported security update duration is missing.
- Vulnerability reports without a process — mails to
info@are not handled, no central intake channel, no triage. - Conformity assessment done once but never updated — major product changes require a new assessment, and this is often overlooked.
- Supply chain transparency missing — open source components and third-party libraries are not inventoried, critical vulnerabilities are detected too late.
- Risk class misclassified — self-assessment even though the product actually falls into Class I or II; an inspection leads directly to a sales ban.
Sources
- Regulation (EU) 2024/2847 (EUR-Lex) — official EU version in all languages
- CRA page of the European Commission — FAQ, guidance and implementation plan
- ENISA materials on the CRA — technical standards and guidelines
- BSI information on the CRA — national implementation and market surveillance
- CycloneDX and SPDX — established SBOM formats