The challenge
Putting a document somewhere safe is a solved problem. Deciding who gets it, and exactly when, is the hard part. Give one person sole control and the whole arrangement depends on them. Make release simple and the vault loses its point. Make it too strict and a family may never receive what was left for them.
So the brief combined security and workflow. Vault contents had to stay private until a defined trigger, release had to require verification from more than one trustee, and every action had to be logged. 911 Vault also needed release on a schedule as well as on events, and recovery options for owners who lose access through one channel.
- Contents kept private until the trigger is proven
- Release only after validation by more than one trustee
- Time-based release alongside event-based release
- An audit trail of activity on each vault
- Recovery for owners that does not rely on any one channel
Our approach
We acted as 911 Vault’s lead engineering partner, building the product end to end with a Django backend and a React front end, in daily contact with the client’s founder. Three disciplines carried most of the weight: security, cryptography and database design.
Encryption comes first. 911 Vault describes its storage as zero-knowledge, and the design goal is that pre-event access stays blind: neither the operator nor any one trustee should be able to open a vault ahead of time.
Release depends on two vault types. Event Vaults, which 911 Vault describes as patent-pending, remain closed until the trigger has been proven by verified trustees. Time-release vaults open on a schedule. Multi-party validation stops a single trustee acting alone, and delayed-release buffers put a pause between verification and release, so that an error, or a bad-faith trigger, can be stopped before anything opens.
The supporting controls each close off a single point of failure. Granular audit trails cover every vault, dark-web monitoring looks for exposure of an owner’s data, and omnichannel recovery means that losing one route in does not shut an owner out.
We gave the data model as much care as the cryptography. Trustees, triggers, vaults, verifications and audit records are tightly related, and release logic can only be as dependable as those relationships. The React front end turns all of this into a guided path: registration, choosing trustees, setting up a vault and, eventually, controlled release.
For anyone building a product where controlled access is the whole point, our advice is to list every way a release could go wrong before writing code: one person acting alone, a mistaken trigger, a lost login. Each control in 911 Vault answers one of those cases.
Architecture & stack
- Front end
- React
- Backend
- Python, Django
- Security
- Encrypted storage (described by 911 Vault as zero-knowledge), Multi-party validation, Granular audit trails, Dark-web monitoring
- Release controls
- Event Vaults (described by 911 Vault as patent-pending), Time-release vaults, Delayed-release buffers, Omnichannel recovery
The outcome
911 Vault lets people store their most sensitive documents and set, ahead of time, the conditions for releasing them. Vault contents stay private until a trigger is proven, release depends on more than one verified trustee, and each step leaves a record.
The design closes off failure in both directions. A single person cannot open a vault early, and a single lost credential or channel cannot stop the right people receiving what was left for them.
- Pre-event access kept blind by encrypted storage
- More than one verified trustee needed for any release
- Event and time-release vaults, with buffers before release
- Audit trails, dark-web monitoring and several recovery routes
Last updated
