GitHub proof of presence: re-auth before risky actions

GitHub proof of presence is a control built on an admission: a valid session and a valid token are not evidence that a person is there. GitHub's changelog says it directly — proof of presence "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". It entered public preview on 24 September 2026, and its scope is narrower than the headline suggests.

That sentence is the threat model. Every layer most enterprises already run — password, MFA at sign-in, SSO through the identity provider — proves who authenticated. None of them proves who is acting now. A stolen session cookie or an exfiltrated token carries all of that proof forward, which is exactly the failure mode this feature exists to answer.

What github proof of presence actually checks

When a member attempts a covered action, GitHub redirects them to the enterprise's identity provider and they complete an authentication step before the action proceeds. Enterprises choose the strength: re-authentication, where the member authenticates again and may do so with a password alone, or MFA, where they must also complete a multi-factor challenge.

Once verified, the check does not repeat on every click. The changelog describes a two-hour window in the same browser session during which further high-impact actions proceed without another prompt. That is deliberately the same shape as sudo mode, which GitHub documents with a two-hour session timeout before it asks again.

The difference is who sets it and what it verifies against. Sudo mode is an account-level behaviour satisfied with a credential GitHub holds. Proof of presence is an enterprise policy satisfied against your identity provider, where your conditional access rules, device compliance checks and phishing-resistant factors already live. It is less a new authentication step than a hook that lets an enterprise's existing IdP policy apply at the moment of a dangerous write.

Which actions require proof of presence

The changelog names four: creating tokens, editing webhooks, changing organization security settings, and viewing recovery codes. Support for proof of presence before pull request merges is described as coming soon.

The four are not an arbitrary set. Each is a persistence mechanism rather than a one-off act of damage:

Action	What an attacker gets from it	Why a session check misses it
Creating a token	Access that outlives the stolen session	The session was already valid
Editing a webhook	A copy of repository events sent elsewhere	Nothing about the request looks new
Changing org security settings	Removal of the controls that would catch the rest	The actor holds owner rights already
Viewing recovery codes	A path back in after the session is revoked	Reading is not a state change

The pending item is the interesting one. Requiring proof of presence before a pull request merge puts an interactive check in front of the step that moves code into production — which is where the merge queue, the deployment pipeline and every bot that merges on green also live. The changelog calls it coming soon and says nothing more, so treat the shape of it as unknown.

The public preview scope is narrow, and the narrowness is the news

Most enterprises reading the changelog cannot turn this on. The preview is limited to managed user (EMU) enterprises on github.com and GHEC-DR that use Microsoft Entra ID as their identity provider, via SAML or OIDC. GitHub's configuration documentation confirms that Entra ID is the only supported provider during the preview.

Read that as four separate conditions, all of which must hold:

• Enterprise Managed Users, not an enterprise of ordinary personal accounts with SSO bolted on.
• github.com or GitHub Enterprise Cloud with data residency — not GitHub Enterprise Server.
• Microsoft Entra ID as the IdP. Okta, Ping and Google Workspace are not in the preview.
• SSO already configured between the enterprise and that IdP, which GitHub lists as the prerequisite.

If you fail any one of them, the honest planning assumption is that this is a roadmap item, not a control you can schedule. That is worth saying to a board or an auditor before someone writes it into a remediation plan with a date next to it.

Does proof of presence break automation?

The mechanism is a browser redirect to an identity provider, completed by a human. A machine identity cannot satisfy it, because there is nothing to satisfy it with. That is the design, not a gap.

What we could not verify is the more useful question: how GitHub treats a covered action attempted by an app, an installation token or a script rather than by a member in a browser. The preview documentation we read covers the member experience and the prerequisites, and does not spell out the behaviour for non-interactive identities. Until GitHub documents it, do not assume either that your automation is exempt or that it will break — test it in a non-production enterprise and confirm with GitHub.

Two things are safe to plan for regardless. Any runbook step that says "generate a token" now needs a person with an IdP session, so break-glass procedures that assumed a single on-call engineer with a stored credential need rewriting. And the two-hour window means batching is rational: if an operator has ten webhook edits to make, doing them in one sitting costs one challenge rather than ten.

What to do if you are outside the preview

The control is unavailable to most enterprises today, but the reasoning behind it is available to everyone. In the DevOps and cloud engineering work we do, the same four actions are worth treating as high-impact regardless of whether GitHub can gate them for you yet.

1. Alert on them rather than gate them. Token creation, webhook edits, organization security changes and recovery code views all emit audit log events. An alert that fires within minutes is a weaker control than a prompt, but it is available now.
2. Shorten what a stolen credential is worth. Expiring tokens and scoping them tightly reduces the value of the thing proof of presence is designed to defend, which is the argument behind API key expiry and governance generally.
3. Reduce the number of identities that can perform them. A control that challenges the actor helps least when forty people are eligible to be challenged.
4. Remember that the attacker does not always need a stolen session at all. A workflow that can be steered into leaking a secret — the pattern behind prompt injection in GitHub Actions — never touches the UI, and proof of presence does not see it.

GitHub has spent 2026 tightening the primitives underneath all of this, from RSA key strength and the removal of SHA-1 onwards. Proof of presence is the same instinct applied one level up: stop trusting the artefact of a past authentication and ask the question again at the moment it matters. The preview conditions decide whether you can act on it this quarter. The threat model does not wait for them.