Attackers Read Your Conditional Access Policies Better Than You Do

Somewhere in one of your tenants is an exclusion added eighteen months ago to unblock a migration. Nobody documented it, nobody reviewed it, and the service account it exempts from MFA still works. That is the kind of gap an attacker probing your Conditional Access posture finds in minutes, because they evaluate policies the way you rarely get time to: looking for what is absent.

Conditional Access remains something most of us either struggle with or implement with extreme inconsistency across customer environments, and most environments carry significant security holes from misconfiguration or an incomplete grasp of policy scope. This post breaks down why that happens, the attacks that exploit it, our recommended 16-policy baseline, and the automation that keeps the baseline true over time.

Why competent MSPs still ship weak policies#

No shade intended here, and no claims of Conditional Access mastery either. Conditional Access is complex, and four forces work against you:

The scope never stops moving. Your ideal target state shifts constantly, both because the threat landscape changes and because Microsoft keeps adding settings to the policy surface. Signing in to find a configuration option you have never seen before is a regular experience.

Every client environment is unique. A single baseline deployed identically everywhere would be ideal. Reality intervenes through hybrid versus cloud-native identity, LOB apps, on-prem file shares, office versus remote workforces, geographic footprint, regulatory requirements (hospitals, schools), and operational maturity: is MFA enforced, are devices in Intune, is compliance enforced, what MFA method is in play, zero trust or secure perimeter?

Exclusions accumulate without change management. Over time, changes and exclusions pile up to clear operational blockers, the classic being a user or service account exempted from MFA because it broke something. Without a formal change process, documentation, or periodic review, that drift from your compliant policy goes undetected.

The time never gets invested. Microsoft produces plenty of things that waste MSP time (NCE, cough cough). Conditional Access is not one of them. If you rank the highest-impact actions available for shrinking your attack surface, strong Conditional Access policies sit at or near the top of the list.

The attacks your policy set will be graded against#

The full catalog of attack vectors would outrun any single post, but five common in-the-wild patterns set the bar.

Credential phishing#

Brute force, password spray, or a phishing page disguised as a legitimate site: however the credentials leak, the attacker walks in with a username and password. Enforcing MFA is the standard counter.

Adversary-in-the-middle (AiTM) phishing#

Tools like Evilginx2 go beyond credential theft by placing hostile infrastructure between the user and the real application. The phished user hands over credentials and the session token carrying the MFA claim, compromising the account even where MFA is enforced. Elliot demonstrates it well here: How hackers are breaking into MFA enabled Microsoft 365 accounts (opens in new tab).

For a real-world case, see this thread where a user running MFA with number matching was still compromised: User Compromised When MFA (Number Matching) In Use, r/msp (opens in new tab).

Pass-the-cookie#

Web applications store authentication state in browser cookies so users are not re-prompted on every page. Pass-the-cookie is the cloud cousin of pass-the-hash and pass-the-ticket in Active Directory: an attacker who compromises a device lifts the Microsoft 365 session cookie and replays it in a browser on another system, skipping authentication controls entirely. No password, not even the email address, is required; the cookie carries everything. Users on personal devices are especially vulnerable.

QR-code phishing#

QR codes earned legitimate popularity over the last few years, partly through COVID, and became one of the fastest growing email attack types in the process. A QR code redirects victims to malicious sites or malware exactly the way a URL does, just from a location your detection stack struggles to inspect. Here is a phishing email impersonating DocuSign with a QR code:

Persistence#

After compromise by any of the above, attackers move to stay in: binding a new device to the account to satisfy future MFA prompts, adding a fresh MFA method like Authenticator in the security settings, or joining new devices to the tenant where nothing prevents it.

The 16-policy baseline, grouped by what each defends#

A caveat before the list: every environment differs, and deploying these does not make a tenant fully protected. These are the baselines we work to implement in all tenants, grouped here by defensive job.

Identity floor: MFA everywhere it counts#

Require MFA for all users. (Microsoft guidance (opens in new tab)) The non-negotiable, enforced in every location. We are not fans of excluding trusted locations from this policy: train users that MFA happens wherever they are. Counters basic credential phishing.

Require MFA for admins. (Microsoft guidance (opens in new tab)) A backup to the all-users policy for when drift adds exclusions. Admin roles should not belong to everyday accounts signing in to email; they should be service accounts bound to a separate credential pair.

Require MFA for guest users. (Microsoft guidance (opens in new tab)) Guests fall outside security standards by default. An MFA-less guest is a short path to data loss or a convincing social engineering run against your internal users.

Require MFA for Azure management. (Microsoft guidance (opens in new tab)) Another deliberate redundancy. We are extra protective of this surface given what a hijacked Azure subscription costs, crypto-mining being the classic example.

Require MFA to join or register devices. (Guidance (opens in new tab)) Stops compromised accounts from binding rogue devices for persistence. Caveat: a brand-new user with no MFA registered who joins a device out of the box needs a Temporary Access Pass to satisfy the requirement.

Phishing-resistant and flow controls#

Require phishing-resistant MFA for admins. (Microsoft guidance (opens in new tab)) Phishing-resistant MFA for every user in every company is the goal and not yet a realistic one. The achievable interim: enforce FIDO2 keys or Windows Hello for admins and high-profile users. Start with Global Administrators and expand.

