CybersecurityGitHub SSH Security Changes: RSA SHA-1 Retirement, 3072-bit Keys and Post-Quantum Key Exchange
GitHub has published a staged SSH security transition: new RSA keys uploaded after October 14, 2026 must be at least 3072 bits, SHA-1 RSA signatures and an older Diffie-Hellman exchange are scheduled for removal, and GitHub is adding ML-KEM hybrid post-quantum key exchange support.
Accuracy-reviewed by the editorial team
Coverage note: This Zeph Tech briefing was published on September 29, 2026 and covers GitHub’s SSH security announcement. Several dates are still in the future. Administrators should verify GitHub’s current changelog before a migration because schedules can change.
GitHub is tightening the cryptographic baseline for SSH connections and adding a hybrid post-quantum key-exchange option. The changes matter most to organizations with older Git clients, automation libraries, build servers or long-lived SSH configurations. Teams using HTTPS Git remotes are outside the primary impact described by GitHub, but organizations with SSH-heavy CI/CD should inventory client versions now rather than discovering incompatibility during a brownout.
What is changing
GitHub says it will remove the ability to use RSA keys with the SHA-1 ssh-rsa signature type, remove the diffie-hellman-group-exchange-sha256 key-exchange mechanism, and require newly uploaded RSA SSH keys to be at least 3072 bits beginning October 14, 2026. GitHub is also adding support for the hybrid post-quantum key-exchange method mlkem768x25519-sha256 on github.com and GitHub Enterprise Cloud with Data Residency, except for the U.S. region as described in the announcement.
The distinction between an RSA key and the ssh-rsa signature algorithm is important. GitHub explains that an existing RSA key does not automatically need to be replaced if the client can use RSA with SHA-2 signatures such as rsa-sha2-256 or rsa-sha2-512. The migration problem is therefore often an outdated SSH implementation or configuration, not simply the presence of an RSA public key.
The published schedule
GitHub’s current schedule sets October 14, 2026 for the new minimum size on newly uploaded RSA keys and for enabling the ML-KEM hybrid key exchange in the listed environments. Brownouts for the deprecated SHA-1 RSA signature type and older Diffie-Hellman exchange are scheduled for November 4 and December 9, 2026. Final removal is scheduled for January 13, 2027. GitHub Enterprise Server receives the changes in later product versions identified in the announcement.
Brownouts are operationally useful because they surface hidden dependencies before permanent removal. Organizations should treat them as planned validation windows, not unexpected outages. A build server that fails only during a brownout is evidence of an obsolete SSH path that needs remediation before the final date.
How to inventory exposure
Search CI/CD systems, developer workstations, deployment automation, artifact builders, source mirrors and third-party integrations for Git remotes beginning with git@github.com: or ssh://. Record the actual SSH implementation and version behind each workflow. The visible application name is not enough because Java libraries, embedded appliances and build tools may carry their own SSH stack independently of the operating system’s OpenSSH client.
Test the negotiated algorithms rather than inferring them from the key file name. An RSA public key labeled ssh-rsa can still be used with a SHA-2 signature when the client and server negotiate it. Capture verbose SSH negotiation in a controlled test or use the relevant client diagnostics to confirm whether the workflow depends on SHA-1 or the retiring Diffie-Hellman exchange.
Migration priorities
Upgrade old SSH clients and libraries first. GitHub’s announcement lists baseline versions for several common implementations, including OpenSSH, JSch, TeamCity, Go SSH, libssh2 and PuTTY, that support RSA with SHA-2 robustly in default configurations. Use the current vendor documentation for each product rather than treating those versions as universal security-support guarantees.
For new developer keys, GitHub recommends Ed25519 when possible. If compatibility requires RSA, new uploads after the scheduled October date must meet the 3072-bit minimum. Do not regenerate every existing RSA key reflexively: determine whether the current client negotiates SHA-2 and whether key rotation is otherwise warranted by age, ownership, storage or exposure. Unnecessary emergency key churn can create its own operational risk.
Post-quantum key exchange without hype
The mlkem768x25519-sha256 method combines ML-KEM with X25519 in a hybrid construction. GitHub says compatible SSH clients should use the new method when configured to prefer it, while older clients can fall back to another supported exchange. The practical near-term value is cryptographic agility: organizations can begin using a quantum-resistant component without making SSH connectivity depend exclusively on a new algorithm.
Post-quantum support does not eliminate the ordinary causes of SSH compromise. Stolen private keys, excessive repository permissions, exposed CI secrets, unreviewed deploy keys and compromised developer endpoints remain immediate risks. The new key exchange should be treated as one layer in a broader identity and access-control program rather than a substitute for key hygiene.
Validation plan before GitHub’s brownouts
Create a representative test matrix covering developer clients, CI runners, build servers, automation libraries and service accounts. For each, test clone, fetch, push and any signed or automated operation that uses SSH. Capture client versions and negotiated algorithms, then remediate unsupported paths. Re-run the matrix during the published brownout windows if operationally feasible so the organization gets evidence before final retirement.
Make rollback planning explicit. If upgrading an embedded library breaks a critical release path, know whether the workflow can temporarily use HTTPS with a supported authentication method while the SSH dependency is repaired. A fallback should be secure and tested in advance; disabling host verification or re-enabling weak algorithms under deadline pressure is not an acceptable recovery strategy.
CI/CD and machine-account considerations
Machine users deserve separate testing from developer laptops because they often run older runtimes for years and fail outside normal business hours. Inventory self-hosted runners, release appliances, dependency mirrors, infrastructure-as-code systems and vendor integrations that authenticate to GitHub over SSH. Record an accountable owner and a tested upgrade path for every dependency that cannot meet the new baseline.
Use the transition to review key ownership as well as algorithms. Shared private keys, deploy keys with broad repository access and credentials copied between build systems create risks that stronger cryptography does not solve. Where possible, give automation a narrowly scoped identity, store private material in a managed secret system, rotate abandoned credentials and remove keys whose owner or purpose cannot be established.
Longer-term security lesson
Cryptographic deprecation is an inventory problem as much as a mathematics problem. Modern services can remove weak algorithms only when customers know which clients still depend on them. Maintaining an accurate list of protocols, libraries, keys and automation owners makes future deprecations routine instead of disruptive. The same discipline will matter as post-quantum transitions expand beyond a single Git hosting service.
Questions teams should be able to answer
Do all existing RSA keys have to be replaced?
No. GitHub says existing RSA keys can continue when the SSH client supports RSA with SHA-2 signatures. The deprecated item is the SHA-1 ssh-rsa signature type, not every RSA key.
Who is most likely to break?
Older SSH libraries, long-lived build systems and embedded integrations deserve the earliest testing. Modern OpenSSH clients generally negotiate stronger algorithms automatically, but organizations should verify their actual environment.
Does ML-KEM require every user to upgrade immediately?
GitHub says older clients can fall back to an older supported key-exchange algorithm. The immediate operational deadline is more likely to come from deprecated algorithms than from failure to adopt the new hybrid exchange.
Related Zeph Tech guidance
Use the Developer Enablement guide to manage tooling baselines, the Vulnerability Management Program guide for controlled remediation, and the risk register to assign owners for legacy SSH dependencies and time-bound exceptions.
Further reading
- Security improvements for SSH — GitHub Changelog
- OpenSSH release notes — OpenSSH
Continue in the Cybersecurity pillar
Return to the hub for curated research and deep-dive guides.
Latest guides
-
Network Security Fundamentals: Segmentation, DNS, Zero Trust & Monitoring | Zeph Tech
A 2026 practitioner guide to network segmentation, firewall policy, DNS security, remote access, encrypted traffic, monitoring, administration, and zero-trust architecture.
-
Small Business Cybersecurity Survival Checklist
A practical 2026 cybersecurity operating guide for small and medium-sized businesses, organized around NIST CSF 2.0 and current FTC guidance with bounded Verizon DBIR threat…
-
Cybersecurity Operations Playbook
Build a defensible cybersecurity operations program around NIST CSF 2.0, current incident-response guidance, exploited-vulnerability prioritization, evidence capture, and…
Coverage intelligence
- Published
- Coverage pillar
- Cybersecurity
- Source credibility
- 40/100 — low confidence
- Topics
- GitHub · SSH · RSA SHA-1 · Post-quantum cryptography · ML-KEM
- Sources cited
- 2 sources (github.blog, openssh.org)
- Reading time
- 6 min
Further reading
- Security improvements for SSH — GitHub
- OpenSSH release notes — OpenSSH
Source feedback
Editorial
Found a factual issue, superseded source, broken citation, or important context we should review? Send the specific claim and supporting source through the correction path so it can be evaluated against the article record.