Checklist de offboarding TI 2026: accesos a apps olvidados, permisos OAuth y claves API (plantilla gratuita)

Cuando alguien se va, la checklist de RR. HH. cubre el portátil, la tarjeta de acceso y la última nómina. TI desactiva la cuenta de correo y da el tema por cerrado. Lo que suele sobrevivir es todo lo que nunca fue una contraseña: el permiso OAuth que una persona aprobó para una herramienta de informes, la clave API pegada en un script, el token de acceso personal en un pipeline de CI, la automatización de Zapier que se ejecuta a su nombre y las contraseñas de administración compartidas que leyó cien veces.

Esta checklist se centra en esa capa olvidada. Puedes descargar la plantilla y usarla tal cual en cada salida.

La respuesta corta

Una checklist de offboarding TI completa tiene tres capas: la identidad (cuenta SSO, sesiones, MFA), los accesos delegados (permisos OAuth, claves API, tokens, integraciones) y los secretos compartidos (contraseñas que la persona podía ver). La mayoría de los equipos solo gestionan la primera. La segunda y la tercera son las que permiten a antiguos empleados, o a atacantes que robaron sus credenciales, conservar el acceso durante meses.

Por qué "desactivar la cuenta" no basta: el caso ConnectWise de octubre de 2026

El 16 de octubre de 2026, ConnectWise publicó un aviso sobre accesos no autorizados a identidades de aplicación conectadas a su servicio Cloud Backup (antes SkyKick). La empresa desactivó siete identidades de aplicación a las 07:00 UTC del 17 de octubre y revocó los certificados de las conexiones afectadas. Aun así, su propio aviso advertía de que "previously issued access tokens may remain usable until they expire or are otherwise invalidated" (los tokens de acceso emitidos previamente pueden seguir siendo utilizables hasta que caduquen o se invaliden de otro modo).

Esa frase resume todo el problema del offboarding en una línea. Cerrar la puerta principal no recupera las llaves que ya se repartieron. Las acciones que ConnectWise recomienda a sus clientes parecen una checklist de offboarding: revisar las "application credentials and federation trusts" (credenciales de aplicación y relaciones de confianza de federación), los "consent grants" (consentimientos otorgados) y los "recent policy changes" (cambios recientes de directivas), buscar "unauthorized mailbox forwarding and inbox rules" (reenvíos de buzón y reglas de bandeja de entrada no autorizados), revisar los "sign-ins" (inicios de sesión) desde el comienzo del periodo del incidente y "do not delete the application as the first response" (no eliminar la aplicación como primera respuesta), para conservar la configuración y las pruebas.

Un empleado que se marcha es la misma situación a menor escala: una identidad, con accesos delegados repartidos entre herramientas que quizá ni conoces. (Avisos de confianza de ConnectWise, consultados el 18 de octubre de 2026.)

Descarga la plantilla gratuita

La plantilla es un archivo CSV que se abre directamente en Excel, Google Sheets, LibreOffice o Numbers. Cada fila es una acción, con la fase, un responsable, un plazo relativo al último día, cómo verificarla y columnas para marcarla y fecharla.

Descargar la plantilla de checklist de offboarding TI (CSV)

Cómo usarla: duplica el archivo para cada salida, borra las filas de las herramientas que no uses, añade una fila por cada herramienta de tu inventario de apps y guarda el archivo completado junto al expediente de RR. HH. Una checklist completada y fechada es también lo que te pedirá un auditor.

La checklist, fase por fase

Antes del último día: crear el inventario

No puedes revocar lo que no has listado. Empieza en cuanto se conozca la salida.

• Lista todas las apps que usa la persona. Tu portal SSO muestra las apps conectadas al proveedor de identidad. Añade las herramientas fuera del SSO: facturación, cuentas de redes sociales, registrador de dominios, portales de proveedores y cualquier cosa contratada con un correo del trabajo.
• Lista lo que posee, no solo lo que usa. Unidades y archivos compartidos, automatizaciones (Zapier, Make, Power Automate), scripts programados, bots, webhooks, registros DNS y de dominio, recursos en la nube. La propiedad es lo que se rompe cuando se elimina la cuenta.
• Lista los secretos que conoce. Cada contraseña compartida, clave wifi, código de alarma o de puerta y cuenta de emergencia a la que tenía acceso.
• Identifica los derechos de administrador. La salida de un administrador es otro nivel de riesgo: puede haber creado claves API, registros de aplicaciones o cuentas de servicio que nadie más conoce.

El último día: cerrar la identidad

• Desactiva (suspende) la cuenta SSO o de directorio a la hora acordada, en lugar de eliminarla.
• Revoca las sesiones activas. En Microsoft Entra ID, la página del usuario tiene una acción "Revoke sessions"; en Google Workspace, la página del usuario en la consola de administración permite cerrar sus sesiones activas. Desactivar la cuenta no siempre termina una sesión que ya está abierta.
• Elimina los métodos MFA y las passkeys registrados y restablece la contraseña, para que una contraseña en caché no pueda reutilizarse si la cuenta se reactiva algún día.
• Retira a la persona de los grupos y listas de distribución, de la VPN y del acceso remoto, y de la gestión de dispositivos móviles (MDM) para poder borrar los datos de la empresa de sus teléfonos personales.
• Recupera los dispositivos y las llaves de seguridad físicas.

Aplicaciones y permisos OAuth: los accesos delegados

