Dein Blog zum Thema digitales Business

Die Pflicht gilt dem Login des Kontos

Eine GitHub-Organisation kann verlangen, dass Mitglieder, Outside Collaborators und Billing Manager Zwei-Faktor-Authentifizierung für ihr persönliches Konto aktivieren. Das klingt nach einer Antwort auf gestohlene Zugangsdaten, ist aber die Antwort auf eine engere Frage: Wer sich an einem Konto anmeldet, braucht mehr als ein Passwort. Wer sich mit einem Token oder einem SSH-Key authentifiziert, meldet sich nicht auf diese Weise an.

Hier steht, was die Organisationsanforderung „Require two-factor authentication“ auslöst, was sie nicht tut und wo die Doku schweigt. Grundlage ist die GitHub-Seite Requiring two-factor authentication in your organization, ergänzt um die Seiten zu Bots und Service-Accounts, zu Wiederherstellungsmethoden und zur REST-Schnittstelle für Organisationsmitglieder. Stand der Doku: 26.09.2026. Schlussfolgerungen und Empfehlungen sind gekennzeichnet.

Die Anforderung gibt es laut Doku für Organisationen mit GitHub Free, GitHub Team, GitHub Enterprise Cloud und GitHub Enterprise Server, nicht für Organisationen in einem Enterprise mit Managed Users. Richtlinien auf Enterprise-Ebene und Single Sign-on sind nicht Thema dieses Beitrags.

Was der Schalter erzwingt: drei Rollen, zwei verschiedene Folgen

Die Doku unterscheidet die Rollen. Die verbreitete Annahme, jeder ohne 2FA fliege sofort raus, stimmt nur für eine davon.

• Mitglieder und Billing Manager ohne 2FA können laut Doku nicht auf die Ressourcen der Organisation zugreifen, bis sie 2FA aktivieren. Sie behalten aber ihre Mitgliedschaft, auch wenn sie damit weiter Seats der Organisation belegen.
• Outside Collaborators ohne 2FA werden aus der Organisation entfernt. Sie verlieren den Zugriff auf die Repositories und auf ihre Forks der privaten Repositories der Organisation. Aktivieren sie 2FA innerhalb von drei Monaten nach der Entfernung, kannst du ihre Rechte und Einstellungen wieder einsetzen.
• Deaktiviert ein Outside Collaborator 2FA später, wird er laut Doku automatisch entfernt.
• Bist du der einzige Owner einer Organisation mit Pflicht, kannst du 2FA an deinem eigenen Konto nicht abschalten, ohne die Pflicht der Organisation abzuschalten.

Schlussfolgerung, keine Aussage der Doku: Die Pflicht räumt Mitglieder nicht auf. Ein Konto, das nie 2FA einrichtet, bleibt als Mitglied im Bestand, ohne Zugriff, aber mit Seat. Prüfe diese Konten danach bewusst. Wie du den Bestand wiederkehrend prüfst, steht in Berechtigungs-Reviews in GitHub-Organisationen.

Was die Doku zu Tokens und Schlüsseln sagt

Die Pflicht betrifft das Anmelden am Konto. Die Doku beschreibt an zwei Stellen, was sich bei der Anmeldung per Token oder Schlüssel nicht ändert:

• Bot- und Service-Konten: Aktivierst du 2FA für ein solches Konto, müssen sich Menschen mit 2FA auf GitHub.com anmelden. Laut Doku ändert das nichts daran, dass sich das Konto in Automatisierungen weiter mit seinen bestehenden Tokens authentifizieren kann. Schlussfolgerung, keine Aussage der Doku: Ein Bot-Konto mit 2FA bleibt ein Token-Konto. Die Pflicht schützt die Anmeldung an GitHub.com, nicht den Token, mit dem die Automatisierung läuft.
• SSH: Die Doku hält fest, dass 2FA nicht ändert, wie du dich auf der Kommandozeile über SSH-URLs authentifizierst. Für HTTPS-URLs brauchst du einen Personal Access Token als Passwort. Für API und Kommandozeile gilt laut Doku, dass du dich mit Token, App oder SSH-Key authentifizierst.

Was die gelesenen Seiten nicht regeln: ob und wie bestehende Personal Access Tokens von Mitgliedern ohne 2FA weiterarbeiten, und wie sich Deploy Keys und App-Tokens verhalten. Sie kommen dort nicht vor, also behaupte dazu nichts. Empfehlung: Teste das Verhalten in einer Test-Organisation, bevor du dich darauf verlässt. Wie Bot-Konten selbst zu Dauer-Zugängen werden, steht in Service-Accounts und Bot-Tokens in GitHub.

Für die Anmeldung eines Menschen an einem Bot-Konto empfiehlt die Doku eine Mailingliste mit allen Verantwortlichen, das TOTP-Secret im zentralen Passwortmanager und ein Zurücksetzen des Passworts bei jeder Anmeldung. Das Passwort selbst gehört nicht in den Passwortmanager.

Welche Methode zählt: „secure methods“

