If your organisation runs Microsoft 365, you already own one of the most capable access-control engines available: Microsoft Entra Conditional Access. It is the mechanism that decides, in real time and for every sign-in, whether to allow access, block it, or demand additional proof. It is the practical heart of a zero-trust identity strategy.
It is also one of the most commonly misconfigured controls in Microsoft 365. Done well, Conditional Access blocks the attacks that matter while staying invisible to legitimate users. Done badly, it either leaves obvious gaps or locks people out of their own accounts — including, in the worst cases, the administrators trying to fix it.
This guide lays out a sensible baseline of policies, the order to roll them out, and the mistakes that catch organisations every time.
What Conditional Access Actually Does
Think of Conditional Access as a set of if-then rules evaluated at every sign-in. Each policy combines:
- Assignments — who and what the policy applies to: users and groups, target applications, and the conditions of the sign-in (device platform, location, client app, and calculated risk level).
- Access controls — what to do when the conditions match: block access, grant access, or grant access only if certain requirements are met, such as multi-factor authentication, a compliant device, or an approved app.
The power lies in the combination. "If a user in the finance group signs in from an unmanaged device outside South Africa, require phishing-resistant MFA and block file downloads" is a single, enforceable policy. That contextual decision-making is what separates Conditional Access from a blunt "MFA always on" approach.
One prerequisite matters: Conditional Access is an Entra ID P1 capability, included in Microsoft 365 E3 and E5 (and Business Premium). Risk-based policies that respond to calculated sign-in and user risk require Entra ID P2, included in E5. Confirm your licensing before designing policies that depend on risk signals.
A Baseline That Works
You do not need dozens of policies. A focused set covers the vast majority of real-world risk. Treat the following as a starting baseline and adapt it to your environment.
1. Require MFA for All Users
The foundational policy. Require multi-factor authentication for every user accessing cloud applications. This single control blocks the overwhelming majority of password-based attacks. Where possible, require phishing-resistant methods — passkeys or FIDO2 security keys — rather than codes that can be relayed by a real-time phishing proxy.
2. Require Phishing-Resistant MFA for Administrators
Privileged accounts are the prize attackers want most. Apply a stricter policy to all administrative roles: accept only phishing-resistant authentication, with no fallback to SMS or typed codes. In Entra this is expressed through an authentication strength requirement attached to the policy.
3. Block Legacy Authentication
Older protocols — such as legacy POP, IMAP, and SMTP authentication paths — cannot enforce MFA. Attackers actively target them precisely because they bypass your other controls. Microsoft has been retiring basic authentication, but explicitly blocking legacy authentication with a Conditional Access policy closes the gap definitively. Check sign-in logs first to confirm no critical service still depends on it.
4. Require Compliant or Hybrid-Joined Devices for Sensitive Apps
For your most sensitive applications, require that the device itself is managed and healthy — marked compliant by Microsoft Intune or hybrid Entra-joined. This means a stolen password alone is not enough; the attacker would also need a device your organisation trusts. Introduce this gradually, starting with the highest-value applications.
5. Use Risk-Based Policies (E5 / Entra ID P2)
If your licensing includes Entra ID P2, layer in risk-based controls. Require a secure password change when a user account is flagged as high risk, and require MFA — or block outright — when a sign-in is flagged as risky. These policies respond to Microsoft's threat intelligence automatically, catching impossible-travel sign-ins, anonymised-IP access, and credentials seen in known breaches.
6. Control Access by Location and Session
Define named locations — your offices, your country — and use them to shape access. You might require additional verification for sign-ins from outside South Africa, or apply session controls that allow access from an unmanaged device but block downloads and apply watermarking. This is particularly valuable for contractors and bring-your-own-device scenarios.
Roll It Out Without Locking Anyone Out
The single most important rule of Conditional Access: never deploy a new policy straight to "On" for everyone. Follow a disciplined rollout.
Always Create Break-Glass Accounts First
Before you configure a single policy, create at least two emergency-access ("break-glass") accounts. These are highly privileged accounts, secured with long unique credentials and strong authentication, that are excluded from all Conditional Access policies. If a misconfigured policy locks out every administrator, these accounts are how you get back in. Store their credentials securely offline, monitor their use closely, and test them periodically.
Use Report-Only Mode
Every Conditional Access policy can be created in report-only mode. In this mode the policy is evaluated and logged for every relevant sign-in, but it is not enforced — nobody is actually blocked or challenged. This lets you see exactly who would have been affected before you turn enforcement on. Leave new policies in report-only mode for a meaningful period, review the results, and only then enable them.
Check the What If Tool
Entra includes a What If tool that simulates how your policies would apply to a hypothetical sign-in — a specific user, app, device, and location. Use it to confirm a new policy behaves as intended and does not unexpectedly collide with existing policies.
Pilot, Then Expand
Enable each enforced policy for a small pilot group first. Confirm legitimate workflows still function — email, Teams, line-of-business apps, mobile access — then expand in stages to the wider organisation. Communicate changes in advance so the service desk is not blindsided by a wave of "I can't sign in" calls.
Mistakes That Catch People Every Time
No break-glass accounts.
The classic disaster: a policy requiring a compliant device is applied to all users including admins, no device is compliant yet, and now nobody can administer the tenant. Break-glass accounts prevent this. Create them first, always.
Going straight to enforcement.
Skipping report-only mode turns every policy into a live experiment on your entire workforce.
Overlapping, contradictory policies.
Conditional Access policies are additive, and the most restrictive control wins. Too many overlapping policies produce confusing, hard-to-debug behaviour. Keep the set small and purposeful.
Forgetting guests and service accounts.
External guests and non-interactive service accounts have different needs. Account for them deliberately rather than letting a blanket policy break integrations.
Setting and forgetting.
Your environment changes — new apps, new device types, new locations. Review policies and sign-in logs regularly so the configuration keeps matching reality.
How This Supports Zero Trust and POPIA
Conditional Access is where zero-trust principles become concrete. Every access decision is evaluated against identity, device health, location, and risk — never trusting the network position alone. Paired with phishing-resistant MFA, it ensures that the verification at the heart of zero trust cannot simply be stolen and replayed.
It also produces exactly the kind of evidence POPIA expects. Access to personal information is controlled, conditional, and logged. When you need to demonstrate appropriate security safeguards to the Information Regulator, a well-documented Conditional Access posture — with sign-in logs to back it up — is precisely the sort of auditable control that shows due diligence.
How OAS Helps
Conditional Access rewards careful design and punishes guesswork. OAS designs, deploys, and manages Entra Conditional Access as part of a managed Microsoft security service. As a long-standing Microsoft partner with over 40 years in the South African market, we help organisations:
Design
a policy baseline matched to your licensing and risk profile
Roll out
safely with break-glass accounts, report-only validation, and staged enforcement
Integrate
Conditional Access with phishing-resistant MFA, Intune device compliance, and Microsoft Sentinel monitoring
Maintain
the configuration as your environment and the threat landscape evolve
The control is already in your licence. The value comes from configuring it properly.
The most powerful security control in Microsoft 365 is the one most often misconfigured.
OAS designs Conditional Access that protects without locking you out.