EU Cyber Resilience Act (CRA)

The EU Cyber Resilience Act (CRA) is Regulation (EU) 2024/2847, the European Union law that makes manufacturers of software and connected devices sold in the EU responsible for the security of everything they ship, open source dependencies included. It requires a software bill of materials, vulnerability handling throughout a support period, and 24-hour reporting of actively exploited vulnerabilities.

As of October 2026, the CRA is half switched on. The reporting obligations in Article 14 have applied since 11 September 2026, and the rest of the regulation applies from 11 December 2027 (Article 71(2)). Breaching the core obligations can cost up to €15 million or 2.5% of worldwide annual turnover, whichever is higher (Article 64(2)).

Our position: most CRA programs are being built around known vulnerabilities, with an SBOM generator feeding a CVE scanner. That covers one of the two reporting tracks. The CRA also defines any incident that leads, or could lead, to malicious code in a product as a severe incident, with the same 24-hour clock. Malicious packages rarely get a CVE, so a CVE-only program produces compliant paperwork and stays blind to the events most likely to trigger a report. We are engineers, not lawyers. What follows is our engineering reading of the text, not legal advice.

The EU Cyber Resilience Act is a product-safety law for software. It applies the CE marking model the EU uses for physical goods to any "product with digital elements," which Article 3(1) defines as "a software or hardware product and its remote data processing solutions."

Cyber resilience in general means withstanding and recovering from attacks. The CRA turns that goal into enforceable duties attached to a product placed on the EU market: secure design and defaults, a documented risk assessment, vulnerability handling for a declared support period, and incident reporting. The support period must be at least five years unless the product's expected use is shorter (Article 13(8)).

Scope is wide but not unlimited. The Commission's final guidance, published on 27 July 2026 with 67 worked examples, says software that runs remotely and is only accessed through a browser is not a product with digital elements on that basis alone (Commission announcement). A backend becomes in scope as a "remote data processing solution" when a shipped product, such as a mobile app or a device, depends on it to function.

Most products self-assess conformity. Annex III raises the bar for "important" products (Annex III). Class I includes operating systems, browsers, password managers, and VPNs. Class II includes hypervisors, container runtimes, and firewalls. Annex IV lists a small set of critical hardware, such as smart cards, that needs certification.

Manufacturers carry nearly all of the Cyber Resilience Act's obligations. A manufacturer is whoever develops a product, or has it developed, and markets it under its own name, wherever that company is based. Importers and distributors have lighter checking duties.

Open source is in scope only when it is supplied in the course of a commercial activity. Recital 18 says that corporate funding of a project or a regular release cadence does not by itself make development commercial. It also says the regulation does not apply to people who contribute code to projects they are not responsible for (Recital 18).

The CRA adds a lighter role for foundations and similar bodies. An open-source software steward is a legal person, other than a manufacturer, that systematically supports open source intended for commercial use (Article 3(14)). Under Article 24, a steward must document a cybersecurity policy, cooperate with market surveillance authorities, and hand over that documentation on request. Article 64(10) states that the administrative fines "shall not apply" to "any infringement of this Regulation by open-source software stewards."

The legal burden sits with the manufacturer, but the work is already flowing upstream to volunteer maintainers. In July 2025, a Fortune 500 company sent cURL creator Daniel Stenberg a CRA risk-assessment questionnaire. It asked nine questions about libcurl 7.87.0, a release from December 2022, and set a two-week deadline. Stenberg declined: "I am not their vendor without having a more formal relationship established."

We think Stenberg is right, and that the text backs him. The CRA puts due diligence on the company that integrates the component. Analyzing the code you ship is that diligence. Mailing a questionnaire to an unpaid maintainer is not.

The Cyber Resilience Act treats every integrated open source component as part of the manufacturer's product. Three provisions do the work.

Due diligence before integration. Article 13(5) requires manufacturers to "exercise due diligence when integrating components sourced from third parties," explicitly including free and open source software. Recital 34 lists what that diligence can look like: check for a CE mark, check the component's security update history, check that it is free of vulnerabilities in public vulnerability databases, and carry out additional security tests.

Fix and report upstream. Article 13(6) says a manufacturer that finds a vulnerability in a component must report it to whoever maintains that component and remediate it. If the manufacturer writes a fix, it must share the code or documentation with the maintainer.

