MFA for Service Accounts and Industrial Devices: Is It Possible?

For decades, multi-factor authentication (MFA) has been the go-to security strategy for interactive user logins, aiming to ensure “something you know” is paired with “something you have” or “something you are.” But when you step into the critical world of industrial networks—where service accounts and industrial devices rather than human users do much of the talking—the question arises: is MFA even possible? Or relevant?

Let’s explore the technical realities, the historical development behind these authentication models, and architecture strategies for securing non-human identities in critical and operational technology (OT) environments. As you’ll see, the answer is nuanced and, as usual, the devil is in the details.

What’s Unique About Service Accounts and Industrial Devices?

Unlike human users, service accounts often exist to allow applications, scripts, and processes to perform their duties automatically and without interactive prompts. Meanwhile, industrial devices—PLCs, RTUs, DCS, sensors, actuators—predate most modern security concepts. Their core mission is stable, reliable operation, often within strict real-time or resource-constrained settings. Their operating systems may be proprietary or lack the extensibility required for contemporary IT security controls.

Historical Note: Authentication in OT

Traditionally, OT environments operated in isolation (“air-gapped”). Authentication needs were minimal; if you had physical access, you had control. That changed as converged IT/OT enablement and remote management needs led to network connectivity, exposing formerly isolated assets to new threat vectors.

As industrial environments were connected to wider corporate networks—often running decades-old protocols like Modbus, DNP3, and Profibus—classic IT practices such as centralized authentication struggled to gain a foothold. Out-of-band authentication mechanisms (visual indicators, physical keys, engineering workstations) have largely been bypassed or deprecated with digital transformation.

Why MFA Is A Challenge for Non-Human Identities

Remember, multi-factor authentication is predicated on the presence of more than one ‘factor’. For humans: a password and a phone, a token, a fingerprint. But neither service accounts nor headless industrial endpoints have hands to touch a phone or eyes to scan a QR code. Interactive authentication is missing by definition.

• Service Accounts: Run automatically, typically as background OS processes. Automated scripts, scheduled jobs, middleware connections. Interactive prompts break automation.

• Industrial Devices: Frequently run embedded or legacy firmware, cannot support dynamic user interaction, and rarely support extensible authentication protocols.

• Human-Machine Interfaces (HMI): The point where user-to-machine authentication can be enforced, but device-to-device (machine-to-machine) MFA remains absent.

Mitigating Risks When MFA Isn’t Feasible

If classic MFA isn’t viable, is it time to give up? No, but the security controls you apply must fit the reality. Here’s how the field is addressing this today:

Categorize Accounts and Devices

First, classify which identities are interactive (human users), which are headless (service/process/system accounts), and which are device identities (industrial endpoints). Each class deserves a distinct security approach.

Principle of Least Privilege

Service accounts should have the minimum access required to function. Historically, especially in Windows Active Directory environments since the 1990s, there’s been a penchant to assign broad privileges for “ease of use”—until an incident demonstrates why that was a poor choice.

Hardening Non-Interactive Accounts

• Strong (Long, Randomized) Secrets: Instead of MFA, require non-interactive accounts use long, randomly generated passwords or managed keys—managed, rotated, and tightly audited.

• Vaulting and Credential Rotation: Use privileged access management (PAM) or credential vaults to store, rotate, and restrict use of account credentials.

• Kerberos and Machine Certificates: Kerberos has supported mutual authentication since the 1980s for machine-based authentication in Windows and Unix environments. Asymmetric keys/certificate authentication allows trusted connections.

• Network Segmentation: Segregate device networks from general IT, limiting lateral movement opportunities.

• IP Allow-Lists: Limit from where service accounts may be used, blocking anomalous geographies or networks.

• Device Authentication (802.1X, TLS): Use device certificates for mutual TLS, network access control (NAC), and device identity verification at the packet level. (Remember: 802.1X was conceived for laptops/desktops—industrial device implementation may require vendor support or intermediation via gateways.)

