Conditional Access monitoring
14 Conditional Access policies. 5-15% of your activity runs under none of them.
Your policies, named locations and trusted ranges describe how the tenant should be entered. 1Security lays that configuration over what actually happens - every sign-in and every file, mail and Teams action attributed to the place, device and account that performed it - and gives you one number to move: the share that completed with no Conditional Access policy applied. In a typical tenant on day one it is 5-15%, and new activity registers within minutes, not days.
- 5coverage verdicts per observed location - not covered, partly, named, trusted, undetermined
- 10 minfor a new sign-in or action to register with its location, device and policy verdict attached
- 0extra API calls for the verdict - the per-sign-in Conditional Access result already rides the records 1Security ingests
The problem
The rules are written down. Whether they fire is a different question.
A policy that names a location and never fires there reads, in a configuration review, exactly like one that protects you every day.
Conditional Access is the front door of a Microsoft 365 tenant, and it is one of the hardest controls to be sure about from configuration alone. A review tells you what you declared. It cannot tell you which places your people actually work from, which of those places no rule mentions, and how much of the traffic - sign-ins, and the file and mail activity behind them - completed with no policy in force at all.
The failure modes are quiet. An office whose internet egress outgrew its declared range still looks correct on paper while half its traffic reaches the tenant outside every rule that mentions it. A trusted range nobody has signed in from in a year is a standing exception with no owner. A named location referenced by zero enabled policies is dead configuration that still looks alive.
The gap between declared and observed is the whole product here. 1Security measures it from your real sign-ins and activity, refreshes it every hour, and reports it as numbers: the share with no policy applied, the count of locations carrying each finding, and the specific ranges to fix - so the review is evidence, not attestation.
Capabilities
Declared configuration, measured against real sign-ins and activity.
Every observed location gets a verdict; every verdict gets findings that say why to act. It lives as the Coverage tab of the Locations screen and as a CA coverage column on the main list.
- per location
Five coverage verdicts
Not covered, partly covered, named, trusted, undetermined - computed from the source addresses actually seen at each place, not from a policy's stated scope. "Partly covered" is the one worth money: a range covering 4 of a site's 9 egress addresses looks correct on paper.
No-enforcement, counted
Sign-ins that completed with no Conditional Access policy in force at all, and the activity performed under them, counted per location and tenant-wide from the per-sign-in verdict - never inferred from configuration. This is the headline tile.
Six findings that name the risk
No enforcement, undeclared but active, office not trusted, trusted but risky network, range outgrown, ungoverned anonymised egress. A location can carry several at once; tenant tiles count locations per finding, and any location list filters by finding.
Activity, not only sign-ins
Every file opened, mail sent and Teams action is attributed to the sign-in, device and location that performed it - so "no policy applied" is measured against what people actually did, and a gap shows up on the first download from a new place, not on the next quarterly review.
Honest about policy state
Report-only and disabled policies are labelled, never counted as protection. A policy that was deleted still appears where it used to act, tagged - "the rule that used to cover this office was deleted" is a finding, not a missing row.
- minutes + hourly
Two clocks, both deliberate
Sign-ins and activity register within about ten minutes with their verdict attached; coverage verdicts recompute hourly; and every policy create, update and delete reaches you in real time as high-severity audit activity - so a policy change on Friday evening does not wait for Monday.
One location, whole story
Open a place. Read its enforcement, with receipts.
Every location's drawer carries a Conditional Access tab that tells the story for that one place.
The verdict and the named location behind it. How many of the observed addresses matched the declared range - 4 of 9, say. How many sign-ins and how much activity were attributed here in the window, and how many carried no policy. Every finding, explained in one line.
Below that, the policies actually observed acting on sign-ins from this location - each with its grant controls and its counts of applied, allowed, blocked and report-only. Listed as observed, not as configured: which is why a disabled policy cannot masquerade as protection, and a deleted one cannot simply vanish from the story.
In practice
A coverage audit, before lunch.
What the declared-versus-observed comparison looks like on day one.
- 01
Read the headline tiles
Open Locations, Coverage tab. The tiles put it plainly: the share of sign-ins and activity that completed with no policy applied - typically 5-15% on a first look - next to a count of locations carrying each finding. This is the number the whole exercise exists to move.
- 02
Work the gap list
Switch to the gaps view: real, sustained activity from places no named location covers, thresholded on events and distinct users so one-off traffic does not bury the genuine blind spots. A first pass usually lists 3-10 places, often a branch office and a home region.
- 03
Open one office
Your main office shows partly covered: 4 of 9 observed egress addresses match the declared range. The office marker also sits outside every trusted location, so your own building is treated as unknown by every "except trusted" rule.
- 04
Fix it, watch the number move
Extend the range, trust the office, retire the never-seen trusted range from three tenants ago - in your Conditional Access configuration, where the fix belongs. New activity from the fixed office registers within minutes, and the next hourly recompute shows the verdict move and the no-policy share drop.
The difference
What you get from holding configuration and observation side by side.
Everything here comes from comparing the two halves - the rules you wrote and the sign-ins and activity that actually happened.
- Partly covered locations - declared ranges an office's real egress has quietly outgrown
- The share of sign-ins and activity that completed with no policy applied, tenant-wide and per location
- Trusted ranges that resolve to VPN, Tor or hosting infrastructure - a standing exception handed to whoever rents the address next
- Trusted ranges nothing has ever signed in from - exceptions with no owner
- Named locations referenced by zero enabled policies - dead configuration that still looks alive
- Deleted policies still shown and tagged where they used to act
- Report-only and disabled policies labelled instead of counted as protection
- Ranges that could not be parsed shown as such, instead of silently shrinking a named location's coverage
Deployment
A re-consent, not a project.
The per-sign-in verdict is already inside the sign-in records 1Security ingests, and every action is already attributed to its sign-in, device and location. Reading named locations and policy configuration adds one permission, Policy.Read.All, granted as a re-consent of the read-only application you already approved. No new app registration, no write access, ever. On the licensing side, the Entra ID P1 that Conditional Access itself runs on is all 1Security needs - nothing above it.
- 0writes - 1Security never edits Conditional Access; every fix happens in your own configuration
- 1permission - Policy.Read.All, riding a re-consent of the app you already granted
- P1the Entra ID tier Conditional Access itself runs on is enough - nothing above it is needed for any of this
Use cases
Three moments this screen earns its keep.
The quarterly access review: instead of walking policies one by one and asserting they look right, export the gap list and the no-enforcement share, fix what the findings name, and watch the number drop by the next recompute. Evidence, not attestation.
The new office: people start working from a location weeks before anyone updates named locations. Undeclared-but-active catches it within minutes of the first real activity, while it is a finding, not an incident - and "office not trusted" catches the marker you placed but never added to the exception list.
The incident question: when a sign-in from an unfamiliar place turns up in an investigation, its location drawer answers "was this governed?" with the policies observed acting there, the activity performed, and the count that carried none. Pair it with impossible-travel context from the same screen and the story assembles itself.
Impossible Travel Detection
The locations this screen verdicts - how throwaway IPs become stable, named places with travel legs and verdicts.
Explore locations →Shadow Device Detection
The device side of the same sign-in story - including the machines that never enrolled anywhere.
Meet the devices →Microsoft 365 Audit Tool
Up to three years of the sign-ins and activity behind every verdict on this page, on standard licenses.
See the history →
FAQ
Common questions.
Does this need a new app registration?
No. Named locations and policy configuration need the Policy.Read.All permission, granted as a re-consent of the read-only application you already approved. The per-sign-in verdict needs nothing extra at all - it already travels inside the sign-in records 1Security ingests.
What licenses are required?
Conditional Access itself runs on Microsoft Entra ID P1, and that is all 1Security needs on your side - nothing above it. If your tenant has no P1, the consent prompt is simply not shown; everything else on the Locations screen keeps working.
Is this only about sign-ins?
No. Every file, mail and Teams action 1Security ingests is attributed to the sign-in, device and location that performed it, so the no-policy share and the location findings are measured against what people actually did - not only against the moment they signed in. New activity registers within about ten minutes.
Can 1Security change my Conditional Access policies?
No, by design. 1Security reads configuration and observes enforcement; every remediation it points at - adding a range, trusting an office, retiring dead configuration - is performed by you, in your own Conditional Access settings. Policy changes then reach 1Security in real time through the audit log.
What does "partly covered" mean, exactly?
Some of a location's observed source addresses fall inside a declared range and some do not - typically an office whose internet egress outgrew its range. It is the most deceptive state, because the named location looks correct on paper while part of the site's traffic reaches the tenant outside every rule that mentions it.
How fresh are the verdicts?
Sign-ins and activity register within about ten minutes with their verdict attached. Coverage is recomputed hourly, because new locations and sign-ins never stop arriving. Configuration is refreshed every few hours, and policy create, update and delete events additionally arrive in real time as high-severity audit activity. Locations discovered since the last pass show as undetermined rather than being reported as gaps they may not be.
Find out how much of your activity no policy touches. Today.
Connect read-only, grant one re-consent, and see the share of your sign-ins and activity that completed with no Conditional Access applied - then watch it drop, within the hour, as you close the gaps.
Or keep reading the rules and hoping they fire.