01
Attackers do not beat the login, they walk around it
Recovery receives a fraction of the design attention that sign-in gets and absorbs a disproportionate share of the attacks. That is not an accident of neglect. It follows from what recovery is for.
The 2023 intrusion at MGM Resorts is the case identity teams now cite by reflex: attackers reached the IT help desk by telephone, impersonated an employee, and were let in, with the company reporting an impact of roughly 100 million dollars. No amount of training resolves a process whose purpose is to be helpful to a stranger in a hurry.
Whoever holds the mailbox holds the account
Where a mailed link can set a new credential, the mailbox is the real credential, and every control on the sign-in page is decoration around a weaker entrance.
Human overrides add uncertainty
Refusing a convincing caller who knows a handful of public details is hard for one person and impossible to make consistent across a team. A manual exception is a policy no test suite ever exercises and no review can reconstruct properly afterwards.
High support volume creates recovery risk
High reset traffic trains agents to move quickly, and speed is exactly the condition under which social engineering works. The queue is not just a cost, it is the attack surface.
02
With no password, recovery is a device problem
Nothing is reset because nothing was set. A user's ability to sign in rests on two things: their face, which they still have, and the key material bound to their enrolled phone, which is what a lost phone takes with it.
So nothing is reissued. A device is re-bound instead, and the gate on that operation is proof of control over contact points the account already held before anything went wrong.
The PIN goes to contact details already on file
It is sent to the mailbox recorded on the account, and by SMS as well when the profile carries a mobile number. The user types it once, on the new handset, and that handset becomes the bound device.
Or prove the mailbox over the backchannel
Where the shape of the flow makes it easier, a backchannel request can carry the same proof: the person demonstrates that the mailbox on file is theirs. The end state does not differ. The replacement handset is bound either way.
A face without a bound device proves nothing
There is no route back in that consists of looking at a camera on unfamiliar hardware. Half of a valid sign-in is the key that lives on a bound handset, and a stranger with a photograph holds neither half.
Resume the normal face-login flow
The ceremony runs on the replacement handset and the person is back where they started. The account itself was never altered: the same sealed token it already carried is what the new device authenticates against, and the re-bind changes nothing about how it is held.
03
What the PIN is, and what it is not
One-time PINs have a poor reputation, and it is deserved wherever they are used as a sign-in factor. The distinction that matters here is what this PIN can authorize.
It binds one device, once, and is spent doing it. It cannot be exchanged for a session, cannot be replayed, and is useless anywhere except the device being bound. It also never appears during a normal sign-in, which gives you a clean line for your own user guidance: anyone asked for a PIN at a sign-in screen is on a page that is not ours.
A PIN authorizes one device binding
There is no second use and no other operation it can reach. It is not a credential, and there is no session sitting behind it to take.
Possession of the new phone is still required
The PIN is entered on the device being bound, and that device then has to pass a live face check against the enrolled account. Intercepting the message alone does not produce access.
Use PINs only for device binding
Binding. Not sign-in, not step-up, not approval. That single-purpose scope is what makes the rule simple enough for users to remember and apply.
04
What changes for the support team
The largest single category of authentication ticket disappears, because a forgotten password is not a thing that can happen. What remains is genuine device replacement, which is a smaller number and a far more predictable one to staff against.
Revocation gets simpler in the same move. A lost handset is not a credential to be chased from system to system: removing the device takes its keys and its refresh-token families out together, and with no standing provider session for end users, the old phone has nothing left to ride.
Self-service recovery for supported cases
The message arrives at an address that was already on the account, and the binding finishes on the new handset. No call, no wait, and no agent asked to make a judgment under time pressure.
Revoking a device is one action
Cutting device keys and refresh-token families together closes out the old phone rather than waiting for a session to expire on its own schedule.
The record names the device
Authentications are written to a read-only, person-level activity stream, so a review can see which device produced which sign-in, and when the pattern changed.
05
The boundary between recovery and proofing
Naming this limit matters, because recovery is the point at which teams are most tempted to ask a product for something it does not do. A passing ceremony confirms one fact: the living person at the camera matches the enrollment held against this account. Their identity in the wider world is a separate question and no part of the result.
Where the stakes justify more, the administrator-assisted path is the place to attach your own proofing: whatever check your organization already trusts for a high-value exception, applied by someone authorized to make that call, and recorded as an administrative action.
No document check, no data lookup
There is no KYC step and no age estimate at any point, at enrollment or at recovery. Those controls, if you need them, belong to your own process.
Administrative action is recorded
Changes an administrator makes in the console append to a hash-chained, tamper-evident log, which is the record a reviewer will ask for when an exception was granted by hand.
06
Frequently asked questions
How does recovery work when there is no password?
The user binds a new device. A one-time PIN goes to the mailbox recorded on the account, and by SMS as well where the profile carries a mobile number. It is entered on the new handset, the face ceremony follows, and access returns. A CIBA email proof serves as the alternative gate. The replacement must also prove a new device key; the account remains bound to the enrolled person through biometric-free, disposable face tokens, and the live face check is still required at sign-in.
What if the user has lost the phone and cannot reach the email account?
There is no self-service path in that case, by design. An administrator has to intervene, and that action is recorded in the console's tamper-evident log. An automated route requiring no proof of possession would reintroduce the weak reset flow this replaces.
Could somebody who intercepts the PIN take over the account?
The PIN authorizes one device binding and nothing else. It is entered on the device being bound, which then has to pass a live face check against the enrolled account, so the message on its own is not enough.
Does a user ever get asked for a code at sign-in?
Never. A PIN appears once in the lifecycle, at device binding. A user asked for one on a sign-in screen is looking at a page that is not ours, and that is a simple rule to publish in your own security guidance.
How quickly can a lost device be cut off?
Removing the device takes its keys and its refresh-token families out together, and a suspension lands at the next token refresh. No provider-side single sign-on session exists for end users, so nothing keeps the old handset alive in the background.
Does SenseCrypt check identity documents during recovery?
No. SenseCrypt authenticates the enrolled person. Identity proofing, where you need it, sits upstream of enrollment or inside your own administrator-assisted exception process.