10 CA Mistakes That Are Probably in Your Tenant Right Now

CA has no user agent filtering. The Device Platform condition is what admins reach for, and it uses user agent strings the device itself provides. Microsoft documents this directly: user agent strings can be modified. Browser dev tools, thirty seconds, policy bypassed.

The second gap is the unmatched case. CA supports six named platforms: Android, iOS, Windows, macOS, Linux, Windows Phone. A session that doesn't report a recognisable platform string lands in the unmatched bucket. A policy targeting specific named platforms doesn't evaluate those sessions at all.

The fix: in the device platform condition, set Include to Any device and Exclude to your supported platforms. What's left, Windows Phone, Linux if you don't use it, and anything that doesn't report a recognised string, hits the block. More reliable than enumerating platforms in the Include tab because you're not betting on that list being exhaustive.

Include — Any device

Exclude — your known platforms

When you add multiple grant controls in a CA policy, the portal asks you whether to require all of the selected controls or one of them. Most admins read past it. The problem cuts both ways, and which operator is "wrong" depends entirely on what you're trying to enforce.

OR logic means the weakest control wins. If a policy has "Require compliant device OR MFA," a user on an unmanaged personal device can satisfy it with just MFA. The compliant device requirement is bypassed. For Hybrid Azure AD Joined or compliant device policies, this is the common error. Admins intend that users must have a managed device, but the OR gives unmanaged devices a path in. AND logic is usually correct for device-based access control.

OR is legitimately correct when you want to give users a choice of how they prove access, where each option is acceptable on its own. AND is correct when you want all conditions met. Check every policy with multiple grant controls. Know which operator you've selected and why.

Admins who want to restrict where devices can be registered or joined to Entra ID reach for the location condition in CA. It's a reasonable instinct. You want device registration to only happen from trusted networks. The problem is the Device Registration Service cannot be protected by a location-based grant control at all.

This was documented and MSRC-confirmed in research published by Fabian Bader (Cloudbrothers) following joint work with Dirk-jan Mollema at TROOPERS25 (VULN-153600). The Device Registration Service (01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) only supports "Require multifactor authentication" as a grant control. Location cannot be enforced. The portal won't error. The policy will appear configured, but the location condition is not evaluated for device registration.

If you need to restrict device join beyond MFA, the controls live outside CA entirely: Intune enrollment restrictions by platform and ownership type, Autopilot profile assignment, and the Entra device settings page for who can join or register. None of these are location-aware. Location-based device registration restriction is a documented architectural gap, not a configuration problem you can fix by adjusting CA policy.

Under Devices in the Entra admin center there's a toggle: "Require Multifactor Authentication to register or join devices with Microsoft Entra." A lot of tenants have it set to Yes. A lot of those same tenants also have a CA policy requiring MFA for device registration. Both are on, both are enforcing, and nobody is sure which one is actually doing the work.

Microsoft's own portal tells you what to do here. The warning on that setting reads: "Set this device setting to No if you require Multifactor Authentication using Conditional Access." This is a legacy toggle, the same category as per-user MFA. It predates CA. It doesn't support Conditional Access conditions, named locations, auth strength, or any of the controls that make CA useful. Running both creates undefined behavior and makes troubleshooting device registration failures significantly harder.

Entra admin center — Devices — Device settings

The same logic applies to the broader device join restriction setting that limits which users can join or register. That's a directory-level control, not an access enforcement mechanism. CA's Require compliant device grant is what blocks app access for unenrolled devices. Don't use the directory restriction as a substitute for that.

This is the chicken and egg problem. You enforce phishing-resistant auth strength across the tenant. Users who don't have a FIDO2 key or Windows Hello for Business registered can't satisfy it. They can't register one without getting in first. Monday morning, helpdesk queue, accounts effectively locked.

The fix is a custom authentication strength that includes Temporary Access Pass as a one-time-use factor alongside your phishing-resistant methods. TAP is single-use by design, time-limited, and admin-issued. It gives the user exactly one path in to register their credential, then it's gone. The same custom strength covers account recovery when someone gets a new phone, loses their key, or needs to re-enroll without being completely locked out.

The custom strength isn't a weakening of the policy. TAP one-time-use is still a controlled, admin-gated credential. What it prevents is the scenario where phishing-resistant enforcement is technically correct but operationally breaks every new hire and every account recovery event because there's no designed path through.

