Cyber Resilience Act reporting stops being theory on 11 September 2026. On that date the notification duties in Article 14 of Regulation (EU) 2024/2847 start to apply, and every manufacturer whose product reaches the European market inherits a 24-hour clock. Not a 24-hour target. A legal deadline, measured from the moment you become aware.
The date catches teams out because it arrives fifteen months before the rest of the regulation. Most planning decks have “CRA” pencilled in against December 2027, which is when conformity assessment, CE marking and the Annex I essential requirements bite. The reporting articles run ahead of that schedule deliberately, and the practical consequence is unusual: from September you can be legally obliged to notify a regulator about a product that is not yet legally required to be conformant.
Our companion guide to Cyber Resilience Act compliance for UK software companies covers the whole regime — scope, product classes, SBOM duties, the support period and the twelve-month programme. This article is the operational half. It is about the notification machine you have to be able to run on a Sunday morning in September: the two triggers, the three deadlines, the platform the reports go to, who is allowed to press send, what each submission contains, and how the clock interacts with NIS2, DORA and the ICO.
Treat it as a runbook rather than a legal briefing. Cyber Resilience Act reporting fails on ordinary operational things — an unmonitored disclosure inbox, a security lead on annual leave, nobody with platform credentials, a legal review process that takes three days for a report due in one. Those are all fixable before September, and they are much harder to fix during an incident. The engineering side of this overlaps heavily with the DevOps practices you already run, which is good news: most of the detection capability is already in your pipeline.
Table of contents
- What Changes for Cyber Resilience Act Reporting on 11 September 2026
- Cyber Resilience Act Reporting: The Two Triggers That Start the Clock
- The Three Deadlines in Cyber Resilience Act Reporting
- Where Cyber Resilience Act Reporting Actually Goes
- What Each Cyber Resilience Act Reporting Submission Must Contain
- Who Files Your Cyber Resilience Act Reporting: Authority and Rotas
- Detecting the Trigger That Starts Cyber Resilience Act Reporting
- Cyber Resilience Act Reporting to Users, Not Just Regulators
- Cyber Resilience Act Reporting Next to NIS2, DORA and UK GDPR
- The Evidence Pack Behind Cyber Resilience Act Reporting
- Penalties for Getting Cyber Resilience Act Reporting Wrong
- A Four-Week Plan to Be Ready for Cyber Resilience Act Reporting
- Cyber Resilience Act Reporting Mistakes to Avoid
- Cyber Resilience Act Reporting Questions Answered
- References
What Changes for Cyber Resilience Act Reporting on 11 September 2026
The Cyber Resilience Act reporting date that arrives first
The Cyber Resilience Act entered into force in December 2024 with a staggered application timetable. Chapter IV, covering the notification of conformity assessment bodies, applies from 11 June 2026. Cyber Resilience Act reporting applies from 11 September 2026. Everything else — the essential requirements, conformity assessment, the CE mark, the declaration of conformity, the technical file — applies from 11 December 2027. Three dates, three different scopes, and only one of them lands this year.
Cyber Resilience Act reporting applies before CE marking does
This is the part that surprises people, and it is worth stating plainly: the obligation to notify an actively exploited vulnerability begins fifteen months before the obligation to demonstrate the product was built securely. There is no grace period tied to conformity. A manufacturer whose Annex I work is barely started in September 2026 still has to file within 24 hours if exploitation is observed. Cyber Resilience Act reporting is therefore the first CRA duty that can be breached, and the first that can be evidenced against you.
Which parts are still not in force in September
Nothing about classification, notified bodies or technical documentation is enforceable against a manufacturer on 11 September 2026. You do not need a completed technical file, a declaration of conformity, or a decision about whether your product is default, Class I, Class II or critical under Annex IV. Those questions belong to the December 2027 milestone. Confusing the two is the most common reason a team concludes its Cyber Resilience Act reporting can wait.
Why the sequencing is deliberate
Regulators wanted the intelligence flow early. A single European view of which products are being actively exploited is useful long before the market is fully conformant, and it gives ENISA and the national CSIRTs time to make the platform work at volume. For manufacturers, the practical reading is that Cyber Resilience Act reporting is a capability deadline rather than a paperwork one. You are being asked to be reachable, decisive and fast — not yet to be perfect.
What a UK software company should take from the date
The Cyber Resilience Act reporting exposure test is market access, not establishment. Leaving the European Union did not remove a UK vendor from Article 14; placing a product on the EU market puts you inside it. If you have German, Irish, Dutch or French customers running your installable software, your firmware, your SDK or your on-premise server product, the September date is yours. Our note on the UK Cyber Security and Resilience Bill covers the domestic regime moving in parallel.
| Date | What applies | What it means for a manufacturer |
|---|---|---|
| 11 June 2026 | Notification of conformity assessment bodies | Notified bodies can be designated; no direct duty on you |
| 11 September 2026 | Reporting obligations under Article 14 | 24-hour, 72-hour and final report duties are live and enforceable |
| 11 December 2027 | Full regime: Annex I, conformity, CE mark, technical file | Products placed on the EU market must be conformant and marked |
Cyber Resilience Act Reporting: The Two Triggers That Start the Clock
Cyber Resilience Act reporting trigger one: an actively exploited vulnerability
The first trigger is a vulnerability in your product that is being actively exploited. The regulation sets a specific evidential bar rather than a suspicion threshold: there must be reliable evidence that a malicious actor executed code on a system without the owner’s permission. A vulnerability that is merely severe, merely public, or merely proof-of-concept does not start the clock. Evidence of real-world exploitation does. This distinction is the single most useful Cyber Resilience Act reporting rule to teach an on-call engineer before September.
Cyber Resilience Act reporting trigger two: a severe incident
The second trigger is a severe incident having an impact on the security of the product with digital elements. This is broader and vaguer, and it is the Cyber Resilience Act reporting path most teams forget to build. It covers events that compromise the security of the product without necessarily involving a vulnerability in your code — a compromised build pipeline, a signing key exposure, a malicious update distributed through your own channel, an attacker with access to the infrastructure your product depends on to function.
What “becoming aware” means in practice
Both clocks run from awareness, not from confirmation, triage or management sign-off. Awareness is an organisational state, not a personal one: a report sitting unread in a security inbox is very hard to argue was not awareness. The practical implication for Cyber Resilience Act reporting is that you must timestamp intake. If you cannot show when a report arrived and when someone acted on it, you cannot demonstrate the 24-hour deadline was met.
The triggers that do not qualify
A patched vulnerability with no evidence of exploitation is not notifiable. A vulnerability in a dependency you do not ship is not yours to report. A denial-of-service against your corporate website, absent any impact on product security, is not a severe incident under this article. Neither is a personal data breach on its own — that is an ICO matter under UK GDPR. Building a clean negative list matters as much as the positive one, because over-reporting burns the same scarce hours as under-reporting.
The judgement call you must be able to defend
In the real case the evidence is ambiguous: a customer reports odd behaviour, telemetry is suggestive, exploitation is plausible but unproven. The defensible posture is to document the reasoning contemporaneously and lean toward notifying. The regulation provides for voluntary notification precisely so that a manufacturer acting in good faith on incomplete information is not punished for it. A written five-line rationale, timestamped, is worth more after the fact than a perfect analysis produced a week later.
The Three Deadlines in Cyber Resilience Act Reporting
The 24-hour Cyber Resilience Act reporting early warning
Within 24 hours of becoming aware, Cyber Resilience Act reporting requires an early warning. Twenty-four hours is not an investigation window — it is an alerting window, and the report is expected to be thin. It says what you know, that exploitation is occurring or that a severe incident has happened, and that work is under way. For an actively exploited vulnerability the early warning should also indicate the Member States where you believe the product has been made available. Nothing else is expected at this stage.
The 72-hour Cyber Resilience Act reporting notification
Within 72 hours you submit a fuller notification: the vulnerability or incident, its severity and impact, and where available any corrective or mitigating measures. This is the report that requires actual triage. It is also the stage where Cyber Resilience Act reporting most often collides with commercial nerves, because a severity assessment written for a regulator will be read later by customers, insurers and possibly a court. Write it accurately and neutrally the first time.
The final report: 14 days or one month
For an actively exploited vulnerability, Cyber Resilience Act reporting closes with a final report due no later than 14 days after a corrective or mitigating measure becomes available. It covers the vulnerability, its severity, the root cause and the fix applied. For a severe incident, the equivalent final report is due within one month of the 72-hour notification. Note the asymmetry: the vulnerability clock is anchored to your remediation, so a slow fix extends the deadline but does not remove it.
Why the first clock is the one that fails
Twenty-four hours sounds generous until you map it against a real calendar. A disclosure arriving at 16:00 on the Friday before a bank holiday leaves a deadline of 16:00 Saturday. If the security lead is unreachable, if the only person with platform credentials is on a plane, or if internal policy requires legal review before any regulator contact, the deadline passes while everyone behaves reasonably. Every serious Cyber Resilience Act reporting failure we expect to see will look like this rather than like negligence.
The user notification runs alongside
Separately from the regulator, you must inform impacted users about the vulnerability or incident and, where appropriate, about corrective measures. That duty has no fixed hour count — it runs without undue delay — but it does not wait for the final report, and it cannot be quietly deferred until a release is ready. In practice the advisory and the 72-hour notification should be drafted together by the same person.
| Stage | Deadline | What the submission must establish | Typical failure |
|---|---|---|---|
| Early warning | 24 hours from awareness | That something is happening, and roughly where | Nobody authorised is awake or has credentials |
| Notification | 72 hours from awareness | Severity, impact and any available mitigations | Legal review stalls a technically ready draft |
| Final report, exploited vulnerability | 14 days after a corrective measure is available | Root cause and the fix actually shipped | Clock forgotten once the patch is out |
| Final report, severe incident | 1 month after the 72-hour notification | Nature, impact and remediation of the incident | No process exists for the incident path at all |
| User notification | Without undue delay | What users must do to protect themselves | Held back until a release is ready to ship |
Expressed as elapsed hours from the moment of awareness, the gap between the first stage and the last is what makes the early warning hard to staff.
Where Cyber Resilience Act Reporting Actually Goes
The single reporting platform and ENISA
Cyber Resilience Act reporting goes through a single platform established by ENISA, with national electronic notification end-points. You notify the CSIRT designated as coordinator in the Member State of your main establishment, and the information is made available simultaneously to ENISA. You report once rather than to every affected country, which is a genuine simplification compared with the fragmented picture under other regimes. Register with the platform and test the credentials well before September.
Choosing your coordinating CSIRT
Your Cyber Resilience Act reporting CSIRT is determined by where your main establishment in the Union sits. For a manufacturer with an EU subsidiary the answer is usually obvious. For a UK company with no EU establishment it is less so, and the pragmatic route is to identify the Member State where you have the largest presence — an authorised representative, a subsidiary, or the market where most of your product is placed. Decide this once, in writing, and record the reasoning.
What “main establishment” means for a UK company
Main establishment turns on where decisions about cybersecurity for your products are actually taken, not where a holding company is registered. A UK vendor selling across the EU through an Irish authorised representative will generally look to Ireland’s CSIRT. The important operational point is that this determines which portal you register with, which language expectations apply, and whose guidance you follow — so it is a prerequisite for the September deadline, not a detail to settle during an incident.
When a report can be delayed or withheld
CSIRTs may defer the onward dissemination of a notification on justified cybersecurity grounds — for example where publicising an unpatched, actively exploited vulnerability would increase risk to users. That discretion belongs to the CSIRT, not to you. Your obligation to notify within 24 hours is unaffected by how sensitive the information is, and there is no self-service exemption for a vulnerability you would rather keep quiet while a fix is built.
Registering before you need it
The single most valuable hour you can spend on Cyber Resilience Act reporting before September is registration. Create the account, name at least two authorised submitters, confirm they can log in, and store the credentials somewhere your on-call engineer can reach at 02:00. Registering during an incident is a guaranteed way to lose most of a 24-hour window to password resets and identity verification.
What Each Cyber Resilience Act Reporting Submission Must Contain
Cyber Resilience Act reporting fields for the early warning
Keep this stage of Cyber Resilience Act reporting short and factual: the product and versions affected, the nature of what you have observed, that exploitation is occurring or that a severe incident has occurred, an indication of the Member States where the product has been made available, and a named contact who can be reached. Explicitly say what you do not yet know. An early warning padded with speculation is worse than a thin one, because it becomes the record of what you claimed.
Cyber Resilience Act reporting fields for the 72-hour notification
The fuller notification adds severity and impact, a technical description, the affected versions with precision, any available corrective or mitigating measures, and — where relevant — indicators of compromise the CSIRT can circulate. If you have issued a CVE identifier, include it. If you have a CVSS score, state the vector string rather than only the number, because a bare score invites argument and a vector invites agreement.
Cyber Resilience Act reporting fields for the final report
The final report closes the loop: the vulnerability or incident, its severity and impact, the root cause, the corrective measure shipped, and the versions that carry the fix. For a severe incident it should also describe the mitigations applied and any residual risk. This is the document most likely to be read years later by a market surveillance authority or an acquirer, which is a good reason to write it as though it will be.
Writing for an audience that is not your customer
A regulator submission is not marketing collateral and not an apology. It should be dry, specific and free of hedging language that would look evasive in hindsight. Avoid characterising impact as “limited” or “minimal” without stating the basis for that view. The habit worth building before September is separating the factual submission from the customer-facing advisory, and drafting the factual one first.
Who Files Your Cyber Resilience Act Reporting: Authority and Rotas
The decision to notify cannot wait for a manager
The most important Cyber Resilience Act reporting change before September is delegating notification authority downward. Someone on call must be able to file an early warning without waking a director. That means a written standing authority, a decision rule that does not require judgement about commercial consequences, and explicit cover for the case where the on-call engineer files and the assessment later turns out to be conservative. Nobody should be reprimanded for a good-faith notification.
The three Cyber Resilience Act reporting roles to name before September
Name a reporting owner who is accountable for the process, a rota of authorised submitters who can actually file, and a technical assessor who decides whether the evidential bar for exploitation is met. These can be three people or one person with two deputies, but they must be named individuals rather than a team mailbox. A duty that belongs to everyone belongs to nobody at 03:00 on a Sunday.
Weekend, holiday and single-point-of-failure coverage
Map your rota against the actual 2026 calendar and look for the gaps: the August shutdown, the Christmas period, the week your security lead is at a conference. Cyber Resilience Act reporting has no out-of-hours allowance, and the 24-hour clock does not pause for a bank holiday. If you are a ten-person software company, this is genuinely hard — but the answer is a named deputy with credentials, not an aspiration to hire.
Credentials, and the person who has them
Cyber Resilience Act reporting credentials must exist in at least two hands and in a vault the on-call rota can reach without going through the person who is unreachable. This sounds trivial and it is the most common failure mode in every regulated notification regime. Test it quarterly by asking a deputy to log in cold. If your managed IT services provider holds part of the incident process, agree in writing which side presses send.
The lawyer question
Legal review is valuable and it is also the classic reason a 24-hour deadline slips. Resolve it structurally: pre-agree a template that counsel has already approved, so the early warning needs no review at all, and reserve legal input for the 72-hour notification where there is time for it. A review process designed for a press release will not survive contact with a one-day statutory clock.
| Role | Decides | Must be reachable | Minimum cover |
|---|---|---|---|
| Reporting owner | Process, templates, registration, evidence retention | Business hours | One named deputy |
| Technical assessor | Whether the exploitation bar is met | 24/7 via on-call | Two engineers on rota |
| Authorised submitter | Files the early warning without escalation | 24/7 via on-call | Two, with tested credentials |
| Communications lead | The user-facing advisory | Within 24 hours | One named deputy |
| Legal counsel | 72-hour wording only, never the early warning | Within 48 hours | Pre-approved template |
Detecting the Trigger That Starts Cyber Resilience Act Reporting
Your disclosure inbox is now a Cyber Resilience Act reporting intake
A coordinated vulnerability disclosure address stops being a courtesy in September and becomes the front door to a statutory deadline. It needs monitored delivery, an auto-acknowledgement that timestamps receipt, and routing to the on-call rota rather than to a single person. If security@ currently forwards to one engineer’s mailbox, that is the highest-value thing on your pre-September list.
Telemetry that tells you exploitation is happening
The Cyber Resilience Act reporting bar is real-world exploitation, which means your detection needs to distinguish scanning from success. Crash telemetry, anomalous authentication patterns, unexpected outbound connections from customer deployments and integrity checks on your own update channel are the signals that turn “a vulnerability exists” into “it is being exploited”. On-premise products are the hard case, because the telemetry lives on somebody else’s network and you may only learn through a customer.
Threat intelligence and third-party notice
You can become aware through channels you do not control: a national CERT, a researcher, a customer’s incident responders, or a public catalogue of exploited vulnerabilities. Subscribe to the feeds that would name your product and make sure alerts route into the same timestamped intake as your disclosure inbox. Awareness gained through a public listing counts, and arguing that nobody internally read it is not a defence.
Dependencies: someone else’s vulnerability, your report
If an actively exploited vulnerability sits in a component you ship inside your product, the reporting duty attaches to you as the manufacturer of the product placed on the market. Upstream disclosing it does not discharge your obligation. This is where the SBOM work described in the companion compliance guide pays for itself early — you cannot assess whether an upstream advisory affects you if you cannot answer what you ship.
The intake log that proves you were on time
Everything above converges on one artefact: a log that records, for each report, when it arrived, through which channel, who saw it, what was assessed, when the decision was made and when the submission was filed. Cyber Resilience Act reporting is judged on that record. A tidy log turns a stressful audit into a short one, and it costs almost nothing if you start it before you need it.
Cyber Resilience Act Reporting to Users, Not Just Regulators
The Cyber Resilience Act reporting duty to users
Alongside the regulator submission, you must inform impacted users about the vulnerability or incident and, where appropriate, about corrective measures and any action they should take. “Users” here means the people running your product, which for a B2B vendor is your customers’ technical teams — not a press release, and not a line item in a release note nobody reads.
Advisories that say enough without arming attackers
The tension is genuine: users need enough detail to act, and a full technical write-up of an unpatched, actively exploited flaw increases risk. The workable pattern is to publish impact, affected versions, and mitigation or workaround immediately, and hold exploitation detail until a fix is broadly deployed. Say plainly that detail is being withheld and why, rather than leaving a vague advisory that readers cannot act on.
Coordinating with the CSIRT’s own disclosure
The CSIRT may be circulating information to other Member States and may itself decide to delay dissemination. Tell them what you plan to publish and when. Nothing damages a regulator relationship faster than a public advisory that contradicts the notification filed hours earlier, and coordination costs one email.
Contract clauses that now conflict
Many enterprise contracts contain notification terms written before this regime existed — 48-hour customer notice, embargo clauses, or approval rights over public statements. Some of these are now impossible to honour alongside a statutory 24-hour duty to a regulator. Review them now rather than during an incident; our guide to supplier contract clauses covers the drafting pattern that keeps the two consistent.
Cyber Resilience Act Reporting Next to NIS2, DORA and UK GDPR
One incident, several clocks besides Cyber Resilience Act reporting
A single event can trigger Cyber Resilience Act reporting and several other regimes at once. A compromised update channel at a vendor serving financial customers can be a CRA severe incident, a NIS2 incident for the operators consuming it, a DORA major ICT-related incident for regulated firms, and a personal data breach under UK GDPR — with four different recipients and four different deadlines. The mistake is building four processes. The right design is one intake and several outputs.
NIS2 governs operators, the CRA governs products
NIS2 attaches to entities operating in specified sectors and asks about their organisational security. The CRA attaches to the product you place on the market. A UK software vendor is usually outside NIS2’s direct scope but inside the CRA’s, while its customers are often the reverse. That asymmetry explains why your enterprise customers ask security questionnaire questions that have nothing to do with your own Cyber Resilience Act reporting duties.
DORA and financial-sector software
DORA governs financial entities and their critical ICT third-party providers, with its own major-incident notification chain running through the customer’s competent authority. If you sell into EU financial services you may find your contractual incident obligations to a bank are tighter than the statutory ones, and that the bank’s own clock starts when you tell them. Sequence your notifications so the regulator submission and the customer notice do not contradict each other.
UK GDPR, the ICO and the 72-hour parallel
If the incident involves personal data you also owe the ICO a notification within 72 hours where the risk threshold is met. The deadlines rhyme but the tests do not: the CRA asks about product security, UK GDPR asks about risk to individuals. Assess both, separately, from the same facts, and record both decisions — including the decision not to notify, which is the one people forget to write down.
Running one intake, many outputs
Build a single triage step that asks four questions: is this an actively exploited vulnerability or severe incident in our product, does it involve personal data, does it affect a customer with regulatory obligations of their own, and does any contract impose a shorter notice period? Route from there. One intake keeps the timestamps consistent, which matters enormously when four regulators later compare notes on the same event.
| Regime | Attaches to | First clock | Final report | You notify |
|---|---|---|---|---|
| Cyber Resilience Act | The product you place on the market | 24 hours | 14 days or 1 month | Coordinating CSIRT, via the ENISA platform |
| NIS2 | Essential and important entities | 24 hours | 1 month | National CSIRT or competent authority |
| DORA | Financial entities and critical ICT providers | 24 hours from awareness | 1 month | The financial entity’s competent authority |
| UK GDPR | Personal data you control or process | 72 hours | No separate final report | The ICO, and data subjects where high risk |
Setting the first deadline of each regime side by side shows how little the clocks differ — and why one intake beats four processes.
The Evidence Pack Behind Cyber Resilience Act Reporting
What Cyber Resilience Act reporting evidence you must show afterwards
Assume that at some point a market surveillance authority asks you to demonstrate that a notification was timely. The pack that answers this is small: the intake log, the assessment note, copies of the three submissions with their platform receipts, the user advisory with its publication timestamp, and the remediation record showing when a corrective measure became available. Five artefacts, each of which is trivial to produce at the time and painful to reconstruct later.
Timestamping awareness is the whole game
Every deadline in Cyber Resilience Act reporting is measured from awareness, so the timestamp on intake is the load-bearing fact in any dispute. Automate it. An auto-acknowledgement from the disclosure address, a ticket created on receipt, and an immutable log are worth more than any amount of narrative. Where awareness arrives informally — a customer call, a conference conversation — write the note the same day.
Retention and where this lands in the technical file
From December 2027 the vulnerability handling evidence forms part of the documentation you must keep for the product. Starting the pack in September 2026 means that by the time the full regime applies you have fifteen months of real records rather than a retrospective reconstruction. Keep it for the support period of the product, which for most manufacturers means five years or the expected product lifetime, whichever is longer.
Reviewing near misses
The regulation allows voluntary notification of vulnerabilities, incidents and near misses. Whether or not you use that channel, review your near misses internally: the report that arrived at the weekend and was picked up on Monday, the alert nobody routed, the credential nobody could find. Those are the rehearsals you get for free, and each one tells you exactly which part of the process would have failed.
Penalties for Getting Cyber Resilience Act Reporting Wrong
The Cyber Resilience Act reporting fine bands
The regulation sets three bands of administrative fine. Breaching the Annex I essential requirements or the manufacturer obligations in Articles 13 and 14 — which includes the reporting duties — carries up to €15 million or 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher. Breaching other obligations carries up to €10 million or 2%. Supplying incorrect, incomplete or misleading information to notified bodies or market surveillance authorities carries up to €5 million or 1%.
Note which band reporting sits in
Cyber Resilience Act reporting failures fall in the top band, alongside shipping a product that does not meet the essential requirements. That is a deliberate signal about how the obligation is regarded, and it is worth putting in front of a board that is inclined to treat notification as administrative. The third band matters too: a rushed, inaccurate submission is not a safe way to meet a deadline, because misleading information carries its own penalty.
Market withdrawal is the sharper risk
For most software companies the fine is not the real exposure. Market surveillance authorities can require an operator to bring a product into conformity, restrict its availability, withdraw it from the market or recall it. A withdrawal order against the product carrying your European revenue is a worse outcome than a fine and it arrives faster. Cyber Resilience Act reporting is best argued internally as revenue protection rather than as penalty avoidance.
The commercial consequence that arrives first
Long before any regulator acts, your enterprise customers will ask how you handled it. A vendor that notified on time, published a clear advisory and shipped a fix looks competent. A vendor that missed a statutory deadline hands every competitor a talking point and every procurement team a reason to add conditions at renewal. That is the penalty most UK software companies will actually feel.
A Four-Week Plan to Be Ready for Cyber Resilience Act Reporting
Week one: Cyber Resilience Act reporting scope and ownership
Confirm in writing that you are a manufacturer for at least one product placed on the EU market, decide your main establishment and coordinating CSIRT, and name the reporting owner, the technical assessors and the authorised submitters. Write the standing authority that lets an on-call engineer file without escalation. This week is entirely paperwork and it removes most of the delay risk.
Week two: intake and detection
Fix the disclosure address so it timestamps, acknowledges and routes to a rota. Subscribe to the intelligence feeds that would name your product or your major dependencies. Stand up the intake log. Check that you can answer, within an hour, which versions of your product contain a given component — and if you cannot, that is the SBOM work starting early rather than a reason to stop.
Week three: templates and registration
Register on the reporting platform, create at least two submitter accounts and verify both can log in. Draft the three submission templates and the user advisory template, and get legal to pre-approve the early warning skeleton so it never needs review. Write the negative list too: the categories of event that explicitly do not trigger Cyber Resilience Act reporting, so on-call staff are not guessing.
Week four: rehearse against the calendar
Run a tabletop at an awkward hour with the primary responder deliberately absent. Inject an ambiguous case rather than an obvious one, and time the whole thing to the minute. The two questions worth answering are whether the deputy could log in and whether anybody hesitated because they were unsure of their authority. Fix whatever the rehearsal breaks, then repeat it quarterly.
After September: keeping it alive
A process rehearsed once decays. Put a quarterly credential test, an annual tabletop and a standing agenda item on near misses into the calendar now. When the full regime arrives in December 2027, this machinery becomes part of the vulnerability handling evidence you have to produce anyway, so the effort compounds rather than expires.
Cyber Resilience Act Reporting Mistakes to Avoid
Assuming Cyber Resilience Act reporting waits until December 2027
The single most expensive Cyber Resilience Act reporting error is planning to one milestone. Reporting is live from September 2026, it sits in the top penalty band, and it requires none of the conformity work to be finished first. Any programme plan that has no September deliverable has misread the timetable.
Treating 24 hours as an investigation window
The early warning in Cyber Resilience Act reporting is an alert, not an analysis. Teams that try to complete triage before filing routinely miss the deadline and then produce a report that is both late and no better. File thin and early, then improve at 72 hours. This is the behavioural change most worth drilling.
Building Cyber Resilience Act reporting for only the vulnerability path
Cyber Resilience Act reporting has two triggers, and severe incidents are consistently the forgotten half. Build the incident path explicitly: what counts, who assesses it, and which final-report clock applies. A compromised signing key on a Friday is exactly the scenario nobody has a runbook for.
Assuming your EU reseller or representative reports
The Cyber Resilience Act reporting duty is the manufacturer’s. An authorised representative can hold documentation and cooperate with authorities, and an importer has its own checks, but neither discharges your Article 14 obligation. Read the mandate you have actually signed rather than assuming the arrangement covers this.
Forgetting free products and open-source distributions
Manufacturer status turns on placing a product on the market under your name, whether for payment, for monetisation or free of charge. A community edition, a free tier or a branded SDK can pull you into scope. Enumerate everything that carries your trademark, not just the things that carry an invoice.
Letting the customer contract set a shorter clock you cannot meet
Notification terms drafted before this regime can commit you to timings that conflict with the statutory sequence. Find them now. A clause promising customer notice before any regulator contact is a clause that instructs you to breach Article 14.
Cyber Resilience Act Reporting Questions Answered
Does this apply to a UK company after Brexit?
Yes — Cyber Resilience Act reporting applies if you place a product with digital elements on the EU market. The test is market access, not establishment, so a UK-registered software company selling to customers in the Union is a manufacturer for these purposes and owes the same Article 14 duties as a company based in Berlin.
What exactly do I have to do on 11 September 2026?
Nothing, if no trigger occurs. The duty is conditional: from that date, if you become aware of an actively exploited vulnerability in your product or a severe incident affecting its security, the 24-hour clock applies. What you should have done by that date is register on the platform, name your people and be able to file.
Is SaaS in scope for Cyber Resilience Act reporting?
Pure cloud services are generally handled under NIS2 rather than the CRA, but the boundary is not clean. Remote data processing solutions that a product needs to function are treated as part of that product. If your SaaS has an installable agent, a downloadable client or an on-premise component, assume the product-side duties reach you.
Does a CVE or a public advisory count as becoming aware?
It can. Awareness is organisational and does not depend on who inside the company noticed. If a public catalogue lists your product as actively exploited, the sensible working assumption is that the clock has started, which is why feed subscriptions should route into the same timestamped intake as your disclosure inbox.
What if we are not sure exploitation is really happening?
Document the assessment and lean toward notifying. The evidential bar is reliable evidence of malicious code execution without permission, but a defensible contemporaneous note explaining a borderline judgement is far stronger than a perfect analysis assembled afterwards. Voluntary notification exists for exactly this situation.
Do we report to every affected Member State?
No. You report once, to the CSIRT designated as coordinator in the Member State of your main establishment, through the single reporting platform, and the information is made available to ENISA simultaneously. That is one of the few places where this regime is simpler than its neighbours.
Does ISO 27001 or Cyber Essentials cover this?
Neither certification satisfies the Cyber Resilience Act reporting duty. They evidence organisational security management, which helps you detect and respond, but Cyber Resilience Act reporting is a specific statutory notification obligation with named deadlines and a named recipient. You can hold both certificates and still miss a 24-hour deadline.
What is the minimum useful thing to do this month?
Register on the platform, name two authorised submitters who can reach the credentials out of hours, and fix your disclosure inbox so arrival is timestamped and routed to a rota. Those three actions remove the majority of the realistic failure modes and take less than a day between them.
References
Regulation (EU) 2024/2847 — the Cyber Resilience Act
European Commission — Cyber Resilience Act
Directive (EU) 2022/2555 — NIS2
Regulation (EU) 2022/2554 — DORA
ICO — Personal Data Breach Reporting
NCSC — Vulnerability Disclosure Toolkit
CISA — Known Exploited Vulnerabilities Catalog
