On 11 September 2026, the first operational obligation of the EU Cyber Resilience Act comes into force. Manufacturers of products with digital elements must report actively exploited vulnerabilities and severe security incidents to their national CSIRT and to ENISA, starting with an early warning within 24 hours of becoming aware.
Most CRA coverage aimed at business has been about documentation: conformity assessment, technical files, CE marking, software bills of materials. None of that is due yet. What lands in September is the one CRA obligation you cannot satisfy with a document. It is an on-call duty, and it is measured in hours.
TL;DR
- 11 September 2026: CRA reporting applies. Early warning in 24 hours, technical notification in 72, final report in 14 days, or one month for a severe incident.
- The trigger is active exploitation, not disclosure. A CVE in your dependency tree is not reportable. Reliable evidence that someone is exploiting it in the wild is.
- It reaches backwards. Article 69(3) covers products already on the EU market, including software shipped years before the CRA existed.
- Pure SaaS is arguably out of scope. Shipping an installable artefact is not. On-premise deployments, BYOC, desktop agents, mobile apps, plugins and customer-run container images are products on the market.
- You cannot rehearse. Ireland’s NCSC states that ENISA’s Single Reporting Platform needs no pre-registration and that accounts are created on first submission, so your first login happens during a live incident.
- Penalties reach €15m or 2.5% of turnover. Conformity assessment and technical documentation follow in December 2027.
What changes in September, and what does not
The CRA applies in stages, and the bulk of it, the part that generates consultancy invoices, does not bite until 11 December 2027. Conformity assessment, CE marking, the Annex I essential requirements and the technical documentation duties are all 2027 problems. If a vendor says you need a CRA-compliant SBOM by September, they are selling next year’s deadline a year early.
What applies in September is Article 14, and it is narrow. Two things are reportable. An actively exploited vulnerability, which Ireland’s National Cyber Security Centre defines as any flaw where reliable evidence shows a malicious actor is exploiting it in the wild. And a severe incident, an operational security event that negatively affects, or could affect, a product’s security functions, the confidentiality of its data or the integrity of the system.
You file once, through ENISA’s Single Reporting Platform, addressed to the CSIRT where you have your main establishment. For an Irish company that is CSIRT-IE, with ENISA receiving it simultaneously. Non-compliance is priced at up to €15m or 2.5% of worldwide annual turnover, whichever is higher, and under Article 69(3) the duty attaches to products already on the market: active exploitation of something you shipped in 2021 is reportable in September 2026.
The trigger is exploitation, which makes this a detection problem
The common misreading is that September obliges you to report vulnerabilities. It does not. It obliges you to report vulnerabilities being exploited, a far smaller set and a far harder one to observe. You will almost never learn it from your own telemetry. You learn it because a researcher emails an address on your website, because an upstream project publishes an advisory noting exploitation in the wild, or because a customer’s security team rings you. Those arrival paths are outside your control, and most land in an inbox with no owner.
The clock also does not wait for certainty. It starts at reasonable belief, so credible signals arriving on a Friday evening cannot be parked pending forensic confirmation. That single design decision turns a reporting obligation into a triage obligation, which is why September is a rota problem rather than a legal one.
“We are a service, so we are out of scope”
This is the position most software companies have quietly adopted, and for genuinely pure SaaS it is arguable. The CRA regulates products placed on the market, and a cloud application never installed anywhere sits on the services side of that line, addressed by NIS2 instead.
The problem is that few products are pure. Ask what you ship that a customer runs themselves. A desktop agent. A mobile app. A browser extension. A WordPress or Shopify plugin. A container image in a customer’s cluster. Firmware. An on-premise edition. Each is an artefact placed on the market, and pulls you into scope as a manufacturer whatever the rest of the business looks like.
The sharpest version is a decision many teams made deliberately in the past two years. When your largest customer asks for your SaaS inside their own cloud and you build a bring-your-own-cloud deployment to win the deal, you convert a service into a product. That is a scope change bought with a purchase order, and it is never priced into the deal model.
Two further notes. Bespoke software built commercially for a client is generally in scope: the tailor-made allowance is a documented concession on secure-by-default configuration, not an exemption. Open source stewards sit under Article 24 in a lighter regime, with no CE marking and no fines, but the same clocks.
Nobody gets a dry run
Here is the detail that should change how you prepare. Ireland’s NCSC states that the Single Reporting Platform requires no pre-registration and that account creation takes place during first submission.
Read that again with an incident in mind. Every blog post telling you to register on the SRP now is describing something you cannot do. The first time anyone in your organisation opens that platform, they will do it under a running 24 hour clock, with an exploited vulnerability in production, probably out of hours, having never seen the form. You cannot practise the submission. You can control everything before it: whether you notice, who decides, and whether the content already exists in draft.
The question no maintenance agreement answers: who files it?
The duty falls on the manufacturer, the entity that places the product on the market. For agency-built software that is normally the client, not the agency. But a client cannot write a 72 hour technical notification describing root cause, affected versions and mitigations. Often only their development partner can. So the obligation sits with one party and the capability with another, joined by a support contract written before any of this existed.
We have reviewed a fair number of Irish maintenance agreements this year and none carried a regulatory notification clause with a clock in it. Most define a P1 response time and stop, which is a promise about fixing things, not a commitment to feed a legal deadline. The gap is worst on the back catalogue: handed over, no retainer, still on the market.
What to do in the next eleven days
- Decide scope per product, in writing, with a name and a date on it. “Probably a service” is not a defensible position, and writing it down is what surfaces the mobile app and the on-premise edition nobody remembered.
- Define “aware” in one sentence. Which inboxes and feeds can start the clock, and who is deemed to have received them. If security@ forwards to a list with no owner, that is your weakest link and an afternoon’s work to fix.
- Name the decider and a deputy, including out of hours. Someone must be authorised to call it reportable at 2am on a Sunday without a legal opinion. On a team of four, the honest answer today is usually nobody.
- Pre-write the early warning. Twenty four hours is not the constraint. The form asks for things you will not know yet, and working out in the moment how to say “unknown” without under-reporting is what burns the time.
- Route upstream advisories to a person. Exploitation signals arrive via GitHub advisories, vendor mailing lists and CISA’s KEV catalogue. A Slack channel nobody owns is not a control.
- Add the clause at the next renewal. Both directions: what suppliers owe you, and what you owe clients whose products you maintain. Mutual notification inside 24 hours, named contacts.
And do not over-report
The failure mode nobody warns about is the opposite of the one everybody fears. Faced with a 24 hour clock and a €15m ceiling, the reflex is to file everything. Do not. The threshold is active exploitation or a severe incident, not every CVE in your lockfile, and filing first while thinking later trains your team out of the judgement the regulation requires. The control is a decision record: what you knew, when you knew it, what you decided and why, including when the decision is not to report. It costs ten minutes and it is what makes a judgement call defensible.
The CRA is the third regulation in eighteen months to land as a specification rather than a policy document, after the AI Act’s phased obligations and Ireland’s 2028 e-invoicing mandate. The pattern holds: the compliance industry sells the documentation, and the real work is engineering, ownership and rotas. If you are unsure whether what you ship counts as a product, or you know it does and have no answer for who picks up the phone at 2am, get in touch. Regulatory readiness is part of how REPTILEHAUS scopes maintenance, not an add-on.
📷 Photo by engin akyurt on Unsplash
