EU CRA Article 14: What DevOps Teams Should Wire In Now

The reporting duties of the EU Cyber Resilience Act (Regulation (EU) 2024/2847, Article 14) apply from 11 September 2026, and the part that lands on engineering is a stopwatch: once you become aware of an actively exploited vulnerability in a product you ship, you have 24 hours to send an early warning. Most teams do not fail that deadline because they are slow at patching. They fail it because nobody owns the decision, nobody can say within an hour whether the product is affected, and the on-call runbook stops at "page security". This post covers what we would wire in this month. It is engineering advice, not legal advice; have counsel confirm whether and how the Act applies to your products.

The three deadlines, as the Commission states them#

Per the European Commission's CRA reporting page, manufacturers report actively exploited vulnerabilities and severe incidents through the Single Reporting Platform that ENISA operates. The notification goes to the CSIRT of the member state where you have your main establishment and, simultaneously, to ENISA, barring exceptional circumstances.

For an actively exploited vulnerability the timeline is:

• Early warning: within 24 hours of becoming aware.
• Vulnerability notification: within 72 hours of becoming aware.
• Final report: no later than 14 days after a corrective measure is available.

Severe incidents run on their own timeline: the same 24-hour and 72-hour steps, then a final report within one month of the 72-hour notification. Open-source software stewards are a separate case, and the Commission says their reporting duties start from 11 December 2027. If you only publish an open-source library and sell nothing, that later date may be yours. If you ship a commercial product built on top of it, it is not.

"Aware" is the word that matters#

The clock starts at awareness, not at triage completion and not when the ticket reaches the right team. A CVE that lands in a scanner on Friday evening, plus a threat-intel post saying it is being exploited, is awareness for a reasonable reading of the rule. We would not bet a 24-hour deadline on a lenient interpretation.

So the first design decision is to make the moment of awareness a recorded event. Every escalation path, whether a customer email, a scanner alert, a vendor advisory, or a researcher report, should end in one intake channel that stamps a timestamp. That timestamp is the input to everything else. The same discipline drives the blameless timelines in incident post-mortems that drive change: if you cannot say when you knew, you cannot defend your response.

You need an owner with authority to file#

Reporting to a national CSIRT and ENISA is a decision with legal weight, so an engineer at 2 a.m. should not be making it alone. Name a reporting owner and a deputy, both reachable on a rota, with pre-agreed authority to submit the early warning. The early warning is deliberately thin, so the authority needed is small. The 72-hour notification needs more, and legal or product leadership can join for that step.

Set up the platform account before you need it. Finding out on day one of an incident that nobody has credentials for the reporting portal is the most avoidable way to burn 24 hours.

An SBOM is how you answer "are we affected" in an hour#

The first question after awareness is whether the exploited component is in a shipped product, and in which versions. Without an inventory this is a week of grepping. With one it is a query. If you already emit an SBOM per build, as we describe in supply chain security with SBOMs and attestation, store them in a place you can search across releases, not just attached to the latest image.

A minimal lookup against a directory of SPDX files:

$ COMPONENT="xz"
$ grep -l "\"name\": \"$COMPONENT\"" sboms/*.spdx.json
$ jq -r --arg c "$COMPONENT" '.packages[] | select(.name==$c) | "\(.name) \(.versionInfo)"' sboms/api-v3.4.1.spdx.json

Note that this answers "is it in our build", not "is it reachable and exploitable". Record both answers separately; the early warning needs the first, the fuller notification benefits from the second.

Turn the clock into a checklist#

Compute the deadlines the second an incident is opened and paste them into the ticket. This script is small on purpose:

$ cat > cra-deadlines.sh <<'EOF'
#!/usr/bin/env bash
# usage: ./cra-deadlines.sh 2026-09-19T08:30:00Z
python3 - "$1" <<'PY'
import sys
from datetime import datetime, timedelta, timezone
t = datetime.fromisoformat(sys.argv[1].replace("Z", "+00:00"))
print("aware:          ", t.isoformat())
print("early warning:  ", (t + timedelta(hours=24)).isoformat())
print("notification:   ", (t + timedelta(hours=72)).isoformat())
print("final report:    14 days after a corrective measure ships")
PY
EOF
$ chmod +x cra-deadlines.sh && ./cra-deadlines.sh 2026-09-19T08:30:00Z

The final report deadline hangs off the fix, not the awareness time, so the runbook should include a step that stamps the day a corrective measure becomes available and schedules the 14-day date from it.

What the on-call runbook needs, and what it should not#

The runbook needs six steps: stamp awareness, query SBOMs for exposure, decide whether exploitation is credible, page the reporting owner, submit the early warning, and start the fix. Notice that patching is step six, not step one. Reporting can and should run in parallel with engineering, which means a person other than the responder owns it.

Do not build a large process. We would rehearse it once as a game day against a real historical CVE, in the format of npm supply chain CI hardening drills, and fix whatever stalls.

The decision, concretely#

• Who files the early warning? A named reporting owner and deputy on a rota, with the authority written down before any incident.
• How do we know if we are affected? A searchable archive of SBOMs for every shipped release, not only the current one.
• When does the 24 hours start? At awareness, so every intake channel must stamp a timestamp on the ticket.
• Are we an open-source steward? If you only publish open-source code, the Commission dates your reporting duties from 11 December 2027; if you sell a product, plan for now.

The call we'd make#

This month, assign the reporting owner, create the platform account, archive SBOMs per release, and run one tabletop with the deadline script. That is a few days of work, and it turns a 24-hour legal obligation into a routine step in an incident you already know how to run. Confirm your product scope with counsel, because this article only covers what engineering should prepare.