QNSI
Start building free
Platform
Platform overviewCapabilitiesAlgorithm catalogWhy QNSI
Solutions
Solutions by Use CaseSolutions by IndustryAssessment & migrationPQC migration guideCompare platforms
Developers
DocumentationDeveloper hubBuild patternsAI assistants (MCP)Public source & evidence
Pricing
Company
About HEOSSIChangelogContactKnowledge CentreResearchNews & Insights
TrustHub
TrustHub overviewSecurity programCompliance mappingPublic evidenceService statusResponsible disclosureLegal & Policy LibraryTerms of ServicePrivacy PolicyData Processing AddendumSub-processors
Start building free

Research

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

QNSI's research surface is field-aligned, not self-referential. Below: what NIST is finalising, what IETF is standardising, where the academic field is moving, where we have positioning leverage, what we contribute back upstream, and what's on roadmap with the upstream dependency cited for each item. Audit refreshed 2026-10-28 against NIST CSRC, IETF datatracker, IACR ePrint.

6NIST milestones tracked
10IETF drafts / recent RFCs
7Active research themes
5QNSI positioning levers

At a glance

The platform in numbers

Derived from the same single-source facts the policy engine, ACVP evidence and service registry use; charts state scope, not deployment proof.

  • 90PQC algorithms27 KEM · 63 signatures · 14 families
  • 4Crypto-policy tiersNIST floors 1 / 3 / 5 / 5
  • 18Manifest-declared servicessource inventory, not runtime proof
  • 435/435ACVP vectors (noble)liboqs 240/240
  • 3Compliance frameworks17 mapped controls
  • 8HSM connectorsPKCS#11 and REST custody paths
Open the evidence hub →

Publications

Author-run research, with its boundary stated

Peer-review status, independent reproduction and production assurance are separate questions. Each entry states what the artifact does and does not establish.

A Reproducibility Protocol for Cross-Implementation Evaluation of Post-Quantum ACVP Test Vectors

Christopher M. Frost · arXiv (cs.CR, cs.SE) · 2026-08-13

Protocol v2 evaluates three public ML-KEM implementations (@noble/post-quantum 0.7.0, liboqs 0.16.0, Go 1.26.4) against a pinned public ACVP corpus. Across three repetitions it produced 2,160 base records: all 1,650 declared executable evaluations matched the NIST oracle, all 510 unsupported records matched Go's predeclared capability boundary, and pairwise agreement was complete on every executable overlap (720/720 noble-liboqs; 210/210 for each Go pairing). Three frozen controls exercised byte comparison, verdict comparison and malformed-response separation, each with its predeclared outcome.

Scope: Establishes bounded author-run repeatability and exposes differing deterministic/validation surfaces between public ML-KEM packages. Independent external reproduction remains unobserved. It does not establish certification, exhaustive correctness, side-channel resistance, secure integration or production assurance.

NIST

What's actively in flight at NIST

6 live milestones from the NIST PQC programme, refreshed 2026-10-28: Round 3 status, FIPS 206 draft status, HQC selection, and the IR 8547 transition schedule.

Active · NIST IR 86102026-05-14

Signature Onramp - Round 3 in progress ↗

NIST advanced nine candidates to Round 3 (FAEST, HAWK, MAYO, MQOM, QR-UOV, SDitH, SNOVA, SQIsign, UOV); HAWK has since been withdrawn, leaving eight active, and CROSS did not advance from Round 2. Round 3 page refreshed 2026-10-13. All remain candidates, not approved standards.

Standardisation underwayPending

FIPS 206 (FN-DSA / Falcon) - open ↗

Constant-time floating-point sampling is the unresolved engineering issue blocking finalisation. Any pre-FIPS implementation shipped today carries side-channel disclosure surface. FIPS 206 remains an initial public draft; the NIST PQC project page (last updated 2026-08-05) still lists FN-DSA standardisation as underway, with no publication date announced.

Selected · March 2025Pending

HQC - selected backup KEM, draft pending ↗