Custom auth strength — WHfB, Passkeys (FIDO2), CBA, and TAP one-time-use as the bootstrap path

Break-glass accounts need to be excluded from CA policies. The mistake is in how the exclusion is built. Two patterns show up repeatedly and both create problems the admin didn't intend.

Dynamic group exclusion is a security flaw. Dynamic groups evaluate a membership rule. An attacker who can enumerate the directory can read that rule, identify the attribute value that qualifies for membership, and potentially manipulate their own account to satisfy it. The exclusion becomes a bypass vector. Whatever attribute drives the dynamic rule — department, job title, extension attribute — if it's writable by a broad enough population or discoverable through normal enumeration, it's a target. Break-glass exclusions built on dynamic groups are exclusions an attacker can engineer their way into.

Role-based exclusion expands beyond break-glass. Excluding the Global Administrator role from a sensitive CA policy sounds like it scopes to break-glass. It doesn't. Every user who activates Global Admin through PIM is now excluded from that policy for the duration of their activation. The exclusion scope grows with every PIM activation across the tenant, not just for the two accounts you intended. Users who were never meant to bypass that policy are bypassing it the moment they elevate.

The geo-block policy looks clean: block all countries except the ones you operate in. Then someone adds an exclusion for a group of users who travel internationally, or a service account that needs to authenticate from a third-party system in a blocked region. The exclusion grows. Nobody audits it.

The result is a set of users who are completely outside the geo-block with no compensating control. They're excluded from the location restriction, but there's no policy requiring them to satisfy MFA, device compliance, or any other grant control when they authenticate from a blocked country. They're just exempt. Fully.

Also worth auditing: how broad is the "allowed countries" list? Tenants that operate in five countries often have fifteen in the allowed list. Named location hygiene is part of the same problem.

CA foundations layer model — exclusions punch holes, gaps compound

These two controls behave very differently when a device fails to meet conditions. The key difference is what the user gets told about it.

Require compliant device as a grant control produces an error message when compliance fails. The user sees their device isn't compliant and gets a remediation path: enrol the device, fix the compliance issue. Internal users who should fix their device posture will do so if they're told what's wrong.

Device filter used as a condition gives the user nothing. If the filter matches (or doesn't match, depending on configuration), access is blocked with no explanation. No remediation path is shown. For privileged access workstations or external-facing resources where you don't want to reveal policy logic, that's intentional. For general corporate access where users need to know what to do, it's the wrong tool.

Device filter — exclude compliant devices, silent block

Grant control — require compliant device, user-facing error

Use device filter for high-security resource access where you explicitly don't want to hint at the policy. Use the compliant device grant control where you want users to self-remediate. Using device filter everywhere, including for routine corporate access, means your helpdesk gets calls from users who have no idea what's wrong.

SIF loops are a common support call that traces back to one misconfiguration: "Every time" applied to the wrong app. Microsoft documents the warning directly: using sign-in frequency to require reauthentication every time, without multifactor authentication, may result in sign-in looping for your users.

The scope matters. For the Azure portal and Entra admin center, Microsoft explicitly recommends time-based SIF or authentication context on PIM activation, not "Every time." An admin mid-session loses context on the re-authentication prompt and has to start the task again. For M365 apps, time-based SIF is the recommendation. "Every time" is valid for specific scenarios: PIM elevation, Intune enrollment, Azure Virtual Desktop, risky sign-ins. Outside those specific cases it creates friction that serves no security purpose.

SIF controls when the next prompt fires. It has no effect on an existing token's validity. Tightening it as a response to token theft doesn't close the window, it just prompts the legitimate user more often.

A user sends an email with a sensitivity label that applies encryption. The recipient gets an .rpmsg attachment instead of readable content. They can't open it. The error they see is unhelpful. They call the helpdesk. Nobody traces it back to CA.

The specific conditions that cause this: a CA policy scoped to all cloud apps includes Microsoft Rights Management Services, the recipient is a guest or external user, and there is no cross-tenant MFA trust configured for their home tenant. When the recipient tries to open the encrypted content, the RMS decryption call hits the CA policy, MFA is required, but the external user's existing MFA claim from their home tenant isn't trusted. They can't satisfy the challenge. The content stays wrapped.

Option 1 — CA policy excluding RMS + Intune Enrollment

Option 2 — Inbound trust settings, Trust MFA from Entra tenants