VeriCrypt produces a cryptographically signed, Merkle-proofed .pqc compliance artefact that proves your organisation's cryptographic posture satisfies DORA, PQFIF, NCSC, and NIST requirements. This manual explains what the report contains, how to interpret every metric, and how to use the results for board reporting, regulatory submission, and migration planning.
VeriCrypt is a single static binary that ingests your organisation's cryptographic inventory — certificates, keys, TLS configurations, HSM records, code dependencies — and executes a 7-stage pipeline to produce a regulator-ready .pqc compliance artefact.
The seven stages are:
The report.pqc file is a self-contained JSON artefact. It is the primary evidence for regulatory submission. Every field is cryptographically bound to the Merkle root and covered by the SLH-DSA signature.
| Field | Description | Business Significance |
|---|---|---|
report_id |
UUID v4 unique to this scan | Identifies this specific compliance artefact for audit trail purposes |
scan_timestamp |
ISO 8601 timestamp of scan execution | Establishes the point-in-time cryptographic posture. Regulators compare against DORA deadline timelines |
binary_hash |
SHA-256 of the VeriCrypt binary that executed the scan | Proves which version of the compliance engine produced this report. Verifiable against published checksums |
input_hash |
Merkle root of all certificate fingerprints in the inventory | Cryptographically binds the report to the exact inventory that was scanned. Any change to the inventory produces a different hash |
total_assets |
Count of all discovered cryptographic assets | Scope of the scan. Regulators assess whether this aligns with the organisation's known infrastructure |
quantum_vulnerable_count |
Assets using quantum-vulnerable algorithms | The size of your PQC migration problem. Every asset here needs a replacement before the relevant deadline |
violations_found |
Number of compliance counterexamples | Specific assets that violate regulatory requirements. Each is listed in violations.txt with remediation guidance |
cbom_merkle_root |
Merkle root of the entire CBOM | Enables O(1) verification that the CBOM has not been modified. A regulator can verify this in under one second |
compliance_theorems |
Array of ASL VM execution results | One entry per regulatory framework. Each contains the theorem status (PROVED/COUNTEREXAMPLE) and execution trace |
tee_attestation |
TEE attestation quote (if available) | Hardware proof that the binary ran untampered in a confidential computing enclave |
signature |
SLH-DSA (NIST FIPS 205) signature | Post-quantum signature over the Merkle root and metadata. The cryptographic anchor of the entire report |
HNDL — Harvest Now, Decrypt Later — is the quantum threat model where encrypted data is captured today for decryption when quantum computers mature. VeriCrypt computes exposure using the multiplicative HNDL model from Rufino et al. (May 2026), which proves that additive scoring frameworks cannot capture the structural interaction between cryptographic vulnerability and operational exposure.
| Factor | What It Measures | Business Question Answered |
|---|---|---|
| Temporal Hazard | Ld > Ha condition — is the data's confidentiality lifetime longer than the attacker's quantum capability horizon? | "Will this data still be sensitive when quantum computers can break this algorithm?" |
| Crypto Vulnerability | Is the algorithm quantum-vulnerable? What NIST security level does it provide? | "Can a quantum computer break this algorithm at all?" |
| Operational Exposure | How widely is this asset deployed? How many systems depend on it? | "If this asset is compromised, how much of our infrastructure is affected?" |
| Defense-Attack Ratio | The organisation's defensive posture relative to attacker capability | "How well are we defending against HNDL attacks overall?" |
Additive models — used by every other PQC tool — treat vulnerability and exposure as independent scores and add them together. Rufino et al. (2026) proved this is mathematically inadequate: a highly vulnerable asset with zero exposure scores the same as a moderately vulnerable asset with moderate exposure. The multiplicative model correctly captures that a vulnerable asset protecting critical data is exponentially more dangerous than either factor alone. VeriCrypt is the only tool that uses the structurally-justified model.
The compliance confidence score is the central metric for regulatory submission. It is a multiplicative composite of three independent factors, each assessed separately and transparently.
| Factor | Range | What It Measures |
|---|---|---|
| P — Proof Confidence | 0.0–1.0 | Were the regulatory axioms successfully executed by the ASL VM? 1.0 = all frameworks PROVED. 0.7 = some theorems UNVERIFIED. 0.3 = degraded mode. |
| I — Inventory Confidence | 0.0–1.0 | How complete is the certificate inventory? Derived from: endpoint coverage, subnet coverage, cert transparency correlation, AD/LDAP reconciliation, HSM reconciliation, duplicate chain analysis, expected-vs-observed entropy, and network topology consistency. |
| R — Regulatory Axiom Confidence | 0.0–1.0 | What is the provenance of the axioms used? 1.0 = axioms reviewed and signed by a qualified regulatory expert. 0.8 = reviewed by internal compliance team. 0.5 = auto-generated without human review. |
| Phase | Threshold | Meaning |
|---|---|---|
| Phase 3 — Primary | ≥ 0.90 | .pqc report is the primary compliance evidence. Traditional documentation is supplementary. |
| Phase 2 — Parallel | ≥ 0.70 | .pqc report submitted alongside traditional documentation. Regulators can compare. |
| Phase 1 — Shadow | ≥ 0.50 | Reports generated but not submitted. Builds internal trust in the tool's output. |
The roadmap.md file contains a Phase 1/2/3 prioritised migration plan. Every asset is ranked by its Shapley value — a game-theoretic measure of that asset's marginal contribution to total system exposure.
| Phase | Timeline | Priority | EU Milestone |
|---|---|---|---|
| Phase 1 | 0–12 months | Highest Shapley value assets. Assets with HNDL exposure above threshold. | EU 2026 PQC transition start |
| Phase 2 | 12–24 months | Medium-priority assets. Infrastructure requiring coordinated migration. | EU 2030 critical infrastructure deadline |
| Phase 3 | 24–36 months | Low-priority assets. Assets with short data lifetimes. | EU 2035 completion target |
Each entry includes: asset ID, current algorithm, NIST PQC replacement recommendation, estimated migration complexity, and regulatory article references (DORA Art. 12.3, PQFIF Phase requirements, NCSC migration milestones).
The cbom.json file is a CycloneDX 1.7 Cryptographic Bill of Materials (ECMA-424). It lists every cryptographic asset as a component with standardised cryptoProperties.
| Property | Example | Meaning |
|---|---|---|
algorithm | RSA-2048 | The cryptographic algorithm |
keySize | 2048 | Key size in bits |
quantumSecurityLevel | 1 | NIST quantum security level (1–5). 1 = vulnerable, 5 = highest resistance |
mode | pkcs1v15 | Operational mode |
padding | oaep | Padding scheme |
curve | P-256 | Elliptic curve (if applicable) |
The CBOM is interoperable with any CBOM-consuming tool — SIEM platforms, GRC systems, asset management databases. PQC algorithm naming follows the CycloneDX Cryptography Registry (e.g., ML-DSA-87, SLH-DSA-256s).
VeriCrypt supports a three-phase deployment model aligned with the Lean-Agent Protocol's regulatory adoption framework. Each phase represents increasing trust in the tool's output and increasing regulatory reliance on .pqc reports.
| Mode | CLI Flag | Duration | What Happens |
|---|---|---|---|
| Phase 1 — Shadow Verification | --mode shadow |
3–6 months | VeriCrypt runs alongside existing compliance processes. .pqc reports are generated and stored but not submitted to regulators. The organisation builds trust in the tool's output, validates inventory completeness, and trains staff on report interpretation. |
| Phase 2 — Parallel Submission | --mode parallel |
6–12 months | .pqc reports are submitted alongside traditional documentation. Regulators can compare VeriCrypt's machine-verified findings with traditional audit results. Compliance confidence threshold: ≥ 0.70. |
| Phase 3 — Primary Compliance Artefact | --mode primary |
Ongoing | .pqc files become the primary evidence for cryptographic compliance. Traditional documentation becomes supplementary. Compliance confidence threshold: ≥ 0.90. This is the long-term operating mode for institutions that have fully adopted VeriCrypt. |
This is VeriCrypt's unique differentiator. Every other PQC compliance tool on the market is a black box — the compliance rules are hidden inside proprietary code. Banks, regulators, and legal counsel have no visibility into how regulations are encoded, no ability to audit the encoding, and no way to correct it if it is wrong.
VeriCrypt is the only system that makes the compliance rules fully transparent, auditable, and editable — and then formally verifies whatever rules are used against the bank's actual cryptographic inventory.
The bank uses Verity's axiom library as shipped, which encodes published regulatory instruments directly (DORA, NIST FIPS 203/204/205, NCSC, PQFIF). This is appropriate for the majority of engagements. The regulatory_axiom_confidence value reflects that the axioms faithfully implement public law. No customisation required.
The bank's compliance team or legal counsel edits the ASL axiom source files to reflect internal policy, a stricter jurisdictional interpretation, or a specific supervisory expectation. They recompile through seedc, run through seedvm, and produce a signed .pqc report proved against the exact rules the bank chose. The execution trace shows precisely which rules were applied — the regulator can see exactly what was proved.
Example: A German bank's legal counsel determines that DORA Art. 6 requires a stricter key size threshold than the standard axiom encodes. They edit the dora.asl source file, change min_rsa_key_size from 3072 to 4096, recompile, and re-run. The resulting .pqc report proves compliance — or identifies counterexamples — against the stricter German interpretation, with a complete verifiable trace.
A national competent authority, supervisory body, or industry consortium publishes their own ASL axiom specifications encoding their precise requirements. Banks load those axioms, run them through VeriCrypt, and produce a .pqc report proved against the regulator's exact rules. The regulator can replay the execution independently to confirm the proof.
Example: The ECB publishes an ASL axiom pack specifying exact cryptographic requirements for all supervised institutions. Every bank in the Eurozone loads the ECB axioms, runs VeriCrypt, and submits a .pqc report proved against the ECB's own rules. The ECB verifies each report independently using vericrypt-verify — offline, in under one second, with zero trust in the bank or Verity.
For a complete DORA cryptographic compliance submission, provide your regulator with:
report.pqc — The signed .pqc compliance artefact (primary evidence)cbom.json — CycloneDX 1.7 Cryptographic Bill of Materials (supplementary)roadmap.md — Phase 1/2/3 migration roadmap (supplementary)vericrypt-verify — The freely-distributable offline verifier binary (so they can independently verify)Your .pqc report maps findings to specific DORA articles:
| DORA Article | Requirement | How VeriCrypt Demonstrates Compliance |
|---|---|---|
| Art. 5 | ICT Governance | Report metadata establishes governance framework — scan timestamp, binary hash, operator identity |
| Art. 6 | ICT Risk Management Framework | HNDL exposure scores quantify cryptographic risk. Multiplicative model captures vulnerability-exposure interaction |
| Art. 9 | Protection of ICT Systems | ASL VM compliance theorems verify cryptographic protections satisfy regulatory requirements |
| Art. 10 | Detection | Counterexamples identify specific assets that violate requirements. Violations.txt provides remediation paths |
| Art. 12 | Crypto-Agility | Migration roadmap demonstrates Phase 1/2/3 plan. CMAP and PQCMM maturity scores show current state and trajectory |
| Art. 13 | ICT Incident Management | TEE attestation quote provides hardware proof of untampered execution. Evidence chain of custody documented |
| Art. 14 | Reporting | .pqc report is a self-contained, cryptographically signed, independently verifiable compliance artefact |
VeriCrypt supports concurrent compliance verification against multiple frameworks. A single scan can prove compliance against DORA (EU), PQFIF (US SEC), NCSC (UK), and NIST standards simultaneously. Each framework produces its own compliance theorem with independent status and execution trace.
When a regulator runs ./vericrypt-verify report.pqc, they see:
VERIFIED — scan at 2026-06-05T14:30:00Z, 2,437 assets, 12 violationsThe verification is O(1) — constant time regardless of scan size. The regulator needs no access to your systems, no trust in Verity, and no network connection. They trust only the embedded Verity public key and the mathematics of the Merkle proof and SLH-DSA signature.
Use the following structure to present VeriCrypt results to your board or risk committee. Every data point is directly extractable from your .pqc report.
vericrypt-verify. This is not a consultant's opinion. It is a mathematical proof.
| Term | Definition |
|---|---|
| ASL | Account Specification Language — Verity's DSL for regulatory axioms, compiled by seedc to VM bytecode, executed deterministically by seedvm |
| CBOM | Cryptographic Bill of Materials — CycloneDX 1.7 JSON document (ECMA-424) listing every cryptographic asset with properties and dependencies |
| CMAP | Crypto-Agility Maturity Assessment Program — four-level maturity model: Crawl → Walk → Run → Fly |
| Compliance Confidence | Multiplicative composite score: P × I × R. The central metric for regulatory submission |
| DORA | Digital Operational Resilience Act (EU 2022/2554) — mandates crypto-agility and ICT risk management for financial entities. Active enforcement began 2026 |
| HNDL | Harvest Now, Decrypt Later — quantum attack where encrypted data is captured today for decryption when quantum computers mature |
| NIST FIPS 203 | ML-KEM — Module-Lattice Key Encapsulation Mechanism. Post-quantum key encapsulation standard |
| NIST FIPS 204 | ML-DSA — Module-Lattice Digital Signature Algorithm. Post-quantum signature standard |
| NIST FIPS 205 | SLH-DSA — Stateless Hash-Based Digital Signature Algorithm. Post-quantum signature standard used for .pqc report signing |
| PASETO v4 | Platform-Agnostic Security Token — capability-token format used for VeriCrypt licence keys. v4.public uses Ed25519 signatures |
| .pqc report | VeriCrypt's output artefact: a self-contained, cryptographically signed, Merkle-proofed compliance artefact containing CBOM, proofs, roadmap, and TEE attestation |
| PQC | Post-Quantum Cryptography — cryptographic algorithms designed to be secure against quantum computer attacks |
| PQCMM | Post-Quantum Cryptography Maturity Model — PKI Consortium five-level framework adopted by industry and regulators |
| PQFIF | Post-Quantum Financial Infrastructure Framework — US SEC guidance for financial market infrastructure |
| seedc | ASL compiler — compiles regulatory axiom source files (.asl) to deterministic VM bytecode (.aslb) at build time |
| seedvm | ASL virtual machine — executes compiled bytecode deterministically at scan time, producing a verifiable schedule trace |
| Shapley Value | Game-theoretic attribution method that computes each asset's marginal contribution to total system exposure. Sum of all Shapley values equals total exposure |
| SLH-DSA | Stateless Hash-Based Digital Signature Algorithm (NIST FIPS 205) — quantum-resistant signature scheme. 256-bit classical security, 128-bit quantum security |
| TEE | Trusted Execution Environment — hardware-enforced isolated compute (Intel TDX or AMD SEV-SNP). Provides cryptographic proof that the binary ran untampered |
| VeriChain | Verity's Merkle-proofed audit chain — provides RFC 6962 Signed Tree Heads with consistency proofs and non-equivocation guarantees |