Does your server offer post-quantum SSH, and does your connection use it?
A newly posted study examines a February 2026 snapshot of 1.52 million internet-facing SSH hosts. Its useful finding comes with an equally useful distinction: an available cryptographic option still has to be selected.
Reading tools for text size, copying, printing and your reading list

A study posted on November 6 found that 45.2% of the SSH hosts in its sample advertised a post-quantum key-exchange option. The measurements came from February 16, 2026. They describe what those servers offered on that day, rather than how many connections are protected today.[1]
SSH is the secure connection people use to administer remote computers. For someone responsible for a website, application or company server, the study turns a broad concern about future quantum computers into a practical question: which key exchange does the administrator’s connection actually use?
That question has two parts. The server must offer a suitable option, and the client connecting to it must negotiate that option. A list of available algorithms answers the first part. Evidence from the connection answers the second.
What the researchers counted
Four researchers at cybersecurity company Bitsight examined data from its GROMA scanning platform. After cleaning the records, they had 1,523,998 unique IP addresses with information about the key-exchange algorithms advertised by their SSH services on port 22. Of those, 688,814 listed at least one post-quantum option and 835,184 did not.[1]
The researchers also mapped addresses to organizations. Among 27,012 organizations in that dataset, 10,788 had at least one observed host offering a post-quantum option, or 39.9%. That organizational figure uses a low threshold: one qualifying host is enough. It does not establish that every server belonging to that organization had been upgraded.[1]
The work is a preprint. Its organizational mapping uses Bitsight’s proprietary attribution system, and its view is limited to the public-facing services captured by the scan. Private systems, services outside the observed inventory and SSH running on other ports are outside this particular count. The researchers did not measure the algorithms selected by users’ everyday connections.[1]
Those boundaries matter when sharing the headline percentage. A server count gives each observed IP address one place in the sample. It does not measure how often a server is used, how many people depend on it or how much confidential information passes through it.
Why the login connection matters
When an SSH session begins, key agreement lets its two ends establish the secret used to protect the connection. The concern is that an attacker could record encrypted sessions now and decrypt them later if a sufficiently capable quantum computer becomes available. That possibility gives long-lived confidential information a reason for attention before such a machine exists.[2]
OpenSSH, a widely used SSH implementation, already provides a migration path. Its official guidance says post-quantum key agreement has been offered by default since version 9.0, released in April 2022. A second option combining ML-KEM with X25519 arrived in version 9.9 and became the default in 10.0, in April 2025. These are hybrid schemes, combining post-quantum and classical methods.[2]
This history also limits what can be inferred from the scan. Finding an advertised option does not reveal why it is there. It could reflect a software default or a deliberate configuration choice; the measurement does not distinguish between them. Nor does the absence of an option explain the owner’s budget, priorities or migration plans.
Three questions for whoever runs the server
First, ask which SSH implementation and version are running at both ends. Then ask which key-exchange options the server permits. OpenSSH’s guidance specifically recommends checking its KexAlgorithms setting when an otherwise capable server does not offer the expected options.[2]
Second, ask for the algorithm negotiated by a representative connection. Keep that result alongside the client, server and configuration details. An upgrade plan becomes easier to assess when the evidence identifies a working connection rather than only a product’s capabilities.
Third, keep key exchange and authentication separate. Protecting a session against later decryption does not establish that its server-identity checks or user-signature algorithms are also post-quantum. OpenSSH treats signature migration as a separate task in its guidance.[2]
For a non-specialist, the request can be straightforward: “Can you show which key exchange our normal server connection uses, and which parts of authentication still need a future upgrade?”
The February snapshot provides a substantial inventory of advertised capability. Its most useful application is to make the next check more precise. A dated record of what your own connection negotiates says more about that connection than a broad claim that a server, organization or product is “quantum-safe.”