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. 

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. 

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. 

1. 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. 

2. 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. 

3. Day of mitigation release (say, the following Thursday): a hardening guide is published. The 14-day clock for the final report starts here. 

4. 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. 

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. 

1. 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. 

2. 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. 

3. 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. 

4. 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. 

5. 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. 

6. 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. 

7. 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 

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. 

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. 

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 

1. Planning around December 2027 only. The reporting duty is already live and covers shipped products. 

2. Waiting for certainty. The early warning is meant to be thin. A late complete report is worse than an on-time partial one. 

3. Starting the 72-hour count from the early warning. It runs from awareness, whatever the platform counter shows. 

4. Treating reporting as a customer-support task. It needs a named decision-maker and legal input. 

5. Forgetting the users. The advisory duty runs beside the authority reports. 

6. Ignoring supply-chain flaws. An exploited flaw in a bought-in component is still your product's report. 

7. 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.