Alta y baja de empleados en Microsoft 365: proceso seguro para no perder datos ni dejar accesos abiertos

Resumen rápido: alta y baja de empleados en Microsoft 365 en 10 puntos

1. El proceso empieza en RRHH: IT necesita una señal fiable de alta, cambio o baja para actuar a tiempo.
2. La identidad es la base: el usuario en Microsoft Entra ID debe crearse con atributos correctos: departamento, cargo, manager, ubicación, tipo de contrato y fecha de incorporación o salida.
3. Las licencias deben asignarse por grupos: reduce errores, acelera altas y facilita retirar licencias cuando la persona sale.
4. El acceso debe ser mínimo desde el primer día: grupos, Teams, SharePoint y aplicaciones deben asignarse por rol, no “copiando” usuarios sin revisar.
5. La baja debe bloquear acceso antes de tocar datos: primero se bloquea el inicio de sesión, se revocan sesiones y se protegen credenciales; después se decide qué hacer con correo, OneDrive y equipos.
6. No retires licencias sin plan de datos: al quitar ciertas licencias se activan periodos de retención limitados; conviene convertir buzones, delegar OneDrive y aplicar políticas de retención cuando haga falta.
7. Teams y SharePoint necesitan nuevos propietarios: si el empleado era owner de equipos o sitios, hay que reasignar responsabilidad para no dejar espacios huérfanos.
8. Power Platform suele olvidarse: flujos, apps, conexiones y automatizaciones pueden depender de la cuenta de una persona.
9. Los dispositivos importan: en Intune hay que decidir si se retira, borra o reasigna el dispositivo según sea corporativo o BYOD.
10. El proceso debe medirse: tiempo de alta, tiempo de revocación, accesos huérfanos, licencias recuperadas e incidencias post-baja.

¿Cuándo se necesita un proceso formal de altas y bajas en Microsoft 365?

Cualquier empresa que utilice Microsoft 365 necesita un proceso de alta y baja de usuarios. La diferencia está en el nivel de madurez: algunas organizaciones lo hacen manualmente desde el centro de administración; otras lo integran con RRHH, grupos, licencias, flujos automáticos y revisiones de acceso.

Escenarios habituales

• Empresas en crecimiento: cada semana entran nuevos empleados y se necesita entregar correo, Teams, OneDrive, licencias y dispositivos sin retrasos.
• Alta rotación: sectores con personal temporal, delegaciones, tiendas, turnos o equipos operativos donde el riesgo de dejar accesos abiertos se multiplica.
• Trabajo híbrido o remoto: el acceso no depende de estar en la oficina; por eso, bloquear identidad, sesiones y dispositivos es crítico.
• Entornos regulados: empresas que necesitan evidencias de quién tenía acceso, cuándo se retiró y qué datos se conservaron.
• Uso intensivo de Teams y SharePoint: los empleados no solo tienen correo; también son propietarios de equipos, sitios, flujos, apps y documentación.
• Reorganizaciones internas: cuando una persona cambia de departamento, no basta con añadir permisos nuevos; también hay que retirar los antiguos.

Introducción

La gestión de empleados en Microsoft 365 no empieza cuando se crea una cuenta ni termina cuando se elimina un usuario. En una empresa moderna, una identidad toca muchas piezas: Microsoft Entra ID, Exchange Online, Teams, SharePoint, OneDrive, Intune, Defender, Purview, Power Platform, grupos, aplicaciones SaaS y, en muchos casos, sistemas locales.

Por eso, hablar de alta y baja de empleados en Microsoft 365 es hablar de seguridad, productividad y continuidad de negocio. Un buen alta permite que la persona empiece a trabajar con las herramientas correctas desde el primer día. Una buena baja evita accesos no autorizados, conserva datos críticos y deja trazabilidad para auditorías.

Esta guía está pensada para equipos de IT, seguridad, operaciones y RRHH que quieren pasar de un proceso manual e improvisado a un modelo más seguro, repetible y fácil de auditar. El objetivo no es crear burocracia: es quitar incertidumbre.

1. Metodología joiner-mover-leaver

En la práctica: el modelo joiner-mover-leaver ordena el ciclo de vida del empleado: entra, cambia de rol y sale.

