Baseline security doesn’t need to be a full lockdown
Conditional Access is no longer optional—but it also doesn’t need to start with a full Zero Trust lockdown. In many real-world tenants, the immediate objective is not maximum restriction. It’s to establish a minimum viable identity security baseline that meaningfully reduces risk, remains operationally practical, and aligns to the licenses actually provisioned.
This post outlines what I consider the minimum acceptable Conditional Access baseline for a Microsoft Entra ID tenant. It intentionally avoids deep device posture requirements and complex conditional logic. Instead, it focuses on high-impact controls that are:
- Achievable in most small-to-mid environments
- Built on Microsoft’s Conditional Access templates wherever possible
- Immediate risk reducers against common identity attack paths
- Supportable—without creating ongoing operational drag
Why a baseline matters (especially after licensing changes)
Many organizations inherit tenants running Security Defaults. Security Defaults are better than nothing, but they are not a long-term policy model: they are limited in flexibility, reporting, and auditing. Once a tenant has Entra ID Premium licensing (for example through Microsoft 365 Business Premium), Conditional Access becomes the correct control plane for identity security.
The challenge is that Conditional Access can also go wrong quickly if deployed without a plan—leading to admin lockouts, broken legacy workloads, or a rushed rollback. A defined minimum baseline avoids those outcomes while still enforcing MFA where it matters most.
Step 1: Disable Security Defaults (cleanly)
If the tenant currently uses Security Defaults, they must be disabled before Conditional Access policies can be reliably enforced. This is not a reduction in security—it is a transition to a more explicit, auditable, policy-driven model. After this change, Conditional Access becomes the primary authority for access requirements.
Defining “minimum”: four paths you must protect
At minimum, every tenant should enforce controls across these four critical access paths:
- Privileged administrative access
- Azure management access
- All interactive user sign-ins
- Legacy authentication protocols
These are the common attack surfaces threat actors expect to be weak. A baseline that covers them stops the bulk of commodity credential-based attacks without requiring advanced maturity.
Core policies (template-driven and low risk)
1) Require MFA for administrators
This policy should exist in every tenant. Microsoft’s template that requires multifactor authentication for admins is straightforward and targets directory roles directly.
- Best practice: no user-based exclusions
- Reason: administrative access is inherently high risk
If an admin cannot satisfy MFA, that’s an identity readiness issue—not a Conditional Access exception.
2) Require MFA for Azure management
Access to Azure management endpoints (portal and APIs) represents elevated risk, even for users who are not Global Administrators. Microsoft’s template for Azure management MFA protection is a high-value baseline policy.
- Protects: Azure Portal, ARM/API, PowerShell and automation paths
- Best practice: keep it clean—avoid broad exclusions
3) Block legacy authentication
Most password spray and credential replay attacks depend on legacy protocols that do not support modern authentication. Blocking legacy authentication is one of the fastest ways to reduce attack surface in a tenant.
- Reduces exposure to password spray attacks
- Forces modern authentication across Microsoft 365 services
- Typically improves Defender Secure Score quickly
If exceptions are required, scope them narrowly to specific service accounts with a documented business justification. Avoid broad “everyone” carve-outs.
4) Require MFA for all users
This is the most impactful baseline control—and often the most delayed. Microsoft’s template for requiring MFA for all users establishes consistent enforcement across cloud apps and removes ambiguity from “who is protected.”
Where exclusions are truly required (for example, narrowly-scoped automation or synchronization accounts in hybrid environments), keep them minimal, explicitly justified, and reviewed regularly.
One additional control most tenants miss
Restrict Azure management to administrative roles only
Many tenants enable Azure management MFA but overlook a key hardening step: limiting Azure management access to administrative roles only. A simple custom Conditional Access policy can:
- Block Azure management access for non-admin users
- Reduce attack surface dramatically
- Align with common Secure Score remediation guidance
This is not a templated policy in many environments, but it’s straightforward and delivers strong value with low operational risk.
Rollout strategies: all at once vs staged
Option A: All-at-once enforcement
Best suited for smaller tenants or organizations with strong change readiness. Policies are enabled quickly, with narrowly-scoped exceptions applied only when required.
Option B: Staged rollout (recommended for most tenants)
For larger organizations or environments with higher change sensitivity, staged rollout reduces disruption:
- Create a security group for pilot enforcement (for example, “MFA Rollout”)
- Apply the MFA enforcement policies to that group
- Onboard users in waves, validating support processes along the way
- Transition to “All Users” once adoption is complete
This approach allows controlled adoption without leaving the tenant exposed indefinitely.
Entra ID Premium Plan 2 (if licensed)
If Entra ID Plan 2 is available, Microsoft provides additional templates that leverage Identity Protection signals. These should generally be layered in after MFA coverage is universal:
- Require MFA for risky sign-ins
- Require password change for high-risk users
These controls can be extremely effective, but enabling them too early (before broad MFA adoption) often increases helpdesk load.
Optional hardening: phishing-resistant MFA for administrators
Where Windows Hello for Business or FIDO2 security keys are implemented, enforcing phishing-resistant MFA for administrators is an excellent next step. It’s not required for a baseline, but it meaningfully increases resilience against modern phishing.
Final thoughts
These standards are intentionally conservative. They are not maximum enforcement—and they aren’t meant to be. They represent the minimum line a modern tenant with Conditional Access licensing should not fall below.
Every policy described here is achievable, auditable, and explainable to stakeholders. Most importantly, it’s sustainable. Security controls that can’t be maintained don’t stay enabled—and a baseline only works if it lasts.