Encryption Algorithm
Every file and mail item is encrypted with AES-256-GCM before it is written to your storage account. Anyone with direct access to your Azure container or S3 bucket sees only ciphertext.
AES-256-GCM
Content is encrypted with AES-256 in Galois/Counter Mode (GCM), an authenticated encryption cipher that produces ciphertext and an authentication tag together.
Encryption happens in memory before the resulting bytes are written to your storage account — unencrypted content is never written to BYOVault’s own disk.
The same encryption scheme applies consistently across every backup path, Microsoft 365 workloads and file-server uploads alike, so content encrypted on one path can always be restored through any other.
A fresh, random IV for every operation
A fresh initialization vector (IV) is generated from a cryptographically random source for every encryption operation and is never reused, even across pieces of the same file.
This guarantees that encrypting the same content twice never produces the same ciphertext, and that no two operations, anywhere in the system, ever share an IV.
That property matters because reusing an IV under the same key can otherwise weaken GCM’s confidentiality guarantee.
Built-in integrity: the GCM authentication tag
GCM produces an authentication tag as part of normal encryption; no separate step is required to generate it. On restore, this tag is verified before any content is returned.
Ciphertext that has been altered, truncated, or presented with the wrong IV or key fails verification outright — it never returns corrupted or partial data.
A second, independent integrity check
Alongside GCM’s own tag, an independent checksum is computed and stored at backup time, and verified again on every restore.
This is a genuinely separate check, computed and verified outside the cipher itself, so it catches a mismatch between what was originally protected and what comes back on restore — including a class of error the cipher’s own tag alone would not catch.
A mismatch fails the restore outright rather than returning content that does not match what was actually backed up.
What this page does not cover
This page describes only the encryption and integrity guarantees applied to your content. How the key behind that encryption is produced for a given tenant, and what happens when a customer supplies their own, are covered separately: see Key Derivation & Hierarchy for how a tenant’s default-path key is derived, and Customer-Managed Keys (BYOK) for the alternative in which the key itself is generated at random and held under the customer’s own control.