PA-05: Requiring Phishing-Resistant MFA for Privileged Users

Overview

This guide walks you through requiring phishing-resistant MFA methods (FIDO2 security keys, Windows Hello for Business, or Passkeys) for all users with privileged administrative roles. Traditional MFA methods like SMS, voice calls, and even authenticator push notifications can be bypassed by sophisticated phishing attacks. Phishing-resistant MFA eliminates these attack vectors.

Why This Matters: Advanced attacks like real-time phishing proxies (Evilginx, Modlishka) and MFA fatigue attacks can bypass traditional MFA. Privileged accounts are the primary targets for these attacks. Phishing-resistant MFA using FIDO2/WebAuthn is cryptographically bound to the legitimate site, making these attacks impossible.

Prerequisites

RequirementDetails
Role RequiredGlobal Administrator, Authentication Policy Administrator, or Conditional Access Administrator
License RequiredMicrosoft Entra ID P1 (for Conditional Access authentication strength)
AccessMicrosoft Entra admin center
HardwareFIDO2 security keys or Windows Hello-capable devices for privileged users

Time Estimate

45-60 minutes for policy configuration, plus hardware provisioning time

  • Authentication strength configuration: 10 minutes
  • Conditional Access policy creation: 15-20 minutes
  • User communication: 10 minutes
  • Testing and verification: 15 minutes
  • Hardware provisioning: Additional time based on organization size

Understanding Phishing-Resistant MFA Methods

MethodPhishing Resistant?How It Works
FIDO2 Security KeyYesCryptographic key bound to origin (website URL)
Windows Hello for BusinessYesBiometric/PIN with hardware-backed credential
Microsoft Authenticator PasskeyYesDevice-bound passkey (iOS/Android)
Certificate-based AuthYesSmart card or certificate credential
SMS/Voice OTPNoCan be intercepted or SIM-swapped
Authenticator PushNoSusceptible to MFA fatigue attacks
Authenticator TOTPNoCan be phished in real-time

Step-by-Step Instructions

Step 1: Enable Phishing-Resistant Authentication Methods

First, ensure FIDO2 and/or Passkey methods are enabled tenant-wide:

Enable FIDO2 Security Keys:

  1. Navigate to entra.microsoft.com
  2. Go to Protection > Authentication methods > Policies
  3. Click FIDO2 security key
  4. Set Enable to Yes
  5. Under Target, select:
    • All users (recommended for future-proofing), OR
    • Select users and groups (to limit to admins initially)
  6. Configure optional settings:
SettingRecommendation
Allow self-service set upYes
Enforce attestationNo (unless you require specific vendors)
Enforce key restrictionsNo (unless blocking specific keys)
  1. Click Save

Enable Microsoft Authenticator Passkeys:

  1. Go to Authentication methods > Policies
  2. Click Microsoft Authenticator
  3. Set Enable to Yes
  4. Under Configure, find Authentication mode
  5. Select Any or Passwordless to enable passkeys
  6. Enable Allow passkey (FIDO2) in the additional settings
  7. Click Save

Enable Windows Hello for Business (if applicable):

This is typically configured via Intune/Group Policy. If using cloud-only:

  1. Go to Devices > Windows > Windows Hello for Business
  2. Configure settings as appropriate for your organization

Step 2: Create an Authentication Strength Policy

Authentication strength policies let you require specific MFA methods in Conditional Access:

  1. Go to Protection > Authentication methods > Authentication strengths
  2. Click + New authentication strength
  3. Configure:
SettingValue
NamePhishing-Resistant MFA for Admins
DescriptionRequires FIDO2, Windows Hello, or Passkey authentication for privileged users
  1. Under Allowed authentication methods, select ONLY:

    • FIDO2 security key
    • Windows Hello for Business
    • Passkey (Microsoft Authenticator)
    • Certificate-based authentication (if using smart cards)
  2. Ensure these are NOT selected:

    • SMS
    • Voice call
    • Microsoft Authenticator (push notification)
    • Software OATH tokens
    • Hardware OATH tokens
  3. Click Next

  4. Review and click Create

Step 3: Create Conditional Access Policy for Privileged Users

  1. Go to Protection > Conditional Access > Policies
  2. Click + New policy
  3. Configure:

Name: Require Phishing-Resistant MFA for Privileged Users

Users:

  • Under Include, select Select users and groups

  • Check Directory roles

  • Select all privileged roles:

    • Global Administrator
    • Privileged Role Administrator
    • Privileged Authentication Administrator
    • Security Administrator
    • Exchange Administrator
    • SharePoint Administrator
    • User Administrator
    • Application Administrator
    • Cloud Application Administrator
    • Authentication Administrator
    • Intune Administrator
  • Under Exclude:

    • Check Users and groups
    • Select your emergency access accounts
    • (Emergency accounts should use FIDO2 but need exclusion as backup)

Target resources:

  • Under Include, select All cloud apps

Conditions:

  • Leave at defaults (all conditions)

Access controls - Grant:

  • Select Grant access
  • Check Require authentication strength
  • Select Phishing-Resistant MFA for Admins (the policy you created)
  • Click Select

Session:

  • Leave at defaults

Enable policy:

  • Start with Report-only to verify impact
  • After verification, change to On
  1. Click Create

Step 4: Verify Policy Impact with Report-Only Mode

Before enforcing the policy:

  1. Go to Protection > Conditional Access > Insights and reporting

  2. Select your new policy

  3. Set the time range to cover your testing period

  4. Review which sign-ins would be blocked:

    • Users without FIDO2/Windows Hello/Passkey registered
    • Users attempting to use non-compliant MFA methods
  5. Identify users who need hardware keys provisioned

