Conditional Access Is Not a Policy: How Enterprises Accidentally Break Identity Security

You’ve seen the screenshots. 37 color-coded conditional access policies by risk tier. MFA enforced. Device compliance required. Geographic restrictions in place. The audit finding is closed. The board deck shows green.

Six months later, an incident response call reveals that a contractor accessed the ERP system from an unmanaged device in a coffee shop, bypassing MFA because they were “temporarily” excluded during a product demo in 2022. Nobody remembers approving it. Nobody remembers removing it. The policy still says “MFA required.” The exclusion list says otherwise.

This isn’t an implementation failure. It’s not even a configuration error. It’s what happens when enterprises treat conditional access as a security policy instead of what it actually is: an execution engine for decisions that nobody explicitly owns.

Conditional Access didn’t fail. Governance did. And without clear decision rights and operating cadence, identity controls decay quietly under operational pressure.

Conditional Access Policies Decay Under Operational Pressure

When you deploy conditional access (CA), you’re not deploying a security control. You’re deploying infrastructure that enforces decisions made elsewhere. The control is the decision. The policy is just the mechanism.

Most enterprises invert this relationship. They treat the presence of a CA policy as evidence of security, when all it actually proves is that someone configured a rule. What that rule does, who it applies to, and whether it still reflects any coherent security intent is a separate question entirely.

The decay starts immediately and compounds predictably.

An executive needs access from a personal device during a board meeting. A temporary MFA exclusion becomes permanent because no one owns the removal. A vendor integration requires location-based exceptions that expand from five IP ranges to twenty-three over two years of organic growth. Service accounts break, so someone adds a broad exclusion “just for automation.” That automation path is not protected by Conditional Access at all. It is governed, if at all, as a workload identity. Read: Workload Identities Are the Real Perimeter. The automation scales. The exclusion doesn’t shrink.

Each of these decisions might have been defensible in context. The problem is that context expires. The exclusion doesn’t.

CA policies age like network ACLs used to: they grow, they accumulate exceptions, and eventually nobody can explain why half of them exist. Network drift at least showed up in packet captures and flow logs. An MFA bypass doesn’t show up in a diagram. It just quietly expands blast radius.

The Exception Gravity Problem

Network exceptions were bad. Identity exceptions are worse.

When you carved out a firewall exception for a legacy app, the damage was bounded. The exception applied to specific ports, specific sources, sometimes specific times of day. It was localized. Auditors hated it, but at least you could draw a box around it.

Identity exceptions don’t work that way. They compound.

An MFA exclusion for a user doesn’t just affect one app. It affects every app that user touches, across every device they authenticate from, in every location they access. The failure domain is the entire identity, not the session. And because conditional access evaluates in sequences and combinations, exceptions interact in ways that aren’t obvious from reading individual policies.

You exclude executives from MFA for “usability.” You exclude third-party consultants from device compliance because they’re temporary. You exclude service accounts from location restrictions because automation doesn’t have geography. Each decision is rational in isolation. Together, they create a class of principals who operate outside your identity controls entirely.

In post-incident reviews, the question “Which users bypass MFA today, and why?” often cannot be answered quickly, if at all. Not because the data doesn’t exist. It does. It’s sitting in exclusion groups, exception lists, and conditional scopes. But nobody stitched it together. Nobody owns the question. And because the exclusions were added incrementally over years, often by different teams, there’s no single artifact that reflects the current state.

This drift is discoverable, but only if you treat CA as an owned system. Entra ID’s CA Insights and reporting workbook shows which policies are applied, which controls granted access, and where users are falling through gaps. Access reviews can force periodic re-approval of excluded users, surfacing exceptions that would otherwise persist indefinitely. The tooling exists. What’s usually missing is someone responsible for looking at it on a cadence, asking whether the current state still reflects intent.

This is security drift at the identity layer. The control looked correct when it was deployed. It decayed gradually under operational pressure. By the time anyone notices, it’s unclear what the original intent even was, let alone whether the current state reflects it.

Device Trust Is Not a Verdict

Enterprises treat device compliance as a binary: compliant or non-compliant. CA reinforces this by offering it as a simple gate. Device is compliant? Grant access. Device is not? Block.

That’s a mistake in how we’re modeling the problem.

Device trust is not a verdict. It’s a signal. Compliance tells you that a device met a set of criteria at a specific point in time. It doesn’t tell you the device is safe. It doesn’t even tell you the device is still in the same state it was when the compliance check passed.

CA policies treat device posture as a one-time verification. The device was compliant when the user logged in, so access is granted for the session. What happens during the session? What happens if the device’s posture degrades? What happens if compliance is only evaluated at check-in intervals and the device has been compromised between checks?

Here’s how this breaks in practice: Intune compliance status is a signal, not a real-time feed. Devices check in periodically, and compliance policies often include grace periods to avoid locking out users during transient failures. A device that disabled endpoint protection yesterday might still show “compliant” today because it hasn’t checked in, or because the grace period hasn’t expired, or because the specific control was marked “not applicable” for that device class. CA sees “compliant.” It grants access. The actual device state is unknown.

The architecture assumes device state is stable. Device state is not stable.

Worse, the exceptions meant for one app quietly weaken enforcement everywhere. You create a device compliance exemption for a legacy HR system that doesn’t support modern authentication. The request came from HR leadership during open enrollment, approved by an IAM admin under time pressure, scoped narrowly in the ticket but broadly in the policy. Six months later, users have learned they can access that app from unmanaged devices. They start accessing other apps the same way, because the browser session is already authenticated and the device check only happens at initial sign-in. The tooling didn’t fail. The boundary did.

