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

URL: https://www.devopsness.com/blog/eu-cra-article-14-what-devops-teams-do-now
Author: Kiril Urbonas
Published: 2026-09-18
Updated: 2026-10-31
Categories: DevOps
Tags: Security, DevSecOps, DevOps, Operations, SRE

Summary: Since 11 September 2026 the 24-hour clock for actively exploited vulnerabilities is live. The owner, the decision path, the SBOM lookup, and the runbook you need this month.

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

Since 11 September 2026, CRA Article 14 gives manufacturers 24 hours from becoming aware of an actively exploited vulnerability to send an early warning, 72 hours to notify, and 14 days after a fix ships to file a final report. DevOps teams should wire in a named reporting owner, a timestamped intake channel, searchable per-release SBOMs, and a rehearsed runbook.

> [!VERIFIED]
> Regulation (EU) 2024/2847, against the European Commission CRA reporting page and ENISA's Single Reporting Platform launch notice and FAQ (SRP live since 11 September 2026). Checked October 2026.

The part of the Cyber Resilience Act that lands on engineering is a stopwatch. Most teams do not miss that deadline because they are slow at patching. They miss 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 once, through the Single Reporting Platform that ENISA operates. ENISA announced the platform's initial operating capability on 11 September 2026, the same day the obligation started. 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: the Commission and ENISA both date their reporting duties (Article 24(3)) from 11 December 2027, and only to the extent they are involved in developing products with digital elements. If you are a foundation-style steward of an open-source project 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](/blog/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 access before you need it. ENISA's FAQ says manufacturers report through Assigned Representatives: personal EU Login accounts with multi-factor authentication, one Primary AR who registers the company and picks the CSIRT, and up to 20 Secondary ARs joining by invitation. Make the reporting owner and deputy those representatives. 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](/blog/supply-chain-security-sbom-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:

```bash
$ 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:

```bash
$ 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](/blog/npm-supply-chain-ci-hardening) drills, and fix whatever stalls.

## Questions people ask

### When do CRA Article 14 reporting obligations apply?

For manufacturers, from 11 September 2026. ENISA's FAQ says the duty covers products already on the market, and that you do not report retroactively if you knew about the exploitation before that date; if you become aware after it, the clock applies even for an old vulnerability. Open-source software stewards follow from 11 December 2027, under Article 24(3).

### What are the CRA 24-hour and 72-hour reporting deadlines?

For an actively exploited vulnerability, the early warning is due within 24 hours of becoming aware, the vulnerability notification within 72 hours, and the final report no later than 14 days after a corrective measure is available. Severe incidents use the same 24-hour and 72-hour steps, with a final report within one month of the 72-hour notification.

### Where do you submit a CRA vulnerability report?

Through ENISA's Single Reporting Platform. A manufacturer files once; the notification goes to the CSIRT designated as coordinator in the member state of its main establishment and, barring exceptional circumstances, is made available to ENISA at the same time. The coordinating CSIRT then shares it with CSIRTs in the other member states where the product is available.

## 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.

## Sources

- [European Commission: CRA reporting obligations](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting)
- [ENISA: The CRA Single Reporting Platform is launched](https://www.enisa.europa.eu/news/the-cra-single-reporting-platform-is-launched)
- [ENISA: Single Reporting Platform FAQ](https://www.enisa.europa.eu/topics/product-security/vulnerability-services/eu-incident-response-and-cyber-crisis-management/single-reporting-platform-srp/frequently-asked-questions)
- [SPDX specification v2.3](https://spdx.github.io/spdx-spec/v2.3/)