Microsoft Entra ID with active Conditional Access policies often creates a convincing picture of Zero Trust maturity. Green dashboards, MFA enforced, device compliance checked at sign-in. The architecture looks solid until you run a real audit. Three recurring categories of gaps keep appearing in real deployments, and each one is enough to give an attacker a usable path in.
Legacy IP exclusions: the technical debt that becomes a backdoor
During the initial rollout of Conditional Access, IP exclusions are almost inevitable. Conference rooms, legacy printers, SCADA systems, old VPN concentrators — something always needs a bypass to avoid blocking operations. The exclusion gets created, documented in a ticket, approved under time pressure, and then forgotten.
The trouble starts when those IP ranges change hands, when the network perimeter shifts, or when an attacker gains access to a segment that Entra still considers trusted. A range listed as a trusted location in Entra ID bypasses MFA, skips device compliance checks, and reduces session scrutiny. If that range is reachable through a compromised VPN or a shared infrastructure with a third-party vendor, the original operational workaround has become a direct access vector.
Audits regularly turn up entire subnets imported from legacy on-premises Active Directory configurations, never reviewed after cloud migration. Some correspond to office locations that no longer exist.
Service accounts: the identities Conditional Access forgot
In most environments, service accounts are explicitly excluded from Conditional Access policies. The reasoning is straightforward: an automated process cannot respond to an interactive MFA challenge. But that exclusion, left uncontrolled, creates a significant attack surface.
A service account excluded from all CA policies can authenticate from any device, any location, at any hour, without triggering any policy-level behavioral alert. If that account is compromised through credential stuffing, pass-the-hash, or a secrets leak in a code repository, the attacker gets persistent, low-noise access to whatever the account can reach.
The right approach is to handle these identities through Conditional Access Workload Identities (available with Entra ID P2), enforce strict IP restrictions on them, and monitor behavioral deviations via Microsoft Defender for Cloud Apps. Simply excluding them and hoping no one targets them is not a control — it's a gap with a label on it.
Missing session re-evaluation: the token that outlives its welcome
Zero Trust is built on one foundational assumption: trust is never permanent, it gets re-evaluated continuously. In practice, many Entra ID deployments use default token lifetimes — or worse, deliberately extended ones to reduce user friction.
Without Continuous Access Evaluation (CAE) enabled, a token issued before an account was disabled, before a device was flagged non-compliant, or before a user risk signal was detected keeps working until it expires naturally. That window can span several hours. In a compromise scenario, that's more than enough time for an attacker who already holds the tokens to move laterally or exfiltrate data.
CAE addresses this by allowing compatible applications to reject tokens in real time when a revocation event is signaled by Entra. But CAE is not universal and is not automatically configured. You have to verify explicitly which applications in your tenant support it and which ones still operate on traditional session models.
How to audit your Conditional Access policies in practice
A serious CA audit goes well beyond checking that policies are enabled. The following checklist covers the gaps that matter most. For hands-on practice against realistic Microsoft hybrid environments, the CyberAct lab and training catalog includes dedicated scenarios covering Entra ID and hybrid identity configurations.
Inventory and review of exclusions
- List every named location defined in Entra ID and validate its current relevance: who owns it, when it was created, what it was created for.
- Identify every CA policy containing an IP or group exclusion and document the operational justification for each one.
- Remove or restrict any IP range that has not been validated in the past 90 days.
Non-human identity handling
- Inventory all accounts excluded from every CA policy: service accounts, break-glass accounts, synchronization accounts.
- For each exclusion, verify whether a Workload Identity policy or a compensating IP restriction is in place.
- Ensure break-glass accounts are subject to active monitoring and alerting — exclusion alone is not a security control.
Session re-evaluation verification
- Review token lifetime settings in authentication policies across the tenant.
- Identify which applications and services in the tenant support CAE and verify it is actually enabled for them.
- Test revocation behavior for critical applications: when an account is disabled, is the active token invalidated in real time?
Policy coverage and missing scenarios
- Check that no enterprise application published through Entra escapes all CA policies — filtering Sign-in logs on "No CA policy applied" is usually revealing.
- Confirm that legacy authentication protocols are explicitly blocked by a dedicated policy, not just assumed to be unused.
- Verify what policies apply to sign-ins from unregistered or non-compliant devices, including personal devices used for work.
A coherent Zero Trust environment is not one where policies exist — it's one where exceptions are known, justified, and reviewed on a regular schedule. If you want to assess where your organization currently stands, a cyber maturity diagnostic surfaces the real risk zones before an external audit or an incident does it for you.
Frequently asked questions
What is an IP exclusion in Entra ID and why is it dangerous?
An IP exclusion in Entra ID marks a network range as a trusted location, which bypasses certain controls like MFA for connections coming from that range. The risk is that these exclusions are typically created under operational pressure and never revisited. If the range changes ownership or becomes reachable from a compromised network, anyone connecting through it gets frictionless access regardless of their identity risk level.
Is it really possible to apply Conditional Access policies to service accounts?
Yes, through Conditional Access Workload Identities, available with Entra ID P2. This feature allows you to create policies targeting non-human identities specifically, including IP-based restrictions and anomaly alerts. It is not a perfect solution, but it is significantly more secure than a blanket exclusion with no compensating control.
Does Continuous Access Evaluation protect all Microsoft 365 applications?
No. CAE is supported by a growing list of Microsoft applications including Exchange Online, SharePoint, and Teams, but it does not cover all third-party applications or every OAuth integration. You need to verify explicitly within your tenant which applications benefit from CAE and which ones continue operating with long-lived tokens.
How often should Conditional Access policies be audited?
A full audit should happen at least twice a year and systematically after any major infrastructure change: cloud migration, merger, vendor change, or new application deployment. Between full reviews, continuous monitoring of Sign-in logs — particularly connections with no CA policy applied — provides an ongoing signal for anomalies and gaps.