GitHub lanzó el 24 de septiembre en vista previa pública una función denominada proof of presence que permite exigir una reautenticación interactiva o un reto multifactor antes de ejecutar acciones de alto impacto. Está dirigida a empresas con Enterprise Managed Users que utilizan Microsoft Entra ID como proveedor de identidad mediante SAML u OIDC, según el anuncio oficial de GitHub.
Qué acciones pueden exigir una nueva comprobación
El control busca añadir una barrera adicional en operaciones que pueden cambiar de forma importante la seguridad de una cuenta. GitHub cita entre los ejemplos la creación de tokens, cambios en webhooks, modificaciones de determinados ajustes de seguridad y el acceso a códigos de recuperación.
El objetivo no es sustituir el inicio de sesión corporativo, sino comprobar que la persona sigue presente y puede superar de nuevo la autenticación justo antes de una operación sensible.
La validación tiene una ventana de dos horas
Tras superar correctamente la prueba, GitHub mantiene una ventana de dos horas en la que el usuario no necesita repetir el desafío para otras acciones cubiertas. Una vez agotado ese periodo, volverá a requerirse una nueva comprobación cuando corresponda.
Esto intenta equilibrar seguridad y fricción: se añade una defensa frente a sesiones comprometidas sin obligar a responder un MFA en cada clic administrativo.
Quién puede utilizarlo ahora
La vista previa está orientada a cuentas Enterprise Managed Users en GitHub Enterprise Cloud, incluidas configuraciones compatibles con residencia de datos, cuando Microsoft Entra ID actúa como proveedor de identidad. GitHub señala además que ampliará la cobertura a más acciones; el soporte antes de fusionar pull requests figura entre las capacidades previstas.
Qué debería revisar una empresa
Las organizaciones que administran repositorios sensibles deberían identificar qué acciones tienen mayor impacto, comprobar su configuración de Entra ID y MFA y decidir si el control encaja en sus flujos. También conviene comunicar la ventana de dos horas a los administradores para evitar que interpreten el nuevo reto como un fallo de sesión.
La función resulta especialmente relevante en cuentas con muchos administradores o con secretos y automatizaciones conectadas a repositorios. Un token o webhook alterado puede abrir una vía de acceso fuera del flujo habitual de autenticación, por lo que añadir una comprobación de presencia reduce el riesgo de que una sesión robada sea suficiente para completar el cambio.
Las empresas que refuercen sus controles de acceso pueden ampliar contexto con la transición a passkeys, la alerta sobre EvilTokens y robo de cuentas, el nuevo centro de seguridad de Microsoft Defender, el parche crítico de GitLab, la remediación de Cloudflare CASB y los fallos de StockAgile.
Fotografía: Christina Morillo / Pexels.
