Conditional Access Policies Every European Organisation Should Have in 2026

Conditional Access is the most important security control in Microsoft 365. It sits at the identity layer — the point where every access request passes through — and it determines whether that request proceeds, requires additional verification, or is blocked entirely. Everything else in the Microsoft security stack assumes that identity is correctly governed. If Conditional Access is wrong, the rest of the security posture is built on an unstable foundation.

Microsoft provides a set of default Conditional Access policies that are enabled when a new tenant is created. These defaults are reasonable starting points for an organisation with no existing policies. For an organisation that has been operating for any length of time, they are not a security posture — they are a floor below which you should not fall. Most mid-market environments need significantly more than the defaults.

This is the baseline Conditional Access policy set for 2026. Eight policies, each with a clear purpose, a common misconfiguration to avoid, and, where relevant, a note on NIS2 alignment.

Policy 1: Require MFA for All Users

What it does: Every user sign-in to any Microsoft 365 application requires multi-factor authentication. The second factor can be the Microsoft Authenticator app, an SMS code, or a hardware FIDO2 key.

Why it matters: Password compromise is the most common initial access vector in Microsoft 365 environments. MFA reduces the value of a compromised password to near zero — the attacker also needs access to the user's second factor. This is the single most impactful security control you can implement, with no change to the underlying platform architecture.

Common misconfiguration: MFA is enabled via the legacy per-user settings in Entra ID rather than enforced via a Conditional Access policy. In the per-user settings, users who have not yet enrolled in MFA can continue to sign in without it. A Conditional Access policy enforces MFA at the point of access — regardless of whether the user has completed MFA registration. Users without MFA registration are blocked, which surfaces the gap and forces remediation.

NIS2 alignment: Directly addresses Article 21(2)(i) — the use of multi-factor authentication or continuous authentication solutions.

Policy 2: Block Legacy Authentication Protocols

What it does: Blocks all sign-in attempts using protocols that cannot satisfy MFA — SMTP AUTH, IMAP, POP3, basic authentication, and older Office client authentication flows.

Why it matters: Legacy authentication protocols bypass MFA by design. If these protocols are enabled in your tenant, an attacker with a valid username and password can authenticate via IMAP regardless of whether MFA is required on the Conditional Access policy. This is a critical and frequently exploited gap. Every organisation that has MFA enabled but legacy authentication not blocked has a materially weaker security posture than they believe.

Common misconfiguration: A policy exists to block legacy authentication, but it contains an IP range exclusion for the corporate network. The reasoning — that on-network devices are trusted — is flawed. Network location is not an identity signal. Legacy authentication should be blocked unconditionally.

NIS2 alignment: Supports Article 21(2)(i) by ensuring MFA enforcement cannot be circumvented.

Policy 3: Require Compliant Device for Sensitive Data Access

What it does: Requires that any device accessing Microsoft 365 applications containing sensitive data — SharePoint, OneDrive, Teams, Exchange — is enrolled in Intune and meets the compliance policy conditions (disk encryption, up-to-date OS, screen lock, endpoint protection active).

Why it matters: Managed, compliant devices provide a materially higher assurance than unmanaged ones. A compliant device requirement ensures that organisational data is not accessed from unpatched personal machines, shared workstations, or devices that have been compromised. It also provides a consistent enforcement point for endpoint security controls.

Common misconfiguration: The policy is applied to all cloud applications rather than a targeted set of sensitive applications. This creates friction for low-sensitivity use cases (e.g. reading internal news) and incentivises users to work around it. Target the policy at applications where the data justifies the control: SharePoint, OneDrive, Exchange, and any other application handling confidential data.

NIS2 alignment: Supports Article 21(2)(e) — security in network and information systems acquisition, development, and maintenance.

Policy 4: Block Access from High-Risk Sign-In Locations

What it does: Uses Named Locations in Entra ID to define trusted locations (office network IP ranges, VPN egress points) and applies additional scrutiny or blocking to sign-ins from locations outside that set. For organisations with a defined geographic operating area, sign-ins from unexpected countries can be blocked entirely.

Why it matters: Credential-stuffing attacks and brute-force attempts predominantly originate from IP ranges and geographic locations unrelated to your user base. Blocking sign-ins from geographies where no employees operate eliminates an entire class of attack vectors without any impact on legitimate users.

Common misconfiguration: Named Locations are never updated after initial configuration. The corporate network changes (new office location, changed ISP, updated VPN endpoint), but the Conditional Access policy still references the old IP ranges. New users from a new office location find themselves blocked because the policy has not kept pace with the organisation's geography. Named Locations must be treated as living configuration, not a set-and-forget setting.

NIS2 alignment: Supports Article 21(2)(a) — policies on risk analysis and information system security.

Policy 5: Require MFA for All Admin Roles

What it does: A separate, stricter policy applying to all Entra ID privileged roles — Global Administrator, Exchange Administrator, SharePoint Administrator, User Administrator, and the full set of privileged directory roles. Requires phishing-resistant MFA (FIDO2 key or certificate-based authentication) rather than app-based MFA.

