Conditional Access deployment across Microsoft 365 and federated apps

A Conditional Access deployment needs Microsoft Entra ID P1 for the users it protects, and Entra ID P2 only for policies that use sign-in risk or user risk. It replaces security defaults rather than adding to them, because the two cannot run side by side. Microsoft’s own deployment plan rolls the core policies out in three phases across about four weeks, each policy in report-only mode for at least a week before it is switched on, with emergency access accounts excluded before anything is enforced.

Federated apps, meaning the SAML and OpenID Connect enterprise applications that sign users in through Entra ID, come under the same policies as Microsoft 365. Linked apps, apps still signed in by another identity provider, and service principals do not. The effort and the cost follow from that inventory: how many users lack the licence, how many apps authenticate somewhere else, how much legacy authentication is still in use, and whether your devices are managed well enough to count as a control. This guide follows Microsoft’s documentation as it stood on 2 November 2026.

What a Conditional Access deployment needs licensed

Microsoft’s Conditional Access overview is plain about the floor: “Using this feature requires Microsoft Entra ID P1 licenses.” Business Premium is covered too: “Customers with Microsoft 365 Business Premium licenses can also use Conditional Access features.” Risk-based policies need more, because sign-in risk and user risk come from ID Protection, “a Microsoft Entra ID P2 feature”. Other controls inside a policy bring their own licence requirements.

P1 may already be in your tenant through a suite. Microsoft’s licensing page lists it inside Microsoft 365 E3, E5, E7, F1 and F3, Enterprise Mobility + Security E3 and Business Premium. P2 comes with Microsoft 365 E5 and E7, Microsoft Defender Suite and Enterprise Mobility + Security E5. Bought standalone, Microsoft’s US Entra pricing page listed P1 at $7.00 and P2 at $10.00 per user per month as US list prices, paid yearly, when checked on 2 November 2026. Before buying anything, a licence review of who already holds which plan is worth doing first, and whether the Entra Suite is worth taking through Microsoft 365 E7 is the subject of our E7 licensing article.

One licensing detail matters for planning a lapse or a downgrade. “When the licenses required for Conditional Access expire, policies aren’t automatically disabled or deleted.” They stay in force, and “You can view and delete remaining policies, but you can’t update them.”

Security defaults or Conditional Access: one or the other

Security defaults are Microsoft’s free baseline. Switched on, they require every user to register for multifactor authentication, require administrators to use it, prompt users when Microsoft judges it necessary, block legacy authentication, block device code flow and require MFA for the Azure portal, Entra admin center, Azure PowerShell and Azure CLI. Tenants created on or after 22 October 2019 might have them on already, and from 1 July 2026 every new tenant blocks device code flow as part of them.

The limit is that they are on or off, with no customisation: no exclusions you control and no targeting. Microsoft’s view is that if you hold P1 or P2, security defaults “are probably not right for you”. And the two cannot be combined. The deployment plan says so directly: “Conditional Access and security defaults aren’t meant to be combined because creating Conditional Access policies prevents you from enabling security defaults.”

So the move is a cutover, not a layering. Microsoft’s guidance is to turn on Conditional Access policies immediately after disabling security defaults, and it points to Microsoft-managed policies that keep the same four protections: blocking legacy authentication, MFA for Azure management, MFA for admins and MFA for all users. Treat the switch as one change. The moment security defaults go off, the tenant has only what Conditional Access is enforcing.

Microsoft-managed policies may already be in your tenant

In an eligible tenant, a Conditional Access deployment may not start from an empty policy list. Microsoft creates Microsoft-managed policies directly in eligible tenants, in report-only state, and “Microsoft enables these policies no less than 30 days after they’re introduced in your tenant if they’re left in the Report-only state.” Customers are told by email and Message center post two weeks before. In some cases a policy is switched on sooner than 30 days, and Microsoft says so in those notices and in the policy details.

