The 24-Hour Clock: What EU CRA’s September 2026 Reporting Deadline Means for Your DevOps Pipeline

There’s a regulatory deadline most DevOps teams have not internalised yet. On 11 September 2026 — exactly four months from now — the first enforceable provisions of the EU Cyber Resilience Act go live. Article 14 will require manufacturers of any “product with digital elements” placed on the EU market to report actively exploited vulnerabilities within 24 hours and severe security incidents within 72 hours.

That’s not a planning horizon. That’s a wall.

Most coverage of the CRA has focused on the December 2027 deadline for full product conformity. That date is real, but it’s a distraction from the more immediate operational problem: the September 2026 reporting obligations apply to every in-scope product already on the EU market — including legacy products you shipped years ago. There is no grace period for products you haven’t touched recently. There is no exemption for “small enterprise” status when it comes to the obligation itself, only a narrow protection from fines specifically for the 24-hour deadline.

For mid-size EU and UK tech companies, this is where the abstract becomes concrete. The CRA isn’t a legal team problem. It’s a DevOps and engineering problem. Because if you cannot detect, classify, and document an actively exploited vulnerability within 24 hours, your legal and compliance teams cannot file a report. And if you cannot file the report, you face fines of up to €15 million or 2.5% of global turnover under Article 64 — whichever is higher.

Four months. That’s the time you have to build, test, and operationalise the engineering layer that makes 24-hour disclosure possible. This is what that audit looks like.

What the September 2026 obligations actually require

Let’s separate the regulatory text from what it means at the engineering layer.

Under Article 14, manufacturers must submit notifications via the ENISA Single Reporting Platform — a centralised intake routed simultaneously to the CSIRT of your main EU establishment and to ENISA itself. The platform is scheduled to be operational by 11 September 2026. As of early May 2026, it is not yet live, and no registration URL has been published.

The reporting cascade has three stages.

Within 24 hours of awareness: an “early warning” — a minimal alert containing product identification, a brief description, and an initial severity assessment. This is the deadline that triggers the operational pain. You don’t need a full root cause analysis. You need to confirm the trigger event, assemble the basic evidence, and get the notification through the platform. The clock starts the moment your team becomes aware that exploitation is occurring.

Within 72 hours: a full notification including technical details, affected versions, exploitation method, and remediation timeline. This requires meaningful investigation work — comparable to what NIS2 and GDPR already demand for their own 72-hour windows.

Within 14 days (vulnerabilities) or one month (severe incidents): a final report covering root cause, complete technical description, remediation actions, and confirmed impact. Each submission builds on the previous one.

Two triggers matter. An “actively exploited vulnerability” means the vulnerability is being weaponised against your product in the wild — not theoretical, not patched in development, actively in use by attackers. A “severe incident” means an event that materially affects product security or could enable malicious code execution in the product or in user systems.

The reporting clock does not run on awareness of a vulnerability — it runs on awareness of exploitation. That distinction is the entire engineering challenge.

Why most DevOps pipelines aren’t ready

Walk into a typical mid-size EU or UK SaaS company today and ask five questions:

1. Do you have a complete, machine-readable SBOM for every product you ship?
2. Can you correlate a newly-published CVE against your SBOMs in under an hour?
3. Do you monitor exploitation telemetry — not just vulnerability presence, but evidence of active attempts in your production environment?
4. Do you have a documented timestamp of “awareness” for every security incident, with a clear chain of custody?
5. Can your on-call team initiate a regulatory notification at 2am on a Friday without waking your CISO?

Most teams answer yes to one, maybe two. The remaining gaps are exactly where the 24-hour clock breaks down.

The structural problem is that traditional vulnerability management is static. You scan, you triage, you patch on a cadence. The CRA assumes your operations are dynamic — that exploitation can be detected and assessed in near-real time, that evidence is automatically captured with timestamps, and that the path from telemetry signal to filed report is operational rather than ad hoc. Most engineering organisations were not built for that.

There’s also a less-discussed problem: scope ambiguity. The CRA applies to “products with digital elements” — a phrase that includes embedded software, IoT devices, mobile apps, operating system components, and the remote data processing solutions that make those products work. If you ship a SaaS product that runs entirely in your cloud, you may or may not be in scope depending on how it’s delivered. If your product includes a connected device or a downloadable agent, you almost certainly are. Most teams haven’t done the scoping exercise yet, which means they don’t know which of their products start the clock on 11 September.

The DevOps audit: what to fix before September

Here’s the practical work, organised by capability layer. None of these are optional. All of them take longer than four months if you start late.

SBOM coverage and freshness

Article 14 reporting effectively requires SBOMs as a precondition. When CISA adds a new vulnerability to the Known Exploited Vulnerabilities catalog, you need to know within minutes — not days — whether your products contain the affected component. If you can’t answer that question fast, you can’t determine whether the 24-hour clock has started, let alone meet it.

The fixes:

• Generate SBOMs for every product as part of the CI/CD pipeline. Use a standard format (CycloneDX or SPDX). Make them machine-readable, not PDFs.
• Cover both first-party and transitive dependencies. The CRA explicitly references “top-level dependencies” as a minimum, but real-world exploitation usually targets transitive ones. Aim for full coverage.
• Pin SBOMs to specific build artifacts. Each release of each product needs its own SBOM, archived with the binary.
• Implement automated correlation against vulnerability databases — the CISA KEV catalog, NVD, GitHub Security Advisories, OSV.dev. New entries should trigger automated checks against your SBOM inventory.

Exploitation telemetry, not just vulnerability detection

Knowing that a vulnerability exists in your product is not the same as knowing it’s being exploited. The 24-hour clock starts on the latter. This is where most teams have the biggest gap.

The fixes:

