March–June 2026 Entra ID Changes: Passkey Profiles and Conditional Access Enforcement

Microsoft made passkey profiles and synced passkeys generally available in March 2026, then adjusted a separate Conditional Access enforcement rollout to begin June 15, 2026. Neither change depends on an administrator choosing the rollout date, and that is precisely the risk. If you have not already reviewed these settings, Microsoft may have applied defaults that do not align with your security posture.

Change 1: Passkey profiles and synced passkeys became generally available in March. During automatic migration, synced passkeys are enabled in the Default profile when the tenant’s prior FIDO2 configuration did not enforce attestation.

Change 2: Conditional Access policies targeting “All resources” with exclusions began enforcing on OIDC-only sign-ins starting June 15. Users whose tenants have received the rollout may now see prompts on flows that previously bypassed those policies.

Both changes are security improvements. Both can cause disruption for unprepared organizations. This post explains how to audit your tenant and regain control after rollout.

Part 1: Passkey Profile Auto-Enablement

What Changed

Microsoft replaced the flat, tenant-wide FIDO2 authentication method configuration with a profile-based architecture. A single set of FIDO2 settings used to apply to the entire tenant. After migration, administrators can configure up to three passkey profiles, each scoped to different security groups.

The profile model is a welcome improvement. The concern is what happens during automatic migration for tenants that do not opt in.

Auto-Migration Behavior

When a tenant migrates (automatically, for anyone who did not opt in first), Microsoft creates a Default passkey profile and populates it from the attestation setting in place at the time:

Most organizations have attestation off. Many disabled it because attestation verification was unreliable, not because they intended for cloud-synced credentials to flow through iCloud Keychain or Google Password Manager. Those tenants come out of migration with synced passkeys enabled by default.

The Timeline

Tenants that opted in during March controlled the configuration. Everyone else was scheduled to receive Microsoft’s defaults once force-enable began in April, with the commercial pass set to complete in late May. Those are Microsoft’s published dates rather than an observed outcome, so confirm the state of your own tenant instead of assuming the calendar held.

Synced Passkeys vs Device-Bound: Why It Matters

For privileged accounts, device-bound is the appropriate choice. For the general workforce, synced passkeys trade a degree of security for significantly better usability. Microsoft reports a 99% registration success rate and 14x faster sign-in compared to password + MFA.

The question is not whether synced passkeys are beneficial. It is whether you want them enabled without an explicit decision to do so.

How to Audit Your Current Configuration

Start with what your tenant is actually running now.

In the Entra portal: Navigate to Protection > Authentication methods > Policies > Passkey (FIDO2).

Via Graph API (returns the complete configuration, including properties not visible in the portal):

GET https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/fido2

Via PowerShell:

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

Get-MgBetaPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
    -AuthenticationMethodConfigurationId 'Fido2'

Key properties to review:

• isAttestationEnforced: If false, the Default profile that migration builds includes synced passkeys
• keyRestrictions.aaGuids: Your AAGUID allowlist. These values carry into the Default profile. If you enabled Microsoft Authenticator in the portal, Entra automatically added two AAGUIDs: 90a3ccdf-635c-4729-a248-9b709135078f (iOS) and de1e552d-db1d-4423-a619-566b625cdc84 (Android)
• includeTargets: The groups that currently have FIDO2 enabled

How to Take Control Now

Step 1: Find out which model your tenant is on. In the Entra portal, go to Passkey (FIDO2), the page shown in the screenshot above. If migration has run, there is a Default profile populated from the previous configuration, and that profile is what the tenant enforces. Passkey profiles are now GA; Microsoft’s current guidance says a tenant cannot opt out after enabling profiles. You can still change profile targets and restrictions, but test those edits before applying them broadly.

Step 2: Configure your profiles. You can create up to 3 profiles. The following is a recommended configuration:

Step 3: Assign profiles to groups. Under the Enable and Target tab, add your security groups and assign the appropriate profile(s) to each.

