GitHub SSH security changes begin taking effect on 14 October 2026, when newly uploaded RSA SSH keys must be at least 3072 bits and GitHub starts enabling the hybrid post-quantum key exchange mlkem768x25519-sha256. The same migration also includes the planned removal of RSA signatures that use SHA-1 and the older diffie-hellman-group-exchange-sha256 key exchange.
For most developers using current SSH clients, the transition should be uneventful. The risk is concentrated in older build agents, long-lived CI images, legacy Java libraries, outdated PuTTY installations and unattended deploy systems that may still negotiate algorithms GitHub is retiring.
What the GitHub SSH security changes include
GitHub announced four related changes. From 14 October, any new RSA key uploaded for authentication or signing must be at least 3072 bits. On the same date, GitHub will enable mlkem768x25519-sha256 for SSH sessions on github.com and GitHub Enterprise Cloud with Data Residency, except for the U.S. region.
GitHub is also phasing out the ssh-rsa signature type that uses SHA-1, together with diffie-hellman-group-exchange-sha256. Brownouts are scheduled for 4 November and 9 December 2026, followed by final removal on 13 January 2027.
The naming can be confusing. An RSA key is not automatically obsolete simply because its public-key type is labelled ssh-rsa. GitHub is retiring the RSA signature method that uses SHA-1. Existing RSA keys can continue to work if the SSH client signs with SHA-2 using rsa-sha2-256 or rsa-sha2-512.
Why this matters for developers and small teams
The main risk is not a developer laptop running a current version of OpenSSH. It is the system nobody has touched for years: a deployment server, old Jenkins node, appliance, Java application or container image that still depends on an older SSH stack.
GitHub lists minimum versions that support RSA with SHA-2 reliably in their default configurations, including OpenSSH 7.2p1, TeamCity 2021.2.3, Go SSH 0.16.0, libssh2 1.11.0 and PuTTY 0.82. Teams using older software should test now rather than wait for the November brownout.
This is especially relevant for automation because failures may first appear in unattended jobs rather than interactive developer sessions. Nevelit’s recent article on GitHub vulnerability reporting controls looked at a different part of GitHub security, but the operational lesson is similar: security changes are most manageable when teams identify affected workflows before they fail.
Post-quantum SSH is arriving without a forced migration
The new mlkem768x25519-sha256 option combines ML-KEM-768 with X25519. NIST standardised ML-KEM in FIPS 203 in August 2024 as a key-encapsulation mechanism designed to remain secure against a sufficiently capable quantum computer.
GitHub’s deployment is hybrid rather than purely post-quantum. That matters because the connection retains protection from an established classical elliptic-curve method while adding protection from ML-KEM. For users, the change should normally be transparent: compatible clients can negotiate the new method, while older clients can fall back to another supported key exchange.
This does not mean teams need to replace every SSH key with a post-quantum credential. The October change concerns key exchange and the minimum size of newly uploaded RSA keys. GitHub still recommends Ed25519 for new SSH keys where compatibility permits.
What to check before 14 October
- Identify SSH-based Git remotes. Repositories using HTTPS are outside the scope of these SSH changes.
- Inventory CI/CD clients. Check build agents, deployment hosts, containers and automation libraries, not only developer workstations.
- Review RSA key generation scripts. Any process that still creates 2048-bit RSA keys for later upload to GitHub will need to change.
- Test old clients. Verify that they negotiate RSA with SHA-2 rather than the SHA-1 ssh-rsa signature type.
- Prefer Ed25519 where practical. GitHub recommends it for newly generated keys when compatibility is not a constraint.
- Use the brownouts as a test window. A failure on 4 November is a warning that the workflow needs remediation before final removal.
Trade-offs and compatibility concerns
The security rationale is clear, but compatibility work can still be awkward. Old libraries embedded in enterprise software may be difficult to upgrade independently. Replacing a client can require application testing, while changing a deploy key may involve several systems that assume a particular key format.
Teams should also avoid replacing keys unnecessarily. GitHub explicitly says existing RSA keys do not need to be regenerated merely because the old signature type is being removed. If the client already supports RSA with SHA-2, the same key can continue to work.
That distinction matters operationally. A rushed key rotation can create more risk than a controlled client upgrade, especially where credentials are embedded in multiple deployment environments.
Why GitHub is tightening the baseline now
The migration follows a wider move away from SHA-1 and towards stronger cryptographic defaults. GitHub disabled SHA-1 for HTTPS connections in September 2026, and the SSH changes continue that modernisation effort.
The RSA key-size requirement also aligns new uploads with a stronger security baseline, while ML-KEM gives compatible SSH clients a post-quantum option without requiring users to redesign their authentication setup. That combination suggests GitHub is treating post-quantum migration as an incremental infrastructure change rather than a one-time replacement project.
Critical analysis
The most important part of the GitHub SSH security changes is not the new post-quantum algorithm. For most organisations, the immediate operational issue is discovering old clients before the SHA-1 and legacy Diffie-Hellman removals expose them.
Teams should therefore separate two questions. First, can every current SSH workflow negotiate algorithms GitHub will continue to support? Second, can newer clients take advantage of stronger options such as the hybrid ML-KEM exchange? The first is a compatibility requirement; the second is a security improvement.
For small businesses and development teams, the sensible response is an inventory and test exercise rather than a broad key replacement campaign. Check the systems that connect to GitHub over SSH, update outdated clients, fix RSA key-generation scripts and use the announced brownouts to validate the result.
Sources
- GitHub Changelog — Security improvements for SSH, 22 September 2026.
- GitHub Docs — Generating a new SSH key and adding it to the ssh-agent, accessed 6 October 2026.
- NIST FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard, finalised 13 August 2024.
- Chornous.dev — GitHub drops SHA-1 RSA signatures over SSH and adds a post-quantum key exchange, 28 September 2026.
Leave a Reply