# SP-053 Zero-Knowledge Proof Architecture

Status: draft. Release 26.03. Modified 2026-03-10. Licence: CC BY-SA 4.0.

Scope: Security architecture for zero-knowledge proof (ZKP) systems covering ZK-SNARK and ZK-STARK proof systems, trusted setup ceremony security, ZK-rollup infrastructure security (sequencer, data availability, forced inclusion), privacy-preserving computation, confidential smart contracts, and enterprise ZK applications including interbank settlement, private supply chain verification, and selective disclosure for...
Use when: Use this pattern when: (1) proving regulatory compliance to regulators or counterparties without disclosing confidential business data; (2) deploying a ZK-rollup for transaction throughput or L2 scaling; (3) building privacy-preserving transaction systems for financial applications; (4) implementing selective disclosure for KYC/AML credentials; (5) building confidential computing applications where even the cloud...
Not when: Do not use ZK proofs when: simpler cryptographic techniques (TLS, HSM-based signing, secure multi-party computation) solve the problem without the complexity overhead; the team lacks ZK cryptographic expertise (implementation bugs are catastrophic); real-time performance requirements cannot tolerate proof generation latency; or the regulatory environment explicitly requires full transaction transparency (some...

## Controls (32, NIST SP 800-53 ids)
- Critical (10): SC-12, SC-13, SA-11, CA-08, SI-10, AC-03, AC-06, SC-28, AU-02, CA-07
- Important (12): SC-07, SC-08, AC-04, AC-05, CM-03, CM-08, IR-04, RA-03, SA-15, SA-17, PE-03, AU-09
- Standard (10): AU-03, CM-02, CM-07, PM-09, SA-04, SR-03, RA-05, PT-02, SI-07, CP-09

## What each critical control mitigates (10)
- SC-12 Cryptographic Key Establishment and Management: T-ZKP-002
- SC-13 Cryptographic Protection: T-ZKP-003, T-ZKP-009
- SA-11 Developer Testing and Evaluation: T-ZKP-001
- CA-08 Penetration Testing: T-ZKP-001
- SI-10 Information Input Validation: none of the threats below
- AC-03 Access Enforcement: T-ZKP-007
- AC-06 Least Privilege: T-ZKP-004, T-ZKP-010
- SC-28 Protection of Information at Rest: T-ZKP-004
- AU-02 Event Logging: T-ZKP-002
- CA-07 Continuous Monitoring: T-ZKP-005, T-ZKP-007

## Threats and the controls that mitigate them (10)
- T-ZKP-001 undefined: SA-11, CA-08, SA-15, SA-17
- T-ZKP-002 undefined: SC-12, PE-03, AC-05, AU-02
- T-ZKP-003 undefined: SC-13, CM-03, CM-08, SI-07
- T-ZKP-004 undefined: SC-28, AC-06, SC-07, CM-02
- T-ZKP-005 undefined: SC-07, CA-07, IR-04, RA-03
- T-ZKP-006 undefined: SC-08, AC-04, AU-09, PM-09
- T-ZKP-007 undefined: AC-03, CM-08, CA-07, RA-05
- T-ZKP-008 undefined: PT-02, PM-09, AC-04, AU-09
- T-ZKP-009 undefined: SC-13, SA-15, RA-03, PM-09
- T-ZKP-010 undefined: AC-06, CM-07, SC-07, CP-09

## More
- The critical controls and what each mitigates, as JSON (a few KB): /api/v1/patterns/SP-053/crosswalk?emphasis=critical
- The same for every control, with its clauses in a framework: /api/v1/patterns/SP-053/crosswalk?framework={framework id}. Framework ids are listed in /llms.txt
- The pattern's prose, examples and references as JSON, 39 KB: /api/v1/patterns/SP-053
- Page for people: /patterns/sp-053/
- Found an error? Open an issue at https://github.com/opensecurityarchitecture/osa-data/issues with the id, what OSA says and what the source says.
- Related: SP-019 Secure Ad-Hoc File Exchange Pattern; SP-040 Post-Quantum Cryptography and Quantum Readiness; SP-051 Tokenised Asset Security Architecture; SP-052 Decentralised Identity & Verifiable Credentials

This card, the API and the page are generated from one file. Checking one against another adds no evidence.