The Cyber Resilience Act Takes Effect — Every Software Dependency Must Be Documented, Signed, and Traceable Within 36 Months

The Cyber Resilience Act (CRA) — EU Regulation 2024/2847, adopted on October 10, 2024 — is no longer a discussion draft. It enters phased application starting in 2026, with the first binding deadline on June 11, 2027 for notification obligations. For the first time, the European Union mandates that every software vendor — from the SaaS giant to the small business selling a WordPress plugin — must document, maintain, and secure its entire software supply chain.

The CRA makes no distinction between a hardware product containing software (a router, an IP camera), embedded software, a SaaS platform, or an open-source library used in a commercial product. If the software is “placed on the market” in the EU, it is covered. The transition period is 36 months from the date of entry into force (December 2024), placing the first operational obligations at December 11, 2027 — with intermediate milestones as early as 2026. This is the most sweeping software regulation ever enacted, and it will reshape how the global software industry builds, ships, and maintains products.

The Three Obligations That Change Everything

The CRA is built around three structural obligations:

1. Mandatory SBOM for Every Software Product

Every software product placed on the EU market must be accompanied by a Software Bill of Materials in SPDX 3.0 or CycloneDX 1.6 format. The SBOM must list:

• All direct and transitive dependencies, with exact version and origin.
• The licenses of each component.
• Known CVEs affecting each dependency, with their CVSS score and remediation status.

The obligation covers first-party code (your application), third-party code (libraries, base containers, runtimes), and integrated external services (third-party APIs whose compromise would affect product security). The European Commission estimates this requirement will apply to over 30,000 software vendors in the EU.

For a development team, this means integrating Syft, Trivy, or cdxgen into the CI/CD pipeline before the end of 2026. Generating an SBOM retroactively for 150 microservices and 8,000 transitive dependencies is not an exercise you improvise in December 2027. The SBOM must be maintained as a living document — every dependency update, every new CVE, every license change must be reflected.

2. Vulnerability Remediation Within Five Business Days

The CRA requires vendors to fix actively exploited vulnerabilities within five business days of public disclosure. For critical vulnerabilities without known exploitation, the deadline is 30 days. This obligation is continuous throughout the product’s announced lifetime — and the minimum support lifetime is set at five years from the date of first sale.

This five-day deadline is the most aggressive ever imposed by any regulation. For comparison, the NIS2 directive (2023) mandated 24-hour incident notification but no binding remediation timeline. The CRA goes further: it’s not enough to say “we’re working on a patch.” The patch must be delivered, documented, and verifiable. This is a close cousin to the CISA Binding Operational Directive 22-01 in the U.S., which mandates remediation timelines for federal agencies — but the CRA applies to the entire commercial market.

For organizations that maintain end-of-life software or legacy versions not covered by a support contract, the CRA creates a legal obligation to either continue patching or withdraw the product from the market. This is a radical shift for the enterprise software industry, where N-2 versions are often left unpatched due to budget constraints. The CRA says: you support it, or you kill it — there is no in-between.

3. 24-Hour Notification to ENISA

Any exploited vulnerability or security incident affecting a software product must be reported to ENISA (the European Union Agency for Cybersecurity) within 24 hours of becoming aware of it. The notification must include:

• The nature of the vulnerability, CVSS score, attack vector.
• The scope of affected products (versions, configurations).
• Available remediation measures or an estimated timeline.
• A cross-border impact assessment.

ENISA will act as a centralized European CSIRT for product vulnerabilities, coordinating with national CSIRTs. Non-compliance with this obligation exposes the vendor to fines of up to €15 million or 2.5% of annual worldwide turnover — the same ceiling as GDPR. This is not a “notify within 72 hours” regime like GDPR’s breach notification; it’s 24 hours, and it applies to vulnerability exploitation, not just confirmed data breaches.

Open Source: The First Structured Exception

The CRA contains an important exception for open source after intense lobbying by the Linux Foundation, the Eclipse Foundation, and the Open Source Initiative. Open-source software provided free of charge and without a direct commercial model is excluded from the scope — provided it is not integrated into a commercial product.

In practical terms: the volunteer maintainer of an npm library is not subject to the CRA. But the company that integrates that library into its SaaS product is fully covered — and it is that company’s responsibility to produce the SBOM covering the open-source library, monitor its CVEs, and apply fixes within the deadlines.

This distinction creates an asymmetry of responsibility that worries the open-source community: major consumers of open-source software (AWS, Google, Microsoft) will have to monitor and fix vulnerabilities in components they didn’t write, maintained by volunteers with no obligation to fix quickly. The Linux Foundation has proposed creating a CRA maintenance fund financed by corporations to support critical maintainers — the debate is ongoing, and it will define the sustainability of open-source infrastructure for the next decade.

The Precise Timeline of Deadlines

December 11, 2027 is the date on which a non-compliant software product can no longer be sold in the EU. National surveillance authorities — ANSSI in France, BSI in Germany, NCSC in the Netherlands — will be responsible for enforcement and sanctions. These agencies are already hiring: ANSSI opened 47 new CRA-related positions in its 2026 recruitment cycle.

Verdict: What Your Organization Must Do Now

The CRA is not a distant administrative formality. It is a rewrite of software liability arriving in 16 months for the first obligations and 18 months for full compliance. Here is the minimum action plan:

• Before March 2027: integrate an SBOM generator (Syft, Trivy, cdxgen) into your CI/CD pipeline. Generate an SBOM for every build and store it alongside the artifact. CycloneDX 1.6 is the right balance between tooling compatibility and CRA compliance. If you’re using GitHub, the dependency graph + dependency submission API can automate much of this — but you still need the CycloneDX file for regulatory submission.
• Before June 2027: establish an ENISA notification procedure. Identify who in your organization is responsible for CVSS qualification, report drafting, and submission within the 24-hour window. Run a tabletop exercise. The 24-hour clock starts when you become aware — not when you finish investigating. Your incident response playbook needs a CRA-specific path.
• Before September 2027: audit your ability to fix a critical vulnerability in five business days. If your current release process takes two weeks of QA, you are not compliant. Automated regression testing and progressive deployment (canary releases) become prerequisites of regulatory compliance — not nice-to-haves.
• Before December 2027: for every software product you maintain, verify that you can produce a complete SBOM covering the entire dependency chain. If a component does not have an SBOM, you cannot legally ship it in the EU. Start mapping your dependency tree now — the gaps will surprise you.

The Cyber Resilience Act will cost real engineering and process money to organizations that haven’t planned for it. But for those that integrate it now, it becomes a competitive advantage: a verifiable SBOM and a five-business-day remediation policy will be the new trust standards of the European software market. The vendors who treat this as a compliance checkbox will drown in last-minute remediation debt. The ones who build it into their engineering culture will sell “CRA-ready” as a premium feature — and the market will pay for it.

---

References

• European Parliament and Council, “Regulation (EU) 2024/2847 on Horizontal Cybersecurity Requirements for Products with Digital Elements (Cyber Resilience Act),” EU Official Journal, December 10, 2024
• ENISA, “Cyber Resilience Act Implementation Guidelines — Draft,” July 2026
• Linux Foundation, “CRA and Open Source: Impact Analysis V2,” June 2026
• Open Source Initiative, “CRA FAQ for Open Source Maintainers,” updated April 2026
• “Executive Order 14028 — Improving the Nation’s Cybersecurity,” The White House, May 2021