Microsoft Entra ID Governance utiliza el enfoque joiner-mover-leaver para automatizar tareas del ciclo de vida de los usuarios. Traducido a lenguaje sencillo:

• Joiner: una persona entra en la organización y necesita acceso inicial.
• Mover: una persona cambia de puesto, área, país, proyecto o responsabilidad.
• Leaver: una persona sale de la organización o deja de necesitar acceso.

Por qué este modelo funciona

Porque evita que IT actúe solo cuando “alguien se acuerda”. El proceso se dispara por eventos de negocio: contratación, cambio de puesto, baja voluntaria, despido, fin de contrato, excedencia, proveedor que termina proyecto o cambio de manager.

La clave es que cada fase tenga dueño. Si “todos” son responsables de una baja, en la práctica no lo es nadie.

2. Assessment: inventario de identidades, accesos y datos críticos

En la práctica: antes de automatizar, hay que saber qué se está automatizando y qué riesgos existen.

Muchas empresas intentan automatizar altas y bajas sin haber revisado antes sus grupos, licencias, permisos y aplicaciones. El resultado suele ser un proceso rápido, pero no necesariamente seguro.

Qué debe revisar el assessment

Resultado esperado

El assessment debe terminar en una hoja de ruta clara: qué puede automatizarse ya, qué hay que limpiar antes, qué grupos se usarán para licencias, qué datos se conservarán en bajas y qué roles deben revisar accesos de forma periódica.

3. Alta de empleados en Microsoft 365 paso a paso

En la práctica: una buena alta permite que la persona trabaje desde el primer día sin pedir accesos uno a uno.

El alta de un empleado en Microsoft 365 debe ser predecible. La persona no debería empezar con “no tengo correo”, “no veo Teams” o “me falta acceso a SharePoint”. Al mismo tiempo, tampoco debería recibir permisos por exceso “por si acaso”.

3.1 Datos mínimos que debe enviar RRHH

• Nombre completo y nombre preferido.
• Fecha de incorporación y tipo de contrato.
• Departamento, cargo, ubicación y manager.
• Perfil de acceso: estándar, directivo, externo, temporal, frontline, técnico, privilegiado.
• Necesidad de dispositivo corporativo, móvil, grupos, apps específicas o acceso a datos sensibles.

3.2 Creación de usuario

El usuario puede crearse manualmente en el centro de administración, sincronizarse desde Active Directory local o provisionarse automáticamente desde un sistema de RRHH. En cualquier caso, es importante estandarizar:

• Formato de UPN y correo principal.
• Alias de correo si aplica.
• Atributos completos para automatizar reglas: departamento, país, manager, puesto.
• Grupos base según rol.

3.3 Licencias por grupo

La asignación de licencias por grupos en Microsoft Entra reduce errores: cuando una persona entra en el grupo adecuado, recibe la licencia correcta; cuando sale, la licencia puede retirarse de forma controlada.

3.4 MFA, registro de seguridad y Acceso Condicional

El alta debe incluir el registro de métodos MFA, autoservicio de restablecimiento de contraseña si se usa, y políticas de Acceso Condicional adaptadas al perfil. Una cuenta nueva sin MFA es una puerta abierta.

3.5 Dispositivo, Intune y aplicaciones

Si la persona recibe portátil o móvil corporativo, el alta debe coordinarse con Intune:

• Asignación de dispositivo o Autopilot si aplica.
• Políticas de cumplimiento.
• Aplicaciones requeridas.
• Configuración de Outlook, Teams, OneDrive y navegador corporativo.

4. Cambios de puesto: el gran olvidado del ciclo de vida

En la práctica: muchas brechas de acceso nacen cuando alguien cambia de rol y conserva permisos antiguos.

La mayoría de empresas tiene algún proceso de alta y baja. Pero los cambios internos suelen quedar peor controlados. Un empleado pasa de ventas a finanzas, de soporte a administración o de un proyecto a otro, y acumula permisos históricos.

Qué debe ocurrir en un cambio de puesto

1. Actualizar atributos: departamento, cargo, manager, ubicación y centro de coste.
2. Añadir nuevos accesos: grupos y aplicaciones del nuevo rol.
3. Retirar accesos antiguos: grupos de equipos, SharePoint, Teams, aplicaciones y buzones compartidos que ya no corresponden.
4. Revisar licencias: puede cambiar el tipo de licencia necesaria.
5. Revisar dispositivo: si el rol exige mayor seguridad, compliance o apps distintas.

