Conditional Access: Proven Safe Accountancy Firm Policies

Conditional Access is the most valuable security control most UK accountancy firms already own and have never switched on. It sits inside every Microsoft 365 Business Premium subscription, it costs nothing extra to configure, and it is the difference between a practice that merely asks staff for a code and a practice that can say exactly who is allowed to reach client data, from what device, from what country, and what happens the moment any of that changes.

The question partners actually ask is narrower and much more useful than “should we turn it on”: which policies should we enable, in what order, and what will break. This guide answers that. It sets out a twelve-policy baseline built for a UK practice, explains what each Conditional Access policy assigns, conditions and controls, tells you what it breaks and how to handle it, and gives you a thirty-day rollout calendar that starts in report-only mode and ends with every Conditional Access policy enforced. It prices the whole thing for a real 34-person, two-office practice.

Three companion pieces sit underneath this one. Our Microsoft 365 security checklist for accountancy firms covers the twenty tenant-wide controls this policy set assumes, is Microsoft 365 Business Premium enough for an accountancy firm works through the licensing that decides which of these twelve policies you can actually build, and Cyber Essentials for accountancy firms covers the certification that now fails a practice outright for weak multi-factor authentication. If your concern is payment fraud specifically, invoice fraud in accountancy firms shows what a compromised mailbox is actually used for.

All UK prices quoted here are the list prices published on Microsoft’s own UK storefront, on an annual commitment, excluding VAT. Every Conditional Access policy setting is quoted from Microsoft’s current documentation rather than from memory, because the product changes constantly and half the guidance circulating online describes a portal that no longer exists.

Table of contents

What Conditional Access Actually Does in a Practice
Why Conditional Access Matters More in an Accountancy Firm
Do You Already Have Conditional Access? The Licence Question
Security Defaults or Conditional Access: Which One Are You On Today?
The Conditional Access Policies Microsoft Has Already Put in Your Tenant
Before You Enable a Single Conditional Access Policy: Break-Glass Accounts
The Twelve-Policy Conditional Access Baseline for an Accountancy Firm
Wave One Conditional Access Policies: The Four Nobody Argues About
Wave Two Conditional Access Policies: Devices, Locations and Sessions
Wave Three Conditional Access Policies: Guests, Risk and Token Theft
Report-Only Mode: Enabling Conditional Access Without Locking Out a Partner
A Thirty-Day Conditional Access Rollout Calendar
What Conditional Access Breaks in a Practice, and How to Handle It
Session Controls in Conditional Access: Sign-In Frequency and Browser Persistence
Conditional Access and Continuous Access Evaluation
What Conditional Access Costs a 34-Person Accountancy Practice
Proving It: Conditional Access Evidence for Cyber Essentials, Insurers and Clients
Naming, Documentation and Change Control for Conditional Access Policies
Ten Conditional Access Mistakes We Keep Finding in Practices
Frequently Asked Questions About Conditional Access
Conditional Access: The Short Version for a Partner Meeting
References and Further Reading

What Conditional Access Actually Does in a Practice

Conditional Access is Microsoft’s policy engine for Microsoft Entra ID. Access control for accountancy practices, for law firms and for hotels runs on exactly the same engine wearing three different sets of client obligations, so it is worth being precise about the mechanics before arguing about the settings.

The if-then model

Microsoft describes Conditional Access policies as “if-then statements”: if a user wants to reach a resource, then they must satisfy an action. If a user wants to open Outlook, then they must complete multi-factor authentication. If a sign-in arrives from an unmanaged laptop, then the browser session must not persist. Every Conditional Access policy you will ever write is one of those sentences.

The important structural detail is that Conditional Access is evaluated after first-factor authentication completes. Microsoft is explicit that it “isn’t intended to be an organization’s frontline defense” against attacks like denial of service. The password is checked first; the Conditional Access policy engine then decides whether that verified identity, on that device, from that location, gets a token.

Signals in, decisions out

A Conditional Access policy reads signals and issues a decision. The signals Microsoft lists are the user, group or agent identity; IP location information including whole countries or regions; the device platform and its compliance state; the application being reached; real-time and calculated risk from Microsoft Entra ID Protection; and session signals from Microsoft Defender for Cloud Apps.

The decisions are simpler. Block access is the most restrictive. Grant access can be unconditional or can require one or more controls: multi-factor authentication, a named authentication strength, a device marked as compliant, a Microsoft Entra hybrid joined device, an approved client app, an app protection policy, a password change, or acceptance of terms of use.

Part of the Conditional Access policy	What you set there	Typical value in a practice
Users or workload identities	Who the policy applies to, and who is excluded	All users, minus the break-glass group
Target resources	Which applications or resources are in scope	All resources, formerly All cloud apps
Network	Named locations by IP range or by country	Office ranges marked trusted, rest blocked
Conditions: client apps	Modern clients versus legacy protocols	Exchange ActiveSync clients and Other clients
Conditions: device platforms	Windows, macOS, iOS, Android, Linux, unknown	Unknown and unsupported platforms blocked
Conditions: sign-in and user risk	Risk levels from Microsoft Entra ID Protection	High risk, on a P2 licence only
Grant controls	Block, or grant with named requirements	Require authentication strength
Session controls	Sign-in frequency, browser persistence, token protection	No persistent browser on unmanaged devices
Enable policy	Report-only, On, or Off	Report-only first, always

Where you find it

Conditional Access lives in the Microsoft Entra admin center under Entra ID then Conditional Access. The least privileged role that can view policies is Security Reader; the least privileged role that can create and edit them is Conditional Access Administrator. In a practice with a two-person IT team, that distinction matters: the person who reviews the Conditional Access policy set every quarter does not need the rights to change it.

The Overview page shows how many policies are enabled versus report-only, a Coverage tab shows which applications have and have not been covered by a Conditional Access policy in the past seven days, and the Policies page lists everything including anything created by Microsoft itself. That Coverage tab is the fastest way to find the gap in a practice that thinks it is already protected.

Why Conditional Access Matters More in an Accountancy Firm

Every business benefits from stronger identity controls. An accountancy practice benefits disproportionately, and it is worth being concrete about why, because that reasoning is what gets a Conditional Access project approved by a partner group that has heard “we need better security” too many times.

You hold the whole client, not part of it

A practice mailbox contains bank details, payroll data, personal tax references, National Insurance numbers, dates of birth, draft accounts, and the email thread in which a client agrees a payment. Very few businesses of comparable size concentrate that much sensitive data about that many other organisations in one Microsoft 365 tenant. A single compromised account is not one victim, it is a supplier-chain incident affecting every client on that person’s list.

Your credentials open other people’s systems

Practice staff log into HMRC agent services, Companies House, client bookkeeping platforms, client banking portals in read-only roles, and client payroll systems. An attacker who lands in a practice mailbox is not looking for your data. They are looking for the standing authority you hold over your clients’ filings and payments, which is exactly the scenario our guide to business email compromise walks through in detail.

The regulators have already moved

HMRC now requires multi-factor authentication for agent services access, Companies House has moved to identity verification for anyone filing, and the Money Laundering Regulations 2017 impose a five-year record-keeping duty that assumes the records are still there and still trustworthy. The Information Commissioner’s Office fined DPP Law £60,000 for security failings that began with an account that was reachable without multi-factor authentication. Conditional Access is the control that makes an evidential answer possible when any of those bodies asks how access was restricted.

The numbers are worse for firms your size

