Which frameworks require or strongly expect MFA for enterprise access?

Why This Matters for Security Teams

MFA is rarely controversial in principle, but enterprise access gets messy fast because “enterprise” includes employees, contractors, admins, federated SaaS users, cloud consoles, and service workflows that were never designed to share the same authentication bar. Frameworks such as NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls push organisations toward stronger authentication, but the practical question is where MFA is required, where it is only expected, and where compensating controls are accepted.

That distinction matters because auditors and incident responders often discover that “MFA enabled” covers only a subset of access paths. Admin panels, remote access, and privileged cloud roles are the usual weak points, while non-interactive and federated access are frequently left with legacy exceptions. NHIMG research shows how often identity controls fall short in practice: the Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, which is why strong authentication has to be paired with privilege control rather than treated as a standalone checkbox. In practice, many security teams encounter MFA gaps only after an access review, audit finding, or credential theft event has already exposed the exception.

How It Works in Practice

For most enterprise programs, the right way to read MFA requirements is path by path. Start with the access surface, then map the framework expectation to each one: interactive user login, privileged administrator access, remote VPN or ZTNA entry, cloud console access, federation into SaaS, and any recovery or break-glass process. The strongest requirements usually sit around privileged and remote access, while standard user access may be satisfied with phishing-resistant MFA, step-up MFA, or a risk-based combination depending on the control family.

Current guidance suggests a few implementation patterns:

• Use phishing-resistant MFA for administrators and high-value systems where possible.
• Apply MFA at the identity provider, but verify that downstream apps do not create bypass paths.
• Document exceptions for service accounts, automation, and recovery accounts separately from human access.
• Test whether conditional access, device trust, or network controls are being counted as substitutes for MFA when the framework does not allow that substitution.

For regulated environments, the useful question is not simply “Is MFA on?” but “Which access path is covered, by what factor, and with what evidence?” The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful here because it frames identity controls as part of auditable governance, not just technical hardening. That same lens aligns with the OWASP Non-Human Identity Top 10, which highlights how weak identity handling expands attack paths once credentials are reused or over-scoped. These controls tend to break down when legacy applications cannot support modern federation, because organisations then create MFA exemptions that persist far beyond the original business need.

Common Variations and Edge Cases

Tighter MFA coverage often increases operational friction, requiring organisations to balance stronger assurance against user experience, help-desk load, and recovery complexity. That tradeoff is especially visible in environments with outsourced support, shared admin tooling, disaster recovery accounts, or machine-to-machine integrations where human-style MFA does not fit cleanly.

There is no universal standard for this yet across every framework and access pattern, so teams should avoid overclaiming. Some regimes strongly expect MFA for privileged or remote access but allow compensating controls when technical constraints exist, while others are more explicit about phishing-resistant factors or minimum assurance levels. This is where policy language, not just product configuration, becomes important. The most common edge case is federated access into third-party SaaS: MFA may be enforced at the identity provider, but the downstream application still needs evidence that the session inherits that assurance.

Another frequent gap is non-human and shared access. Service accounts, API keys, and automation often do not use MFA directly, so the better control is short-lived credentials, workload identity, and strict entitlement review. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs both reinforce that access governance fails when credentials outlive their purpose or when no one can prove who, or what, is actually using them. For enterprise MFA questions, the real test is whether the control survives exceptions, not whether the login page says “multi-factor” on paper.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• When do NHI access reviews create more value than a one-time cleanup?
• What is the difference between reviewing human access and reviewing NHIs?