Customer-managed encryption keys keep the organisation in control of the keys that protect sensitive data, usually through an HSM it owns or manages. Provider-managed keys place that custody with the service operator. The practical difference is governance. Customer-managed keys give stronger sovereignty and policy alignment, while provider-managed keys reduce customer operational responsibility.
How the Two Models Split Control of Encryption Keys
Customer-managed encryption keys and provider-managed encryption keys differ first in custody, then in governance. With customer-managed keys, the organisation decides who can create, rotate, disable, or destroy the keys, usually through a KMS or HSM boundary it controls. With provider-managed keys, the SaaS operator owns more of that lifecycle and the customer consumes the protection as a service feature.
The operational effect is not just where the keys live. It changes who can prove key provenance, who approves rotation timing, and who can respond when a key must be revoked. For teams that treat encryption as part of policy enforcement, the distinction matters as much as the cryptography itself.
Why Custody Changes Sovereignty, Auditability, and Blast Radius
Customer-managed keys are usually chosen when the organisation needs stronger sovereignty over sensitive data, tighter alignment to internal policy, or a clearer separation of duties. That often matters in regulated environments, cross-border deployments, and cases where evidence of key control is part of the control story. Cryptographic Key Management Guide is a useful companion because the real question is not whether encryption exists, but who governs the key lifecycle behind it.
Provider-managed keys simplify operations, but they also concentrate trust in the SaaS operator. The customer typically gets less direct visibility into rotation cadence, key hierarchy, and recovery mechanics, which can make incident response and audit evidence more dependent on the provider’s assurances. Where certificate and key handling are part of the platform design, the lifecycle view in Machine Identity, PKI and Certificate Lifecycle Guide helps explain why custody and lifecycle are inseparable.
From a governance perspective, the practical difference is blast radius. If the provider controls the keys, the customer may reduce administrative burden, but it also inherits whatever constraints the provider imposes on rotation, revocation, escrow, or forensic access. If the customer controls the keys, it gains more authority, but it also accepts more responsibility for availability and recovery.
When the Choice Becomes a Security Decision, Not a Procurement One
In saas pki environments, the key question is whether encryption is serving only confidentiality, or also compliance, segregation, and control objectives. If the answer involves regulated data, strict tenant isolation, or a requirement to disable access quickly after a compromise, customer-managed keys usually matter more because they preserve an independent control point outside the provider’s default administration model.
Provider-managed keys are often acceptable when the organisation wants strong baseline encryption without the overhead of key operations. That trade-off is valid when the data classification, regulatory exposure, and incident assumptions do not require the customer to hold a distinct revocation lever. The mistake is to treat provider-managed keys as “good enough” for every workload simply because encryption is present.
When SaaS access is mediated by accounts, tokens, certificates, or APIs, key control should be evaluated alongside the broader trust boundary. For teams assessing exposure from compromised credentials or upstream platform abuse, LastPass breach 2022 is a reminder that the security outcome depends heavily on what the operator can access, not only on whether encryption was enabled.
Risk and Threat Considerations
Key custody changes what an attacker, insider, or compromised provider account can do after gaining access. In customer-managed models, the main risk is misconfiguration, weak key governance, or unavailable recovery paths; in provider-managed models, the main risk is over-reliance on the operator’s controls and incident handling.
Failure mechanism: If the organisation cannot independently rotate, revoke, or retire keys when trust is lost, compromise can persist longer than expected, especially when encrypted backups, archives, or replicated data remain reachable under the same trust model.
Impact: The organisation may lose the ability to contain exposure quickly, demonstrate control to auditors, or enforce internal policy over sensitive SaaS data, even if the underlying cipher strength remains sound.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57, CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | Key custody and lifecycle are the core issue in managed-key SaaS encryption. |
| Recommendation — Define who can create, rotate, revoke, and destroy keys before approving the model. | ||
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Managed key models depend on access governance over who can administer cryptographic material. |
| Recommendation — Restrict administrative access to key management actions and separate duties tightly. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | The question is about cryptographic control choice and governance over protected data. |
| Recommendation — Specify whether key custody stays with the customer or the SaaS provider in policy. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Key and secret lifecycle controls are central when SaaS encryption depends on managed credentials. |
| Recommendation — Manage cryptographic secrets with documented rotation, revocation, and recovery procedures. | ||
Practitioner Guidance
What to verify: Confirm whether the SaaS product supports customer-held keys, provider-held keys, or a split model, and check whether the customer can actually rotate, revoke, and recover keys without opening a provider ticket. That operational detail matters more than marketing language about “customer control.”
Decision rule: If the data set is high-value, regulated, or subject to strict sovereignty expectations, favour customer-managed keys only when your team can also sustain the operational duties that come with them. If your team cannot own the lifecycle, provider-managed keys may be safer operationally, but they should be accepted with open acknowledgement of the trust trade-off.
What practitioners underestimate: Key ownership is not the same as data ownership. The control only delivers meaningful assurance when the organisation can prove who holds the effective revocation power, who records key events, and how quickly encryption can be invalidated after an incident.
Practitioner takeaway: Choose the model by asking who must be able to act when trust breaks, because the decisive issue is not encryption strength, it is who can govern the keys fast enough to contain exposure.
Related resources from NHI Mgmt Group
- What is the difference between keeping AI gateway analytics in customer-owned object storage and running a managed logging database in the provider cloud?
- What is the difference between a self-hosted private vault and a managed vault with customer-managed keys?
- What is the difference between attached provider keys and AI gateway-managed provider keys?
- When should organisations use customer-managed keys for application data instead of provider-managed encryption?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