An SBOM with a low floor. Annex I, Part II, point 1 requires a software bill of materials "in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products."

That floor is far below what vulnerability handling needs. To see by how much, we created a minimal Express project and ran the SBOM generator built into npm 10.9.9 on 27 October 2026:

$ npm install express@4.21.2
added 69 packages in 2s

$ npm sbom --sbom-format cyclonedx > sbom.cdx.json
$ jq '.specVersion, (.components | length)' sbom.cdx.json
"1.5"
69

# The legal minimum: top-level dependencies only
$ jq -r '.metadata.component["bom-ref"] as $r
    | .dependencies[] | select(.ref == $r) | .dependsOn[]' sbom.cdx.json
express@4.21.2

$ npm audit --json | jq -r '.vulnerabilities[] | "\(.name)\t\(.severity)\tdirect=\(.isDirect)"'
body-parser     high      direct=false
express         high      direct=true
path-to-regexp  high      direct=false
qs              moderate  direct=false

An SBOM that meets the letter of Annex I lists one component. The real tree has 69. Three of the four packages npm audit flags are transitive dependencies that a top-level SBOM never names. One of them, path-to-regexp 0.1.12, is affected by CVE-2026-4867, a CVSS 7.5 regular expression denial of service fixed in 0.1.13 on 26 March 2026 (GHSA-37ch-88jc-xwx2). A vulnerability database cannot match an advisory to a package the SBOM does not contain.

The figure shows three nested layers for this project. The innermost layer, the Annex I minimum, holds one component: express@4.21.2. The middle layer, the full runtime graph, holds 69 components, including the three flagged transitive packages path-to-regexp@0.1.12, body-parser, and qs. The outer layer holds build and CI tooling that never appears in a runtime SBOM, such as the eslint → file-entry-cache → flat-cache → keyv chain and tools run with npx or installed globally.

Treat the Annex I wording as the minimum a regulator can demand, not as an engineering target. Generate the full resolved graph, from the lockfile, in a standard format such as CycloneDX or SPDX, on every build. The software bill of materials then becomes the input to monitoring rather than a document filed once. That is also the model in ENISA's March 2026 advisory on secure package manager use, which organizes dependency security as a lifecycle of selecting, integrating, monitoring, and responding.

A full runtime SBOM still has a blind spot: it describes what ships, not what ran during the build. We come back to that below, because it is where the 2026 incidents we describe actually executed.

The Cyber Resilience Act's reporting rules run two parallel clocks, and both start when the manufacturer becomes aware of a problem. One clock covers actively exploited vulnerabilities (Article 14(1) and (2)). The other covers severe incidents affecting the product's security (Article 14(3) and (4)) (Article 14).

Every report goes through ENISA's Single Reporting Platform, which launched on 11 September 2026. A manufacturer reports once. The CSIRT in the member state of its main establishment receives the report, ENISA sees it at the same time, and the CSIRT forwards it to the other member states where the product is sold (Commission). ENISA's executive director, Juhan Lepassaar, put the rationale this way: "Vulnerabilities in digital products are often exploited by threat actors to subvert or hamper critical services" (ENISA).

Article 3(42) defines an actively exploited vulnerability as one with "reliable evidence" that a malicious actor exploited it in a system without the owner's permission. That resembles the bar for CISA's Known Exploited Vulnerabilities catalog, with one difference: KEV requires an assigned CVE ID (CISA), and the CRA does not.

The Commission guidance narrows the vulnerability clock in two ways that matter for dependency triage (Hogan Lovells summary). Vulnerabilities known before 11 September 2026 need no retroactive report unless exploitation begins or becomes known after that date. A vulnerability in a third-party component is reportable under Article 14 only when it is actively exploited in the manufacturer's own product. The Article 13(6) duties to fix it and tell upstream still apply.

That second rule turns reachability analysis from a noise filter into a compliance input. If your code never calls the vulnerable function, the component's advisory is rarely evidence of exploitation in your product. Socket's Tier 1 Reachability builds a call graph from your code into each dependency and flags a CVE only if a path reaches the vulnerable function. By the numbers we have published, it typically filters out about 80% of vulnerabilities as unreachable. Socket's CycloneDX export, currently in beta, can carry those reachability and VEX results inside the SBOM, which gives you a written record of why something was not reported. Reachability has limits. Static analysis is conservative, marks uncertain paths as reachable or unknown, and cannot see code loaded through configuration or reflection it does not model. Keep the trace as evidence, not as proof.

