How ZKS Compares to Other Approaches
Zero-Knowledge Sovereignty (ZKS) is complementary to existing security frameworks, not a replacement. This page clarifies the relationship between ZKS and common approaches.
ZKS vs. Zero Trust (NIST SP 800-207)
| Aspect | Zero Trust | ZKS |
|---|---|---|
| Primary Question | "Who can access this resource?" | "Who can decrypt this data?" |
| Trust Model | Never trust, always verify | Never rely on policy; verify capability |
| Focus | Network perimeter, identity, access | Cryptographic control, topology, sovereignty |
| Threat Model | Assumes breach; limits lateral movement | Assumes provider compromise; ensures decryptability control |
Relationship: Complementary. A ZKS-compliant system can (and should) also implement Zero Trust principles. ZT controls access to the system; ZKS controls decryptability of the data. For detailed analysis, see ZKS vs. Zero Trust Architecture.
ZKS vs. BYOK / HYOK / DKE
| Approach | Description | ZKS Assessment |
|---|---|---|
| BYOK (Bring Your Own Key) | Customer provides key; provider uses it | Often non-compliant - provider holds key during use |
| HYOK (Hold Your Own Key) | Customer retains key; provider requests on-demand | Depends on implementation - key release may grant provider access |
| DKE (Double Key Encryption) | Two keys required; customer holds one | Can be compliant if customer key never reaches provider |
The Problem: "Customer-managed keys" often means the provider still possesses the key during processing. ZKS requires that the provider cannot access or derive decryptability - not even temporarily. This requirement is formalized in A2: providers must not possess the cryptographic components required to decrypt.
ZKS vs. End-to-End Encryption (E2EE)
| Aspect | E2E Encryption | ZKS |
|---|---|---|
| Scope | Transport/storage encryption | Full sovereignty (encryption + topology + control + metadata) |
| Key Management | Often unspecified | Explicit requirements for key plane separation |
| Metadata | Often exposed | Minimization required (A7) |
| Revocation | Varies | User must retain unilateral control (A4) |
| Provider Role | May hold ciphertext | Must be cryptographically blind |
Relationship: E2EE is necessary but not sufficient for ZKS compliance. A system can have E2EE and still fail ZKS if the provider can revoke decryptability, access metadata, or hold keys.
ZKS vs. Confidential Computing (CC)
| Aspect | Confidential Computing | ZKS |
|---|---|---|
| Protection | Data in use (processing) | Data at rest, in transit, and sovereignty |
| Mechanism | Hardware enclaves (SGX, SEV, TDX) | Architectural topology, key separation |
| Trust Model | Trust hardware attestation | Trust capability constraints |
| Provider Access | Encrypted during processing | Never - provider is cryptographically blind |
Relationship: Defense in depth. CC can protect data during processing within a ZKS architecture. However, CC alone doesn't address key management, metadata exposure, or revocation control. ZKS defines "Extended CSD" for scenarios where remote TEEs participate in the Client Sovereignty Domain with explicit attestation requirements.
ZKS vs. "Zero-Knowledge" Marketing Claims
Many products claim "zero-knowledge" without meeting ZKS requirements:
| Claim | Reality | ZKS Position |
|---|---|---|
| "We can't see your data" | Often policy-based, not capability-based | Must be technically incapable of accessing data, not just policy-prohibited |
| "End-to-end encrypted" | Keys may still be provider-accessible | Provider must be cryptographically blind |
| "Customer-managed keys" | Key may be exposed during use | Provider must never access key material |
| "We don't store your password" | Password may derive keys server-side | Key derivation must occur within CSD only |
The ZKS Test: Can the provider access or derive the complete set of components required to decrypt? If yes - regardless of marketing claims - they are not ZKS-compliant.
Summary Matrix
| Framework | Access Control | Decryptability Control | Topology Control | Metadata Protection |
|---|---|---|---|---|
| Zero Trust | Primary focus | Not addressed | Not addressed | Partial |
| BYOK/HYOK | Not addressed | Partial | Not addressed | Not addressed |
| E2E Encryption | Not addressed | Partial | Not addressed | Not addressed |
| Confidential Computing | Partial | During processing | Not addressed | Partial |
| ZKS | Out of scope | Primary focus | Required | Required |
Conclusion: ZKS addresses a specific gap - decryptability control - that other frameworks do not fully cover. For comprehensive security, combine ZKS with Zero Trust, Confidential Computing, and robust access controls.