Use case · tech teams

Infrastructure account 2FA, for tech teams

Cloud root account, registrar, DNS, GitHub organisation: make the 2FA codes of critical accounts available to on-call staff, through the web, the API or an agent, with a log of every access.

Demo interface. The codes are fictional.

A tech team’s most sensitive accounts are also the ones it uses least: the cloud provider’s root account, the registrar, DNS, the owner of the GitHub organisation. Their 2FA is often set up once, on one person’s phone, and forgotten until something goes wrong.

Where it breaks without a shared vault

  • An incident at 3 a.m. needs the root account, and the seed is on the phone of someone who is asleep.
  • The domain is about to expire, and the registrar account is protected by a former partner’s phone.
  • The seed was pasted into a wiki or an environment variable “just to get by”, and nobody knows any more who copied it.

How Share Auth handles it

On-call gets the code, not the seed. On-call members are readers: they get the current code without being able to copy what produces it. Seeds stay encrypted in the vault.

Every access leaves a trace. The access log tells you who obtained the code for the root account, when and from which address: enough to piece together who did what during an incident.

Through the right tool. The website for occasional access, the API for a script, the MCP connector for an AI agent, Slack or Discord for the on-call channel, limited by per-channel restrictions to the accounts that matter.

Tokens that do only that. An API token can be limited to reading codes, for a period of 1 to 90 days, and revoked at any time.

Further reading

Frequently asked questions

Yes, through the API, with a token limited to reading codes. It cannot change anything, expires after the period you choose, and every code obtained appears in the access log, under the name of the person who owns the token.