News

GitHub testet frische Entra-Prüfung vor sensiblen Enterprise-Aktionen

Die Proof-of-Presence-Vorschau gilt laut GitHubs Ankündigung nur für Enterprise Managed Users mit Microsoft Entra ID. Nach einer erfolgreichen Prüfung vertraut GitHub derselben Browsersitzung zwei Stunden; Pull-Request-Merges bleiben zunächst außen vor.

GitHub, eine Plattform für Quellcode und Softwareentwicklung, hat am 24. September 2026 die Sicherheitsfunktion Proof of Presence als öffentliche Vorschau angekündigt. Enterprise-Administratoren können GitHub damit so konfigurieren, dass Microsoft Entra ID unmittelbar vor ausgewählten Hochrisiko-Aktionen eine neue Identitätsprüfung verlangt. Ein bereits angemeldeter Browser oder ein gültiger Sitzungscookie genügt für diese Aktionen dann nicht automatisch.

In der Ankündigung vom 24. September begrenzt GitHub die Vorschau auf Unternehmen mit Enterprise Managed Users, kurz EMU, auf github.com sowie GitHub Enterprise Cloud mit Data Residency. EMU sind zentral von einer Organisation verwaltete GitHub-Konten. Data Residency bezeichnet hier die Cloud-Variante mit festgelegter regionaler Datenspeicherung. Zusätzlich muss Microsoft Entra ID als zentraler Identitätsanbieter über SAML oder OIDC eingesetzt werden; beide Protokolle übertragen Anmeldeinformationen zwischen GitHub und dem Identitätsanbieter.

Die Kontrolle sitzt zwischen Sitzung und Aktion

Proof of Presence erweitert GitHubs Sudo-Modus, der sensible Aktionen nach einer frischen Identitätsprüfung vorübergehend freigibt. Versucht ein Mitglied eine erfasste Aktion, leitet GitHub den Browser zu Entra ID weiter. Dort kann die Organisation je nach Richtlinie eine erneute Anmeldung, eine Mehrfaktorprüfung oder eine Prüfung des Gerätezustands verlangen. Erst wenn Entra ID die Prüfung bestätigt, gibt GitHub die Aktion frei.

GitHub nennt als Beispiele das Erstellen eines Tokens, das Ändern von Webhooks oder Sicherheitseinstellungen und das Anzeigen von Wiederherstellungscodes. Ein Token ist ein maschinenlesbarer Zugangsnachweis; ein Webhook übermittelt Systemereignisse automatisch an eine hinterlegte Adresse.

Damit genügt ein gestohlener Sitzungscookie allein nicht mehr für die erfassten Aktionen. Bereits gestohlene oder außerhalb dieses Browserablaufs verwendete Zugangsdaten schützt die Funktion nicht automatisch. Ebenso verhindert sie nicht jede missbräuchliche Aktion auf einem bereits kompromittierten Konto oder Gerät.

Zwei Stunden Vertrauensfenster

Nach einer erfolgreichen Prüfung darf die Person in derselben Browsersitzung zwei Stunden lang weitere erfasste Hochrisiko-Aktionen ausführen, ohne den Nachweis erneut zu erbringen. Das ist kein Schutz pro Einzelaktion, sondern ein zeitlich begrenztes Vertrauensfenster. Teams sollten deshalb prüfen, ob dieses Fenster und die eigenen Entra-Richtlinien zu den festgelegten Angriffsszenarien passen.

Pull-Request-Merges bleiben außerhalb der Vorschau

Pull-Request-Merges sind noch nicht unterstützt. GitHub kündigt diese Abdeckung lediglich für später an. Wer besonders schützenswerte Entwicklungszweige absichern will, braucht daher weiterhin Regeln für geschützte Branches, verpflichtende Reviews, kryptografisch bestätigte Commits oder andere bestehende Kontrollen. Proof of Presence ersetzt diese Regeln nicht.

Was Enterprise-Administratoren jetzt prüfen sollten

  1. Klären, ob das Unternehmen tatsächlich EMU auf github.com oder GitHub Enterprise Cloud mit Data Residency und Microsoft Entra ID verwendet.
  2. Erfassen, welche der aktuell unterstützten Hochrisiko-Aktionen im eigenen Sicherheitskonzept besonders relevant sind.
  3. In Entra festlegen, ob erneute Anmeldung, Mehrfaktorprüfung oder zusätzliche Gerätevorgaben verlangt werden sollen.
  4. Die Vorschau zunächst mit einem kleinen Administratorkreis testen und Notfallzugänge sowie Wiederherstellungswege dokumentieren.
  5. Pull-Request-Merges ausdrücklich als noch nicht abgedeckt im Sicherheitskonzept und im Ablaufhandbuch vermerken.

Die Funktion ist keine allgemeine zweite Anmeldung für GitHub. Sie ist eine zusätzliche Schranke vor bestimmten Aktionen, in einem eng begrenzten Enterprise-Cloud-Setup und mit einem zweistündigen Vertrauensfenster. Diese drei Grenzen gehören in die Entscheidung über eine Einführung.

Quellen

Quellenstand: 25. September 2026.