The figure restates the table as two timelines. Both start at T0, the moment of awareness, and both demand an early warning at 24 hours and a notification at 72 hours. They diverge only at the final report. For a malicious dependency, T0 depends on detection: keyv@6.0.0 was published at 09:35 UTC on 4 August 2026, and Socket flagged it at about 09:41 UTC. A team that relies on CVE feeds alone has no T0 until someone else reports the compromise.

A malicious dependency is the clearest example of a severe incident in the Cyber Resilience Act. Article 14(5)(b) defines an incident as severe when "it has led or is capable of leading to the introduction or execution of malicious code in a product with digital elements or in the network and information systems of a user of the product."

That definition does not mention CVEs, and a malicious package does not need one to qualify. Most malicious packages never receive a CVE, and the few compromises that do are catalogued after the malware has already run. Run the Recital 34 checklist against a freshly trojanized release and it passes: an open source library carries no CE mark, the update history looks healthy, and no vulnerability database lists the new version. Only "additional security tests" that inspect what the package actually does can catch it.

The keyv and cacheable compromise shows the timing, using npm registry publish timestamps from 4 August 2026:

• 09:35 UTC. keyv@6.0.0 publishes with a new preinstall hook, setup.mjs. The hook downloads a standalone Bun runtime and runs a roughly 728 KB obfuscated second stage that harvests cloud, Vault, Kubernetes, GitHub Actions, and npm credentials.
• About 09:41 UTC. Socket's malware detection flags the hook, about six minutes after publication.
• 10:09 to 10:14 UTC. Nine more packages in the cacheable family publish trojanized versions, including flat-cache and file-entry-cache.
• Throughout. keyv@6.0.0 passes npm provenance checks, because the legitimate release workflow built source the attacker had already modified.

The library code in keyv@6.0.0 was byte-identical to the clean release candidate. Everything malicious lived in the install hook, so the package worked normally after it had already compromised the host. Across the campaign, Socket detected affected artifacts an average of five minutes and 18 seconds after publication.

Most victims never installed keyv directly. Socket's analysis traces a common path: eslint depends on file-entry-cache, which depends on flat-cache, which depends on keyv. eslint is a development tool. It will not appear in a runtime SBOM, yet it can execute in CI, where publishing and signing credentials often live. In our reading, a stolen release token on a build runner is "capable of leading to the introduction" of malicious code into the product, which starts the 24-hour clock.

The axios compromise on 31 March 2026 had the same shape. OpenAI disclosed that the malicious axios 1.14.1 ran inside its macOS app-signing workflow, which had access to the certificate it uses to sign and notarize its desktop apps. OpenAI rotated the certificate and reported no evidence that user data or production software was compromised. That incident predates Article 14, but it is exactly what 14(5)(b) describes. Tools fetched with npx or installed globally in CI usually sit outside the project lockfile, so an SBOM generated from the lockfile never records them, as our analysis of the axios blast radius showed. The build pipeline is part of the product's attack surface, and CI/CD security is part of CRA compliance whether or not the SBOM can see it.

Verdict: the vulnerability clock needs a full transitive SBOM, advisory scanning, and reachability, used together. The incident clock needs behavioral analysis of packages before they install, in CI as well as on developer machines. Provenance is necessary for both and sufficient for neither.

The SBOM floor is the clearest gap. "At the very least the top-level dependencies" lets a manufacturer comply with an inventory that hides almost every component an attacker would actually use. Regulators should raise it to the full resolved graph. Engineering teams should not wait for them.

The second gap is economic. The CRA correctly makes the integrator responsible for its components, and Article 13(6) correctly sends fixes back upstream. It funds none of the upstream work, so cost arrives as unpaid questionnaires to people like Stenberg. Companies that depend on a project should pay for its maintenance or do the analysis themselves.

The third gap is the trigger. Both reporting clocks start at awareness, which can seem to reward not looking. The CRA closes that loophole elsewhere: Article 13(5) requires due diligence before integration, so not looking is itself a failure. In practice, detection latency is now a compliance variable. A team that learns about a malicious dependency from the news has not avoided a 24-hour deadline. It has missed the diligence that should have started the clock in minutes.