Account Recovery: Getting Back Into an Account Securely

Imagine arriving at work and discovering that you can’t get into the building.

You’ve forgotten your key, your access card has stopped working, or perhaps someone has stolen your key.

The organisation needs to get you back inside.

But there is an obvious problem:

How do they know that you really are who you claim to be?

If the security guard simply says:

“You look like the person who normally works here, so I’ll let you in.”

an attacker could exploit the same process.

Account recovery is therefore a security problem in its own right.

Account recovery is the process of restoring legitimate access to an account when normal authentication is no longer possible or the account has been compromised.

It might be needed because:

  • A user has forgotten their password
  • An account has become locked
  • A phone has been lost
  • An MFA device is unavailable
  • Recovery codes have been lost
  • An account has been compromised
  • A user’s credentials have been stolen
  • A security key has been lost
  • An administrator needs to recover an account

Account recovery must be easier than losing an account—but harder than breaking into one.

Why Account Recovery Matters

Authentication controls are designed to prevent unauthorised access. But sometimes they also prevent the legitimate user from getting in.

A secure recovery process provides another way for the genuine user to prove their identity.

The Security Problem

Account recovery creates a second authentication path to allow legitimate users the ability to provide another form of identity if their primary option is unavailable.

This means the recovery process itself becomes a security control, but if the recovery process is weaker than the normal login process, an attacker may simply attack the recovery mechanism instead.

Imagine an account protected by a password, MFA, and device verification.

But the recovery process is a simple security question such as “Tell us your name and date of birth.”

An attacker doesn’t need to defeat the strong authentication – They attack the weak recovery process.

This is why account recovery needs to be designed with the same care as authentication.

Common Reasons for Account Recovery

There are many different situations that can require recovery.

  • Forgotten password
  • Lost MFA device
  • Lost security key
  • Locked account
  • Compromised account

These situations may each require different recovery procedures.

Password Reset vs Account Recovery

These terms are often confused.

A password reset is one type of account recovery.

Account recovery is a broader process though.

It can include recovering access when:

  • Passwords are unavailable
  • MFA is unavailable
  • Devices are lost
  • Recovery credentials are unavailable
  • The account has been compromised

Password reset is a recovery mechanism of the broader process of account recovery.

The Basic Recovery Process

A secure recovery process normally follows the steps below:

Step 1: Identify the User

The first question is – Which account are you trying to recover?

But knowing the username or email address does not prove that the person requesting recovery owns the account.

That’s the next step.

Step 2: Verify Identity

The recovery process needs evidence that the requester is genuinely the account owner.

This could involve:

  • A recovery code
  • A previously registered authentication method
  • A trusted device
  • A security key
  • An authenticator application
  • Identity verification
  • An administrator
  • Recovery information

Don’t rely on one weak question. A recovery process based on easily obtainable information is dangerous.

Attackers may be able to discover these details through:

  • Social media
  • Public records
  • Previous data breaches
  • Phishing
  • Social engineering

Knowledge-based questions therefore provide limited security.

A much stronger approach is to provide recovery codes when an account is initially configured.

Recovery codes should be treated as sensitive authentication credentials and hould generally be invalidated after use.

This prevents someone who obtained the code from using it repeatedly.

Because recovery codes are effectively a backup authentication mechanism, if an attacker obtains them, they may be able to bypass the normal authentication process.

They should therefore be stored securely. They should not simply be left in an unprotected file.

Recovery Email Addresses

Some services allow an account to have a separate recovery email address.

Whilst this can be useful, it introduces another security dependency – If the recovery email account is compromised, the attacker may be able to compromise the main account.

Similarly, organisations may use a registered telephone number as part of recovery.

However, SMS-based recovery has security limitations and should not automatically be considered equivalent to stronger forms of MFA. See the page about SIM swapping for more detail about this.

Recovery Using a Trusted Device

Another option is to use a device that has already been established as trusted.

The security of the trusted device therefore becomes important.

Recovery Using Another Authentication Factor

If one authentication factor is lost, another may still be available.

This is one reason organisations should avoid relying on a single authentication mechanism.

For example, a user may be permitted to register multiple authentication methods. So if one is lost, another can be used.