Modern Shifts: Passwordless and Certificate-Based Auth

Vendors increasingly offer “passwordless” technologies (FIDO2, PKI-based, SSH certificates) and zero trust frameworks centered on device posture, machine certificates, and strong policy enforcement. In this sense, while you might not get an 'MFA dialogue box,' you can demand that only cryptographically trusted systems make connections—enforcing identity and integrity at the machine or service level.

Historical Context: SSH Keys and Certificates

SSH keys have provided non-interactive authentication since the late 1990s in Unix/Linux environments—another example of a “two factor” relationship (something the endpoint has: the private key; something the server knows: the public key). But key sprawl, poor key management, and weak client identification have often blunted their effectiveness. Newer approaches—such as short-lived SSH certificates delivered from a central CA—are making inroads in modern orchestration systems.

Is Device MFA on the Horizon?

There is ongoing research and vendor work around “device-level MFA”—but it’s a semantic stretch. What’s being discussed is actually extending strong device authentication beyond one secret, such as requiring possession of a cryptographic identity and presence on an expected network, or integrating secure enclaves or Trusted Platform Modules (TPM).

Industrial hardware refresh cycles are slow. In reality, security approaches must adapt to the install base—meaning layered, compensating controls, not always direct MFA analogues.

IT/OT Collaboration: Process and Pragmatism

Historically, IT and OT have had different attitudes, toolsets, and skillbases regarding authentication. IT assumes modern OS support and is used to central management and rapid change; OT prioritizes availability first, and change management next. The idea that “IT just deploys MFA everywhere” is often unworkable without intimate understanding of operational consequences—accidental lockout of a critical service or device during an update window can impact safety and production.

Effective collaboration means IT architects and security teams listening to OT engineers—and vice versa. Security improvements must be measured for technical fit, operational reliability, and risk reduction. Where classic MFA can’t be implemented, a risk-based rationale with strong compensating controls, and an ongoing monitoring and improvement program, is key.

Deployment Strategies in Industrial and Critical Environments

• Architect for Segmentation and Zero Trust: Don’t trust by default; validate at every connection, privilege elevation, and network boundary crossing.

• Use Network Security Monitoring: Where you can’t put a lock, watch the door closely. Anomaly detection, logging and SIEM integration are crucial for long-term resilience.

• Work with Device and Platform Vendors: Push suppliers for MFA readiness in next-generation devices; for legacy, focus on network-level control and credential management.

• Prepare for Human Exceptions: Identify which workflows actually require interactive access, and ensure that for those scenarios, MFA is non-negotiable—even if device-level coverage remains out of reach for now.

Conclusion: Honest Answers for a Messy Landscape

In summary: MFA, as popularly imagined, is not currently feasible for non-interactive service accounts and most industrial devices. But that doesn’t mean you must surrender to weak authentication practices. Robust machine authentication, strong credential management, layered defense-in-depth, and collaborative IT/OT security operations fill the gap.

As the industry evolves, standards and vendor platforms may begin to offer more native supports for device “MFA”—but for now, realism and pragmatism must guide strategy. Ask not, “How do I bolt on user MFA to everything?” but rather, “How can we enforce strong identity and least privilege for every system, device, and service across the stack, without breaking the machinery that keeps the lights on?”

And, maybe most importantly: keep pushing the envelope with your vendors, your processes, and your own architecture. The gap is smaller than it used to be, but progress remains in our hands.

Further Reading / References

• NIST SP 800-82 Rev 2: Guide to Industrial Control Systems (ICS) Security

• NIST SP 800-63B: Digital Identity Guidelines – Authentication and Lifecycle Management

• IEC 62443: Industrial communication networks – IT security for networks and systems

• SANS ICS Security Resources: ICS Security Whitepapers

• Microsoft: Securing service accounts in Windows Active Directory

• OpenSSH Certificates documentation