Microsoft Security · Identity and access

Phishing-resistant MFA: prepare a rollout without locking users out

A user can have MFA configured and still be vulnerable to a fake sign-in page. Rolling out phishing-resistant MFA therefore takes more than counting registered methods. You need to establish which credential each person uses, which devices they work from and what happens when their usual method becomes unavailable.

This guide focuses on preparing and validating a deployment in Microsoft Entra. The aim is to reduce exposure to credential theft while creating an operation your team can maintain. The proposed tests, owners and acceptance criteria below are practical recommendations, rather than universal Microsoft requirements. Adapt them to your applications and the consequences of losing access.

Phishing-resistant MFA: what changes in practice

A password and a code entered into a fraudulent website can end up in an attacker’s hands. Phishing resistance aims to bind authentication to the legitimate service. That changes what your IT team needs to test. Confirming that an additional prompt appears is insufficient. Identify the method accepted by the policy and verify that the sign-in completes in its intended context.

Microsoft provides authentication strengths with different requirements. The MFA strength, passwordless MFA strength and phishing-resistant MFA strength are different controls. Approving a conventional Microsoft Authenticator notification does not, by itself, mean the user has used a phishing-resistant method. A passkey in the same application is a different method from a conventional push notification.

Supported options include FIDO2 passkeys, Windows Hello for Business and certificate-based authentication configured for multifactor use. The choice depends on your environment. A physical security key may suit an administrator who changes computers. Windows Hello for Business may fit a managed personal workstation. Certificates require infrastructure and a lifecycle that the organisation can reliably operate.

Passkeys can be bound to a device or synchronised through a provider. The same custody requirements may not suit every user profile. For privileged accounts, review whether device-bound credentials are needed and which providers are acceptable. Check the current passkey profile options in your tenant. This capability evolves, and instructions based on old screens can miss relevant controls or supported choices.

Start with actual access, before buying security keys

Build an inventory by user, device and application combination. Someone may work from a managed laptop, check Teams on a phone and occasionally connect through a virtual desktop. Success on the laptop does not validate the other two cases. Include separate administrative accounts, shared workstations, remote employees, contractors and devices that the company does not manage.

For each combination, record the operating system, browser or client, available method, device owner and business application. You do not need a huge spreadsheet containing every technical detail. You need enough information to identify ready cases, cases requiring work and cases with no evidence yet. Separate critical applications from those that can tolerate a short interruption during a planned change.

Check authentication method policies and their included or excluded groups. Being able to register a credential and being able to use it are separate checks. Review existing Conditional Access policies too. Users in several groups may receive cumulative requirements that are easy to miss when inspecting only one policy. Document these dependencies before introducing another access requirement.

Licences and permissions before the pilot

Verify licensing for Conditional Access and any additional capabilities you intend to use. A menu being visible in the portal does not establish that everyone in scope is appropriately licensed. Assign tasks with the minimum necessary privilege. Distinguish who can configure methods, who can issue onboarding credentials and who can change access policies.

Establish a baseline as well: methods currently used, applications with existing failures and the support requests your team already receives. This reference helps separate new incidents from pre-existing problems. Recording intermittent application access failures beforehand prevents every issue during the pilot from being attributed to the MFA deployment. Include known limitations in the change record.

Registration and onboarding: the work that often gets missed

An email saying “register your security key” does not ensure safe onboarding. Define how the person’s identity will be verified, where they receive instructions and what assistance is available. The communication should identify the service, explain the change and use a known support channel. Avoid training people to trust unexpected links or give codes to someone who calls them.

Temporary Access Pass, or TAP, can help with onboarding and recovery of passwordless methods. It is a temporary credential that needs an enabled policy and a secure delivery procedure. Do not treat it as a courtesy password support can issue without verifying the requester. Record who authorised it and subsequently confirm that the user registered the intended method.

Rehearse the complete registration process with people outside the security team. Check what they see when a key is disconnected, when a browser offers several credentials and when they use an administrative account different from their everyday account. Technically correct instructions can still be confusing if the screen offers names or choices the procedure never explains.

Complete onboarding with a new sign-in. Successful registration does not prove access from Outlook, Teams, an administration portal or an internal application. Confirm the result in the logs. An existing session or previously issued token can hide a problem that becomes visible only when authentication is renewed, possibly hours after the support team considers registration finished.

Design a pilot that can fail under controlled conditions

Select a small but representative group. Include someone who travels, a person using a critical application, an administrator and a shared or virtual device scenario where relevant. Coverage matters more than size. A pilot made up entirely of technicians with new computers creates confidence that may not translate to the wider workforce and its everyday working conditions.

Before enforcement, review the policy in report-only mode and use the available evaluation tools. These results help identify scope and requirements, but do not replace a real test of the authentication method. For that stage, see our guide to validating Conditional Access in report-only. Both articles belong to the same operational security series.

