A caller asks the help desk to reset MFA. Nothing happens.
For your own help desk The same signature gate, applied to MFA resets for your own staff.
The ticket opens. The reset itself waits for a signature from the employee’s own enrolled device, which the caller cannot produce, however good the story is.
Written for CISO · IAM lead · Service-desk manager · SecOps
A caller knows the VP Finance’s date of birth, manager and last ticket number. The answers to every verification question are for sale.
The agent opens ticket T-8812 and clicks “reset MFA.” The reset does not fire. A push lands on the real employee’s enrolled phone.
She is in a meeting and taps nothing. The reset expires. The caller hangs up. A signed record of a reset that was requested and never authorized.
Each button is a real attack on this action. Press one. The signature stops verifying.
Nothing you press here leaves this tab. In this demo, a keypair generated in your browser signs the receipt. In production, the receipt is signed with Manav's published Ed25519 key after the approver's passkey check, and your gate verifies it offline.
The help desk is where these attacks start.
The intrusion doesn’t start in your customer’s IAM. It calls the help desk and asks. Training cannot fix a verification question whose answer is public, and a charming caller can sound exactly like a real employee. Only one of them holds the employee’s enrolled device. Several large 2023-2025 breaches began with a help-desk reset.
estimated cost of the 2025 M&S and Co-op cyber attacks.
Cyber Monitoring Centre, via The Register, June 2025Clorox’s claim against its service-desk vendor, alleging credentials were reset on request without verification.
Clorox v. Cognizant, The Register, July 2025What each person gets from the same receipt.
The answer to the board’s question this year: the caller alone cannot complete the reset, and the evidence is a signed event.
The same gate on admin-role grants, break-glass access and recovery-contact changes: the actions attackers actually want.
Agents stop being the control. They open the ticket; the employee’s device closes it.
Every requested reset, authorized or not, leaves a signed, verifiable record you can forward to your SIEM.
Check it on a machine we have never seen.
Download the receipt and verify it yourself with any Ed25519 library, offline, on your own machine. Verification needs only the published public key.
// Verify offline (Node 20+). Any Ed25519 library works. // npm i @noble/ed25519 then save as verify.mjs import * as ed from '@noble/ed25519'; // pub: "x" from the published JWKS. msg: the receipt's canonical bytes. // sig: the receipt signature. All three as Uint8Array. console.log(await ed.verifyAsync(sig, msg, pub) ? 'valid' : 'INVALID');
What this receipt does not cover.
A lost or new device still needs your existing high-friction manual path. The difference is that path is now reserved for the few who need it, instead of available to every caller.
The caller alone cannot complete the reset.
Your workflow calls sign() before executing any credential or MFA reset. The push lands on the enrolled device and is approved with the device passkey (Face ID / fingerprint). A fresh single-use request ID defeats a replay. Fails closed.
Bring the action you would gate first. We issue a real receipt on your payload, live on the call.
You verify it on your own machine, then change one byte and see it fail.
Where it sits in your stack and what the auditor re-performs. Then a plain yes, no, or not yet.
An engineer, not an SDR. No slides. Your email goes to one inbox and nowhere else.