EU Cyber Resilience Act 24-Hour Reporting: A 5-Step Compliance Architecture for IIoT Vendors (2026)

Twenty-four hours is shorter than the average industrial vendor’s triage meeting cadence. That is the engineering problem at the heart of Cyber Resilience Act 24-hour reporting, which became applicable on 11 September 2026 along with ENISA’s Single Reporting Platform. A regulation that once looked like a documentation exercise now imposes a latency budget on a human process that most operational-technology companies never designed for speed. If your product security incident response team learns about an exploited flaw on a Friday evening and the first cross-functional call is Monday morning, the clock has already expired twice over. This post treats that clock as a systems-design constraint rather than a legal one: what you have to instrument, what you have to precompute, and where the pipeline breaks when your fleet is air-gapped and your firmware is fifteen years old.

What this covers: the trigger definitions, a five-step reference architecture, a triage decision tree, the evidence pipeline, ENISA submission integration, and the OT-specific failure modes.

One-line note: this is a systems-architecture article, not legal advice. Validate obligations and scope with qualified counsel.

Context and Background

The Cyber Resilience Act — Regulation (EU) 2024/2847 — is the EU’s horizontal product-security law for “products with digital elements”. Most of its substantive requirements, including conformity assessment and CE marking for cybersecurity, do not apply until 11 December 2027. But the reporting obligations in Article 14 jumped the queue and became applicable on 11 September 2026, which means the first thing manufacturers must operationalise is the part with the tightest deadline and the least tooling.

The staged clock is well documented on the Commission’s CRA reporting page. A manufacturer that becomes aware of an actively exploited vulnerability, or of a severe incident having an impact on the security of a product with digital elements, submits an early warning within 24 hours, a fuller notification within 72 hours, and a final report thereafter. For an actively exploited vulnerability the final report is due no later than 14 days after a corrective or mitigating measure becomes available; for a severe incident the corresponding window is one month. Submission happens through ENISA’s Single Reporting Platform (SRP), which routes the notification to the CSIRT designated as coordinator and makes it simultaneously available to ENISA.

Two properties of this regime matter to architects more than the dates. First, it applies to products already on the EU market, not only to products placed on the market after September 2026 — so your installed base is in scope on day one. Second, Article 64 backs it with penalties of up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher, which is enough to make reporting latency a board-level reliability metric rather than a compliance checkbox.

Most IIoT vendors are not starting from zero. If you already run an IEC 62443 zones-and-conduits programme, you have a segmentation model and probably an IEC 62443-4-1 secure development lifecycle. Gap analyses circulated during 2025 and 2026 consistently found that 62443-4-1 covers a substantial share of CRA Annex I Part II — the vulnerability-handling half — but 62443-4-1 was written to govern process maturity, not wall-clock response latency. It tells you to have a defined vulnerability-handling procedure. It does not tell you that procedure must terminate in an external filing within one day. That delta is what this architecture closes.

A Five-Step Architecture for Cyber Resilience Act 24-Hour Reporting

Cyber Resilience Act 24-hour reporting is achievable when you decompose it into five pipeline stages that each own a slice of the latency budget: a pre-built asset and SBOM inventory, a normalised signal intake, a deterministic trigger-triage engine, an evidence service that assembles the dossier, and a submission integration to the ENISA SRP with a coordinated-disclosure loop feeding back into inventory. The only stage that can be done reactively is submission. Everything upstream must be precomputed.

Figure 1: The five-step CRA reporting pipeline, with the disclosure loop feeding back into inventory.

Read the diagram as a latency budget, not an org chart. Step 1 runs continuously and contributes zero hours to the clock if it is healthy. Step 2 is where the clock starts, because “awareness” is a property of your intake system. Step 3 should complete in minutes, not days, because it is a classification decision against fixed criteria. Step 4 is the stage that actually consumes hours, and it is the stage most vendors have never built. Step 5 is a form submission that should take under thirty minutes once the dossier exists. The feedback arrow matters: every filed case should improve the inventory and the VEX corpus that made it filable.

Step 1: inventory is the precondition, not a deliverable

