GitHub lanzó el 24 de septiembre de 2026 Proof of Presence, o prueba de presencia, para elevar la protección de acciones de alto impacto en GitHub Enterprise Cloud. En el anuncio del preview, el alcance se limitó a empresas con Enterprise Managed Users (EMU) en github.com y GHEC-DR que usan Microsoft Entra ID como proveedor de identidad mediante SAML u OIDC. Una sesión ya autenticada deja de ser suficiente para determinadas operaciones sensibles.
Cuando un miembro intenta una acción protegida, GitHub lo redirige al proveedor de identidad. Entra ID aplica la política de la organización y devuelve la confirmación de que el desafío se completó. La configuración puede exigir solo una nueva autenticación o también MFA. La función está en public preview y puede cambiar.
Quién puede activar la prueba de presencia
Dentro del alcance anunciado en el lanzamiento, la empresa necesita GitHub Enterprise Cloud con Enterprise Managed Users, Microsoft Entra ID como IdP y SSO mediante SAML u OIDC. También debe definir en Entra ID una política de autenticación compatible con el nivel de garantía requerido.
La documentación de GitHub identifica la función como preview público e indica compatibilidad con Microsoft Entra ID. Como el alcance puede ampliarse rápidamente, los administradores deben consultar la documentación vigente antes de habilitarla.
Qué acciones pueden exigir reautenticación
Proof of Presence amplía el modo sudo empresarial. Las acciones protegidas por el modo sudo también pueden activar el desafío.
| Área | Ejemplos de acciones protegidas |
|---|---|
| Tokens y credenciales | Crear personal access tokens, añadir claves SSH, generar o eliminar secretos de cliente y revocar tokens. |
| Webhooks | Crear, ver, editar o eliminar webhooks de repositorio, organización o empresa, además de ver o reenviar entregas. |
| Cuenta y aplicaciones | Cambiar el correo asociado, eliminar una cuenta o autorizar aplicaciones de terceros. |
| Seguridad y recuperación | Cambiar configuraciones de seguridad de la organización y ver códigos de recuperación, según los flujos protegidos disponibles. |
El anuncio indica que la prueba de presencia antes de fusionar pull requests llegará más adelante, por lo que ese caso no debe considerarse disponible en el preview inicial.
Reautenticación o MFA
Con Re-authentication, el miembro se autentica de nuevo en el IdP y, según la política empresarial, una contraseña puede ser suficiente. Con MFA, además debe completar un factor adicional configurado en Entra ID, como una aplicación autenticadora o biometría.
GitHub delega la verificación al IdP, lo que permite combinar la exigencia de GitHub con controles de identidad ya administrados por la empresa, incluidas políticas basadas en el método de autenticación o el cumplimiento del dispositivo.
Cuánto dura la validación
Después de completar el desafío, el usuario entra en la misma ventana de sesión protegida que usa el modo sudo. En el lanzamiento, esa ventana permite realizar acciones protegidas en el mismo navegador durante dos horas sin repetir la prueba de presencia. Cuando caduca, una nueva acción de alto impacto vuelve a exigir el desafío.
Esto reduce interrupciones durante una secuencia breve de tareas administrativas, pero significa que MFA no se solicita en cada clic. Los equipos que necesiten una garantía más estricta deben considerar este modelo de sesión.
Cómo habilitarla y qué validar antes
- Abra la empresa en GitHub y vaya a Settings.
- Entre en Authentication security.
- En Proof of presence, elija reautenticación o MFA.
- Pruebe el flujo con las políticas de Entra ID y confirme que los miembros pueden completar el desafío y volver a GitHub.
Antes de una activación amplia, conviene probar cuentas administrativas, métodos de MFA, reglas de acceso condicional y procedimientos de recuperación. Una política del IdP demasiado restrictiva puede bloquear una operación sensible, mientras que una demasiado permisiva puede reducir el beneficio esperado.
Qué cambia para los equipos de seguridad
El cambio principal es separar una sesión válida de una autorización reciente para una acción crítica. GitHub presentó la función como protección para escenarios en los que se comprometen cookies de sesión o tokens de autenticación de larga duración. Proof of Presence no sustituye la protección de credenciales, la revisión de tokens, el mínimo privilegio ni la supervisión de auditoría, pero añade una barrera interactiva al intentar una operación sensible.
Consulte el anuncio de GitHub, la documentación de Proof of Presence y la referencia de modo sudo.
