In many companies, encryption is considered “done” because the service indicates encrypted at rest and the team marks the control as fulfilled. The problem is not encryption itself, but the interpretation: a default provider-managed key (the typical “aws/s3”, “Microsoft-managed”, “Google-managed”) rarely adds a real barrier if an attacker gains permissions over the resource.
The myth appears when it is assumed that “using KMS” is equivalent to “controlling who can decrypt”. In practice, with provider-managed keys, decryption is often implicitly allowed through the service itself as long as you have access to the resource. If your permissions model fails (and in real incidents it often fails), encryption does not stop unauthorized access.
What went wrong: default encryption does not separate access to the data from access to the key
The pattern repeats: a bucket, a database, or a volume appears as encrypted and the team feels reassured. Then a credential compromise occurs (leaked API key, exposed CI/CD token, stolen session) and the attacker does not “break” the encryption: they simply read the object or query the table because the service decrypts for them.
In corporate environments with complex IAM, that difference between “I can read the resource” and “I can use the key” is critical. With default provider-managed keys, the provider usually performs decryption as part of the normal service flow. Result: the key does not act as an additional guardrail, and the impact of the incident shifts from “data inaccessible” to “silent exfiltration”.
Real consequence in a company: internal audits where the control was marked as OK due to “encryption at rest”, but the incident proves there was no second layer of authorization tied to key usage. What was missing was not cryptography; it was policy design.
The most common abuse: “anyone with access to the resource can decrypt”
The typical abuse scenario is not sophisticated. A role with broad permissions to S3/Blob/Storage (for example, a support role with temporary read access, or a pipeline with inherited permissions) ends up being enough to access sensitive data. Default encryption adds no friction because the service decrypts on the fly for whoever meets the resource access conditions.
In forensic investigation terms, this shows up as legitimate accesses from compromised identities, not as cryptographic failures. If there are also enumeration permissions, the attacker can locate containers with critical data and extract them without touching key configuration.
- Direct read on the resource: when the bucket/container policy or IAM allows GetObject/Read, the service does the rest. In real incidents, the control that fails first is permissions, not encryption.
- Cross-cutting permissions for “convenience”: roles shared between apps or teams (or “temporary admin” profiles) turn default encryption into a compliance check with no operational value. The damage appears when those permissions are reused outside the expected context.
- False sense of separation of duties: it is believed that security “owns KMS” and platform “owns the resource”, but if the key does not enforce restrictions, that separation is cosmetic. The attacker does not need to touch KMS to decrypt if the service does it for them.
The problem is not using managed services, but trusting that a default provider-managed key will act as an access control. For critical data, you need key usage to be conditioned and verifiable.
How to do it in practice: CMK and policies that force going through the service and specific roles
The practical fix in AWS often starts by migrating to Customer Managed Keys (CMK) and designing the Key Policy as a real security control, not as an “allow admin”. The goal: even if someone gets permissions over the resource, they cannot use the key outside the expected context or from unauthorized identities.
A useful pattern is to require that key usage happens via the service and only for a set of roles/applications. In AWS this is implemented with conditions like kms:ViaService and, where applicable, context restrictions (account, region, encryption context). Example statement (illustrative fragment) to limit usage to S3 in a specific region and to an application role:
{
"Sid": "AllowUseFromS3OnlyForAppRole",
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::123456789012:role/app-prod"},
"Action": ["kms:Encrypt","kms:Decrypt","kms:GenerateDataKey"],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:ViaService": "s3.eu-west-1.amazonaws.com",
"kms:CallerAccount": "123456789012"
}
}
}
The important thing is not copy/paste: it is the criterion. If the attacker steals credentials from another role with access to S3, but that role cannot use the CMK under those conditions, the read will fail even if the bucket is accessible. That is where encryption starts to be an effective control.
- Create a CMK per data domain: not one per service “just because”, but per set of data with similar criticality and lifecycle. This allows you to revoke or rotate with controlled impact and apply specific policies per application.
- Configure the Key Policy as the primary authority: avoid delegating everything to IAM if there is no restrictive key policy. In AWS, the key policy rules; if it is permissive, encryption becomes decorative again.
- Validate with negative tests: in addition to testing that the app works, test that a “nearby” role (for example, a general read role or a data tooling user) receives AccessDenied when trying to read objects encrypted with that CMK. In companies, these tests detect 80% of modeling errors.
Operationally, add continuous verification: review AWS CloudTrail KMS events (Decrypt/GenerateDataKey) and correlate them with the expected role. If you see decryptions from identities or services not planned, your policy is not fulfilling its function.
Multi-cloud without self-deception: AWS KMS, Azure Key Vault, and GCP Cloud KMS do not behave the same
The concept repeats across the big three: provider-managed keys simplify operations, but they tend not to strongly separate “access to the resource” from “explicit authorization to use the key” for your specific case. The details change by platform and service, and that is where mistakes are made when extrapolating a mental model from one cloud to another.
In AWS, separation is achieved with CMK + Key Policy + conditions such as kms:ViaService. In Azure, using your own keys is usually implemented with Customer-Managed Keys in Azure Key Vault or Managed HSM depending on the service (for example, storage encryption, or TDE/Always Encrypted in databases, depending on the case). In GCP, the equivalent is Cloud KMS (and, when you need stronger isolation, Cloud HSM).
The practical difference in a company is how identities and permissions are governed: in Azure, the anti-pattern often appears that “many contributors have access to the storage account and, by extension, to data encrypted with managed keys”, because decryption is part of the service. In GCP, a common mistake is assuming that “CMEK = total control” without reviewing who has permissions to use the key and from which services/projects.
When to consider dedicated HSM: when there are cryptographic isolation requirements, strict regulatory compliance, or insider-abuse risk that requires additional controls (approvals, stronger separation, evidence). It is not a wildcard: it adds cost and operational complexity, and if the resource IAM is still the open door, it will not save you.
Recommendations for corporate environments
Cloud encryption does not fail; the expectation fails. Default provider-managed keys are suitable to reduce exposure to physical loss or lower layers, but they are not designed to stop an actor who has already obtained permissions over the resource.
For critical data, real control arrives when you use customer-managed keys and turn the key policy into a guardrail: limit which roles can use it, require that usage happens via the correct service (for example, kms:ViaService in AWS), and validate with negative tests that “nearby” identities cannot decrypt.
In multi-cloud, avoid carrying assumptions between providers. Always review the exact point where key usage is authorized (KMS/Key Vault/Cloud KMS) and verify that access to the resource does not imply automatic decryption for identities that should not see the data.
Interested in Cloud Security?
Technical analysis, hands-on labs and real-world cloud security insights.