Adaptive MFA in regulated industries: risk-based access that fits context

At a glance

What this is: This is an analysis of adaptive MFA for regulated industries and its use of contextual signals to vary authentication strength by risk.

Why it matters: It matters because IAM teams need authentication controls that protect sensitive systems without breaking clinician, banker, or civil-service workflows.

👉 Read eMudhra's analysis of adaptive MFA for regulated industries

Context

Adaptive MFA is a risk-based authentication model that changes the verification challenge based on the current session, not just the user account. In regulated industries, that matters because the same control has to support both sensitive access and operational speed, especially where identity assurance, auditability, and user friction all affect outcomes.

The core governance problem is that static MFA treats every login as if it carries the same risk. That assumption breaks in banking, healthcare, and government workflows, where device posture, network context, role sensitivity, and transaction value all change the right level of assurance. For teams building or refining identity programmes, the question is how to apply stronger assurance only when the session warrants it while preserving access for legitimate work.

For broader IAM context, adaptive authentication should be understood alongside zero trust and phishing-resistant authenticators, not as a replacement for them. Regulated organisations need to align policy, assurance level, and audit evidence so that step-up decisions are defensible after the fact, not just convenient at login.

Key questions

Q: How should security teams implement adaptive MFA in regulated environments?

A: Start by classifying access paths by sensitivity, then define which contextual signals can raise or lower assurance. Use managed device status, location, role, and transaction value to trigger step-up only when the session warrants it. Keep the policy explainable so audit teams can see why stronger verification was required.

Q: Why do regulated industries need adaptive MFA instead of static MFA?

A: Static MFA treats every login the same, which creates unnecessary friction for low-risk sessions and insufficient scrutiny for sensitive ones. Regulated environments need assurance that responds to context, because the risk of a routine portal login is not the same as the risk of a privileged transaction or ePHI access.

Q: What do security teams get wrong about adaptive authentication?

A: They often treat it as a user-experience tweak rather than a governance control. The real issue is deciding which identities, resources, and actions deserve stronger assurance, and proving that decision later. Without good signal quality and clear policy mapping, adaptive MFA becomes inconsistent and hard to audit.

Q: Who is accountable when step-up authentication fails to protect regulated access?

A: Accountability usually sits across identity engineering, application owners, and compliance teams, because the control depends on policy design, signal quality, and workflow integration. If a sensitive action was not challenged, the organisation should be able to show who owned the policy, who tuned the signals, and who approved the exceptions.

Technical breakdown

How risk scoring drives adaptive authentication decisions

Adaptive MFA works by translating context into a risk score or policy branch. Signals may include whether the device is managed, whether the network is expected, whether the login time fits normal behaviour, and whether the requested resource is high sensitivity. The important distinction is that the system does not verify the user once and stop. It re-evaluates the session in light of present risk and then selects the least disruptive assurance level that still satisfies policy. In regulated settings, that policy logic must be consistent, explainable, and mapped to audit requirements, otherwise step-up becomes hard to justify after an incident or review.

Practical implication: define which signals trigger step-up and keep the policy logic auditable end to end.

Step-up authentication for high-risk login and transaction events

Step-up authentication is the mechanism that increases assurance only when risk rises. A normal session may use a biometric push or passkey, while a sensitive action may require a hardware token or additional verification. In banking, that distinction often matters at the transaction layer because the authentication need is not only about who logged in, but what they are trying to do. In healthcare, the equivalent issue is access to ePHI or controlled functions. The control works best when it is tied to specific risk thresholds and protected workflows, not when it is applied as a blanket prompt to every interaction.

Practical implication: map the strongest authenticators to privileged or high-impact actions, not to all sessions equally.

Why static MFA fails under regulated workload pressure

Static MFA creates predictable friction, which in turn encourages fatigue, prompt acceptance, and unsafe workarounds. It also does not distinguish between low-risk and high-risk access attempts, so users see the same challenge even when context clearly differs. That makes static MFA a weak fit for regulated industries where both security and service continuity matter. Adaptive MFA is therefore not just a user-experience improvement. It is a governance response to the fact that authentication risk varies by session, actor, and resource. The control has to be tuned carefully because poor policy design can move risk from the login screen into shadow processes and manual exceptions.

Practical implication: measure prompt fatigue and exception rates, then adjust policy so security does not migrate into bypass behaviour.

Threat narrative

Attacker objective: The attacker aims to turn a routine login into trusted access to high-value regulated systems or transactions.

1. Entry occurs through credential reuse, phishing, or a low-friction login path that does not challenge the session strongly enough for its actual risk profile.
2. Escalation happens when the attacker reaches a sensitive account, transaction, or workflow and the authentication policy fails to require step-up at the point of highest value.
3. Impact follows when access is used to move money, expose ePHI, or alter government or financial records under the cover of legitimate authentication.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Microsoft Midnight Blizzard breach — Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static MFA is a poor fit for regulated access because it assumes every session deserves the same friction. That model was built for broad authentication coverage, not for contexts where the sensitivity of the action changes minute by minute. In banking, healthcare, and government, the control has to distinguish between ordinary access and high-risk activity. Practitioners should treat adaptive assurance as an operating requirement, not a cosmetic improvement.

