The CRA's 24-Hour Clock Starts September 11. Most Software Teams Think They Have Until 2027.

The Deadline Everyone Skipped Past

Ask an engineering leader in Europe when the Cyber Resilience Act starts to matter and you'll almost always get the same answer: December 2027. It's an understandable answer, because December 11, 2027 is when the CRA's full set of obligations applies — CE marking, conformity assessment, the complete essential cybersecurity requirements, the retained technical documentation. That's the date on the compliance slide deck, and it's comfortably far away.

It's also not the next deadline. The European Commission's own CRA reporting guidance is explicit: the reporting obligations commence on September 11, 2026, when the Single Reporting Platform that ENISA was tasked with building under Article 16 becomes operational. From that date, manufacturers of products with digital elements must notify actively exploited vulnerabilities and severe security incidents on a fixed statutory clock. There is no phase-in, no grace period for organizations still standing up their process, and no exemption for products that were already on the EU market before the CRA fully applies.

That last point is the one that catches teams off guard. The reporting duty from September 2026 covers in-scope products already made available on the EU market, not just new releases shipped after December 2027. If you have software in the field in Europe today, the reporting obligation reaches it in a matter of weeks — well before the conformity machinery most organizations are budgeting for in 2027.

The gap between those two dates is where the risk sits. Organizations have built their CRA programmes as 2027 projects, staffed accordingly, and left the reporting duty as a downstream detail to be handled once the broader compliance work is underway. The sequencing is backwards. Reporting is the obligation that bites first, and it's the one that demands operational readiness — people, on-call rotations, decision authority — rather than documentation.

