One product. Seven subsystems.Each one fails alone.

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.

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.

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.