They should verify whether the provider can ever reconstruct the full secret, not just whether access is restricted by policy. The evaluation should cover key fragmentation, operation flow, recovery paths, and failure states. If a complete credential can be reassembled anywhere in the service, the platform still depends on provider trust rather than structural control.
Why Security Teams Should Test the Trust Boundary, Not Just the UX
Zero-knowledge positioning only matters if the provider truly cannot reconstruct the secret at any point in the workflow. For security teams, the evaluation question is not whether a platform hides data from staff or encrypts it at rest, but whether the architecture prevents full secret recovery during generation, sharing, rotation, recovery, and support operations. That distinction is central to the OWASP Non-Human Identity Top 10, where trust boundaries and secret lifecycle controls are a recurring failure point.
This is especially relevant because secret sprawl is still the norm. NHIMG research on Guide to the Secret Sprawl Challenge shows how distributed secret handling makes it easy for teams to confuse policy controls with structural controls. If a service can rebuild a full credential for recovery, export, or collaboration, then the trust model still depends on provider restraint rather than cryptographic separation. In practice, many security teams discover that gap only after a support workflow, integration bug, or incident response event has already exposed it.
How It Works in Practice
A credible evaluation starts with asking how the platform fragments and reassembles secret material. Some platforms split a secret into shards, some wrap it with customer-controlled keys, and some keep only partial metadata while performing operations on the provider side. The key test is whether any operational path can produce the complete secret in one place, even briefly.
Security teams should review the full lifecycle, not just the steady state. That includes initial creation, policy-based access, device binding, approval flow, rotation, recovery, export, and revocation. A platform may be called zero-knowledge, but if support can reset an account by replaying a master recovery path, or if a backup service can decrypt the underlying material, the model is no longer structurally zero-knowledge.
- Confirm whether encryption keys are customer-held, provider-held, or jointly derived.
- Identify every process that can reconstruct a full secret, including backups and disaster recovery.
- Test whether administrators can access plaintext through operational tooling.
- Verify what happens when devices are lost, keys are rotated, or an account is recovered.
- Check whether logs, telemetry, or analytics ever carry secret fragments that can be recombined.
Current guidance suggests aligning this review with the CISA Zero Trust Maturity Model and with NHIMG’s analysis in Ultimate Guide to NHIs – Static vs Dynamic Secrets, because the same lifecycle questions apply to human and non-human credentials. The practical takeaway is simple: if the service ever needs plaintext to operate, support, or recover, the zero-knowledge claim is limited. These controls tend to break down when the product relies on centralized recovery or shared administrative access because those paths reintroduce reconstructability.
Common Variations and Edge Cases
Tighter secret isolation often increases operational friction, requiring organisations to balance recovery convenience against the loss of provider visibility. That tradeoff is real, and best practice is evolving. There is no universal standard for what qualifies as zero-knowledge in every product category, so teams need to define acceptable failure states before procurement.
One common edge case is “zero-knowledge for stored data” but not for active operations. Another is customer-managed encryption where the provider still handles decrypted material inside a controlled enclave or service tier. Those designs may reduce exposure, but they are not the same as a model where the provider can never reconstruct the full secret. Teams should also separate marketing claims from auditability: the SPIFFE ecosystem is useful for workload identity, but it does not by itself prove zero-knowledge secret handling.
For procurement, the strongest evaluation questions are operational, not brand-based. Ask who can trigger recovery, what can be exported, whether key shards are ever co-located, and whether the system can still function after a key loss without revealing plaintext. NHIMG’s 52 NHI Breaches Analysis is a reminder that hidden trust assumptions usually surface during incidents, not during sales demos. In highly regulated environments, even a partial reconstruction path may be unacceptable if it creates provider-side custody risk.
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 NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Secret rotation and recoverability are core to zero-knowledge trust claims. |
| NIST CSF 2.0 | PR.AC-1 | Access control must be evaluated against all secret lifecycle paths. |
| NIST AI RMF | Risk management should cover provider trust, recovery, and failure states. |
Verify no operational path can reconstruct plaintext, including recovery and support.
Related resources from NHI Mgmt Group
- How should security teams evaluate zero-knowledge claims in password managers?
- How should security teams govern SCIM in zero-knowledge platforms?
- How should security teams evaluate ITDR coverage across cloud and SaaS environments?
- How should security teams decide whether JIT access is safe for non-human identities?
