7. Achieving, Assessing, and Maintaining ZKS Compliance

7.1 Purpose and Scope (Informative)

This section specifies how ZKS compliance may be achieved, assessed, and maintained over time. It translates the ZKS definition (Section 2.1), tenets (Section 2.3), architectural constraints (Section 3.5–3.6), deployment invariants (Section 4), and threat taxonomy (Section 5) into:

• a compliance lifecycle suitable for both greenfield and migration contexts; and
• normative conformance requirements and evidence/verification expectations suitable for hostile audit.

Section 7 is normative in Sections 7.4 and 7.5. Sections 7.1–7.3 are informative guidance intended to support consistent interpretation and practical adoption.

7.2 Greenfield ZKS Architectures (Informative)

7.2.1 Design Approach

Greenfield ZKS architectures should be designed by first defining the sovereignty boundary (Section 3.4) and then ensuring that all external components (CSS, OP, KCS/UKRS, IRM when external) are outside that boundary and remain cryptographically blind to decryptability.

A recommended design sequence is:

1. Define the user sovereignty domain. Determine whether "user" refers to an individual, a family unit, or an organization (Section 4.7). Define the boundary accordingly.

2. Define decryptability components. Enumerate decryption-relevant components (Section 2.2.2) and ensure they are generated and possessed only inside the CSD (Section 3.5.1).

3. Separate planes by default. Ensure the Data Plane transports/stores ciphertext only; the Key Plane governs key generation/wrapping and remains inside the CSD; the Control Plane orchestrates without key-plane visibility; and the OOB Plane is independent (Section 3.3 and canonical diagrams).

4. Treat all third parties as adversarial by capability. Ensure no provider or intermediary can access, derive, intercept, or revoke decryptability (Sections 2.1 and 5).

5. Design recovery as sovereignty-preserving. If using an external UKRS/KCS, implement sovereign restoration as required in Section 4.10 (including secondary, user-held recovery artifacts independent of the service).

7.2.2 Implementation Guidance (Non-Normative)

• Prefer split topology where feasible (Section 4.6) to reduce correlation risk and strengthen Tenet 4.
• Use TEEs/HSMs/secure elements as appropriate to protect keys on endpoints, but do not rely on them as a substitute for sovereignty boundary enforcement (Section 6.5.4).

7.3 Migration from Non-ZKS Systems (Informative)

7.3.1 Migration Principle

Migration is frequently blocked by hidden sovereignty dependencies such as:

• provider-controlled key custody ("BYOK" systems where providers possess key material, Section 6.5.2);
• opaque policy enforcement points (Section 6.2.4);
• provider-operated recovery/reset flows (Sections 5.3.2 and 5.3.8); and
• metadata pipelines that enable cross-plane correlation (Section 5.3.5).

A migration program SHOULD begin by enumerating these dependencies explicitly and removing or isolating them.

7.3.2 Migration Staging (Recommended)

1. Establish CSD-only decryptability. Move decryption and key possession entirely into the CSD; disable provider-side decryptability paths.

2. Convert storage to ciphertext substrates. Move data into CSS form (encrypted blobs) that can be relocated and replicated without provider permission (Section 4.6).

3. Replace provider recovery with sovereign restoration. Implement independent user-held recovery artifacts when UKRS/KCS is used (Section 4.10).

4. Harden orchestration to be Key-Plane blind. Ensure OP does not see or retain Key Plane artifacts (Section 3.5.5) and is not an aggregation point.

5. Finalize evidence generation and testing. Generate evidence and run conformance tests (Sections 7.5 and 8; Appendix D).

7.4 Conformance Requirements (Normative)

7.4.1 Conformance Claim Scope

A system claiming ZKS compliance MUST specify the following scope as part of its compliance claim:

• the deployment model(s) in scope (Section 4);
• all third-party services and intermediaries required for normal operation (CSS, OP, KCS/UKRS, IRM, relay providers, analytics/telemetry providers, crash reporting services, and any other component that processes, stores, or transmits ciphertext, key material, or sovereignty-relevant metadata);
• whether the claim is ZKS-Core, ZKS-Enhanced, or ZKS-Enterprise (Section 2.6); and
• which optional features are enabled (e.g., UKRS/key separation mode, enterprise delegation, cross-domain collaboration).

