Dora NodaOn September 11, 2026, the EU's Cyber Resilience Act stopped being a compliance date on a slide deck and became an operating reality. Since that Friday, any manufacturer of a product with digital elements sold into the EU — hardware or software, one-person shop or platform vendor — must file an early warning within 24 hours of learning that a vulnerability in its product is being actively exploited. The filing portal, ENISA's Single Reporting Platform, went live the same day the obligation began. There was no grace period, no soft launch, and no alternate channel: the platform is the only way to file.
This matters to self-hosted PaaS vendors more than most of them expected. If your product is open-source platform software that tenants deploy on machines they own, you are very likely a manufacturer under the Act, not a lightly-regulated open-source steward — the moment money changes hands around the software, the steward regime stops applying. And the clock that now governs your vulnerability response runs in hours, not sprints.
The first week of coverage tells a consistent story: the deadline is not the hard part. Knowing whether the deadline applies to you, within a day, is.
The timeline, precisely
Article 14 of the CRA sets a three-stage, progressive clock. The trigger is awareness: the countdown starts the moment you become aware of an actively exploited vulnerability in your product or a severe incident affecting its security.
| Stage | Actively exploited vulnerability | Severe incident |
|---|---|---|
| Early warning | Within 24 hours of awareness | Within 24 hours of awareness |
| Fuller notification | Within 72 hours | Within 72 hours |
| Final report | Within 14 days of a corrective or mitigating measure becoming available | Within one month of the 72-hour notification |
Two scope facts routinely surprise vendors. First, the reporting duty covers products already on the EU market — legacy releases you shipped years ago are in scope, not just what you ship after September. Second, the duty continues after a product's support period ends. You cannot age out of the obligation by declaring a release end-of-life.
The staged design is deliberate. As ENISA spokesperson Laura Heuvinck told TechTarget in the first week, the process is "intentionally progressive": the 24-hour early warning carries whatever information is available at that stage, and the later filings add detail as the investigation develops. The early warning is a signal flare, not a root-cause analysis. But you still have to decide, within a day, that the flare needs firing.
What the first week exposed: three questions in 24 hours
TechTarget's September 16 report, the most grounded first-week coverage, framed the operational problem exactly right: before a team can report in 24 hours, it must answer three questions. Is the flaw present in a shipped product? Is it under active exploitation? And is it genuinely exploitable in our implementation, rather than merely present in a dependency?
That last question is where scanners stop and engineering starts. IDC research director Katie Norton put it bluntly: "Before a company can report in 24 hours, it must know which products contain the affected component, where they're deployed and whether the flaw is genuinely exploitable in its own product rather than just present in a dependency. That last judgment takes engineering, not a scanner."
Consider what each question demands of a PaaS vendor concretely:
Which shipped products contain the affected component? This requires a component inventory that extends back to older releases — per-version records of what shipped, including dependencies. For a platform with a fast release cadence, that means every release needs a bill of materials you can query years later, not a spreadsheet someone updates when they remember. Older products are the sharp edge here: developers leave, suppliers drop components, build environments become unreproducible, and the team ends up reconstructing inventories from shipped artifacts.
Is it under active exploitation? The CRA's definition is factual, not speculative: there must be reliable evidence that a malicious actor has exploited the vulnerability in a system without the owner's permission. Meeting that bar in 24 hours requires an intake workflow that connects exploit intelligence — a CISA KEV listing, a threat-feed alert, a customer report — to incident triage the same day it lands, including weekends and holidays. On-call coverage is not optional under this regime; the clock does not pause for Saturday.
Is it exploitable in our implementation? A CVE in a library you bundle is not automatically a vulnerability in your product. The affected function may be disabled, the interface unexposed, the component sandboxed. Making that determination in hours requires engineers who know the product's architecture on call and a written procedure saying who is authorized to make the call. This is the judgment the whole regime pivots on — and, as the first week's legal analysis showed, it is also the least settled part of the law.
The genuinely unclear case: real vulnerability, impossible exploit
On September 14, three days after the obligations took effect, Ropes & Gray published the analysis every product-security team should read: what happens when the vulnerability is real, actively exploited somewhere in the world, and impossible to exploit in your product?
The interpretive problem is structural. Article 14(1) requires manufacturers to notify "any actively exploited vulnerability contained in the product" — with no qualifier for severity, materiality, or impact. The triggers are two factual questions: is there reliable evidence of exploitation in the wild, and is the vulnerable component contained in the product? A product-specific exploitability analysis — the vulnerable function is unreachable in our configuration — is arguably beside the point of the reporting trigger, even though it is the entire point of the actual risk.
Ropes & Gray gives three reasons a vendor should not treat "not exploitable in our implementation" as a reporting exemption:
- Severity and impact enter the regime at the later reporting stages, which expressly ask for them — suggesting they are things you communicate through the process, not gates before it.
- Neither Commission nor ENISA guidance introduces a materiality filter; if regulators wanted one, the implementation material would say what it is.
- A market surveillance authority may take the strict view that Article 14(1) deliberately imposes a broad duty, and a vendor that chose not to file would be defending an interpretive position with limited authoritative support.
The conservative posture follows directly: file the early warning within 24 hours when the statutory conditions are met, and use the 72-hour and final stages to explain the product-specific circumstances, including why the flaw has limited or no practical impact in your implementation. Treat exploitability analysis as an internal prioritization tool and a documented assessment — which also feeds the separate duty to inform affected users — not as a reason to stay silent. Over-reporting with a clear technical explanation is cheap; defending a non-reporting decision to a regulator is not.
This is also the strongest argument for doing the exploitability analysis fast rather than skipping it. The analysis still matters enormously: it determines your severity rating, your corrective measures, and what you tell users. It just does not buy you the right to miss the 24-hour window while you deliberate.
What the clock demands of an Apache-2.0 PaaS vendor
Translate the regime to a concrete vendor profile: an open-source, Apache-2.0-licensed PaaS whose customers deploy it on their own machines. Here is the readiness checklist the first week implies, item by item.
Know which regime you are in. Non-commercial open source sits outside the CRA, and open-source stewards carry light obligations with no fines. But where free software is placed on the market in the course of commercial activity — hosted offerings, paid editions, support contracts around the software — the responsible company qualifies as a manufacturer with the full duty set. If you sell anything around the software, assume you are a manufacturer and plan for the 24-hour clock.
Build a per-release shipped-version inventory. For every release, record exactly what shipped: your code at a pinned revision plus every dependency, ideally as a machine-readable SBOM generated at build time and archived where incident response can query it. The TechTarget test — "which products contain the affected component" — must be answerable in minutes, for current and legacy releases alike. If your SBOM story today is "we could reconstruct it," you do not have one.
Wire exploitation telemetry to triage. Designate the feeds that can start your clock — CISA's Known Exploited Vulnerabilities catalog, vendor advisories, customer reports — and build an intake workflow that routes them to a human who can open an incident the same day. IDC's advice to CISOs applies directly: the intake workflow must connect the exploit notification to triage, identify the affected asset from inventory context, and, where remediation cannot be immediate, stand up monitoring with updated detection logic.
Write a disclosure runbook with a one-day fuse. The runbook needs named decision-makers authorized to determine that the reporting threshold is met, on-call coverage through weekends and holidays, pre-arranged access to the Single Reporting Platform (authentication runs through EU Login — do not discover this at hour 20), and templates for the early warning, the 72-hour notification, and user communications. Then rehearse it: a runbook nobody has walked through will not survive first contact with a real 24-hour fuse.
Push evidence requirements upstream. Supplier notifications flow through the product chain and can impose obligations on you, so IDC's Michelle Abraham advises writing CRA evidence requirements into supply-chain contracts: what evidence suppliers must provide and early enough for you to meet your own deadlines. For a PaaS built on upstream open-source components, this means knowing who tells you about exploitation in your dependencies and how fast.
Do not forget the users. Beyond regulatory notification, manufacturers may have to inform affected users — and where appropriate other users — about the vulnerability or incident and about corrective or mitigating measures. Your documented product-specific assessment does double duty here: it shapes both the regulatory filing and the user advisory.
December 2027 is not an excuse
The most dangerous sentence in CRA planning is "full application is December 2027." Full application — December 11, 2027, with CE marking, essential requirements, and the complete duty set — is fifteen months away. But the reporting duty is enforceable now, noncompliance carries fines up to 15 million euros or 2.5% of worldwide annual turnover, and the operational capabilities the clock demands cannot be built in the week you first need them.
The burden also falls unevenly in ways that should worry small vendors most. As IDC's Norton observed, the work scales with the number of products, not the size of the company: a five-person firm and a 5,000-person firm with the same three products face roughly the same job, and only one has a compliance function. Microenterprises and small manufacturers are spared fines solely for missing the 24-hour deadline — but the reporting obligation and all subsequent stages still apply. The exemption softens the penalty, not the workload.
There is also little point running two product-security processes. Finite State's Doc McConnell, a former CISA branch chief, told TechTarget the CRA is "a stricter standard by far than the current requirements in the U.S.," with the closest American analog being the Cyber Incident Reporting for Critical Infrastructure Act — and predicted manufacturers selling into the EU will not maintain a strong process for Europe and a weaker one everywhere else: "It's already turning into the practical baseline." SANS instructor Jan D'Herdt made the same point from the EU side: the Act applies to products sold into the EU regardless of where the manufacturer sits, so vendors from North America to Asia-Pacific are likely to adopt one CRA-aligned process globally rather than regional variants. Build the capability once, to the strictest bar you face.
The readiness data suggests most vendors are starting late. OpenSSF's June 2026 awareness report found only about a third of respondents correctly identifying the compliance timeline, with a majority saying they were unfamiliar with the Act. If your team is in that majority, the first week of the reporting regime is the cheapest possible moment to start: every artifact — the SBOM pipeline, the intake workflow, the runbook, the platform access — is useful before it is urgent, and none of them can be created inside a 24-hour window.
As Heigor Freitas of the Council of Registered Ethical Security Testers told TechTarget, the reporting duty should be read as a baseline, not a destination: "While the CRA sets an essential baseline, it should not be seen as the ultimate destination for cyber resilience." The vendors who treat the 24-hour clock as the floor of their product-security operations — inventory, telemetry, runbook, rehearsal — will find December 2027 a paperwork exercise. The ones who treat it as next year's project will discover, at the worst possible moment, that the clock started last week.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
