Who is accountable when a security platform manages encryption keys?

Why This Matters for Security Teams

When a security platform manages encryption keys, the accountability question is not about who operates the tooling, but who can prove control over the protected data. That distinction affects auditability, separation of duties, breach response, and legal responsibility. A platform may automate key generation, rotation, escrow, or recovery, but those functions do not transfer accountability away from the customer unless the contract and control design explicitly do so.

This is why security teams should treat key management as a governance problem as much as a technical one. The NIST Cybersecurity Framework 2.0 makes ownership, protective controls, and continuous oversight part of a broader risk program, not a vendor-only implementation detail. If the vendor can rotate keys without customer approval, restore keys without logged authorisation, or retain master access, the organisation may still be on the hook for confidentiality failures and compliance gaps.

In practice, many security teams discover the accountability gap only after a revocation request, incident investigation, or audit has already shown that no one can independently prove who controlled the keys at the critical moment.

How It Works in Practice

Operationally, accountability should be mapped across three layers: data ownership, key control, and service operation. The customer usually remains responsible for the data classification, acceptable use, retention, and authorisation model. The platform operator may manage the cryptographic service, but that service should be bound to customer-defined policy, logging, and revocation rights. Where a vendor provides a managed key service, the key question is whether the customer retains effective administrative authority or merely receives reporting after the fact.

Good practice is to document who approves creation, rotation, suspension, backup, recovery, and destruction of keys. Those responsibilities should be tested against the actual control path, not just the contract language. The controls in NIST SP 800-53 Rev 5 Security and Privacy Controls are useful here, especially where cryptographic safeguards, audit logging, access enforcement, and contingency handling need to be evidenced. Organisations should also verify that key events are visible in SIEM or equivalent monitoring so that emergency actions can be reconstructed during incident response.

• Define whether the customer, the vendor, or a third party has authority to create and destroy keys.
• Require customer-approved rotation and revocation workflows for high-value data.
• Ensure logs capture who requested, approved, executed, and verified each key action.
• Test recovery and revocation procedures before relying on them in production.
• Confirm export, backup, and escrow rules do not undermine separation of duties.

Where the platform abstracts keys behind a fully managed interface, the model must still preserve customer evidence, because accountability without verifiable control quickly becomes contractual fiction. These controls tend to break down when the vendor operates across multiple tenants with shared administrative paths and the customer cannot independently inspect or interrupt key operations.

Common Variations and Edge Cases

Tighter key governance often increases operational overhead, requiring organisations to balance resilience and assurance against faster automation and simpler recovery. That tradeoff becomes sharper in hybrid environments, during mergers, or where legal and regulatory obligations differ across jurisdictions.

Current guidance suggests there is no universal standard for every managed key model. Some services give the customer sole control of encryption keys, while others use customer-held wrapping keys, split control, or vendor-managed recovery. The accountability outcome changes with that design. If the vendor can access plaintext, bypass customer approval, or recover keys through internal support processes, the customer should assume reduced practical control even if the contract says otherwise. For sensitive workloads, organisations often require explicit evidence that they can revoke access, rotate keys, and obtain tamper-evident logs on demand.

Special cases include regulated sectors, shared responsibility in cloud deployments, and incident scenarios where business continuity depends on emergency recovery. In those environments, teams should clarify whether the security platform is acting as a processor, a sub-processor, or a delegated operator, and whether customer obligations under policy or regulation still apply. For governance alignment, the operating model should be reviewed alongside NIST Cybersecurity Framework 2.0 and the relevant control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls.

Where organisations rely on vendor-hosted key custody for convenience, the most common failure is assuming accountability has shifted with the tool, when in reality only the operational burden has moved.

Related resources from NHI Mgmt Group

• How should security teams handle access keys differently from encryption keys?
• Who is accountable when a consolidated cloud security platform still leaves identity risk unresolved?
• Who is accountable when privileged access is embedded into a broader security platform?
• How should security teams manage encryption keys in cloud environments?