Phishing-Resistant Authentication with FIDO2, TAP and Windows Hello

Lab Metadata

Core technologies

Scenario and Description

Lab 03 enforced MFA for everyone at Northgate. That defeats the commonest attacks, but it does not defeat the most dangerous one aimed at privileged staff: adversary-in-the-middle phishing. A tool such as a reverse-proxy phishing kit sits between the user and the real Microsoft sign-in page, captures the password, relays the MFA prompt, and steals the resulting session token. App push, SMS and one-time codes are all phishable this way, because the user is tricked into completing a genuine challenge on the attacker's behalf.

Phishing-resistant methods break this. FIDO2 security keys and Windows Hello for Business use public-key cryptography bound to the real sign-in origin. The credential will not release a signature to a look-alike domain, so a proxy has nothing to relay. There is no shared secret to capture. This is why the brief calls for deploying "enhanced robust authentication, such as YubiKeys, for operational support accounts", these are the accounts an attacker most wants and most targets.

You will enable FIDO2 and Temporary Access Pass in the Authentication Methods policy, issue a Temporary Access Pass so a support engineer can bootstrap a security key with no password at all, register and verify a FIDO2 key, optionally restrict which key models are permitted, and then upgrade the CA002 admin policy from "require MFA" to "require phishing-resistant authentication strength". Finally you set up Windows Hello for Business for standard corporate devices.

Prerequisites

Prior labs

Labs 01, 02 and 03 are required. This lab upgrades the CA002 admin policy created in Lab 03 and relies on the break-glass accounts from Lab 03 staying excluded. The Authentication Methods policy from Lab 02 is where FIDO2 and TAP are enabled.

Hardware note

Graph scopes introduced

Real-World Problem Statement

Privileged and operational support accounts are the highest-value targets in any tenant. Protecting them with a phishable factor leaves the crown jewels one convincing email away from compromise. The problem is not only choosing a phishing-resistant method, it is onboarding people onto it without a password bootstrap that reintroduces the weakness.

Concrete scenario: Northgate has 30 operational support engineers with standing access to sensitive systems. The CISO wants every one of them on a hardware security key within a fortnight, onboarded without emailing passwords around, and wants the admin Conditional Access policy to reject anything less than a phishing-resistant credential.

Skills Mapped to Production Solutions

Architecture Overview

The flow has two halves. Onboarding: a Temporary Access Pass lets a passwordless user register a FIDO2 key. Enforcement: Conditional Access requires an authentication strength that only phishing-resistant methods satisfy.

Step-by-Step Implementation

Phase A - Enable the phishing-resistant methods

Connect-MgGraph -Scopes 'Policy.ReadWrite.AuthenticationMethod',
  'UserAuthenticationMethod.ReadWrite.All','Policy.ReadWrite.ConditionalAccess' -NoWelcome

# --- FIDO2 security keys ---
$fido2Body = @{
  '@odata.type' = '#microsoft.graph.fido2AuthenticationMethodConfiguration'
  state = 'enabled'
  isSelfServiceRegistrationAllowed = $true
  isAttestationEnforced = $true            # require the key to prove its make and model
  includeTargets = @(@{ targetType='group'; id='all_users' })
}
Update-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
  -AuthenticationMethodConfigurationId 'Fido2' -BodyParameter $fido2Body

# --- Temporary Access Pass ---
$tapBody = @{
  '@odata.type' = '#microsoft.graph.temporaryAccessPassAuthenticationMethodConfiguration'
  state = 'enabled'
  defaultLifetimeInMinutes = 60
  defaultLength = 8
  isUsableOnce = $true                      # one-time use is the safer default for onboarding
  minimumLifetimeInMinutes = 10
  maximumLifetimeInMinutes = 480
  includeTargets = @(@{ targetType='group'; id='all_users' })
}
Update-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
  -AuthenticationMethodConfigurationId 'TemporaryAccessPass' -BodyParameter $tapBody

'Fido2','TemporaryAccessPass' | ForEach-Object {
  (Get-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
    -AuthenticationMethodConfigurationId $_) | Select-Object Id,State }
# Expected: both show State = enabled

Phase B - Onboard a support engineer passwordless

$domain = (Get-MgOrganization).VerifiedDomains | Where-Object IsDefault | Select-Object -ExpandProperty Name

# Group to hold operational support accounts (used for targeting later).
$ops = New-MgGroup -DisplayName 'Ops-Support-PhishResistant' -MailEnabled:$false `
  -MailNickname 'ops-support-pr' -SecurityEnabled:$true
$lokafor = Get-MgUser -Filter "userPrincipalName eq 'lokafor@$domain'"
New-MgGroupMember -GroupId $ops.Id -DirectoryObjectId $lokafor.Id

# Issue a one-time TAP valid for 60 minutes.
$tap = New-MgUserAuthenticationTemporaryAccessPassMethod -UserId $lokafor.Id `
  -BodyParameter @{ isUsableOnce = $true; lifetimeInMinutes = 60 }

Write-Host "TAP for lokafor: $($tap.TemporaryAccessPass)" -ForegroundColor Yellow
Write-Host "Valid until: $($tap.StartDateTime.AddMinutes(60))"

# USER STEP (lokafor, in a browser):
# 1. Go to https://aka.ms/mysecurityinfo and sign in using the TAP.
# 2. Add sign-in method > Security key (or Passkey), follow the prompts,
#    touch the key when asked, and give it a name such as 'YubiKey-lokafor'.

