Join our Newsletter — 33% off our NHI Course

How do you block risky sign-ins with Conditional Access in Microsoft Entra ID?

Block risky sign-ins by using a Conditional Access policy that requires stronger verification or denies access when sign-in risk is elevated. Pair the policy with risk remediation steps, such as password reset or step-up authentication, and confirm that break-glass accounts are excluded. Track risk changes and denied sign-ins in the audit and sign-in logs.

What Conditional Access is actually doing when sign-in risk is high

Conditional Access in microsoft entra id is acting as the policy enforcement layer between the sign-in attempt and the app. When sign-in risk is elevated, the policy can either block access outright or require a stronger control before the session is allowed to proceed. The practical goal is not just denial, it is to force the session through a higher-confidence decision path.

That distinction matters because “risky sign-in” is not the same as “compromised account.” The policy is responding to a risk signal, so you should design it to be strict enough to stop suspicious access while still leaving a route for legitimate users to recover. That is why remediation and exception handling belong in the same design, not as an afterthought.

For most teams, the cleanest model is to reserve hard block decisions for high-risk conditions and use step-up verification where business continuity matters. That keeps the policy aligned with the actual threat: unknown or suspicious sign-in context, not necessarily a confirmed takeover.

How to design the policy so it blocks the right sessions

The key design choice is whether the response should be “require stronger verification” or “deny access.” A stricter response reduces exposure, but if you apply it too broadly you can strand legitimate users or create help desk load. The policy should be scoped so that the decision is driven by the sign-in risk signal, not by a broad population rule that catches too much traffic.

Break-glass accounts need special treatment. They should be excluded from the risky sign-in policy, but only if they are truly emergency accounts with strong offline protection, monitored use, and very limited exposure. If you include them in the same control path as ordinary users, you can create an availability problem exactly when you need an administrative recovery path.

Conditional Access becomes most effective when it is paired with the surrounding identity controls that make risky access easier to validate. The same operating model that uses the policy should also preserve strong sign-in logging, clear alerting, and a defined recovery path so that a blocked sign-in is actionable rather than opaque. Conditional Access Guide is the best place to ground the policy design choices, especially for report-only testing and exclusions.

What to check before and after you turn the policy on

Before enforcement, validate who will be affected, which apps are in scope, and whether the policy behaves differently for interactive users, admins, and emergency access accounts. If you already have legacy or weak authentication paths in the tenant, those can make the policy look effective on paper while leaving other paths usable in practice. This is where Entra ID hardening and access policy design should be reviewed together. Active Directory and Entra ID Hardening Guide helps connect Conditional Access to the surrounding identity controls.

After rollout, watch the sign-in logs for denied attempts and for users who repeatedly trip the policy. A rising pattern of risky sign-ins can point to phishing, token theft, or password spraying, while isolated denials may simply reflect a noisy signal. The important question is whether the denial is closing off a real attack path or just creating friction without improving security.

If the policy is doing its job, you should see fewer successful sign-ins from risky contexts and a clearer remediation trail for users who are forced through password reset or step-up authentication. For the broader identity recovery and containment picture, the Identity Provider and SSO Security Guide is useful because it ties Conditional Access to token, session, and federation protections.

Why risky sign-in blocking fails in practice

The most common failure is treating the policy as a standalone control. If the tenant still has weak recovery flows, poorly managed exclusions, or privileged accounts that are overexposed, the policy only blocks one path while the attacker moves to another. Risk-based access works best when it is part of a broader zero trust posture, not a single decision rule.

Another failure mode is overtrusting the risk signal. A risky sign-in alert is useful, but it is still a signal, not proof of compromise. If you block too aggressively without a recovery process, you can create operational disruption; if you are too lenient, you leave a window for attackers to complete the session before remediation starts. Zero Trust Identity Guide is the most relevant navigation point when you want to place Conditional Access inside a continuous verification model.

Risk and Threat Considerations

Risk-based blocking is only as good as the identities and recovery paths around it. If exclusions are too broad, or if an attacker already has a privileged foothold, a risky sign-in policy may stop a user session while leaving a more dangerous administrative path intact.

Failure mechanism: Attackers exploit weak recovery, excessive exclusions, or alternate authentication paths to bypass the intended denial point, then continue the intrusion through another account, token, or app path.

Impact: The organisation gets a false sense of containment, while the real compromise path remains open or the attacker simply pivots to a higher-value identity.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST Zero Trust (SP 800-207), NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST Zero Trust (SP 800-207) PR.AA-01 — Identity and Access Management Conditional Access is an identity-centric access decision layer.
Recommendation — Apply identity-centric policy decisions to step up or deny risky access.
NIST SP 800-53 Rev 5 AC-2 — Account Management Risky sign-in blocking depends on account scoping and exception handling.
IA-2 — Identification and Authentication (Organizational Users) The policy hinges on stronger verification for suspicious user sign-ins.
AU-6 — Audit Record Review, Analysis, and Reporting Denied sign-ins and risk changes must be reviewed in logs to validate control effect.
Recommendation — Review account scope and exclusions before enforcing risky-sign-in policies. Require stronger authentication when sign-in risk crosses your threshold. Monitor sign-in and audit logs for repeated risk and denied access patterns.
CIS Controls v8 CIS-6 — Access Control Management Conditional Access is a practical access-control safeguard for risky sign-ins.
Recommendation — Use access-control policy to block or step up risky authentication attempts.

Practitioner Guidance

What to verify: Confirm that high-risk sign-ins are actually blocked or stepped up for the target apps and user groups you care about, and that emergency access accounts remain reachable through a separately governed path.

Decision rule: If the account can access production systems or administrative functions, treat any risky-sign-in exemption as a high-value exception that needs explicit ownership and review, not a convenience setting.

What to measure: Track denied sign-ins, repeat risk hits on the same account, and the percentage of risky sign-ins that end in successful remediation versus repeated failure.

Practitioner takeaway: The control works when it changes attacker economics and user recovery at the same time, so design the block, the exception, and the remediation path as one policy family.