Recomendación práctica

Cada cambio de puesto debería tratarse como una baja parcial y un alta parcial: se quita lo que ya no corresponde y se entrega lo nuevo.

5. Baja de empleados en Microsoft 365 paso a paso

En la práctica: la baja segura bloquea el acceso rápido, conserva datos necesarios y elimina lo que ya no debe permanecer activo.

La baja de un empleado debe seguir un orden claro. Si eliminas primero la cuenta o quitas licencias sin pensar en los datos, puedes perder correo, OneDrive, evidencias o automatizaciones. Si tardas demasiado en bloquear acceso, dejas abierta una ventana de riesgo.

5.1 Tipos de baja

• Baja planificada: jubilación, fin de contrato, salida acordada. Permite preparar transferencia de conocimiento y datos.
• Baja inmediata: despido, incidente, riesgo de seguridad. Requiere bloquear acceso de forma prioritaria.
• Ausencia prolongada: baja médica, excedencia o suspensión temporal. No siempre implica eliminar cuenta.
• Proveedor o externo: requiere retirar acceso a equipos, sitios, apps y posiblemente eliminar invitado.

5.2 Orden recomendado de baja

1. Confirmar la baja: RRHH o responsable autorizado envía solicitud formal.
2. Clasificar riesgo: normal, sensible, inmediato, legal/compliance.
3. Bloquear inicio de sesión: impedir que el usuario acceda a Microsoft 365.
4. Revocar sesiones: cortar tokens y sesiones activas para reducir acceso persistente.
5. Cambiar contraseña: evitar que credenciales conocidas vuelvan a utilizarse.
6. Proteger correo y OneDrive: decidir reenvío, shared mailbox, delegación o retención.
7. Reasignar propietarios: Teams, SharePoint, grupos, flujos, apps y buzones compartidos.
8. Retirar grupos y aplicaciones: eliminar accesos que ya no corresponden.
9. Gestionar dispositivos: retirar, borrar, bloquear o reasignar según tipo.
10. Recuperar licencias: solo cuando datos y cumplimiento estén resueltos.
11. Guardar evidencia: auditoría, ticket, aprobaciones y acciones realizadas.

6. Exchange Online: buzón, reenvío, respuesta automática y shared mailbox

En la práctica: el buzón suele contener información crítica: clientes, contratos, conversaciones y decisiones.

En una baja, el correo es una de las piezas más sensibles. No basta con bloquear la cuenta. Hay que decidir qué ocurre con los mensajes nuevos y con el histórico.

Opciones habituales

• Convertir el buzón en shared mailbox: útil cuando varias personas necesitan consultar el histórico.
• Dar acceso delegado al manager: permite revisar correo sin compartir credenciales.
• Configurar reenvío: para nuevos correos entrantes, si negocio lo necesita.
• Respuesta automática: informa de que la persona ya no está y redirige al contacto correcto.
• Inactive mailbox o retención: si hay requisitos legales o de auditoría.

Qué evitar

• No compartir la contraseña del exempleado.
• No quitar licencia sin revisar conservación de correo.
• No dejar reenvíos permanentes sin revisión.
• No depender de una cuenta personal para procesos de negocio.

Connect-MgGraph -Scopes "User.ReadWrite.All","Directory.AccessAsUser.All"

# Bloquear inicio de sesión
Update-MgUser -UserId "usuario@empresa.com" -AccountEnabled:$false

# Revocar sesiones activas
Revoke-MgUserSignInSession -UserId "usuario@empresa.com"

Recomendación: adapta scripts a tu entorno, roles administrativos y proceso de aprobación.

7. OneDrive y SharePoint: conservar datos sin dejar accesos abiertos

En la práctica: OneDrive puede contener información de negocio aunque parezca “personal”.

Cuando un empleado sale, sus archivos pueden estar repartidos entre OneDrive, bibliotecas de SharePoint, carpetas sincronizadas, equipos de Teams y enlaces compartidos. La baja debe revisar todo esto antes de eliminar la cuenta o retirar licencias de forma definitiva.

OneDrive del exempleado

