If your company sells software or connected devices in the European Union, a new law now affects how your engineering team handles vulnerabilities. Since 11 September 2026, the EU Cyber Resilience Act (CRA) requires manufacturers to report actively exploited vulnerabilities and severe incidents on a strict clock. Most of the other requirements apply from 11 December 2027.

This is not legal advice. It is a practical guide for engineers to what the CRA asks for and the processes and tooling that make it achievable. Confirm the details for your products with your legal or compliance team.

Who the CRA applies to

The CRA covers "products with digital elements" placed on the EU market: software and hardware that connect to a device or network. It applies to manufacturers, importers and distributors, wherever they are based, if they sell in the EU.

Open-source projects developed outside a commercial activity are generally out of scope. Organisations that steward open source used in commercial products, known as open-source software stewards, have a lighter set of duties. If you use open source in a product you sell, the obligations for the product are yours.

The reporting clock

When a manufacturer becomes aware of an actively exploited vulnerability in its product, Article 14 sets three deadlines:

  1. Within 24 hours: an early warning.
  2. Within 72 hours: a fuller vulnerability notification.
  3. Within 14 days after a fix or mitigation is available: a final report.

Severe incidents affecting the security of a product follow a similar 24-hour and 72-hour pattern, with a final report within one month. Reports go through ENISA's Single Reporting Platform to the relevant national CSIRT.

Three details catch teams out:

  • The clock starts when you become aware of exploitation, not when you confirm a fix.
  • Reporting applies to products already on the market, including ones sold before the CRA took effect.
  • For a flaw in a third-party component, reporting is required if it is exploitable and has been exploited in your product.

What engineering needs to have ready

Twenty-four hours is not enough time to invent a process. These are the capabilities that make the deadline realistic.

Know what is inside each product

You cannot assess a vulnerability in a library if you do not know which products ship it. Generate a software bill of materials (SBOM) for every release and keep it with the release artefacts. The CRA's main obligations, from December 2027, include drawing up an SBOM covering at least top-level dependencies.

For example, with Syft:

bash
syft dir:. -o cyclonedx-json > sbom.cdx.json

Store SBOMs per version, so you can answer "which customers run the affected version?" in minutes.

Monitor for vulnerabilities continuously

Scan SBOMs against vulnerability databases on a schedule, not only at build time, because new CVEs appear for old releases:

bash
grype sbom:sbom.cdx.json --fail-on high

Also watch the CISA Known Exploited Vulnerabilities catalogue and vendor advisories; "known exploited" is the signal that the CRA reporting clock may apply.

Have a way for people to report issues

Publish a coordinated vulnerability disclosure policy and a contact point. A security.txt file at /.well-known/security.txt is a simple, standard way to do this:

text
Contact: mailto:security@example.com
Expires: 2027-12-31T23:59:59Z
Policy: https://example.com/security/disclosure
Preferred-Languages: en

Write the incident runbook now

Agree in advance who decides whether something is "actively exploited", who submits the report, and who approves it. Include out-of-hours contacts, because a 24-hour clock that starts on a Friday night still ends on Saturday.

Ship updates securely and for long enough

From December 2027, manufacturers must provide security updates for a defined support period, which should generally be at least five years unless the product is expected to be used for less time. Make sure your update pipeline is signed, automated and tested, and that you can patch old supported versions, not only the latest.

Secure by default

The CRA's essential requirements are mostly good engineering practice made mandatory. Examples include:

  • No known exploitable vulnerabilities at release.
  • Secure default configuration, with no shared default passwords.
  • Protection of data in transit and at rest.
  • Minimised attack surface and logging of security-relevant events.

Mapping your existing secure development practices to these requirements, and recording the evidence, is most of the work for December 2027.

A 30-day starting plan

  1. List every product you sell in the EU and its supported versions.
  2. Generate and store an SBOM for each supported version.
  3. Set up scheduled vulnerability scanning and alerts for exploited CVEs.
  4. Publish a disclosure policy and security.txt.
  5. Write and rehearse the 24/72-hour reporting runbook with a tabletop exercise.

Key takeaways

  • CRA reporting obligations have applied since 11 September 2026; most other duties apply from 11 December 2027.
  • Actively exploited vulnerabilities need an early warning within 24 hours and a notification within 72 hours.
  • SBOMs per release are the foundation for answering "are we affected?" quickly.
  • Prepare a disclosure policy, continuous scanning and a rehearsed reporting runbook.
  • Confirm scope and obligations for your products with legal or compliance experts.

Sources: European Commission: Cyber Resilience Act, Regulation (EU) 2024/2847, RFC 9116: security.txt.