Most GRC teams filed the Cyber Resilience Act under two words: "product" and "2027."
Both are wrong.
The reporting obligation under Article 14 applies from 11 September 2026. Not December 2027. That is the date everyone remembers, and it is the wrong one.
Three weeks.
And it does not only cover what you ship next year. It covers what you already shipped. A product placed on the EU market in 2018 and still available today is in scope for reporting on the day the obligation switches on.
If your organisation sells anything with digital elements into the EU, this is your incident process, not the product team's paperwork.
What Article 14 Actually Requires
Two triggers, three clocks, one channel.
The triggers:
- an actively exploited vulnerability in your product
- a severe incident having an impact on the security of your product
The clocks:
- 24 hours: early warning, from the moment you become aware
- 72 hours: full notification, including corrective or mitigating measures taken
- 14 days: final report, once a corrective measure is available for an actively exploited vulnerability
- one month: final report for a severe incident, once handled
The channel:
One filing through ENISA's Single Reporting Platform, addressed to the CSIRT where you have your main establishment, made available to ENISA at the same time.
Note what is not in there. This is not "report every CVE." The trigger is active exploitation in the wild, or a severe incident. That distinction is the difference between a workable process and a team that drowns in week two.
Let's break down what you have to get right.
1. The Date Is 2026. The One You Memorised Is 2027.
The CRA (Regulation (EU) 2024/2847) entered into force on 10 December 2024. The bulk of the obligations (security by design, technical documentation, conformity assessment, CE marking) apply from 11 December 2027.
Article 71(2) carves out the reporting duties and moves them fifteen months earlier.
Then Article 69(3) closes the escape route. The transitional arrangements that let existing products stay on the market until December 2027 without full conformity do not extend to reporting.
So the population in scope on 11 September is not your 2027 roadmap. It is your entire installed base.
Tip: If your product inventory only lists what is in active development, you do not have a product inventory. You have a backlog.
2. The Clock Starts on "Aware." Nobody Has Defined That.
This is where the whole thing lives or dies, and it is not a legal question.
Twenty-four hours is not a long time. It is one working day, or a Saturday night. The clock does not start when your legal team agrees you have a problem. It starts when the organisation becomes aware.
So who is "the organisation"?
- a support engineer who sees an odd ticket at 19:00
- a researcher who emails your generic security@ address
- a threat intel feed flagging your product name
- a customer SOC calling your account manager
Every one of those can be the moment of awareness. If none of them knows what to do next, your 24 hours are burning while an email sits unread.
You need three things written down before September:
- what event constitutes awareness, in plain language
- who is authorised to declare it, with a named backup
- where the clock is recorded, so you can prove when it started
That last one matters more than people expect. If a regulator asks why the early warning landed at hour 31, "we became aware later than you think" is only an answer if you can show it.
Anecdote: We have all watched this happen with GDPR. A breach gets declared three weeks late, and not because anyone was hiding anything. Support logged it as a bug. IT called it a configuration issue. Nobody in the chain had ever agreed on what actually counted as a personal data breach, so the clock never started. Legal found out when a customer asked a question.
Same mechanic under the CRA, with a tighter window. Definitions are the boring part. They are also the part that decides whether you were late.
3. The CRA Asks You to Report Before It Asks You to Listen
Here is the ordering problem nobody flags, and it is the one that will catch careful teams.
Article 13(8) requires manufacturers to have policies and procedures, including the coordinated vulnerability disclosure policy set out in Annex I, Part II, point (5), to process and remediate vulnerabilities reported from internal or external sources.
There are actually three legally distinct obligations sitting there, and in most companies one inbox serves all three:
- a CVD policy, written, published and enforced
- a contact address for reporting vulnerabilities in your products and in the third-party components you ship
- a single point of contact through which users can reach a human directly
Now the timing. Those obligations live in Annex I, Part II. Annex I becomes legally binding on 11 December 2027. Article 14 reporting becomes binding on 11 September 2026.
Read that again. For fifteen months, the law requires you to report vulnerabilities being actively exploited in your products, without yet requiring you to operate the channel through which you would find out.
A team that follows the dates literally will spend those fifteen months on a 24-hour clock with no reliable way to learn the clock has started. Because the honest answer to "how do most manufacturers discover active exploitation of their own product?" is: someone tells them.
There is a second reason to do this now. Of everything in the CRA, the CVD policy and the contact address are the two things visible from outside your organisation. A market surveillance authority forming a first impression of your posture will look at your website before it ever asks you for a document.
What good looks like:
- policy at a stable, public URL, not buried in a legal page
- a security.txt file on your domain
- a monitored inbox with a named owner and a backup, not an alias nobody reads
- stated scope, expected response times, what testing is in and out of bounds, how you handle credit and publication
- every report logged, because enforcing the policy is itself the obligation
Tip: You do not need to invent this. ISO/IEC 29147 and ISO/IEC 30111 are the reference standards for disclosure and handling, and the NCSC vulnerability disclosure toolkit is a solid free starting point. Publishing something workable in three weeks beats publishing something perfect in December 2027.
4. You Cannot Report What You Cannot Name
The 72-hour stage asks for product type and classification. That means you need, before an incident and not during one:
- the list of products with digital elements you place on the EU market
- for each, whether it is default, important (Annex III, Class I or II), or critical (Annex IV)
- an SBOM in a commonly used, machine-readable format
Classification follows the product's core function, and where more than one class fits, the stricter one applies.
The SBOM is the part teams underestimate. Article 14 asks you to report a vulnerability in your product. If your product bundles an end-of-life framework you have not inventoried, you will not learn it is being exploited from your own telemetry. You will learn it from a customer, or from the news, which is a very expensive way to start a 24-hour clock.
Tip: Run the exercise backwards. Pick a component you know is in three of your products. Can you produce that list in under an hour, today, without asking engineering? If not, that is your first gap.
5. The Platform Is Not Live. Register Anyway.
Here is the part that makes this a story rather than a compliance memo.
The Single Reporting Platform, established under Article 16 and operated by ENISA, is scheduled to be operational on 11 September 2026. Not before. As of mid-August, the public access URL has not been published. Short videos and a webinar are promised two weeks before launch.
The obligation is fixed. The tool is not. That gap is yours to carry, not the regulator's.
Three things do not depend on the platform existing:
Create the EU Login accounts now. Registration runs through EU Login at ecas.ec.europa.eu. You can create the account today. Doing it mid-incident, with a 24-hour clock running, is a self-inflicted delay.
Set up two seats, not one. There is a Primary Assigned Representative who registers by selecting the role, picking the coordinating CSIRT, accepting the agreement and entering the manufacturer details. The backup, or Secondary AR, is invited by email, and that invitation expires after seven days. Send it and confirm it. An unaccepted invitation is not a backup.
Do not wait for CSIRT validation. Validation of the AR by the coordinating CSIRT happens after registration. It runs in parallel and it does not block you from notifying. Teams that assume they need a green light before they can file will lose hours they do not have.
ENISA's guidance has already moved twice this month. The registration and notification guides were re-dated 3 August, the interface guide appeared on 14 August. All of it is marked subject to change. Build your internal process against the mandatory fields, not against the screenshots.
6. There Are No Harmonised Standards Yet
On 13 August 2026, ETSI put 17 final draft CRA product standards under Public Enquiry. None of them is a harmonised standard. Comments close from mid-September, with approval running into November depending on the vertical.
Notified bodies come in December 2026.
So the honest position is this: the conformity infrastructure of the CRA is still being built, and the reporting obligation is arriving first anyway.
If your plan was "we will start once the standards are published," you have already lost the reporting window. Standards tell you how to prove your product meets the essential requirements. They do not tell you who files the early warning on a Sunday.
7. Your NIS2 and DORA Reporting Does Not Cover This
I see this assumption constantly, and it is dangerous because it is almost right.
You may already have a 24/72-hour muscle from NIS2 or DORA. Good. It is not the same obligation.
| NIS2 / DORA | CRA Article 14 | |
|---|---|---|
| Trigger | incident affecting your services | vulnerability or incident affecting your product, in your customers' hands |
| Who reports | you as an entity | you as a manufacturer |
| Recipient | your national authority | your CSIRT of main establishment, via the SRP, with ENISA |
| Awareness | your operations | often someone else's environment |
One event can trigger both. A severe incident in a product you manufacture and also operate is two filings, two recipients, two record trails.
The reflex to build now is not a new process. It is a decision point at the top of your existing one: which regimes does this event touch? Answer that in minute five, not hour twenty.
Anecdote: I will be straight with you about the state of the market. Almost none of my clients are asking about the CRA right now, because they are still not taking NIS2 seriously enough to get that far. Three weeks out. That is the honest picture.
So the example I can give you is my own. At Mobilexpense, where I sit as CISO, this is exactly what we are building: one incident process with two branches. Same intake, same first questions, and then a fork at the point where you decide whether the event is an entity matter, a product matter, or both. The fork is cheap to design now. It is very expensive to improvise at hour three.
8. What You Can Actually Finish Before 11 September
Three weeks is not enough to build a programme. It is enough to build the part that fires first.
Week one:
- create the EU Login accounts, primary and backup
- send and confirm the Secondary AR invitation before it expires
- identify your coordinating CSIRT
- start the CVD policy through legal review, because that is the long pole
Week two:
- publish the CVD policy, the contact address and security.txt
- freeze the list of in-scope products, including legacy
- assign each one a classification
- write the definition of "aware" and name the two people who can declare it
Week three:
- build the 24-hour early warning as a short internal form matching the mandatory fields
- add the regime-routing question to the top of your incident process
- rehearse it on paper. One scenario, one Saturday evening, one stopwatch
That last step is the one everyone skips and the only one that tells you whether the other eleven worked.
Final Thought
The uncomfortable truth of 11 September is that the regulator is arriving before its own tooling, and that changes nothing about your position.
You cannot file an early warning with an ISO 27001 certificate. You cannot classify a product with a policy. And you cannot start a 24-hour clock with a process that exists only in a document nobody has run.
The manufacturers who handle this well in September will not be the ones with the best CRA gap analysis. They will be the ones who, when the ticket lands at 19:00 on a Saturday, have a named human who knows they are allowed to press the button.
Everything else is preparation for that one moment.
Penalties for breaches of the essential requirements and manufacturer obligations reach €15 million or 2.5% of total worldwide annual turnover, whichever is higher. But the fine is not the risk. The risk is discovering, on the day, that awareness was nobody's job.
If you want the 24/72-hour muscle built properly (triggers, escalation, evidence, and the regulatory routing that decides which regimes an event touches), that is exactly what we run in the ISO/IEC 27035 Lead Incident Manager. Five days, aligned to DORA and NIS2, and now to CRA Article 14. Certified or refunded.