The current list includes blocking legacy authentication, blocking device code flow, MFA for admins accessing Microsoft admin portals, MFA for all users, MFA for per-user MFA users, MFA and reauthentication for risky sign-ins, blocking and remediating high-risk users, phishing-resistant authentication for admins, and a preview policy for high-risk agents. Eligibility follows licensing: the admin portal MFA policy applies to P1 and P2 tenants without security defaults, while the risky sign-in policy targets P2 tenants.

You can change a managed policy’s state and its exclusions, and nothing else. They cannot be renamed or deleted, and Microsoft’s advice for anything more is to duplicate the policy and edit the copy. Two related policies can also be created through Baseline security mode in the Microsoft 365 admin center, by an administrator rather than by Microsoft. They show “Baseline security mode” in the Created by column and are managed from that admin center instead.

The practical consequence: the first task of any rollout is an inventory. Check the Created by column in the policy list, record what Microsoft has already put there and when it will switch on, and exclude your emergency access accounts from those policies as you would from your own. If the tenant still shows classic policies, they “stopped enforcing controls after July 10, 2024”, according to Microsoft’s policy templates page, and need rebuilding as modern policies.

Plan before you build

Microsoft’s deployment plan starts with prerequisites that are easy to skip: a non-admin test user and a group containing it, the Security Reader role to read policies and Conditional Access Administrator to create them, and a communication plan telling users what changes, when, and where to get help.

For each policy it then asks you to record answers before creating it: which users, groups, roles or workload identities are in and out; which apps, user actions or authentication contexts it targets; which conditions apply, such as device platform, network location, client app type, device filters or risk; and which grant and session controls it enforces.

How policies combine

Two behaviours shape the design more than any single setting. First, every policy that applies must be satisfied, so a user caught by one MFA policy and one compliant-device policy needs both. Second, the gap: “Access tokens are issued by default if a Conditional Access policy condition doesn’t trigger an access control.” Microsoft’s example is a payroll app with an MFA policy for the finance group. Users outside that group are not blocked by it; they get a token without MFA. Keeping them out takes a second policy that blocks everyone except finance.

That is why Microsoft recommends that every app sits under at least one policy, ideally one that targets All resources, so a newly onboarded app is covered without anyone editing a policy. The same page adds a warning: “Be careful when using block and all resources in a single policy.” That combination can lock out administrators, and some endpoints, Microsoft Graph among them, cannot be excluded.

Keep the policy set small and owned

“Conditional Access has a limit of 240 policies per tenant”, and the count includes policies that are off or in report-only. Microsoft’s advice is to group apps with the same requirements for the same users into one policy, and to include users by group or role rather than by name. Policies have no built-in owner field, so the plan suggests encoding ownership in the policy name and keeping a separate register of which team owns which policy. It also recommends protected actions, so that creating, changing or deleting a policy needs fresh authentication, and managing policies as code through the Microsoft Graph API with source control, so every change is reviewable and reversible.

The naming standard Microsoft proposes carries a sequence number, the apps, the response, who it applies to and when. It extends to contingency policies that sit disabled until an outage, named with “ENABLE IN EMERGENCY” at the front and an order for switching them on.

Microsoft’s three phases

Microsoft’s plan deploys a core set of policies in three phases. Many of them are available as templates, which are created in report-only mode by default.

Microsoft says the timelines can be adjusted for size, complexity and change management capability, and attaches two conditions that can stretch them: “Enable each policy in report-only mode for at least one week before enforcement”, and users must have registered the authentication methods a policy will demand before it is enforced. Of the last item in Phase 3 it is blunt: “Privileged Access Workstations (PAW) require significant infrastructure planning.”

Emergency access accounts and the exclusions that matter

Every policy design starts with the accounts it must never stop. Microsoft’s emergency access guidance asks for two or more cloud-only accounts on the *.onmicrosoft.com domain, not federated and not synchronised from on-premises, holding Global Administrator as a permanent active assignment in Privileged Identity Management rather than an eligible one.

