🗂 List Policies

Browse every Conditional Access policy, grouped by persona (the CA-number range in the name: Global 000–099, Admins 100–199, Internals 200–299, and so on).

• Cards / List / Settings matrix — Cards show each policy in full; List is a compact one-line-per-policy view; the Settings matrix is a policies × settings grid for spotting differences at a glance. The matrix has a full-screen button.
• Search — filter by CA number, policy name or persona.
• Select policies (checkboxes) — a green action bar appears: send the selection straight to Documentation, Backup, Assign groups, Set state or Delete.
• Per-card quick actions — Documentation, Backup, Assign groups and Policy state, scoped to that one policy.
• Apply flow (per persona) — a visual of what actually applies to a persona, including Global policies in scope and honouring exclusions (an excluded persona group drops the policy from the flow).
• 🧹 Housekeeping — appears only when there is something to clean: policies that are Off while a higher version of the same CA number also exists, i.e. the old versions a match & replace import left behind as your rollback. It lists each one next to the policy that superseded it; the ones you tick go through the normal delete flow (JSON backup + typed DELETE).

Read-only. Nothing changes until you open a write tool from the action bar.

📄 Create documentation

Turn all or selected policies into shareable documentation with Limon-IT branding.

• Word (.docx) — an editable document, one section per policy.
• PDF — the same, print-ready.
• PNG — a single image of the selection.
• PNG bundle — a zip with one image per policy.

Produces a download. Nothing is written to the tenant.

🔍 Gap analyse

A users × policies impact matrix: who is in scope for what, who bypasses a policy and why.

• Group filters — narrow the matrix columns to the policies that target chosen groups.
• Apply flow — the same per-persona flow as in List Policies.
• Export — a standalone HTML report you can open outside the tool.

Read-only.

🛡 Best-practice & bypass checks

Checks the baseline against known Conditional Access bypasses and the Swiss-cheese model.

• MFA coverage, FOCI token-sharing, break-glass coverage, known bypass apps, and a persona × control coverage matrix.
• Each finding has a severity and an explanation; a deployed-but-Off policy is flagged as not yet enforcing.
• Export MD — the findings as Markdown for a ticket or review.

Read-only.

⚡ CA validator NEW

For each enabled policy, the sign-in simulations it implies — the combinations of user, application, client app, location, device platform and risk it targets — and, per grant control, the control each one should enforce.

• Expected control — every simulation shows the control the policy would require (MFA, Block, Compliant device, …). When the principal, app, location or platform is on the excluded side, the expectation inverts to “no <control>” — proving the policy does not fire there.
• Run against a target — optionally enter a user (UPN) or a persona group (name or ID) to scope the report to only the policies that actually apply to that principal (include minus exclude); for a user, their group and role memberships are evaluated. Leave empty to simulate every policy.
• Include report-only — off by default; tick it to also simulate policies in report-only mode.
• Filter & search — filter by expected control, or search by policy or simulation text; collapse/expand all policies.
• Users are shown as representative placeholders (“all users”, “members of <group>”, “role: …”) — no individual accounts are sampled. Session-only policies are listed as having nothing to assert.

Read-only. Ported from Jasper Baes' Conditional Access Validator (CC BY-NC-SA 4.0); the Maester test-code generation is not included.

🧪 What-If NEW

Simulate one sign-in and see exactly which policies would hit it — the same idea as the Entra portal's What If tool.

• Required conditions — user, target resource, device platform and client app. Everything else (IP, country, device state, sign-in/user/insider risk, authentication flow) is optional.
• Policies that apply — each with the grant controls (and/or) and session controls that must be satisfied. A verdict line at the top says whether access ends up blocked or granted-with-controls.
• Policies that do not apply — each with the first condition that wasn't met (user excluded via a group, wrong client app, location out of scope, …).
• Unspecified conditions — if a policy scopes something your scenario leaves blank (say sign-in risk), it can't be evaluated and so does not apply. Fill the field in to test it, exactly as the Microsoft evaluation API behaves.
• App groups don't match — a policy targeting the Office 365 group won't match by design; pick the specific app. Only enabled and report-only policies are evaluated; Off policies are listed separately.
• Export MD — the scenario and both lists as Markdown.

Read-only. Like the Microsoft tool it does not follow Conditional Access service dependencies, so a policy on a downstream service isn't pulled in.

🕓 Change audit NEW

Who changed which Conditional Access resource, when, and exactly what changed — read from the Entra directory audit log.

• Covers policies, named locations, authentication strengths and contexts, and terms of use — add, update and delete.
• Field-level diff — expand an entry and you get the fields that actually moved (state: report-only → enabled, a group added to excludeGroups), not a wall of JSON. Assignment lists are compared as sets, so you see the one group that changed rather than the whole array.
• Who and from where — the user or application that made the change, with the source IP, plus the result if it failed.
• Filters — by resource kind, plus search across resource, person and changed field name; pick a 7, 30 or 90-day window.
• Export MD — the whole change set with per-entry diff tables, for a review or a ticket.

Read-only. Needs AuditLog.Read.All (requested when you run it) and a reader role such as Reports Reader, Security Reader or Security Administrator. Audit retention is licence-bound — roughly 30 days on Entra ID P1/P2, 7 days otherwise — so this is a rolling window, not full history.

🚪 Exclusion analyzer

Every exclusion across all policies in one place.

• Matrix (default) — exclusions × policies; Effective users — the same but expanded to the individual users a group exclusion covers; Risk review — policies scored for exclusion governance, worst first.
• Risk review flags — High a privileged role excluded, or all guests/external excluded; Medium direct user exclusions (no lifecycle), more than five excluded groups, or disabled accounts still in scope — directly or sitting inside an excluded group; Info a report-only policy whose exclusions go live the moment it is enforced. Each flag is a prompt to review, not a finding. Patterns follow Tiago S. Carvalho's CA exclusions audit.
• Type chips — All, User, Group, Directory role, Guest/external, Application, Named location, Device platform.
• Click to filter — click a user/group row to show only the policies excluding it, or a policy column to show only the exclusions in scope for it. The out-of-scope “·” cells drop away; a banner shows the filter with a one-click clear.
• Export — CSV or Markdown; full-screen for wide grids.

Read-only.

🧬 Baseline Policies — Limon-IT R26.6

Matches this tenant against the Limon-IT baseline catalog and shows the gap.

• Status filters — Missing (not in tenant), Outdated (older version present), Up to date, Not in baseline (in tenant but not the catalog).
• Table / Cards — the large Limon-IT catalog opens as a Table by default; switch to Cards for full detail. Search and collapsible persona sections.
• Catalog switch — Limon-IT R26.6 or the community Joey Verlinden catalog.
• Export MD — a gap report; Refresh re-compares in place; Import baseline hands the missing/outdated set to the Import tool.

Read-only comparison. Only Import (below) writes.

🧩 Baseline (Joey Verlinden)

The same comparison view against the community Conditional Access Baseline by Joey Verlinden — a different catalog, opens as Cards.

Read-only.

📘 MS Learn checks

Checks policies against documented Microsoft Learn exclusions and limitations — break-glass, token protection, Teams Rooms, retired features.

• Findings tab lists what conflicts with the docs; Refresh re-runs after you fix something.
• Buildable fixes — where a documented fix exists, apply it in the tenant (creating a service principal or group if the fix needs one). writes to tenant

Checks are read-only; applying a fix writes, and produces a change report.

🗄 Backup (JSON)

Select policies (or take all) and download their raw JSON in a zip — dependencies (groups, named locations, auth strengths/contexts) and any Terms-of-use PDFs are included, so the backup is importable.

Read-only download.

👥 Conditional Access groups writes to tenant

The group side of the baseline, in one tool.

• Check — baseline groups vs this tenant: present, missing, or drifted. Create a single missing group per row (the TeamsSharedDevices group is created as a dynamic group with the Teams-Rooms membership rule). If a group should be role-assignable but isn’t (immutable after creation), ↻ Recreate role-assignable renames the old one, creates a new one, re-points the referencing policies and writes a readme of where it was assigned.
• Members — a members × groups matrix.
• Assign — add a group to policies’ include or exclude lists (ADD is additive — it never removes what’s there). A final confirmation and a change report before anything is written.

Writes only on Create / Recreate / Assign, each behind a confirmation.

🌐 Named locations BETA writes to tenant

