How to Deploy Phishing-Resistant Passwordless Auth in Microsoft Entra ID

Start by evaluating your organization's device landscape and user personas to select the right phishing-resistant methods. Microsoft Entra ID supports several options: passkeys (including the new Windows passkey preview), FIDO2 security keys, Windows Hello for Business, and certificate-based authentication.

Sign in to the Microsoft Entra admin center at entra.microsoft.com and navigate to Identity > Users > All users to review your user base. Document which users have:

• Windows devices (Entra-joined, registered, or unmanaged)
• Mobile devices with Microsoft Authenticator
• Need for hardware security keys
• Administrative privileges requiring high assurance

For new users without existing passwords, plan to use Temporary Access Pass (TAP) or Microsoft Entra Verified ID for bootstrapping their first phishing-resistant credential.

Configure the authentication methods policy to enable phishing-resistant options. By default, FIDO2 security keys are disabled and must be manually enabled.

In the Microsoft Entra admin center, navigate to Protection > Authentication methods > Policies. You'll see a list of available methods:

# Check current authentication methods via PowerShell (optional)
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgPolicyAuthenticationMethodPolicy | Select-Object -ExpandProperty AuthenticationMethodConfigurations

Enable each method you plan to use:

1. FIDO2 security keys: Click on "FIDO2 security keys" and set Enable to "Yes". Configure target users (start with your pilot group).
2. Microsoft Authenticator: Ensure it's enabled and configure for passwordless phone sign-in.
3. Windows Hello for Business: This is typically enabled through device management policies.

For the new Microsoft Entra passkey on Windows (public preview as of March 2026), opt-in via the Microsoft 365 message center notification that appeared in mid-March 2026.

Set up Temporary Access Pass (TAP) to bootstrap new users without requiring an initial password. This is crucial for truly passwordless onboarding.

In the Entra admin center, go to Protection > Authentication methods > Policies > Temporary Access Pass. Configure these settings:

• Enable: Yes
• Target users: Select specific groups or all users
• Minimum lifetime: 60 minutes
• Maximum lifetime: 24 hours
• Default lifetime: 8 hours
• One-time use: Yes (recommended for security)

To create a TAP for a new user, navigate to Identity > Users > [Select User] > Authentication methods and click + Add authentication method:

{
  "@odata.type": "#microsoft.graph.temporaryAccessPassAuthenticationMethod",
  "startDateTime": "2026-04-26T09:00:00.000Z",
  "lifetimeInMinutes": 480,
  "isUsableOnce": true
}

Alternatively, use Microsoft Graph API to automate TAP creation:

# Create TAP via PowerShell
$userId = "user@contoso.com"
$tapParams = @{
    startDateTime = (Get-Date).ToString("yyyy-MM-ddTHH:mm:ss.fffZ")
    lifetimeInMinutes = 480
    isUsableOnce = $true
}
New-MgUserAuthenticationTemporaryAccessPassMethod -UserId $userId -BodyParameter $tapParams

For organizations using hardware security keys, provision FIDO2 keys on behalf of users using the Microsoft Graph API. This centralizes key management and ensures proper registration.

First, obtain the necessary Graph API permissions. You'll need UserAuthenticationMethod.ReadWrite.All scope:

# Connect with required permissions
Connect-MgGraph -Scopes "UserAuthenticationMethod.ReadWrite.All"

# Provision FIDO2 key for a user
$userId = "user@contoso.com"
$fido2Params = @{
    displayName = "YubiKey 5 Series"
    model = "YubiKey 5C NFC"
    aaGuid = "cb69481e-8ff7-4039-93ec-0a2729a154a8"  # YubiKey AAGUID
}

# Create the FIDO2 method
New-MgUserAuthenticationFido2Method -UserId $userId -BodyParameter $fido2Params

For bulk provisioning, create a CSV file with user information and iterate through it:

# Bulk FIDO2 key provisioning
$users = Import-Csv "users.csv"  # Columns: UserPrincipalName, KeyModel, KeyAAGUID

foreach ($user in $users) {
    try {
        $fido2Params = @{
            displayName = "$($user.KeyModel) - $(Get-Date -Format 'yyyy-MM-dd')"
            model = $user.KeyModel
            aaGuid = $user.KeyAAGUID
        }
        
        New-MgUserAuthenticationFido2Method -UserId $user.UserPrincipalName -BodyParameter $fido2Params
        Write-Host "✓ Provisioned FIDO2 key for $($user.UserPrincipalName)" -ForegroundColor Green
    }
    catch {
        Write-Warning "Failed to provision key for $($user.UserPrincipalName): $($_.Exception.Message)"
    }
}

Common FIDO2 key AAGUIDs for reference:

Enable the new Microsoft Entra passkey on Windows feature, which became available in public preview in March 2026. This allows device-bound passkeys in the Windows Hello container for unmanaged Windows devices.

First, check if your tenant received the opt-in notification. In the Microsoft 365 admin center, go to Health > Message center and look for the "Microsoft Entra passkey on Windows" announcement from mid-March 2026.

To opt-in to the preview:

1. Navigate to the Microsoft Entra admin center
2. Go to Identity > Authentication methods > Policies
3. Look for "Microsoft Entra passkey (preview)" in the methods list
4. Enable it for your pilot group

Configure the policy settings:

{
  "@odata.type": "#microsoft.graph.microsoftAuthenticatorAuthenticationMethodConfiguration",
  "state": "enabled",
  "includeTargets": [
    {
      "targetType": "group",
      "id": "pilot-group-id",
      "isRegistrationRequired": false
    }
  ],
  "featureSettings": {
    "displayAppInformationRequiredState": {
      "state": "enabled",
      "includeTarget": {
        "targetType": "group",
        "id": "pilot-group-id"
      }
    }
  }
}

Users in the pilot group can now register passkeys on their Windows devices:

1. Navigate to myaccount.microsoft.com
2. Go to Security info > Add sign-in method
3. Select "Passkey in Windows Hello"
4. Follow the prompts to create a device-bound passkey using face, fingerprint, or PIN

Enforce phishing-resistant authentication through Conditional Access policies. This is where you'll require users to use only the strong authentication methods you've configured.

Navigate to Protection > Conditional Access > Policies and click + New policy. Create a policy with these settings:

Policy Name: "Require Phishing-Resistant MFA - Pilot Group"

Assignments:

• Users: Select your pilot group
• Cloud apps: All cloud apps
• Conditions: Configure as needed (e.g., exclude trusted locations)

Access controls:

• Grant: Grant access
• Require authentication strength: Select "Phishing-resistant multifactor authentication"

Here's the policy configuration in JSON format for reference:

{
  "displayName": "Require Phishing-Resistant MFA - Pilot Group",
  "state": "enabledForReportingButNotEnforced",
  "conditions": {
    "users": {
      "includeGroups": ["pilot-group-id"],
      "excludeUsers": ["break-glass-account-id"]
    },
    "applications": {
      "includeApplications": ["All"]
    }
  },
  "grantControls": {
    "operator": "AND",
    "authenticationStrength": {
      "id": "00000000-0000-0000-0000-000000000004"  # Phishing-resistant MFA
    }
  }
}

For administrative users, create a separate, more restrictive policy:

# PowerShell to create admin-specific policy
$adminPolicy = @{
    displayName = "Admin - Require Phishing-Resistant MFA"
    state = "enabled"
    conditions = @{
        users = @{
            includeRoles = @(
                "62e90394-69f5-4237-9190-012177145e10",  # Global Administrator
                "194ae4cb-b126-40b2-bd5b-6091b380977d",  # Security Administrator
                "7be44c8a-adaf-4e2a-84d6-ab2649e08a13"   # Privileged Authentication Administrator
            )
            excludeUsers = @("break-glass-account-id")
        }
        applications = @{
            includeApplications = @("All")
        }
    }
    grantControls = @{
        operator = "AND"
        authenticationStrength = @{
            id = "00000000-0000-0000-0000-000000000004"
        }
    }
}

