What should organisations do when suspicious account recovery activity appears?

Why Suspicious Account Recovery Deserves Immediate Containment

Suspicious recovery activity is often more dangerous than a normal login alert because it can signal an attacker trying to lock in persistence. Recovery channels are designed to restore control, so if they are being manipulated, the organisation may already be dealing with an active takeover attempt rather than a simple authentication failure.

That is why the right response is to slow the process down, increase assurance, and keep the affected session under tight control until the situation is understood.

In practice, the most important distinction is between a user who genuinely forgot access details and a request pattern that looks like reset abuse, help desk impersonation, or session hijacking. Treat the latter as an incident signal, not a routine service request.

Which Recovery Events Need the Strongest Response?

Some recovery actions are higher risk than others. Password resets, MFA resets, recovery email or phone changes, backup code re-issuance, and delegated account recovery all affect the controls an attacker would target to make access durable.

Events deserve special attention when they happen after unusual login geography, repeated failed access attempts, help desk pressure, suspicious device changes, or concurrent session anomalies. A single recovery action may be benign, but a cluster of changes in a short period usually means the actor is trying to move from temporary access to stable control.

Organisations should also separate self-service recovery from assisted recovery. If the recovery path relies heavily on human verification, the help desk or support function becomes part of the attack surface and must be monitored accordingly.

How Organisations Should Respond Without Losing Control of the Account

Start by verifying the event through an independent channel and pausing further sensitive changes. Preserve the current session state, restrict additional resets, and require stronger proof before any change that would alter the account’s recovery posture.

Where the risk is credible, isolate the session, revoke active tokens where appropriate, and review whether the attacker could still reach email, SMS, or device-based recovery routes. The goal is to stop the attacker from using the recovery path to regain durable access while avoiding unnecessary disruption to the legitimate user.

For systems that support it, step-up verification should be used before recovery is completed. This can mean stronger authentication, out-of-band validation, or manual review for higher-value accounts and privileged users.

Risk and Threat Considerations

Recovery abuse is attractive to attackers because it often bypasses the very control that originally blocked them. Once an attacker controls the reset path, they can replace passwords, enroll new authenticators, and make the compromise harder to reverse.

Failure mechanism: Weak recovery assurance, poorly monitored help desk flows, or overly permissive self-service changes allow an attacker to turn a temporary foothold into persistent control of the account.

Impact: The organisation can lose trusted access to email, collaboration tools, admin portals, or customer systems, and the attack may continue even after the original password is changed.

Practitioner Guidance

What to prioritise: Treat recovery events as a control-plane problem, not just a user-support event. The first job is to determine whether the actor is trying to change the account’s future recovery options, not merely regain access once.

What to verify: Confirm whether the same account has recent authentication anomalies, device changes, or help desk contact patterns that do not fit the user’s normal behaviour. If the recovery step is the only suspicious action, keep it under review; if it is part of a wider pattern, escalate as an active takeover attempt.

Decision rule: If the change can expand the attacker’s durability, such as replacing a reset factor or adding a new trusted device, pause it until verification is complete and the session has been assessed.

Practitioner takeaway: The key judgement is to protect the recovery path with more scrutiny than the normal login path, because that is often where an attacker tries to convert initial access into lasting control.

Related resources from NHI Mgmt Group

• What should organisations do after a suspicious identity provider account activity is discovered?
• What should organisations do after they detect suspicious privileged account activity?
• How can organisations tell legitimate automation from compromised service account activity?
• When should organisations use stronger identity proofing for account recovery?