TL;DR: Key material fragmented across regions and cloud providers so no single entity can reconstruct it is the core of Akeyless’s Distributed Fragments Cryptography model, according to Akeyless. The real issue is that secrecy, sovereignty, and operational simplicity now have to be governed as one identity and key-management problem, not separate ones.
At a glance
What this is: This is an analysis of zero-knowledge secrets management and the claim that fragmented key custody can remove vendor trust while preserving SaaS operations.
Why it matters: It matters because IAM, PAM, and NHI teams need to decide whether cryptographic separation really changes custody, sovereignty, and lifecycle control for keys, certificates, and secrets.
By the numbers:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
- Only 44% of organisations are currently using a dedicated secrets management system.
👉 Read Akeyless's analysis of distributed fragments cryptography for regulated key custody
Context
Zero-knowledge secrets management is about controlling cryptographic material without handing complete custody to the service provider. That matters for regulated enterprises because key ownership, residency, and access transparency are now treated as governance requirements, not implementation details, and the first question is whether the architecture actually removes provider visibility or only relocates trust.
Akeyless positions Distributed Fragments Cryptography as a way to keep encryption keys split across environments so no single entity can reconstruct them. For identity and access teams, the practical issue is whether a control model built around fragmented key custody changes lifecycle management, offboarding, and privileged access boundaries for secrets, certificates, and encryption keys.
This is a common pressure point in modern secrets programmes: teams want SaaS simplicity, but they also need evidence that control over sensitive material remains with the customer. That tension is especially familiar to organisations balancing cloud adoption with sovereignty, auditability, and strict compliance expectations.
Key questions
Q: How do security teams evaluate zero-knowledge key custody in SaaS models?
A: 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.
Q: Why do fragmented key architectures matter for regulated enterprises?
A: They reduce concentration risk by preventing any one system from holding complete cryptographic material, which supports sovereignty and audit expectations. That matters when the organisation must show that the provider cannot inspect or reconstruct customer keys, certificates, or secrets. The control value is strongest when custody proof is more defensible than policy language.
Q: What breaks when secret management is treated as storage only?
A: Storage-only thinking leaves replication, runtime delivery, and offboarding outside governance. Secrets can still be copied into pipelines, logs, and workloads even when a vault exists, so the real failure is lifecycle blind spots. Organisations need discovery, ownership, and revocation controls around every place a secret can be materialised or reused.
Q: What is the difference between zero-knowledge custody and ordinary vault encryption?
A: Zero-knowledge custody means the provider cannot reconstruct the full secret at any point, while ordinary vault encryption may still leave the operator or platform with the ability to access complete material. The difference is about who can assemble the key, not just who stores it. That distinction matters most in regulated environments and shared SaaS operations.
Technical breakdown
How distributed key fragments change custody models
Distributed Fragments Cryptography splits a key into fragments and stores them across separate regions or cloud providers so no single location holds the complete secret. Cryptographic operations use the fragments without recombining them into a reusable full key, which changes the custody model from central storage to distributed proof of control. That is materially different from conventional vault design, where one system can often access the whole credential set. The security value comes from reducing the blast radius of any single compromise, not from pretending the keys no longer exist.
Practical implication: Map every high-value secret to a custody model that proves who can reconstruct it and where the fragments live.
Why zero-knowledge architecture depends on the gateway boundary
Zero-knowledge claims only hold if the vendor never gains a path to reconstruct the complete key. In this model, the customer environment retains one fragment and the gateway is stateless, outbound-only, and acts as the local trust boundary. That means the real control question is not just encryption strength but whether the gateway, fragment placement, and operational workflows prevent recombination at any point in the service chain. If recombination can occur, the architecture is no longer zero knowledge in the practical sense that regulated buyers care about.
Practical implication: Treat gateway placement and fragment separation as the control boundary for audit and design reviews.
What continuous fragment refresh means for secret lifecycle risk
Continuous refresh changes the threat model from static key exposure to ongoing cryptographic churn. Instead of relying only on periodic rotation, the fragment values are refreshed while preserving the underlying key integrity, which is intended to reduce insider risk and limit the usefulness of stolen material. For identity governance teams, the important distinction is that refresh does not remove lifecycle obligations. Ownership, revocation, offboarding, and access scoping still have to be defined for the identities and systems that can request protected operations.
Practical implication: Align key lifecycle governance with the systems that request protected actions, not just with the stored material itself.
NHI Mgmt Group analysis
Zero-knowledge key ownership is a governance model, not a marketing claim. The article’s central proposition is that complete control over secrets and keys can be preserved even in a SaaS operating model if no single party can reconstruct the full cryptographic material. That matters because identity programmes often equate custody with storage, when the real governance question is who can assemble, use, and revoke the material across its lifecycle. Practitioners should treat custody proof as the deciding requirement.
Secret custody and secret access are no longer the same control problem. Fragmented key storage changes where risk concentrates, but it does not eliminate the need to govern the identities and workflows that invoke protected operations. For NHI and PAM teams, that means the control boundary shifts from one vault to a distributed trust model with stricter rules around request paths, gateway exposure, and operational accountability. The implication is that access governance must follow the operation, not just the repository.
Fragmentation reduces concentration risk, but it also raises the standard for evidentiary control. Regulated buyers do not just need assurance that secrets are encrypted. They need evidence that no provider, administrator, or compromised platform path can reconstruct the full asset, and that ownership remains defensible under audit. That is why cryptographic separation must be evaluated alongside lifecycle governance and sovereignty requirements.
For identity teams, this pattern sharpens the case for secrets as governed identities. Secrets, certificates, and encryption keys behave like non-human identities when they can invoke privileged operations and outlive the human actors around them. The operational conclusion is that custody, ownership, and revocation need the same rigor applied to high-risk NHI estates, especially in regulated environments.
Control without compromise only works when the failure mode is precisely bounded. The article suggests a model where the vendor cannot view or reconstruct the customer’s material, but that assurance depends on architecture, not trust statements. Practitioners should use this as a reminder that cryptographic proof is stronger than policy language, yet still only as strong as the boundary conditions that preserve it.
From our research:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 62% of all secrets are duplicated and stored in multiple locations, according to The 2025 State of NHIs and Secrets in Cybersecurity, which shows how redundancy amplifies exposure when lifecycle control is weak.
- Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs explains how ownership, rotation, and offboarding should be structured for machine identities and secrets.
What this signals
Ephemeral custody models are forcing identity teams to separate storage design from governance design. When secrets are fragmented and recombined only for approved operations, the programme question becomes who owns revocation, not just where the material lives. That is the same pattern that shows up in NHI lifecycle failures, where control is lost when offboarding and reuse are not tied to accountable ownership.
With 44% of NHI tokens exposed in the wild, per The 2025 State of NHIs and Secrets in Cybersecurity, teams cannot rely on storage alone to prevent misuse. The better test is whether the operational path to a secret is narrowed enough that exposure does not automatically become compromise. That is why fragment custody, approval boundaries, and access scope have to be evaluated together.
Zero-knowledge should be treated as a control objective, not a procurement label. If the architecture cannot prove that no full secret exists in the provider domain, the programme still depends on trust. OWASP Non-Human Identity Top 10 remains the right lens for understanding how secret exposure, overuse, and lifecycle drift compound each other.
For practitioners
- Validate custody proof, not just vendor assurances Require evidence that no single service path can reconstruct complete keys, and test the fragment boundary as part of design review and audit evidence.
- Map secrets to operational owners and revocation paths Assign explicit ownership for keys, certificates, and secrets, then define who can request, approve, and revoke protected operations across the full lifecycle.
- Review gateway placement and outbound-only trust boundaries Confirm that the customer-controlled fragment remains in your environment and that inbound access paths are not introduced through supporting infrastructure.
- Treat lifecycle governance as separate from storage design Document how offboarding, rotation, and emergency revocation work for identities that can use protected cryptographic material, even when storage is zero knowledge.
Key takeaways
- Zero-knowledge secrets management changes the custody model, but only if no single provider-controlled path can reconstruct the full key.
- The main governance question is not where secrets are stored, but who can assemble, request, and revoke them across the lifecycle.
- Regulated enterprises should treat cryptographic separation as one control in a wider NHI and privileged access programme, not as a substitute for lifecycle governance.
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 surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Insecure Authentication Methods | The article focuses on secret custody, reconstruction risk, and key handling across the lifecycle. |
| Recommendation — Map key custody paths to NHI-03 and verify that no complete secret is reconstructable in provider workflows. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorisations | The model depends on tightly governed access to cryptographic operations and fragments. |
| Recommendation — Apply PR.AC-4 to restrict who can request and approve use of protected cryptographic material. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Fragment custody still requires least-privilege control over operational and administrative access. |
| Recommendation — Use AC-6 to minimise who can interact with fragments, gateways, and key-use workflows. | ||
| NIST Zero Trust (SP 800-207) | 4.2 — Explicit Verification | Zero-knowledge claims rely on explicit verification of custody boundaries and trust assumptions. |
| Recommendation — Apply explicit verification to prove the customer environment retains control over key reconstruction conditions. | ||
| ISO/IEC 27001:2022 | A.8.2 — Privileged Access Rights | Privileged access to cryptographic operations must remain tightly bounded in a regulated deployment. |
| Recommendation — Govern privileged access to cryptographic workflows under A.8.2 and review who can trigger sensitive operations. | ||
Key terms
- Zero-Knowledge Custody: A custody model in which the provider cannot reconstruct the customer’s complete secret, key, or certificate material. The control objective is not only encryption at rest but also preventing any operational path from assembling the full asset inside the vendor domain.
- Distributed Fragments Cryptography: Distributed Fragments Cryptography is a method of splitting cryptographic material into fragments so no single system holds the complete key. The security value comes from keeping fragments separated during operations, reducing the chance that an attacker or provider can recover the full secret from one place.
- Gateway Boundary: The gateway boundary is the control point where model calls, tool access, and policy enforcement intersect. When used well, it becomes the place to apply approvals, logging, and scope limits so the agent can act only within its intended runtime privileges.
- Secret lifecycle governance: Secret lifecycle governance is the set of controls that manage creation, distribution, rotation, expiry, and revocation for credentials. It treats secrets as living access artefacts rather than static text. That approach is essential when the same credential may travel through code, email, and automation.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- Implementation specifics for Distributed Fragments Cryptography across regulated environments and hybrid deployments
- The platform's claims about zero-knowledge custody and how the gateway participates in protected operations
- Compliance positioning for FIPS, SOC 2, ISO 27001, and GDPR in multi-cloud use cases
- How the vendor describes automated rotation and just-in-time access in the context of DFC
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on September 14, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
