Standard MFA breaks on shared terminals without individual attribution

At a glance

What this is: NHI Mgmt Group's analysis, drawing on OLOID's blog post: Standard multi-factor authentication can fail on shared terminals because device-dependent methods do not preserve individual session attribution.

Why it matters: IAM teams, PAM leads, and operational security owners need authentication that works under shift patterns, shared devices, and regulated access where attribution matters as much as login success.

By the numbers:

• MFA blocks more than 99.2% of account compromise attacks, according to Microsoft's published research cited by OLOID.

Context

Multi-factor authentication is only as strong as the operating model it supports. In frontline environments, the real issue is not whether a second factor exists, but whether the authentication method still ties access to one person when many workers share the same terminal across a shift.

Conventional MFA programs often presume a personal device, stable login patterns, and a single user per workstation. That presumption weakens in manufacturing, retail, and clinical settings, where shared devices are normal and individual attribution is a governance requirement rather than a convenience.

The result is a gap between policy and practice: a control can be technically enabled while the session history still reflects a shared login pattern instead of a named individual. That is the core operational problem this post addresses.

Key questions

Q: How should teams authenticate workers on shared devices without using shared logins?

A: Use individual identities with device-bound authentication, such as badge tap, smart card, biometric sign-in or a short-lived token, so each worker can authenticate without a shared username or password. The session should be tied to the person and the device, then revoked or timed out at sign-out, which preserves accountability and avoids credential sharing. bind each session

Q: Why do SMS one-time passwords fail in frontline and shift-based environments?

A: SMS one-time passwords fail where staff cannot reliably receive or protect a handset, because the code travels over a phone number rather than a managed device or strong authenticator. In frontline and shift work, shared kiosks, changing locations and lost or unavailable phones make SMS brittle, and SIM swap, message interception and delayed delivery weaken assurance. personal phones

Q: What is the difference between traditional MFA and passwordless authentication?

A: Traditional MFA usually adds a second factor on top of a password, so the login flow still depends on a shared secret. Passwordless authentication removes the password and uses device-bound cryptographic proof instead. The practical difference is that passwordless reduces the number of reusable secrets an attacker can steal, replay, or coerce a user into approving.

Q: What should healthcare teams do to keep shared workstation access attributable?

A: Healthcare teams should assign each user an individual sign-in, then capture a session trail that records who accessed the shared workstation, when they did so and which application or record they opened. Timeouts, re-authentication and central logging keep the access attributable even when the device itself is shared, which supports audit, incident review and access governance. session trail

Technical breakdown

Why shared terminals break the standard MFA model

Standard MFA mechanisms were built for an identity flow where one person authenticates once and keeps that identity bound to the session. Shared terminals disrupt that assumption because the device, not the person, becomes the stable object in the workflow. When workers rotate through the same kiosk or workstation, a factor that depends on a personal phone, a remembered password, or a persistent session no longer cleanly represents the current user. The control may still function at sign-in, but it stops delivering reliable individual attribution across the shift.

Practical implication: Design the authentication flow around the session handoff, not the login event alone.

Why phone-dependent factors fail in operational environments

SMS OTP, push approval, and app-based TOTP all depend on a personal mobile device, which is often unavailable or prohibited on the floor. That creates a structural mismatch, not just a usability issue. If the worker cannot carry or use a phone, the organisation either accepts exceptions or introduces workarounds that undermine the control. In practice, that pushes users toward shared credentials, reused sessions, or informal bypasses that leave the environment less governable than the original policy suggests. See the MFA Guide.

Practical implication: Treat smartphone dependency as a deployment constraint, not a minor inconvenience.

How passwordless methods preserve individual attribution

Passwordless authentication shifts the control point from something the user types to something that binds the session to the person or their assigned credential hardware. Biometrics, badge-based login, and cryptographic keys reduce the incentive to share secrets and make it easier to identify who used the terminal at a given time. The important architectural change is that the shared device no longer has to carry the identity burden by itself. Instead, the factor used at login becomes part of a session record that can stand up to review. See the Smart Card and PIV/CAC Authentication Guide.

Practical implication: Use identity-bound factors where shared workstations must still produce a defensible audit trail.

Threat narrative

Attacker objective: Obscure who performed an action by exploiting a session model that cannot reliably distinguish one worker from another.

