Why the Sequence of Device Identity Matters

Before a device can be evaluated for compliance, it must complete Entra ID device registration or Entra ID join. That registration process itself requires authenticated access to Microsoft's Device Registration Service (DRS) — a cloud endpoint that sits under the All cloud apps umbrella in Conditional Access.

Here is the exact sequence that must succeed for a new Windows 11 device to reach a compliant state:

1. Device contacts DRS to register its identity.
2. Intune enrollment begins, pulling down compliance policies.
3. Compliance evaluation runs — the device is assessed against those policies.
4. The device is marked Compliant in Entra ID.
5. The user can now enroll a FIDO2 passkey via aka.ms/mysecurityinfo, which calls the Combined Security Information Registration endpoint.

When a Compliant-Device CA policy covers All cloud apps with no exclusions, it intercepts step 1. The device has no Entra ID identity yet. It cannot satisfy a device-based grant control. DRS access is blocked. The device never registers. Compliance is never evaluated. The user never gets to step 5.

This distinction matters operationally. Support tickets will describe the symptom as "passkey enrollment is broken." The actual break point is upstream, at DRS or at the Combined Registration endpoint, depending on whether the device is net-new or re-provisioned.

---

The Specific Endpoints That Get Blocked

Microsoft's Conditional Access engine treats the following as distinct application targets, but all of them fall under All cloud apps unless explicitly excluded:

• Device Registration Service — required for Entra join and registration
• Microsoft Intune Enrollment — App ID d4ebce55-015a-49b5-a083-c84d1797ae8c
• Microsoft Intune — App ID 0000000a-0000-0000-c000-000000000000
• My Security Info / Combined Registration — the endpoint users hit at mysecurityinfo to register passkeys

Each of these must be reachable during the onboarding window. A CA policy that enforces Require device to be marked as compliant against All cloud apps will block all four before the device has any identity to evaluate.

The Microsoft Intune Enrollment app ID is the one most frequently overlooked. Administrators exclude the Device Registration Service because Microsoft's documentation calls it out explicitly, but they miss the Intune Enrollment app, which causes a secondary failure even after DRS access is restored.

---

Identifying the Misconfiguration with PowerShell

The Microsoft Graph PowerShell SDK is the correct tool for this audit. The legacy AzureAD module is deprecated and should not be used for new automation.

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

$policies = Get-MgIdentityConditionalAccessPolicy -All

$compliantPolicies = $policies | Where-Object {
    $_.GrantControls.BuiltInControls -contains "compliantDevice"
}

foreach ($policy in $compliantPolicies) {
    $appConditions = $policy.Conditions.Applications
    $includesAll = $appConditions.IncludeApplications -contains "All"
    $exclusionCount = $appConditions.ExcludeApplications.Count

    [PSCustomObject]@{
        PolicyName     = $policy.DisplayName
        State          = $policy.State
        TargetsAllApps = $includesAll
        ExclusionCount = $exclusionCount
    }
}

Any policy where TargetsAllApps is True and ExclusionCount is 0 is a candidate for this failure. Cross-reference those policies against your tenant's passkey enrollment rollout timeline to confirm correlation.

---

Operational Impact at Scale

In a single-device provisioning scenario, this failure is annoying. In an enterprise running Windows Autopilot or Microsoft Deployment Toolkit at scale — onboarding hundreds of devices per week — it becomes a provisioning blocker that cascades into help desk volume, delayed access for new hires, and re-imaging cycles that consume IT time without resolving the root cause.

Re-provisioned devices hit this problem differently than net-new devices. A re-provisioned device may retain a stale Entra ID object that shows as non-compliant rather than unregistered. In that case, the CA policy blocks access not because the device has no identity, but because its identity is present and explicitly marked non-compliant. The remediation path differs: the stale device object must be deleted from Entra ID before re-enrollment, otherwise the device inherits the old compliance state during the registration window.

From a user experience standpoint, the failure at mysecurityinfo presents as a generic access denied error with no actionable guidance. Users cannot self-remediate. Every blocked enrollment becomes a support ticket, and without KQL-based monitoring in place, the help desk has no visibility into whether the failure is CA-related, network-related, or credential-related.

