diff --git a/website/content/docs/concepts/security/data-encryption.mdx b/website/content/docs/concepts/security/data-encryption.mdx
index ca395970c3..468ad0fdb9 100644
--- a/website/content/docs/concepts/security/data-encryption.mdx
+++ b/website/content/docs/concepts/security/data-encryption.mdx
@@ -20,7 +20,7 @@ Worker](/docs/configuration/worker/pki-worker) for storage of authentication
 keys. It is optional for PKI workers; if not specified the authentication keys
 will not be encrypted on disk. This is not used by KMS workers.
 
-## The `rootKey` KMS Key and Per-Scope KEK/DEKs <sup>OSS Only</sup>
+## The `root` KMS Key and Per-Scope KEK/DEKs <sup>OSS Only</sup>
 
 Following best practices of using different encryption keys for different
 purposes, Boundary has a number of encryption keys generated within each scope.
@@ -29,11 +29,11 @@ data. You can create new key versions by _rotating_ the keys. A key version
 can be destroyed, which will re-encrypt any existing data before destroying the
 key material permanently.
 
-The `rootKey` KMS key acts as a KEK (Key Encrypting Key) for the scope-specific
-KEKs (also referred to as the scope's `rootKey` key). The scope's `rootKey` KEK
+The `root` KMS key acts as a KEK (Key Encrypting Key) for the scope-specific
+KEKs (also referred to as the scope's `root` key). The scope's `root` KEK
 and the various DEKs (Data Encryption Keys) are created when a scope is created.
-The DEKs are encrypted with the scope's `rootKey` KEK, and this is in turn
-encrypted with the KMS key marked for the `rootKey` purpose.
+The DEKs are encrypted with the scope's `root` KEK, and this is in turn
+encrypted with the KMS key marked for the `root` purpose.
 
 The current scoped DEKs and their purposes are detailed below: