GitHub Enterprise Cloud: Entra ID Proof of Presence Preview for EMU

GitHub Enterprise Cloud Proof of Presence Adds an Entra ID Checkpoint to Sudo Mode​

GitHub announced the feature in its changelog and calls it an expansion of sudo mode for enterprises. Sudo mode is GitHub's name for asking a signed-in user to confirm their identity before a sensitive action. With proof of presence turned on, GitHub sends the member to the identity provider (IdP) when they try a protected action. The action only goes ahead if the member comes back with proof that they met the policy the enterprise requires.

GitHub's configuration documentation says proof of presence "adds an identity-provider challenge to sudo mode for enterprises." It also says the actions that trigger sudo mode are the same ones that trigger the new challenge. The documentation update was merged into GitHub's public docs repository as "Proof of Presence (PoP) – Interactive re-authentication for high-impact actions (Entra IdP) [public preview]." Both GitHub's documentation and changelog label the feature a public preview and say it may change.

The preview has tight limits. The changelog restricts it to EMU enterprises on github.com and on GHEC-DR, the GitHub Enterprise Cloud offering with data residency. Those enterprises must use Microsoft Entra ID as the SSO identity provider. The developer news aggregator daily.dev describes the same boundary: the feature is currently limited to managed user (EMU) enterprises on github.com and GHEC-DR using Microsoft Entra ID as their SSO IdP via SAML or OIDC. That write-up restates GitHub's announcement, though, so it is not independent confirmation.

GitHub's own records don't fully agree on scope. The configuration guide says the feature is available to "Enterprise accounts on GitHub Enterprise Cloud." Its prerequisites also cover enterprises that use personal accounts with SAML SSO, not just EMU. The changelog, by contrast, says the preview is "only scoped" to EMU enterprises. Until GitHub resolves this, the safer reading is the narrower one: EMU plus Entra ID. Organizations with personal accounts and SAML SSO shouldn't plan around the feature yet.

Why Enterprise Managed Users Needed Something Other Than the Sudo Prompt​

The feature is aimed at EMU for a clear reason. GitHub's documentation on managed user accounts says they authenticate only through the enterprise's identity provider and have no password or two-factor methods stored on GitHub. The same page adds that, as a result, managed users "do not see the sudo prompt when taking sensitive actions."

That's the before-and-after in one sentence. A regular GitHub user who tries to create a personal access token or change a webhook is asked to confirm with a password, passkey, security key, GitHub Mobile or a TOTP code, even though they're already signed in. A managed user had nothing stored on GitHub to confirm with, so there was no prompt. An active session was enough to perform the same sensitive actions.

Proof of presence fills that gap without storing credentials on GitHub. The check happens at the IdP, where EMU identities already live. So the conditions attached to the check are set by the organization's Entra ID policies, not by GitHub's account-level options.

The High-Impact Actions Proof of Presence Now Guards​

The changelog names four examples of protected actions: creating a token, editing webhooks, changing organization security settings and viewing recovery codes. Because the configuration guide ties proof of presence to the sudo-mode trigger list, the wider list from GitHub's sudo mode documentation is the best guide to what's covered. That list is marked as "including but not limited to":

• Account changes, including deleting a user account, changing an associated email address, adding a new SSH key or authorizing third-party applications.
• Developer settings, including generating or removing a client secret, creating personal access tokens, revoking all tokens or transferring an OAuth app.
• Webhooks at repository, organization or enterprise level, including creating, viewing, editing or deleting them, and viewing or redelivering webhook deliveries.
• Organization membership changes, including sending or editing invitations, adding members directly, adding team members or changing team roles.
• Organization security changes, such as changing two-factor enforcement or other security settings.
• Enterprise settings, such as creating organizations in an enterprise or changing app access settings for an IdP IP allow list.
• Creating and modifying rulesets at organization and repository level.
• Viewing, downloading, printing or regenerating authentication or SSO recovery codes.

Some of those items apply to personal accounts, and not every one will matter in an EMU context. The general shape still holds: these are the actions an attacker would use to stay in, widen access or quietly pull out data.

Pull request merges are the notable gap. GitHub says support for requiring proof of presence before merging a pull request is "coming soon" and gives no date. Until that ships, the control protects the settings that decide who can do what. It does not yet protect the moment code actually lands in a protected branch.

Two Policy Choices, and Entra ID Decides What They Actually Mean​

Administrators pick one of two requirements. Both send the member through the IdP, but they give different levels of assurance.

This is the most important design point for administrators. GitHub does not set the strength of the challenge itself; the IdP does. The changelog says the IdP check could mean multi-factor authentication, a device compliance check, or simply signing in again to show the session is fresh. GitHub's documentation tells customers to make sure their IdP authentication policies provide the level of assurance they need before turning the feature on.

The practical takeaway is simple. If your Entra ID sign-in accepts a password on its own, "Re-authentication" mostly proves that someone knows the password. It doesn't prove the person is using a trusted device or holding a second factor. The MFA option is the one that raises the bar against someone replaying a stolen session. GitHub's announcement does not say exactly how Entra ID Conditional Access policies are evaluated during the redirect. Administrators should test whether their device-compliance rules apply to this flow rather than assume they do.

The Two-Hour Session Window Behind the Proof of Presence Challenge​

Proof of presence doesn't challenge every single action. According to the changelog, after a successful challenge the member can keep performing high-impact actions in the same browser session for two hours without another check. That's the same session model sudo mode uses. The configuration guide phrases it as members can act "until the sudo-mode session expires."

There's a detail in GitHub's standard sudo mode documentation worth noting. It says any sensitive action taken during the two-hour window resets the timer. The proof-of-presence pages don't restate that rule. Since GitHub says the two features share the same session and timeout model, though, it's a reasonable inference that an administrator doing steady sensitive work could stay in the elevated state for longer than two hours in total. Security teams modelling exposure should treat two hours as the minimum window after the last sensitive action, not a hard cap from the first challenge.

The window is also tied to the browser session. The published material describes the challenge as happening when a member attempts an action interactively. It does not explain how API calls made with tokens that already exist are treated. That gap matters to anyone thinking this control neutralizes previously leaked tokens. What it clearly does is stop a hijacked session from minting new tokens or changing webhooks without passing the IdP check.

Turning On Proof of Presence in GitHub Enterprise Cloud​

GitHub documents a short setup path. The prerequisite is working SSO between the enterprise and a supported IdP, which during the preview means Microsoft Entra ID. For EMU enterprises, that is the IdP configuration set up when the enterprise was first created.

1. Go to your enterprise account, for example from the Enterprises page on github.com.
2. Click Settings at the top of the page.
3. Under Settings, click Authentication security.
4. In the Proof of presence dropdown, choose either Re-authentication or MFA.

The policy applies across the entire enterprise as soon as it's enabled. There's no documented way to pilot it on one organization first. Tell members before you switch it on, because the first token creation or webhook edit afterward will send them to Entra ID unexpectedly.

If it works, a member who tries a protected action is sent to the Entra ID sign-in, completes whatever prompts the policy requires, and returns to GitHub to finish the action. If a member can't complete the challenge, GitHub's documentation says they should contact the enterprise administrator or IdP administrator who manages authentication. The guide describes no other bypass or fallback path. That makes it important to check the IdP policy before enabling. If the MFA option is chosen and some administrators haven't registered a second factor in Entra ID, they will be locked out of these actions until they do.

Stolen Sessions, Agents and FDA Part 11 Drive the Rationale​

GitHub points to recent attacks to explain the feature. The changelog says stolen session cookies and long-lived authentication tokens "have shown up in several recent supply chain attacks." It says proof of presence confirms a real, authorized person is acting at the moment of the high-impact action, not just that a valid session or token was presented. GitHub also says the check can stop compromised or hijacked credentials, or agents, from going "an extra step" without the organization's knowledge. That's a pointed mention now that AI coding agents increasingly act inside developer sessions.

That's GitHub's case for the feature, and the mechanism backs it within limits. A cookie stolen by infostealer malware carries an authenticated session, but it can't pass a fresh MFA challenge at Entra ID. With the MFA option set, that cookie can no longer be used to create a personal access token, add a webhook that sends repository events to an attacker's server, or relax organization security settings. The control does not claim to prevent session theft itself, and it doesn't cover merges yet.

On compliance, GitHub says fresh authentication before sensitive operations helps regulated customers meet requirements from frameworks such as FDA Part 11. The word is "helps." Turning on a GitHub setting doesn't make an organization compliant by itself. The assurance an auditor sees depends on what the Entra ID policy actually enforces at the redirect.

What this means for you​

If you run an EMU enterprise on github.com or GHEC-DR with Entra ID, you should seriously consider this preview, because until now your members had no step-up check on sensitive actions at all. Everyone else, including enterprises using personal accounts and enterprises using a non-Entra IdP such as Okta, can't use it yet under the scope GitHub announced and should wait for broader support. Before you enable it, check what your Entra ID policy actually requires at sign-in. The strength of the GitHub setting is limited by the strength of that policy.

• Proof of presence is a public preview, announced September 24, 2026, and GitHub says it may change before general availability.
• Only EMU enterprises on github.com and GHEC-DR using Microsoft Entra ID over SAML or OIDC are in scope, even though GitHub's configuration guide describes eligibility more broadly.
• The MFA option is the one that meaningfully resists stolen-session abuse; the Re-authentication option may be satisfied by a password alone, depending on your IdP policy.
• Enabling the setting under Enterprise Settings > Authentication security applies it to the whole enterprise at once, so make sure administrators have Entra ID MFA registered first.
• A successful challenge covers two hours of protected actions in that browser session, and under GitHub's sudo-mode rules further sensitive actions probably extend that window.
• Pull request merges are not protected yet; GitHub says that support is coming but hasn't given a date.

Proof of presence gives Enterprise Managed Users the confirmation step personal GitHub accounts have had for years, and puts it in Entra ID where enterprise identity policy already lives. For Entra-backed EMU shops, the MFA option is a low-cost way to stop a hijacked session from creating tokens, changing webhooks or loosening security settings. The next milestone to watch is merge protection. Once proof of presence can gate the moment code reaches a protected branch, it will cover the supply-chain step GitHub's own rationale is most concerned about.