NIST selected HQC as the code-based backup KEM in March 2025. The draft standard has not been published; HQC stays an explicit diversity option and is never presented as finalized or as a default.

Final · October 20262026-10-27

IR 8547 - classical transition schedule ↗

NIST's final report keeps the two general dates: deprecate quantum-vulnerable algorithms after 2030, disallow them under NIST standards after 2035. It also states that this window does not move the earlier federal deadlines - high value assets and high impact systems must adopt PQC key establishment by 31 December 2030 and digital signatures by 31 December 2031 (EO 14412 + OMB M-26-15), with TLS 1.3 support required by 2 January 2030 (EO 14306).

Final · Sep 20252025-09-18

SP 800-227 - KEM guidance ↗

NIST's final recommendations for secure KEM use, including implementation, key-establishment, and protocol-design considerations.

Held2025-09-24

6th NIST PQC Standardization Workshop ↗

NIST's annual PQC technical workshop covering algorithm performance, side-channel posture, and migration evidence. Slides + presentations published.

IETF

Drafts and recent RFCs we track

Active work in PQUIP, LAMPS, TLS. 10 entries - including RFC 9935 (ML-KEM in CMS, published March 2026) and the hybrid TLS 1.3 codepoint that ships in OpenSSH, OpenSSL, and the major browsers.

WGDraft / RFCState
LAMPSRFC 9935 - ML-KEM certificates ↗Published · Mar 2026
LAMPSRFC 9936 - Use of ML-KEM in CMS ↗Published · Mar 2026
LAMPSRFC 9881 / 9882 - ML-DSA in CMS + Algorithm IDs ↗Published · Oct 2025
LAMPSRFC 9909 / 9814 - SLH-DSA in CMS ↗Published · 2025
TLSHybrid ECDHE-MLKEM Key Agreement for TLS 1.3 ↗RFC Editor Queue (Proposed Standard)
TLSUse of ML-DSA in TLS 1.3 ↗Publication Requested · May 2026
LAMPSComposite ML-DSA for X.509 PKI ↗RFC Editor Queue
LAMPSComposite ML-KEM for X.509 PKI ↗Submitted to IESG
PQUIPAdapting Constrained Devices for PQC ↗Publication Requested
PQUIPRFC 9794 - Terminology for Hybrid PQC ↗Published · Jun 2025

Industry deployment

What's already live in product

The PQC migration is no longer aspirational at the infrastructure layer. Below: seven concrete deployments at OpenSSH, OpenSSL, AWS, Microsoft, Cloudflare, Chrome - each with an announcement URL and date.

2025-04-09

OpenSSH 10.0 - ML-KEM hybrid default KEX ↗

`mlkem768x25519-sha256` became the default key-exchange in OpenSSH 10.0 (initial support landed in 9.9, Sept 2024). The most widely deployed PQC key-exchange on the internet today.

2026-05-14

AWS PQC Readiness Scanner ↗

Classifies ALB/NLB/API-Gateway TLS configs against PQC-ready policies (Tier 1/2/3). Surfaces which AWS endpoints can already negotiate hybrid PQC TLS and which need security-policy updates.

2026-04-30

Cloudflare hybrid PQC IPsec - GA ↗

Cloudflare One IPsec tunnels now use hybrid ML-KEM by default. Confirmed interop with Cisco 8000 Series (IOS-XR 26.1.1+) and FortiOS 7.6.6+. Distinct from the older RFC 9370 path Palo Alto still uses.

2026-04-07

Cloudflare - full-platform PQ target 2029 ↗

Roadmap to migrate every connection type to PQ by 2029. >65% of human HTTPS traffic was already PQ-encrypted in early 2026; the gap is authentication (server certificates), not key agreement.

2025-11

Microsoft - Windows 11 + Server 2025 GA PQC ↗

Built-in ML-KEM and ML-DSA via SymCrypt under the Quantum Safe Program. Microsoft 365 / Azure full transition targeted by 2033.

2025-04-08

OpenSSL 3.5.0 LTS - native ML-KEM / ML-DSA / SLH-DSA ↗

