GitHub can now demand a fresh IdP check before tokens and webhooks change
Victoria Shinder2 min readGitHub has added "proof of presence", a public preview that lets enterprises require a fresh interactive check before members take high-impact actions. According to the 24 September changelog, it extends GitHub's existing sudo mode: when a member tries to create a token, edit webhooks, change organisation security settings or view recovery codes, GitHub redirects them to their identity provider to satisfy a policy, and only lets the action proceed if they return with proof they did.
Administrators choose between two requirements: re-authentication, which depending on the IdP policy may be satisfied by a password, or MFA, which requires an additional multi-factor challenge such as an authenticator app or biometric. Because the check runs at the identity provider, enterprises can apply their own policies, including device compliance. After a successful challenge, the member can keep performing high-impact actions in that browser session for two hours, the same model as sudo mode. Support for requiring proof of presence before pull request merges is listed as coming soon.
The scope of the preview is narrow. It applies only to Enterprise Managed Users enterprises on github.com and to GitHub Enterprise Cloud with data residency, and only where Microsoft Entra ID is the SSO identity provider, via SAML or OIDC.
GitHub's stated reason is recent supply-chain attacks, in which stolen session cookies and long-lived tokens appeared repeatedly. Proof of presence, the changelog says, confirms that an authorised person is acting at the moment of the action, not just that a valid session or token was used, and it also helps regulated customers meet requirements for fresh authentication before sensitive operations.
What it means
A session cookie proves that someone authenticated at some point; it says nothing about who is holding it now. For most actions that is an acceptable risk. For creating tokens or changing webhooks - exactly the steps an attacker takes to persist after stealing a session - it is not, and a fresh check at the identity provider breaks the chain from stolen cookie to lasting access.
The two-hour window and the narrow preview scope are the limitations to note. An attacker with a session less than two hours old after a successful challenge still gets through, and enterprises on other identity providers or not using managed users cannot enable it yet.