• Application-level telemetry that can detect anomalous behaviour patterns associated with known exploitation techniques — not just “is the CVE present” but “is something attempting to use it?”
• Integration between your runtime observability stack (Datadog, Dynatrace, New Relic, Grafana, whatever you use) and your vulnerability management platform. The two should share context.
• Customer-reported incident channels that feed into the same workflow. A coordinated vulnerability disclosure (CVD) policy with a clear intake URL is no longer optional — it’s a piece of compliance infrastructure.
• Threat intelligence feeds that surface active exploitation campaigns targeting your product category.

Awareness timestamping and audit trail

When a regulator asks “when did you become aware?”, you need an answer that survives legal scrutiny. Verbal recollections won’t pass.

The fixes:

• Every security signal that could trigger a CRA reporting obligation must be automatically timestamped at the moment it enters your system — whether from internal telemetry, a customer report, a researcher disclosure, or a public CVE database.
• Chain of custody must be preserved. Who saw it, when, what action they took. This is standard incident response hygiene, but most teams do it inconsistently.
• Retention policies must align with CRA expectations — typically the support period of the product, or up to 10 years depending on the obligation.
• The audit trail must be exportable in a format that maps cleanly to the ENISA Single Reporting Platform’s submission templates, once those templates are published.

Pipeline controls for “substantial modifications”

The CRA introduces a concept that catches many teams off guard: a “substantial modification” can re-trigger compliance obligations. Routine patches and minor functional changes don’t count. But adding new functionality, changing the security model, or modifying data handling can. If your CI/CD pipeline ships frequently, this matters.

The fixes:

• Tag releases by type — security patch, feature addition, breaking change. Automate the classification where possible.
• Build a review gate for any change that adds new functions or alters cybersecurity-relevant behaviour. This is where DevSecOps policy-as-code earns its keep.
• Maintain documentation showing your reasoning for why a given change was or wasn’t a substantial modification. Regulators will want to see the framework, not just the conclusion.

On-call and escalation rota

The 24-hour clock will run on weekends, holidays, and Friday evenings. Your existing on-call structure probably wasn’t designed for regulatory disclosure.

The fixes:

• Pre-authorised escalation rota covering nights, weekends, and bank holidays. At least two named individuals who can initiate an early warning notification without waiting for senior sign-off.
• Pre-approved notification templates for the 24-hour early warning and the 72-hour follow-up. Pre-approved templates are the single biggest time-saver when the clock is running. Get them written and legally reviewed now, not in the moment.
• Tabletop exercises before September. Run a Friday-evening exploitation scenario end-to-end. Time how long it actually takes to file the early warning. Whatever number you get, plan for it being twice that during a real incident.

Coordination with parallel regimes

The CRA doesn’t replace your existing reporting obligations — it adds to them. If a CRA-reportable incident also involves personal data, you have a separate 72-hour GDPR notification to your data protection authority. If you’re in scope for NIS2, you have additional national notification duties. The same incident can require three coordinated submissions.

The fix: build a single incident response workflow that decisions all three regimes simultaneously, with checklists for each. Don’t let your CRA process be parallel infrastructure to your NIS2 and GDPR processes — they need to be unified.

The OpsHero perspective: this is genuinely solvable, but only if you start now

We’ve been working with European clients on CRA readiness throughout Q1 2026, and the pattern is consistent: the engineering work is achievable, but it’s substantial, and the four-month window is the binding constraint.

The companies that will hit September 2026 in good shape have three things in common. They’ve already done the scoping exercise — they know which of their products are in scope and have an explicit list. They’ve prioritised the SBOM and exploitation telemetry layers over the more visible “policy” work, because those are the longest-lead capabilities to build. And they’ve integrated their CRA workflow with their existing GDPR and NIS2 processes from day one, rather than building parallel pipelines that will inevitably drift.

What worries us most is the medium-sized companies — typically 50 to 500 engineers, often shipping connected products into the EU as a meaningful portion of revenue — who have read about the December 2027 deadline and concluded they have time. They don’t. They have until September. And the work they need to do is engineering work, not legal work, which means it can’t be outsourced to counsel and ticked off in a final-quarter sprint.

If you’re reading this and you can’t answer the five questions from earlier in this post — start there. Each one points at a capability you’ll need before the clock starts running.

Five questions to answer about your pipeline this month

These are the questions we walk every CRA-readiness engagement through. Honest answers point at your roadmap.

1. Do you have a complete inventory of every product currently on the EU market that qualifies as a “product with digital elements” — and a documented assessment of which ones are in CRA scope?

1. Can your team determine, within one hour of a new CVE being published, whether any of your in-scope products are affected?

1. Do you have application-level telemetry that distinguishes between vulnerable and being actively exploited — and can you produce a timestamped record of the moment exploitation was first detected?

1. Have you written and legally reviewed the pre-approved templates for the 24-hour early warning and 72-hour notification, with named owners and a tested escalation rota that covers weekends?

1. Is your CRA reporting workflow integrated with your GDPR (72-hour) and NIS2 obligations so that one incident produces coordinated submissions, not three independent fire drills?

Most teams I’ve spoken with this quarter can answer two. That’s not a failure. It’s a four-month roadmap.

The September 2026 deadline isn’t going to move. The Single Reporting Platform will go live whether your engineering layer is ready or not. The teams that build now — deliberately, with the right priorities — will be the ones whose first real CRA notification looks like a controlled, evidence-rich submission. The teams that wait will be the ones whose first notification arrives as a missed deadline, with all the regulatory consequences that follow.

You have four months. Start with the SBOMs.

---

Need help running a CRA readiness audit for your engineering organisation? OpsHero has been working with EU technology companies on CRA, NIS2, and DORA-aligned DevSecOps readiness throughout 2026. We can help you scope, prioritise, and operationalise the engineering controls before September. Let’s talk.