Context-aware authentication only works when the risk signals are operationally trustworthy. Device posture, geolocation, user role, and resource sensitivity can all inform step-up decisions, but each signal has to be governed for quality and explainability. If the data feeding the policy is noisy or incomplete, the authentication decision becomes difficult to defend under audit or incident review. Practitioners should evaluate the signal chain as part of the control, not as an implementation detail.

Phishing-resistant authentication becomes more important, not less, when adaptive policies are introduced. Adaptive MFA reduces unnecessary friction, but it does not eliminate the need for strong authenticators at the top end of risk. Where privileged access, payments, or regulated records are involved, the step-up path must resist prompt bombing and real-time proxy attacks. Practitioners should align assurance level with the highest-impact workflows, not the average one.

Adaptive MFA is really an assurance policy problem, not just an authentication feature. The field keeps focusing on prompts, but the governance question is who gets challenged, when, and for which actions. That means identity teams, PAM teams, and compliance leads need a shared policy model that maps risk to assurance consistently across human access paths. Practitioners should manage adaptive MFA as part of identity governance, not as a standalone login control.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities.
• That confidence gap is why programmes need lifecycle and access governance resources such as Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs as the next control layer.

What this signals

Adaptive MFA is becoming a governance pattern, not just an authentication setting. Regulated organisations that still apply the same login challenge everywhere are carrying unnecessary friction in low-risk paths and unnecessary exposure in high-risk ones. That creates pressure on support teams, exception processes, and audit evidence, especially where identity spans banking, healthcare, and government services.

Risk-based authentication must be paired with policy observability. If teams cannot explain why a session was stepped up, they cannot defend the control after a security event or compliance review. That is why zero trust language alone is not enough. The policy decision, the signal source, and the recorded outcome all need to be visible to identity and compliance teams.

The control now needs to sit alongside the broader assurance stack, not in isolation. For regulated IAM programmes, that means linking adaptive MFA with phishing-resistant authenticators, privileged access controls, and identity lifecycle processes. The organisations that succeed will treat authentication as one part of a larger assurance chain, not as the endpoint.

For practitioners

• Define step-up triggers by risk tier Separate low-risk access from high-risk access using managed device status, location, user role, and resource sensitivity. Document which combinations require passkey, hardware token, or additional verification, and keep the logic consistent across major workflows. suggested_anchor
• Bind stronger authenticators to privileged workflows Use phishing-resistant methods for administrative actions, payment approvals, clinical record access, and other high-impact events. Do not rely on the same prompt for every session when the transaction value or data sensitivity changes. suggested_anchor
• Review exception paths and login fatigue Track bypass requests, repeated prompts, and help-desk overrides to identify where static policies are causing unsafe behaviour. Reduce friction only where the policy remains defensible, and tighten it where exceptions become habitual. suggested_anchor
• Align policy decisions with audit evidence Log the signals that drove each step-up decision so auditors can see why a session received stronger verification. Tie the control to regulated workflows such as payments, ePHI access, and privileged administration. suggested_anchor

Key takeaways

• Adaptive MFA works because it matches authentication strength to actual session risk instead of treating every login as equally sensitive.
• Regulated industries need step-up policies they can explain, audit, and defend, especially for privileged access and high-impact transactions.
• The real control issue is not the prompt itself, but the quality of the signals and the governance behind the decision.

Key terms

• Adaptive MFA: Adaptive MFA is an authentication approach that changes the challenge based on session risk. It uses contextual signals such as device health, location, role, and resource sensitivity to decide whether a user can continue or must prove identity again with a stronger factor.
• Step-Up Authentication: Step-up authentication is an extra verification step triggered when risk rises during access or transaction flow. In regulated environments, it is used to protect privileged actions, sensitive records, and high-value transactions without applying the same friction to every session.
• Risk-Based Authentication: Risk-based authentication is a policy model that scores or classifies login conditions before choosing how much assurance to require. It helps organisations balance security and usability, but only works well when the underlying signals are trustworthy and the policy is auditable.
• Phishing-Resistant Authenticator: A phishing-resistant authenticator is a method that is designed to resist credential interception and prompt manipulation. In practice, this usually means passkeys or hardware-backed methods that do not rely on reusable secrets or easily proxied one-time prompts.

What's in the full article

eMudhra's full article covers the operational detail this post intentionally leaves for the source:

• Policy examples for banking, healthcare, and government access paths
• eMudhra's compliance mapping across RBI, PSD2, HIPAA, FedRAMP, and NIS2
• SecurePass authentication method combinations, including FIDO2, TOTP, biometric push, and hardware tokens
• Implementation framing for converged IAM, PAM, and PIM architectures

👉 The full eMudhra article covers sector-specific policy examples and compliance mapping.

Deepen your knowledge

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