Risky sign-ins are one of the best ideas in Entra ID and one of the most frustrating in practice. On paper, Entra ID Protection flags authentication that looks suspicious — impossible travel, unfamiliar location, leaked credentials — so you can respond before damage is done. In reality, a lot of teams turn on the alerts, drown in false positives, and eventually stop looking.
This post covers how to audit your risky sign-in configuration so it stays useful instead of becoming noise.
What risky sign-ins actually are
Entra ID Protection evaluates sign-in and user risk using signals like:
- Anonymized IP / unfamiliar location — sign-ins from proxies or unexpected geographies
- Leaked credentials — credentials found in known breach corpora
- Impossible travel — two sign-ins too far apart in time to be real
- Malware-linked IPs — sign-ins from addresses associated with botnets
- Password spray / brute force — patterns consistent with credential attacks
Risk is scored at sign-in, and Conditional Access can use it: block high-risk sign-ins, require MFA, or force a password change. Done well, it catches real attacks. Done badly, it groans under false positives.
Why false positives happen
The most common causes, all of them configuration:
- No trusted locations defined. Without named corporate networks, legitimate VPN and office traffic can look "unfamiliar."
- VPNs and proxies. Corporate VPN egress IPs that are not marked trusted get flagged as anonymized.
- Traveling users. Real travel looks like impossible travel when no exclusions or policies account for it.
- Risk policies that require P2 without the workflow. If risk-based Conditional Access needs protection you have not licensed, you get alerts you cannot act on.
- No tuning. Risk detection without a review process just accumulates.
The fix is rarely "ignore more." It is to configure the context Entra needs — trusted locations, exclusions, and the right policy responses — so the signal reflects reality.
How to audit risky sign-in configuration
A practical audit checks:
1. Is identity protection actually enforced, not just alerting? Risk can be used in Conditional Access to block or challenge. Alerting alone changes nothing.
2. Are trusted named locations defined? This is the single biggest lever for cutting false positives.
3. Are sign-in and user risk policies present and scoped properly? Check that high risk is blocked or challenged, and that the scope covers the users who matter.
4. Is the licensing right? Risk-based policies require the appropriate entitlements. Mismatches create gaps and noise.
5. Is there a review cadence? Risk detections need a process — weekly or as they surface — or they are just a feed nobody reads.
These map directly to the identity frameworks. EIDSCA and CISA SCUBA both include sign-in risk and Conditional Access coverage checks; you can see the identity coverage on our EIDSCA benchmarking page.
Cut noise without cutting protection
The goal is a risk configuration that alerts on the things that matter:
- Define trusted named locations for corporate/VPN egress.
- Use risk-based policies to challenge (MFA) rather than only alert.
- Scope policies to all users where practical, with narrow, documented exceptions.
- Review detections on a cadence and tune the exclusions that cause the worst noise.
- Audit the configuration regularly — because a risk policy someone disabled during an incident is invisible until something goes wrong.
The short version
Risky sign-ins are high-value and high-noise at the same time. The difference is configuration: trusted locations, real enforcement, correct licensing, and a review process. Audit it like any other control, and the signal gets useful again.
Run an audit to check your identity protection configuration against the identity frameworks.