First mainline OpenSSL release with native PQC. Default TLS supported-groups now prefers hybrid PQC KEM groups. Distros (Debian, RHEL, Ubuntu) cut over through 2025-2026.

2025

Chrome - X25519MLKEM768 (codepoint 0x11EC) ↗

Chrome 131+ replaced experimental Kyber (0x6399) with the standardised hybrid codepoint. Aligns with Cloudflare, Google front-ends, and Akamai PQC posture.

Field themes

Active research questions we track

Seven themes from the current academic + standards conversation. Each cites at least one IACR ePrint paper or IETF draft from 2025-2026.

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 QNSI 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 QNSI'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.

QNSI positioning

Where we have leverage in the field

Five architectural decisions shipping on the platform today that give QNSI credible standing in PQC research conversations. Each cites a source-of-truth file in the open codebase.

Dual-provider cross-verification across 18 algorithms

Maximum and Government policy sources can require dual-provider verification through liboqs and @noble/post-quantum. Complete runtime coverage, comparison semantics, failure handling, and recording across every cryptographic operation remain NOT VERIFIED.

packages/cryptography/src/cross-verification.ts · packages/security/src/crypto-policy.ts TIER_PROVIDER_STRATEGY

Reproducible dual-provider ACVP harness

The ACVP runner drives both providers against canonical NIST vectors with deterministic seeds via OQS_KEM_keypair_derand / OQS_KEM_encaps_derand. Outputs are bound by SHA-3-256 digest. The harness source is public; auditors can rerun the validation independently.

apps/web/scripts/run-nist-acvp-conformance.ts · /verify/conformance · /pqc-evidence/acvp-latest.json

Crypto-policy tier enforcement at scale

Four source-defined tiers (default / strict / maximum / government) specify which PQC algorithms and parameter sets are allowed per tenant. KMS, vault, and audit paths integrate the policy contract; complete production enforcement across every route and downgrade attempt remains deployment-specific and NOT VERIFIED.

packages/security/src/crypto-policy.ts (TIER_POLICIES + validateCryptoMaterial)

SHA-3-512 Merkle audit log signed with ML-DSA

The audit source defines SHA-3-512 Merkle aggregation and ML-DSA checkpoint-signing paths. Complete event ingestion, historical reconstruction, published-root availability, and verification across every key, vault, and policy route remain NOT VERIFIED without deployment evidence.

apps/audit-service/src/services/merkle-tree.ts

CBOM differential tracking with drift detection

CycloneDX-compatible Cryptographic Bills of Materials are emitted per service, aggregated per tenant, and compared release-over-release. Tenants see when an algorithm class rotated, when a tier promoted, or when a connector surfaced a legacy RSA asset. Operationalises NIST's CBOM standardisation work.

apps/crypto-inventory-service/src/services/cbom-aggregator.ts · apps/edge-gateway/src/services/cbom-service.ts

Contributions back to the field

What we ship upstream

Open-source contributions, public artifacts, and an honest record of what we proposed and what upstream declined.

Shipped

Deterministic-input KEM bindings to liboqs

QNSI maintains @heossihq/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.

Shipped

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.

Shipped

Auditable entropy-chain documentation pattern

/security/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.

Declined upstream

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.

Honest limits

What we don't do

Where we depend on the field, not contribute to it. Stated explicitly so prospects, auditors, and academic partners can calibrate.

Formal verification of PQC algorithms

Theorem-prover proofs (Coq, Isabelle, K) of ML-KEM / ML-DSA correctness against FIPS spec are academic-lab territory. QNSI ships implementation validation (ACVP), not formal proof. We consume those proofs as they're published.

Lattice cryptanalysis & parameter selection

Why ML-DSA-87 for Government tier (not 65) - that decision is made by NIST based on lattice-hardness research. QNSI enforces the recommendations, not their derivation. Cryptanalysis (lattice reduction, quantum speedups, structural breaks) belongs to academic groups and the NIST analysis teams.

Hardware design & side-channel labs

