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: Examine an architecture diagram
- Failure: Only if topology itself is compromised
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. You can verify structural privacy by looking at a diagram - it's auditable like "load-bearing capacity" in a building, not dependent on promises or mathematical hardness.
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)
- 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 over capability - The test is what they hold, not what they can do
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 from architecture diagram |
| Compulsion resistance | Nothing to compel if components don't coexist |
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 |
| 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; topology cannot be violated by policy failure)
The Subpoena Test: Possession vs. Capability
The "Subpoena Test" is often framed as: "Can the provider comply with a decryption demand?"
ZKS reframes this as a Possession Test: "Does the provider hold the components that would make compliance a question?"
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) | None | Keys without data are cryptographically useless; there is nothing to decrypt |
| Ciphertext only (no keys) | Medium | Ciphertext can still be attacked; "harvest now, decrypt later" remains viable |
This asymmetry matters: a provider holding only keys (like a key delivery service) has a stronger position than one holding only ciphertext.
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" | None (nothing to decrypt) | Strong (PSDA) |
| Holds neither | "We possess nothing" | None | Strongest |
The ZKS-compliant answer is always a possession claim, not a capability claim. "We don't have it" is stronger than "We can't use it."
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 | Examine architecture diagram |
| Failure mode | Policy failure → exposure | Policy failure → still protected |
| Compulsion resistance | Policy may be overridden | Nothing 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 regardless of policy |
| HIPAA | Access controls for PHI | Architectural control: covered entity topology prevents exposure |
| Schrems II | Access restrictions for EU data | Topological defense: US provider cannot comply with foreign demands (doesn't possess components) |
| SOC 2 | Access control criteria | Structural evidence: topology diagram demonstrates separation |
| 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 US provider will comply with US government demands - it's whether the topology makes compliance possible. If the provider doesn't possess both components, compliance is architecturally impossible.
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 architecture diagram review
- 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 architecture diagrams
- 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, insider threats, and acquisitions. Zero Trust controls access; ZKS makes trust irrelevant.
References
- NIST SP 800-207: Zero Trust Architecture
- ZKS-1.0: Zero-Knowledge Sovereignty Standard
- CISA Zero Trust Maturity Model
- Forrester Zero Trust eXtended (ZTX) Framework