Who is accountable for protecting data in a zero-knowledge system during an audit or breach?

Why This Matters for Security Teams

Zero-knowledge architecture changes who can decrypt data, but it does not change who is accountable for protecting it. During an audit or breach, the organisation still has to show that it chose the architecture knowingly, controlled key access, and enforced device and account protections. That obligation is consistent with NIST Cybersecurity Framework 2.0, which treats governance and access control as core security outcomes, not provider-only responsibilities.

For NHI-heavy environments, this distinction matters even more because compromise often begins with secrets, tokens, or service accounts rather than interactive users. NHIMG research shows how often identity weakness becomes the failure point, including the 2024 ESG Report: Managing Non-Human Identities, which found that 72% of organisations have experienced or suspect a non-human identity breach. The practical lesson is that zero-knowledge protects confidentiality, but it does not remove the need to prove control over identities, endpoints, recovery, and evidence retention. In practice, many security teams encounter this only after an audit request or incident disclosure has already exposed gaps in ownership and logging.

How It Works in Practice

In a zero-knowledge system, the provider may host encrypted content without holding the decryption material, but the customer still owns the security model around that content. The organisation must be able to demonstrate who can create, use, rotate, and revoke keys; which devices are trusted; and how access is monitored. That is why audit evidence typically spans identity governance, endpoint management, and incident response rather than encryption alone.

A mature control set usually includes user and admin separation, strong multi-factor authentication, device trust checks, recovery key protection, and documented break-glass procedures. For technical assurance, teams often map these controls to NIST SP 800-53 Rev 5 Security and Privacy Controls and then validate them against operational identity risk patterns described in Ultimate Guide to NHIs and the NHI Lifecycle Management Guide. Where data is accessed by automation, the same ownership principle applies to service accounts, API keys, and delegated workflows: someone in the organisation must be able to explain how those identities are provisioned, constrained, and retired.

• Keep decryption keys under customer-controlled governance, not informal team ownership.
• Log authentication, recovery, sharing, and administrative events in an evidence-ready format.
• Document device posture rules and remote wipe or revocation steps for lost endpoints.
• Test backup and recovery paths regularly, including key escrow and emergency access procedures.

These controls tend to break down when recovery depends on a single person, a single endpoint, or a manually managed key vault because breach response then becomes a custody problem instead of a security process.

Common Variations and Edge Cases

Tighter key custody often increases operational friction, requiring organisations to balance confidentiality against recoverability and support overhead. That tradeoff becomes sharper when legal, audit, and engineering teams all expect different evidence from the same incident.

One common edge case is shared responsibility confusion in SaaS environments. The provider may be unable to read customer data, but it can still supply logs, admin activity records, and service availability evidence. The customer remains responsible for proving that access policy, device control, and recovery procedures were enforced. Another edge case arises when employees use unmanaged personal devices: zero-knowledge does not protect against compromised endpoints, key theft, or session hijacking, so the organisation still needs conditional access and revocation capability.

Current guidance suggests treating zero-knowledge as a confidentiality control, not a governance exemption. That means auditors may still expect evidence for identity lifecycle management, incident handling, and privileged access review. NHIMG’s 52 NHI Breaches Analysis shows how frequently identity failures underpin broader compromise, which is why the same discipline should extend to automation, backup operators, and recovery accounts. For organisations with agentic workflows, the risk is even more pronounced because machine identities can move faster than human review cycles. The accountable party is the organisation that selected, configured, and operates the system, even when the provider cannot decrypt the payload.

Related resources from NHI Mgmt Group

• Who is accountable for protecting identity data when access is granted across partners and internal business units?
• Who is accountable when incomplete audit trails prevent teams from proving how sensitive data was used?
• Who should be accountable for fast vendor responses during a breach or zero-day?
• Who is accountable when an agentic system exposes control gaps during an audit?