Shared MFA Codes

What this is for

Some accounts are genuinely shared: a bank login the accounts-payable team uses, a vendor portal two people administer. Their second factor is sent to one phone or one mailbox, so in practice somebody screenshots the code into a chat. That works, and it is also the worst possible place for it — the code lands somewhere with no expiry, no record of who used it, and a far wider audience than intended.

This gives that arrangement somewhere deliberate to live. Codes arrive at an address your organisation owns, only named people can read them, each code disappears within minutes, and every reveal is recorded against the name of the person who revealed it.

Be clear about the trade you are making

Sharing an authentication factor is a deliberate weakening, and it is worth saying so plainly rather than burying it. NIST SP 800-63B restricts one-time codes sent over SMS, and PCI DSS 8.x requires that authentication factors not be shared. This feature does not make those concerns go away; it makes the arrangement visible, bounded and auditable instead of invisible.

Because of that, an address can be linked to an exception — the record where your organisation wrote down the decision. Linking one is optional. Once linked it is enforced: if that exception is denied, withdrawn or expires, the address stops serving codes and everyone who could read it is told why. An authorisation that has lapsed stops authorising.

Reading a code

Open My TATER → MFA Codes. The table shows the codes that have arrived at every address you are a member of, newest first, and refreshes on its own — you normally open this page because you have just asked a website to send you a code, so there is nothing to click.

Each row shows a masked code. Reveal shows the real one and copies it. A revealed code re-masks itself after a minute and a half, and everything revealed is forgotten when you leave the page: this screen is most useful left open on a second monitor, which is exactly where a live second factor should not sit indefinitely.

Codes expire a few minutes after they arrive and then vanish. That is deliberate — a lasting archive of one-time codes would be a standing list of credentials with almost no practical use, since each is dead to the provider within minutes anyway.

Rows marked “uncertain”

TATER reads the code out of the message. Most of the time that is unambiguous. Occasionally a message is written so that the code cannot be identified with confidence, and the row is marked uncertain or probable.

Treat those as a suggestion rather than an answer. The original message is not kept — only the code, who sent it, and the subject line — so there is nothing on screen to check the number against. If a marked code is refused, that is far more likely to be a misread than somebody else using your account.

Why it may ask for your security key

Your organisation can require a security-key check before a code is revealed. The reason is worth understanding: if the password lives in the Vault and the second factor lives here, and both open with the same sign-in, then two factors have quietly become one. Being asked to touch a key proves a person is present, which a stolen browser session cannot do.

Register a key from the Your security keys panel on the same page. One check covers a couple of minutes of reveals. Adding a second key, or removing one, needs a check with a key you already have — otherwise anyone holding your session could simply enrol their own.

When the table is empty

An empty table always says which kind of empty it is, because the three need opposite responses:

• No codes right now — ask the website to send one; it will appear within a few seconds.
• You are not a member of any shared address — codes only appear for addresses an administrator has added you to. Ask yours.
• On hold — you are a member, but the exception permitting the sharing has lapsed. The codes are being withheld, not lost. The notice names the record that needs renewing.

A failure to load is never shown as an empty table. If the list could not be fetched it says so, because “no codes” would send you off to request another one for no reason.

Setting one up

Administrators use Manage → Shared MFA Addresses. An address is the part before the @ of the address codes are sent to, or a phone number if the codes arrive by text. For each one you name the people who may read its codes — individually, or by pointing at an Entra group so access follows the group you already manage.

Two things about this screen are deliberate and often surprise people:

• Being an administrator grants no access on its own. Only the people named for an address can read its codes. An administrator who needs them adds themselves, and that is recorded like any other change — so nobody reads a code without an entitlement that predates the reading.
• An address nobody has configured is readable by nobody. Addresses come into existence the moment somebody types one into a sign-up form, so the screen lists any that are receiving codes without being set up. Until you configure one, its codes arrive and expire unread.

Text messages, and why they often will not work

Codes can also arrive by text at a number you provision through a messaging provider. Expect this to work for some services and not others, and not because of anything TATER does: banks, brokerages, Google, Apple, PayPal and most payroll and tax portals refuse to send one-time codes to a relay number at all, and the number ranges these services come from are widely blocked. There is no way to look this up — the only way to find out is to try.

That is what the provider results list on the same screen is for. Record what happened, whether it worked or not, and what the refusal said. “We tried and were refused” and “nobody has tried” call for completely different next steps, and without a record every person rediscovers the same rejections one service at a time.

Email is the reliable channel. Treat text messages as a bonus where a provider happens to allow it.

Reaching it from a Vault item

A login in the Vault can name the shared address its codes go to, and then offers Open codes to jump straight to that address’s list. The address is stored inside the item’s encrypted contents like any other field, so it is a convenience, not a second copy of anything sensitive. The codes themselves never live in the Vault.