Block authentication flows. (Microsoft guidance (opens in new tab), background on the technique (opens in new tab)) The device code flow gives attackers another QR-code route: the victim signs in at a legitimate Microsoft URL while the attacker captures the access and refresh tokens through the flow.

Location and legacy controls#

Require strict location continuous access evaluation. (CAE (opens in new tab), strict enforcement (opens in new tab)) Strictly enforced trusted locations are the counter to AiTM and pass-the-cookie: a stolen token or cookie replayed from outside a trusted location is blocked immediately, instead of surviving the default one-hour token lifetime that ordinary CAE tolerates.

Block unapproved countries. (Microsoft guidance (opens in new tab)) Limits exposure when credentials or tokens leak, and shuts down the persistence scenario when the attacker operates from a country off your list (US only, for instance). Pair it with an easy "travel exception" request path so legitimate travelers are handled proactively.

Block legacy authentication. (Microsoft guidance (opens in new tab)) Single-factor legacy protocols have no place in the tenant. Do not let printers and scanners justify broad legacy auth holes; Microsoft documents the right way to handle multifunction devices (opens in new tab).

Risk-based controls (Entra ID P2)#

Block high-risk users, and block high-risk sign-ins. (High-risk users (opens in new tab), high-risk sign-ins (opens in new tab)) We create these as two separate policies for cleaner tracking in the sign-in logs. Some configure self-service password reset on high risk; we prefer the cautious route of blocking outright so the account gets a proper investigation. Both require Entra ID P2 licensing.

Device trust#

Require managed devices for sign-in. (Guidance (opens in new tab)) Personal and unenrolled devices lack your AV, EDR, and other protections, making their users far easier to breach. Requiring managed devices counters both account compromise and persistence.

Require compliant devices. (Guidance (opens in new tab)) One of the strictest policies available and one of the most protective. We treat it as the minimum for regulated clients.

Sessions and mobile#

Limit browser sessions for privileged users. (Guidance (opens in new tab)) Less critical if strict location CAE is in place, but Global Admin browser sessions should cap at an hour to shrink the window on devices where an admin stays signed in. Some recommend this for all users; we find that creates far too much user friction and is a fast way to anger customers.

Require app protection policies on mobile. (Grant control (opens in new tab), policy guidance (opens in new tab)) For corporate data on personal phones: encryption, save-as and cut-copy-paste restrictions, and remote wipe of the app's corporate data without touching the rest of the phone.

Require approved client apps on mobile. (Guidance (opens in new tab)) Keep users out of native mail clients and inside the store-distributed Microsoft apps where app protection policies apply.

Deployment discipline beats policy count#

• Start in report-only. Watch the end-user impact and communicate proactively instead of flipping policies on blind.
• Name policies identically in every tenant. Consistent naming is what makes cross-tenant reporting and gap discovery possible later. Append a marker like (NA) to baseline policies a tenant cannot enforce yet, whether for licensing or environmental reasons.
• Use deployment rings. Treat CA policies like patches: a beta-tester group first, then wider. Report-only mode does not surface everything, and champions in the early ring supply the messaging feedback that prevents helpdesk floods.
• Reduce the decisions you have to make. Some allowances explode policy complexity, personal-device access being the prime example. For us, no personal devices is a non-negotiable, and it removes a large slice of the policies we would otherwise need. Define core principles that shrink the configuration space.

Conditional Access as code#

Managing CA policies as code has been possible for years, with adoption held back mostly by the technical barrier to entry. The goal: configure, deploy, and monitor policies across customers automatically, to ensure proper change control, detect drift, and avoid the human-error misconfigurations that created the gaps in the first place. Two open source projects worth your time:

• AlexFilipin/ConditionalAccess (opens in new tab) deploys a set of policies, your baseline, into a tenant easily. A great way to land your baseline in report-only mode during customer onboarding.
• Azure-Samples/azure-ad-conditional-access-apis (opens in new tab) manages the full policy lifecycle: build, deploy, and back up policies in tenants, including an Azure Logic App pattern for working approvals into the workflow.

Reporting across every customer#

We also built a script that reports on all Conditional Access policies across your customers (opens in new tab), using your GDAP relationships for the permissions to pull everything in one pass. Output is a CSV of every policy and its settings across customers:

Prerequisite: the Secure Application Model must be configured in your environment, set up as described in My Automations Break with GDAP: The Fix!.

One more script worth running: discover licensed users excluded from MFA-enforcing CA policies (opens in new tab). Those exclusions are exactly where this post started.

The eight-step adoption plan#

1. Document the Conditional Access policies in your customer environments as they exist today.
2. Define your MSP-approved baseline, using the naming conventions above so future reporting can find deployment gaps.
3. Test the baseline in your internal tenant.
4. Update customer environments to match, leaving policies you cannot enable yet in report-only mode.
5. Build a project plan from the gaps to enable CA across all customer environments.
6. Stand up formal change management for the baseline lifecycle: at minimum, how new policies and updates get submitted and approved, and how often the baseline gets reviewed (quarterly or semi-annually).
7. Document every deviation, exclusion, and exception per customer.
8. Make baseline deployment a formal step in customer onboarding.