Why it matters: Administrator accounts are the highest-value targets in any Microsoft 365 environment. An attacker with a compromised global admin account has full control of the tenant. Regular MFA (Microsoft Authenticator push notification) is vulnerable to MFA fatigue attacks — adversaries spam the user with approval requests until one is accidentally approved. Phishing-resistant MFA eliminates this attack vector.

Common misconfiguration: Admin accounts are the primary user accounts of the IT team — the same account used for email and daily work also has Global Admin rights. The correct model is a separate, cloud-only account used exclusively for admin tasks, with no mailbox and phishing-resistant MFA enforced. The daily-use account has standard user privileges.

NIS2 alignment: Directly addresses Article 21(2)(i) for privileged accounts.

Policy 6: Block Access for High-Risk Users

What it does: Integrates Entra ID Identity Protection's user risk scoring. Users flagged as high risk — based on signals including leaked credentials, suspicious activity patterns, and impossible travel — are blocked from accessing applications until their risk is remediated. Remediation requires MFA completion and a password reset.

Why it matters: Identity Protection continuously processes signals that individual Conditional Access policies cannot — leaked credential data from the dark web, anomalous behaviour patterns, sign-ins that are physically impossible given the user's recent location. High-risk user blocking ensures that when a compromise signal is detected, access is automatically restricted rather than requiring manual intervention.

Common misconfiguration: The policy is configured in report-only mode and never moved to enforcement. Report-only is appropriate for initial deployment to understand the impact — but it provides no protection. Move to enforcement once you have confirmed the policy scope is correct and the helpdesk has a process for handling risk remediation requests.

NIS2 alignment: Supports Article 21(2)(b) — incident handling and Article 21(2)(a) — risk management.

Policy 7: Require Approved Client Apps for Mobile Access

What it does: Ensures that access to Exchange Online email and Teams from mobile devices occurs through Microsoft-managed applications (Outlook Mobile, Teams) rather than the native iOS Mail app or any other third-party client. App Protection Policies in Intune can then be applied to these approved apps, enforcing copy-paste restrictions and remote wipe capability.

Why it matters: Native mobile OS applications, including the iOS Mail app, do not support modern authentication flows or Intune App Protection Policies. Data accessed through these applications cannot be governed — organisational email can be copied freely, and there is no mechanism for remote wipe if the device is lost. Approved client app requirements bring mobile access within the governance perimeter.

Common misconfiguration: The policy applies to all platforms, including Windows desktop. Windows desktop clients (Outlook, Teams) are already governed by Conditional Access and Intune — adding an approved client app requirement for Windows can cause issues with legitimate client scenarios. Scope this policy to iOS and Android only.

Policy 8: Session Controls for Unmanaged Devices

What it does: For users accessing Microsoft 365 from unmanaged devices (personal computers, contractor machines that are not Intune-enrolled), applies session controls via Microsoft Defender for Cloud Apps: download blocking for sensitive documents, clipboard restrictions, and sign-out after inactivity.

Why it matters: Some legitimate use cases require access from unmanaged devices — contractors, partners, users accessing from a personal machine during travel. Blocking access entirely may not be appropriate. Session controls allow read-only or limited interaction with organisational data from unmanaged devices without the risk of data being downloaded to uncontrolled endpoints.

Common misconfiguration: Session controls are applied to all applications, which causes performance issues and user experience friction. Scoped session controls — applied only to SharePoint and OneDrive, where document download is the primary risk — deliver the security outcome with minimal friction.

The Common Gap: MFA Enabled vs. MFA Enforced

Across every organisation where Conditional Access policies are reviewed as part of a broader security assessment, the same gap appears with remarkable frequency: MFA is enabled in the tenant settings, but it is not enforced via Conditional Access. IT reports that MFA is in place. The reality is that a percentage of users — typically 10–30% — have never completed MFA registration and are signing in without it. The tenant settings show MFA as enabled because that is the configuration. Conditional Access would show the reality.

The fix is straightforward: implement Policy 1 above in report-only mode for two weeks to see which users would be blocked, remediate the non-enrolled users, then move to enforcement. The entire process typically takes three to four weeks and immediately improves the organisation's security posture.

Conditional Access Is a Living System

These eight policies are a baseline, not a final state. The threat landscape changes. New attack vectors emerge. Your organisation's access patterns evolve as you add remote workers, new office locations, contractor programmes, and new applications.

Conditional Access policies require quarterly review: are all Named Locations current? Are there new administrative roles that need coverage? Have any emergency exclusions been added and not removed? Are the sign-in risk and user risk thresholds still calibrated correctly?

Organisations that treat Conditional Access as a configuration milestone — something to set up once and move on from — will find that it drifts out of alignment with both their environment and the threat landscape within 12 months. Those that treat it as a control to be regularly reviewed maintain a posture that genuinely reflects current risk. The investment is not large: one structured review session per quarter, with documented outputs.

If you want an independent review of your current Conditional Access policy set, our security hardening and Zero Trust assessments include a full CA audit as a standard component.