Conditional access policies in Microsoft Entra ID evaluate identity signals, device state and risk context at every sign-in, then grant, block or restrict access based on rules you define. They are the identity layer of a Zero Trust architecture. But identity-layer controls cover only half the access surface. The other half, network-level access to internal applications, on-premise resources and non-Microsoft services, falls to SASE-platform ZTNA. For mid-market IT teams running 50 to 400 users, the strategic question in 2026 is how to coordinate both layers so that a single identity context drives every access decision, from Microsoft 365 to your on-premise ERP, without maintaining two disconnected policy sets.
What are conditional access policies in 2026?
Conditional access policies are if-then rules in Microsoft Entra ID that evaluate signals (user identity, group membership, device compliance, location, sign-in risk) and enforce controls (require MFA, require a compliant device, block access, limit session duration) before granting access to cloud applications and resources. In 2026, conditional access has expanded beyond static rule evaluation into AI-assisted policy optimisation, phased rollout capabilities, and enforcement of policies against AI agent identities. The scope has widened, but the core logic remains: collect signals, evaluate against policy, enforce a decision. What conditional access does not cover is network-level access. Applications that sit behind your firewall, industrial control systems, custom web applications on private infrastructure, and legacy services that predate cloud identity, all require a complementary enforcement layer that operates at the network level.
Conditional access fundamentals
The conditional access engine operates on three phases. First, signal collection: Entra ID gathers identity signals (user, group, role), device signals (compliance state from Intune, OS version, encryption status), location signals (IP, named locations), application context (which resource is being accessed) and risk signals (sign-in risk and user risk from Entra ID Protection). Second, policy evaluation: all applicable policies are evaluated simultaneously. If a user falls under multiple policies, every condition must be met. A policy requiring MFA and a separate policy requiring a compliant device mean the user satisfies both before access is granted. Third, enforcement: the engine blocks access, grants access with controls (MFA, device compliance, authentication strength), or applies session controls (limited session duration, app-enforced restrictions, continuous access evaluation).
For setup specifics, licensing detail and step-by-step configuration, Microsoft Learn remains the authoritative source. This guide focuses on the coordination architecture that Microsoft’s own documentation does not address: how conditional access works alongside SASE-platform ZTNA to deliver unified policy enforcement across identity and network layers.
The 2026 conditional access landscape
Three developments between January and May 2026 have reshaped what conditional access can do.
The Conditional Access Optimization Agent became generally available through Microsoft Security Copilot. It scans your tenant continuously, identifies users, applications and AI agent identities not covered by existing policies, and suggests targeted fixes. The agent evaluates whether MFA is enforced, whether device-based controls are active, whether legacy authentication is blocked, and whether similar policies can be consolidated. Each scan consumes less than one security compute unit. Phased rollout support means you can deploy policy changes gradually across user groups rather than enforcing tenant-wide in one step. A passkey adoption campaign feature assesses device and user readiness for phishing-resistant authentication and generates a rollout plan. The Optimization Agent requires Entra ID P1 at minimum. Full risk-based policy capabilities require P2 or Microsoft 365 E5.
The all-resources enforcement change closes a bypass that existed for years. When a conditional access policy targeted “All resources” with one or more resource exclusions, sign-ins requesting only basic OIDC scopes (openid, profile, email) or limited directory scopes (User.Read) were silently exempt from policy enforcement. Tools like Azure CLI, Visual Studio Code and custom applications using these minimal scopes bypassed MFA and device compliance checks entirely. Microsoft announced the fix in January 2026, began enforcement on 13 May 2026, and will complete the progressive rollout by mid-summer 2026. IT teams with custom applications that request only baseline scopes need to verify these applications can handle conditional access challenges before enforcement reaches their tenant.
AI agent identities are now first-class actors in the Entra ID ecosystem. Microsoft Entra Agent ID provides registration, lifecycle management and governance for AI agents that act on behalf of users. Conditional access policies can target these identities through on-behalf-of flows, applying the same controls (MFA, device compliance, risk evaluation) that apply to human users. The Optimization Agent monitors agent identities for excessive permissions and recommends least-privilege adjustments. For organisations deploying Microsoft 365 Copilot, custom AI assistants or third-party agent frameworks, governing these identities through conditional access is no longer optional.
The highest-impact policies for mid-market teams
For organisations with 50 to 400 users, a small number of well-configured policies delivers the majority of risk reduction. Complexity is the enemy of security in the mid-market, and policy sprawl creates more gaps than it closes.
Phishing-resistant MFA for all users. The 2026 baseline is passkeys or FIDO2 security keys, not SMS or authenticator app push notifications. Adversary-in-the-middle (AiTM) attacks intercept traditional MFA tokens in real time. Phishing-resistant methods eliminate this vector entirely. The Optimization Agent can assess your tenant’s readiness and generate a phased rollout plan.
Block legacy authentication protocols. IMAP, POP3 and SMTP basic authentication do not support MFA and remain primary targets for password spraying. A single policy blocking these protocols across all users closes one of the simplest attack paths.
Require compliant devices for corporate data. Tie access to Microsoft 365 resources (SharePoint, Teams, Outlook, OneDrive) to Intune compliance state. Only devices with current OS versions, active disk encryption and running endpoint protection gain access. This prevents data leakage to unmanaged personal devices without blocking BYOD entirely, because browser-based access with session restrictions remains available as a fallback.
Risk-based controls for privileged accounts. Global Administrators, Security Administrators and other privileged roles require MFA at every sign-in and automatic blocking when Entra ID Protection detects elevated user risk. Separate these into a dedicated policy rather than relying on the baseline MFA policy.
Block access from untrusted geographies. Named location policies that restrict sign-ins to countries where your organisation operates filter a significant volume of automated attack traffic. IP-based location is not foolproof, but it raises the cost of credential abuse substantially.
Protect administrative portals. Access to the Azure Portal, Entra Admin Center and Microsoft 365 Admin Center deserves its own policy requiring both a compliant device and phishing-resistant MFA. Administrative interfaces are high-value targets that warrant stricter controls than general user access.
The licensing tier matters. Microsoft 365 E3 includes Entra ID P1, which provides conditional access with device compliance, MFA enforcement and named locations. Microsoft 365 E5 adds Entra ID P2, which enables risk-based policies (sign-in risk and user risk), the full capabilities of the Optimization Agent, and Entra ID Protection. For organisations that need risk-based controls, token protection and full AI-assisted optimisation, E5 delivers meaningful security value above E3.
Common deployment mistakes and how to avoid them
Lockout through over-broad blocking. A policy set to “All users, All resources, Block” without exclusions locks everyone out if MFA services experience an outage or a configuration error affects all administrators. Maintain at least two emergency access accounts (break-glass accounts) excluded from all conditional access policies. These accounts use extremely long, unique passwords stored physically offline and are monitored through Entra ID audit logs for any sign-in activity.
Exception sprawl. Policies accumulate exclusions over time: a contractor who needed temporary access, a legacy application that could not handle MFA, a service account that nobody documented. Each exclusion is an unmonitored access path. The Optimization Agent identifies these gaps automatically, but you still need a quarterly review process that examines every exclusion and either removes it or documents the business justification.
Naming chaos. When 30 policies have names like “Test MFA policy” and “New policy – copy”, troubleshooting becomes guesswork. Adopt a structured naming convention: CA[number]-[scope]-[action]-[condition]. For example: CA001-AllUsers-RequireMFA-PhishingResistant. Use Report-only mode for at least one week before enforcing any new policy, and review the Conditional Access Insights workbook to understand the impact before switching to enforcement.
Missing continuous access evaluation. A token issued at 9:00 with a one-hour lifetime gives an attacker who steals that token a full hour of access. Continuous access evaluation (CAE) enables near-real-time revocation when critical events occur: password reset, account disable, network location change, or compliance state change. Verify that CAE is enabled for your critical policies rather than relying solely on token lifetime controls.
Conditional access and ZTNA: complementary policy layers
This is where most guidance stops, and where the coordination gap begins. Conditional access controls the identity layer: it decides whether a user with a specific device in a specific context can access a Microsoft 365 application or a registered SaaS service. SASE-platform ZTNA controls the network layer: it decides whether that same user can reach an internal application, a private web service, a database server, or an OT management interface.
Both layers consume the same identity context. Jimber’s SASE platform authenticates against Entra ID as the identity provider. The same user identity, group membership and device compliance state that conditional access evaluates at the Microsoft 365 boundary also drives ZTNA access decisions at the network boundary. There is no separate identity store to maintain, no credential synchronisation to manage, and no policy duplication to keep aligned.
The practical coordination works as follows. Conditional access governs Microsoft 365 and registered SaaS applications. When an IT manager signs into Teams, Entra ID evaluates the conditional access policies. Jimber’s ZTNA governs internal applications, private web services and on-premise resources. When the same IT manager connects to the on-premise ERP system, the SASE platform evaluates the Entra ID identity context and applies its own access policies. Both decisions reference the same device compliance state from Intune. If a laptop fails its compliance check, conditional access blocks Teams access and the SASE platform blocks ERP access simultaneously. No gap, no inconsistency.
This coordination extends to logging and audit trails. Entra ID logs identity-level events: who authenticated, what MFA method was used, which risk signals were present, which policy granted or blocked access. Jimber’s platform logs network-level events: which internal application was accessed, from which source IP, through which ZTNA connection, with which encryption parameters. Combined, these logs provide the complete access picture that neither system delivers alone.
For organisations managing agentless devices, printers, IoT sensors, industrial equipment, the coordination has a third dimension. These devices cannot participate in Entra ID authentication. Jimber’s NIAC hardware provides inline isolation at the network level, enforcing access controls for devices that sit outside the conditional access boundary entirely. The identity layer handles users and managed endpoints. The SASE platform handles everything else.
NIS2 audit evidence from conditional access and SASE
NIS2 Article 21 requires “appropriate and proportionate technical, operational and organisational measures” for risk management, explicitly including access control policies, multi-factor authentication, and continuous monitoring. Conditional access generates direct evidence for several of these requirements.
Access control documentation comes from conditional access policy exports showing least-privilege enforcement: which users access which resources under which conditions. MFA enforcement evidence comes from Entra ID sign-in logs confirming that multi-factor authentication was required and completed for every access to systems within scope. Supply chain access controls come from guest access policies that restrict external partner permissions and enforce device compliance for B2B collaboration.
Where conditional access evidence falls short is at the network level. NIS2 also requires network segmentation, incident detection and response capabilities, and monitoring of lateral movement. These are network-layer controls that Entra ID does not provide. A SASE platform fills these gaps. Jimber’s centralised logging captures network-level access events alongside identity-level events, providing the combined audit trail that NIS2 inspectors expect. Device posture verification, network segmentation through microsegmentation policies, and incident containment through inline isolation all generate compliance evidence that conditional access alone cannot produce.
For Belgian organisations preparing for CyberFundamentals verification, the combination is particularly relevant. CyFun controls under the Protect function map directly to device posture checks, identity-based access and network segmentation. The NIS2 compliance checklist for IT managers covers what the Centre for Cybersecurity Belgium expects to see.
Where conditional access is heading in 2026
Continuous access evaluation is becoming the default session model. Rather than relying on token lifetimes measured in hours, CAE enables near-instant session termination when security-relevant events occur. The window of opportunity for attackers using stolen tokens shrinks from 60 minutes to seconds.
Passkeys and FIDO2 adoption is accelerating in the mid-market, supported by the Optimization Agent’s passkey deployment campaigns. As phishing-resistant authentication becomes the floor rather than the ceiling, traditional MFA methods (SMS, push notification) will increasingly be treated as insufficient for regulated environments.
AI-assisted policy governance through the Optimization Agent will expand beyond gap identification into predictive policy recommendations based on sign-in pattern analysis and threat intelligence. The March 2026 enhancements already include context-aware recommendations, deep gap analysis and Zero Trust posture reporting.
Identity and network policy convergence is the longer-term trajectory. The distinction between “did the identity check pass” and “is the network path secure” is an implementation artefact, not a security principle. Platforms that unify both evaluations against a single identity context, applying conditional access at the cloud boundary and ZTNA at the network boundary, deliver the architecture that the next generation of access control requires. For IT managers evaluating their 2026 security architecture, the question is not whether to deploy conditional access or ZTNA. Both are necessary. The Zero Trust architecture guide covers how these layers fit together in a comprehensive model.
Frequently asked questions
What are conditional access policies in 2026?
Conditional access policies are if-then rules in Microsoft Entra ID that evaluate identity signals, device state and risk context at sign-in, then enforce controls such as MFA, device compliance or session restrictions before granting access to cloud applications and resources. In 2026, they also cover AI agent identities and benefit from AI-assisted optimisation through the Conditional Access Optimization Agent.
What is the Conditional Access Optimization Agent?
The Optimization Agent is an AI-powered agent in Microsoft Security Copilot that continuously scans your Entra ID tenant for policy gaps, uncovered users, applications and AI agent identities. It recommends new policies, suggests consolidation of existing ones, supports phased rollout of changes, and can generate passkey adoption campaigns. It requires Entra ID P1 at minimum and consumes security compute units.
How does conditional access work with SASE platforms like Jimber?
Conditional access governs access to Microsoft 365 and registered SaaS applications at the identity layer. Jimber’s SASE platform governs access to internal applications, private resources and agentless devices at the network layer. Both consume the same Entra ID identity context, so device compliance and user identity drive access decisions consistently across cloud and on-premise resources without maintaining separate policy sets.
What changed for conditional access enforcement in 2026?
Microsoft began enforcing conditional access policies against sign-ins using only basic OIDC scopes (openid, profile, email) and limited directory scopes (User.Read) from 13 May 2026. Previously, these sign-ins bypassed policies targeting “All resources” when resource exclusions were present. The change closes a long-standing enforcement gap that allowed tools like Azure CLI to avoid MFA requirements.
Does conditional access satisfy NIS2 Article 21 requirements?
Conditional access provides evidence for identity-based access control and MFA enforcement, which are explicit NIS2 requirements. It does not satisfy network-level requirements such as network segmentation, lateral movement monitoring and incident containment. Meeting the full scope of Article 21 requires combining identity-layer controls with network-layer controls from a SASE platform.
Conditional access vs ZTNA: are they the same thing?
They are complementary, not identical. Conditional access evaluates identity and device context at the cloud application boundary. ZTNA evaluates identity context at the network boundary, granting per-application access to internal resources without exposing the broader network. Conditional access decides whether you can open Teams. ZTNA decides whether you can reach the on-premise ERP server. Both enforce Zero Trust principles at different layers of the access stack.
Ready to see how identity-based access coordinates across cloud and on-premise resources for your environment? Book a demo and walk through how Jimber’s SASE platform works alongside Microsoft Entra ID to deliver unified policy enforcement without duplicating identity management.
