GitHub has adopted the origin-bound draft standard for SMS-delivered security codes. The change alters how the code appears in the message itself and lets a browser or app verify the code’s recipient before offering autofill — closing a phishing gap that the existing autofill approach left open.

When Apple introduced SMS security code autofill in iOS 12 and macOS Mojave, the feature relied on heuristics to decide whether a received message contained a code meant for the active page. That assumption is what made autofill convenient, but it also made it exploitable: if a user landed on a lookalike sign-in page, the browser would still offer to fill the code there. Manual entry had the same weakness — the user had no way to know the code’s intended destination.

The problem is that SMS itself carries no binding between the sender and the site where the code should be entered. A classic person-in-the-middle attack demonstrates why this matters. A victim visits a page impersonating github.com and enters their username and password. The attacker relays those credentials to GitHub, triggering a real SMS code. The victim, believing they are on the legitimate site, types the code into the fraudulent page, and the attacker uses it to sign in.

The origin-bound standard addresses this by defining a message format that explicitly ties the code to the originating site. For GitHub, the security code text now includes a standardized footer line with the site’s origin and the code:

123456 is your GitHub authentication code.

@github.com #123456

The browser uses that footer to decide whether to autofill. If the active page isn’t GitHub.com, the code will not be offered as an autofill candidate. Relying on the browser to follow that rule is far more dependable than expecting users to parse URLs and understand their security implications — something research shows people consistently struggle with.

Platform Support and the Web OTP Path

Apple is the first implementer of the origin-bound standard, with support arriving in iOS 14 and macOS Big Sur. The underlying spec, however, is not proprietary. It also serves as the basis for Google’s Web OTP API, a proposal for a standard JavaScript interface that paves the way for security codes to be fetched and autofilled through a unified web API. Current Web OTP support is limited to Android. GitHub says it will keep watch for broader adoption of the proposal.

The two approaches are complementary but distinct. Apple’s implementation uses the origin-bound message format with autofill logic that is limited to Apple’s browsers and devices. The Web OTP API is an open proposal that any platform owner could implement, standardizing how a client requests and receives the code.

SMS Security in Context

GitHub’s investment in SMS-based authentication might seem puzzling given the known weaknesses of the channel. SMS is not resilient against targeted attacks, and it is weaker than the other multi-factor options GitHub supports. Still, current data indicates SMS remains effective against the most common attacks. Its usability profile is also strong: no app to install and no dependency on a single device, which makes it a practical recovery path after hardware loss.

The decision to adopt the origin-bound standard is part of a larger effort to improve the security of an option that GitHub and others continue to offer. At the same time, GitHub is tracking WebAuthn and its platform authenticators — including Face ID, Touch ID, and Windows Hello — as a possible route to substantially stronger security without sacrificing convenience. The standard is still early in its adoption curve, but GitHub sees it as a promising direction.

For now, the origin-bound change is both meaningful and low-cost: a small modification to SMS messages that eliminates a straightforward avenue for phishing attacks on security codes.