Security teams should separate encrypted data from the keys needed to unlock it, and ensure those keys are generated and held only by the customer. If the provider can access both, a breach of the provider can expose everything. Strong encryption is not enough on its own. Key custody, derivation, and storage boundaries determine whether encrypted data stays protected in practice.
Why provider-readable encryption fails the privacy test
The security boundary is not the ciphertext alone. If the provider can also reach the decryption key, escrowed secret, or wrapping mechanism, the provider effectively becomes part of the trust domain and can recover the plaintext. That means the design goal is not “encrypted at rest,” it is customer-exclusive key control with a boundary the provider cannot cross.
In practice, this is the difference between protecting data from outsiders and protecting it from the operator of the platform itself. If the provider can decrypt, it can inspect, copy, or expose customer content under breach, subpoena, abuse, or privileged access scenarios, even when the storage layer remains encrypted.
What design choices actually keep the provider out
The provider must never hold the only decryption path. Strong designs use customer-managed keys, external key custody, or client-side encryption so that the provider sees only ciphertext and cannot reconstruct plaintext without customer involvement. For cloud workloads, the relevant question is where keys are generated, where they are stored, and who can invoke the decrypt operation.
The most important control is separation of duties between data storage and key custody. Encryption algorithms matter, but they do not solve this problem by themselves. A provider-managed vault, a shared KMS policy, or a default integration that silently grants decrypt capability can undo the privacy promise even if the cryptography is sound.
That is also why envelope encryption must be reviewed carefully. It can be secure when the customer controls the root key, but it fails the stated objective when the provider can unwrap the data key or access the root material. The implementation detail, not the label “encrypted,” determines whether the provider is excluded from decryption.
Where the boundary is usually lost in real systems
The boundary most often fails through operational convenience. Teams let the platform manage rotation, share keys across environments, or grant support personnel access to break-glass tooling that can decrypt production data. Those choices may improve recoverability, but they also enlarge the number of parties who can turn ciphertext back into readable information.
Another common failure is indirect access through integrations. Backups, analytics jobs, search indexing, or application proxies may receive enough secret material to decrypt data even when the primary storage service does not. If any downstream component can reconstruct plaintext, the provider has not been meaningfully excluded from the trust chain.
For teams designing around this requirement, the key question is whether the provider can independently complete the decrypt path. If the answer is yes, the encryption model protects against passive exposure only, not against provider compromise or privileged misuse.
Risk and Threat Considerations
When the provider can decrypt customer data, encryption no longer meaningfully limits the blast radius of a provider breach, privileged insider abuse, or compelled disclosure. The apparent protection becomes conditional on the provider remaining uncompromised, which is a weaker assurance than most customers expect.
Failure mechanism: The provider retains or can invoke the decryption key path, so a compromise of the provider environment, admin plane, or support workflow can expose plaintext even though the data was stored encrypted.
Impact: Customer confidentiality depends on provider trust, not just cryptography, and a single provider-side compromise can disclose large volumes of data across tenants or workloads.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST SP 800-57 and NIST Zero Trust (SP 800-207) set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-12 — Cryptographic Key Establishment and Management | Customer-held key custody and unwrap control are central to provider-blind encryption. |
| IA-5 — Authenticator Management | Key rotation and lifecycle control are required where keys function as authenticators to data access. | |
| AC-6 — Least Privilege | Prevent provider roles and support workflows from gaining unnecessary decrypt authority. | |
| Recommendation — Separate key custody from storage and restrict who can establish and manage decryption keys. Manage encryption key lifecycle so decryption capability is tightly controlled and rotated. Limit decrypt privileges to the smallest set of customer-controlled roles possible. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The design depends on enforcing who may access decryption capability, not only stored data. |
| A.8.24 — Use of cryptography | Cryptographic design must ensure ciphertext stays unreadable to the provider by controlling key use. | |
| Recommendation — Define and enforce access boundaries so providers cannot reach customer decryption material. Implement cryptography so only the customer can use the keys that reveal plaintext. | ||
| NIST SP 800-57 | Key Management | The question is fundamentally about key generation, custody, and separation from encrypted data. |
| Recommendation — Design the key lifecycle so decryption keys remain outside the provider’s operational reach. | ||
| NIST Zero Trust (SP 800-207) | Never Trust, Always Verify | Provider-side access to plaintext should be denied by design, not assumed safe by network or platform trust. |
| Recommendation — Apply zero trust boundaries so no provider component is implicitly trusted to decrypt customer data. | ||
Practitioner Guidance
What to verify: Confirm who generates the root key, who can rotate it, who can unwrap data keys, and whether any provider-operated component can trigger decryption without customer approval. If the answer cannot be demonstrated from configuration and architecture evidence, the design is not yet privacy-safe.
Decision rule: If the provider can decrypt independently, treat the model as shared-trust encryption and scope it for availability or compliance use cases only. If the business requirement is provider-blind confidentiality, require customer-held keys, strict separation of duties, and a documented path that keeps plaintext inaccessible to the provider.
Practitioner takeaway: The real control is not stronger encryption, it is preventing the provider from ever obtaining a usable decryption path.
Related resources from NHI Mgmt Group
- How should security teams protect sensitive vault data when the platform provider cannot decrypt it?
- How should security teams design password-based authentication so stolen verifier data cannot be reused to attack accounts or decrypt data?
- How should security teams choose between a secrets manager and an encryption service for customer data in a SaaS application?
- How should security teams design encryption and key management for sensitive data in multi-tenant applications?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