Step 5: Communicate with Affected Users

Send notification to all privileged users:

Subject: New Security Requirement - Phishing-Resistant Authentication

Effective [Date], all users with administrative privileges will be required to use phishing-resistant authentication methods when signing in. This is a critical security enhancement to protect against advanced attacks.

What This Means For You:

  • You must use a FIDO2 security key, Windows Hello, or Microsoft Authenticator passkey to sign in
  • SMS codes, voice calls, and regular authenticator notifications will not be accepted

What You Need To Do:

  1. [If providing hardware keys] Pick up your security key from [location/person]
  2. Register your security key at mysignins.microsoft.com > Security info
  3. Test signing in with your new key before [enforcement date]

Need Help? Contact IT Support at [email/phone] for assistance with setup.

Why This Change? Phishing-resistant authentication stops sophisticated attacks that can bypass traditional MFA. As an administrator, your account is a high-value target. This change significantly reduces the risk of your account being compromised.

Step 6: Provision Security Keys (If Needed)

If users don't have compatible methods:

For FIDO2 Security Keys: See PA-06: Hardware Security Keys for detailed provisioning guidance.

Quick provisioning steps:

  1. Purchase FIDO2-certified security keys (YubiKey, Feitian, etc.)
  2. Distribute to privileged users
  3. Users register at mysignins.microsoft.com > Security info

For Windows Hello for Business:

  • Ensure users have compatible Windows devices (Windows 10/11 with TPM)
  • Enable Windows Hello via Intune or Group Policy
  • Users complete setup at next Windows sign-in

For Microsoft Authenticator Passkeys:

  • Users need Microsoft Authenticator app (latest version)
  • Enable passkey in the app settings
  • Register at mysignins.microsoft.com > Security info

Step 7: Enable the Policy

Once all privileged users have registered compliant methods:

  1. Go to Protection > Conditional Access > Policies
  2. Click your phishing-resistant MFA policy
  3. Change Enable policy from Report-only to On
  4. Click Save

Step 8: Monitor and Maintain

Set up ongoing monitoring:

  1. Go to Monitoring & health > Sign-in logs
  2. Add filter: Conditional Access > Failure or Not applied
  3. Review any failures related to authentication strength

Create an alert for policy violations:

  1. Go to Azure Monitor > Alerts
  2. Create an alert for sign-in failures due to authentication strength requirements
  3. Notify security team

Verification Checklist

  • FIDO2 security key authentication method is enabled
  • Microsoft Authenticator passkeys are enabled (optional)
  • Windows Hello for Business is configured (if applicable)
  • Custom authentication strength policy is created (phishing-resistant methods only)
  • Conditional Access policy targets all privileged directory roles
  • Emergency access accounts are excluded from the policy
  • Policy tested in Report-only mode with no unexpected impact
  • All privileged users have registered a compliant authentication method
  • Users have tested signing in with their new method
  • Policy is enabled (changed from Report-only to On)
  • Monitoring is configured for authentication failures

Troubleshooting

"User can't sign in - authentication method not accepted"

  1. Verify the user has registered a phishing-resistant method:
    • Go to Users > [user] > Authentication methods
    • Check for FIDO2, Windows Hello, or Passkey registration
  2. If not registered, have user add method at mysignins.microsoft.com
  3. Temporarily exclude user from policy while they register (with documented approval)

"FIDO2 key not recognized during sign-in"

  1. Check browser compatibility (Edge, Chrome, Firefox support WebAuthn)
  2. Try different USB port
  3. Ensure key is FIDO2-certified (not just U2F)
  4. Have user re-register the key:
    • Go to mysignins.microsoft.com > Security info
    • Remove old key
    • Add new key

"Windows Hello prompts but policy still blocks"

  1. Verify Windows Hello for Business is configured (not just Windows Hello):
    • Check device is Entra joined or hybrid joined
    • Verify TPM attestation is working
  2. Check policy includes Windows Hello for Business in authentication strength
  3. Review sign-in logs for specific failure reason

"User lost their security key"

  1. Have user sign in using backup method (if they have one registered)
  2. If no backup, temporarily exclude from policy (documented)
  3. Revoke lost key: Users > [user] > Authentication methods > delete the key
  4. Issue new security key
  5. User registers new key and re-enable policy

"Sign-in failing for service accounts/apps"

  1. Service accounts should not be using interactive sign-in
  2. If they are, consider:
    • Moving to managed identities
    • Using certificate-based authentication
    • Excluding from this specific policy with compensating controls

Cost Considerations

ComponentCost Impact
Entra ID P1 LicenseRequired for Conditional Access authentication strength. ~$6/user/month standalone, included in M365 E3/E5, EMS E3/E5
FIDO2 Security Keys$25-70 per key depending on vendor and features
Backup KeysRecommend 2 keys per user = 2x hardware cost
Windows HelloFree (hardware-dependent - requires TPM)
Authenticator PasskeysFree (requires compatible smartphone)

Cost Example for 10 Privileged Users:

  • P1 licenses (if not already licensed): 10 x $6 = $60/month
  • YubiKey 5 NFC ($50 each, 2 per user): 20 x $50 = $1,000 one-time
  • Annual cost: ~$720 licenses + $1,000 hardware = $1,720 first year

Rollout Strategy

For organizations with many privileged users, consider a phased rollout:

PhaseScopeDuration
Pilot2-3 IT admins who will support rollout1 week
Phase 1Global Admins and Privileged Role Admins1 week
Phase 2Security Admins, User Admins1 week
Phase 3All remaining privileged roles1-2 weeks
Full EnforcementPolicy enabled for allOngoing

Related Controls

Additional Resources