GitHub verpflichtet alle Entwickler, die bis zum 2. September 2026 Commits durchführen, zur Nutzung der Zwei-Faktor-Authentifizierung (2FA).

Ende eines 2022 begonnenen Übergangs - das echte Problem sind die noch an nicht-2FA-Token angebundenen Automatisierungs-Workflows.

Der Fakt

GitHub macht die Zwei-Faktor-Authentifizierung (2FA) für jeden Entwickler, der zur Plattform beiträgt (Commit, PR, Review), ab dem 2. September 2026 obligatorisch (Hacker News, 20/07/2026, oben auf der Startseite). Der Wechsel finalisiert das Programm, das 2022 nach dem Kompromittieren mehrerer beliebter Repositories durch Token-Diebstahl gestartet wurde. Das Datum fällt mit dem Inkrafttreten der obligatorischen Hardware-Passkeys bei OpenAI Trusted Access for Cyber zusammen.

Unsere Analyse

Ende eines langen, kontrollierten Ausstiegs, keine Unterbrechung. GitHub hatte bereits die 2FA für Maintainer von "High-Impact"-Repositories vorgeschrieben und diese dann schrittweise ausgeweitet. Das eigentliche Problem: CI/CD-Workflows und Skripte, die noch auf nicht-2FA-Personal-Access-Tokens basieren - sie werden beim Wechsel brechen. 45 Tage vor dem Wechsel explodiert die Support-Warteschlange: Hier konzentriert sich das operationelle Risiko, nicht in der 2FA selbst. Zu beachten: Hardware-Passkeys bleiben optional; GitHub behält TOTP und SMS als Einstiegsklasse bei, was Reibung auf der Phishing-Achse hinterlässt - die Lücke zum Standard der Frontier-Berechtigungen bleibt deutlich (Frontier-Access-Control).

Zu beobachten

• Verhalten der CI (GitHub Actions, Circle, selbstgehostet) und Token-Manager beim Wechsel.
• Auswirkungen auf Open-Source-Projekte mit gelegentlichen Contributoren - mögliche Reibung.
• Nächster Schritt: Passkeys als Standard oder obligatorisch?