Multi-factor authentication proves the login, not the breaker

An engineer authenticates with multi-factor into an intermediate system and holds the session for four hours. Every control action in that window inherits the strength of one authentication event that happened before the operator knew what they were going to do.

Part of Grid, water and OT identity

Five layers, and where identity disappears

Map the control path from an engineer's laptop to a field device and mark, at each layer, whether a principal identity exists.

The decay is not an implementation failure. Industrial protocols were specified for deterministic machine-to-machine communication on physically isolated networks, where the question who is issuing this command had an obvious physical answer. DNP3 Secure Authentication exists and addresses message integrity between devices; it does not carry a human principal.

The quantity to measure

Session-level authentication is adequate when a session contains one consequential operation. It degrades linearly as that number rises. So the variable worth instrumenting is consequential operations per remote session.

1. Export remote session records for one quarter: user, start, end.
2. Export control system change logs for the same period: setpoint writes, configuration changes, firmware actions, forced points.
3. Join on time window and user. Count operations per session.
4. Report the distribution. The tail — sessions with twenty or more operations — is where your exposure concentrates.

In most utilities the median is low and the tail is long, driven by commissioning work and vendor maintenance windows. That shape is useful: it means a per-operation control can be scoped to the tail without touching routine operations.

What the 2026 incidents demonstrated about this gap

The water sector campaign of July 2026 is the clearest available illustration. Actors reached devices and issued administrative commands. No authentication boundary existed between reaching the device and commanding it, because the protocol layer has no principal and the device's own credential check was the only gate.

Every MFA deployment in the sector would have been irrelevant to those events, because no interactive remote access session was involved in the way the standard contemplates. That is not an argument against MFA. It is an argument about where MFA's protection ends.

A safeguard that protects the corridor cannot protect a room that has another door.

Carrying a principal to the last enforceable layer

You cannot add a principal field to DNP3. What you can do is carry a signed authorisation alongside the operation, and enforce it at the last layer that is capable of enforcement — which in most architectures is the gateway, the historian-adjacent control server, or a modern controller with signed command support.

The statement is small and human-readable, because the point is that a human confirmed something specific:

{
  "type": "manav-stmt/1",
  "action": "setpoint_change",
  "render": [
    "Device: [substation] / [device id]",
    "Point: [tag name] — [description]",
    "From: [current value]  To: [proposed value]",
    "Work order: [id]  Window: [start]–[end]"
  ],
  "operator": "[credential assertion, UV required]"
}

Verification is local and offline. Latency budget for the check is well under a tenth of a second, which is not the binding constraint; the binding constraint is the human gesture, and that is why this applies to a scoped set of operations rather than to everything.

Scoping without breaking operations

Three rules of thumb that survive contact with a control room:

• Never gate anything on the automatic control path. If a protection scheme or an automated response needs to act, it acts.
• Gate configuration and setpoint changes made by humans, not values written by control logic.
• Gate firmware and logic downloads without exception. These are the operations whose consequences persist after the session ends.

The third category is small, infrequent, and disproportionately consequential — which makes it the correct first deployment.

What this is not

It is not a replacement for segmentation, which remains the primary control. It is not protocol security — it does nothing about message integrity on the wire. And it does not prevent an authorised engineer from making a bad change, which is a training and change-management problem.

It answers one question that currently has no answer at the layer where it matters: which named human authorised this specific operation on this specific device.

Why the protocols carry no principal

They were designed for deterministic control over serial links between trusted devices in a physically secured plant. Identity was a property of the wire. Everything since has layered networks and remote access on top of that assumption without revisiting it.

Objections and honest limits

“MFA is still the right priority.” It is, and nothing here argues against it. It closes remote access, which is the largest opening. It cannot reach the protocol layer, and saying so is not a criticism of the recommendation.

“Protocol changes are decades away.” They are. The practical route is a gateway that requires a signed authorisation for defined commands and translates verified intent into the protocol, rather than waiting for the protocol to grow a principal field.

Extending attribution to the device

1. Identify the command set that matters. Breaker operations, setpoint changes, protection settings. A short list.
2. Put a gateway in front of it. Which verifies a signed authorisation before translating.
3. Bind the command, not the session. So one authorisation authorises one command.
4. Log the receipt at the gateway. Where attribution still exists.

Terms used here

Interactive remote access

A human-initiated remote session into an OT environment, the target of the MFA recommendation.

Principal

The identity on whose behalf an action is taken — a field OT protocols do not carry.

Protocol gateway

A component translating between networks, and the practical place to enforce authorisation the protocol cannot express.

Frequently asked questions

Does DNP3 Secure Authentication solve this? It addresses authentication between devices and message integrity, which is valuable and different. It does not carry a human principal, so it cannot answer which person authorised a command.

Would this add latency to control operations? Signature verification is sub-millisecond on modest hardware. The time cost is the human gesture, which is why the control is scoped to operations where a human is already deliberating.

What about automated or scheduled operations? Those run under a pre-signed authorisation with explicit bounds — device set, value ranges, time window. Anything outside the bounds requires a fresh human signature.

Is any of this required by NERC CIP? No. CIP requires MFA for interactive remote access and the ability to determine and terminate vendor sessions. Per-operation authorisation exceeds the requirement.

Is MFA the wrong priority for OT? No. It closes remote access, which is the largest opening, and it is correctly prioritised. It simply cannot reach the protocol layer.

Why do OT protocols lack a principal? They were designed for deterministic control between trusted devices in a secured plant, where identity was a property of the wire.

What is the practical fix? A gateway that verifies a signed authorisation for a defined command set before translating into the protocol.

Sources and further reading

• NERC Reliability Standards
• NERC Reliability Standards — CIP
• CISA cybersecurity advisories
• IEEE 1815 (DNP3) including Secure Authentication provisions; Modbus application protocol specification.