The Cyber Security Breaches Survey 2025/2026, published on 30 April 2026, found 43% of UK businesses had experienced a breach or attack in the previous twelve months, rising sharply with headcount. The professional, scientific and technical sector, which is where accountancy practices sit, reported the highest rate of board-level ownership of cyber risk at 41%, and yet only 47% of businesses overall reported using two-factor authentication at all. Read next to the rest of the survey, that single figure says most cybersecurity money in professional services has gone into tooling rather than into identity.

Businesses reporting a breach or attack in the last 12 months, by size (CSBS 2025/2026)

Micro businesses — 42%

Small businesses — 46%

Medium businesses — 65%

Large businesses — 69%

Conditional Access has the best evidence base in the industry

Microsoft’s own figures are unusually blunt. Alex Weinert, its Director of Identity Security, has written that an account is “more than 99.9% less likely to be compromised” when multi-factor authentication is used. Microsoft’s later research puts the figure at blocking more than 99.2% of account compromise attacks, and the Microsoft-managed policy documentation states that requiring multi-factor authentication “continues to reduce the risk of compromise by more than 99%”. Conditional Access is the mechanism that makes that requirement universal instead of optional.

Do You Already Have Conditional Access? The Licence Question

This trips up more practices than any other part of the subject, so it is worth settling immediately. Conditional Access requires Microsoft Entra ID P1 at minimum, and Microsoft’s documentation states plainly that “customers with Microsoft 365 Business Premium licenses can also use Conditional Access features”.

What Business Premium already includes

Microsoft 365 Business Premium, at £16.90 per user per month, includes Microsoft Entra ID P1. That means a 34-person practice on Business Premium can build every Conditional Access policy in waves one and two of the baseline below without buying anything at all. Most practices we assess are paying for this capability already and using none of it.

What needs Microsoft Entra ID P2

Risk-based policies are the exception. Any Conditional Access policy that conditions on sign-in risk or user risk requires Microsoft Entra ID Protection, which is a P2 feature. So the three risk policies in wave three need either a standalone Entra ID P2 licence at £7.70 per user per month, or the Microsoft Defender Suite add-on for Business Premium, which is also £7.70 per user per month and includes Entra ID P2 alongside Defender XDR, Defender for Endpoint P2, Defender for Office 365 P2, Defender for Identity and Defender for Cloud Apps.

That is a genuinely important piece of arithmetic for a practice: at identical list price, the Defender Suite buys Entra ID P2 plus five other products, and the only constraints are that it “requires a Microsoft 365 Business Premium subscription” and is capped at a maximum of 300 seats.

UK list price per user per month, annual commitment, ex VAT

Entra ID P1 (policy engine only) — £5.40

Entra ID P2 (adds risk detections) — £7.70

Entra Suite — £9.20

Business Premium (P1 plus everything else) — £16.90

What happens if the licence lapses

Microsoft handles expiry gracefully and it is worth knowing. When the licences required for Conditional Access expire, policies “aren’t automatically disabled or deleted”; you can view and delete the remaining policies but you cannot update them. Your practice does not suddenly become wide open because a renewal slipped, but it does become frozen, which is its own problem during an incident.

Security Defaults or Conditional Access: Which One Are You On Today?

Before writing a single policy, find out which of the two systems your tenant is currently running, because they are mutually exclusive and the answer changes what you do first.

What security defaults enforce

Security defaults are free, apply to every tenant regardless of licence, and enforce a fixed set of protections: all users must register for multi-factor authentication, administrators must perform it, other users must perform it “when necessary” as judged by Microsoft, legacy authentication protocols are blocked, device code flow is blocked, and privileged activity such as reaching the Azure portal requires multi-factor authentication.

If your tenant was created on or after 22 October 2019, security defaults may well be switched on already, with a 24-hour grace period after tenant creation before enforcement begins. Microsoft also periodically enables them automatically for tenants that have no Conditional Access policies, no premium licences and no active legacy authentication clients. Since 29 July 2024 the old 14-day grace period for users to register has been removed entirely, and from 1 July 2026 all new tenants block device code flow as part of security defaults.

Why a practice should not stay there

Security defaults are all-or-nothing. You cannot exclude the multifunction printer that scans to email, you cannot require a stronger method for partners than for temporary staff, you cannot exempt the office IP range, and you cannot run anything in report-only mode to see what it would do. Microsoft’s own guidance is direct: “if you’re an organization with Microsoft Entra ID P1 or P2 licenses, security defaults are probably not right for you.”

Question a partner will ask	Security defaults	Conditional Access
What does it cost?	Nothing, any licence	Included in Business Premium
Can we exclude the scanner?	No	Yes, by account and by condition
Can partners face stronger rules?	No	Yes, by group or directory role
Can we test before enforcing?	No	Yes, report-only mode
Can we block by country?	No	Yes, named locations
Can we require a managed device?	No	Yes, with Intune compliance
Can we react to risky sign-ins?	Partly, Microsoft decides	Yes, explicitly, with P2
Can we evidence it to an auditor?	One screenshot, one toggle	Named policies with change history

The switchover rule

You cannot run both. Organisations that implement Conditional Access policies must disable security defaults, under Entra ID then Overview then Properties then Manage security defaults. Microsoft’s instruction is that after disabling them, organisations “should immediately enable Conditional Access policies to protect their organization” — so build and test the Conditional Access policies first, in report-only mode, and only then flip the switch. A practice that disables security defaults on a Friday afternoon and plans to write policies on Monday has spent a weekend with nothing enforced at all.

The Conditional Access Policies Microsoft Has Already Put in Your Tenant

Most practices do not start from zero, and many do not realise it. Microsoft now deploys its own Conditional Access policies directly into eligible tenants, and they behave in a very specific way that a practice needs to understand before it starts building.

How Microsoft-managed policies work

Microsoft creates these policies automatically in a Report-only state, with preconfigured conditions and recommended controls. It then enables them “no less than 30 days after they’re introduced” if they are left in report-only, having notified customers by email and Microsoft 365 message centre post two weeks before enabling. You can turn them on sooner, or opt out by setting the state to Off. You cannot rename or delete them.

That is the part practices miss. A Microsoft-managed policy sitting quietly in report-only will start enforcing on its own timetable. If nobody in the practice reads the message centre, the first sign is a partner being prompted for multi-factor authentication on a Monday morning with no warning.

The current list

Microsoft-managed policy	What it does	Who it targets
Multifactor authentication for all users	Requires MFA on every sign-in	All users in the tenant
Multifactor authentication for admins accessing Microsoft Admin portals	Requires MFA for portal access	14 highly privileged roles
Multifactor authentication for per-user multifactor authentication users	Moves legacy per-user MFA into policy	Tenants with under 500 such users
Block legacy authentication	Blocks IMAP, SMTP, POP3 and old clients	All users
Block device code flow	Blocks the cross-device code sign-in flow	All users
Multifactor authentication and reauthentication for risky sign-ins	Forces MFA and reauthentication on high risk	P2 tenants, guests excluded
Block access for high-risk users	Blocks until the user risk is remediated	P2 tenants
Require remediation for high-risk users	Guides the user through recovery instead of blocking	P2 tenants, not for guests
Block all high risk agents from accessing all resources (Preview)	Blocks agent identities flagged high risk	Agent identities
Require phishing resistant authentication for admins	Baseline security mode policy for admin roles	Privileged admin roles

The three things to do about them this week

First, open Entra ID then Conditional Access then Policies and filter for anything with Microsoft in the Created by column. Second, add your break-glass group to the excluded identities on every one of them — Microsoft explicitly tells you to “exclude your break-glass or emergency access accounts from managed policies just like other Conditional Access policies”, and the edit control you need sits under the Excluded identities section rather than the Edit pencil at the top, which can throw a “failed to update” error. Third, decide deliberately whether each one goes On or Off rather than letting the 30-day clock decide for you.

