The takeover button is labelled "Add authenticator"

Your account security model probably treats a payment as high risk and a settings change as routine. That ranking is backwards. Enrolling a new authenticator is the single most consequential thing anyone can do inside an account, because it converts a stolen session that expires into durable access that does not.

The security engineer found it on a Tuesday, which is when these things are always found, because Monday is for meetings and Friday is for pretending the week is over.

She was not looking for it. She was tuning alert thresholds on the identity provider, trying to work out why the anomalous-login rule fired eleven times a day and was correct roughly once a month. To calibrate, she pulled ninety days of authentication events for a sample of forty accounts and started reading them the way you read a stranger's diary, quickly and slightly guiltily.

Account nineteen had a line she read twice. Three weeks earlier, at 03:14 local time, the log said: user.mfa.factor.activate. A new passkey had been registered. The device name was "iPhone". The event was green. It had generated no alert, because registering an authenticator is not anomalous. It is hygiene. It is the thing security teams spend entire quarters begging people to do.

The account belonged to a finance manager who had been on annual leave that week, in a time zone where 03:14 local was the middle of her afternoon, so even the timestamp looked reasonable. She had noticed nothing. She still had her phone, her laptop, her original passkey, and full access to everything. Nothing had been taken from her. Something had been added.

For three weeks, the account had two owners.

What actually happens after an attacker steals a session?

There is a persistent mental model of account compromise that goes: attacker gets in, attacker does the bad thing, attacker leaves. It is a burglary model. It shapes how alerts are written, how playbooks are drafted, and how executives are briefed, and for a certain class of smash-and-grab fraud it is roughly accurate.

It is not how competent intrusions work. A stolen session is a wasting asset. Session cookies expire. Conditional access policies re-evaluate. Someone rotates a token, a device drops off the network, the user logs out on a plane. An attacker who has just spent effort and money obtaining access to an account is holding something that is quietly decaying in their hands, and their first priority is not to spend it. It is to convert it into something that does not decay.

The conversion step is enrollment. Register a new authenticator, and the attacker now holds a credential that is independent of the compromised session, survives a password reset, survives the victim logging out everywhere, survives the phishing page being taken down, and in many configurations survives the victim changing their password out of vague unease. The attacker has stopped being a visitor and become a resident.

The full sequence, as it appears in incident timelines again and again, has five beats, and it is worth walking each one slowly because the ordering is the whole lesson.

One: obtain a session. The method barely matters, which is itself an important point. An adversary-in-the-middle phishing kit relays the genuine login page and harvests the post-authentication token, so the victim authenticates correctly against the real identity provider and the attacker collects the result. Tycoon 2FA, disrupted in an action reported in March 2026 involving Microsoft, Europol and partners, is the widely cited example, with reporting describing victim counts in the tens of thousands and hundreds of seized domains. An infostealer on a contractor laptop achieves the same thing without any phishing. A device-code phishing campaign persuades someone to type a legitimate code into a legitimate Microsoft page. A help desk, following its documented procedure, resets a factor for a caller who sounds credible and stressed. Five different front doors, one identical outcome: the attacker holds an authenticated session.

Two: re-authenticate. This is the part that surprises people who have not looked closely at their own enrollment policy. Most platforms do require a step-up before you can add an authenticator, and security teams reasonably regard that as protection. But the step-up is satisfied by the session the attacker is holding. If the policy says "re-enter your password", the attacker has the password. If it says "approve a push", the attacker triggers it and the victim, conditioned by a decade of approving pushes, approves it. If it says "confirm with your existing passkey", and the attacker has a live session from an adversary-in-the-middle proxy, the proxy relays that ceremony too. The gate is real. It is just installed on the wrong side of the door.

Three: register. The attacker enrolls their own authenticator. On a modern platform this takes about four seconds and produces a log line indistinguishable from a user setting up a new phone, because that is exactly the API being called. There is no separate "suspicious enrollment" endpoint.

