The EU Cyber Resilience Act — formally Regulation (EU) 2024/2847 — entered into force on 10 December 2024, with phased application dates running through 11 December 2027. 2026 is the year the early obligations become real. Article 14 incident reporting is live as of 11 September 2026, and the main body of obligations applies from 11 December 2027. Manufacturers placing "products with digital elements" on the EU market have a narrow window to get their conformity assessment, SBOM, and vulnerability handling programs in order.
This post is the 2026 enforcement map for engineering and compliance leaders. Skip the marketing explainers; this one is organized around dates, article numbers, and the evidence you will be asked to produce.
What products does the CRA cover in 2026, and who is the "manufacturer"?
The CRA applies to "products with digital elements" — hardware or software products whose intended purpose includes direct or indirect data connection to a device or network — placed on the EU market. Article 2 sets the scope; limited carve-outs exist for products already regulated under Regulation (EU) 2017/745 (medical devices), Regulation (EU) 2019/2144 (motor vehicles), and a handful of other sector-specific regimes.
The "manufacturer" definition in Article 3(13) is broad. It includes anyone who develops or manufactures products with digital elements or has them designed, developed, or manufactured and markets them under their name or trademark. Importers (Article 19) and distributors (Article 20) have their own obligations to verify CE marking and documentation. SaaS is largely out of scope as a general matter, but the "remote data processing solutions" definition in Article 3(2) pulls components that support a product with digital elements — such as a backend the product depends on — back into scope.
Free and open-source software received a targeted treatment after heavy community pressure. Recitals 18–19 and Article 3(14) introduce the concept of the "open-source software steward," which carries lighter, duty-of-care obligations than the full manufacturer regime — but only for non-commercial stewardship.
When exactly do each of the CRA obligations bite?
Article 71 sets the application dates. The regulation entered into force 10 December 2024 (20 days after publication in the Official Journal of the European Union on 20 November 2024). Chapter IV obligations on conformity assessment bodies apply from 11 June 2026. Article 14 obligations on reporting of actively exploited vulnerabilities and severe incidents apply from 11 September 2026. The main substantive obligations — essential cybersecurity requirements (Annex I), vulnerability handling, CE marking, technical documentation (Annex VII), conformity assessment (Article 32 and Annex VIII) — apply from 11 December 2027.
This is why 2026 matters. Reporting obligations start in September 2026, but the essential requirements that the reportable incidents relate to do not apply for another 15 months. Manufacturers who have not built their incident disclosure pipeline and their SBOM and vulnerability handling program in parallel will be reporting events against a control posture they cannot yet evidence.
Member state enforcement authorities must be designated by 11 December 2027 under Article 52, but many national supervisory authorities — including Germany's BSI, France's ANSSI, Italy's ACN, and Spain's INCIBE — have already published guidance aligning with CRA timelines during 2025 and 2026.
What does Article 14 incident reporting actually require?
Article 14 introduces a three-stage reporting regime to ENISA and the designated CSIRT of the member state. First, an early warning notification within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident having an impact on the security of the product. Second, a vulnerability or incident notification within 72 hours, including the corrective or mitigating measures taken or intended. Third, a final report no later than 14 days after the corrective or mitigating measure is available, or one month after the initial notification for severe incidents.
ENISA is building the single reporting platform contemplated by Article 16. The 15 October 2025 ENISA technical specification and the companion implementing act draft circulated by the Commission in early 2026 set out the information model: product identification, version(s) affected, CVE where available, CVSS or other severity, affected customer count or geography, and — critically — the SBOM references necessary to map the incident to deployed components.
A manufacturer that cannot produce a current SBOM in machine-readable form is effectively in violation of Article 14's information obligations even before the December 2027 essential requirements apply.
What are the Annex I essential requirements and how are they verified?
Annex I has two parts. Part I sets essential cybersecurity requirements for the product itself — secure by default configurations, protection against unauthorized access, confidentiality and integrity of stored and transmitted data, minimization of attack surfaces, exploitation mitigation, and so on. Part II sets vulnerability handling requirements — identifying and documenting components (the SBOM obligation, point 1), addressing and remediating vulnerabilities without delay, applying effective and regular testing, publicly disclosing fixed vulnerabilities, and operating a coordinated vulnerability disclosure policy.
Conformity assessment is governed by Article 32 and Annex VIII. Most non-"important" products (defined under Article 7 with classes in Annex III) can use Module A self-assessment. "Important" products — for example, password managers, endpoint security software, identity management systems — must use Module B + C, Module H, or a relevant European cybersecurity certification scheme per Regulation (EU) 2019/881. "Critical" products listed in Annex IV may be subject to mandatory EU certification via delegated act.
Harmonized standards are being drafted under the Commission's standardization request M/606 of 1 August 2024. In the absence of harmonized standards, manufacturers must demonstrate conformity through the common specifications Article 27 process — harder and more expensive than simply mapping to a published standard.
How does the CRA interact with NIS2, the GDPR, and product liability rules?
CRA does not displace NIS2 (Directive (EU) 2022/2555), which regulates the cybersecurity of essential and important entities and their services. An essential entity under NIS2 that manufactures products with digital elements has obligations under both instruments, with Article 14 CRA incident reporting generally feeding the same ENISA platform used for NIS2 coordination.
It also does not displace the revised Product Liability Directive (Directive (EU) 2024/2853, adopted 23 October 2024, to be transposed by 9 December 2026), which now clearly covers software as a product and includes defective cybersecurity as a basis for liability. A CRA non-conformity is exhibit A in a PLD claim. GDPR Article 32 and Article 33 obligations on security of processing and personal data breach notification continue to apply independently — a breach may be reportable under CRA, NIS2, and GDPR to different authorities with different clocks.
Market surveillance authorities under Regulation (EU) 2019/1020 handle CRA enforcement, with administrative fines under Article 64 of up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher, for non-compliance with essential requirements.
What should non-EU manufacturers be doing in 2026?
If you place products on the EU market from the US, UK, or anywhere else, you either appoint an authorized representative under Article 18 or rely on an importer that meets Article 19 diligence obligations. Either way, you are the manufacturer for CRA purposes.
Practical priorities for 2026: appoint or confirm your authorized representative; build and maintain machine-readable SBOMs for every product and release; stand up a Coordinated Vulnerability Disclosure program consistent with ISO/IEC 29147 and the forthcoming harmonized standards; draft your Annex VII technical documentation template now; and prepare your Article 14 reporting pipeline to produce 24-hour, 72-hour, and 14-day notifications without a fire drill each time.
The worst outcome in 2026 is a severe incident at 3 a.m. Central European Time and no pre-wired path to ENISA's early warning portal.
How Safeguard.sh Helps
Safeguard.sh operationalizes the CRA for engineering and compliance teams. Lino, our compliance mapping engine, maps Annex I Part I and Part II, Article 14 reporting triggers, Article 13 manufacturer obligations, and the Annex VII technical documentation requirements to your existing controls across ISO/IEC 27001:2022, IEC 62443-4-1, NIST SSDF, and your internal SDLC — so the evidence you need for a notified body, a market surveillance authority, or an importer's due diligence is already mapped and traceable. Safeguard.sh produces and continuously updates CycloneDX and SPDX SBOMs aligned with the CRA Annex I Part II point 1 component obligation, with vulnerability linkage for every component so an Article 14 notification is a query, not a project. Our TPRM module tracks your upstream suppliers — including open-source software stewards covered by Article 24 — so that your conformity assessment files and importer questionnaires do not go stale. Safeguard.sh's attestation and signing pipeline produces signed, verifiable provenance per in-toto and SLSA, which drops directly into Annex VII technical documentation and supports CE marking claims. When a member state authority or your authorized representative asks for evidence, you produce it from a single system — not a shared drive scramble.
The December 2027 cliff is closer than it looks. The manufacturers who treated 2025 and 2026 as preparation years will ship and file calmly. The rest will learn about Article 64 fine calculations the hard way.