What Actually Triggers a Report (It Isn't Every CVE)

The most common misreading of the CRA reporting duty is that it turns every vulnerability disclosure into a regulatory filing. It doesn't, and the distinction matters enormously for how much process you need to build.

Two things trigger a notification. The first is an actively exploited vulnerability in your product with digital elements — meaning there is evidence of exploitation in the wild, not merely a theoretical weakness or a published CVE with a proof of concept. The second is a severe incident having an impact on the security of the product. A routine dependency CVE that nobody is exploiting does not start the clock. A vulnerability in your product that attackers are demonstrably using does.

That sounds like a manageable filter until you ask the operational question underneath it: who in your organization is capable of determining, within hours, whether a vulnerability in your own software is being actively exploited? For most teams, the honest answer is that this determination requires telemetry they don't collect, threat intelligence they don't subscribe to, and a judgment call nobody has been formally assigned. The legal test is narrow. The engineering capability required to apply that test quickly is not.

There's a second-order consequence for teams with heavy open-source dependency trees. Deciding whether an actively exploited upstream vulnerability constitutes an actively exploited vulnerability in your product requires knowing whether your product actually reaches the vulnerable code path — which requires dependency visibility most organizations discover they lack precisely when they need it most.

The 24 / 72 / 14 Clock, Precisely

The timeline is prescriptive, and it runs from the moment of awareness rather than the moment of confirmation. An early warning is due within 24 hours of becoming aware of the actively exploited vulnerability or severe incident. A full notification follows within 72 hours. A final report is due no later than 14 days after a corrective measure becomes available for an actively exploited vulnerability, or within one month for a severe incident.

Submission runs through a single channel. Manufacturers report once, via the CRA Single Reporting Platform, addressed to the Computer Security Incident Response Team of the relevant member state. The receiving CSIRT then distributes the notification to other relevant CSIRTs and to ENISA. A delegated act adopted on December 11, 2025 sets out the narrow cybersecurity grounds on which that onward sharing can be delayed — a useful provision, but not one that changes your own filing deadline.

What makes the 24-hour figure demanding isn't its length in the abstract. It's that the clock starts on awareness, and awareness can arrive at 2am on a Sunday via a customer email, a security researcher's tweet, or an alert from a monitoring tool nobody was watching. Twenty-four hours is a comfortable window if you have a defined intake path, a named decision-maker, and a pre-drafted notification template. It is a genuinely difficult window if the first hour is spent working out who is allowed to decide that a report is required.

Outsourcing the Code Does Not Outsource the Obligation

This is the part that ought to reshape vendor conversations over the next two months. The CRA places its obligations on the manufacturer — the entity that develops or has developed a product with digital elements and places it on the EU market under its own name or trademark. If you commission software from an agency, a contractor, or an offshore development partner and ship it under your brand, you are the manufacturer. The reporting duty is yours.

Your development partner has no CRA reporting obligation to the regulator on your behalf. What they have is something arguably more important operationally: the knowledge, access, and engineering capacity required for you to meet your obligation. If a vulnerability in your product is being actively exploited, the people who can tell you which versions are affected, whether the vulnerable path is reachable, and how quickly a corrective measure can ship are the people who wrote the code. If those people are in a distant timezone, working through an account manager, and contractually obliged only to respond to tickets within two business days, your 24-hour regulatory clock is running against a supply chain that cannot keep pace with it.

The practical implication is that CRA readiness is now a vendor selection criterion and a contractual one. Development agreements written before 2026 almost certainly lack the security incident cooperation clauses this regime requires: a defined escalation path, a committed response window measured in hours rather than days, an obligation to preserve and share diagnostic information, and named technical contacts who can be reached outside business hours. Teams renegotiating outsourcing contracts this year should be treating these terms as non-negotiable rather than as boilerplate.

This is one of the underappreciated structural arguments for nearshore development inside the EU. A dedicated team in Serbia working on European hours overlaps your entire business day, sits within a compatible legal and regulatory culture, and — because the engineers are the same people every sprint — actually knows the codebase well enough to answer 'is this reachable in production?' in minutes. Stepto builds teams on exactly that model: direct-hire senior engineers embedded in your organization rather than rotating ticket-takers, which is the difference between a 24-hour clock you can meet and one you can only apologise for missing.

The SBOM Requirement and the End-of-Life Dependency Trap

Running alongside the reporting duty is the CRA's software bill of materials obligation. Manufacturers must create, maintain, and retain an SBOM for products with digital elements placed on the EU market, in a commonly used machine-readable format, covering at minimum the top-level dependencies of the product. The SBOM lives in the technical documentation and is provided to market surveillance authorities on reasoned request — it is a compliance artefact, not something you're required to publish.

The minimum bar of top-level dependencies sounds forgiving, and compared to a full transitive graph it is. But 'maintain' is doing quiet work in that sentence. An SBOM that reflects your dependency tree as of the last release, regenerated manually when someone remembers, is not a maintained artefact. Meeting this obligation means SBOM generation becomes a build-pipeline step with the same reliability expectations as your test suite.

The sharper problem is end-of-life dependencies. The CRA requires that components in your product be identified and tracked regardless of the compliance status of the component itself, and it requires that vulnerabilities be handled with due diligence. A dependency that no longer receives security updates from anyone is a structural problem under this regime: you cannot apply a corrective measure that doesn't exist, and 'upstream is abandoned' is not a defence that scales across a portfolio. Analyses of CRA readiness have flagged EOL components as one of the most common and least tractable gaps in existing products.

The CRA does soften the position for the open-source ecosystem itself. It creates a distinct 'open source steward' category for legal persons providing ongoing support to free and open-source software intended for commercial activity, with obligations lighter than a manufacturer's — no CE marking, no formal conformity assessment, no retained technical documentation requirement. Individual volunteer maintainers stay out of scope. That's a sensible carve-out, but it's a carve-out for the maintainers. It does nothing to reduce your obligation as the manufacturer of a product that depends on their code.

What 24-Hour Readiness Actually Requires of an Engineering Organization

Strip away the legal framing and the reporting obligation reduces to a handful of concrete capabilities, most of which are engineering and organizational rather than legal. You need a single intake path where any signal of exploitation — customer report, researcher disclosure, monitoring alert, upstream advisory — lands somewhere monitored, rather than in whichever inbox the reporter happened to guess. You need a named person, with a named backup, authorised to make the 'is this actively exploited?' determination without convening a committee.

You need enough production telemetry to answer the exploitation question at all. This is where many organizations discover their real gap: the legal test asks about exploitation in the wild, and answering it requires observability into how your deployed software is actually being used and abused. You need version-to-customer mapping, so 'which of our releases contain this?' isn't a research project. And you need a pre-drafted notification, because composing a regulatory filing from scratch under time pressure is how organizations file incomplete reports.

Finally, you need to have rehearsed it. A reporting process that exists only as a document has never been tested against the failure modes that actually occur — the decision-maker on holiday, the vendor contact who has left the company, the telemetry gap discovered at hour three. Organizations that run a tabletop exercise against this timeline before September consistently find two or three broken assumptions. Finding them in August is inexpensive. Finding them during a live exploitation event is not.

Why the Penalty Structure Changes the Calculus

Non-compliance with the CRA's essential cybersecurity requirements and with the reporting obligations in Articles 13 and 14 carries administrative fines of up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher. That is GDPR-scale exposure attached to an obligation most engineering organizations have not yet operationalised.

The more consequential shift is structural rather than financial. The CRA brings software into a product-safety enforcement model, complete with market surveillance authorities empowered to demand documentation and, in the limit, to restrict products on the EU market. Software vendors are accustomed to security obligations arriving through contracts and customer questionnaires, where the counterparty is a commercial partner with an interest in a working relationship. A market surveillance authority is not that counterparty.

For organizations weighing how much to invest before September, the useful framing isn't the maximum fine — it's that the reporting obligation is the first point at which a regulator will observe, directly and on a clock, whether your security operation functions. A missed 24-hour notification is a visible, documented failure. It is a poor way to introduce yourself to the authority that will later assess your conformity in 2027.

Building the Capability Rather Than the Paperwork

The organizations that will handle September well are not the ones with the thickest compliance binders. They're the ones whose engineering teams can detect, triage, and remediate quickly enough that a 24-hour regulatory notification is a routine byproduct of an incident response they were going to run anyway. That capability is built from ordinary engineering discipline: dependency visibility, production observability, tested release-to-customer traceability, and enough senior judgment on the team to distinguish a theoretical CVE from an exploited one.

That last ingredient is the scarcest, and it's where the staffing model matters. Making an exploitation determination under time pressure requires engineers who understand the system deeply enough to reason about reachability and blast radius. It's not work that can be handed to whoever is available in a rotating pool, and it's not work that survives high contractor churn — the knowledge required is accumulated, not provisioned.

This is the case Stepto makes for dedicated nearshore teams over project-based outsourcing, and the CRA sharpens it considerably. Senior engineers in Serbia working as a persistent extension of your team build exactly the accumulated system knowledge that a 24-hour clock demands, on European hours, within an EU-adjacent legal and regulatory environment. When the obligation is to answer hard technical questions about your own product before tomorrow, continuity of the people who built it stops being a nice-to-have and becomes the mechanism by which you comply.