The IEC 62443 Compliance Trap: Why Checking Boxes Won't Catch the Attack Your Auditor Never Saw Coming
An OT operator I spoke with recently put it plainly: “We passed our IEC 62443 audit. We’re secure.” He said it the way you’d say “the fire extinguisher passed inspection” — with the quiet confidence that the box was checked, the paperwork was filed, and the problem was handled.
But here’s the thing about audits: they measure conformance to a point-in-time snapshot. They tell you whether you had a segmentation diagram, whether your zones were documented, whether your risk assessment was current at the moment of review. They don’t tell you whether your network actually sees the Modbus write that shouldn’t exist, the firmware upload at 3 AM from an engineering workstation that never does firmware uploads, or the new device that appeared on Level 1 and started talking before anyone in the SOC knew its MAC address.
IEC 62443 is the most comprehensive framework the OT security community has — and it deserves that reputation. Parts 2-1 (security program), 3-2 (zone and conduit risk assessment), and 3-3 (system security requirements) together form a rigorous model for understanding industrial risk. But the standard itself contains a warning that many operators skip past: compliance with 62443 does not guarantee security. It provides a structure for reasoning about security — and the reasoning is the part that matters.
What IEC 62443 Actually Says About Detection
Let’s look at 62443-3-3, the system security requirements. Requirement SR 2.8 (Auditable Events) mandates that the system “provide the capability to generate audit records” for security-relevant events. SR 6.2 (Continuous Monitoring) requires the system to “monitor and detect security violations.”
These are not optional. They are foundational requirements. And they are not satisfied by a firewall log or a Windows Event Collector forwarding syslog to a SIEM that nobody checks.
What the standard is asking for — what it means when it says “continuous monitoring” and “auditable events” — is the ability to see what the network is actually doing, compare it to what it should be doing, and flag the delta. That delta is where every novel attack lives. The disgruntled engineer who knows the password. The compromised vendor laptop plugged into a Level 2 switch. The supply chain implant that speaks valid protocol but to the wrong register.
A compliance audit might check whether you have something generating logs. It won’t check whether those logs can distinguish between a legitimate firmware update and an unauthorized one using valid credentials. That’s the gap.
The Three Things Audits Don’t Test
1. Baseline integrity under a living network. Your zone diagram was accurate when you drew it — but OT networks change. Contractors plug in test equipment. New PLCs get commissioned on weekends. An IEC 62443-compliant design is static; your network is not. If your detection capability freezes the baseline along with the zone diagram, it freezes itself into irrelevance. The detection engine must keep learning — the baseline is a starting point, not a destination. We freeze the baseline, not the detection — the attack is still fully caught.
2. Novel threats that use legitimate commands. This is the category where signatures fail and checklists never look. A Modbus write to a holding register is not malicious on its face. It becomes malicious when the source shouldn’t be writing to that destination at that time of day. IEC 62443 doesn’t require you to catch that — it requires you to have monitoring. The quality of that monitoring is where security lives or dies. Signatures only catch what’s been seen before — a valid protocol operation from an unexpected source doesn’t match any signature. A behavioral engine sees a relationship that shouldn’t exist and flags it.
3. What happens below the zone boundary. IEC 62443 zones are architectural abstractions — they’re how you reason about trust boundaries. But a single zone can contain dozens of devices, and peer-to-peer traffic within a zone doesn’t cross the conduit where your monitoring sits. Unless your detection lives inside the zone — at the switch level, on the wire — you’re blind to lateral movement, reconnaissance, and the quiet enumeration that precedes every targeted OT attack. The standard expects you to monitor within zones. Most implementations don’t.
NIS2 Raises the Stakes
For operators in the EU — and increasingly, for global suppliers into European critical infrastructure — NIS2 transforms compliance from a best-practice aspiration into a legal obligation. October 2024 was the transposition deadline. Enforcement is happening now.
NIS2 Article 21 requires “appropriate and proportionate technical, operational and organisational measures” including incident handling, supply chain security, and — critically — “the ability to detect, respond to, and recover from incidents.” That word detect is not an accident. Regulators are telling operators: you must be able to see the attack. A firewall policy and an annual penetration test do not constitute detection.
IEC 62443 is explicitly referenced in NIS2 guidance as a framework operators can use to demonstrate due diligence. But the standard’s value to a regulator isn’t in the checklist — it’s in the fact that the standard demands continuous monitoring. An operator who says “we’re 62443-compliant” while running signature-only detection in a single zone is making a claim their architecture doesn’t support. And regulators are getting more sophisticated about distinguishing paperwork from capability.
What Real Detection Looks Like Under 62443
A genuinely 62443-aligned detection capability — one that satisfies the spirit of SR 6.2, not just the letter — has a few defining characteristics.
It’s passive. It doesn’t poll devices, doesn’t inject traffic, doesn’t risk disrupting the process. It listens. In an OT environment where a single malformed packet can halt production, passive monitoring is not a nice-to-have — it’s the only safe option for continuous visibility.
It’s behavioral, not signature-based. Signatures catch what’s been seen before — the known malware hash, the documented exploit pattern. But the attacks that compromise OT environments today — the Volt Typhoons, the Sandworm tradecraft, the insider with valid credentials — don’t use known malware. They use the protocol. Behavioral detection models the network’s normal communication patterns and flags deviations. A device that never talks to the engineering workstation suddenly does. A firmware transfer at an unusual time. A new MAC address answering to an existing IP. These are not signatures. They’re relationships.
It’s explainable. This is where many operators get uneasy. “Behavioral” and “machine learning” sound like black boxes. But the standard doesn’t ask for AI — it asks for monitoring. The best detection tells you not just that something is anomalous, but why: “This PLC received a stop command from an HMI that has never communicated with it in 90 days of baseline.” That’s not magic. That’s arithmetic applied to protocol metadata — here’s why we flagged this, and here’s the evidence. And it’s the kind of audit record that actually satisfies SR 2.8 — not a syslog entry that says “firewall permit,” but an event that says “this is why we flagged this, and here’s the evidence.”
The Honest Conversation
If you’re an OT operator working toward IEC 62443 alignment — and especially if NIS2 has landed on your desk — here’s what the standard is actually asking of you: build a capability to see what your network is doing, know when it deviates from normal, and have the evidence to explain why.
That’s a detection problem. It’s not solved by a stronger password policy or a better-segmented VLAN. It’s solved by continuous, passive, behavioral monitoring that lives on the wire — inside the zones, not just at the conduit boundaries — and that speaks the language of the protocols your operations depend on.
The audit is not the objective. The audit is a snapshot of a moment when someone asked whether you have the pieces in place. The question that matters — the one your network answers every second of every day — is whether those pieces actually see the attack when it comes.
Maigadi — the OT/ICS network detection & response (NDR) platform that passively learns your network’s normal and detects the novel, signature-less attacks others miss. On-premise. Explainable. Sovereign by design.