GitHub Enterprise Cloud has introduced a public‑preview feature named proof of presence that forces a user to re‑authenticate or satisfy an MFA challenge through their Microsoft Entra ID identity provider before performing certain high‑impact actions. This extra verification step is designed to ensure that a live, authorized person is initiating the operation, reducing the risk posed by stolen session cookies or long‑lived tokens.
Proof of presence workflow
When a member of a managed‑user (EMU) enterprise attempts an operation such as creating a personal access token, editing a webhook, changing organization security settings, or viewing recovery codes, GitHub redirects the browser to the configured IdP (Microsoft Entra ID via SAML or OIDC). The IdP then enforces the organization’s authentication policy, which may be a simple password re‑entry, a full multi‑factor challenge, or additional device‑compliance checks. After the IdP returns a successful response, GitHub records a proof of presence token that remains valid for two hours, allowing subsequent high‑impact actions in the same session without another challenge.
Why engineers and security teams should care
Recent supply‑chain incidents have demonstrated that attackers can hijack active sessions and reuse long‑lived authentication tokens. By requiring a fresh authentication step at the moment of a critical operation, proof of presence raises the bar against credential‑theft attacks and helps organizations satisfy regulatory mandates that demand “fresh” authentication for sensitive changes (e.g., FDA Part 11). For DevOps pipelines, SREs, and AI engineers who automate token creation or webhook updates, the extra redirect introduces a potential pause that must be accounted for in automation scripts.
Architectural and operational implications
- Scope limitation: The preview is limited to EMU enterprises on github.com and GHEC‑DR that use Microsoft Entra ID as the SSO provider. Environments using other IdPs are not affected.
- IdP policy dependency: The strength of the proof of presence check depends entirely on the IdP’s configured policies. Organizations should review their Entra ID conditional access rules to ensure they align with the desired security posture.
- Session duration: After a successful challenge, the proof of presence token is valid for two hours. Teams need to understand this window when designing short‑lived automation tokens or when rotating credentials more frequently.
- Impact on automation: Scripts that perform high‑impact actions in non‑interactive contexts (e.g., CI jobs) will encounter a redirect that cannot be satisfied without a human‑presented factor. Workarounds may include pre‑authorizing service accounts with limited scopes or postponing such actions until a proof of presence has been established manually.
- Future expansion: Support for proof of presence before pull‑request merges is announced as forthcoming, indicating that the control surface will broaden beyond the current set of actions.
Related CloudNinjas coverage: security.
What This Means For Practitioners
Evaluate your organization’s Microsoft Entra ID conditional access policies to confirm they enforce the desired re‑authentication or MFA requirements for proof of presence. Test the preview in a staging environment to identify any automation breakage caused by the redirect flow, and consider adjusting service‑account scopes or introducing manual checkpoints where necessary. Finally, monitor the two‑hour proof of presence window to ensure it aligns with your credential‑rotation cadence and compliance timelines.
