Security Overview
BYOVault is built around one structural guarantee: your backed-up data is encrypted and written directly to a storage account you own. BYOVault's own infrastructure never holds a copy of your file content — only the metadata needed to find and restore it.
The trust model
When BYOVault backs up SharePoint, OneDrive, Exchange, or a file server, the encrypted bytes are written straight to the Azure Blob container or AWS S3 bucket you configured — a storage account that belongs to you, not to BYOVault.
BYOVault’s own database records only the catalog information needed to find and restore an item: what it is, where it lives in your storage account, and the metadata needed to put it back correctly. It does not store the file content itself.
If someone gains access to BYOVault’s own infrastructure without also gaining access to your storage account, they see catalog metadata and pointers, not readable data.
Your storage credentials are held by BYOVault only as a reference to a secret in BYOVault’s own Key Vault, resolved at the time a backup or restore operation actually needs them.
See Storage Credentials for how that resolution works and what it does and does not protect against.
What the rest of this section covers
The trust model above is a summary. Each of the following pages goes into the specific mechanism behind it.
| Page | What it covers |
|---|---|
| Encryption Algorithm | The AES-256-GCM construction used for content encryption, IV handling, and integrity verification. |
| Key Derivation & Hierarchy | How a tenant’s default-path encryption key is derived from the master key via HKDF. |
| The Shared Master Key | Where the default-path master key actually lives, and what protecting it changes and does not change. |
| Customer-Managed Keys (BYOK) | The alternative to the shared master key: a randomly generated, customer-wrapped key created per file. |
| BYOK on AWS KMS: Architecture | The two-layer trust model behind AWS-backed BYOK. |
| BYOK on Azure Key Vault: Architecture | Why Azure-backed BYOK uses a multi-tenant app and federated identity rather than a shared secret. |
| Key Availability & Failure Behavior | What happens to backup and restore operations if a customer-managed key becomes unreachable, disabled, or deleted. |
| Storage Credentials | How your Azure or AWS storage credentials are held and resolved by BYOVault. |
| Data Residency & Data Flow | Which bytes touch BYOVault’s infrastructure and which go directly to your storage account, per operation. |
| Authentication & Session Security | How operator sessions and end-user self-service sessions are secured, and why they are kept separate. |
The default path does not give you a customer-held key
Unless a tenant has been configured for customer-managed keys, every tenant’s encryption key is derived from a single master key that BYOVault itself controls — held in BYOVault’s own Azure Key Vault.
Hardening where that key is stored changes how hard it is to leak. It does not change who controls it.
Customers who require a genuinely customer-held key — one BYOVault cannot use independently of you — should configure Customer-Managed Keys (BYOK), where the key protecting each file is generated at random and wrapped by a key held in your own AWS KMS or Azure Key Vault, not derived from BYOVault’s shared master key.