Gotchas to Watch For

1. Removing an AAGUID from an allow list is retroactive. It blocks existing sign-ins, not just new registrations. If you prune your AAGUID list while reworking the profiles, users with those key types lose access immediately.

2. Registration campaigns change silently. When synced passkeys are enabled and Microsoft-managed registration campaigns are active, the campaign target shifts from Microsoft Authenticator to passkeys. The audience also expands to all MFA-capable users with unlimited daily reminders. Check where your campaign settings stand:

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

$policy = Get-MgPolicyAuthenticationMethodPolicy
$campaign = $policy.RegistrationEnforcement.AuthenticationMethodsRegistrationCampaign

$campaign | Select-Object State, SnoozeDurationInDays
$campaign.IncludeTargets | Select-Object Id, TargetedAuthenticationMethod

Read TargetedAuthenticationMethod on an enabled campaign. If it reads passkeys and nobody on your team put it there, migration made that change for you.

3. Profile enablement cannot be reversed. Passkey profiles are GA, and Microsoft’s current guidance says you cannot opt out after enabling them. Test profile targeting, attestation, and AAGUID restrictions before broad rollout so a policy change does not lock out users.

4. Policy size limit: 20 KB. Tenants with extensive AAGUID lists across multiple profiles may reach this ceiling.

Part 2: Conditional Access Enforcement Fix

The Gap That Existed

If you have a Conditional Access policy targeting “All resources” with one or more resource exclusions, certain sign-in flows were not being evaluated by that policy.

Specifically, when an application requested only basic OIDC scopes (openid, profile, email) or minimal directory scopes (User.Read), the sign-in was not mapped to any resource for CA evaluation purposes. The “All resources” policy with exclusions simply did not fire.

That meant users authenticating through applications that only requested basic scopes had been bypassing MFA requirements, device compliance checks, and location restrictions, silently, for an unknown period of time.

What Changed Starting June 15

Beginning June 15, 2026, Microsoft maps these OIDC-only sign-ins to Azure AD Graph as the target resource as the rollout reaches each tenant. Policies that target “All resources” (with exclusions) then evaluate and enforce on these flows.

The affected scopes:

Microsoft adjusted the schedule after its original announcement. The current official Microsoft Entra update says enforcement begins June 15, 2026 and rolls out in phases, with no opt-out. Check your Message Center and sign-in logs rather than assuming the change reached every tenant on the first day.

How to Find Your Affected Policies

A policy is affected if all three conditions are true:

1. Targets “All resources” (formerly “All cloud apps”)
2. Has at least one resource exclusion
3. Has grant controls (MFA, device compliance, etc.)

PowerShell to find affected policies:

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

$policies = Get-MgIdentityConditionalAccessPolicy -All

$affected = $policies | Where-Object {
    $_.Conditions.Applications.IncludeApplications -contains "All" -and
    $_.Conditions.Applications.ExcludeApplications.Count -gt 0 -and
    ($_.GrantControls.BuiltInControls.Count -gt 0 -or $_.GrantControls.AuthenticationStrength)
}

$affected | ForEach-Object {
    [PSCustomObject]@{
        Name           = $_.DisplayName
        State          = $_.State
        ExcludedApps   = ($_.Conditions.Applications.ExcludeApplications -join ", ")
        GrantControls  = ($_.GrantControls.BuiltInControls -join ", ")
    }
} | Format-Table -AutoSize

What Users Experience

As the June 15 rollout reaches a tenant, users authenticating through applications that only request basic scopes may encounter:

• MFA prompts where they previously had seamless access
• Device compliance blocks if the policy requires compliant or hybrid-joined devices
• Location-based blocks if the policy restricts by named location

The most common impact is on custom line-of-business applications, legacy applications with minimal scope requests, and any application using openid profile email without requesting resource-specific permissions.

How to Test Your Exposure

