Drawing the Conduit

The previous post ended with a question: is the vendor engineer’s laptop in its own zone, what conduit does it traverse, and what gets logged when it does?

That question sounds rhetorical until you actually try to answer it. To answer it properly, you need two standards — one for drawing the boundaries, one for filling them in — and a regulatory framework that gives teeth to both. This post covers all three.

What replaces an air gap

The standard that replaces the air gap as the unit of security architecture is IEC 62443, and specifically 62443-3-2 — Security risk assessment for system design. The 3-2 workflow is eight steps. Six of them are about identifying boundaries:

Define the system under consideration.
High-level risk assessment.
Partition into zones and conduits.
Detailed risk assessment per zone and per conduit.
Set a Target Security Level (SL-T) per zone and per conduit.
Compare SL-T against the SL-Capability of available products.
Specify compensating controls.
Document.

A zone is a set of assets that share the same security requirement. A conduit is the communication path between two zones. The protection IEDs and merging units on a substation process bus are one zone. The station-level historian and gateway are another. The substation-to-control-centre WAN is the conduit between them.

The interesting move in the 62443 architecture is that zones don’t have to map to physical boundaries any more. A zone can be “the set of VMs that run protection logic on this hypervisor cluster”, enforced by an NSX distributed firewall rule on the vNIC, regardless of which host the VM happens to be running on. The boundary moves from being a wall to being a contract — the SL-T contract on the conduit, the SL-Achieved measurement of what’s actually delivered, and the audit trail that shows the gap.

This is genuinely better than what came before, for two reasons. First, it’s enforceable in software, which means it survives the contractor with the USB stick, the vendor with the support tunnel, and the next architectural shift after that. Second, it’s explicit. There is no part of the 62443 workflow that allows you to write “air-gapped” in a checkbox and stop thinking. You write down the zones, you write down the conduits, you write down what flows through each one, and you justify the SL you chose. If you want a high-trust zone, you have to engineer it. If you want plaintext IEC 60870-5-104 between two zones, you have to write down what compensating controls make that defensible.

It’s more work. The work is the point.

IEC 62443 also scores everything against four Security Levels: SL 1 covers operator typos and accidents; SL 2 the script-kiddie; SL 3 the organised crime group with OT skills; SL 4 the nation-state actor. The bit worth knowing is that 62443 quietly defines three flavours of SL — SL-T (target, what you need), SL-C (capability, what the product can do), SL-A (achieved, what’s actually delivered after integration).

The SL score is a vector across seven Foundational Requirements — the capabilities 62443 expects every zone and conduit to address:

FR1 — Identification and Authentication Control. Every user, device, and software process must prove who it is before it acts.
FR2 — Use Control. Once authenticated, the system enforces what that identity is allowed to do — role-based privileges, not blanket access.
FR3 — System Integrity. The system detects and resists unauthorised modification — firmware, configuration, data in transit.
FR4 — Data Confidentiality. Sensitive information is protected against disclosure, whether at rest, in transit, or in use.
FR5 — Restricted Data Flow. Communication paths are segmented so that data only flows where the design says it should — the conduit enforcement requirement.
FR6 — Timely Response to Events. The system logs security-relevant events and supports timely detection and response — the monitoring and alerting requirement.
FR7 — Resource Availability. The system resists denial-of-service conditions and maintains availability of critical functions under attack.

These seven recur throughout the rest of this series. When the next post maps a product capability to “FR5”, it means the capability is closing the Restricted Data Flow requirement for a specific conduit at a specific SL.

Vendors love advertising “our IED is SL 3”. What they almost always mean is SL-C 3 in some of those seven FRs — and what they typically have not done is the third-party 62443-4-2 component certification that would actually evidence the claim. At the time of writing, no major protection-relay vendor — SEL, Siemens, GE, Hitachi Energy — appears on the ISASecure CSA certified-components register. Read into that what you will.

The substation on the wall