Four: prune, optionally. Some attackers remove the victim's original factors, which is loud and forces the victim into a recovery flow the attacker may also be positioned to intercept. More careful attackers leave them alone. A victim who can still log in normally has no reason to investigate anything, and the intrusion stays quiet for as long as the attacker wants it to.

Five: act, eventually. Now, and only now, the attacker does whatever they came to do. Sometimes within hours. Sometimes after weeks of reading email and learning who approves what. The gap between step three and step five is what makes this pattern so damaging, because every hour in that gap is an hour where the account looks fine and is not.

Why is "add authenticator" more dangerous than "reset password"?

Ask a security team to rank the risk of account operations and you will get a fairly consistent answer: moving money is highest, changing a password is significant, changing an email address matters, and adding an MFA device is somewhere in the middle, filed under account hygiene.

That ranking measures the wrong axis. It measures the immediate value of the action. What matters for an attacker is the durability of the access the action creates, and on that axis the ordering inverts almost completely.

Durability is the property nobody ranks

Think about a hotel. There is a difference between someone who slips through the lobby door behind a guest, and someone who walks up to the front desk and is issued their own key card. The first person has to keep slipping in and will eventually be noticed. The second person is now a guest. The door does not merely open for them, it opens for them legitimately, and every subsequent entry is invisible because it is indistinguishable from every other guest's entry.

Registering an authenticator is being issued a key card. And in most systems, the way you prove you are entitled to a key card is by already being inside the building.

Here is the same set of operations ranked by durability rather than by immediate value. The right-hand column is the one that matters and the one almost nobody computes.

Read the bottom row again. The operation most platforms treat as the least interesting produces access that is independent of the original compromise, resistant to phishing (working now for the attacker rather than for you), and invisible in normal use. The strongest authentication technology the industry has built becomes the attacker's own security control, defending their access from you.

This is the ugly irony at the centre of the passkey era. Passkeys are genuinely excellent. They defeat credential phishing, they cannot be reused across sites, and they end password reuse as an attack class. They deserve the adoption they are getting. But by making credentials much harder to steal, they moved the entire economics of intrusion one step earlier in the chain. You cannot steal a passkey, so nobody tries. You add one instead.

This is the same structural pattern we describe in the payee add is the real transaction: the operation that changes the shape of an account is more consequential than the operation that moves value through it, because shape changes are what make future value extraction look normal. Adding an authenticator is the account-shape change that governs every other one.

Why does re-authentication not stop this?

Because re-authentication answers a question about the session, and the attacker's problem was never the session.

When a platform asks you to re-authenticate before a sensitive change, it is checking whether the current session still corresponds to someone who can satisfy the login requirements. That is a genuinely useful check against a completely different threat: the unattended laptop, the shoulder surfer, the shared machine at a co-working desk. It was designed in an era when the primary risk to a logged-in session was physical proximity.

An attacker holding a stolen session satisfies it by construction. They have the session because they completed, or relayed, the authentication that produced it. Asking them to do it again is asking them to repeat something they have already demonstrated they can do. This is the failure we call Session-Inherited Authorization, described at length in your MFA worked perfectly and the attacker was already inside the session: every action after login carries the authority of the login, so any theft of the session is a theft of all subsequent authority.

The help desk version is the same failure with a human in the loop instead of a cookie. The Scattered Spider intrusions documented by CISA in advisory AA23-320A worked by social engineering IT support into resetting or re-enrolling factors, and the reported outcomes at MGM Resorts, which disclosed an impact in the region of one hundred million dollars in its own filings, and at Caesars, illustrate how much follows from that one operation. The attacker never defeated a cryptographic control. They persuaded a person to perform an enrollment on their behalf, which is precisely the assisted form of the same action. We wrote about that path in the help desk can be fooled.

And the scale is not niche. The FBI's Internet Crime Complaint Center advisory of 25 November 2025 reported more than 262 million dollars in account takeover losses across more than 5,100 complaints since the start of that year, with attackers frequently impersonating institutions to obtain credentials and codes. Not every one of those involves an enrollment step. A great many of the ones that persist do.

Why do the notification emails not help?

They help a little, and they fail in three specific ways that are worth naming because each one has a different fix.

