Your lead DevOps engineer quits on a Friday, no notice, master password included. Or maybe it's simpler: your company's sole founder comes back from a two-week trip and just... can't remember it.
Either way, someone in the room asks the question we hear on almost every technical call about Passwork: "Is there a backdoor for this? A way to just unlock everything?"
The honest answer is no, and that's on purpose. Any "restore everything" button that can instantly decrypt all data in a password manager is a massive single point of failure (SPOF). If you build a backdoor for emergencies, you've also built a front door for attackers. Compromise one account, get everything. That's not a feature, that's the whole system's threat model collapsing into a single credential.
This post is about how we designed access recovery for a zero-knowledge password manager without that button. Instead of one god-mode admin, we split recovery into three isolated layers, each with a narrow job and a hard boundary on what it can't do. We think the pattern generalizes past our own product, so we're sharing the reasoning, not just the feature list.
The zero-knowledge dilemma
Zero-knowledge architecture means the server only ever sees ciphertext. Encryption and decryption happen client-side; the server stores encrypted blobs and has no way to read them without a cryptographic grant, a wrapped key handed to a specific user for a specific vault.
This is great for security and terrible for anyone who assumes recovery works "somehow." If nobody sets up a recovery path before an incident, the math is unambiguous: the data is gone. Not "hard to get," not "requires a support ticket." Gone, because the server never had the key in the first place.
We treat this as the correct trade-off, not a bug to work around. The alternative, a server that can always decrypt on demand, means every password in the vault is one server compromise away from a breach. But it does mean recovery can't be an afterthought. It has to be architecture, decided and configured before anyone needs it, not improvised during an incident at 2 a.m.
So the design question becomes: how do you let an organization recover from losing an account, a device, or an employee, without ever creating a single credential that can decrypt the whole system?
Deconstructing "god mode": our three-tier recovery model
We ended up splitting recovery into three tiers, each solving one narrow problem. None of them, alone or combined, produces a master key to everything. That's the point.
Tier 1: Infrastructure level, the emergency console
The first tier answers a login problem, not a data problem: what if the Owner (the top-level system administrator) can't get into their own account and normal recovery, like an email link, isn't available?
For this we built an emergency console: a set of CLI commands that run on the server itself, not through the web UI. An admin with server access can use it to reset the Owner's password or two-factor authentication when the normal recovery path isn't available.
Two things gate this deliberately:
- It requires server-level access, via SSH or console, rather than a button in the interface.
- The emergency commands are locked behind a state flag that the server admin has to explicitly enable before they can run.
The emergency commands stay disabled by default and become available only after a server administrator explicitly enables the required state flag. Deliberate activation protects the recovery path from accidental use and keeps it beyond the reach of someone with web application access alone.
The key boundary is that the emergency console restores login access while preserving the existing cryptographic access model. Resetting the Owner's password lets them sign in again with exactly the vault permissions they had before the incident.
Vault decryption still depends on cryptographic grants issued in advance. In other words, the emergency console solves the account-access problem, while access to vault data remains governed by the existing grants.
Every use of it gets logged as a distinct event: password reset, 2FA reset, whatever ran. It's traceable, not a quiet backdoor.
Tier 2: Data level, the offline recovery account
Fixing login solves half the problem. The other half: what if the person who actually had the cryptographic grant to a vault is the one who's gone?
Our approach relies on pre-shared cryptographic grants, set up before anything goes wrong rather than improvised during the incident.
In practice: create a standard user account (not an Owner, not a service account), assign it as administrator for the specific vault types your team cares about, then print the master password and put it in a physical safe, a bank deposit box, or another team's offline vault.
The classic break-glass pattern works because the cryptographic access is already in place before the emergency. There's no way to retroactively grant access to a vault after the fact if nobody set up the grant beforehand. If your recovery account only has access to two vault types today, that's exactly what it'll be able to recover next year, no more.
The scope is deliberately narrow. This account isn't root. It's a targeted key to a defined set of vaults that someone consciously decided were worth this level of insurance. Wider coverage means assigning more vault types to it, and thinking harder about how you're storing that offline password.
Tier 3: Automation level, service accounts aren't a backdoor
The third tier is less about recovery and more about closing a mistake we've seen teams make: treating a service account as an emergency login.
A service account exists for automation, onboarding scripts, CI/CD pipelines, identity provider sync, anything that needs programmatic access to the API without a human typing a password. It authenticates with API tokens.
Critically, a service account is designed exclusively for programmatic access through API tokens. Interactive login remains unavailable. That separation is a deliberate design decision: allowing interactive access would turn a narrowly scoped automation credential into a quiet backdoor, potentially sitting in a CI secret store with privileges beyond its intended purpose.
If a token leaks, the blast radius is whatever that integration was explicitly granted, and nothing else. It's still bound by the same access-grant rules as any other account. It doesn't become a master key just because it's automated.
The architecture at a glance
The three recovery tiers solve different problems and deliberately stop at different boundaries.
The emergency console restores access to the Owner account when normal login recovery is unavailable. It requires server-level access and explicit activation, and it cannot decrypt vaults the Owner was never granted access to.
The offline recovery account restores access to selected vault types through cryptographic grants created in advance. Its reach is limited to those pre-assigned vaults: it cannot gain new access retroactively during an incident.
The service account handles programmatic access for integrations and automation. Its API token is limited to explicitly granted resources and cannot be turned into an interactive web login.
This separation is the important part. Recovery does not depend on one privileged credential with access to everything. Each mechanism has its own trigger, scope, and boundary, so compromising one recovery path does not automatically compromise the entire system.
Together, the three tiers provide different paths for account recovery, data recovery, and automation without creating a universal master key.
Security is about distributing trust, not concentrating it
The engineering takeaway is simple, even if implementing it took real work: a password manager with a god-mode admin isn't actually zero-knowledge, whatever the marketing says. If one account, one password, or one command can unlock every secret in the system, you've built a single point of failure with extra steps.
The harder, more useful design goal is recovery without concentration: multiple isolated mechanisms, each auditable, each scoped to a narrow job, none of them capable of becoming a universal key on its own.
We're curious how other teams solve this. How does your org handle the bus factor for critical infrastructure secrets? Physical safe, Shamir's Secret Sharing, something homegrown with HashiCorp Vault, or are you still crossing your fingers? Drop it in the comments, we'd like to compare notes.
Top comments (0)