QNSI detects side-channel surface empirically through dual-provider cross-verification (one provider fast, the other potentially leaky - drift flagged) but we do not run EM / power-analysis labs or propose novel hardware countermeasures. We rely on upstream implementations' mitigations.

Roadmap

On roadmap - with upstream dependencies cited

Items we are tracking for integration. Each item names what we're waiting on so the dependency is transparent. We do not ship pre-finalised algorithms or pre-published RFCs into customer-facing tiers.

On roadmap

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.

On roadmap

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.

On roadmap

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.

On roadmap

FIPS 140-3 module-level validation

Blocked on: NVLAP-accredited CSTL engagement

Algorithm conformance and module validation are separate evidence domains. A customer-managed HSM may provide a vendor-validated root of trust only when the exact model, firmware, mode, certificate scope, and QNSI integration have been qualified for that deployment.

Field events

Where the cryptography field meets

The conferences QNSI tracks. Adoption signals, attack research, parameter-set debate, and standards work happen here.

Real World Crypto 2026 ↗

Mar 9-11, 2026 · Taipei, Taiwan

PQCrypto 2026 (17th edition) ↗

Apr 14-16, 2026 · Saint-Malo, France

EUROCRYPT 2026 ↗

May 10-14, 2026 · Rome, Italy

IEEE Symposium on Security & Privacy 2026 ↗

May 18-20, 2026 · San Francisco, CA

CRYPTO 2026 (46th) ↗

Aug 17-20, 2026 · Santa Barbara, CA

CHES 2026 (Hardware & Embedded Crypto) ↗

Oct 11-15, 2026 · Antalya, Türkiye

ASIACRYPT 2026 (32nd) ↗

Dec 7-11, 2026 · Hong Kong

Open Quantum Safe

liboqs 0.16.0 · released 2026-07-09

QNSI depends on the Open Quantum Safe project (a Linux Foundation PQC Alliance member). We track their release notes and CVE feed.

  • ›liboqs 0.16.0 (2026-07-09): removes deprecated SPHINCS+ algorithm identifiers, updates HQC to the 20250822 specification, and keeps SLH-DSA as the FIPS 205 hash-signature family QNSI maps first.
  • ›liboqs 0.15.0 (2025-11-14): integrated SLH-DSA from pq-code-package/slhdsa-c, restored NTRU, removed Round-3 Dilithium implementations, added DeriveEncapsulation, integrated ICICLE-PQC ML-KEM. SPHINCS+ deprecated in favour of SLH-DSA (replacement in 0.16.0).
  • ›liboqs 0.14.0 (2025-07-10): ML-KEM updated to PQ Code Package's mlkem-native v1.0.0, added SNOVA, AVX-512VL SHA3/SHAKE. CVE-2025-52473 - HQC compiler optimisations disabled to avoid secret-dependent branches.
  • ›liboqs 0.13.0 (2025-04-16): deterministic key-gen API for KEMs added (the basis for our ACVP harness derand path), GPU-accelerated ML-KEM via Nvidia cuPQC, UOV added.
  • ›oqs-provider 0.10.0+: aligns with OpenSSL 3.5.0 - disables ML-KEM/ML-DSA when OpenSSL provides them natively. QNSI follows the same handoff pattern.
liboqs releases ↗Open Quantum Safe project ↗

Responsible disclosure

Vulnerability disclosure policy

Coordinated disclosure aligned with NIST and CISA practice. Active since 2026-01-01.

AcknowledgementWithin 48 hours of receiptInitial assessmentWithin 5 business daysResolution target90 days (Critical / High) · 180 days (Medium / Low)Advisory ID schemeQNSI-SA-YYYY-NNNSafe harbourGood-faith research conducted under this policy will not be pursued through legal channels. Proof-of-concept only; no DoS, no data exfiltration beyond what's needed to demonstrate.Disclosed advisoriesNone to date. Policy active since 2026-01-01; coordinated disclosures will be published with full reproduction details under QNSI-SA-YYYY-NNN.

Next

Verify the evidence, talk to the security team

NIST ACVP conformance →Performance benchmarksCleared research evidenceSecurity hubContact the security team