Everywhere else on this site we speak plainly. This page is for the reviewer, the auditor, the insurer, and the nephew who knows computers. Precise claims only. For the business-language version, see compliance.
The design assumption: every protected endpoint will eventually be fully compromised. The attacker holds local admin, every stored credential, and the backup agent's own configuration. The design goal: that attacker can, at worst, damage the current backup of that one device. Never the recovery history. Never another device. Never another customer.
| Scenario | Outcome |
|---|---|
| Ransomware with full admin on one device | Can corrupt that device's current backup at most. Sealed Vault copies and version history survive. Other devices unaffected. |
| Attacker steals the device's storage credentials | Those credentials reach one device's own storage area only, and cannot touch Vault snapshots at all. |
| Storage provider is breached | Attacker obtains ciphertext. Without the customer's key, it is noise. |
| EverBack itself is breached | We hold no customer keys and no plaintext. Control-plane compromise cannot decrypt customer data. |
| Malicious insider at EverBack | Same answer. The math does not care who signs the paycheck. |
| Customer loses their encryption key and recovery kit | Data is unrecoverable. By anyone. We accept this consequence openly, and the onboarding makes the recovery kit hard to skip. |
Data plane: the agent on each device encrypts locally and writes directly to that device's own storage area over SSH/SFTP. Backup payloads never pass through EverBack's servers. There is no central service that sees, buffers, or could log customer file data.
Control plane: our backend handles enrollment, policy, health telemetry (counts, timestamps, sizes; never file contents or names), storage provisioning, and Vault snapshot scheduling. It holds no keys capable of reading any customer's data.
Isolation: one customer, one isolated storage unit. Within it, one device, one locally-generated SSH keypair, one subaccount confined to its own directory. No shared credentials anywhere in the fleet.
The backup engine is restic, an open-source repository format with a decade of public scrutiny. We chose it precisely so you do not have to trust our proprietary crypto. There isn't any.
| Encryption at rest | AES-256 in counter mode with Poly1305-AES authentication. Performed client-side, before upload. |
| Key derivation | scrypt. The repository key is generated on the customer's device and never transmitted. |
| Transport | SSH (SFTP) with per-device keys and pinned host keys. |
| Deduplication | Content-defined chunking. Only changed chunks travel or are stored. |
| Integrity | Every blob is content-addressed by SHA-256 and cryptographically verified on read and during periodic checks. |
| Vault immutability | Storage-layer point-in-time snapshots, read-only by construction. No endpoint credential can list, alter, or delete them. |
| Independence | With their key, a customer can restore using stock open-source tooling, without any EverBack software or service. |
Verify it yourself: any customer can point standard restic at their own repository and confirm every claim on this page: the encryption, the integrity checks, the independence. We think a security product you cannot independently verify is a rumor.
Restore verification: we periodically restore and hash-verify real samples from customer repositories (ciphertext operations only; we verify integrity, not contents) so "backups work" is measured, not assumed.
Monitoring: every device reports backup health. Silence, failures, and abnormal change patterns raise alerts on our side before the customer notices anything.
Data residency: customer data is stored in the region chosen at signup: United States or European Union. It does not move between regions.
Key handling at onboarding: the recovery kit (customer's key, printed or stored offline) is generated during setup and verified before we consider a customer protected. Losing every copy of the key means losing the data. We say this out loud during onboarding, twice.
Report security issues to security@everback.cloud. We respond within one business day, we do not threaten researchers, and we credit findings publicly if you want the credit. Good-faith research against your own account and data is welcome.