How should regulated operators implement MFA without creating unnecessary abandonment?

Why This Matters for Security Teams

Regulated operators cannot treat MFA as a single, universal hurdle. If every sign-in gets the same friction, users look for workarounds, drop out, or push access requests into shadow processes. That creates a control that exists on paper but fails at the point of use. Current guidance from the NIST Cybersecurity Framework 2.0 supports risk-based access decisions, which is the right lens for authentication design.

This matters even more when NHI governance is already weak. NHI Mgmt Group notes that Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs highlights how lifecycle gaps, rotation failures, and weak visibility compound identity risk. For human MFA, the same lesson applies: assurance must rise with risk, but the user journey must stay proportionate. If the control feels like an obstacle at every step, regulated users will delay enrollment, abandon high-friction channels, or rely on insecure recovery paths. In practice, many security teams encounter abandonment only after conversion drops, support tickets spike, and users start bypassing the intended path.

How It Works in Practice

The operational pattern is to separate low-risk activity from privileged or regulated actions, then step up assurance only when the event justifies it. For example, account creation, routine dashboard access, and session refresh may need one factor or a background possession check, while payments, record changes, data export, and admin actions can require stronger verification. This is consistent with the risk-based approach in NIST Cybersecurity Framework 2.0, which prioritises outcome-driven controls rather than blanket friction.

In mobile-first journeys, possession factors usually outperform document capture or knowledge questions because they can be completed with less interruption. Best practice is evolving toward step-up MFA that uses device binding, push approval, passkeys, or cryptographic possession signals when the policy requires stronger assurance. That keeps the screen flow short while still allowing real-time risk evaluation. It also reduces repeated prompts by reusing a trusted session for a limited time window, provided the step-up was tied to the correct task and context.

For operators managing identities at scale, the same design logic appears in NHI governance. NHI Mgmt Group’s Top 10 NHI Issues shows how over-permissioning and lifecycle gaps amplify risk when access is not tightly contextual. The practical human analogue is to align MFA strength with transaction risk, not with a fixed account label. That usually means:

• Using the least-friction factor that satisfies the policy requirement for the current action.
• Applying step-up MFA only for sensitive transactions, new devices, anomalous geolocation, or recovery events.
• Prefering possession-based factors that can be validated in the background on mobile devices.
• Keeping recovery paths equally governed, so weak backup flows do not become the real bypass.

These controls tend to break down when legacy applications cannot pass risk context to the identity provider, because the system then falls back to one-size-fits-all prompts.

Common Variations and Edge Cases

Tighter MFA often increases abandonment and support overhead, requiring organisations to balance assurance against conversion, accessibility, and call-centre load. The right design is not identical for every regulated environment, and there is no universal standard for this yet. Current guidance suggests that financial services, healthcare, and critical infrastructure may all need different step-up thresholds depending on the action and the data involved.

One common edge case is account recovery. Many environments make sign-in easier than reset flows, then leave recovery as the weakest link. Another is shared-device or frontline work, where repeated MFA prompts can slow operations enough that staff seek informal shortcuts. A third is accessibility: step-up methods must still work for users who cannot use a phone, receive SMS reliably, or complete document-based verification quickly. Regulators usually care less about the exact factor and more about whether the assurance matches the risk and the process is defensible.

For audit readiness, the strongest posture is to document which actions trigger step-up, why that assurance level was selected, and how exceptions are approved. NHI Mgmt Group’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful here because auditors respond well to lifecycle evidence, clear ownership, and consistent enforcement logic. That same discipline helps human MFA avoid becoming either performative or punishing. When the regulated workflow is unusually brittle, the control often fails because business teams optimise for completion while security teams optimise for assurance, and neither side documents the tradeoff clearly.

Related resources from NHI Mgmt Group

• How should mobility platforms implement biometric authentication without creating unnecessary friction?
• How should small businesses implement MFA without creating too much user friction?
• How should teams implement customer MFA without creating too much login friction?
• How should security teams implement MFA in web applications without creating inconsistent protection?