Offboarding seguro en Microsoft 365: checklist al dar de baja empleados

Por Kike Gandia · Co-Fundador y CEO, OSCP

Una cuenta de ex-empleado mal gestionada en Microsoft 365 sigue teniendo acceso a correo, archivos y aplicaciones federadas mucho después de que la persona se haya ido, si el proceso de baja se limita a desactivar el inicio de sesión. Este checklist cubre el offboarding seguro de un empleado en Microsoft 365, paso a paso.

Bloquea el inicio de sesión y revoca sesiones activas de inmediato

El primer paso es bloquear el inicio de sesión de la cuenta y revocar explícitamente todas las sesiones activas y los tokens de actualización (refresh tokens). Bloquear el inicio de sesión por sí solo no cierra las sesiones ya abiertas: un token válido puede seguir dando acceso durante horas si no se revoca de forma expresa. Este paso debe ejecutarse el mismo día de la baja, no en el siguiente ciclo de mantenimiento.

Revisa reglas de reenvío, delegaciones de buzón y apps OAuth

Antes de asumir que la cuenta está aislada, revisa si el usuario configuró reglas de reenvío automático en Exchange, si delegó acceso a su buzón a otra persona (delegación que puede sobrevivir a la baja) y qué aplicaciones OAuth de terceros tienen consentimiento sobre su cuenta. Cualquiera de los tres puede mantener un canal de acceso a la información de la cuenta incluso con el inicio de sesión bloqueado.

Transfiere el buzón, OneDrive y la propiedad de Teams

Convierte el buzón en compartido o transfiérelo a un responsable para no perder correo relevante para el negocio, y transfiere la propiedad de los archivos de OneDrive a un manager u otra ubicación con la herramienta de migración de Microsoft. Revisa también los equipos de Teams y canales de los que el usuario era único propietario: sin transferencia previa, esos equipos pueden quedar sin administrador tras la baja.

Revoca dispositivos, licencias y aplica retención

Desvincula o borra remotamente los dispositivos gestionados asociados a la cuenta (Intune), retira al usuario de todos los grupos de seguridad y distribución, aplica la política de retención que corresponda (con Purview si procede) y, por último, libera la licencia de Microsoft 365. Documenta cada paso: es la evidencia que necesitarás si surge una disputa o una investigación posterior.

Comprueba lo que la cuenta dejó fuera del buzón

El correo y los archivos son la parte visible del rastro que deja un empleado en Microsoft 365, pero rara vez es la parte que crea problemas meses después. Antes de cerrar la baja conviene revisar qué construyó esa identidad en el tenant.

Lo que suele aparecer: aplicaciones registradas o entidades de servicio creadas por el usuario, con secretos propios que siguen siendo válidos aunque la cuenta esté bloqueada; flujos de Power Automate y aplicaciones de Power Apps de los que era propietario, que o bien dejan de funcionar y rompen un proceso de negocio, o bien siguen ejecutándose con su identidad; asignaciones de rol en suscripciones de Azure que no aparecen en ningún informe de Microsoft 365; credenciales guardadas en un Key Vault al que solo él accedía; y dispositivos registrados en Entra que siguen figurando como suyos.

Qué sobrevive al bloqueo del inicio de sesión

Esta es la tabla que conviene tener delante al cerrar una baja, porque casi todo lo que hay en ella se da por resuelto y no lo está.

Elemento	¿Lo corta el bloqueo de inicio de sesión?	Qué hay que hacer
Sesión de navegador ya abierta	No, hasta que caduque el token	Revocar sesiones y tokens de actualización
Regla de reenvío en Exchange	No	Eliminarla de forma explícita
Delegación de buzón	No	Retirarla en Exchange
Consentimiento concedido a una app OAuth	No	Revocar el consentimiento del usuario
Flujo de Power Automate del usuario	No, sigue ejecutándose	Transferir la propiedad o desactivarlo
Secreto añadido a una aplicación registrada	No	Rotar el secreto y reasignar el propietario
Exclusión de acceso condicional	No	Sacar al usuario del grupo de exclusión
Asignación de rol en Azure	No	Retirar la asignación
Equipo de Teams del que era único propietario	No, pero queda sin administrador	Asignar un propietario nuevo antes de la baja

FAQ

¿Basta con desactivar la cuenta en Entra ID el día de la baja?

No es suficiente por sí solo. Desactivar la cuenta bloquea nuevos inicios de sesión, pero no revoca sesiones y tokens ya activos, ni elimina reglas de reenvío, delegaciones o consentimientos de apps OAuth que puedan mantener acceso independiente a la contraseña o al estado de la cuenta.

¿Qué pasa si el empleado tenía Conditional Access con exclusión propia?

Hay que revisar y eliminar cualquier exclusión de Conditional Access asociada a la cuenta como parte del offboarding, porque una exclusión olvidada puede dejar a esa identidad sin las protecciones de MFA o de dispositivo gestionado que sí aplican al resto de la organización.

¿Cuándo convierto el buzón en compartido y cuándo lo transfiero?

Convertirlo en compartido tiene sentido cuando la dirección sigue recibiendo correo de negocio que alguien debe atender: clientes, proveedores o un alias funcional. Transferir el contenido a un responsable encaja mejor cuando lo que interesa es el histórico y la dirección puede dejar de existir. Lo que conviene evitar es la tercera opción de facto: dejar el buzón intacto con la cuenta bloqueada y sin dueño, que es como se acumulan identidades muertas con datos vivos.

¿El buzón compartido consume licencia?

Depende del tamaño del buzón y de si se le aplican funciones que requieran licencia, como determinadas políticas de retención o de archivado. La comprobación es rápida y conviene hacerla antes de convertir buzones en masa, porque el ahorro esperado al liberar licencias puede desaparecer si los buzones compartidos acaban necesitando una de todas formas.

¿Cómo lo gestionamos con muchas bajas al año?

A mano deja de ser viable enseguida, y el fallo no es de diligencia sino de diseño: un checklist de nueve pasos ejecutado por personas distintas siempre pierde alguno. La vía razonable es automatizar la secuencia con Graph y PowerShell, dejando registro de cada paso, y reservar la intervención manual para las decisiones que sí requieren criterio: qué se hace con el buzón, quién hereda los equipos de Teams y qué flujos hay que transferir.

¿Y si hay una investigación o una reclamación abierta?

Entonces el orden cambia: antes de transferir, convertir o borrar nada, hay que aplicar la retención correspondiente sobre el buzón y OneDrive. Transferir la propiedad o eliminar la cuenta altera el estado que después haría falta justificar. Aplicada la retención, el resto del checklist se ejecuta con normalidad, pero con la garantía de que el contenido original se conserva.