How do you detect sign-ins from malicious IP addresses in Microsoft Entra ID?

Detect them by alerting on Entra sign-ins that are associated with known malicious or suspicious IP reputation data. Prioritise failed attempts, repeated MFA prompts, and successful logins from the same address across multiple accounts. Confirm whether the source is tied to automation, password spraying, or bot activity, then block or challenge the session as appropriate.

What “malicious IP” detection should look for in Entra ID

Detection starts with Entra sign-in telemetry, then adds reputation context from threat intel, proxy, EDR, and identity logs. The useful signal is not just a bad IP on its own, but a sign-in pattern that matches abuse: repeated failures, MFA fatigue prompts, password spraying, token replay, or one source touching many accounts. Correlate the IP with user, app, device, location, and time window before you decide it is truly hostile.

Because IP reputation changes quickly, treat “malicious” as a scoring input rather than a final verdict. A single sign-in from a flagged address may be noise, but a cluster of failures followed by success, or the same address appearing across unrelated accounts, is much stronger evidence of active abuse. That is why teams usually combine reputation with behavioural indicators and session context rather than relying on the IP field alone.

For practitioners who want the control pattern rather than the alert pattern, Microsoft’s own sign-in and risk tooling is most effective when it is tuned to the behaviours that matter. The right detection logic should flag suspicious sources early, then enrich the event so the responder can distinguish automation from a user travelling or using a shared network. Active Directory and Entra ID Hardening Guide is useful here because it covers the broader hardening context around Entra ID, conditional access, and attack-path reduction.

How to tune detections so they catch abuse, not just noise

Build rules around combinations of signals. For example, a failed sign-in from a suspicious IP is useful, but a failed sign-in followed by repeated MFA prompts, then success from the same source against several accounts, is much more actionable. Add thresholds for spray-like behaviour, unusual geography, impossible travel only where it is reliable, and account concentration from a single source. If you have threat intel feeds, use them to enrich the event, not to replace the behavioural check.

Also watch for signs that the IP is part of automated activity rather than a human session. Bots often create a high volume of low-and-slow attempts, rotate accounts, and avoid normal user timing patterns. If the same source touches many tenants, many users, or many failures across short periods, treat it as a stronger candidate for blocking or step-up verification. Cloud Logging and Audit Trail Guide supports this approach by showing why correlation across audit and sign-in logs matters when you want a defensible alert.

To keep detections useful, separate “known bad” from “suspicious but unconfirmed.” Known bad IPs can justify immediate containment, while suspicious IPs should usually trigger higher scrutiny, such as MFA challenge, token revocation review, or temporary access restriction. That distinction keeps you from overblocking residential ISPs, mobile carriers, and shared egress points that occasionally appear hostile but are not actually malicious.

What to verify before you block the session

Before you take action, confirm whether the source is already associated with a wider incident pattern. Check whether the same IP is also tied to password spraying, suspicious MFA prompts, consent abuse, or repeated access across accounts that should not normally share a source. If the event is successful, verify whether the session is still active, whether refresh tokens may already be issued, and whether downstream activity has started.

When the sign-in lands in an administrative or high-value account, the response should be faster and stricter. Review the sign-in history for companion indicators such as device changes, new browser fingerprints, or unusual conditional access outcomes. If the same address keeps reappearing after blocks, treat that as evidence of persistence, not a one-off alert. Identity Recovery Guide is a good adjacent reference when the sign-in event turns out to be part of a larger identity compromise and you need to think beyond simple containment.

Risk and Threat Considerations

Malicious IP detection is only useful when it is paired with behavioural context, because attackers can reuse infrastructure, pivot through common cloud providers, or hide behind proxies and residential networks. The main risk is both false negatives, where the source looks ordinary, and false positives, where legitimate users are blocked because the IP reputation signal was stale or overbroad.

Failure mechanism: The defender treats IP reputation as sufficient evidence and misses correlated abuse such as password spraying, MFA fatigue, or automated account probing. Alternatively, the defender overreacts to a shared or transient IP and creates noise that weakens analyst confidence.

Impact: Missed abuse can lead to account takeover, token issuance, and lateral access across multiple accounts. Overblocking can interrupt business users, hide the real attack path in alert fatigue, and delay response to the actual source of compromise.

Standards & Framework Alignment

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

NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AU-6 — Audit Record Review, Analysis, and Reporting	Entra sign-in detection depends on reviewing correlated audit and sign-in events.
	IA-2 — Identification and Authentication (Organizational Users)	Malicious sign-ins target user authentication events and account takeover paths.
	AC-7 — Unsuccessful Logon Attempts	Repeated failures from the same IP are a core signal for spraying and automated abuse.
Recommendation — Correlate sign-in and audit records to identify hostile IP patterns and suspicious authentication behaviour. Strengthen user authentication controls and monitor authentication failures tied to hostile sources. Alert on repeated failed logons from the same source and escalate when they cluster across accounts.
NIST CSF 2.0	DE.CM-08 — Malicious Code and Anomalous Behavior Detection	The question is about detecting suspicious sign-in behaviour and hostile source patterns.
	PR.AA-05 — Access Permissions, Entitlements, and Authorization Management	Blocking or challenging risky sign-ins depends on enforcing access decisions based on risk.
Recommendation — Monitor authentication telemetry for anomalous sign-in patterns tied to hostile infrastructure. Apply risk-based access decisions to challenge or block suspicious sign-ins from hostile IPs.

Practitioner Guidance

What to prioritise: Prioritise the sign-ins that combine hostile reputation with repeated failures, multiple accounts, and any successful authentication from the same source. Those events are much more likely to indicate active abuse than a single low-confidence hit.

What to verify: Confirm whether the IP is part of automation or spraying by checking the account spread, timing, and MFA behaviour. If the source succeeds, validate whether the session or refresh token is still live before you assume the event is contained.

Decision rule: If the address is clearly tied to active abuse, block or step-up challenge immediately; if the signal is weaker, keep it in monitoring until you can corroborate it with identity, device, or session evidence.

Practitioner takeaway: IP reputation is an input to investigation, not the conclusion, and the strongest detections are the ones that turn a suspicious source into a provable abuse pattern.