Post-quantum cryptography (PQC) readiness depends on upgrading the underlying protocols that secure how systems communicate, including SSH (used for remote access to systems) and TLS (used to protect data in transit across applications and websites). Our research shows that while PQC adoption is increasing across both, progress toward quantum-safe security remains uneven — leaving persistent gaps in PQC readiness.
Main Findings:
- Most of the internet is still not quantum-safe. The number of SSH servers supporting PQC on the internet has grown substantially in one year, but progress has been uneven.
- SSH servers supporting PQC increased 72% from 11.5 million to over 19 million
- Total PQC-capable SSH servers grew from 6.2% to 11.8%
- Nearly 90% of SSH servers remain non-PQC-capable
- 40% of OpenSSH servers on the internet now support PQC by default
- Only 3% of identified servers running Dropbear – common in embedded devices – support PQC, highlighting slower adoption in constrained environments
- In enterprise networks, PQC support is also uneven.
- 50% of IT devices use OpenSSH versions that support PQC
- Only 28% use PQC-capable OpenSSH for IoT, 16% for OT, and 6% for IoMT devices, revealing a widening readiness gap across device types
- Every device type had noticeable growth, but the rate of growth is likely to slow down as easy-to-upgrade systems migrate first – leaving more complex, legacy environments behind.
- At the current pace, no asset class is likely to be fully migrated by 2029, with IoMT and OT devices facing the highest levels of residual exposure.
- TLSv1.3 on the internet and PQC on TLS in enterprise networks have also been growing, representing early steps toward quantum-safe security for encryption in transit.
- TLSv1.3 now runs on 30% of identified servers on the internet, up from 19% a year ago
- In enterprise networks, IT devices most commonly support PQC on TLS (8%), while specialized devices are again left behind (5.6% for IoT and IoMT, 0.8% for OT)
- Two thirds of OT devices in enterprise networks are both high risk and are not PQC-capable on TLS
- Nearly half of IoT devices fall into the same high-risk, non-PQC capable category
Mitigation Recommendations:
- Build and maintain a real-time cryptographic inventory of the assets in your network that do or do not support PQC
- Correlate that inventory with contextual information (criticality, exposure, function, etc.) about these assets to understand and prioritize quantum risk and PQC readiness gaps
- Adopt Secure Remote Access (SRA) for hard-to-upgrade unmanaged devices to limit their exposure to internal networks and reduce risk during PQC migration
While some security leaders still believe the threat of quantum computing is far away in the future, the technology has been advancing rapidly. Governments and organizations are now concerned that a quantum computer could break traditional asymmetric encryption in the next few years, possibly as early as 2029.
Post-quantum cryptography (PQC), which is designed to resist quantum attacks, already exists but organizations need to migrate their assets to this new technology. The first step of this migration is to build a complete inventory of network assets and prioritize PQC migration based on risk, including IT, IoT, OT, medical devices, and others.
At Forescout Research – Vedere Labs, we have been tracking the adoption of PQC for over a year. Key trends include the slower pace of adoption for unmanaged devices and uneven adoption across industries.
Here, we update those findings with the latest data and discuss how Forescout can help organizations identify, prioritize, and mitigate PQC-related risk and accelerate PQC migration in their environments.
PQC Adoption Update
To measure PQC adoption on the internet and enterprise networks, we look at two main protocols, SSH and TLS, and three data sources: Censys and Shodan for internet data and Forescout Device Cloud for enterprise networks.
SSH
In May 2026, there were over 160 million SSH hosts on the internet supporting several different key exchange (KEX) algorithms, which are used to establish session keys for end-to-end encrypted communication.
The 11 most popular KEX algorithms running on those servers are all variations of traditional and Elliptic Curve Diffie-Hellman (ECDH) — and are all susceptible to quantum attacks.
The most popular PQC KEX algorithms are SNTRUP (OpenSSH’s default KEX between versions 9.0 and 9.9) and ML-KEM (OpenSSH’s default KEX since version 10):
| PQC KEX | #Hosts | %Hosts |
|---|---|---|
| [email protected] | 13,676,692 | 8.53% |
| sntrup761x25519-sha512 | 3,466,567 | 2.16% |
| mlkem768x25519-sha256 | 1,830,040 | 1.14% |
| [email protected] | 41,102 | 0.03% |
| mlkem1024nistp384-sha384 | 17,996 | 0.01% |
| mlkem768nistp256-sha256 | 11,433 | 0.01% |
| Other PQC | 245 | < 0.01% |
On the bright side, the number of servers supporting PQC has grown substantially over the last 12 months. PQC-capable SSH servers increased from 11.5 million to over 19 million, a 72% increase — with total share rising from 6.2% to 11.88%. The biggest growth was servers using ‘mlkem768x25519-sha256’ — which grew by 184% since August 2025.
Despite this progress, nearly 90% of SSH servers remain non-PQC-capable.
Different versions of OpenSSH run on over 80% of identified SSH servers, so naturally most of the growth in PQC adoption comes from upgrading OpenSSH versions to those that support PQC by default. Legacy versions of OpenSSH between 7.0 and 8.9 decreased from 75% to 60% in a year. However, PQC-capable versions increased from 21% to 37%, including 9.x and 10.x which have SNTRUP and then ML-KEM as default KEX.
Smaller gains also come from upgrades to other SSH servers, such as Dropbear, which is popular for embedded devices and added PQC support in March 2025. There are now over 58,000 servers running Dropbear versions between 2025.87 and 2026.90 which support PQC. However, only 3% of identified servers are running Dropbear which is the first indication that embedded devices with specialized applications are upgrading at a slower pace.
Using data from Forescout’s Device Cloud, we drilled down into the device types that use those quantum-capable OpenSSH versions. While 50% of IT devices use OpenSSH versions that support PQC, adoption drops significantly to just 28% for IoT, 16% for OT, and 6% for IoMT devices. This is where quantum-related risk is concentrating.
The good news is that for every device type there was noticeable growth between August 2025 and April 2026. The bad news is that there is still a long way to go for specialized devices. If it continues at this same pace, they are unlikely to be fully migrated in this decade.
IoMT devices, in particular, had the fastest growth but remain way behind in terms of PQC adoption. In April, MITRE published a risk analysis for medical devices due to recent technologies. They highlighted that the PQC transition for this type of equipment will require close collaboration between their manufacturers and healthcare delivery organizations. Challenges include: higher memory and computation costs for PQC, interoperability with legacy devices, and extended transition timelines due to safety considerations, certification requirements, extended lifespans, and other factors. Similar aspects are relevant for OT too, as highlighted by CISA in a previous publication.
TLS
For internet-scale TLS data, we use the TLS versions supported by servers as a proxy for PQC support. Only TLSv1.3 (released in 2018) is positioned to support PQC.
TLSv1.3 was the third most popular version of the protocol a year ago. It is now the second most popular — driven by migrations from TLSv1 and TLSv1.1. TLSv1.3 now runs on 30% of identified servers, up from 19%, while TLSv1.2 runs on the same 43% identified a year ago.
Within enterprise networks, we can look deeper into the Key Exchange Mechanism (KEM) algorithms used in TLS connections and distinguish devices between PQC-capable (those offering PQC ciphers) or not:
These results are slightly different than what we saw for SSH for several reasons, such as devices adopting SSH and TLS upgrades at different times and the data for SSH being based on actively querying devices. TLS data is based on passively listening to connections. In general, SSH is easier to upgrade since it is usually a standalone application. TLS is implemented in several libraries linked to several applications with several different configurations.
Nevertheless, the overall trend remains the same: IT devices most commonly support PQC on TLS while specialized devices are left behind. In this case, OT is markedly behind.
One key takeaway we have emphasized since we started tracking PQC adoption: PQC readiness must be evaluated in the context of quantum risk, not just adoption rates.
With that in mind, the figure below shows the percentage of devices in enterprise networks without PQC-capable TLS and a critical risk score, according to the same risk scoring methodology we use for the annual riskiest devices report, which considers vulnerabilities, asset criticality, and internet exposure.
Notice that here, as opposed to the previous charts, a higher percentage is negative. Two-thirds of OT devices and nearly half of IoT devices in organizations’ networks have critical risk and are not PQC-capable. These are the highest-priority exposure areas for organizations as we accelerate toward Q-day and work to improve quantum readiness and quantum-safe security posture.
Quantum Risk Mitigation Recommendations
The migration data continues to show that traditional, managed IT systems will be easier to transition to PQC, while unmanaged critical assets that are internet-exposed and can’t be easily patched represent the primary risk.
To help organizations identify these risky areas, Forescout launched today PQC Readiness and Encryption Hygiene Dashboards that summarize information about which devices in your network are PQC-capable and which are most at risk. This offers organizations a crystal clear view of where the highest-risk gaps exist in their environments. That capability is built on patented technology to identify the use of quantum-unsafe encryption coupled with Forescout’s deep understanding of risk across different types of network assets.
Beyond identifying areas of risk and planning migration, one immediate action that organizations can do to start mitigating risk for unmanaged devices is employing Secure Remote Access (SRA).
SRA gateways mediate each interaction between a user and an unmanaged asset, ensuring that those assets – and their potentially vulnerable communications – are not directly exposed on the internet.
Our research shows that unmanaged, internet‑exposed assets are among the most vulnerable to “harvest now decrypt later” (HNDL) attacks and among the hardest to upgrade. SRA mitigates this risk by centralizing quantum‑safe security controls at the gateway, reducing exposure while PQC migration remains incomplete.