If you want to change more than the state and the exclusions, use the Duplicate button. That gives you a fully editable copy starting from Microsoft’s recommended position, which is a much better starting point than a blank policy.

Baseline security mode is a second, separate source of policies

Two Conditional Access policies can also arrive from Baseline security mode in the Microsoft 365 admin center: Require phishing resistant authentication for admins and Block legacy authentication. These show Baseline security mode in the Created by column, are managed from the Microsoft 365 admin center under Settings, Org Settings, Security and Privacy, and — unlike Microsoft-managed policies — they count as created by the administrator, not by Microsoft.

There is one known artefact worth checking. Customers who opened Baseline Security Mode between November 2025 and early February 2026 “might see two draft Microsoft Entra ID Conditional Access policies created in their tenant in a Disabled state”, attributed to whichever administrator visited the page. Microsoft has confirmed this “doesn’t represent a security incident”. If you find two mystery disabled policies with an admin’s name on them, that is almost certainly what they are.

Before You Enable a Single Conditional Access Policy: Break-Glass Accounts

This is the step practices skip, and it is the step that turns a routine rollout into a support call to Microsoft. Every piece of Microsoft guidance on every Conditional Access policy template repeats the same instruction: exclude your emergency access accounts.

What Microsoft actually specifies

Create two or more emergency access accounts. They must be cloud-only accounts using the .onmicrosoft.com domain, not federated and not synchronised from on-premises. Assign the Global Administrator role, and in Privileged Identity Management make that assignment permanent active rather than eligible, so no approval workflow stands between you and recovery.

Register a passwordless, phishing-resistant method on them — a passkey (FIDO2) is Microsoft’s recommendation, with certificate-based authentication as the alternative if the practice already runs a PKI. That method must be different from the one your normal admin accounts use: if the partners use the Authenticator app, the break-glass accounts use security keys.

Why they still need multi-factor authentication

A point that catches people out: break-glass accounts are not exempt from Microsoft’s mandatory MFA enforcement. Microsoft’s documentation states that “break glass or emergency access accounts are also required to sign in with MFA once enforcement begins”, and the FAQ is blunter still — system enforcement “applies to all user accounts, regardless if they are a student account, break-glass account, an administrator account with activated or eligible roles, or any user exclusions”. Passkey or certificate-based authentication satisfies the requirement, which is precisely why Microsoft specifies those two methods.

The exclusion rule, stated precisely

Exclude emergency access accounts from Conditional Access policies that block or restrict sign-in. Report-only policies do not block access and do not need an exclusion. In practice, create a security group called something like EmergencyAccess, put both accounts in it, and exclude that group on every enforcing policy you build. Excluding a group rather than two named users means a future third account is covered automatically.

Guardrail	Microsoft’s requirement	What it looks like in a 34-person practice
Number of accounts	At least two, for redundancy	Two, held by two different partners
Account type	Cloud-only, .onmicrosoft.com, not federated	No link to the practice domain or to the server
Authentication method	Passkey (FIDO2) or certificate-based	Two security keys, different brand to the staff keys
Role assignment	Global Administrator, permanent active in PIM	Never eligible-only, never approval-gated
Credential storage	Separate, secure, fireproof locations	One key per office safe, combinations changed on leavers
Policy exclusion	Excluded from policies that block or restrict	One EmergencyAccess group, excluded everywhere
Monitoring	Alert on every sign-in and audit event	Severity 0 alert to both partners and the IT provider
Validation cadence	At least every 90 days, and on IT staff changes	Four drills a year, minuted at the practice meeting
Credential expiry	Must not expire or be caught by automated cleanup	Excluded from any stale-account clean-up script
Post-use review	Post-mortem after every use	Was it a drill, an emergency, or misuse?

The quarterly drill is the part that gets skipped

Microsoft asks you to “regularly test (for example, every quarter) that emergency access accounts can sign in successfully with your current Conditional Access configuration”, and to validate at least every 90 days, on IT staff changes, and when subscriptions change. In a practice, tie the drill to the quarter end that is already in the diary. The drill has three steps: confirm the authorised-user list is current, sign in with each account and perform one administrative task, and confirm the alert fired. Fifteen minutes, four times a year.

Contingency policies

The advanced move, and one worth building once the baseline is stable, is a set of contingency Conditional Access policies kept in the Off state, ready to enable during an outage to restore access for critical users. If your multi-factor authentication provider or your device compliance service has a bad day, a pre-written, pre-approved fallback policy is the difference between a controlled degradation and an unplanned free-for-all.

The Twelve-Policy Conditional Access Baseline for an Accountancy Firm

Here is the answer to the question in the title. Twelve policies, grouped into three waves, each wave enabled a week apart after a report-only soak. Waves one and two need only Microsoft 365 Business Premium. Wave three needs Entra ID P2, whether standalone or via the Defender Suite.

Microsoft ships policy templates for most of these, organised into categories — Secure foundation, Zero Trust, Remote work, Protect administrator, Emerging threats and one for AI agent identities — and you will find them under Conditional Access then Create new policy from templates, with Show more revealing the full list of each category. Templates are created in report-only mode by default. There is one trap: a template that targets users “exclude only the user creating the policy from the template”, so you must edit every template-created Conditional Access policy to swap that personal exclusion for your EmergencyAccess group.

#	Policy	Assigned to	Control	Licence	Wave
1	Require MFA for all users	All users	Require authentication strength	P1	One
2	Block legacy authentication	All users	Block access	P1	One
3	Phishing-resistant MFA for admins	14 directory roles	Phishing-resistant MFA strength	P1	One
4	MFA for Microsoft admin portals	14 directory roles	Require MFA	P1	One
5	Block device code flow	All users	Block access	P1	Two
6	Secure security-info registration	All users	Require MFA, restrict to trusted network	P1	Two
7	Require compliant or hybrid device, or MFA	All users	Grant with one of three controls	P1 plus Intune	Two
8	Block access from outside approved countries	All users	Block access	P1	Two
9	No persistent browser on unmanaged devices	All users	Session controls	P1	Two
10	Require MFA for guest access	Guest and external users	Require MFA	P1	Three
11	Risk-based sign-in and user risk policies	All users	MFA, reauthentication or block	P2	Three
12	Token protection for mail, files and chat	Pilot group, then all	Session control	P1	Three

Why twelve and not twenty

You can build forty Conditional Access policies. You should not. Every Conditional Access policy you add is a policy somebody has to understand at two in the morning when a partner cannot sign in from a hotel in Dublin. Twelve is enough to cover identity, protocols, privilege, devices, geography, sessions, guests, risk and token theft, and it is few enough that the whole set fits on one page of a practice’s information security documentation.

The one policy to build first if you build nothing else

If a practice will only ever do one thing, make it policy 1: require multi-factor authentication for all users, targeting all resources, with no application exclusions. Microsoft’s own recommendation is stated in exactly those terms: “Microsoft recommends all organizations create a baseline Conditional Access policy that targets: All users, all resources without any app exclusions, and requires multifactor authentication.”

Wave One Conditional Access Policies: The Four Nobody Argues About

These four policies are the ones every practice should be running, they carry almost no business disruption once the exclusions are right, and together they close the routes that credential attacks actually use.

Policy 1: Require multi-factor authentication for all users

