The questions worth asking

EternaKeys is a private, locked place to keep the information the people you love would need if they ever had to step in for you — account details, important documents, instructions, and final wishes.

Most families do not lose this information because it was secret. They lose it because it was scattered: a password in a notebook, a policy number in an old email, a wish nobody wrote down. EternaKeys puts it in one place, keeps it encrypted, and lets you decide who should be able to request it later.

They overlap, but they answer different questions. A password manager answers "how do I log in today?" EternaKeys answers "how would someone I trust find what they need if I could not tell them?"

That is why EternaKeys holds documents, instructions, and wishes alongside credentials, and why it has a verified process for someone you named to request access later. A password manager has no such concept.

EternaKeys is organized into four categories, so almost anything you would want to leave behind has a natural place to go:

Directives — your will, healthcare wishes, and final instructions. Financial Assets — bank accounts, insurance policies, investments, and cryptocurrency. Digital Life — email, subscriptions, and online accounts. Physical Assets — property deeds, titles, and valuables.

You do not have to fill in all four. Start with whatever would be hardest for someone to piece together without you.

It means we hold the locked box, and you hold the only key.

Your information is locked on your own device — your phone or computer — before any of it is sent to us. What arrives on our servers is scrambled. We can store it and hand it back to you, but we cannot read it.

No — and not because of a policy we could quietly change. It is a consequence of how the system is built. The key that unlocks your vault content is never sent to us, so there is nothing on our side to read it with.

This is worth being precise about: it applies to your vault contents. It does not apply to your account email or your billing status, which we do hold in readable form because the service cannot function otherwise.

Two different kinds of things, and it is worth knowing the difference.

Your vault contents are stored encrypted — unreadable to us. Your account information is stored normally: your email address, whether your subscription is active, and security records like sign-in times. We need those to run the service, bill you, and show you your own security history.

The system is designed on the assumption that this could happen. That assumption is the reason your information is locked before it reaches us rather than after.

An attacker who took a full copy of our database would get scrambled vault contents they cannot unscramble, plus the account information described above — emails, subscription status, and security logs. That last part is a real consequence and we would treat a breach seriously, but your vault contents would not be readable.

EternaKeys responds to valid legal process with the information it actually has. What it has is the account-level information described above — not your decrypted vault contents.

We cannot hand over readable vault contents in response to a court order for the same reason we cannot hand them to ourselves: we do not hold the key. We are describing what we are technically able to produce, not offering you a legal guarantee about any particular jurisdiction or proceeding.

A standard called AES-256-GCM. It is the same class of encryption used to protect government and banking data, and there is no known practical way to break it.

The useful part is not the name. It is where it happens: on your device, before anything is sent.

It is the step that turns your passphrase into an encryption key, deliberately slowly.

If turning a passphrase into a key were fast, someone with a stolen copy of the database could try billions of guesses. Argon2id makes each single guess expensive in both time and memory, which turns "billions of guesses" into something that is not practical. The small delay you notice when unlocking your vault is that protection doing its job.

Your device does the searching, not our server.

When you save an item, your device creates scrambled markers for the words in it. When you search, your device scrambles your search word the same way and asks whether any markers match. The server compares scrambled values to scrambled values, and never learns the word you searched for or the words in your items.

It is encrypted on your device first, then the scrambled version is uploaded. We store a file we cannot open. The filename is treated as private too — it is encrypted along with the contents.

It is a way of signing in using your device itself — Face ID, a fingerprint, or your device PIN — instead of typing a password.

Your face or fingerprint never leaves your device and is never sent to us. Your device simply proves to us that it is really you, and we let you in. In practice: you tap, it recognizes you, you are in.

Two reasons, and the second one is the big one.

First, there is no password sitting in a database for an attacker to steal. Second, a passkey is tied to our actual web address. If a convincing fake EternaKeys site tries to get you to sign in, your device will simply refuse — it knows it is the wrong site. A human can be fooled by a lookalike page; a passkey cannot.