This reduces the risk of the user becoming permanently locked out. However, there is an important trade-off.

Suppose an account has five ways to recover access.

Every additional recovery mechanism is another potential attack path.

Therefore recovery methods should be convenient enough to prevent lockout, but strong enough to resist account takeover.

Account Recovery After Compromise

Recovering a compromised account is different from recovering a forgotten password.

Suppose an attacker has obtained the user’s password. Simply giving the legitimate user a new password may not be enough.

The attacker may also have:

  • Active sessions
  • Authentication tokens
  • Recovery methods
  • API keys
  • App passwords
  • Registered devices
  • Additional accounts

A compromised account may therefore require a more extensive process involving activities such as:

  • Contain account
  • Reset password
  • Revoke sessions
  • Review MFA methods
  • Remove unknown devices
  • Review recovery methods
  • Check account activity

before the account is restored

This is closer to incident response than a simple password reset.

Recovery Should Remove Attacker Persistence

This is similar to the malware removal concept covered here.

You don’t simply remove the obvious problem – You need to remove the attacker’s ability to return.

Administrator-Assisted Recovery

Organisations may provide administrators with the ability to recover accounts.

This can be useful for business systems, but administrator recovery itself needs strong controls.

If an administrator can recover anyone’s account, compromising the administrator could be extremely valuable to an attacker.

Administrator recovery privileges should therefore be carefully restricted.

Recovery and Privileged Accounts

Privileged accounts deserve special consideration.

Losing access to a normal user account is inconvenient, but losing access to the organisation’s only administrator account could be much more serious.

The higher the privilege, the stronger the recovery process should generally be.

Break-Glass Accounts

Organisations sometimes maintain special break-glass or emergency accounts. These are designed to provide access when normal authentication or administrative processes are unavailable.

These accounts can be extremely powerful and therefore require particularly strong protection. Often the credentials for break-glass accounts are stored in pieces so that more than one person needs to be involved in the recovery process. The pieces are commonly written on pieces of paper and kept in sealed envelopes in separate secure storage.

Instead, organisations should consider:

  • Strong credentials
  • Restricted access
  • Secure storage
  • Monitoring
  • Alerting
  • Regular testing
  • Clear procedures
  • Limited use

Recovery and Identity Proofing

For high-value accounts, the organisation may need stronger proof of identity. This is sometimes referred to as identity proofing.

The identity evidence could include any of the following:

  • Official documentation
  • Existing credentials
  • Trusted device
  • Other approved evidence

The appropriate level required depends on the risk associated with the privileged account.

Risk-Based Recovery

A useful approach is to make recovery more difficult when the circumstances are suspicious.

Factors might include:

  • New device
  • Unusual location
  • Suspicious IP address
  • Recent password change
  • Recent MFA change
  • Account compromise indicators
  • Privilege level

Recovery Notifications

Users should generally be informed when important recovery actions occur.

This gives the legitimate user an opportunity to report an unauthorised recovery.

High-risk recovery activity can also generate security alerts. This can be particularly important for privileged accounts.

Recovery actions should be logged. The logs can help establish:

  • Who performed the recovery
  • When it happened
  • What changed
  • Why it happened
  • Which methods were used

Recovery events can be sent to a SIEM. This can help identify suspicious recovery activity.

EUBA can also help identify unusual recovery behaviour. Remember that the combination of events may be more significant than any individual event.

Recovery and Incident Response

If account recovery is being performed because an account has been compromised, the process becomes part of incident response.

This is considerably more comprehensive than simply changing the password.

Account Recovery and MFA

MFA makes account recovery particularly interesting. Suppose a user loses their authenticator device.

The organisation needs another secure way to establish that the person is legitimate.

Possible mechanisms include:

  • Another registered authenticator
  • Security key
  • Backup security key
  • Recovery code
  • Trusted device
  • Administrator-assisted recovery
  • Identity verification

Recovery and Account Lockout

Account lockouts are often enforced to protect against brute-force attacks, but legitimate users can also trigger lockouts.

A recovery process allows them to regain access.

However, attackers may deliberately trigger lockouts to cause a denial-of-service against the user.

Therefore, recovery procedures should be designed carefully.

Don’t Make Recovery Too Easy

There is a fundamental tension between security and usability.

