How do teams decide when to keep traditional MFA alongside Windows Hello for Business?

When should traditional MFA stay in the sign-in flow?

traditional mfa should remain when you need a stronger step-up than the passwordless flow normally delivers, such as enrollment, recovery, admin elevation, shared-device access, or hardware-token-only use cases. It also stays relevant where a business application, regulatory requirement, or risk posture still expects a second factor beyond the windows hello for business session.

That decision is less about whether passwordless works and more about whether the assurance level is sufficient for the specific workflow. Teams usually keep both options during transition periods, because different users, devices, and applications do not reach the same state at the same time.

For example, if a user has not yet completed a trusted device registration, or if the workflow involves account recovery, support-assisted resets, or a high-value administrative action, traditional MFA may still be the safer control. Windows Hello for Business can reduce routine friction, but it does not remove the need to validate identity or satisfy a policy that explicitly requires MFA.

How do teams decide by risk, enrolment state, and app sensitivity?

The practical decision is to classify each use case by assurance need. If the user is fully enrolled, the device is trusted, and the application can tolerate passwordless assurance, Windows Hello for Business can become the default. If any of those conditions is missing, keep traditional MFA as the fallback or required path.

Enrolment state matters because many failures happen before the passwordless method is even available. New joiners, re-provisioned users, lost-device recoveries, and temporary exceptions often need a control that works before the stronger auth method is established. In those scenarios, MFA is not a legacy holdover, it is the control that makes access possible without lowering assurance too far.

Application sensitivity is the other deciding factor. General productivity apps may accept passwordless sign-in, while finance, production administration, privileged access, or regulated workflows may require step-up checks, reauthentication, or a hardware-backed factor. The more damaging a mistaken approval would be, the less comfortable teams should be with convenience alone as the deciding criterion.

What does a sensible mixed model look like in practice?

A stable approach is to treat Windows Hello for Business as the preferred everyday method and keep traditional MFA for exceptions and higher-trust transitions. That usually means allowing both methods, then applying policy by user group, device posture, application, or risk signal so that the right method appears at the right time.

Teams also need explicit rules for support, recovery, and privileged workflows. If help desk reset, new-device enrolment, or administrative elevation depends on identity proofing or a second approval step, MFA should remain available even when the main workforce experience is passwordless. This avoids forcing one authentication pattern into every scenario.

Clear communication matters as much as policy design. If users think passwordless means “MFA is gone,” they may bypass important controls in edge cases, mis-handle recovery, or treat step-up prompts as unnecessary friction. The mixed model works best when users understand that assurance is being matched to the task, not removed from the system.

Risk and Threat Considerations

Keeping both methods can create confusion if teams do not define when each method is required. The main risk is not the coexistence itself, but inconsistent enforcement that lets lower-assurance sign-in slip into high-value actions or recovery flows.

Failure mechanism: If policy does not distinguish enrollment, recovery, privileged access, and normal sign-in, attackers can target the weakest path, such as social engineering a reset, hijacking a support flow, or using the easier method where stronger assurance should have been mandatory.

Impact: The result can be account takeover, privilege escalation, or a bypass of the intended assurance level for sensitive applications and admin workflows.

Practitioner Guidance

What to verify: Check that each application and workflow has a named assurance requirement, not just a global MFA rule. The common failure is assuming a passwordless default covers enrolment, recovery, and privilege elevation automatically.

Decision rule: If the workflow involves first-time registration, support-assisted recovery, shared access, or elevated privilege, keep traditional MFA or another stronger step-up path available. If the user is fully enrolled and the application is low sensitivity, make Windows Hello for Business the preferred path.

What good looks like: Users see passwordless as the normal case, while traditional MFA appears only where the risk or policy explicitly justifies it. That is a better control model than trying to eliminate MFA everywhere at once.

Practitioner takeaway: The right question is not “Can we remove MFA?”, but “Where does the workflow still need an additional assurance step?”

Related resources from NHI Mgmt Group

• How should security teams roll out Windows Hello for Business without weakening MFA governance?
• How should organisations decide whether to keep using traditional MFA?
• What do security teams get wrong about Windows Hello for Business?
• How do teams decide whether to keep SMS MFA during an identity migration?