• Asignar acceso temporal al manager o responsable designado.
• Identificar documentos de negocio y moverlos a SharePoint cuando corresponda.
• Revisar enlaces compartidos externamente.
• Aplicar retención si hay requisitos legales o contractuales.

SharePoint y sitios de equipo

• Revisar si el empleado era propietario de sitios.
• Asignar nuevos propietarios antes de cerrar la cuenta.
• Eliminar permisos directos o únicos que ya no correspondan.
• Revisar bibliotecas sensibles y enlaces externos.

Lecturas relacionadas de MSAdvance: SharePoint como gestor documental · Automatización documental con SharePoint y Power Automate.

8. Microsoft Teams: propietarios, canales, archivos y reuniones

En la práctica: si un empleado era owner de Teams, su baja puede dejar equipos sin responsable.

Microsoft Teams no es solo chat. Detrás hay grupos de Microsoft 365, sitios de SharePoint, archivos, canales, reuniones, grabaciones, Planner, pestañas y aplicaciones. Por eso, una baja debe revisar:

• Equipos donde el usuario era propietario.
• Canales privados o compartidos con permisos específicos.
• Archivos publicados en canales.
• Reuniones recurrentes organizadas por el usuario.
• Grabaciones asociadas a reuniones.
• Aplicaciones o pestañas configuradas por el usuario.

Acciones recomendadas

1. Asignar nuevo propietario a equipos y grupos.
2. Revisar canales privados y compartidos.
3. Transferir o recrear reuniones recurrentes si son críticas.
4. Revisar archivos y grabaciones con información sensible.
5. Eliminar acceso de invitado si se trata de un externo.

Recurso relacionado: Consultoría Microsoft Teams.

9. Dispositivos e Intune: retirar, borrar o reasignar equipos

En la práctica: la identidad bloqueada no siempre basta si quedan sesiones, datos o dispositivos activos.

Los dispositivos son parte clave del offboarding. No es lo mismo un portátil corporativo que un móvil personal con acceso a Outlook y Teams.

Decisiones según tipo de dispositivo

Qué revisar en Intune

• Dispositivos asociados al usuario.
• Estado de cumplimiento.
• Aplicaciones corporativas instaladas.
• Perfiles Wi-Fi, VPN, certificados y acceso a recursos internos.
• BitLocker, claves de recuperación y reprovisionamiento.

10. Aplicaciones, Power Platform y cuentas de servicio

En la práctica: muchas bajas rompen procesos porque un flujo, app o conector dependía de una cuenta personal.

En entornos Microsoft 365, los empleados pueden ser propietarios de:

• Flujos de Power Automate.
• Power Apps internas.
• Conexiones a SharePoint, Exchange, Dataverse, SQL o APIs.
• Informes y modelos de Power BI.
• App registrations y secretos en Entra ID.
• Automatizaciones con cuentas personales.

Acciones recomendadas

1. Inventariar flujos, apps y conexiones del usuario.
2. Cambiar propietario a una cuenta de servicio o equipo responsable.
3. Reautenticar conectores críticos.
4. Revisar secretos, certificados y permisos de aplicaciones.
5. Documentar el cambio para futuras auditorías.

11. Seguridad: MFA, Acceso Condicional, sesiones y roles privilegiados

En la práctica: la baja segura empieza bloqueando acceso y revocando sesiones activas.

El offboarding debe actuar sobre la identidad de forma inmediata, especialmente si la salida tiene riesgo. No basta con “quitar la licencia”. Una cuenta sin licencia, pero todavía habilitada en ciertos contextos, puede seguir siendo un problema.

Controles clave

• Bloquear inicio de sesión en Microsoft Entra ID.
• Revocar sesiones para cortar tokens activos.
• Cambiar contraseña si la cuenta no se elimina inmediatamente.
• Retirar métodos MFA o registrar el estado de autenticación si aplica.
• Eliminar roles administrativos y revisar PIM si se usa.
• Revisar aplicaciones empresariales y permisos OAuth concedidos.

Cuentas privilegiadas

Si el usuario tenía roles de administración, acceso a Azure, seguridad, facturación o datos sensibles, la baja debe tratarse como caso sensible. Conviene revisar:

• Roles en Entra ID.
• Roles en Microsoft 365 admin center, Exchange, SharePoint, Teams, Intune y Purview.
• Acceso a suscripciones de Azure.
• Credenciales almacenadas, certificados y secretos.
• Actividad reciente y cambios administrativos.

Recurso relacionado: Conditional Access en Microsoft Entra: políticas base · MFA en Microsoft Entra ID.

12. Cumplimiento: retención, eDiscovery, auditoría y evidencias

En la práctica: no todo dato debe conservarse para siempre, pero lo que se debe conservar tiene que estar protegido.

En una baja, hay que decidir qué datos se conservan, quién puede acceder y durante cuánto tiempo. Esta decisión no debería tomarla IT en solitario: deben intervenir legal, compliance, seguridad o el responsable de negocio cuando corresponda.

Preguntas de cumplimiento

• ¿Existe obligación legal de conservar correo o documentos?
• ¿Hay litigio, investigación o auditoría abierta?
• ¿El usuario manejaba información sensible, financiera, sanitaria, contractual o confidencial?
• ¿Se debe aplicar retención o eDiscovery?
• ¿Qué evidencias se guardan del proceso de baja?

Evidencias mínimas recomendadas

• Solicitud formal de baja.
• Hora de bloqueo de cuenta.
• Revocación de sesiones.
• Acciones sobre buzón, OneDrive, Teams y SharePoint.
• Dispositivos retirados o borrados.
• Licencias recuperadas.
• Aprobación de legal/compliance si aplica.

Si tu organización necesita auditoría, retención, DLP o eDiscovery, consulta: Servicio de Seguridad & Cumplimiento Microsoft 365.

13. Automatización con Microsoft Entra ID Governance y Lifecycle Workflows

En la práctica: automatizar altas y bajas reduce errores, pero solo si el diseño de roles y grupos está claro.

Microsoft Entra ID Governance permite automatizar tareas del ciclo de vida mediante Lifecycle Workflows. Estos flujos pueden ayudar a ejecutar acciones de alta, cambio y baja basadas en atributos como fecha de incorporación, manager, departamento o tipo de usuario.

Qué puede automatizarse

• Enviar correos de bienvenida.
• Añadir usuarios a grupos.
• Asignar tareas al manager.
• Retirar usuarios de grupos en la baja.
• Ejecutar acciones de preparación para offboarding.
• Revisar flujos e informes de ejecución.

Automatización realista

No todo tiene que estar automatizado desde el primer día. Un enfoque sano es empezar por:

1. Alta estándar con grupos y licencias.
2. Baja estándar con bloqueo, revocación y retirada de grupos.
3. Revisión de managers y propietarios.
4. Casos sensibles con aprobación humana.

14. Licencias y costes: cómo recuperar licencias sin perder información

En la práctica: retirar licencias ahorra costes, pero hacerlo antes de tiempo puede provocar pérdida de datos.

Muchas empresas quieren recuperar licencias rápidamente cuando una persona sale. Es lógico, pero hay que hacerlo en el orden correcto. Antes de retirar licencias, revisa si hay que conservar buzón, OneDrive, Teams, datos de cumplimiento o acceso temporal delegado.

Buenas prácticas

• Usar licencias basadas en grupos para altas y bajas.
• No retirar licencia hasta decidir qué ocurre con correo y OneDrive.
• Convertir buzón a shared mailbox cuando aplique.
• Aplicar retención si hay obligación legal.
• Revisar licencias de Power BI, Power Apps, Visio, Project, Defender, Teams Phone u otros add-ons.

MSAdvance también puede ayudarte a revisar licenciamiento: Suministro y venta de licencias para empresas.

15. Checklists operativos de alta, cambio y baja

En la práctica: un checklist reduce errores y permite demostrar que el proceso se ejecutó correctamente.

15.1 Checklist de alta de empleado

• Solicitud aprobada por RRHH y manager.
• Usuario creado o sincronizado en Microsoft Entra ID.
• Atributos completos: departamento, cargo, manager, ubicación.
• Licencia asignada por grupo.
• MFA y métodos de seguridad configurados.
• Grupos, Teams y SharePoint asignados por rol.
• Dispositivo preparado en Intune si aplica.
• Aplicaciones empresariales asignadas.
• Guía de bienvenida y buenas prácticas enviada.

