Conditional Access Policy Review and Break-Glass Validation
A fixed-price, two-week review of the Microsoft Entra Conditional Access estate you already have — a clean-up, not a rebuild. In one Microsoft Entra tenant we export every policy with its state, assignments, conditions, grant and session controls and exclusions; build an overlap and conflict matrix that shows where two policies say the same thing and where they contradict each other; compare what you run against Microsoft's Conditional Access templates and against the Microsoft-managed policies that Microsoft now creates in eligible tenants in report-only state and enables no less than 30 days later if you leave them there; and hunt the bypasses — legacy authentication, device code flow, exclusion groups nobody has pruned, named locations that outlived the office they described, resources sitting outside ‘All resources’, and template-created policies that excluded only the administrator who created them. Every proposed change is evidenced from your sign-in logs, the policy impact view and the What If tool before anything moves; the agreed consolidation is then executed in report-only first and enforced in waves you approve. The engagement ends with a witnessed emergency-access test: two cloud-only break-glass accounts with passkeys, excluded from every enforced policy that could block them — Microsoft-managed policies included — with sign-in alerting and a signed test record. $2,450 per project, fixed, for one Microsoft Entra tenant with up to 30 Conditional Access policies; larger estates and additional tenants are quoted per tenant. Conditional Access itself requires Microsoft Entra ID P1 or higher (P2 for the risk-based policies), billed by Microsoft or your CSP and never folded into this fee.
What this engagement is
Conditional Access is rarely designed twice. It gets built once and then grows by accretion: a policy for the finance pilot, an exclusion for an executive's tablet, a trusted location for an office that has since moved, a template someone clicked through at the end of a long day. Two or three years later, nobody in the room can say with confidence which policy would stop an attacker holding a valid password and a session cookie, or which one would lock out the sales team on a Monday morning. The policy list is long enough that nobody reads it, and the exclusion groups are the part nobody dares touch. Microsoft has made that uncertainty urgent. Microsoft-managed Conditional Access policies are created directly in eligible tenants, already configured, in Report-only state — and Microsoft enables them no less than 30 days after they are introduced if you leave them in report-only, with email and Message center notice two weeks before. You can turn them on sooner or opt out by setting a policy to Off, but you cannot rename or delete them, and the only edits you can make are the state and the excluded identities. The current set covers blocking legacy authentication, blocking device code flow, multifactor authentication for admins accessing the Microsoft admin portals (14 highly privileged roles), MFA for all users, MFA for tenants still on per-user MFA, MFA and reauthentication for risky sign-ins, blocking access for high-risk users, requiring remediation for high-risk users, and — in preview — blocking high-risk agent identities. Two more arrive through Baseline security mode in the Microsoft 365 admin center: require phishing-resistant authentication for admins, and block legacy authentication. Landing those on top of a hand-built estate is where duplicate MFA prompts, contradictory grant controls and genuine lockouts come from. This engagement is the review you do before that happens — or immediately after the first notice arrives. We start with a complete export. Every policy in the tenant, in any state — on, off, report-only — with its assignments, target resources, conditions, grant and session controls, exclusions and the Created by attribution that separates your policies from Microsoft-managed and Baseline security mode ones. That becomes an inventory you can read and an overlap matrix that answers the questions the admin center will not: which policies apply to the same users and the same resources, which grant controls are asked for twice, which pair could be one policy, and which policy exists only because someone was troubleshooting in 2023. Microsoft's own guidance is to consolidate rather than add — Conditional Access has a hard limit of 240 policies per tenant across all states, and policies carry no owner attribute, so ownership has to live in the name and in a register you keep. We give you both: a naming standard that states purpose, target, response and scope at a glance, and an ownership register with a review date against every exception. Then the bypass hunt, because a policy set is only as strong as the paths around it. Legacy authentication and device code flow — the two protocols attackers reach for, and the two Microsoft is now blocking for you. Users still on per-user MFA rather than Conditional Access. Exclusion groups whose membership has drifted: the contractor who left, the service account that was 'temporary', the executive who was excluded during a trip three years ago. Named and trusted locations that quietly grant more than anyone remembers, including country-block lists with a stale allow set. Resources outside a policy that targets All resources (formerly 'All cloud apps'), so a newly onboarded application is protected by nothing. Policies created from a template, which exclude only the administrator who created them — a documented behaviour and a very common source of orphaned exclusions. Guest and B2B access, where inbound trust settings decide whether a partner's MFA claim is accepted. Workload identities. And classic policies, which stopped enforcing controls after 10 July 2024 but still sit in some tenants pretending to be protection; the What If tool tells you whether any remain. Nothing gets changed on an opinion. Each proposed change carries evidence: sign-in log queries showing who would actually have been affected in the retained window (Microsoft keeps 30 days of sign-in logs on Entra ID P1 and P2, seven days on the free tier), the per-policy policy impact view over 24 hours, 7 days or a month, the Conditional Access Insights and Reporting workbook where you already stream sign-in logs to a Log Analytics workspace, and What If simulations for the awkward cases. The findings report and a decision workshop turn that into an agreed change set — including an explicit decision on each Microsoft-managed policy: leave it on, exclude a named identity, or opt out and own the consequence in writing before Microsoft's date passes. Execution follows Microsoft's own order and ours: safety net first. Before a single policy state changes we build or repair the emergency access accounts, to Microsoft's current guidance — two or more accounts, cloud-only on your .onmicrosoft.com domain, not synchronized or federated, credentialled with a passkey (FIDO2 security key) or certificate-based authentication rather than the Authenticator app your other admins use, Global Administrator held as a permanent active assignment in Privileged Identity Management, membership of a dedicated exclusion group applied to every enforced policy that could block sign-in, credentials stored under a dual-control procedure you own, and an alert on every sign-in. Only then does the consolidation go in: changes staged in report-only, observed against real sign-ins, and enforced in waves you approve, each wave with a rollback that is one switch. Microsoft's advice is to run a policy in report-only for at least a week before enforcement, and a two-week engagement does not give every change that long. So we are explicit about it: the changes we enforce inside the window are the ones the evidence already supports, and anything that needs a longer observation period is left staged in report-only with a written enforcement plan, a rollback and a date you own. Leaving a wave staged is a normal outcome of this engagement, not a failure of it — an enforcement date chosen to suit a project plan is how people get locked out. The last day is the test that most organizations have never actually run. With every policy enforced, both break-glass accounts sign in, perform an administrative action, and trigger the alert — watched by your people, written up and signed. You keep the findings report, the evidence pack, the consolidated policy set with names and owners, the exception register, and a runbook that covers the 90-day emergency-access drill Microsoft asks for, the contingency policies to enable during an identity-provider outage, and what to do when Microsoft introduces the next managed policy — because it will. If the review finds that your tenant has no coherent baseline to consolidate, we say so and point you at Conditional Access Policy Implementation, which designs a policy set from scratch. Reviewing an estate and building one are different jobs, and you should only pay for the one you need.
Success criteria
What you receive
How the work unfolds
We take time-bound delegated access that you approve — read-oriented for this phase — and export every Conditional Access policy in the tenant with its full configuration, plus the sign-in log window, named locations, exclusion group memberships, per-user MFA states and the Created by attribution. You get the inventory as a document and a spreadsheet on day two, before any interpretation, so you can see your own estate laid out in one place — often for the first time.
The overlap and conflict matrix is built, the estate is compared against Microsoft's Conditional Access templates and the Microsoft-managed and Baseline security mode policies sitting in your tenant, and the bypass hunt runs: legacy authentication and device code flow in the sign-in logs, per-user MFA holdouts, exclusion group membership, named-location scope, resources outside 'All resources', template-created single-creator exclusions, guest and workload identity coverage, and classic policies. Every finding is verified by an engineer against real sign-in data rather than reported from a tool dump.
A written findings report with severity, exploitability and effort per item, and a two-hour working session with your IT lead and whoever owns security. We agree the target policy set, the naming standard and owners, the decision on each Microsoft-managed policy, which exceptions stay and who owns them, the enforcement waves and their order, the communications plan, and the change window. Decisions are written up the same day and signed off before anything is touched.
The safety net goes in before the changes. Two cloud-only break-glass accounts are created or repaired to Microsoft's current guidance, passkeys registered, Global Administrator assigned permanent active, the dedicated exclusion group applied to every enforced policy that could block sign-in, the sign-in alert rule and action group created and proven, and the credential-storage procedure written with your custodians. Both accounts sign in successfully before we continue. The agreed consolidation is then staged in report-only, and the contingency 'ENABLE IN EMERGENCY' policies are created disabled.
Report-only results are reviewed against real sign-ins in the Conditional Access and Report-only tabs of the sign-in logs and in the policy impact view. Waves are enforced in the agreed order — lowest-risk consolidations first, then the policies that change an authentication requirement, then the blocks — each with your approval, a communications trigger and a documented rollback. Retired policies are switched off rather than deleted first, so reverting is one action, and removed only once the wave is proven.
With every wave enforced, both emergency access accounts sign in, perform an administrative action and trigger the alert, watched by your staff; the test record is timestamped and signed. We deliver the readout — what changed, what it now blocks, what remains open and who owns each exception — hand over the runbook including the 90-day drill and the next-managed-policy procedure, and remove our own delegated access, showing you the audit log entry that proves it.
Prerequisites
Who does what
IT Partner
- Export and inventory every Conditional Access policy in the tenant, build the overlap and conflict matrix, and compare the estate against Microsoft's templates and the Microsoft-managed policies in your tenant
- Run the bypass hunt and verify every finding against real sign-in data before it appears in the report, with the evidence attached
- Build or repair the two emergency access accounts, their exclusion group and their sign-in alert, and prove them before any policy state changes
- Execute the agreed consolidation in report-only, observe it, enforce it in the approved waves with a rollback for each, and stage the contingency policies disabled
- Run the witnessed break-glass test with every policy enforced, deliver the findings report, readout and runbook, and remove our delegated access at the end and show you the proof
Your team
- Approve time-bound delegated access and name the decision-makers for the findings workshop and the enforcement waves
- Decide what happens to each exception and each Microsoft-managed policy — we recommend and evidence, you own the risk decision
- Provide the FIDO2 keys or passkeys for the emergency access accounts, decide where their credentials live and who may open them, and provide the witnesses for the final test
- Own user communications and the service desk during the enforcement waves, and pay Microsoft for licences and for any Azure consumption behind the alerting workspace
- Own the runbook after handover — the exception register and its review dates, the 90-day emergency-access drill, and the decision on the next Microsoft-managed policy that appears
What's not included
Limitations & technical notes
Frequently asked questions
What does the Conditional Access Policy Review and Break-Glass Validation service actually do?
It takes the Conditional Access estate you already run in one Microsoft Entra tenant and makes it explainable, smaller and safe to enforce, in two weeks. We export and inventory every policy, build an overlap and conflict matrix, compare the estate against Microsoft's templates and the Microsoft-managed policies now landing in tenants, hunt the bypasses, evidence every proposed change from your sign-in logs and the What If tool, execute the agreed consolidation in report-only and then enforce it in waves you approve, and finish with a witnessed break-glass test and a signed test record. You keep the findings report, the evidence pack, the consolidated policy set with names and owners, and a runbook.
Microsoft emailed us that it will enable a Conditional Access policy. What happens if we do nothing?
Microsoft enables it. Microsoft-managed policies are created in eligible tenants in report-only state, and Microsoft turns them on no less than 30 days after they are introduced if you leave them in report-only, with email and Message center notice two weeks before — and Microsoft notes that in some cases it can be faster, which it states in the notice. Doing nothing is a decision, and often a reasonable one: these policies are Microsoft's baseline and most tenants should end up with them on. The risk is the collision with what you already run — duplicate MFA prompts, a control that contradicts an existing policy, or an account nobody excluded. This engagement is the 30 days used properly: measure the impact, decide per policy, exclude what genuinely needs excluding, and go into the enablement date knowing what will happen.
Is this just a report, or do you change anything?
Both, in that order. Days 1–5 produce the inventory, the overlap matrix, the bypass findings and a written report with a decision workshop. Days 6–10 execute what you approved in that workshop: the consolidation staged in report-only, observed against real sign-ins, then enforced in waves with a rollback for each, plus the emergency access accounts and their alerting. What we will not do is change something you have not agreed to — every enforced change is on a plan you signed.
What is a break-glass account, and how many should we have?
An emergency access or break-glass account is the way back into your tenant when normal administration fails — a federation or identity-provider outage, every admin's MFA device unavailable, the last Global Administrator leaving, or the Privileged Identity Management deadlock where all Global Administrators are eligible, activation needs approval, and no approver is available. Microsoft's guidance is two or more: cloud-only accounts on the .onmicrosoft.com domain, not synchronized or federated, using a passkey (FIDO2 security key) or certificate-based authentication that differs from the method your other admins use, holding Global Administrator as a permanent active assignment, excluded from Conditional Access policies that block or restrict sign-in, with credentials stored in separate secure locations and an alert on every sign-in. Two, so one lost key or one unavailable custodian does not leave you with none.
How do you test break-glass accounts without locking us out?
In the safest possible order. The accounts are built or repaired on day six — before any policy state changes — with a dedicated exclusion group applied to every enforced policy that could block sign-in, and both accounts sign in successfully before we go further. Then the consolidation is staged in report-only, which by design blocks nothing, and enforced in waves. On the final day, with every wave enforced, both accounts sign in again, perform an administrative action and trigger the alert, in front of your staff. If a wave ever did go wrong, the accounts you proved on day six are the way back in — which is the whole point of building them first.
We already have break-glass accounts. Is this still worth it?
Usually yes, and this is the part of the engagement that surprises people most. The common findings are accounts that were created years ago and never tested; accounts excluded from the policies that existed then but not from the ones added since, or from the Microsoft-managed policies that arrived this year; accounts with a password in a spreadsheet instead of a passkey; accounts synchronized from on-premises, so an Active Directory outage takes them with it; and nobody who can say where the credentials are. We bring what you have up to Microsoft's current guidance rather than replacing it for the sake of it, and the fixed fee is the same either way.
Do we need Microsoft Entra ID P2 for this?
No. Conditional Access itself requires Microsoft Entra ID P1 or higher, and Microsoft 365 Business Premium customers can use Conditional Access features too. Microsoft Entra ID P2 is needed only for the risk-based policies — sign-in risk and user risk — because those depend on Microsoft Entra ID Protection, and Microsoft's managed risk policies target P2 tenants. If you are on P1 we review and consolidate what P1 supports and tell you plainly what P2 would add, with no pressure to buy it. Licences are billed by Microsoft or your CSP; we can transact them at Microsoft's price, and you can move them elsewhere at any time.
How is this different from your Conditional Access Policy Implementation service?
Direction of travel. Conditional Access Policy Implementation designs and builds a policy set for a tenant that does not have one, at $2,950. This engagement reviews, rationalizes and validates a set you already run — inventory, overlap matrix, bypass hunt, evidence, consolidation and break-glass validation — at $2,450. If the review finds an estate too incoherent to consolidate, the honest answer is a rebuild and we will say so and quote it; if you are unsure which one you need, a 30-minute call usually settles it.
How many policies does the fixed fee cover?
One Microsoft Entra tenant with up to 30 Conditional Access policies, counted at export in any state — on, off or report-only — with Microsoft-managed and Baseline security mode policies included in the count. Above 30, or across several tenants, we quote per tenant after a look at the export. Most organizations of 100–2,000 seats sit comfortably under 30; if you are well above it, that is usually itself the finding, because Microsoft's own guidance is to consolidate rather than add against a hard limit of 240 policies per tenant.
Will users be locked out while you consolidate?
That is the risk the whole method is built around. Nothing changes state without evidence from your own sign-in logs; every change is staged in report-only first, which evaluates but does not enforce; Microsoft's advice is at least a week in report-only, and where a change needs longer than the engagement allows we leave it staged with a written enforcement plan rather than rushing it; enforcement happens in waves you approve, in an order that puts the low-risk consolidations first and the blocks last; retired policies are switched off rather than deleted so a revert is one action; and the emergency access accounts are proven before any of it starts. We also ask you to warn your service desk — a quiet consolidation is one your help desk pays for.
Could we just use Microsoft's Conditional Access Optimization Agent instead?
It is a genuinely useful tool and it does something different. The agent scans the last 24 hours for users, applications and agent identities not covered by policy, suggests new policies in report-only, and proposes consolidation of similar policy pairs — up to 40 pairs, 300 users and 150 applications per run. It needs Microsoft Security Copilot with provisioned security compute units and Microsoft Entra ID P1, and Microsoft bills at least one SCU every month once provisioned, whether the agent runs or not; that consumption is your charge from Microsoft, never ours. What it does not do is hunt stale exclusion-group members, judge whether a named location still reflects reality, decide which exceptions your business is willing to keep, or sign in as your break-glass account with a witness in the room. Where you already have it, we read its suggestions as one more input and say which we agree with.
We still need legacy authentication and device code flow for a few things. Is that a problem?
It is a finding with an owner, not a lecture. We locate every real use in your sign-in logs — the scanner that sends by SMTP, the line-of-business app on IMAP, the Teams Rooms devices and shared hardware that genuinely depend on device code flow — and then scope the exception narrowly rather than leaving the protocol open tenant-wide. Microsoft publishes specific guidance for restricting device code flow while allowing Microsoft Teams devices, and that is the pattern we use. Every exception ends up in the register with a named owner, a reason and a review date, so it is a decision rather than a leftover.
What do we get at the end, and who is it for?
A findings report with severity and effort per item; the policy inventory and overlap matrix as a document and a spreadsheet; the evidence pack behind every change; the consolidated policy set with a naming standard, owners and an exception register with review dates; the executed changes and their rollback plan; the two emergency access accounts with their alerting, storage procedure and signed test record; and a runbook covering the 90-day drill, the contingency policies and what to do when the next Microsoft-managed policy appears. The readout is written for two audiences at once — the engineers who will run it and the manager who has to answer the insurer's questionnaire.
Who looks after this after you leave?
You do, with the runbook — it is written for the people who will actually use it, and the exception register carries review dates rather than good intentions. If you buy your Microsoft licensing through IT Partner, break-fix support during business hours is included at no extra charge, so a question about a policy that fired unexpectedly is just a ticket. There is no lock-in in either direction: you can stop at any time, and your subscriptions can move to another CSP or back to Microsoft whenever you choose.
How does pricing work?
$2,450 per project, fixed, quoted in writing before work begins — and you pay after you approve delivery. It covers one Microsoft Entra tenant with up to 30 Conditional Access policies: the export and inventory, the overlap and conflict matrix, the template and managed-policy comparison, the bypass hunt, the evidence pack, the findings report and decision workshop, the executed consolidation in report-only and its enforcement waves, the two emergency access accounts with their exclusion group, alerting and storage procedure, the witnessed break-glass test, the readout and the runbook. Larger estates, additional tenants, licences and any Azure consumption behind the alerting workspace sit outside the fee — Microsoft bills those, we do not.