GitHub Adds Fresh Authentication: Entra ID Preview Only

GitHub introduced Proof of Presence in public preview on September 24, 2026, for Enterprise Managed Users (EMU) enterprises on github.com and GitHub Enterprise Cloud with data residency that use Microsoft Entra ID for SSO via SAML or OIDC, according to its launch note. The feature can require a new identity-provider challenge before members create tokens, edit webhooks, change organization security settings or view recovery codes.

For an eligible administrator, the decision is what Entra ID must demand at that challenge and whether people who perform sensitive work can still regain access when their usual factor or device is unavailable. The control adds a checkpoint to protected actions in an existing browser session. It does not require a separate challenge for every action.

The preview’s eligibility is narrower than the help page suggests

The dated launch announcement limits the preview to EMU enterprises using Entra ID. GitHub’s configuration guide, however, labels the feature available to Enterprise Cloud accounts generally and includes SSO prerequisites for enterprises using personal accounts. Those statements describe different scopes. Until GitHub clarifies the broader wording, the explicit launch boundary is the sound basis for a rollout plan.

Eligible enterprises need SSO with Entra ID in place. The control sits in enterprise Settings under Authentication security, where an administrator selects a requirement from the Proof of presence dropdown. Enabling it applies the policy across the enterprise; the published setup does not describe a switch for piloting one organization within that enterprise. An administrator who needs a staged rehearsal should therefore use a separate eligible test enterprise if one is available.

The check protects the actions that trigger sudo mode

Proof of Presence extends GitHub’s sudo mode. When enabled, an action that would trigger sudo mode instead requires the member to return from the enterprise identity provider with evidence that the selected requirement was met. The launch examples are concrete: token creation can establish a new credential, webhook changes can alter an integration, organization security changes can affect access rules, and recovery-code viewing can expose a route back into an account.

The documented rule is broader than those examples because it follows the protected-action boundary of sudo mode. Administrators should map their actual privileged workflows to that boundary rather than treat the four launch examples as an exhaustive list. Pull request merge protection was described as forthcoming, so a plan for the current preview should not count a merge itself as a newly protected action. The feature also describes a challenge before an interactive protected action, not a cleanup of credentials issued earlier.

Entra ID policy sets the strength of the challenge

The GitHub setting offers Re-authentication and MFA. Re-authentication sends the member back to Entra ID to authenticate again; depending on the enterprise policy, a password may satisfy that requirement. MFA requires another authentication step plus an additional factor, such as an authenticator app or biometric method configured through the identity provider. A device-compliance condition may also be relevant, but its effect depends on the Entra ID policy applied to the redirect.

That distinction matters when the threat is a stolen browser session. If the person using it cannot pass a required additional factor, the fresh challenge can prevent a protected change. A password-only policy sets a different barrier, particularly if the password is compromised too. Before enforcement, administrators should compare the intended assurance level with the prompts their privileged users actually receive, including on devices that do not meet their normal access conditions. The GitHub dropdown alone cannot establish what Entra ID will accept.

The two-hour window is a rolling exposure

A successful challenge permits further protected actions in the same browser session without an immediate repeat prompt. A WindowsForum examination highlights the relevant sudo-mode rule: a sensitive action during the two-hour window resets its timer. Because Proof of Presence inherits sudo mode’s session and timeout model, administrators should plan around a potentially rolling window, rather than assume access always ends two hours after the first challenge. That application of the sudo-mode rule to the preview is an inference, not a separately documented test result.

The checkpoint has a narrower security effect than continuous verification. It can obstruct someone using a hijacked session when a new challenge is due and they cannot satisfy Entra ID’s policy. It does not establish that the endpoint remains trustworthy after a legitimate challenge, and the published behavior does not promise to revoke existing tokens or restrict what an already valid token can do through an API. A compromised endpoint or previously exposed credential therefore remains a separate problem.

Rollout depends on recovery as well as enforcement

A useful rehearsal starts with the protected work that an enterprise actually performs: creating a token, changing a webhook, changing organization security settings and retrieving recovery codes. For each workflow, identify who must complete it and whether the Entra ID policy should require another sign-in or an additional factor. Then try the action with representative privileged accounts and record both the prompt and the result. This is an operational recommendation, not a claim that GitHub provides a built-in policy test.

Recovery-code access deserves particular attention because the enterprise-wide policy can interrupt it at the moment it is needed. Rehearse an emergency administrator’s route through the challenge when a usual factor is lost or a device fails the applicable condition. Members who cannot complete a challenge are directed to an enterprise or identity-provider administrator; the published configuration guidance does not describe a GitHub-side bypass. The recovery plan should therefore identify who can restore access through Entra ID and how that person remains reachable during an incident.

At the current preview stage, an Entra-backed EMU enterprise can gate sensitive interactive changes with its chosen identity policy, subject to sudo mode’s session behavior. The open product questions are when merge protection will arrive and whether GitHub will expand eligibility beyond the explicitly announced EMU scope. Neither change has a published release date.