The Cyber Resilience Act's 24-hour problem

The Cyber Resilience Act's first hard deadline landed on 11 September 2026. Not the big one, full application is still 11 December 2027, but the one that matters right now if your organisation ships anything with code or a chip in it into the EU, or if you're evaluating vendors who do: mandatory reporting of actively exploited vulnerabilities and severe incidents.

If you're sitting across from your risk committee or fielding a vendor security questionnaire this quarter, here's what actually applies, stripped of the legal hedging most of what's published on this reduces to.

What the CRA covers

The CRA applies to "products with digital elements": hardware, software, and the remote backends they depend on to function, placed on the EU market. That's deliberately broad, broad enough that at some point during our own scoping exercise someone in the room asked, entirely seriously, whether the office kettle counted. It doesn't, but the fact the question felt worth asking tells you something about how wide the net is. Consumer IoT, routers, operating systems, mobile apps, firmware, SDKs and libraries distributed as components, all in scope.

Pure SaaS is generally excluded. If a product runs entirely on the vendor's own infrastructure and a user reaches it through a browser with nothing installed on their side, Article 2(2) and Recital 9 keep it out. But the exclusion has a hole in it: if a cloud backend is what makes a physical or installed product work, that backend counts as part of the product and falls back into scope. This is worth asking any vendor directly, not assuming from their category label. "We're SaaS" is a category, not a legal defence, and it won't do much for you in front of a market surveillance authority either.

One more scope point worth checking, for your own products and your vendors': Article 69(3) covers old products too, not just new ones. If it's still on the EU market and an exploited vulnerability turns up, the CRA doesn't care when it shipped, the regulatory equivalent of your landlord turning up about a leak from a boiler installed under a previous government.

What has to be reported, and when

Not every bug. Not every patch. Only two triggers count: a vulnerability that's being actively exploited, and a severe incident affecting the product's security. A flaw found and fixed before anyone exploits it stays in normal vulnerability handling and never touches this reporting channel, which is the one piece of mercy the CRA shows anyone.

Once one of those triggers fires, the clock is 24/72/14:

• 24 hours: early warning to ENISA and the national CSIRT through the Single Reporting Platform, even before full details are known.
• 72 hours: a fuller notification covering the nature of the vulnerability or incident, an initial impact assessment, and any mitigation available so far.
• 14 days after a fix is available: a final report with root cause, severity, and what was done. For a severe incident rather than a vulnerability, that final window stretches to one month.

One report, one platform, ENISA routes it to the right member state CSIRT. That part is well designed. The part that catches people out is the 24 hour figure: it starts the moment the organisation has determined the product is affected and being actively exploited, not when a CVE gets published or a researcher sends an email, and definitely not when someone gets back from lunch.

If you're assessing a vendor, this is a fair question to put to them directly: do they have a documented process that hits 24 hours, or a vulnerability management policy that was never built to run on a government clock and is about to find that out the hard way.

Self-assessment or something heavier

The reporting deadline isn't the only clock running. The other question worth having answered, for your own products and anything you're procuring, is how conformity gets proven at all. That depends on which of four tiers a product lands in.

Most products, including most software, are "Default". Self-assessment: technical documentation, a declaration of conformity, the CE mark. No external body reviews any of it, the manufacturer carries the legal responsibility, which is either refreshingly trusting of the EU or a very polite way of saying "we'll be checking your homework later."

Important, Class I covers things like identity management and access control software, browsers, password managers, VPNs, network management tools, SIEM systems. Self-assessment is still possible here, but only if a harmonised standard covers the requirement in full. No standard, no self-assessment, a notified body gets involved instead.

Important, Class II (operating systems, hypervisors, firewalls, intrusion detection and prevention systems) and Critical (hardware security modules, smart cards, smart meter gateways) skip self-assessment entirely. A notified body is mandatory regardless of what standards exist. No door marked "just this once."

The catch right now is that the Class I escape hatch is only as open as the standards behind it, and those standards aren't finished. European standardisation bodies are still drafting them, and until one is published in the Official Journal, applying it doesn't give the legal presumption of conformity the whole system is built around. Notified bodies themselves have only been able to register as notified bodies under the CRA since 11 June 2026, so even the mandatory third-party route has a thin bench to work with. If a vendor tells you they're Important Class I and self-assessing, worth asking which standard they're relying on and whether it's actually been published yet, or whether they're self-assessing against a standard that exists mainly in a draft folder and someone's optimism.