I spent a week sketching out what IEC 62443-3-2 looks like when you apply it to a real-shaped substation — not a textbook diagram with three boxes and two arrows, but the kind of composite 275 kV transmission site you’d find on the UK grid, with a virtualised control centre tens of miles away. The composite is assembled from vendor whitepapers, conference talks, and the public technical literature rather than a single real site, but the choices in it are the ones that keep coming up.

What I found is that the hard part isn’t drawing the zones. The hard part is drawing the conduit — the thing between the zones — and making it mean something beyond a line on a diagram.

The site: two transformers, four 275 kV bays, a process bus running Sampled Values and trip GOOSE under PRP redundancy, ten or so protection IEDs, two merging units per bay, a PTP grandmaster for time sync, and a station gateway.

Northbound, DNP3 over the operator’s telecoms network — fibre running inside the OPGW earth wire on the pylon route — to a regional control centre. The control centre runs a virtualised RTU on a vSphere cluster that also hosts the ADMS front-end, with an EMS on bare metal in the same data hall. The same control centre serves hundreds of substations across the region — a fact that becomes important shortly.

The system under consideration runs from the merging units up to and including the ADMS application. Corporate IT, billing, the customer portal — out of scope. The operational telecoms transport layer below the IP service — out of scope (though operator-owned, which matters for the trust model). Active Directory, the SOC, the SIEM — in scope as supporting infrastructure but not part of the core design.

The threat model is the one every UK transmission site lands on eventually: the credible worst case is a state-sponsored ICS-capable actor, not just a misconfigured firewall. The assets at risk are the trip-circuit integrity of the protection scheme (catastrophic if compromised — wrong-trip damages transformers and de-stabilises the grid), the availability of the SCADA telemetry (operators run blind if denied), and the confidentiality of the operational data (useful for an attacker preparing a follow-up but not directly damaging). That puts you in SL-3 territory for the critical zones, SL-2 elsewhere.

Eight zones, eight conduits, one diagram

A zone is a set of assets that share the same security requirement — not “are on the same VLAN” but “would a reasonable adversary treat these as equivalent targets, and would equivalent controls defend them”. For a site like this, eight zones fall out:

Z-PROC — Process bus. Merging units and protection IEDs exchanging Sampled Values and GOOSE under PRP. Trip-time-budgeted. Sub-millisecond. Touch nothing in here that adds latency.
Z-STN — Station bus. Station gateway, local HMI, IED engineering interfaces, PTP time source. Talks MMS to the IEDs, DNP3 northbound.
Z-WAN — The operational telecoms circuit between substation and control centre. Carries DNP3. In this case, operator-owned fibre over OPGW — physically secure, but the zone still exists as a documented trust boundary because the transport crosses open country and terminates at equipment outside the substation perimeter. Other operators — particularly distribution companies or utilities in other countries — may use leased MPLS or carrier Ethernet here instead, which shifts the trust model further toward “private but not owned”.
Z-RTU — Virtualised RTU VMs in the control-centre vSphere cluster. Just the VMs and their vNICs.
Z-OPS — ADMS application servers, also virtualised, same cluster. Different zone because the security requirement is different — this is where the operator HMI lives.
Z-EMS — Bare-metal EMS in the same data hall. Different zone because of the bare-metal/virtualised split and because EMS has wider visibility across the transmission network.
Z-EW — Engineering workstations. Vendor laptops, SCL configuration tools. The most volatile zone — population changes weekly.
Z-IDMZ — Industrial DMZ. Historian replicas, jump hosts, file-transfer relays.

Two of those — Z-WAN and Z-IDMZ — exist only to anchor security controls; they don’t contain assets in the usual sense. A zone whose job is to be a documented boundary is still a useful zone.

The conduits are the communication paths between them:

C-PROC-STN: process bus ↔ station bus (MMS over the station LAN)
C-STN-WAN: station gateway ↔ WAN edge
C-WAN-RTU: WAN edge ↔ virtualised RTU (this is the one we’ll zoom into)
C-RTU-OPS: virtualised RTU ↔ ADMS (intra-cluster)
C-OPS-EMS: ADMS ↔ EMS (intra-data-hall)
C-EW-STN: engineering workstation ↔ station bus
C-OPS-IDMZ: ADMS ↔ historian in the DMZ
C-IDMZ-IT: DMZ ↔ corporate IT (the IT side is out of scope, but the conduit is in)

Eight zones, eight conduits, one diagram you could put on a wall. Drawing it took an afternoon. Making any of it real takes considerably longer.

The blast radius nobody drew

Here’s the thing the standard doesn’t quite force you to think about: when you virtualise the RTUs and put them in a control-centre cluster instead of leaving them at the substation edge, you change the unit of failure.

A substation has a blast radius the size of one substation. A control-centre cluster running virtualised RTUs for hundreds of substations has a blast radius the size of all of them. That’s not the kind of risk 62443’s per-zone SL-T calculations are designed to capture. The standard doesn’t have a column called what if you lose the whole data hall. It has columns for FR3 integrity and FR4 confidentiality, and assumes the assets in a zone are bounded.

The protection schemes inside each substation continue to operate locally — they don’t depend on the RTU, so transformers don’t blow up. But the transmission operator goes blind across the entire region the cluster serves at once. Telemetry visibility could take hours to restore; remote control could take days.

No individual SL-T = 3 zone declaration catches that. The hypervisor cluster needs to be modelled as a zone in its own right, with controls proportional to the combined impact of every RTU it hosts. Virtualisation buys DR consolidation, lifecycle simplification, faster vendor patching, and a unified operations model. It also concentrates the operational decision surface into a smaller number of physical buildings. The 62443 framework can express that concentration — but only if you remember to define the zone that captures it.

Assigning the security levels

For each zone and conduit, you assign a Target Security Level. SL-T is technically a vector across the seven Foundational Requirements, but in practice most teams collapse it to a single number and accept the loss of resolution.

Z-PROC: SL-3. Compromise here trips breakers and wrecks transformers.
Z-STN: SL-2. Compromise lets an attacker reach Z-PROC, but with another hop.
Z-WAN: SL-2. Operator-owned OPGW fibre, but the zone still warrants its own SL because the transport crosses open country and the trust boundary is worth documenting explicitly.
Z-RTU and Z-OPS: SL-3. Real-time control surfaces.
Z-EMS: SL-3. Wider blast radius than ADMS.
Z-EW: SL-2 with strong compensating controls (EDR, jump-host-only access, no direct routing to Z-PROC).
Z-IDMZ: SL-2.

Conduits inherit the higher of the two zones they connect, then get adjusted for the protocol carried. C-WAN-RTU connects SL-2/SL-3 zones, carries DNP3, and crosses an operator-owned but physically distributed network. SL-T = 2 is the typical call: below SL-3 because the WAN is private fibre not internet, above SL-1 because DNP3 has no native authentication. (For an operator using leased MPLS rather than owned OPGW, the same SL-T = 2 landing would apply but with a different justification — the circuit is private but not owned, and the compensating controls would lean harder on encryption.)

SL-2 in 62443-3-3 is the protection envelope for attackers with low resources and generic skills — the disgruntled-insider tier, not the nation-state tier. That’s the threat envelope the conduit is being designed to.

Then you compare SL-T against the SL-Capability of the products you’ve actually procured. The vendor’s RTU spec sheet might claim SL-C = 2 across all FRs except FR4 (Data Confidentiality), where it’s SL-C = 1 because the product ships DNP3 in plain-text and doesn’t support IEC 62351-5 (DNP3 Secure Authentication) without a paid add-on the buyer didn’t take. SL-C is the IEC 62443-4-2 component-level rating; in mature procurement it’s backed by an ISASecure CSA certificate rather than just a marketing claim on the data sheet.