# Apply the policy
New-MgIdentityConditionalAccessPolicy -BodyParameter $adminPolicy

Validate the end-to-end user experience by testing registration and authentication flows with your pilot group. This step ensures everything works before broader deployment.

Test Scenario 1: New User with TAP

1. Create a test user and generate a TAP
2. Provide the TAP to the user
3. Have them sign in at myaccount.microsoft.com using the TAP
4. Guide them through registering their first phishing-resistant method

Test Scenario 2: Existing User Adding Passkey

1. Have a pilot user sign in with their current method
2. Navigate to Security info > Add sign-in method
3. Register a passkey or FIDO2 key
4. Test signing in with the new method

Monitor the authentication process using PowerShell:

# Check recent sign-ins for your test users
$testUsers = @("testuser1@contoso.com", "testuser2@contoso.com")

foreach ($user in $testUsers) {
    $signIns = Get-MgAuditLogSignIn -Filter "userPrincipalName eq '$user'" -Top 10
    
    foreach ($signIn in $signIns) {
        Write-Host "User: $($signIn.UserPrincipalName)"
        Write-Host "Date: $($signIn.CreatedDateTime)"
        Write-Host "Auth Method: $($signIn.AuthenticationMethodsUsed)"
        Write-Host "Status: $($signIn.Status.ErrorCode)"
        Write-Host "---"
    }
}

Test different scenarios:

• Windows Hello: Face recognition, fingerprint, and PIN
• FIDO2 keys: USB insertion and touch verification
• Passkeys: Cross-platform and platform authenticators
• Conditional Access: Verify policies trigger correctly

Document any issues in a test matrix:

Set up comprehensive monitoring to track authentication events, identify issues, and ensure security. Microsoft Entra ID provides detailed logs and reporting capabilities.

Configure authentication method activity monitoring in the Entra admin center:

1. Navigate to Monitoring > Sign-ins
2. Apply filters for authentication methods: "FIDO2 security key", "Windows Hello for Business", "Passkey"
3. Set up alerts for failed authentication attempts

Use PowerShell to create custom monitoring scripts:

# Monitor phishing-resistant authentication usage
$startDate = (Get-Date).AddDays(-7).ToString("yyyy-MM-dd")
$endDate = (Get-Date).ToString("yyyy-MM-dd")

# Get sign-ins using phishing-resistant methods
$phishingResistantSignIns = Get-MgAuditLogSignIn -Filter "createdDateTime ge $startDate and createdDateTime le $endDate" | 
    Where-Object { 
        $_.AuthenticationMethodsUsed -match "FIDO2|WindowsHello|Passkey" 
    }

# Generate usage report
$report = $phishingResistantSignIns | Group-Object AuthenticationMethodsUsed | 
    Select-Object Name, Count, @{Name="Percentage"; Expression={[math]::Round(($_.Count / $phishingResistantSignIns.Count) * 100, 2)}}

$report | Format-Table -AutoSize

# Export to CSV for further analysis
$report | Export-Csv "PhishingResistantAuthReport.csv" -NoTypeInformation

Set up Microsoft Entra ID Protection for advanced threat detection:

1. Navigate to Protection > Identity Protection
2. Enable risk policies for user and sign-in risks
3. Configure automated responses to high-risk events

Create a SIEM integration for centralized monitoring:

# Export authentication logs to SIEM
$logAnalyticsWorkspace = "your-workspace-id"
$sharedKey = "your-shared-key"

# Function to send logs to Azure Monitor
function Send-LogAnalyticsData {
    param(
        [string]$WorkspaceId,
        [string]$SharedKey,
        [object]$Body,
        [string]$LogType
    )
    
    # Implementation for sending logs to Azure Monitor
    # This would include proper authentication and data formatting
}

