What do security teams get wrong about choosing between always-on MFA and opt-in MFA?

Why Security Teams Misjudge MFA as a Binary Choice

Security teams often frame MFA as either mandatory everywhere or available on demand, but that misses the real control decision: where the extra factor meaningfully reduces risk, and where it creates friction without improving coverage. NIST’s guidance on identity assurance and authentication control selection shows that authentication strength should match the sensitivity of the action, not just the account.

The mistake is assuming opt-in MFA will naturally spread to the highest-risk users and workflows. In practice, adoption skews toward the most security-aware people, while the accounts that matter most in incidents can remain behind weaker access patterns. That is especially dangerous for shared mailboxes, delegated admin accounts, vendor access, and service-linked workflows where attackers only need one weak path. NHIMG research on the Ultimate Guide to NHIs shows how often credentials and privileges remain mismanaged across the environment, which is exactly why selective enforcement leaves gaps.

Security teams also underestimate how quickly attackers exploit policy inconsistency. If MFA is required for login but not for privileged changes, token issuance, or recovery flows, the strongest control is bypassed at the moment it matters most. In practice, many security teams discover those exceptions only after an account takeover, not through deliberate access design.

How to Decide Between Always-On and Opt-In Enforcement

The right model depends on whether the organisation is trying to reduce baseline exposure for all users or preserve flexibility for lower-risk populations. Always-on MFA is generally the safer default for workforce access, privileged users, remote access, and anything tied to sensitive data or admin actions. Opt-in MFA may be acceptable only for limited, low-impact use cases where adoption can be monitored and enforced through other controls.

A practical approach is to separate authentication policy by use case rather than by identity type alone. For example, a standard user may be allowed a lighter path for low-risk access, but the same user should hit stronger verification for password resets, payment actions, privileged console access, or new device enrollment. That aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls, which emphasises adaptive control selection based on risk and system impact.

Teams should also make sure the policy is actually enforceable. The following checks are usually where design either holds or fails:

• Require MFA for privileged roles, recovery flows, and external access first.
• Block sign-in from high-risk locations or unmanaged devices without step-up verification.
• Apply stronger controls to actions, not only to initial login.
• Review whether opt-in groups are large enough to create false confidence.

NHIMG’s Microsoft Midnight Blizzard breach analysis is a useful reminder that identity weakness is often exploited through permissive paths, not the controls teams think are central. These controls tend to break down when legacy apps, break-glass accounts, or partner-integrated workflows cannot support consistent step-up authentication.

Where the Tradeoffs and Edge Cases Actually Matter

Tighter MFA enforcement often increases helpdesk load, recovery complexity, and user frustration, so organisations need to balance stronger protection against operational continuity. That tradeoff is real, especially where executives, field staff, or third-party users rely on older devices or constrained workflows.

Current guidance suggests there is no universal standard for when opt-in MFA is acceptable. It can make sense for low-risk internal tools, pilot groups, or temporary adoption programmes, but only if there is a clear path to full enforcement later. The common failure is letting opt-in become permanent, which turns a transitional policy into a security exception.

Edge cases also matter for service accounts, shared credentials, and automated processes. MFA is not always the right primitive there, because some non-human workflows cannot complete interactive challenges. In those cases, the better control is not to force human-style MFA, but to use stronger workload identity, short-lived credentials, and explicit approval gates around sensitive actions. That distinction becomes clearer when comparing human login policy with machine access patterns in NHI governance.

For teams defining policy, the key question is not “Can MFA be turned on?” but “Which access paths remain exposed if it is not enforced here?” If that answer includes privileged changes, recovery, or externally reachable systems, opt-in MFA is usually the weaker choice. As a rule, the more unpredictable the access path, the less defensible voluntary adoption becomes.

Related resources from NHI Mgmt Group

• What do security teams get wrong about choosing between AI Code Analysis and AI pentesting?
• What do security teams get wrong about using APIs to manage user roles and application licences?
• What do security teams get wrong about scaling identity controls across regions and channels?
• What do security teams get wrong about access control when they focus only on login authentication?