Die einfache Pflicht verlangt nur, dass 2FA aktiv ist. Zusätzlich gibt es die Option „Only allow secure two-factor methods“. Als sicher führt die Doku Passkeys, Sicherheitsschlüssel, Authenticator-Apps und die GitHub-Mobile-App auf. Wer keine sichere Methode eingerichtet hat oder eine unsichere wie SMS, kann laut Vorbereitungsseite nicht auf Ressourcen der Organisation zugreifen. Für Outside Collaborators ist die Folge härter: Wer SMS-2FA eingerichtet hat, wird bei dieser Option entfernt.

Zu SMS sagt die Doku an anderer Stelle, dass sie sich abfangen lässt, keinen Schutz gegen Phishing bietet, unzuverlässig zugestellt wird und nicht in allen Ländern unterstützt wird. GitHub empfiehlt deshalb eine TOTP-App als Hauptmethode und Sicherheitsschlüssel als Backup-Methode statt SMS. Warum Passkeys, Sicherheitsschlüssel und Apps als „secure“ gelten, begründet die Seite nicht. Darum steht hier auch nicht, sie seien phishing-resistent.

Für Passkeys nennt die Doku eine Bedingung: Sie erfüllen Passwort und 2FA in einem Schritt, aber zur Vermeidung von Sperrungen solltest du eine Ausweichmethode wie eine TOTP-App oder SMS eingerichtet lassen. Schlussfolgerung: Unter der strengen Option taugt SMS nicht als Ausweichmethode, weil sie dort als unsicher gilt.

Wiederherstellungscodes: was passiert, wenn das Gerät weg ist

Bei der Einrichtung lädst du Wiederherstellungscodes herunter. Verlierst du dein Telefon, meldest du dich damit an. Nach der Doku sind es 16 Codes, jeder gilt einmal, ein neuer Satz macht den alten ungültig. Speichere sie im Passwortmanager und gib sie nicht weiter. Als weitere Wiederherstellungswege nennt die Doku SSH-Keys, Personal Access Tokens und verifizierte Geräte, die du vorher einrichtest.

Der wichtigste Satz steht in einer Warnung: Der GitHub Support kann den Zugriff auf ein Konto mit 2FA nicht wiederherstellen, wenn du deine Zugangsdaten und Wiederherstellungsmethoden verlierst. Ohne Wiederherstellungsmethode ist der Zugriff nach der Doku dauerhaft verloren. Schlussfolgerung: Für einen einzigen Owner ist das ein Risiko der Organisation, nicht nur seines Kontos.

2FA erzwingen: die Reihenfolge vor dem Einschalten

1. Eigenes Konto zuerst. Laut Doku musst du als Owner selbst 2FA aktiviert haben.
2. Ankündigen. Die Doku empfiehlt, Mitglieder, Outside Collaborators und Billing Manager mindestens eine Woche vorher zu informieren, damit sie 2FA einrichten. Eine Karenzzeit zwischen Einschalten und Wirkung nennt die Seite nicht. Der Vorlauf ist die Ankündigung, die du selbst machst. Bei der strengen Option empfiehlt die Doku zusätzlich, unsichere Methoden vorher zu entfernen.
3. Stand prüfen. Auf der Seite People siehst du, wer 2FA nutzt, mit den Filtern Secure, Insecure und Disabled. Per REST liefert GET /orgs/{org}/members?filter=2fa_disabled nur Mitglieder ohne 2FA, 2fa_insecure nur Mitglieder mit unsicheren Methoden. Beide Filter sind laut REST-Doku nur für Owner verfügbar. Für Outside Collaborators nennt die Doku die People-Seite.
4. Bot-Konten als Outside Collaborators nicht vergessen. Ohne 2FA werden sie entfernt und verlieren den Zugriff auf ihre Repositories.
5. Bestätigen. Falls GitHub beim Speichern anzeigt, wen die Änderung betrifft, lies es und bestätige.

Danach: Entfernte Personen findest du im Audit-Log mit action:org.remove_outside_collaborator, der Eintrag zeigt, ob wegen fehlender 2FA entfernt wurde. Die Betroffenen erhalten laut Doku eine E-Mail. Sie aktivieren 2FA und melden sich bei einem Owner. Die Doku empfiehlt, ihnen eine Einladung zu schicken, die ihre früheren Rechte wiederherstellt; sie können sie erst annehmen, wenn 2FA aktiv ist.

Wo das Thema an Nachbarthemen grenzt

Hier geht es um den Login-Schutz der Konten. Den Zugriff über Tokens beschreiben Fine-grained Personal Access Tokens und OAuth-Scopes installierter GitHub-Apps. Wie Outside Collaborators ohne Organisationsmitgliedschaft direkten Zugang auf Repository-Ebene erhalten und die 2FA vor Annahme der Einladung aktivieren müssen, beschreibt Onboarding-Berechtigungen in GitHub. Wie der Zugang am Ende einer Zusammenarbeit entzogen wird, behandelt Offboarding in GitHub.

Wo Unterstützung ansetzt

Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es läuft über drei Felder: Implementation (Delivery- und Nachweiskontrollen in die Pipeline einziehen), AI Governance (Nachvollziehbarkeit dort schaffen, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen) und Maintenance (die Übergabefrage: wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem gehört). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst. Kontakt: mm@mhm-dl.de.

Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.