They arrive in a place the attacker may control. If the intrusion started with mailbox compromise, the notification lands in an inbox where a rule can file it into a folder nobody opens, or delete it outright. Notifying the account holder through the channel the attacker just took over is a design that assumes the attack it is warning about did not happen.

They are unactionable. Consider what a well-written notification actually says: a new sign-in method was added to your account, if this was not you, please contact support. The recipient is a finance manager, not an incident responder. They do not know what a passkey is, they cannot tell whether "iPhone" is theirs, and the only lever available to them is a support queue that will ask them to verify their identity, possibly by adding an authenticator. If a warning cannot be acted on, it is not a control, it is a record.

They are sent after the fact. This is the fundamental one. The notification is emitted after the enrollment has been accepted. The attacker already holds the credential. Even a perfectly delivered, perfectly understood, immediately acted-upon notification is a race, and the attacker got a head start measured in however long it takes a human to read email.

Detection tooling has the same shape. Identity threat detection products can absolutely flag an unusual registration, and good ones do. But detection operates after the authority was granted, and the honest question for any detection control is what percentage of cases it catches before harm and how long the tail is. In an operation that takes four seconds and looks like hygiene, that tail is long.

What should happen before an account accepts a new passkey?

The account should require that the new key be introduced by a key it already trusts.

That sentence sounds almost too simple, so let us be precise about what it changes. Today, the logic of enrollment is: this request came from an authenticated session, therefore accept the new credential. The proposal is: this request carries a signature from a credential already enrolled on this account, over the specific details of the credential being added, therefore accept it.

The difference is the difference between an assertion about state and a signed act by a human. A stolen session is state. A signature from the victim's existing device is not something the attacker can produce, because producing it requires the victim's device, and the victim's device is precisely what the attacker does not have.

What gets signed

The payload must name the thing being introduced. Signing a generic "approve" is worthless, because a generic approval can be replayed against a different registration. What matters is that the signature covers the identity of the new credential specifically, so that a signature obtained for one enrollment cannot authorise another.

A concrete payload looks like this. Every field is doing work.

{
  "act": "authenticator.enroll",
  "account": "acct_8831f0",
  "new_credential_id": "kQ3n...T7A",      // the credential being added
  "new_credential_aaguid": "d548826e...", // authenticator model
  "device_label": "iPhone",
  "introduced_by": "cred_2f91ab",         // an already-enrolled credential
  "issued_at": "2026-09-14T09:12:44Z",
  "expires_at": "2026-09-14T09:17:44Z"    // five minute window
}

The registration endpoint computes the hash of that canonical object, requires a WebAuthn assertion over it from introduced_by, and refuses the enrollment without one. In outline:

function acceptEnrollment(req) {
  const payload = canonical(req.enrollmentPayload);
  const receipt = req.coSignature;

  // 1. The signature must come from a credential already on this account
  if (!account.credentials.includes(receipt.credentialId)) reject("not co-signed by an enrolled key");

  // 2. It must cover THIS credential, not a replayed generic approval
  if (receipt.payloadHash !== sha256(payload)) reject("signature does not bind this credential");

  // 3. Freshness, so an old receipt cannot be reused
  if (now() > payload.expires_at) reject("expired");

  // 4. Verify offline against the published key. No callback needed.
  if (!verifyEd25519(receipt, publishedKey)) reject("invalid signature");

  account.addCredential(req.newCredential, { introducedBy: receipt.credentialId, receipt });
}

Note the last line. The account does not merely accept the credential, it records which key introduced it. Do that consistently and you accumulate something no platform currently has: a genealogy of the authenticators on an account. Every key can be traced back through the key that introduced it, to the key that introduced that one, to the original enrollment. When something goes wrong, the question "where did this credential come from" has an answer instead of a shrug.

Manav's Beam pairing already works this way for device claiming: a new device is bound through a one-time token issued after a face-liveness challenge, tied to the same one-way person key, so the new device inherits its trust from a verified continuity event rather than from an ambient session. Applied to an identity provider or a bank's device-registration service, the same receipt becomes the required input at the enrollment hook. The technical details of the receipt format are in the developer documentation, and you can see the pairing ceremony end to end in the account lab.

