Skip to content
SECURITY · POST-QUANTUM SECURITY / SSH

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.

Published Source report Sources checked
Reading tools for text size, copying, printing and your reading list
My reading list
Dense blue network cables and illuminated racks of Wikimedia Foundation servers.
Wikimedia Foundation servers, photographed in July 2015. Archival infrastructure context; this photograph does not establish whether these servers were scanned or which cryptography they use.Image: Wikimedia Foundation servers in July 2015 · Victor Grigas / Wikimedia Foundation · CC BY-SA 3.0Full image credit

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.”

Keep your reading trail

Evidence & context

2 linked sources

New preprint about a February snapshot; original explanation separates advertised capability, negotiated connections and authentication.

How to read the evidence and dates

An announcement records what an organization stated. An experiment reports an observation. A simulation or resource estimate depends on its assumptions. QubitWire’s analysis connects these sources; the labels are not quality scores.

Published is the article’s first QubitWire publication. Updated marks a substantive content change. Sources checked records a review of the underlying evidence. An older paper can support a new explanation, and another press release about the same work is not independent replication.

QubitWire take

Ask for the negotiated connection, not just a product label. Advertised key-exchange support does not prove complete post-quantum migration.

Sources

  1. Bitsight researchers: SSH adoption preprint

    Posted November 6, 2026; measurements February 16, 2026. Preprint, not established peer-reviewed evidence.

  2. OpenSSH: post-quantum cryptography guidance

    Official implementation guidance checked November 10, 2026. Key exchange and signatures are separate migration tasks.

READ NEXT

Continue exploring

All Security stories
  1. More on post-quantum security

    The web’s quantum-security upgrade has a size problem

    New funding for Let’s Encrypt supports a different way to prove a website’s identity without carrying a bulky certificate chain through every connection.

    Published · Source report · Sources checked · About 4 min read
  2. More on post-quantum security

    Quantum-safe encryption still has an ordinary-computer problem

    A newly started European project will test how post-quantum cryptography behaves in real devices. The mathematics is only one part of keeping a secret.

    Published · Source report · Sources checked · About 4 min read