Post-Quantum Cryptography Vendor Landscape

What the landscape includes

Post-quantum cryptography (PQC) is the effort to use cryptographic approaches intended to resist threats from both classical and quantum computers. The cited material describes PQC as a response to the long service lives of data, devices, and infrastructure: choices made during design can be difficult to change later. It also cautions against treating the quantum threat as a claim that every encryption system will fail at once. The stated concern is more specific: certain public-key cryptographic systems are vulnerable, and migration has operational consequences involving performance, key sizes, implementation, and compatibility.6

The vendor landscape should therefore be read as a set of solution scopes. A cryptographic inventory platform is not automatically a PQC implementation library; a validated library is not automatically an enterprise discovery system; and an HSM option or certificate-management capability is not automatically an end-to-end migration program. Several vendors describe broader platforms that combine multiple functions, but the evidence still needs to be examined function by function.12378

Standards and evidence foundation

NIST describes an open standardization process that began with submissions from cryptographers around the world, followed by public analysis and multiple rounds of evaluation. Its overview says NIST assessed 82 algorithms from 25 countries in one account of the initiative, while another passage describes 69 candidate algorithms submitted by the deadline; these figures belong to different stages or descriptions in the cited material and should not be collapsed into one number. NIST also says its process considered constrained devices as well as larger computers.4

The NIST overview, published August 13, 2024 and marked current in the source set, states that the first three finalized PQC standards were released in 2024 and encourages organizations to begin transitioning to them. This makes standards alignment a foundational comparison criterion. It does not, however, establish that every vendor product listed in this article is certified, interoperable, or compliant with a particular standard. Those attributes require product-specific verification.48

PQShield’s documentation similarly presents internationally recognized standards as important for trust, interoperability, and long-term security, and warns that proprietary or unproven algorithms may create compatibility, security, or lifecycle risks. This is a vendor-authored rationale, not an independent comparative finding. It is useful as an evaluation principle: identify the algorithms, protocol versions, implementation status, validation scope, and change-management process rather than accepting a general statement that a product is “quantum safe.”6

Practical vendor categories

The following taxonomy is intended to organize vendor capabilities, not to rank suppliers. Products can appear in more than one category, and the cited passages do not provide enough evidence to determine market share, total coverage, or relative effectiveness.123

• Enterprise cryptographic discovery and risk management: QuantumGenie describes mapping applications, services, databases, identities, certificates, and keys, then tracing paths to weak or quantum-vulnerable cryptography. QIZ describes mapping cryptographic risk in applications, data in transit, and data at rest, with prioritized findings. QuSecure describes an inventory spanning cloud, on-premises, air-gapped, and legacy systems.
• Crypto command and control, remediation, and orchestration: QuSecure describes centralized discovery, automated workflows, unified control, crypto-agility, remediation, and CBOM reporting. SandboxAQ describes inventory, remediation, automated policy enforcement, compliance reporting, and unified cryptography management. These claims describe intended capabilities; they are not independent proof of deployment results.
• Validated PQC and cryptographic software: SafeLogic describes Cryptocomply software with ML-KEM, ML-DSA, and SLH-DSA, hybrid encryption, QUIC and TLS 1.3 support, and OpenSSL 3.5 compatibility. PQShield describes cryptographic libraries, platforms, and performance-oriented products across chips, applications, and cloud environments.
• TLS, protocol, and application integration: SafeLogic describes a PQC TLS product with legacy compatibility and policy-based crypto-agility. Keyfactor documents interoperability across TLS, CMS, certificate lifecycle management, and HSMs, along with supported algorithms and version requirements in a living resource.
• PKI, certificates, machine identities, and HSMs: Keyfactor emphasizes certificate issuance, digital signatures, PKI, interoperability, and crypto-agility. Entrust’s cited documentation identifies an nShield post-quantum cryptography option pack alongside HSM and Security World documentation. The evidence does not describe the full functional scope or deployment requirements of that option pack.
• Migration expertise and implementation guidance: ISARA describes agentless discovery and analysis across cloud, on-premises, and hybrid environments, standards-aligned libraries, and implementation experience. PQShield describes standards participation and migration constraints. Keyfactor provides strategy, glossary, and interoperability resources.
• Adjacent security platforms: The cited Wiz, Snyk, CrowdStrike, Cyera, and CyberArk passages describe broader cloud, developer, endpoint, data, or machine-identity security capabilities, but do not provide sufficient PQC-specific evidence to classify them as dedicated PQC vendors in this landscape.

