Vendor-Managed Encryption Keys

Encryption is the control most organizations cite first when asked how they protect data shared with vendors. It is also one of the most misunderstood. The question is not only whether data is encrypted , in most cloud environments it is, by default, using the cloud provider's managed keys. The question is who controls the encryption keys, under what conditions they can be accessed, and what happens to the protection of your data if the vendor is compromised, compelled, or simply makes the wrong configuration decision. Encryption without key governance is a lock with no owner. The data is protected , until the keys are not.

What is Encryption Key Management, Really?

Encryption key management is the discipline of controlling who can generate, access, use, rotate, and revoke the cryptographic keys that protect data. Encryption without key management is like locking a safe and leaving the combination written on top of it , the mechanism is sound but the control is absent. In cloud environments, this distinction plays out across three fundamentally different key management models, each with materially different security and governance implications for vendor relationships.

The first model is provider-managed keys , the default for most cloud storage and database services. The cloud provider generates and controls the keys, handles rotation automatically, and uses them transparently to encrypt and decrypt data as it is read and written. This model is convenient and provides protection against physical media theft, but it does not protect against threats that operate at the application layer , including a vendor with legitimate access credentials, a compromised cloud account, or a legal compulsion order served to the cloud provider. The data is encrypted, but anyone with authorized access to the service can read it, and the provider can technically access it under certain conditions.

The second model is customer-managed keys , where the customer generates and controls the keys, typically through a key management service like AWS KMS, Azure Key Vault, or GCP Cloud KMS, and the cloud provider uses those keys to perform encryption operations on the customer's behalf. This model gives the customer meaningful additional control: they can define who is authorized to use the key, audit every cryptographic operation, rotate keys on their own schedule, and , critically , revoke a key to render data inaccessible even to parties who have storage-level access. For vendor relationships, customer-managed keys enable a specific and powerful control: if a vendor relationship ends or a compromise is suspected, revoking the key effectively destroys access to the data without requiring deletion of the underlying objects.

The third model is bring-your-own-key or hold-your-own-key arrangements, where the customer manages keys entirely outside the cloud provider's infrastructure , using dedicated hardware security modules or external key management services. This provides the highest level of customer control and the strongest protection against cloud provider access, but at significant operational complexity. For most vendor relationships, customer-managed keys through the cloud provider's native KMS service represents the appropriate balance of control and manageability.

Encryption key risk in vendor relationships concentrates around four failure patterns:

• Provider-managed keys as the default assumption , organizations accepting the default encryption model without considering whether it provides adequate separation between their data and the vendor's access
• Key access scope misaligned with data access scope , a vendor granted key usage permissions that allow them to decrypt more data than their integration actually requires
• No key revocation plan , encryption keys associated with vendor access that have no defined revocation trigger, meaning key access persists indefinitely alongside or beyond the vendor relationship
• Key audit logging absent , cryptographic operations using vendor-associated keys not being logged or reviewed, making it impossible to detect unauthorized decryption activity

Why this matters

In the context of third-party risk, encryption key governance determines whether encryption is a meaningful control or a compliance checkbox. When a vendor has access to data encrypted with keys they can also use , which is the case in most default configurations , the encryption protects against a narrow class of threats while providing no protection against the vendor themselves exceeding their authorized access, being compromised, or retaining access beyond the agreed period. The encryption is real. The protection it provides against vendor-related risk is limited.

Customer-managed keys change this dynamic meaningfully. When a customer controls the keys that encrypt data a vendor is processing, they retain a final-layer control that operates independently of the vendor's own security practices. A vendor breach that compromises the vendor's access credentials does not automatically compromise the encrypted data if those credentials do not include key usage permissions. A vendor relationship that ends results in key access revocation that is effective immediately , not dependent on the vendor deleting their cached copies of the data. The customer retains a technical enforcement mechanism for the data protection obligations they have accepted.

From a regulatory standpoint, the ability to demonstrate control over encryption keys is increasingly relevant in data sovereignty discussions, cross-border data transfer frameworks, and sector-specific regulations. GDPR's requirements around technical and organizational measures for data protection, PCI-DSS's encryption key management controls, and HIPAA's addressable encryption implementation specifications all create a framework within which key governance is not optional , it is the mechanism through which encryption becomes a meaningful protective measure rather than a nominal one.

Where most teams get this wrong

The most pervasive failure is treating encryption as a binary , data is either encrypted or it is not , without examining who controls the keys that make the encryption meaningful. An organization that can confirm all vendor-processed data is encrypted at rest has answered a necessary but not sufficient question. The follow-up question , who controls the keys, and what can they do with them , is what determines whether that encryption provides any protection against vendor-related threats.

The second failure is not including key management requirements in vendor contracts and data processing agreements. Most data handling agreements specify that data must be encrypted at rest. Few specify the key management model, the key access scope, the key rotation frequency, or the revocation obligations at contract termination. This leaves the entire key governance dimension outside the contractual framework , meaning there is no enforceable standard against which to assess the vendor's practices.

• Accepting default provider-managed keys without assessing whether that model provides adequate protection for the sensitivity of the data being processed
• No audit logging of key usage , cryptographic operations by the vendor or their systems generating no audit trail
• Key access not scoped to data access , a vendor with key permissions that span the entire account rather than the specific data set they are authorized to process
• No revocation trigger defined , key access continues indefinitely because nobody has defined the condition that would cause it to be revoked
• Vendor contracts that require encryption without specifying the key management model , leaving a critical governance gap undefined

What good looks like

In mature environments, encryption key governance for vendor data is as deliberately designed as the access controls governing who can reach the data in the first place. The two controls work together: access controls determine whether the vendor can reach the encrypted data, and key controls determine whether they can read it. Both dimensions are managed, both are audited, and both have defined lifecycle endpoints tied to the vendor relationship.

• Customer-managed keys used for all storage containing data processed by high-risk vendors , giving the customer control over key usage, rotation, and revocation independent of the vendor
• Key access scoped specifically to the data the vendor is authorized to process , not an account-wide key usage permission
• Key usage audit logging enabled and reviewed , every decrypt operation by a vendor-associated identity logged and anomalous patterns alerted on
• Key rotation on a defined schedule , typically annually at minimum, with rotation triggered by any suspected compromise
• Key revocation as a defined offboarding step , contract termination triggers key access revocation as an explicit, confirmed action rather than an assumed consequence
• Data processing agreements that specify the key management model , not just 'encrypted at rest' but the specific model, key ownership, and governance obligations

Tooling

Key management tooling is mature and largely native to major cloud platforms. The gap for most organizations is not tool availability , it is applying key management discipline to vendor data specifically rather than treating it as an infrastructure concern separate from third-party risk governance.

Cloud Key Management Services , AWS KMS, Azure Key Vault, GCP Cloud KMS

These are the foundational platforms for customer-managed key implementations in major cloud environments. They enable key creation, access policy definition, usage logging, rotation scheduling, and revocation. For TPRM practitioners, the relevant capability is the ability to define precisely which identities , including vendor service accounts and IAM roles , are authorized to use a given key, and to audit every usage event. AWS KMS, for example, logs every cryptographic operation to CloudTrail, providing a complete audit trail of who decrypted what and when. That audit trail is what makes encryption a meaningful control rather than a nominal one.

Hardware Security Modules , AWS CloudHSM, Azure Dedicated HSM, Thales

For organizations with the highest key governance requirements , regulated industries, cross-border data sovereignty obligations, or sensitive data requiring demonstrable key exclusivity , dedicated hardware security modules provide key management with physical isolation from the cloud provider's infrastructure. HSMs are operationally complex and expensive relative to KMS services, but for specific high-risk vendor relationships involving highly sensitive regulated data, they provide the strongest available evidence of key control exclusivity.

Secrets and Key Governance , HashiCorp Vault, CyberArk Conjur

For organizations managing encryption keys alongside other secrets in a unified governance framework, platforms like HashiCorp Vault provide a single control plane for key lifecycle management, access policy enforcement, and audit logging. Vault's transit secrets engine provides encryption-as-a-service capabilities that abstract key material away from applications entirely , the vendor's workload requests encryption or decryption operations through the Vault API without ever having direct access to the underlying key material.

Key Usage Monitoring , AWS CloudTrail, Azure Monitor, Datadog

Monitoring key usage requires integrating key management audit logs with the broader security monitoring infrastructure. CloudTrail captures every AWS KMS API call , including every encrypt and decrypt operation, the identity that requested it, and the key that was used. Configuring alerts on high-volume decrypt operations, decrypt operations outside business hours, or decrypt operations by identities outside the expected vendor scope turns key audit logs from a forensic resource into an active detection mechanism.

Governance challenges

The governance challenge with vendor encryption key management is that it sits at the boundary between security engineering and third-party risk governance , a boundary that most organizations have not clearly defined. Security engineers implement key management as an infrastructure control. TPRM practitioners assess vendor security as an organizational control. Neither team is typically asking whether the key management implementation for vendor-processed data reflects the risk governance decisions that the TPRM program has made about that vendor relationship. The result is key management that is technically sound but not aligned with the vendor risk framework.

