10 min read - GitHub proof of presence: put a fresh check before sensitive actions

On 24 September 2026, GitHub released a public preview of “proof of presence” for high-impact actions in GitHub Enterprise Cloud. An enterprise can require a member to return to Microsoft Entra ID and authenticate again before GitHub accepts changes such as creating a token, editing a webhook, changing organisation security settings or viewing recovery codes.

The timing of the check is the useful part. A person may already have a valid GitHub session, yet the next action can change who has access or what trusted systems execute. GitHub’s announcement places a fresh identity-provider decision between that session and the sensitive action.

For security and engineering leaders, the preview is a reason to inspect more than one GitHub setting. Which actions deserve a fresh check? What assurance does the identity provider demand? How long does the stronger session last? Which API, automation and recovery paths sit outside the interactive browser flow? A control that cannot answer those questions may add prompts without reducing the risks the team meant to address.

A valid session is not fresh proof

Normal sessions spare people from signing in before every click. That trade makes daily work possible, but it also means a session cookie can keep conferring access after the original authentication event. Proof of presence asks the identity provider for a new decision when the requested action crosses GitHub’s protected boundary.

GitHub describes two policy choices. Re-authentication sends the member back to the IdP, where a password may be enough if the enterprise policy allows it. The MFA option also requires an additional factor configured in Entra ID. In both cases, GitHub proceeds only after the member returns with evidence that the required policy was satisfied.

This distinction prevents a common procurement mistake: “reauthentication” does not name the strength of the check. The IdP policy does. A password entered again, a compliant managed device and a phishing-resistant authenticator are different controls, even if the application labels all three as proof of presence.

NIST’s current Digital Identity Guidelines make the same separation. Reauthentication confirms continued presence during a session, while the relying party remains responsible for deciding whether an IdP assertion meets its requirement. For a federated service, freshness and authentication strength need explicit policy rather than an assumption that “SSO handled it.”

What GitHub protects, and where the boundary ends

GitHub extends its existing sudo-mode boundary. The sudo-mode documentation lists protected work across accounts, developer settings, webhooks, organisation membership, security settings, enterprise configuration, rulesets and recovery codes. These are sensible interruption points because many can create durable access or alter a control that governs later work.

The preview does not turn every GitHub operation into a transaction signed by a person. GitHub says support before pull-request merges is coming later. Its documentation describes an interactive redirect through the IdP and a browser sudo-mode session, so teams should not assume the same check covers tokens, applications, command-line flows or automated jobs. Test each path that matters.

That third row matters. Authentication confirms who completed a challenge; it does not necessarily prove that the person understood the exact webhook destination, token scope or ruleset change. OWASP’s transaction authorisation guidance recommends showing the significant transaction data, binding authorisation to the operation and enforcing the decision on the server. Proof of presence is a strong building block, but it is not the whole approval design.

Check eligibility before planning a rollout

The release announcement and the live documentation do not describe preview eligibility in identical terms. The 24 September announcement says the preview is scoped to Enterprise Managed User enterprises on GitHub.com and GHEC-DR using Microsoft Entra ID through SAML or OIDC. The configuration page currently says GitHub Enterprise Cloud, supports Entra ID during the preview, and links prerequisites for both personal-account and Enterprise Managed User configurations.

Do not resolve that difference by copying the broader wording into a project plan. Check whether the setting appears in the target enterprise and confirm the supported account and deployment model with GitHub before promising a date. Public previews can change; the configuration page says so directly.

Teams without the required GitHub plan or identity setup still have work they can do. They can inventory high-impact actions, restrict who may perform them, strengthen normal account authentication, reduce token scope, review installed applications and alert on security-setting changes. The preview adds a new interruption point. It does not replace those controls.

The identity-provider policy is part of the application control

GitHub delegates the challenge to Entra ID, which lets the enterprise use conditions it already manages. Microsoft’s authentication-context guide explains that applications can request stronger policy only for sensitive data or actions. Policies may require MFA, a compliant device or another defined condition, depending on the tenant configuration.

Treat that policy as code with an owner, review history and test evidence. A vague name such as “strong authentication” is not enough. Record the included users, excluded or emergency accounts, authentication methods, device conditions, session behaviour and failure path. Then ask a test user to perform representative actions from a managed device, an unmanaged device and a recovery scenario.