OAuth es la forma en que un usuario permite que una app actúe en otra ("Permitir que esta herramienta lea tu Google Drive"). Esos permisos no son contraseñas, así que restablecer la contraseña no los afecta necesariamente. Revócalos de forma explícita.

• Google Workspace: en la página del usuario de la consola de administración, la sección de seguridad lista las aplicaciones conectadas con el acceso concedido a cada una. Elimínalas. La vista de todo el dominio está en Seguridad, controles de API.
• Microsoft 365 / Entra ID: revisa en "Enterprise applications" los consentimientos que concedió el usuario, y en "App registrations" cualquier aplicación de la que sea propietario. Un registro de aplicación propiedad de alguien que se ha ido suele contener un secreto de cliente que aún podría usar.
• Slack, Teams, Notion y herramientas similares: revisa las apps, bots y webhooks que instaló la persona, y reasigna o reinstala los que conserves con una cuenta propiedad del equipo.
• Buzón de correo: revisa las reglas de reenvío, las reglas de la bandeja de entrada y los accesos delegados. Una regla de reenvío a una dirección personal es una de las formas más habituales de que los datos sigan saliendo tras una salida.

Claves API, tokens y claves SSH

Son las credenciales que más tiempo sobreviven, porque están diseñadas para funcionar sin que nadie inicie sesión.

• Proveedores cloud: en AWS IAM, lista las claves de acceso del usuario, desactívalas, comprueba que nada se rompe y luego elimínalas. El informe de credenciales de IAM muestra cuándo se usó cada clave por última vez. Aplica la misma lógica a las claves de cuentas de servicio en otros proveedores.
• GitHub y GitLab: retira a la persona de la organización y revisa las deploy keys y los secretos de CI de los repositorios que mantenía. Las deploy keys y los secretos de repositorio pertenecen al repositorio, no a la persona, así que siguen siendo válidos después de retirarla.
• Claves API de SaaS: muchas herramientas (pagos, envío de correo, analítica, CRM) permiten a los usuarios crear claves API en su configuración. Localiza las que creó la persona que se va, rótalas y vuelve a crearlas con una cuenta de servicio.
• Secretos que la persona conocía: cualquier clave, token o cadena de conexión que pudiera leer en un archivo de configuración, un ticket o un mensaje de chat debe rotarse, aunque técnicamente sea propiedad de la empresa.

Contraseñas compartidas y la bóveda de contraseñas

Es la capa que nadie puede revocar: puedes retirar a alguien de una bóveda compartida, pero no de su memoria ni de una exportación que haya hecho.

• Retira a la persona de las bóvedas y colecciones compartidas de tu gestor de contraseñas y transfiere la propiedad de los elementos que creó.
• Rota las credenciales compartidas que podía leer, empezando por las más sensibles: consolas de administración, finanzas y banca, dominio y DNS, cuentas de redes sociales, cuentas de emergencia.
• Usa los registros de actividad para acotar la lista. Si tu gestor de contraseñas registra qué elementos abrió cada miembro, rotas lo que realmente vio en lugar de todas las contraseñas compartidas. Sin registros, da por hecho que vio todo aquello a lo que tenía acceso. Nuestra guía para compartir contraseñas de forma segura explica por qué el chat y el correo son los peores lugares para estos secretos.

Después de la salida: la revisión de 30 días

• Revisa los registros de inicio de sesión de la cuenta desactivada y de las cuentas compartidas durante al menos 30 días. Un inicio de sesión correcto después del último día es una señal de alarma.
• Comprueba que las integraciones siguen funcionando tras rotar las claves: mejor descubrir una sincronización nocturna rota el día 2 que el día 30.
• Elimina la cuenta solo cuando se hayan confirmado las transferencias de propiedad y haya pasado tu periodo de retención.
• Actualiza el inventario con todo lo que hayas descubierto durante esta salida, para que la siguiente sea más rápida.

Dónde mirar: accesos olvidados por plataforma

Errores frecuentes

• Eliminar la cuenta el primer día. Los archivos, flujos e integraciones de la cuenta pueden desaparecer o detenerse con ella, y los registros que necesitas también se pierden. Suspende primero.
• Considerar que restablecer la contraseña es el final. En muchas herramientas, los permisos OAuth, las claves API y los tokens personales no dependen de la contraseña.
• Olvidar las herramientas fuera del SSO. Las redes sociales, el registrador de dominios y las pequeñas herramientas SaaS contratadas con una tarjeta de crédito casi nunca están en el proveedor de identidad.
• No rotar nada porque "confiamos en esa persona". El offboarding no es una cuestión de confianza: los dispositivos y cuentas personales del antiguo empleado pueden verse comprometidos más adelante, y cada secreto que aún conoce pasa a ser del atacante.
• Ningún responsable de la checklist. RR. HH., TI y el responsable directo creen que otro lo ha hecho. Pon un nombre en cada fila.

Elegir herramientas que agilizan el offboarding

El offboarding más rápido es aquel en el que los accesos estaban centralizados desde el principio: apps detrás del SSO, aprovisionamiento mediante SCIM para que desactivar la identidad retire al usuario de todas partes, y credenciales compartidas guardadas en un gestor de contraseñas para empresas en lugar de en una hoja de cálculo o en el historial del chat. Si estás comparando opciones, nuestra guía del mejor gestor de contraseñas para empresas cubre las funciones de administración y los precios, y la guía de aprovisionamiento SCIM de Bitwarden muestra cómo es el desaprovisionamiento automatizado en la práctica. Para la capa de identidad en sí, consulta qué es el inicio de sesión único y dónde se queda corto.