Assignments: include All users; exclude your EmergencyAccess group and, if you run Microsoft Entra Connect or Cloud Sync, the Directory Synchronization Accounts directory role. Target resources: All resources (formerly ‘All cloud apps’), with no application exclusions. Access controls: grant access, Require authentication strength, and select the built-in Multifactor authentication strength.

Authentication strength rather than the older “Require multifactor authentication” tick box is the modern control, and it matters because it lets you raise the bar later without rebuilding the Conditional Access policy. There is one compatibility warning to note: external authentication methods “are currently incompatible with authentication strength”, so a practice using a third-party MFA provider must use the plain Require multifactor authentication grant control instead. You also cannot combine both controls in one policy, because the built-in Multifactor authentication strength is equivalent to the tick box.

The three built-in authentication strengths

Understanding these three is what lets you write policies 1 and 3 correctly, because they are the same control set at different heights.

Authentication method combination	MFA strength	Passwordless MFA	Phishing-resistant MFA
FIDO2 security key	Yes	Yes	Yes
Windows Hello for Business or platform credential	Yes	Yes	Yes
Certificate-based authentication (multifactor)	Yes	Yes	Yes
Microsoft Authenticator (phone sign-in)	Yes	Yes	No
Temporary Access Pass	Yes	No	No
Password plus something the user has	Yes	No	No
Federated multifactor	Yes	No	No
SMS sign-in, password alone, single-factor certificate, QR code	No	No	No

“Something the user has” means a text message, a voice call, a push notification, a software OATH token or a hardware OATH token. Note what is missing from every column: a password on its own, and SMS sign-in on its own, satisfy nothing.

Policy 2: Block legacy authentication

Assignments: All users, excluding EmergencyAccess and, temporarily, any account that genuinely still needs an old protocol. Target resources: All resources. Conditions: Client apps, set Configure to Yes, and tick only the two boxes Exchange ActiveSync clients and Other clients. Access controls: Block access.

The evidence for this one is the strongest in the whole product. Microsoft’s analysis finds that “more than 97 percent of credential stuffing attacks use legacy authentication and more than 99 percent of password spray attacks use legacy authentication protocols”. Legacy protocols cannot carry a second factor, so an attacker who finds one open has bypassed policy 1 completely.

Before enabling, find out who is using it. In Entra ID then Monitoring & health then Sign-in logs, add the Client App column, filter on the legacy protocols, and repeat the exercise on the User sign-ins (non-interactive) tab — that second tab is where the scanner and the old line-of-business app hide. Microsoft also publishes a “Sign-ins using legacy authentication” workbook that does the triage for you.

Policy 3: Require phishing-resistant multi-factor authentication for administrators

Assignments: include the directory roles rather than named people, so the Conditional Access policy follows the role. Target resources: All resources. Access controls: grant, Require authentication strength, Phishing-resistant MFA strength.

This is the single highest-value upgrade in the set, and it is free on Business Premium. It means a partner with Global Administrator rights cannot approve a push notification into an attacker’s hands, because push notifications do not satisfy the strength. Practically, it means buying security keys or enabling Windows Hello for Business, and it means the admin accounts must be separate from the day-to-day accounts — which is good practice anyway and dramatically reduces how often anyone is prompted.

The fourteen roles Microsoft treats as highly privileged

Global Administrator, Application Administrator, Authentication Administrator, Billing Administrator, Cloud Application Administrator, Conditional Access Administrator, Exchange Administrator, Helpdesk Administrator, Password Administrator, Privileged Authentication Administrator, Privileged Role Administrator, Security Administrator, SharePoint Administrator and User Administrator. In a 34-person practice, most of these should be assigned to nobody at all. Audit the list before you write the Conditional Access policy; it is common to find a departed bookkeeper still holding Helpdesk Administrator.

Policy 4: Require multi-factor authentication for Microsoft admin portals and Azure management

Assignments: the same fourteen roles. Target resources: the Microsoft Admin Portals resource, and separately the Windows Azure Service Management API if the practice has any Azure footprint. Access controls: Require multifactor authentication.

This policy overlaps with Microsoft’s own mandatory enforcement but is not the same thing, and the distinction matters for evidence. Microsoft’s mandatory MFA is a platform-level enforcement outside your control; policy 4 is a Conditional Access policy of yours, with a name, an owner and a change history, which is what an auditor can actually be shown.

Mandatory MFA is already here, on Microsoft’s timetable

Phase 1 began in October 2024 for the Azure portal, Microsoft Entra admin center and Microsoft Intune admin center, covering any create, read, update or delete operation, and extended to the Microsoft 365 admin center from February 2025.

Phase 2 began on 1 October 2025 for Azure CLI, Azure PowerShell, the Azure mobile app, infrastructure-as-code tools, REST API endpoints and the Azure SDK, for create, update and delete operations; read operations are exempt. Postponement was available until 30 September 2025 for phase 1 and until 1 July 2026 for phase 2. Both windows have now closed. There is, in Microsoft’s words, “no way to opt out”.

Application	Enforcement started	Relevance to a practice
Azure portal	Second half of 2024	Only if the practice runs Azure resources
Microsoft Entra admin center	Second half of 2024	Where you configure all of this
Microsoft Intune admin center	Second half of 2024	Device compliance and enrolment
Microsoft 365 admin center	February 2025	Licence and user administration
Azure CLI and Azure PowerShell	1 October 2025	Any automation scripts your IT provider runs
Azure mobile app, IaC tools, REST API, SDK	1 October 2025	Write operations only, reads exempt

One consequence for practices with any scripting: the OAuth 2.0 Resource Owner Password Credentials flow “is incompatible with MFA”, and the username-and-password credential classes across the Microsoft authentication libraries are now deprecated. If your practice management system or a backup script signs in with a stored username and password, that is a migration to a workload identity, not a Conditional Access exclusion.

Wave Two Conditional Access Policies: Devices, Locations and Sessions

Wave two is where a practice moves from “we have MFA” to “we control the conditions”. These five policies are still all Business Premium, but they need more care because they can affect people who are doing nothing wrong.

Policy 5: Block device code flow

Device code flow lets a user start authentication on one device and finish it on another, with the token returned to the first device. It exists for smart TVs, Teams Rooms panels, printers and other input-limited hardware. Microsoft’s assessment is that it “is rarely used by customers, but is frequently used by attackers”, and it is a mainstay of current phishing kits precisely because the victim sees a legitimate Microsoft page and types a code they were sent by the attacker.

Block it. If the practice runs Microsoft Teams devices that need it, Microsoft publishes specific guidance to scope those exceptions correctly while continuing to block the flow for everyone else — which is the right shape of answer, rather than leaving the door open estate-wide.

Policy 6: Secure security-information registration

This policy governs where staff are allowed to register or change their multi-factor authentication methods. Without it, an attacker holding a stolen password can register their own authenticator and lock the real user out. With it, registration is only possible from a trusted location or after a satisfactory existing authentication.

It is one of the templates in the Secure foundation category, and it is the Conditional Access policy that closes the most common takeover route we see after an initial credential phish. Note that it uses the User actions scope, which is the one scope report-only mode does not evaluate — so this policy must be tested with a real pilot user rather than a report-only soak.

Policy 7: Require a compliant device, hybrid joined device, or multi-factor authentication

The purest version of this control requires devices to be marked compliant by Microsoft Intune. The pragmatic version for a practice that has not finished device enrolment is the “or MFA” variant, which grants access if any one of compliant device, Microsoft Entra hybrid joined device, or multi-factor authentication is satisfied.

