Conditional Access Basics: A Microsoft Entra Guide for IT Teams

Conditional Access is the policy engine in Microsoft Entra ID that decides what happens after someone signs in: allow access, block it, or ask for more, such as multifactor authentication (MFA) or a compliant device. Each policy is an if-then rule. It needs Microsoft Entra ID P1 or Microsoft 365 Business Premium, and risk-based policies need Entra ID P2. Test every policy in report-only mode first.

At a glance

• What it is: Microsoft's Zero Trust policy engine, applied after the first authentication factor is complete
• Licence: Microsoft Entra ID P1, or Microsoft 365 Business Premium. Sign-in risk and user risk policies need Entra ID P2
• Free alternative: security defaults, which are either on or off with no customisation
• First policies: MFA for admins, block legacy authentication, MFA for all users, MFA for Azure management
• Safety net: at least two emergency access accounts, excluded from policies that block or restrict sign-in
• Testing: report-only mode, the What If tool, policy impact and the sign-in logs

How a Conditional Access policy works

Microsoft describes policies at their simplest as if-then statements. If the assignments match, then the access controls apply.

Grant controls range from blocking access, the most restrictive decision, to requiring MFA, an authentication strength, a compliant or Microsoft Entra hybrid joined device, an approved client app, an app protection policy, a password change or terms of use. Session controls, such as sign-in frequency, shape what happens after access is granted.

When several policies apply to one sign-in, all of them must be satisfied. That is why a single badly scoped block policy can lock out far more people than its author intended.

Security defaults or Conditional Access?

If you have no P1 licences, security defaults are your baseline. They require MFA registration for everyone, MFA for admins and for Azure management, and block legacy authentication. You cannot use both at once: creating Conditional Access policies prevents you from enabling security defaults.

Microsoft's guidance is that when you turn security defaults off, you should immediately enable Conditional Access policies that give the same protection. Do not leave a gap between the two.

The baseline policies most organisations start with

Microsoft publishes Conditional Access templates and recommends its Secure foundation set as the base for all organisations, deployed as a group:

Two policies deserve priority. Block legacy authentication, because Microsoft states that more than 99 percent of password spray attacks use legacy authentication protocols such as IMAP, POP3 and SMTP, which cannot complete MFA. And MFA for all users, because the UK's Cyber Essentials requirements (v3.3, April 2026) state that authentication to cloud services must always use MFA. If you hold or are working towards Cyber Essentials, our article on the Microsoft 365 settings admins miss covers the wider control set.

With Entra ID P2, add MFA for risky sign-ins and password change for high-risk users. For admins, the next step up is phishing-resistant MFA, such as passkeys.

Check for Microsoft-managed policies first

Before you build anything, open Entra ID, Conditional Access, Policies and look at the Created by column. Microsoft deploys managed policies into eligible tenants in report-only mode, covering items such as blocking legacy authentication, blocking device code flow, MFA for admins on admin portals, MFA for all users and risky sign-ins.

Microsoft enables these no less than 30 days after they arrive if you leave them in report-only, and says it sends email and Message center notices two weeks beforehand. You can exclude users and change the state, but you cannot rename or delete them. If you need bigger changes, duplicate the policy and edit the copy. The first job is to add your emergency access accounts to their exclusions.

Break-glass accounts before anything goes live

Microsoft's emergency access guidance is specific:

• Keep at least two emergency access accounts.
• Make them cloud-only on the onmicrosoft.com domain, not synchronised or federated.
• Protect them with passkeys (FIDO2) or certificate-based authentication, different from your everyday admin method.
• Assign Global Administrator as permanent active, not eligible, in Privileged Identity Management.
• Put them in a dedicated group, such as EmergencyAccess, and exclude that group from policies that block or restrict sign-in.
• Alert on every sign-in and validate the accounts at least every 90 days.

If your sign-in logs flow to a Log Analytics workspace, an alert query can be as simple as this:

SigninLogs
| where UserId in ("<object-id-1>", "<object-id-2>")
| project TimeGenerated, UserPrincipalName, IPAddress, ResultType, AppDisplayName

Report-only mode: how to test safely

Templates create policies in report-only mode by default. The policy is evaluated at every sign-in but never enforced, and the result is written to the sign-in log.

Review results in the policy impact view, the Conditional Access insights and reporting workbook (which needs sign-in logs in Log Analytics) and individual sign-in events. The What If tool answers "which policies would hit this user on this app from here?" before you change anything.

Two limitations to know. Policies scoped to user actions cannot run in report-only mode. And a report-only policy that requires a compliant device can prompt macOS, iOS and Android users to pick a certificate, so Microsoft advises excluding those platforms from such tests.

To see every policy and its state at a glance, Microsoft Graph PowerShell helps:

Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy | Select-Object DisplayName, State | Sort-Object State

A state of enabledForReportingButNotEnforced means report-only. Microsoft does not set a minimum test period. In practice, leave each policy in report-only long enough to capture weekly and month-end jobs, then switch it on.

A rollout order for a small IT team

1. Week 1, prepare. Confirm licences, create the break-glass accounts and group, review Microsoft-managed policies, and filter the sign-in logs by client app to find legacy authentication still in use.
2. Week 2, report-only. Deploy the Secure foundation templates in report-only, tell staff what is coming and ask them to register MFA at the security info page.
3. Week 3, enforce in stages. Turn on MFA for admins and block legacy authentication first, then MFA for all users once registration is complete.
4. Week 4 and after, harden. Add device compliance with Intune, risk-based policies if you have P2, and phishing-resistant MFA for admins.

Use a naming convention such as CA01-Admins-RequireMFA so the list stays readable. Common mistakes to avoid: excluding so many accounts that the policy means little, forgetting service accounts (Microsoft recommends moving scripts to managed identities), and leaving classic policies in place, which stopped enforcing controls after 10 July 2024.

Licensing to check before you start

• Entra ID P1 or Microsoft 365 Business Premium for Conditional Access itself.
• Entra ID P2 for sign-in risk and user risk policies through Microsoft Entra ID Protection.
• Intune for compliant device controls, and Microsoft Purview for insider risk conditions.
• Security Copilot security compute units if you want the Conditional Access Optimization Agent's suggestions.

If Conditional Access licences lapse, Microsoft says policies are not disabled or deleted, but you can no longer update them.

How CertTulen Academy can help

CertTulen Academy runs live, MCT-led online training with hands-on labs. SC-900 gives IT staff the identity and Zero Trust grounding that makes Conditional Access decisions easier, and MD-102 covers the Intune device compliance that the stronger policies depend on. For an IT team rolling out policies together, a private cohort works well. Contact us for a batch that suits your time zone.