Customer-managed keys don't stop the cloud from decrypting

Yes, the cloud can still decrypt your secrets with a customer-managed key. In AWS Secrets Manager, Google Cloud Secret Manager and Azure Key Vault, the service itself decrypts the value before it hands it to the caller, whether the key is the provider's default or one you manage in the cloud's key service. A customer-managed key, often shortened to CMEK, changes who controls the key's policy, what gets logged, and whether you can switch the key off. It does not move decryption out of the provider's infrastructure. That can be an acceptable trade, and this post shows where it is and where it isn't.

What follows is what each provider's documentation says, what CMEK actually gives you, and the questions that decide whether that is enough. For the same question asked of every kind of vault, see the guide who can decrypt your secrets.

The common design: envelope encryption in the service

All three use the same pattern. Each secret value is encrypted with a data key. The data key is encrypted with a key-encryption key held in the cloud's key management service. To read a secret, the service asks the key service to unwrap the data key, then decrypts the value with it and returns plaintext to your application.

"Customer-managed" refers to the key-encryption key. Instead of a key the provider creates and controls, you create one in the key service, set its policy and decide its lifecycle. The service still performs every encryption and decryption; it now does so with your key, on your behalf.

AWS Secrets Manager

AWS describes envelope encryption directly: "To decrypt the secret, Secrets Manager first decrypts the encrypted data key using the KMS key in AWS KMS." For reads, "Secrets Manager decrypts the secret value before returning it to the caller" (AWS: secret encryption and decryption).

You can use the AWS managed key aws/secretsmanager or any symmetric customer managed key in the account. The same page lists what is not encrypted at all: the secret name and description, rotation settings, the ARN of the KMS key, and tags.

The choice of key changes control rather than location. When Secrets Manager uses a KMS key, "it acts on behalf of the user who is accessing or updating the secret value." With a customer managed key, that user needs permission on your key, which you can restrict to calls that come through Secrets Manager with the kms:ViaService condition.

Google Cloud Secret Manager

Google's documentation describes the same structure: Secret Manager encrypts data "with a unique data encryption key (DEK)", which is then encrypted with a key-encryption key. By default that KEK is "owned by the Secret Manager service", which Google calls Google default encryption. With CMEK, "the KEK is called a CMEK key and is a symmetric key you manage within Cloud KMS" (Google Cloud: CMEK for Secret Manager).

The page is explicit about who does the work: "The service identity for Secret Manager, rather than the caller, is responsible for encrypting and decrypting secrets", and "the service identity accesses the key and encrypts or decrypts the secret on your behalf." You grant that service identity access to your key; it decrypts.

Azure Key Vault

Azure's description is the shortest: "The Azure Key Vault service encrypts your secrets when you add them and decrypts them automatically when you read them." The encryption keys form a hierarchy protected by FIPS-validated modules, with a leaf key unique to each key vault (Azure: about Key Vault secrets).

The same page then gives advice that makes the point of this post: "For highly sensitive data, consider adding extra layers of protection. For example, encrypt data by using a separate protection key before storing it in Key Vault." In other words, if you need the service not to be able to read a value, encrypt it yourself before it arrives.

What a customer-managed key actually gives you

CMEK is not decorative. It gives you four real controls.

Key policy you write. With a customer managed key in AWS, a principal needs both permission on the secret and permission to use your key. That gives you a second, independent place to say no. It is also how cross-account access works: AWS notes that "you can't use the AWS managed key (aws/secretsmanager) for cross-account access", so sharing a secret with another account requires a key you create.

A log of key use. Every decrypt shows up in the key service's audit log. On AWS, the Decrypt call that Secrets Manager makes includes an encryption context with the secret's ARN and version ID, so CloudTrail records which secret and which version were decrypted, and on whose behalf.

A switch you can turn off. In AWS KMS, "if you disable a KMS key, it cannot be used in any cryptographic operation until you re-enable it" (AWS KMS: enable and disable keys). On Google Cloud, "existing secret versions can't be accessed if the CMEK key that encrypted it is unavailable", and "if a key is destroyed, the secret data is unrecoverable." Disabling the key is a way to stop the service from serving those secrets.

Rotation and location on your terms. You decide the key's rotation schedule and, on Google Cloud, which location it lives in; the CMEK key "must be in the same Google Cloud location as the secret version replica it encrypts."

What CMEK does not give you is a service that can't read your values. While the key is enabled and the service identity has access to it, the service decrypts on request, and anyone who can make an authorized request gets plaintext.

When that is enough

It can be. If your threat model is "an outsider who steals a disk or a database backup", envelope encryption at rest already covers it. If it is "a person in our own cloud account who shouldn't read production secrets", IAM and key policies are the right tool, and CMEK adds a second gate and an audit trail. If you need to show an auditor that you can revoke the provider's ability to serve your data, a key you can disable does that.

It is not enough when the question is about the provider's own systems or anyone who can act as the service: a compromised service path, an insider at the provider, or a legal demand served on the provider rather than on you. In those cases the service, by design, can decrypt. The only answer is the one Azure suggests: encrypt the value before it reaches the service, with a key the service never has.

Three questions to ask

1. Where is the value decrypted? On every one of these services, inside the service.
2. Who can make the service decrypt? Anyone with IAM access to the secret and, with CMEK, to the key, plus the service identity itself.
3. Can you prove who did? With CMEK, the key service's log shows each decrypt; check that it is retained long enough.

The glossary entries for customer-managed key and KMS define the terms, and the pages on AWS Secrets Manager, Google Cloud Secret Manager and Azure Key Vault compare each service with Crunu.

The alternative: decrypt only on your devices

Client-side encryption moves the answer to question 1. In Crunu, values are encrypted and decrypted only in the browser and in the crunu agent on your machines and CI runners. The server, including the cloud service at app.crunu.com, stores ciphertext and holds no decryption key at any point in the protocol. Each environment has its own key, sealed to the public key of every person and machine with access, so access is a matter of who holds keys rather than of a policy the server enforces.

That changes the trade-offs, not just the answer:

• The server can't help you recover. It can't reset a password or decrypt on your behalf; the account's keys come from a password and a Secret Key that never leave the device.
• The server still sees metadata. Names of organizations, projects, environments and machines, email addresses, the audit log, and the size and time of each version.
• No server-side features that need plaintext. No dynamic secrets, no built-in sync to other platforms, no rotation of values at providers.

If your applications run inside one cloud and your concern is people in your own account, a cloud secret manager with a customer-managed key is a reasonable, well-understood choice. If your concern is anyone who operates the service, only encryption before the service will do.

Sources

• Secret encryption and decryption in AWS Secrets Manager, checked October 30, 2026.
• Access AWS Secrets Manager secrets from a different account, checked October 30, 2026.
• Enable and disable keys, AWS KMS Developer Guide, checked October 30, 2026.
• Enable customer-managed encryption keys for Secret Manager, Google Cloud, checked October 30, 2026.
• About Azure Key Vault secrets, Microsoft Learn, checked October 30, 2026.