A conformance claim SHALL NOT exclude a component that materially participates in ciphertext storage, key custody, orchestration, authorization, recovery, or metadata logging.

7.4.2 Mandatory Assertions (ZKS-Core)

A ZKS-Core conformant system MUST satisfy all assertions below.

A1 - CSD-Only Decryption

Decryption of user information MUST occur only within the Client Sovereignty Domain (CSD). No external component SHALL be technically capable of decrypting protected user information or inducing decryption outside the CSD. (Traceability: Sections 2.1, 3.2.1, 4.2 INV-1, 5.4(1).)

A2 - Exclusive Key Material Possession

No third party - including service providers and intermediaries - SHALL possess plaintext decryption keys, master secrets, key derivation secrets, or equivalent material that enables decryptability. "Control by policy" is insufficient if third parties retain key possession. (Traceability: Section 1.4, Sections 2.1–2.2.2, Section 6.5.2.)

A3 - No Third-Party Decryptability Assembly

No third party, and no colluding set of third parties, SHALL be able to access, derive, or intercept the complete set of components required to decrypt the user's information (given ciphertext availability). (Traceability: Section 2.1, Tenet 4, Section 5.3.6.)

A4 - No Third-Party Revocation of Decryptability

No third party SHALL be technically capable of revoking decryptability for an authorized user (given ciphertext availability). Service denial is permitted only as an availability failure and SHALL NOT constitute a mechanism by which a third party can permanently prevent decryptability. (Traceability: Section 2.2.6, Section 4.2 INV-4, Section 5.3.2.)

A5 - Plane Separation and OP Blindness

The system MUST maintain separation of Data Plane, Key Plane, Control Plane, and OOB Plane such that external components cannot co-locate ciphertext, unwrapping capability, and authorization. In particular, the Orchestration Plane (OP) MUST be blind and stateless with respect to the Key Plane. "Stateless" means the OP does not retain key-plane artifacts; temporary caching of opaque blob references for delivery is permitted. (Traceability: Section 3.3, Section 3.5.5, Section 4.5 INV-4.5-C, Section 5.3.4.)

A6 - User-Governed Topology and Relocation

The user MUST retain topological control over ciphertext location and replication, including the ability to relocate ciphertext substrates without provider permission or constraints that effectively prevent migration. (Traceability: Section 2.2.5, Tenet 5, Section 4.6 INV-4.6-B, Section 5.3.9.)

A7 - Metadata Minimization and Non-Correlation

External components MUST adhere to metadata minimization requirements and SHALL NOT accumulate metadata sufficient to derive decryption workflows or enable decryptability by correlation. (Traceability: Section 3.6, Section 5.3.5.)

A8 - Recovery and Reset Safety

Identity and recovery mechanisms MUST NOT create provider-side decryptability, provider-side key possession, or provider-side revocation of decryptability through reset or support workflows. (Traceability: Section 3.5.6, Section 5.3.2, Section 5.3.8, Section 6.4.2.)

7.4.3 Conditional Assertions (Feature-Dependent)

A9 - UKRS / Key Separation Mode (If Implemented)

If a User-Controlled Key Recovery Service (UKRS) or equivalent external key custody service is implemented, the system MUST satisfy:

A9.1 UKRS cryptographic blindness (no unwrapping capability); A9.2 Explicit user authorization for release, with OOB mechanisms where the threat model requires; A9.3 Sovereign restoration: the user MUST retain an independent recovery artifact or method such that denial of UKRS service cannot revoke decryptability (given ciphertext availability); and A9.4 UKRS audit logging MUST NOT contain key material or unwrapping-sufficient metadata.

(Traceability: Section 4.10 INV-4.10-B/C/D, Section 5.3.2.)

A10 - Cross-Domain Collaboration (If Implemented)

If cross-account or cross-organization collaboration is implemented, sharing MUST NOT use unblinded re-encryption proxies or server-side key wrapping that grants an intermediary temporary access to plaintext or unwrapped keys (any access, however brief, during the cryptographic operation constitutes a violation), and MUST preserve independent sovereignty boundaries unless formally merged under user governance. (Traceability: Section 4.8 INV-4.8-A/B/C, Section 5.4(4).)

A11 - Enterprise Delegation (If Implemented)

