Most breaches still start the same way. An attacker tricks a user into handing over a password, or spams push notifications until a tired admin taps approve just to make them stop. Text codes and push approvals stop casual attackers. But they fold against real-time phishing kits, SIM-swap attacks, and MFA fatigue campaigns that target the same admin over and over. FIDO2 passkeys close that gap, and the shift is no longer theoretical: the FIDO Alliance’s FIDO Passkey Index puts 36% of user accounts worldwide already enrolled with a passkey as of October 2025, with 93% of accounts now passkey-eligible. The cryptographic key never leaves the device, and it never gets typed into a fake login page.
This tutorial deploys FIDO2 passkeys for administrator accounts on Windows 11 and Microsoft Entra ID. Admin accounts go first because they carry the most risk if phished. You’ll enable the authentication method, restrict which security keys the tenant trusts, enroll a physical key, and build a Conditional Access policy that actually enforces phishing resistance. You’ll also set up break-glass accounts before flipping the switch, a step too many rollouts skip. By the end, you’ll have a working, auditable deployment instead of a policy that locks out your own admins.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
Why Phishing-Resistant MFA Is Now the Baseline
For years, “turn on MFA” was the standard advice. That advice has aged badly. Adversary-in-the-middle phishing kits now proxy a live login session in real time, capturing the password and the one-time code together and replaying both before the code expires. Push notifications fare even worse once an attacker has a stolen password, because they can trigger repeated approval prompts until the target taps accept out of habit or annoyance. Security teams call this MFA fatigue or push bombing, and it has shown up in a long list of intrusions where the initial control, a password plus a phone-based second factor, simply wasn’t built to resist a determined phisher.
Standards bodies caught up to this problem. NIST Special Publication 800-63B classifies FIDO2 and WebAuthn authenticators as phishing-resistant, and requires phishing-resistant methods for Authenticator Assurance Level 3 (AAL3), the tier used for high-risk and administrative access. The Cybersecurity and Infrastructure Security Agency has pushed the same message to federal agencies through Binding Operational Directive 22-01, which prioritizes retiring SMS, voice call, and push-based MFA in favor of hardware-backed, phishing-resistant authenticators. Industry commitment is catching up to the regulatory push, too: the FIDO Alliance’s Passkey Pledge had drawn more than 240 organizations by May 2026, each publicly committing to phase out legacy MFA in favor of phishing-resistant authentication. Neither requirement is limited to government networks. They’ve become the reference architecture that enterprise security teams point to when they justify a passkey rollout to leadership.
Admin accounts are the logical starting point. A compromised standard user account is bad. A compromised Global Administrator or Privileged Role Administrator account in Microsoft Entra ID can hand an attacker control of every mailbox, every conditional access policy, and every other identity in the tenant. Scoping the first phase of a FIDO2 rollout to admins and other privileged roles limits the blast radius while your team works out the enrollment process, the help desk playbook, and the break-glass plan covered later in this guide. That staged approach matches what peer organizations are actually doing: a Liminal FIDO Passkey Adoption Study of 200 organizations in October 2025 found most were still finalizing deployment plans rather than enforcing tenant-wide on day one, which is exactly the admin-first, phased pattern this guide follows. If you’re building out a broader detection stack alongside this project, it pairs naturally with a centralized log pipeline like the one in our Graylog SIEM setup guide, since sign-in logs are exactly what you’ll want flowing into a SIEM once enforcement goes live.
FIDO2 Passkeys vs Passwords, One-Time Codes, and Push Approvals
FIDO2 combines two specifications maintained by the FIDO Alliance: WebAuthn, a W3C standard implemented in browsers and operating systems, and CTAP2, the protocol a browser or OS uses to talk to an external authenticator like a security key. When you register a FIDO2 credential, the authenticator generates a public-private key pair. The private key never leaves the device or its secure hardware. The public key goes to the relying party, in this case Microsoft Entra ID. During sign-in, the server sends a challenge, the authenticator signs it with the private key, and the signature proves possession without ever transmitting a shared secret an attacker could steal or replay.
The detail that actually blocks phishing is origin binding. A FIDO2 credential is cryptographically tied to the exact domain it was registered against. If a user lands on a lookalike login page, the browser and authenticator simply refuse to produce a valid signature for the wrong origin, even if the page is a pixel-perfect clone. Passwords and OTP codes have no equivalent concept. They work anywhere they’re typed, which is exactly why phishing kits can capture and replay them. The WebAuthn Level 3 specification documents the full credential ceremony if you want the underlying detail.
There are two flavors of FIDO2 credential worth distinguishing before you roll anything out. A device-bound passkey lives on a single piece of hardware, such as a USB security key or a machine’s built-in TPM, and cannot be exported or copied. A synced passkey lives in a platform credential manager (Windows, iCloud Keychain, Google Password Manager) and syncs across a user’s devices, trading a small amount of assurance for a much better recovery story. Both are phishing-resistant. Only device-bound keys meet the strictest AAL3 guidance, which matters for your highest-privilege roles.
| Method | Phishing-Resistant | Primary Weakness | NIST AAL Level |
|---|---|---|---|
| Password only | No | Reuse, phishing, credential stuffing | AAL1 |
| SMS one-time code | No | SIM swap, real-time relay phishing | AAL1 |
| Authenticator push notification | No | MFA fatigue / push bombing | AAL2 |
| TOTP authenticator app | No | Real-time phishing relay | AAL2 |
| Windows Hello for Business (platform) | Yes | Device theft without PIN/biometric lock | AAL2-AAL3 |
| FIDO2 security key (device-bound) | Yes | Physical loss of the key | AAL3 |
Prerequisites: Versions, Licensing, and Hardware You Need
Confirm every item below before you touch a production tenant. Skipping the licensing check in particular is the most common reason a rollout stalls halfway through, since Conditional Access enforcement (not the authentication method itself) is the piece that requires a paid tier.
| Component | Minimum Requirement | Notes |
|---|---|---|
| Windows edition | Windows 11, version 22H2 or later | Native passkey/FIDO2 support, 23H2/24H2 adds primary sign-in refinements |
| Microsoft Entra ID tier | Free (method enablement), P1 for Conditional Access enforcement | P1 runs about $6/user/month, P2 about $9/user/month |
| Admin role | Authentication Policy Administrator or Global Administrator | Needed to edit authentication methods policy |
| Automation tooling | Microsoft Graph PowerShell SDK (current release) | The legacy AzureAD and MSOnline modules are retired, use Microsoft Graph modules only |
| Security key hardware | Any CTAP2/FIDO2-certified key | YubiKey 5 NFC and YubiKey 5C NFC are common choices, roughly $45-$55 each |
| Browser | Current Edge, Chrome, or Firefox | All ship with WebAuthn support built in |
You’ll also need a short list of pilot users, ideally three to five admins who are comfortable reporting friction instead of quietly working around it, and at least two physical security keys per person once you get to the break-glass step. Buy the keys before you start. Ordering hardware mid-rollout is the single easiest way to stall a project for two weeks.
Step 1: Audit Current MFA Methods and Pick a Pilot Group
Start by finding out what your admins are actually using today. Microsoft Entra ID’s authentication methods usage report exposes this through Microsoft Graph, and it’s the fastest way to see how many privileged accounts are still relying on SMS or voice calls as their strongest registered method.
Connect-MgGraph -Scopes "Reports.Read.All","UserAuthenticationMethod.Read.All"
Get-MgReportAuthenticationMethodUserRegistrationDetail -All |
Where-Object { $_.IsAdmin -eq $true } |
Select-Object UserPrincipalName, IsMfaRegistered, MethodsRegistered, IsPasswordlessCapable |
Export-Csv -Path .\admin-mfa-audit.csv -NoTypeInformationOpen the CSV and sort by MethodsRegistered. Anyone showing only sms or voiceMobile against an admin role goes to the top of your priority list. From that list, pick three to five volunteers for the pilot group. Avoid picking every admin at once. A staged rollout gives you room to fix a broken enrollment flow before it becomes a help desk incident affecting your whole leadership team.
Step 2: Confirm Prerequisites and Hardware
Verify the Windows build on each pilot machine and confirm the tenant’s Entra ID licensing before moving further.
# Check Windows build on the local machine
Get-ComputerInfo | Select-Object WindowsProductName, OsBuildNumber
# Confirm the tenant's current licensing (requires Directory.Read.All)
Connect-MgGraph -Scopes "Directory.Read.All"
Get-MgSubscribedSku | Select-Object SkuPartNumber, ConsumedUnits, PrepaidUnitsYou’re looking for an OsBuildNumber that maps to Windows 11 22H2 or newer, and a SKU list that includes an Entra ID P1 or P2 entitlement for at least the users you plan to enforce Conditional Access against. If P1 isn’t present, you can still enable FIDO2 as a registration option tenant-wide, but you won’t be able to require it through Conditional Access until the license is in place.
Step 3: Enable FIDO2 as an Authentication Method in Microsoft Entra ID
In the Microsoft Entra admin center, go to Protection, then Authentication methods, then Policies, and select FIDO2 Security Key. Set the state to Enabled and target it at your pilot group rather than All users. The same change can be made through Microsoft Graph, which is worth scripting even if you also click through the portal once to sanity-check the UI.
$body = @{
"@odata.type" = "#microsoft.graph.fido2AuthenticationMethodConfiguration"
state = "enabled"
isSelfServiceRegistrationAllowed = $true
isAttestationEnforced = $true
includeTargets = @(
@{ targetType = "group"; id = "PILOT-GROUP-OBJECT-ID"; isRegistrationRequired = $false }
)
} | ConvertTo-Json -Depth 5
Invoke-MgGraphRequest -Method PATCH `
-Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/Fido2" `
-Body $body -ContentType "application/json"Leave isAttestationEnforced set to true. It forces the tenant to validate the authenticator’s attestation certificate against FIDO Alliance metadata during registration, which stops someone from registering a software-emulated or unverified authenticator instead of real hardware.
Step 4: Restrict Allowed Security Keys by AAGUID
Every FIDO2 authenticator model reports an AAGUID, a model identifier that lets you allow or block specific hardware. Without a restriction list, any FIDO2-certified device can be registered, including ones your IT team never purchased or approved. Yubico publishes the AAGUIDs for its product line on its YubiKey developer documentation, which is the easiest source if that’s the hardware you standardized on.
$body = @{
"@odata.type" = "#microsoft.graph.fido2AuthenticationMethodConfiguration"
keyRestrictions = @{
isEnforced = $true
enforcementType = "allow"
aaGuids = @(
"cb69481e-8ff7-4039-93ec-0a2729a154a8",
"ee882879-721c-4913-9775-3dfcce97072a"
)
}
} | ConvertTo-Json -Depth 5
Invoke-MgGraphRequest -Method PATCH `
-Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/Fido2" `
-Body $body -ContentType "application/json"Those two sample AAGUIDs correspond to specific YubiKey 5 series models. Swap in the exact AAGUIDs for whatever hardware your organization has standardized on, and double-check them against the vendor’s published list before you enforce, since a typo here locks out every key that doesn’t match.
Step 5: Turn On Passkey Support for Windows 11 Sign-In
On unmanaged or lightly managed machines, users can enroll a security key directly from Settings once the Entra ID authentication method is enabled. On managed fleets, push the setting through Intune so it’s consistent across every pilot machine instead of depending on each user to find the option. In Intune, create or edit a Windows device configuration profile under Identity Protection, and enable “Turn on security key sign-in.” Assign it to the same pilot device group you used for the Entra ID authentication method rollout, so the two stay in sync.
If any pilot machines are still on Windows 10, flag them now. Windows 10 has partial WebAuthn support in the browser, but the polished, native passkey enrollment flow this tutorial walks through is a Windows 11 feature. Plan a parallel upgrade track for those machines rather than trying to force feature parity that isn’t there.
Step 6: Enroll a Physical Security Key on Windows 11
With the policy live, walk a pilot user through enrollment. Open Settings, then Accounts, then Sign-in options. Under Security key, select Manage, then Add a security key. Windows prompts the user to insert the key and tap it, then asks them to set a security key PIN if the key doesn’t already have one. That PIN unlocks the key locally. It never gets sent to Microsoft and it’s separate from the user’s Windows password.
Once the tap-and-PIN sequence completes, Windows shows a confirmation that the security key was set up successfully, along with the option to name the key. Naming matters more than it sounds. Once a user has two or three keys registered, “Yubikey – desk” versus “Yubikey – backup, home drawer” saves a support call six months later when they’re trying to remember which key does what.
Step 7: Set Up a Synced Passkey as a Backup Method
A device-bound key that gets left at home is a locked-out admin. Give every pilot user a second, synced passkey as a fallback, registered the same way through Security info in the Entra ID My Account portal, but stored in a platform credential manager rather than on separate hardware. For most admins this ends up living in Windows’ own credential manager or in Microsoft Authenticator, and it syncs across their signed-in devices automatically.
Treat the synced passkey as a recovery path, not the primary credential for your highest-privilege roles. It’s still phishing-resistant, but it doesn’t meet the strict device-bound requirement that AAL3 guidance calls for. For a Global Administrator account, that distinction is worth enforcing deliberately rather than leaving to chance.
Step 8: Build a Conditional Access Authentication Strength Policy
Enabling FIDO2 as a registration option doesn’t force anyone to use it. Enforcement happens in Conditional Access, through a built-in grant control called an authentication strength. Microsoft Entra ID ships a predefined “Phishing-resistant MFA” strength that already scopes to FIDO2 security keys, Windows Hello for Business, and certificate-based authentication, documented on Microsoft’s authentication strengths reference. Reference it directly instead of rebuilding it from scratch.
$policy = @{
displayName = "Require phishing-resistant MFA - Pilot Admins"
state = "enabledForReportingButNotEnforced"
conditions = @{
users = @{ includeGroups = @("PILOT-GROUP-OBJECT-ID") }
applications = @{ includeApplications = @("All") }
}
grantControls = @{
operator = "OR"
authenticationStrength = @{ id = "00000000-0000-0000-0000-000000000004" }
}
} | ConvertTo-Json -Depth 6
Invoke-MgGraphRequest -Method POST `
-Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" `
-Body $policy -ContentType "application/json"Note the state: enabledForReportingButNotEnforced. That runs the policy in report-only mode first, so you can see exactly who would be blocked before anyone actually is. Check the sign-in logs for a few days, fix any gaps, and only then flip the state to enabled.
Step 9: Scope Enforcement to Admin and Privileged Roles
Once the pilot group proves the policy works, widen the scope from a static pilot group to actual directory roles. Target the policy at the built-in admin role groups (Global Administrator, Privileged Role Administrator, Security Administrator, and similar) rather than a manually maintained group, so anyone promoted into an admin role automatically picks up the requirement without a separate manual step.
Don’t forget roles activated through Privileged Identity Management. A user who is eligible for Global Administrator but not permanently assigned won’t be caught by a policy that only checks standing role assignments. Include PIM-eligible role activations in the same Conditional Access condition, or build a parallel policy that fires specifically on role activation events.
Step 10: Register Break-Glass Emergency Access Accounts
Before you enforce anything tenant-wide, create at least two cloud-only emergency access accounts, excluded from the new Conditional Access policy, with long random passwords stored offline in a sealed, physically secured location rather than in a password manager tied to the same identity system you’re locking down. These accounts exist for exactly one scenario: something breaks in your Conditional Access configuration and every other admin is locked out.
Monitor sign-ins to these accounts closely, since any activity on a break-glass account outside a genuine emergency is itself a signal worth investigating. Set an alert on sign-ins to these two accounts specifically, review that alert monthly even if it never fires, and rotate the credentials on a fixed schedule. This is the step most rollouts skip, and it’s the one that turns a policy mistake into a multi-hour outage instead of a five-minute fix.
Step 11: Automate Compliance Checks with Microsoft Graph PowerShell
Manually checking who has enrolled a passkey doesn’t scale past a handful of pilot users. Script it instead, and run the script on a schedule so you have a running view of adoption without chasing people individually.
Connect-MgGraph -Scopes "Reports.Read.All","RoleManagement.Read.Directory"
$admins = Get-MgRoleManagementDirectoryRoleAssignment -All |
Select-Object -ExpandProperty PrincipalId -Unique
$registrations = Get-MgReportAuthenticationMethodUserRegistrationDetail -All
$gapReport = $registrations | Where-Object {
$admins -contains $_.Id -and $_.MethodsRegistered -notcontains "fido2SecurityKey"
}
$gapReport | Select-Object UserPrincipalName, MethodsRegistered |
Export-Csv -Path .\fido2-compliance-gaps.csv -NoTypeInformation
Write-Host "$($gapReport.Count) privileged accounts still missing a FIDO2 passkey."A typical run against a mid-size tenant during the pilot phase looks like this:
8 privileged accounts still missing a FIDO2 passkey.
Export complete: .\fido2-compliance-gaps.csv (8 rows)Wire that count into whatever dashboard or ticketing system your team already watches. A number that shrinks week over week is a much easier thing to report to leadership than a one-time enrollment email blast.
Step 12: Roll Out, Monitor Sign-In Logs, and Retire Legacy MFA
With the pilot clean and break-glass accounts in place, expand the Conditional Access policy from report-only to enforced, then widen the scope in phases rather than all at once: admin roles first, then any group with standing access to sensitive systems, then the broader user base if your organization decides to go that far. Query the sign-in logs regularly to track which authentication method actually satisfied each sign-in.
Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/auditLogs/signIns?`$filter=isInteractive eq true&`$top=50" |
Select-Object -ExpandProperty value |
Select-Object userPrincipalName, authenticationRequirement, @{n='Methods';e={$_.authenticationDetails.authenticationMethod}}Sample output during an active rollout:
userPrincipalName authenticationRequirement Methods
------------------ ------------------------- -------
[email protected] multiFactorAuthentication FIDO2 security key
[email protected] multiFactorAuthentication Windows Hello for Business
[email protected] singleFactorAuthentication Password (flagged for follow-up)Once your compliance report from Step 11 shows every targeted account enrolled and the sign-in logs confirm they’re actually authenticating with FIDO2 or Windows Hello for Business, disable SMS and voice call as registrable methods for that same population. Leaving legacy methods active as an unused fallback defeats much of the point, since an attacker only needs one weak method to still work.
Common Pitfalls When Deploying FIDO2 Passkeys
Most FIDO2 rollouts that stall or get rolled back hit one of the same handful of problems. Watch for these specifically.
- Enforcing before break-glass accounts exist. This is the single most common cause of a full admin lockout, and it’s entirely avoidable with Step 10.
- Leaving AAGUID restrictions wide open. Without them, anyone can register an unmanaged or unverified authenticator against a privileged account.
- Skipping the pilot and enforcing tenant-wide on day one. A configuration mistake that affects five pilot users is a minor incident. The same mistake affecting every employee is a company-wide outage.
- Treating synced and device-bound passkeys as interchangeable. They’re both phishing-resistant, but only device-bound keys satisfy strict AAL3 requirements for your most sensitive roles.
- Leaving SMS or voice call active as a silent fallback. A phishing-resistant policy only works if attackers can’t route around it through a weaker registered method.
- Forgetting PIM-eligible role activations when scoping Conditional Access. A policy that only checks standing assignments misses users who activate admin roles on demand.
- Skipping help desk training. The first week of enrollment generates support tickets. A help desk that doesn’t know the recovery flow will improvise one, and improvised recovery flows are exactly what attackers try to exploit through social engineering.
- Not testing against the actual device mix in use. Older Windows 10 laptops, non-standard browsers, and virtual desktop environments all behave differently, and none of that surfaces until you test on the real hardware.
Troubleshooting FIDO2 and Passkey Sign-In Issues
Even a careful rollout generates support tickets in the first few weeks. Here’s what tends to come up, and the fastest path to a fix for each.
- “This browser or app may not support security keys.” Usually an outdated browser or an app using an embedded, older web view. Update the browser first, and check whether the sign-in is happening inside a legacy embedded control that doesn’t support WebAuthn.
- Security key not detected over USB, NFC, or Bluetooth. Try a different USB port before assuming the key is faulty, and confirm NFC is enabled in Windows settings if the key is being tapped rather than plugged in.
- User is prompted to set a PIN before they can enroll. This is expected behavior on a new key, not an error. Walk them through setting the security key PIN, which is separate from their Windows sign-in PIN.
- “You don’t meet the authentication strength requirements” during sign-in. The account hasn’t registered a method covered by the assigned authentication strength. Check their registered methods against the strength’s allowed list.
- FIDO2 option missing from the Security info page. Confirm the user is actually included in the Entra ID authentication method’s target group, not just the Conditional Access policy target group. The two are configured separately.
- “This security key isn’t allowed” during registration. The key’s AAGUID isn’t on your allow list from Step 4. Confirm the model against your organization’s approved hardware list before assuming it’s a bug.
- A synced passkey doesn’t appear on a second device. Confirm both devices are signed into the same platform account (Microsoft account, iCloud, or Google account) with sync enabled, since passkey sync rides on the same mechanism as other credential sync features.
- An admin gets locked out immediately after enforcement. This is what break-glass accounts are for. Sign in with a break-glass account, move the affected admin back into the pilot or excluded group, and investigate before re-enforcing.
- A Graph PowerShell script returns 403 Forbidden. The connected app registration or delegated session is missing a required scope. Recheck the scopes passed to
Connect-MgGraphagainst what the specific cmdlet or endpoint requires. - A passkey gets created against a personal Microsoft account instead of the work account. Common on shared or personal devices where the user is signed into both. Have them explicitly choose the work or school account during the enrollment prompt rather than letting Windows pick a default.
Advanced Tips for Scaling Beyond Admin Accounts
Once the admin rollout is stable, the same pattern extends to the rest of the company. A few things change at that scale that are worth planning for early.
Synced Passkeys vs Device-Bound Keys for High-Assurance Roles
For a general employee population, synced passkeys are usually the better default. They’re phishing-resistant, they don’t require distributing and tracking physical hardware, and the built-in recovery story (a new device signed into the same platform account) means far fewer help desk tickets. Reserve mandatory device-bound hardware keys for the roles where AAL3 assurance genuinely matters: Global Administrators, break-glass accounts, and anyone with standing access to production infrastructure or financial systems.
Cross-Platform Sign-In With Hybrid Transport
FIDO2’s hybrid transport option lets a user scan a QR code on a desktop with their phone to complete sign-in using a passkey stored on the phone, over a Bluetooth-secured channel rather than the internet. It’s useful for shared kiosks, lab machines, and any desktop where a user doesn’t want to register a separate credential. Test it explicitly before relying on it, since it depends on Bluetooth being enabled on both the desktop and the phone.
Extending Phishing-Resistant MFA to the Whole Company
Widen the rollout by department rather than by headcount percentage. Finance, HR, and anyone with access to sensitive customer data should move up the queue regardless of team size, since they’re disproportionately targeted by business email compromise and invoice fraud campaigns that specifically try to bypass weaker MFA. Employee familiarity is already ahead of most enterprise rollouts: a FIDO Alliance World Passkey Day survey found 69% of consumers had enabled at least one passkey on a personal account by May 2025, so many employees arrive already knowing the tap-to-sign-in flow before IT rolls it out at work. Keep the same report-only-then-enforce pattern from Step 8 for every new group you add, even after the process feels routine.
The Complete Deployment Script
Individually, the steps above are straightforward. Stitched together, they form a repeatable deployment you can hand to another admin or reuse for the next department. The script below chains the audit, the method configuration, the key restriction, and a compliance check into a single run, intended as a starting template rather than a drop-in for every environment.
Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod","RoleManagement.Read.Directory","Reports.Read.All"
# 1. Snapshot current admin MFA state
$before = Get-MgReportAuthenticationMethodUserRegistrationDetail -All |
Where-Object { $_.IsAdmin -eq $true }
$before | Export-Csv -Path .\pre-rollout-snapshot.csv -NoTypeInformation
# 2. Enable FIDO2 for the target group, attestation enforced
$fido2Body = @{
"@odata.type" = "#microsoft.graph.fido2AuthenticationMethodConfiguration"
state = "enabled"
isAttestationEnforced = $true
keyRestrictions = @{
isEnforced = $true
enforcementType = "allow"
aaGuids = @("cb69481e-8ff7-4039-93ec-0a2729a154a8")
}
includeTargets = @(@{ targetType = "group"; id = "PILOT-GROUP-OBJECT-ID"; isRegistrationRequired = $false })
} | ConvertTo-Json -Depth 6
Invoke-MgGraphRequest -Method PATCH `
-Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/Fido2" `
-Body $fido2Body -ContentType "application/json"
# 3. Create the Conditional Access policy in report-only mode
$caBody = @{
displayName = "Require phishing-resistant MFA - Rollout"
state = "enabledForReportingButNotEnforced"
conditions = @{
users = @{ includeGroups = @("PILOT-GROUP-OBJECT-ID") }
applications = @{ includeApplications = @("All") }
}
grantControls = @{ operator = "OR"; authenticationStrength = @{ id = "00000000-0000-0000-0000-000000000004" } }
} | ConvertTo-Json -Depth 6
Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" -Body $caBody -ContentType "application/json"
# 4. Re-check compliance after enrollment window closes
Start-Sleep -Seconds 1
$after = Get-MgReportAuthenticationMethodUserRegistrationDetail -All |
Where-Object { $_.IsAdmin -eq $true -and $_.MethodsRegistered -notcontains "fido2SecurityKey" }
Write-Host "Rollout complete. $($after.Count) admin accounts still need enrollment."
$after | Export-Csv -Path .\post-rollout-gaps.csv -NoTypeInformationRun the snapshot step before every phase expansion, not just once at the start. It gives you a before-and-after record for each group you roll out to, which turns out to be useful both for tracking progress and for demonstrating compliance if an auditor asks how the rollout was managed.
What Phishing-Resistant MFA Actually Costs
The software side of this deployment is close to free. Registering a FIDO2 method costs nothing beyond an existing Entra ID Free tier, and Windows 11’s passkey support is included in the OS. The two real costs are Conditional Access licensing and the physical keys themselves, and demand for that hardware is climbing fast: MarketIntelo valued the global FIDO2 security key market at $1.2 billion in 2025, projecting a 20.5% CAGR that would put it near $6.8 billion by 2034.
| Item | Cost | Required For |
|---|---|---|
| Microsoft Entra ID Free | $0 | Enabling FIDO2 as a registration method |
| Microsoft Entra ID P1 | ~$6/user/month | Conditional Access enforcement (authentication strengths) |
| Microsoft Entra ID P2 | ~$9/user/month | P1 features plus Identity Protection and PIM |
| YubiKey 5 NFC | ~$45-$50/key | Primary device-bound key |
| YubiKey 5C NFC | ~$50-$55/key | USB-C devices, primary or backup key |
| Second key per admin (backup) | ~$45-$55/key | Recovery without falling back to weaker MFA |
For a 20-person admin and privileged-role population, budget roughly $900-$1,100 in hardware for two keys per person, plus whatever the P1 licensing gap costs if the tenant isn’t already on that tier for other reasons. Most organizations rolling this out to admins first already carry P1 or P2 for existing Conditional Access policies, which makes the marginal cost of this specific project mostly the hardware line.
Mapping This Rollout to Compliance Frameworks
Security teams rarely get budget for an identity project on the technical merits alone. It helps that this one maps cleanly onto frameworks auditors already ask about. Microsoft documents the full set of supported authentication methods, including FIDO2, on its authentication methods reference, which is worth bookmarking alongside the authentication strengths page from Step 8 since auditors tend to ask for both the method and the enforcement policy together.
Under NIST SP 800-63B, this deployment moves admin accounts from AAL2 (password plus a possession factor like SMS or push) to AAL3 (a hardware-backed, phishing-resistant authenticator), which is the assurance level federal guidance calls for on privileged access. Under CISA’s BOD 22-01, the deployment addresses the directive’s core ask directly: replacing legacy MFA with hardware-backed, phishing-resistant authentication for the accounts that matter most. If your organization reports against SOC 2 or ISO 27001, the access control and authentication sections of both frameworks generally accept FIDO2 enrollment records and Conditional Access sign-in logs as direct evidence, which is one more reason to keep the CSV exports from Steps 1 and 11 rather than discarding them after the rollout.
Verizon’s long-running Data Breach Investigations Report has tracked stolen or phished credentials as a recurring factor in confirmed breaches for years, which is the underlying reason this class of control gets prioritized in the first place. An auditor who asks why FIDO2 specifically, rather than “more MFA” in the abstract, is really asking whether your team understands that not all MFA blocks the same attack. The comparison table earlier in this guide is the short answer. The rollout itself is the long one.
Frequently Asked Questions
Do I need Microsoft Entra ID P1 or P2 to use FIDO2 security keys?
Not to register one. FIDO2 as an authentication method is available on the Free tier. You need P1 (or P2) to enforce it through Conditional Access authentication strengths, which is the piece that actually requires phishing-resistant MFA instead of just allowing it as an option.
What’s the difference between a passkey and a FIDO2 security key?
A FIDO2 security key is a piece of hardware. A passkey is the credential itself, the public-private key pair created under the FIDO2/WebAuthn standard. A passkey can live on a hardware security key (device-bound) or in a platform credential manager that syncs across devices. Every security key produces a passkey, but not every passkey lives on a security key.
Can I use FIDO2 passkeys on Windows 10?
Partially. Windows 10 supports WebAuthn in modern browsers for web sign-in, but the native, OS-level passkey enrollment and management flow this tutorial covers is built for Windows 11 (22H2 and later). Plan a Windows 11 upgrade alongside this project for any machines still on Windows 10.
What happens if an admin loses their security key?
They sign in with their backup method, ideally the synced passkey registered in Step 7, then register a replacement key and revoke the lost one from their Security info page. This is exactly why Step 7 isn’t optional: a single device-bound key with no backup turns a lost key into a support escalation.
Are synced passkeys as secure as device-bound ones?
Both are phishing-resistant against the attack that matters most: credential relay through a fake login page. Device-bound keys add an extra layer because the private key physically cannot be extracted or copied, which is why strict AAL3 guidance calls for them specifically on the highest-risk accounts. For everyone else, synced passkeys are a reasonable, well-supported default.
Does this work with Google Workspace, or only Microsoft?
FIDO2 and WebAuthn are open standards maintained by the FIDO Alliance and the W3C, not a Microsoft-specific technology. Google Workspace, Okta, and most major identity providers support FIDO2 security keys and passkeys through the same underlying protocol. This tutorial focuses on Microsoft Entra ID and Windows 11 because that’s the most common combination in enterprise environments, but the core concepts carry over directly.
How long does rollout typically take for an IT team?
Plan on roughly 45 minutes for the initial configuration covered in this tutorial (enabling the method, restricting AAGUIDs, and building the report-only Conditional Access policy), plus one to two weeks running the pilot group in report-only mode before enforcing. Expanding beyond admins to the full company is a separate, longer project measured in months rather than weeks.
Do FIDO2 passkeys replace Windows Hello for Business?
No, they complement each other. Windows Hello for Business is itself a phishing-resistant, FIDO2-compatible platform authenticator built into Windows, tied to the specific device. A separate FIDO2 security key adds portability across devices and a physical factor a user can carry independently of any one machine. Many organizations deploy both: Windows Hello for Business as the daily driver and a security key as backup or for shared machines.
Do legacy authentication protocols bypass this policy?
They can, which is why FIDO2 enrollment alone isn’t the whole project. Older protocols like POP, IMAP, and legacy SMTP authentication were built before interactive MFA existed, so they can’t prompt for a passkey at all. If a mailbox or app still accepts legacy authentication, an attacker with a stolen password can often skip your new Conditional Access policy entirely. Blocking legacy authentication protocols tenant-wide is a companion project worth scheduling right after this one, not a follow-up you can defer indefinitely.
Should I keep push notifications enabled after passkeys are live?
Keep push as an interim fallback during the pilot in Steps 1 through 9, since it gives users a safety net while they get comfortable with a new sign-in method. Once your Step 11 compliance report shows full enrollment and the Step 12 sign-in logs confirm people are actually authenticating with FIDO2 or Windows Hello for Business, disable push and other legacy methods for that population. An unused fallback that’s still technically active is still an active attack path.
Related Coverage
For more on building out the defensive security stack around this kind of identity hardening project, see our related guides:
- Graylog SIEM Setup: 13 Steps, 45 Min [2026]
- CrowdSec: Block Malicious IPs in 12 Steps, 40 Min [2026]
- Proton Pass vs Bitwarden vs 1Password: $0 vs $48 [2026]
- North Korea Poisons 140 npm AI Packages in 19 Min [2026]
- New CitrixBleed Flaw: NetScaler Hit in 24 Hours [2026]
- OpenSSL vs BoringSSL vs wolfSSL: PQC Hits 50% [2026]
For the full picture of what’s shaping enterprise security this year, visit our cybersecurity threats hub.
