MFA for OT. The VPN is not where it belongs.
Most industrial sites put multi-factor authentication on the VPN, then trust everything that comes out of the tunnel. This is where MFA actually belongs on an OT network, and what to do about the controllers that cannot authenticate at all.
Last updated:
MFA for OT means proving who a person is at the point where they reach a machine, not at the edge of the network.
The usual tools stop short of that point: a VPN with MFA authenticates the tunnel once and then passes traffic with no identity, and a jump server narrows the path but still logs in with a shared account at the far end. The controllers cannot help either, because a PLC or an HMI has no concept of a user and its firmware will never gain one.
So the working form of MFA in an industrial network is a checkpoint in front of the equipment that:
- Authenticates the human
- Opens a single session to a single asset
- Keeps a record of what was done
Same acronym, three very different guarantees.
Every remote access design puts MFA somewhere. The question is what the second factor actually proves once the session is open, and how much of the plant is reachable after it.
At the VPN concentrator
The user proves identity once, then receives a route. What the second factor bought you is a trusted network position, not a trusted action. After the handshake the session is ordinary IP traffic, and the PLC at the other end cannot tell it from any other packet.
Proves: this person opened a tunnel.
At the jump server
The user authenticates to an intermediate host and works from there. The blast radius is smaller and there is a place to record the session. But the hop from jump server to equipment is usually a shared local account, so the identity stops at the jump server.
Proves: this person reached the jump server.
In front of the asset
A proxy terminates the session, authenticates the human against your directory with a second factor, and opens one connection to one machine for one task. The identity is attached to the action, and the record names a person rather than a service account.
Proves: this person did this, to this machine, at this time.
The tunnel authenticates once. The plant stays open all session.
A VPN is a routing decision dressed as a security control. It answers one question at connect time, is this credential valid, and then spends the rest of the session answering a different question, can this packet reach that subnet. MFA improves the first answer and changes nothing about the second.
That gap is what incident reports keep describing. An engineering laptop with a valid certificate, a contractor account that was never disabled, a vendor appliance with a second uplink: in each case the credential was real and the second factor, where it existed, was satisfied. What went wrong afterwards was reachability, not authentication.
The practical consequence for an OT network is that VPN MFA cannot answer the questions an auditor asks. Which named person changed that setpoint. Which of the four people sharing the maintenance login opened that session. Whether the integrator who was in on Tuesday could also have reached the safety system. A tunnel has no opinion on any of these.
One hop is better than a route. It is still not an identity.
The terms get used interchangeably and the distinction is mostly one of exposure. A bastion host is a hardened machine deliberately exposed to an untrusted network, built to survive being attacked. A jump server is an intermediary you pass through to reach a different security zone. In practice most industrial sites run one box that is both, and call it either.
Either way it is a real improvement on a flat VPN route: one place to apply MFA, one place to watch, one place to patch. The limitation is what happens on the second hop. The jump server logs in to the HMI with a local account that predates the person using it, so the audit trail ends at the jump box and the equipment sees a login it cannot attribute.
| VPN route | Jump server | Proxy in front of the asset | |
|---|---|---|---|
| MFA is possible | Yes, at connect time | Yes, at the host | Yes, per session |
| Reach after authentication | The whole subnet | Whatever the host can reach | One asset, one protocol |
| Identity at the equipment | None | Shared local account | The named person |
| Record of what was done | Connection logs | Host logs, if enabled | Session recording per asset |
| Revoking one contractor | Disable the account, hope | Disable the account | Ends the session in progress |
| Works with equipment that cannot authenticate | Not applicable | No | Yes, the proxy authenticates instead |
Four cases where the endpoint will never hold up its end.
MFA assumes an endpoint that can challenge a user. Most of an industrial estate cannot, and no firmware update is coming. These are the four shapes the problem takes, and in each the answer is the same: move the check off the device and put it on the path.
The PLC with no user model
A controller has a protocol, not a login. Modbus and S7 execute whatever arrives at the port from whoever sends it. There is no account to attach a second factor to, so authentication has to happen before the packet is allowed to exist.
The HMI on an unsupported OS
A panel running Windows XP or 7 cannot take a modern authenticator, and the vendor support contract usually forbids touching it. The screen is also frequently shared by a shift, so even a password identifies a role rather than a person.
The service account
Historians, SCADA polling services and integration jobs authenticate as machines, continuously, with no human to present a token. They cannot be given MFA in the usual sense, so the control is to bind the account to one source, one destination and one protocol, and alert on anything else.
The air-gapped cell
A network with no route out cannot reach a cloud identity provider or send a push notification. MFA there has to be satisfiable locally: a hardware token, a badge, or an offline one-time code validated by something inside the boundary.
The plant floor rules out most of what works in an office.
The right method is decided by the room, not by the security team's preference. Gloves, no personal phones, shared terminals, no signal and a running process each disqualify something that works fine in IT.
| Method | Phishing resistant | Works with gloves and shared terminals | Works offline | Where it fits in OT |
|---|---|---|---|---|
| SMS code | No | Poor, needs a personal phone | No | Avoid. No signal in most plant rooms, and the weakest factor available. |
| TOTP app | No | Poor, needs a personal phone | Yes | Workable for engineers at a desk, awkward at a panel. |
| Push approval | No | Poor | No | Convenient, but fatigue approvals are a known failure and it needs connectivity. |
| Hardware token, FIDO2 | Yes | Good, a key on the lanyard | Yes | The default for engineers and remote vendors. |
| Badge, physical credential | Yes | Best, already on the operator | Yes | Fits shift work and shared terminals, and matches the site access process. |
Two practical notes. Phishing-resistant means the factor is bound to the site it authenticates to, which rules out anything a person can read aloud or type into the wrong window. And a factor the operator already carries for the door is the one that survives contact with a running shift.
Every regime asks for MFA on remote access. None accepts the VPN alone as evidence.
The wording differs, the substance does not: strong authentication on any path into the industrial network, and a record that ties an action to a person. The distinction that matters for an audit is between having MFA and being able to show who did what.
CMMC and NIST SP 800-171
Control 3.5.3 requires multifactor authentication for local and network access to privileged accounts, and for network access to non-privileged accounts. Assets that cannot support it are handled as a documented exception with a compensating control, which is exactly the case a proxy in front of the equipment makes.
NERC CIP-005
Requirement R2.3 requires multi-factor authentication for all Interactive Remote Access sessions into high and medium impact BES Cyber Systems, and R2.1 requires those sessions to pass through an Intermediate System. For an electric utility, the VPN alone does not meet it.
IEC 62443
Foundational Requirement 1 covers identification and authentication control, including human users (SR 1.1) and software processes and devices (SR 1.2). The standard explicitly anticipates that the control may be enforced by the zone boundary rather than by the component.
CISA and NIST guidance for remote access
CISA's Cross-Sector Cybersecurity Performance Goals list phishing-resistant MFA among the baseline practices, and NIST SP 800-82 treats remote access into an ICS as a path requiring both strong authentication and monitoring, not one or the other.
Three steps, in this order.
Find the paths, not the users
List every way in: the VPN, the jump server, the vendor's cellular router in the cabinet, the dial-up modem nobody decommissioned. The last two are usually missing from the network diagram and are where the unauthenticated access lives.
Outcome
An inventory of access paths with the account each one uses.
Put a checkpoint in front of the equipment
A proxy placed beside the existing network becomes the path to the assets. It authenticates the person against your directory, applies the second factor, and opens one session to one machine. No agent on the controller, no firmware change, no maintenance window.
Outcome
Named sessions with a second factor, on equipment that has neither.
Retire the routes you replaced
The step most projects skip. If the VPN route still reaches the cell after the proxy is live, you have added a control rather than applied one. Close the old path and the audit question becomes answerable.
Outcome
One authenticated way in, and evidence that there is only one.
MFA for OT, answered.
No. MFA on a VPN authenticates the connection, then hands the user a network route. From that point the session is ordinary traffic and the equipment cannot tell who is on the other end, so nothing that happens inside the plant is attributable to a person. It is a necessary control at the perimeter and an insufficient one for the machines. The test is simple: if an auditor asks which named individual changed a setpoint last Tuesday, VPN logs cannot answer, because they record a tunnel rather than an action.
Mostly exposure. A bastion host is a hardened machine deliberately placed where an untrusted network can reach it, designed to withstand direct attack. A jump server is an intermediary you connect to in order to reach a different security zone. Most industrial sites run a single box that serves both purposes and use the names interchangeably. The practical question is not which name applies but what happens on the second hop: if the jump server logs in to the HMI with a shared local account, the identity stops there and the equipment records a login it cannot attribute to anyone.
You do not apply it to the PLC. A controller has a protocol rather than a login, and no firmware update will add a user model to equipment designed before those standards existed. The control moves to the path instead: a proxy placed in front of the asset authenticates the person against your directory, applies the second factor, and only then opens a connection to the controller. The PLC sees an ordinary protocol session from an approved source, its configuration is untouched, and the audit trail names the person rather than a shared account.
Not in the usual sense, because there is no human present to produce a second factor. A historian polling a SCADA server authenticates continuously and unattended. The equivalent control is to constrain the account rather than challenge it: bind it to one source address, one destination and one protocol, give it the narrowest rights that keep the integration working, rotate its credential on a schedule, and alert when it is used from anywhere else. Under CMMC this is the shape of a documented compensating control rather than a gap.
A hardware token or a badge, in most rooms. SMS needs a signal that plant rooms rarely have. A TOTP app and push approval both assume a personal phone, which many sites prohibit on the floor and which gloves make awkward at a panel. A FIDO2 key on a lanyard or the badge the operator already carries for the door works with gloves, works offline, works at a shared terminal, and is phishing resistant because the factor is bound to what it authenticates to.
It has to be satisfiable without leaving the boundary, which rules out cloud identity providers and push notifications. The workable methods are a hardware token, a badge, or an offline one-time code validated by a service that runs inside the air gap. The wider point is that air-gapped networks still need authentication: the gap stops routing, not the engineer with a laptop and a maintenance cable, and most incidents in isolated cells arrive through an authorised person rather than a route.
It should not, and a design that does will be bypassed within a week. The rule is that MFA belongs on the paths that reach equipment remotely, not between an operator and the panel in front of them during a process upset. Local control stays local. Where a break-glass path is genuinely needed, it should be a named account with a second factor and heightened logging rather than a shared password in an envelope, so the emergency remains attributable after the fact.
Three things, and the last is where most programmes fall short. First, that a second factor is enforced on every path into the industrial network, which means the inventory of paths has to be complete. Second, that the factor is appropriate, with phishing-resistant methods on privileged access. Third, that sessions are attributable: a record showing which named person reached which asset, when, and what they did. A VPN log satisfies the first, is silent on the second, and cannot produce the third.