var img = document.createElement('img'); img.src = "https://analytics.zks-standard.org/matomo.php?idsite=1&rec=1&url=https://zks-standard.org" + location.pathname; img.style = "border:0"; img.alt = "tracker"; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(img,s);
Skip to main content
Version: 1.0-RC1 / CANDIDATE STANDARD

Front Matter

Authority, Status, and Publication Series​

Title: ZKS-1.0-RC1 - Zero-Knowledge Sovereignty Standard

Issuing Body: This document is published under the authority of the ZKS Working Group as part of the Zero-Knowledge Sovereignty (ZKS) Standards Series.

Status of This Document: This document defines ZKS-1.0-RC1 (Release Candidate), the proposed definition of the Zero-Knowledge Sovereignty Standard, currently open for academic review and community comments. ZKS-1.0-RC1 is intended for use as a provisional reference by system architects, auditors, and researchers seeking to evaluate systems claiming Zero-Knowledge Sovereignty properties. While the core architectural tenets are fixed, specific topological definitions may evolve based on the ongoing formal verification process.

Publication Series: This document is part of the ZKS Standards Series, which defines terminology, architecture, conformance, and evaluation criteria for systems asserting sovereignty over cryptographic decryptability.

Revision History​

VersionDateDescription
ZKS-0.12025-06-16Initial internal draft defining ZKS scope, terminology, and core principles
ZKS-0.22025-07-28Expanded draft with architecture model, threat taxonomy, and deployment use cases
ZKS-0.92025-10-13Public review draft with conformance, testing, and audit methodology
ZKS-1.0-RC12026-01-28Initial stable Release Candidate open for review and comments

Abstract​

The Zero-Knowledge Sovereignty (ZKS) Standard defines a class of data systems in which users retain unilateral cryptographic, operational, and topological control over their data, and in which no third party, including service providers or intermediaries in the digital supply chain, possesses the technical capability to access, derive, revoke, or intercept the complete set of components required to decrypt that data.

Unlike existing security and privacy frameworks that focus primarily on access control, trust assumptions, or policy enforcement, ZKS introduces a capability-based sovereignty model centered on decryptability, key material possession, and revocation semantics. The standard formalizes architectural requirements, threat models, deployment invariants, and conformance testing methodologies that make sovereignty claims falsifiable (i.e., testable and subject to disproof through defined procedures) and auditable.

This document specifies the ZKS definition, tenets, reference architecture, deployment models, threat taxonomy, compliance requirements, and conformance testing procedures required to substantiate ZKS claims in both consumer and enterprise environments.

Terminology Note: The term "Zero-Knowledge" in this Standard refers to the condition where service providers and intermediaries possess zero knowledge of the cryptographic components required to decrypt user data. This is distinct from "Zero-Knowledge Proofs" (ZKPs), which are a specific cryptographic primitive. ZKS does not mandate the use of ZKP cryptographic techniques, although such techniques may be employed in ZKS-compliant implementations.

Audience​

This document is intended for:

  • System and Security Architects designing cryptographic systems, storage platforms, collaboration tools, or secure data infrastructures.
  • Product and Engineering Teams implementing systems that claim zero-knowledge, end-to-end encryption, or data sovereignty properties.
  • Auditors, Assessors, and Certification Bodies evaluating technical compliance with sovereignty and cryptographic separation claims.
  • Enterprise Security, Risk, and Compliance Teams assessing vendor claims related to key ownership, decryptability control, and cloud risk.
  • Researchers and Standards Professionals studying capability-based security models and decentralized trust architectures.

This document assumes familiarity with modern cryptography, distributed systems, and security architecture concepts.

Document Conventions​

Normative vs. Informative Sections​

This document uses the following conventions:

  • Normative sections define mandatory requirements for ZKS compliance. Statements in normative sections establish conditions that MUST or MUST NOT be satisfied.

  • Informative sections provide explanatory, contextual, or illustrative material. Informative sections do not introduce new requirements and SHALL NOT be used as the sole basis for compliance claims.

