Key takeaways
What is Microsoft Entra Conditional Access?
Microsoft Entra Conditional Access is an identity-driven access control engine. It evaluates the circumstances surrounding a sign-in and applies a decision before access is granted to a cloud application, administrative portal or protected resource. At its simplest, a policy follows an if-then model: if a defined user, application and set of conditions are matched, then block access or require one or more controls.
Unlike a traditional network perimeter, Conditional Access can make decisions using identity and cloud signals. A sign-in from a compliant corporate laptop, a managed mobile application and a known user can be treated differently from a sign-in using an unfamiliar device, an unexpected location or a risky authentication event.
Conditional Access should not be designed as a collection of isolated switches. It is an access strategy that connects identity, authentication, devices, applications and security operations.
Verify explicitly
Use available signals to make a deliberate access decision rather than assuming a trusted network equals a trusted session.
Use least privilege
Apply stronger controls to administrators, sensitive applications and high-impact actions.
Assume breach
Design controls that limit the value of stolen credentials and compromised sessions.
Protect productivity
Use the least disruptive control that achieves the required security outcome.
Licensing and prerequisites
Conditional Access generally requires Microsoft Entra ID P1. Microsoft 365 Business Premium includes Conditional Access capabilities for licensed users. Risk-based policies using Microsoft Entra ID Protection signals require Microsoft Entra ID P2. Related controls can introduce additional licensing requirements, including Microsoft Intune for compliant device signals and Microsoft Defender for Cloud Apps for real-time session controls.
Before deployment, confirm which users are in scope, which licences are assigned and whether every person benefiting from a policy has the appropriate entitlement. Also confirm administrative role design. Security Reader can review policies and sign-in results, while Conditional Access Administrator can create and manage policies. Privileged role activation through Privileged Identity Management is preferable where available.
| Capability | Typical requirement | Planning note |
|---|---|---|
| Core Conditional Access | Microsoft Entra ID P1 | Supports user, application, location, device and grant controls. |
| Risk-based access | Microsoft Entra ID P2 | Uses user risk and sign-in risk from Identity Protection. |
| Compliant device requirement | Intune plus Entra licensing | The device must be enrolled and evaluated against compliance policy. |
| Session monitoring | Defender for Cloud Apps where used | Can restrict downloads or monitor activity in supported applications. |
How a Conditional Access decision works
Each policy has assignments, conditions and access controls. Assignments define who and what is targeted. Conditions refine when the policy applies. Access controls determine whether access is blocked, granted with requirements or limited through session controls. Multiple applicable policies are cumulative: a user must satisfy every requirement imposed by every policy that applies.
Policy decision flow
Policy order does not create precedence. A broadly scoped policy is not overridden by a narrower policy. This is why exclusions, policy overlap and the combined user experience must be considered during design.
Signals and conditions
Users and groups
Target all users, selected groups, directory roles, guests or workload identities. Prefer groups and roles over long lists of individuals.
Cloud applications
Protect all resources or selected applications. Sensitive apps may justify stronger requirements than everyday productivity services.
Locations
Use named locations for known IP ranges or countries and regions. A trusted location should reduce friction only where the network is genuinely controlled.
Devices
Consider platform, join state, compliance and device filters. Device state is often more useful than network location for modern work.
Client applications
Distinguish browser, mobile and desktop clients, legacy authentication and selected authentication flows.
Risk
With Entra ID P2, user and sign-in risk can trigger remediation or blocking based on detected identity risk.
Named locations
Named locations can represent trusted corporate egress addresses, VPN endpoints or geographic areas. They should not be treated as a complete trust signal. A compromised device on a trusted network remains compromised. Use named locations to shape policy and reduce unnecessary prompts, not as a substitute for strong authentication or device assurance.
Device filters
Device filters provide precise targeting based on attributes such as ownership, device ID, operating system or extension attributes. They can support privileged access workstations, phased device migrations and exceptions for specialist equipment. Keep filter logic documented and tested because a small syntax or attribute assumption can change the affected population.
Grant and session controls
Grant controls decide what must happen before access is allowed. Common controls include multifactor authentication, a selected authentication strength, a compliant device, a Microsoft Entra hybrid joined device, an approved client app, an app protection policy, password change or terms of use. A block control should be used carefully because it is absolute when the policy matches.
Authentication strengths allow an organisation to require a defined set of methods. For administrators and high-value applications, phishing-resistant authentication such as passkeys, FIDO2 security keys or Windows Hello for Business can provide materially stronger protection than basic MFA methods.
Session controls operate after authentication and can shape the ongoing session. Examples include sign-in frequency, persistent browser settings and integrations that restrict actions in supported cloud applications. Avoid using very short sign-in frequency settings as a substitute for risk-based access; excessive prompts can reduce usability without proportionate security benefit.
Recommended baseline policy set
A practical baseline is easier to test and operate when each policy has one clear purpose. The exact set depends on licensing, applications, risk appetite and device strategy, but most organisations should consider the following controls.
| Policy | Purpose | Typical scope |
|---|---|---|
| Block legacy authentication | Prevent protocols that cannot satisfy modern authentication requirements. | All users, with only validated technical exclusions. |
| Require strong authentication for administrators | Protect privileged roles from password theft and weak MFA. | Directory roles and privileged accounts. |
| Require MFA for users | Reduce credential-only compromise across cloud applications. | All users and guests, deployed in stages. |
| Protect security information registration | Require trusted conditions when users register or change authentication methods. | All users. |
| Require compliant devices for sensitive apps | Ensure access originates from devices meeting management and security standards. | Selected business-critical applications. |
| Protect risky sign-ins and risky users | Respond automatically to identity risk. | All users where Entra ID P2 is licensed. |
| Control device code flow | Reduce abuse of high-risk device authentication workflows. | All users, with explicit supported exceptions. |
Emergency access and exclusions
Maintain at least two cloud-only emergency access accounts with strong, separately controlled credentials and no dependency on the organisation's normal identity infrastructure. These accounts should be excluded from policies that could prevent tenant access, protected from routine use and monitored for any sign-in or credential change.
Exclusions should be rare, named, justified and reviewed. Avoid broad permanent exclusion groups that gradually become a bypass path. Where an application or service account cannot meet a control, first determine whether the identity can be modernised, converted to a workload identity, restricted by location or replaced with a managed identity.
Safe deployment approach
Conditional Access can create immediate user impact, so deployment should be deliberate. Report-only mode records how a policy would have evaluated without enforcing the control. Combine this with a representative pilot group, sign-in log review and the What If tool.
Define the access strategy
Identify critical applications, user populations, device expectations, authentication methods and acceptable exceptions.
Prepare identities and recovery
Create emergency access accounts, clean up stale identities and confirm administrative roles.
Register authentication methods
Ensure users can satisfy the planned controls before enforcement begins.
Build one-purpose policies
Use consistent names, descriptions and documented ownership. Avoid combining unrelated scenarios.
Use report-only mode
Review expected and unexpected matches across real sign-ins, devices and applications.
Pilot with representative users
Include different roles, locations, platforms, applications and support scenarios.
Enable in stages
Expand gradually, monitor impact and keep rollback actions ready.
Operate and improve
Review sign-in failures, exclusions, unused policies, new applications and licence changes.
Troubleshooting Conditional Access
Start with the Microsoft Entra sign-in logs. Capture the user, timestamp, target application, operating system, client type, correlation ID and failure details. The Conditional Access tab for a sign-in shows which policies applied, did not apply or were not evaluated, along with the result of each control.
Useful diagnostic tools
- What If: simulate a policy evaluation using selected user, application, device and location attributes.
- Report-only results: see whether a policy would have succeeded, failed or required user action.
- Sign-in logs: inspect policy decisions, authentication details, device information and error codes.
- Policy change history: correlate unexpected behaviour with recent administrative changes.
Common causes include an unexpected application dependency, a service account caught by an all-users policy, an unmanaged device that cannot satisfy compliance, authentication method registration gaps, conflicting session settings or an exclusion that does not work as assumed.
Governance and ongoing operations
Assign an owner to every policy and record the business purpose, scope, exclusions, licence dependency, support impact and review date. Use consistent names that make the intent readable in logs, for example CA-Users-AllApps-RequireMFA or CA-Admins-AllApps-PhishingResistant.
Review policy coverage whenever new applications are introduced, administrators change, device strategy evolves or licensing is modified. Monitor sign-in failure trends and user support volume. Back up policy definitions through Microsoft Graph or configuration management where appropriate, and treat changes as controlled security changes rather than ad hoc portal edits.
Common mistakes to avoid
No emergency access design
An administrator enables a broad policy and discovers there is no reliable recovery path.
Turning policies on immediately
A policy is enforced before report-only testing and representative pilot validation.
Too many overlapping policies
Administrators cannot easily explain the combined requirements for a sign-in.
Permanent broad exclusions
Exceptions quietly become an alternative route around the security baseline.
Trusting location too much
A corporate IP range is treated as proof that the user and device are safe.
Ignoring user readiness
Users are required to perform MFA or passwordless authentication before methods are registered.
Conditional Access deployment roadmap
Week 1: discovery
Catalogue applications, users, administrators, guests, service accounts, devices and current authentication methods.
Week 2: recovery and foundations
Create emergency access, role assignments, naming standards, pilot groups and monitoring.
Week 3: baseline protection
Build report-only policies for legacy authentication, administrator protection and authentication registration.
Week 4: user authentication
Roll out MFA or selected authentication strengths to users and guests in controlled stages.
Weeks 5–6: device and application controls
Add compliance, app protection and stronger requirements for sensitive resources.
Ongoing: risk and optimisation
Add risk-based policies where licensed, review coverage and retire redundant exceptions.
Conditional Access checklist
Frequently asked questions
Microsoft Entra Conditional Access is a policy engine that evaluates identity, application, device, location, risk and other signals before allowing or blocking access.
Core Conditional Access capabilities generally require Microsoft Entra ID P1. Risk-based policies using Identity Protection signals require Microsoft Entra ID P2.
No. MFA is one access control that Conditional Access can require. Conditional Access decides when MFA or another control is needed.
No. Use report-only mode, test users, pilot groups, sign-in logs and the What If tool before broad enforcement.
They provide a recovery path if normal administrators are blocked by a policy, authentication outage or identity configuration problem.
Yes. A policy can require the device to be marked compliant, provided the required Microsoft Entra and Intune licensing and configuration are in place.
All applicable policies are evaluated and their requirements accumulate. A narrower policy does not override a broader policy.
Review them regularly and whenever applications, identity roles, device strategy, authentication methods or licensing materially change.
Planning a Conditional Access deployment?
Fedelta can assess your current identity controls, design a practical policy set, test it safely and support a staged rollout.