The Cyber Resilience Act's 24-Hour Clock at the Edge

The enclosure sits at chest height on a steel upright. Grey powder-coat, louvres along the bottom, a clear door with a torque label on the latch. Open it and the inventory is familiar: a DIN-rail edge gateway about the size of a paperback, a managed switch beside it, a protocol converter that talks Modbus on one side and OPC-UA on the other, and a small fanless PC running a historian. Cables dressed, ferrules crimped, every conductor numbered. A clean cabinet. We've commissioned dozens that look almost exactly like this one.

What's different now isn't in the cabinet. It's in the law. As of this summer, nearly every box behind that door — anything that ships with software and gets sold into the European market — is a "product with digital elements". And one category of those products is about to acquire something it never carried before: a legal clock, measured in hours.

What the regulation puts behind the door

The Cyber Resilience Act, Regulation (EU) 2024/2847, has been on the books since December 2024. Most of it stays quiet until December 2027, when the secure-design "essential requirements", the conformity assessment, and the CE marking all take effect. So it's tempting to file the whole thing under "deal with it later". That's the trap. One slice of the regulation moves first. The duty to report, set out in Article 14, starts on 11 September 2026. As of late June, that's about ten weeks away.

The scope is wide by design. A product with digital elements is, in the regulation's own words, "a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately". Hold that definition up against the cabinet. The gateway qualifies. So does the managed switch, the protocol converter, the panel PC, and the firmware on the vibration probe bolted to a pump three metres away (yes, that probe counts too). Each is a distinct product. Most come from distinct makers.

And the machinery is already switching on around us. Two dates this month mattered. By 11 June, Member States had to have in place the bodies that will assess and notify conformity. Through June, ENISA published the registration steps and the dry-run material for the platform that will receive these reports. None of this is hypothetical anymore. The breakers are closing.

Why a probe needs a clock

Why should a vibration probe fall under cybersecurity law at all? The answer is in the threat data. ENISA's threat assessment for 2025, published last October, curated 4,875 incidents across the year ending 30 June 2025. Manufacturing climbed from seventh to fourth place among the sectors the Union tracks under NIS2. Most of the hits on manufacturers were ordinary crime, ransomware mostly, rather than state work. But the same report flags hacktivist campaigns that pushed past public websites and tried to disturb operational-technology systems directly, often where a plant sat near a defence supply chain. When a curve bends like that, regulators reach for deadlines. An exploited flaw in a gateway isn't an IT inconvenience on a plant; it's a route to the process itself, to the loop that holds a furnace or a digester where it should be. That's the logic the regulation runs on, and it's why the obligation reaches all the way down to the firmware on a probe.

The cascade, and what actually trips it

Here's the part that reorders a plant's week. The thing that starts the clock isn't a vulnerability. It's an actively exploited one. The regulation is exact about the bar: a vulnerability "for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner". Not a theoretical CVE. Not a vendor advisory you skim on a Friday. Evidence that someone is using the flaw, in the wild, against a live system.

Once a maker becomes aware of that, three reports come due in sequence, and the first one comes fast.

Two details matter more than the deadlines. First, the report has one destination. It reaches the maker's coordinating CSIRT and ENISA at the same moment, through a single platform, filed once, instead of being fanned out across twenty-seven national inboxes. Second, that opening note is meant to be thin. Within a day, before anyone has a root cause, the maker says only that exploitation is happening and where the product is on sale. The forensics follow in the later notification and the final report. ENISA, for its part, holds the receiving end and turns the aggregate into trend reporting on a two-year cycle.

One more nuance worth keeping. A "severe incident" affecting a product's security is a separate trigger from an exploited vulnerability, and it carries its own tail on the final report. After September, the same platform also opens a voluntary lane: makers can flag general vulnerabilities, near misses, and threats they think others should see. The mandatory core stays narrow. The exploited-in-the-wild subset is what carries the stopwatch.

Here's what surprised us

The first time we walked a cabinet through the regulation line by line, the surprise wasn't the deadline. It was the count. We tallied the products with digital elements behind a single door. One gateway. One managed switch. One protocol converter. One panel PC. Then the firmware: in the sensor, in the variable-frequency drive, in the safety relay. The assembly we had always commissioned and documented as one system was, in the law's eyes, a dozen separate products, each with its own maker, its own declared support window, its own clock. The boundary an engineer draws around a system and the boundary the law draws around a product are not the same line.

The second surprise was direction. The reporting duty sits with the maker, not with you, the operator. But where does a maker first catch evidence that one of its products is being exploited? Often in the field, in telemetry coming back from a site exactly like yours. So your plant becomes the maker's early-warning sensor, whether or not anyone designed it that way. Your incident response and your supplier's legal deadline are now coupled. That 24-hour clock can begin ticking on the strength of an anomaly your historian flagged at three in the morning, long before a CSIRT has ever heard of it.

The bill of materials you can't report without

None of this functions without knowing what you actually shipped. Annex I of the regulation tells makers to identify and document the components in a product and to keep a software bill of materials in a machine-readable format, covering at the very least the top-level dependencies, kept current and available to market-surveillance authorities on request. The text doesn't pin a format (CycloneDX and SPDX are the two the tooling and the authorities already read).

The SBOM is the unglamorous engine of the whole scheme. You can't report a flaw in a library you didn't know was inside your firmware. When a CVE drops against, say, a widely used compression library at two in the morning, the maker holding a current SBOM runs one query and learns within minutes whether the product is affected, and which versions. The maker without one starts a scavenger hunt across build systems and old release branches. One of those teams makes the window. The other is still grepping when it closes.