They still need strong authentication. Mandatory MFA now applies to Azure and admin portal sign-ins, and Microsoft’s mandatory MFA page is explicit: “Break glass or emergency access accounts are also required to sign in with MFA once enforcement begins.” The recommended method is a passkey (FIDO2), or certificate-based authentication where a PKI already exists, and it should differ from the method your everyday admin accounts use.

Microsoft’s deployment plan says to verify they are excluded from all policies; its emergency access page is more precise. Exclude them, through a dedicated group, from any policy that blocks or restricts sign-in, because an enforced policy “could prevent sign-in during the exact emergency the account is designed for”. Report-only policies are different: “Report-only policies don’t block access and don’t need to exclude emergency accounts.” Then test the accounts against the live policy set at least every 90 days, and alert on every sign-in. Our CSP comparison covers what an administrator lockout means when Microsoft support runs through a partner.

Three other exclusion points need attention:

• Templates exclude only you. “Conditional Access template policies targeting users exclude only the user creating the policy from the template.” Add the emergency group to every template policy by hand.
• Service accounts are not covered by user policies. “Calls made by service principals aren’t blocked by Conditional Access policies scoped to users.” Policies for service principals need workload identity licences, and user accounts used as service accounts should move to managed identities or other workload identities. Mandatory MFA makes that more urgent, since those accounts must now complete MFA to create, update or delete Azure resources.
• Every other exclusion is a gap to manage. Microsoft’s instruction is to “Use exclusions sparingly, only in situations where the user is trusted”, and to add users back as soon as possible.

Test with report-only mode and the What If tool

Report-only mode evaluates a policy at every sign-in without enforcing it, and logs the result on the Report-only tab of each sign-in event: success, failure, user action required, or not applied. It cannot evaluate policies scoped to user actions, such as registering security information. A policy impact view shows the effect on interactive sign-ins over 24 hours, 7 days or a month.

One trap is specific to device controls. A report-only policy that requires a compliant device can still prompt users on macOS, iOS and Android to pick a device certificate, repeatedly, even though nothing is enforced. Microsoft’s advice is to exclude those platforms from report-only compliance policies until you enforce.

The What If tool answers a different question: which policies would apply to one user, agent or service principal signing in to one app under stated conditions. It needs the identity, target resource, device platform and client app, and works by App ID, so app groupings such as Office 365 do not match. It also has a stated blind spot: “The What If tool doesn’t test for Conditional Access service dependencies.” A What If run for Teams, for example, ignores policies on Exchange Online, which Teams depends on.

Neither replaces a real test. Microsoft’s plan says a simulation “doesn’t replace an actual test run in a properly configured development environment”, and asks you to test the exclusions too, because another policy may still prompt an excluded user. If a policy misbehaves after enforcement, disable it or exclude the affected users; deleted policies can be restored within a 30-day soft-delete period.

Block legacy authentication first

In our experience, the thing a Conditional Access deployment most often finds first is legacy authentication still in use, from old mail clients, devices or scripts, before a single policy is written. It is why we start with the sign-in logs rather than the policy editor.

Legacy protocols cannot do MFA, so, as Microsoft’s security defaults page warns, an attacker can sign in through them and bypass multifactor authentication. Microsoft’s legacy authentication guidance gives the reason in numbers: “more than 97 percent of credential stuffing attacks use legacy authentication and more than 99 percent of password spray attacks use legacy authentication protocols.”

The policy itself is simple: all users, all resources, client apps set to Exchange ActiveSync clients and Other clients, grant set to block. Finding what depends on legacy authentication before you enforce it is the work. Filter the sign-in logs by client app for the legacy protocols, on both the interactive and the non-interactive tabs, and use Microsoft’s legacy authentication workbook to triage. Microsoft links separate instructions for multifunction devices and applications that send email through Microsoft 365, and its mandatory MFA page notes that the resource owner password credentials (ROPC) flow “is incompatible with MFA”, so any automation still using it breaks when MFA reaches the account.

