If your product ships with a single line of code and touches an EU customer, the Cyber Resilience Act (CRA) already has an opinion about how you handle vulnerabilities in it. The regulation, which entered into force on December 10, 2024, sets specific clocks running: a 24-hour early warning to ENISA for any actively exploited vulnerability, a 72-hour follow-up notification, and a 14-day final report after a fix ships. Vendors like Anchore have positioned SBOM generation as the finish line for CRA readiness, but SBOMs are only the input. The actual obligation is a running process — continuously monitored, triaged against exploitability, and reported on a countdown you don't control. Most vulnerability management stacks built for internal risk reduction were never designed to hit a 24-hour regulatory deadline. This piece breaks down what the CRA actually requires, when it bites, and where tooling choices — including Anchore's — help or hurt.
What does the CRA actually require for vulnerability management?
The CRA requires manufacturers of "products with digital elements" to treat vulnerability handling as a designed-in process, not an incident response afterthought. Annex I, Part II lists the concrete obligations: identify and document components (including third-party and open-source dependencies) in a machine-readable SBOM, apply the CVSS or an equivalent scoring approach, remediate without delay through security updates, and — critically — report actively exploited vulnerabilities and severe incidents to ENISA and the affected national CSIRT under Article 14. The law also requires manufacturers to provide free security updates for the "expected product lifetime," with a hard floor of 5 years from placing the product on the market. That means your vulnerability management program has to have institutional memory measured in years, not sprint cycles. A one-time SBOM export at release doesn't satisfy this; the SBOM has to stay current as dependencies patch, get replaced, or go end-of-life.
When do the CRA's deadlines actually take effect?
The reporting obligations under Article 14 apply starting September 11, 2026, a full 15 months before the rest of the regulation. That's the date most teams get wrong — they plan around the headline "2027" date and miss that the exploited-vulnerability reporting clock (24 hours to ENISA, 72 hours for the full notification, 14 days for the final report) is live more than a year earlier. The remaining substantive requirements, including CE marking, conformity assessment, and the general security-by-design obligations in Annex I, apply from December 11, 2027, 36 months after entry into force. Practically, this means any team shipping connected products, embedded firmware, or commercial software into the EU needs a reporting pipeline operational in Q3 2026 — roughly 14 months from now — even though the "real" enforcement date feels further out. Waiting until 2027 to build the process leaves no runway to test it against a live exploited-CVE scenario before it's mandatory.
Why is CRA vulnerability management harder than what most teams already do for NIS2 or SOC 2?
It's harder because the CRA regulates the product, not the organization, and ties reporting to a specific exploit event rather than a periodic audit cycle. NIS2 and SOC 2 largely ask "do you have a documented, operating vulnerability management process" — evidenced through quarterly scans, patch cadence, and control narratives reviewed annually. The CRA asks a sharper question: when CVE-2026-XXXXX in a library you shipped is confirmed as actively exploited in the wild, can you notify ENISA within 24 hours of becoming aware of it? That requires three things most compliance-driven programs don't have wired together: an accurate, current SBOM per shipped product version (not per repo), a feed that correlates your dependency graph against CISA's Known Exploited Vulnerabilities (KEV) catalog or equivalent exploitation intelligence in near-real time, and a pre-built reporting workflow to the correct national CSIRT. Teams that treat vulnerability management as a monthly Jira ticket sweep will discover the gap the first time a zero-day lands in a transitive dependency on a Friday night.
What happens if a company misses the reporting window?
Missing it exposes the company to some of the steepest penalties in EU tech regulation: fines up to €15 million or 2.5% of worldwide annual turnover, whichever is higher, for the most serious violations of the core security obligations, with a lower tier of up to €10 million or 2% for other infringements including failure to comply with reporting duties. Beyond the fine, market surveillance authorities in any EU member state can require corrective action or withdraw a non-compliant product from the market — a materially worse outcome for a vendor than the fine itself. There's also a reputational mechanic specific to this regulation: because the CE mark under the CRA now covers cybersecurity (not just physical safety), a public enforcement action reads as a safety recall, not a quiet compliance footnote. For a company selling into regulated EU sectors — industrial control systems, medical devices adjacent to CRA's scope, or critical infrastructure software — a single missed 24-hour window on one CVE can become the reason a product loses market access across all 27 member states simultaneously.
How does Anchore's approach to CRA compliance compare?
Anchore's strength is SBOM generation and static compliance gating — tools like Syft and Grype are well-established for producing an SBOM and running a point-in-time vulnerability scan against it, and Anchore Enterprise wraps that in policy-as-code for build-pipeline gates. That covers the documentation half of Annex I well: you can generate a CycloneDX or SPDX SBOM per build and block a release on a policy violation. Where it's a heavier lift is the part of the CRA that isn't about the release moment at all — the continuous, post-ship obligation. A CVE disclosed 18 months after a product shipped, against a dependency version already in the field, needs to be matched back to every affected SBOM, scored for real-world exploitability, and routed into a 24-hour reporting clock — without a human re-running a scan pipeline to discover it. Anchore's model is strongest at build time; CRA Article 14 obligations live almost entirely at run time, across a product's full 5-year support window, which is a different operating rhythm than a CI/CD gate.
How Safeguard Helps
Safeguard is built around the operating rhythm the CRA actually demands rather than the one a build pipeline is optimized for. We maintain a living SBOM per shipped product version — not per repo snapshot — and continuously re-correlate it against new CVE disclosures, CISA's KEV catalog, and EPSS exploitability scores as they update, so a dependency that was safe at release but becomes actively exploited in month 20 doesn't sit undetected until the next scheduled scan. When a match crosses the actively-exploited threshold, Safeguard starts the clock automatically: it flags the finding with a timestamp of first detection, pre-populates the Article 14 notification fields (affected product, CVE, exploitation status, remediation status) mapped to your national CSIRT's format, and tracks the 24-hour, 72-hour, and 14-day milestones with escalation alerts so the deadline is never discovered by missing it. Because the CRA's support-period requirement runs a minimum of 5 years, Safeguard's SBOM history is versioned and retained for the full product lifetime, not just the current release — so you can answer "which shipped versions contain this component" for a product line from three years ago as fast as for one shipped last week. For teams running Anchore or similar tools at build time, Safeguard layers on top as the continuous monitoring and reporting-readiness system, closing the gap between "we generated a compliant SBOM" and "we can prove, with a timestamped audit trail, that we met the CRA's reporting deadlines." That combination — build-time hygiene plus run-time regulatory response — is what CRA vulnerability management actually requires, and it's the part most SBOM-first tooling wasn't built to do.