That’s a gap. SL-T = 2 on FR4, SL-C = 1 on FR4. The options are: buy the add-on, accept the gap with documented justification, or specify compensating controls that close it. You write down which one you took and why. You sign the document. The external assessor — for a UK transmission operator, that’s whoever Ofgem’s NIS Regulations inspectorate has tasked with the audit — reads it.

This is where the standard stops being abstract and starts being a paper trail.

Three ways to close a gap

C-WAN-RTU is the conduit from the WAN edge at the substation to the virtualised RTU’s vNIC in the control-centre vSphere cluster. Source: substation gateway IP. Destination: RTU VM IP. Protocol: DNP3 (TCP/20000). SL-T: 2. Plain-text on the wire.

The FR4 gap is the interesting design question. SL-2 confidentiality is the requirement, on a conduit carrying plain-text DNP3 over a private circuit. Three ways to close it, trading off in different directions.

Option A: IEC 62351-5 (DNP3 Secure Authentication). Message-level integrity and authentication via HMAC challenge/response. Closes the gap directly. Costs: requires both ends to support it (most deployed RTUs don’t, out of the box), introduces certificate management, marginally increases packet size and processing time. Most UK operators don’t pick this option today because the substation gateways in the field are on firmware that doesn’t support 62351-5; refreshing the firmware across an estate of hundreds of sites is a separate multi-year project.

Option B: IPSec over the WAN. Tunnel the DNP3 inside an IPSec channel between the substation and the control centre. Closes the gap by treating the WAN as untrusted and encrypting at the network layer. Costs: needs an IPSec endpoint at every substation (the UK estate has hundreds), and the processing delay eats into the latency budget on time-sensitive telemetry. More compelling when the WAN is leased MPLS rather than operator-owned OPGW — if you don’t own the fibre, encrypting the transport is a stronger argument. In either case, on paper attractive; in practice often rejected on cost and operational complexity across the estate.

Option C: Compensating controls. Treat the OPGW circuit as a trusted private network (the operator owns the fibre, the earth wire, and the transport equipment — a stronger trust basis than leased MPLS, where the working assumption would be that the carrier isn’t actively hostile). Pin the conduit at both ends to known IPs, log every packet flow, and put protocol-aware monitoring in front of the DNP3 stream so any tampering would be detected even if not prevented. Doesn’t close the FR4 gap formally — but it lets you document why the residual risk is acceptable.

Option C is the choice that tends to land. The justification typically runs to about a page in the SL-T compliance document, and most external assessors accept it as a reasonable reading of the standard.

What a conduit is actually made of

Option C turns into five concrete artefacts:

NSX distributed firewall rule on the vNIC of every RTU VM. Source = the specific IP block of the substation gateway (a /29 advertised via the operational telecoms WAN). Destination = the RTU VM’s vNIC IP. Service = TCP/20000 (DNP3). Action = Allow. Logging = Enabled. Every packet flow generates a syslog event with src/dst/bytes/timestamp, forwarded to the SIEM. Default-deny on every other source/protocol pair.
Source-pinning at the substation end. The substation gateway’s static route table can only originate DNP3 to the control-centre RTU VIP. Any attempt to talk to a different destination gets dropped. Belt-and-braces — the NSX rule already enforces destination, but the source-side restriction means a compromised gateway can’t trivially pivot to other zones.
Dragos passive sensor with a SPAN port on the inbound switch at the control-centre side, parsing DNP3 in real time. Detects unauthorised function codes, abnormal point counts, replay patterns, and known indicators from the Dragos threat intelligence feed. Alert SLA: 15 minutes to SOC ticket.
TPM-attested boot on the RTU VM. The hypervisor measures the boot chain into a vTPM; the RTU VM presents its boot attestation to the management cluster on every restart; if the attestation fails, the VM doesn’t get its network interface activated. FR3 (System Integrity) closure for the endpoint.
Annual penetration test scoped to this conduit. External red team with a remit to attempt to inject a forged DNP3 control command from a position adjacent to the OPGW circuit. The test itself is part of the SL-A (Security Level Achieved) evidence base, regardless of outcome.

