Last year, the CNSS breach exposed the personal and financial data of nearly two million Moroccan citizens. What struck me was that a few days after the news broke, I had received a call from a customer, a manufacturer whose SCADA system had been hit by ransomware. Production had stopped completely. When we started the investigation, we found the entry point was a simple infected USB connected to the SCADA station. No OT-specific security in place, no segmentation, no monitoring. The ransomware had moved laterally and encrypted the primary SCADA server before anyone noticed anything was wrong.
Production was down for a full day. We recovered as fast as we did only because the facility had a cold redundant system sitting unused. We switched it to master, validated the process variables and restarted the line. Without that redundancy, the stoppage would have been measured in days, not hours.
I found myself thinking that the systems we are relying on are more exposed than the people responsible for them realize.
Morocco's industrial operators, the facilities classified as Organismes d'Importance Vitale (OIVs, the Moroccan equivalent of operators of vital importance or critical infrastructure operators) running energy networks, water treatment, port logistics and chemical processing, are in the middle of a digitalization push that is accelerating faster than the security thinking around it. Most of them are now focused on a single goal: DNSSI compliance — the Directive Nationale de la Sécurité des Systèmes d'Information, Morocco's national directive on information systems security and the country's baseline cybersecurity framework for public administrations and critical infrastructure operators. Get the auditors in, satisfy the checklist, file the report.
I understand why. It is a legal obligation, it creates accountability and it is a genuine starting point. But having worked with industrial systems across Morocco, I keep returning to the same uncomfortable observation. The manufacturer who called me had no security framework at all. Some of the compliant facilities I visit have the appearance of security. In practical terms, the distance between those two situations is smaller than anyone involved wants to admit.
That gap is what this article is about.
What DNSSI was built to do, and where it stops
Morocco's OIVs are currently under real regulatory pressure to achieve DNSSI compliance, and that pressure is not misplaced. Since its first publication in 2014, updated under Law №05–20 and its implementing decree in 2021, the DNSSI has created a genuine national baseline. It gives every Moroccan institution, from a public administration to a critical infrastructure operator, a common language for cybersecurity governance.
Asset inventory, access management, incident response, audit obligations: these are not trivial requirements and implementing them seriously represents a real improvement over nothing.
But the DNSSI was designed to govern information systems broadly. It speaks the language of data: confidentiality, integrity, availability. That language is appropriate for a ministry managing citizen records or a bank protecting financial transactions. It is not the native language of a control system managing a high-pressure industrial process.
In OT security, the priority order is completely different from IT. Safety comes first, then availability, then integrity and only then confidentiality. A PASSI auditor (PASSI being Morocco's accredited audit framework for information systems security service providers) checking DNSSI compliance will verify that your patch management policy exists, that your asset inventory is maintained, that your access controls are documented. These are legitimate checks. But that same auditor will not have the operational expertise to reason about what it actually means to protect a legacy PLC that has been running a critical process continuously for a decade, and this is where the gap between compliance and resilience begins to open.
When the patch cannot be applied
The most ordinary cybersecurity control in existence is patch management. Every framework mandates it, every audit checklist includes it and in an IT environment applying a patch is almost routine.
Now bring that same control to the shop floor.
Your SCADA system is managing a continuous process. The vendor releases a critical security patch. Your PASSI auditor marks it overdue. On paper the path is clear. But in the field, a proper patch deployment on a live OT system requires a controlled shutdown sequence, functional validation of every connected process variable and a restart procedure that for a continuous production process can mean four to eight hours of lost production. That is not just the cost of those hours. It collapses your Overall Equipment Effectiveness (OEE) for the week. OEE is a multiplier and every lost percentage point echoes forward through delivery commitments, energy contracts and maintenance schedules.
So the operations manager makes the only rational decision available to him: the patch waits for the next maintenance window. The maintenance window gets consumed by a mechanical overhaul. The vulnerability ages. The compliance report stays green.
What the compliance report cannot capture is what happens if someone exploits that vulnerability. An attacker who reaches an unpatched controller managing a high-pressure loop does not need to steal data. They can manipulate a setpoint, suppress an alarm, force a valve closed when the process expects it open. The result is not a breach notification. It is an overpressure event. A thermal runaway. A fire. In the worst case, an explosion.
The DNSSI signed off on your patch management policy. It had no way to account for this chain of events. That is not the framework's failure. It is the boundary of what any compliance audit can see.
Why your asset inventory is probably wrong
Before you can patch a system, isolate it or build any control around it, you need to know it exists. In an IT environment this is tractable. In a brownfield OT facility, it is one of the hardest operational problems in industrial security, and almost nobody talks about it honestly.
The DNSSI requires an asset inventory. The PASSI auditor checks whether it exists and whether it has been recently updated. What neither the framework nor the auditor can verify is whether the inventory reflects what is actually connected to your network today.
In practice, the gap between the documented network and the real network grows continuously. A contractor adds a drive during a production expansion and connects it under a temporary address that never gets formalized. An HMI fails during a night shift and the replacement is a different model from a different vendor, but updating the asset register waits because the line needed to restart in four hours. Over years and decades, these small undocumented changes accumulate into a network that nobody has a complete picture of.
The ISA/IEC 62443 series of standards addresses this with a level of structured asset classification, firmware versions, communication protocols, physical location and zone membership that goes far beyond a simple inventory list. The reason it demands this detail is not bureaucratic. It is because you cannot define a security zone boundary without knowing precisely what is inside it, and you cannot build a compensating control strategy around an asset whose communication behavior you have never formally mapped.
Now here is the problem that every OT engineer recognizes and no compliance framework acknowledges. The standard tool for closing an inventory gap is an active network discovery scan. In IT this is routine. You send packets; devices respond; you build your picture.
On a PLC network, that same scan can stop production.
Older generation controllers have extremely limited processing capacity allocated to network communication. When such a controller receives a volume of discovery packets beyond what its communication stack expects, the watchdog timer, the internal mechanism designed to catch infinite loops and processing faults, interprets the load as a system failure. The PLC stops. Not with a warning. It stops the physical process it was controlling.
This means active discovery on a live OT network is not just ill-advised. It is a production risk. A proper active scan requires a scheduled maintenance window, full production shutdown, careful sequencing to avoid triggering fault responses in sensitive controllers and enough time to do the work safely. And it needs to be repeated regularly because the inventory drifts again the moment production resumes. The alternative is passive monitoring, listening to existing network traffic without injecting packets. This is safe for production environments. But it has a hard ceiling, and this is where the history of industrial cybersecurity becomes impossible to ignore.
Stuxnet entered through a USB drive carried by an employee into a facility with no internet connection whatsoever. Once inside, it injected malicious logic directly into legacy PLCs, commanding them to operate beyond safe limits, while simultaneously feeding every monitoring dashboard, every passive network sensor, perfectly normal readings. Operators watched all-normal values on their screens while the physical destruction was already underway. The attack operated undetected for over a year.
Passive monitoring listens to what devices report about themselves. Stuxnet taught us that a compromised device can be instructed to report exactly what you expect to hear while doing something else entirely in the physical world. Network visibility is necessary. It is not sufficient. True asset integrity requires engineers who can physically validate what is running on each controller, who understand how to safely query PLC registers during maintenance windows without triggering watchdog faults, and who can distinguish between what a device says over the network and what it is actually executing in its control logic.
Until the inventory is verified at that level, everything else, the zone architecture, the patch decisions, the access controls, rests on an assumption. And as Stuxnet demonstrated, assumptions in industrial security are where catastrophes begin.
The knowledge that does not appear on any audit report
Real industrial security does not live in a policy document. It lives in the engineer who has spent years on a specific shop floor and knows that DB10.DBX0.1 in the PLC data block is not an abstract memory address. It is the start signal for the main conveyor, and if that signal is manipulated during a specific production phase, the downstream consequence is a mechanical jam that takes three hours to clear and risks damaging capital equipment worth hundreds of thousands of dirhams.
A PASSI auditor cannot know this. An external consultant on a one-week engagement cannot know this. This knowledge belongs to the OT engineer, the automation specialist, the process safety team who have read the electrical schematics, traced the physical wiring and built over years an understanding of what each register in each PLC actually controls in the real world.
When a patch decision reaches the table, these are the people who need to be in the room. Not as an afterthought after IT has already designed the security architecture, but as the primary voice defining what a real threat to this specific process looks like and what the physical consequence of exploitation would actually be. The question is not just whether the patch should be applied. It is what the vulnerability allows an attacker to do in the context of this process, what the realistic path to exploitation looks like given the actual network architecture and if the patch cannot be applied now, what compensating controls reduce the risk to an acceptable level in the meantime.
Managing what cannot be fixed
Some systems simply cannot be patched. A PLC on an obsolete operating system, from a vendor who no longer certifies updates, running a process line that has operated continuously for 15 years: this is not an edge case in Morocco's industrial landscape. It is a significant portion of the operational infrastructure across energy, water, chemicals and manufacturing. Replacing it requires a capital project with an 18-month planning horizon.
A compliance audit marks it as a finding and moves on. A genuine security practice asks what can be done about it right now. The first answer is containment. A system that cannot be hardened from the inside can be isolated from the outside. Place it in a dedicated network zone, define precisely which systems it needs to communicate with for legitimate operational purposes, whitelist only those communication paths and block everything else. An attacker who cannot reach the controller cannot exploit it. This requires someone who understands both the network architecture and the physical process well enough to define those boundaries without disrupting production.
The second answer is application whitelisting. On a system that cannot receive OS updates, whitelisting prevents any unauthorized executable from running even if a payload reaches the machine. This directly addresses the entry vector that both the manufacturer who called me and Stuxnet relied upon, preventing unauthorized code from executing regardless of how it arrived.
The third answer is layered monitoring that goes beyond the network. Network behavioral monitoring is necessary but insufficient on its own. Correlating network behavior with physical process data, comparing what the controller reports against what sensors and actuators in the physical process are actually measuring, is what catches the attack that has been designed to look normal on every dashboard. A controller running a process outside safe parameters will betray itself in physical measurements even when its network traffic is clean.
The fourth answer is physical discipline. Stuxnet entered through a USB drive. The ransomware that stopped my customer's production line entered through an infected laptop. Locked enclosures, port blocking, strict removable media policies and rigorous access logging for anyone who physically touches a controller are not sophisticated measures. They close the exact vector that has been used in two of the most instructive industrial security incidents I can point to, one from a textbook and one from a Tuesday morning phone call.
The decision that only leadership can make
The CNSS breach revealed a pattern that goes beyond technical controls. Security implemented in fragments, without executive ownership, without the cross-functional governance that turns individual controls into an actual defense posture.
For an OIV, DNSSI compliance can be achieved by a security team working in a silo. The auditors come in, the documentation is reviewed, the certificate is issued. The plant director may never be part of that process in any meaningful way. The operations manager who knows the production cost of a four-hour shutdown for patching is also absent from that conversation. The result is a set of controls that satisfy the audit and miss the operational reality they were meant to address.
Cyber resilience for an industrial facility requires these conversations to happen together. The decision about whether to patch a controller, defer it or implement compensating controls around it is not a security decision alone. It is simultaneously a production decision, a safety decision and a financial decision. It needs to be owned at a level where all of those dimensions are visible.
No framework mandates that. It requires an executive team that has genuinely understood that an unprotected industrial control system is not a compliance gap to be managed. It is a safety risk to be owned.
Where to go from here
The DNSSI is the starting line. For OIVs operating industrial infrastructure, it is also the beginning of a more demanding conversation about what security actually requires at the operational level.
The DNSSI explicitly acknowledges that its minimum rules can be enriched for specific operational contexts. For industrial operators, that enrichment means building a real asset inventory verified at the physical layer, not just documented on paper. It means patch governance that brings operations and safety into the room alongside security. It means compensating control strategies for legacy assets that treat network isolation, application whitelisting and physical process monitoring as a coherent defense posture rather than individual checkboxes. And it means executive ownership of the risk decisions that no auditor and no framework can make on your behalf.
The manufacturer who called me on that Saturday morning had no framework and no redundancy strategy beyond the cold backup that saved them. They were lucky. The next time they may not have a redundant system to switch to, and the production stoppage will not be measured in one day.
Stuxnet answered the question of what a targeted attack on a legacy PLC looks like 15 years ago. The same controller is still running in Moroccan factories today. The same USB vector it used is what stopped my customer's production line earlier this year. Compliance tells you where the floor is. What you build above it is the only thing that actually matters.
The opinions and views expressed are solely those of the author and do not necessarily reflect any official policy, position or views of the International Society of Automation (ISA), Automation.com or the ISA Global Cybersecurity Alliance (ISAGCA).
