GitHub’s 3072-bit RSA and post-quantum SSH changes are now live

GitHub’s [SSH security schedule](https://github.blog/changelog/2026‑09‑22‑security‑improvements‑for‑ssh/) set October 14 as the date when newly added RSA keys must be at least 3072 bits. The rule applies when adding a key; it does not state that every existing shorter key is immediately deleted. GitHub recommends Ed25519 for new keys where the local platform supports it. Its [key‑generation guide](https://docs.github.com/en/authentication/connecting‑to‑github‑with‑ssh/generating‑a‑new‑ssh‑key‑and‑adding‑it‑to‑the‑ssh‑agent) provides current commands and notes for older systems. Inventory keys before rotating them. Removing a working key before its replacement is installed can interrupt Git and automation access.

GitHub also enabled `mlkem768x25519‑sha256`, a hybrid post‑quantum key‑exchange algorithm, on GitHub.com and GitHub Enterprise Cloud with data residency except the U.S. region. Compatible clients can negotiate it; older clients fall back to an algorithm they share with the server. That means the server‑side addition is designed to be compatible rather than an immediate client mandate. It changes key exchange, not the SSH public key stored on an account. Check the algorithm actually negotiated in a controlled verbose connection when evidence matters. A successful clone alone does not identify the selected key exchange.

GitHub scheduled brownouts for `ssh‑rsa` SHA‑1 signatures and `diffie‑hellman‑group‑exchange‑sha256` on November 4 and December 9. Permanent removal is scheduled for January 13, 2027. An RSA account key does not automatically mean the client uses the SHA‑1 `ssh‑rsa` signature. Modern OpenSSH can sign with RSA‑SHA2 using the same key. The client version and negotiation determine whether action is required. Use the brownout dates as test windows, then update unsupported clients before the final removal rather than waiting for a production failure.

Repositories using HTTPS remotes do not negotiate these SSH algorithms. They are unaffected by this specific cutover, although their tokens and credential helpers have separate security requirements. For SSH users, [GitHub’s connection test](https://docs.github.com/en/authentication/connecting‑to‑github‑with‑ssh/testing‑your‑ssh‑connection) confirms authentication to the expected host and account. Run it after adding a replacement key, and test the actual automation identity separately from a developer laptop. Do not copy private keys between systems to simplify migration. Generate and register a distinct key for each controlled identity.

List local OpenSSH versions, configured GitHub hosts, account keys and machine identities. Flag new RSA provisioning below 3072 bits, clients that depend on SHA‑1 signatures and clients lacking supported key exchange. Add replacements before revoking old credentials, verify authentication, then remove superseded keys under the normal access‑review process. Preserve an owner and deadline for every exception. Follow [GitHub’s OpenTools organization page](https://opentools.ai/organizations/github) for further platform‑security changes. *Image: Real screenshot of GitHub’s official SSH security schedule. OpenTools captured the source page without generative alteration or artificial upscaling.*