---

Monitoring Enrollment Failures with KQL

The following query runs against the Entra ID Sign-in Logs table in Log Analytics and surfaces CA-blocked enrollment attempts targeting the Combined Registration endpoint:

SigninLogs
| where AppDisplayName in (
    "Device Registration Service",
    "Microsoft Intune Enrollment",
    "My Security Info"
)
| where ConditionalAccessStatus == "failure"
| extend CAPolicy = tostring(ConditionalAccessPolicies[0].displayName)
| extend FailureReason = tostring(Status.failureReason)
| summarize FailureCount = count() by UserPrincipalName, AppDisplayName, CAPolicy, FailureReason
| order by FailureCount desc

Run this query scoped to the last 7 days during any Autopilot or provisioning wave. A spike in failures against Microsoft Intune Enrollment or My Security Info attributed to a compliant-device CA policy confirms the misconfiguration. Export the results and cross-reference against your Intune device inventory to identify which devices are stuck in a non-compliant or unregistered state.

For ongoing alerting, wrap this query in an Azure Monitor Alert Rule with a threshold of more than five failures per hour against these app IDs. That threshold catches provisioning waves before they generate significant help desk volume.

---

Governance Considerations

The governance risk here is more subtle than it appears. Administrators who have deployed a Compliant-Device CA policy covering All cloud apps believe their environment enforces device compliance universally. The enrollment bypass means that belief is incorrect — non-compliant or unregistered devices are authenticating to DRS and potentially to the Combined Registration endpoint during the onboarding window.

This creates a compliance attestation gap. If your organization is subject to frameworks like NIST SP 800-63B, ISO 27001, or SOC 2 Type II, auditors will ask whether all authentication events are gated by device compliance controls. The honest answer, in a misconfigured tenant, is no — and the audit evidence in your sign-in logs will show it.

The secondary governance risk is policy drift. Exclusions added to fix this problem are frequently added as broad user-group exclusions rather than application-scoped exclusions. A broad user-group exclusion that bypasses the compliant-device requirement for all apps is far more dangerous than a targeted application exclusion for DRS and Intune Enrollment. Document every exclusion with a named justification, a review date, and the owner responsible for that exception.

---

Recommendations for Remediation

Exclude the correct application IDs, not user groups. The fix is to add application-scoped exclusions to the Compliant-Device CA policy, not to create a parallel policy with weaker controls or to exclude entire user groups from the compliant-device requirement.

The applications to exclude are:

• Device Registration Service (no static App ID — target by display name or use the deviceRegistration condition in the CA policy)
• Microsoft Intune Enrollment — App ID d4ebce55-015a-49b5-a083-c84d1797ae8c
• Microsoft Intune — App ID 0000000a-0000-0000-c000-000000000000

For the Combined Security Information Registration endpoint, Microsoft provides a dedicated CA policy condition: User actions → Register security information. Scope a separate CA policy to this user action and apply a phishing-resistant MFA grant control rather than a compliant-device grant control. This allows passkey enrollment to proceed while still requiring strong authentication.

$params = @{
    DisplayName = "Require Phishing-Resistant MFA for Security Info Registration"
    State = "enabledForReportingButNotEnforced"  # Start in report-only
    Conditions = @{
        Users = @{
            IncludeUsers = @("All")
        }
        Applications = @{
            IncludeUserActions = @("urn:user:registersecurityinfo")
        }
    }
    GrantControls = @{
        Operator = "OR"
        AuthenticationStrength = @{
            Id = "<phishing-resistant-auth-strength-policy-id>"
        }
    }
}

New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Start this policy in report-only mode and validate against sign-in logs before enabling enforcement. Report-only mode is available for all CA policies in Entra ID and is the correct way to validate impact before enforcement.

Audit exclusions quarterly. Any application exclusion added to a Compliant-Device CA policy should appear in a named exclusion register with a review cadence. Use the PowerShell audit script above as part of a scheduled quarterly review to confirm that exclusion counts have not grown beyond the intended set.

---