If recovery is too difficult it creates user frustration, and puts a burden of work on the supporting IT functions

If recovery is too easy , then not only is it easy for the legitimate user, it is easy for an attacker to abuse.

The objective is to find the appropriate balance.

Account recovery has an interesting security paradox:

The user needs a way around the normal authentication process, but the attacker must not be given the same way around it.

Recovery is effectively an alternative authentication mechanism.

Account Recovery as a Security Control

Account recovery can serve several purposes. It is primarily a corrective control because it restores access and security after a problem has occurred.

However, it can also have:

  • Preventive elements — strong recovery mechanisms prevent attackers taking advantage of weak recovery paths.
  • Detective elements — recovery events can generate alerts and logs.
  • Compensating elements — recovery methods provide an alternative when the normal authentication mechanism is unavailable.

So account recovery doesn’t fit neatly into just one category.

What Happens After Recovery?

Recovery shouldn’t necessarily be the end of the process. The organisation may want to review:

  • Password
  • MFA methods
  • Recovery methods
  • Trusted devices
  • Active sessions
  • API keys
  • Recent login history
  • Recent account changes

Recovery and Resilience

A good recovery process also contributes to resilience.

If users can securely recover their accounts it creates a level of organisational resilience

This is particularly important for critical systems.

Test Account Recovery

One of the biggest mistakes organisations can make is never testing their recovery procedures.

A recovery process that looks good on paper may fail when it is actually needed.

Organisations should consider scenarios such as:

“What happens if the only administrator loses their MFA device?”

or:

“What happens if the administrator account is compromised?”

or:

“What happens if the identity provider itself is unavailable?”

Testing these scenarios can expose serious weaknesses before a real emergency occurs.

In many organisations, the help desk plays an important role in account recovery, and that automatically makes help-desk staff potential targets for social engineering.

An attacker doesn’t necessarily need to hack the authentication system if they can persuade someone to bypass it.

Help-desk recovery procedures should therefore include appropriate identity verification.

Remember though that the process should avoid relying solely on information that an attacker could easily obtain.

Social Engineering is one of the biggest threats to account recovery.

An attacker may attempt to create a convincing story:

“I’ve lost my phone and I’m travelling.”

“I’m the CEO and I urgently need access.”

“My laptop was stolen.”

The story may be completely believable. But the recovery process should still require appropriate verification.

In Summary

Account recovery is the process of securely restoring access to an account when normal authentication is unavailable or the account has been compromised.

It can be required because of:

  • Forgotten passwords
  • Lost MFA devices
  • Lost security keys
  • Locked accounts
  • Lost recovery information
  • Compromised accounts
  • Lost or replaced devices

A secure recovery process should include:

  • Identify – Determine which account is being recovered.
  • Verify – Establish that the person requesting recovery is genuinely authorised to access the account.
  • Assess – Determine the risk associated with the request.
  • Recover – Restore access using an appropriate recovery mechanism.
  • Re-secure – Reset credentials, review MFA, remove unknown devices and revoke existing sessions where necessary.
  • Monitor – Watch for suspicious activity following recovery.
  • Audit – Record what happened and who performed the recovery.

Account recovery connects closely with many of the other controls covered in this series:

  • MFA provides strong authentication and alternative recovery factors.
  • Access Controls ensure recovered accounts retain the correct permissions.
  • Least Privilege prevents recovery from accidentally granting excessive access.
  • Separation of Duties can require multiple people to approve sensitive recovery.
  • Logging and Auditing records recovery activity.
  • EUBA can identify unusual recovery behaviour.
  • SIEM can correlate recovery events with other security events.
  • Incident Response handles recovery when an account has been compromised.
  • Zero Trust ensures recovery requests aren’t automatically trusted.
  • Secure by Design ensures recovery is considered when authentication systems are designed.
  • Defence in Depth provides multiple layers of protection around the recovery process.

The important lesson is that account recovery is part of the security boundary.

It shouldn’t be treated as a convenient customer-service feature bolted onto the authentication system.

If an attacker can defeat the recovery process, they may have effectively defeated the authentication system itself.

Make account recovery easy enough for the legitimate user—but hard enough that the attacker can’t use it to become the legitimate user.