Skip to main content

The EU Cyber Resilience Act is live: what software teams must do now

· 8 min read
Vulkro
Vulkro
Security research

An advisory lands for a library inside a product you sell. By lunchtime there are reports that it is being exploited. Until this autumn, the next question was a business one: how fast do we patch? Since 11 September 2026, if that product is sold in the EU, there is a legal one first. The Cyber Resilience Act gives the manufacturer 24 hours from becoming aware of an actively exploited vulnerability to send an early warning to its national CSIRT and to ENISA, 72 hours to send the full notification, and a fixed window for the final report.

The report itself is short. Answering it is not, unless you already know what is in every version you ship and whether the vulnerable code can be reached. This post covers what the regulation asks of software teams, which dates matter, and what evidence to have on disk before you need it.

This is a plain-language summary of EU law for software teams, not legal advice: check the official text and your counsel before you rely on it.

The reporting deadlines already apply​

The CRA is Regulation (EU) 2024/2847. Most of it applies from 11 December 2027, but Article 14, the reporting duty, applied from 11 September 2026, and it applies to every in-scope product, including those already on the market before 2027 (Article 69(3)). There is no grace period for existing products.

Article 14 sets two parallel clocks, both counted from the moment the manufacturer becomes aware:

Actively exploited vulnerabilitySevere incident affecting the product
Early warningwithin 24 hourswithin 24 hours
Notificationwithin 72 hourswithin 72 hours
Final reportno later than 14 days after a corrective or mitigating measure is availablewithin one month of the notification

The notification has to carry general information about the product, the nature of the exploit and the vulnerability, the corrective or mitigating measures taken, and the measures users can take. The final report describes the vulnerability's severity and impact and the security update that fixes it.

Reports go through a single reporting platform, which notifies the coordinating CSIRT and ENISA at once. ENISA announced on 11 September 2026 that it had deployed the platform's initial operating capability.

Who is in scope, and who is not​

The regulation applies to "products with digital elements" made available on the EU market whose intended or reasonably foreseeable use includes a data connection to a device or a network. Software sold on its own counts. So do the cloud functions a product needs in order to work, which the regulation calls remote data processing.

A pure software-as-a-service product is, in general, a different story. The CRA's own recitals say that NIS2 applies to cloud computing services such as SaaS, and that cloud services designed outside the responsibility of a product manufacturer fall outside the CRA. If you run a hosted service, read our post on NIS2, DORA and your Salesforce org as well. If you ship anything a customer installs, this one is yours. Where the line falls for your product is exactly the question to take to counsel.

What applies from 11 December 2027​

Annex I sets the essential requirements. For a software team, the ones that change daily work are these:

  • No known exploitable vulnerabilities. Products are made available "without known exploitable vulnerabilities", on the basis of the manufacturer's risk assessment.
  • A software bill of materials. Manufacturers must "identify and document vulnerabilities and components", including by drawing up an SBOM "in a commonly used and machine-readable format covering at the very least the top-level dependencies". It belongs in the technical documentation, and a market surveillance authority can ask for it.
  • Remediation without delay, through security updates, separate from feature updates where technically feasible.
  • Effective and regular tests and reviews of the product's security.
  • A coordinated vulnerability disclosure policy, a contact address for reports, and public disclosure of fixed vulnerabilities once an update is out.
  • A support period that reflects how long the product is expected to be in use, and at least five years unless it is expected to be in use for less. Each security update must stay available for at least ten years or the rest of the support period, whichever is longer.
  • Due diligence on components, open-source ones included, so that what you integrate does not compromise what you ship.

The penalties are in Article 64. Breaching the essential requirements or Articles 13 and 14 can cost up to EUR 15 000 000 or 2.5% of total worldwide annual turnover, whichever is higher. Other listed obligations carry up to EUR 10 000 000 or 2%, and misleading information to authorities up to EUR 5 000 000 or 1%.

Why the first 24 hours are the hard part​

Read the reporting clock against how most teams answer an advisory today. Which service pulls that library? Which release went to which customer? Is the function the advisory names even called? Each of those is a lookup that should take seconds and, without the right records, takes an afternoon. The afternoon is the whole early-warning window.

The regulation does not ask you to have fixed anything in 24 hours. It asks you to know. That means three things already exist before the advisory does: an inventory of what each product contains, a way to search it in seconds, and a way to say whether the vulnerable code is reachable from anything your product runs.

What to have ready, and how Vulkro produces it​

Vulkro Core scans your code and its lockfiles on your own machine and writes the evidence as files. Nothing is uploaded. The commands below are the ones the documentation publishes.

# the inventory, in the two formats reviewers read
vulkro sbom . --format cyclonedx > sbom.cdx.json
vulkro sbom . --format spdx > sbom.spdx.json

# the 24-hour question: is this package anywhere in the project?
vulkro respond --package lodash@4.17.20 .

# the exploitability statement, backed by reachability (opt-in)
VULKRO_SCA_REACHABLE=1 vulkro sbom . --format openvex > vex.json

# SBOMs + VEX + an evidence pack, stapled into one zip
vulkro cra-bundle . --framework iso27001 -o cra-readiness.zip
  • The SBOM. One component per resolved package, with the version your lockfile actually resolved, a package URL and the licence where one resolved, in CycloneDX or SPDX. Generate it per release and keep it with the release. See SBOM and VEX.
  • The lookup. vulkro respond walks every lockfile and import once and reports every place a package shows up, direct or transitive, from the files on disk and without calling an advisory service.
  • The exploitability statement. A VEX document records, per advisory, whether your product is affected. Vulkro marks a component not_affected only when the advisory names its vulnerable functions and nothing your code can run calls one. When the advisory does not say, the statement is under_investigation, not a guess. That is the substance of a 72-hour notification.
  • The bundle. vulkro cra-bundle writes both SBOMs, the OpenVEX document and a control-by-control evidence pack into one zip, with a one-page index. Its own front page calls it readiness evidence, not a conformance attestation. See the command reference.
  • The release gate. vulkro gate fails a build only on findings that are new against a base branch or commit, so a new exploitable flaw does not ship while existing debt does not block every change. That is how "without known exploitable vulnerabilities" becomes a check rather than a hope.
  • The record of testing. Scans saved with vulkro scan --save are kept and comparable over time, which is the paper trail behind "regular tests and reviews".

On tiers: the scan, every finding with its proof, the fix and current vulnerability data are free on one repository, with no account. The SBOM, the VEX and other evidence formats, respond, the bundle, the diff-scoped release gate and scan history are part of Vulkro Pro.

What Vulkro does not do​

Plainly, so nobody discovers it on the day:

  • It does not make a product compliant or certified. The CRA has a conformity assessment and a CE marking. A scanner produces evidence for parts of Annex I; it does not perform or replace that assessment.
  • It does not report for you. The manufacturer submits the early warning, the notification and the final report through the single reporting platform.
  • It does not write your policies. The coordinated disclosure policy, the reporting contact and the support period are decisions only you can make.
  • It does not know what you shipped to whom. Vulkro tells you what is in a codebase. Which build went to which customer is a record only you hold.

Start before the next advisory​

The cheapest moment to build the inventory is before the advisory that needs it. Install Vulkro, run a scan on the product you ship, and generate the SBOM for its current release. When the next advisory lands, the 24-hour question becomes a lookup.

Sources​