Evaluation criteria

Passes known-answer tests and test vectors for the final standardised parameter sets.

• ●

  ML-KEM keygen, encapsulation and decapsulation against FIPS 203 vectors.

• ●

  ML-DSA keygen, sign and verify against FIPS 204 vectors.

• ●

  SLH-DSA sign and verify against FIPS 205 vectors, where the vendor claims support.

• ●

  Decapsulation on a malformed or adversarial ciphertext fails closed, rather than returning a usable shared secret.

Ships the final standardised parameter sets — not draft or round-3 Kyber / Dilithium naming and parameters.

• ●

  Marketing and documentation use the standardised names, so a buyer can tell which is implemented.

• ●

  Where a pre-final implementation is still shipped for compatibility, it is labelled as such rather than presented as conformant.

A conformance claim against a non-NIST national standard is checked against that body's own published document, never silently mapped onto NIST's.

Algorithm identifiers and OIDs match the standard the vendor claims.

• ●

  Certificate and protocol encodings use the registered identifiers, not vendor-private ones.

• ●

  Where a vendor-private identifier is unavoidable, it is documented and its scope stated.

Algorithm-level validation by an external programme, where one exists for the algorithm in question.

Any deviation from standardised parameters is disclosed by the vendor rather than discovered by a reviewer.

Keygen / encapsulate / decapsulate and keygen / sign / verify timings, measured rather than quoted.

• ●

  Reported with a distribution, not a single mean — median, p95 and p99 at a stated iteration count.

• ●

  Measured on named hardware, at a stated liboqs or library version, traceable to a reproducible public run.

Measured on more than one architecture (x86-64 and ARM) so the numbers travel to the reader's estate.

Handshake-level cost measured in situ, not inferred by adding primitive timings together.

Key, ciphertext and signature sizes checked against the standard rather than taken from the datasheet.

Operations per second under sustained load, and the point at which the device saturates.

Where an implementation is not independently testable, that is recorded as not assessed — never inferred from the vendor's own published figures, and never scored as zero.

Raw algorithm library only, versus integration into TLS, QUIC, SSH or IPsec.

• ●

  Which protocols are supported, and at which layer the vendor's code sits.

• ●

  Whether integration is a supported product or a reference sample.

Hybrid key exchange supported, and available in production rather than behind a branch or a flag.

Post-quantum authentication — signatures in the handshake and in the certificate chain — not only key exchange.

• ●

  Key exchange alone addresses harvest-now-decrypt-later. It does not address a forged chain.

• ●

  Where PQ authentication is not yet offered, whether the vendor says so plainly.

PQC and hybrid certificate issuance actually reaches a usable chain, including intermediates and revocation.

Integration is documented for practitioners — configuration, supported suites, failure modes — not only announced in a press release.

Algorithms are selectable through configuration rather than compiled in.

More than one algorithm family is supported for the same function, so a break in one is survivable.

• ●

  Lattice and hash-based signatures both available, rather than a single lattice bet.

• ●

  For KEMs, whether anything other than ML-KEM is offered.

A documented path exists for replacing an algorithm after deployment, including what happens to data already protected.

Hybrid and classical-only modes can both be expressed, since jurisdictions differ on which is required.

Cryptographic inventory or bill-of-materials output is available in a machine-readable form.

Algorithm changes are deliverable as a firmware update to devices already in the field.

Performance claims are accompanied by actual numbers rather than adjectives.

• ●

  "Minimal impact", "negligible overhead" and similar phrasing, with no figure attached, scores as no claim at all.

Third-party or independent validation is cited, and the citation is not circular — a source that itself cites the vendor does not count.

Test conditions behind any published figure are stated: hardware, software versions, iteration counts, and what was being measured.

Known limitations are disclosed by the vendor rather than found by a reviewer.

Technical claims are attributed to named people rather than to the company in the abstract.

A reader with the same hardware could in principle reproduce the vendor's published figure from what is published.

FIPS 140-3 validation status, checked against the public CMVP Validated Modules list.

Whether a module is validated, in process, or neither — three different states, reported as such and never collapsed into “FIPS compliant”.

The certificate's scope is read, not just its existence: what was validated is frequently narrower than what is marketed.

• ●

  Which module, which version, and which operational environment the certificate actually covers.

• ●

  Whether the PQC algorithms specifically are in scope, or only the classical ones.

Common Criteria evaluation status, with protection profile and assurance level, where applicable.

Browser and OS root-program inclusion, and standing in good order with the relevant program requirements.

Sector-specific certifications relevant to the vendor's stated market.

Where CNSA 2.0 alignment is claimed, the claim matches the suite's actual algorithm and timeline requirements.

Pricing is published, indicative, or contact-only — recorded as found, without treating contact-only as disqualifying.

Trial availability and evaluation licensing: can an engineer try it before a sales conversation?

Contract flexibility — term length, exit terms, and whether migration off the product is contemplated.

Migration support offered, and whether it is included or a separate professional-services line.

Documentation is sufficient to deploy without a sales engagement.

Support model and response commitments are stated, including who carries the pager for a cryptographic defect.

A published vulnerability-disclosure process, and a track record of using it.

• ●

  Where to report, and expected response time.

• ●

  Whether past advisories were published, and how quickly patches followed.

Compatibility with liboqs and the Open Quantum Safe integrations, as an interoperability baseline.

Participation in the relevant IETF work, and conformance to the hybrid-TLS design as it stands.

Demonstrated interoperation with at least one independent implementation, not only with the vendor's own client.

Keys, certificates and messages use standard encodings that another product can consume.

Language bindings, platform and architecture coverage relative to what the vendor's market actually runs.

Standard integration interfaces are supported for post-quantum key types, not only for classical ones.

A named production deployment, rather than a pilot described in the abstract.

• ●

  Whether the customer is named, or only a sector is.

• ●

  Whether the deployment is production or an evaluation.

Published case studies contain actual data rather than only qualitative claims.

Partnership and ecosystem announcements are recorded as what they are, and never counted as deployment evidence.

How long the deployment has run and at what scale, where either is discoverable.

Publicly known incidents or defects affecting the cryptographic product, and how the vendor handled them.

A stated timeline for algorithms still being standardised, rather than silence.

Evidence the vendor tracks standards revisions, and ships against final rather than draft text.

A stated policy for deprecating an algorithm, including notice periods for customers.

Alignment with the published regulatory timelines the vendor's market is actually held to.

Roadmap items are distinguishable from shipped features in the vendor's own material.