Where we sit with Elba

We get asked this in procurement conversations often enough that it's worth putting in writing. The test the Commission's own guidance uses is core functionality, the main thing a product exists to do, not every component inside it. Integrating a component that resembles an Annex III category doesn't automatically pull the whole product into that category, the Commission's own example is that a smartphone embedding an operating system isn't itself classified as "an operating system." Elba's core functionality is agentic workflow automation across voice and messaging, task completion inside customer systems. That's not identity management, not a VPN, not network management software in the sense Annex III means it.

Components like our MCP gateway, which lets agents reach downstream systems, have always been internal infrastructure. It's never been on our roadmap to sell separately. That happens to matter under the CRA too: a component only gets its own separate classification if it's placed on the market separately. Kept internal, it stays part of Elba's classification, not its own.

That reads as Default to us: self-assessment, no notified body. Worth being precise about the caveat, since we'd rather a CISO doing due diligence on us get an accurate picture than a reassuring one, and we'd rather field the follow-up question now than the awkward one later. Our production deployments today are hosted, which is the shape the SaaS exclusion is written for. We also offer on-prem and private-cloud deployment, which doesn't get that exclusion at all, on-prem software is squarely a product placed on the market the day it ships, no ambiguity, no small print. We're doing this classification work ahead of any such deployment going live rather than under it. If you're evaluating us, or any vendor with a similar shape (hosted today, on-prem available, an internal gateway component mediating access to your systems), that's the exercise worth asking them to walk you through: classification by core functionality, not by category label, and whether any internal component might ever be sold or offered standalone.

The gap in most vulnerability management programs

We went through our own setup ahead of the reporting deadline and found what I'd guess most organisations find if they look honestly. Our internal vulnerability management policy was solid: find a problem, triage it, fix it, log it. What it didn't cover was reporting that same problem to the outside world within 24 hours of finding it. In our defence, so did almost everyone else's. The CRA didn't expose bad security practice so much as a filing cabinet nobody had labelled "and then tell Brussels."

Those are two different processes. Internal handling and external notification need separate owners and separate runbooks, because the second one runs on a government clock and the first one doesn't. An internal-only policy is a gap that won't show up until someone is timing it against 24 hours for real, at which point discovering the gap and discovering the incident tend to happen in the same unpleasant afternoon. Worth checking your own organisation's policy for the same blind spot, and worth asking vendors whether theirs covers both halves or only the one that was always there.

Article 10(6) also requires a documented coordinated vulnerability disclosure policy, the process by which outside security researchers can report a flaw responsibly. Worth confirming that exists in writing, not just as an informal practice, for your own organisation and anyone you're assessing.

Prepare identity now, register the platform when it's needed

Two separate steps here, and conflating them is an easy mistake. An EU Login account with multi-factor authentication is generic EU infrastructure, nothing CRA-specific about it, ready for a designated filer and a backup any time. Registering as an Assigned Representative on the Single Reporting Platform itself, tied to the manufacturer entity and validated by the coordinating CSIRT, is different, and ENISA has explicitly asked manufacturers to leave that step until they have an actual notification to submit, so CSIRTs aren't validating accounts for organisations that may never file anything.

Which puts you racing a 24-hour clock the moment an incident happens, while the authority setting that clock tells you not to pre-position the one piece of infrastructure it depends on. A bit like being handed a fire extinguisher and told not to take it out of the box until the building's already alight. Do everything ENISA doesn't object to in advance: live EU Login accounts, a named Primary and backup representative, the coordinating CSIRT identified, report templates drafted. Leave the platform registration itself for the moment it's needed.

What I'd tell a CISO or DPO looking at this today

Don't wait for December 2027, whatever you believe in won't file the report for you. The reporting obligation is live now, it can apply to products placed on the market years ago, and the platform involved only existed from the day it was needed. Get your own classification straight, by core functionality rather than by label, split internal and external reporting processes, and have identity infrastructure ready before the reporting platform itself is. Then ask the same questions of your vendors.

Most of compliance is unglamorous timing work done early, on both sides of a procurement relationship. It's not thrilling. Nobody's putting "beat the CSIRT to it" on a highlight reel. But the alternative is explaining to your board why the first time your organisation touched a government reporting portal was also the day something was actively on fire, and that's a much worse story to be telling, even with good posture and a strong voice. Brussels isn't grading on delivery.