GitHub Enterprise Cloud now demands a fresh sign-in to create a token or change a webhook

A valid session cookie has been enough to mint a GitHub personal access token for years, and every phishing kit knows it. GitHub started a public preview on 24 September 2026 that closes that path for enterprise accounts, by requiring what it calls proof of presence before a high-impact action can go through.

Proof of presence, GitHub says on its changelog, confirms that a real, authorized person is acting at the moment the high-impact action happens, and that a valid session or token by itself is no longer enough. A user has to complete a fresh sign-in through the identity provider before the action runs, and a re-authentication is honoured for two hours before it must happen again.

What triggers a challenge

GitHub lists four actions in the preview: creating tokens, editing webhooks, changing organization security settings, and viewing recovery codes. Merging a pull request will join the list in a later release, per the same page.

The two ways an enterprise can prove a person is at the keyboard are the identity provider's password sign-in and its multi-factor step, which can be an authenticator app or a biometric check depending on how the provider is configured.

Who can turn it on

The preview is limited to managed user, or EMU, enterprises on github.com and to GitHub Enterprise Cloud with Data Residency, and only when Microsoft Entra ID is the single sign-on provider through SAML or OIDC. An admin turns it on from enterprise settings, and users then see the challenge the next time they attempt one of the four actions.

Personal accounts, Team and standard Enterprise Cloud accounts are not included yet. GitHub's own sudo mode, the ordinary password or passkey prompt used on high-risk pages, is a separate feature and stays as it was for accounts outside the preview.

The move brings token creation under the same real-time check that most enterprises already have on sensitive payroll or admin steps, and it does so through the identity provider rather than through a GitHub-specific factor. A team that already runs Entra ID conditional access for sign-in gets a single control that now also covers the moment a developer mints a token.

The two hour window between challenges is where the real trade-off lives. A short window annoys engineers who create scoped tokens ten times a day for CI experiments; a long window widens the gap during which a stolen laptop can still print credentials. Two hours matches what most identity providers use for their own step-up prompts, which will feel familiar to anyone who already re-authenticates for admin consoles.

For a security team, the value of the preview is that it converts token creation and webhook editing from routine self-service into an event the identity provider records. Every high-impact action now carries a matching sign-in log line, so an audit trail exists even when a session was hijacked, and a compromised session cookie by itself no longer opens a route to data exfiltration through a new webhook or a fresh token.

Source

• Announcement: GitHub changelog, 24 September 2026