In almost every M365 security assessment I’ve been involved with, the same gaps appear. Missing or misconfigured Conditional Access is near the top of the list, consistently. Not because organisations don’t know it exists — they do — but because the default M365 tenant comes with Security Defaults enabled, and organisations mistake that for a Conditional Access strategy.
It isn’t.
What Security Defaults actually give you
Security Defaults, introduced by Microsoft in 2019 as a baseline, enable:
- MFA registration requirement for all users
- MFA enforcement for administrators always
- MFA enforcement for all users “when necessary” (which Microsoft defines, not you)
- Blocking of legacy authentication protocols
This is meaningfully better than nothing. Legacy auth blocking alone removes a large category of brute-force and password-spray attack vectors. But Security Defaults are a blunt instrument. You get no control over scope, no risk-based conditions, no named location exclusions, and no device compliance integration.
Why Conditional Access changes the equation
Conditional Access is the policy engine that lets you express: “under these conditions, require this control.” The conditions include:
- Who: specific users, groups, roles
- What: specific applications, all cloud apps
- Where: named locations, countries, IP ranges
- How: device compliance state, client app type, sign-in risk level (if you have P2)
- When: using real-time risk signals from Entra ID Protection
The controls you can require include MFA, compliant device, hybrid joined device, approved client app, or simply blocking access entirely.
This means you can say: any sign-in from outside our known network to Exchange Online from a non-compliant device requires MFA and a compliant device, and any sign-in that Entra ID flags as high-risk requires a password reset regardless of device state.
Security Defaults cannot say any of that.
Where organisations go wrong
Over-relying on the “require MFA for admins” policy. Admin accounts should have CA policies, but so should every user account. User accounts are compromised far more frequently, and a compromised user account with an assigned licence gives an attacker access to email, SharePoint, Teams, and OneDrive.
Ignoring legacy authentication. Even with Security Defaults enabled, I’ve seen organisations re-enable legacy auth for specific service accounts or shared mailboxes because it was “easier.” Every legacy auth enabled endpoint is a vector that bypasses MFA entirely.
No named locations defined. If you don’t define your trusted locations, you can’t write policies that treat on-premises traffic differently from anonymous proxy traffic. Named locations take twenty minutes to configure and enable a whole category of useful policy conditions.
No device compliance policy. Conditional Access can require that devices are Intune-compliant before access is granted. Without a compliance policy defined in Intune, all devices pass the compliance check by default — which means the CA policy condition does nothing.
A minimum viable Conditional Access posture
If you’re starting from Security Defaults and want to move to Conditional Access without disrupting your organisation, a reasonable starting point:
- Disable Security Defaults — you can’t use CA and Security Defaults simultaneously.
- Enable MFA for all users — a broad CA policy requiring MFA for all users on all cloud apps, with a named location exclusion for your trusted corporate network if needed.
- Block legacy authentication — a policy blocking all legacy auth client types.
- Require MFA (always) for all administrator roles — no location exclusions, no device condition as a bypass.
- Enable Entra ID Protection (if licensed) and create sign-in risk and user risk policies.
This is the floor. From there, you build more specific policies as you understand your user behaviour and application estate better.
The monitoring gap
Conditional Access is only as useful as the logging you have around it. Entra ID sign-in logs, available in the portal and streamable to Sentinel, show every CA policy evaluation. A policy set to “report-only” will log what it would have blocked without blocking anything — use this for testing before enforcement.
Don’t enable CA policies in enforcement mode without first running them in report-only for two to four weeks and reviewing the logs. Every time I’ve seen an organisation skip this step, they’ve had a disruption to legitimate access.
More on Entra ID Identity Protection and risk-based Conditional Access in a future post.