Five artefacts. None of them is a line on a network diagram. All of them are auditable.

The syslog entry that proves it

The final piece — the one I find most satisfying — is the proof that the conduit is working. The NSX rule logs every flow. The SIEM correlates the flows against the expected DNP3 poll cycle (one read every thirty seconds, plus occasional control commands during operator actions). If the rate falls outside expected bounds, an alert fires. If a packet matches the rule’s source/destination but presents an unexpected DNP3 function code, the Dragos sensor fires a separate alert. If the RTU VM reboots and the attestation fails, a third alert fires.

Three independent monitoring paths, three independent alerts, three independent on-call rotations. The conduit has observability built in, not bolted on.

A representative SIEM entry, redacted: a flow logged at 14:23:11 BST on a Tuesday afternoon, source 10.x.x.x:51234, destination 10.y.y.y:20000, 384 bytes, DNP3 function code 0x01 (Read), object group 30 variation 5 (Analog Input — single-precision floating point, with flag). That’s an ADMS poll for the active-power readings on the busbar. It’s expected, it matches the rule, it’s logged. If it weren’t there at 14:23:41, the next-poll alert would fire thirty seconds later.

That entry is what an SL-T = 2 conduit looks like at the moment of execution. Not the diagram. The line on the diagram is just the place the rule lives.

The materials catalogue

62443 tells you where the boundaries should go and what level of protection each one needs. It doesn’t tell you what those boundaries are made of. Asking 62443 how to authenticate your DNP3 traffic is like asking the architect’s plan how to mix the concrete: not the right document. The right document is IEC 62351 — a family of standards that bolts cryptography onto the protocols power systems already speak. It’s the materials catalogue you reach for once you’ve decided where the walls should go.

A family, not a standard

Most people who say “IEC 62351” mean one of three or four parts and don’t realise there are more. The family has grown by accretion since the early 2000s, one part at a time, as the IEC has worked through the protocols that matter for power-system operation.

The parts that come up in substation work are roughly:

62351-3 — TLS profile. Specifies which TLS versions, which cipher suites, and which certificate handling rules apply to any TCP/IP-based power-system protocol. The underlay for everything in the family that runs over TCP.
62351-4 — Security for MMS, the IEC 61850 station-bus client/server protocol. TLS underneath, ACSE-level authentication on top, with end-to-end signing of selected payload fields added in the 2018 edition.
62351-5 — Security for IEC 60870-5 and DNP3. The DNP3 Secure Authentication mechanism most people mean when they say “DNP3 SA”.
62351-6 — Security for GOOSE and Sampled Values, the layer-2 multicast protocols on the substation process bus. Embedded HMAC and signature fields inside the protocol PDU itself, because TLS isn’t usable at this latency.
62351-8 — Role-based access control for power-system applications.
62351-9 — Cryptographic key management. The operational layer that everything else assumes works.

The shape that helps me keep them straight is: protocol determines the part. If a conduit carries DNP3, you reach for 62351-5. If it carries MMS, you reach for 62351-4. If it carries GOOSE, you reach for 62351-6. The 62443 conduit is protocol-agnostic; the 62351 mechanism isn’t. That’s where most of the architect’s work happens — at the join.

62351-5: the DNP3 case

The first part of the family I learned about was 62351-5, the one that secures DNP3. It’s the textbook example of how the family works: take a 1990s-vintage protocol with no security at all, bolt on an HMAC-based challenge/response mechanism, and you’ve turned the plain-text payload into signed-plain-text. The wire format is the same; the integrity guarantee is new.

The interesting bit isn’t the mechanism — that’s catalogued in the reference — it’s that the deployment lag in the UK has nothing to do with the standard. The standard has been published since 2013. The reason most operators haven’t enabled it is that the substation gateways in the field are on firmware that doesn’t support it, and refreshing the gateway estate is a multi-year programme that competes with everything else for engineering time.

