Conditional Access is one of the most consequential configuration areas in a Microsoft 365 tenant. Done well, it enforces consistent authentication requirements across users, applications, and devices. Done poorly, it gives the appearance of coverage while leaving material gaps that surface only when something goes wrong, or when an auditor starts asking pointed questions.
This article covers what a defensible Conditional Access policy set actually looks like, the gaps that most commonly erode real-world coverage, and how to observe and evidence what your policies are doing rather than what you assume they are doing.
What defensible means
A policy set that holds up under scrutiny is not necessarily the most restrictive one. It is the one where every design decision can be explained, where coverage is consistent and intentional, and where exceptions are controlled rather than accumulated.
From an audit perspective, the questions are practical. Which users are in scope? Which applications? Under what conditions does enforcement weaken, and was that a deliberate choice? If an exclusion exists, who owns it, and when was it last reviewed?
Conditional Access answers those questions through configuration. If the configuration is ambiguous or inconsistent, no amount of documentation will fill the gap.
The baseline structure
A functional Conditional Access policy set typically addresses four areas: authentication strength, device state, application scope, and risk-based controls.
Authentication strength is where most organisations start. Requiring multi-factor authentication for all users, across all cloud applications, is the foundation. The practical question is whether that requirement applies everywhere it should, or whether broad exclusions have been granted that hollow it out.
Device state controls let you require that a device is Entra-joined, Hybrid-joined, or meets your Intune device compliance policy before access is granted. This matters most for access to sensitive applications or administrator portals.
Application scope matters because policies that exclude broad application categories, or that were built around legacy named applications and never updated, may no longer reflect what is actually in use in the tenant.
Risk-based controls use Entra ID Protection signals, sign-in risk, and user risk to trigger step-up authentication or block access when anomalous behaviour is detected. These controls depend on licensing and on the risk signals actually being active.
Building policies that cover all four areas gives you a layered posture. The weakness in most tenants is not that any single area is entirely missing. It is that each area has quiet exceptions that, taken together, represent a meaningful uncovered population.
Where coverage erodes quietly
Broad exclusions
Exclusions are the most common source of policy drift. A helpdesk team needs emergency access, so a group is excluded from MFA enforcement. A third-party integration is causing sign-in failures, so an application is removed from scope. A legacy system cannot support modern authentication, so a named location is exempted.
Each individual decision is understandable. The problem is that exclusions tend to accumulate without a review cadence. After eighteen months, the excluded group has forty members, the application exclusion covers a service that was replaced, and the named location exception applies to a network range that is no longer in use. The policy set still reads as comprehensive. The effective coverage is not.
The test is not whether exclusions exist. It is whether you can account for every exclusion currently in place and confirm it is still appropriate.
Legacy authentication paths
Legacy authentication protocols such as SMTP AUTH, IMAP, POP, and basic authentication via Exchange ActiveSync do not support modern Conditional Access controls. Any client or service account that authenticates over these protocols can bypass Conditional Access entirely, regardless of what your policies say.
Microsoft has progressively retired basic authentication across Exchange Online, and for most tenants this is largely resolved. Residual legacy authentication paths can still exist through older mobile clients, shared mailbox configurations, or third-party applications that were not updated. The risk is that these paths are not always visible in standard policy reporting.
A policy that explicitly blocks legacy authentication protocols, rather than simply not addressing them, is the more defensible design. It makes the control active rather than relying on a dependency that may have changed.
Guest and external user accounts
Guest accounts are frequently underserved by Conditional Access. Policies written with the tenant's own users in mind often do not apply cleanly to guests, particularly where the policy scope uses group membership rather than all users including guests.
The practical risk is that a guest with access to SharePoint Online, Teams channels, or shared applications may be operating under a materially weaker authentication requirement than an internal user doing the same work. In a B2B collaboration context that may be acceptable with compensating controls. In most cases it is an oversight.
Checking whether your Conditional Access policies explicitly include or explicitly exclude guest and external users, and whether that reflects a deliberate decision, is a basic hygiene step that is frequently skipped.
Service accounts and non-human identities
Service principals, managed identities, and application accounts present a different problem. Most Conditional Access policies target interactive user sign-ins. Workload identity policies, which apply Conditional Access controls to service principals, require separate configuration and additional licensing.
The result is that many tenants have comprehensive Conditional Access coverage for human users and almost none for service accounts, even where those accounts hold broad application permissions or tenant-level roles. This is an increasingly visible gap given the growth in application-to-application access patterns.
Observing real coverage versus assumed coverage
The gap between what a policy set is designed to do and what it is actually doing is not always visible from the policy list. A policy can be enabled, configured, and documented, and still not apply to the population you think it covers.
The primary tools for understanding real coverage are the Conditional Access insights and reporting workbook in the Entra portal, sign-in logs filtered by Conditional Access outcomes, and the What If tool for testing policy application against specific user and application combinations.
Useful questions to answer from these sources:
- What percentage of sign-in events in the past 30 days were subject to at least one Conditional Access policy?
- Which sign-ins succeeded without any Conditional Access policy applying?
- Are there users or applications that consistently appear in sign-ins with no policy match?
- Which policies have the largest exclusion populations?
Answering these questions with data from sign-in logs gives you observable evidence of actual coverage, not assumed coverage. That evidence is what holds up when someone asks you to demonstrate that your controls are working.
ScanPosture observes Conditional Access configuration across authentication requirements, exclusion patterns, guest and service account coverage, and the presence of legacy authentication policy. It surfaces gaps between what the policy set intends and what it is likely to enforce, providing structured evidence of control posture that can support internal review or external scrutiny.
ScanPosture shows alignment and readiness against selected technical controls related to this area. It does not itself certify compliance or replace formal assessment, certification, or legal advice.
Alignment with Cyber Essentials and the NCSC CAF
For UK organisations, two frameworks are frequently referenced in governance conversations around access control.
Cyber Essentials sets expectations for multi-factor authentication on user accounts, stronger controls on administrative accounts, restriction of privileged access, and disabling of unused accounts. A well-configured Conditional Access policy set contributes directly to meeting those expectations in technical practice.
The scheme specifies what outcomes are required. It does not prescribe the mechanism. Conditional Access is the primary Microsoft mechanism for enforcing authentication requirements at sign-in, which makes it a central part of any credible Cyber Essentials technical implementation on Microsoft 365.
The NCSC Cyber Assessment Framework (CAF) is used by organisations in sectors that fall under the Network and Information Systems regulations, and increasingly as a general governance reference. The Identity and Access Control objective is directly relevant. It covers access control policies, authentication mechanisms, and privileged account management, and Conditional Access configuration is observable evidence for several of its indicators.
Neither framework certifies a Conditional Access configuration. What they provide is a set of expected outcomes against which you can measure your observable posture. Where your configuration produces those outcomes consistently, with documented decisions behind exclusions and exceptions, you are in a materially stronger position than where policies exist on paper but coverage in practice is inconsistent.
Making the policy set auditable
Auditability is partly about what the configuration does and partly about whether that can be demonstrated. A few practical points:
Name policies clearly. A policy named "CA007" tells an auditor nothing. A policy named "Require MFA - All Users - All Cloud Apps - Exclude BreakGlass" is self-documenting.
Document the reasoning behind exclusions. Even a simple Entra ID group description or a linked ticket reference in change management creates a trail. Exclusions without reasoning look accidental.
Establish a review cadence. Policy sets drift because they are configured once and not revisited. A quarterly review of exclusion group membership and a check against current application registrations takes less than an hour and prevents the accumulation described earlier.
Test with What If regularly. Especially after tenant changes, new application registrations, or changes to group membership. Configuration that was correct in January may not apply as intended in July.
Use report-only mode carefully. Report-only mode is valuable for impact assessment before enabling a new policy. A policy left in report-only mode indefinitely is not providing any protection.
Summary
Conditional Access policy design is not primarily a technical challenge. The Microsoft tools are capable, and the configuration options are extensive. The challenge is consistency: maintaining intentional coverage across users, applications, and access paths over time, in a tenant that is constantly changing.
The policies that hold up under audit are the ones where every design decision is observable, every exclusion is accounted for, and the gap between what the policy set claims to do and what it actually enforces is as small as possible. That is a governance and operational discipline as much as a technical one, and it relies on periodic evidence gathering rather than a one-time configuration exercise.
