> For the complete documentation index, see [llms.txt](https://docs.therisk.global/organization/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.therisk.global/organization/standardization/nexus-sovereignty/ix.-security-privacy-and-resilience/post-quantum-signature-readiness.md).

# Post-Quantum Signature Readiness

## Post-Quantum Security and Cryptographic Agility in the Nexus Sovereignty Framework: PQ-Ready Credentials, Clause Integrity, Governance Signatures, Simulation Proofs, Attestation Chains, and Intergenerational Trust

### Why Post-Quantum Security Is Mandatory

The Nexus Sovereignty Framework is designed for long-lived governance infrastructure. Its records may need to remain verifiable across decades: treaty-aligned evidence, multilateral simulation logs, credential issuance records, Project Evidence records, public-safe outputs, AI agent audit trails, clause execution proofs, private-chain anchors, edge and offline synchronization bundles, finance-readiness evidence, insurance-readiness evidence, and institutional governance decisions. These records must remain trustworthy not only under today’s adversarial conditions, but under future cryptographic threat models.

Quantum computing creates a specific long-term risk: cryptographic systems that are secure against classical adversaries may become vulnerable if large-scale, fault-tolerant quantum computers become practical. Current public-key schemes based on elliptic-curve or discrete-log assumptions, including many deployments of ECDSA, Ed25519, and BLS-style signatures, may become unsafe under future quantum attack. That affects credential authenticity, DAO-compatible governance votes, clause signatures, runtime attestations, audit anchors, key exchange, encrypted evidence stores, private-chain bridges, and long-term proof archives.

NSF therefore treats post-quantum cryptography as a protocol-readiness requirement, not a later upgrade. The purpose is not to claim that all deployments must immediately abandon classical cryptography. The purpose is to make every protocol layer cryptographically agile, migration-ready, hybrid-compatible, and capable of preserving evidence integrity through long-term transition periods.

The core doctrine is:

**Nexus must assume that today’s classical public-key signatures and key-establishment systems may not be sufficient for intergenerational governance records. Post-quantum readiness must therefore be built into credentials, clauses, CACs, simulations, registries, anchors, AI audit logs, and governance workflows from the beginning.**

### Post-Quantum Readiness Is Cryptographic Agility, Not One-Time Replacement

Post-quantum security is not a single algorithm swap. It is a lifecycle discipline. Algorithms mature. Standards evolve. Implementations receive errata. Deployment guidance changes. Hardware support varies. Legacy systems remain in use. Some environments require FIPS-aligned profiles. Some require sovereign cryptographic policy. Some require offline operation. Some require extremely small signatures. Some require long-term archive survivability. Some require hybrid proof during transition.

NSF therefore requires **cryptographic agility**. Every cryptographic object should identify its algorithm suite, parameter set, key version, issuer policy, validity window, migration status, hash domain, revocation path, and verification requirements. A credential should be able to carry classical and PQ signatures during transition. A clause should be able to rotate signing keys without losing version lineage. A CAC should identify the proof suite used at execution time. A registry should track which objects remain legacy, hybrid, PQ-ready, or PQ-required. A verifier should be able to reject weak signatures for high-consequence workflows after a defined cutover point.

Cryptographic agility prevents the framework from becoming trapped in today’s primitives.

### PQC Standards and Benchmark Alignment

NSF should align its post-quantum profiles with recognized public standards and implementation guidance, especially where sovereign, institutional, or regulated environments require stable reference points. NIST finalized the first three Federal Information Processing Standards for post-quantum cryptography in August 2024: FIPS 203 for ML-KEM, FIPS 204 for ML-DSA, and FIPS 205 for SLH-DSA. NIST’s PQC project also notes that FALCON was selected for standardization as a future FIPS 206, and that HQC was selected for standardization in 2025. ([NIST Computer Security Resource Center](https://csrc.nist.gov/News/2024/postquantum-cryptography-fips-approved?utm_source=chatgpt.com))

This means Nexus documentation should use the current standardized algorithm names where possible. CRYSTALS-Kyber is represented in the NIST standard as **ML-KEM**, a module-lattice-based key-encapsulation mechanism. FIPS 203 specifies ML-KEM parameter sets ML-KEM-512, ML-KEM-768, and ML-KEM-1024. ([NIST Computer Security Resource Center](https://csrc.nist.gov/pubs/fips/203/final?utm_source=chatgpt.com)) CRYSTALS-Dilithium is represented as **ML-DSA**, the module-lattice-based digital signature standard in FIPS 204. ([NIST Computer Security Resource Center](https://csrc.nist.gov/pubs/fips/204/final?utm_source=chatgpt.com)) SPHINCS+ is represented as **SLH-DSA**, the stateless hash-based digital signature standard in FIPS 205. ([NIST Computer Security Resource Center](https://csrc.nist.gov/projects/post-quantum-cryptography?platform=hootsuite\&utm_source=chatgpt.com))

For NSF, these standards should become reference profiles, not hardcoded assumptions. A sovereign node may adopt a FIPS-aligned profile. A research deployment may test additional algorithms. A high-assurance archive may use hash-based signatures. A low-power edge device may require a performance-constrained profile. A future update may incorporate additional standardized algorithms. The registry must record which profile applies.

### PQ-Ready Signature Schemes in NSF

NSF should support multiple signature classes, each suited to different governance requirements.

**ML-DSA-compatible signatures** can support general-purpose post-quantum signing for credentials, clause releases, governance proposals, registry updates, CAC envelopes, and AI agent policy records.

**SLH-DSA-compatible signatures** can support high-assurance, stateless, hash-based signing where long-term verifiability and conservative assumptions are more important than compact signatures or signing speed.

**Future FN-DSA or Falcon-derived profiles** may support contexts where compact signatures and deterministic signing properties are useful, subject to formal standardization, implementation review, and registry approval.

**Hybrid classical-PQ signatures** should be used during transition periods, especially where interoperability with legacy systems remains necessary. A hybrid signature may require both a classical signature and a PQ signature to validate, or may allow policy-defined acceptance depending on risk class.

**Threshold and multisignature profiles** should support post-quantum governance signatures, but must be handled carefully because many existing threshold schemes are classical. NSF should define registry-approved PQ threshold profiles rather than assuming classical multisig remains safe indefinitely.

**Hash-based archival signatures** should support long-lived records, such as treaty-aligned evidence, public-good governance archives, Project Evidence commitments, public-safe outputs, and intergenerational institutional memory.

Every signature profile should be recorded in the Cryptographic Profile Registry with algorithm, parameter set, key type, use class, security level, implementation status, allowed workflows, deprecation plan, and cutover requirements.

### VC and Credential Layer Hardening

The Credential Layer is one of the most important post-quantum migration surfaces. Verifiable Credentials may define who can review evidence, issue data, validate simulations, operate nodes, publish public-safe outputs, sign governance actions, access Project Evidence rooms, use AI tools, or participate in finance-readiness and insurance-readiness evidence workflows. If credential signatures become forgeable, the entire governance model is at risk.

NSF credentials should therefore support PQ signature fields, hybrid signature fields, issuer DID documents with PQ key declarations, algorithm agility metadata, status root signatures, revocation registry signatures, credential dependency proofs, and selective disclosure proofs compatible with PQ-safe commitments where possible.

A PQ-ready credential may include:

```json
{
  "credential_type": "SimulationReviewerVC",
  "issuer": "did:nsf:org:SimulationGovernanceRegistry",
  "subject": "did:nsf:person:0x91",
  "scope": {
    "domain": "flood-risk-simulation",
    "jurisdiction": ["KEN"],
    "permitted_actions": [
      "review-simulation-output",
      "attach-review-note"
    ]
  },
  "crypto_profile": {
    "mode": "hybrid-classical-pq",
    "classical_signature": "Ed25519",
    "pq_signature": "ML-DSA",
    "hash_suite": "SHA3-512",
    "status_root_signature": "SLH-DSA",
    "migration_state": "pq-ready"
  },
  "valid_until": "2026-01-01T00:00:00Z",
  "non_meaning": [
    "not-public-authority",
    "not-certification",
    "not-finance-approval"
  ]
}
```

Revocation lists and credential status registries should be signed under PQ-ready profiles. Long-lived credential histories should be periodically re-anchored with PQ-safe hash trees. If an issuer remains classical-only after a cutover deadline, its credentials may become restricted, advisory-only, or invalid for high-consequence workflows.

Credential hardening must also preserve privacy. PQ migration should not force public disclosure of sensitive credential metadata. Selective disclosure, ZK proofs, and private status checks should remain available where appropriate.

### Clause Hashing and Post-Quantum Anchoring

Smart Clauses are governance-critical artifacts. A clause defines triggers, simulation requirements, credential dependencies, public-safe constraints, fallback states, jurisdictional scope, and audit obligations. If a clause signature or hash commitment is weak, attackers may attempt retroactive forgery, replay, unauthorized fork injection, or registry substitution.

NSF should therefore use strong hash commitments and clear domain separation. Clause artifacts should include content hashes, metadata hashes, dependency hashes, simulation-template hashes, credential-schema hashes, and public-safe policy hashes. Hash domains should distinguish classical-era clause commitments from PQ-era commitments so that old records cannot be confused with upgraded records.

Clause records should support PQ-signed Merkle proofs, PQ-signed release signatures, forward-secure signature chains, version-tree commitments, and re-anchoring schedules. A clause issued under a legacy signature should be re-anchored under a PQ profile before it is used in high-consequence, long-lived, treaty-aligned, or public-good archival workflows.

A clause PQ commitment may look like:

```json
{
  "clause_id": "FloodEvidenceRouting@3.4",
  "clause_hash": "sha3-512:0xabc",
  "metadata_hash": "sha3-512:0xdef",
  "dependency_root": "sha3-512:0x881",
  "version_tree_root": "sha3-512:0x99a",
  "signature_profile": "ML-DSA-with-SLH-DSA-archive-anchor",
  "legacy_signature_profile": "Ed25519",
  "migration_state": "hybrid-accepted",
  "cutover_required_before": "2028-01-01T00:00:00Z",
  "audit_record": "audit-0x71bc"
}
```

The goal is to protect not only future execution, but future replay. A governance record must remain interpretable even if the original classical signature is no longer trusted.

### DAO and Governance Proposal Security

Governance records are particularly sensitive to post-quantum risk because they may determine protocol upgrades, registry entries, credential schemas, model approvals, clause activation, public-safe policies, AI tool permissions, Project Evidence schemas, finance-readiness evidence profiles, and insurance-readiness evidence profiles. If proposal signatures, quorum proofs, or vote records become forgeable, institutional memory becomes vulnerable.

NSF governance should transition toward hybrid and then PQ-native governance signatures. During migration, governance proposals may require both classical and PQ signatures. High-consequence governance actions may require a minimum number of PQ-signed validators even before full cutover. Proposal state snapshots should be PQ-signed and hash-anchored. Quorum records should identify which signatures were classical, hybrid, or PQ. Governance logs should be periodically re-anchored with PQ-safe archival commitments.

A governance proposal record may include:

```json
{
  "proposal_id": "proposal-0x88bc",
  "proposal_type": "ClauseUpgrade",
  "affected_clause": "DroughtEvidenceRouting@3.2",
  "signature_policy": {
    "required_mode": "hybrid-classical-pq",
    "minimum_pq_signers": 2,
    "allowed_pq_algorithms": ["ML-DSA", "SLH-DSA"]
  },
  "state_snapshot_hash": "sha3-512:0x77a",
  "quorum_record": "QuorumRecord#0x44",
  "migration_state": "pq-ready",
  "non_meaning": [
    "governance-approval-only-within-declared-scope",
    "not-public-authority-approval"
  ]
}
```

Governance signatures must remain role-bound. A PQ signature proves cryptographic control of a key. It does not prove that the signer had authority unless the signer’s credential and role scope are also valid.

### Simulation Proof Integrity

Simulation outputs may influence clause validation, proposal generation, public-safe review, Project Evidence updates, finance-readiness evidence, insurance-readiness evidence, and AI agent permissions. A post-quantum attacker who can forge simulation signatures or manipulate archived simulation records could distort institutional memory.

NSF simulation records should use PQ-signed SimulationRunVCs, strong hash commitments, model lineage roots, input and output commitments, runtime attestation hashes, uncertainty records, and registry-state references. For privacy-sensitive simulations, input data may remain encrypted or committed, with PQ-safe key encapsulation and selective disclosure where appropriate.

ML-KEM-compatible key encapsulation can support encrypted session establishment for sensitive simulation workflows, controlled evidence rooms, private-chain relays, and edge-to-registry transfers. PQ signatures can bind forecast delta hashes, simulation result bundles, model status records, and review attestations. STARK-friendly or hash-based proof transcripts may be useful where long-term verification and transparent setup assumptions are prioritized, subject to implementation review and registry approval.

A PQ-ready SimulationRunVC may include:

```json
{
  "type": "SimulationRunVC",
  "simulation_id": "sim-0x71cc",
  "template": "FloodRiskEvidence@3.1",
  "model_hash": "sha3-512:0xmodel",
  "input_commitment": "sha3-512:0xinput",
  "output_commitment": "sha3-512:0xoutput",
  "runtime_attestation_hash": "sha3-512:0xtee",
  "crypto_profile": {
    "signature": "ML-DSA",
    "archive_signature": "SLH-DSA",
    "key_encapsulation": "ML-KEM",
    "hash_suite": "SHA3-512"
  },
  "review_status": "accepted-for-evidence-support",
  "non_meaning": [
    "not-prediction-certainty",
    "not-official-warning"
  ]
}
```

Simulation proof integrity protects the record of what was modeled, not the certainty of what will happen.

### TEE and Remote Attestation PQ Readiness

Trusted Execution Environments and remote attestation chains are important for CAC, confidential simulation, private-chain anchoring, secure event handling, and AI agent governance. But many existing attestation systems depend on classical signature chains. If those chains become forgeable in the future, archived attestation records may become weaker.

NSF should therefore define PQ-ready attestation profiles. These profiles may include hybrid remote quotes, PQ-signed attestation certificates, PQ-anchored quote logs, runtime measurement hashes, enclave metadata commitments, forward-secure storage of attestation reports, and periodic re-anchoring of older attestation records. Sensitive session data between verifiers and enclaves may use PQ-ready key establishment where supported.

A PQ-ready attestation record should identify the hardware or runtime profile, measurement hash, quote chain, classical signature, PQ signature, verifier policy, timestamp source, registry state, and replay conditions.

TEE readiness must remain boundary-safe. A PQ-secured attestation proves that a declared runtime measurement was attested under a declared cryptographic profile. It does not prove that the policy was legitimate, the model was correct, the data was true, or the institution had authority.

### Key Management and PQ Credential Rotation

Post-quantum readiness depends heavily on key lifecycle management. NSF DID documents, node identities, issuer keys, registry signers, governance signers, simulation signers, edge-node keys, AI agent credentials, public-safe publication keys, and Project Evidence room keys should all declare cryptographic profiles and migration states.

DID documents should include key class, algorithm, parameter set, allowed use, created date, expiry, rotation policy, migration status, revocation path, recovery policy, and deprecation date. Long-lived roles should not rely indefinitely on one key. Key rotation should be scheduled, enforceable, auditable, and compatible with offline and edge deployments.

NSF should support automatic key rollover windows, grace periods, emergency revocation, dual-signing transition periods, legacy-to-PQ signature trees, Merkle tree rebasing, VC regeneration pipelines, and archival re-signing. Governance may define trust decay models where old classical-only signatures lose acceptance over time for higher-risk workflows.

A key readiness declaration may look like:

```json
{
  "did": "did:nsf:org:ProjectEvidenceRegistry",
  "key_id": "key-pq-2026-01",
  "algorithm": "ML-DSA",
  "allowed_use": [
    "credential-issuance",
    "registry-state-signing"
  ],
  "migration_state": "pq-primary",
  "legacy_key_link": "key-ed25519-2024-01",
  "rotation_policy": {
    "max_validity": "P365D",
    "next_rotation_due": "2027-01-01T00:00:00Z"
  },
  "recovery_policy": "multisig-with-pq-signers",
  "status": "active"
}
```

Key rotation must be governance-aware. A rotated key should preserve issuer continuity without allowing unauthorized continuation by compromised keys.

### PQ Readiness for Edge, Offline, and Low-Power Environments

Post-quantum algorithms can impose larger keys, larger signatures, and higher computational overhead than many classical schemes. This matters for edge and offline deployments. Low-power devices, field kits, mesh networks, LoRa links, bootable USB systems, and mobile humanitarian tools cannot assume unlimited bandwidth or compute.

NSF should define multiple PQ profiles for different environments. A full archival profile may use heavier hash-based signatures. A field profile may use compact hybrid signatures where acceptable. A sync profile may aggregate signatures and compress proof bundles. Offline nodes may batch PQ signatures and upload roots when connected. Credential verifiers may use cached PQ status roots instead of fetching full credential chains.

The design goal is to avoid excluding low-resource environments from PQ readiness. Cryptographic strength must be balanced with realistic deployment constraints, without weakening high-consequence workflows.

### PQ Readiness for AI Governance and Verifiable AI Outputs

AI governance records may need long-term verification. An AI agent may draft a governance proposal, summarize public-safe evidence, classify Project Evidence, route simulation outputs, review SDG or ESG evidence, or interact with finance-readiness and insurance-readiness evidence. These outputs may later be audited. If the signatures or logs proving agent scope become forgeable, the audit trail weakens.

NSF should require PQ-ready signing for high-risk AI agent actions, tool-use records, model-policy records, memory governance logs, public-safe output approvals, and CAC-like agent attestations. AI output commitments should include model identifier, policy hash, tool credential, prompt or retrieval commitments where appropriate, output hash, reviewer status, and PQ signature profile.

PQ security does not make AI outputs true. It makes the record of what the agent did harder to forge across time.

### PQ Readiness for Project SPVs, Finance-Readiness, and Insurance-Readiness

Project Evidence records may remain relevant for many years. Infrastructure projects, climate adaptation assets, water systems, energy systems, health facilities, and resilience investments often have long operating lives. Evidence records may need to remain verifiable across planning, construction, operation, monitoring, refinancing, insurance review, dispute resolution, and public-safe reporting.

ProjectEvidenceVCs, FinanceReadinessEvidenceVCs, InsuranceReadinessEvidenceVCs, monitoring records, asset telemetry commitments, public-safe summaries, evidence-room anchors, and credential bundles should therefore support PQ-ready signatures and re-anchoring. This protects long-lived evidence against future cryptographic degradation.

The boundary remains strict. PQ security strengthens evidence integrity. It does not approve finance, provide investment advice, underwrite insurance, determine claims, certify insurability, approve procurement, or create public authority endorsement.

### PQ Migration Governance

PQC migration is itself a governance process. NSF should not silently change cryptographic assumptions. The Cryptographic Profile Registry should define supported algorithms, allowed use cases, risk classes, transition timelines, cutover dates, deprecated schemes, emergency migration procedures, and validation requirements. Governance bodies should review implementation readiness, interoperability, side-channel risks, library maturity, conformance tests, and field deployment constraints.

Migration governance should include:

Inventory of classical cryptographic dependencies.

Classification of records by longevity and consequence.

Hybrid-signature transition policy.

PQ key issuance and rotation plan.

Credential regeneration schedule.

Registry re-anchoring schedule.

TEE attestation transition plan.

Edge and offline compatibility profile.

Fallback and rollback plan.

Deprecation and rejection dates for legacy-only signatures.

Dispute and correction procedures for legacy records.

Migration should be observable. Users and institutions should know whether a record is legacy, hybrid, PQ-ready, or PQ-primary.

### Boundary Statement for Post-Quantum Security

Post-Quantum Security supports cryptographic agility, PQ-ready credentials, hybrid signatures, PQ key encapsulation, clause hash strengthening, simulation proof integrity, governance proposal security, TEE attestation hardening, registry re-anchoring, AI audit protection, Project SPV evidence survivability, finance-readiness evidence integrity, insurance-readiness evidence integrity, edge and offline proof durability, and intergenerational institutional memory.

It does not by itself create legal authority, public authority status, regulatory approval, certification, procurement approval, finance approval, investment advice, insurance underwriting, claims determination, official public warning status, treaty enforcement, professional licensing, sovereign consent, community consent, legal compliance determination, ESG rating, SDG certification, institutional endorsement, data truth, model correctness, prediction certainty, treasury authority, custody authority, or guaranteed security. A PQ signature or PQ proof proves only that a declared cryptographic verification succeeded under a declared algorithm, key, parameter set, and policy profile. Its institutional meaning depends on source authority, governance review, credential status, jurisdiction, applicable law, contracts, community rules, licensed actors, and competent adoption.

A PQ signature is not authority.

A PQ-secured credential is not unlimited permission.

A PQ anchor is not legal validity.

A PQ attestation is not policy legitimacy.

A PQ-signed simulation is not prediction certainty.

A PQ governance vote is not valid outside its mandate.

A PQ-secured finance-readiness record is not finance approval.

A PQ-secured insurance-readiness record is not underwriting.

A PQ-secured Project Evidence record is not procurement approval.

This boundary should appear in cryptographic profile records, DID documents, credential schemas, clause metadata, SimulationRunVCs, CAC records, TEE attestation records, registry anchors, AI agent policies, Project Evidence records, finance-readiness evidence records, insurance-readiness evidence records, public-safe outputs, dashboards, and audit reports.

### NSF as a Post-Quantum-Resilient Governance Protocol

Post-quantum readiness gives Nexus a way to preserve trust across cryptographic eras. The framework must be able to prove that a clause version was authentic, that a credential was issued by the proper issuer, that a governance proposal was signed by valid participants, that a simulation record was not forged, that a CAC envelope corresponds to declared execution, that an AI agent acted under approved policy, that a Project Evidence record remained intact, and that a public-safe output can still be traced back to source commitments years later.

This is not merely technical hardening. It is institutional continuity.

Governance records should outlive today’s algorithms.

Treaty-aligned evidence should remain verifiable across generations.

Credentials should survive key migration.

Clause lineage should remain inspectable.

Simulation archives should remain defensible.

AI audit trails should remain attributable.

Project Evidence should remain durable.

Finance-readiness and insurance-readiness evidence should remain integrity-protected without becoming regulated approval.

Public-good memory should not collapse because cryptography changed.

The purpose of post-quantum security in the Nexus Sovereignty Framework is to ensure that verifiable governance remains verifiable under cryptographic threat evolution. NSF does not simply “upgrade to PQ.” It builds cryptographic agility into the protocol layer so that institutions, communities, projects, and governance domains can preserve proof, scope, auditability, and correctionability across decades of technological change.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.therisk.global/organization/standardization/nexus-sovereignty/ix.-security-privacy-and-resilience/post-quantum-signature-readiness.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.