The field, where it's going, and where we're aligned.

ML-KEM side-channel hardening

Masking schemes and randomised invalid-coefficient countermeasures to defend ML-KEM implementations against side-channel-assisted chosen-ciphertext attacks. Active in both academic and standards-validation contexts.

Hybrid KEM combiners against lattice break

Constructions that pair a lattice KEM (ML-KEM) with a structurally different KEM (FrodoKEM, code-based) so IND-CCA2 security holds if either assumption survives. Relevant to QNSP Maximum/Government tier composition.

Composite PQC certificate chains at scale

Hybrid X.509 certificates carrying both a classical and a PQC signature. Open engineering questions: chain validation cost, OCSP/CRL size, root-CA migration sequencing. Standards work near publication.

PQ public-key validation / linting

Formal lint rules that detect malformed or risky ML-KEM and ML-DSA public keys at the protocol layer. Connects to validation patterns we already exercise in our ACVP harness.

Microarchitectural agility for ML-KEM / ML-DSA

Moving beyond hand-tuned assembly so PQC primitives can be retargeted to new microarchitectures (ARMv9 SVE2/SME, RISC-V V) without losing performance. Affects QNSP's multi-architecture deployment posture.

FIPS 206 (FN-DSA) constant-time FP sampling

The open engineering issue blocking FIPS 206 finalisation. Anyone shipping FN-DSA today is shipping a pre-FIPS implementation; constant-time floating-point sampling under formal scrutiny remains hard.

PQC on constrained devices

HSM-bound ML-DSA-87 and ML-KEM-1024 fit, key-handling, and side-channel posture on embedded / IoT / smartcard targets. Standards work in IETF PQUIP near publication.

Deterministic-input KEM bindings to liboqs

QNSP maintains @cuilabs/liboqs-native with Node.js bindings for OQS_KEM_keypair_derand + OQS_KEM_encaps_derand. The only publicly-available JS interface to seed-controlled KEM operations aligned with FIPS 203 §6. Unblocks reproducible ACVP testing in JavaScript ecosystems.

Dual-provider ACVP harness pattern (open source)

The harness source (apps/web/scripts/run-nist-acvp-conformance.ts) and the evidence file format (schema v2, SHA-3-256 digest binding) are public. Researchers and standards bodies can adopt the pattern without dependency on a centralised CSTL.

Auditable entropy-chain documentation pattern

/trust/entropy publishes a three-chain entropy model (CSPRNG, HSM DRBG, optional QRNG mix-in) with NIST SP 800-90A/B/C citations and per-vendor HSM FIPS 140-3 records. Honest caveat: cryptoEntropySource is a declarative contract today; per-operation entropy routing is on roadmap.

OQS_SIG_keypair_derand upstream proposal

PR opened against open-quantum-safe/liboqs to add deterministic-input bindings for ML-DSA / SLH-DSA / FN-DSA / MAYO / CROSS / UOV / SNOVA. Closed unmerged (2026-01-19) on policy grounds — no formal FIPS spec basis for seed-driven signature key generation. We cross-verify at runtime instead; signature derand is not in our roadmap until upstream policy changes.

HQC integration

Blocked on: NIST FIPS draft + liboqs production-ready build

HQC was selected by NIST in March 2025 as the fifth standard. liboqs ships it but disabled-by-default after CVE-2025-52473. We track upstream and integrate on stable hardened build with NIST-confirmed parameter sets.

FN-DSA / Falcon ACVP coverage

Blocked on: NIST FIPS 206 finalisation + ACVP test vectors published

FIPS 206 finalisation is pending; the constant-time floating-point sampling issue remains open. Once NIST publishes vectors and a stable spec, we extend the ACVP harness to cover FN-DSA-512 and FN-DSA-1024 with the same dual-provider validation model.

Composite X.509 certificate chains

Blocked on: RFC publication from draft-ietf-lamps-pq-composite-sigs-19

Composite ML-DSA signatures for hybrid X.509 PKI are in the IETF RFC editor queue. Once published, we add composite-signature support to KMS code-signing and certificate-issuance paths.

Per-operation entropy-source routing

Blocked on: Internal engineering

Today the cryptoEntropySource field is a declarative contract per tenant. Roadmap target: per-operation routing so a tenant can require, e.g., HSM DRBG for KMS sign and QRNG-mixed CSPRNG for vault encrypt within the same workflow.

FIPS 140-3 module-level validation

Blocked on: NVLAP-accredited CSTL engagement

CAVP algorithm validation is the prerequisite QNSP is working through first. Module-level FIPS 140-3 validation requires CSTL submission and is a separate process from algorithm conformance. Customer-managed HSMs (Thales Luna / Entrust nShield / AWS CloudHSM / etc.) already provide FIPS 140-3 root of trust on Maximum and Government tiers.