# ADMIN VERIFICATION (Graph): read the registered FIDO2 methods.
Get-MgUserAuthenticationFido2Method -UserId $lokafor.Id |
  Select-Object DisplayName, Model, AaGuid, CreatedDateTime

# Populate with the AAGUIDs of models you approve. Yubico publishes these,
# and you can read one from a registered key with Get-MgUserAuthenticationFido2Method.
$approvedAaGuids = @(
  '<yubikey-5-series-aaguid>',
  '<yubikey-5-nfc-aaguid>'
)

$restrictBody = @{
  '@odata.type' = '#microsoft.graph.fido2AuthenticationMethodConfiguration'
  state = 'enabled'
  isAttestationEnforced = $true
  keyRestrictions = @{
    isEnforced = $true
    enforcementType = 'allow'     # only these AAGUIDs may register; use 'block' to deny specific ones
    aaGuids = $approvedAaGuids
  }
  includeTargets = @(@{ targetType='group'; id='all_users' })
}
Update-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
  -AuthenticationMethodConfigurationId 'Fido2' -BodyParameter $restrictBody

Phase C - Demand phishing-resistant strength for admins

$ca002 = Get-MgIdentityConditionalAccessPolicy `
  -Filter "displayName eq 'CA002 - Require MFA for admin roles'"

$prStrengthId = '00000000-0000-0000-0000-000000000004'  # built-in: Phishing-resistant MFA

$update = @{
  grantControls = @{
    operator = 'OR'
    builtInControls = @()
    'authenticationStrength@odata.bind' =
      "https://graph.microsoft.com/v1.0/policies/authenticationStrengthPolicies/$prStrengthId"
  }
  # Keep it report-only first if you want to preview, then set to enabled.
  state = 'enabledForReportingButNotEnforced'
}

Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $ca002.Id -BodyParameter $update

Phase D - Windows Hello for Business

# WHfB is device-provisioned, not a single Graph call. The enablement path:
#
# 1. Microsoft Intune admin center > Devices > Enrollment >
#    Windows Hello for Business. Set 'Configure Windows Hello for Business' = Enabled.
# 2. Set PIN policy (length, complexity) and enable biometric use.
# 3. For hybrid access to on-prem resources, deploy 'cloud Kerberos trust':
#    run the Entra Kerberos server object setup on a domain controller
#    (Set-AzureADKerberosServer via the AzureADHybridAuthenticationManagement module).
#
# Result: on an enrolled Windows device, the user provisions a PIN or face/fingerprint,
# which becomes a phishing-resistant credential that satisfies the same authentication
# strength you applied to CA002.

Testing and Validation

1. TAP onboarding: sign in as lokafor using the issued TAP, confirm you reach the security-info page without a password.
2. Key registration: register a key, then confirm it via Get-MgUserAuthenticationFido2Method.
3. Strength enforcement (report-only): as jpatel, app push yields reportOnlyFailure on CA002, the key yields reportOnlySuccess.
4. Break-glass safety: confirm CA002 still shows notApplied for break-glass before you enforce.

Security Analysis

What makes this sound

• Origin binding: FIDO2 and WHfB credentials refuse to sign for a look-alike domain, defeating adversary-in-the-middle phishing that beats app and SMS MFA.
• Passwordless bootstrap: Temporary Access Pass removes the password from onboarding, so there is no weak credential to phish during rollout.
• Quality-based enforcement: authentication strengths let Conditional Access demand a specific credential class for privileged access, not merely any second factor.

Intentionally simplified for the lab

• The AAGUID allowlist uses placeholders. Production populates it from your approved hardware catalogue.
• WHfB is described at the enablement and architecture level, its full device rollout is an Intune workstream in its own right.
• TAP delivery is manual. At scale, integrate issuance into a governed onboarding or recovery workflow.

Production hardening

• Enforce attestation and an AAGUID allowlist so only vetted keys can register.
• Apply the phishing-resistant strength to all privileged roles and to access to your most sensitive applications, not admins alone.
• Monitor for any downgrade of an admin policy from a phishing-resistant strength to plain MFA as a tamper signal.

Cleanup Instructions

$ca002 = Get-MgIdentityConditionalAccessPolicy -Filter "displayName eq 'CA002 - Require MFA for admin roles'"
Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $ca002.Id -BodyParameter @{
  grantControls = @{ operator='OR'; builtInControls=@('mfa'); 'authenticationStrength@odata.bind'=$null } }

$g = Get-MgGroup -Filter "displayName eq 'Ops-Support-PhishResistant'"
if ($g) { Remove-MgGroup -GroupId $g.Id }

# Remove a test FIDO2 method if you want a clean slate:
# Get-MgUserAuthenticationFido2Method -UserId $lokafor.Id | ForEach-Object {
#   Remove-MgUserAuthenticationFido2Method -UserId $lokafor.Id -Fido2AuthenticationMethodId $_.Id }
Disconnect-MgGraph

Recommended Learning Links

• Passwordless authentication options
• Enable FIDO2 security key sign-in
• Configure Temporary Access Pass
• Conditional Access authentication strengths
• Windows Hello for Business
• FIDO Alliance specifications (WebAuthn, CTAP)

Key Takeaways and Next Lab

• App and SMS MFA are phishable by real-time proxies. FIDO2 and Windows Hello are not, because credentials are bound to the real origin.
• Temporary Access Pass onboards users to passwordless with no password in the loop.
• Authentication strengths let Conditional Access demand a credential class, protecting privileged access specifically.
• Confirm every targeted admin holds a phishing-resistant method before enforcing, break-glass remains the safety net.