Home / Sample briefs / Security
Anatomy of a CISO brief.
An Illustrative end-to-end Veriqa migration memo for a synthetic regulated organization. Same format and discipline a real PQC engagement produces.
Brief metadata.
Every Veriqa brief opens with the target, an ID, the date of grading, the engagement, and the methodology version pinned to that grading. So a verdict you read six months from now is re-readable against the rules that produced it.
The call, stated once.
A well-run PQC posture isn't usually a Proceed — it's a Monitor while a phased migration proceeds against a known clock. The verdict states which call this brief makes and why.
Monitor
Cryptographic inventory complete; classical-baseline TLS 1.3 + RSA inventory mapped; migration to ML-KEM + ML-DSA scoped over 18 months; high-shelf-life data prioritized for first-wave.
Public verdict vocabulary: Proceed / Monitor / Require further diligence. Verdict is decision-support; the reviewer gate is enforced in software before a brief leaves draft. Illustrative
The questions a CISO brief answers.
A brief that tries to answer everything settles nothing. The frame is the contract: these are the questions on the table; anything outside is acknowledged as out of scope, not silently graded.
-
What is the harvest-now-decrypt-later exposure?
For each long-shelf-life data class, estimate the window in which captured ciphertext could be decrypted under a future cryptographically relevant quantum computer. Drives first-wave prioritization.
-
Where are RSA / ECDH / RSA-PSS in the stack?
A complete inventory of asymmetric key exchange and signature primitives across TLS, PKI, code-signing, VPN, HSM-rooted keys and third-party integrations. No claim of "we're modern" without the list.
-
What is the data shelf-life that governs priority?
Map data classes to retention obligations (regulatory, contractual, business-rationale). Long-shelf-life key exchange moves first; short-lived session traffic can wait inside the migration window.
-
What is the FIPS 203/204/205 path?
For every flagged primitive, the named NIST target family: ML-KEM (FIPS 203) for KEMs, ML-DSA (FIPS 204) for signatures, SLH-DSA (FIPS 205) as a lattice-independent signature fallback for high-assurance and firmware.
-
What is the crypto-agility readiness?
Can primitives be swapped by configuration rather than re-engineering? The next transition is cheaper only if this one builds the swap-points. Measured per surface: TLS termination, PKI, HSM, code-signing, embedded fleet.
Three scores, each with a reason.
Veriqa never reports a single opaque number. The scores are a transparent rule-based heuristic from features of the graded evidence — not a sentiment score, not a statistically validated model.
What this means: we know more about what to do than how fast we can do it. Inventory is complete; cutover capacity and HSM crypto-agility are the rate-limiting unknowns.
What this means: the HNDL clock is running. Long-retention policy claims (PHI-adjacent, financial records, ID artifacts) put captured TLS today inside the decryption window of a plausible future CRQC.
What this means: PQC is standardized; little hype here. The risk is operational (migration cost, breakage, vendor readiness), not language inflation around "quantum advantage".
Score values are Illustrative — generated to demonstrate the rubric on a synthetic target, not drawn from a real assessment.
Every primitive, next to its NIST successor.
A PQC plan that lists targets but not the primitives it replaces is unreadable. The baseline table is the load-bearing artifact: current cipher suite on the left, NIST target on the right, status in the margin.
| Component | Current cipher suite | PQC migration target | Problem size | Status |
|---|---|---|---|---|
| TLS 1.3 handshake customer + B2B endpoints |
RSA-2048 key transport / ECDHE-P256 | ML-KEM-768 (FIPS 203) | ~4,200 TLS terminators inventoried; ~340 require vendor firmware update | Migration scoped |
| X.509 signatures internal PKI, intermediates |
RSA-2048-PSS | ML-DSA-65 (FIPS 204) | 2 root CAs · 9 intermediates · ~58k issued certs | Migration scoped |
| Long-term archives claims, policy records (20-year retention) |
AES-256 (symmetric) | No migration required — AES-256 is quantum-resistant at this key size | ~14 PB encrypted at rest | On-track |
| Firmware signing field telematics + sensor fleet |
ECDSA-P256 | ML-DSA-44 or SLH-DSA-128s (lattice-independent fallback for long-life devices) | ~71k devices; 8-12 year service life | At-risk |
| VPN / IPsec site-to-site + remote access |
IKEv2 with ECDH-P256 | ML-KEM-768 hybrid (FIPS 203, hybrid-mode where vendor supports it) | ~110 site-to-site tunnels · ~4,800 remote-access clients | Inventoried |
| Code-signing (internal builds) CI/CD provenance |
RSA-3072 | ML-DSA-65 (FIPS 204), with SLH-DSA-256s as compromise-resilient fallback | ~14 signing keys across 6 build farms | Inventoried |
Mappings reflect the NIST FIPS 203/204/205 target families finalized August 2024. AES-256 is symmetric and quantum-resistant at sufficient key size — symmetric primitives are confirmed in use, not migrated. Status labels are planning guidance, not guarantees. Illustrative
Every sub-claim, its source, its confidence.
The evidence table is the brief. A verdict is a function of what's in it, not an opinion layered on top.
| Sub-claim | Source | Confidence | Notes |
|---|---|---|---|
| FIPS 203 (ML-KEM) is the standard target for RSA/ECDH key exchange. | NIST FIPS 203 (Aug 2024) — csrc.nist.gov | high | Published standard; lattice-based (ML-KEM, derived from CRYSTALS-Kyber). |
| FIPS 204 (ML-DSA) is the standard target for RSA-PSS / ECDSA signatures. | NIST FIPS 204 (Aug 2024) — csrc.nist.gov | high | Published standard; lattice-based (ML-DSA, derived from CRYSTALS-Dilithium). |
| FIPS 205 (SLH-DSA) is a stateless hash-based signature, lattice-independent fallback. | NIST FIPS 205 (Aug 2024) — csrc.nist.gov | high | Used here for long-life firmware where a non-lattice signature is prudent. |
| CNSA 2.0 sets transition expectations for NSS-adjacent systems through 2033. | NSA CNSA 2.0 Cybersecurity Advisory (Sep 2022, updated) | high | Atlas Federal is not NSS, but contractual flow-downs cite CNSA 2.0 dates as a planning anchor. |
| Cryptographic inventory complete across 4,200 TLS terminators and 9 intermediates. | Atlas Federal internal audit, May 2026 (synthetic source SRC-IA-014) | medium | Synthetic. Coverage gaps: embedded fleet (see Missing Evidence). |
| Symmetric estate (AES-256, SHA-256+) confirmed in use; no quantum-driven migration required. | Atlas Federal internal audit (synthetic) · cross-checked against NIST PQC FAQ | high | Grover gives only a √ speedup; AES-256 retains a sufficient effective key size. |
| HNDL exposure window opens for 20-year-retention records captured today. | NIST PQC program guidance · planning heuristic (no regulatory figure) | medium | Threshold is a planning heuristic, not a regulatory deadline; restated to leadership as such. |
| HSM vendor roadmap supports ML-KEM in firmware track Q4 2026. | Vendor roadmap statement (synthetic SRC-VR-008) | low | Forward-looking; not contractually committed. Reflected in plan as a dependency, not a fact. |
Sources marked synthetic are fabricated for this Illustrative brief. NIST FIPS references are real and current as of the methodology version above. Illustrative
What we couldn't see — named.
A brief that lists only what it knows is half a brief. The missing-evidence list is what would change the verdict, and what the validation plan is built to close.
- Embedded device crypto inventory incomplete for legacy telematics fleet. ~9k of ~71k devices unverified at firmware level; could include ECDSA-P256 with no field-upgradable signing path.
- HSM crypto-agility unverified. Current HSMs are FIPS 140-2 Level 3 but PQC algorithm support depends on vendor firmware track Q4 2026 (low confidence). No contractual commitment.
- No measured PQC performance benchmark on current load. ML-KEM handshake latency and ML-DSA signature size impact on TLS termination throughput not measured against production traffic; estimates only.
- Third-party integrations not inventoried for downstream PQC support. ~140 vendor-hosted endpoints exchange TLS with Atlas; their PQC roadmaps are unknown.
- Code-signing key custody review pending. Six build farms; rotation cadence and HSM-bound vs. file-bound key state not fully audited.
- Mainframe PKI (legacy core insurance system) excluded from this brief. Scoped as a separate engagement; no claim is made about it here.
What the next 90 days look like.
A phased 90-day plan to close the gaps above and de-risk the 18-month migration. Each step has a deliverable; nothing is "do more research".
-
1
Days 0–30 · Complete the inventory
Finish embedded-fleet firmware crypto inventory (close the ~9k device gap). Issue a vendor questionnaire to the top-30 third-party endpoints on their FIPS 203/204 timelines. Deliverable: a single, signed-off cryptographic inventory, structured and machine-readable.
-
2
Days 30–60 · Benchmark and contract
Run a measured PQC performance benchmark on representative TLS terminators (ML-KEM-768 hybrid) and signature verification (ML-DSA-65) under production-shaped load. Convert HSM vendor PQC roadmap into a contractual milestone with a remediation clause. Deliverable: a benchmark report and a HSM addendum.
-
3
Days 60–90 · First-wave cutover plan
Lock the first-wave cutover: hybrid TLS on the top-decile harvest-now-exposed endpoints; rotate the highest-issuance intermediate CA to ML-DSA-65; pilot ML-DSA-44 firmware signing on one telematics SKU. Deliverable: a board-ready cutover plan with rollback, success criteria and reviewer sign-off.
Honest about the gate.
The reviewer gate is what separates a draft from a delivered brief. The discipline applies to this sample in exactly the form it applies to a real one.
Every Veriqa brief stays in draft until an internal reviewer approves it against a written credential standard. The gate is enforced in the rules engine, not as an editorial nicety — a brief cannot leave draft state without passing it.
We do not yet represent outside expert review of every report. Independent cryptographic review — for example, by a domain specialist or your own crypto bench — is recommended before you act on any plan, especially for primitives outside this brief's scope (mainframe PKI, regulated workloads).
Bring us your cryptographic inventory.
Tell us the size of your estate, the regulatory clocks you face and the shelf-life of the data you protect. We respond with scope and a fixed price within two business days — and the brief you receive looks like the sample above.