No. Neither one is ever sent to us, so neither one is ever stored by us.

Your passphrase is typed on your device and used there. What we store is a random salt and a note of which key-derivation settings were used — neither of which lets anyone work backwards to your passphrase.

No. This is the most important thing to understand about EternaKeys, and it is the honest cost of the guarantee that we cannot read your vault.

A company that can restore your data when you forget your passphrase is a company that could always read your data. You cannot have both. We chose the version where your information is genuinely yours — which means if the passphrase is lost, the encrypted contents are lost with it.

So: write your passphrase down and keep it somewhere physically safe. A sealed envelope in a home safe or a safe deposit box is not old-fashioned here; it is the correct approach.

Losing one device is recoverable if you registered a passkey on another one. That is why we ask you to add a second device early — a tablet, a second computer, or a hardware security key.

Losing every device with a registered passkey is a different situation: account sign-in cannot be restored, because sign-in depends on a device proving it is you and no such device remains.

These are two separate things worth keeping straight: your passkeys control getting into your account, and your passphrase controls unlocking your vault contents. You need both, and we can replace neither.

Someone you name in advance as a person who should be able to request access to your vault information later — often a spouse, an adult child, or a close friend.

Naming someone does not give them access. It means that if they ever go through the verified process described below, the system knows they are someone you actually chose.

No. Naming someone gives them nothing on its own. There is no button they can press to look inside.

The only path to access runs through a verified request process, and that process notifies you and gives you a window to stop it. If someone tries this while you are alive and well, you find out and you shut it down.

It is the verified process a designated recipient has to complete before any information is released — and it is deliberately slow and noisy rather than automatic.

It exists because the alternatives are worse. A timer that releases your vault if you do not log in would empty your vault while you were on a long holiday or in hospital. A button we could press for a grieving family would mean we could press it for anyone. So instead: the person requesting must prove who they are, you are told immediately, you get a window to refuse, and an administrator must make an explicit decision before anything is released.

You are notified and receive reminders during the veto window. People stored in your encrypted People to Contact section are not automatically notified and cannot veto a request.

If you reject it, it stops. That is the whole point of the veto window — it is your stop switch, and it does not require you to explain yourself.

This is the right question to ask, and the answer is that we never hold the key at any point.

When a request is fully authorized, the released information is re-locked with a brand new key that is scrambled specifically so that only the recipient's own device can open it. We pass along a package we cannot open, exactly as we do with your vault.

No. EternaKeys is software. It does not make findings about anyone's death, and it has no legal authority to do so.

What it checks today is that a request came from the verified account bound to the person you named, that you were notified and did not refuse, and that an administrator made an explicit decision. The evidence reference is not a verified document and EternaKeys does not make a legal determination.

No, none of those. EternaKeys is not a law firm and holds no legal role in your affairs. It does not act on your behalf, does not manage anything for you, and does not provide legal, tax, or estate-planning advice.

It is a secure place to store information and a controlled way to pass it on. Storing a will in EternaKeys does not make that will valid, and naming a designated recipient does not appoint anyone to any legal role. For anything legal, talk to an actual attorney in your jurisdiction.

You can export your vault at any time while your account is active, and we would encourage you to keep an exported copy regardless — not because we expect to disappear, but because a vault you can only reach through one company is a single point of failure.

We are a young company and we are not going to dress up a promise about the distant future as a guarantee. What we can tell you is what exists today: an export function, and encryption that is standard rather than proprietary, so an exported copy is not dependent on us continuing to exist.

Ideally, less than you might expect — and that is the point.

The question we tried to design around was not "how do we get people to trust us with their most sensitive information?" It was "how do we make it so they do not have to?" You should not have to take our word that we will not read your vault. You should be able to rely on the fact that we cannot.

Trust the architecture, not the marketing. Everything on this page describes what the system does; the Zero-Knowledge Disclosure and Security Practices documents go further into the specifics, including the limitations.