There is a hard prerequisite that Microsoft states as a warning: “without a compliance policy created in Microsoft Intune, this Conditional Access policy won’t function as intended. Create a compliance policy first and ensure you have at least one compliant device before proceeding.” Build the Intune compliance baseline — encryption, minimum OS version, firewall, antivirus, screen lock — then build the Conditional Access policy.

Two behaviours are worth knowing so you do not misdiagnose them. The compliant-device control does not block Intune enrolment itself, and it does not block the Microsoft Authenticator app from reading the authentication-method scope it needs during registration. And on iOS, Android, macOS and some third-party browsers, users are prompted to pick a client certificate the first time they sign in through a browser, which is normal and not a fault.

The report-only trap on device compliance

One warning deserves its own paragraph because it generates support calls. Policies in report-only mode that require a compliant device “can prompt users on macOS, iOS, and Android devices to select a device certificate during policy evaluation, even though device compliance isn’t enforced”, and those prompts can repeat until the device is compliant. Microsoft’s fix is to exclude the Mac, iOS and Android device platforms from report-only policies that perform device compliance checks, then remove that exclusion when you enforce.

Policy 8: Block access from outside approved countries

First create the location. Under Conditional Access then Named locations, create either a Countries location or an IP ranges location. For a UK practice, the usual shape is a countries location containing the United Kingdom and any country where the firm genuinely has people, with the Conditional Access policy blocking everywhere else. If you build an IP ranges location for the offices, you can optionally Mark as trusted location, which then feeds other policies.

Then create the Conditional Access policy: All users excluding EmergencyAccess, All resources, Network set to Configure Yes, include Selected networks and locations and pick the blocked location, grant control Block access.

Be honest with the partners about what this does and does not do. It stops the commodity attacker signing in from an unusual country. It does not stop anyone using a UK-exit VPN. It is a filter, not a wall, and its real value in a practice is reducing the noise in the sign-in logs so the genuinely odd events stand out.

Policy 9: No persistent browser session on unmanaged devices

Microsoft Entra ID’s default lets users on personal devices decide for themselves whether to stay signed in, via the Stay signed in? prompt. On a personal or shared machine that is exactly the wrong default, because the cookies “remain stored on the user’s device even after the browser is closed” and the resulting artefacts “remain usable until token expiration, regardless of the Conditional Access policies applied to the resource environment”.

The Conditional Access policy sets browser persistence off, scoped to sessions from devices that are not compliant and not hybrid joined. The practical effect: a member of staff who checks their email from a hotel business centre is signed out when the browser closes, and a partner on a managed laptop notices nothing.

Wave Three Conditional Access Policies: Guests, Risk and Token Theft

Wave three is the layer most practices never reach, and it is where the modern attacks actually live. Two of these three need Entra ID P2.

Policy 10: Require multi-factor authentication for guest access

Practices invite external people into Teams and SharePoint constantly: an outsourced bookkeeper, a client’s finance director, a corporate finance adviser, an auditor working on a transaction. Each of those is a guest identity in your tenant with access to whatever you shared.

Microsoft’s guest MFA template is the control. Note that guest MFA can be satisfied either in the guest’s home tenant or in yours, depending on your cross-tenant access settings, and that if you trust a partner organisation’s device compliance claims you can configure inbound trust rather than re-prompting. Note also that continuous access evaluation “doesn’t support Guest user accounts”, so revocation for guests is not near-instant — another reason to remove guest access on a schedule rather than relying on session controls.

Policy 11: Risk-based sign-in and user risk policies

With Entra ID P2, Conditional Access can read Microsoft Entra ID Protection’s risk signals. Two policies matter. A sign-in risk policy requires multi-factor authentication and reauthentication when a sign-in is scored high risk — Microsoft’s examples are “travel that is highly abnormal, password spray attacks, or token replay attacks”. A user risk policy acts when the account itself is judged likely compromised, for instance because credentials appeared in a leak.

For user risk, Microsoft now offers two shapes. Block access for high-risk users blocks until the risk is remediated. Require remediation for high-risk users uses adaptive risk remediation to walk the user through recovery instead, and it automatically applies authentication strength and a sign-in frequency of every time so that reauthentication happens at the right strength after session revocation. Precedence, if a user is caught by several, is documented: require risk remediation overrides require password change, and block overrides everything.

Two practical caveats. Risky users are blocked from registering for multi-factor authentication, by design, to stop an attacker enrolling their own method. And the remediation policy “isn’t supported for external and guest users”, so it does not cover the population in policy 10.

Policy 12: Token protection for mail, files and chat

Token theft is now the attack that gets past multi-factor authentication, because a stolen session token is a completed authentication. Token protection binds the sign-in session token to the device it was issued to, so that “even if a threat actor steals the token, it can’t be used from another device”.

Availability is uneven and you must check it against your estate before enforcing. For native applications it is generally available on Windows, and in preview on iOS, iPadOS and macOS. It covers Exchange Online, SharePoint Online and Microsoft Teams, plus Azure Virtual Desktop and Windows 365 on Windows. Browser-based support is preview only, limited to selected web apps reaching Azure Resource Manager. Supported Windows devices are Windows 10 or newer that are Entra joined, hybrid joined or registered; the Apple preview needs macOS 14.0 or later or iOS 16.0 or later, the Microsoft Enterprise SSO plug-in, and MDM management.

Microsoft’s deployment advice is explicit and worth following literally: start with a pilot group, run it in report-only first, capture both interactive and non-interactive sign-in logs, analyse them long enough to cover normal application use, and only then add known-reliable users to an enforcement policy.

What wave three is really buying

Waves one and two stop the attacker getting in with a password. Wave three deals with what happens when they get in anyway — a token lifted from a compromised laptop, a leaked credential that surfaces on a breach list, a guest account nobody removed. In a practice holding client money instructions, that second layer is not a luxury.

Report-Only Mode: Enabling Conditional Access Without Locking Out a Partner

Report-only mode is the reason a Conditional Access rollout can be safe. It is a Conditional Access policy state in which the system evaluates the policy on every sign-in and logs what it would have done, without enforcing anything. Users are never prompted and never blocked by a report-only policy.

The seven result states, and what each one is telling you

Result in the sign-in log	What it means	What to do about it
Report-only: Success	Conditions and controls were all satisfied	Nothing, this is the target state
Report-only: Failure	Conditions met, controls not satisfied	Investigate before enforcing, this would have blocked
Report-only: User action required	The user would have been prompted	Usually fine, confirm the prompt is reasonable
Report-only: Not applied	Conditions were not all met	Check the scope is what you intended
Success	Enforced policy applied and allowed the sign-in	Nothing
Failure	Enforced policy blocked the sign-in	By design, or a misconfiguration — check which
Not applied	The policy did not apply, for example the user was excluded	Confirm the exclusion is intentional

The three ways to read the results

Sign-in logs give you per-event detail: every event lists which policies were enabled, in report-only, applied or not applied, with a dedicated Report-only tab. Policy impact gives a snapshot of the effect on interactive sign-ins over the past 24 hours, 7 days or 1 month, visible to anyone with at least Security Reader, and it works on report-only policies too. The Conditional Access Insights and Reporting workbook lets you compare report-only and enforced results side by side for a chosen time range, set of applications and users; it needs Entra ID P1 and a Log Analytics workspace receiving sign-in logs.

How long to soak

Long enough to cover a full business cycle for the practice, which in accountancy means long enough to include the people who only appear at month end. A week catches the daily pattern. Ten working days catches the payroll run and the monthly management-accounts cycle. Our recommendation for the baseline below is a ten-day soak per wave, with an explicit review before each wave is enforced.

The technique that removes almost all the residual risk

