European quantum technologiesSign inCreate accountContact & information
QUANTUM
EUROPE

PQC interoperability test reports

Published post-quantum interoperability test reports, each with the scope it states: products and versions where given, endpoint roles, protocol, algorithms and parameter sets, hybrid or pure mode, formats, method, date and limitations.

A passed test applies only to what was tested. It is not a certification, it does not show that a service or an organisation is ready and it changes no readiness in the product navigator. Tests with pre-standard algorithms are outdated. Vendor and project tests are not independent.

Filter the reports

15 of 15 reports shown.

Test reports

  • NIST NCCoE SP 1800-38C: hybrid and pure Kyber key exchange in SSH

    NIST National Cybersecurity Center of Excellence (NCCoE) with project collaborators · Government laboratory with industry collaborators

    Outcome
    Passed within the stated scope. The report states that every method supported by both ends interoperated; methods one end lacked are marked not applicable.
    Date
    . Preliminary draft of December 2023; the CSRC page is dated 19 December 2023.
    Protocol or use
    SSH
    Algorithms and parameter sets
    Kyber, pre-standard (round 3). Kyber-512, Kyber-768, Kyber-1024; P256+Kyber-512, X25519+Kyber-512, P384+Kyber-768, P521+Kyber-1024, with the method names of version 01 of an individual SSH draft
    Mode
    Both pure and hybrid
    Certificate and key formats
    Key exchange only; post-quantum host and user authentication was deferred.
    Products, versions and endpoint roles
    • OQS OpenSSH (v8, version tested; Client and server)
    • wolfSSH (version not stated; Client and server)
    • AWS SSH implementation (AWS Transfer Family) (version not stated; Client and server)
    Test method
    Connections in the NCCoE lab between every client and server for each key exchange method both ends supported, on Ubuntu 22.04.1 and Amazon Linux 2 virtual machines.
    Standards status
    Pre-standard algorithm versions or identifiers: outdated
    Limitations
    Pre-standard Kyber (round 3) and draft SSH method names, since replaced by ML-KEM and RFC 10042. Preliminary draft, not final. wolfSSH is identified only as a June 2023 build, without a version. The table cells cannot be attributed reliably from the PDF text, so only the stated overall result is recorded.
    Locator, read on
    Section 5.2.1 and Table 2, pages 16 to 17; lessons learned in Section 5.4; 2026-10-30

  • NIST NCCoE SP 1800-38C: hybrid and pure Kyber key exchange in TLS 1.3

    NIST National Cybersecurity Center of Excellence (NCCoE) with project collaborators · Government laboratory with industry collaborators

    Outcome
    Passed within the stated scope. The report states that all methods supported by both ends interoperated; one cell of Table 3 is marked pending.
    Date
    . Preliminary draft of December 2023; the CSRC page is dated 19 December 2023.
    Protocol or use
    TLS 1.3
    Algorithms and parameter sets
    Kyber, pre-standard (round 3). Kyber-512, Kyber-768, Kyber-1024; P256+Kyber-512, P384+Kyber-768, P521+Kyber-1024, with the code points of OQS OpenSSL (draft-ietf-tls-hybrid-design-05 had no assigned code points)
    Mode
    Both pure and hybrid
    Certificate and key formats
    Key exchange only; certificates were classical.
    Products, versions and endpoint roles
    • Open Quantum Safe (OQS) OpenSSL Provider (version not stated; Client and server)
    • wolfSSL (version not stated; Client and server)
    • AWS s2n-tls (version not stated; Client and server)
    • Samsung SDS PQC-TLS (s-pqc-tls) (version not stated; Client and server)
    • OQS NGINX (version not stated; Server)
    Test method
    TLS 1.3 connections between each client and server for every key exchange both supported, on Ubuntu 22.04.1 virtual machines in the NCCoE lab.
    Standards status
    Pre-standard algorithm versions or identifiers: outdated
    Limitations
    Pre-standard Kyber and temporary OQS code points, not the ML-KEM code points of RFC 10024. No product versions are stated. Section 6.4 records a handshake failure between s2n-tls and OQS OpenSSL while they implemented different draft versions. Preliminary draft, not final.
    Locator, read on
    Sections 6.1 and 6.2.1, Table 3, pages 18 to 21; lessons learned in Section 6.4; 2026-10-30

  • NIST NCCoE SP 1800-38C: Kyber-1024 key exchange with Dilithium5 authentication in TLS 1.3

    NIST National Cybersecurity Center of Excellence (NCCoE) with project collaborators · Government laboratory with industry collaborators

    Outcome
    Passed within the stated scope. The report states that all implementations supporting the profile interoperated; several pairs are marked not applicable.
    Date
    . Preliminary draft of December 2023; the CSRC page is dated 19 December 2023.
    Protocol or use
    TLS 1.3
    Algorithms and parameter sets
    Kyber, pre-standard (round 3); Dilithium, pre-standard (round 3). Kyber-1024 key exchange with Dilithium5 (level 5) authentication, no hybrids (the report's CNSA 2.0 profile)
    Mode
    Post-quantum only
    Certificate and key formats
    Dilithium5 certificates; the certificate encoding is not stated in this section.
    Products, versions and endpoint roles
    • Open Quantum Safe (OQS) OpenSSL Provider (version not stated; Client and server)
    • wolfSSL (version not stated; Client and server)
    • AWS s2n-tls (version not stated; Client and server)
    • Samsung SDS PQC-TLS (s-pqc-tls) (version not stated; Client and server)
    • OQS NGINX (version not stated; Server)
    Test method
    TLS 1.3 connections between each client and server that supported the profile, in the NCCoE lab.
    Standards status
    Pre-standard algorithm versions or identifiers: outdated
    Limitations
    Pre-standard Kyber and Dilithium (now ML-KEM and ML-DSA with different encodings). Fewer components supported the profile. No product versions are stated. Preliminary draft, not final.
    Locator, read on
    Section 6.2.2 and Table 4, pages 21 to 22; 2026-10-30

  • NIST NCCoE SP 1800-38C: post-quantum key exchange and authentication in QUIC

    NIST National Cybersecurity Center of Excellence (NCCoE) with project collaborators · Government laboratory with industry collaborators

    Outcome
    Not tested. No interoperability test: only one post-quantum QUIC implementation was available at the time.
    Date
    . Preliminary draft of December 2023; the CSRC page is dated 19 December 2023.
    Protocol or use
    QUIC
    Algorithms and parameter sets
    Kyber, pre-standard (round 3); Dilithium, pre-standard (round 3). Kyber-512, Kyber-768, Kyber-1024 and ECDHE+Kyber hybrids; a second profile with Dilithium-2, -3 and -4 authentication
    Mode
    Both pure and hybrid
    Certificate and key formats
    Not applicable: no interoperability test took place.
    Products, versions and endpoint roles
    • AWS s2n-quic (built with s2n-tls and AWS-LC) (version not stated; Client and server)
    Test method
    Planned client and server connections; only performance measurements with one implementation were made.
    Standards status
    Pre-standard algorithm versions or identifiers: outdated
    Limitations
    Shows only that no second implementation was available in 2023. The performance results used enlarged RSA certificates to emulate Dilithium sizes and are not interoperability evidence.
    Locator, read on
    Sections 7.1 to 7.2.2, pages 27 to 28; 2026-10-30

  • NIST NCCoE SP 1800-38C: post-quantum keys, signatures and key encapsulation across HSMs

    NIST National Cybersecurity Center of Excellence (NCCoE) with project collaborators · Government laboratory with industry collaborators

    Outcome
    Partly passed: failures within the stated scope. High interoperability for the supported capabilities; the one incompatibility found was the SPHINCS+ SHA2 variants of Entrust, which Crypto4A and Thales DIS could not verify, and the reverse.
    Date
    . Preliminary draft of December 2023; the CSRC page is dated 19 December 2023.
    Protocol or use
    Hardware security modules
    Algorithms and parameter sets
    Kyber, pre-standard (round 3); Dilithium, pre-standard (round 3); Falcon (not yet a final standard); SPHINCS+, pre-standard; XMSS and XMSS^MT (stateful hash-based); LMS and HSS (stateful hash-based). Kyber 512, 768 and 1024; Dilithium levels 2, 3 and 5; Falcon 512 and 1024; SPHINCS+ SHA2 and SHAKE variants; XMSS, XMSS^MT and LMS/HSS parameter sets listed in Table 17
    Mode
    Post-quantum only
    Certificate and key formats
    Public keys exported from one HSM and imported into another, with temporary object identifiers from the IETF Hackathon and liboqs (Table 15); not tested across PKCS#11.
    Products, versions and endpoint roles
    • Crypto4A HSM (version not stated; Hardware security module)
    • Entrust HSM (version not stated; Hardware security module)
    • Thales DIS HSM (version not stated; Hardware security module)
    • Thales TCT HSM (version not stated; Hardware security module)
    • Utimaco HSM (capabilities reported by the vendor, results not available) (version not stated; Hardware security module)
    Test method
    Keys generated on one vendor's HSM exported and imported into another; signatures made on one verified on another; a key encapsulated on one decapsulated on another with the same shared secret.
    Standards status
    Pre-standard algorithm versions or identifiers: outdated
    Limitations
    Pre-standard algorithm versions (Kyber v3.02, Dilithium v3.1) and temporary identifiers. No product or firmware versions are stated. Utimaco results were not available for the draft. Performance and PKCS#11 interoperability were not tested.
    Locator, read on
    Section 9, Tables 15 to 19 and the summary in Section 9.3, pages 37 to 54; 2026-10-30

  • IETF PQC Hackathon: ML-DSA-65 X.509 certificate artifacts

    IETF Hackathon pqc-certificates project · Standards community event, several submitters

    Outcome
    Passed within the stated scope. Artifacts of 17 producers verified by all 4 parsers: 68 of 68 pairs passed.
    Date
    . Results generated on 6 October 2026, 12:08 UTC (page header).
    Protocol or use
    X.509 certificates and key files
    Algorithms and parameter sets
    ML-DSA (FIPS 204). ML-DSA-65 (pure)
    Mode
    Post-quantum only
    Certificate and key formats
    Self-signed X.509 certificates in the RFC 9881 format, submitted as files
    Products, versions and endpoint roles
    • bc (version not stated; Parser and verifier)
    • composite-ref-impl (version not stated; Parser and verifier)
    • openssl (version not stated; Parser and verifier)
    • qubip-aurora (version not stated; Parser and verifier)
    Test method
    Automated parsing and signature verification of each producer's certificate files by each parser.
    Standards status
    Final algorithm standards
    Limitations
    File test, not a TLS handshake or a deployed service. The page names submitters and parsers, not product releases or builds. Not a certification.
    Locator, read on
    Table ML-DSA-65-cert (2.16.840.1.101.3.4.3.18-cert): rows are producers, columns are parsers; 2026-10-30

  • IETF PQC Hackathon: ML-DSA-65 private key formats

    IETF Hackathon pqc-certificates project · Standards community event, several submitters

    Outcome
    Partly passed: failures within the stated scope. Seed-format keys of 10 producers read; those of 2 producers, Botan and one other submitter, rejected, and the same 2 failed the consistency check.
    Date
    . Results generated on 6 October 2026, 12:08 UTC (page header).
    Protocol or use
    X.509 certificates and key files
    Algorithms and parameter sets
    ML-DSA (FIPS 204). ML-DSA-65 private keys, seed and expanded-key encodings
    Mode
    Post-quantum only
    Certificate and key formats
    Private key files in the seed format and the expanded-key format
    Products, versions and endpoint roles
    • openssl (version not stated; Parser and verifier)
    Test method
    Automated reading of each producer's private key files with the OpenSSL parser and a check that seed and expanded key agree.
    Standards status
    Final algorithm standards
    Limitations
    The page does not state why the files were rejected. Applies to the submitted files only, not to a product release, and says nothing about certificates or signatures.
    Locator, read on
    Tables ML-DSA-65-seed and ML-DSA-65-consistent (2.16.840.1.101.3.4.3.18): column openssl; 2026-10-30

  • IETF PQC Hackathon: X.509 certificates carrying ML-KEM-768 keys

    IETF Hackathon pqc-certificates project · Standards community event, several submitters

    Outcome
    Passed within the stated scope. Artifacts of 11 producers: 19 results, all passed; the openssl parser checked all 11, the composite reference implementation 8; the bc and qubip-aurora columns are empty.
    Date
    . Results generated on 6 October 2026, 12:08 UTC (page header).
    Protocol or use
    X.509 certificates and key files
    Algorithms and parameter sets
    ML-KEM (FIPS 203). ML-KEM-768 public key in an end-entity certificate signed by the producer's CA
    Mode
    Post-quantum only
    Certificate and key formats
    X.509 end-entity certificates holding an ML-KEM-768 key, submitted as files
    Products, versions and endpoint roles
    • composite-ref-impl (version not stated; Parser and verifier)
    • openssl (version not stated; Parser and verifier)
    Test method
    Automated parsing and verification of each producer's certificate files by each parser that reported a result.
    Standards status
    Final algorithm standards
    Limitations
    File test, not a key exchange in a protocol. Empty cells mean no result, not a failure. The page names submitters and parsers, not product releases.
    Locator, read on
    Table ML-KEM-768-cert (2.16.840.1.101.3.4.4.2-cert): rows are producers, columns are parsers; 2026-10-30

  • IETF PQC Hackathon: ML-KEM-768 key consistency

    IETF Hackathon pqc-certificates project · Standards community event, several submitters

    Outcome
    Partly passed: failures within the stated scope. 7 of 8 producers passed; the artifact of the producer labelled bc (Bouncy Castle) failed.
    Date
    . Results generated on 6 October 2026, 12:08 UTC (page header).
    Protocol or use
    X.509 certificates and key files
    Algorithms and parameter sets
    ML-KEM (FIPS 203). ML-KEM-768 private keys, seed and expanded-key encodings
    Mode
    Post-quantum only
    Certificate and key formats
    Private key files in the seed format and the expanded-key format
    Products, versions and endpoint roles
    • openssl (version not stated; Parser and verifier)
    Test method
    Automated check with the OpenSSL parser that each producer's seed and expanded key agree.
    Standards status
    Final algorithm standards
    Limitations
    The page does not state the cause of the failure. Applies to the submitted files, not to a Bouncy Castle release.
    Locator, read on
    Table ML-KEM-768-consistent (2.16.840.1.101.3.4.4.2-consistent): column openssl; 2026-10-30

  • IETF PQC Hackathon: composite ML-DSA-65 with ECDSA P-256 certificates

    IETF Hackathon pqc-certificates project · Standards community event, several submitters

    Outcome
    Passed within the stated scope. Artifacts of 12 producers verified by 2 parsers: 24 of 24 results passed; the openssl and qubip-aurora columns are empty.
    Date
    . Results generated on 6 October 2026, 12:08 UTC (page header).
    Protocol or use
    X.509 certificates and key files
    Algorithms and parameter sets
    Composite ML-DSA with a classical signature. ML-DSA-65 combined with ECDSA P-256 and SHA-512 in one composite signature
    Mode
    Hybrid (post-quantum with classical)
    Certificate and key formats
    Self-signed X.509 certificates with a composite key and signature, submitted as files
    Products, versions and endpoint roles
    • bc (version not stated; Parser and verifier)
    • composite-ref-impl (version not stated; Parser and verifier)
    Test method
    Automated parsing and signature verification of each producer's certificate files by each parser that reported a result.
    Standards status
    Final algorithms in a draft format or protocol specification
    Limitations
    The composite format comes from an IETF draft, not a published RFC, on the day read. File test only; the page names submitters, not product releases.
    Locator, read on
    Table id-MLDSA65-ECDSA-P256-SHA512-cert (1.3.6.1.5.5.7.6.45-cert); 2026-10-30

  • IETF PQC Hackathon: SLH-DSA-SHA2-128s X.509 certificates

    IETF Hackathon pqc-certificates project · Standards community event, several submitters

    Outcome
    Passed within the stated scope. Artifacts of 12 producers verified by 2 parsers: 24 of 24 results passed; the composite reference and qubip-aurora columns are empty.
    Date
    . Results generated on 6 October 2026, 12:08 UTC (page header).
    Protocol or use
    X.509 certificates and key files
    Algorithms and parameter sets
    SLH-DSA (FIPS 205). SLH-DSA-SHA2-128s (pure)
    Mode
    Post-quantum only
    Certificate and key formats
    Self-signed X.509 certificates, submitted as files
    Products, versions and endpoint roles
    • bc (version not stated; Parser and verifier)
    • openssl (version not stated; Parser and verifier)
    Test method
    Automated parsing and signature verification of each producer's certificate files by each parser that reported a result.
    Standards status
    Final algorithm standards
    Limitations
    File test only, one of twelve SLH-DSA parameter sets on the page. The page names submitters, not product releases.
    Locator, read on
    Table SLH-DSA-SHA2-128s-cert (2.16.840.1.101.3.4.3.20-cert); 2026-10-30

  • OASIS KMIP Technical Committee: KMIP 3.0 post-quantum interoperability test

    OASIS Key Management Interoperability Protocol (KMIP) Technical Committee · Standards body technical committee, several vendors

    Outcome
    Passed within the stated scope. The committee post states that all participants interoperated on every test case each client and server pair supported, after configuration issues were fixed and retested.
    Date
    . Test period 3 to 7 March 2025 on kmip-interop.org; the committee post is dated 03-12-2025.
    Protocol or use
    KMIP key management
    Algorithms and parameter sets
    ML-KEM (FIPS 203); ML-DSA (FIPS 204); SLH-DSA (FIPS 205). Parameter sets not stated; the post names the hybrid group X25519MLKEM768 for the TLS connection
    Mode
    Both pure and hybrid
    Certificate and key formats
    KMIP 3.0 objects and operations; not stated in detail in the post
    Products, versions and endpoint roles
    • Cryptsoft KMIP clients (12) (version not stated; KMIP client)
    • Cryptsoft KMIP servers (C and Java) (version not stated; KMIP server)
    • NetApp KMIP client (version not stated; KMIP client)
    • Project 6 Research (P6R) SKC client (version not stated; KMIP client)
    Test method
    Test cases run between each KMIP client and server pair during a one-week interop; participants reviewed and agreed the results.
    Standards status
    Final algorithm standards
    Limitations
    No product versions, test case list or per-pair results in the page text; the result views on kmip-interop.org were not readable as text. Most testing used TLS 1.2 with the hybrid key exchange enabled, as the post states.
    Locator, read on
    Committee discussion post on the results; summary of the 2025 PQC test on kmip-interop.org; 2026-10-30

  • Keyfactor interoperability page: ML-KEM key exchange in TLS 1.3 sessions

    Keyfactor (vendor documentation) · Vendor’s own testing, not independent

    Outcome
    Passed within the stated scope. The row is marked successful.
    Date
    . Page last updated September 2025, as it states.
    Protocol or use
    TLS 1.3
    Algorithms and parameter sets
    ML-KEM (FIPS 203). ML-KEM key exchange; the parameter set and any hybrid group are not stated
    Mode
    Not stated
    Certificate and key formats
    Mutual TLS; certificate types for this row are not stated
    Products, versions and endpoint roles
    • OpenSSL (3.5.0, minimum version stated (equal or higher); Library)
      Same name and version in the product navigator: OpenSSL 3.5
    • Apache HTTP Server (2.4.64, minimum version stated (equal or higher); Server)
    • Bouncy Castle (1.80, minimum version stated (equal or higher); Client and server)
    • Go (1.25, minimum version stated (equal or higher); Client and server)
    • wolfSSL (version not stated; Client and server)
    • WildFly (version not stated; Server)
    • Firefox (version not stated; Client)
    • Chromium (version not stated; Client)
    • cURL (version not stated; Client)
    Test method
    Mutual TLS sessions between OpenSSL-based tools and Java servers using Bouncy Castle TLS; no test procedure or pass criteria are published.
    Standards status
    Final algorithm standards
    Limitations
    The vendor's own testing, not independent. Versions are minimums (the page says equal or higher), and OpenSSL 3.5.0 is named as the build of Apache 2.4.64. The page warns that behaviour may differ in other environments. The page is updated in place; earlier results are not kept.
    Locator, read on
    TLS 1.3 table, row Session encryption; list of required component versions; 2026-10-30

  • Keyfactor interoperability page: post-quantum certificate lifecycle with EJBCA

    Keyfactor (vendor documentation) · Vendor’s own testing, not independent

    Outcome
    Passed within the stated scope. All seven lifecycle rows are marked successful; CertBot needed a request created with OpenSSL.
    Date
    . Page last updated September 2025, as it states.
    Protocol or use
    Certificate lifecycle (requests, issuance, revocation)
    Algorithms and parameter sets
    ML-DSA (FIPS 204); SLH-DSA (FIPS 205); LMS and HSS (stateful hash-based); ML-KEM (FIPS 203). ML-DSA, SLH-DSA and LMS for requests, certificates and revocation; ML-KEM certificates through CMP; parameter sets not stated
    Mode
    Post-quantum only
    Certificate and key formats
    Certificate signing requests, X.509 certificates, CRLs, OCSP responses, CMP and ACME messages
    Products, versions and endpoint roles
    • EJBCA (9.3, minimum version stated (equal or higher); Certificate authority)
    • OpenSSL (3.5, minimum version stated (equal or higher); Parser and verifier)
    • Bouncy Castle (1.80, minimum version stated (equal or higher); Parser and verifier)
    • CertBot (version not stated; Client)
    Test method
    Requests created with Bouncy Castle, EJBCA or OpenSSL; certificates, CRLs and OCSP responses issued by EJBCA validated with OpenSSL and Bouncy Castle; CMP with Bouncy Castle; ACME with CertBot.
    Standards status
    Final algorithm standards
    Limitations
    The vendor's own testing, not independent. Versions are minimums (equal or higher). No test procedure or pass criteria are published. The page is updated in place.
    Locator, read on
    Certificate Lifecycle Management table, rows CSR generation to ACME; list of required component versions; 2026-10-30

  • strongSwan KVM test ikev2/rw-mlkem: hybrid ML-KEM key exchange for road warriors

    strongSwan project · Project’s own automated test, one implementation

    Outcome
    Passed within the stated scope. The test is listed as passed; the run reports 0 failures.
    Date
    . Test run 20260906-1003-37 of strongSwan 6.1.0, on the results index.
    Protocol or use
    IKEv2 and IPsec
    Algorithms and parameter sets
    ML-KEM (FIPS 203). x25519-ke1_mlkem512 (client carol) and ecp384-ke1_mlkem768 (client dave)
    Mode
    Hybrid (post-quantum with classical)
    Certificate and key formats
    X.509 certificate authentication (classical)
    Products, versions and endpoint roles
    • strongSwan (6.1.0, version tested; Gateway)
    Test method
    Automated virtual network test: two clients set up tunnels to gateway moon with an additional ML-KEM key exchange, then reach a host behind it.
    Standards status
    Final algorithm standards
    Limitations
    strongSwan on both ends: a regression test of one implementation, not interoperability between vendors. strongSwan 6.1.0 is not a release listed in the product navigator.
    Locator, read on
    Test page ikev2/rw-mlkem; status passed on the ikev2 results index (test 228); 2026-10-30

Published post-quantum interoperability test reports read on the publishers' own pages on 30 October 2026 (#471). Each record keeps the exact scope as published: product names and versions only where the report states them, endpoint roles, protocol, algorithms and parameter sets, hybrid or pure mode, formats, method, date, outcome and limitations, in the portal's own words. A passed test applies only to what was tested; it is not a certification and changes no readiness in the product navigator. Products link to the navigator only when the stated name and version equal a navigator product and release exactly. Reports read 2026-10-30.

Contact & information · Privacy and cookies · Legal notice · Terms of use · Accessibility

Image credits · All tools and pages