IAM4.7 Authentication Strength Policies

Why "require MFA" isn't enough

A Conditional Access policy that requires MFA treats all MFA methods as equivalent. A user who authenticates with password + SMS satisfies the same MFA requirement as a user who authenticates with a FIDO2 security key. From the Conditional Access engine's perspective, both are "MFA-authenticated." But from a security perspective, the SMS user is vulnerable to SIM swapping, SS7 interception, and AiTM phishing. The FIDO2 user is resistant to all three. The MFA requirement doesn't distinguish between these outcomes.

Authentication strength policies solve this by replacing the binary "require MFA" grant control with a granular "require specific authentication methods" grant control. Instead of "this access requires MFA," you define "this access requires phishing-resistant authentication", and the policy engine checks whether the user's actual authentication method satisfies that specific strength requirement.

This is how you build tiered access controls. Standard resources require any MFA method (password + Authenticator push is fine). Sensitive resources require passwordless methods (Authenticator passkey, WHfB, FIDO2). Privileged resources require phishing-resistant methods on managed devices (FIDO2 or WHfB only, not Authenticator passkey, which runs on unmanaged phones). Each tier maps to a different authentication strength policy, and each strength policy maps to specific Conditional Access policies in Module 5.

Estimated time: 50 minutes.

Built-in authentication strengths

Entra ID provides three built-in authentication strength policies that you can reference directly in Conditional Access grant controls.

Query the built-in authentication strengths:

$strengths = Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/policies/authenticationStrengthPolicies" `
  -OutputType PSObject

foreach ($s in $strengths.value) {
    Write-Host "$($s.displayName) (ID: $($s.id))"
    Write-Host "  Policy type: $($s.policyType)"
    Write-Host "  Allowed combinations:"
    foreach ($combo in $s.allowedCombinations) {
        Write-Host "    $combo"
    }
    Write-Host ""
}

MFA strength (ID: 00000000-0000-0000-0000-000000000002)
  Policy type: builtIn
  Allowed combinations:
    windowsHelloForBusiness
    fido2
    x509CertificateMultiFactor
    deviceBasedPush
    temporaryAccessPassOneTime
    password,microsoftAuthenticatorPush
    password,softwareOath
    password,hardwareOath
    password,sms
    password,voice

Passwordless MFA strength (ID: 00000000-0000-0000-0000-000000000003)
  Policy type: builtIn
  Allowed combinations:
    windowsHelloForBusiness
    fido2
    x509CertificateMultiFactor
    deviceBasedPush

Phishing-resistant MFA strength (ID: 00000000-0000-0000-0000-000000000004)
  Policy type: builtIn
  Allowed combinations:
    windowsHelloForBusiness
    fido2
    x509CertificateMultiFactor

Study the differences. MFA strength includes password,sms and password,voice: the weakest MFA combinations. Passwordless MFA adds deviceBasedPush (Authenticator passkey), which is passwordless but still involves a phone. Phishing-resistant excludes everything except hardware-backed, domain-verifying methods. The built-in strengths cover the three tiers from the diagram above, but you may need custom strengths for edge cases.

The combination strings use a specific syntax. A single string like fido2 means the method satisfies MFA on its own: no password required. A comma-separated pair like password,microsoftAuthenticatorPush means both are required: the password is the first factor, the Authenticator push is the second. This is why the Phishing-resistant strength doesn't include any password,* combinations, phishing-resistant methods are passwordless by definition. If a method requires a password as the first factor, the password can be phished, which disqualifies the combination from phishing-resistant status regardless of the second factor's strength.