The single biggest determinant of whether you can hit a 24-hour early warning is whether you can answer “which shipped units contain this component, at which version, on which sites, in which member states” without a human investigation. That is a join across three datasets: the component graph from your build pipeline, the deployed fleet ledger from shipment and activation records, and the geographic distribution that tells you which CSIRT jurisdictions are implicated.

CRA Annex I Part II requires manufacturers to identify and document components, including by drawing up a software bill of materials in a commonly used machine-readable format covering at least the top-level dependencies, and to keep it current through the support period. The regulation does not name a format; CycloneDX and SPDX are both accepted in practice. The operational point is that a top-level-only SBOM is legally sufficient but architecturally inadequate. When an exploit lands in a transitive dependency — a TLS library three levels down inside a vendor-supplied radio stack — a top-level SBOM answers no useful question inside 24 hours.

Build the component graph at full depth even though the minimum is top-level. Store it as a graph, not as a pile of JSON documents in object storage. The query you need under time pressure is a reverse lookup from a component-and-version tuple to a set of firmware build identifiers, and from build identifiers to serial numbers. If that query requires scanning every SBOM you ever generated, you have built an archive, not an index.

Step 2: awareness is an engineering event, not a feeling

Article 14’s clock starts when the manufacturer becomes aware. Your architecture should therefore define awareness as a timestamp written by a system, because otherwise it becomes a contested reconstruction after the fact. Practically that means a single intake queue that normalises every inbound signal into one case schema with a monotonic awareness timestamp: customer reports, distributor and importer notifications, threat-intelligence feeds, CISA-style exploited-vulnerability catalogues, researcher submissions via your coordinated disclosure address, honeypot and telemetry anomalies, and internal red-team findings.

Importers and distributors are a specific and underrated input channel. Articles 19 and 20 require them to inform the manufacturer without undue delay when they become aware of a vulnerability in a product they handle. In a two-tier industrial distribution model, that notification frequently arrives as an email to a regional sales contact. If it takes three days to reach your PSIRT, you have consumed the entire budget before the case exists. Give distributors a structured intake endpoint and treat it as a first-class source, with an SLA you actually measure.

The design rule: every channel must terminate in the same queue, with the same schema, and the queue must be the only place where awareness is recorded. Multiple parallel inboxes are how a 24-hour obligation quietly becomes a 96-hour one.

Step 3: triage must be deterministic, because judgement does not scale to one day

The trigger definitions are narrower than most teams assume, and that narrowness is your friend. An actively exploited vulnerability is one for which there is reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner. That is an evidence test, not a severity test. A CVSS 9.8 with no evidence of exploitation does not fire the trigger. A CVSS 5.3 with a confirmed in-the-wild exploit chain does.

The severe-incident branch is the one that catches teams out, because it hinges on whether an incident negatively affects — or is capable of negatively affecting — the product’s ability to protect availability, authenticity, integrity or confidentiality of data or functions. “Capable of” is doing a lot of work in that sentence, and it is why your triage engine needs a documented interpretation with worked examples rather than an ad-hoc call per case.

Encode both branches as a decision tree with explicit evidence thresholds and a hard timebox on the “unclear” path. The tree is not there to remove human judgement; it is there to bound it. A reviewer who must decide within forty minutes against written criteria produces a defensible, repeatable outcome. A reviewer who must decide “is this serious” produces a meeting.

The Triage Decision Tree in Depth

Figure 2: Mapping an inbound signal to the two CRA trigger definitions, with a timeboxed hold state.

The tree has four gates. The first is scope: does the signal affect a product with digital elements that you, as manufacturer, have made available on the EU market? For a multinational IIoT vendor this is rarely obvious. A controller sold globally under three OEM brands, two of which are private-label relationships, needs a scoping answer that the triage engine can return automatically from the product master data rather than one a product manager reconstructs from memory.

The second gate splits vulnerability from incident. These are different objects with different final-report deadlines and different evidence requirements, and conflating them produces filings that the coordinator has to bounce back. A vulnerability is a property of the product. An incident is an event affecting the security of the product. A single case can spawn both — a vulnerability actively exploited against a customer site is simultaneously an actively exploited vulnerability and, potentially, a severe incident — and your case model must allow one intake record to generate two tracked obligations rather than forcing a choice.

The third gate is the evidence test for exploitation. Define your evidence tiers in advance and write them down:

• Tier A — direct observation. Your own telemetry, forensic artefacts from a customer incident, or a reproducible exploit chain observed against a deployed unit. Fires the trigger.
• Tier B — credible third-party attribution. A national CERT advisory, a named vendor report with indicators of compromise, or a government exploited-vulnerability catalogue entry naming your component. Fires the trigger.
• Tier C — circumstantial. Public proof-of-concept code, exploit-broker chatter, or scanning activity against the affected port without confirmed compromise. Does not fire by itself; enters the timeboxed hold.
• Tier D — theoretical. Severity score only, no exploitation signal. Standard remediation backlog.

The timeboxed hold on Tier C is the most important control in the tree. It exists because the realistic failure mode is not a wrong classification — it is an indefinite “we’re still looking into it” that runs past hour 24 without anyone deciding anything. Give the hold an expiry. When it expires without a downgrade to Tier D, it escalates to trigger-fired and the early warning goes out. An early warning that is later withdrawn or corrected is a recoverable outcome; a missed deadline is not.

The fourth gate is the impact test for incidents. Write worked examples for your product family: a ransomware event on an engineering workstation that holds project files for your HMI is probably not a severe incident affecting your product; the same ransomware propagating through your remote-access broker into customer controllers probably is. The examples do the interpretive work once, in calm conditions, so that the on-call engineer at 02:00 is pattern-matching rather than reasoning from first principles.

Why severity scoring alone misroutes cases

Teams that already run a CVSS-driven PSIRT process tend to wire the CRA trigger to a severity threshold because it is the mechanism they have. This misroutes in both directions. It over-reports, because a stream of critical-scored but unexploited library CVEs floods the SRP with filings that carry no exploitation evidence. And it under-reports, because exploitation of a medium-scored flaw — an authentication bypass reachable only from an adjacent network segment, say — sits below the threshold and never escalates.

Keep severity scoring; it drives remediation prioritisation and customer advisories. But make the reporting trigger a separate, evidence-driven predicate that reads the same case record. Two consumers, one source of truth. This is the same separation-of-concerns argument that shows up in SOC 2 versus ISO 27001 control mapping: a control that serves two frameworks with different predicates should be instrumented once and evaluated twice, not forked.

Evidence Pipeline and ENISA SRP Submission

Steps 4 and 5 are where the architecture earns its keep, because they convert a classification decision into a filed document under time pressure.

Figure 3: The 24/72/final submission sequence across intake, triage, evidence and the ENISA Single Reporting Platform.

The sequence shows the awareness timestamp travelling with the case from intake through to the filing, which is the audit property you want: a single case identifier that ties the field signal, the triage decision, the dossier version and the SRP case reference together. When a market surveillance authority later asks why the early warning landed at hour 23 rather than hour 6, you want that answer to be a query, not an archaeology project.

What the early warning actually needs

The early warning is deliberately thin. It is a first notification that an actively exploited vulnerability or a severe incident has occurred, including — for incidents — whether it is suspected to be caused by unlawful or malicious acts. It is not a root-cause analysis, and treating it as one is the single most common way teams blow the deadline. The engineering implication is that the 24-hour artefact should be assemblable from data you already hold: product identity, affected versions as currently understood, the nature of the trigger, and the suspicion flag.

Build it as a templated document generated from the case record, with free-text fields the on-call engineer fills in under a word limit. If your early-warning generation requires input from three teams, it is not a 24-hour artefact.

What the 72-hour notification adds

The 72-hour notification is where the substance arrives: a description of the vulnerability or incident, and details of corrective and mitigating measures taken or available. Seventy-two hours is enough time for real analysis but not for a full fix cycle on embedded firmware, so the honest content is usually a scoped description plus compensating controls — network isolation guidance, feature disablement, credential rotation — rather than a patch.

This is where your VEX corpus pays for itself. A Vulnerability Exploitability eXchange statement records, per product and per component, whether a given vulnerability is exploitable in that product’s configuration and why. If you have been emitting VEX alongside every SBOM, the 72-hour scope statement is largely a rendering of existing machine-readable assertions. If you have not, three days is not enough to establish exploitability across a product line with two hundred firmware variants. The same argument applies further up the stack for teams shipping model-bearing products, where AI model supply-chain security introduces artefacts your SBOM tooling probably does not enumerate at all.