The interim pattern is to accept the FR4 gap with documented compensating controls — the Option C from earlier in this post. 62351-5 is what eventually replaces those controls. The five-year plan is “deploy SA across the gateway estate”. The two-year plan is “monitor and detect, accept the residual risk”.

62351-6: the GOOSE case

62351-6 sits at the other end of the protocol catalogue. Where 62351-5 is about TCP-borne control commands at human timescales, 62351-6 is about layer-2 multicast at machine timescales — securing GOOSE and Sampled Values on the process bus, where the per-frame latency budget is measured in microseconds.

You can’t bolt TLS onto that — there’s no session to handshake into. So 62351-6 puts an authentication field inside the protocol PDU itself, and the engineering trade-off becomes the choice of cryptographic primitive: an HMAC tag (cheap, but every IED on the bus needs the key), or a digital signature (heavier, but per-sender attribution).

The deployment reality on this one is rougher than for DNP3 SA. The mechanism works, but distributing keys to every IED on every process bus — see 62351-9 below — is a problem most operators are still figuring out. The interim compensating control is physical isolation: the process bus is a dedicated LAN inside the substation cabinet, and the threat model is “we trust the cabinet”. Defensible against remote attackers. Less defensible against insiders with cabinet access.

62351-4: signing the MMS session

MMS — Manufacturing Message Specification, ISO 9506 — is the application-layer protocol on the IEC 61850 station bus. It’s the wire format for read/write/control services between IEDs and station-level applications. Less time-critical than GOOSE or SV; richer than DNP3. Runs over TCP/IP.

62351-4 secures it in two layers: TLS underneath per 62351-3, plus application-layer authentication so the identity is bound to the MMS association, not just the underlying TCP socket. The 2018 edition added end-to-end signing of selected payload fields — the “E2E security” extension — so a man-in-the-middle who terminates TLS still cannot silently rewrite a control command. The signed payload would have to be re-signed by an attacker holding the right key, which they don’t.

In the UK estate today, 62351-4 deployment is patchier than 62351-5. Most station-bus traffic is still on the LAN inside the substation perimeter, and operators rely on physical isolation rather than cryptographic protection on the bus itself. That’s likely to shift as IT/OT segregation moves further from “perimeter trust” toward “zero trust at the protocol layer”, which is the direction every recent NCSC and CISA piece has been pushing.

62351-9: where the keys live

This is the part of the family that turns up least in vendor brochures and most in deployment retrospectives.

Cryptographic key management is the operational substrate that every other 62351 part assumes. 62351-5 needs update keys and session keys. 62351-6 needs HMAC keys distributed to every IED on a process bus. 62351-4 needs TLS certificates for every MMS endpoint. None of those keys provision themselves.

The standard PKI model from the IT world doesn’t transplant cleanly. IT certificates are typically valid for one to three years, renewed online via ACME or similar, with OCSP for revocation. Power-system devices have asset lifetimes of twenty to thirty years, intermittent connectivity (some sites are only reachable for engineering visits), and no realistic path to internet-based revocation services. The CA itself needs to outlive the devices, which means an institutional commitment that exceeds most procurement cycles.

62351-9 specifies the protocols and data formats — how a key request is encoded, what a certificate profile looks like, how a key revocation propagates. It does not specify who runs the CA. That’s left to the operator, and the answers in the field appear to vary:

Vendor-operated PKI tied to the device. Works out of the box, locks you to the vendor for the asset lifetime.
Utility-operated CA with offline root and online intermediates. The pattern that scales but requires a security team that can run a 20-year CA without losing the keys.
Manual provisioning at commissioning. Still common for SV and GOOSE keys that rarely change. Doesn’t survive an audit but does survive an attempted deployment.

