Security & access continuity

Account and 2FA recovery, without giving up user control

In LoginMaster no administrator can reset a user's password, email or 2FA. So, if you lose the phone with your authenticator, how do you get back in? Here is the real recovery model, reconciled with exclusive user control and the zero-knowledge architecture.

See the two recovery pathsDiscover the security model

The principle: no admin can set your credentials

The heart of the LoginMaster model is exclusive user control: password, email and second factor cannot be read or set by an administrator. Credentials live in the customer's Tenant and the provider's Cloud stays zero-knowledge.

This raises a fair question: if you lose the device with your authenticator, how do you get back in without someone setting 2FA on your behalf? The answer is a two-path recovery model, designed never to break this principle.

Two paths to recovery

It always starts with user autonomy; admin approval steps in only when needed, and only to authorize.

Path 1 · Self-service

Get back in on your own with a recovery code

When you set up 2FA you receive a set of one-time recovery codes. They exist precisely for the day you lose, replace or wipe the phone with your authenticator: no administrator is involved and the principle of exclusive control stays intact.

  1. 1When you set up 2FA, you store the recovery codes somewhere safe (password manager, vault, printout).
  2. 2If you lose your TOTP device, at login you choose to use a recovery code instead of the time-based code.
  3. 3You enter a one-time code: it is consumed and authenticates you. You then re-enroll 2FA on a new device.
Path 2 · Admin approval

Request an MFA reset with administrator approval

If you no longer have your recovery codes, you open an MFA reset request. An administrator (of the tenant or of the project, according to the ACLs) approves it. The approval authorizes unlocking the second factor: the admin neither sees nor sets your credentials or your 2FA, it only authorizes you to reconfigure it yourself.

  1. 1You open an MFA reset request. The system prevents duplicate requests for the same user.
  2. 2An administrator with the permissions defined by the ACLs reviews the request and approves it.
  3. 3The approval authorizes resetting the second factor, without exposing any credentials.
  4. 4At your next login you reconfigure 2FA yourself on the new device.
Tenant · MFA reset
LoginMaster Tenant console: MFA reset request queue with status filter (pending, approved, rejected).
MFA reset approval from the console · real screenshot with anonymized data.

Why it is secure

Recovery is not a shortcut around the model: it respects every one of its constraints.

The Cloud stays zero-knowledge

Credentials and authentication factors remain in the customer's Tenant. The provider's Cloud neither reads nor stores them: recovery never opens a door onto the user's secrets.

The admin authorizes, it does not execute

No administrator can read or set a user's password or 2FA. In the approval path the admin only authorizes the unlock: reconfiguring the second factor stays in the user's hands.

Anti-abuse protection

MFA reset requests are tracked and protected against duplicates, so a request cannot be multiplied or used to bypass access controls.

Recovery fits into the same design as per-project configurable TOTP 2FA, the MFA enrollment grace period and the Tenant-Cloud architecture. Learn more in the features and the security page.

Recovery FAQ

If you kept your recovery codes, you get back in on your own: at login you use a one-time code instead of the TOTP code and then re-enroll 2FA on a new device. If you no longer have your recovery codes, you open an MFA reset request that an administrator must approve.

No. The administrator neither sees nor sets your credentials or your second factor. In the approval path it only authorizes unlocking the MFA: you are the one who reconfigures 2FA at the next login.

They are one-time recovery codes you receive when you set up 2FA. They let you get back in on your own if you lose your TOTP device, without involving any administrator. Keep them somewhere safe.

A tenant or project administrator, based on the configured ACLs. The approval authorizes resetting the second factor but does not expose credentials; requests are protected against duplicates.

No. Credentials and factors remain in the customer's Tenant and the Cloud stays zero-knowledge. Recovery does not give the admin the ability to read secrets: it only lets them authorize the unlock, while reconfiguration stays with the user.

Want to see it in action?

We'll show you live how recovery codes and MFA reset requests work, without ever exposing a user's credentials.

Request a demoExplore security