Multi-factor authentication, or MFA, requires a person to prove their identity with more than one thing - typically a password plus a second factor such as a code from a phone or a hardware token - before they are allowed in. In OT it matters most on the remote-access paths that let someone reach the control system from outside, where a stolen password alone should never be enough. This page explains what MFA is, why remote OT access is exactly where it belongs, and the practical hurdles of applying it to shared consoles and offline field sites.
MFA in OT in one line: Multi-factor authentication requires two or more independent forms of proof to log in - most commonly something you know, like a password, combined with something you have, like a phone-generated code or a hardware token - so that a compromised password by itself cannot grant access. In OT, its greatest value is on remote-access paths into the control system, where it turns a stolen credential from a way in into a dead end, though shared control-room consoles and disconnected field sites make it harder to apply universally than in IT.
A password is a single secret, and single secrets are stolen constantly - phished, reused across sites, guessed, or leaked in breaches. If a password is the only thing standing between an attacker and a system, then stealing that password is game over. Multi-factor authentication defeats this by demanding a second, independent proof: even if the attacker has the password, they still lack the phone, token, or other factor the legitimate user holds, so the stolen password alone gets them nowhere.
In OT, this protection is most urgent on the remote-access paths - the ways an engineer, vendor, or operator reaches the control system from outside the plant. These paths are attractive to attackers precisely because they lead into the control environment from a distance, and a remote path guarded only by a password is a well-known way in. Putting MFA on those paths means a compromised credential is no longer sufficient to cross from the outside world into OT. This is why remote engineering access, jump hosts, and VPNs into control networks are the first places MFA is applied.
The reasoning is a matter of exposure. Internal control-room systems that are physically guarded and network-isolated face a different threat profile than a login reachable over the internet. The remote path is the one an attacker can attempt from anywhere, without ever setting foot on site, so it is the one where the single-secret weakness of a password is most dangerous. Concentrating MFA on remote access puts the strongest control where the exposure is highest, which is the most valuable place a limited security effort can spend it.
MFA is straightforward in IT, where every user has a personal account and a smartphone in their pocket. OT breaks several of those assumptions, starting with shared consoles. A control-room workstation is often used continuously by whoever is on shift, and demanding a fresh second factor on every interaction would fight against the need for an operator to act instantly during an upset. The common resolution is to apply MFA where a new session or elevated access begins - such as logging in to the workstation at shift start or reaching in remotely - rather than on every routine screen action, so security does not impede fast operational response.
Offline and remote field sites pose a harder problem, because many MFA methods assume connectivity. A one-time code delivered to a phone, or a check against a central authentication server, presumes the site can reach a network and a service - an assumption that fails at a disconnected wellsite or during a comms outage. Factors that work offline, such as hardware tokens that generate codes independently, become important here, as does designing so that a legitimate technician is never locked out of equipment they must reach when the network is down. The goal is strong authentication that does not depend on the very connectivity a remote site may lack.
Then there is the reality of legacy equipment. Plenty of installed control devices simply have no native support for multi-factor authentication and cannot be made to require it directly. Rather than force the impossible onto the device, the usual approach is to put MFA on the paths that lead to it - the remote-access gateway, the jump host, the network entry point - so a user must clear a second factor to get near the legacy device even though the device itself only knows about passwords. This wraps strong authentication around equipment that cannot provide it, which is often the only workable answer.
As oil and gas operations put more of their monitoring and access online, MFA becomes central rather than optional. A cloud SCADA platform like Merobix is reached over the internet by design, which is exactly the situation where a password alone is inadequate - the login is available to anyone who can reach the service, so a second factor is what keeps a stolen credential from becoming unauthorized access to the operation's data and controls. MFA on the cloud login is the natural first line of defense for remote visibility.
It is useful to separate the layers. MFA guarding access to a monitoring platform protects the dashboards, trends, and any remote actions that platform offers. That is distinct from, and complementary to, the MFA guarding deeper engineering paths into the control network itself, such as reaching a controller to change its logic. Both deserve a second factor, because both are remote doorways, but they protect different things - the operator's visibility on one hand and the process's programmability on the other.
For dispersed, lightly staffed field operations, MFA on these remote paths is what makes distant access defensible. When people can reach the operation from anywhere, the ability to reach it must be tied to more than a reusable password, or the convenience of remote work quietly becomes the operation's biggest exposure. Applied to the remote-access and cloud-login paths - the places attackers can actually attempt from afar - MFA lets an operator embrace remote monitoring and support without accepting that any single leaked password can open the door.
Because remote-access paths are the ones an attacker can attempt from anywhere without being on site, making them the highest-exposure targets where a password's single-secret weakness is most dangerous. Internal, physically guarded control-room systems face a different threat profile. Concentrating MFA on remote access, jump hosts, and cloud logins puts the strongest control where the exposure is greatest, which is the most valuable use of a limited security effort.
Methods that need connectivity, like codes texted to a phone or checks against a central server, fail at a disconnected site. The answer is factors that work offline, such as hardware tokens that generate valid codes on their own without contacting a server. Designs also ensure a legitimate technician is never locked out of equipment they must reach during a comms outage, so strong authentication does not depend on the connectivity a remote site may lack.
Usually not directly, because many legacy control devices only understand passwords and cannot be made to require a second factor themselves. The practical approach is to put MFA on the paths that lead to them - the remote-access gateway, jump host, or network entry point - so a user must clear a second factor to reach the vicinity of the legacy device. This wraps strong authentication around equipment that cannot provide it natively.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.