Key Findings
- Post-quantum cryptography (PQC) support for SSH servers is growing
- 8.5% of all SSH servers
- 26% of all OpenSSH servers
- TLSv1.3 adoption, which supports PQC, hasn’t grown in the past few months
- TLSv1.3 adoption remains at 19%
- TLSv1.2 – which does not support PQC – increased from 43% to 46%
- Unmanaged devices are getting left behind and there is still a long way to go until most are quantum-safe
- IoT, OT, IoMT and network equipment have much lower adoption of PQC for SSH than traditional IT assets.
- The PQC migration doesn’t end with TLS and OpenSSH
- Industry adoption is uneven — especially for sectors with many unmanaged devices
- Manufacturing, oil and gas, and mining have the lowest PQC adoption rates
- Professional and business services have the highest
Recommendations
- Educate your team on NIST’s “Migration to PQC” guidelines mapping to CSF 2.0 and NIST SP 800-53
- Classify your data by longevity and sensitivity
- Build an inventory of the assets in your network that do or do not support PQC
- Correlate that inventory with contextual information about these assets to understand risk
Not long ago, most security leaders still thought the threat of quantum computing was something far away in the future. But the need to migrate network assets – IT, IoT, OT, medical devices, and others – to post-quantum cryptography (PQC) is closer than many realize.
As we approach the countdown to Q-Day – the day when a quantum computer can break asymmetric encryption in practice – a lot of preparation work is needed to inventory and prioritize those network assets most at risk and create migration plans. Current quantum migration roadmaps throughout the world now define transition deadlines to PQC between 2030 and 2035, especially for critical assets.
Recently, Forescout announced the release of patented technology to detect the use of quantum-unsafe encrypted communications across network assets. At the same time, we published our first blog covering the risks of not adopting PQC and tracked the status of PQC adoption on the internet. We found:
- Only 6% of all SSH servers – or 20% of those running OpenSSH – already supported PQC
- 19% of HTTPS servers used TLSv1.3 which could support PQC algorithms
That blog analyzed data available at the end of April. Now, we extend this dataset to the end of August combined with data from Forescout’s Device Cloud — our repository of detailed information about monitored assets. Here, we want to understand what devices have already migrated and what industries are ahead in the PQC transition. Our new data shows:
- PQC support is growing, mostly for the standardized algorithms and mostly via new OpenSSH versions. Now, 8.5% of all SSH servers (26% in the case of OpenSSH) support PQC key exchange. TLSv1.3 adoption remains at 19%.
- Unmanaged devices are getting left behind. While more than 40% of IT assets using OpenSSH already run versions supporting PQC, that number decreases to 20% for IoT, 11% for OT and network equipment, and only 2% for IoMT.
- Industry adoption is uneven. Every industry we track has less than 50% of devices with OpenSSH supporting PQC. Industries that more heavily rely on unmanaged devices, such as manufacturing, oil and gas, and mining have the lowest PQC adoption rates. The highest rate was seen on professional/business services.
Based on these findings, we discuss what organizations should expect for the near future and what actions can help to mitigate risk.
The PQC Migration Is Advancing Towards Standardized Algorithms
At the end of August, there were over 175 million SSH hosts on the Internet supporting several different key exchange (KEX) algorithms, which are used to establish the session keys for end-to-end encrypted communication.
As in our original dataset, the most popular PQC KEX algorithms – shown in the table below – continue to be 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] | 11,942,238 | 6.80% |
sntrup761x25519-sha512 | 2,336,403 | 1.33% |
mlkem768x25519-sha256 | 643,474 | 0.37% |
[email protected] | 64,341 | 0.04% |
mlkem768nistp256-sha256 | 1,494 | < 0.01% |
mlkem1024nistp384-sha384 | 1,411 | < 0.01% |
Other PQC | 128 | < 0.01% |
Three observations are relevant:
- PQC support is growing. The absolute number of servers with PQC support grew from 11.5 million in April to almost 15 million in August, an increase of 30%. The relative number grew from 6.2% of total servers to 8.5%.
- Support is growing on the standardized algorithms. In April, we still saw several experimental algorithms marked with vendor extension names such as “@openquantumsafe” and “@amazon”. We don’t see those anymore. There are still a few entries marked as Kyber and FrodoKEM, which tend to disappear, since the largest growth is in the two most popular PQC KEX. As the figure below shows, sntrup761x25519-sha512 grew by 17% between April and August, while mlkem768x25519-sha256 grew by 323% in the same period.
- Most of the growth comes from upgrading OpenSSH versions. The percentage of OpenSSH versions between 7.0 and 8.9, released before OpenSSH added support for PQC by default, decreased from 75% to 70%. At the same time, versions 9.0 until 10, which have SNTRUP and then ML-KEM as default KEX increased from 21% to 26%. 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. There are now over 10,000 servers running Dropbear 2025.87 and 2025.88, which support PQC.
But Unmanaged Devices Are Getting Left Behind
Using data from Forescout’s Device Cloud, we drilled down into the device types and industries that use those quantum-safe OpenSSH versions.
The figure below shows that while 42% of IT devices use OpenSSH versions that support PQC, this number is only 20% for IoT, 11% for network equipment and OT, and a tiny 2% for IoMT devices.
This distribution is not surprising since IT devices are usually the easiest to upgrade, but the most worrisome finding is about network devices, such as routers, firewalls and VPN appliances. These devices are often exposed online and SSH is used to manage them remotely, which can provide privileged initial access to attackers. Threat actors have been showing special interest in this kind of device for espionage and pre-positioning. The possibility that their credentials could be cracked during transmission because of weak encryption is alarming.
Among the IoT, OT and IoMT devices, some examples of specific functions with the lowest adoption percentages include Physical Access Control (1%), VoIP (1%) and Healthcare Communication Systems (2%).
Go deeper: Watch Forescout CEO Barry Mainz, Chief Strategy Officer, Robert McNutt, and Daniel dos Santos, Sr. Director of Research at Vedere Labs, in conversation on post-quantum cryptography:
The figure below shows the percentage of devices with OpenSSH versions supporting PQC broken down by industry. Every industry we tracked is below 50% adoption. Those industries that more heavily rely on unmanaged devices tend to have the lowest adoption rate of PQC which is consistent with our previous findings.
What the Future Holds
As expected, the percentage of SSH servers on the internet with a default PQC KEX is still growing, but at a much slower pace than between 2022 and early 2024 when the first OpenSSH versions supporting PQC were released. It finally broke out of the 20-25% plateau we identified in our original research (now 26%), but there is still a long way to go until most SSH servers on the internet are quantum-safe.
Similar findings hold for TLS. The IETF is only adding PQC support for TLSv1.3. The good news is that v1.3 is now the second most popular version on the internet (it was the third in April). But in relative terms, it remained at 19% of the share of traffic while TLSv1.2 – which does not support PQC – increased from 43% to 46%.
These two figures show that the PQC transition will be long and complex. Here’s why:
- The PQC migration doesn’t end with TLS and OpenSSH. There are many other common protocols that have separate migration roadmaps, such as IPSEC / IKEv2 and WireGuard for VPN tunnels. There are also many other protocols that are OT- or IoMT-specific and will require different approaches, but there the biggest challenge has been adopting encryption in the first place.
- Many embedded devices use outdated crypto libraries. Even if popular applications and libraries like OpenSSH and OpenSSL adopt PQC, that does not mean that every device out there can just use the new version of these software. During our Project Memoria research, we catalogued over 50 TCP/IP stacks used in embedded devices. While many of them rely on well-maintained libraries, such as mBedTLS for cryptographic support, some popular stacks had their own implementations or used outdated libraries. Recent research has shown that planned PQC support across several cryptographic libraries is uneven.
What To Do About It
The new findings confirm that those who can easily upgrade servers and devices will likely do so fast, but we will see decreasing rates of growth in PQC adoption as the easy deployments are done first. That leaves organizations with the task of understanding the risk they are exposed to and what can be done to mitigate this risk.
The first step towards PQC migration is to build an inventory of what assets in your network support PQC or not, something that Forescout’s patented technology can help you to do.
The National Institute of Standards and Technology (NIST) is currently running a “Migration to PQC” project where one of the workstreams is cryptographic discovery. In September, NIST released a whitepaper mapping the capabilities defined in that workstream to the Cybersecurity Framework 2.0 (CSF 2.0) and the Security and Privacy Controls for Information Systems and Organizations (NIST SP 800-53). This is valuable reading for you to determine how prepared your organization is to start building this inventory and then planning your migration.
But as you plan the migration, you need to really understand asset risk. And for that you need deeper contextual information about these assets. For example, a TLS 1.2 handshake using RSA-2048 might look dangerous, but if it’s protecting short-lived traffic in a hardened enclave, it’s a red herring. Conversely, an outdated FTP server quietly archiving merger documents is a strategic liability. This kind of context is crucial: know where cryptographic risk resides and what it protects. Scanning for unsafe algorithms is not about panic. It is about mapping your exposure with clarity.
So here is a pragmatic strategy to start thinking about your own quantum migration roadmap:
- Classify data by longevity and sensitivity.If it won’t matter in 12 months, you’re fine. If it will matter in 12 years, you are not. For network assets, sensitive information, such as credentials, are paramount. Here, there are risks beyond quantum attacks. If your environment allows static credentials, long-lived sessions, or unmanaged tokens, these hygiene issues need to be addressed first, regardless of the algorithm in play.
- Instrument your infrastructure.Use Forescout to detect legacy cryptography, correlate that with contextual asset information, map exposure, and enable network segmentation and other security controls.
- Design for agility.It’s important to keep in mind that quantum-safe does not mean quantum-proof. It means resistant to known attack vectors as best understood today. That definition will evolve. Your crypto stack must be able to evolve with it. Make sure to build key rotation and algorithm swapping into your newly deployed cryptographic frameworks from day one.
Want to stay on top of the latest threats? Sign up for the Vedere Labs Threat Feed and get the full context of these threats in our monthly newsletter.