The EU Cyber Resilience Act — formally Regulation (EU) 2024/2847 — entered into force on 10 December 2024, and its obligations phase in across three dates well before full enforcement. The first, on 11 June 2026, brings rules for notifying conformity-assessment bodies into effect. The second, on 11 September 2026, is the one that catches most engineering teams off guard: manufacturers of "products with digital elements" sold into the EU must report actively exploited vulnerabilities to ENISA within 24 hours of becoming aware of them. That's not a typo carried over from incident-response tabletop exercises; it's now a statutory clock. The full regime — CE marking, conformity assessment, technical documentation — becomes mandatory on 11 December 2027. Unlike GDPR's 72-hour breach notice, which most security teams have internalized for years, the CRA folds vulnerability handling, SBOM production, and security-by-design obligations into a single regulation with per-obligation deadlines spread across three separate dates. Teams that wait until late 2027 to start will be retrofitting SBOM tooling, disclosure processes, and update-support commitments into products that were never built with any of it in mind. This guide breaks down what's actually due when, and what to change in the SDLC now.
What counts as a "product with digital elements" under the CRA?
The CRA defines a product with digital elements broadly: any software or hardware product whose intended or foreseeable use includes a direct or indirect logical or data connection to a device or network, placed on the EU market as a standalone product or as a component. That sweeps in everything from a standalone SaaS backend to a firmware-flashed IoT sensor to an open-source library distributed for commercial integration. There are carve-outs: products already governed by sector-specific EU rules — medical devices, in-vehicle systems, aviation equipment — are generally excluded because equivalent cybersecurity requirements already apply under those regimes. Open-source software also gets conditional relief: an individual maintainer or non-commercial open-source steward isn't automatically a "manufacturer" under the Act, though a company that commercializes, bundles, or provides paid support for open-source components generally is. If your product ships to any EU customer and has a network interface, assume it's in scope until you've confirmed otherwise against the European Commission's official CRA summary guidance.
What are the actual reporting deadlines, and what triggers them?
Two distinct triggers exist under Article 14: an actively exploited vulnerability in your product, and a severe incident affecting its security. Both start the same clock — an early warning to ENISA and the relevant national CSIRT within 24 hours of the manufacturer becoming aware, a fuller notification within 72 hours including known exploitation details and mitigations, and a final report within 14 days of a corrective or mitigating measure becoming available for an exploited vulnerability, or within one month for a severe incident. This obligation is one of the earliest-binding parts of the CRA, effective 11 September 2026 — over a year before the rest of the regulation applies. Practically, this means your incident response runbook needs an ENISA/CSIRT notification step wired in well before the SDLC-level requirements (SBOMs, technical documentation) are legally required, because the reporting clock doesn't wait for the rest of your compliance program to catch up.
What does "security by design and by default" actually require in practice?
Annex I of the CRA sets essential cybersecurity requirements that apply across a product's development lifecycle, not just at release. In practice this means: shipping with no known exploitable vulnerabilities at release, using secure-by-default configurations (no default or hardcoded credentials), minimizing the attack surface, protecting data confidentiality and integrity, and ensuring the product can receive and apply security updates. None of these are new concepts — they mirror NIST's Secure Software Development Framework and OWASP's long-standing secure-SDLC guidance — but the CRA is the first EU regulation to make them a legal precondition for CE marking rather than a best-practice recommendation. For engineering teams, the operational translation is concrete: a documented threat model per product line, dependency and secrets scanning gates in CI, and a written vulnerability handling policy that supports coordinated disclosure — because Annex I explicitly requires manufacturers to establish a process for receiving, triaging, and remediating externally reported vulnerabilities.
Why does the CRA require an SBOM, and what has to be in it?
The CRA requires manufacturers to produce a Software Bill of Materials covering, at minimum, the top-level dependencies of the product, in a commonly used machine-readable format — the two formats the Commission has pointed to as meeting that bar are CycloneDX and SPDX, the same formats already standard in US federal procurement following Executive Order 14028. The SBOM isn't a one-time deliverable filed at release; because the CRA also requires manufacturers to monitor and remediate vulnerabilities in included components (including third-party and open-source dependencies) for the product's defined support period, the SBOM has to stay queryable and current as new CVEs are disclosed against those dependencies. This is functionally the same discipline EO 14028 forced on US government suppliers starting in 2021 — an SBOM that answers "are we affected" the moment a new CVE lands, not a static PDF attached to a compliance binder.
What's the realistic timeline for building this into an existing SDLC?
Three dates matter, and they don't align with a single "go-live." Notification-body rules for conformity assessment start 11 June 2026; the 24/72-hour/14-day vulnerability and incident reporting obligation starts 11 September 2026; and the full set of obligations — CE marking, technical documentation, conformity assessment — becomes enforceable on 11 December 2027. Working backward from September 2026, teams need an incident-response process capable of hitting a 24-hour ENISA notification window in production well before that date, since "we'll build it when it's due" leaves no room for a dry run. Working backward from December 2027, SBOM generation, security-by-design gating in CI, and defined update-support periods need to be operating in production months earlier so the technical documentation reflects real practice rather than a paper exercise assembled at the deadline. Given how tightly compressed those windows are relative to normal enterprise procurement and audit cycles, most manufacturers realistically need to start SBOM and vulnerability-handling changes in 2026, not 2027.
How Safeguard helps
The EU Cyber Resilience Act is one of the frameworks tracked in Safeguard's compliance catalog of 197 supported regulations and standards, scored per-control with drill-down after each assessment, so a security team can see CRA-relevant gaps alongside SOC 2, FedRAMP, or NIST SSDF findings instead of running a separate spreadsheet for EU obligations. Safeguard's SBOM compliance engine — already validating SBOMs against EO 14028 and NTIA minimum-element requirements (supplier identification, component versioning, and dependency relationships, plus cryptographic hash values as a baseline attribute beyond the original NTIA set) — applies the same gap-analysis and automated-remediation mechanics that the CRA's own SBOM requirement calls for: flagging missing fields, generating a compliance score, and producing an audit-ready report a team can hand to a notified body. Combined with continuous SCA scanning and Griffin AI's remediation guidance, that gives manufacturers a working head start on the SDLC changes the CRA requires, well ahead of the September 2026 and December 2027 deadlines.