When you enforce the policy for the pilot, test a new sign-in from every planned combination. Record the test user, time, application, device, method and applied policy. Keep secrets out of the evidence. The useful question is whether the new requirement was satisfied and the person completed their work, rather than whether a single screen displayed a successful result.

Positive and negative tests

A positive test shows that a permitted method works. A negative test checks that an insufficient method cannot satisfy the required authentication strength. Use accounts and resources prepared for the exercise. Avoid improvised tests that could leave an administrator without access. Write the expected outcome for each case before carrying out the test, including how to restore the test environment.

Include a different browser, signing out, a replacement computer and loss of the primary method. For virtual desktops and remote connections, validate the specific flow and requirements for redirection or authentication across devices. Do not assume that a key physically connected to a laptop can be used in the same way inside every remote session.

For guests, check the home tenant, collaboration model and cross-tenant policies. An internal employee’s experience does not validate an external user’s experience. If an application depends on partners, make that scenario an acceptance condition of its own. The solution may involve coordination with another organisation, rather than a permanent exception in your tenant that weakens the intended protection.

Recovery is part of security too

Losing a key or phone should not force support to remove the security requirement for the entire user account. Prepare a backup method that satisfies the policy where possible and an identity recovery procedure. Rehearse who authorises recovery, how a temporary credential is delivered and which lost method must be removed. Make the procedure accessible during a real outage.

Properly designed recovery leaves an audit trail and a verified final state. The ticket should not close when the TAP is issued. Confirm new registration, access to the resource and removal of the method that should no longer be used. Where theft or misuse is suspected, involve the responsible team in investigating sessions and activity as part of the incident response.

Emergency access accounts require specific handling: protected credentials, phishing-resistant authentication, alerts and periodic testing. They are not unprotected accounts. Review Microsoft’s guidance and maintain their availability independently of restrictive policies that might prevent access during an emergency. An account nobody has tested represents an intention, rather than a demonstrated recovery capability your team can rely on.

Support and communication that make expansion possible

Prepare a short user guide and a separate support procedure. The first should explain what changes in the working day and what to do when the method is unavailable. The second needs diagnostic questions: account, device, application, time of failure and displayed message. A screenshot may help, provided it does not include codes, credentials or information that should not be circulated.

Reserve support capacity during the first window of each wave. Training is no substitute for someone who can resolve incomplete registration or a compatibility problem. Use a known contact channel. Avoid scheduling the change during travel, financial closing or widespread device replacements. Choose timing based on operational readiness as well as the urgency of improving security.

Explain what users should avoid: sharing the key, approving a request they did not initiate or providing a code to an unexpected caller. The announcement does not need to become a catalogue of threats. A brief example and a clear route to assistance are often more useful than a long message nobody can find when they encounter a problem.

What evidence makes a wave ready to expand?

Set acceptance criteria beforehand. At a minimum, critical cases need a documented expected outcome, access must be confirmed with the intended method and recovery must have been rehearsed. Application owners should validate that work can be completed. Security should review exceptions, while support should recognise the most common failure patterns and know where to escalate unusual cases.

• An inventory of tested combinations and outstanding scenarios.
• Logs identifying the method and applied policy.
• A backup or recovery test with a documented result.
• Exceptions with owners and review dates.
• A person responsible for the next wave and conditions for stopping it.

Do not choose a success percentage that hides a single critical failure. If ninety people can work but the recovery administrator cannot sign in, the wave is not ready. Review the importance of each scenario alongside the numbers. Aggregated data helps reveal patterns, but the decision also depends on the impact of the outstanding cases and the available recovery options.

A practical decision example

Consider a company with managed laptops and salespeople accessing resources from phones. The pilot validates the laptops but finds that some phones lack the permitted method. A reasonable decision would be to expand only to validated combinations, assist with mobile registration and maintain a visible list of outstanding cases. A hidden exception does not mean that the project has reached its objective.

After each wave, compare incidents with the baseline and review the policies actually applied. If an exclusion leaves more people outside the policy than intended, stop expansion and correct the scope. The final handover should cover joiners, leavers and device changes. Otherwise, coverage starts to deteriorate as soon as new employees arrive or existing users replace their equipment.

Who maintains the control after deployment?

Assign an owner to review coverage when groups change, applications are introduced or devices are replaced. Maintenance should check methods actually used and exceptions still open. Include that review in routine administration and retain a brief record of the decisions. A well-executed deployment can lose effectiveness months later if new starters follow a different procedure or a temporary exclusion remains without supervision.

Include a support handover with a worked example of a successful sign-in and an example of an expected rejection. Record where the operator finds the relevant policy and method evidence. This makes diagnosis less dependent on the person who originally configured the pilot. Schedule a short review after the first normal business cycle to check whether support demand, outstanding device scenarios and recovery requests match the assumptions used when approving expansion.

Official documentation for checking the configuration

• Authentication strengths
• Planning a phishing-resistant deployment
• Temporary Access Pass
• Synced passkeys
• Emergency access accounts