Security and encryption at Restorable

Three layers of keys

A data encryption key per client, 256-bit and versioned. It encrypts every object written for that client in every workload. Old versions are kept so old objects stay readable.
A control-plane key held by Restorable, identified so it can be rotated. Each client key is stored wrapped under it. This is what a worker unwraps to run a backup at three in the morning with nobody present.
Your recovery passphrase, set once and never stored by us. It is stretched with Argon2id, and each client key is also stored wrapped under the result. A separate verifier lets the console tell you that a typed passphrase is right without touching a key.

Wrapping is AES-256-GCM with the wrapped key's own metadata bound in as associated data. Changing your passphrase unwraps every client key through the control-plane key and rewraps it under the new one, in one transaction, and it is audited.

Where the working keys live. Agentless Microsoft 365 backup has to run with nobody present, so Restorable's backup service keeps a working copy of each client key, sealed under the control-plane key, to run backups and restores unattended. That is true of every product in this category, which is why we do not describe Restorable as zero knowledge. What is different is that you hold an independent copy of every key, wrapped under a passphrase we never see, and the data sits in a bucket we do not own. You can walk away and still read everything.

What an object looks like in your bucket

Every object is an encrypted stream: a short self-describing header carrying the format version, the client key version and a base nonce, then the payload in one megabyte chunks each sealed with AES-256-GCM. The object key is bound in as associated data, so an object cannot be moved, swapped or truncated without it failing to open.

Object keys are laid out as tenant, workload, principal, item, version. The item component is a hash, so a bucket listing tells an onlooker nothing readable about your customers: no names, no subjects, no file names.

The format is a public commitment rather than an implementation detail, because the offline recovery tool has to open every object ever written. Header and chunk layout changes are versioned, never altered silently.

The recovery kit

Three things read your backups with no involvement from us:

Your bucket credentials, which you already hold.
Your recovery passphrase, which only you know.
The recovery bundle, downloaded from the passphrase page: the key derivation parameters, every client with its bucket location, every tenant identifier, and every client key version wrapped under your passphrase. It contains no bucket credentials and no passphrase, so it opens nothing on its own. Downloading it is audited.

restorable-recover is a single static binary for Windows, macOS and Linux, published on every release. It never talks to Restorable. It reads the bundle, prompts for the passphrase, checks it against the verifier, lists the client's prefix in your bucket with your credentials, decrypts each object and writes plain files: mail as .eml, drive files byte for byte. Add the client manifest from the console and recovered files get their real names.

--verify-only opens every object and writes nothing. Run it against one client twice a year. A backup nobody has ever restored is a rumour.

Replacing your passphrase invalidates old bundles at once, and the console tells the owner to download a fresh one. Adding a client is also a reason to re-download.

What is indexed and what is not

Search has to be instant across an entire estate, so it runs against our index rather than your bucket. That index holds metadata and only metadata:

In the index, in the clear: Message subjects, sender and recipient addresses and display names, folder paths, dates, sizes, content hashes, object keys, file and folder names, and drive and site paths.
Never indexed: Message bodies and file contents. Indexing them would put customer content, or a word-level shadow of it, into our database in the clear. If a client genuinely needs body search, that is a separately priced, opt-in design and a conversation to have with us, not a default.

Explorer therefore matches on subjects, sender addresses and names, file names and paths, with filters for client, date range, attachments, workload and file extension. Every search with a term is written to the audit log with the name of whoever ran it, because searching across every customer's mail is a privileged act and should leave a trace.

Access to your account

Roles. Read only sees everything and changes nothing. Technician protects, excludes, backs up, restores and exports. Admin adds clients, policies, storage, team and notifications. Owner adds the recovery passphrase and API keys. Nobody can grant a role above their own or act on a user who outranks them, and the last owner cannot be removed or demoted.
Second factor. An authenticator app, with ten single-use recovery codes shown once. An owner can clear a locked-out colleague's second factor.
Sessions. A password reset link is single use and lasts an hour, and using it signs out every other session. Changing a password signs out your other sessions. Removing a user revokes theirs immediately.
API keys. Created by an owner, shown once, sent as a bearer token, and optionally restricted to a list of clients so a key for one customer's dashboard cannot see another's.
Audit log. Consent changes, protection changes, restores, exports, searches with a term, bundle downloads and passphrase operations are all recorded with the actor.
Tenant scoping. Every tenant-owned table carries the MSP identifier and every query filters on it, enforced in the data access layer rather than left to individual handlers, with a build-time check that it stays that way.

Access to your customers' Microsoft 365

Restorable is one multi-tenant Entra application. Each customer's own administrator grants it consent once, in their own tenant. Backups then run with application permissions through Microsoft Graph, with no user signed in. The customer can revoke consent themselves by removing the enterprise application in their tenant, and we ask for the narrowest set of permissions that will do the job: reading and writing mail and files for backup and restore, mailbox settings, and Microsoft's usage reports so you can see sizes before you protect anything.

Storage credentials

The access key secret for your bucket is stored encrypted under the control-plane key and never shown again after you save it. Adding a bucket runs a test that it can be listed and written before you rely on it. One bucket is your default and any client can be pointed at another.

Hosting and transport

The service runs on a Contabo Cloud VPS in the European Union (France). Development is local and never touches production data.
It is a single host in a single region today. A hardware failure is downtime, not data loss, because your backup data is in your own bucket and our database is backed up separately. There is no published uptime commitment yet: see [uptime commitment] in the terms.
All traffic is over TLS with certificates from Let's Encrypt, with HTTP Strict Transport Security, X-Content-Type-Options: nosniff and a strict referrer policy. Internal metrics endpoints are never exposed publicly.
This website loads nothing from anyone else: no fonts, no scripts, no images, no analytics, no content delivery network. It also sets no cookies.

Sub-processors and data protection

The organisations that process data on our behalf are listed on the sub-processors page, with what each one is for. Your storage provider is your own choice and your own contract, and is not our sub-processor. The data processing agreement sets out the Article 28 terms, and the privacy notice covers the personal data we hold about you as a customer.

Reporting something

If you find a vulnerability, email hello@restorable.cloud with enough detail to reproduce it and we will come back to you. Please do not run automated scanning or load testing against production without asking first: it is indistinguishable from an attack and it is covered by the acceptable use policy. A dedicated security contact and disclosure timetable are still to be set: [security contact and disclosure policy].