Scoring Your CRA Readiness From the Plant Floor

Third cabinet from the door, behind a smoked-acrylic window, a paperback-sized gateway blinks on the DIN rail. Fanless. It's been there three years, maybe four. Someone flashed it from a vendor image during a commissioning week, wired it to a bank of centrifugal pumps, and it's fed flow and vibration data to the historian ever since. Nobody's touched it since. Install it, forget it, trend the readings. That's usually the whole idea.

A regulation changed what that box is, and most people who walk past it don't know yet. The EU Cyber Resilience Act entered into force in December 2024. Under it (Regulation (EU) 2024/2847, for your files), a gateway like that one stops being mere plant kit. It becomes a product with digital elements. Someone now has to stand behind its security for the whole time it runs. The manufacturer, usually. Not always. And the cases where it isn't the manufacturer are where plant and integration teams get caught.

On 13 July 2026, the EU cybersecurity agency ENISA published a tool aimed straight at whoever now has to answer for boxes like that. It's called the SME Cyber Resilience Maturity Assessment Model, a self-scoring instrument built around five domains, each rated across three levels from basic to advanced. You read your own operation against it. And out comes a rough measure of how far you sit from ready. Read against a real processing line, though, it behaves less like a scorecard than a gap list. Here's what it looks like from inside the cabinet.

Is that gateway a product now?

Walk any food, metals, or waste-to-energy site and you'll find two kinds of digital kit. Bought and built. The bought kind (the transmitter from Endress+Hauser, the PLC from Siemens, the drive from ABB) comes from a manufacturer who now carries the Cyber Resilience Act obligation for it. Good. That's their software bill of materials, their patch pipeline, their support declaration. Your job with those is mostly to keep buying from makers who take it seriously, and to actually read the support-period line on the datasheet.

Where's the line, though? A product with digital elements, in the law's language, is roughly anything carrying software or firmware that can connect, directly or indirectly, to a device or a network. That's most of a modern plant. The transmitter with a Bluetooth commissioning app. The safety relay with a configuration port. The soft starter serving its own little web page. A mechanical valve with no logic in it sits outside. Almost everything with a chip and a comms path sits inside.

But the built kind is where it gets interesting. That flashed gateway. The edge node someone in engineering stood up to bridge Modbus to MQTT. The HMI image you cloned and tweaked across nine lines. A bare sensor module you integrate and deploy under your own plant's name. Do enough to a product (integrate it into something you place on the market, modify it substantially, badge it as your own) and the regulation can treat you as its manufacturer. Not the original vendor. You.

This is why ENISA didn't write the model only for device makers. It says so plainly: the tool is meant first for organisations that make and sell products with digital elements, but it's built to be used by the integrators and service providers around them too. On a processing site, that's you more often than you'd like. The systems integrator who commissioned the line. The maintenance outfit that keeps a fleet of gateways alive. The plant that quietly became a small manufacturer the day it started cloning its own edge image.

Two grey zones catch people. The first is substantial modification: change a product enough after it's on the market and, in the regulation's logic, you've made a new one and picked up the maker's duties for it. Reflashing a gateway with your own build is the plain case; a heavy configuration change is arguable. The second is the private-label move. Buy a vibration sensor as a white-label module, put your plant's name on the housing, deploy it as your own, and you've placed a product on the market under that name. Neither is exotic on a real site. Both quietly slide the obligation onto you.

Five domains, read off the cabinet

The model splits readiness into five domains. None of them will surprise a plant engineer in the abstract. What surprises people is where their own site actually lands once they score each one honestly against the hardware in the room. The security-by-design domain, for one, is largely IEC 62443 thinking pointed at a single product instead of a whole architecture.

Take security by design. On a lot of OT the honest basic score is generous: shared admin passwords printed on a laminated card by the panel, a flat network where the billing PC can reach the burner management system, and "it's air-gapped" as a controls philosophy that stopped being true the day someone added a cellular modem for remote support. Advanced here isn't exotic. It's the segmentation, the secure defaults, and the change control that IEC 62443 has described for years. The regulation just makes the maker responsible for shipping the product already in that state.

Two things fall out of scoring it this way. The domains people brace for aren't the ones that sink them. And the fix for the worst domain isn't a firewall. It's a filing cabinet.

