Listen to this Post
Introduction:
Microsoft’s Windows Hello has evolved beyond a simple biometric login. When configured as a passkey (not to be confused with Windows Hello for Business), it creates a phishing‑resistant, FIDO2‑based credential that can roam across tenants without any device management. This means a student on a personal laptop can seamlessly sign into an Azure Virtual Desktop (AVD) session hosted in a completely separate Entra ID tenant – using only their face or fingerprint – while the passkey remains bound to the device’s TPM for hardware‑level security.
Learning Objectives:
- Understand how Windows Hello passkeys differ from WHFB and enable cross‑tenant, device‑unmanaged authentication.
- Configure and test passkey redirection for AVD sessions using local accounts or cross‑tenant Entra ID.
- Identify the security trade‑offs between TPM‑bound and software‑based passkeys, and implement blocking policies via AAGUID.
You Should Know
- Windows Hello Passkey vs. Windows Hello for Business – The Core Distinction
Windows Hello as a passkey is a FIDO2 credential that lives in the Windows WebAuthn layer. Unlike Windows Hello for Business (WHFB), it does not require device join (Hybrid or Entra Join), device management (Intune/MDM), or even a tenant relationship with the resource you are accessing. The passkey is created locally and, if the device has a TPM 2.0, becomes device‑bound – the private key never leaves the TPM.
When is this available?
The feature is rolling out via Windows Update and Entra ID tenant configuration. It appears under “Sign‑in options” → “Passkey” after registration. Check if your tenant supports it:
Windows PowerShell (Admin) – Check WebAuthn capability
Get-WindowsCapability -Online | Where-Object { $_.Name -like "WebAuthn" }
Step‑by‑step to register a Windows Hello passkey:
- Go to Settings → Accounts → Passkeys (or Sign‑in options).
- Click “Set up a passkey” – choose “Windows Hello” (face, fingerprint, or PIN).
- Follow biometric enrollment. The system will generate a FIDO2 credential.
- The passkey now appears in your Microsoft account’s passkey list (under account.microsoft.com).
To verify TPM binding:
Get-Tpm | Select-Object TpmReady, TpmPresent, ManufacturerVersion
- Cross‑Tenant AVD Sign‑in with Local Accounts – Pass‑Through Magic
Jay Kerai’s post highlights a killer scenario: using your face to sign into an AVD session in another tenant where your device is unknown, and the passkey remains usable inside the session. This works because AVD supports passkey redirection – the WebAuthn request from the remote session is routed to the local Windows Hello provider.
Step‑by‑step to enable and test cross‑tenant AVD passkey:
- On the AVD session host (Windows 10/11 multi‑session): Ensure RDP properties include WebAuthn redirection.
Via Intune or PowerShell:
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" -Name "fDisableWebAuthn" -Value 0
2. On the client device (any Windows 11 with Windows Hello passkey registered):
– Open Remote Desktop client, connect to the AVD workspace.
– When the login prompt appears, select “Sign‑in options” → “Passkey”.
– Windows will invoke the local Windows Hello prompt – use face/PIN.
– The remote session receives the assertion and logs you in, without the target tenant ever seeing your device ID.
3. Inside the AVD session, test passkey reuse: open a WebAuthn‑enabled site (e.g., webauthn.io). The session will again redirect to your local Windows Hello.
Why this is a game changer for MSPs: When GDAP breaks or you need a local account in a customer “red” tenant, you no longer type a password. Just a local account with a registered passkey on your jump box – zero password exposure.
- TPM‑Bound vs. Software Passkeys – Securing the Weakest Link
By default, Windows Hello passkeys use the TPM if present. However, on devices without a TPM (or with TPM emulation disabled), Windows falls back to a software‑based passkey – the private key is stored in the Windows OS keystore (Cryptography Next Generation). While still phishing‑resistant, a software key can be extracted by malware with system privileges.
Blocking software passkeys via AAGUID:
Microsoft exposes a unique AAGUID for software‑only Windows Hello passkeys:
`6028b017-b1d4-4c02-b4b3-afcdafc96bb2`
Step‑by‑step to create a Conditional Access policy that blocks this AAGUID:
1. In Entra ID admin center → Protection → Authentication strengths.
2. Create a new strength → Add “Passkey (FIDO2)”.
3. Under “Exclude specific authenticators”, add the AAGUID above.
4. Assign this authentication strength to a Conditional Access policy that requires it for sensitive apps.
PowerShell equivalent (using Microsoft Graph):
Connect-MgGraph -Scopes Policy.ReadWrite.AuthenticationMethod
$params = @{
displayName = "Block Software Passkeys"
allowedCombinations = @("password")
authenticationMethodConfigurations = @(
@{
id = "Fido2"
state = "enabled"
excludedAuthenticatorGuids = @("6028b017-b1d4-4c02-b4b3-afcdafc96bb2")
}
)
}
New-MgPolicyAuthenticationStrengthPolicy @params
- BYOD Without Management – Education and Emergency Access
The post calls out education as a massive win: students can bring any personal device, register a Windows Hello passkey using their face (no phone required), and access class resources in a managed tenant. The device never needs to be Entra joined, Intune enrolled, or even touched by IT.
For university IT admins – enabling this scenario:
- Ensure the resource tenant (e.g., office365.contoso.edu) has FIDO2 passkey enabled as an authentication method.
- Instruct students to register a passkey on their personal Windows device via Settings → Accounts → Passkeys.
- For web apps, the passkey is presented via the browser’s WebAuthn API. For AVD, follow the redirection steps above.
Security note: Because the device is unmanaged, you cannot enforce BitLocker or antivirus. However, the passkey itself is hardware‑bound (if TPM present) – stealing the device without the user’s face or PIN yields nothing. This is infinitely better than password‑based BYOD.
- Phishing Resistance – Why Passkeys Destroy Passwords (Even Without WHFB)
Windows Hello passkeys are phishing‑resistant by design. The WebAuthn protocol binds the credential to the origin (domain) of the website or RDP endpoint. An attacker’s fake login page cannot trigger the Windows Hello prompt because the origin will not match. This stops credential harvesting, man‑in‑the‑middle attacks, and even sophisticated adversary‑in‑the‑middle (AiTM) phishing that bypasses SMS and app‑based MFA.
Compare security levels:
| Method | Phishing Resistant | Device Bound | Requires Management |
|–|–|–|-|
| Password | No | No | No |
| TOTP/SMS | No | No | No |
| WHFB (full) | Yes | Yes (TPM) | Yes |
| Windows Hello passkey (TPM) | Yes | Yes | No |
| Windows Hello passkey (software) | Yes | No | No |
Limitation: Windows Hello passkey does not provide the same anti‑replay or hardware attestation features as WHFB with certificate trust. For highly regulated environments (e.g., DoD, finance), WHFB remains the gold standard. But as Jay Kerai says: “if the alternative is passwords then I know what I am picking.”
6. Verification and Troubleshooting – Commands You Need
Check which passkeys are registered on your device (Windows):
Enumerate WebAuthn credentials certutil -csp "Microsoft Passport Key Storage Provider" -key -user
Force TPM usage only – disable software fallback:
reg add "HKLM\SOFTWARE\Policies\Microsoft\PassportForWork" /v "RequireSecurityDevice" /t REG_DWORD /d 1 /f
Test passkey authentication flow with a local web server (Linux admin’s view – though passkeys are Windows‑centric, you can test WebAuthn):
On Linux, use docker to run a WebAuthn test server docker run -p 8080:8080 ghcr.io/mastercard/webauthn-test-server
Then access `http://localhost:8080` from a Windows machine. Windows will offer to use a passkey if enrolled.
View AAGUID of an existing passkey:
Use the browser’s developer tools → Application → WebAuthn (Chromium) or about:webauthn (Edge). The AAGUID for Windows Hello hardware is 08987058-cadc-4b81-b6e1-30de50dcbe96. The software fallback is 6028b017-b1d4-4c02-b4b3-afcdafc96bb2.
- Future Outlook – From Cross‑Tenant Passkeys to Passwordless Everywhere
Microsoft is clearly betting on passkeys as the successor to passwords. The ability to use Windows Hello as a passkey across tenants without management closes a critical gap: consumer‑grade usability with enterprise‑grade phishing resistance. Expect to see this extended to:
– Linux desktops via third‑party WebAuthn providers (e.g., PAM module for FIDO2).
– Mobile AVD clients passing through Apple FaceID/TouchID as passkeys.
– Entra ID External Identities (B2B) allowing passkey auth for guest users from any device.
What Undercode Says:
- Passkeys are not just for websites – RDP and AVD redirection turn desktop virtualization into a passwordless frontier.
- Block software passkeys via the provided AAGUID unless you fully trust the device’s OS integrity.
- MSPs should standardize on local account + TPM‑bound passkey for break‑glass access – no more password spreadsheets.
Prediction: Within 18 months, major identity providers will treat “Windows Hello passkey” as a separate, fully supported authenticator. Cross‑tenant authentication will become the default for BYOD scenarios, forcing password retirement even in unmanaged environments. However, the tension between convenience (software passkeys) and security (TPM) will lead to a new class of conditional access policies based on authenticator attestation.
▶️ Related Video (72% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Jay Kerai – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
