The EU Cyber Resilience Act (CRA) is a horizontal product regulation that applies cybersecurity requirements to almost any product with digital elements sold in the European Union. For software vendors, it turns what was previously best-practice into legal obligation: you ship an SBOM, you handle vulnerabilities on a clock, you disclose actively exploited vulnerabilities within 24 hours, and you affix a CE mark attesting to conformance.
The regulation entered into force on 10 December 2024. The main obligations apply from 11 December 2027, with the vulnerability reporting obligations under Article 14 kicking in earlier, on 11 September 2026. If you sell software into the EU, the countdown is already running.
Who does the CRA actually apply to?
The CRA applies to any manufacturer, importer, or distributor that places a "product with digital elements" on the EU market. The definition is deliberately broad — any software or hardware whose intended use includes a direct or indirect data connection to another device or network is in scope. That covers nearly all commercial software, most IoT hardware, SaaS components delivered as on-premises modules, and commercial firmware.
The carve-outs are narrower than most vendors hope. Pure SaaS delivered from the vendor's own infrastructure is generally regulated under NIS2 rather than CRA, but any on-premises or customer-hosted components of a hybrid SaaS product fall under the CRA. Medical devices (MDR), aviation (EASA), automotive (UNECE R155), and a handful of other sector-specific regimes remain governed by their existing rules, explicitly excluded to avoid overlap. Free and open-source software not supplied in the course of a commercial activity is also out of scope, with a lighter-touch regime for "open-source software stewards" — foundations and similar entities that systemically support FOSS projects intended for commercial use.
The distinction that trips vendors up: being a U.S. company does not matter. Placing a product on the EU market is what triggers CRA applicability. If your software is downloaded, installed, or operated by customers in the EU and you are in the commercial supply chain, you are a manufacturer under the CRA regardless of where your HQ is.
What does the CRA require vendors to do?
The CRA imposes three clusters of obligations: essential cybersecurity requirements for the product itself, vulnerability handling obligations for the product's lifetime, and documentation and conformity assessment obligations before the product enters the market. Each cluster maps to specific articles in the regulation.
Essential cybersecurity requirements (Annex I). Products must be delivered without known exploitable vulnerabilities, configured securely by default, designed to minimize attack surface, and protected against unauthorized access with confidentiality and integrity controls. The requirements are outcome-based rather than prescriptive, but standards bodies (ETSI, CEN-CENELEC) are developing harmonized standards that a vendor can demonstrably conform to instead of self-justifying each control.
Vulnerability handling (Annex I Part II). Manufacturers must identify and document vulnerabilities in their products, provide security updates free of charge for the support period (typically five years or the expected use duration), maintain a coordinated vulnerability disclosure policy, and produce a Software Bill of Materials in a commonly used machine-readable format. This is where CycloneDX and SPDX enter the regulation as the practical answer, even though the text is format-agnostic.
Article 14 reporting. Manufacturers must notify ENISA and the relevant national CSIRT within 24 hours of becoming aware of an actively exploited vulnerability in their product, and of any severe incident impacting the product's security, with a follow-up report at 72 hours and a final report at one month. This is the obligation that has the earliest deadline — 11 September 2026 — and the one that most changes how PSIRT teams need to be staffed.
What is CE marking and how does it apply to software?
CE marking under the CRA is a declaration by the manufacturer that the product conforms to the essential cybersecurity requirements. For most software products — those that are not classified as "important" or "critical" under Annexes III and IV — the manufacturer can self-assess and self-declare by issuing an EU Declaration of Conformity and affixing the CE mark.
Important products (Annex III class I and class II — categories like password managers, network management systems, hypervisors, boot managers, public key infrastructure software, EDR) have a stricter path. Class I important products can still be self-assessed if the manufacturer applies a harmonized standard fully; otherwise, third-party conformity assessment by a Notified Body is required. Class II always requires Notified Body involvement. Critical products under Annex IV may require European cybersecurity certification under the EU Cybersecurity Act.
Practically, the CE mark for software is applied to the product documentation, installer, or digital packaging rather than a physical chassis. The EU Declaration of Conformity is a document you publish alongside the product, with a pointer to the technical documentation that evidences conformance. Technical documentation has to be retained for ten years from the date the product is placed on the market.
What does the timeline look like?
The CRA has a staged application schedule with three key dates. The regulation entered into force on 10 December 2024, but substantive obligations do not bite immediately — member states and vendors have a transition window.
11 June 2026 — Conformity assessment bodies can begin being designated as Notified Bodies under the CRA. Vendors of important and critical products start building relationships with assessors who can certify them.
11 September 2026 — Chapter IV (Articles 14 and 15) applies, activating the vulnerability and incident reporting obligations. From this date, manufacturers must notify ENISA of actively exploited vulnerabilities and severe incidents on the 24/72-hour cadence. This is the earliest hard deadline and the one most likely to catch teams without a formal PSIRT process unprepared.
11 December 2027 — The full CRA applies. Products placed on the EU market from this date must comply with all essential cybersecurity requirements, have CE marking, ship with an SBOM, have documented vulnerability handling processes, and maintain an EU Declaration of Conformity. Products placed on the market before 11 December 2027 are grandfathered as long as they are not substantially modified thereafter.
In practical terms, any product that is actively developed and shipping updates through 2028 will need to be brought into compliance well before the December 2027 date.
What happens if you miss compliance?
Non-compliance penalties under the CRA scale with the severity of the obligation breached, and they are deliberately modeled on GDPR in structure. The headline numbers are up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher, for breaches of the Annex I essential requirements or Article 14 reporting obligations. Breaches of other manufacturer obligations carry a cap of EUR 10 million or 2% of turnover, and supplying incorrect information to national authorities carries EUR 5 million or 1%.
Market surveillance authorities in each member state enforce the CRA and have powers including product recall, withdrawal from the market, and restriction or prohibition of products that do not conform. For a software vendor, a withdrawal order has operational consequences beyond the fine — distribution partners have to be notified, existing customers have to be informed, and the product cannot return to market until the non-conformity is corrected and re-assessed.
The enforcement pattern most analysts expect is similar to GDPR's first two years: initial focus on egregious, high-profile cases rather than uniform enforcement, followed by progressively broader sweeps as authorities build capacity. The reputational damage from being the first CE marking non-conformance story in your sector likely exceeds the fine.
How does this compare to US EO 14028?
The CRA and Executive Order 14028 share a theme — lift the floor on software supply chain security — but they differ sharply in scope, legal character, and specificity. EO 14028 is procurement-focused: it binds U.S. federal agencies to require certain attestations from vendors, and it cascades through NIST SSDF (SP 800-218) and CISA's self-attestation form into contractual obligations. It is powerful but bounded to the federal software supply chain.
The CRA is a market regulation. It binds every vendor selling a product with digital elements into the EU, regardless of customer type, with direct obligations backed by the conformity assessment and market surveillance machinery that already governs physical products in the EU. In practical requirements — SBOM, vulnerability handling, secure defaults — the two converge. In enforcement posture, the CRA is closer to the Medical Device Regulation than to EO 14028.
A vendor selling into both markets can design one compliance program that satisfies both, with the CRA as the more demanding standard for most practical fields. The CRA's 24-hour Article 14 reporting and CE marking obligations have no clean EO 14028 analogue, so plan those separately.
How Safeguard.sh Helps
Safeguard.sh produces the CRA's core required artifacts as a side effect of normal CI — CycloneDX and SPDX SBOMs on every build, with full metadata, hashes, and dependency graphs ready to include in your technical documentation. The TPRM module ingests vendor and open-source SBOMs so you can satisfy the Annex I obligation to ship without known exploitable vulnerabilities before the product leaves your pipeline. Reachability analysis cuts 60–80% of the noisy CVEs that would otherwise overwhelm your PSIRT inbox under the Article 14 reporting workload, letting you focus on actually exploitable findings. Griffin AI autonomously produces and tests patch PRs for reachable vulnerabilities, keeping your support-period obligation to ship free security updates operational at scale. The 100-level dependency scanner and container self-healing ensure that transitive components and base image drift are not where your next Annex I finding hides.