GitHub Enables Post-Quantum SSH Key Exchange—For Now, Not in the US

Today, October 14, 2026, GitHub began applying two changes to SSH: newly uploaded RSA keys must be at least 3,072 bits long, and the post-quantum key-exchange algorithm mlkem768x25519-sha256 is being enabled for some connections. The changes apply to SSH connections; users accessing Git over HTTPS do not need to change their settings because of this announcement.

GitHub’s September 22 announcement says the algorithm is becoming available on github.com and GitHub Enterprise Cloud with Data Residency, excluding the US region. This marks the start of platform support; whether the new algorithm is actually used also depends on the SSH client and its configuration.

What’s changing

New RSA SSH keys uploaded after October 14 must be at least 3,072 bits long. Existing RSA keys do not need to be changed solely because of their length: GitHub recommends using RSA-SHA-2 signatures with them—rsa-sha2-256 or rsa-sha2-512. The company also recommends Ed25519 for new keys when that type is suitable for the environment.

The second change concerns session-key negotiation. mlkem768x25519-sha256 combines ML-KEM—a post-quantum key-encapsulation mechanism—with X25519. According to GitHub’s plan, compatible clients configured to prefer this algorithm will be able to select it automatically. Older clients should fall back to a supported compatibility algorithm.

What your team should check

1. Identify how you connect. Check your Git remote URLs: entries beginning with https:// are not affected by the SSH changes. For SSH, check the clients, libraries, and integrations in use.
2. Check RSA signatures. Make sure the client and library in use support RSA-SHA-2. GitHub lists minimum versions for popular implementations, including OpenSSH 7.2p1, Go SSH 0.16.0, and libssh2 1.11.0.
3. Check new keys. If your organization’s policy requires RSA, a new key must be at least 3,072 bits long. For an RSA key that has already been uploaded, support for the signature algorithm matters more than generating a replacement solely because of this change.
4. Check client support for ML-KEM. A platform update alone does not guarantee that a particular client will choose the new key exchange. First, check its documentation and behavior in a test connection; for older clients, plan upgrades according to your organization’s schedule.

There is also a separate phase coming later: GitHub has scheduled trial disablements of the outdated RSA signature using SHA-1 and the diffie-hellman-group-exchange-sha256 mechanism for November 4 and December 9, 2026, with final removal planned for January 13, 2027. So today’s requirement for the length of new RSA keys and the future retirement of older algorithms should be treated as separate migration tasks.

For teams, the practical priority today is to inventory SSH clients and check RSA-SHA-2 support, then separately test ML-KEM support. Availability of the new algorithm has not yet been announced for users in the US; the size requirement for new RSA keys already applies to uploads made after October 14.