1. Conditional Access What-If tool: Test specific user and application combinations in the Entra portal under Protection > Conditional Access > What If. This shows which policies fire for a given combination.

2. Review sign-in logs: Monitor for CA-related failures dated on or after June 15. The following PowerShell snippet retrieves recent failures where Conditional Access blocked a sign-in:

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

$cutoff = (Get-Date).AddDays(-7).ToString("yyyy-MM-ddTHH:mm:ssZ")
$signIns = Get-MgAuditLogSignIn -Filter "createdDateTime ge $cutoff and status/errorCode ne 0" -Top 50

$signIns | Where-Object { $_.ConditionalAccessStatus -eq "failure" } | ForEach-Object {
    [PSCustomObject]@{
        User      = $_.UserPrincipalName
        App       = $_.AppDisplayName
        ErrorCode = $_.Status.ErrorCode
        Reason    = $_.Status.FailureReason
    }
} | Format-Table -AutoSize

This requires the Microsoft.Graph.Reports module and a Microsoft Entra ID P1/P2 license for sign-in log access.

3. Create a report-only policy: Build a CA policy in report-only mode targeting “All resources” without exclusions, and compare the evaluation results against your existing policies.

What To Do About It

If your applications already handle CA challenges (MFA prompts, device compliance), no action is required. This is a security improvement.

If you have applications that cannot handle CA challenges, update them using Microsoft’s Conditional Access developer guidance before enforcing replacement policies.

If you intentionally excluded a resource to avoid CA on certain flows, that exclusion no longer prevents enforcement for OIDC-only scopes. Review whether those exclusions are still necessary and test the impact using report-only mode before enforcing replacement policies. Microsoft’s recommendation is to build a baseline MFA policy targeting all users and all resources without resource exclusions.

Key Takeaways

1. Passkey profiles and synced passkeys became GA in March. If attestation was off, the tenant can come out of migration with synced passkeys in its Default profile. Open that profile and decide whether you actually want that.
2. Conditional Access enforcement began June 15. As the phased rollout reaches each tenant, OIDC-only sign-ins are evaluated by “All resources” policies with exclusions, so users can receive MFA prompts they never had before.
3. These rollouts are not reversible tenant options. Microsoft says the Conditional Access change has no opt-out, and tenants cannot opt out after enabling passkey profiles. You still control profile configuration and affected policy design.
4. Audit first, then act. Run the scripts in this post to determine exactly what is affected in your tenant before making changes.
5. Device-bound passkeys for privileged accounts, synced for workforce. Use the new profile model to enforce this separation rather than applying a single configuration to all users.

Resources

• Enable passkeys and configure passkey profiles (Microsoft Learn)
• Enable passkeys in Authenticator for Microsoft Entra ID (Microsoft Learn)
• Conditional Access enforcement change (Help Net Security)
• Conditional Access: Targeting resources (Microsoft Learn)
• Upcoming Conditional Access enforcement change (Microsoft Tech Community)
• MC1221452 - Auto-enabling passkey profiles (Message Center)
• Microsoft Entra ID auto-enables passkey profiles (LazyAdmin)
• Conditional Access developer guidance (Microsoft Learn)

Jerrad Dahlager, CISSP, CCSP

Cloud Security Architect · Adjunct Instructor

Marine Corps veteran and firm believer that the best security survives contact with reality.

Have thoughts on this post? I'd love to hear from you.

LinkedIn Email Me

You might also like

Identity Security

Just-In-Time Access for AI Agents: Building a ZSP Gateway in Azure

Build an Azure gateway that grants service principals and managed identities …

15 min read

Cloud Security

From Authorization to Action: Operationalizing CISA's Microsoft Cloud Logs Playbook in Sentinel

Map CISA's Microsoft cloud logging guidance to Entra, Purview, Microsoft 365, …

12 min read

Threat Detection

Block Device Code Phishing in Entra Without Breaking Legit Workflows

Detect device-code phishing with Sentinel and Defender XDR, from …

15 min read