When you first sit down with the production director in a glass room overlooking the packaging line, any talk of “regulatory compliance” sounds abstract. One glance at the overall equipment effectiveness (OEE) board by the door is a reminder that every minute of downtime costs real money. The Directive on Measures for a High Common Level of Cybersecurity Across the Union (NIS2) and the Directive on the Resilience of Critical Entities (CER) weren’t written to make anyone’s life harder; they were meant to force organizations that deliver services and supply chains critical to society to treat cybersecurity and resilience not as a project, but as an operational capability. In operational technology (OT), that capability is forged not on slides, but in control rooms, on engineering workstations, in controlled data flows between zones, and in how the Chief Information Security Officer (CISO), maintenance, and technology vendors work together.

So, this piece is told from the plant’s perspective. It shows how to translate the language of NIS2 and CER into the cadence of changes, maintenance windows, and upkeep plans; what “24/72-hour reporting” looks like in practice; and why the single most valuable investment is often patiently mapping flows between zones. The Cyber Resilience Act (CRA) appears only if you’re also a manufacturer of devices or software with digital elements.

Where NIS2 and CER Meet Shop-Floor Reality

On paper, you could say NIS2 regulates cyber risk management, oversight, and incident reporting, while CER addresses “all-hazards” resilience of critical entities—from accidents to deliberate acts. In reality, inside a factory, those worlds meet at one chokepoint: the conduit between information technology (IT) and OT. That’s where telemetry flows to Manufacturing Execution Systems (MES), where work orders return from Enterprise Resource Planning (ERP) and sometimes discovered only in a crisis where unauthorized service traffic sneaks in. Plant leadership quickly realizes that “meeting requirements” isn’t a one-off checklist. It’s a work cycle. We identify assets and connections, ratchet down trust at the IT/OT seam, rehearse response, and then measure whether we can restore control and production in an acceptable time. Only when defined this way does the daily grind start building the resilience NIS2 and CER, for critical entities, are after and only then are we talking seriously about risk rather than “ticking boxes.”

Governance That Works: People, Ownership, Cadence

There is no resilience without owners. In practice, it begins with a simple but essential division of roles. The board confirms risk appetite and the metrics it expects (for example, target times to restore control after an incident). The CISO owns policies and oversight—and, crucially, ensures cyber processes are anchored in the plant’s rhythm, not just in the office. The Chief Operating Officer (COO) or plant manager is accountable for enforcing controls, planning maintenance windows, and making sure security doesn’t crush productivity. The OT lead takes custody of zones and conduits per International Electrotechnical Commission (IEC) 62443: they know which segments are critical, which flows the process truly needs, and which can be blocked without pain.

This structure only works with a regular cadence: monthly reviews of changes and incidents with the shop floor and the Operational Technology Security Operations Center (OT-SOC), quarterly meetings of the resilience committee, and an annual deep-dive on major risks with the board. In those intervals we discuss what went well in the last tabletop, what needs fixing in the runbooks, and where to invest next: a bastion, micro-segmentation, or replacing obsolete gateways.

An OT Incident: Minute by Minute

Picture Monday, 09:12. The SOC (security Operations Center) lights up: an unusual sequence of commands at one station on the line, doesn’t look like a normal operator mistake. Two minutes later, the analyst correlates it with a spike in quality defects reported to MES. Triage is not academic; it’s about answering three questions fast. Does this affect the safety of people or the environment? Can it spread to other zones (based on Purdue Model)? Does it threaten production?

If the answer is “yes,” the plant’s 24/72/30 playbook kicks in. That is a living document, not a PDF in a cabinet. Someone flips the conduit’s policy to “essential protocols only,” someone else preserves evidence: images of engineering stations, Programmable Logic Controller (PLC) configuration snapshots, hashes, and chain of custody so facts won’t be disputed later. Within hours, an early warning is drafted for the competent authority; within the next hours, a concise 72-hour notification goes out. The most important work happens in parallel: regaining control and returning the process to nominal parameters. The team that wins is the one not improvising rollback configurations are ready and recovery paths are already tested.

