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
| Requirement | Details |
|---|---|
| Role Required | Global Administrator, Authentication Policy Administrator, or Conditional Access Administrator |
| License Required | Microsoft Entra ID P1 (for Conditional Access authentication strength) |
| Access | Microsoft Entra admin center |
| Hardware | FIDO2 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
| Method | Phishing Resistant? | How It Works |
|---|---|---|
| FIDO2 Security Key | Yes | Cryptographic key bound to origin (website URL) |
| Windows Hello for Business | Yes | Biometric/PIN with hardware-backed credential |
| Microsoft Authenticator Passkey | Yes | Device-bound passkey (iOS/Android) |
| Certificate-based Auth | Yes | Smart card or certificate credential |
| SMS/Voice OTP | No | Can be intercepted or SIM-swapped |
| Authenticator Push | No | Susceptible to MFA fatigue attacks |
| Authenticator TOTP | No | Can 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:
- Navigate to entra.microsoft.com
- Go to Protection > Authentication methods > Policies
- Click FIDO2 security key
- Set Enable to Yes
- Under Target, select:
- All users (recommended for future-proofing), OR
- Select users and groups (to limit to admins initially)
- Configure optional settings:
| Setting | Recommendation |
|---|---|
| Allow self-service set up | Yes |
| Enforce attestation | No (unless you require specific vendors) |
| Enforce key restrictions | No (unless blocking specific keys) |
- Click Save
Enable Microsoft Authenticator Passkeys:
- Go to Authentication methods > Policies
- Click Microsoft Authenticator
- Set Enable to Yes
- Under Configure, find Authentication mode
- Select Any or Passwordless to enable passkeys
- Enable Allow passkey (FIDO2) in the additional settings
- Click Save
Enable Windows Hello for Business (if applicable):
This is typically configured via Intune/Group Policy. If using cloud-only:
- Go to Devices > Windows > Windows Hello for Business
- 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:
- Go to Protection > Authentication methods > Authentication strengths
- Click + New authentication strength
- Configure:
| Setting | Value |
|---|---|
| Name | Phishing-Resistant MFA for Admins |
| Description | Requires FIDO2, Windows Hello, or Passkey authentication for privileged users |
-
Under Allowed authentication methods, select ONLY:
- FIDO2 security key
- Windows Hello for Business
- Passkey (Microsoft Authenticator)
- Certificate-based authentication (if using smart cards)
-
Ensure these are NOT selected:
- SMS
- Voice call
- Microsoft Authenticator (push notification)
- Software OATH tokens
- Hardware OATH tokens
-
Click Next
-
Review and click Create
Step 3: Create Conditional Access Policy for Privileged Users
- Go to Protection > Conditional Access > Policies
- Click + New policy
- 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
- Click Create
Step 4: Verify Policy Impact with Report-Only Mode
Before enforcing the policy:
-
Go to Protection > Conditional Access > Insights and reporting
-
Select your new policy
-
Set the time range to cover your testing period
-
Review which sign-ins would be blocked:
- Users without FIDO2/Windows Hello/Passkey registered
- Users attempting to use non-compliant MFA methods
-
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:
- [If providing hardware keys] Pick up your security key from [location/person]
- Register your security key at mysignins.microsoft.com > Security info
- 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:
- Purchase FIDO2-certified security keys (YubiKey, Feitian, etc.)
- Distribute to privileged users
- 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:
- Go to Protection > Conditional Access > Policies
- Click your phishing-resistant MFA policy
- Change Enable policy from Report-only to On
- Click Save
Step 8: Monitor and Maintain
Set up ongoing monitoring:
- Go to Monitoring & health > Sign-in logs
- Add filter: Conditional Access > Failure or Not applied
- Review any failures related to authentication strength
Create an alert for policy violations:
- Go to Azure Monitor > Alerts
- Create an alert for sign-in failures due to authentication strength requirements
- 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"
- Verify the user has registered a phishing-resistant method:
- Go to Users > [user] > Authentication methods
- Check for FIDO2, Windows Hello, or Passkey registration
- If not registered, have user add method at mysignins.microsoft.com
- Temporarily exclude user from policy while they register (with documented approval)
"FIDO2 key not recognized during sign-in"
- Check browser compatibility (Edge, Chrome, Firefox support WebAuthn)
- Try different USB port
- Ensure key is FIDO2-certified (not just U2F)
- 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"
- Verify Windows Hello for Business is configured (not just Windows Hello):
- Check device is Entra joined or hybrid joined
- Verify TPM attestation is working
- Check policy includes Windows Hello for Business in authentication strength
- Review sign-in logs for specific failure reason
"User lost their security key"
- Have user sign in using backup method (if they have one registered)
- If no backup, temporarily exclude from policy (documented)
- Revoke lost key: Users > [user] > Authentication methods > delete the key
- Issue new security key
- User registers new key and re-enable policy
"Sign-in failing for service accounts/apps"
- Service accounts should not be using interactive sign-in
- If they are, consider:
- Moving to managed identities
- Using certificate-based authentication
- Excluding from this specific policy with compensating controls
Cost Considerations
| Component | Cost Impact |
|---|---|
| Entra ID P1 License | Required 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 Keys | Recommend 2 keys per user = 2x hardware cost |
| Windows Hello | Free (hardware-dependent - requires TPM) |
| Authenticator Passkeys | Free (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:
| Phase | Scope | Duration |
|---|---|---|
| Pilot | 2-3 IT admins who will support rollout | 1 week |
| Phase 1 | Global Admins and Privileged Role Admins | 1 week |
| Phase 2 | Security Admins, User Admins | 1 week |
| Phase 3 | All remaining privileged roles | 1-2 weeks |
| Full Enforcement | Policy enabled for all | Ongoing |
Related Controls
- PA-04: PIM for All Roles - Combine with PIM for comprehensive privileged access security
- PA-06: Hardware Security Keys - Detailed guide for key provisioning
- PA-01: Standing Global Admin - Convert permanent to eligible assignments