Architecture
One product. Seven subsystems.Each one fails alone.
Bundling features increases UX power. It does not have to increase blast radius. Henedo's will builder, vault encryption, Trusted Delivery, 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.
The argument we are answering
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.
The seven subsystems
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.
Will builder
What it does: A shared will-draft template with location labels and clause defaults; local legal validity is not verified.
What it touches: Plaintext form input → encrypted in place via the vault module before persistence.
If it fails: The builder uses worker operations instead of raw master-key bytes. Its form data is plaintext in the page; a script compromise can affect that data and misuse cryptographic operations.
Vault crypto
What it does: Per-file FEKs wrapped under a single MK. AES-256-GCM at rest.
What it touches: File bytes and file keys during encryption/decryption. Master-key operations run in a worker.
If it fails: A bug can affect encryption or key handling. Confidentiality also depends on the page code that handles inputs, plaintext, and cryptographic requests.
Trusted Delivery
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.
Canary detector
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, Trusted Delivery still gates everything else and sessions can still be revoked manually.
Transparency verifier
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.
Contact PII layer
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.
Eternal Vault signer
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.
Failure-mode matrix
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 | Template-driven field validation |
| Vault crypto bug | Possible: most-audited path | Files become unreadable | AES-GCM auth tag detects tampering |
| Trusted Delivery 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 | Optional audit may fail | Audit result may be inaccurate |
| 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 shared surface
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.
Why bundling beats separating
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 keeps private vault encryption and many cross-feature handoffs in your browser. Account and delivery data have separate server-side processing, and optional AI features process the readable inputs you consent to send. The worker isolates raw master-key memory; rendered plaintext still lives in the page. Encrypted browser state can resume your session after a refresh, using a locally stored wrapping key, until your chosen idle timeout. This convenience depends on browser storage and does not protect against malicious page code.
Encrypted cloud storage and long-term preservation
The current Eternal Vault offer is $699 once for 100 GiB, with a 100-year preservation term. Confirmed payment adds a purchase to your account. From the Eternal Vault dashboard, you select content, upload its encrypted form, and seal the archive for your inheritors.
Encrypted objects are stored in Cloudflare R2. Sealing binds the archive to an integrity manifest and per-inheritor access keys. The current cloud offer uses email delivery for inheritors. Its operation depends on the cloud storage, access, and delivery services described here.
Long-term preservation requires continuing operations and future migrations as technology changes. Independent geographic replicas and a fixed hardware-refresh programme are future work; Henedo does not currently operate the previously described ten-year refresh cycle. Physical M-DISC delivery remains available only under legacy purchase contracts that include it. The current cloud offer includes no physical disc or shipping.
How to verify
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 compare served JavaScript assets with the signed build.
FAQ
Combining features can reduce manual data handoffs, but modular code alone does not guarantee security. Henedo encrypts private vault content in the browser and keeps raw master keys in a worker. Page modules share access to plaintext and cryptographic operations, and encrypted session resume retains a browser-local recovery capability. Server-side delivery and optional readable-data features have separate access boundaries.
A trust boundary separates components with different access to your data. The web app keeps raw master-key bytes in a dedicated worker and gives page code operation handles. Encrypted browser state, with a locally usable wrapping key, can resume an unlocked session after refresh until its idle timeout. Private vault file contents are encrypted before upload. Account and delivery details are processed by the service, and optional AI features send selected readable inputs after your consent. Worker isolation reduces direct key exposure; malicious page code can still use browser keys, request operations, or capture plaintext. Server-side API access is also controlled by your authenticated session and row-level security policies.
The impact depends on which component fails and its access. The will builder handles plaintext and uses worker operations to encrypt it. Worker isolation prevents ordinary page code from directly reading private worker variables, but page modules share a security context: injected code can capture plaintext or misuse cryptographic capabilities. Server-side access controls and delivery policies must be assessed separately.
AES-256-GCM, Argon2id, HKDF-SHA-256, SHA3-512 are the only shared surface, and they are widely audited NIST-standard primitives. Sharing them is a feature: one well-reviewed implementation per primitive, one place to fix a vulnerability, one thing for an external auditor to read. Each subsystem above the primitive layer is independent.
The architecture spec in SECURITY.md and BACKEND_ARCHITECTURE.md documents every subsystem, its inputs, outputs, and failure modes. The source is open for review and the build is signed with binary transparency, so the JavaScript running in your browser matches the architecture we describe.
The current Eternal Vault offer is $699 once for 100 GiB and a 100-year preservation term. After payment is confirmed, you upload and seal an encrypted archive from your dashboard. Encrypted objects are stored in Cloudflare R2, and inheritors receive their access material by email. Physical discs apply only to legacy purchases whose contracts include them. Independent geographic replicas and a fixed hardware-refresh programme are future preservation work, not currently operated Henedo services.
Get started
Bundled UX. Modular under the hood. Open for review.
Read the architecture spec. Verify the build. Then start your vault.