Conditional Access Baseline for SMEs: The First Policies

By · Published

Conditional Access is the central control for identity security in Microsoft Entra ID. At every sign-in it uses signals such as user, application, device, location and risk to decide whether access is granted, requires additional verification or is blocked.

Many tenants start with security defaults or with a set of policies that grew over time. This article describes a lean baseline that works well for small and mid-sized organisations and how to introduce it without disrupting operations.

Prerequisites: licensing and security defaults

Conditional Access requires Microsoft Entra ID P1, which is included in Microsoft 365 Business Premium, E3 and E5 among others. Risk-based policies (sign-in and user risk) require Entra ID P2.

Security defaults and Conditional Access are mutually exclusive. Security defaults must be turned off before your own policies take effect – ideally only once the replacement policies have been validated in report-only mode, so that no protection gap appears.

First: emergency access (break-glass) accounts

Before enabling the first blocking policy, create at least two cloud-only accounts with the Global Administrator role that are reserved for emergencies. Microsoft recommends protecting these accounts with strong, ideally phishing-resistant authentication (for example FIDO2 security keys) and monitoring their sign-ins.

Emergency access accounts are excluded from most Conditional Access policies. This keeps the tenant reachable if a faulty policy or an MFA service outage locks out every other administrator.

The baseline policies

The following policies cover the most common attack paths and form a solid foundation. Give every policy a clear name (for example a prefix and number) so its effect remains traceable later.

  • MFA for all administrator roles – ideally with the “phishing-resistant MFA” authentication strength.
  • MFA for all users on all cloud apps, excluding the emergency access accounts.
  • Block legacy authentication (client apps “Exchange ActiveSync” and “Other clients”), because these protocols cannot perform MFA.
  • MFA for access to Azure management (Azure portal, CLI, PowerShell).
  • Device requirements for corporate data: compliant device (Intune) or app protection policy on mobile devices.
  • With Entra ID P2: MFA or password change on elevated sign-in or user risk.

Rolling out without lockouts: report-only mode

Every new policy is first enabled in report-only mode. The policy is evaluated at each sign-in but not enforced. The sign-in logs and the “Conditional Access insights and reporting” workbook show which sign-ins would have been blocked or challenged.

Only when several days of evaluation show no unexpected results – such as service accounts, scanners or integrations – is the policy switched on. Exclusions should remain rare, documented and reviewed regularly.

Common mistakes

  • No emergency access account, only one, or accounts that depend on a single employee's MFA method.
  • Policies enabled directly instead of being tested in report-only mode.
  • Broad exclusion groups that grow over time and are never reviewed.
  • Location-based exceptions (“no MFA on the office network”) that offer no protection for compromised accounts.

Key takeaway

A good Conditional Access baseline consists of a few clearly named policies, protected emergency access accounts and a disciplined rollout through report-only mode. After that, review exclusions and sign-in logs regularly.

Sources