What must phone-based authenticator re-enrolment require that a caller with a name cannot supply?

## Frame it as a precondition, not as a behaviour The question is deliberately asked as an architecture question, and the strong answer refuses to answer it as a training question. Write down what the operator actually needs in order to succeed: 1. A name of a real employee, and enough surrounding facts to sound internal. 2. A reason to be locked out that is common and unremarkable — a replaced phone, a lost device, a new starter's handset. 3. A process that can complete a factor change using facts the caller states, over the channel the caller chose. Items 1 and 2 are free. Company directories, professional networks, an out-of-office reply, a job advert naming the internal tooling — none of that can be taken back, and none of it is a defect. **Item 3 is the only precondition you own.** Everything worth doing is aimed there. ## Why knowledge checks fail, categorically Employee ID, manager's name, date of hire, the last four digits of a payroll or personal identifier, the name of the department's project — every one of these is a fact. Facts can be researched, guessed, or simply supplied by the caller with confidence, and the caller only has to be right once while the desk has to be right every time. Worse, a failed knowledge check often teaches the operator what is being asked so the next call goes better, and the crew's tempo means the next call is minutes away with a different agent. The general rule to state out loud: **a check the caller can answer with information cannot distinguish a caller who has information from a caller who is the person.** ## What actually changes the precondition Ranked by strength: **1. Approval signed from an already-enrolled credential.** The cleanest control: to add a new authenticator, prove control of an existing one. It moves the requirement from knowledge to possession, and possession is the thing the caller does not have. The design consequence is that users must hold **two** credentials from day one — a security key plus a platform authenticator, or two keys — so the ordinary lost-phone case is self-service with the spare and never reaches a human at all. **2. Identity proofing that is not conducted by telephone.** For the genuine both-credentials-lost case, something out of the channel: in person at a desk or a locker, or a documented remote proofing session against a government identity document with the result recorded against the account. This is slow and that is acceptable, because the design intent is that almost nobody needs it. **3. An independent assertion by a second person, through an authenticated workflow.** A manager approval that arrives as an authenticated action in a system — not a name spoken on a call, and not an email that could have come from anywhere. The property that matters is that the approver was authenticated, and that the approval is bound to the specific request. **4. Confirmation to a channel the organisation binds, plus delay.** A challenge pushed to an enrolled device, or a notification on the account's own internal channels, together with a mandatory waiting period on factor changes. This is weaker than 1–3 and must never rest on a phone number, since a number can be re-pointed by its carrier. Its real value is tempo: callback operations burn one pretext per call and cannot sit through a 24-hour hold. ## The two wrong answers, and why they are wrong **"Train the service desk to spot it."** The desk exists to get blocked people working again, and is measured on doing that quickly. The pretext is not an anomaly against that job — it is a perfect example of it. Awareness raises the pass rate for the operator's next attempt, not the floor of the process. Training is worth doing and it is not a control. **"Require more MFA."** Each factor you enrol comes with a way to recover it, and a recovery path is a lower-assurance route to the same account. Adding factors without designing recovery increases the number of doors while leaving the weakest one unchanged. State the inversion plainly: **the assurance of an account is the assurance of its weakest recovery path, not of its strongest factor.** ## The trade you should name before you are asked Anything strong enough to stop the call is also strong enough to strand a legitimate employee at 2 a.m. on another continent. The resolution is not to weaken the check but to make it rare: issue spare credentials at onboarding so self-service covers the common case, and reserve the slow proofed path for genuine total loss. Where the cost is still unacceptable, tier by privilege — administrators, finance approvers and anyone who can move money or change identity configuration always take the slow path, whatever it costs them. ## What a strong answer sounds like "The technique needs a re-enrolment path that can be completed with facts over a channel the caller picked. So the path has to require possession — an approval from an already-enrolled credential — or an assertion the caller cannot make for themselves, like in-person proofing or an authenticated manager approval. Training the desk does not change the precondition, and adding factors adds recovery paths. I would issue everyone a spare credential so the human path is exceptional, and make that exceptional path slow and proofed."