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, whil