Architecture
Bundling features increases UX power. It does not have to increase blast radius. Henedo's will builder, vault encryption, dead man's switch, canary detector, transparency verifier, contact PII layer, and Eternal Vault signer are independent modules built on a single audited primitive layer. A bug in any one of them is contained to that one.
A common critique of all-in-one platforms is that more features mean more failure points. On a poorly architected product, that is true. On a modular product, it is the opposite: every cross-product handoff between separate vendors (a password manager → a separate will tool → a separate vault → a separate inheritance app) is a plaintext-touching boundary, and every boundary is a place data can leak.
Henedo's design rule is the opposite: bundled UX, modular internals.The user sees one product and one passphrase. Underneath, each feature is a self-contained subsystem that holds only the keys it needs and fails in place if it ever fails at all.
Each subsystem is a separable module with its own threat model, its own data flow, and its own audit boundary.
Content surfaces (the Journal, the 1,000-prompt Life Story, voice memos, video messages) are not separate subsystems. They are users of the Vault crypto subsystem: every byte they produce is encrypted under the same per-record FEK wrapped under the same MK as the document vault. Adding a content surface adds zero new cryptographic boundaries and zero new attack surface.
What it does: State-specific legal templates, attorney-reviewed.
What it touches: Plaintext form input → encrypted in place via the vault module before persistence.
If it fails: A bug here cannot read your master key. The will is encrypted under the same MK as everything else; the builder never sees the MK.
What it does: Per-file FEKs wrapped under a single MK. AES-256-GCM at rest.
What it touches: File bytes during encrypt/decrypt only. Web Worker isolated.
If it fails: A bug here is the only one that could affect data confidentiality. It is also the most-audited code path in the product.
What it does: Server-side state machine: ACTIVE → WARNED → TRIGGERED → DELETED.
What it touches: Timestamps and email queues. Never touches keys, never touches ciphertext.
If it fails: A bug here can cause a wrong-time email or a mistaken state transition. It cannot decrypt anything.
What it does: Tripwire blobs planted in every vault. SECURITY DEFINER Postgres function.
What it touches: Vault row IDs and access timestamps.
If it fails: Failing open here means a real attacker is not auto-locked-out, the DMS still gates everything else and sessions can still be revoked manually.
What it does: Client-side Ed25519 signature check on every JS asset.
What it touches: Asset hashes and a public key.
If it fails: Verification failure produces a visible warning banner. Other subsystems continue to operate, but the user is told the build cannot be trusted.
What it does: Server-side pgcrypto AES-256 + HMAC-SHA-256 blind index for emails.
What it touches: Trusted-contact name, email, phone, address. Never touches MK or vault FEKs.
If it fails: A bug here can leak ciphertext PII columns. The application-layer key is in a separate Postgres schema with no PUBLIC privileges, so a DB-only breach still yields ciphertext.
What it does: Ed25519 + ML-DSA-65 hybrid signing on sealed vaults.
What it touches: A serialised vault manifest at sealing time only. Keys are zeroed after signing.
If it fails: A bug here can produce an invalid signature, which the inheritor would detect. It cannot retroactively decrypt prior vaults.
For each subsystem, what is exposed if that one subsystem has a critical bug? In a well-isolated architecture, the answer in most rows is nothing.
| Feature | Confidentiality | Availability | Integrity |
|---|---|---|---|
| Will builder bug | No leak (encrypted in place) | Will form may fail to save | Validation by attorney-reviewed templates |
| Vault crypto bug | Possible: most-audited path | Files become unreadable | AES-GCM auth tag detects tampering |
| DMS timer bug | No leak (no key access) | Possibly miscounted timer | Visible to user: login resets state |
| Canary detector bug | No leak | Lockdown may not trigger | Manual session revocation still works |
| Transparency verifier bug | No leak | Banner may misfire | User notified of any mismatch |
| Contact PII layer bug | Possible: ciphertext only (DB-only) | PII reads may fail | HMAC blind index unaffected |
| Eternal Vault signer bug | No leak (signing only) | New seals may fail | Inheritor detects invalid signature |
The only thing the seven subsystems share is the cryptographic primitive layer: AES-256-GCM, Argon2id, HKDF-SHA-256, SHA3-512, Ed25519, ML-DSA-65. These are NIST-standardised, widely audited algorithms with reference implementations in the @noble/* family and the Web Crypto API. Sharing them is a feature, one well-reviewed implementation per primitive, one place to fix any vulnerability, one thing an external auditor needs to read.
Above the primitive layer, every subsystem is independent.
If you assemble your own legacy stack from a separate password manager, a separate will tool, a separate cloud vault, and a separate inheritance app, you have created four plaintext-touching boundaries: one each at every export and import. Each handoff is a place ciphertext is decrypted, recombined, and re-encrypted under a different key, and each step is a place a bug can leak data.
Henedo bundles the UX so plaintext only ever lives in one trust boundary, your browser. Cross-feature handoffs happen inside the same encrypted memory space, never across products and never over the wire. That is what fault-isolated all-in-one looks like, and it is fewer attack surfaces than the unbundled alternative, not more.
Subsystem isolation handles bugs. Active preservation handles time. A vault built to outlive its owner has to outlive its hardware too. Hard drives degrade in 3–5 years. SSDs lose charge without power. Whole storage formats become obsolete in a generation. Treating long-term storage as a static cloud bucket is the single biggest reason consumer "lifetime" services do not last.
Henedo's primary storage layer is geo-redundant: encrypted blobs are replicated across multiple regions on a current-generation cloud object store, with continuous SHA-3 fixity checks that detect silent corruption and re-replicate automatically. On top of that runs an active-preservation cycle: roughly every 10 years the underlying drives, formats, and infrastructure are migrated to current storage technology, the discipline used by the Library of Congress, national archives, and other archival institutions, formalised by ISO 14721 (OAIS) and the PREMIS preservation metadata standard. The StorageAdapter interface in BACKEND_ARCHITECTURE.md is what makes this migration low-risk: implementations swap, business logic does not change.
M-DISC is the extra redundancy layer, not the primary medium. We burn an annual encrypted snapshot to Verbatim M-DISC BDXL (ISO/IEC 10995:2011/ECMA-379, rated up to 1,000 years per U.S. DoD projection), verify with SHA-3, and store three copies in three climate-controlled vaults across three geographic locations. It is a belt-and-suspenders archival practice that survives even total loss of the primary store, never the only copy of your data.
Every subsystem in this page is documented in our open architecture spec (SECURITY.md) and the source is loaded into your browser under a signed manifest, see the transparency log. Independent auditors can read the architecture, fetch the manifest, and verify that the JavaScript running on this page is the JavaScript we describe.
Read the architecture spec. Verify the build. Then start your vault.