Every Microsoft Entra ID tenant needs a starting point for identity security, and Conditional Access is where that starting point should be. This article walks through a set of baseline Conditional Access policies I recommend for any tenant that has a P2 license. These are not exotic policies. They cover the basics that most breaches exploit when they are missing: weak MFA enforcement, legacy authentication protocols, and no response to risky sign-ins.
None of this is theoretical. These policies come from actual tenant hardening work, and each one earns its place because it closes a real gap that security defaults leave open.
Why Security Defaults Are Not Enough
Security defaults are a reasonable starting point for a new tenant with no P2 license. They force MFA for all users and block a handful of risky legacy behaviours, but you cannot customize them. The moment you have a P2 license, Conditional Access policies give you far more control, including phishing resistant authentication for admins, sign-in risk evaluation, and terms of use enforcement.
Disable security defaults before you start building Conditional Access policies, otherwise the two systems overlap and cause confusing behaviour. You will find the setting under your tenant Overview, then Properties.
Once security defaults are off, the tenant has no baseline protection until you activate Conditional Access policies to replace them. Do this in one sitting rather than leaving a gap between the two, because an unprotected window is exactly when things go wrong.
The Six Baseline Policies
The following six policies apply sensibly to almost every tenant, regardless of size or industry. I list them here in the order I usually create them, though the order does not matter much once they are all active.
- Force MFA conditional access policy (All users)
- Require Terms of Use policy
- Block legacy authentication (All users)
- Enable Sign-in risk policy (All users)
- Require phishing resistant authentication for admins
- Enable User risk policy (All users)
Before you activate any of these, create a single break glass account and exclude it from every policy. This account should never be used except in a genuine emergency, and you should have alerting configured so someone notices immediately if it ever signs in. Skipping this step is the most common mistake I see, and it turns a small policy misconfiguration into a full tenant lockout.
1. Force MFA for All Users
Multi-factor authentication should be mandatory for every user except the break glass account. Use the Require authentication strength control rather than the older grant control, since it lets you define the default strength centrally and update it later without rebuilding the policy.
Name the policy clearly, something like Force MFA All users except break glass account, so anyone reviewing the policy list six months later understands its scope without opening it. Vague policy names are a recurring source of confusion during audits.
2. Require Terms of Use Policy
A Terms of Use policy forces users to accept your organization’s terms before they can use any client app connected to the tenant. This matters for compliance reasons as much as security ones, since it gives you a recorded acceptance timestamp per user.
You need to add the terms of use document to the tenant first, then build the policy around it. Microsoft’s own documentation on Conditional Access terms of use and the require terms of use walkthrough cover the exact steps, so there is no need to repeat them here.
3. Block Legacy Authentication
Legacy authentication protocols do not support modern MFA challenges, which makes them a favourite target for password spray attacks. Scope the policy to Exchange ActiveSync clients and Other clients under Client apps, then set the grant control to block.
Check your sign-in logs for legacy authentication attempts before you block it outright. Some older line-of-business apps or scanners still use basic auth, and blocking without checking first can break a workflow nobody remembers configuring.
4. Enable Sign-in Risk Policy
Sign-in risk evaluates each authentication attempt for signals like anonymous IP addresses, unfamiliar sign-in properties, or leaked credentials, and requires a P2 license to use. When the risk level crosses your chosen threshold, the user must complete an additional MFA challenge before access is granted.
Start with the medium and above threshold rather than low. A low threshold generates a large number of MFA prompts for ordinary travel or new device sign-ins, and users who get challenged too often start looking for ways around the policy instead of trusting it.
5. Phishing Resistant Authentication for Admins
Administrator accounts deserve stronger protection than ordinary users, since a compromised admin account gives an attacker control over the whole tenant. Microsoft provides a ready-made Conditional Access template for this exact scenario, which saves you from building the role list by hand.
The template applies to the roles most attackers target first:
- 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
- User Administrator
Anyone assigned one of these roles must authenticate using a phishing resistant method such as a FIDO2 key or Windows Hello for Business before the tenant grants access. Passwords and standard push MFA are not accepted for these accounts once the policy is active.
6. Enable User Risk Policy
User risk is different from sign-in risk. It looks at the overall likelihood that an account itself has been compromised, based on signals like leaked credentials found on the dark web, rather than evaluating a single sign-in attempt. This also requires a P2 license.
I have gone back and forth on whether self-service password reset makes sense as the remediation step here. If your users sign in with passwordless or phishing resistant methods, forcing a password reset does not actually clear the user risk signal, and the account stays flagged until you resolve it manually. In practice, this policy earns its keep mostly at the high risk threshold combined with a block, rather than pairing it with SSPR. Test this behaviour in your own tenant before you rely on it, since the interaction between user risk and passwordless sign-in is not well documented.
Summary
These six policies form a sensible baseline, not a complete security posture. Depending on your tenant’s requirements, you will likely add session controls such as sign-in frequency limits or app-enforced restrictions, device compliance requirements, or location-based policies on top of this baseline.
Practical Notes
Every policy shown here was created through the Azure portal for clarity, but portal-based setup does not scale well once you manage more than one tenant or need repeatable deployments. Rebuilding it as a Terraform script or a Microsoft Graph automation, wired into an Azure DevOps or GitHub Actions pipeline, gives you version control over policy changes and a much faster recovery path if a policy gets misconfigured.
There is no GitHub sample tied to this particular article, so if you want to automate these policies, look at the Microsoft Graph beta endpoint for Conditional Access policies and the AzureAD Terraform provider as starting points. Also worth reading alongside this is Microsoft’s documentation on Continuous Access Evaluation, since CAE changes how quickly these policies take effect after a risk signal or role change.
Leave a Reply