What GitHub shipped on September 24
GitHub announced proof of presence on September 24, 2026 as a public preview for GitHub Enterprise Cloud. When it is enabled, a member who attempts a high-impact action is redirected to the enterprise's identity provider (IdP). GitHub lets the action proceed when the member returns with proof that the required IdP policy was satisfied. GitHub describes it as an expansion of sudo mode for enterprises.
The stated motivation is session and token theft: GitHub points to stolen session cookies and long-lived authentication tokens in recent supply chain attacks. A valid session tells you that someone authenticated at some point. Proof of presence is meant to show that an authorized person is present at the moment a sensitive change happens.
Step one: does the preview apply to you?
Answer this before you design any policy. The changelog limits the preview to enterprises that meet all three conditions:
| Condition | What the announcement requires | If you do not meet it |
|---|---|---|
| Enterprise type | Enterprise Managed Users (EMU) | Outside the announced preview scope |
| Deployment | github.com or GHEC-DR (data residency) | Outside the announced preview scope |
| Identity provider | Microsoft Entra ID as SSO IdP, via SAML or OIDC | Okta, PingFederate or another IdP is not covered yet |
GitHub's EMU overview lists Entra ID as the partner IdP with SAML, OIDC and SCIM support, while Okta and PingFederate are listed for SAML and SCIM. An EMU enterprise on one of those two partners therefore sits outside this preview even though its setup is otherwise supported. The configuration guide says that during the preview proof of presence supports Entra ID, and its prerequisites also link SAML setup for enterprises with personal accounts. Treat the narrower changelog scope as the planning baseline and confirm in your own enterprise settings whether the option appears.
Which actions trigger the check
The announcement gives four examples: creating a token, editing webhooks, changing organization security settings and viewing recovery codes. Those are examples, not a complete list. The configuration guide states that the same protected actions that trigger sudo mode trigger a proof of presence challenge, and the sudo-mode page lists its categories as "including but not limited to":
- Account changes, such as adding an SSH key or authorizing third-party applications
- Developer settings, such as creating personal access tokens or generating client secrets
- Webhooks at repository, organization and enterprise level, including viewing or redelivering deliveries
- Organization membership and organization security settings
- Enterprise settings and rulesets
- Viewing, downloading or regenerating recovery codes
There is a detail that matters for EMU in particular. The sudo-mode page notes that in an EMU enterprise the setup user is the one account that receives sudo prompts, because managed user accounts have no credentials stored on GitHub. Our reading is that proof of presence introduces an interruption your managed users have not seen on GitHub before. Plan communication accordingly.
Re-authentication or MFA
An enterprise picks one of two requirements. Both send the member to the IdP; they differ in what the IdP must confirm.
| Requirement | Documented behavior | Trade-off to weigh |
|---|---|---|
| Re-authentication | The member authenticates again with the IdP. Depending on IdP policy, a password may satisfy this. | Least friction, but proves freshness rather than a second factor unless your IdP policy demands more |
| MFA | The member authenticates again and completes an additional multi-factor challenge, such as an authenticator app or biometric, as configured in the IdP | Stronger evidence of presence; every member who performs protected actions needs a working second factor |
The practical strength of either option lives in Entra ID, not in GitHub. GitHub's announcement says the IdP policy might require MFA, check device compliance, or ask for a fresh sign-in. If you choose re-authentication, look at what your Entra ID policy currently accepts for a GitHub sign-in: if a password alone passes, a phished password may pass too. The docs make the same point by telling administrators to confirm that IdP authentication policies give the assurance they require before enabling the feature.
The two-hour window
After a successful challenge, the changelog says the member can continue performing high-impact actions in that browser session for two hours without another check. The sudo-mode page adds that sensitive actions reset its two-hour timer, and the configuration guide says proof of presence uses the same timeout model. Read together, a session with a steady stream of protected actions may not be challenged again exactly two hours after the first prompt. That is our interpretation of the documentation, not observed behavior; verify it in your rollout before you describe the window to auditors.
The documented window is tied to the browser session, so plan for a new challenge when a member moves to another browser or device. The flip side: the documentation describes no second prompt inside the window, so someone who takes over an already-verified browser session during those hours is not stopped by this control. Proof of presence reduces the value of a stolen cookie or token; it does not replace session hygiene or credential inventory and incident response.
Fill in this decision template
The template below is our proposal for recording the decision, not a GitHub artifact. Complete one per enterprise.
| Decision field | What to record |
|---|---|
| Eligibility | EMU yes/no; github.com or GHEC-DR; Entra ID via SAML or OIDC; option visible in settings yes/no |
| Requirement | Re-authentication or MFA, with the Entra ID policy that will satisfy it |
| Affected roles | Organization owners, developers who create tokens, integration maintainers who edit webhooks, anyone who handles recovery codes |
| Affected workflows | Token rotation days, webhook changes during incidents, security-setting reviews, onboarding that includes token creation |
| Support path | Who members contact when a challenge fails; the docs direct them to the enterprise or IdP administrator |
| Rollout | Announcement date to members; the docs say the policy applies across the enterprise once enabled, with no per-organization staging described |
| Merge checks | Owner and review date for the announced pull request merge support |
The documented location is enterprise Settings, then Authentication security, then the Proof of presence dropdown. Because the setting is enterprise-wide, test the member experience with a small group of administrators and developers before announcing it, and have an IdP administrator available the day you turn it on.
Pull request merges are announced, not shipped
GitHub's post ends with one sentence: support for proof of presence before pull request merges is coming soon. There is no date and no description of how it will work. Do not write it into a control narrative yet. Add a line to your decision record instead: who will evaluate it when it arrives, which repositories would be candidates, and how a merge-time prompt would interact with automation and review rules such as those in our GitHub Advanced Security enforcement guide. Proof of presence fits the same identity-first approach described in zero-trust architecture for AI agents: verify the actor when the action matters, not merely when the session began.