Microsoft’s own advice for changing an existing enforced policy is the piece practices rarely adopt: before you modify an enforced policy, create a copy in report-only mode carrying your proposed changes, compare its results against the original, and only then update the live policy and delete the copy. It costs five minutes and it means no change to a working Conditional Access policy is ever made blind.

One structural limit to plan around: report-only mode does not evaluate policies that use the User actions scope, which is what policy 6 uses. Test that one with a pilot group instead.

A Thirty-Day Conditional Access Rollout Calendar

Here is the plan we run for a practice of around 30 to 50 people. It assumes one competent administrator and a partner who has agreed to be the pilot user, and it deliberately front-loads the preparation so that no week contains both a surprise and a deadline.

Day	Action	Done when
1	Create two break-glass accounts, register passkeys, place in EmergencyAccess group	Both accounts sign in from a clean browser
1	Configure severity 0 alerting on both accounts	A test sign-in produces an alert
2	Audit the 14 privileged roles, remove everyone who does not need them	Role list matches a written justification
2	Review Microsoft-managed policies, add the exclusion group, decide On or Off	No policy is left drifting in report-only by accident
3	Run the legacy authentication report on both sign-in log tabs	Every legacy client is named and owned
4	Create named locations: office IP ranges trusted, approved countries	Both locations resolve correctly in the What If tool
5	Build wave one, all four policies, in report-only	Four policies created, exclusions verified
6–9	Soak. Review report-only results daily	No unexplained Report-only: Failure rows
10	Enforce wave one. Communicate to staff the day before	Four policies On, IT provider briefed
11	Disable security defaults if still enabled	Toggle off, policies already enforcing
12	Build Intune compliance baseline, enrol a pilot device	At least one device shows Compliant
13	Build wave two, five policies, in report-only, Apple and Android platforms excluded on the compliance policy	Five policies created
14–19	Soak. Enrol the rest of the estate into Intune	Compliance above 90% of managed devices
20	Enforce wave two, remove the platform exclusions	Nine policies On
21	Review guest accounts, remove anyone whose engagement has ended	Guest list matches live engagements
22	If P2 is in place, build wave three in report-only, token protection scoped to a pilot group	Three policies created
23–29	Soak. Capture interactive and non-interactive logs for token protection	Pilot users report no disruption
30	Enforce wave three. Export the Conditional Access policy set to JSON and file it	Twelve policies On, documented

Policies enforced by day, thirty-day rollout (of twelve)

Day 10 — 4 of 12 enforced

Day 20 — 9 of 12 enforced

Day 30 — 12 of 12 enforced

Why the order matters

Wave one before wave two, because there is no point controlling devices while a legacy protocol is still open. Break-glass before everything, because it is the only step that cannot be done afterwards. Security defaults off only after wave one is enforcing, so the tenant is never unprotected. Intune compliance before the device policy, because Microsoft’s own warning says the Conditional Access policy will not work without it. Guest review before the guest policy, because it is cheaper to delete an account than to license and manage it.

The What If tool

Before enforcing each wave, run the What If tool against a real user, a real application and a real location. It tells you which policies would apply to that hypothetical sign-in and which would not, and it will also tell you whether any deprecated classic policies still exist in the tenant. Classic policies stopped enforcing after 10 July 2024 and depend on the retired Azure AD Graph service, so if the tool finds any, document their settings, rebuild them properly, and disable them — a classic policy cannot be re-enabled once disabled.

What Conditional Access Breaks in a Practice, and How to Handle It

No honest guide claims nothing breaks. Here is the list we actually encounter in accountancy practices, with the fix that does not involve weakening the Conditional Access policy.

What breaks	Which policy causes it	The fix that keeps the control
Multifunction printer scan-to-email	2, block legacy authentication	Move it to SMTP AUTH with a dedicated account, or to direct send
Old practice or tax software that sends email	2	Vendor update to modern authentication, or an approved relay
A shared mailbox opened with a password	1 and 2	Convert to a real shared mailbox with delegated access, no sign-in
Teams Rooms panel or meeting device	5, block device code flow	Scoped exception for the resource account only
A backup or sync script signing in as a user	1, 4 and platform enforcement	Migrate to a managed identity or service principal
Partner working from a villa in France in August	8, country block	Add the country temporarily, or use a break-glass-free travel group
Personal iPad used to read email	7, device compliance	Enrol it, or accept the MFA branch of the “or MFA” policy
Certificate for staff on macOS prompting repeatedly	7, in report-only	Exclude Apple platforms while in report-only, restore on enforcement
Client’s auditor cannot open the shared folder	10, guest MFA	Cross-tenant trust settings, or have them satisfy MFA at home
Excel or Power BI pulling from Exchange	Baseline security mode EWS setting, not Conditional Access	Check the EWS impact list before enabling that setting
Sign-in loop after tightening sessions	9 with reauthentication set to every time	Never use “every time” without MFA in the same policy
Unexpected prompts after enabling sign-in frequency	9 combined with “Remember MFA on trusted devices”	Disable the legacy remember-MFA setting first

The scan-to-email problem, specifically

This is the single most common blocker in a practice, and it is worth stating the answer plainly because it comes up in every rollout. A photocopier configured years ago with a mailbox username and password is using basic authentication. Blocking legacy authentication will stop it. The correct fix is to reconfigure the device for SMTP AUTH against a dedicated, licensed, tightly scoped account, or to use direct send or an SMTP relay connector, and then to remove that account’s ability to sign in interactively.

The wrong fix, which we still find in practices, is an exclusion on the block-legacy-authentication policy that quietly covers a general user account.

Communicate before you enforce, not after

Microsoft publishes communication templates and end-user documentation for exactly this, and staff can register their methods in advance at the security-info page. In a practice, send one email a week before each wave, hold a fifteen-minute session at the Monday meeting, and register everyone’s method for them during that session. A rollout where staff register on the day of enforcement generates ten times the support load of a rollout where they registered a week earlier, and it is the help desk that absorbs the difference.

Session controls are where well-meaning administrators do the most damage, because the instinct — ask people to sign in more often — is the opposite of Microsoft’s guidance and of the security evidence.

The default is 90 days, and that is deliberate

The Microsoft Entra ID default for user sign-in frequency is a rolling window of 90 days. Microsoft’s explanation is worth quoting because it changes minds in a partner meeting: “It might seem sensible to ask users for credentials often, but this approach can backfire. Users who habitually enter credentials without thinking might unintentionally provide them to malicious prompts.”

The default is stated as a principle: “don’t ask users to provide their credentials if the security posture of their sessions hasn’t changed.” And posture changes do revoke the session — a password change, a device becoming non-compliant, an account being disabled, or an administrator explicitly revoking sessions.

Where a shorter frequency is justified

Microsoft lists the scenarios where fresh authentication every time is appropriate: reaching sensitive applications, resources behind a VPN, privileged role elevation in Privileged Identity Management, sign-ins to Azure Virtual Desktop, risky users and risky sign-ins, and sensitive actions such as Intune enrolment. For a practice, that translates to a short sign-in frequency on the admin portals and on any application holding client money instructions, and the 90-day default everywhere else.

Two mechanical details matter if you do set a short frequency. On Entra joined and hybrid joined devices, unlocking the device refreshes the Primary Refresh Token every four hours, and the Conditional Access policy is measured against that timestamp, which is why a user who locks their machine at 00:30 and returns at 04:45 is prompted at 05:45 rather than 01:30. And selecting Every time builds in five minutes of clock skew, so nobody is prompted more often than once every five minutes.

The warnings, in Microsoft’s own words