Manage the named locations your Conditional Access policies target — the IP-range and country locations — without leaving the tool.

• Cards / Table — Cards tile at least two per row with the ranges, usage and the Edit/Delete buttons; Table is the same information one line per location, which is the readable option once a tenant has dozens.
• View — every location with its ranges or country list, whether it's trusted, and which policies use it (included or excluded). Filter by IP / country / trusted / unused, or search.
• ＋ New location — create an IP ranges location (CIDR, one per line, IPv4 or IPv6, optionally marked trusted) or a countries/regions location (two-letter ISO codes, optionally including unknown countries, with client-IP or Authenticator-GPS lookup).
• Edit — rename and change the ranges/countries. The type is fixed at creation: an IP location can't become a country location. If you change the trusted flag, you're warned how many policies use “All trusted locations” and would follow the change.
• Delete — a location that no policy references deletes after a plain confirm; one that is still referenced lists those policies and needs a typed DELETE, because removing it drops that condition and usually widens the policy.
• Click a location name — opens its report: every range or country, the trusted flag and what it means, the location id, and the full list of policies that name it plus the ones covering it through “All trusted locations” (each clickable through to the policy card). From there, 📄 Documentation (MD) writes that one location up on its own.
• Export MD — the full inventory with usage, as Markdown.
• ⭳ Export JSON — the configuration of every location as a snapshot file. Nothing is stored server-side, so this is how you keep a record of what the ranges looked like on a given day.
• ⇄ Compare… — load an earlier JSON export and see what moved since: locations whose ranges, countries or trusted flag changed, ones in the file that are gone from the tenant, and ones created since. Matched by display name, because an id from another tenant means nothing here. A flipped trusted flag is the one worth looking at first — it silently changes which policies match.

Reading is read-only; create, edit and delete write to the tenant and ask for Policy.ReadWrite.ConditionalAccess when you run them.

🎚 Set Policy state writes to tenant

Switch selected policies between On (enabled), Report-only (logged, not enforced) and Off (disabled).

Writes the new state to the tenant after you confirm.

📥 Import writes to tenant

Restore a backup (zip or extracted folder). Dependencies are created first (create-if-missing), then the policies — always in state Off unless a replacement inherits an existing state.

• Assignment mode — 🚀 Deployment groups: new policies are scoped to this tenant’s deploy persona groups (CAD-SEC-U-DG-*). Staged and safe — nothing already in the tenant is touched.
• Assignment mode — ♻️ Match & replace: for a policy whose CA number already exists at a different version, the new version keeps the current policy’s assignment and state, merges in any new exclusion groups the update adds (created if missing), and the old version is switched Off — a seamless swap.
• Import only — pick a persona to bring in just its policies, or use All / None. A policy with the same CA number and version is skipped.
• Unknown application references — a policy can only name an app that has a service principal in this tenant, and Graph rejects the whole policy over one it cannot resolve. The importer instantiates the missing ones first (the baseline excludes Microsoft first-party apps like Defender for Endpoint and Defender for Mobile TVM that an unused tenant does not have). If one still cannot be created, the policy is imported without that reference rather than failing — the report names each drop, and a dropped exclusion widens the policy, so review it before switching it On.
• 🔒 no Workload ID licence — a policy scoped to service principals (the CA900 range) needs the separately purchased Microsoft Entra Workload ID licence, which is not part of Entra ID P1/P2. The importer reads the tenant’s subscriptions first; without the licence those policies are shown greyed out and left out entirely, rather than attempted and rejected by Graph with a bare 400. Buy or trial the licence, then re-import.
• 📜 needs ToU — a policy granting a Terms of use imports without that control (Terms of use has no create API); the report gives a checklist to create it in the portal, then re-import.

Writes; a change report is shown on screen and downloadable.

General

• Tabs — tools open in browser-style tabs; the + opens another, the house button returns to the tool grid, and ✕ all closes every tab at once.
• Permissions — sign-in is read-only; a write tool requests its extra scope only when you run it, with an up-front consent step so pop-ups aren’t blocked.
• Demo — append ?demo=1 to explore with sample policies; writes are simulated.
• Build — the number on the sign-in screen matches the asset version; hard-refresh if it lags what you expect.