Identity & Security · · 12 min read
Microsoft Entra ID Conditional Access: 10 Policies I Would Review First
A practical review sequence for real users, devices, applications and operational constraints
A Conditional Access review should not begin with the question, “How many policies do we have?” Ten carefully owned policies can be clearer and safer than forty overlapping ones. The useful question is whether each important sign-in receives the right decision—and whether the organisation can explain, test and recover from that decision.
When I review an environment, I would start with the ten areas below. This is not a universal template to enable unchanged in every tenant. It is an audit sequence: identify the risk, inspect the current behaviour, understand the operational dependency, then change the control in stages. That distinction matters because Conditional Access can stop an attacker, but it can also stop every administrator if confidence moves faster than testing.
Safety before enforcement
The principle I use is simple: emergency access first, evidence second, enforcement third. Report-only mode, representative pilots, sign-in logs, peer review and a tested rollback path are part of the security control—not paperwork around it.
How this review differs from a policy template
Microsoft Entra ID evaluates users, applications, devices, locations, risk and session controls together. A policy copied from another tenant cannot know your enrolment flow, contractor model, legacy applications, travel patterns or support capacity. The goal is therefore not identical policies everywhere; it is a defensible control set that matches the environment.
If you need the concepts and a phased implementation sequence first, start with my practical Microsoft Entra Conditional Access guide. This article goes one level deeper: what I would inspect during a policy review and which questions reveal operational risk.
The review sequence
Identity assurance → privileged access → legacy paths → risk → device trust → unmanaged access → location → applications and sessions → recovery → evidence and overlap
10 Conditional Access policy areas I would review first
These are policy areas rather than copy-and-paste policy names. Some environments will implement an area with one policy; others will separate administrators, platforms or applications for clearer ownership and safer change control.
Policy review 01
MFA coverage and authentication strength
- Risk addressed
- A user can have MFA registered while important sign-in paths still avoid it. Broad exclusions, remembered sessions, legacy methods and inconsistent application scope can leave a gap between the security policy people think they have and the one Entra ID actually evaluates.
- What I would verify
- Check which users, groups, applications and authentication contexts are in scope. Review the authentication methods allowed, registration status, sign-in frequency and whether stronger phishing-resistant methods are justified for privileged or high-impact roles.
- Common concern
- A single tenant-wide ‘require MFA’ policy may overlap with older per-user MFA settings or another Conditional Access rule. That can produce duplicate prompts, confusing exceptions or false confidence about coverage.
- Rollout and testing
- Start by observing the real sign-in population in report-only mode. Pilot changes with representative users, including mobile, desktop and remote scenarios, and communicate authentication-method changes before enforcement.
Policy review 02
Privileged and administrator access
- Risk addressed
- Administrative identities can change the controls that protect everyone else. A compromised privileged session has a very different impact from an ordinary account, so it should not inherit an ordinary user baseline by accident.
- What I would verify
- Inventory active and eligible role assignments, dedicated admin accounts, management portals, workload identities and the authentication strength required for privileged work. Confirm that administrative access is covered even when the user is outside the usual office network.
- Common concern
- Policies scoped only to directory roles can miss newly introduced roles, service principals or admin-capable applications. At the other extreme, an untested policy covering every cloud app can block the portal needed to repair it.
- Rollout and testing
- Protect a small admin pilot first, test every management path used by the team and keep emergency access available. Record the owner, purpose and change ticket for each privileged-access policy.
Policy review 03
Legacy authentication and unsupported clients
- Risk addressed
- Older authentication protocols cannot satisfy modern MFA challenges and may bypass the controls expected at an interactive sign-in. One forgotten mailbox, scanner or application can keep that weaker path alive.
- What I would verify
- Use sign-in logs to identify legacy client activity and determine whether it is a real dependency, stale traffic or an unsupported application. Map each dependency to an owner and a modern replacement before blocking it.
- Common concern
- Treating every legacy sign-in as malicious can break business workflows; treating every exception as permanent leaves the tenant exposed. Exceptions without owners and expiry dates tend to become invisible infrastructure.
- Rollout and testing
- Measure first, remediate named dependencies, then apply a block in report-only and pilot stages. Monitor failures after enforcement and keep a documented rollback decision—not an undocumented permanent exclusion.
Policy review 04
Risky users and risky sign-ins
- Risk addressed
- Identity Protection signals can identify unusual sign-in behaviour or credentials believed to be compromised. Ignoring those signals wastes useful context; treating every signal as certainty can lock out legitimate users.
- What I would verify
- Where the required licensing is available, review user-risk and sign-in-risk policies, remediation actions, alert ownership and the process for investigating detections. Confirm that help-desk and security teams understand the difference between the two risk types.
- Common concern
- Risk policies are sometimes enabled without a recovery process, or configured around licensing that does not cover the targeted population. Automated password change also depends on the tenant’s authentication and reset configuration.
- Rollout and testing
- Begin with visibility and analyst review. Test self-service remediation with a pilot group, define escalation thresholds, and make sure high-risk blocks have an operational route for verified users to regain access.
Policy review 05
Device compliance and managed endpoints
- Risk addressed
- A valid identity on an unpatched, unencrypted or unmanaged endpoint can still expose Microsoft 365 data. Conditional Access becomes stronger when identity decisions include the device’s actual management and compliance state.
- What I would verify
- Check Intune enrolment coverage, compliance-policy assignment, grace periods, stale device objects and the applications that require a compliant or appropriately joined device. Validate the experience across Windows, macOS, iOS and Android where those platforms are supported.
- Common concern
- Requiring compliance before devices can complete enrolment creates a circular dependency. Inconsistent device records can also make a healthy device appear unknown, particularly during migrations or rebuilds.
- Rollout and testing
- Separate enrolment flows from steady-state access, pilot by platform and watch compliance latency. Give support teams a clear path to distinguish a policy block from a genuinely non-compliant endpoint.
Policy review 06
Unmanaged-device access to company data
- Risk addressed
- Not every personal or partner device should receive the same download and sync rights as a managed corporate endpoint. The decision is not simply allow or block; browser restrictions and session controls may offer a safer middle ground.
- What I would verify
- Review which SharePoint, OneDrive, Exchange and Teams scenarios are allowed from unmanaged devices. Confirm whether browser-only access, download restrictions or approved client applications match the organisation’s real working model.
- Common concern
- A blanket block can disrupt contractors, frontline staff or legitimate bring-your-own-device use. A blanket allow can place sensitive files on devices the organisation cannot encrypt, patch or remotely wipe.
- Rollout and testing
- Pilot with the user groups most dependent on personal devices. Test document preview, download, printing, mobile clients and external collaboration before expanding the control.
Policy review 07
Location, network and workload context
- Risk addressed
- Named locations and network signals can add useful context, but IP location is not proof of identity or device trust. VPNs, mobile networks, cloud egress and changing office addresses make location-only trust fragile.
- What I would verify
- Review named locations, trusted IP ranges, countries or regions in scope, IPv6 coverage and any dependency on compliant network signals. Confirm why each location exists and who maintains it.
- Common concern
- Marking an office network as trusted can unintentionally weaken MFA for every device behind that address. Country blocking can also affect travel, roaming users and services whose traffic does not originate where expected.
- Rollout and testing
- Use location as one signal among several, not a substitute for strong authentication. Test travel, VPN, mobile tethering and cloud-hosted workloads, and give temporary exceptions an owner and expiry date.
Policy review 08
Application scope and session controls
- Risk addressed
- A policy can protect Microsoft 365 broadly while missing a sensitive enterprise application—or apply a disruptive session rule to an app that cannot handle it. Application scope is where a sensible control can become operationally blunt.
- What I would verify
- Map policies to all cloud apps, selected apps, authentication contexts and user actions. Review sign-in frequency, persistent browser sessions, app-enforced restrictions and Continuous Access Evaluation support where relevant.
- Common concern
- Overly frequent reauthentication creates user fatigue without necessarily reducing the highest risks. Selected-app policies can drift as new applications are introduced, leaving coverage dependent on someone remembering to update a list.
- Rollout and testing
- Test normal browser, desktop, mobile and service workflows. Use authentication context for especially sensitive actions where it improves precision, and document why a session control is stricter than the baseline.
Policy review 09
Emergency access, exclusions and recovery
- Risk addressed
- Conditional Access can block the administrators needed to correct a mistake. Emergency access accounts and deliberate exclusions are part of the control design, not an embarrassing exception to it.
- What I would verify
- Confirm emergency accounts are cloud-only, strongly protected, monitored, tested and excluded from the policies that could cause tenant-wide lockout. Review every other exclusion for owner, reason, compensating control and expiry.
- Common concern
- An emergency account used for routine administration is no longer an emergency account. A group-based exclusion can quietly expand, while an account nobody tests may fail exactly when it is needed.
- Rollout and testing
- Test the recovery procedure before enforcing major changes and alert on any emergency-account sign-in. Require peer review for new exclusions and revisit the exclusion register on a fixed schedule.
Policy review 10
Report-only results, logs and policy overlap
- Risk addressed
- Individual policies can look correct while their combined result is confusing or contradictory. Without log review and change control, teams discover overlap only after a user is blocked—or after a control fails to apply.
- What I would verify
- Use the What If tool, report-only insights and sign-in logs to trace which policies applied, did not apply or were not evaluated. Review naming, ownership, duplicate controls, disabled policies and the retention or export of logs needed for investigation.
- Common concern
- Report-only is evidence, not proof that every edge case has been tested. Short observation windows miss monthly tasks, travelling users and rarely used applications; overlapping policies also make troubleshooting harder than necessary.
- Rollout and testing
- Move from report-only to a representative pilot, then staged groups, with a documented rollback point. Monitor after enforcement, record the expected result and simplify duplicate policies when the evidence supports it.
Device signals only help when endpoint operations are healthy
Conditional Access does not repair device management. It consumes the signal produced by it. Before requiring compliance broadly, I would inspect enrolment success, policy assignment, stale records and the support path for users whose device is incorrectly reported. My Intune and endpoint management overview explains how compliance, deployment and day-to-day operations fit together.
What a useful review produces
The output should not be a screenshot collection or a score with no owner. A useful review produces a policy inventory, an exclusion register, evidence from sign-in logs, identified dependencies, a prioritised change backlog and an agreed rollout method. It should also identify where licensing limits a desired control, rather than pretending every Microsoft Entra feature exists in every subscription.
This is where identity work connects to the wider Microsoft platform. The Microsoft cloud specialist profile covers the relationship between Microsoft 365, Entra ID, Intune and cloud operations, while the Entra ID consulting for tenant reviews and safe rollout is the main overview of my professional focus on identity, MFA, Conditional Access and governance.
The decision test
“Can we explain why this sign-in was allowed or blocked, identify the policy that made the decision, and recover safely if our assumption was wrong?”
Conditional Access review checklist
Before calling the review complete, I would want clear answers to these ten operational checks:
01Every policy has a named owner, purpose and review date.
02Emergency access is excluded, monitored and recently tested.
03All non-emergency exclusions have a reason, owner and expiry decision.
04Report-only evidence includes representative users, apps, devices and locations.
05The support team can identify which policy caused a block from sign-in logs.
06Legacy authentication dependencies have owners and migration plans.
07Device-compliance requirements do not block enrolment or recovery flows.
08Policy overlap has been reviewed with What If and real sign-in evidence.
09Changes follow peer review, communication, monitoring and rollback procedures.
10Licensing supports every signal and control assigned to the target population.
Final thought: clarity is a security control
Good Conditional Access is not the policy set with the most conditions. It is the one where the organisation understands the intended decision, can see the real result in the logs, and can change it without gambling on user access. Strong identity security and reliable IT operations are the same conversation viewed from different sides.
After 15+ years in professional IT across Microsoft 365, Entra ID, Intune, cloud, infrastructure and advanced support, that is the standard I would bring to an identity review: practical controls, careful rollout and enough documentation that the next person does not have to reverse-engineer the reasoning.
Professional networking
I am currently open to IT opportunities involving Microsoft 365, Entra ID, Intune, identity security, cloud operations and technical leadership. Recruiters, hiring managers and fellow IT professionals are welcome to review my experience or get in touch.
Written by Davor Smajilovic, an IT specialist with 15+ years of professional experience across Microsoft 365, Entra ID, Intune, cloud, infrastructure and advanced IT support.