GitHub shipped proof of presence in public preview on September 24, 2026. GitHub's changelog entry describes what the feature does: it "confirms that a real, authorized person is acting at the moment the high-impact action happens, not just that a valid session or token was used." GitHub is checking presence at the second a sensitive action fires, a separate question from whether that person logged in earlier in the day.
What GitHub's proof of presence actually checks
A GitHub session on its own tells the platform you authenticated at some point in the past two hours. Proof of presence, PoP for short, adds a second check on top of that session: an interactive challenge that routes back to the organization's identity provider before the action goes through. For enterprises in scope, the org's Entra ID tenant confirms presence rather than GitHub's login form alone. That's the actual difference between being logged in and being present at the moment it counts.
Which actions require it right now
GitHub's changelog names four actions as examples of what triggers a challenge today: creating a token, editing webhooks, changing organization security settings, and viewing recovery codes. GitHub's configuring-PoP docs describe the real trigger set as the same protected actions that already trigger sudo mode, so the four named actions are examples rather than the entire list. Pull request merges aren't covered yet. GitHub's own language on that point is direct: "Support for proof of presence before pull request merges is coming soon." Anyone assuming PoP already gates a merge is wrong today.
Exactly who this applies to today
The scope is narrow and GitHub states it plainly: "This public preview is only scoped to managed user (EMU) enterprises on github.com and GHEC-DR that use Microsoft Entra ID as their SSO identity provider (IdP), via SAML or OIDC." A non-EMU org, an EMU org running a different identity provider such as Okta or PingOne, or a GHEC org without data residency enabled gets nothing new from this release. Those organizations keep GitHub's standard re-authentication instead of an IdP-level check.
Re-authentication or MFA: the two options an admin can set
GitHub gives an eligible admin two challenge types to choose from: "Re-authentication: The member authenticates again with your IdP. Depending on your IdP policy, a password may satisfy this. MFA: The member authenticates again and satisfies an additional multi-factor challenge (e.g., authenticator app, biometric) as configured in your IdP." The tradeoff is real. MFA is the stronger of the two, but it adds friction to actions engineers do constantly, like rotating a token or editing a webhook. Re-authentication is lighter and may ask for nothing more than a password.
How the two-hour window works
A successful challenge doesn't reset with every action. "After a successful challenge, the user can continue performing high-impact actions in that browser session for two hours without performing another proof of presence check." An admin who rotates a token and then edits two webhooks back to back hits their identity provider once, not three times.
That model isn't new. Per GitHub's sudo mode documentation, "GitHub has a two-hour session timeout period before prompting you for authentication again," reset every time a sensitive action fires. That baseline already covers a wider, older list for every GitHub.com user, including account deletion, SSH key management, third-party app authorization, personal access token generation, webhook management, organization membership changes, two-factor authentication settings, and recovery code access; the sudo mode documentation holds the complete list. GitHub's own configuring-PoP docs confirm that PoP shares that exact session and timeout model. PoP layers an IdP-level check on top of that same window, only for the EMU-plus-Entra population.
What this means for tokens, webhooks and automation
GitHub describes PoP as an interactive, browser-based flow: a click, an IdP redirect, then continued access in that browser session. Neither the changelog nor the configuring-PoP docs say whether a personal access token, OAuth app, or GitHub Actions token performing the same action through the API, editing a webhook programmatically, for instance, triggers the same challenge. That's genuinely unanswered. Teams running CI jobs that create tokens or touch webhooks on an EMU org should test the behavior against a real workflow rather than assume an answer.
That question sits apart from what GitHub's deny, ask, allow permissions for Copilot agents already settle. That framework governs what an already-authenticated agent can do, while PoP governs whether a human is present before a sensitive action runs. Both live on the same admin console, but rolling out one says nothing about the other.
How to turn on proof of presence for your enterprise
1. Confirm eligibility
Check three things before touching a setting: the enterprise runs as EMU, it sits on github.com or GHEC-DR, and Microsoft Entra ID is the SSO identity provider via SAML or OIDC. Outside that exact combination, there's nothing to turn on yet.
2. Open enterprise Settings, then Authentication security
From the enterprise account, go to Settings, then Authentication security. GitHub's docs on configuring proof of presence put the control there, next to a "Proof of presence" dropdown.
3. Choose re-authentication or MFA from the Proof of presence dropdown
Pick the challenge type per the tradeoff above. GitHub's own guidance is worth reading before flipping the switch: "Before enabling PoP, make sure your IdP authentication policies provide the level of assurance that you require." It's also still labeled a preview: "This feature is in public preview and subject to change."
4. Communicate the change before rollout
Warn engineers before turning this on, especially if MFA is the chosen option. Token creation and webhook edits are routine tasks, and a workflow that used to finish in one click now stops for an IdP challenge mid-task. Other admin-console changes are landing the same month. GitHub shipped three separate changelog entries on code review defaults on September 11, 18 and 23, a September 9 entry rolled out the new agent permissions model on its own, and GitHub's new billing rules take effect October 1 under an August 28 changelog post. Bundle the PoP rollout notice with whatever else is already on that calendar instead of sending a separate email for each one.
FAQ
Does proof of presence apply if my org isn't using GitHub Entra ID SSO?
No, not today. The public preview only covers EMU enterprises on github.com or GHEC-DR running Microsoft Entra ID as their SSO provider through SAML or OIDC. Any other IdP, or a non-EMU org, gets nothing new here.
Does proof of presence replace sudo mode?
No. PoP layers on top of GitHub's existing sudo mode session model instead of replacing it. Every GitHub.com user already gets a two-hour re-authentication window for actions like SSH key changes or token generation. PoP adds an identity-provider-level check on top of that window, but only for the EMU-plus-Entra population in scope today.
Will proof of presence block a pull request merge?
Not yet. GitHub's changelog says support for PoP before pull request merges is coming soon, but it isn't part of the preview. The changelog names creating a token, editing webhooks, changing organization security settings, and viewing recovery codes as examples of what triggers a challenge today; the actual scope matches whatever action already triggers sudo mode.
Does a personal access token or GitHub Action trigger a proof-of-presence challenge?
GitHub hasn't said. The changelog and configuring-PoP docs both describe an interactive, browser-based challenge, and neither addresses whether a PAT, OAuth app, or Actions token performing the same action through the API gets challenged the same way. Treat this as untested until you check it against a real workflow. </content>