The short version
Regulation (EU) 2024/2847, the Cyber Resilience Act (CRA), entered into force on 10 December 2024. It makes cybersecurity a condition for placing hardware and software on the EU market, the same way electrical safety already is. No conformity, no CE marking, no sale.
Two dates matter:
| Date | What applies |
|---|---|
| 11 June 2026 | Rules on notification of conformity assessment bodies |
| 11 September 2026 | Reporting obligations for actively exploited vulnerabilities and severe incidents (Article 14) |
| 11 December 2027 | Everything else, including essential requirements and conformity assessment |
The September 2026 date is the one vendors underestimate. Reporting applies to products already on the market, not just new ones. If you sell software in the EU, you need a working path from "we learned this is being exploited" to "ENISA's platform has our early warning" within 24 hours, in a matter of weeks.
Are you in scope?
The CRA covers products with digital elements: hardware and software whose intended or foreseeable use includes a direct or indirect data connection to a device or network. That is deliberately broad. Desktop apps, mobile apps, firmware, libraries sold commercially, IoT devices, network equipment and their remote data processing solutions are all in.
Notable exclusions and carve-outs:
- Products already covered by sector rules with equivalent security requirements (medical devices, motor vehicles, civil aviation, marine equipment).
- Pure SaaS is generally covered by NIS2 rather than the CRA, unless it is a remote data processing solution essential to a product's function (the cloud backend of a connected device, for instance).
- Free and open-source software developed or supplied outside the course of a commercial activity is out of scope.
- Products developed exclusively for national security or defence.
Products then fall into classes that determine how conformity is assessed:
| Class | Examples (Annexes III and IV) | Conformity route |
|---|---|---|
| Default | Most software and devices | Self-assessment by the manufacturer |
| Important, class I | Identity management, browsers, password managers, VPNs, network management, routers, operating systems | Harmonised standard or third-party assessment |
| Important, class II | Hypervisors, firewalls, intrusion detection and prevention, tamper-resistant microprocessors | Third-party assessment |
| Critical | Hardware devices with security boxes, smart meter gateways, smartcards | European certification where required, otherwise third party |
Most vendors are in the default class. That still means meeting every essential requirement; it only changes who checks.
The essential requirements, translated
Annex I has two parts. Part I is about the product, Part II about the manufacturer's vulnerability handling process.
Part I: properties of the product
Paraphrased, a product must be designed, developed and produced to ensure an appropriate level of cybersecurity based on risk, and specifically:
- be placed on the market without known exploitable vulnerabilities
- ship with a secure-by-default configuration, with the ability to reset to original state
- be able to receive security updates, including automatic updates on by default where applicable, with a clear opt-out
- protect against unauthorized access (authentication, identity, access management)
- protect confidentiality and integrity of data, commands and configuration
- process only the data necessary (data minimisation)
- protect availability of essential functions, including against denial of service
- minimise attack surface, including external interfaces
- record and monitor relevant internal activity (security logging), with an opt-out for users
- allow users to securely and easily remove all data and settings
None of this is new to a mature product security team. What is new is that "we knew about that CVE in our bundled library but shipped anyway" now has a legal consequence.
Part II: vulnerability handling
This is where SBOM and process obligations live. Manufacturers must, for the support period:
- identify and document vulnerabilities and components, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies
- address and remediate vulnerabilities without delay, including by providing security updates, separate from feature updates where technically feasible
- apply effective and regular tests and reviews
- publicly disclose information about fixed vulnerabilities (description, affected products, impact, severity, remediation)
- put in place and enforce a coordinated vulnerability disclosure policy, with a contact address for reports
- take measures to facilitate sharing of information about vulnerabilities, including in third-party components
- distribute updates securely and, for security fixes, without delay and free of charge (unless otherwise agreed for a tailor-made product)
The SBOM does not have to be published. It belongs in your technical documentation and must be available to market surveillance authorities on request. But an SBOM that sits in a drawer is useless for the actual obligation, which is to know when a component you ship becomes vulnerable. We cover the mechanics in SBOM vulnerability tracking.
The support period must reflect how long the product is expected to be in use, and must be at least five years unless the product is expected to be used for less.
Generate the SBOM in CI, not by hand. CycloneDX and SPDX are both widely used machine-readable formats. Produce one per release artifact, store it next to the build, and feed it into continuous vulnerability matching. A per-release SBOM is also exactly what you need to answer "which customers run the vulnerable version" during an incident.
Reporting: 24 hours, 72 hours, 14 days
From 11 September 2026, Article 14 requires manufacturers to notify actively exploited vulnerabilities in their products and severe incidents having an impact on the security of their products. Notifications go simultaneously to the CSIRT designated as coordinator (normally in the member state of your main establishment) and to ENISA, through the single reporting platform that ENISA operates.
For an actively exploited vulnerability, the stages are:
| Deadline (from becoming aware) | What to send |
|---|---|
| 24 hours | Early warning, including member states where the product is made available, if known |
| 72 hours | Vulnerability notification: general information on the product, nature of the exploit and vulnerability, corrective or mitigating measures taken and those users can take, sensitivity of the information |
| 14 days after a corrective measure is available | Final report: description, severity and impact, information about any malicious actor exploiting it if available, details of the security update or other corrective measures |
Severe incidents follow a similar 24-hour and 72-hour structure, with a final report within one month. Manufacturers must also inform impacted users, and where appropriate all users, about the vulnerability or incident and the mitigations available.
Note the trigger: actively exploited, not merely discovered. A vulnerability reported through your CVD programme with no evidence of exploitation does not start the 24-hour clock. A customer's incident responder telling you they found your product being abused does. So does a public catalogue such as CISA's Known Exploited Vulnerabilities list adding a CVE affecting your product.
What 24 hours requires in practice
You cannot build this process during the incident. Before September:
- Decide who is "aware". The clock starts when the manufacturer becomes aware. Define the intake channels (security@ mailbox, CVD platform, support escalations, threat intel feeds) and who triages them, including weekends.
- Prepare the early warning template. It is short. Product, versions, the fact of exploitation, member states affected if known. Do not wait for root cause.
- Map product versions to customers and markets. That is your SBOM plus your licensing or telemetry data.
- Pre-authorise a decision maker. Someone must be allowed to file without convening a committee.
- Rehearse. Tabletop a scenario where a bundled third-party library in your product shows up in a known-exploited catalogue on a Friday evening.
For the triage itself, the usual enrichment applies: look the CVE up on /tool/cve-search, score it with the CVSS calculator, and check whether exploitation evidence is credible. Our guide on CVSS, EPSS and KEV prioritization covers how to weigh those signals.
Your dependencies are now your liability
The CRA applies to the manufacturer of the final product, including for the components it integrates. Article 13 requires due diligence when integrating third-party components, including open-source ones, so that they do not compromise the product's security. If you find a vulnerability in a component, you must report it to whoever maintains it.
That makes dependency hygiene a compliance control:
- Know what is in the build. Lockfiles, vendored code, container base images, statically linked native libraries.
- Detect malicious packages, not just vulnerable ones. A typosquatted dependency with an install script will never have a CVE. Tools like /postmortem scan a project's dependency tree locally for malicious code, install hooks and risky packages.
- Track end-of-life components. An unmaintained library cannot receive the fixes you are now obliged to ship.
# Example: generate a CycloneDX SBOM for a Node project in CI
npx @cyclonedx/cyclonedx-npm --output-file sbom.cdx.json
# Keep it with the release artifacts, keyed by version
cp sbom.cdx.json "releases/${VERSION}/sbom.cdx.json"
Open-source stewards
The CRA introduces a new role: the open-source software steward. This is a legal person, other than a manufacturer, that systematically provides sustained support for the development of free and open-source products intended for commercial activities. Foundations and some companies hosting open-source projects fit here.
Stewards get a deliberately lighter regime. They must put in place and document a cybersecurity policy that fosters secure development and effective vulnerability handling, cooperate with market surveillance authorities, and report actively exploited vulnerabilities and severe incidents to the extent they are involved in development. They are not subject to administrative fines for those obligations.
Individual maintainers publishing code without monetizing it are not manufacturers. The burden falls on the company that ships the open-source component inside a commercial product. If you are that company, contributing fixes upstream is no longer charity: it is how you meet your own obligations.
Penalties
Non-compliance with essential requirements or the manufacturer obligations in Articles 13 and 14 can lead to fines up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher. Market surveillance authorities can also order withdrawal or recall of non-compliant products. For a software vendor, a forced withdrawal from the EU market is the real risk.
What to do this quarter
- [ ] Confirm which products are in scope and which class each falls into.
- [ ] Stand up the Article 14 reporting process before 11 September 2026: intake, triage owner, templates, decision maker, 24/7 coverage.
- [ ] Produce a machine-readable SBOM for every release and match it continuously against vulnerability data.
- [ ] Publish a coordinated vulnerability disclosure policy with a working contact.
- [ ] Define and publish the support period for each product.
- [ ] Separate security updates from feature updates in your release process.
- [ ] Audit dependencies for malicious and abandoned packages, not just CVEs.
- [ ] Gap-assess against Annex I Part I now; December 2027 is closer than a typical product roadmap.
The CRA does not invent new security practice. It takes the things good vendors already do and makes skipping them illegal.
