1 · Event
Do you have the exact sign-in?
Match the reported time, user, application, resource, status, and correlation or request information when available. A nearby sign-in is not automatically the same event.
Everyday IT · Identity & Access
A Conditional Access block is a policy result, not a password problem.
If the password is accepted and access fails afterward, stop resetting credentials and identify the exact Microsoft Entra sign-in event, the policy that evaluated it, and the requirement that was not satisfied.Match the event. Read the policy result. Prove the failed control. Change nothing until the reason is clear.
The Conditional Access failure decision tree
Use the sign-in evidence to decide which branch deserves the next test.
2 · Policy
Did Conditional Access apply?
Review the Conditional Access result for the selected sign-in. Separate a policy that applied and failed from one that did not apply, was disabled, or was only evaluated in report-only mode.
3 · Requirement
Which control was not satisfied?
Identify the actual requirement: MFA, compliant device, joined device, approved application, authentication strength, location, risk, terms, or another configured control.
4 · Scope
Is the failure isolated or broad?
One user, one device, one application, one location, or many users? Scope determines whether to investigate the user/session/device or the shared policy and dependency layer.
Branch 1: the policy says Failure
A failed policy result means the sign-in was in scope and a required control was not satisfied.
MFA
Password succeeded, additional authentication did not
Review authentication details and the user's registered methods before assuming the policy is wrong. If the user lost or replaced a factor, follow the approved recovery process rather than bypassing MFA. MFA recovery without weakening security
Device
Compliance or join state is the requirement
Compare the device shown in the sign-in with the device the user believes they are using. Blank, stale, unmanaged, or noncompliant device context points toward the endpoint or enrollment path, not the user's password.
Location / Risk
The context triggered the rule
Record the source network, displayed location, sign-in risk, and user risk as evidence. Do not treat geolocation as proof of physical presence, and do not casually exclude a location or risk condition to restore access.
App / Resource
The sign-in is targeting something specific
Confirm the application and target resource in the event. Policies can behave differently across resources and dependencies, so a working sign-in to one Microsoft service does not prove the failing resource should also be allowed.
Branch 2: the policy says Not applied
Do not blame a policy that was not in scope for the selected sign-in.
Assignments
User or workload not in scope
Check whether the identity is included, excluded, or reaches the policy through group membership. If the sign-in is outside the assignment, move to the next policy or failure layer.
Resource
The target did not match
Verify the actual cloud application or resource from the sign-in event rather than assuming the visible app name tells the whole dependency path.
Condition
A configured condition did not match
Platform, location, client app, device state, risk, or another condition can keep a policy out of scope. Treat that as evidence, not a reason to edit the condition.
Wrong event
Re-check the event boundary
If the policy result contradicts the user's error, confirm you selected the correct sign-in type and exact event before drawing conclusions.
Branch 3: report-only shows a problem, but the user was not blocked
Report-only is planning evidence, not proof that the current policy caused the user's failure.
Report-only failure
The policy would have blocked
Use the result to understand impact before enforcement. Record which control would fail and who or what would be affected.
Current failure
Find the enforced cause separately
If the user is already blocked, identify the enabled policy, authentication failure, application dependency, device issue, or other control that actually stopped the sign-in.
Testing
Use simulation as a planning tool
The Microsoft Entra What If tool can help evaluate which enabled or report-only policies would apply to a defined scenario, but simulation does not replace the evidence from the real sign-in event.
Use the event before the What If tool
The real sign-in tells you what happened. Simulation helps answer what should happen under a defined set of conditions.
Real event
Start with observed evidence
Preserve the sign-in's identity, application, resource, client, device, network, authentication, risk, and policy results.
Simulation
Model the same scenario deliberately
When using What If, define the identity, target resource, device platform, client application, and other relevant conditions as completely as possible. Missing conditions can produce an incomplete comparison.
Difference
Explain why simulated and real results differ
Service dependencies, changed conditions, different resources, or incomplete input can make simulation and a real sign-in disagree. Do not force the real event to fit the simulation.
Known-good comparisons that actually help
Change one meaningful variable at a time.
Same user
Another device
If the same account works from a known-good device, investigate device registration, compliance, client, session, and local state before changing the tenant policy.
Same device
Another approved user
If a similar user succeeds on the same device, compare assignments, group membership, authentication methods, risk, and exclusions.
Same user/device
Another resource or client
Browser success with desktop failure, or one cloud resource working while another fails, helps isolate application, resource, token, or dependency behavior.
What not to change casually
Conditional Access is shared security infrastructure.
Do not
Disable MFA just to test
Prove the failing control first. Removing a security requirement can hide the cause and create a new risk.
Do not
Add broad exclusions for one ticket
An exclusion can affect future sign-ins far beyond the user or device currently being investigated.
Do not
Edit multiple conditions at once
Changing users, resources, locations, grant controls, and session rules together destroys the evidence needed to know which change mattered.
Do not
Treat a successful password reset as proof
Conditional Access evaluates context after or around authentication. A correct password does not satisfy device, risk, location, resource, or policy requirements by itself.
Escalate with a usable evidence package
If the fix requires policy design or a tenant-wide change, make the handoff smaller and safer.
Event
Exact sign-in details
Include timestamp, user, application, resource, sign-in type, error, request/correlation information, and the selected event URL or exported details when approved.
Policy
Which policy and which result?
Record the policy name, result, failed requirement, and whether it was enabled or report-only at the time.
Scope
Who else is affected?
One user, one device, one location, one application, or a broader population. Include known-good comparisons already tested.
Question
State the unresolved decision
Example: “Should this device satisfy the compliant-device requirement, or is the current block expected by design?” That is better than “Conditional Access is broken.”
Escalate the policy decision, not just the login ticket.
If the required next step is a broad exclusion, policy redesign, privileged-account exception, or tenant-wide control change, move into planned-change territory. Escalate with Evidence and Change Safety & Rollback are the next paths. When those shared controls need independent architecture or risk review, KrippyTech Consulting is available at that boundary.
Related guides
Use the next guide that matches the layer you proved.
Passwords, Lockouts & MFA
Start here when the authentication layer is still unclear. Troubleshoot sign-in problems
MFA Recovery
Use the approved recovery path when the user no longer has a working factor. Recover MFA safely
Suspicious Sign-In First Response
If the problem looks like identity compromise rather than ordinary access failure, change the objective from “make login work” to “prove who is signing in.” Triage suspicious sign-ins
Entra Sign-In & Conditional Access Investigation
Use the deeper tutorial when you need a full evidence-first review of the sign-in event and policy evaluation. Open the advanced investigation