Bridging this gap requires incorporating key governance questions into vendor risk assessments and data processing agreement reviews , not as a technical deep dive, but as a governance question: who controls the keys protecting this data, can that access be revoked, and is the usage auditable? Those three questions, asked consistently for every high-risk vendor relationship, will surface the majority of key governance gaps without requiring TPRM practitioners to become encryption engineers.

• Add key management model to data processing agreement requirements , specify customer-managed keys as the standard for high-risk vendor relationships
• Include key revocation in vendor offboarding checklists as an explicit, confirmable step alongside application access revocation
• Review key usage logs for high-risk vendors annually as part of the vendor reassessment cycle , anomalous decryption patterns are a risk signal worth examining
• Tier key governance requirements by data sensitivity , not every vendor relationship warrants customer-managed keys, but vendors processing regulated, sensitive, or high-volume data should meet a defined key governance standard
• Confirm key rotation status during vendor assessments , ask when vendor-associated keys were last rotated and whether rotation is automated

If you are a small team

Start by identifying which vendors process your most sensitive data and what key management model is in place for that data today. For most organizations, the answer will be provider-managed keys by default , not because someone decided that was appropriate, but because nobody decided anything. That gap is addressable. For your highest-risk vendor relationships, enable customer-managed keys through your cloud provider's native KMS service and scope key usage permissions to the specific vendor identity. Then enable key usage logging. Those two steps move encryption from a nominal control to a meaningful one for the relationships that matter most.

• Enable AWS KMS, Azure Key Vault, or GCP Cloud KMS customer-managed keys for storage containing your highest-sensitivity vendor-processed data
• Scope key usage permissions to the specific vendor IAM role or service principal , not an account-wide permission
• Enable key usage logging and set a calendar reminder to review it quarterly
• Add three questions to your data processing agreement template: what is the key management model, who controls key rotation, and what is the key revocation process at contract termination

What to require

Ask directly:

"What encryption key management model do you use for storage containing our data , provider-managed keys, customer-managed keys, or a dedicated key management service? Who controls key rotation and revocation?"

"If our contract were terminated today, what is the specific process by which your access to encryption keys protecting our data would be revoked, and what is the expected timeframe?"

"Is key usage audited , specifically, are decrypt operations against storage containing our data logged, and are those logs available to us on request?"

Expect as evidence

• A clear description of the key management model , not 'we use encryption' but the specific model and who controls the keys
• A defined key revocation process tied to contract termination with a specific timeframe
• Key usage audit log availability , evidence that decryption operations are logged and reviewable
• Key rotation policy with a defined schedule and evidence of most recent rotation

A vendor who cannot describe their key management model beyond 'we use AES-256 encryption' has answered the technology question and ignored the governance question. The technology is necessary. The governance is what makes it protective.

How to evidence it

Encryption key governance is specifically addressed in PCI-DSS (Requirement 3), HIPAA's encryption implementation specifications, and GDPR's technical and organizational measures standard. For regulated organizations, demonstrating due diligence requires evidence that encryption key management has been assessed for vendor relationships, not just confirmed as present.

• Vendor assessment records documenting the key management model for vendors processing regulated or sensitive data
• Data processing agreements specifying key management requirements, rotation obligations, and revocation timelines
• Key usage audit log records demonstrating active monitoring of cryptographic operations by vendor-associated identities
• Evidence of customer-managed key implementation for highest-risk vendor relationships
• Key revocation records confirming encryption access was terminated alongside other offboarding steps for departed vendors

Key Takeaway

Encryption is not a destination , it is a mechanism. Its value as a control depends entirely on the governance around the keys that make it work. For vendor relationships, that governance is the difference between encryption that protects your data from vendor-related threats and encryption that protects your data from someone stealing the hard drives out of the data center. Both are real protections. Only one is relevant to the actual risk profile of most vendor relationships. Who controls the keys controls the data. That question belongs in every vendor risk assessment that involves data processing , not as a technical footnote, but as a governance priority.

Encryption is the control most organizations cite first when asked how they protect data shared with vendors. It is also one of the most misunderstood. The question is not only whether data is encrypted , in most cloud environments it is, by default, using the cloud provider's managed keys. The question is who controls the encryption keys, under what conditions they can be accessed, and what happens to the protection of your data if the vendor is compromised, compelled, or simply makes the wrong configuration decision.

#TPRM #DoNoBeLarry #VerisqAi #LiveThreat #SupplyChainRisk # #SupplyChainSoftwareRisk #Cybersecurity #TPRM #VendorRisk #ThreatIntel

More on Security

• API Identity Misuse
• Access Certification Effectiveness
• Access Policy Misconfigurations