15.2 Checklist de cambio de puesto

• Nuevo manager y departamento actualizados.
• Nuevos grupos y apps asignados.
• Accesos anteriores revisados y retirados.
• Licencias ajustadas.
• Acceso a datos sensibles revisado.
• Manager confirma que el usuario puede trabajar con normalidad.

15.3 Checklist de baja de empleado

• Solicitud formal recibida.
• Cuenta bloqueada.
• Sesiones revocadas.
• Contraseña cambiada.
• Buzón convertido/delegado/retenido según caso.
• OneDrive revisado y acceso delegado al responsable.
• Propiedad de Teams, SharePoint, grupos y flujos reasignada.
• Dispositivos retirados, borrados o reasignados.
• Grupos y aplicaciones retirados.
• Licencias recuperadas tras proteger datos.
• Evidencias guardadas en ticket o sistema de auditoría.

16. KPIs y controles de calidad

En la práctica: si no se mide, el proceso acaba dependiendo de memoria y buena voluntad.

17. Riesgos frecuentes y mitigaciones

En la práctica: los riesgos más graves suelen venir de pasos pequeños que nadie revisó.

18. Scripts y snippets útiles

En la práctica: los scripts ayudan, pero deben integrarse en un proceso con aprobaciones y evidencias.

Connect-MgGraph -Scopes "User.ReadWrite.All"

$user = "usuario@empresa.com"

Update-MgUser -UserId $user -AccountEnabled:$false
Revoke-MgUserSignInSession -UserId $user

Connect-ExchangeOnline

Set-Mailbox -Identity "usuario@empresa.com" -Type Shared

Set-MailboxAutoReplyConfiguration -Identity "usuario@empresa.com" `
  -AutoReplyState Enabled `
  -InternalMessage "Esta persona ya no forma parte de la organización. Contacta con soporte@empresa.com." `
  -ExternalMessage "Esta persona ya no forma parte de la organización. Contacta con soporte@empresa.com."

{
  "usuario": "usuario@empresa.com",
  "tipoBaja": "normal",
  "acciones": {
    "bloquearInicioSesion": true,
    "revocarSesiones": true,
    "revisarBuzon": true,
    "delegarOneDrive": true,
    "reasignarTeamsSharePoint": true,
    "retirarDispositivos": true,
    "recuperarLicencias": "despues_de_conservar_datos"
  }
}

Estos ejemplos son orientativos. Deben probarse en entorno controlado y adaptarse a permisos, roles y políticas internas.

19. Preguntas frecuentes sobre alta y baja de empleados en Microsoft 365

20. Recursos oficiales y enlaces externos

• Microsoft Learn — Add users and assign licenses in Microsoft 365
• Microsoft Learn — Remove a former employee and secure data
• Microsoft Learn — Give another employee access to OneDrive and Outlook data
• Microsoft Learn — Convert a user mailbox to a shared mailbox
• Microsoft Learn — OneDrive retention and deletion
• Microsoft Learn — What are Lifecycle Workflows?
• Microsoft Learn — Lifecycle Workflow tasks
• Microsoft Learn — Plan access reviews
• Microsoft Learn — Retention settings in Microsoft Purview
• Microsoft Learn — Group-based licensing in Microsoft Entra ID

Recursos internos de MSAdvance

• Seguridad & Cumplimiento Microsoft 365
• Modern Workplace Microsoft 365
• Conditional Access en Microsoft Entra
• Autenticación multifactor en Microsoft Entra ID
• Auditar y monitorizar usuarios en Entra ID
• Todos los servicios

21. Conclusión y siguientes pasos

Un buen proceso de alta y baja de empleados en Microsoft 365 no se limita a crear o eliminar usuarios. Debe proteger identidad, datos, correo, OneDrive, SharePoint, Teams, dispositivos, aplicaciones y evidencias de auditoría.

Si la organización quiere reducir riesgo, mejorar productividad y evitar pérdidas de información, los siguientes pasos suelen ser:

• Documentar el proceso joiner-mover-leaver actual.
• Revisar grupos, licencias y permisos heredados.
• Definir checklists de alta, cambio y baja.
• Automatizar lo repetible con Microsoft Entra ID y grupos.
• Medir tiempos de alta, bloqueo, retirada de accesos y licencias recuperadas.