Each section is explicitly labeled as Normative, Informative, or Informative with Normative Constraints.

Bold text outside of RFC 2119 keywords is used for emphasis and does not carry normative force.

Normative Keywords (RFC 2119)​

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

These terms are used only in normative contexts.

Acknowledgments​

This standard reflects contributions from practitioners and researchers with expertise in cryptography, distributed systems, security architecture, privacy engineering, and enterprise risk management.

The authors acknowledge the influence of prior work in zero-trust architecture, end-to-end encryption systems, and decentralized security models, while noting that ZKS introduces distinct and independent requirements regarding decryptability sovereignty and key material possession.

Specific contributor acknowledgments MAY be added in future revisions of this document.

Patent and Intellectual Property Notice​

This document is provided on an "AS IS" basis and is intended to define an open technical standard.

Contributors to this document assert that they are not aware of any patent claims that would be unavoidably infringed by an implementation conforming to this specification. Any party aware of patents believed to be essential to implementing this specification is invited to disclose such patents to the ZKS Working Group.

Implementers are responsible for ensuring that their use of this specification does not infringe applicable intellectual property rights.

Nothing in this document grants any license, express or implied, to any patent, trademark, or other intellectual property.

1. Introduction (Informative)

1.1 Purpose and Objectives​

This document specifies the Zero-Knowledge Sovereignty (ZKS) Standard, a set of definitions, tenets, and compliance criteria for systems intended to preserve unilateral user control over the confidentiality and lifecycle of encrypted information.

The ZKS Standard addresses a recurring deficiency in contemporary data systems: many systems claim "zero-knowledge," "end-to-end encryption," or "client-side encryption," yet retain one or more of the following sovereign-breaking capabilities within the broader digital supply chain:

  • the capability to access decryption-relevant components directly through privileged infrastructure access, support tools, or administrative functions;
  • the capability to derive decryption-relevant components (e.g., key material, authorization artifacts, recovery secrets) from held materials, whether through cryptographic reconstruction, combination of partial components, or extraction from server-held secrets;
  • the capability to revoke a user's effective ability to decrypt their own information by controlling essential key custody or key release functions;
  • the capability to intercept decryption-relevant components through service-side orchestration, metadata aggregation, privileged access or man-in-the-middle positions in the data path.

ZKS compliance can be evaluated through two fundamental tests:

  1. The Subpoena Test: Can the provider be compelled by a court or adversary to produce the complete set of components required to obtain plaintext?

  2. The Capability Test: Can the provider reconstruct decryptability by combining what they hold or can access?

A system is non-compliant if either test yields an affirmative answer, regardless of provider policy or claims of impracticality.

The primary objective of this Standard is to define ZKS as a capability-based property rather than a claim of policy intent. ZKS compliance requires that third parties, including service providers and intermediaries, are prevented by technical incapability from obtaining the complete set of components required to decrypt a user's information.

Secondary objectives include:

  • establishing a neutral vocabulary and reference model for expressing sovereignty requirements in procurement, audits, and technical design;
  • enabling systematic evaluation of architectures and deployments against falsifiable conformance criteria; and
  • providing a compliance framework that supports multiple implementations while preserving the same sovereignty invariants.

1.2 Scope​

This Standard defines:

  • the formal definition of Zero-Knowledge Sovereignty (ZKS);
  • normative tenets that characterize ZKS-compliant systems;
  • operative concepts and semantics required to evaluate compliance (e.g., the meaning of "revoke" in the ZKS context);
  • a baseline threat model and assumptions;
  • requirements for Binary Transparency to ensure software distribution channels cannot introduce deferred decryption capability;
  • a compliance statement and compliance profiles:
    • ZKS-Core for baseline architectural requirements,
    • ZKS-Enhanced for additional transparency measures and peer review, and
    • ZKS-Enterprise for third-party audit, reproducible builds, and regulated-industry requirements; and
  • the architectural and operational properties required for a system to claim ZKS compliance.

