In the previous post, we looked at Conditional Access architecture: how policies are evaluated, how scopes and exclusions interact, how to structure the policy set, and how to test changes without creating unexpected results. This time, we move from architecture to maturity.
A mature Conditional Access environment is not simply one with more policies. It is one where broad protections are applied consistently, stronger controls are added where the risk justifies them, and identity, device, application, and risk signals are combined without turning the policy set into something nobody wants to maintain.
This post looks at the policies we would expect to see as a Microsoft 365 environment matures: baseline protection, phishing-resistant and passwordless authentication, risk-based access, device and application controls, Token Protection, and finally how to keep the policy set manageable as it grows.
Licensing Note
Microsoft Entra Conditional Access requires Microsoft Entra ID P1 and is also included with Microsoft 365 Business Premium.
Risk-based Conditional Access using Microsoft Entra ID Protection requires Microsoft Entra ID P2. Device compliance and app protection policies normally rely on Microsoft Intune.
Token Protection requires Microsoft Entra ID P1. Its supported platforms, applications, and resources still vary, so the current Microsoft support matrix should be reviewed before enforcement.
From Architecture to a Mature Policy Set
There is no single Conditional Access policy set that fits every organisation. A cloud-only startup with managed laptops, a large hybrid enterprise, and an organisation with thousands of unmanaged mobile devices will not end up with exactly the same policies.
The underlying principles should still be similar.
A mature environment normally starts with broad controls that apply to almost everyone. Stronger requirements are then added for privileged identities, risky users or sign-ins, sensitive applications, and specific device scenarios.
The objective is not to create a new policy every time a new risk appears. Start with broad protection, then add targeted policies where the security requirement genuinely differs.
The persona-based numbering model discussed in the previous post is useful here. Global policies can use the CA001-CA099 range, administrator policies CA100-CA199, internal users CA200-CA299, and so on.
This is an example, not a baseline to import blindly. The exact scopes depend on the applications, authentication methods, devices, guest access model, and business requirements in the tenant. The important part is that the policy set has a clear structure and that every policy has a reason to exist.
Start with a Consistent Baseline
Before adding sophisticated risk or device conditions, the basic protections need to be consistent.
For most Microsoft 365 environments, MFA should broadly protect user access. Legacy authentication should be blocked, privileged identities should use stronger authentication, emergency access accounts should be handled deliberately, and unsupported platforms should not silently fall outside the intended controls.
For administrators, generic MFA is no longer where we would stop. Microsoft recommends phishing-resistant authentication methods for privileged access, and Conditional Access authentication strengths allow that requirement to be enforced.
Device code flow also deserves attention. Microsoft recommends getting as close as possible to a unilateral block and only allowing it for documented scenarios where it is genuinely required.
That does not mean enabling a block policy without checking existing usage. Some constrained devices and specific authentication scenarios can still depend on device code flow. Existing usage should be identified and understood first. Sessions originally established through device code flow are protocol-tracked, so blocking the flow can also affect those existing sessions during subsequent token refreshes, potentially resulting in loss of access or complete device sign-out. If the policy is later disabled or moved back to Report-only, affected users might still need to obtain a fresh token before the device works again.
This creates a sensible maturity path:
MFA for broad user access > phishing-resistant authentication for privileged access > broader passwordless and phishing-resistant adoption where practical.
The baseline should also use broad resource coverage where possible.
If MFA is a tenant-wide requirement, protecting All resources avoids leaving a newly added enterprise application outside the policy simply because nobody remembered to add it. Application-specific policies still make sense when the requirement genuinely differs. They should be created for a security reason, rather than becoming the default design pattern.
Move Beyond Generic MFA
MFA is essential, but not all MFA methods provide the same protection. A password combined with SMS can satisfy MFA. So can a password combined with an authenticator notification. FIDO2 security keys, Windows Hello for Business, and certificate-based authentication can provide much stronger resistance against phishing.
Conditional Access authentication strengths let you make that distinction. Microsoft currently provides three built-in strengths:
Multifactor authentication
Passwordless MFA
Phishing-resistant MFA
Passwordless MFA requires an authentication method that does not rely on a password. Microsoft Authenticator phone sign-in is one example.
Phishing-resistant MFA is more restrictive. Supported methods include FIDO2 security keys (passkeys), Windows Hello for Business or platform credentials, and certificate-based authentication.
For privileged identities, we would normally move towards phishing-resistant MFA rather than treating every MFA method as equivalent. For normal users, the transition can be gradual. A broad MFA policy can remain in place while passwordless methods are introduced. Stronger authentication strengths can then be required for sensitive applications or specific user populations.
That transition is becoming increasingly important. Microsoft is retiring Microsoft-provided SMS and voice authentication on 1 February 2027 for most users, followed by Global Administrators and external users on 1 July 2027. Since 1 September 2026, users enabled for SMS or voice have also been brought into Microsoft's passkey migration experience.
Organisations that still have a legitimate business, regulatory, or technical need for SMS or voice will be able to configure a telephony provider through the Microsoft Security Store, with provider configuration becoming available from 30 October 2026. For everyone else, this is a good opportunity to move users towards stronger phishing-resistant authentication rather than designing new access policies around SMS or voice.
It is also important to keep the distinction from the previous post in mind:
- The Authentication methods policy determines which methods users are allowed to use.
- Conditional Access authentication strengths determine which methods are acceptable for a particular access request.
Passwordless should therefore not be treated as a project completely separate from Conditional Access. Authentication methods provide the capability, while Conditional Access determines where that capability is required.
Use Risk to Adapt the Access Decision
Static policies provide the baseline, but not every sign-in represents the same level of risk.
Microsoft Entra ID Protection provides two important signals to Conditional Access: sign-in risk and user risk.
- Sign-in risk represents the probability that a specific authentication attempt was not performed by the legitimate user.
- User risk represents the probability that the identity itself has been compromised.
They should be treated as separate scenarios. Microsoft recommends creating separate Conditional Access policies for sign-in risk and user risk rather than combining both conditions into the same policy.
Sign-in Risk
Microsoft currently recommends requiring MFA when sign-in risk is Medium or High.
The objective is to let the legitimate user prove that the suspicious sign-in really belongs to them. Microsoft also recommends configuring Sign-in frequency: Every time so that the risky authentication attempt requires fresh authentication.
In environments where suitable passwordless methods are already deployed, a stronger authentication strength can be required instead of treating every MFA method as equivalent.
Risk-based authentication should complement the normal MFA baseline rather than replace it. A low-risk sign-in should not suddenly become password-only simply because no risk was detected.
User Risk
High user risk is more serious because Entra ID believes the identity itself may have been compromised.
Microsoft currently recommends Require risk remediation for High user risk.
This is particularly useful because the remediation process works with both password-based and passwordless identities.
For users with passwords, remediation can include a secure password change after strong authentication. For passwordless users, remediation can revoke their existing sessions and require authentication again.
When Require risk remediation is selected, Conditional Access automatically adds an authentication strength and the mandatory Sign-in frequency: Every time session control.
There is an important limitation: Require risk remediation is currently not supported for external and guest users. Those identities therefore need to be handled separately when designing the risk response.
Combine Device and Application Signals
Identity is only part of the access decision. A valid user signing in from a managed corporate laptop is not the same scenario as that user accessing company data from an unknown personal device.
For managed devices, Microsoft Intune compliance provides one of the strongest device signals available to Conditional Access. Compliance policies determine whether the endpoint meets the organisation's requirements. Conditional Access determines where that compliance is required.
The obvious temptation is to require a compliant device everywhere. That can be appropriate in environments where every endpoint is managed, but many organisations also have contractors, BYOD scenarios, mobile devices, or users working from customer-owned systems.
In those environments, a more targeted approach is often necessary.
For mobile BYOD, Intune app protection policies provide another option. Organisational data can be protected inside supported applications without requiring full management of the personal device.
Conditional Access can then require an app protection policy for those access scenarios. New designs should use Require app protection policy rather than the retired Require approved client app grant.
Device Platform Is Not Device Trust
Device platform conditions are useful for deciding where a policy should apply, but they should not be confused with proof that a device is trusted.
Platform information can depend on information supplied by the client and can be missing, unknown, or manipulated.
There is also a common scoping mistake. Selecting Windows, macOS, Linux, iOS, and Android does not necessarily mean every possible platform is covered. Unknown or unsupported platforms can fall outside a policy that explicitly includes only the listed platforms.
Where the objective is to block unsupported platforms, Microsoft recommends including Any device and excluding the platforms the organisation supports. Everything else is then caught by the block policy.
Use compliance or device identity when the actual security decision depends on whether an endpoint is trusted.
Protect the Session with Token Protection
Strong authentication reduces credential theft, but it does not eliminate session-token theft.
An attacker who steals a usable session token might not need the password or another MFA challenge. This is why passwordless and phishing-resistant authentication do not make token protection irrelevant. They protect different parts of the attack chain.
Token Protection is a Conditional Access session control designed to reduce token replay by requiring supported sign-in session tokens to be cryptographically bound to the device that originally received them.
If an attacker steals a supported device-bound token and attempts to replay it from another device, that request should not satisfy the Token Protection requirement.
Support Still Needs Careful Scoping
Token Protection is not something we would apply blindly to All resources.
Microsoft currently supports native application scenarios on Windows and supported Apple platforms. Android is not supported.
For native applications, supported resources include Exchange Online, SharePoint Online, and Microsoft Teams. Windows additionally supports Azure Virtual Desktop, Windows 365, and Windows Cloud Login for Windows App scenarios.
Apple has additional deployment requirements. Supported iOS, iPadOS, and macOS devices need to be managed through MDM and use the supported Microsoft Enterprise SSO or Platform SSO configuration.
Apple's native Mail and Calendar applications do not support Token Protection. If a Token Protection policy applies to the protected resources, those applications can therefore be blocked.
Browser-based Token Protection is even narrower and remains Preview. It currently supports only a limited set of Microsoft administration applications accessing Azure Resource Manager through supported browsers and managed device configurations. Unsupported web applications accessing the same protected ARM resource can be blocked when the policy is enforced.
This makes pilot testing particularly important.
For Windows native applications, Microsoft also warns against simply targeting the broad Office 365 application grouping. The policy should target the specifically supported resources and use the appropriate Mobile apps and desktop clients client-app condition.
Token Protection is valuable defence in depth, but it does not replace phishing-resistant authentication, device compliance, or identity-risk controls.
Keep the Policy Set Maintainable
Maturity eventually creates another risk: policy sprawl. The tenant starts with a handful of policies. Then administrators add stronger authentication, device compliance, mobile app protection, risk-based policies, sensitive applications, Token Protection, and business exceptions.
Over time, several policies can end up repeating the same users, exclusions, and resources with only small differences in their controls.
That is where the architecture from the previous post becomes important again.
Keep the persona-based structure consistent. Consolidate policies where the scope and requirement genuinely match. Review exclusions regularly. Remove temporary migration policies when the migration is finished.
Microsoft-managed policies should also be reviewed alongside custom policies. If Microsoft introduces a managed policy that overlaps with an existing control, maturity means understanding the overlap rather than simply keeping both forever.
Most importantly, review the policy set as a whole. If five policies all solve almost the same problem for almost the same users, creating a sixth probably is not the answer.
Conditional Access Policy Plans
Microsoft is currently previewing Conditional Access Policy Plans, which directly address part of this maintainability problem.
A Policy Plan allows related Conditional Access rules to share common assignments and conditions. For example, several policies could inherit the same user population and emergency-access exclusions instead of duplicating them in every standalone policy.
Shared exclusions are particularly useful. An exclusion configured at the plan level applies to every rule and cannot be overridden by an individual rule.
Plans also introduce descriptions, tags, and owners. Owners are governance metadata and do not grant permission to modify the plan.
The enforcement model itself does not change. Every rule is evaluated independently alongside existing Conditional Access policies, and every applicable requirement still needs to be satisfied. There is no priority or override relationship.
There are also design constraints. All users cannot currently be configured as a shared plan-level identity condition, while All resources must be configured at rule level.
Rules created manually start in Report-only mode. Rules generated through templates or the migration experience start Off so they can be reviewed first.
Policy Plans are still Preview and have limitations. For example, user-targeted plans using Location as a condition currently receive one-hour access tokens without the normal instant IP enforcement check.
For now, we would treat Policy Plans as something worth evaluating rather than a reason to redesign an existing production Conditional Access environment.
The direction is nevertheless interesting. Microsoft is recognising that consistency, shared targeting, and maintainability have become security problems of their own as Conditional Access environments grow.
Wrapping Up
Conditional Access maturity is not about enabling every available control. It is about applying the right controls consistently while keeping the policy set understandable.
Start with broad protection. Require MFA for normal access and move privileged identities towards phishing-resistant authentication. Use sign-in and user risk to increase requirements dynamically. Use device compliance and app protection where endpoint context matters, and deploy Token Protection where the applications, platforms, and resources actually support it.
As those controls accumulate, maintainability becomes part of the security model. Consolidate policies where requirements genuinely match. Keep exclusions governed. Remove obsolete exceptions. Review Microsoft-managed policies alongside custom policies, and keep an eye on Policy Plans as Microsoft develops the feature beyond Preview.
A mature Conditional Access environment should become easier to reason about as it evolves, not harder.
Let's Connect
Are you in need of assistance from our Cloud Experts, or want to discuss how these principles apply to your organization? Don't hesitate to fill out the contact form below!