Founder of Brainpulse IT and Identity & Endpoint Security Architect in the Microsoft ecosystem. Microsoft MVP and Microsoft …
Five Conditional Access policies every organisation needs
Conditional Access is where Microsoft Entra ID decides who can access what, and under which conditions. It is the Zero Trust policy engine. Yet in many environments we find a collection of policies that has grown over the years: an exception for a project, a policy that was switched on once and that nobody dares to touch any more.
It can be simpler. Microsoft publishes its own templates and guidance for a secure baseline. In this article we set out the five policies that, in our view, belong in every organisation. For each policy you will read what it does, why it is needed and which pitfalls we encounter.
As of 13 October 2026.
What do you need?
Conditional Access requires Microsoft Entra ID P1. Organisations with Microsoft 365 Business Premium can also use it. The risk-based policies (policy 5) require Entra ID P2, because they rely on Microsoft Entra ID Protection. If you have neither, security defaults provide baseline protection, including blocking legacy authentication.
Policy 1: MFA for all users
What: one baseline policy that requires multifactor authentication (MFA) for all users and all resources. Microsoft describes a single baseline policy without app exclusions as the starting point for every organisation. The template uses the built-in MFA authentication strength for this.
Why: a password on its own is too easy to guess, leak or intercept. This policy is the safety net beneath all the others.
Pitfalls:
- Exclusions for the office network. Technically this is possible, but it turns an IP address into the key. We prefer MFA everywhere, combined with a managed device with Windows Hello for Business, so that signing in remains convenient.
- Per-app exclusions that were needed temporarily and were never reversed.
- Forgetting the synchronisation account. If you use Entra Connect or Cloud Sync, exclude the Directory Synchronization Accounts role.
Policy 2: Phishing-resistant MFA for administrators
What: administrator roles get a stricter requirement: the Phishing-resistant MFA authentication strength. This covers methods such as Windows Hello for Business, passkeys (FIDO2) and certificate-based authentication. A code or push notification in an app does not count. The template lists the roles that should at least be included, from Global Administrator to Helpdesk Administrator.
Why: a compromised administrator account causes the most damage, and these are exactly the accounts attackers target. Codes and push notifications are susceptible to remote phishing. Phishing-resistant methods require an interaction between the authentication method and the device or app being signed in to.
Pitfalls:
- Switching it on before administrators have a suitable method. That is how you lock yourself out. Have administrators register a passkey first using a Temporary Access Pass.
- Relying on custom roles. Conditional Access does not enforce this policy for custom roles or roles scoped to an administrative unit. That quietly leaves a gap.
Policy 3: Block legacy authentication
What: old protocols and clients that do not support MFA, such as Exchange ActiveSync with basic authentication, are blocked for all users.
Why: according to Microsoft’s analysis, more than 97 per cent of credential stuffing attacks and more than 99 per cent of password spray attacks use legacy authentication. This policy closes that channel in one go.
Pitfalls:
- Switching it on blindly. First check the sign-in logs to see which clients still use old protocols, including the non-interactive sign-ins. A ready-made workbook in Entra ID helps with this.
- The exception for that one scanner or application. Such exceptions often stay in place for years. Give them an owner and an end date.
Policy 4: Only managed devices or protected apps
What: full access to company data only from devices that meet your Intune compliance policy or are hybrid joined. On iOS and Android you require an app protection policy. Microsoft also advises blocking unknown or unsupported device platforms.
Why: MFA proves who is signing in, not on what. A valid sign-in from an unmanaged or infected laptop is still a risk to your data. For unmanaged devices we therefore often choose a restricted route with the Use app enforced restrictions session control. SharePoint, OneDrive and Outlook on the web then give such a device a limited experience, for example working in the browser without downloading files.
Pitfalls:
- A compliance policy that is not in order. This policy is only as strong as the Intune policy underneath it.
- Policies using Require approved client app. Since 30 June 2026 that control has been read-only. New policies are built with Require app protection policy.
- Certificate prompts during testing. In report-only mode, a policy that requires a compliant device can still prompt for a certificate on macOS, iOS and Android. Exclude those platforms during the test phase.
Policy 5: Act on risk
What: Microsoft Entra ID Protection calculates, per sign-in (sign-in risk) and per user (user risk), how likely it is that an account is being misused. The templates require MFA for medium or high sign-in risk, and remediation, such as a secure password change, for high user risk. This requires Entra ID P2.
Why: the first four policies are static. This policy responds to what is happening at that moment, such as a leaked password or a sign-in that deviates from the normal pattern.
Pitfalls:
- Users without registered MFA. They cannot resolve a risky sign-in themselves and are blocked. Make sure everyone is registered first.
- Both risks in one policy. The documentation explicitly warns against this: create a separate policy for sign-in risk and for user risk.
- The old risk policies in ID Protection. Microsoft gives 1 October 2026 as the date on which these are retired, and that date has now passed. If you still have risk policies in ID Protection, move them to Conditional Access.
The foundation beneath the five policies
Emergency access accounts
Microsoft advises at least two emergency access (break-glass) accounts: cloud-only on the .onmicrosoft.com domain, protected with a passkey (FIDO2) or certificate that differs from your normal administrator accounts, and excluded from every policy that blocks or restricts sign-in. Every use triggers an alert, and at least every 90 days you test whether the accounts still work.
Note: a policy you create from a template only excludes the account you create it with. You add your emergency access accounts yourself.
Report-only first
Every policy starts in report-only mode. The templates do this by default. The sign-in logs show what the policy would do, without anyone being blocked. We then roll a policy out in phases: a pilot group first, then the rest of the organisation.
A fixed structure and naming convention
Choose a naming convention that shows the purpose, target and scope at a glance. A policy has no owner field, so you record the owner in the name and in a register. We work with a fixed structure of number, target group, application and control. That way everyone can see at a glance why a policy exists.
Keeping exceptions under control
This is where most problems arise. An exception is quickly made, but rarely cleaned up. Excluded users often do not know they are excluded, someone can add themselves to an exclusion group, and the reason for an exception may have lapsed long ago.
Our principle: as few exceptions as possible, each with an owner, a reason and an end date. With access reviews (Entra ID P2 or Entra ID Governance) you can demonstrate periodic review. Protect changes to the policies themselves with protected actions.
And the Dutch Cyber Security Act?
Article 21 of the Dutch Cyber Security Act (Cyberbeveiligingswet) lists access control policies and, where appropriate, multifactor authentication as topics your measures must cover. A clear Conditional Access architecture is therefore not only more secure, but also easier to demonstrate. Read more in our article on the Cyber Security Act.
How we can help
Founder Stefan Dingemanse has been a Microsoft MVP for seven years, in both Security (Intune) and Windows and Devices (Windows 365), and is a Microsoft Certified Trainer. In many environments, Conditional Access is full of exceptions that nobody can explain any more. With our consultancy for Identity Protection we design an architecture with a fixed structure and as few exceptions as possible. We first map your existing policies and then roll out the new design in phases, via report-only mode and without surprises for your users.
Would you like to know where you stand first? The Security Health Check measures your Conditional Access and MFA configuration against the CIS benchmark, the CISA baselines and Zero Trust, and shows where your environment deviates.