The year-ten problem is the one nobody talks about: when the CA cert is rotated, every device needs to trust the new chain. If the device firmware can’t be updated remotely, that means a truck roll to every substation. The architecture that survives ten years of CA rotation is genuinely hard to design, and most operators in the public literature are still figuring it out.

62351-8: who’s allowed to do what

The RBAC part of the family. Defines a set of standard roles for power-system applications — VIEWER, OPERATOR, ENGINEER, INSTALLER, SECADM — and the access rights each role has to common power-system data.

The intent is to give 62443’s FR1 (Identification & Authentication Control) and FR2 (Use Control) a standardised vocabulary inside the IEC 61850 world. Rather than every vendor inventing their own permission model, 62351-8 defines a shared one.

The deployment reality is that most engineering work happens through vendor configuration tools rather than direct IED access, so RBAC enforcement often lives in the tools layer rather than the protocol layer. Centralised identity stores that the IEDs themselves can reach for authentication decisions are rarer than centralised stores for the operators using the tools. That’s a gap worth being honest about: 62351-8 defines the model; whether the IED in the cabinet actually checks role membership before honouring a write is a per-vendor question.

The protocols 62351 doesn’t cover

The family addresses the IEC and IEEE protocols the IEC has standardised — DNP3, the 60870-5 series, the 61850 stack, MMS. It does not cover everything on a substation LAN. Two gaps come up often enough to matter.

OPC UA is the protocol of choice for new-build substation gateways exposing data to historians and asset-management platforms northbound. It carries its own security stack — TLS, X.509 mutual authentication, three security modes — defined in IEC 62541, not in 62351. From a 62443 architect’s point of view, an OPC UA conduit is a 62541 problem rather than a 62351 problem. The mechanism is mature; the operational pain (certificate rotation across asset lifetimes) is the same pain 62351-9 confronts on the 61850 side.

Modbus sits at the other extreme. It has been on substation LANs since the 1980s, talking to battery monitors, HVAC controllers, auxiliary metering, and any vendor I/O module bought outside the protection scheme. It has no native security at all. The Modbus Organization published Modbus/TCP Security in 2018, but adoption is near-zero in the field and the realistic compensating control is network-layer isolation: pin each Modbus device into a zone of its own, allow-list the source IPs that are permitted to talk to it, and accept that the protocol itself remains the integrity boundary it has always been — which is to say, no boundary at all.

Both protocols are recurring sources of the we did not know that was there finding in substation pen-tests. They are out of scope for 62351 and inside the scope of 62443. Mind the gap.

What 62443 doesn’t tell you about 62351

Reading the two standards in sequence, the gap between them is striking. 62443 says “the conduit needs SL-T = 2 on FR4”. 62351 contains the parts that could close that requirement. Neither standard tells you, in so many words, which part. That’s an architect’s call, and one that has to account for:

The protocol the conduit carries (which fixes the 62351 part)
The edition of that part the available products implement (which usually doesn’t match the latest standard)
Which of the part’s optional features are actually shipped (62351 is full of optional features)
The operational cost of running the key-management substrate (62351-9) for the chosen mechanism

Vendors writing “62351-compliant” on a spec sheet without naming the parts, the editions, and the optional features are claiming something that cannot be verified. The procurement question that gets the right answer is: which parts of 62351, which editions, which conformance class, and what’s the gap to the latest published version. That spreadsheet rarely fits in a single line of a procurement document, but it’s what the SL-Capability column is actually capturing.

The Enhanced CAF: why the regulator cares about your logging

Everything above — the 62351 mechanisms, the conduit designs, the key-management substrate — is engineering. The question that turns engineering into obligation is regulatory, and in the UK the regulatory instrument is the NCSC’s Cyber Assessment Framework (CAF), enforced for energy operators by Ofgem under the NIS Regulations 2018.

