A valid GitHub session does not settle every question about a sensitive change. There is a gap between knowing that a session is valid and confirming that its owner is present for the action.

Proof of Presence, announced on September 24, 2026, brings the enterprise identity provider into that confirmation. Its name can be misleading, though, if you interpret it as mandatory MFA before every sensitive operation.

For GitHub Enterprise Cloud administrators, the useful questions are where the challenge occurs and what allows work to continue. The connection to sudo mode helps explain both the protection and the deployment decisions.

Sudo mode gains an enterprise IdP challenge

GitHub already uses sudo mode to request authentication before sensitive actions, even from signed-in users. Adding an SSH key or creating a personal access token (PAT), for example, can establish a new route into an account. The sudo mode documentation describes this separate confirmation step.

Proof of Presence adds the enterprise identity provider (IdP) to that step. When a protected action requires re-authentication, GitHub redirects the member to the IdP; the action can proceed after the required policy is satisfied. The configuration documentation explains that it inherits the protected actions and session model of sudo mode.

Operationally, this adds another design question alongside who receives a permission: what authentication conditions should they satisfy before using it?

The preview targets EMU enterprises using Entra ID

The September 24, 2026 public preview is limited to Enterprise Managed Users (EMU) enterprises on github.com and GitHub Enterprise Cloud with data residency (GHEC-DR), using Microsoft Entra ID for SSO through SAML or OIDC.

EMU lets an external IdP manage GitHub user lifecycles and authentication. It is distinct from an enterprise whose members use personal accounts. The official EMU explanation provides the background for checking your account model and SSO provider before evaluating this feature.

Although the configuration page also links to SSO instructions for personal-account enterprises, the release announcement limits this preview to EMU. Support for requiring Proof of Presence before pull request merges was still planned at announcement time. If merge-time verification is your goal, distinguish that planned capability from what was released.

Re-authentication and MFA provide different assurance

Eligible enterprises select a requirement under Settings → Authentication security → Proof of presence. Enabling the policy applies it across the enterprise. The official configuration procedure offers two choices.

Option	Authentication required
Re-authentication	Authenticate again at the IdP; a password may suffice under the policy
MFA	Re-authenticate and satisfy the configured additional multi-factor challenge

Enabling Proof of Presence therefore does not automatically mean an additional factor is required. Decide whether another sign-in is sufficient or an additional factor is necessary, aligning the GitHub choice with the Entra ID policy.

During a rollout test, look beyond whether a prompt appears: check that the protected action cannot proceed without the intended authentication. This is a suggested validation, not a report of testing in a live enterprise. It also helps to agree on the support route between enterprise and IdP administrators for members who cannot complete the challenge.

Include the two-hour session in your protection requirements

After a successful challenge, the same browser session permits further sensitive actions for two hours without another Proof of Presence check. It does not require fresh authentication for each operation.

The sudo mode timeout rules also reset the timer when a sensitive action occurs during that period. Because Proof of Presence shares that model, the timeout should not be treated as a fixed deadline two hours after the first challenge.

Consider another protected action 30 minutes after authentication. In the same valid session, it can proceed without another challenge and resets the timer. This is an illustration of the documented behavior. Reusing the confirmation reduces repeated prompts, but an operational requirement for fresh authentication evidence for every action needs a separate assessment.

The practical value of Proof of Presence is bringing enterprise authentication policy to sensitive operations instead of relying only on a valid login. Adoption should turn on two questions: whether the challenge provides the assurance you need, and whether reusing its result for the session fits your requirements.

Source

• Title: Require proof of presence for high-impact actions
• URL: https://github.blog/changelog/2026-09-24-require-proof-of-presence-for-high-impact-actions