Use cases / Critical credentials
Root accounts, cloud credentials, TOTP secrets — if only one person holds them, you are one incident away from losing access.
The problem
AWS root account, domain registrar, GitHub organization owner — critical credentials often live in one person’s head or password manager. If that person is unavailable, operations stop.
Credentials in a shared Google Doc, Slack channel or team password manager create exposure. Any compromised team member puts everything at risk.
Investors, boards and compliance auditors increasingly ask about credential recovery. Most organizations have no answer beyond “we trust the person who set everything up.”
Single-maintainer projects often have no succession plan for signing keys, deployment credentials or package registry access. The project dies with the maintainer.
The solution
Store critical credentials in an encrypted QR code backup called a block — replace shared Google Doc, Slack channel or team password manager with an offline backup.
Learn more →Split credentials into a set of blocks called a blockset — distribute blocks among board members, executives and trusted colleagues, establishing governance that survives the unthinkable.
Learn more →Enter critical credentials and TOTP secrets, choose a strong passphrase and create a block. Print block on paper or save as a file.
Keep block in company vault, HSM or other secure facility alongside other critical files. Passphrase can live in organization password manager. Storing block and passphrase separately creates two-factor recovery.
To restore, scan block, enter passphrase and view credentials.
Create a 2-of-3 or 3-of-5 blockset containing critical credentials. All blocks share the same passphrase.
Share passphrase with all parties and distribute blocks to company vault, outside counsel and board members.
Recovery requires cooperation — the threshold you chose determines how many blocks must be recovered. Document the scheme in your incident response plan.
For single-maintainer projects, the same approach allows designated contributors to recover signing keys, deployment credentials, repository access and package manager accounts.
When the time comes, board members or designated people gather required number of blocks, enter passphrase and view credentials.
No solution protects against everything — being honest about that is part of earning your trust.
Superbacked enforces strong passphrases but cannot prevent reuse. If passphrase is reused from a breached service, brute-force protection is bypassed. Consider using built-in passphrase generator.
If you lose passphrase, block or blockset becomes permanently unrecoverable. Store passphrase in your password manager or another secure location.
If someone gains access to both block and passphrase — for example, through unlocked password manager — secret is compromised. Lock devices when away.
If malware is running on computer when you create a block or blockset, secret could be captured before encryption. For high-stakes secrets, use Superbacked OS.
Superbacked protects credentials at rest but does not protect against credentials that were already compromised before being stored. Consider rotating credentials before creating backups if breach is suspected.
If enough custodians collude to meet threshold, they can recover secret without authorization. Choose custodians carefully and set thresholds that reflect your trust model.
For high-stakes secrets, use Superbacked OS — a hardened operating system that runs offline and persists nothing to disk.
Explore other use cases: signing keys, digital assets and personal backups.
Copyright (c) Superbacked, Inc.