How to evaluate vendors consistently

A fair comparison begins by defining the problem boundary. An organization seeking to discover unknown cryptographic dependencies should ask different questions from an organization seeking a production PQC library or a certificate and HSM transition plan. The evaluation should record what the product claims to cover, what it actually observes, how findings are attributed to owners and applications, and which actions can be automated.468

1. Define the asset and environment scope. Record whether the offering addresses source code, infrastructure, endpoints, cloud, on-premises, air-gapped systems, legacy systems, applications, databases, certificates, keys, HSMs, or network protocols. “Enterprise-wide” should be treated as a claim to test, not as a substitute for a scope statement.
2. Identify standards and algorithms. Record named standards and algorithms, including whether support is experimental, production-ready, validated, certified, or merely documented. Confirm version numbers and the date of the relevant documentation.
3. Test discovery and attribution. Determine whether the product can identify cryptographic assets, dependencies, algorithm provenance, owners, affected applications, and data flows. Ask how it handles unknown, dynamically generated, embedded, or third-party cryptography.
4. Assess remediation and crypto-agility. Establish whether changes require code changes, configuration changes, replacement components, policy updates, or service restarts. Test rollback, hybrid operation, legacy compatibility, and the ability to change algorithms without disrupting dependent systems.
5. Check protocol and integration coverage. Test the actual environments that matter: TLS or QUIC, CMS, PKI and certificate lifecycle management, HSMs, APIs, cloud services, constrained devices, and operational technology. Interoperability should be demonstrated in the target architecture.
6. Examine governance and reporting. Review CBOM or equivalent inventory outputs, risk prioritization, policy enforcement, audit logs, compliance reports, ownership workflows, and integration with ticketing or change-management systems.
7. Separate vendor evidence from independent evidence. Treat product pages, customer quotations, awards, and vendor-published performance figures as self-reported documentation. Seek reproducible testing, customer references appropriate to the use case, implementation documentation, and independent validation where the decision requires it.
8. Model migration constraints and lifecycle. Account for performance, memory, key and signature sizes, hardware limitations, certificate replacement, protocol changes, vendor support periods, and the possibility that cryptographic choices may need to change again.

The cited evidence illustrates why these criteria must remain separate. SafeLogic presents software and protocol capabilities, including hybrid encryption and named algorithms. Keyfactor presents interoperability documentation and certificate-related resources. QuSecure and SandboxAQ present broader discovery, orchestration, remediation, policy, and reporting claims. QuantumGenie presents discovery, attribution, remediation, and monitoring as connected stages. These descriptions can inform a shortlist, but they do not constitute a controlled head-to-head comparison.12510

Important limitations of this landscape

This article is a taxonomy and evaluation guide, not a dated market study. The source set contains current source-status labels but does not provide a common test methodology, a uniform product-version matrix, pricing, deployment effort, customer adoption denominator, or independently measured comparative performance. Vendor pages also use different terminology and emphasize different parts of the migration lifecycle. As a result, the article should not be used to rank vendors or infer that a listed capability is equivalent across suppliers.6

Dates and versions matter. NIST’s cited overview is dated August 13, 2024. SandboxAQ’s cited page identifies AQtive Guard as generally available in a passage dated March 27, 2024. SafeLogic’s cited material includes later blog dates in 2026, including a July 23, 2026 launch reference. These dates are preserved as source context, but the evidence does not establish a single synchronized product baseline. Procurement teams should request current release notes, supported versions, validation records, and roadmaps before making a decision.6

A useful next step is cryptographic discovery: establish an inventory and understand where algorithms, certificates, keys, protocols, and dependencies are used before selecting remediation technology. The related prerequisite topic is available as What is Cryptographic Discovery?6

Conclusion

The post-quantum cryptography vendor landscape is best understood as an overlapping set of capabilities rather than a single ranked market. Discovery and inventory, risk attribution, remediation and orchestration, validated cryptographic software, protocol and PKI integration, HSM support, and migration guidance answer different operational needs. NIST standards provide the central reference point, while vendor documentation supplies product-specific claims that must be verified against scope, versions, environments, interoperability, lifecycle controls, and independent evidence. Organizations can make a more defensible shortlist by comparing those criteria explicitly and by treating “quantum safe,” “crypto-agile,” and “enterprise-wide” as claims requiring demonstration.468