Team Shieldworkz
The clock is already running on products you shipped years ago
Most CRA conversations still point at 11 December 2027, the date the full product requirements apply: secure by design, CE marking, conformity assessment. For industrial manufacturers that date feels far enough away to plan around. The reporting duty did not wait for it.
Since 11 September, Article 14 of the Cyber Resilience Act has required manufacturers to report actively exploited vulnerabilities and severe incidents in their products. It applies to everything in scope, including products placed on the EU market long before the Act, as the Commission's July guidance and ENISA's FAQ both confirm. A PLC family, a gateway line or a SCADA package that has been in the field for fifteen years is covered the same way as a product launched last month.
This guide explains how the Cyber Resilience Act reporting obligations work in practice, what has changed since go-live, and how an industrial manufacturer can run the 24-hour workflow without improvising during an incident.
The short version
Two triggers: an actively exploited vulnerability in your product, or a severe incident affecting its security.
Three reports: early warning within 24 hours, notification within 72 hours, final report later (14 days after a fix or mitigation for vulnerabilities; one month after the 72-hour notification for incidents).
One channel: a single submission through ENISA's Single Reporting Platform, which reaches both ENISA and the national CSIRT acting as coordinator.
Legacy included: products already on the market, and per the Commission, products past the end of their support period.
Penalty ceiling: administrative fines up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher.
No shortcuts at launch: the platform is a web form in English with no API, and sign-in needs an EU Login account with multi-factor authentication.
What Article 14 actually requires
Article 14 is a notification duty, not a vulnerability-handling programme. It asks a manufacturer to tell the authorities about two kinds of event, and only two.
1. An actively exploited vulnerability. The CRA definition, as ENISA repeats it, is a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission. Three tests sit inside that sentence: reliable evidence, a malicious actor, and no permission. A proof of concept, a scanner hit or a researcher's write-up does not meet it on its own.
2. A severe incident affecting product security. Under Article 14(5), an incident is severe if it affects, or could affect, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or if it has led or could lead to malicious code being introduced or executed in the product or in a user's network. The words "could lead" matter: capability is enough, and you do not need to wait for proven damage. Legal commentary on the recitals gives a clear example, which is an attacker compromising the manufacturer's release channel for security updates (BD Emerson summary).
When does the clock start?
The 24-hour and 72-hour deadlines run from the moment you become aware, so this is the question that matters most. Per the Commission's July guidance as summarised by Jones Day, awareness arises once an initial assessment gives you a reasonable degree of certainty that exploitation or a severe incident is real. Suspicion alone does not start the clock. But you cannot stretch the assessment to postpone it, either (itemis walkthrough). Two further points from ENISA's FAQ are worth pinning to your procedure:
You do not have to report retroactively where you already knew about the exploitation before 11 September. If you learned of it after that date, you do, even if the underlying vulnerability is old or already public.
The duty covers products on the market before the CRA's main application date, and the Commission has clarified that it continues after a product's support period ends (Pearl Cohen). Retired product lines stay on your hook as long as they are out there being exploited.
Does it trigger? Industrial examples
These are illustrative readings, not legal advice. The call is always case by case, and your counsel owns it.
Event | Likely Article 14 report? | Why |
A researcher emails a working exploit for an auth bypass in your PLC web server, with no sign of attacks | Not yet | No reliable evidence of exploitation. Handle through normal vulnerability handling, and watch for evidence |
A CVE in a third-party library inside your gateway firmware is added to a known-exploited list | Probably yes | Exploitation evidence exists and the flaw is in your product, so triage the same day |
A customer's SOC shows attackers logging in to your HMI using a default credential | Probably yes | Active exploitation of a weakness in your product, reported by a credible source |
Your firmware build server is compromised and a signing key may be exposed | Likely severe incident | Malicious code could reach users through your own update channel |
Ransomware hits your office IT, with no impact on build, signing, release or deployed products | Not under Article 14 | May still trigger NIS2 or GDPR duties, which run on separate clocks |
Your own pen test finds a critical flaw in a lab unit | No | Good-faith testing is not exploitation by a malicious actor |
The 24-hour, 72-hour and final report timeline
Every stage is a notification submitted through the same platform. The first two are measured from awareness, and the two tracks only diverge at the end.
Stage | Deadline | Actively exploited vulnerability | Severe incident |
Early warning | 24 hours from awareness | That exploitation is happening and, where known, the Member States where the product is available | At least whether unlawful or malicious acts are suspected |
Notification | 72 hours from awareness | General product information, nature of the exploit and flaw, measures taken and measures users can take | Nature of the incident, an initial assessment, and measures taken and available to users |
Final report | 14 days after a corrective or mitigating measure is available | Description with severity and impact, actor details where known, and the fix or mitigation | One month after the 72-hour notification: detailed description, likely threat or root cause, mitigation applied and ongoing |
Intermediate report | On request | The coordinating CSIRT can ask for status updates at any point | Same |
Field requirements come from ENISA's published data-field table: some fields are optional at 24 hours and become required later, while identifiers such as a CVE or EUVD ID can be added when they exist. The early warning is meant to be thin. What it cannot be is late.
Two details trip people up.
The 72-hour clock starts at awareness, not at your early warning. ENISA's FAQ says the platform's own 72-hour counter currently shows a due time 48 hours after the early warning is submitted, so it may flag a report as overdue before 72 hours have passed. ENISA says it will move to the awareness timestamp in a later release. Run your own clock from the timestamp you recorded, and treat the platform counter as a reminder only.
For vulnerabilities, the final report is tied to a mitigation, not only a patch. The 14 days start when a corrective or mitigating measure becomes available. In OT, where a firmware fix can take months to validate, that distinction is useful. It also cuts the other way: the day you publish a workaround, a clock starts.
The duty to your users runs in parallel. Article 14(8) requires you to inform affected users, and all users where needed, about the issue and what they can do, in a machine-readable format where appropriate. If you do not, the CSIRT can do it for you (itemis).
A worked example (illustrative)
A customer's SOC tells your PSIRT at 22:10 on a Monday that attackers are using a flaw in your gateway's remote-access service. Triage runs overnight, and at 02:30 on Tuesday the team documents that evidence is reliable and the product is yours. That is the awareness timestamp.
Wednesday 02:30: early warning due. It can be short, but it needs the affected product and the Member States you know it ships to.
Friday 02:30: the 72-hour notification is due, covering the nature of the exploit, what you know and the mitigations. Your first user advisory should go out around now.
Day of mitigation release (say, the following Thursday): a hardening guide is published. The 14-day clock for the final report starts here.
Within 14 days of that: final report, with severity, impact, actor information if you have it, and the update or workaround.
Notice that nothing pauses for the weekend, and that you filed the first report while the engineering team was still reproducing the flaw. That is how the regime is meant to work.
How the Single Reporting Platform works, and what to sort out before you need it
You file once. The notification goes to the CSIRT you select as coordinator and to ENISA at the same moment, and the CSIRT passes it on to the other Member States where the product is sold. Everything below comes from ENISA's FAQ, last updated 15 October.
Access is personal. Each assigned representative needs their own EU Login account with multi-factor authentication. There is one Primary representative per manufacturer and up to 20 Secondary ones. Any of them can continue a report another started, but drafts are stored in the individual's own account and are not shared.
Verification runs in parallel. The CSIRT validates the link between representative and manufacturer after first access, and it does not block filing. An unverified account can submit up to 20 notifications before verification becomes mandatory.
You choose the CSIRT, and a wrong choice can invalidate the report. The default is the Member State of your main EU establishment, meaning where cybersecurity decisions for your products are mainly taken. Without an EU establishment, the order is your authorised representative, then the importer, then the distributor, then the country with the most users.
One notification per event, even with several EU subsidiaries or a non-EU parent. Coordinating internally is your job.
It is a web form. There is no API at this stage, and the interface is English only. Automated filing from your ticketing system is not possible yet, so design for a human operator.
If the platform is down, wait and file when it returns. You may contact your CSIRT directly in the meantime if you need to communicate urgently, but the notification still has to go through the platform afterwards.
Delaying onward sharing is narrow. The "particularly exceptional circumstances" option applies to the 72-hour notification of an exploited vulnerability only, not to severe incidents, and it is a request that the coordinating CSIRT decides (analysis of ENISA's guidance). It does not move any deadline.
Mistakes are hard to undo. Only the CSIRT that received a notification can close it, so a report filed in error needs a request to that CSIRT.
ENISA advises registering when you have something to file, to avoid flooding CSIRTs with verifications. That leaves a real gap: if your first login happens during a live incident, you lose hours. Create the EU Login accounts and agree who your representatives are now, and do a dry run using the user manual and tutorial ENISA has published.
Latest updates since go-live
The regime is still settling. Here is what has moved, newest first.
Date | Update | Why it matters |
20 Oct | ENISA upgraded the platform to version 1.2.1 (ENISA) | Re-check your internal screenshots and runbooks against the live interface |
15 Oct | ENISA FAQ updated, adding guidance on cancelling mistaken notifications and on ENISA contacting you about EUVD entries and CVE assignment | Decide who answers follow-up contact from ENISA or the CSIRT |
15 Oct | Germany's Bundestag passed its CRA implementation act, making the BSI the market surveillance authority; the BSI has coordinated CRA reports for Germany since 11 September (BSI via Silicon Saxony) | National enforcement is taking shape, and more Member States are drafting their own laws |
11 Sep | Reporting duty and the platform went live together; the list of coordinating CSIRTs for all 27 Member States had been published a week earlier | Your CSIRT choice can be settled in advance |
27 Jul | Commission published its CRA application guidance (over 80 pages, non-binding, with a section on reporting) | Market surveillance authorities are expected to follow it, so align your definitions to it |
11 Dec 2025 | Delegated Regulation (EU) 2026/881 set the conditions for delaying onward dissemination | Governs when a CSIRT can hold back a notification from other Member States |
One caution for anyone maintaining a runbook: ENISA has revised several guidance pages without changing their "last updated" stamps, so keep your own dated copy of anything you rely on.
A reporting workflow that works at 3 a.m.
Most manufacturers already have a PSIRT, a vulnerability intake and an incident plan. The work is joining them to the Article 14 definitions and the platform, and making sure one named person can press submit at any hour. This is the sequence we recommend for industrial product makers.
Capture every signal in one place. Researcher emails, customer SOC reports, integrator calls, threat intelligence, national CSIRT contacts and known-exploited lists all land in a single queue with a timestamp. Publish a monitored security contact (a security.txt file helps) so signals reach you instead of a generic inbox.
Triage against the two definitions, fast. Set an internal target for the initial assessment (many teams aim for hours, not days) and require a written decision: what evidence exists, whether it meets "reliable evidence" or the severe incident test, who decided, and when. This memo is your best protection if an authority asks why you reported when you did.
Declare awareness and start three clocks. The 24-hour and 72-hour clocks for the authorities, and a parallel clock for user advisories. Record the awareness timestamp where everyone can see it.
Build the early warning from facts you have. Affected products and versions, the Member States where you know they ship, and, for incidents, whether malicious acts are suspected. Keep a pre-approved template so no one is drafting from scratch under pressure.
Submit through the platform, and keep proof. Save the confirmation and the submitted text. Decide in advance who may press submit, who reviews, and who covers when the first person is unreachable.
Run the 72-hour and advisory work together. The notification and the first customer advisory draw on the same facts, so write them from one source. Consider a machine-readable advisory format so asset owners can ingest it.
Close out the final report. Track the date a corrective or mitigating measure becomes available, because that starts the 14-day count for vulnerabilities, and the one-month count for incidents runs from the 72-hour notification.
Who needs to be in the room
Role | Owns |
PSIRT lead | Triage, the awareness decision and the decision memo |
Legal or regulatory counsel | Interpreting the trigger in grey areas, and the delay request where it applies |
Platform representative (primary and backup) | Filing and updating on the platform |
Engineering or product owner | Technical facts, affected versions, mitigation and fix plan |
Customer and field support | Advisories, and reaching integrators and asset owners |
Communications | Public statements, coordinated with the advisory |
Executive sponsor | Authority to act at night, and escalation of high-severity events |
Where industrial products make this harder
The 24-hour model was written for the whole product market, but OT vendors face friction that a smart-speaker maker does not. These are the six we see most, with what to do about each.
Challenge | Why it bites in OT | What to do |
Decades-old installed base | Article 14 covers products already on the market, including ones past end of support, and the units may be anywhere | Keep a product, version and country footprint from shipment and ERP data, so the Member State list in an early warning takes minutes, not days |
Weak visibility of exploitation | You rarely see attacks in a customer's plant, so awareness comes from outside | Add contract clauses and a direct channel for customers and integrators to tell you about suspected exploitation, and subscribe to advisory and known-exploited feeds |
Slow fixes | Firmware changes can need re-validation, safety review or a maintenance window before they reach a running line | Prepare mitigation playbooks (segmentation, access restriction, configuration changes) so a mitigating measure exists early. Remember it starts the 14-day final-report count |
Third-party code | Protocol stacks, RTOS and OEM modules mean the exploited flaw often sits in someone else's component | Get SBOMs per version, flow reporting duties down to suppliers, and record who tells whom. Under the CRA you also have to tell the component's maintainer |
Dual role as vendor and operator | Many OT firms are manufacturers under the CRA and essential or important entities under NIS2, and their customers have their own 24-hour clocks | Map each event to both regimes in one triage step, and send advisories fast, because your customers' deadlines depend on your information |
Build and release security | Engineering workstations, programming software and signing keys sit in scope of the severe incident test | Treat compromise of build, signing or update infrastructure as a potential Article 14 event from the first alert |
Scope still matters
Article 14 applies to products with digital elements inside the CRA's scope, and the product class (default, important or critical) does not change the reporting duty. What does matter is whether the product is in scope at all. Some sector-regulated products, such as medical devices, are excluded under Article 2, so check your own portfolio against it with counsel before you assume either way. Also note that importers and distributors who sell under their own brand or substantially modify a product can become manufacturers for CRA purposes (Lewis Silkin). For system integrators and machine builders, that is worth a careful look.
The honest gap
A fair challenge for any OT vendor is that the regime assumes you can find out. If a flaw in your product is being exploited inside a segmented plant and nobody tells you, you have not "become aware". The practical lesson is not to hide in that gap. Regulators will read your intake process, so make it easy for the people who do see the attacks to reach you.
Penalties, enforcement and the other clocks
What a miss can cost
Breaches of Articles 13 and 14 sit in the top fine tier of the CRA: up to €15 million or 2.5% of total worldwide annual turnover for the preceding year, whichever is higher (itemis, citing Article 64). Microenterprises and small enterprises cannot be fined for missing the 24-hour early warning specifically, but the reporting duty and the later stages still apply to them. For a mid-sized or large industrial manufacturer, there is no such cushion.
Fines are only part of the exposure. Market surveillance authorities can also demand corrective action, and a late or missing report on an exploited flaw damages customer trust in a sector where trust is the product.
Who enforces it
The CSIRTs and ENISA receive the reports. Enforcement belongs to national market surveillance authorities, and those regimes are still taking shape. Germany has passed its implementation law, with the BSI as market surveillance authority, while other Member States are at draft or consultation stage (law-firm analysis of the German act). Check the position in each country where you have an establishment or a significant market.
The other regimes that may fire on the same event
A single incident can start several clocks at once. The CRA is product-centred, NIS2 is entity-centred, and GDPR is data-centred, and each has its own recipient.
Regime | Trigger | First deadline | Reported to | Maximum fine |
CRA Article 14 | Actively exploited vulnerability or severe incident in a product | 24 hours | Through ENISA's platform, to the coordinating CSIRT and ENISA at once | €15 million or 2.5% of worldwide turnover |
NIS2 Article 23 | Significant incident at an essential or important entity | 24 hours (early warning) | National CSIRT or competent authority | €10 million or 2% (essential), €7 million or 1.4% (important) |
GDPR Article 33 | Personal data breach likely to risk individuals' rights | 72 hours | Supervisory authority | €20 million or 4% |
Figures from Lewis Silkin's October comparison. The practical consequence is that your triage should ask the regime questions together: does this meet the CRA test, does it affect our own operations as an NIS2 entity, and does it involve personal data? One decision memo, three possible filings.
Where IEC 62443 fits
IEC 62443 does not replace CRA reporting, and CRA reporting does not replace it. Think of the standard as the engine room: a mature secure development lifecycle and security update management make triage faster and give you the evidence to describe mitigations credibly. The CRA adds a legal clock and a named recipient on top. If you have already mapped your controls to IEC 62443, our earlier posts cover that. What this workflow adds is the live reporting layer.
CRA reporting readiness checklist
Use this as a self-check. If you cannot tick an item today, that is your next sprint.
Every in-scope product and version is listed, with the Member States where it ships
Component data (SBOM) exists for each supported and legacy version
A monitored intake exists for vulnerability and exploitation signals, internal and external
A written triage procedure maps to "reliable evidence" and to the Article 14(5) severe incident test
An awareness decision memo template exists, with four timestamps: first signal, triage start, decision, submission
Your main EU establishment and coordinating CSIRT are documented, with the fallback order if you have none
Primary and backup platform representatives have EU Login accounts with multi-factor authentication
Pre-approved templates exist for the early warning, 72-hour notification and final report on both tracks
A 24/7 on-call owner has authority to submit
A user advisory template and publishing channel exist, ideally with a machine-readable option
Mitigation playbooks exist for your top product families, and the team knows a published mitigation starts the final-report clock
Supplier contracts require fast notice of exploitation in components you ship
Your triage also tests NIS2 and GDPR triggers in the same step
You have run at least one timed exercise with an inconvenient start time
Common mistakes we see
Planning around December 2027 only. The reporting duty is already live and covers shipped products.
Waiting for certainty. The early warning is meant to be thin. A late complete report is worse than an on-time partial one.
Starting the 72-hour count from the early warning. It runs from awareness, whatever the platform counter shows.
Treating reporting as a customer-support task. It needs a named decision-maker and legal input.
Forgetting the users. The advisory duty runs beside the authority reports.
Ignoring supply-chain flaws. An exploited flaw in a bought-in component is still your product's report.
First login during an incident. Register, test and document access before you need it.
Frequently asked questions
Who has to report under CRA Article 14? Manufacturers of products with digital elements that are in the CRA's scope. Importers and distributors who sell under their own name or substantially modify a product can count as manufacturers, and open-source stewards have their own duty that starts on 11 December 2027.
What is the CRA 24-hour reporting deadline? An early warning is due within 24 hours of becoming aware of an actively exploited vulnerability or severe incident, followed by a notification within 72 hours and a final report later. The clock runs from awareness, which the Commission describes as reasonable certainty after an initial assessment.
Does it apply to products that are already on the market or out of support? Yes. The duty applies to in-scope products placed on the market before the CRA's main application date, and the Commission has said it continues after support ends.
Where do manufacturers submit reports? Through ENISA's Single Reporting Platform, selecting the CSIRT that coordinates for your main EU establishment. It is a web form in English with no API at this stage, and sign-in needs an EU Login account with multi-factor authentication.
What if the platform is unavailable? Wait and submit when it returns. ENISA allows contacting your CSIRT directly if immediate communication is needed, but the notification must still be filed through the platform.
What are the penalties for missing a report? Administrative fines up to €15 million or 2.5% of worldwide annual turnover, whichever is higher. Microenterprises and small enterprises cannot be fined for missing the 24-hour early warning alone.
How Shieldworkz can help
Shieldworkz is an end-to-end industrial OT cybersecurity company, covering products, services and solutions for SCADA, OT and IoT environments. For manufacturers of industrial products, the CRA reporting duty lands where product security meets plant reality, and that is the space we work in.
Typical starting points are a reporting readiness assessment against the checklist above, a facilitated tabletop that runs your own product scenario against the 24-hour clock, OT-specific vulnerability and patch management that makes mitigation planning realistic, and help building the customer advisory process so asset owners get what they need in time. If you want to test your workflow before an incident does, talk to the Shieldworkz team.
Additional resources
OT Network Visibility & Threat Detection RFP Template here.
OT Security Operations Center (SOC) with Incident Response Retainer RFP Template here.
Get Weekly
Resources & News
See How Our Industry-Leading OT Security Solutions Address Critical Security Challenges
You may also like
ARTEX AI Cyberattacks 2026: How Vapor Panda Breached 200+ Organizations in 11 Days
Team Shieldworkz
Supermarket Cyberattack 2026: How Attackers Manipulated Refrigeration Controllers Across Europe
Team Shieldworkz
MITRE ATT&CK for ICS: What v20 Changes for Plant Security Teams
Team SHieldworkz
OT Security in Pharma: Protecting GxP Production Systems
Team Shieldworkz
The Purdue Model for OT Security: Levels 0-5 with Examples and Latest Updates
Team Shieldworkz
CISCO SD-WAN Attack: CVE-2026-20127 Exploited to Deploy KeyDrift Malware and Collect Encryption Keys
Team Shieldworkz