The final report and the fix-availability dependency

For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure is available. Note the dependency: the deadline is anchored to fix availability, not to the original awareness timestamp. For severe incidents, the corresponding window runs to one month and the content shifts toward incident description, root cause and mitigations applied.

That anchoring has a subtle architectural consequence for OT vendors. “Available” is a state your release pipeline knows about, so your release system needs to emit an event that starts the 14-day countdown automatically. Firmware for a safety-rated controller may take months to validate; the 14-day clock does not start during that period, but the moment the signed image is published, it does. Teams that track the countdown manually tend to discover it retroactively.

Integrating with the Single Reporting Platform

ENISA’s Single Reporting Platform went live on 11 September 2026. The submission model has three properties that shape your integration design.

Identity is federated and human. Registration runs on EU Login accounts with multi-factor authentication. Each manufacturer designates a primary Assigned Representative plus a set of secondary ARs. Validation of an AR’s authority by the CSIRT designated as coordinator happens after registration and in parallel with reporting, so a newly registered AR is not blocked from filing while validation is pending. Architecturally, this means the last mile is an authenticated human session, not a service-account API call. Design for that: your evidence service should produce a submission-ready package that a named human pastes or uploads, and you should have more than one trained AR because the on-call rotation does not care about office hours.

Coordinator selection is your decision. You choose the CSIRT designated as coordinator, generally the member state of your main establishment in the EU — where decisions about your products’ cybersecurity are predominantly taken. Make that determination once, document the reasoning, and store it in the case template. Deciding it during an incident is a guaranteed delay.

Routing is fan-out, not multicast from you. You file once; the receiving coordinator disseminates to other relevant member-state CSIRTs, and the notification is made available to ENISA. This removes the pre-CRA pattern of parallel national filings, and it means your integration surface is one platform rather than twenty-seven.

A practical operational detail: keep an offline-capable copy of the submission package. If your evidence service is itself degraded during a severe incident — a realistic scenario if the incident touches your own cloud backend — you still need to file. A rendered PDF plus a JSON case record on a laptop is an unglamorous but effective contingency.

OT-Specific Failure Modes: Air-Gapped Fleets and Long-Lived Firmware

Figure 4: The evidence pipeline that resolves a vulnerable component to affected serial numbers, including offline attestation for air-gapped sites.

Consumer software vendors solve most of this with telemetry. Industrial vendors cannot, and the differences are structural rather than incidental.

Air-gapped fleets break the observability assumption. A substantial fraction of installed industrial equipment never phones home, by customer policy and often by contract. You therefore cannot detect exploitation on those units, and you cannot enumerate their firmware versions on demand. The architectural response is to shift from live telemetry to a deployed fleet ledger built from shipment records, activation events, service-visit reports and commissioning data, with an explicit confidence attribute per record. A ledger entry that says “we believe site X runs firmware 4.2.1, last confirmed at a service visit fourteen months ago, confidence medium” is far more useful in an early warning than a blank. Offline attestation — a signed version manifest collected during scheduled maintenance and uploaded later — converts some of that medium confidence into high confidence over time.

Long-lived firmware makes the component graph historical. A controller shipped in 2013 and still under a support commitment contains a dependency set that your current build system has no knowledge of. Reconstructing an SBOM for a decade-old image is a binary-analysis project, not a lookup. If you are only generating SBOMs going forward, you have a coverage cliff precisely where your exposure is largest. Retroactive SBOM generation for supported-but-legacy images is unglamorous backlog work that pays off exactly once, catastrophically, when an exploited flaw lands in a component that only exists in old builds.

Third-party component provenance is frequently opaque. Industrial products commonly embed supplier-provided modules — radio stacks, protocol libraries, RTOS distributions, motion-control firmware — delivered as binaries under NDA with no SBOM. When exploitation news breaks for a component inside one of those modules, you cannot answer the scoping question without the supplier, and the supplier’s response latency is not governed by your 24-hour clock. The only durable fix is contractual: SBOM delivery obligations and a defined vulnerability-notification SLA in supplier agreements, with the SLA tighter than your own external deadline. In the interim, maintain a manually curated inventory of opaque modules with named supplier security contacts, so that hour one is a phone call rather than a search for who to call.