If enterprise delegation is implemented, delegation within the user's sovereignty domain is permitted. Delegation to the vendor or external intermediaries in a manner that grants decryptability or key possession is prohibited. (Traceability: Section 3.5.6, Section 4.7 INV-4.7-A/B, Section 5.3.8.)

A12 - Opaque Policy Enforcement (If Implemented)

If the system integrates with ZTA policy engines or external enforcement points, such enforcement MUST NOT require decryptability or key possession outside the CSD. Opaque policy enforcement mechanisms that cannot be demonstrated to be cryptographically blind SHALL be treated as non-compliant. (Traceability: Section 6.2.4.)

7.4.4 Prohibited Capabilities (Non-Exhaustive)

A system SHALL NOT claim ZKS compliance if any of the following capabilities exist within any third-party component or workflow in scope:

• plaintext decryption or content inspection outside the CSD;
• provider possession of plaintext keys, master secrets, or derivation inputs enabling decryptability;
• provider-controlled recovery/reset workflows enabling key reconstruction or key release bypass;
• server-side re-encryption proxies or server-side key wrapping in collaboration that involves temporary provider access to plaintext or unwrapped keys;
• orchestration services that store, log, or correlate key-plane artifacts in a manner that enables assembly of decryptability;
• any mechanism by which disabling a provider-operated service can permanently revoke decryptability (given ciphertext availability); or
• any mechanism by which the provider can identify which specific items a user is accessing based on key-release patterns, where such identification would enable targeted attacks.

(Traceability: Sections 2.1–2.2, Sections 4.8 and 4.10, Section 5.4.)

7.4.5 Sovereignty Responsibility Disclosure (Normative)

ZKS transfers certain responsibilities from provider to user. Vendors MUST ensure users understand this transfer.

Required Disclosures. Vendors MUST explicitly communicate the following:

Disclosure 1 — Artifact Responsibility:

"Your Sovereign Restoration Artifact (recovery key, mnemonic phrase, backup file) is the only way to recover your data if you lose access to all your devices. Loss of this artifact may result in permanent, irrecoverable data loss. Store it securely."

Disclosure 2 — Provider Limitation:

"[Provider] cannot recover your data if you lose your sovereign artifact. This is by design — the same protection that prevents [Provider] from accessing your data also prevents [Provider] from helping you recover it."

Disclosure 3 — No Backdoor:

"There is no 'forgot password' reset, no customer support recovery, and no backdoor. If you lose your sovereign artifact and all devices, your data is permanently inaccessible."

Disclosure Presentation Requirements:

These disclosures MUST be:

1. Presented during initial setup — not buried in Terms of Service
2. Repeated when sovereign artifacts are created or modified
3. Available in user-accessible help documentation
4. Acknowledged by user (RECOMMENDED) — explicit checkbox or confirmation during onboarding

Rationale: Traditional SaaS users expect providers can assist with recovery. ZKS inverts this expectation. Without explicit disclosure, users may lose data due to misunderstanding the sovereignty model.

7.5 Evidence and Verification (Normative)

7.5.1 Evidence Principles

ZKS compliance is a claim about technical incapability. Therefore, evidence MUST be falsifiable and SHALL be sufficient to show that prohibited capabilities cannot be exercised by third parties in scope.

Evidence SHALL be evaluated under the threat assumptions in Section 5, including plausible collusion.

Evidence MUST be categorized as:

• Required Evidence (mandatory for conformance claims), and
• Supporting Evidence (useful but insufficient on its own).

Architecture diagrams are supporting evidence; they are not sufficient to demonstrate compliance.

7.5.2 Required Evidence (ZKS-Core)

A system claiming ZKS-Core compliance MUST provide evidence in each of the following categories.

E1 - Observable Behavior Evidence

Evidence demonstrating that external components do not receive plaintext, do not receive unwrapped keys, and do not perform decryption. This evidence SHOULD include:

• network captures or equivalent telemetry showing ciphertext-only data plane flows to CSS;
• absence of plaintext or decryption artifacts in OP/KCS interactions; and
• demonstration that OP traffic remains cryptographically blind to the Key Plane.

E2 - Decryptability-Impossibility Demonstration

Evidence demonstrating that a service provider or intermediary cannot decrypt user information even with privileged access to their own infrastructure. Examples include:

• controlled tests where the provider is given full access to CSS and OP data and still cannot decrypt without user-held components;
• Adversarial Assessment Reports: formal documentation of "red-team" or hostile analysis exercises focused specifically on key derivation, recovery surfaces, and side-channel leakage, demonstrating that motivated adversaries failed to obtain decryptability.

Third-party penetration testing reports may contribute to this evidence category but should explicitly address sovereignty-specific attack vectors.

E3 - Revocation Boundary Demonstration

Evidence demonstrating that third-party denial of service cannot revoke decryptability (given ciphertext availability). This MUST include:

• tests where the CSS or OP is disabled and decryptability for locally held ciphertext remains intact; and
• for UKRS scenarios, tests showing sovereign restoration via user-held recovery artifacts independent of the UKRS without requiring any form of provider cooperation.

E4 - Collusion and Correlation Resistance Evidence

Evidence demonstrating that collusion between plausible intermediaries cannot yield decryptability. This SHOULD include:

• analysis and testing of correlation points (identifiers, logs, telemetry);
• where split topology is used, evidence that CSS and OP are distinct entities and do not share correlatable identifiers beyond minimal operational requirements.

Evidence	Validates Assertions
E1 (Observable Behavior)	A1, A2, A5
E2 (Decryptability-Impossibility)	A2, A3, A8
E3 (Revocation Boundary)	A4, A6
E4 (Collusion Resistance)	A3, A7

7.5.3 Supporting Evidence (Non-Sufficient)

Supporting evidence MAY include:

• architecture diagrams mapped to canonical reference diagrams (Appendix C);
• threat model documentation and security design reviews;
• third-party security assessment reports;
• formal specifications of key custody and recovery workflows;
• documentation of metadata minimization policies and retention configurations.

Supporting evidence SHALL NOT be used as the sole basis for compliance. However, for opaque (closed-source) components, Supporting Evidence (specifically Independent Assessments) combined with Required Evidence (Observable Behavior) MAY be accepted as sufficient to demonstrate compliance, provided the assessment explicitly validates the component's internal blindness.

7.5.4 Sufficiency and Auditability Rules

1. Network evidence is necessary but not sufficient. Network captures alone cannot demonstrate absence of provider-side recovery bypass or key possession.

2. Policy assertions are not evidence. Contractual statements, policies, or "trust us" claims do not satisfy ZKS.

3. Opaque components are non-compliant unless proven blind. If a component's internal behavior cannot be evidenced sufficiently to demonstrate cryptographic blindness, it SHALL be treated as non-compliant for ZKS conformance purposes.

4. Evidence must be version-bound or explicitly inherited. Evidence SHALL be tied to a specific software/hardware version set. Subsequent versions MAY inherit compliance claims only if the vendor provides a cryptographic or auditable assertion that the changes do not modify the Sovereignty Boundary, the Key Plane, or the Cryptographic Engine ("Non-Sovereignty-Impacting Change"). Major updates to cryptographic cores require fresh evidence.

7.5.5 Verification Model and Limitations

7.5.5.1 Verification Assurance by Profile

Profile	Server-Side Verification	Client Verification	Assurance Level
ZKS-Core	Architecture analysis + observable behavior	Binary Transparency	Detects targeted malicious binaries; does not detect implementation bugs
ZKS-Enhanced	+ Peer review	+ Binary Transparency	Higher assurance via peer review; does not guarantee absence of vulnerabilities
ZKS-Enterprise	+ Third-party audit	+ Reproducible builds (RECOMMENDED)	Highest practical assurance; third-party validation

7.5.5.2 Inherent Limitations

ZKS verification provides structural assurance that the architecture prevents provider decryption. It does not guarantee:

• absence of implementation bugs;
• correctness of cryptographic implementations;
• resistance to all side-channel attacks; or
• absence of vulnerabilities in dependencies.

These limitations apply to all security standards and are addressed through complementary practices (code review, penetration testing, formal verification, dependency auditing) outside ZKS scope.

7.5.5.3 Binary Trust Assumption

ZKS assumes the deployed client binary behaves as specified. Binary Transparency (Section 5.3.1) ensures any deployed binary is publicly logged, enabling detection of targeted attacks. It does not guarantee the binary is free of vulnerabilities.

For highest assurance, ZKS-Enterprise deployments SHOULD implement reproducible builds enabling independent binary verification from published source.