Only once the line stabilizes does the team gather to write down lessons. They almost always concern simple things: “we were missing an allow-list for these flows,” “it wasn’t clear who approves changes in the maintenance window,” “these operator commands weren’t captured by the bastion.” Over months, this cadence shortens incidents and makes decisions faster and calmer.

Supply Chain: The Longest Risk Lever

In many plants, the first material incident doesn’t come through the front door. It arrives through the vendor’s remote service or via a library an integrator bundled into firmware. That’s why an OT resilience program needs room for two areas: component transparency and vendor access control. Transparency starts with a software bill of materials (SBOM) and Vulnerability Exploitability eXchange (VEX), which states whether a product is truly exploitable in a given context. This isn’t paperwork; it’s how, when a new Common Vulnerabilities and Exposures (CVE) entry drops, you know if it affects your controller, how it could be exploited in your topology, and when you must patch versus when compensating controls will do. In mature teams, SBOMs don’t sit in drawers they feed a system that correlates them with vulnerability catalogs and with the profile of your OT zones.

Vendor access control is the second pillar. The simplest, most effective change is placing a single bastion/Privileged Access Management (PAM) in front of every “little tunnel” for remote service and enforcing just-in-time (JIT) and just-enough-access (JEA): access only when there is a need, and only as much privilege as needed. Add multi-factor authentication (MFA), mutual Transport Layer Security (mTLS) on both ends, and session recording. Suddenly those “temporary” accounts with multi-year lifespans make no sense, and the team has eyes and ears on what’s happening. What looks beautiful in a policy is cemented by the contract. When you buy a service or equipment, you explicitly require SBOM/VEX, service only through the bastion, key rotation, and service-level agreements (SLAs) for vulnerability response. Not to argue with vendors, but so in the moment of truth both sides aren’t debating basics.

Patching in OT: A Decision, Not a Reflex

In information technology (IT) we automate patches almost by default. In OT, simplification can be dangerous. Vulnerability management in control environments is a multi-stop process. First asset: criticality. The same CVE has very different meaning in an isolated test zone versus on a controller that directly affects safety or the environment. Next exploitability: is there a working exploit in the wild? Is there a pathway in our actual topology, or is it mostly theoretical? Then compensating controls: what can we do right now to enforce least privilege, narrow protocols, and raise detection fidelity before we step into a maintenance window? The key that resolves most arguments is a digital twin or sandbox. In a separate environment we test the update to ensure it doesn’t break the process, we prepare a rollback plan, and only then schedule the window. We record, in one sentence, who made the decision, on what basis, and when we’ll revisit it if we chose deferral. That humble page the “CVE decision record” is an auditor’s best friend and a gift to your future self.

Exercises That Leave a Mark on the Process

A tabletop can be a great experience but only if it ends with a concrete change in how you operate. In practice we plan two kinds of exercises. The first governance and communications involve leadership, environment, health, and safety (EHS), and maintenance, and simulates a material incident: can we make decisions quickly, who talks to the authority and the media, and can we describe service impact in language non-specialists understand? The second technical drills test whether our tools see what they should and whether isolation between zones stands up to pressure. In both cases the most important part is the learning loop. Each exercise ends with a short punch list: add the missing step to the runbook, clarify responsibility in Responsible, Accountable, Consulted, and Informed (RACI), tighten a conduit policy, earmark budget for the missing bastion. That’s how resilience is built; small, unglamorous moves, day after day.

How to “Translate” Law into Standards and Evidence

