Start by proving that no single provider-controlled component can reconstruct the full key material. The test is architectural, not contractual: fragment placement, gateway boundary, and operational workflows must prevent recombination in normal use and under compromise. If the design cannot demonstrate that boundary, custody still depends on vendor trust.
What Zero-Knowledge Key Custody Proves in a SaaS Design
Zero-knowledge key custody is a claim about control boundaries, not a marketing label. Security teams should verify that no single provider-controlled component can ever reconstruct the full key material during normal operation, maintenance, or incident recovery. That means examining where fragments live, where they are combined, and whether any privileged workflow silently reassembles custody inside the vendor boundary.
The practical test is whether the SaaS service can still function without retaining a recomposable copy of the key. If the answer depends on an internal trust promise, the model is still vendor-custody with extra steps. That is why teams need to inspect architecture diagrams, runtime boundaries, and recovery procedures, not just contractual language. In practice, many failures appear only when a backup path, support workflow, or emergency access path is reviewed after deployment.
A useful external reference is the OWASP Non-Human Identity Top 10, which helps teams think about machine-accessed secrets, trust boundaries, and operational custody assumptions. For incident patterns, the Snowflake breach is a reminder that provider-adjacent access paths can still become the weak point when custody and exposure are not tightly bounded.
How Teams Test the Boundary in Practice
Teams usually need to test zero-knowledge custody at three layers: cryptographic separation, operational separation, and failure-path separation. Cryptographic separation asks whether the key is fragmented or wrapped so that one provider system cannot reconstruct it alone. Operational separation asks who can trigger key use, where approvals happen, and whether support or automation has a path to recombine fragments. Failure-path separation asks what happens during backup, restore, rotation, disaster recovery, and tenant migration.
- Check whether any provider-owned gateway, HSM, or orchestration service can see all fragments in sequence.
- Review whether administrative tooling can bypass the normal custody boundary during support or incident response.
- Validate that rotation and recovery do not create a hidden recombination step.
- Confirm that audit logs prove custody enforcement, not just successful application access.
Teams should treat “encrypted at rest” as insufficient unless the control also prevents recomposition in use. The real question is whether the SaaS provider can unilaterally unlock the protected material, even if only briefly and even if only through an internal service chain. The best designs make that impossible without the customer-controlled side participating.
That is also why zero-knowledge claims need proof under compromise conditions. If an insider, support operator, or compromised service can move from partial access to full key reconstruction, the custody boundary has failed even if the encryption algorithm is strong. These controls tend to break down when emergency recovery is designed for convenience first and customer verifiability second.
Common Variations and Edge Cases
Tighter custody usually increases operational friction, so teams have to balance verifiability against serviceability. Some SaaS models use customer-held keys, some use split control with customer approval, and some use opaque provider-managed wrapping that is not truly zero-knowledge. Current guidance suggests treating those as materially different risk profiles, even when the vendor uses similar encryption language.
Edge cases matter most when a provider also handles backup, analytics, search indexing, or delegated administration. Those workflows often create the exact recombination path that the design was supposed to eliminate. A second edge case appears in multi-tenant SaaS, where one tenant’s recovery logic can accidentally expand the provider’s effective control over many tenants if custody is centralized.
Security teams should also be careful with legal assurances that sound strong but cannot be validated technically. Contract terms can help with accountability, but they do not prove that the provider cannot reconstruct the key. The deciding issue is whether the implementation preserves customer-enforced separation when normal operations fail or when a privileged component is compromised.
Risk and Threat Considerations
Zero-knowledge custody reduces provider trust exposure, but it also shifts the assessment toward hidden recombination paths, privileged workflows, and recovery abuse. The main risk is false assurance, where the SaaS product appears customer-controlled while internal systems still hold enough material to recreate access.
Failure mechanism: The weakness usually appears when fragments, wrappers, or approvals are distributed in theory but rejoin in practice through support tools, backup jobs, orchestration services, or emergency admin paths. A compromise of any component in that chain can collapse the intended boundary.
Impact: If custody can be reconstructed by the provider, the customer loses the core benefit of zero-knowledge design, which is reduced vendor trust and reduced blast radius. That can expose sensitive data, enable broader administrative access, and make compromise or insider misuse much harder to detect or prove.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Zero-knowledge custody hinges on whether key material can be recombined or exposed. |
| Recommendation — Map every custody path and prevent any provider-controlled component from reconstructing full key material. | ||
| CIS Controls v8 | 3 — Data Protection | Custody design is a data-protection control over sensitive key material. |
| Recommendation — Classify and protect key material so operational workflows cannot expose or recombine it. | ||
| NIST Zero Trust (SP 800-207) | SC-7 — Boundary Protection | The question is fundamentally about enforcing a hard trust boundary around key use. |
| Recommendation — Enforce a boundary that blocks unilateral provider access to customer-controlled key material. | ||
Practitioner Guidance
What to verify: Ask for a custody proof, not a policy statement. The proof should show where full key material can and cannot exist, including backup, restore, rotation, and support workflows.
Decision rule: If the vendor cannot demonstrate that no provider-controlled component can recombine the key in ordinary or failure conditions, treat the custody model as vendor-dependent rather than zero-knowledge.
What good looks like: The control boundary is visible in architecture, enforced in operations, and testable through audit evidence. Teams can trace every path that touches key material and confirm that none of them independently complete reconstruction.
Practitioner takeaway: Zero-knowledge custody is only real when the architecture removes provider unilateral recovery, because the strongest encryption claim is still weak if operational shortcuts can rebuild the key.
Related resources from NHI Mgmt Group
- How should security teams evaluate zero-knowledge claims in password managers?
- How should security teams evaluate zero-knowledge secrets platforms?
- How should teams secure non-human identities across cloud and SaaS?
- How should security teams decide whether JIT access is safe for non-human identities?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