There's a second field fact folded into Annex I: the support period. A maker now has to state, at the point of sale, how long it will handle vulnerabilities for the product. Set that against how OT actually lives. A pump skid or a switchgear lineup runs fifteen, twenty years. Plenty of edge devices ship with a support commitment of a fraction of that. The stretch between the day support lapses and the day the asset is finally pulled is a genuine exposure, and it's now a figure you can read off the datasheet at purchase rather than a nasty discovery three site audits later.

Where IEC 62443 already did the heavy lifting

If you run OT, most of this will feel like ground you've already covered. The secure-development and component-hardening practices the CRA labels "essential requirements" line up closely with the IEC 62443 series that plant engineers already write into tenders. Europe is making that alignment official. The Commission has asked CEN, CENELEC and ETSI for 41 harmonised standards under the regulation; a product built to one of those, once they land, earns a presumption of conformity. For industrial equipment, the drafting bodies are working straight from 62443's parts 4-1 and 4-2: secure product development on one side, technical security for the components on the other.

On the operations side, NIST's SP 800-82 has carried the OT vulnerability-management playbook for years: inventory the assets, track the exposures, coordinate the fix, remediate without sacrificing uptime or safety. The CRA doesn't replace that work, and it doesn't contradict it. What it adds is a statutory deadline on one half of the job, the disclosure half, and a single address to send it to. So the honest framing for a plant team is a modest one. This regulation is less a new discipline than a new tempo. The work you'd already call good OT hygiene is now also the work the law expects, with a stopwatch on the bench.

Is your device "important"? The 2027 question to start now

There's a second wave behind the reporting deadline, and it's worth scoping early. From December 2027, a product's class decides how hard its conformity assessment is. Ordinary products can self-assess. But the regulation singles out "important" and "critical" categories in its annexes, and several read like a cabinet inventory: components with security functions, network-management tools, parts of industrial systems. For the important class II and the critical tier, self-assessment is off the table; a maker needs a notified third party or a certification scheme. You won't file those assessments. Your suppliers will. The reason to map your installed base against those classes now is plain: it tells you which of your vendors face the steepest climb to 2027, and therefore which deserve a hard look before you specify them into the next project.

What to put in the contract

You aren't the entity that files the report. But you carry the exposure when a supplier is slow, and the place you hold real influence is procurement. Four things belong in every tender for a connected device now.

Ask for the support-period end date in writing, on the quote. Require an SBOM delivered with the device, in CycloneDX or SPDX, and kept current through the support life. Get the name of the supplier's CRA reporting contact and a one-page description of what happens when a flaw in their product is exploited inside your fence. And settle, up front, how they'll take in the signals your site can offer: the logs, the anomalies, the telemetry that's often the very first sign something is wrong.

That last point is where operations meets the clock. The same edge telemetry that catches a bearing starting to fail is, more and more, the evidence that starts a 24-hour report somewhere up the chain. If you run an edge telemetry and analytics platform, the practical move is to wire its security-relevant alerts through to the supplier's disclosure contact, and not let them sit only in a maintenance queue. A site that can hand a maker clean, timestamped evidence fast is a site whose suppliers hit their deadlines, and whose own window of exposure closes sooner.

And name an owner before you need one. When a supplier's product is the one being exploited, the clock is theirs, but the evidence and the access are usually yours. Decide now who at your site takes that call on a Saturday, what they're cleared to share, and how an artefact (a packet capture, a controller log, a photo of an alarm screen) reaches the vendor without threading three approvals first. A channel agreed in the kick-off meeting is worth more than any clause once a live exploit is moving through the fleet.

Where the clock gets blurry

None of this is as tidy on a gravel access road as it is in the Official Journal. Start with the platform itself. As of late June, it isn't fully live. ENISA has been shipping registration guides and dry-run exercises through the month, with the production system due to open alongside the deadline. The rehearsal window before September is thin. A regime whose whole promise is "report within a day" is asking makers to practise on infrastructure that arrived only weeks before go-live. These are real limitations, not lawyerly nitpicks.

Then the definitions do their own damage. When, exactly, are you "aware"? A single strange log entry, or a confirmed exploit chain? The threshold sets when the clock starts, and two competent engineers will read it two ways. What separates a "severe incident" from a bad afternoon? A product sold across the Union touches several CSIRTs at once, and the rules carve out narrow exceptions where a notification can be held back on security grounds. None of that gets settled by reading the article a second time.

And there's the installed base, which is where most plants actually live. The CRA governs products placed on the market. It doesn't reach back and re-certify the drive you commissioned in 2019. That drive is still in the cabinet, still networked, still exposed, and still outside anyone's 24-hour clock. The regime makes new equipment more accountable. It does nothing for your legacy estate. Securing that remains exactly as much your job as it was last year, and it won't change in September.

One more open edge: open source. Maintainers of free components get a deliberately lighter touch than commercial makers, which matters because so much edge firmware sits on open foundations. Where the duty lands when a volunteer library, a system integrator, and a device maker all touch the same flaw is going to take real cases, and probably a few uncomfortable ones, to work out.

Back at the cabinet. Nothing about it looks different in late June than it did a year ago: the same grey door, the same dressed cables, the same quiet fan in the panel PC. What changed is invisible and legal. Come September, several of those boxes carry a duty measured in hours, and the plant wrapped around them is part of how that duty gets met. The engineering is familiar. The deadline is new. The useful move is to know which of your cabinets is already on the clock, before someone outside your fence starts it for you.