# Send authentication events
$authEvents = Get-MgAuditLogSignIn -Top 1000 | 
    Where-Object { $_.CreatedDateTime -gt (Get-Date).AddHours(-1) }

Send-LogAnalyticsData -WorkspaceId $logAnalyticsWorkspace -SharedKey $sharedKey -Body $authEvents -LogType "EntraAuthEvents"

Common troubleshooting scenarios:

• FIDO2 key not recognized: Check browser compatibility and key firmware
• Windows Hello enrollment fails: Verify TPM 2.0 and biometric hardware
• Passkey registration blocked: Check Conditional Access policies and browser settings
• Cross-device sync issues: Remember that Entra passkeys are device-bound (no sync)

After successful pilot testing, expand phishing-resistant authentication to your entire organization. This requires careful planning and phased rollout to minimize disruption.

Phase 1: Expand to Department Groups

Update your Conditional Access policies to include larger user groups:

# Update existing policy to include more users
$policyId = "your-pilot-policy-id"
$policy = Get-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policyId

# Add additional groups
$updatedConditions = $policy.Conditions
$updatedConditions.Users.IncludeGroups += @(
    "department-it-group-id",
    "department-finance-group-id",
    "department-hr-group-id"
)

# Update the policy
Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policyId -Conditions $updatedConditions

Phase 2: Bulk User Provisioning

Automate the provisioning process for large numbers of users:

# Bulk TAP creation for new user onboarding
$newUsers = Import-Csv "new_users.csv"  # UserPrincipalName, Department, Manager

foreach ($user in $newUsers) {
    try {
        # Create user account
        $userParams = @{
            displayName = $user.DisplayName
            userPrincipalName = $user.UserPrincipalName
            mailNickname = $user.UserPrincipalName.Split('@')[0]
            accountEnabled = $true
            passwordProfile = @{
                forceChangePasswordNextSignIn = $false
                password = "TempPass123!"  # Will be replaced by TAP
            }
        }
        
        $newUser = New-MgUser -BodyParameter $userParams
        
        # Create TAP for passwordless onboarding
        $tapParams = @{
            startDateTime = (Get-Date).ToString("yyyy-MM-ddTHH:mm:ss.fffZ")
            lifetimeInMinutes = 1440  # 24 hours
            isUsableOnce = $true
        }
        
        $tap = New-MgUserAuthenticationTemporaryAccessPassMethod -UserId $newUser.Id -BodyParameter $tapParams
        
        # Send TAP to user via secure channel (email, SMS, etc.)
        Send-WelcomeEmail -UserEmail $user.UserPrincipalName -TAP $tap.TemporaryAccessPass
        
        Write-Host "✓ Created user and TAP for $($user.UserPrincipalName)" -ForegroundColor Green
    }
    catch {
        Write-Warning "Failed to create user $($user.UserPrincipalName): $($_.Exception.Message)"
    }
}

Phase 3: Legacy Authentication Cleanup

Gradually disable legacy authentication protocols:

1. Navigate to Protection > Conditional Access > Policies
2. Create a new policy: "Block Legacy Authentication"
3. Target all users except service accounts
4. Block access for legacy authentication clients

{
  "displayName": "Block Legacy Authentication",
  "state": "enabledForReportingButNotEnforced",
  "conditions": {
    "users": {
      "includeUsers": ["All"],
      "excludeUsers": ["service-account-1", "service-account-2"]
    },
    "applications": {
      "includeApplications": ["All"]
    },
    "clientAppTypes": [
      "exchangeActiveSync",
      "other"
    ]
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": ["block"]
  }
}

Phase 4: Communication and Training

Develop user communication materials:

• Email templates explaining the new authentication methods
• Video tutorials for registering passkeys and FIDO2 keys
• IT helpdesk scripts for common issues
• Manager talking points for team meetings