Why the paperwork domain fails first

Here's what surprised us, reading the model against real lines: the domain that scores worst is the one with the least technology in it. Vulnerability and patch management is the one everybody dreads, and it's genuinely hard on a plant, because you can't reboot a running PLC to take an update. Yet most sites limp to something like intermediate there. Segmentation and update discipline are things you can buy and schedule. Governance and documentation is where the floor drops out.

The patch problem is genuine, to be clear, just shaped differently than IT's. You can't push a Tuesday update to a controller mid-anneal. The update window might be a scheduled outage twice a year, and proving that a firmware bump didn't shift a control loop's behaviour takes longer than the bump itself. So the advanced score here isn't "patch fast." It's "have a tested, scheduled, reversible way to patch at all, and a channel to hear about the vulnerability before it's a headline." That's achievable. It just isn't automatic.

Now ask a site for a software bill of materials for the gateway in cabinet three, and watch what happens. Blank looks, mostly. Nobody wrote down which Linux build it runs, which libraries the vendor baked in, which of those carry known holes. The image came from a supplier, got flashed, got forgotten. That isn't negligence. It's how OT has always worked. Hardware is the asset; software is the stuff that makes the hardware go. The Cyber Resilience Act inverts that. It treats the software as the thing you answer for, named component by named component, across the whole service life.

There's a mechanical fix and a cultural one. The mechanical fix is the SBOM itself: a machine-readable list of every software component in a device, its version, and where it came from. Vendors are starting to ship them, and you can generate your own for self-built images with open tooling. The cultural fix is harder. It means treating a firmware image the way you already treat a piping-and-instrumentation diagram: a controlled document, versioned, owned, revisited when anything changes. Plants know document control cold. They've just never pointed it at the software inside their sensors.

Product life cycle management is the same wound from another angle. A furnace controller on a metals line runs fifteen, even twenty years. The vendor who sold it might not exist by year twelve. So who ships a security update then? The model wants that answered at design time: a declared support period, and a plan for the day it ends. Most sites have never declared anything of the sort. The kit runs until it dies, and "end of support" means the morning it finally didn't come back up.

The clock that starts in September

Two dates matter, and the near one is close. From 11 September 2026, the Cyber Resilience Act's reporting duties switch on. If a product you count as the manufacturer of carries a vulnerability that's being actively exploited, the clock runs tight and in two stages: an early warning to your national CSIRT and to ENISA within 24 hours of becoming aware, a fuller notification inside 72 hours, then a final report no later than 14 days after a fix or mitigation is ready. Everything moves through one channel, the CRA Single Reporting Platform that ENISA operates. We walked through those reporting mechanics in June; the maturity model asks the question underneath them, which is whether you could hold to that clock at all.

Read that as an operations problem, because that's what it is. A one-day early-warning window isn't a filing exercise. It assumes you'd know, within that day, that one of your edge devices is being exploited in the wild. Which assumes more than most sites have: eyes on the fleet close enough to notice, a named owner for the call to report, a path that works on a Sunday. The historian trends process data beautifully. It says nothing about whether the gateway feeding it just got popped.

Picture the mechanics of it. A CVE lands for the exact Linux build on your protocol converters, and word comes that it's being exploited. Who sees that advisory? Who decides it applies to your fleet, and how quickly? Who holds the credentials and the authority to file with the CSIRT and ENISA on a Saturday night? On most sites the honest answer is nobody yet, or one overloaded controls engineer who's also covering a shift. The reporting duty wants more than a filled-in form. It wants a standing capability, and capabilities take a lot longer to build than templates take to publish.

Vulnerabilities aren't the only trigger. Severe incidents count too: a breach that touches the security of the product, or of the people using it. Same platform, same tight early clock, a final report inside a month of the 72-hour mark. And the duty reaches products already out in the field, not merely the ones shipped new after the deadline. The gateway that's been blinking since 2022 isn't grandfathered out.

The far date is 11 December 2027. That's when the main obligations land in full: the essential cybersecurity requirements, the conformity assessment, CE marking against them, the technical file behind all of it. Far enough off to feel abstract. Not far enough to start late, given that the paperwork domains are the slow ones, and you can't buy your way through them in a quarter.

