Manage MFA, passkeys, and self-service password reset in Microsoft Entra ID

How can MFA, Passkeys, and Self-Service Password Reset be implemented so that users can log in securely and the helpdesk can provide controlled assistance in case of device loss? First, the Authentication Methods Policy defines which methods are allowed for which groups. Then, registration, Conditional Access, Self-Service Password Reset, and recovery are designed as a unified process. Temporary Access Pass can support time-limited, strong initial or re-registration.

"MFA enabled" is not a complete description. For operations, it must be known which method can be used as the first factor, as an additional factor, or for SSPR. Microsoft lists these capabilities separately by method. Not every method fulfills every purpose.

Distinguish authentication and authorization

Authentication answers: Who is logging in and how is the identity verified?

Authorization answers: Which resource is the identity allowed to access?

MFA or a Passkey does not grant permission. Conditional Access can require strong authentication, while roles, groups, or app assignments determine the actual access.

Authentication methods policy as control point

For new and cleaned configurations, the Authentication Methods Policy should be the primary control point. It must be clearly documented which groups are allowed to use which method for login, MFA, or recovery. Old MFA or SSPR individual configurations should not be continued in parallel as shadow logic.

The Authentication Methods Policy defines which groups are allowed to use which methods. Typical methods include:

• Microsoft Authenticator,
• Passkeys/FIDO2 security keys,
• Windows Hello for Business,
• Certificate-Based Authentication,
• Temporary Access Pass,
• SMS or phone call,
• Software-OATH and other supported methods.

Microsoft recommends phishing-resistant methods such as Windows Hello for Business, Passkeys/FIDO2, or certificate-based authentication for high security. Which method is practically suitable depends on devices, platforms, user groups, and the recovery process.

Assess passkeys and FIDO2

Passkeys or FIDO2 can generally be used in all Microsoft Entra editions. However, if a specific Authentication Strength is enforced via Conditional Access, Entra ID P1 is typically required.

Passkeys use cryptographic key pairs and are more resistant to classic phishing attacks than passwords plus verified push. Microsoft Entra supports various Passkey/FIDO2 scenarios, including security keys and supported device or Authenticator variants.

Before a rollout, check:

• supported operating systems and browsers,
• devices used jointly or personally,
• mobile and desktop login,
• Number of allowed keys per user,
• Loss and replacement procedures,
• Registration without an existing strong method,
• Conditional-Access-Authentication-Strength.

Error scenario: orphaned passkey

A passkey may still exist on a device even after its registration has been removed from Entra. The user might then see an entry that no longer works. Delete the outdated registration carefully on both sides and register again.

Microsoft authenticator

Authenticator can support push-based MFA, passwordless sign-in, or passkey features, depending on configuration and platform. Number Matching and additional context information strengthen push confirmation but do not eliminate every social engineering risk.

Operationally relevant are:

• Device change,
• Backup and recovery behavior,
• Multiple accounts in Authenticator,
• Users with limited smartphone access,
• App protection and device security,
• Registration and deletion of old methods.

Temporary Access Pass

The TAP method itself is also controlled via the Authentication Methods Policy. Changes to this policy require an appropriate administrative role such as Authentication Policy Administrator; issuing a TAP for a user then belongs in a narrowly defined helpdesk or authentication process with documented identity verification.

Temporary Access Pass, or TAP, is a time-limited passcode that authorized administrators can issue for a user. It can support sign-in and registration of strong methods without providing the user with a permanent replacement password.

A TAP process requires:

• Authorized helpdesk or authentication role,
• Reliable identity verification,
• Short, appropriate validity period,
• Decision on single or multiple use,
• Secure delivery,
• Logging,
• subsequent verification of the registered method.

A TAP is not a universal password replacement. Microsoft documents limitations, such as in specific password change scenarios.

Self-service password reset

SSPR enables authorized users to reset their own passwords when the configured verification requirements are met. In hybrid environments, additional prerequisites may apply for Password Writeback.

To plan:

• target groups,
• required number of methods,
• allowed methods,
• registration and regular review,
• helpdesk procedures when methods are missing,
• hybrid dependencies,
• notifications upon reset.

SSPR reduces support effort only when users are registered and still possess the methods. Therefore, the registration process is more important than simply activating the feature.

Combined registration

Microsoft Entra provides a unified user interface for MFA and SSPR security information. The available methods are determined by the Authentication Methods Policy and the respective features.

A rollout includes:

1. pilot group,
2. clear user instructions,
3. secured registration location or Conditional Access rule,
4. helpdesk preparation,
5. analysis of failed registrations,
6. gradual expansion.

Microsoft documents special requirements when adding or changing Passkeys, including current strong authentication. Registration sessions may be time-limited.

Secure first registration of new users

