Every password manager asks you to trust one secret. One password, or one account password, that opens the vault where everything else lives. The objection writes itself: if that secret fails, everything fails at once.
That is not wrong. It is also not the whole picture.
What the objection is really about
People mean two different things when they say "single point of failure," and conflating them leads to bad decisions.
One secret unlocks many things. True. That is the design. You are trading many weak, reused passwords scattered across sticky notes and browser saves for one secret you can actually protect.
One breach exposes everything. Sometimes true, depending on what failed. A weak password stored in plaintext on your laptop is catastrophic. A strong password you never write down, combined with phishing resistance and device protections, is a different risk profile entirely.
The question is not whether concentration exists. It always does, somewhere. The question is whether your secrets live in one place you control, or in many places you do not.
One strong secret vs scattered plaintext
Before password managers, most people did not have many independent secrets. They had one email password, one bank password, and the same password again on twelve other sites. Recovery codes lived in a Notes app. The spare house key was under a flower pot and the Wi-Fi password was on a label on the router.
That is not diversification. It is dispersion without protection. Anyone with access to your unlocked phone, your email inbox, or a reused password database from a breached retailer gets a wide path in.
A master password concentrates risk, but it also concentrates defense. You can make that one secret long, unique, and never written down in an obvious place. You can protect it with a hardware key. You can notice when someone tries to use it from an unfamiliar location. You cannot do any of that effectively for forty passwords stored in four different systems.
The honest version of the trade: you are not eliminating a single point of failure. You are choosing which point you are willing to defend properly.
What a provider breach actually means
This is where encryption design matters, and where marketing often blurs two different claims.
Encrypted at rest usually means the provider encrypts data on their disks. That helps if someone steals a hard drive. It does not, by itself, mean the provider cannot read your content. If they hold the keys, or can derive them, a breach of their servers can still expose plaintext.
End-to-end encryption for the live vault means something tighter: your content is encrypted in your browser before upload, and the service stores ciphertext it cannot decrypt. A breach of their servers should yield encrypted blobs, not your documents and logins in readable form.
That distinction is not academic. When LastPass suffered a breach in 2022, attackers obtained encrypted vault data along with metadata. The security of each user's vault then depended on the strength of their master password and the KDF parameters, not on the provider's promise that data was "encrypted."
HeirVault's live vault follows the stronger model: protected by end-to-end encryption, encrypting in your browser before upload. That means HeirVault stores ciphertext and cannot decrypt your live vault. A server breach is bad, but it is not the same as handing an attacker a readable archive.
For beneficiary handoffs, delivery mode decides who holds the handoff key. HeirVault-assisted delivery stores a protected handoff key and transfers it after claim, so that path is not end-to-end to the beneficiary alone. Inviting your beneficiary now, or sharing a unique beneficiary password out of band, keeps that key off our servers. The security page walks through each mode.
When the master password fails anyway
No honest post skips this part.
If someone phishes your password, they get in. Encryption does not protect you from typing the secret into a fake site, or from malware on an unlocked device, or from someone watching over your shoulder. A master password is only as strong as the habits and tooling around it.
If you forget it and lose recovery material, the data is gone. That is the cost of a design where the provider genuinely cannot help you decrypt. There is no responsible back door.
If you are coerced into unlocking, encryption alone does not save you. Someone with a wrench and your unlocked laptop does not need to guess your password.
These are real limits. They are why "we use encryption" is never a complete answer.
Mitigations that actually help
None of these eliminate the single-secret design. They shrink the ways it fails.
Passkeys with PRF support. Where available, a hardware key can unlock your vault without retyping the password on every device, which reduces exposure to keyloggers and shoulder surfing on daily use.
Idle auto-lock and sign-out. A vault that stays open forever on an unattended laptop is not protected by any password. Short idle timeouts matter, especially on shared or travel machines.
Login history and session review. Unfamiliar locations and new devices should be visible. If your account shows a sign-in from a country you have never visited, that is the moment to rotate secrets and review what was accessed.
A duress password on Shield. A second password that unlocks a decoy or triggers a different response under coercion. Niche, but for the people who need it, nothing else substitutes.
Recovery material stored offline. The emergency kit belongs somewhere your everyday devices cannot reach. Not in the same password manager entry as "where I hid the emergency kit."
Why vendor-readable storage is worse
If your objection to one master password is concentration of risk, ask the same question of the alternative: a service that can read everything today.
Many "digital legacy" products are document stores with a timed email. Your files upload in a form the company can read, sit on their servers for years, and release when a timer fires. You have not removed a single point of failure. You have added a permanent one: the vendor's access, their employees, their breach history, their subpoena response, and their business continuity.
A dead man's switch on top of a readable database is scheduling, not encryption. The sensitive moment is not only "when my family needs access." It is every day between now and then, while your tax returns, medical records, and account inventory sit where someone else can open them.
One master password you defend well, on a vault the provider cannot read, is a concentrated risk you chose. Vendor-readable storage is a concentrated risk they chose for you.
The practical takeaway
Use a strong, unique master password or password. Turn on the protections your manager or vault actually offers. Store recovery material offline. Tell the people who would need access that the system exists, so a future email does not look like a scam.
And when a product promises calm, ask the sharper question: who can decrypt my content today, not only after I cannot hand things over?
If the answer is "the company, whenever they want," you have not solved the single point of failure problem. You have outsourced it.
Read how client-side encryption fits different threat models, or see the full security model.
This is general information, not legal advice. Rules differ by country and state. Talk to a qualified professional about your own situation.
