The best Conditional Access Policies to protect Microsoft 365 with Zero Trust

Microsoft Entra ID Conditional Access Policies (CAP) are the Zero Trust “policy engine”: at their core they are if/then rules that decide whether to allow access and under what conditions (MFA, compliant device, block, Terms of Use, session controls, etc.).

In a modern Microsoft 365 tenant, Conditional Access turns Zero Trust principles into concrete controls:

• Verify explicitly: don’t rely on passwords or IP addresses alone.
• Least privilege: protect most where the impact is greatest (admins and portals).
• Assume breach: reduce the effectiveness of token replay and session hijacking.

Important note: CAPs should always be introduced via Report-only → Pilot → Rollout to avoid lockouts and unexpected impact.

---

Design principles (that save you from incidents and rollbacks)

Before getting into the detail of how to configure the policies, here are two small operational rules that make a real difference and that have always helped me:

1. Naming standards and “clean” policies: one policy = one clear objective (easier debugging).
2. Break-glass excluded: 1–2 emergency accounts always excluded from every CAP (and closely monitored).

Break-glass: these are dedicated administrative accounts to be used only in exceptional scenarios, for example when a configuration mistake (Conditional Access/MFA), an Identity Provider problem or a security incident locks the “normal” administrators out. The idea is to have a guaranteed way back in: for this reason these accounts are generally excluded from all Conditional Access Policies and protected with very strict compensating measures (a long, unique password, secure storage, continuous monitoring/alerting and access allowed only when genuinely needed).

---

The Conditional Access Policies I recommend (complete set)

In this section we will look in depth at a set of Conditional Access Policies (CAP) designed to cover the main Zero Trust pillars in Microsoft 365: eliminating “legacy” vectors, raising assurance with MFA, protecting privileged accounts, risk-driven remediation (Identity Protection) and governance through Terms of Use.

On my own tenant I chose to adopt a consistent naming convention with the [CAP] prefix, so that security policies are instantly recognisable at a glance and stay tidy over time.

Below are the policies we will analyse and how I named them in my tenant:

---

1) Block Legacy Authentication

Objective: block legacy authentication (non-modern protocols/clients), which is often the first vector exploited in password spraying and brute-force attacks.

Why it matters: legacy protocols are easier to attack and can reduce the effectiveness of modern controls.

Typical implementation

• Users: All users (exclude break-glass)
• Target resources: All cloud apps (or at least Exchange Online if you want to start gradually)
• Conditions → Client apps: Other clients / legacy auth
• Grant: Block access

• Detailed configuration – Microsoft Docs

---

2) Entra Token Protection (Session control)

Objective: reduce token replay and session theft attacks by requiring that accepted tokens are “bound” to the expected device/session.

Key point: it is not a “Grant control” like MFA; it is session hardening. It needs to be piloted, because not every app/client combination behaves the same way.

Typical implementation

• Users: Pilot group (then extend)
• Cloud apps: Microsoft 365 core (Exchange/SharePoint/Teams) or critical apps
• Access controls → Session: Require token protection for sign-in sessions
• Enable: Report-only → On

• Detailed configuration – Microsoft Docs

---

3) Require MFA for all users (Trusted location exception)

Objective: raise the baseline: if a password is compromised, that alone must not be enough to get in.

Warning: “Trusted location” is often a UX choice. An IP address does not prove that the device is managed or healthy.

Typical implementation

• Users: All users (exclude break-glass)
• Locations: Exclude “Trusted named locations”
• Grant: Require MFA (or) Require authentication strength: MFA strength

• Detailed configuration – Microsoft Docs

---

4) Require phishing-resistant MFA for Administrators

Objective: protect privileged accounts with a higher level of assurance.

Modern best practice: use Authentication Strength: Phishing-resistant MFA for admins, because it reduces the attack surface for advanced phishing (proxy/AiTM).

Typical implementation

• Users: Directory roles (Global Admin + critical roles)
• Cloud apps: Microsoft Admin Portals (at least) or All cloud apps
• Grant: Require authentication strength → Phishing-resistant MFA strength

• Detailed configuration – Microsoft Docs

---

5) Admins: access to admin portals only from compliant/hybrid joined devices

Objective: drastically reduce the likelihood that stolen admin credentials turn into a tenant takeover.

Why it is so effective: even with stolen credentials, the attacker often does not have a device that meets the management/compliance requirements.

Typical implementation

• Users: Directory roles (admin)
• Cloud apps: Microsoft Admin Portals
• Grant:
  • Require device to be marked as compliant OR
  • Require Microsoft Entra hybrid joined device

Note: “compliant” assumes an MDM/compliance strategy (typically Intune). Without real compliance policies, this CAP will not behave as you expect.

• Detailed configuration – Microsoft Docs

---

6) Require remediation for risky sign-in (Sign-in risk)

Objective: when Microsoft Entra detects a risky sign-in, require remediation (typically MFA) or block if the user is not registered.

Typical implementation

• Condition → Sign-in risk: Medium/High (or High to start conservatively)
• Grant: Require MFA

• Detailed configuration – Microsoft Docs

---

7) Require remediation for risky user (User risk)

Objective: if it is the identity itself that is considered compromised (user risk), the typical remediation is a password change.

Typical implementation

• Condition → User risk: High
• Grant: Require password change

Licensing note: risk-based features require Microsoft Entra ID Protection (typically Entra ID P2 / Entra Suite).

• Detailed configuration – Microsoft Docs

---

8) Bonus CAP - Force Terms of Use

Objective: present a document (PDF) and require acceptance before granting access to specific resources. It is useful for compliance, acceptable use and user awareness.

Typical implementation

• Create the Terms of Use (PDF, language(s), display name)
• CA policy:
  • Target resources: Microsoft Admin Portals (or sensitive apps)
  • Grant: Require terms of use

• Detailed configuration – Microsoft Docs

---

Recommended rollout order (to reduce risk and impact)

1. Block legacy authentication (Report-only → On)
2. MFA for everyone (pilot + extension)
3. Admins: phishing-resistant MFA strength
4. Admin portals only from compliant/hybrid joined devices
5. Risk-based (sign-in risk / user risk) if you have Entra ID Protection
6. Token Protection (pilot, then broaden)
7. Terms of Use on admin portals/sensitive apps

---

Conclusion

Conditional Access is not about “turning on MFA”: it is about defining how much and when to trust, using different signals and consistent controls. If you block legacy authentication, enforce MFA (ideally governed through Authentication Strengths), introduce risk-based remediation and add session hardening with Token Protection, you are already covering most modern attack patterns.

The real step up in maturity, though, comes when you clearly separate “user” access from “administrative” access: admins must not only authenticate more strongly, they must administer from managed, compliant devices. Restricting access to the Microsoft Admin Portals to compliant or hybrid joined devices is one of the most effective measures for preventing credential theft from turning into a full tenant compromise.

Finally, security is not measured by the number of active policies, but by how you govern them: Report-only, piloting, monitoring the sign-in logs and discipline over exceptions. Conditional Access is a continuous control: it evolves along with the way you work, your apps and attack techniques.