The two vSAN encryption services, the threat each addresses and which one needs a key provider.
From Ultra Transcenders 2V0-16.25 by Tony Rough (coming October 2026)
vSAN offers two independent encryption services at the cluster level, one for data on disk and one for data on the wire. They protect against different threats and have different prerequisites.
| Data-at-rest encryption | Data-in-transit encryption | |
|---|---|---|
| Protects against | A device removed from the cluster | Interception of traffic between hosts |
| Scope | Everything on the vSAN datastore | All data and metadata between hosts, witness traffic and vSAN file service traffic |
| Key provider needed | Yes: external KMS (standard key provider) or Native Key Provider | No; hosts generate symmetric keys per connection |
| Algorithm | AES-256 XTS | AES-256 with forward secrecy |
| Interaction with space efficiency | OSA: after deduplication and compression; ESA: after compression on the write path | Not applicable |
| Configuration | Cluster > Configure > vSAN > Services > Data Services | Same page, with a rekey interval |
The two can be enabled separately. In vSAN OSA each disk has its own DEK; in vSAN ESA all disks in the cluster share a DEK for object data. After a reboot a host does not mount its disk groups until it receives the KEK. Enabling data-at-rest encryption on an existing cluster starts a rolling reformat across all disk groups or storage pools; Wipe residual data and Allow reduced redundancy are options on that dialog. The witness host does not take part in vSAN encryption; to protect witness metadata, encrypt the cluster that hosts a witness appliance.
vSAN encryption and vSphere Virtual Machine Encryption use the same libraries but differ in scope: vSAN encrypts at the datastore level, VM encryption per VM on any datastore type, including vSAN.
Common trap: Deploying the KMS that serves vSAN encryption on the same vSAN datastore it protects - the design guidance says not to, because hosts that reboot need the KMS to unlock their disks. Use a highly available KMS outside the encrypted cluster, or a Native Key Provider.
This note is one section of Ultra Transcenders 2V0-16.25: VMware vSphere Foundation 9.0 Administrator, an independent study guide that explains every topic the exam covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to Broadcom TechDocs.
Due on Amazon in October 2026, in Kindle and paperback editions.
About the book · 2V0-16.25 terms in the glossary · All 2V0-16.25 study notes
What VVF 9.0 includes, what only VCF 9.0 adds, and where the two share a code base.
Storage pools or disk groups: the hardware, memory and network each vSAN architecture needs, and how failures differ.
The rules in a vSAN storage policy, their defaults, and how mirroring compares with erasure coding.
Per-host or vCenter-managed networking, and the features only a distributed switch brings.
Cluster resource percentage, slot policy and dedicated failover hosts compared, with what each reserves.
How each library type gets and shares its content, and when subscribers download items.
Node layouts, failure protection and latency limits for each VCF Operations cluster model, and how a VVF platform reaches them.