What’s the issue?
Always Encrypted protects sensitive columns by encrypting data in the client driver, so the SQL Server engine only ever sees ciphertext. The model depends on a two-level key hierarchy: a column encryption key that protects the data, and a column master key that protects the column encryption key and is held outside the database.
SQL Server stores only metadata describing where the column master key lives, not the key itself. Supported locations include Azure Key Vault, a hardware security module, and the Windows certificate store, with the certificate store option specifying either the current user or the local machine on a given host.
This check identifies column master keys whose metadata points to the local machine certificate store on the SQL Server host, detected by examining the key path in sys.column_master_keys.
Why is this a problem?
Storing the master key on the SQL Server host defeats the premise of separation that Always Encrypted is built on. The entire point of the feature is that the database server cannot decrypt the protected columns, and placing the key on that same host means anyone with administrative access to the machine has both the ciphertext and the means to decrypt it.
The set of people who can reach the key is wider than the database team. Local administrators, backup operators, virtualization administrators, and anyone who can restore a system image or snapshot of the host can extract a key from the local machine certificate store.
The configuration also weakens the protection Always Encrypted offers against a compromised database. An attacker who reaches the host, whether through the database engine or through the operating system, no longer needs to defeat the encryption separately, since both halves of the problem sit in the same place.
What should you do about this?
Review the current key locations by querying sys.column_master_keys and examining the key path for each, identifying which point at the local machine store on a SQL Server host. Confirm with the application owners which applications use each key and where the corresponding clients run.
Plan a migration to a key store that is separate from the database host, with Azure Key Vault or a hardware security module being the usual choices. The rotation process involves creating a new column master key in the target store, re-encrypting each column encryption key under both keys, updating clients, then removing the old key.
Ensure the new key store restricts access to only the application identities that need to decrypt.