A new account does not yet have a strong method. Possible approach:

1. HR or onboarding process confirms identity.
2. Administrator creates a short-lived TAP.
3. TAP is transmitted via a separate, authorized channel.
4. User logs in and registers a passkey, Authenticator, or other intended method.
5. User confirms successful login.
6. Helpdesk checks that no unexpected methods were registered.
7. TAP expires or is removed.

An initial password via unencrypted email is not an equivalent process.

Users without a smartphone

Not every user can or is allowed to use a personal smartphone. Alternatives can be:

• FIDO2 security key,
• Windows Hello for Business on a managed device,
• certificate-based authentication,
• other supported hardware or enterprise solutions.

The selection must fit the workplace, devices, accessibility, and support. A pure SMS exception should not automatically become the long-term solution.

Device loss or smartphone change

Standard process

1. User reports loss via an authorized channel.
2. Helpdesk verifies identity according to established procedure.
3. existing sessions are revoked if there is risk.
4. lost authentication method is removed.
5. temporary access is provided under control.
6. a new strong method is registered.
7. sign-in is tested.
8. the process and the admin identity used are documented.

Identity verification

The helpdesk should not rely solely on information that an attacker can easily know. Appropriate procedures can combine internal callbacks, verified manager contacts, personal verification, or existing company processes. The specific method must match the risk class and be compliant with data protection regulations.

Roles for the helpdesk

Not every helpdesk employee needs Privileged Authentication Administrator. Microsoft distinguishes roles for normal and privileged users. The Role Model for Microsoft Entra Administrator Roles should be reviewed:

• which user groups are supported,
• whether administrative accounts are excluded,
• whether Administrative Units can limit the scope,
• whether PIM activation is required,
• which actions appear in the audit.

Conditional Access and authentication strength

Authentication Strengths are a Conditional Access mechanism and therefore not a standalone replacement for method control. Anyone who wants to enforce phishing-resistant sign-ins must therefore consider both the allowed methods and the required CA licensing together.

Conditional Access can require MFA or a defined Authentication Strength. This allows a phishing-resistant method to be required for privileged access, while other scenarios are handled differently.

Before activation:

• check whether all target users have a compatible method,
• test registration and recovery,
• configure Emergency Access accounts,
• use Report-only and Pilot,
• examine old clients and protocols.

Typical failure patterns

User does not receive offered method

Possible causes:

• not in the target audience of the Authentication Methods Policy,
• the method is not supported for the purpose,
• Conditional Access blocks registration,
• the platform or browser does not support the process,
• the user already has the maximum number of registrations or conflicting registrations.

SSPR does not work even though MFA is registered

MFA and SSPR eligibility for a method are not identical. Check the current method table, SSPR target audience, number of required methods, and hybrid writeback dependencies.

New smartphone, no access to old device

Use the documented recovery process. Remove old methods only after identity verification. Provide TAP or alternative strong registration. Do not disable MFA for the entire user group en masse.

MFA push is requested multiple times

Check the sign-in log, Conditional Access policies, session controls, client tokens, and suspicious sign-in attempts. If an attack is possible, revoke sessions and re-evaluate credentials and methods.

Passkey works in one app but not in another

Support may depend on the platform, browser, native app, and authentication flow. Test the real application matrix instead of just the My Account portal.

Fallback paths

• second registered strong factor,
• FIDO2 backup key,
• time-limited TAP after identity verification,
• Helpdesk reset of the method with the appropriate role,
• Emergency Access procedure for administrators,
• limited pilot exception for a proven client issue.

Every fallback must be time-limited and closed after successful recovery.

Test catalog

1. new user registration with TAP,
2. sign-in with passkey,
3. Sign in with Authenticator,
4. SSPR with the designated methods,
5. smartphone replacement,
6. lost security key,
7. users without a smartphone,
8. privileged administrator with stronger requirements,
9. registration from an untrusted network,
10. helpdesk reset with a restricted role,
11. locked or disabled account,
12. revoke session and sign in again.

Operational metrics

• proportion of registered target users,
• proportion of phishing-resistant methods,
• number of recovery cases,
• TAP issuances and validity duration,
• failed registrations,
• old or duplicate methods,
• users without a fallback method,
• helpdesk interventions on privileged accounts.

If strong authentication methods are to be enforced in production, the next step usually builds on Conditional Access in Microsoft Entra ID. For administrators, the article Emergency Access for Microsoft 365 remains relevant as well.

How to keep strong authentication manageable even in support scenarios

Strong authentication works in daily operations only with an equally robust registration and recovery process. Method groups, passkeys, TAP, SSPR, helpdesk roles, and Conditional Access must be planned together. This ensures the organization remains capable of acting even with a new device, a lost key, or a missing initial registration, without broadly disabling security requirements.