EU regulation 2024/2847
The Cyber Resilience Act entered into force December 2024. Vulnerability reporting to ENISA is mandatory from September 2026. Full compliance is required from December 2027. If you sell hardware or software in the EU you need to be ready by then.
This page is a concrete checklist, not a legal overview. Broad strokes and technical measures we have seen work. For legal interpretation, consult a lawyer.
Does it apply
Two regulations, two scopes. CRA is "product safety": you sell a product. NIS2 is "essential service": you operate a critical service. Many companies are covered by both, often without realising.
IoT manufacturers, embedded software, downloadable software, smart home, OT, industrial firmware, on-prem appliances, mobile apps, browser extensions, SaaS that integrates into a product. Pure cloud (no install) is excluded art. 2(5).
Energy, healthcare, transport, water, digital infrastructure (data centers, CDN, cloud), public administration, postal, chemicals, food, manufacturing. Mid-size and large companies in those sectors are covered automatically.
Most common: IoT vendors with their own cloud, security suppliers with both SaaS and on-prem appliances, e-commerce platforms shipping plugins. Two separate compliance tracks — do not try to merge them.
Consultancies, law firms, small web agencies building for clients (the client is the CRA manufacturer). You have no direct CRA obligations, but responsibility can come via the client supply chain (Art. 14(2) supplier disclosure).
Checklist
CycloneDX or SPDX format, generated in CI on every release. Includes transitive dependencies, license and version. Kept available for market surveillance — does NOT need to be published publicly (CRA art. 13).
Published process for how you receive, triage and remediate vulnerability reports. RFC 9116 security.txt and Coordinated Vulnerability Disclosure policy. CRA Annex I part 2 requires this.
Actively exploited vulnerabilities and severe incidents reported to the ENISA single reporting platform within 24 hours (art. 14). An email address and a runbook is enough initially.
Defined and communicated support window (expected product lifetime). Security patches shipped free during the entire support window. End-of-support date published clearly.
No default passwords. MFA support built in. Encrypted communication by default. Least privilege. Document which security properties the product has and why.
Cybersecurity risk assessment per product (which threats, which mitigations). Technical documentation showing the product meets Annex I requirements. Retained 10 years after the last unit placed on market.
Products cannot be sold in EU without CE marking. Standard products use internal self-declaration. "Important" and "critical" PDE require third-party assessment (notified body). Notified body must be in place at least 6 months ahead.
Your suppliers (open source, commercial components) must report vulnerabilities to you within a reasonable time (art. 14(2)). You in turn must choose components that are "continuously maintained". Open source foundations have lighter rules.
What we do
We do not do CE marking for you and we do not write your legal risk assessment. Those must sit with your own organisation. What we do is build the technical evidence CRA requires you to be able to produce.
Further reading: our CRA 2027 walkthrough, API Security Scanning, Strategic Security Assessment.
FAQ
No. CRA art. 13 requires SBOM to be "available for market surveillance" (ENISA, national authorities), not published. Many companies (including us) keep it private — a public SBOM gives attackers an exact map of dependencies. Customers needing it for due diligence get it under NDA.
A vulnerability in your product with confirmed signs of actual exploitation in the wild (customer incident, IOCs in logs, leaked exploit code published). A CVE with a POC alone does not count. The threshold is higher than NIS2 incident reporting.
Depends. Pure cloud service with no installed component at customer is excluded art. 2(5) — that goes under NIS2 instead. If you ship a CLI, browser extension, mobile app, plugin or on-prem appliance, THAT part is CRA-scoped. Many companies have both tracks.
You are the CRA manufacturer of the final product regardless of whether dependencies are OSS or commercial. Open source projects have lighter rules (if foundation-run), but YOUR product containing the same OSS is fully scoped. Requirement: choose "continuously maintained" components, track them in SBOM, monitor for CVE.
Yes, if you sell the product in EU. CRA has no size exemption (unlike NIS2 which starts at 50 employees). A one-person consultancy selling an IoT component must meet the same technical requirements as a large manufacturer. Some simplified procedures exist for "microenterprise" but no exemption.
Up to 15 million EUR or 2.5% of global turnover (whichever higher), per art. 64. For minor breaches (incorrect documentation) 5 million EUR or 1% of turnover. Market surveillance can also order product recall from the EU market.
Honest assessment of what is required and what can wait. No sales pitch. If you do not need us, we will tell you.