Use authentication strengths for the accounts that matter

“Require multifactor authentication” accepts any MFA combination the tenant allows, text messages included. Authentication strengths let a policy say which methods count. There are three built-in strengths, MFA, passwordless MFA and phishing-resistant MFA, and the phishing-resistant one accepts Windows Hello for Business or platform credential, a FIDO2 security key, or multifactor certificate-based authentication. Custom strengths can be built on top.

Three limitations shape how they are used. A strength is checked after the first sign-in step, so “an authentication strength doesn’t restrict a user’s initial authentication”. “You can’t use the Require multifactor authentication and Require authentication strength grant controls together in the same Conditional Access policy.” And guests signing in with an email one-time passcode cannot satisfy a strength, which matters for partner access to federated apps. For partner organisations you trust, cross-tenant access settings can accept MFA performed in the guest’s home tenant.

Strengths are where Microsoft’s Phase 1 starts for privileged roles. Combined with authentication context, they can also step up a single sensitive action, such as opening a protected SharePoint site or activating a role in Privileged Identity Management, without forcing the stronger method on every sign-in.

Device-based controls

Requiring a compliant device depends on work outside Conditional Access. “Devices must be registered in Microsoft Entra ID before they can be marked as compliant”, and Microsoft’s compliant device policy guide warns: “Without a compliance policy created in Microsoft Intune, this Conditional Access policy won’t function as intended.” The control supports Windows 10 and later, iOS, Android, macOS and Linux Ubuntu devices registered with Entra ID and enrolled in Intune, and treats Edge InPrivate on Windows as noncompliant.

For estates not ready to require compliance from everyone, Microsoft suggests intermediate policies: a compliant or hybrid joined device for administrators, and a compliant device, hybrid joined device or MFA for all users. We would not enforce compliant-device policies until Intune compliance is mature; until then, “compliant device or MFA” is the interim. On mobile, the grant controls page says the approved client app grant was retiring in early March 2026, and that new policies should use the app protection policy grant only.

Two cautions. The device platform condition is not a security boundary: Microsoft’s policy building guide says it “comes from unverified sources, like user agent strings that can be changed”. And device-based grants cannot be satisfied through device code flow, because the device completing sign-in is not the device asking for access. For partner organisations you trust, cross-tenant access settings can accept their device compliance claims instead.

How federated apps come under Conditional Access

Any application integrated with Entra ID can be a policy target. Microsoft’s target resources page lists gallery apps, custom non-gallery apps, apps published through application proxy, legacy apps published through app delivery controllers, and apps using password-based single sign-on. So a SAML or OpenID Connect app comes under Conditional Access the day it is configured to sign users in through Entra ID, and a policy on All resources covers it without any edit.

In our view, that is the reason to start from one All resources baseline policy and carve out exceptions. Never build per-app policies up from nothing, because a new app then arrives unprotected.

A few mechanics matter when you add apps at scale:

• Policies apply to the resource, not the client. “Conditional Access applies to resources not clients, except when the client is a confidential client requesting an ID token.” A policy on a web app’s API applies to every client calling it.
• Some apps are invisible in the picker. “Some applications don’t appear in the picker at all.” They are covered by an All resources policy, or by adding their service principal through PowerShell or Microsoft Graph.
• Exclusions on All resources are tightening. From March 2026 Microsoft has been phasing out the exemption for low-privilege scopes that used to slip past an All resources policy carrying an app exclusion, so users who were never challenged may start to be.
• Filters beat lists. Tagging apps with custom security attributes and targeting by filter keeps policies short and inside their size limit as the app count grows.
• Federation adds its own upkeep. Microsoft’s SSO planning guide notes that the SAML signing certificate is valid for three years by default, and asks for named owners and a renewal process so an expiry does not become an outage.

What stays outside it

Conditional Access governs what Entra ID signs in, and only that. These sit outside it:

• Linked apps. “Linked-based SSO doesn’t provide sign-on functionality through Microsoft Entra ID.” The linked option only places a tile in My Apps, and the app’s own identity provider decides who gets in.
• Apps still signed in by another identity provider, such as AD FS. They come under Conditional Access when they are moved to Entra ID, which Microsoft’s AD FS migration guidance stages through test instances, modern-protocol apps first.
• Apps with their own local accounts, where single sign-on is disabled.
• Service principals under user policies, as above. Even workload identity policies cover only single-tenant service principals: “Microsoft and third-party SaaS applications, including multitenant apps, are not covered by these policies”, and “Managed identities aren’t covered by policy.”
• The first sign-in step. “Conditional Access policies are enforced after first-factor authentication is completed.” Microsoft says it is not meant as a front-line defence against attacks such as denial of service; it acts once the first factor has succeeded.

We would not tighten policy before moving apps off AD FS or a second identity provider. A policy that half the estate bypasses gives false assurance.

Timing is a final gap. Policies are evaluated when a token is issued, and “Newly added users to a role or group aren’t subject to the policy until they get a new token.” Access tokens last an hour by default. Continuous access evaluation lets Exchange, Teams and SharePoint Online act on critical events, such as a disabled account or a password reset, in near real time, though Microsoft says “latency of up to 15 minutes might be observed because of event propagation time”. Your own changes are a different matter: tokens in those sessions can last up to 28 hours, and “Changes made to Conditional Access policies and group membership made by administrators could take up to one day to be effective.” Where a change must reach a user at once, Microsoft’s answer is to revoke that user’s sessions. How quickly a change reaches a federated SaaS app also depends on how long that app keeps its own session before it returns to Entra ID for a new token.

Monitoring once policies are on

The insights and reporting workbook shows the combined effect of enabled and report-only policies by user, app, device state, platform, location and risk, over anything from 4 hours to 90 days. It needs P1, a Log Analytics workspace receiving sign-in logs, and both the Security Reader role and Contributor rights on the workspace, and it only shows sign-ins from after the logs were connected. Connect the logs before the first policy goes into report-only, not after.

Three other views complete the picture. The Coverage tab on the Conditional Access overview “shows a summary of applications with and without Conditional Access policy coverage over the past seven days”, which is the quickest check that new federated apps are inside a policy. Policy changes are in the audit log, but “Audit log data is kept for 30 days by default”, so route it to Log Analytics or a storage account through diagnostic settings if you need a longer change history. And emergency access accounts need an alert on every sign-in, which Microsoft’s guidance illustrates with an Azure Monitor alert rule.

What drives the effort and cost of a Conditional Access deployment

Microsoft’s planning guidance gives no effort or cost figure for a Conditional Access deployment, and neither does this article. Its three-phase plan covers about four weeks of policy rollout for a core set, and says that timing flexes with size, complexity and change management capability. What its guidance does make clear is where the work sits:

1. The licence gap. Users without P1 need it, at $7.00 per user per month (US list price, paid yearly, checked on 2 November 2026), and risk-based policies need P2 for the users they cover. Guests are billed differently: “The MAU billing model for External ID applies to all guest users,” per Microsoft’s External ID pricing guide.
2. How many apps authenticate somewhere else. Apps already signed in through Entra ID are covered by an All resources policy as they stand. Apps on AD FS, another identity provider or linked sign-on each need migrating and testing first, and every SAML app adds a certificate to renew.
3. Legacy authentication still in use. Each device, mail client or script found in the sign-in logs needs replacing, reconfiguring or a deliberate, documented exclusion before the block goes on.
4. The device estate. A compliant-device policy depends on Intune compliance policies and registered devices existing first. Privileged access workstations are a project in their own right.
5. Service accounts and automation. User accounts used by scripts need moving to managed identities or other workload identities, a move that mandatory MFA makes more urgent.
6. Testing time. At least a week in report-only per policy, a non-admin test user, a written test plan and exclusion tests, phase by phase.
7. People. Communications before each phase, MFA registration before enforcement, and a help desk that knows to ask for the correlation ID.
8. Running it afterwards. Log Analytics for the workbook, a naming and ownership register under a 240-policy ceiling, Microsoft-managed policies arriving on Microsoft’s timetable, and emergency account tests every 90 days.

