Two factor methods ranked for fleet work

A customer of mine runs around sixty accounts and had done the security homework properly. Every guide he read put hardware keys at the top, so he bought one and registered it across the lot.

Then the key went through a wash cycle in a jacket pocket.

Sixty accounts, no second factor, and the only route back into any of them ran through phone numbers he had deliberately avoided attaching. He spent the next fortnight doing the exact thing his setup existed to prevent.

He had not made a mistake against the ranking he was following. The ranking was answering somebody else’s question.

The order I would actually use

Strongest first, for a fleet: authenticator seeds, with the recovery codes filed next to them. Then recovery codes on their own. Then email. Then hardware keys. Then SMS, last, and used anyway because a large share of platforms will not let you refuse it.

That is close to the reverse of what a security page tells you, and the difference is in the criteria rather than in how the methods work.

The three criteria a fleet is actually graded on

A published ranking measures one property: how hard is this to phish. For one account holding your money, that is the right property and hardware keys win it outright.

Run many accounts and three other questions decide whether you keep them.

Does the method link accounts to each other? Anything you can only afford one of gets shared, and anything shared is a join.

Do you still have access when the thing it was enrolled on is gone? A traded in handset, a wiped device, a line that lapsed while you were not looking.

Does it survive being handed to somebody else for the week you are away?

Phishing resistance is the fourth question. It stays real, and it stops being the one that sets the order.

SMS: accepted everywhere, worst on linkage

SMS earns its place at the bottom for reasons that have nothing to do with SIM swapping.

A phone number reused across two accounts is one of the strongest joins a platform has. It sits in their own records, where no proxy or browser profile reaches. It was verified by a carrier rather than claimed by you, which is the property that makes it useful to them.

The second problem gets less attention. You rent the number. A prepaid line goes dormant, gets recycled, and reappears in somebody else’s hand, and any account anchored to it is now anchored to a stranger who can receive its codes. That is the normal end state of a line nobody topped up.

I have written elsewhere about where numbers come from and what each source costs. Short version: a line with no prior life costs real money, and the cheap ones arrive pre judged.

The one thing SMS has is universal acceptance. No platform refuses a phone number, and many will not let you remove it once it is on the account. So treat this as an instruction for when you are forced into it. One number per account, no exceptions, and no borrowing a good line for an evening.

The seed is the second factor, the app is furniture

An authenticator code comes from a seed. A string handed to you once, usually as a square you scan, after which the app and the platform compute the same six digits from it separately.

Nothing in that seed identifies you and nothing in it reaches another account. Twenty accounts in one authenticator app share an app and nothing else. No value common to any two of them ever arrives at the platform. That wins the first criterion outright, and it is why this sits at the top of my list rather than second.

The second criterion is where people quietly lose. Portability lives in the seed. If you scanned the square and never recorded the string, the app on that particular handset is the only thing in the world that can produce those codes.

The failure is undramatic, which is why it keeps happening. Somebody enrols thirty accounts on a phone. The phone gets replaced eighteen months later. The export never happens because every account was working fine that week and nothing was on fire. Then one account asks for a code, and the device that could produce it was traded in with a screen protector still on it.

Store the seeds themselves, in whatever already holds your passwords, and the app becomes a convenience you can rebuild in ten minutes on any handset.

Hardware keys: the best product, the wrong shape

Hardware keys are the strongest security object on this list. For one identity they are excellent, the secret never leaves the device, and the attack they were built to stop is genuinely stopped.

For many identities you reach a fork with two bad prongs.

Buy a key per account and it is real money plus a drawer of small identical objects to label and never lose. Register one key across a dozen accounts and you have twelve accounts pointing at one device.

That second option is the one people take, and it is a tie. I cannot tell you how heavily any platform weights a shared authenticator device, and nobody outside those companies can. What I can say is that it is the shape of thing detection systems are built to find, and you introduced it while trying to be careful.

There is a duller problem underneath both. The key has to be physically present. If the account lives on a rented Android handset in a rack in Singapore and the key is on a desk in another country, those two facts never meet.

Passkeys inherit most of this. A passkey lives inside a device, or inside a platform account that syncs it between devices, which makes the holder of your second factor an identity in its own right, one that can be shared across accounts and read as shared.

Email as a second factor is a mailbox in a costume

Email codes are exactly as isolated as the mailbox behind them.

Point ten accounts at one recovery mailbox and you have drawn a line between ten accounts and hung a lock on it. The mailbox layer decides everything here, including the catch all domain problem, where every address is different and the suffix is one shared value under the whole fleet. I have covered mailbox strategy in its own piece and none of it changes when the mailbox is wearing a security label.

Third place, and only because a well built mailbox layer is something you need anyway.

The codes almost nobody files

When you enable two factor, the platform prints a list of recovery codes. Eight of them, or ten. One screen, once, never shown again.

They get screenshotted into a photo library, or pasted into a note, or read and closed because the setup was already three steps long and there was work waiting.

For fleet work those codes are the real second factor and everything above them is a convenience layer. The list is what opens an account when the handset is gone, the line lapsed, and the key is somewhere else.

They also have a property nothing else on this page has. A recovery code is a string. It verifies against nothing external and points at nothing, so there is no value there for anybody to join to another account. Zero linkage, by construction.

The item with the best properties for this job appears at the least convenient moment in the setup flow, and gets skipped for that reason alone.

Whoever can reach the seed owns the account

This is where a security decision turns into an operations one.

Wherever the seed lives, that is who can get into the account. Not whose name is on it. Whoever can reach the value.

Keep every seed in an app on your personal phone and you are a single point of failure with a battery. Nobody covers for you, and an account that locks while you are unreachable stays locked. Keep every seed in a shared vault a helper can open and they can reach anything in it, including accounts they were never meant to touch, and they keep that reach after they leave unless you run the rotation.

The rule from the piece on sharing account access holds here without amendment. What you hand over is the identity, and the second factor is part of the identity. The version that goes wrong is a helper adding their own phone as the recovery contact across eleven accounts so they can always get back in, which builds the join you were paying to avoid at the layer nobody audits.

The same logic runs backwards through recovery. Anything you attach during a challenge becomes a standing field on the account, which is why the second factor improvised under pressure is the one you end up keeping.

Where this ranking is wrong

It is wrong for your payout account.

Whatever holds the money, the card, the ad billing, the destination earnings land in, is a single high value identity targeted by people who write phishing pages for a living. For that one the published ranking is correct and mine is wrong. Buy the key, register a backup, and stop reading operator advice about it.

And I cannot give you the weighting. I do not know how much any platform cares that one key answered for twelve accounts, or whether it looks at all, and anybody quoting you a figure has made it up.

What I can tell you is which of these choices are reversible. A seed you exported moves anywhere tomorrow. A number already welded to three accounts cannot be unwelded, and a shared recovery contact sitting under a batch is a decision from last year that today cannot undo. When two options look close, that asymmetry is the whole of my reasoning.

Guides and the stack we run and test are at Multi Account Ops.

Get new guides and videos first — join the Telegram channel.