“Triggering reauthentication too frequently can increase security friction to a point that it causes users to experience MFA fatigue and open the door to phishing.” And: “Using sign-in frequency to require reauthentication every time, without multifactor authentication might result in sign-in looping for your users.”

Before enabling sign-in frequency at all, disable Remember MFA on trusted devices in the legacy multi-factor authentication service settings. Using both together prompts users unpredictably, and the resulting support tickets get blamed on Conditional Access rather than on the leftover setting.

Browser persistence

The persistent-browser control is the more useful of the two for a practice, because it is narrowly targeted and nobody on a managed device notices it. Set browser persistence off for sessions from devices that are not compliant and not hybrid joined, and leave the Stay signed in? prompt alone for everyone else. Whether users see that prompt at all is controlled separately, in the company branding pane.

Setting	Microsoft default	Our recommendation for a practice
User sign-in frequency, general staff	Rolling 90 days	Leave at the default
Sign-in frequency, admin portals	Rolling 90 days	Short, time-based, or PIM reauthentication
Reauthenticate every time	Off	Only with MFA in the same policy, on few apps
Browser persistence, managed devices	User chooses	Leave as is
Browser persistence, unmanaged devices	User chooses	Off, via policy 9
Remember MFA on trusted devices	Legacy setting, may be on	Disable before using sign-in frequency
Configurable token lifetime	Retired 30 January 2021	Do not use alongside session controls

Conditional Access and Continuous Access Evaluation

Continuous access evaluation is the feature that makes the 90-day default defensible, and every practice should know it is there because it answers the obvious objection: what happens between sign-ins?

What it does

Access tokens are normally valid for one hour, and historically nothing could be done until they expired. Continuous access evaluation creates a two-way conversation between Microsoft Entra and the resource so that the resource can be told to stop honouring a token. Microsoft’s target is “near real time”, with “latency of up to 15 minutes” for event propagation, while “IP locations policy enforcement is instant”.

The five critical events

User account deleted or disabled; password changed or reset; multi-factor authentication enabled for the user; an administrator explicitly revoking all refresh tokens; and high user risk detected by Microsoft Entra ID Protection. Critical event evaluation does not depend on Conditional Access policies at all, so it works in any tenant. SharePoint Online is the one exception: it does not support user risk events.

Why tokens get longer, not shorter

In sessions negotiated with a capable client, token lifetime “increases to long-lived, up to 28 hours”, because revocation is driven by events rather than by expiry. Without capable clients, the default access token lifetime remains one hour. For a practice, the leaver process is the practical consequence: disabling a departing employee’s account now removes their access to mail, files and Teams within minutes rather than up to an hour.

The limits worth knowing before you rely on it

Changes to Conditional Access policies and to group membership “could take up to one day to be effective”, with optimisation reducing that to two hours in some cases; to apply a change immediately, revoke the user’s sessions explicitly.

Continuous access evaluation only understands IP-based named locations, not country or region locations, so if you want location enforcement in real time, use IP ranges and include both IPv4 and IPv6.

If the total of all IP ranges in your location policies exceeds 5,000, real-time location enforcement stops and a one-hour token is issued instead. Guest accounts are not supported. And re-enabling a disabled user takes roughly 15 minutes to propagate to SharePoint and Teams, and 35 to 40 minutes to Exchange Online.

What Conditional Access Costs a 34-Person Accountancy Practice

Worked properly, this is a much smaller number than partners expect, because most of the capability is already paid for.

The practice

Take a two-office practice with 34 named staff: 6 partners and directors, 15 qualified and part-qualified accountants, 5 tax specialists, and 8 payroll and administrative staff. Add 9 shared mailboxes and 4 service or administrative accounts, and the tenant holds 47 identities, of which 13 are not a single named human being. The estate is 34 laptops, 21 mobile devices and 3 meeting-room devices, so 58 devices in total.

What the twelve policies cost

Waves one and two, nine of the twelve policies, cost nothing beyond the existing Business Premium licences. At £16.90 per user per month, 34 users is £574.60 per month, or £6,895.20 per year, which the practice is already paying. That is £202.80 per person per year for the whole Microsoft 365 stack, of which the Conditional Access engine is one included component.

Wave three needs Entra ID P2. Buying it through the Microsoft Defender Suite add-on at £7.70 per user per month costs 34 × £7.70 = £261.80 per month, or £3,141.60 per year — £92.40 per person per year. Total identity and security spend becomes £836.40 per month, £10,036.80 per year, or £295.20 per person per year.

Put in proportion

That £3,141.60 annual increment is £12.47 per working day across a 252-day year. The Information Commissioner’s Office penalty of £60,000 issued to DPP Law is more than 19 years of that spend. And the same £7.70 that buys Entra ID P2 on its own buys the whole Defender Suite when purchased as the Business Premium add-on, which is why we rarely recommend the standalone route.

Annual licence cost for 34 staff, four routes, scaled to the E5 figure

Business Premium only — £6,895.20

Business Premium plus Defender Suite — £10,036.80

Microsoft 365 E3 — £13,668.00

Microsoft 365 E5 — £21,052.80

The cost that is not licensing

The real cost of a Conditional Access rollout is time, and it is front-loaded. The thirty-day calendar above is roughly three to four days of administrator effort in total, plus a fifteen-minute session with staff before each wave, plus a standing fifteen minutes a quarter for the break-glass drill. Practices that try to compress it into a weekend generate more support load in the following fortnight than they saved.

The cost of not doing it

A practice that is breached spends its money on incident response, forensic investigation, notification to the Information Commissioner’s Office within 72 hours, client communication, professional indemnity excess, and the partner time that all of that consumes. Conditional Access is not insurance against that, but it removes the entry route that the overwhelming majority of these incidents use.

Proving It: Conditional Access Evidence for Cyber Essentials, Insurers and Clients

Configuring the Conditional Access policies is half the job. In a regulated practice, being able to demonstrate them is the other half, and it is the half that gets forgotten until a questionnaire lands.

Cyber Essentials

The current Cyber Essentials question set requires multi-factor authentication on cloud services, and weak or absent multi-factor authentication is an automatic fail rather than a point deduction. A Conditional Access policy requiring MFA for all users, screenshotted with its assignment, its control and its enabled state, is the cleanest possible answer to that question. Our Cyber Essentials guide for accountancy firms covers the full question set.

What to capture, and when

Evidence	Where it comes from	How often
Policy list with names, states and Created by column	Conditional Access, Policies page	Quarterly, and after every change
JSON export of each Conditional Access policy definition	Template export or Microsoft Graph	On every change
Coverage tab showing applications with no policy	Conditional Access, Overview	Monthly
Policy impact snapshot per policy	Policy impact tab	Before and after each change
Audit log filtered to the Conditional Access service	Monitoring & health, Audit logs	Quarterly review, exported
Break-glass drill record	Sign-in logs plus the alert	Every 90 days
Privileged role membership list	Roles and administrators	Quarterly
Guest account review	Users, filtered to guests	Quarterly
Legacy authentication report showing zero	Sign-in logs workbook	Monthly for the first quarter, then quarterly

Watching for Microsoft’s own changes

Microsoft-managed policies change without you doing anything, so include a check for that in the quarterly review. Administrators with the right permissions can query the audit log for entries initiated by Microsoft Managed Policy Manager in the Policy category, which returns exactly the set of changes Microsoft made. Managed policy names begin with Microsoft-managed:, so they filter cleanly.

The client questionnaire answer

