Know what your Conditional Access policies actually let through
Conditional Access is the front door to a Microsoft 365 tenant, and almost nobody can say with confidence what their own policy set permits. This inventories every policy — enabled, disabled and report-only — checks five named coverage baselines, and draws the paths that actually reach your resources across principals, device classes, policies and resources. Every edge of that map says how much authority stands behind it.
Coming soon Built, but you cannot buy it yet
This one is built and running, and it is close. You still cannot buy it, and nothing on this page is an invitation to try. Its price is published so the number is settled before it ships rather than negotiated after.
Why it matters
Conditional Access policy sets accrete. A policy is added for a project, a group is excluded for a fortnight, a break-glass account is carved out and stays carved out. Almost nothing is ever removed, because removing a policy is how you lock somebody out on a Friday afternoon. What survives is a set of overlapping rules nobody has read end to end, guarding the one door every account comes through.
The question that eventually gets asked — in an incident, in an audit, when a contractor's engagement ends — is not "which policies exist" but "what could this account, on this device, have reached". Entra will answer that one evaluation at a time, if you already know which evaluation to ask for. The point of a map is that you do not have to know the question first.
What it does
- Every policy, including the ones not in force — a full inventory across enabled, disabled and report-only, with the three kept visibly apart. A disabled policy that reads like coverage is one of the more common reasons a tenant believes it is protected.
- Five named coverage baselines — each one a question about the whole policy set rather than about a single policy. They are answered from the policies actually in force: a report-only or disabled policy is listed against the baseline, but never allowed to satisfy it.
- An access map, not a policy list — the paths that genuinely reach your resources, drawn across principals, device classes, policies and resources, each one marked allowed or blocked. A list of policies has never been an answer to "what can reach this".
- Provenance on every edge — each edge says whether it was computed by us, confirmed against Microsoft's own What-If evaluation, or unconfirmable because we could not sample honestly. Where our evaluator and Entra's disagree, you are told — rather than the map quietly correcting itself and hiding that it had been wrong. The disagreement is usually the finding worth having.
- Your policy set treated as code — connect a Git repository, GitHub or Azure DevOps, and the repository is compared against the live tenant field by field, on a cron you set, with the history kept. "These have diverged" is not a finding; the field that moved is.
- Comparison that runs both ways — take a tenant you trust, capture its live policy set back into the repository as a pull request somebody reviews, then hold every other tenant against it. Capture writes to your repository on a new branch; it never pushes to the branch we read.
- Write-back is the top rung, and it is gated — enable, disable or move a policy to report-only, or deploy the repository's policy into a tenant. One approved change at a time, never by the person who requested it, and not without a connector consent you grant separately. Nothing is ever deleted: a policy the tenant has and the repository does not is reported, not removed.
What it will not do
Half-scheduled, and the half matters. The repository-versus-tenant comparison runs on a cron you set and keeps its history. The underlying scan does not — it runs when you ask for it. So a scheduled comparison is only ever as current as the last scan somebody ran, and "continuous" stays a word used about ShareCare and MailTrust and deliberately not about this.
Its findings stay inside the product. They do not reach PosturePortal rollups, and CompliancePortal reads your Conditional Access policies itself rather than taking our verdict for them. That is duplicated work by design, and it will not be described as an integration.
Confirmation catches disagreement in one direction only: we check the paths we drew. A policy Microsoft applies where we drew nothing is an access path the map does not show, and we do not detect it. That is the honest shape of the gap — the map can be wrong about what it contains, and it will say so; it can also be incomplete, and there it is silent.
Capability and what you get from it
| Capability | What you get from it |
|---|---|
| Inventory across enabled, disabled and report-only | A policy that is not in force can never be mistaken for one that is |
| Five named coverage baselines | Gaps stated against the whole policy set, not policy by policy |
| Access map across principals, device classes, policies and resources | An answer to "what can reach this" you can read, rather than reconstruct |
| Provenance on every edge — computed, confirmed or unconfirmable | You know which parts of the map Microsoft stands behind and which are ours alone |
| Disagreements surfaced rather than reconciled | Where our evaluator and Entra's differ, you see both instead of the tidier one |
| Repository-versus-tenant comparison, field by field | Drift named down to the field that moved, in either direction |
| Baseline capture as a pull request | A tenant you trust becomes the standard every other tenant is held against |
| Approval-gated write-back | Changes to the front door happen on the record, and never by the person who asked for them |
Ask it about your own policy set
Not something you can order today. It is something we can point at your tenant and walk you through — your policies, your map, and a straight account of which edges Microsoft confirmed and which ones we could not.