This Standard does not:

  • mandate specific cryptographic algorithms (including post-quantum primitives) or protocol suites;
  • prescribe product user interfaces, workflows, or user training programs except where necessary to preserve normative security invariants;
  • define legal, regulatory, or contractual compliance requirements, although it may be used alongside such requirements; or
  • replace broader security architecture frameworks, such as Zero Trust Architecture (ZTA). ZKS is complementary and focuses specifically on sovereignty over encrypted information and its decryption capability boundaries.

1.3 Intended Outcomes and Non-Goals​

Intended Outcomes​

Implementers, auditors, and purchasers using this Standard should be able to:

  • determine whether a system is ZKS-compliant by evaluating third-party capability constraints;
  • distinguish between "service availability" failures and "sovereignty failures," especially with respect to key custody and revocation semantics;
  • express sovereignty requirements precisely, including data topology constraints and operational control boundaries; and
  • validate compliance through evidence and conformance testing, including observational and failure-mode demonstrations.

Non-Goals​

ZKS is not intended to:

  • guarantee that users cannot lose data due to operational mistakes (e.g., voluntarily deleting all key material without backup);
  • prevent compromise of a user's device or runtime environment; rather, it defines sovereignty boundaries and the constraints on third parties even in the presence of compromise scenarios, including constraints on how third parties can exploit endpoint compromise (see Section 5.3.1);
  • standardize enterprise governance models, identity assurance levels, or organizational processes; or
  • enforce a single trust model for all deployments. Instead, it defines what trust MUST NOT be required for sovereignty claims.

1.4 Applicability and System Classes​

The ZKS Standard applies to systems designed to manage and protect user information through encryption where sovereignty is a core requirement. ZKS is relevant to both consumer and enterprise environments and to a range of deployment and storage topologies.

This Standard recognizes (non-exhaustively) the following classes of systems:

  1. Client-only systems Systems where all data and keys reside exclusively on user-controlled devices and where no third-party services participate in custody or key release.

  2. Multi-device peer systems Systems where users synchronize encrypted information across multiple devices under user control. Such systems may include orchestration services for connectivity or coordination, provided these services do not possess decryption capability.

  3. Systems with external ciphertext substrates Systems where encrypted data is stored on external storage infrastructure (e.g., cloud object storage, consumer cloud drives, NAS substrates) while decryption capability and key material possession remain exclusively under user control.

  4. Systems with User-Controlled Key Recovery Services Systems that provide an optional mechanism for users to separate and protect decryption-relevant components (e.g., wrapped item keys) from local endpoints for specific threat models (see Section 4.10), provided that such mechanisms do not introduce third-party decryption capability or the ability to unilaterally prevent users from decrypting their own data (see Section 5.3 for formal definitions of sovereignty failures).

ZKS compliance applies to the system as deployed, including all third-party services and intermediaries required for normal operation. Claims of ZKS compliance SHALL NOT be limited solely to a client application if the deployed architecture includes external services that can obtain decryption-relevant components.

1.5 Structure of This Document​

This Standard is structured to progress from definitions and tenets to architectural concepts, deployment models, threat analysis, and compliance methods:

  • Section 2 defines ZKS formally and normatively, including tenets, baseline threat model, and compliance profiles.
  • Section 3 introduces the logical components and planes of a ZKS architecture, including required properties and metadata minimization.
  • Section 4 describes deployment models and use cases with the invariants that MUST remain intact.
  • Section 5 defines threats and risks associated with ZKS, including the critical distinction between revocation of decryptability and service availability failures.
  • Section 6 describes how ZKS relates to other standards and guidance, including Zero Trust Architecture.
  • Section 7 specifies how ZKS compliance may be achieved, assessed, and maintained, with evidence and verification requirements.
  • Section 8 provides conformance testing and evaluation guidance.
  • Appendices provide acronyms, formal terminology, reference diagrams, test catalogs, and security/privacy considerations.