The quiet ironwork
behind the app.

How the encryption works

On your device. When you record a voice note or write a memory, it is encrypted on your device using keys generated and stored on that device. The ciphertext is what travels to our servers.

In transit. All communication between the app and our servers runs over TLS 1.3 with modern cipher suites. Certificate pinning is used where appropriate.

At rest. We store the ciphertext your device produces. We also encrypt our storage at the infrastructure layer as a secondary defense, but the meaningful protection is the one your device already did before sending us anything.

To your circles. When you assign a memory to a circle, we re-route the encrypted content to the devices of people in that circle, using keys specific to that circle. Someone outside the circle — including our servers and our team — cannot decrypt it.

Capsules. A sealed capsule’s contents are encrypted against the capsule’s eventual recipient. Until the delivery condition is met, the capsule stays sealed; nothing about its contents is revealed to our systems.

Key management

Keys are generated on your device when you sign up and are rotated periodically. We sync encrypted backups of your keys between your own devices, protected by a passkey (or, if you choose, an additional recovery passphrase that only you know).

What this means if you lose a device: as long as you have at least one other signed-in device, or a recovery passphrase, you can restore access to your archive. If you lose every signed-in device and you’ve chosen not to set a recovery passphrase, we cannot recover your archive for you — because we can’t read it. We make this trade-off obvious during setup.

For trusted contacts and capsule delivery, we use a limited key-wrapping scheme that allows us to route the right ciphertext to the right recipient at the right time, without ever gaining the ability to read the plaintext ourselves. The specifics of this mechanism will be published here before launch and reviewed by an independent cryptographer.

Authentication

evervoice uses passkeys (WebAuthn / FIDO2) as the default sign-in method. Passkeys are resistant to phishing and don’t require you to manage a password.

Where passkeys aren’t available, we fall back to email-plus-code sign-in. Password-based sign-in is not supported, by design.

Two-factor options include a second passkey on a different device, and a recovery passphrase stored only on your devices.

Sessions are pinned to the device and can be revoked from Settings. Unusual sign-in activity triggers an email notice and can be locked from inside the app.

Access inside our team

The people who work on evervoice do not have access to the contents of your archive. We’ve built the system so that access is not possible by design, not just restricted by policy.

For the small surface where operational access is possible — account metadata, billing records, error logs — we apply the principle of least privilege, require strong authentication, and log access. Production changes go through peer review.

Subprocessors

evervoice runs on infrastructure from a small set of vetted providers. Each one sees only what it needs to do its job, and sees encrypted content rather than plaintext.

We maintain a current list of subprocessors, including what each one does, where they operate, and when they were added. You can request it at privacy@evervoice.app. We will publish it on this page before launch.

How we handle incidents

If we discover a security incident that affects you, we will:

• Contain and investigate the issue promptly.
• Notify you inside the app and by email with what we know, what we don’t yet know, and what we’re doing about it — within the timeframes required by applicable law, and in any case within 72 hours of confirming a material incident.
• Publish a public post-mortem once the incident is resolved, describing the cause and the changes we’ve made.

Responsible disclosure

If you’ve found a security issue, we’d like to hear about it. Please email security@evervoice.app with a description and, if possible, steps to reproduce.

We commit to:

• Acknowledging your report within two business days.
• Working with you in good faith while we investigate and fix the issue.
• Not pursuing legal action against researchers who follow this policy — specifically, who avoid data destruction, social engineering, denial of service, and accessing data beyond the minimum needed to demonstrate the issue.
• Crediting you in our release notes if you’d like.

A formal bug bounty program, with scope and rewards, is planned for after launch. The PGP key for submitting sensitive reports will be published here at that point.

Compliance and audits

We are building toward SOC 2 Type II and, where applicable, ISO 27001. Our first audit period opens after launch. In the meantime, we plan to commission an independent cryptographic review of the key-management and capsule-delivery mechanisms; we will publish the summary of its findings here.

For customers with specific compliance requirements, we can share our security overview on request.

What you can do

A short list of things that will meaningfully strengthen your own security:

• Use a passkey on every device you sign in from.
• Set a recovery passphrase if you want to be able to restore your archive after losing every device.
• Sign out of devices you no longer use — the list is in Settings.
• Keep your operating system and the evervoice app up to date.
• Be suspicious of any email that claims to be from us and asks for a password, a code, or a key. We will never ask for those.

Contact

For security questions or to report an issue: security@evervoice.app.

For privacy questions, see the Privacy Policy.