When a client’s procurement team asks how you control access to their data, the answer is no longer a paragraph of intent. It is: twelve named policies, all enforced, break-glass accounts excluded and drilled quarterly, multi-factor authentication required for every user on every application, phishing-resistant methods required for administrators, legacy protocols blocked, and sign-in evidence retained. That is a materially better answer than most practices of this size can currently give.

Naming, Documentation and Change Control for Conditional Access Policies

Microsoft’s guidance in every Conditional Access policy walkthrough includes one line that is easy to skim past: “Create a meaningful standard for the names of your policies.” In a twelve-policy estate that is not bureaucracy, it is the difference between a five-minute diagnosis and an hour of clicking.

A naming convention that works

Use a scheme that encodes sequence, target, action and state: CA01-AllUsers-RequireMFA, CA02-AllUsers-BlockLegacyAuth, CA03-Admins-RequirePhishResistant, and so on up to CA12. Number them so the wave order is visible in the list, name the population second so you can see the blast radius at a glance, and name the control third.

Document four things per Conditional Access policy

The business reason it exists, the person who owns it, the exclusions and why each one is justified, and the date it was last reviewed. Four lines per policy is twelve short paragraphs for the whole estate, and it fits in the practice’s information security policy as an appendix. Every exclusion should carry an expiry date, because the exclusion granted for the old scanner in March is still there in November unless somebody wrote down when to remove it.

Change control

Export each Conditional Access policy’s JSON definition and keep it with the documentation. Templates can be exported to JSON and re-imported using Upload policy file, which means a policy set can be version-controlled and rebuilt. Before any change to an enforced policy, build the report-only copy first. After any change, capture the audit-log entry. This is the same discipline a practice already applies to a client’s accounts file; it is unfamiliar only because it is being applied to identity.

Ten Conditional Access Mistakes We Keep Finding in Practices

1. No break-glass accounts at all

By far the most common. The practice has policies, they work, and there is no route back if the multi-factor authentication provider or the Conditional Access policy itself fails. Two cloud-only accounts with passkeys, held in two safes, fixes it in an afternoon.

2. Break-glass accounts that are also somebody’s admin account

An emergency account that shares a person, a device or an authentication method with a normal admin account is not an emergency account. Microsoft is explicit that the method must differ from the one your regular admin accounts use.

3. Excluding a real user “temporarily”

The exclusion for the partner who was travelling in April is still there. Exclusions need an owner and an expiry date, and the quarterly review needs to check them.

4. Leaving Microsoft-managed policies to enable themselves

They will switch on after 30 days in report-only. Deciding deliberately is free; being surprised is not.

5. Running security defaults and thinking it is Conditional Access

It is not, it cannot be tuned, and it cannot be evidenced with the same specificity. If the practice has Business Premium, the premium capability is already paid for.

6. Blocking legacy authentication without checking the non-interactive log

The interactive sign-in log looks clean and the scanner sits in the non-interactive tab. Check both tabs before enforcing.

7. Requiring a compliant device before Intune compliance exists

Microsoft’s warning could not be plainer, and yet this is a regular cause of a locked-out practice on a Monday morning.

8. Setting sign-in frequency to something aggressive

Ninety days is the researched default. Shortening it estate-wide increases phishing susceptibility through prompt fatigue, which is the opposite of the intent.

9. Using country blocking as the primary control

It filters noise. It does not stop a determined attacker with a UK exit node, and a practice that treats it as the main defence has misread what it does.

10. Never reviewing the Conditional Access policy set again

Microsoft changes the product, the practice changes its people, and a Conditional Access policy set that was correct in March is stale by September. Put the quarterly review in the diary alongside the break-glass drill.

Frequently Asked Questions About Conditional Access

Do we need Conditional Access if we already force multi-factor authentication?

Almost certainly yes. Per-user multi-factor authentication is a configuration Microsoft “no longer recommends”, and it cannot express any of the conditions that make Conditional Access useful: device state, location, application, risk, session behaviour. Microsoft even ships a managed policy specifically to migrate tenants with fewer than 500 per-user MFA accounts across to Conditional Access.

Will Conditional Access work with our third-party multi-factor authentication provider?

Yes, through external authentication methods, which satisfy the MFA requirements of Microsoft-managed policies. Two caveats: external authentication methods are currently incompatible with the authentication strength control, so use the plain grant control instead; and the legacy custom controls preview does not satisfy the requirement and should be migrated.

Does Conditional Access apply to Microsoft Graph or only to Azure?

The Conditional Access policies you write apply to whichever resources you target. Microsoft’s separate mandatory MFA enforcement is narrower: only requests to the Azure Resource Manager endpoint are in scope, and “generally, Microsoft Graph APIs aren’t in scope for Azure MFA enforcement”.

Are service accounts covered?

Not by a user-scoped policy. Calls made by service principals “aren’t blocked by Conditional Access policies scoped to users”; you need Conditional Access for workload identities, which is a separate licence. The better answer for a practice is to replace user accounts used as service accounts with managed identities, which is what Microsoft recommends and what the mandatory MFA enforcement now effectively requires.

What happens to a Conditional Access policy if we downgrade our licences?

Policies are not deleted or disabled. You can view and delete them but not update them, which Microsoft describes as a “graceful state” allowing migration away without a sudden change in posture.

Can we test a Conditional Access policy on one person before rolling it out?

Yes, and you should. Assign the Conditional Access policy to a pilot security group rather than All users, verify the behaviour, then widen the assignment. For anything using the User actions scope, this is the only way to test it, because report-only mode does not evaluate that scope.

How quickly does a Conditional Access policy change take effect?

For the sign-in itself, immediately. For services that have synchronised the policy, such as Exchange Online and SharePoint Online, changes to policies and group membership “could take up to one day”, optimised to two hours in some cases. Revoke the user’s sessions if you need it applied now.

Do we still need Conditional Access if we use passkeys everywhere?

Yes. Passkeys satisfy the strongest authentication strength, but Conditional Access is what requires them, what blocks the legacy protocols that bypass them, what stops a stolen token being replayed on another device, and what evidences all of it. The strength is the method; the policy is the enforcement.

Is there anything that will build the policies for us?

The Conditional Access Optimization Agent, part of Microsoft Security Copilot, suggests new policies and changes to existing ones based on Zero Trust principles, creates its suggestions in report-only mode, and supports a phased rollout. It needs at least Entra ID P1 plus provisioned security compute units, so it is not present in most practice tenants, but it is worth knowing it exists before someone tells you it is the only way.

What is the very first thing to do on Monday morning?

Open the Conditional Access Overview page and look at two things: how many policies are enabled versus report-only, and which applications the Coverage tab says have no policy at all. Those two numbers tell you, in about ninety seconds, whether your practice is protected by design or by luck.

Conditional Access: The Short Version for a Partner Meeting

Conditional Access is already included in the Microsoft 365 Business Premium licences the practice pays for. Twelve policies, built in three waves over thirty days, cover identity, protocols, privilege, devices, geography, sessions, guests, risk and token theft. Nine of the twelve cost nothing extra. The remaining three need Entra ID P2, which for a 34-person practice is £3,141.60 a year, or £12.47 a working day.

The prerequisites are two break-glass accounts and an honest inventory of what still uses old protocols. The method is report-only first, always. The evidence is a named policy set with an owner, a review date and an audit trail, which is exactly what clients, insurers and Cyber Essentials assessors are asking for. If your practice is running security defaults, or per-user multi-factor authentication, or nothing at all, this is the highest-return security project available to you and most of it is already bought and paid for.

If you would like help building the policy set, testing it in report-only and evidencing it afterwards, our IT support for accountancy firms service does exactly this work for UK practices.