Running the model against your own line

You don't need a consultant for the first pass. You need an afternoon and an honest inventory. Start with the asset register, or the historian's tag list if the register's gone stale, and write down every device on the line that runs software. Not just the obvious computers. The smart transmitters, the protocol converters, the managed switches, the vibration gateways, the vision camera over the sorter. Anything with firmware you could, in principle, update.

Then split that list in two. For each device, one question: are we the manufacturer of this, in the regulation's eyes? Bought whole and running untouched vendor firmware: that's theirs. Self-built, reflashed, materially modified, or badged and passed on under your name: that's yours. The second pile is your scope. It's usually the shorter list, and the more uncomfortable one, because it's the kit nobody ever documented.

Now score the short pile against the five domains, level by level, and fight the urge to be generous. Basic means basic. Out of the gaps, two priorities sort themselves. The September duty wants an answer first, because it's nearest and it's operational: can you actually detect and report an exploited device inside a day? That's a monitoring problem before it's a compliance one, which is what a live edge-telemetry and fleet-visibility layer exists to do: know what every device runs, and get told the moment one starts acting wrong. The 2027 obligations, the documentation and the lifecycle work, run underneath as the longer project.

For the bought pile, there's one active move worth making now: ask your suppliers for their SBOMs and their declared support periods, in writing, and start filing them. It costs you an email, and it tells you fast which vendors have their act together. For the built pile, begin the boring documentation the model rewards: what it runs, who owns it, when support ends. Start it before the deadline forces it, because a document trail you build calmly beats one you assemble in a panic the quarter it's due.

None of this needs a big-bang programme. The model is graded for a reason: basic to intermediate on a domain is often a week of unglamorous work, not a capital project. Pick the two worst domains on your owned pile, move each up a level, re-score, repeat. You climb it one level and one domain at a time.

The fifth domain, awareness and skills, is the quiet one, and the survey behind the model shows why it earns its place. ENISA polled 194 organisations across 31 countries early this year. Two thirds of them, 66%, had so much as heard of the Cyber Resilience Act before the questionnaire arrived. Sit with that. A third of the small firms building and integrating digital products into Europe's plants hadn't heard of the law at all, and that was months before its first duties bite. On a plant floor the figure's probably worse, because the person flashing gateways rarely reads EU regulatory bulletins.

A green score is not a certificate

ENISA put a caveat on its own tool, and it's the most important sentence in the pack. An advanced score, it says, doesn't replace your legal obligations and shouldn't be taken as evidence of compliance. Read that twice before you show a green dashboard to a board. The model measures readiness, not conformity. You can score well and still be non-compliant, because compliance is judged against the regulation's actual requirements, not against how mature you feel.

The trap is a quiet one. A maturity dashboard glowing green makes a comfortable slide, and comfort is the opposite of what you want a year out from a hard deadline. But a self-assessed "advanced" can breed the belief that the compliance work is finished, when the model has only told you your habits are in decent shape. A market surveillance authority won't ask for your maturity score. It'll ask for the technical documentation, the conformity assessment, the evidence. Keep the two ideas in separate boxes: this is how ready you are, and that is what the law will actually check.

That doesn't make it a paperwork toy. Used honestly, it does the one thing a plant team struggles to do in a status meeting: it turns "are we okay on this cyber thing?" into a ranked list of specific, ownable gaps. Which devices are yours to stand behind. Which domain is weakest. What has to be true by September, and what by 2027. Any plant team can spare an afternoon for that.

Which brings it back to the box in cabinet three, still blinking its slow green heartbeat behind the acrylic. For three years it was a data source and nothing else. It's still that. It's also, now, a product someone has to answer for. The first useful step is the cheapest one: knowing whether that someone is you. The model won't make the gateway secure. Scored straight, it tells you how far you've got to go. On most sites that distance is longer than the dashboard hopes, and shorter than the dread fears.

Notes

A caveat on the caveat: this reads a sector-agnostic tool from one angle, the process plant. The model is meant for any SME making products with digital elements, so how much of it bites depends on how much you build versus buy. Not every tweak to a device makes you its manufacturer; where that line falls is a legal call worth getting properly rather than from a blog. And the model's own warning stands over all of it: it measures readiness, not compliance.