If you ship software that ends up in European hands, the EU Cyber Resilience Act (CRA) changes your obligations in ways a legal summary won't fully capture. This is not about adding a cookie banner. It is about how you build, what you document, and how fast you act when a vulnerability surfaces.
The CRA entered into force December 10, 2024. Full enforcement is December 11, 2027. That sounds distant — it is not, if you need to retrofit your CI/CD pipeline, vulnerability disclosure process, and dependency management practices into compliance.
Who is actually in scope
The CRA covers products with digital elements — hardware or software that has a direct or indirect data connection to another device or network.
Default (Class 0): The vast majority of software products can self-assess against the essential security requirements. Self-assessment means you document compliance and sign your own declaration of conformity. Market surveillance authorities can inspect your technical documentation at any time.
Class I "important" products require a third-party conformity assessment: web browsers, password managers, VPNs, network management tools, remote access software, routers, and smart home hubs.
Open-source software released under a free and open-source license and not intended for commercial use is excluded. If you commercialize OSS — through support contracts, hosted services, or integration into a commercial product — the commercialized product is in scope.
B2B SaaS that ships an agent, browser extension, SDK, CLI tool, or any software component running in the customer's environment is in scope for those components. Pure cloud services with no embedded client are provisionally out of scope (covered by NIS2 instead).
What "secure by design" actually requires
The CRA's essential requirements translate into engineering terms:
Default configurations must be secure. No default admin passwords, no debug logging enabled by default, no default-open firewall. Features not necessary for the product's primary function should be disabled by default.
Dependency security is your responsibility. This is the most significant shift. Under pre-CRA norms, a vendor could largely disclaim responsibility for vulnerabilities in open-source components. The CRA eliminates that position. If you ship a vulnerable component, you are responsible for it. You need to know what is in your dependency tree, monitor it for new CVEs, and patch.
No known exploitable vulnerabilities at release. Products must ship without known actively exploited vulnerabilities. This means checking your dependencies against CISA's Known Exploited Vulnerabilities (KEV) list before release — a CVE that is actively being exploited is a different risk from one that is technically flagged but unused.
The SBOM requirement
Article 13(3) requires manufacturers to draw up technical documentation including a Software Bill of Materials covering open-source components.
Format: Machine-readable, using SPDX (ISO/IEC 5962:2021) or CycloneDX. Both are acceptable. CycloneDX is the easier starting point for most teams.
Minimum content: Component name, supplier name, version, unique identifier (PURL or CPE), dependency relationships, SBOM author, and timestamp. Generate full transitive depth — regulators and enterprise buyers expect it.
Currency: An SBOM generated once at release goes stale immediately. A new CVE in a dependency disclosed the week after your release means your product contains a known vulnerability you could have addressed. Treat SBOM generation as a CI/CD step on every build.
Retention: Technical documentation must be maintained for 10 years after a product's last sale.
The 72-hour disclosure requirement
When a manufacturer becomes aware of a security incident affecting their product, they must notify ENISA within 24 hours (early warning) and 72 hours (full notification). An actively exploited vulnerability — even without an incident — triggers a 24-hour notification.
You need to monitor CISA KEV and threat intelligence feeds for exploitation evidence, not just wait for CVEs to appear in a database. If a CVE drops on a Friday night and appears on the KEV list over the weekend, a reporting obligation started ticking while your team slept. Automated monitoring with on-call notification is no longer optional for CRA-covered products.
Enforcement timeline
| Date | What kicks in |
|---|---|
| June 2026 | Conformity assessment provisions apply |
| September 2026 | Vulnerability and incident reporting to ENISA begins |
| December 11, 2027 | Full compliance required for new products |
Penalties: up to €15 million or 2.5% of global annual turnover, whichever is higher. For SaaS products with continuous delivery, the conservative reading is that your compliance clock starts at December 2027 regardless of when you started shipping.
A practical starting checklist
- Generate a CycloneDX SBOM on every build, covering transitive dependencies
- Store versioned SBOMs alongside build artifacts; retain for 10 years
- Monitor SBOM components against OSV, NVD, and CISA KEV continuously
- Publish a vulnerability disclosure policy (
SECURITY.mdat minimum) - Set up on-call notification for KEV-listed vulnerabilities in your components
- Establish the ENISA reporting process and test it before September 2026
- Use lockfiles and
npm ci/ equivalent for reproducible builds - Audit default configurations: no default passwords, debug off, unused ports closed
- Run secret scanning against full git history and on every commit
The underlying practices the CRA mandates — SBOM generation, continuous vulnerability monitoring, dependency hygiene — are the same practices that make supply chain attacks harder to execute and faster to detect. The 2027 deadline is a forcing function. The engineering work is overdue regardless of regulation.
Lumstep generates a CycloneDX SBOM on every scan, scores it with sbomqs, and monitors components against CISA KEV and EPSS data continuously — the living inventory and exploit-prioritized alert signal that CRA compliance depends on.
Or let Lumstep handle it.
Connect a repo and Lumstep scans it automatically - secrets, dependencies, SBOM, and code quality - and opens the fix PR.