Many readers ask: “this all sounds sensible but how do we prove it to a regulator?” The most practical answer is a simple matrix. Column one: the NIS2 or CER requirement (for example, incident reporting, risk management, supply chain resilience). Column two: the matching controls from IEC 62443 (for example, SR 1.x for identity, SR 3.x for integrity) and International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) 27001 (organizational controls, suppliers, incidents). Column three: the artifact a runbook, a bastion log, an exercise report, a patching decision record. Column four: the owner and review cadence. It’s not about bureaucracy; it’s about having everything at hand when questions come. CER often absent from strictly cyber conversations adds a valuable continuity and physical security perspective. When you bring EHS and operational resilience teams into the rhythm, decisions become faster and smarter: when to stop a line, how long to run in degraded mode, when to call the crisis team.

How to Measure It so Leadership Sees Progress

Every program fails if it can’t show meaningful numbers. Good OT metrics don’t count “how many alerts,” but how much time we need to regain control and production and how often we manage to contain issues without shutting the line down. The leadership dashboard should track:

• Mean Time to Detect/Mean Time to Restore in OT (MTTD/MTTR-OT) — Time to detect and restore control/production (and what that does to OEE)
• Segmentation Coverage — The share of zones with enforced allow-lists for flows
• Inventory Completeness — The share of OT assets with criticality and an owner
• Supply Chain Discipline — Suppliers that passed due diligence; vendor sessions going only through the bastion/Privileged Access Management (PAM)
• Reporting Discipline — How we perform against 24/72/30 in real events
• Vulnerability Backlog in Zones — Counts at >30/60/90 days and the compensations in place

Over time the charts start telling a story: unauthorized flows trend down, time-to-restore shrinks, and teams keep feeding runbooks with proven fixes. That’s the language to use with the board.

Cyber Resilience Act (CRA)

If your role goes beyond operations and you also build devices or software with digital elements, the Cyber Resilience Act (CRA) enters the picture. It’s a different rhythm: security from design, SBOM treated as a product artifact, a secure update channel as a first-class architectural element, and a defined process for receiving and communicating vulnerability information. This matters because increasingly the same team supports its devices in customers’ plants and CRA is a chance to put that on a transparent, repeatable footing. If you’re not a manufacturer, focus on NIS2 and CER just make sure your suppliers take CRA seriously.

Two Short Stories from the Field – Energy: Remote Service Under Control

At a distribution operator, the biggest pain was “exception” connections to Supervisory Control and Data Acquisition (SCADA) and PLCs each a bit different, each justified, collectively forming a murky web where it was hard to say who did what and when. After deploying a bastion with JIT/JEA, session recording, and mTLS on both ends and adding contract clauses for SBOM/VEX, maintenance windows, and key rotation the world calmed down. Inspections took less time, undocumented sessions disappeared, and regulatory notifications met deadlines without nervous arguments about facts because the facts were on tape.

Fast-moving consumer goods (FMCG): a patch without downtime

In a beverage plant a critical vulnerability hit controllers on a high-speed line no one wanted to stop before the weekend. The team analyzed context: segmentation was solid, the attack path constrained. Instead of rushing into installation, they first deployed compensations: default-deny, disabling unused functions, stronger protocol monitoring. In parallel they built a “mini twin” of that part of the line and tested the patch with a rollback plan. Eight weeks later the update landed in a maintenance window with no OEE loss. Unauthorized flows dropped on the trend, and the patching runbook gained a new, proven branch.

What to Take Away from This Story

First, resilience is a cadence, not a project. NIS2 and CER give language and guardrails, but the “day-to-day” is built on reviews, drills, and small improvements. Second, the supply chain, SBOM/VEX and vendor access control is the longest risk lever in OT. Third, patching is a decision measured by its impact on safety and production, not by the mere availability of a fix. And finally: measure what matters. Don’t count alerts measure time to restore control, the share of zones with enforced segmentation, reporting discipline, and real progress on closing vulnerabilities. If after reading you spend an hour with the maintenance lead and the OT lead to outline the three first steps zone owners, the bastion plan, and the first tabletop, then NIS2 and CER are starting to live in your plant. And that’s what this whole “compliance” journey was for in the first place.