M365 Security Defaults Are Not Enough: The Conditional Access Baseline Every MSP Should Deploy
When a new M365 tenant gets created, Microsoft turns on Security Defaults automatically. It's free, it requires no configuration, and it covers roughly 40% of what your clients assume "we have MFA" actually means.
Most MSPs leave it on. Not because it's the right call, but because replacing it means an Entra ID P1 conversation, a licensing delta, and client pushback about MFA friction. So it sits there, giving everyone just enough confidence to not ask questions.
This post fixes that. Five policies, the licensing math, how to deploy them without triggering a support storm, and where this connects to HIPAA and CMMC requirements your clients have to meet.
What Security Defaults Actually Give You
Microsoft's own docs call Security Defaults "basic identity security mechanisms." That phrasing is doing a lot of work.
With Security Defaults on, Microsoft does the following for the tenant:
- Requires all users to register for MFA
- Requires admins to complete MFA on every sign-in
- Blocks legacy authentication protocols
- Challenges users for MFA when its risk engine flags the sign-in
That last point is the one that trips people up. Under Security Defaults, Microsoft decides when to prompt for MFA, not you. A user logging in from the same location every morning might go weeks without a challenge. Microsoft's risk engine trusts the pattern and skips it. You have no visibility into when that logic fires or why.
The actual gaps:
No exclusions. You can't carve out a break-glass admin, a service account, or a user running a legacy integration. Security Defaults is all-or-nothing for the whole tenant.
No device requirements. A personal phone with no MDM enrollment can access SharePoint and OneDrive without issue.
No session controls. Persistent authenticated sessions stay persistent. Indefinitely.
No named locations. You can't trust the client's office IP range or block sign-ins from countries they've never done business in.
No risk signals. An impossible travel sign-in (New York at 9am, London at 9:10am) looks clean to Security Defaults.
Security Defaults isn't wrong. It's appropriate for a three-person shop with no compliance requirements, no sensitive data, and no time to think about policy design. For clients where any of those conditions don't hold, you need something better.
The Licensing Question
Conditional Access requires Microsoft Entra ID P1. Here's where you get it:
- Microsoft 365 Business Premium (~$26/user/month), includes Entra ID P1, Intune, and Defender for Business
- Microsoft 365 E3, includes Entra ID P1 plus the full enterprise stack
- Microsoft Entra ID P1 as a standalone add-on (~$6/user/month on top of Business Standard or Basic)
Most SMB clients are on Business Standard ($12.50/user/month) or Business Basic ($6/user/month). Neither includes Conditional Access.
For clients under 25 seats with no compliance requirements, the P1 add-on at $6/user is usually the right call. For clients with HIPAA or CMMC obligations, push for Business Premium. The bundle gives you Defender for Business and Intune, both of which you need anyway for compliant device policies.
Clients need to know: Security Defaults and Conditional Access cannot coexist. Creating your first CA policy disables Security Defaults. That means your baseline CA policies need to replicate what Security Defaults was doing, plus fill the gaps. Don't go dark on any of it.
5 M365 Conditional Access Policies Every MSP Should Deploy
Every client with Entra ID P1 should have these five running before you touch anything more granular.
1. Require MFA for All Users
All users. All cloud apps. All platforms. Enable number matching in Authenticator to block MFA fatigue attacks. Exclude your two break-glass admin accounts (covered below in deployment).
The friction objection is real but manageable. Microsoft Authenticator with number matching takes three seconds per sign-in. The key is getting users registered before you enable enforcement. Don't skip the registration push.
2. Block Legacy Authentication
Block all legacy auth client types: Exchange ActiveSync, Other clients (SMTP AUTH, POP3, IMAP, MAPI). Target all users, all apps. No exceptions.
This is the single highest-value policy you can deploy. Microsoft reports that 97% of password spray attacks target legacy authentication, because these protocols don't support MFA. You can have MFA enforced everywhere and still be completely exposed if legacy auth is open, because attackers bypass MFA entirely through those channels.
The one gotcha: multi-function printers and scan-to-email devices often use SMTP AUTH. Find those before you block. Either move them to a service account with modern auth or build a narrow device exclusion.
3. Require MFA for Admin Roles
Yes, "Require MFA for all users" technically catches admins too. Run a separate admin policy anyway. Scope it to: Global Administrator, Privileged Role Administrator, Security Administrator, SharePoint Administrator, Exchange Administrator, Conditional Access Administrator. If the client has hardware keys, require phishing-resistant MFA (FIDO2). At minimum, Authenticator with number matching.
Admins get targeted specifically. Separate policy means separate logging, separate controls, and easier auditing when something goes wrong.
4. Require Compliant Device for Sensitive Apps
Block access to SharePoint, OneDrive, and Exchange from devices not enrolled in Intune and marked compliant. This requires Intune, which is another reason Business Premium is worth it for data-sensitive clients.
For clients not ready for full device management (BYOD-heavy environments, no MDM rollout yet), use the app-only fallback: require an approved app with an app protection policy applied. It's weaker than full device compliance, but it blocks browser access from random personal devices while you work toward full Intune enrollment.
5. Named Locations and Sign-In Risk
Create named locations for each client's office IP ranges. Use those to build context: require MFA for sign-ins outside trusted locations. If the client doesn't operate in specific regions, block sign-ins from there. This is quick to configure and catches a meaningful slice of account takeover attempts.
Clients on E3 or E5 get Entra ID P2 and can add identity protection sign-in risk policies on top: automatically block high-risk sign-ins or require step-up authentication when Microsoft's threat intelligence flags something unusual.
The Three Objections (And What to Say)
"My team can't deal with MFA friction." Number matching in the Authenticator app takes three seconds. If the real concern is workflow disruption, deploy the policies in report-only mode for two weeks first. You can show clients exactly which sign-ins would have been challenged, what would have been blocked, and how many users would have been affected, before a single person gets a prompt.
"We're too small to be targeted." Password spray attacks are automated. They don't select targets based on size; they run against credential lists from prior breaches and try each one across thousands of tenants. Small businesses have real data, slower incident response, and less security, which makes them easier wins than enterprise targets. The attack doesn't care that the company has 12 employees.
"It'll break something." It might. That's exactly what report-only mode is for. Run every policy in that mode first, run it for at least two weeks, then review the sign-in logs under Conditional Access in the Entra admin center. Find the service accounts, the shared mailboxes running on legacy protocols, the printer nobody documented. Fix or exclude those before you flip to enforced.
The Compliance Connection
For clients with HIPAA obligations, Conditional Access isn't a best practice recommendation. It's a technical safeguard requirement.
HIPAA 164.312(d) requires entity authentication, verifying user identity before granting access to electronic protected health information. Security Defaults' conditional, risk-based MFA prompting doesn't reliably satisfy that requirement. A CA policy requiring MFA on every sign-in to Exchange and SharePoint does. See the full breakdown in our HIPAA compliance guide for MSPs.
CMMC 2.0 Level 2 includes IA.L2-3.5.3: multi-factor authentication for network access to privileged accounts. Level 2 also requires IA.L2-3.5.4: replay-resistant authentication. Legacy authentication passes replayed credentials. An organization cannot achieve CMMC Level 2 with legacy auth protocols open. More detail on building a profitable compliance motion is in our MSP compliance pricing guide.
If you have HIPAA or CMMC clients running Security Defaults today, that's not a yellow flag in a report. It's a gap with a remediation timeline.
Scopable's comparison resources and MSP compliance services help teams turn these findings into a client-ready plan. If you want this baseline packaged into your own workflow, join early access.
Deploying This Without a Support Call Storm
Follow this sequence. Skip steps at your own risk.
Step 1: Create break-glass accounts first. Two cloud-only global admin accounts, excluded from all CA policies. Long random passwords stored offline, printed and kept in a physical safe, or in a password manager with no SSO dependency. Enable MFA on these manually via the per-user MFA settings page. These are your recovery accounts if something breaks.
Step 2: Set every new policy to report-only. Do not touch enforced mode yet.
Step 3: Run for two weeks. Check sign-in logs in the Entra admin center under Monitoring > Sign-ins, filtered by Conditional Access. Look for service accounts, shared mailboxes, any client flagged as a legacy authentication client.
Step 4: Fix the exceptions. Either migrate to modern auth, create a service principal with certificate auth, or build the minimum-scope exclusion. Document everything.
Step 5: Enable Block Legacy Auth first. Lowest user friction, highest security gain. This is the one that closes the door on 97% of spray attacks.
Step 6: Enable MFA for All Users. Make sure users have registered Authenticator before you flip this to enforced. A registration campaign one to two weeks before enforcement saves a lot of helpdesk calls.
Step 7: Enable the remaining policies in sequence. One per week if the client is anxious. Watch the support queue after each one. The device compliance policy usually generates the most friction, so save it for last and build Intune enrollment alongside it.
FAQ
What's the difference between Security Defaults and Conditional Access in Microsoft 365?
Security Defaults is Microsoft's free, automatic baseline. It turns on MFA requirements for users and admins, and blocks some legacy authentication. Conditional Access is a policy engine that requires Entra ID P1 and lets you define precise rules: who, what app, what device, what location, what risk level, what authentication strength. Security Defaults is on or off for the whole tenant. Conditional Access gives you granular control and the ability to exclude specific accounts, trusted locations, and compliant devices.
What Microsoft 365 license do you need for Conditional Access?
Microsoft Entra ID P1 is required. It's included in Microsoft 365 Business Premium (~$26/user/month), M365 E3, and M365 E5. It can also be added as a standalone add-on for around $6/user/month on top of Business Standard or Business Basic.
What are the most important Conditional Access policies for MSPs to deploy?
Five policies form the non-negotiable baseline: (1) require MFA for all users, (2) block legacy authentication protocols, (3) require MFA for admin roles specifically, (4) require compliant device for access to SharePoint, OneDrive, and Exchange, and (5) named location policies to challenge or block sign-ins from outside trusted IP ranges. All five should run in report-only mode before enforcement.
Does HIPAA require Conditional Access?
Not by name, but HIPAA's entity authentication requirement (164.312(d)) requires verifying identity before granting access to PHI. Security Defaults' conditional, Microsoft-controlled MFA doesn't reliably satisfy that. A CA policy requiring MFA on every access does. HIPAA also requires audit controls (164.312(b)), and CA sign-in logs provide the evidence trail.
What happens to Security Defaults when you enable Conditional Access?
Creating any Conditional Access policy disables Security Defaults automatically. Before you build your first CA policy, make sure your baseline policies are ready to replace everything Security Defaults was handling. Don't create one CA policy and leave the rest unprotected.
