GitHub adds proof-of-presence checks for high-impact actions
GitHub Enterprise Cloud now lets eligible Entra-backed enterprises require fresh re-authentication or MFA before sensitive administrative actions.
GitHub Enterprise Cloud now supports a fresh-authentication gate before sensitive account actions. In public preview, eligible enterprises can require interactive re-authentication or a multi-factor challenge through Microsoft Entra ID before members create tokens, edit webhooks, change organization security settings, or view recovery codes.
The control targets a gap that ordinary login and MFA do not fully close: a stolen session cookie or long-lived token can remain usable after the legitimate user has authenticated. GitHub’s new “proof of presence” check asks the identity provider to verify that an authorized person is acting at the moment of the high-impact operation.
Who can enable GitHub proof of presence
The preview is narrower than a general GitHub security setting. It applies to Enterprise Managed User (EMU) enterprises on github.com and GitHub Enterprise Cloud with Data Residency (GHEC-DR) when Microsoft Entra ID is used as the SSO identity provider through SAML or OIDC.
GitHub says administrators can use the Entra policy already configured for the organization. That policy may require another sign-in, MFA, device compliance, or a combination of controls. Enterprises outside this identity and deployment scope should not assume the preview is available to them.
Which actions receive a step-up check
The initial high-impact action set includes creating a token, editing webhooks, changing organization security settings, and viewing recovery codes. GitHub redirects the member to the configured identity provider; the action proceeds only when the required policy returns proof that its conditions were met.

After a successful challenge, the browser session can continue making high-impact changes for two hours without another proof-of-presence check. GitHub says support for requiring the check before pull-request merges is coming later, so the preview does not yet cover every operation that can affect code or release flow.
What security teams should verify
This is a control for session and token abuse, not a replacement for least privilege, short-lived credentials, signed commits, or incident response. GitHub points to recent supply-chain attacks involving stolen cookies and long-lived authentication tokens; independent coverage from ReleaseBytes confirms the preview’s scope and the affected administrative actions.
Administrators considering the feature should first map which enterprise actions are delegated to automation, then test the Entra policy against service accounts and emergency access procedures. A fresh human challenge can block a hijacked browser session, but it can also interrupt legitimate automation if the organization has not separated machine identities from interactive administration.
Availability and next milestone
GitHub labels proof of presence as a public preview, limited to the EMU/Entra configuration described above. Teams should confirm the setting, policy behavior, and two-hour session window in their own tenant before making it part of a compliance or incident-response control set. GitHub’s next stated expansion is proof of presence for pull-request merges.
Sources and methodology
GitHub’s Changelog is the primary source for the preview scope, action list, IdP behavior, and session duration. ReleaseBytes independently reports the same feature and deployment limits. The article treats the rollout as a preview and does not claim availability for GitHub organizations outside the documented Enterprise Managed User and Microsoft Entra scope.
Try the related loot
Give Any Model a Sandboxed Shell and File Workspace with OpenRouter