Add a cooling period, but do not rely on it

A useful companion control: a newly enrolled authenticator can log in, but cannot perform high-value actions or enroll further authenticators until it has aged, typically 24 to 72 hours. This gives notifications time to be read and gives the platform a window to reverse an enrollment cheaply.

Two honest caveats. First, cooling periods are friction, and friction gets negotiated away by whoever owns the conversion metric, usually about six months after the incident that justified it. Write it down as a policy with an owner or it will quietly become two hours. Second, a cooling period is a delay, not a denial. It buys time for a control that can actually say no. Co-signature is that control; the cooling period is the alarm attached to it.

What about the person who lost every device?

This is the serious objection, and it deserves a serious answer rather than a hand wave, because a co-signature requirement is only as good as its answer to the person standing at the airport with a broken phone.

The honest answer has two parts.

First, the bootstrap case is genuinely different from the steady-state case, and conflating them is what produces bad designs. Enrolling your second authenticator when you already have one is a completely different security question from enrolling your first after losing all of them. The first can and should require a co-signature. The second cannot, by definition, and needs a recovery ceremony instead.

Second, the recovery ceremony should establish continuity, meaning evidence that this is the same human as before, rather than re-running identity proofing from documents. That is a substantial topic in its own right and we have written it up separately in passkeys fixed the login and recovery is where the account gets stolen now, and in more mechanical depth in why does losing your phone mean uploading your passport. The short version is that a companion liveness check against the one-way key created at enrollment, or a co-signature from a designated trusted contact, or simply a longer time window, all provide continuity evidence without the platform holding a biometric template or a photograph of a passport.

What matters for this post is the architectural point: the existence of a recovery path is not a reason to leave the steady-state path ungated. Most enrollments are not recoveries. Most enrollments happen while the user is holding a working device. Gating those correctly costs the honest user one tap and costs the attacker the entire attack, and routing the genuinely hard minority through a deliberate, slower ceremony is a feature rather than a compromise.

What are the honest limits?

Several, and they are real.

A compromised device defeats it. If the attacker controls the victim's enrolled device, they can produce the co-signature. This control raises the bar from "steal a session" to "compromise a device", which is a very large increase in cost and skill, but it is not infinity.

A tricked user defeats it. A victim who is talked into approving an enrollment they do not understand produces a perfectly valid signature. The signature binds intent to an action; it does not audit whether the intent was well-informed. This is why the prompt matters enormously and should name what is being added in plain language, and why any implementation that shows a generic "Approve?" has thrown away most of the value.

The bootstrap remains the trust bottleneck. Everything above rests on the first enrollment being bound to the right human. Get that wrong and every subsequent co-signature is a chain anchored to the wrong person, faithfully verifying nonsense.

It requires the relying party to change an endpoint. This is not a setting anyone can toggle. It is a change to the registration hook, using Okta Workflows, Entra custom authentication extensions, or the equivalent in a bank's device-registration service. Manav does not ship native identity provider connectors today; integration is through the API at the enrollment hook.

It does not span ecosystems on its own. Apple and Google already do a partial version of this inside their own ecosystems, where adding a device typically requires an existing device. That is genuinely good and covers a great deal of consumer risk. What it does not do is span a bank, an identity provider, an exchange, and a consumer platform with one portable artifact, which is the gap this addresses.

What to audit this week

Concrete, in rough order of effort.

