Post

The Essential Guide to Microsoft's Conditional Access Recommendations

Posted Updated
By Alf Løkken
views 6 min read
The Essential Guide to Microsoft's Conditional Access Recommendations

Microsoft’s Conditional Access documentation is extensive, but the specific recommendations are scattered across multiple articles and sections, making it difficult to get a consolidated view. This article compiles all of Microsoft’s explicit Conditional Access recommendations from official documentation into one structured, actionable reference. Each recommendation includes a direct link to the source material for further context and detail.

Design Guidelines

This section covers on design principles, operational resilience, policy rollout, and session management — as distinct from specific policy templates, which are covered in the next section.

Design principles

Source: Plan a Conditional Access deployment

  • Use a structured naming standard that includes sequence numbers and has descriptive policy names.
  • Ensure that every app has at least one policy applied.
  • Minimize the number of policies by grouping users and apps covered by repetitive patterns.
  • Use protected action as another layer of security on attempts to create, modify or delete policies.
  • Implement policy assignments through groups, not individuals.1
  • Ensure a consistent experience across Microsoft 365 client applications by implementing the same set of controls for services such as Exchange Online and SharePoint.1 2

To protect Conditional Access assignment groups, consider using role-assignable groups and/or placing them in restricted-management administrative units to prevent unauthorized modification.

Operational Resilience

Source: Create a resilient access control management strategy

  • Provide multiple authentication methods for each user, using different communication channels.
  • Combine multiple Conditional Access controls to avoid lockouts:
    • Use Windows Hello for Business to satisfy MFA requirements at sign-in.
    • Use trusted devices (hybrid-join or Intune-managed) to satisfy strong authentication requirements without implicit MFA challenge.
    • Leverage risk-based policies that prevent access when the user or sign-in is at risk, in place of fixed MFA policies.
  • Do regular reviews of the exception groups.1
  • Deploy password hash sync even if federated or using pass-through auth.
  • Maintain at least two cloud-only emergency permanent-admin accounts using *.onmicrosoft.com domain, phishing-resistant authentication (different to that of other admin accounts).3
  • Implement disabled policies that act as secondary resilient access controls in outage or emergency access scenarios.4
  • If using on-prem VPN with NPS extension, federate as a SAML app or plan how to disable or replace in an emergency.

Policy Deployment Process

Source: Plan a Conditional Access deployment

Consider using a phased rollout approach when deploying Conditional Access in production. There is no official guidance on this, but it can help reduce risk.

Session and Re-authentication Settings

Source: Reauthentication prompts and session lifetime

  • Enable single sign-on across applications by using either:
  • If reauthentication is needed, configure a sign-in frequency policy.
  • For mobile users, encourage the use of the Microsoft Authenticator app to reduce authentication prompts.
  • Avoid KMSI (Keep Me Signed In/Company Branding)- use Conditional Access to enforce persistent browser sessions instead.

Deprecation and Transition Guidance

The ‘Secure foundation’ templates provide the minimum baseline that all organizations should implement first. These policies drive broad MFA adoption and device-based authentication, establishing essential security controls before advanced protections are implemented.

recommended policies from microsoft documentation

Once that baseline is in place, you can move toward more advanced protections. Focus on risk-based controls, phishing-resistant authentication for admins, authentication strength, and alignment with a Zero Trust model.

The recommended policies below support this progression. They introduce more granular and risk-aware access controls.

Secure foundation

Device compliance may be challenging to enforce in practice - see alternatives to device compliance below.

Zero Trust

Authentication strength is not supported for external users who authenticate with email OTP, SAML/WS-Fed or Google federation.

Emerging threats

Uncategorized

Alternatives to Device Compliance

Other Considerations

While the following topics are not explicitly listed as part of Microsoft’s conditional access recommendations, they represent practical and security-relevant scenarios that many organizations should consider:

License requirements

The table below summarizes license dependencies for features discussed in this article. Refer to the Microsoft Entra licensing for more details.

License TierRequired For
Microsoft Entra ID P1- Conditional Access
Microsoft Entra ID P2- Risk-based policies
- Access Reviews (group membership)
- Privileged Identity Management (PIM)
Entra ID Governance- Access Reviews (Inactive Users)
Workload ID Premium- Conditional Access for Workload IDs (service principals)

What’s Next?

Conditional Access is evolving rapidly. These recommendations provide a solid foundation, but successful implementation requires structured policy design and consistent review. For guidance on scalable implementation, watch for my upcoming article on structured Conditional Access policy design.

Further reading

Microsoft:

Other resource:

References

1: Microsoft Entra authentication management operations reference guide 🔗
2: Service dependencies in Microsoft Entra Conditional Access 🔗
3: Manage emergency access accounts 🔗
4: Plan a Conditional Access deployment - Naming standards for emergency access controls 🔗

Entra ID, Conditional Access
Entra ID Conditional Access
This post is licensed under CC BY 4.0 by the author.