Check how authentication and policy requirements combine before treating a blocked sign-in as resolved.
A Conditional Access block can be an important incident signal. Don’t close the investigation just because the attacker didn’t reach the resource.
Conditional Access is enforced after first-factor authentication. It evaluates whether the request meets your access requirements, and can ask the authentication service to satisfy additional requirements, such as MFA or an authentication strength. A successful first factor still doesn’t guarantee access.
This is why Conditional Access isn’t the control that stops someone trying passwords. Password Protection reduces weak passwords when they’re set or changed, and Smart Lockout helps stop password guessing.
When a suspicious request is blocked by a location or device policy, open the sign-in’s Authentication Details and Conditional Access tabs. Check how authentication was satisfied, which resource was requested, and which policy blocked it. Authentication might have used a password, a passwordless method, or existing session/token claims; the block alone doesn’t prove which credential the attacker possesses. Authentication Details can be incomplete until logs finish aggregating.
Also check every applicable policy. All applicable requirements must be met, and an applicable block wins. Excluding a user from one policy doesn’t exempt them from the others.
Treat the block as a reason to investigate the account and surrounding activity.
Conditional Access overview | How policies combine | Sign-in log details
Original post: 24 January 2025. Documentation checked 14 October 2026.