Microsoft’s documentation for testing protected actions shows why this needs deliberate testing. A user may not see a new prompt if the policy was already satisfied in the same session; a mis-scoped user assignment can stop the policy from triggering; an inactive or report-only policy will not enforce the requirement. Seeing the feature enabled in GitHub is therefore not evidence that the intended Entra policy ran for every targeted member.

Start in a test enterprise or a tightly scoped group where possible. Keep a tested emergency-access route, but do not exempt ordinary administrators merely to avoid setup friction. An exception that covers the people with the most authority can erase the benefit of the control.

Examine the two-hour window

After a successful challenge, GitHub says the member can keep performing protected actions in that browser session for two hours without another proof-of-presence check. The sudo-mode documentation adds that each sensitive action resets the two-hour timer.

That window makes the feature usable, yet it creates a specific residual risk. If an attacker gains control of the browser or session after the challenge, another prompt may not appear while sudo mode remains active. The control narrows the opportunity around the first protected action; it does not make the subsequent session harmless.

Measure the window against your own administrative work. Record when sudo mode starts, what resets it, which alerts fire for protected changes and how quickly an administrator can revoke access. Device security, short-lived privileges, change notifications and session revocation still matter. So does the recovery process, because proof-of-presence configuration and recovery-code access can affect the same operators during an incident.

Use the pattern beyond GitHub

The design pattern applies to internal products even when the GitHub preview does not. Most applications have a small set of actions whose impact far exceeds ordinary reading or editing: adding an administrator, changing a payout destination, exporting personal data, rotating credentials, disabling audit logs or connecting a new integration.

Do not force the strongest prompt on every page. Mark those high-impact state transitions, request a recent and suitable authentication event, display the change being authorised, enforce the result on the server and expire the authorisation quickly. The application should log the action, the policy requested, the authentication time and the outcome without storing authentication secrets.

The same review should cover non-human access. Our guide to IAM for non-human workers addresses ownership, delegated authority and permission expiry for agents. The GitHub Actions cache boundary review shows how seemingly separate workflows can influence later trusted work. A human prompt cannot compensate for an overpowered application or workflow that can reach the same state change without one.

A practical decision record

Before enabling the preview, write a short record with the current exposure and the expected change. It should contain:

• the GitHub account and deployment model, with eligibility confirmed;
• protected actions the organisation actually uses and material gaps;
• the Entra authentication context, methods, device rules and exceptions;
• test cases for administrators, recovery accounts and failed challenges;
• the two-hour sudo window, alerting, revocation and incident ownership;
• automation and API paths that require other safeguards.

Approve the rollout only when the team can produce evidence for those items. A screenshot of the enabled setting proves configuration, not protection.

For organisations operating across offices or delivery partners, use one shared control record and name the owner of the GitHub policy, the Entra policy and incident response. Exceev’s services approach connects strategy, engineering and enablement; this kind of identity change needs all three because the technical switch, operating procedure and administrator training must agree.

GitHub’s preview points to a sound security decision: treat a high-impact action as a new moment of risk, even inside a valid session. The benefit comes from the boundary around that moment. Define the actions, choose the actual assurance, test the identity path and document what remains outside it.

Sources and limitations

We opened and reviewed every source below on 25 September 2026.

• GitHub’s 24 September release announcement establishes the preview date, announced scope, example actions, two policy choices, two-hour browser window and planned merge support.
• GitHub’s proof-of-presence configuration page describes the live configuration, Entra ID support, enterprise-wide application and public-preview status. Its eligibility wording is broader than the announcement, so teams should confirm availability rather than infer it.
• GitHub’s sudo-mode documentation lists protected action categories and explains the session timeout behaviour.
• Microsoft’s authentication-context guidance and protected-action test guide provide independent implementation context for selective policy requests and testing.
• NIST SP 800-63B-4 and the OWASP transaction authorisation guidance provide independent guidance on session freshness, federated reauthentication and operation-bound authorisation.

We did not access a GitHub Enterprise tenant with the preview, test an Entra policy, inspect GitHub’s private implementation or verify every API and automation path. The article does not claim that proof of presence prevents all session theft, malware, insider misuse or social engineering. Eligibility and behaviour may change during the preview. No Exceev client deployment, compliance result or security guarantee is claimed.