You'll notice temporaryAccessPassOneTime in the MFA strength but not in the Passwordless or Phishing-resistant strengths. TAP is classified as a strong credential (it satisfies MFA) but it's not passwordless (it's a code the user types) and it's not phishing-resistant (the code can be entered on a fake page). TAP's purpose is bootstrapping, getting a user to the point where they can register a passwordless method. It shouldn't be a permanent authentication option, which is why it doesn't appear in the higher-tier strengths.

Migrating from "Require MFA" to authentication strength

Existing Conditional Access policies that use the "Require multifactor authentication" grant control should be migrated to use "Require authentication strength" instead. The migration is not disruptive if you select the right built-in strength: the MFA strength built-in accepts all the same combinations that "Require MFA" accepts. The user experience doesn't change, but you now have the option to tighten specific policies to Passwordless or Phishing-resistant strengths without modifying the base policy.

# Identify CA policies using legacy "Require MFA" (migration candidates)
$policies = Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" `
  -OutputType PSObject

Write-Host "=== CA Policies Using Legacy MFA Grant ==="
foreach ($p in $policies.value) {
    if ($p.grantControls.builtInControls -contains "mfa") {
        Write-Host "  $($p.displayName), state: $($p.state)"
        Write-Host "    Target apps: $($p.conditions.applications.includeApplications -join ', ')"
    }
}
Write-Host "`nMigration: replace 'Require MFA' with 'Require authentication strength: MFA strength'"
Write-Host "  No user impact, same methods accepted. Enables future strength upgrades."

Creating custom authentication strengths

Custom strengths let you define exactly which method combinations are acceptable. This is how you handle scenarios the built-in strengths don't cover.

Create a custom strength via Graph API:

$customStrength = @{
    displayName = "Privileged Access - Hardware Only"
    description = "FIDO2 and WHfB only. No Authenticator passkey, no CBA, no password-based MFA."
    allowedCombinations = @(
        "fido2"
        "windowsHelloForBusiness"
    )
}

$created = Invoke-MgGraphRequest -Method POST `
  -Uri "https://graph.microsoft.com/v1.0/policies/authenticationStrengthPolicies" `
  -Body ($customStrength | ConvertTo-Json -Depth 3) `
  -OutputType PSObject

Write-Host "Created custom strength: $($created.displayName) (ID: $($created.id))"

Verify the custom strength:

$verify = Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/policies/authenticationStrengthPolicies/$($created.id)" `
  -OutputType PSObject

Write-Host "Strength: $($verify.displayName)"
Write-Host "  Allowed combinations: $($verify.allowedCombinations -join ', ')"

Why exclude Authenticator passkey from the privileged access strength? Authenticator passkeys run on phones, personal devices that may not be managed, may not have screen lock enforced, and may be shared with family members. For privileged access to admin portals and PIM activation, the credential should be on dedicated hardware (FIDO2 key) or a managed, compliant device (WHfB). This is a design decision, not a universal rule, if your organization manages all phones through Intune with device compliance policies, including Authenticator passkey in the privileged strength may be acceptable. Document the rationale either way.

Authentication strength in Conditional Access

Authentication strength policies become effective when referenced in Conditional Access grant controls. Module 5 covers CA policy design in full, but the connection between strength and CA is the critical design point from this module.

The design pattern for three access tiers maps authentication strengths to CA policies:

# Query your authentication strength policies for CA reference
$strengths = Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/policies/authenticationStrengthPolicies" `
  -OutputType PSObject

Write-Host "Available authentication strengths for CA policies:"
foreach ($s in $strengths.value) {
    Write-Host "  $($s.displayName). ID: $($s.id)"
    Write-Host "    Methods: $($s.allowedCombinations -join ', ')"
}

Authentication strength and device compliance, defense in depth

Authentication strength alone doesn't fully protect privileged access. An administrator who authenticates with a FIDO2 key from a compromised personal laptop has proven their identity with a phishing-resistant credential, but the device they're operating from may have malware that captures the session after authentication. Module 5 covers this in full, but the design principle belongs here: pair authentication strength with device compliance for privileged access.

The layered model works like this. The authentication strength policy controls the credential quality (FIDO2 or WHfB only). The device compliance requirement controls the device quality (managed, patched, encrypted). The Conditional Access policy combines both: require authentication strength = Privileged AND require device compliance = compliant. An administrator who authenticates with FIDO2 from a compliant managed device passes both checks. An administrator who authenticates with FIDO2 from a personal laptop passes the strength check but fails the compliance check, and is blocked.

This layering is why the Privileged tier custom strength excludes Authenticator passkey. Authenticator passkeys run on phones. Even if the phone has Intune MAM policies, the authentication session transfers to whatever device the user's browser is running on, which may not be managed. FIDO2 keys and WHfB both authenticate on the device where the session runs, making device compliance a meaningful check. Authenticator passkeys authenticate on the phone but authorize a session on a potentially different device, creating a gap that device compliance can't close.

Custom strength governance

Custom authentication strengths are governance artifacts that need ongoing management. Unlike built-in strengths (which Microsoft maintains), custom strengths don't update automatically when Microsoft adds new authentication methods to the platform. If Microsoft introduces a new phishing-resistant method, your custom "Hardware Only" strength won't include it until you manually add the new combination.

This creates a quarterly governance requirement: review custom authentication strengths against Microsoft's current method catalog. Check whether new methods should be added to your custom strengths, whether existing methods have been deprecated, and whether the strength names and descriptions still accurately reflect the allowed combinations.

Custom strengths that are referenced by active CA policies cannot be deleted. Entra ID prevents deletion of a strength that a policy depends on. To retire a custom strength, you must first update all referencing CA policies to use a different strength (or the built-in equivalent), then delete the custom strength. Document which CA policies reference each custom strength so you know the impact of any change.

# Custom strength governance check, enumerate dependencies
$strengths = Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/policies/authenticationStrengthPolicies" `
  -OutputType PSObject

$customStrengths = $strengths.value | Where-Object { $_.policyType -eq "custom" }
$caPolicies = Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" `
  -OutputType PSObject

Write-Host "=== Custom Strength Governance Review ==="
foreach ($cs in $customStrengths) {
    Write-Host "$($cs.displayName) (created: $($cs.createdDateTime))"
    Write-Host "  Combinations: $($cs.allowedCombinations -join ', ')"
    $refs = $caPolicies.value | Where-Object {
        $_.grantControls.authenticationStrength.id -eq $cs.id
    }
    if ($refs.Count -gt 0) {
        Write-Host "  Referenced by: $(($refs | ForEach-Object { $_.displayName }) -join ', ')"
    } else {
        Write-Host "  ⚠ Not referenced by any CA policy, evaluate whether still needed"
    }
}

At Northgate Engineering: NE's authentication strength design uses three tiers. Standard: built-in MFA strength (any MFA method, covers the 810-user population during migration). Sensitive: built-in Passwordless MFA strength (Finance and Engineering applications, targets groups that have completed passwordless registration). Privileged: custom "Hardware Only" strength (FIDO2 + WHfB only, targets the 22 administrator accounts for Entra admin portal, Azure portal, and PIM activation). The tier mapping feeds directly into Module 5's CA policies. ADR-IAM4-007 documents the three-tier design, the rationale for excluding Authenticator passkey from the privileged tier, and the migration plan: all users start at Standard, move to Sensitive after Authenticator passkey registration, administrators move to Privileged after FIDO2 registration.

Strength tier evolution

The three-tier model is a starting point, not a permanent fixture. As your passwordless deployment progresses, the tier boundaries shift. When 90% of users have passwordless methods registered, the Standard tier (any MFA) is no longer the baseline, you can tighten it to Passwordless MFA for most users, leaving MFA strength only for the SMS exceptions group. When FIDO2 or WHfB coverage reaches 100% for specific populations, you can create application-specific strength policies that require hardware-bound methods for sensitive applications without waiting for the entire organization to reach that coverage level.

The evolution follows the registration curve. Don't tighten a strength tier until the registration data confirms that the target population can satisfy the new requirement. The quarterly posture review from section 4.9 is the decision input: when the Tier 3 percentage crosses a threshold (e.g., 85% passwordless for a specific department), evaluate whether that department's CA policies should move from Standard to Sensitive. The evolution is per-population, not tenant-wide.

Authentication strength for external identities

Authentication strength policies apply to guest and external users too, but the governance dynamics are different. You don't control which authentication methods your guests have registered in their home tenant. A guest user from a partner organization might authenticate with password + SMS in their home tenant and receive a token that your CA policy evaluates.

When your CA policy requires phishing-resistant authentication strength for a resource that guests access, the guest must satisfy that requirement using their home tenant's credentials. If the guest's home tenant only supports push MFA, the guest is blocked, even though they successfully authenticated at home. This creates a cross-organizational governance dependency that Module 5's CA policies for external identities must address.

The practical approach for guest access is to use a separate CA policy with a lower strength tier. Your internal users accessing the Finance portal might require Passwordless MFA, while guests accessing the same portal require MFA strength (any MFA). The risk difference is documented in the ADR: "Guest access to Finance portal accepts any MFA because we cannot control guest home tenant method policies. Compensating control: guest access is time-bounded through entitlement management (Module 11), and guest application access is reviewed quarterly (Module 12)."

# Check authentication methods used by guest users in sign-in logs
$guestSignIns = Get-MgAuditLogSignIn -Filter "userType eq 'Guest' and createdDateTime ge $((Get-Date).AddDays(-30).ToString('yyyy-MM-ddTHH:mm:ssZ'))" -All `
  -Property UserDisplayName,UserType,AuthenticationMethodsUsed,Status |
  Where-Object { $_.Status.ErrorCode -eq 0 }

$guestMethods = @{}
foreach ($s in $guestSignIns) {
    foreach ($m in $s.AuthenticationMethodsUsed) {
        if (-not $guestMethods[$m]) { $guestMethods[$m] = 0 }
        $guestMethods[$m]++
    }
}

Write-Host "Guest authentication methods (last 30 days):"
$guestMethods.GetEnumerator() | Sort-Object Value -Descending |
  ForEach-Object { Write-Host "  $($_.Key): $($_.Value) authentications" }

This query reveals whether your guests are authenticating with phishing-resistant methods or weaker alternatives. If 90% of guest authentications use password + push, your guest population has a different risk profile than your internal users, and your CA policies should reflect that difference.

Decision-point simulation

Scenario 1. Your custom authentication strength for privileged access includes only FIDO2 and WHfB. An administrator working remotely from a personal laptop (not managed by Intune) can authenticate with their FIDO2 key but WHfB is unavailable (not enrolled on the personal device). They can access the admin portal with FIDO2. Is this acceptable?

FIDO2 on an unmanaged device provides phishing-resistant authentication: the key verifies the domain regardless of the device. The credential security is in the key, not the device. However, the device itself may be compromised. Pair the authentication strength requirement with a device compliance condition in the CA policy: require phishing-resistant authentication AND device compliance. The administrator on a personal laptop passes the authentication strength check but fails the device compliance check. This forces administrators to use managed devices for privileged access, defense in depth, not just authentication strength.

Scenario 2. A CA policy uses the built-in "MFA strength" for all cloud apps. A new compliance requirement mandates phishing-resistant MFA for payroll access. You can't change the all-apps policy without breaking access for users who only have SMS. How do you add the requirement?

Create a second CA policy that targets the payroll application specifically, requires the "Phishing-resistant MFA" authentication strength, and targets the payroll user group. CA policies are additive: both the all-apps MFA policy and the payroll phishing-resistant policy evaluate for payroll users. The more restrictive policy wins. Users who access payroll must satisfy both: MFA (from the all-apps policy) and phishing-resistant MFA (from the payroll policy). Users who access other apps only need to satisfy the MFA policy. This is the standard pattern for adding strength requirements incrementally without disrupting existing access.

Scenario 3. Your organization has 50 users who cannot register any passwordless method (no smartphone, no dedicated workstation, frontline workers with shared tablets). The compliance team requires MFA for all users. What authentication strength do you assign, and how do you document the exception?

These users can register hardware OATH tokens (TOTP-based, no smartphone required: a small hardware device that generates 6-digit codes). Assign the built-in MFA strength (which includes password,hardwareOath). Document the exception in the risk register: "50 frontline workers authenticate with password + hardware OATH token. This satisfies MFA but is not phishing-resistant. Risk accepted: frontline workers access only low-sensitivity applications (scheduling, timekeeping). If frontline access expands to sensitive data, re-evaluate method requirements."

Reusable script, authentication strength audit

# IAM4.7. Authentication Strength Audit
# Lists all strengths and their usage in CA policies

Connect-MgGraph -Scopes "Policy.Read.All"

# List all authentication strengths
$strengths = Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/policies/authenticationStrengthPolicies" `
  -OutputType PSObject

Write-Host "`n=== Authentication Strength Policies ==="
foreach ($s in $strengths.value) {
    Write-Host "$($s.displayName) ($($s.policyType))"
    Write-Host "  Methods: $($s.allowedCombinations -join ', ')"
}

# Check which CA policies reference authentication strength
$caPolicies = Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" `
  -OutputType PSObject

Write-Host "`n=== CA Policies Using Authentication Strength ==="
foreach ($p in $caPolicies.value) {
    $grant = $p.grantControls
    if ($grant.authenticationStrength) {
        Write-Host "  $($p.displayName) → strength: $($grant.authenticationStrength.id)"
    }
}

# Identify CA policies using legacy "require MFA" (migration targets)
Write-Host "`n=== CA Policies Using Legacy 'Require MFA' (migrate to strength) ==="
foreach ($p in $caPolicies.value) {
    if ($p.grantControls.builtInControls -contains "mfa") {
        Write-Host "  ⚠ $($p.displayName), uses 'Require MFA' instead of authentication strength"
    }
}