1. Entry occurs through a shared terminal or workstation where multiple workers can access the same session boundary in a shift-based environment.
2. Credential or session abuse follows when a login is shared, left open, or reused because the deployed MFA method is inconvenient on the floor.
3. Impact is a weak audit trail that records device activity rather than individual activity, which blocks attribution during incident review and compliance checks.

Breaches seen in the wild

• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
• SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standard MFA does not solve individual attribution when the session itself is shared. The control may still satisfy a checklist requirement, but the governance outcome is different when one workstation is reused by multiple people over a shift. In that environment, the real problem is not factor count but identity continuity, and that is why shared-terminal authentication should be evaluated as a session governance issue, not just a login method choice.

Phone-dependent MFA creates a governance exception whenever personal devices are restricted. SMS OTP, push approval, and app-based codes all assume a user can carry a private device into the workflow. That assumption fails on factory floors, in wards, and in stockrooms, so the organisation either accepts operational exceptions or tolerates informal workarounds. The result is not just weaker authentication, but weaker accountability.

Passwordless authentication is best understood as an attribution control, not merely a convenience layer. In shared-device settings, biometric and badge-based flows matter because they bind the session to an individual without requiring a personal smartphone. That changes the governance model from shared secret management to individual session ownership, which is the core problem frontline environments need solved.

Shared-device environments expose an attribution gap that traditional MFA programs rarely model explicitly. The control objective is often stated as stronger authentication, but the operational objective is traceable access by a named worker. Those are not the same thing. Program owners need to treat individual attribution as a first-class requirement alongside phishing resistance and rollout simplicity.

Identity assurance on shared terminals should be measured by session ownership, not just successful login rates. If multiple workers can use the same access path without a durable link to the person who acted, the governance model is already incomplete. The practitioner conclusion is straightforward: the environment, not the factor label, determines whether authentication really works.

What this signals

Shared-device authentication is really a governance problem about session ownership. When access is reused across workers, the control objective shifts from proving that someone authenticated to proving which person used the terminal at a specific moment. Programs that do not model that distinction will keep producing controls that look compliant but fail under investigation.

The practical threshold is whether the method still works when the environment breaks the one-user, one-device assumption. If the answer is no, the organisation is not facing a tuning problem, but a design mismatch that needs a different authentication pattern.

For practitioners

• Define individual attribution requirements for shared terminals Specify that every session on a shared workstation must be attributable to a named worker, even when the device is reused across shifts.
• Remove personal-phone dependency from frontline access Map where SMS OTP, push approval, and app-based codes fail because staff cannot carry phones, then replace them with methods that work on the floor.
• Adopt passwordless flows for shared workstations Use biometrics, badge-based login, or cryptographic keys to keep access tied to the individual rather than to a reusable shared password.
• Test login flows against shift-change conditions Validate whether authentication still works when multiple users move through the same terminal, with limited time, PPE, or restricted device use.

Key takeaways

• Shared terminals create an attribution problem that conventional MFA does not resolve when one device serves many workers across a shift.
• The risk is not limited to weaker authentication strength; it also affects incident review, auditability, and accountability for access events.
• Passwordless and identity-bound methods are the controls that most directly address the gap because they preserve session ownership without requiring a personal smartphone.

Related NHI Mgmt Group resources: Breach and Attack Simulation (BAS) Guide · MFA Guide · Smart Card and PIV/CAC Authentication Guide

Key terms

• Multi-Factor Authentication: Multi-factor authentication requires two or more independent verification factors before access is granted. In practice, it reduces the chance that a stolen password alone will open a system, but it only works well when applied consistently across all high-risk access paths and identity types.
• Time-Based One-Time Password (TOTP): A time-based one-time password is a short authentication code that changes at fixed intervals, usually 30 seconds, and is used as a second factor during login. TOTP is generated from a shared secret and the current time, making the code valid only briefly and reducing replay risk in MFA workflows.
• Push notification authentication: An MFA method that asks a user to confirm a login attempt from another device, usually a mobile app. It improves security over passwords alone, but it creates an approval event that attackers can target with impersonation, repetition, and timing pressure.
• Passwordless Authentication: An authentication approach that removes passwords and uses a device-bound cryptographic key plus local user verification. It reduces phishing and replay risk, but it only improves assurance when enrollment, recovery, and revocation are tightly governed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.