ZKS vs. Zero Trust Architecture
How Zero-Knowledge Sovereignty Complements NIST SP 800-207
Version: 1.2 Status: Position Paper Audience: Security Architects, CISOs, Compliance Officers
Executive Summary
Zero Trust Architecture (ZTA) and Zero-Knowledge Sovereignty (ZKS) address different but complementary security concerns:
| Framework | Primary Question | Control Mechanism |
|---|---|---|
| Zero Trust | "Who is allowed to access this resource?" | Policy & Identity |
| ZKS | "Where do the cryptographic components exist?" | Topology & Architecture |
Key insight: Zero Trust controls access through policy enforcement. ZKS controls topology - ensuring data and key components never coexist under external control. A system can be fully Zero Trust compliant while completely failing ZKS. The frameworks are complementary: Zero Trust protects against unauthorized access; ZKS makes the question of provider trust architecturally irrelevant.
The Fundamental Distinction
Zero Trust: Policy-Based Access Control
Zero Trust operates on the principle "never trust, always verify." Every access request is authenticated, authorized, and continuously validated. But critically, Zero Trust still assumes someone can access the resource - it just controls who.
ZKS: Topology-Based Component Separation
ZKS operates on a different principle: "Make trust irrelevant by separating components." Rather than controlling who can access data, ZKS ensures that the components required for decryption never coexist under external control. The question isn't "do we trust the provider?" - it's "does the topology make that question moot?"
| Aspect | Zero Trust | ZKS |
|---|---|---|
| Core Question | "Who can access?" | "Where do components exist?" |
| Control Mechanism | Policy enforcement | Topological separation |
| Trust Model | Verify every request | Make trust irrelevant |
| Failure Mode | Policy failure → data exposed | Policy failure → data still undecryptable |
| Privacy Type | Behavioral (enforcement-based) | Structural (architectural) |
Three Types of Privacy
Understanding ZKS requires distinguishing three fundamentally different approaches to privacy:
1. Behavioral Privacy (Weakest)
"The provider promises not to access your data."
- Based on policy, contracts, Data Processing Agreements (DPAs)
- Depends on provider behavior
- Verification: Trust their word, audit compliance
- Failure: Policy violation, insider threat, acquisition
Example: "Our employees sign NDAs and cannot access customer data."
2. Capability Privacy (Stronger)
"The provider cannot decrypt your data."
- Based on cryptographic controls
- Depends on current cryptographic strength
- Verification: Analyze cryptographic protocols
- Failure: Cryptographic advances, implementation flaws, coercion to attempt decryption
Example: "We use AES-256 encryption; decryption is mathematically infeasible."
3. Structural Privacy (Strongest - ZKS)
"The provider never holds the components that would make decryption a question."
- Based on architectural topology
- Depends on where components physically/logically exist
- Verification: Test the architecture - the declared topology is verified through the standard's conformance tests (ZKS-1.0 Sections 7–8: capability, observability, and revocation tests), not by inspection of a diagram alone
- Failure: Topology compromise - most plausibly via the software update channel, which is why ZKS-1.0 Section 5.3.1 mandates Binary Transparency for the update mechanism
Example: "Data Plane and Key Plane are operated by different parties; no single party holds both."
The ZKS Innovation: Privacy becomes a property of the topology, not of provider behavior or cryptographic difficulty. Structural privacy is auditable like "load-bearing capacity" in a building: the architecture diagram states the claim, and the standard's conformance tests inspect it. (Per ZKS-1.0 §7.5.1, diagrams alone are supporting evidence; the tests are what make the claim falsifiable.)
Zero Trust Architecture Overview
Core Principles (NIST SP 800-207)
- No implicit trust - All access requests are authenticated and authorized
- Least privilege - Users receive minimum necessary access
- Assume breach - Design as if the network is already compromised
- Continuous verification - Trust is reassessed continuously
What Zero Trust Controls
| Domain | Zero Trust Approach |
|---|---|
| Network | Micro-segmentation, no trusted zones |
| Identity | Strong authentication, continuous verification |
| Devices | Device health verification, posture assessment |
| Applications | Application-level access control |
| Data | Classification, access logging, policy enforcement |
What Zero Trust Does NOT Control
Zero Trust focuses on who can reach resources. It does not inherently address:
- Topology - Where cryptographic components physically exist
- Coexistence - Whether data and keys reside under the same control
- Structural separation - Whether planes are architecturally isolated
- Compulsion resistance - What happens when the controller must comply
A provider with perfect Zero Trust implementation can still:
- Hold both ciphertext and key material
- Be compelled to combine them under legal pressure
- Accumulate components for future decryption ("harvest now, decrypt later")
Zero-Knowledge Sovereignty Overview
Core Principles (ZKS-1.0-RC2)
- Topological separation - Data and key components never coexist under external control
- Structural privacy - Privacy is an architectural property, not a policy
- Trust irrelevance - The architecture makes provider trustworthiness moot
- Possession as the audit lens - Asking what a party holds is the practical way to audit the architecture; the standard's normative criterion remains capability (ZKS-1.0 §2.1: access, derive, intercept, revoke), which also catches providers that hold nothing but can obtain or induce what they need
What ZKS Controls
| Domain | ZKS Approach |
|---|---|
| Topology | Strict separation of Data Plane and Key Plane |
| Component location | No coexistence under single external control |
| Structural privacy | Privacy verifiable against the architecture via conformance tests |
| Compulsion resistance | No decryption-enabling material to compel; metadata and wrapped artifacts remain producible |
The Topological Requirement
ZKS doesn't just ask "can they decrypt?" - it asks "do they hold the components that would make that question relevant?"
Trust Replacement vs. Trust Verification
The Zero Trust Approach to Trust
Zero Trust doesn't eliminate trust - it continuously verifies trust. Every access request is a trust decision. The system constantly asks: "Should I trust this identity, this device, this request?"
This is valuable, but it still operates within a trust paradigm. Someone, somewhere, is trusted to make the access decision.
The ZKS Approach to Trust
ZKS makes trust architecturally irrelevant. By ensuring components never coexist under external control, there's nothing to trust the provider with.
| Aspect | Zero Trust | ZKS |
|---|---|---|
| Trust status | Continuously verified | Architecturally irrelevant |
| Provider role | Trusted to enforce policy | Has nothing to be trusted with |
| Failure requires | Policy/enforcement failure | Topology compromise (e.g., a malicious client update - the residual channel ZKS-1.0 §5.3.1 closes with mandatory Binary Transparency) |
| Audit question | "Are policies being followed?" | "Are components separated?" |
The Difference:
- Zero Trust: "We verify the provider is trustworthy"
- ZKS: "The architecture makes provider trustworthiness irrelevant"
This is why ZKS is immune to arguments like:
- "But they're ISO 27001 certified!" (Certification verifies policy, not topology)
- “They have a Data Processing Agreement (DPA)!” (A DPA is a contractual, behavioral control, not a structural or architectural guarantee.)
- "Their admins can't access data!" (Policy can fail; a deployed topology cannot be violated by a policy decision alone. The one vendor decision that can change the topology is shipping a malicious client update - which is why ZKS-1.0 §5.3.1 makes Binary Transparency mandatory rather than trusting the update channel)
The Subpoena Test: Possession vs. Capability
The "Subpoena Test" is often framed as: "Can the provider comply with a decryption demand?"
ZKS reframes the practical audit as a Possession Test: "Does the provider hold the components that would make compliance a question?"
Framing note: Possession analysis is the practical audit method - it is fast, observable, and hard to argue with. The standard's normative criterion is capability (ZKS-1.0 §2.1): a provider that holds nothing but can derive keys through a recovery channel, or induce the client to exfiltrate them, fails ZKS even though it passes a pure possession check. Possession is how you audit; capability is what the standard requires.
Traditional Framing (Capability)
Court: "Decrypt this user's data."
Provider analysis: Do we have the ciphertext? → Yes Do we have the keys? → Yes (wrapped) Can we unwrap the keys? → Currently no Result: "We cannot comply" (but components coexist)
Problem:
- Court may order provider to engineer a solution
- Future cryptographic advances may enable unwrapping
- Coercion can compel attempts
- "Cannot" becomes "not yet" or "not easily"
ZKS Framing (Possession/Topology)
Court: "Decrypt this user's data."
Provider analysis: Do we hold ciphertext? → Yes/No Do we hold key material? → Yes/No Do both coexist under our control? → NO Result: "We possess only [one component]; we cannot comply because we do not hold the other component."
Advantage:
- No amount of engineering can produce missing components
- Coercion cannot compel production of non-possessed items
- The question is closed, not deferred
Important Asymmetry: The two single-component scenarios are NOT equal:
| Scenario | Future Risk | Why |
|---|---|---|
| Keys only (no ciphertext) | Minimal | The provider holds no ciphertext to attack; residual risk arises only if the wrapped-key holder and a ciphertext holder are later joined (compromise or collusion), which ZKS addresses through metadata non-correlation (A7) and split topology |
| Ciphertext only (no keys) | Medium | Ciphertext can still be attacked; "harvest now, decrypt later" remains viable |
This asymmetry matters: a provider holding only wrapped keys (like a key delivery service) has a stronger position than one holding only ciphertext. Note that in both single-component scenarios the provider still holds operational metadata, which carries its own privacy obligations.
The Topology Defense
| Provider State | Subpoena Response | Future Risk | Strength |
|---|---|---|---|
| Holds ciphertext + keys | "We can't unwrap" | High (coexistence) | Weakest (non-compliant) |
| Holds ciphertext only | "We don't possess keys" | Medium (cryptographic advances) | Compliant |
| Holds keys only | "We don't possess ciphertext" | Minimal (no ciphertext to attack; residual joining risk addressed by A7/split topology) | Strong (PSDA) |
| Holds neither | "We possess no content or key material" | Minimal (metadata exposure remains) | Strongest |
The strongest ZKS answer under compulsion is a possession statement about content and key material - "we don't have it" is more durable than "we can't use it." In every row the provider can still be compelled to produce what it does hold: wrapped artifacts and operational metadata, neither of which is decryption-enabling.
Note: PSDA (Provider-Side Data Absence) means the provider never holds ciphertext - it permits holding wrapped keys. The keys-only scenario is PSDA-compliant and particularly robust because even future cryptographic breakthroughs cannot help an attacker who has no ciphertext to attack. The holds neither scenario goes beyond PSDA requirements and represents the theoretical maximum separation.
Comparison Matrix
| Aspect | Zero Trust | ZKS |
|---|---|---|
| Primary control | Policy enforcement | Topological separation |
| Trust model | Verify continuously | Make trust irrelevant |
| Privacy type | Behavioral/Enforcement | Structural/Architectural |
| Verification method | Audit policy compliance | Conformance-test the architecture (ZKS-1.0 §7–8) |
| Failure mode | Policy failure → exposure | Policy failure → still protected |
| Compulsion resistance | Policy may be overridden | No decryption-enabling material to compel |
| Subpoena response | "We won't" or "We can't" | "We don't possess" |
| Future-proofing | Depends on policy durability | Depends on topology durability |
The Gap Zero Trust Leaves Open
Scenario: Perfect Zero Trust, Failed ZKS
Organization implements:
- Strong identity verification (MFA, continuous auth)
- Micro-segmented network
- Device posture verification
- Application-level access control
- Comprehensive logging and monitoring
- Zero standing privileges
But at the architectural level:
- Provider holds ciphertext on their storage
- Provider holds wrapped keys in their HSM
- Components coexist under provider control
- Topology places trust burden on provider
Result:
- Perfect policy compliance
- Complete ZKS failure
- Provider can be compelled to attempt decryption
- "Harvest now, decrypt later" remains viable
Why This Matters
Zero Trust asks: "Is this access request authorized?" ZKS asks: "Does the topology make authorization irrelevant for decryption?"
A Zero Trust system protects against unauthorized access. It doesn't protect against:
- Authorized access by a compelled provider
- Future capability to decrypt currently-held components
- Insider threats with legitimate access
- Acquisition by entity with different policies
ZKS protects against all of these by ensuring the topology doesn't permit them.
How They Work Together
Defense in Depth Model
Practical Integration
Zero Trust protects the Client Sovereignty Domain:
- Strong authentication to user devices
- Device posture verification
- Micro-segmentation of CSD networks
ZKS ensures topology prevents provider decryption:
- Data Plane and Key Plane never coexist under provider control
- Even with full provider infrastructure access, topology prevents decryption
- Zero Trust failures don't compromise structural privacy
Addressing Common Objections
"We have Zero Trust policies preventing admin decryption"
Response: Zero Trust policies control access. They don't control topology. If your architecture places ciphertext and keys under the same control, policy failure or legal compulsion can still lead to decryption. ZKS ensures the topology makes this impossible regardless of policy.
"Our admins are verified and monitored"
Response: Verification and monitoring are behavioral controls. They depend on the admin's trustworthiness and the monitoring system's effectiveness. ZKS makes admin trustworthiness irrelevant - there's nothing for them to decrypt because the topology doesn't permit it.
"We're ISO 27001 / SOC 2 certified"
Response: Certifications verify policy compliance and security controls. They don't verify topology. A certified provider can still hold both ciphertext and keys. Certification is behavioral assurance; ZKS is structural assurance.
"We have a Data Processing Agreement limiting data use"
Response: DPAs are contracts - behavioral controls. They can be violated, overridden by legal compulsion, or rendered irrelevant by acquisition. ZKS ensures the topology makes contractual controls unnecessary for privacy protection.
Regulatory Alignment
| Regulation | Zero Trust Alignment | ZKS Alignment |
|---|---|---|
| GDPR | Access controls for personal data | Structural measure: processor cannot access content regardless of policy (metadata held by the processor remains personal data with its own obligations) |
| HIPAA | Access controls for PHI | Architectural control: may support treating ZKS-protected PHI as secured, subject to HHS guidance on encryption and key custody |
| Schrems II | Access restrictions for EU data | Topological support: corresponds to EDPB Recommendations 01/2020 Use Case 1 (encrypted transfer with keys held solely by the exporter), subject to the conditions stated there |
| SOC 2 | Access control criteria | Structural evidence: architecture and conformance-test results support access-control criteria |
| FedRAMP | Zero Trust requirements | Complementary architectural controls |
Schrems II Note: ZKS is particularly relevant for cross-border data protection. The question isn't whether a provider will comply with a foreign-government demand for content - it's whether the topology makes such compliance possible for content the provider cannot decrypt. EDPB Recommendations 01/2020 (Use Case 1) identifies exactly this architecture class - strong encryption with keys held solely by the data exporter - as an effective supplementary measure. Metadata held by the provider remains within reach of legal process and transfer analysis. This table describes technical alignment, not legal advice; regulatory outcomes depend on jurisdiction-specific conditions and supervisory assessment.
Implementation Considerations
For Zero Trust Implementations Adding ZKS
| Current State | ZKS Addition | Outcome |
|---|---|---|
| Server-side encryption | Client-side encryption | Keys never enter provider topology |
| Provider-held keys | User-controlled keys | Key Plane exits provider control |
| Centralized key management | Distributed topology | No single point of coexistence |
| Access-controlled data | Access-controlled ciphertext + separated keys | Defense in depth |
For ZKS Implementations Adding Zero Trust
| Current State | Zero Trust Addition | Outcome |
|---|---|---|
| Basic authentication | Strong identity verification | Reduced CSD compromise risk |
| Flat network | Micro-segmentation | Lateral movement prevention |
| Static authorization | Continuous verification | Adaptive access control |
| Limited logging | Comprehensive audit | Threat detection within CSD |
Recommendations
For Security Architects
- Implement both - Zero Trust for access control, ZKS for topological separation
- Verify differently - Zero Trust via policy audit; ZKS via conformance testing of the architecture (ZKS-1.0 §7–8)
- Layer appropriately - Zero Trust protects CSD; ZKS ensures provider blindness
- Document topology - Architecture diagrams should clearly show plane separation
For CISOs
- Different audits - Zero Trust audits verify policy; ZKS audits verify topology
- Different questions - "Who can access?" vs. "Where do components exist?"
- Complementary certifications - Neither replaces the other
- Regulatory positioning - ZKS provides structural evidence for data protection claims
For Compliance Officers
- Structural evidence - ZKS compliance is demonstrable via the standard's conformance tests and evidence requirements (diagrams are supporting evidence, per ZKS-1.0 §7.5.1)
- Compulsion defense - ZKS provides "impossibility" defense, not "unwillingness"
- Due diligence - Evaluate vendor topology, not just vendor policy
- Future-proofing - Topology survives policy changes and acquisitions
Conclusion
Zero Trust and Zero-Knowledge Sovereignty are complementary frameworks addressing different security dimensions:
| Framework | Controls | Trust Model | Privacy Type |
|---|---|---|---|
| Zero Trust | Access (who can reach) | Continuous verification | Behavioral |
| ZKS | Topology (where components exist) | Trust irrelevance | Structural |
Zero Trust ensures unauthorized parties cannot access resources.
ZKS ensures the topology makes provider trust irrelevant - components never coexist under external control, so there's nothing to trust them with.
A robust security architecture implements both:
- Zero Trust to verify and control access
- ZKS to ensure that even with access, the topology prevents decryption
The key insight: Architecture beats policy. Topological separation provides structural privacy that survives policy failures, legal compulsion for content, insider threats to production systems, and acquisitions. The one channel through which a vendor decision can still change the deployed topology - the software update mechanism - is exactly the channel ZKS-1.0 §5.3.1 places under mandatory Binary Transparency. Zero Trust controls access; ZKS makes trust irrelevant.
References
- Rose, S., Borchert, O., Mitchell, S., Connelly, S. (2020). Zero Trust Architecture. NIST Special Publication 800-207. https://doi.org/10.6028/NIST.SP.800-207
- ZKS Working Group (2026). Zero-Knowledge Sovereignty Standard, ZKS-1.0-RC2 (Release Candidate). https://zks-standard.org/spec/v1/
- European Data Protection Board (2021). Recommendations 01/2020 on measures that supplement transfer tools, Version 2.0.
- CISA (2023). Zero Trust Maturity Model, Version 2.0.
- Forrester Research. The Zero Trust eXtended (ZTX) Ecosystem Framework.