1. Find your enrollment policy and read it literally. Not the intent, the configuration. Write down the exact condition under which your identity provider accepts a new authenticator. If the answer is "an authenticated session, possibly with a step-up", you have the gap.
2. Pull ninety days of enrollment events. Count them. Most teams are surprised by the volume. Look for enrollments outside working hours, enrollments that closely follow a password reset or a help desk ticket, and accounts with more authenticators than the person has devices.
3. Check what your notification actually says, by triggering one on a test account. Read it as a non-technical user. Ask whether it names the device in a way a person could recognise, and whether it offers an action they can take in under a minute.
4. Test the help desk path yourself. Call your own service desk as a user who has lost a device. Note the exact evidence they accept. This is usually the most uncomfortable and most valuable thirty minutes in the whole exercise.
5. Rank your account operations by durability, not by immediate value, using the table above as a starting point. Bring the reordered list to your next risk review. The conversation it starts is the real deliverable.
6. Introduce a cooling period for newly enrolled authenticators before they can approve high-value actions or enroll further keys, and give it a named owner so it does not erode.
7. Require co-signed enrollment for privileged accounts first. Administrators, finance approvers, anyone who can move money or change access. Prove the flow on a population that will tolerate friction before you take it wider.
8. Record the introducing credential on every enrollment, starting now, even before you enforce anything. The genealogy is only useful if you have been collecting it, and it costs one column.

Frequently asked questions

Can someone add a passkey to my account without my permission? On most platforms today, yes, if they have a valid session. Enrollment is typically gated by re-authentication, which a stolen session satisfies. Unless the platform requires a signature from a device already enrolled on the account, possession of a session is sufficient to add a new credential that then survives a password reset.

How do attackers persist after an MFA reset? By registering their own authenticator immediately after obtaining access. The reset gets them in; the enrollment keeps them in. The new credential is independent of the original compromise, so revoking the session or changing the password does not remove it. Enrollment, not the reset, is the persistence step.

What should happen before an account accepts a new authenticator? The registration payload should be signed by a credential already enrolled on the account, with the signature covering the specific new credential identifier rather than a generic approval. If no prior credential exists, the request should be routed to a deliberate recovery ceremony that establishes continuity rather than treated as a routine enrollment.

Why did MFA not stop breaches like MGM? Because the attack targeted the enrollment process rather than the authentication mechanism. CISA advisory AA23-320A describes social engineering of IT support to reset or re-enroll factors. No cryptography was broken. A person was persuaded to perform an enrollment, which is the assisted version of the same operation.

Does a notification email count as a control? Not really. It arrives after the credential has been accepted, it may land in a mailbox the attacker controls, and it usually asks a non-technical user to evaluate a device name they cannot verify. Treat it as a record that supports investigation, not as a control that prevents the outcome.

What if I lose all my devices? That is the bootstrap case and it needs a recovery ceremony rather than a co-signature, because by definition no prior key is available. A good ceremony establishes continuity with the human who enrolled originally, using a liveness check against a one-way key, a trusted contact's signature, or a deliberate time delay, without storing a biometric template or requiring a document upload.

Do Apple and Google already solve this? Partially, and within their own ecosystems. Adding a device to an Apple or Google account typically involves an existing trusted device, which is the right shape. What is missing is a portable version that works across a bank, an identity provider, an exchange and a consumer platform, so that the same human's existing devices raise the bar everywhere rather than only inside one vendor's estate.

Sources

1. CISA, Joint Cybersecurity Advisory AA23-320A on Scattered Spider, describing social engineering of help desks to reset and re-enroll authentication factors: cisa.gov
2. FBI Internet Crime Complaint Center, public service announcement of 25 November 2025 on account takeover fraud, reporting more than $262 million in losses across more than 5,100 complaints since January 2025: ic3.gov
3. Microsoft Security Blog, reporting on the Tycoon 2FA adversary-in-the-middle phishing-as-a-service platform and the March 2026 disruption with Europol and partners: microsoft.com/security/blog
4. MGM Resorts International, disclosure filings describing the financial impact of its 2023 cybersecurity incident: SEC EDGAR full text search
5. W3C, Web Authentication Level 3, for the registration ceremony and credential identifiers: w3.org/TR/webauthn-3
6. NIST Special Publication 800-63B, Digital Identity Guidelines, on authenticator binding and re-binding: pages.nist.gov
7. FIDO Alliance specifications, including work on credential exchange and portability: fidoalliance.org/specifications

Passkeys made credentials very hard to steal, so attackers stopped stealing them and started adding their own.