What breaks when organisations rely on single-factor PAM instead of MFA for human access?

Why This Matters for Security Teams

Single-factor PAM does not fix weak human authentication. It only wraps privileged access in a control plane that is still dependent on the first factor, so a stolen password, replayed session, or phished OTP can still open the door to crown-jewel systems. That is why privileged workflows should be treated as high-impact human access, not as a separate exception to normal authentication requirements.

The risk is not theoretical. Privileged sessions often become the fastest path to data export, policy changes, and lateral movement once an attacker lands on the account. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls aligns with the basic principle that access enforcement must be strong at the point of authentication, not only at the point of elevation. NHIMG research on the Ultimate Guide to NHIs shows why identity weaknesses matter at scale: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a reminder that attackers routinely target the easiest trust path available.

In practice, many security teams discover the weakness only after a privileged account is used to access sensitive systems, rather than through intentional testing of the login path.

How It Works in Practice

For human users, PAM should be the broker for privilege, not the substitute for strong authentication. The correct model is MFA at initial login, then PAM issues just enough privileged access for the approved task, with session controls layered on top. That means the user proves identity with a strong factor set before entering the privileged workflow, and PAM enforces approvals, session recording, command filtering, and time-bounded elevation after that point.

This distinction matters because a single-factor PAM flow still leaves the organisation exposed to password theft, token replay, and account takeover. If the attacker can satisfy the one factor, they inherit the full privileged path. By contrast, MFA reduces the chance that a stolen credential can be used at all, and PAM then reduces the blast radius if privilege is actually needed. This is consistent with the broader identity guidance in the OWASP Non-Human Identity Top 10, which underscores that access control failures usually occur when authentication, credential lifecycle, and privilege boundaries are treated as separate problems.

• MFA should protect the human login before any privileged session starts.
• PAM should enforce least privilege, approval, and just-in-time elevation.
• Sessions should be recorded and scoped to the task, not left open-ended.
• Fallback methods, recovery flows, and break-glass access need the same strength as normal access paths.

NHIMG’s 52 NHI Breaches Analysis is useful here because it shows a recurring pattern: trust is often abused through the weakest identity path, not the most visible control. These controls tend to break down when shared admin accounts, legacy VPN access, or excluded break-glass workflows bypass the MFA requirement because the privileged route becomes easier to attack than the standard route.

Common Variations and Edge Cases

Tighter privileged access control often increases operational friction, so organisations have to balance user convenience against the much higher cost of a privileged compromise. The tradeoff is most visible in legacy environments, where older applications or jump hosts cannot easily support modern MFA prompts, and teams are tempted to leave PAM as the only gatekeeper.

That shortcut is risky, and current guidance suggests treating it as a temporary exception only. If a platform cannot support MFA, compensating controls should be explicit, time-limited, and documented, not assumed to be equivalent. For example, break-glass accounts may need separate monitoring, stronger hardware-backed factors, or network restrictions. Shared admin accounts are even harder to defend because MFA can become non-attributable or inconsistently enforced, which weakens both prevention and accountability. The underlying lesson is that PAM is not a substitute for identity assurance; it is a privilege orchestration layer. That distinction is widely reflected in the control intent of NIST and in identity-centric analysis from Ultimate Guide to NHIs, even though there is no universal standard for every legacy exception pattern yet.

In environments with remote contractors, admin desktops, or federated access, the safer model is to require MFA at the identity provider, then let PAM constrain what the authenticated user can do. Anything weaker turns privileged access into a trust amplifier for stolen credentials.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on SMS or email MFA for sensitive access?
• What breaks when organisations rely on MFA and VPNs alone for contractor access?
• What breaks when organisations rely on observability instead of access control?
• What breaks when organisations rely on persistent access instead of just-in-time controls?