GitHub proof of presence: fresh identity checks for sensitive actions

A signed-in session answers one question: has this browser authenticated? A sensitive administrative action raises another: should the person at the keyboard prove their identity again? A new GitHub preview brings that distinction into enterprise security.

What changed on 24 September

GitHub announced proof of presence on 24 September 2026. The launch targets Enterprise Managed Users on github.com and GitHub Enterprise Cloud with data residency, using Microsoft Entra ID through SAML or OIDC. It is a public preview, not a universal rollout. This article was published on 25 September; that is not the feature's announcement date.

How the check works

The configuration documentation describes a redirect to the enterprise identity provider before a protected action proceeds. Administrators choose re-authentication or an additional MFA challenge. A password can satisfy the former, depending on policy; the two settings do not provide identical assurance.

The sudo-mode reference lists protected operations such as token creation, webhook changes and security settings. Its two-hour timeout is renewed by sensitive activity. This is therefore session-based verification, not a fresh approval for every operation.

What it does not promise

The launch announcement says protection before pull-request merges is still coming. Do not describe it as available today. The preview can change, and the configuration guide describes enterprise prerequisites more broadly than the launch announcement. Confirm your deployment's actual eligibility before planning a rollout.

GitHub positions the feature as reducing compromised-session risk. That is a vendor security claim, not a measured result from this article. No control should be presented as eliminating account compromise or automatically satisfying a compliance obligation.

Engineering analysis: separate preparation from execution

For a product team, the useful design lesson is a boundary between preparing a change and committing it. An assistant might assemble an integration configuration, explain its effect and show a diff. Applying that change should remain a separately controlled operation.

This is architectural analysis, not a claim that GitHub implements a general approval engine. In your own product, consider binding an approval to a specific action, tenant and set of parameters. If those parameters change after review, require a new review rather than silently executing the modified request.

Fresh identity and authorization also answer different questions. A successful identity check should not grant a user permissions they lacked before the check. For multi-tenant systems, keep that boundary alongside tenant isolation, rather than treating authentication as a substitute.

A practical rollout checklist

Start with a low-risk test environment. Confirm account eligibility and the identity-provider policy, then exercise success, cancellation, expiry and interrupted navigation. Check whether the user returns to the intended operation without losing context or accidentally submitting it twice.

For your own approval-gated workflows, record the proposed action, the decision and the eventual outcome using a correlation identifier. Do not store authentication secrets in those logs. An observability plan helps distinguish an abandoned challenge from an application failure.

The decision is not simply whether to add another prompt. It is where renewed trust is necessary, what that trust authorizes, and how the product recovers when the person cannot complete the check.

Prepared by: Noor Yasser