The standard CAF profile defines four objectives and fourteen principles covering security governance, defence, detection, and response. Since 2023, NCSC has been rolling out an Enhanced CAF profile to the most critical CNI operators — the transmission and distribution network operators whose compromise would have national-level consequences. The enhanced profile doesn’t change the framework structure; it raises the bar on specific indicators, and the ones that bite hardest in a substation context are about logging, monitoring, and detection:

Comprehensive logging of privileged access and OT/IT boundary traffic with defined retention periods. An operator who can show centralised, correlated, retained logs across the infrastructure and OT layers is meeting the enhanced detection indicators. An operator who is scraping logs per-host with no SIEM correlation is not.
SOC-level detection capability, not just perimeter defences. The enhanced profile is asking: if an attacker is inside the perimeter, can you detect them? Microsegmentation with flow logging and OT-IDS is the architecture that answers that question.
Supply chain assurance for vendors and third-party access. The engineering-workstation zone (Z-EW) and the conduit controls on vendor access (C-EW-STN) from 62443 are the technical expression of this requirement. The enhanced profile asks operators to demonstrate that vendor access is controlled, logged, and revocable — not just trusted because the vendor has a support contract.

The Enhanced CAF is the regulatory mechanism that gives teeth to the 62443 and 62351 work. Without it, zones and conduits are an engineering best practice. With it, they are an auditable obligation. The Cyber Security and Resilience Bill, working its way through Parliament, will strengthen these requirements further by expanding the scope of regulated entities and giving Ofgem stronger enforcement powers.

The practical effect for an infrastructure architect: the logging and monitoring are not optional extras bolted on after the security design. They are the security design, as far as the regulator is concerned.

The drawing and the materials

If 62443 is the architect’s drawing — where the walls go, what they’re for, what level of protection each room needs — then 62351 is the materials specification. Steel grade, glass thickness, fastener torque. Either alone produces a building that doesn’t work. The drawing without the materials is aspirational; the materials without the drawing are a pile of stuff in a yard.

A conduit isn’t a wire. It isn’t a port. It isn’t even a firewall rule on its own. It’s a small bundle of artefacts — a documented design decision, an enforcement rule on the data path, a monitoring sensor, an alert pipeline, and a paper trail explaining why the choices were made. You can have all of that without ever drawing it on a diagram. And you can draw a beautiful diagram and have none of it.

The cryptography is solved. The protocols are specified. The integration with 62443 is sketched out. The thing that breaks the deployment isn’t ever the maths — it’s the institutional capacity to operate a power-system PKI for thirty years without losing the keys.

Drawing the conduit was the easy bit. Building what the conduit is made of is the work. The next post takes the standards off the page and maps them onto a product catalogue — how NSX overlay isolation, distributed firewall, and VCF lifecycle automation turn 62443 zones and 62351 mechanisms into operational infrastructure.

References

IEC 62443

ISA — ISA/IEC 62443 series of standards
IEC 62443-3-2:2020 — Security risk assessment for system design
IEC 62443-3-3:2013 — System security requirements and security levels
IEC 62443-4-2:2019 — Technical security requirements for IACS components
IEC Webstore — IEC 62443-3-3
Novesh — Understanding IEC 62443-3-2 zones, conduits, and risk assessments

IEC 62351 family

IEC 62351-3:2014 + AMD1:2018 — Communication network and system security — Profiles including TCP/IP
IEC 62351-4:2018 — Profiles including MMS and derivatives
IEC 62351-5:2013 — Security for IEC 60870-5 and derivatives (DNP3 SA)
IEC 62351-6:2020 — Security for IEC 61850 profiles (GOOSE & SV)
IEC 62351-8:2020 — Role-based access control for power system management
IEC 62351-9:2017 — Cyber security key management for power system equipment

Protocol security

IEEE 1815-2012 — Distributed Network Protocol (DNP3)
IEC 61850 — Communication networks and systems for power utility automation
ISO 9506 — Manufacturing Message Specification (MMS)
DNP Users Group — DNP3 Secure Authentication v5/v6 specification

Regulatory

Reference architectures and guidance