Device trust must be contextual, time-bound, and revocable. CA can enforce those properties, but only if the policies are designed to degrade by default. Most aren’t. They grant access until someone explicitly removes it, which means they’re optimized for persistence, not security.

Identity Becomes Tier 0 Without Being Treated Like It

In many enterprises, CA changes go through lighter review than firewall changes did a decade ago. A CA policy change can have tenant-wide impact. A single misconfigured exclusion can collapse segmentation across every application that relies on Entra ID for authentication. A blanket MFA bypass doesn’t just affect the user. It affects every resource that user can reach, which in a modern enterprise is potentially everything.

Identity is the new perimeter, but governance hasn’t caught up. Network changes went through CAB. Firewall rules required architecture review. CA changes often get pushed by identity admins who may or may not understand the downstream security implications.

The reason is partly structural. Identity tooling frequently lives in the IAM organization, not the security organization. It’s treated as user lifecycle management, not access control architecture. The people who administer CA are often focused on reducing friction and unblocking users, not threat modeling lateral movement.

This isn’t a criticism of IAM teams. It’s an organizational design problem. When identity was just authentication, that model made sense. Now that identity is authorization, segmentation, and access control, the model is wrong.

Tier 0 controls require Tier 0 change discipline. That means named approvers. Architectural review for broad-scope changes. Testing in isolation before production rollout. Automatic expiry for exceptions unless explicitly renewed.

The result is that identity policy drifts faster than infrastructure policy, because infrastructure had review gates and identity often doesn’t.

Where Conditional Access Breaks Remote Access Strategy

CA was supposed to enable Zero Trust. In practice, it often just props up VPN-era assumptions with identity tooling.

You retired the VPN. Users authenticate directly to SaaS apps and cloud workloads. CA enforces MFA and device compliance at the front door. On paper, this is correct.

In practice, the policies still encode location-based trust. “Trusted locations” become a proxy for the old internal network. Users on corporate IP ranges get lighter restrictions. Users outside those ranges face more friction. The access decision is still based on where you are, not who you are or what you’re doing.

This defeats the purpose. If location is still the primary trust signal, you haven’t eliminated the perimeter. You’ve just moved it into the identity provider.

The deeper problem is that CA can’t fix a missing remote access architecture. If you’re using identity controls to make up for weak application segmentation, you’re asking the identity layer to solve a problem it wasn’t designed to solve.

Authentication is not authorization. CA can enforce authentication policy. It can gate access based on identity signals. It cannot replace application-level access control, network segmentation, or privilege boundaries.

But enterprises try anyway. They use CA to block risky apps, restrict unmanaged devices, enforce geographic boundaries, all things that should be enforced at the application or network layer. When those controls don’t exist, identity becomes the fallback. And because identity is easier to change than architecture, the policies accumulate workarounds.

This is why CA configurations become unmaintainable. They’re encoding decisions that should have been made during access architecture design, but weren’t. The policies are compensating for missing controls elsewhere in the stack.

What a Functional Operating Model Looks Like

Mature organizations don’t treat CA as an IAM tool. They treat it as shared infrastructure with joint ownership between IAM, security architecture, and application teams.

Exceptions require expiry. Not optional expiry. Mandatory expiry. If you need to extend an exception, you explicitly renew it. Renewal creates friction, which is the point. Friction forces someone to answer whether the exception is still necessary. Most of the time, it isn’t.

CA is treated as architecture, not configuration. Changes go through the same review process as changes to network segmentation or privileged access tiers. If a policy affects Tier 0 resources, it requires Tier 0 approval. If a policy creates exceptions for executives or third parties, it requires executive sponsor sign-off.

Here’s what that looks like in practice: A project manager requests an MFA exception for a vendor team during a six-week integration. The request goes to the security architecture team, not just IAM ops. They approve it with a 45-day expiry and a named sponsor from the business unit. At day 40, the sponsor gets a renewal notice. If they don’t respond, the exception dies. If they renew, they have to re-justify. The vendor finished three weeks ago, so they don’t renew. The exception expires. No one had to remember to clean it up.

This doesn’t mean CA becomes slow. It means changes are deliberate. Most day-to-day adjustments, adding a user to a group, updating a device compliance threshold, don’t require review because they’re within predefined parameters. The review applies to changes that alter trust boundaries, expand blast radius, or create new exception classes.

The key shift is treating decision rights and cadence as part of the control, not separate from it.

Mature organizations also instrument CA telemetry. They track which policies fire most often, which exceptions get used most frequently, and where users experience the most friction. Not to remove the friction. To understand whether the friction is aligned with risk.

If executives bypass MFA constantly, that’s a signal. Either the policy is wrong, or the exception is wrong, but one of them has to change. If service accounts are excluded from location restrictions, someone needs to validate that those accounts aren’t being used for interactive access.

The telemetry doesn’t replace governance. It informs it. You still need humans making decisions. But those decisions should be based on what’s actually happening, not what the policy document says should be happening.

Conclusion

CA failures don’t announce themselves. There’s no alert when an MFA exception quietly expands from one user to twelve. No dashboard lights up when a device compliance policy stops being enforced because too many exceptions accumulated.

When a firewall rule breaks, traffic stops flowing. Someone notices. When an identity control erodes, access still works. In fact, access works better, because the friction is gone.

Governance is what keeps identity from becoming accidental. Without it, CA becomes what it was always at risk of becoming: security theater that runs in production until an incident proves it was never really there.