MFA for OT. Prove who reached every machine.

Put MFA in front of the equipment and leave the equipment unchanged. There are five architectures: a ZTNA gateway or industrial VPN for remote access, a PAM bastion for administration sessions, a micro-firewall with a captive portal in front of a cell, an MFA agent on workstations that accept one, and a DMZ in a box such as Access Gate, which combines the proxy, the bastion and the filtering in one appliance per site. In every case, close the direct paths to the machine afterwards.

It is an industrial DMZ in one appliance per site. Access Gate connects beside the existing network and provides zone filtering, the authenticating proxy and the bastion for remote sessions. One rule on the existing router sends machine traffic to it. Nothing is installed on the machines, and removing the rule rolls the change back.

Plan a break-glass path so operators keep control during a failure. With Access Gate connected beside the network, the network keeps running if the appliance is offline, and local panels stay usable. An identity provider hosted on site only needs the local network, so an internet outage does not stop authentication.

OT authentication is the check that proves who a person is before a session to an industrial machine opens. In OT the check often cannot run on the machine itself, because PLCs, RTUs and older HMIs have no user accounts. So it runs on the access path instead: at the remote access gateway, at the jump host, or at a proxy placed in front of the equipment. Good OT authentication ties each session to a named person, uses a second factor, and leaves a record of which machine was reached.

MFA makes a stolen or shared password useless on its own. In OT that matters because one session can change a setpoint or stop a line, and because plant networks now connect to the office network and to vendors. With MFA, an attacker who copies a contractor's VPN password still needs the second factor before any session opens. MFA also gives each session a named person, which is what an auditor or an incident review needs.

On remote access, for both staff and vendors, because a stolen credential can be used on those paths from anywhere. Then on jump hosts, engineering workstations and privileged accounts on SCADA servers and historians. Shared HMIs on the floor come next, usually with a badge, because the panel itself cannot take a second factor. Controllers that cannot authenticate at all are covered by a proxy in front of them.

Yes. Control 3.5.3 in NIST SP 800-171 Rev. 2 requires multifactor authentication for local and network access to privileged accounts, and for network access to non-privileged accounts. CMMC Level 2 assesses that control. In an OT environment, equipment that cannot support MFA is handled as a documented exception with a compensating control, such as an authenticating proxy in front of it.

They answer different questions. MFA proves who the person is. Segmentation limits what that person can reach after the check passes. Used alone, MFA on a VPN still hands the user a route to a whole subnet. Combined, each authenticated session reaches one machine over one protocol, and a stolen credential cannot be reused to move across the plant.

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. Ask 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 what happens on the second hop. If the jump server logs in to the HMI with a shared local account, the identity stops there. The equipment then 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 and applies the second factor. Only then does it open 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, solves this. It works with gloves, offline and at a shared terminal. It is also 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. Access Gate's TOTP works offline. Air-gapped networks still need authentication. The gap stops routing, but it does not stop an engineer with a laptop and a maintenance cable.

It should not, and a design that does will be bypassed within a week. MFA belongs on the paths that reach equipment remotely. It does not belong 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. That way 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.