How do you handle repeated high-risk alerts from an expired token?

November 15, 2026 4 answers
Asked by b702+clkpin_5

An M365 account was compromised, and the password and sessions were reset. Now failed sign-ins using an expired token from an IP associated with a known threat actor keep marking the user high risk and blocking their access.

Dismissing the risk only helps until the next attempt. Is there a practical way to stop the disruption without weakening security, or is a new account the better option?

Answers

Javlo-9m

I would open a Microsoft support case and include the sign-in and risk detection details. The distinction matters here: the attempts are failing, but the risk policy is still blocking the legitimate user.

Ask support to review the recurring detection and what remediation options are available. Keep checking the sign-in logs rather than assuming every future attempt will fail in the same way.

Reply to this answer
q.519__postbox

Changing the sign-in name is worth testing as a fallback. You could investigate keeping the old address as an email alias, but don't assume that a rename will stop token-based attempts or the risk detections. Verify both sign-in behavior and mail delivery before relying on it.

n.805!claspmark:

A fresh account is another option if the disruption continues, though that means planning the move of access and account data too.

Reply to this answer
c.925+byteclip

I'd be cautious about putting the user in a group that bypasses the high-risk policy. It may get them working again, but it also removes a control when a genuinely risky sign-in happens.

If an exception is necessary, keep it narrowly scoped, review the other protections on the account, and monitor it closely. Don't treat dismissing a detection as proof that the account is safe.

Reply to this answer
u.718!postcard

Blocking the source IP through Conditional Access may not solve the alert loop. Conditional Access is evaluated after authentication, and a failed attempt can still produce the risk detection that locks out the user.

It's also worth reviewing how the token was obtained and whether other credentials or sessions need investigation. The failed attempts alone don't establish that the original compromise has been fully contained.

Reply to this answer

Add your answer

Answers are reviewed before publication.

Related Discussions