Distributor and importer layers add hops. Article 19 and 20 duties run to the manufacturer, not to ENISA, which means the channel is an input dependency you own operationally even though the legal duty sits with them. Instrument it: a structured web form, a monitored mailbox with automated case creation, and a quarterly test message to confirm the path still works after the inevitable partner reorganisation.

Product identity is messier than the data model assumes. OEM relabelling, regional variants, configurable option modules and field-retrofitted subassemblies mean that “affected product” is not a single SKU. Your impact resolver needs to traverse from component to build to configuration to serial number, and it needs to handle the case where a customer has installed a third-party expansion card that changes the exposure. Getting this traversal right is the same class of problem as maintaining a coherent digital thread for regulatory artefacts elsewhere in the EU stack — the battery passport data model faces an almost identical identity-resolution challenge for a different regulation.

Trade-offs, Gotchas, and What Goes Wrong

Over-reporting is a real cost, not a safe default. Some advisors recommend filing whenever in doubt. That is defensible legally and expensive operationally: every filing consumes PSIRT capacity, generates coordinator correspondence, and — because notifications propagate to multiple national CSIRTs — creates customer-facing questions you then have to answer. A vendor that files forty early warnings a year on Tier C evidence will spend more engineering time on correspondence than on fixes. The trigger definitions are narrow by design; use them.

Under-reporting concentrates risk on one decision. The mirror failure is a triage culture that rationalises every signal into Tier D. Watch the ratio of holds that expire into escalation versus holds that downgrade. If nothing ever escalates from hold, your criteria are not being applied.

The awareness timestamp is contestable and you will be asked about it. If a researcher emailed your generic support address eight days before your PSIRT saw the case, a market surveillance authority may take the view that awareness began earlier. Route and log every security-relevant inbound channel; unmonitored aliases are an unbounded liability.

Coordinated disclosure and mandatory reporting can conflict. A researcher under a 90-day embargo may expect no third-party notification. CRA reporting is not optional because of an embargo, and the resulting filing may reach parties the researcher did not anticipate. Set that expectation in your published disclosure policy rather than negotiating it mid-case.

Your own backend is in scope for the incident branch. If you operate a cloud service that is part of the product — a device-management platform, an OTA distribution service — a compromise there can be an incident having an impact on the security of the product. Teams that scoped their CRA programme to firmware only tend to discover this late.

Twenty-seven-language customer communication is a hidden dependency. Article 14(8) expects users to be informed of the vulnerability and, where necessary, of mitigating and corrective measures. For a pan-European installed base, advisory translation and distribution is a workflow with its own latency. Pre-translate the templates, not the specifics.

Anti-pattern: treating the SRP as the system of record. The platform is a submission surface. Your case management system is the system of record, and it must hold the full evidence trail, the decision rationale and the version history of every dossier. If your only copy of what you told the coordinator lives in a web form you filled in at 03:00, you cannot reconstruct the timeline eleven months later.

Practical Recommendations

Start with the query, not the policy. Pick a real component — a TLS library, a protocol stack — and time how long it takes your organisation to produce a list of affected serial numbers and member states. That number is your actual readiness metric, and it is usually measured in days. Everything in this architecture exists to drive it under an hour.

Then close the gaps in dependency order. Inventory before triage, triage before evidence, evidence before submission integration. Building the SRP integration first is tempting because it is concrete and bounded, and it is useless without the three stages that feed it.

Run the drill quarterly with a realistic scenario: a Tier B advisory naming a component in a supplier-provided module, arriving at 17:00 on a Friday. Measure time-to-awareness-timestamp, time-to-triage-decision, and time-to-submission-ready-package separately, because they fail for different reasons.

A starting checklist:

• [ ] Single normalised intake queue with a system-written awareness timestamp, covering all inbound channels including distributors and importers.
• [ ] Full-depth component graph with reverse lookup from component-version to build to serial number, including retroactive coverage for supported legacy firmware.
• [ ] Deployed fleet ledger with per-record confidence and an offline attestation path for air-gapped sites.
• [ ] Written evidence tiers, a documented severe-incident interpretation with worked examples, and a hard timebox on the hold state.
• [ ] VEX statements generated alongside every SBOM, so 72-hour scoping is a render rather than an investigation.
• [ ] CSIRT coordinator determination made and documented in advance; at least two trained and registered ARs on the SRP, covering the on-call rotation.
• [ ] Release-pipeline event that starts the 14-day final-report countdown when a fix becomes available.
• [ ] Supplier contracts carrying SBOM delivery and a vulnerability-notification SLA tighter than 24 hours.
• [ ] Pre-translated advisory templates and a customer notification channel that can reach affected users down to version level.
• [ ] Case management as the system of record, with full decision rationale and dossier version history.

Frequently Asked Questions

When does the 24-hour CRA clock actually start?

It starts when the manufacturer becomes aware of the actively exploited vulnerability or severe incident. Because “awareness” is contestable after the fact, the defensible approach is to make it a system event: a timestamp written by your intake queue when a security-relevant signal is received through any monitored channel. Unmonitored inboxes are the main risk, since a signal that sat in a generic support alias for a week may be treated as the point of awareness rather than the day your PSIRT opened the case.

Does a critical CVSS score trigger CRA reporting?

No. The trigger for the vulnerability branch is exploitation, not severity. An actively exploited vulnerability is one for which there is reliable evidence that a malicious actor has exploited it in a system without the system owner’s permission. A CVSS 9.8 flaw with no exploitation evidence does not fire it; a medium-scored flaw with a confirmed in-the-wild exploit does. Keep severity scoring for remediation prioritisation, but drive the reporting predicate from evidence tiers instead.

Do importers and distributors file reports to ENISA themselves?

The Article 14 reporting duty sits with the manufacturer. Importers and distributors have a separate obligation to inform the manufacturer without undue delay when they become aware of a vulnerability, and to inform market surveillance authorities where a product presents a significant cybersecurity risk. For a vendor, this makes the channel partner an input dependency: if their notification takes days to reach your PSIRT, it consumes your budget, so give them a structured intake path and measure it.

How do I report on air-gapped units I cannot observe?

You report what you know, with stated confidence. Replace live telemetry with a deployed fleet ledger assembled from shipment, activation, commissioning and service-visit records, and attach a confidence attribute and last-confirmed date to each entry. Offline attestation — a signed version manifest collected during scheduled maintenance — upgrades that confidence over time. An early warning that scopes affected units probabilistically, with the basis stated, is far better than one that scopes nothing.

Does an existing IEC 62443 programme cover CRA reporting?

Partly. Published gap analyses indicate IEC 62443-4-1 addresses a large share of CRA Annex I Part II vulnerability-handling requirements, so a mature secure-development lifecycle gives you the process scaffolding, SBOM discipline and disclosure policy. What 62443-4-1 does not impose is a wall-clock external filing deadline. The gap you must close is latency engineering — intake normalisation, deterministic triage, precomputed evidence — rather than process documentation.

What happens if I miss the 24-hour deadline?

Article 64 provides for administrative fines of up to EUR 15 million or 2.5% of worldwide annual turnover for the preceding financial year, whichever is higher, for breaches of the Article 14 obligations. Enforcement sits with national market surveillance authorities and is expected to weigh intent, cooperation and remediation. The practical implication for architects is that reporting latency should be treated as a tracked reliability metric with its own error budget, not as a legal edge case.

Further Reading

• IEC 62443 industrial control systems cybersecurity zones and conduits — the segmentation and secure-development foundation that most of this architecture assumes.
• AI model supply-chain security in 2026 — extending component provenance to model artefacts that conventional SBOM tooling misses.
• SOC 2 vs ISO 27001 technical controls — instrumenting one control surface for multiple compliance predicates.
• Battery passport PLM data model under EU regulation — the same product-identity resolution problem in a different EU regime.
• European Commission — CRA reporting obligations — the primary source for the staged timeline.
• ENISA — Single Reporting Platform — registration guidance and the Assigned Representative user manual.
• Vulnerability Coordination Under the Cyber Resilience Act (arXiv 2412.06261) — peer-reviewed analysis of the CRA’s coordination model.

By Riju — about