A synced passkey stored in Chrome and backed up to Google Password Manager felt like the end of the password problem. Then, on August 3, 2026, Palo Alto Networks’ Unit 42 team published a technical breakdown of an attack family it calls Pass-ta-key, and the picture changed. In its strongest form, the attack pulls a single 32-byte master secret out of Chrome’s process memory on a Windows machine, and that one secret unlocks every synced passkey tied to the victim’s Google account. A separate but related Windows flaw, CVE-2026-34348, made parts of that job easier until Microsoft patched it on July 14, 2026.
None of this means passkeys are broken as a concept. It means the industry built two different things and called them the same name: hardware-bound FIDO2 keys that never leave a physical device, and cloud-synced passkeys that trade some of that isolation for convenience across phones and laptops. This tutorial walks through setting up the hardware-bound version correctly, auditing which accounts are still relying on the weaker synced model, and closing the session-hijacking gap that a separate August 2026 phishing kit, Mirage2FA, has been using to walk straight past MFA and passkeys alike. By the end you will have a working, tested hardware security key deployment plus a checklist for locking down the accounts that matter most.
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 Synced Passkeys and Hardware Security Keys Are Not the Same Thing
The FIDO Alliance’s State of Passkeys 2026 report, published May 7, 2026, counts more than 5 billion passkeys in active use worldwide, with 90% consumer awareness, 75% of people having enabled a passkey on at least one account, and 68% of organizations deploying, piloting, or rolling out passkeys for employee sign-in. Those numbers are genuinely good news for the death of the password. But “passkey” has become a marketing umbrella that covers two very different security models, and the Pass-ta-key research is really a story about what happens when people assume both models offer identical protection.
Hardware-Bound Passkeys
A hardware-bound passkey lives inside a physical authenticator, typically a USB-C, USB-A, NFC, or Lightning security key such as a YubiKey, and the private key material never leaves that chip. There is no cloud copy, no sync domain, and nothing for malware on your laptop to steal, because the signing operation happens on the device itself. If you already compared this model to plain passwords in our passkeys vs. passwords breakdown, this is the deployment path that keeps every one of those speed and security gains intact even against a compromised endpoint.
Synced (Cloud) Passkeys
A synced passkey, by contrast, is generated on one device and then encrypted and pushed to a cloud vault (Google Password Manager, iCloud Keychain, or a third-party password manager) so it can be used on your phone, your laptop, and your tablet without re-enrolling each one. That convenience depends on a master secret that decrypts the whole vault, and Unit 42’s research showed that on a compromised Windows endpoint running Chrome, that master secret can be recovered from memory.
According to the Unit 42 disclosure summarized by The Hacker News, the attack family has three variants of increasing severity: a baseline “Pass-ta-key” path that recovers synced passkey material available through Chrome and Google Password Manager on Windows; “Silver Pass-ta-key,” which recovers more sensitive signing material without the full master secret; and “Golden Pass-ta-key,” the strongest variant, which extracts the 32-byte security domain secret directly from Chrome’s process memory. Because that secret protects every synced passkey tied to the account, not just one credential, a single successful extraction can compromise dozens of logins at once. This is the throughline of this tutorial: the fix is not “stop using passkeys,” it’s “know which passkeys are hardware-bound and put your highest-value accounts there.”
What CVE-2026-34348 Actually Is
CVE-2026-34348 is a Windows information-disclosure vulnerability in the Windows Event Logging Service, carrying a vendor CVSS score of 6.5. The practical issue: Windows had been logging authentication signatures tied to security keys and passkey confirmations in a form that could be read by any authenticated, non-privileged user on the machine, including in some remote-access scenarios. Microsoft shipped a fix on July 14, 2026 that truncates the logged signatures down to six bytes, which is not enough material to replay or reconstruct a usable credential. Microsoft also added mitigations against a related passkey-confirmation relay behavior that researchers flagged alongside the original bug. Full technical details are tracked on the Microsoft Security Response Center advisory page.
If you manage Windows endpoints, the single highest-leverage action from this whole disclosure is confirming that the July 2026 cumulative update (or later) is installed everywhere, particularly on machines used by administrators, finance staff, and anyone with access to source code repositories or production infrastructure. The step-by-step below treats that patch check as step one, not an afterthought, because everything else in this guide assumes a patched OS as the baseline.
| Authenticator Type | Private Key Location | Exposed to Pass-ta-key? | Exposed to CVE-2026-34348? | Recommended For |
|---|---|---|---|---|
| Hardware security key (FIDO2, e.g. YubiKey, Titan Key) | Secure element on the device | No | Patch closes the logging gap; key itself unaffected | Admin, finance, engineering, executive accounts |
| Synced passkey (Google Password Manager, Chrome, Windows) | Cloud vault, decrypted in browser memory | Yes, on unpatched/compromised Windows + Chrome | Yes, prior to July 2026 patch | Low-risk personal accounts only |
| Synced passkey (iCloud Keychain, macOS/iOS) | Apple’s cloud vault, Secure Enclave-backed sync | Not named in the Unit 42 disclosure | Not applicable (non-Windows) | General consumer use |
| Platform passkey (Windows Hello, on-device only) | TPM on the local device | Not the primary target; related logging issue applies | Yes, prior to July 2026 patch | Single-device use cases |
| Password + SMS OTP (legacy) | N/A | Not applicable; already the weakest option | Not applicable | Nothing; retire this everywhere |
Prerequisites
This tutorial assumes you are setting up hardware security keys for yourself or for a small-to-midsize team, and that you also want to audit existing synced-passkey usage. Have the following ready before you start:
- Two FIDO2-compliant hardware security keys per user (one primary, one backup stored separately) — YubiKey 5 series, Google Titan Security Key, or a comparable FIDO2 Level 2-certified key
- Windows 11 24H2 or later, fully patched (confirm build includes the July 14, 2026 security update or newer, which resolves CVE-2026-34348), or macOS 15 Sequoia / 16 or later
- Chrome 128+, Edge 126+, or Safari 18+ (all current stable channels support WebAuthn Level 3 as of mid-2026)
- Administrative access to your identity provider: Microsoft Entra ID, Okta, or Google Workspace admin console
- A password manager that supports FIDO2 for its own vault unlock, separate from any browser-synced passkey store
- 15-20 minutes per user for initial key enrollment, plus 30-45 minutes for the organization-wide audit steps later in this guide
- A spreadsheet or identity-governance tool to track which accounts use hardware keys versus synced passkeys versus passwords
Step 1: Patch Windows and Confirm CVE-2026-34348 Is Closed
Before touching any authenticator hardware, confirm every Windows endpoint that handles passkeys is patched. Open PowerShell as an administrator and check the installed build and update history.
Get-ComputerInfo | Select-Object WindowsProductName, OsVersion, OsBuildNumber
Get-HotFix | Where-Object {$_.InstalledOn -ge (Get-Date "2026-07-14")} | Sort-Object InstalledOnIf the second command returns no results for a machine, that endpoint has not received a security update since the patch date and needs immediate attention. For fleets managed with Microsoft Intune or WSUS, cross-reference against the July 2026 patch Tuesday release notes and the specific KB tied to CVE-2026-34348 on the MSRC advisory page linked above. Do not proceed to enrolling hardware keys on an endpoint until this check comes back clean — a compromised, unpatched machine can still leak session material even after you plug in a physical key, because the vulnerability sat in event logging, not in the authenticator itself.
Step 2: Inventory Every Account That Currently Uses a Passkey or Password
You cannot secure what you have not counted. Before enrolling new hardware keys, build a simple inventory of authentication methods per account. For individuals, this means walking through your password manager’s vault export. For organizations, most identity providers expose this through their admin API or reporting console.
# Microsoft Entra ID: list authentication methods registered per user
Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All"
Get-MgUser -All | ForEach-Object {
$methods = Get-MgUserAuthenticationMethod -UserId $_.Id
[PSCustomObject]@{
User = $_.UserPrincipalName
Methods = ($methods | ForEach-Object { $_.AdditionalProperties["@odata.type"] }) -join ", "
}
} | Export-Csv -Path ./auth-method-inventory.csv -NoTypeInformationRun this against every tenant you administer, then sort the output by role. Anyone in a privileged group (Global Admin, Security Admin, Exchange Admin, or an equivalent in Okta or Google Workspace) who shows up with only a synced passkey or a password-plus-SMS combination should move to the top of your migration list. This single spreadsheet becomes the source of truth for every remaining step.
Step 3: Unbox and Prepare Your FIDO2 Hardware Security Keys
Buy two keys per user from the start. A single key that gets lost, left in a hotel room, or run through a washing machine locks you out of every account tied to it unless a backup is already registered. Label each key physically (a small engraved initial or a colored cap works) so users can tell primary from backup at a glance, and record each key’s serial number against the user in your inventory spreadsheet from Step 2.
Before enrollment, set a FIDO2 PIN on each key. This is the single most skipped step, and it is the difference between “a stolen key is useless” and “a stolen key is a stolen credential.” Most FIDO2 keys ship with no PIN set by default. Yubico’s own setup wizard walks through this for its key lineup if you want a guided, vendor-specific flow instead of the command line below.
# Using Yubico's official CLI tool (ykman) to set a FIDO2 PIN
ykman fido access change-pin
# Verify the key requires a PIN for user verification
ykman fido infoSet a PIN of at least 6 digits, avoid dates or repeated sequences, and store it in your password manager, not on a sticky note. A key with a strong PIN and touch-based user presence verification satisfies “phishing-resistant MFA” as defined by NIST’s guidance on multi-factor authentication, because the private key never leaves the device and the PIN prevents use by anyone who merely finds or steals the key.
Step 4: Register Your Primary Hardware Key With Your Identity Provider
Registration flows differ slightly by provider, but the underlying WebAuthn ceremony is identical. Here is the Entra ID flow, which mirrors what you will see in Okta and Google Workspace with minor UI differences.
- Sign in to
myaccount.microsoft.comand navigate to Security Info - Select “Add sign-in method” and choose “Security key”
- Choose USB device (or NFC, depending on your key) when prompted
- Insert the key and touch it when it blinks — this proves physical presence, not just possession
- Enter the FIDO2 PIN you set in Step 3
- Name the key something identifiable, such as “YubiKey-Primary-JDoe,” so audits later are legible
Repeat the same flow for any other identity provider your accounts touch — GitHub, AWS IAM, your password manager’s own vault unlock, and any SaaS tool that supports WebAuthn directly (Microsoft documents the equivalent flow for Entra ID passkey and FIDO2 registration in its admin configuration guide). GitHub, for example, has supported hardware security keys as a primary 2FA method since well before this disclosure, and it is one of the highest-value places to enroll a key given how much source code and CI/CD access rides on a single compromised developer account.
Step 5: Register the Backup Key and Test It Independently
Do this in the same sitting as Step 4, not later. Repeat the registration flow with your second key, then physically remove the primary key, sign out completely, and sign back in using only the backup. This confirms the backup actually works rather than assuming it does. A shocking number of hardware-key rollouts skip this test and discover the backup was never fully registered only after the primary key is lost.
Store the backup key somewhere genuinely separate from the primary: a home safe if the primary lives on your keychain, or a locked drawer at a different office location for organizational deployments. The goal is that a single event (stolen bag, house fire, lost laptop bag) cannot take out both keys at once.
Step 6: Migrate High-Value Accounts Off Synced Passkeys
Using the inventory from Step 2, work through every account flagged as privileged or high-value and either add a hardware key as an additional method or, where the provider allows it, remove the synced passkey entirely once the hardware key is confirmed working. Google, Microsoft, and most enterprise identity platforms let multiple authenticators coexist, so there is rarely a reason to rush the removal step — register the hardware key first, verify it signs you in cleanly on a fresh browser session, and only then prune the weaker method.
# Entra ID: enforce that privileged roles require a hardware-bound
# authentication method via Conditional Access authentication strength
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"
$policy = @{
displayName = "Require FIDO2 Hardware Key for Privileged Roles"
state = "enabled"
conditions = @{
users = @{ includeRoles = @("62e90394-69f5-4237-9190-012177145e10") } # Global Admin role ID
}
grantControls = @{
authenticationStrength = @{ id = "00000000-0000-0000-0000-000000000004" } # Phishing-resistant MFA strength
}
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $policyThat Conditional Access authentication strength ID corresponds to Microsoft’s built-in “Phishing-resistant MFA” strength, which accepts FIDO2 hardware keys and Windows Hello for Business but rejects SMS, voice, and standard app-based push approvals. Applying this specifically to privileged directory roles, rather than to every user on day one, is the fastest way to close your biggest exposure without a disruptive company-wide rollout.
Step 7: Close the Post-Authentication Gap — Defend Against Session Hijacking
Here is the detail that catches most teams off guard: a hardware key stops credential theft, but it does not stop session theft. The Mirage2FA phishing kit, which researchers reported surging through August 2026 with telemetry linking it to more than 4,500 unique organization email domains linked to the Mirage2FA campaign, does not try to defeat MFA or passkeys at all. It sits as an adversary-in-the-middle proxy between the victim and the real Microsoft 365 login page, lets the victim complete authentication (passkey, hardware key, or otherwise), and then steals the session cookie issued after that successful login. From there, the attacker rides the authenticated session into every connected SSO app without ever needing the original credential again.
Mitigating this requires token-binding and session-lifetime controls layered on top of the authenticator work you just did. Configure sign-in frequency and continuous access evaluation so stolen tokens expire quickly rather than remaining valid for hours or days.
# Entra ID: enforce sign-in frequency to shrink the window a stolen
# session token remains usable
$signInFrequency = @{
sessionControls = @{
signInFrequency = @{
value = 4
type = "hours"
isEnabled = $true
}
persistentBrowser = @{
mode = "never"
isEnabled = $true
}
}
}
Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policyId -BodyParameter $signInFrequencyPair this with continuous access evaluation, which most enterprise identity providers now support, so a session gets revoked in near real time if the user’s location, IP reputation, or device compliance status changes mid-session. This is also a good moment to review the internal guide on detecting and stopping session hijacking, since the detection side (anomalous token replay, impossible-travel alerts, new-device fingerprinting) complements the prevention work described here.
Step 8: Harden Browser and Chrome Password Manager Settings
For any account that must remain on a synced passkey for practical reasons (shared family accounts, low-value logins where a hardware key would be overkill), reduce exposure by locking down the browser environment the synced vault runs in. On managed Windows fleets, push these settings through Group Policy or Intune configuration profiles rather than relying on end users to change them manually.
# Chrome enterprise policy (registry, HKLM\SOFTWARE\Policies\Google\Chrome)
# Require OS-level re-authentication before revealing saved passkeys/passwords
reg add "HKLM\SOFTWARE\Policies\Google\Chrome" /v PasswordManagerReauthenticateOnBiometricSyncSensitiveActions /t REG_DWORD /d 1 /f
# Disable Chrome's ability to sync passkeys to a personal (non-managed) Google account
reg add "HKLM\SOFTWARE\Policies\Google\Chrome" /v BrowserSignin /t REG_DWORD /d 0 /fThese two settings reduce the window an attacker has to extract the master secret from Chrome’s memory, since sensitive password-manager actions now require a fresh OS-level authentication prompt, and they stop corporate devices from syncing credentials into a personal Google account outside IT’s visibility. Combined with the CVE-2026-34348 patch from Step 1, this materially narrows the Pass-ta-key attack surface on any machine that still touches synced passkeys.
Step 9: Set Up Recovery Codes and a Break-Glass Account
Every hardware-key rollout needs an escape hatch that does not depend on the keys themselves. Generate one-time recovery codes for each critical account and store them offline (printed and locked in a safe, or in an encrypted, non-cloud-synced file). For organizations, create at least one break-glass administrator account that is excluded from the Conditional Access policy built in Step 6, secured instead with an extremely long, randomly generated passphrase stored in a sealed physical envelope, and monitored so any sign-in to it triggers an immediate alert.
# Entra ID: create an alert rule for any sign-in to the break-glass account
Connect-MgGraph -Scopes "AuditLog.Read.All"
$breakGlassUPN = "[email protected]"
Get-MgAuditLogSignIn -Filter "userPrincipalName eq '$breakGlassUPN'" -Top 1 |
Select-Object CreatedDateTime, IpAddress, StatusWire that query into a scheduled task or your SIEM so a sign-in against the break-glass account pages someone immediately. This account should be used so rarely that any activity on it is inherently suspicious.
Step 10: Roll Out to the Rest of the Organization in Waves
With privileged accounts secured, extend hardware key enrollment outward in waves rather than all at once. A reasonable sequence: IT and security staff first (they will surface enrollment friction before anyone else hits it), then finance and HR (common targets for business email compromise), then engineering, then the broader company. Track completion against the spreadsheet from Step 2, and set a hard deadline for each wave, since voluntary rollouts without a deadline tend to stall well short of full adoption.
Budget two physical keys per person at roughly $25-$85 each depending on the model and form factor, so a rollout of 200 employees runs somewhere between $10,000 and $34,000 in hardware, plus the labor cost of the enrollment sessions themselves. That is a modest line item next to the cost of a single successful business email compromise incident, a category the FBI’s Internet Crime Complaint Center has repeatedly flagged as among the costliest forms of reported cybercrime.
Step 11: Audit Passkey Confirmation and Relay Behavior
Beyond the July 2026 patch, Microsoft implemented additional mitigations against passkey-confirmation relay behavior that researchers reported alongside CVE-2026-34348. Confirm your endpoint management tooling is set to auto-approve security updates for identity and authentication components specifically, since these tend to ship out of the normal monthly cadence when a researcher disclosure forces an accelerated patch.
# SCCM/Intune: query which devices are still pending the identity-related
# update ring rather than the general monthly cumulative update
Get-CMSoftwareUpdate -CategoryName "Security Updates" |
Where-Object { $_.LocalizedDisplayName -match "34348" } |
Select-Object LocalizedDisplayName, IsDeployed, NumMissingRun this weekly for the first month after any identity-related CVE disclosure, since patch compliance tends to lag furthest behind on machines that are offline for extended periods, such as laptops belonging to remote or traveling staff.
Step 12: Document the Deployment and Schedule a Recurring Review
Close the loop by writing down what was deployed, when, and why, and put a recurring calendar reminder (quarterly is reasonable) to re-run the inventory query from Step 2. Authentication landscapes shift: new employees join without hardware keys, contractors get temporary access that never gets cleaned up, and new SaaS tools get connected to SSO without anyone checking whether they support FIDO2. A quarterly re-audit catches this drift before it becomes an incident.
This is also a good point to revisit your broader hardening posture. Teams that recently worked through CIS Benchmarks server hardening or a CISA KEV patch workflow already have the discipline needed here — treating authenticator management as another asset class that needs a patch cadence and an owner, not a one-time project.
Example Output: What a Completed Rollout Audit Looks Like
After running the inventory script from Step 2 against a 150-person organization mid-rollout, a typical output file looks like this:
User,Methods
[email protected],"fido2Authenticator, phone"
[email protected],"passwordAuthenticationMethod, smsAuthenticationMethod"
[email protected],"fido2Authenticator, fido2Authenticator"
[email protected],"windowsHelloForBusinessAuthenticationMethod, fido2Authenticator"
[email protected],"passwordAuthenticationMethod"Reading this: Alice has one hardware key registered but no backup — flag for Step 5. Bob is still on password-plus-SMS and needs to be pulled into the next migration wave immediately. Carla has correctly registered two separate hardware keys. The dev team lead has both Windows Hello and a hardware key, a reasonable combination. The contractor account has only a password, and depending on what that account can access, it may need to be disabled outright rather than upgraded.
Common Pitfalls When Deploying Hardware Security Keys
Only buying one key per person. This is the single most common mistake, and it turns a lost key from an inconvenience into a lockout incident. Budget for two keys from day one.
Never testing the backup key. A key that was registered but never actually used to sign in is an assumption, not a working recovery path. Test it in the same session you register it.
Leaving the FIDO2 PIN unset. Many keys work for sign-in without ever prompting for a PIN if user verification is not enforced by the relying party. Explicitly require user verification during registration so a lost key is not usable by whoever finds it.
Assuming a hardware key fixes session hijacking. As the Mirage2FA kit demonstrates, a stolen session cookie bypasses the authenticator entirely because theft happens after successful login. Session-lifetime and continuous access evaluation controls from Step 7 are not optional extras.
Rolling out to everyone at once with no support plan. Enrollment friction (lost keys, unfamiliar UI, forgotten PINs) scales with headcount. Waves with a helpdesk on standby beat a single company-wide rollout every time.
Forgetting non-browser use cases. SSH, VPN clients, and some legacy on-premises applications need separate configuration to accept FIDO2 keys, and teams often secure the browser-based SSO layer while leaving these side doors on passwords.
Not excluding a break-glass account from strict Conditional Access. If every single admin account requires a hardware key and all the keys are locked in a single office that floods, nobody can get back in. One account with an offline recovery path prevents this.
Troubleshooting Guide
| Symptom | Likely Cause | Fix |
|---|---|---|
| Key is inserted but browser does not detect it | Outdated browser or missing WebAuthn support | Update to the current stable channel (Chrome 128+, Edge 126+, Safari 18+) and retry |
| “This site can’t be reached” during registration | Corporate proxy blocking the identity provider’s WebAuthn endpoint | Whitelist the provider’s authentication domain in the proxy/firewall rules |
| PIN prompt never appears, key signs in without verification | Relying party did not request user verification | Check the identity provider’s authentication method policy and enforce “required” user verification |
| Backup key registration fails with “authenticator already registered” | Provider deduplicates by device attestation, not per physical unit, on some legacy configurations | Use a different key model for primary vs. backup, or check provider-specific multi-key documentation |
| NFC key not reading on Android/iOS | NFC disabled in device settings, or case interfering with antenna | Enable NFC, remove thick phone cases, and hold the key flat against the upper back of the phone |
| Conditional Access policy locks out legitimate users unexpectedly | Authentication strength policy applied too broadly, catching service accounts | Scope the policy to specific role groups, exclude service/break-glass accounts explicitly |
| Sign-in frequency setting causes constant re-authentication complaints | Interval set too aggressively for the user population | Start at 4-8 hours for standard users, tighten only for privileged roles |
| User lost both primary and backup key | Backup was stored too close to the primary (same bag, same desk) | Use recovery codes from Step 9, then re-enroll two new keys and revoke the lost ones immediately |
| Chrome still shows synced passkeys after policy push | Group Policy not yet refreshed on the endpoint | Force a policy refresh with gpupdate /force and restart Chrome |
| MSRC advisory shows CVE-2026-34348 as “not applicable” for a given build | Endpoint running an older Windows release outside the patched branch | Upgrade to a currently supported Windows 11 build before re-checking |
How This Fits Into a Broader Identity Security Program
Hardware key deployment does not happen in isolation, and it should not be the only identity project on your roadmap this quarter. The same discipline of inventorying assets, patching on a deadline, and re-auditing on a cycle applies across the rest of your security posture. If your team has not yet run a structured pass on exposed services, our guide on running a vulnerability scan is a natural companion project, since unpatched internet-facing systems remain the most common way attackers get onto an endpoint in the first place, before they ever try to touch a browser’s password vault.
Where Authentication Fits Relative to Network and Endpoint Controls
Strong authentication answers the question “is this really the account owner?” It does not answer “has this endpoint already been compromised in a way that lets an attacker act as the account owner once they are logged in?” That second question is why Step 1’s patch check, Step 7’s session controls, and Step 8’s browser hardening all appear alongside the hardware key rollout instead of being treated as separate projects. A hardware key on a compromised machine still protects the credential itself, but a fully compromised endpoint can still ride an authenticated session, log keystrokes, or wait for the next sensitive action. Treat identity hardening, endpoint patching, and session monitoring as three legs of the same stool rather than three separate initiatives owned by three separate teams that never talk to each other.
Advanced Tips for Larger Deployments
For organizations beyond a few hundred users, look at FIDO2 attestation policies so your identity provider only accepts keys from approved manufacturers, preventing an attacker from registering a cheap, unverified authenticator against a compromised account during a brief window of access. Most enterprise identity providers expose an attestation certificate allowlist specifically for this purpose.
Consider biometric-capable keys (fingerprint-equipped FIDO2 devices) for staff who resist PIN entry, since they satisfy the same phishing-resistant bar while reducing friction. They cost more per unit, typically in the $75-$95 range, but adoption rates tend to run noticeably higher when the second factor is a fingerprint rather than a PIN to remember.
Finally, build the hardware-key requirement into your onboarding and offboarding checklists as a formal, tracked step, not a suggestion in a wiki page. New hires should leave their first IT session with two keys already registered, and departing employees’ keys should be collected and their credentials revoked from the identity provider on their last working day, not whenever someone remembers.
Complete Working Project: A Rollout Audit Script
Putting the pieces together, here is a compact PowerShell script that a small IT team can adapt to pull the authentication method inventory and flag accounts needing migration in one pass — a practical starting point rather than a finished enterprise tool.
# passkey-audit.ps1 — run with Global Reader or higher in Entra ID
param(
[string]$OutputPath = "./passkey-audit-report.csv"
)
Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All","Directory.Read.All"
$results = @()
$users = Get-MgUser -All -Property Id, UserPrincipalName, JobTitle
foreach ($user in $users) {
$methods = Get-MgUserAuthenticationMethod -UserId $user.Id
$methodTypes = $methods | ForEach-Object { $_.AdditionalProperties["@odata.type"] }
$hasHardwareKey = $methodTypes -contains "#microsoft.graph.fido2AuthenticationMethod"
$hasOnlyPassword = ($methodTypes -contains "#microsoft.graph.passwordAuthenticationMethod") -and
(-not $hasHardwareKey) -and
(-not ($methodTypes -contains "#microsoft.graph.windowsHelloForBusinessAuthenticationMethod"))
$riskLevel = if ($hasOnlyPassword) { "HIGH - password/SMS only" }
elseif (-not $hasHardwareKey) { "MEDIUM - no hardware key registered" }
else { "LOW - hardware key present" }
$results += [PSCustomObject]@{
User = $user.UserPrincipalName
JobTitle = $user.JobTitle
Methods = $methodTypes -join "; "
RiskLevel = $riskLevel
}
}
$results | Sort-Object RiskLevel | Export-Csv -Path $OutputPath -NoTypeInformation
Write-Host "Audit complete. $($results.Count) accounts reviewed. Report saved to $OutputPath"
Write-Host "High-risk accounts: $(($results | Where-Object {$_.RiskLevel -like 'HIGH*'}).Count)"Run this weekly during an active rollout and monthly afterward as a maintenance check. The output feeds directly into the wave-based rollout plan from Step 10 — sort by RiskLevel, work the HIGH bucket first, and re-run after each wave to confirm the count is dropping.
Hardware Security Key Comparison
| Key Model | Connector | Biometric | Approx. Price | Best For |
|---|---|---|---|---|
| YubiKey 5C NFC | USB-C + NFC | No | $55 | General enterprise standard, cross-platform |
| YubiKey 5Ci | USB-C + Lightning | No | $60 | Mixed iPhone/laptop workflows |
| Google Titan Security Key (USB-C) | USB-C + NFC + Bluetooth | No | $30 | Budget-conscious Google Workspace shops |
| YubiKey Bio Series | USB-C or USB-A | Fingerprint | $85 | High-friction-averse users, executives |
| Feitian ePass FIDO2 | USB-A/USB-C + NFC | No | $25 | Large-scale budget rollouts |
Prices reflect typical retail listings as of late 2026 and will vary by reseller and order volume. For deployments over 100 units, most manufacturers offer direct enterprise pricing with volume discounts, so contact the vendor directly rather than buying at single-unit retail rates.
Frequently Asked Questions
Does the Pass-ta-key attack affect hardware security keys like a YubiKey?
No. The Unit 42 research targets synced passkeys stored in Google Password Manager and decrypted in Chrome’s memory on Windows. A hardware-bound FIDO2 key never exposes its private key material to the host operating system or browser, so the attack chain does not apply to it.
Is CVE-2026-34348 fully patched now?
Microsoft released a fix on July 14, 2026 that truncates logged authentication signatures to six bytes. Any Windows machine that has installed updates since that date should no longer be vulnerable, but you should confirm this directly against your patch management console rather than assuming it, since offline or infrequently updated devices commonly lag behind.
Should I stop using synced passkeys entirely?
Not necessarily. For low-value personal accounts, synced passkeys remain far better than passwords. The recommendation in this guide is narrower: move privileged, financial, and administrative accounts to hardware-bound keys, and keep synced passkeys for everything else.
Can a hardware key be phished?
The private key material cannot be extracted through phishing, since it never leaves the device. However, a determined attacker running an adversary-in-the-middle proxy can still steal the session token issued after a successful hardware-key login, which is exactly what the Mirage2FA kit does. That is why Step 7’s session-lifetime controls matter as much as the key itself.
What happens if I lose my only hardware key and never registered a backup?
You fall back to whatever recovery method your identity provider offers, typically one-time recovery codes generated at setup or an identity-verification process through IT or the account provider’s support team. This is precisely why Step 5 insists on registering and testing a second key at the same time as the first.
Do hardware keys work with mobile phones?
Yes, most modern FIDO2 keys support NFC or Bluetooth for use with Android and iOS devices in addition to USB connections to laptops and desktops. Confirm your specific phone model and key combination before a full rollout, since NFC placement and case interference vary by device.
How is Mirage2FA different from a normal phishing attack?
A normal phishing page tries to steal a password. Mirage2FA is an adversary-in-the-middle kit: it proxies the real Microsoft 365 login in real time, lets authentication (including MFA or passkeys) complete successfully, and then captures the resulting session cookie. The attacker never needs to defeat the authenticator because they steal what comes after it.
How many organizations are actually using passkeys of any kind in 2026?
According to the FIDO Alliance’s State of Passkeys 2026 report, 68% of organizations are deploying, piloting, or rolling out passkeys for employee authentication, and more than 5 billion passkeys are in active use worldwide as of the May 2026 report.
Related Coverage
- Set Up Content Security Policy: 12 Steps, 90 Min [2026]
- CIS Benchmarks Server Hardening: 13 Steps, 90 Min [2026]
- How to Run a Vulnerability Scan: 12 Steps, 90 Min [2026]
- Steam Guard Setup: Block Account Hacks in 12 Steps [2026]
- How to Encrypt Files: 12 Steps, 90 Min [2026]