Read together, Microsoft’s guidance puts most of the work outside the policy editor, in the apps, protocols, devices and accounts the policies will touch. Those are the inputs an estimate has to be built from.

Where to start

Before writing the first policy, check six things:

1. What is already there. Security defaults on or off, classic policies, and any Microsoft-managed or Baseline security mode policies with their switch-on dates.
2. Who holds P1 and P2. Every user a policy protects needs P1; risk-based policies need P2 for the users they cover.
3. Emergency access. Two cloud-only accounts with passkeys, in a group excluded from every blocking or restricting policy, tested against the live set.
4. The app inventory. Which apps sign in through Entra ID, which through AD FS or another provider, which are linked, and which keep local accounts.
5. Legacy authentication. What the interactive and non-interactive sign-in logs show before the block goes on.
6. Logging. Sign-in and audit logs flowing to Log Analytics before the first report-only policy.

Conditional Access governs who gets in and from what. What users can do with content once inside is a separate layer of controls, covered in our article on sensitivity label rollout defaults, the platform side of identity in Azure is part of landing zone design, and Azure platform work sits with our Azure services.

Veratas’s fixed-price Microsoft 365 Security Baseline, from $5,000, covers designing, testing in report-only mode and rolling out a foundational Conditional Access policy set for a standard single-tenant estate, with two emergency access accounts set up and verified, alongside core Microsoft 365 and Defender baseline hardening. Bringing devices into Intune compliance before a compliant-device policy, session policies through Conditional Access App Control, cutovers from a third-party identity provider and policy sets spanning several subsidiaries are quoted separately, and Entra ID P1 licences are billed on top of the fee. The full scope is on our security and compliance page, alongside our wider Microsoft 365 services. If you are planning a Conditional Access deployment, or inheriting policies nobody has reviewed since they were switched on, talk to our team.

Frequently asked questions

Does Conditional Access need Entra ID P2? No. Conditional Access needs Microsoft Entra ID P1, which is included in Microsoft 365 E3, E5, E7, F1, F3 and Business Premium. P2 is needed only for policies that use sign-in risk or user risk from ID Protection. Requiring a compliant device also needs Intune (or, for Windows, a supported partner), and policies for service principals need Workload Identities Premium.

Can security defaults and Conditional Access run together? No. Microsoft says the two are not meant to be combined, and creating Conditional Access policies prevents you from enabling security defaults. When you disable security defaults, Microsoft’s guidance is to enable Conditional Access policies immediately, and its managed policies cover the same protections.

How long does a Conditional Access deployment take? Microsoft’s deployment plan puts the core policies into three phases across about four weeks, with each policy in report-only mode for at least a week before enforcement, and says organisations can adjust that to their size and complexity. Migrating apps from other identity providers, removing legacy authentication and setting up device compliance come on top.

Do Conditional Access policies apply to SAML and OpenID Connect apps? Yes, when Entra ID is the app’s identity provider. Gallery and custom enterprise apps using SAML or OpenID Connect can be targeted individually or covered by a policy on All resources. Linked apps, apps still signed in by AD FS or another provider, and apps with their own local accounts are outside Conditional Access.

Should emergency access accounts be excluded from every policy? From every policy that blocks or restricts sign-in, yes, ideally through a dedicated group. Report-only policies do not need the exclusion, because they never block. The accounts still need MFA, since mandatory MFA applies to them, and Microsoft recommends a passkey or certificate-based authentication, tested at least every 90 days.

Gaurav Aggarwal

Cloud and enterprise architect with 17 years of experience across data platforms, integration and application development. Focus areas include Azure architecture, cloud-native application design, and ERP to data platform integration.