GitHub Adds Proof of Presence Before High-Impact Enterprise Actions

GitHub Adds Proof of Presence Before High-Impact Enterprise Actions

GitHub Enterprise Cloud can now require a managed user to return to Microsoft Entra ID before completing a high-impact action, even when the user already has a valid GitHub session. The new Proof of Presence control entered public preview on September 24 and extends GitHub’s existing sudo-mode checkpoint to enterprise identity-provider policy.

The preview has a narrow boundary: it applies to Enterprise Managed User organizations on github.com and GitHub Enterprise Cloud with data residency, and it currently supports Microsoft Entra ID through SAML or OIDC. It is not a new MFA system inside GitHub. The enterprise’s IdP decides whether reauthentication, MFA, device compliance, or another conditional-access rule satisfies the challenge.

The check happens at the action boundary

GitHub sends the member to the IdP when a protected operation begins. Examples named in the release and sudo-mode documentation include creating a personal access token, changing webhooks, modifying organization security settings, and viewing or regenerating recovery codes. GitHub permits the action only after the IdP returns evidence that the required policy was satisfied.

GitHub Enterprise Cloud documentation for configuring Proof of Presence
Image: GitHub.

This placement matters because a stolen session cookie can still represent a previously authenticated browser. Proof of Presence asks for a fresh, interactive decision at the point where credentials, access paths, or recovery material could be changed.

The session window remains two hours

After a successful challenge, GitHub uses the same session model as sudo mode. The member can continue protected work in that browser for two hours without another Proof of Presence check, and each protected action resets the timeout. Administrators should therefore treat the feature as step-up authentication with a bounded working window, not as a challenge on every click.

GitHub documentation listing protected actions covered by sudo mode
Image: GitHub.

What to verify before enabling the preview

  • Eligibility: confirm the enterprise uses managed users and a supported Entra ID SAML or OIDC configuration.
  • Assurance: decide whether simple reauthentication is enough or whether the IdP policy must require MFA or device compliance.
  • Recovery: document who can help a member who cannot satisfy the IdP challenge.
  • Automation: inventory administrative workflows that depend on browser sessions and distinguish them from API or token-based automation.

GitHub says Proof of Presence before pull-request merges is coming later, so the preview should not be represented as a merge-approval control today. It also complements rather than replaces controls such as restricted GitHub Actions cache access and Copilot execution sandboxing.

The useful rollout test is concrete: confirm a protected action redirects to the intended Entra policy, confirm the return path completes, and verify that break-glass support does not quietly weaken the same high-impact boundary.

Sources

About TVG Editorial Team

TVG Report editorial coverage for robotics, AI, maker hardware, automation, and STEM technology.

View all posts by TVG Editorial Team →

Leave a Reply

Your email address will not be published. Required fields are marked *