Cybersecurity

Hace unos años, el consejo estándar era simple: evalúe a sus proveedores, firme un NDA, realice un cuestionario anual. Entonces ocurrió SolarWinds, luego MOVEit, luego XZ Utils — una puerta trasera plantada durante dos años de contribuciones legítimas a código abierto, detectada por un ingeniero que notó un proceso ejecutándose 500ms más lento de lo debido. Todos esos ataques entraron a través de una relación de confianza.

El patrón se mantiene en cada incidente importante. La participación de terceros ahora representa el 48% de todas las filtraciones de datos (frente al 30% del año anterior) según el DBIR 2026 de Verizon, y el compromiso promedio de la cadena de suministro cuesta 4,91 millones de dólares y tarda 267 días en contenerse, según el informe Cost of a Data Breach 2025 de IBM. 

La mayoría de las organizaciones todavía responden con cuestionarios y auditorías anuales. Estos tienen su lugar. Pero un cuestionario no detiene una filtración. Revocar los privilegios permanentes de un proveedor sí lo hace. Esta guía trata la seguridad de la cadena de suministro como lo que realmente es: un problema de IAM y control de credenciales, con una capa de cumplimiento normativo encima.

Puntos clave

• La participación de terceros ahora representa el 48% de todas las filtraciones de datos — frente al 30% del año anterior, según el DBIR 2026 de Verizon. Los ataques a la cadena de suministro son el vector de filtración dominante.
• El compromiso promedio de la cadena de suministro cuesta 4,91 millones de dólares y tarda 267 días en contenerse. Ese tiempo de permanencia es lo que hace tan peligrosos los privilegios permanentes de los proveedores — los atacantes no necesitan moverse rápido si las credenciales nunca expiran.
• Todos los incidentes importantes de cadena de suministro entraron a través de una relación de confianza. SolarWinds, MOVEit, XZ Utils — en cada caso, el atacante utilizó acceso que ya estaba aprovisionado y ya era de confianza.
• Los cuestionarios y las auditorías anuales no detienen las filtraciones. Revocar los privilegios permanentes de los proveedores sí lo hace. Los controles que importan son técnicos: almacenamiento de credenciales en bóvedas, acceso JIT, RBAC limitado al alcance del compromiso y MFA resistente al phishing.
• NIS2, DORA y la Ley de Ciberresiliencia de la UE convierten la seguridad de la cadena de suministro en una obligación legal. El artículo 21 de NIS2, los artículos 28-30 de DORA y los requisitos de la CRA se aplican en un calendario escalonado hasta 2027.
• El 70% de los 50 principales proveedores compartidos por las empresas del Global 2000 tienen al menos una vulnerabilidad KEV sin parchear, según el informe Third-Party Breach Report 2026 de Black Kite.

¿Qué es la gestión de riesgos de la cadena de suministro cibernética (C-SCRM)?

La gestión de riesgos de la cadena de suministro cibernética (C-SCRM) es la disciplina de identificar, evaluar y mitigar los riesgos de ciberseguridad que se originan en la red extendida de proveedores, vendedores, prestadores de servicios y dependencias de software de una organización. Abarca todo, desde las herramientas SaaS que usan los desarrolladores hasta el proveedor de servicios gestionados (MSP) con acceso de administrador a su entorno de producción.

C-SCRM se sitúa en la intersección de adquisiciones, seguridad de TI y cumplimiento normativo. NIST SP 800-161 Rev. 1 proporciona el marco federal más detallado para ello, definiendo C-SCRM como un proceso estructurado para gestionar la exposición a riesgos de ciberseguridad a lo largo del ciclo de vida de la cadena de suministro — desde la selección inicial del proveedor hasta la terminación del contrato y la revocación del acceso.

El alcance es más amplio de lo que la mayoría de los equipos imaginan. Su cadena de suministro incluye:

• Proveedores de software y dependencias de código abierto
• Infraestructura en la nube y proveedores SaaS
• Proveedores de servicios gestionados y soporte de TI
• Fabricantes de hardware y proveedores de firmware
• Empresas de servicios profesionales con acceso a la red o los datos

Cada uno de estos es un punto de entrada potencial. Los incidentes de SolarWinds, MOVEit y XZ Utils explotaron ese punto de entrada de diferentes maneras.

El estado de los ataques a la cadena de suministro en 2025–2026

Los ataques a la cadena de suministro alcanzaron niveles récord en 2025–2026. El DBIR 2026 de Verizon registró la participación de terceros en el 48% de todas las filtraciones analizadas — el más alto en la historia del informe y un aumento del 60% respecto al 30% del año anterior. El informe Cost of a Data Breach 2025 de IBM sitúa el compromiso promedio de la cadena de suministro en 4,91 millones de dólares, con un ciclo de vida promedio de 267 días desde la detección hasta la contención.

Los actores de amenazas han aprendido que comprometer a un proveedor de confianza proporciona acceso a docenas o cientos de organizaciones posteriores simultáneamente. La economía favorece al atacante: una intrusión exitosa, multiplicada por toda la base de clientes de un proveedor.

Según el informe Third-Party Breach Report 2026 de Black Kite, el 70% de los 50 principales proveedores compartidos por las empresas del Global 2000 tienen al menos una vulnerabilidad sin parchear del catálogo de Vulnerabilidades Explotadas Conocidas (KEV) de CISA. Estos no son riesgos teóricos — CISA marca las entradas KEV específicamente porque están siendo explotadas activamente.

Lecciones de SolarWinds, MOVEit y XZ Utils

Los tres incidentes comparten un hilo común: el vector de acceso inicial era de confianza. Software de confianza, proveedor de confianza, colaborador de confianza. Una vez dentro, el atacante se movió lateralmente utilizando credenciales y acceso que ya estaban aprovisionados.

SolarWinds (2020)

Los atacantes comprometieron directamente el pipeline de compilación, insertando una puerta trasera en una actualización de software firmada que se distribuyó a los clientes como un parche rutinario. Aproximadamente 18.000 organizaciones la instalaron. Las consecuencias legales se prolongaron durante años: la SEC presentó una acción de cumplimiento civil contra SolarWinds y su CISO en octubre de 2023, y el caso finalmente se desestimó por completo en 2025.

La lección: los controles de integridad del software y la visibilidad del SBOM (Software Bill of Materials) importan tanto como los controles del perímetro de red — y la exposición a responsabilidad por un compromiso del pipeline de compilación se extiende mucho más allá de la filtración inicial.

MOVEit (2023)

Una vulnerabilidad de inyección SQL de día cero (CVE-2023-34362) en un producto de transferencia de archivos gestionada dio al grupo de ransomware Cl0p acceso a datos de más de 2.700 organizaciones — muchas de las cuales no tenían relación directa con MOVEit pero se vieron afectadas por el uso que sus proveedores hacían de él. El recuento final de víctimas alcanzó aproximadamente 95 millones de personas. 

La lección: su superficie de ataque incluye el software que ejecutan sus proveedores, no solo el software que ejecuta usted.

XZ Utils (2024)

Una campaña de ingeniería social de varios años insertó una puerta trasera en una biblioteca de compresión de código abierto ampliamente utilizada. El atacante contribuyó código legítimo durante dos años antes de introducir la carga maliciosa — y la puerta trasera fue detectada no por ningún proceso de seguridad formal, sino por un ingeniero de Microsoft que notó un retraso de 500ms en los inicios de sesión SSH. 

La lección: el riesgo de dependencias de código abierto es real, los SBOMs son la única forma sistemática de rastrearlo, y sus controles de detección necesitan cubrir el comportamiento, no solo las firmas.

Principales riesgos de proveedores en la cadena de suministro moderna

Las cinco categorías de riesgo de cadena de suministro más comunes son:

• Credenciales compartidas y control de acceso deficiente
• Vulnerabilidades en dependencias de software
• Manipulación de hardware y componentes
• Shadow AI y exposición de datos de terceros
• Riesgo de concentración de proveedores

Cada una requiere una respuesta de control distinta. Los fallos de credenciales compartidas son un problema de proceso. La manipulación de hardware requiere verificación de procedencia física.

Credenciales compartidas y control de acceso deficiente

El riesgo de cadena de suministro más común y más prevenible es también el menos glamuroso: cuentas compartidas. Un equipo de soporte de proveedor obtiene un único conjunto de credenciales para acceder a su entorno. Esas credenciales se comparten entre el personal del proveedor, se almacenan en una hoja de cálculo o hilo de correo electrónico, y nunca se rotan después de que termina el compromiso.

Cuando ese proveedor es vulnerado, o cuando un empleado descontento se va, no hay forma de saber quién usó esas credenciales, cuándo o a qué accedió. No hay rastro de auditoría. No hay forma de revocar el acceso de un individuo sin cambiar las credenciales para todos.

El DBIR 2026 de Verizon identifica los fallos de autenticación (MFA ausente o eludida, credenciales robadas) como el mecanismo principal en los escenarios de filtración de terceros. Este es un fallo de proceso.

Vulnerabilidades en la cadena de suministro de software y la necesidad de SBOMs

Un Software Bill of Materials (SBOM) es un inventario legible por máquina de cada componente en un producto de software: bibliotecas, dependencias, versiones y sus vulnerabilidades conocidas. La Orden Ejecutiva 14028 de EE.UU. (2021) exigió SBOMs para el software vendido a agencias federales. La Ley de Ciberresiliencia (CRA) de la UE extiende requisitos similares a los productos vendidos en el mercado europeo, con obligaciones de notificación de vulnerabilidades aplicables desde septiembre de 2026 y requisitos completos de producto desde diciembre de 2027.

Sin un SBOM, no puede responder «¿Estamos ejecutando la versión vulnerable de Log4j?» en menos de 24 horas. Con uno, sí puede. Esa diferencia de velocidad es la brecha entre un incidente contenido y una filtración que tarda 267 días en cerrarse.

Manipulación de hardware y componentes

El riesgo de la cadena de suministro de hardware es distinto del riesgo de software y a menudo se subestima. Los componentes falsificados o manipulados — equipos de red, hardware de servidor, firmware — pueden introducir puertas traseras persistentes que sobreviven a la reinstalación del sistema operativo y son invisibles para los controles de seguridad de la capa de software.

La Ley de Ciberresiliencia de la UE aborda explícitamente los productos de hardware con elementos digitales, exigiendo a los fabricantes que evalúen y documenten la seguridad de la cadena de suministro para los componentes físicos. Para las organizaciones que adquieren infraestructura de red o sistemas de control industrial, esto significa verificar la procedencia de los componentes, exigir atestación de integridad del firmware a los proveedores y mantener un inventario de versiones de hardware equivalente a un SBOM de software.

Shadow AI y exposición de datos de terceros

El DBIR 2026 de Verizon identifica shadow AI como uno de los tres principales comportamientos internos — empleados que utilizan herramientas de IA no autorizadas que procesan datos organizacionales fuera de los canales aprobados. El ángulo de la cadena de suministro: muchas de estas herramientas son productos SaaS de terceros con sus propias políticas de retención de datos, acuerdos de subprocesadores y posturas de seguridad que su organización nunca revisó.

Cuando un desarrollador pega credenciales de base de datos en un asistente de IA para depurar una consulta, esas credenciales pueden ser retenidas, registradas o utilizadas para el entrenamiento del modelo. El riesgo del proveedor no es solo el proveedor de IA — es cada subprocesador en su cadena.

Interrupciones de disponibilidad y riesgo de concentración de proveedores

Un fallo de seguridad de la cadena de suministro no siempre significa una filtración de datos. Las interrupciones de proveedores, los ataques de ransomware a proveedores críticos y los puntos únicos de fallo en la infraestructura compartida pueden interrumpir las operaciones por completo. El mandato de resiliencia operativa de DORA existe precisamente porque el sector financiero de la UE reconoció que el riesgo de disponibilidad de terceros de TIC es tan material como el riesgo de confidencialidad.

El riesgo de concentración agrava esto: cuando el 70% de las empresas del Forbes Global 2000 comparten los mismos 50 principales proveedores, un único compromiso se propaga a escala. Mapear las dependencias de proveedores críticos y mantener planes de continuidad documentados para fallos de proveedores de Nivel 1 es un requisito del artículo 28 de DORA para las entidades financieras.

Requisitos regulatorios europeos e internacionales para la seguridad de la cadena de suministro

NIS2, DORA y la Ley de Ciberresiliencia de la UE forman juntos el marco regulatorio vinculante para la seguridad de la cadena de suministro en el mercado europeo. NIST CSF 2.0 y SP 800-161 son marcos estadounidenses — no obligaciones legales de la UE — pero son ampliamente referenciados por organizaciones multinacionales y proporcionan detalle operativo que complementa los requisitos de la UE.

Directiva NIS2 (Artículo 21)

El artículo 21 de NIS2 exige a las entidades cubiertas implementar «seguridad de la cadena de suministro, incluidos los aspectos relacionados con la seguridad en las relaciones entre cada entidad y sus proveedores directos o prestadores de servicios». Esta es una obligación legal para las entidades esenciales e importantes en 18 sectores, con una aplicación que los estados miembros de la UE comenzaron a implementar a finales de 2024.

En la práctica, el artículo 21 significa que debe evaluar la postura de seguridad de sus proveedores directos, incluir requisitos de seguridad en los contratos y mantener un proceso documentado para gestionar incidentes relacionados con proveedores. Para la gestión de credenciales específicamente, esto se traduce en: sin cuentas compartidas, procedimientos documentados de aprovisionamiento y revocación de acceso, y registros de auditoría que puedan presentarse durante una revisión de supervisión.

Para un desglose detallado de cómo NIS2 se relaciona con los requisitos de control de acceso, consulte la guía de cumplimiento de NIS2 de Passwork.

DORA (Ley de Resiliencia Operativa Digital)

DORA se aplica a las entidades financieras y sus proveedores de servicios de TIC terceros que operan en la UE. Los artículos 28 a 30 establecen un marco detallado de gestión de riesgos de TIC de terceros, incluyendo requisitos para mantener un registro de todos los proveedores de TIC, realizar evaluaciones de riesgo antes de la incorporación y garantizar que los contratos incluyan disposiciones para derechos de auditoría y notificación de incidentes.

DORA también introduce el concepto de «proveedores de TIC terceros críticos» (CTPPs), que las Autoridades Europeas de Supervisión pueden designar para supervisión directa. Si su organización es un CTPP — o depende de uno — el escrutinio sobre sus controles de seguridad de la cadena de suministro es sustancialmente mayor. El riesgo de interrupción de disponibilidad descrito anteriormente es una preocupación de DORA tanto como de seguridad: el artículo 28 exige explícitamente planes de continuidad documentados para dependencias de terceros críticos.

Ley de Ciberresiliencia de la UE (CRA)

La CRA fue adoptada en 2024 y se aplica en un calendario escalonado. Las obligaciones de notificación de vulnerabilidades e incidentes entran en vigor a partir del 11 de septiembre de 2026. Los requisitos completos de producto — incluyendo mandatos de SBOM y evaluaciones de conformidad para productos con elementos digitales — se aplican a partir del 11 de diciembre de 2027. Las organizaciones que venden hardware o software conectado en el mercado de la UE deben comenzar el trabajo de cumplimiento ahora; el plazo de 2027 llega más rápido de lo que permiten la mayoría de los ciclos de desarrollo de productos.

NIST CSF 2.0 y NIST SP 800-161

NIST CSF 2.0, publicado en febrero de 2024, añadió «Gobernar» como una sexta función central. La subcategoría GV.SC aborda explícitamente la gestión de riesgos de la cadena de suministro, exigiendo a las organizaciones integrar C-SCRM en la gobernanza de riesgos empresariales — no tratarlo como un proyecto de TI separado. Para las organizaciones de la UE, CSF 2.0 no es un requisito legal pero proporciona una estructura operativa útil que se corresponde bien con las obligaciones de NIS2 y DORA.

NIST SP 800-161 Rev. 1 proporciona el detalle operativo: cómo realizar evaluaciones de proveedores, qué controles exigir en los contratos y cómo estructurar un programa C-SCRM a lo largo de todo el ciclo de vida de adquisición. Para los contratistas federales de EE.UU., la alineación con SP 800-161 es cada vez más un requisito de adquisiciones.

Cómo asegurar el acceso de proveedores: El modelo técnico

Los cuatro controles de mayor impacto para la seguridad del acceso de proveedores son RBAC limitado al alcance del compromiso, acceso privilegiado justo a tiempo, almacenamiento centralizado de credenciales en bóveda y MFA resistente al phishing. Aplicados en ese orden, abordan los modos de fallo más comunes — privilegios permanentes, cuentas compartidas y brechas de autenticación — sin requerir nueva infraestructura en la mayoría de los entornos.

Aplique un control de acceso basado en roles (RBAC) estricto

El control de acceso basado en roles (RBAC) asigna permisos a roles, no a individuos. Un ingeniero de soporte del proveedor obtiene el rol de «monitoreo de producción de solo lectura», no una cuenta de administrador personal. Cuando termina el compromiso, se elimina la asignación del rol. Cuando el proveedor rota su personal, no necesita rastrear cuentas individuales — el rol define lo que es accesible.

Para el acceso de proveedores específicamente, RBAC debe estar limitado al mínimo requerido para el compromiso. Un proveedor de base de datos que realiza una auditoría de rendimiento no necesita acceso de escritura a la configuración de la aplicación. Defina el rol antes de aprovisionar el acceso, no después.

Implemente acceso privilegiado justo a tiempo (JIT)

El acceso justo a tiempo (JIT) significa que las credenciales privilegiadas se emiten para una ventana de tiempo definida y se revocan automáticamente cuando esa ventana se cierra. Un ingeniero del proveedor solicita acceso para una ventana de mantenimiento de dos horas; el sistema lo concede, registra la sesión y lo revoca a las dos horas independientemente de si el ingeniero recuerda cerrar sesión.

El acceso JIT elimina los privilegios permanentes: el acceso persistente y siempre activo que los atacantes explotan durante el tiempo de permanencia promedio de 267 días de una filtración de cadena de suministro. No hay nada que robar si las credenciales expiran antes de que el atacante pueda usarlas. JIT es particularmente efectivo para escenarios de emergencia: acceso de proveedor de emergencia durante un incidente, donde la velocidad importa pero también la responsabilidad.

Almacenamiento seguro de credenciales de proveedores en bóveda

Las cuentas de proveedor compartidas son una responsabilidad. La alternativa es una bóveda de credenciales: un almacén centralizado y cifrado donde las credenciales del proveedor son mantenidas por su organización, no por el proveedor. El proveedor se autentica en la bóveda, retira las credenciales para su sesión, y la bóveda registra cada evento de acceso.

Este enfoque le proporciona un rastro de auditoría completo de quién accedió a qué y cuándo, la capacidad de rotar credenciales sin coordinarse con el proveedor, revocación automática cuando termina la relación con el proveedor, y evidencia de cumplimiento para los requisitos de derechos de auditoría del artículo 21 de NIS2 y el artículo 30 de DORA.

El gestor empresarial de contraseñas y secretos de Passwork soporta compartición de credenciales con tiempo limitado, registro de sesiones e integración con infraestructura AD/LDAP y SSO — con cifrado AES-256 del lado del cliente y una REST API completa para integración en flujos de trabajo de aprovisionamiento existentes.

Exija MFA resistente al phishing para terceros

MFA es el control con mayor retorno de inversión para el acceso de terceros. El DBIR 2026 de Verizon atribuye la mayoría de los escenarios de filtración de terceros a fallos de autenticación — y la mayoría de esos fallos son MFA ausente, no MFA eludida.

Para el acceso privilegiado de proveedores a sistemas de producción, el estándar debe ser MFA resistente al phishing: llaves de hardware FIDO2/WebAuthn o passkeys, no OTP por SMS. MFA basada en SMS es vulnerable al intercambio de SIM y proxies de phishing en tiempo real. Exija contractualmente MFA resistente al phishing a los proveedores como condición de acceso. Inclúyalo en su anexo de seguridad del proveedor, no solo en su política interna.

La mayoría de los fallos de control de acceso descritos en esta guía se remontan a la misma causa raíz: credenciales de proveedor que nunca se almacenaron correctamente en bóveda, no se limitaron en alcance o no se revocaron. Passwork aborda eso directamente — almacenamiento centralizado de credenciales en bóveda, acceso basado en roles, compartición con tiempo limitado y un registro de auditoría completo vinculado a identidades nominativas. Disponible autoalojado o como despliegue en la nube, se integra con AD/LDAP y SAML SSO y tiene certificación ISO 27001.

Construyendo un marco de evaluación de riesgos de proveedores

Un marco de evaluación de riesgos de proveedores clasifica a los terceros por nivel de acceso y aplica requisitos de seguridad proporcionales a cada nivel. El modelo de 5 niveles a continuación escala desde proveedores de Nivel 1 con acceso privilegiado a producción, que requieren evaluaciones de seguridad completas y revisiones anuales — hasta proveedores de Nivel 5 sin acceso a datos o sistemas, donde la debida diligencia de adquisiciones estándar es suficiente.

El modelo de clasificación de riesgos de proveedores de 5 niveles:

La clasificación impulsa un esfuerzo proporcional. No necesita un informe de prueba de penetración completo de su proveedor de suministros de oficina. Sí lo necesita del MSP con acceso de administrador a su Active Directory.

Lista de verificación de control de acceso de proveedores

La siguiente lista de verificación de acceso de proveedores previa a la auditoría se corresponde directamente con los requisitos del artículo 21 de NIS2, el artículo 28 de DORA y NIST SP 800-161. Úsela en la incorporación de proveedores y en cada revisión anual.

Antes del aprovisionamiento de acceso:

•  Proveedor clasificado por nivel según el nivel de acceso
•  Alcance de acceso mínimo necesario definido por escrito
•  Individuos identificados por nombre (sin cuentas compartidas/genéricas)
•  Requisito de MFA confirmado y probado
•  Acceso aprovisionado a través de bóveda de credenciales, no compartición directa de credenciales
•  Registro de sesiones habilitado

Durante el compromiso:

•  Alcance de acceso revisado si el alcance del compromiso cambia
•  Patrones de acceso inusuales marcados para revisión
•  Cláusula de notificación de incidentes del proveedor activa en el contrato

Revocación de acceso:

•  Disparador de desvinculación definido (fin de contrato, cambio de personal, incidente)
•  Credenciales rotadas inmediatamente en la desvinculación
•  Acceso a la bóveda revocado y registro de auditoría exportado
•  Revisión de acceso documentada para registros de cumplimiento

Conclusión: Hacer operativa la seguridad de la cadena de suministro

Las organizaciones que gestionan esto bien no tienen menos proveedores; tienen controles más estrictos sobre cómo se autentican esos proveedores, a qué pueden acceder y durante cuánto tiempo.

El modelo técnico es claro: clasifique a los proveedores por nivel de acceso, elimine las cuentas compartidas, almacene las credenciales centralmente en bóveda, aplique acceso JIT para sesiones privilegiadas y exija MFA resistente al phishing. NIS2, DORA y la CRA proporcionan la estructura de gobernanza y el apalancamiento contractual para exigir a los proveedores el mismo estándar.

Comience con sus proveedores de Nivel 1 — los que tienen acceso privilegiado a sistemas de producción. Audite su alcance de acceso actual, confirme la asignación de cuentas individuales y verifique que MFA esté activo. Ese único pase revelará más riesgo accionable que un año de cuestionarios.

Preguntas frecuentes

¿Cuál es la diferencia entre seguridad de la cadena de suministro y gestión de riesgos de proveedores?

La gestión de riesgos de proveedores (VRM) es la disciplina más amplia que cubre riesgos financieros, operacionales, reputacionales y cibernéticos de terceros. La seguridad de la cadena de suministro es el subconjunto específico de ciberseguridad: proteger sistemas, datos e integridad del software de amenazas que entran a través de relaciones con proveedores. VRM informa las decisiones de adquisición; la seguridad de la cadena de suministro gobierna los controles técnicos de acceso y la integridad del software.

¿Qué regulaciones requieren controles de seguridad de la cadena de suministro en 2025–2026?

El artículo 21 de la Directiva NIS2 exige a las entidades esenciales e importantes de la UE evaluar y gestionar los riesgos de seguridad de los proveedores. Los artículos 28–30 de DORA imponen obligaciones de gestión de riesgos de TIC de terceros a las entidades financieras de la UE. La Ley de Ciberresiliencia de la UE exige la notificación de vulnerabilidades desde septiembre de 2026 y requisitos completos de SBOM y conformidad desde diciembre de 2027. En EE.UU., NIST SP 800-161 y la Orden Ejecutiva 14028 establecen expectativas de C-SCRM para contratistas federales.

¿Qué es el acceso justo a tiempo (JIT) y por qué importa para la seguridad de proveedores?

El acceso JIT emite credenciales privilegiadas para una ventana de tiempo definida y las revoca automáticamente cuando esa ventana se cierra. Elimina los privilegios permanentes — acceso persistente que los atacantes explotan durante el tiempo de permanencia extendido típico de las filtraciones de cadena de suministro. Los datos de IBM de 2025 muestran que los compromisos de cadena de suministro tardan en promedio 267 días en identificarse y contenerse; el acceso JIT reduce la ventana explotable a horas, no meses.

¿Cómo reducen los SBOMs el riesgo de la cadena de suministro?

Un Software Bill of Materials (SBOM) es un inventario legible por máquina de todos los componentes de software y sus versiones. Cuando se divulga una nueva vulnerabilidad — como Log4Shell en 2021 — un SBOM le permite determinar en minutos si alguno de sus sistemas o software suministrado por proveedores contiene el componente afectado. Sin un SBOM, esa misma determinación puede llevar días o semanas, durante las cuales la vulnerabilidad permanece sin parchear y explotable.

¿Qué debe incluir un anexo de seguridad del contrato con el proveedor?

Como mínimo: un requisito de cuentas individuales nominativas (sin credenciales compartidas), MFA resistente al phishing para acceso privilegiado, obligaciones de notificación dentro de 24–72 horas de un incidente de seguridad, derechos de auditoría que permitan a su organización revisar los registros de acceso, y un proceso de desvinculación definido que incluya rotación de credenciales. Tanto el artículo 21 de NIS2 como el artículo 30 de DORA requieren disposiciones de seguridad contractuales — el anexo es su evidencia de cumplimiento.

¿Cómo deben las organizaciones clasificar a los proveedores para propósitos de evaluación de riesgos?

Clasifique por nivel de acceso, no por valor del contrato o tamaño del proveedor. Una pequeña consultoría con acceso de administrador a su entorno de producción es de mayor riesgo que un gran proveedor de software sin acceso directo al sistema. El modelo de clasificación de riesgos de proveedores de 5 niveles anterior proporciona una estructura práctica: Nivel 1 (acceso privilegiado a producción) hasta Nivel 5 (sin acceso a datos o sistemas), con requisitos de evaluación y frecuencia de revisión escalados en consecuencia.

¿Cuál es el fallo de control de acceso más común en las filtraciones de terceros?

Credenciales compartidas sin responsabilidad individual. Un único conjunto de credenciales emitido a un equipo de proveedor, almacenado fuera de una bóveda, nunca rotado, y nunca revocado cuando termina el compromiso. El DBIR 2026 de Verizon identifica los fallos de autenticación como el mecanismo principal en escenarios de filtración de terceros. La solución son cuentas individuales nominativas, almacenamiento de credenciales en bóveda y un proceso de desvinculación documentado — no tecnología más compleja.

¿Qué es el riesgo de la cadena de suministro de hardware y cómo se diferencia del riesgo de la cadena de suministro de software?

El riesgo de la cadena de suministro de hardware involucra componentes físicos falsificados o manipulados — equipos de red, hardware de servidor, firmware — que pueden introducir puertas traseras persistentes invisibles para los controles de seguridad de la capa de software. A diferencia de las vulnerabilidades de software, la manipulación de hardware sobrevive a la reinstalación del sistema operativo. La Ley de Ciberresiliencia de la UE aborda esto directamente, exigiendo a los fabricantes documentar la seguridad de la cadena de suministro para productos de hardware con elementos digitales.

Dentro de ataques reales a la cadena de suministro: Bitwarden CLI, Axios y Vercel

¿Por qué vulnerar su red cuando los atacantes pueden comprometer una dependencia de confianza con millones de descargas y deslizarse silenciosamente en miles de organizaciones a la vez? Tres campañas de 2026 demuestran que los ataques a la cadena de suministro ya no son incidentes aislados.

Passwork BlogAlex Muntyan

Shadow IT vs Shadow AI: Por qué la IA es la mayor amenaza

Los empleados están usando herramientas de IA que usted no aprobó, en cuentas que no puede monitorear, con datos que no puede recuperar. Así es como realmente se ve el riesgo y qué debe abordar la gobernanza.

Passwork BlogAlex Muntyan

Controles de acceso NIS2 para seguridad de la cadena de suministro

El 48% de las filtraciones ahora involucran a terceros. El artículo 21 de NIS2 convierte la gobernanza del acceso de proveedores en una obligación legal. Así es cómo mapear el acceso de proveedores, aplicar MFA y privilegio mínimo, y mantener la evidencia de auditoría que demuestra que sus controles funcionan.

Passwork BlogAlex Muntyan

A few years ago, the standard advice was simple: vet your vendors, sign an NDA, run an annual questionnaire. Then SolarWinds happened, then MOVEit, then XZ Utils — a backdoor planted over two years of legitimate open-source contributions, caught by an engineer who noticed a process running 500ms slower than it should. Every one of those attacks entered through a trusted relationship.

The pattern holds across every major incident. Third-party involvement now accounts for 48% of all data breaches (up from 30% the previous year) according to Verizon's 2026 DBIR, and the average supply chain compromise costs $4.91 million and takes 267 days to contain, per IBM's 2025 Cost of a Data Breach Report. 

Most organizations still respond with questionnaires and annual audits. Those have their place. But a questionnaire doesn't stop a breach. Revoking a vendor's standing privileges does. This guide treats supply chain security as what it actually is: an IAM and credential control problem, with a compliance layer on top.

Key takeaways

• Third-party involvement now accounts for 48% of all data breaches — up from 30% the previous year, according to Verizon's 2026 DBIR. Supply chain attacks are the dominant breach vector.
• The average supply chain compromise costs $4.91 million and takes 267 days to contain. That dwell time is what makes standing vendor privileges so dangerous — attackers don't need to move fast if the credentials never expire.
• Every major supply chain incident entered through a trusted relationship. SolarWinds, MOVEit, XZ Utils — in each case, the attacker used access that was already provisioned and already trusted.
• Questionnaires and annual audits don't stop breaches. Revoking standing vendor privileges does. The controls that matter are technical: credential vaulting, JIT access, RBAC scoped to the engagement, and phishing-resistant MFA.
• NIS2, DORA, and the EU Cyber Resilience Act make supply chain security a legal obligation. NIS2 Article 21, DORA Articles 28–30, and CRA requirements apply on a staggered timeline through 2027.
• 70% of the top 50 vendors shared by Global 2000 companies carry at least one unpatched KEV vulnerability, per Black Kite's 2026 Third-Party Breach Report.

What is cyber supply chain risk management (C-SCRM)?

Cyber Supply Chain Risk Management (C-SCRM) is the discipline of identifying, assessing, and mitigating cybersecurity risks that originate from an organization's extended network of suppliers, vendors, service providers, and software dependencies. It covers everything from the SaaS tools your developers use to the managed service provider (MSP) with admin access to your production environment.

C-SCRM sits at the intersection of procurement, IT security, and compliance. NIST SP 800-161 Rev. 1 provides the most detailed federal framework for it, defining C-SCRM as a structured process for managing exposure to cybersecurity risks throughout the supply chain lifecycle — from initial vendor selection through contract termination and access revocation.

The scope is broader than most teams realize. Your supply chain includes:

• Software vendors and open-source dependencies
• Cloud infrastructure and SaaS providers
• Managed service and IT support providers
• Hardware manufacturers and firmware suppliers
• Professional services firms with network or data access

Each of these is a potential entry point. The SolarWinds, MOVEit, and XZ Utils incidents all exploited that entry point in different ways.

The state of supply chain attacks in 2025–2026

Supply chain attacks reached record levels in 2025–2026. Verizon's 2026 DBIR recorded third-party involvement in 48% of all breaches analyzed — the highest in the report's history and a 60% increase over the prior year's 30%. IBM's 2025 Cost of a Data Breach Report puts the average supply chain compromise at $4.91 million, with a 267-day average lifecycle from detection to containment.

Threat actors have learned that compromising one trusted vendor yields access to dozens or hundreds of downstream organizations simultaneously. The economics favor the attacker: one successful intrusion, multiplied across an entire vendor's customer base.

According to Black Kite's 2026 Third-Party Breach Report, 70% of the top 50 vendors shared by Global 2000 companies carry at least one unpatched vulnerability from CISA's Known Exploited Vulnerabilities (KEV) catalog. These aren't theoretical risks — CISA flags KEV entries specifically because they are being actively exploited in the wild.

Lessons from SolarWinds, MOVEit, and XZ Utils

All three incidents share a common thread: the initial access vector was trusted. Trusted software, trusted vendor, trusted contributor. Once inside, the attacker moved laterally using credentials and access that were already provisioned.

SolarWinds (2020)

Attackers compromised the build pipeline directly, inserting a backdoor into a signed software update that went out to customers as a routine patch. Roughly 18,000 organizations installed it. The legal fallout ran for years: the SEC filed a civil enforcement action against SolarWinds and its CISO in October 2023, with the case finally dismissed in full in 2025.

The lesson: software integrity controls and SBOM (Software Bill of Materials) visibility matter as much as network perimeter controls — and the liability exposure from a build pipeline compromise extends well beyond the initial breach.

MOVEit (2023)

A zero-day SQL injection vulnerability (CVE-2023-34362) in a managed file transfer product gave the Cl0p ransomware group access to data held by over 2,700 organizations — many of which had no direct relationship with MOVEit but were affected through their vendors' use of it. Final victim counts reached approximately 95 million individuals. 

The lesson: your attack surface includes software your vendors run, not just software you run.

XZ Utils (2024)

A multi-year social engineering campaign inserted a backdoor into a widely used open-source compression library. The attacker contributed legitimate code for two years before introducing the malicious payload — and the backdoor was caught not by any formal security process, but by a Microsoft engineer who noticed a 500ms delay in SSH logins. 

The lesson: open-source dependency risk is real, SBOMs are the only systematic way to track it, and your detection controls need to cover behavior, not just signatures.

Top vendor risks in the modern supply chain

The five most common supply chain risk categories are:

• Shared credentials and poor access control
• Software dependency vulnerabilities
• Hardware and component tampering
• Shadow AI and third-party data exposure
• Vendor concentration risk

Each requires a distinct control response. Shared credential failures are a process problem. Hardware tampering requires physical provenance verification.

Shared credentials and poor access control

The most common and most preventable supply chain risk is also the least glamorous: shared accounts. A vendor support team gets a single set of credentials to access your environment. Those credentials are shared across the vendor's staff, stored in a spreadsheet or email thread, and never rotated after the engagement ends.

When that vendor is breached, or when a disgruntled employee leaves, you have no way to know who used those credentials, when, or what they accessed. You have no audit trail. You have no way to revoke access for one individual without changing credentials for everyone.

Verizon's 2026 DBIR identifies authentication failures (missing or bypassed MFA, stolen credentials) as the primary mechanism in third-party breach scenarios. This is a process failure.

Software supply chain vulnerabilities and the need for SBOMs

A Software Bill of Materials (SBOM) is a machine-readable inventory of every component in a software product: libraries, dependencies, versions, and their known vulnerabilities. The U.S. Executive Order 14028 (2021) mandated SBOMs for software sold to federal agencies. The EU's Cyber Resilience Act (CRA) extends similar requirements to products sold in the European market, with vulnerability reporting obligations applying from September 2026 and full product requirements from December 2027.

Without an SBOM, you cannot answer "Are we running the vulnerable version of Log4j?" in under 24 hours. With one, you can. That speed difference is the gap between a contained incident and a breach that takes 267 days to close.

Hardware and component tampering

Hardware supply chain risk is distinct from software risk and often underestimated. Counterfeit or tampered components — network equipment, server hardware, firmware — can introduce persistent backdoors that survive OS reinstallation and are invisible to software-layer security controls.

The EU Cyber Resilience Act explicitly addresses hardware products with digital elements, requiring manufacturers to assess and document supply chain security for physical components. For organizations procuring network infrastructure or industrial control systems, this means verifying component provenance, requiring firmware integrity attestation from suppliers, and maintaining an inventory of hardware versions equivalent to a software SBOM.

Shadow AI and third-party data exposure

Verizon's 2026 DBIR identifies shadow AI as a top-three insider behavior — employees using unauthorized AI tools that process organizational data outside approved channels. The supply chain angle: many of these tools are third-party SaaS products with their own data retention policies, subprocessor agreements, and security postures that your organization never reviewed.

When a developer pastes database credentials into an AI assistant to debug a query, those credentials may be retained, logged, or used for model training. The vendor risk is not just the AI provider — it is every subprocessor in their chain.

Availability disruptions and vendor concentration risk

A supply chain security failure does not always mean a data breach. Vendor outages, ransomware attacks on critical suppliers, and single points of failure in shared infrastructure can disrupt operations entirely. DORA's operational resilience mandate exists precisely because the EU financial sector recognized that availability risk from ICT third parties is as material as confidentiality risk.

Concentration risk compounds this: when 70% of Forbes Global 2000 companies share the same top 50 vendors, a single compromise propagates at scale. Mapping your critical vendor dependencies and maintaining documented continuity plans for Tier 1 supplier failures is a DORA Article 28 requirement for financial entities.

European and international regulatory requirements for supply chain security

NIS2, DORA, and the EU Cyber Resilience Act together form the binding regulatory framework for supply chain security in the European market. NIST CSF 2.0 and SP 800-161 are U.S. frameworks — not EU legal obligations — but are widely referenced by multinational organizations and provide operational detail that complements the EU requirements.

NIS2 Directive (Article 21)

NIS2 Article 21 requires covered entities to implement "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." This is a legal obligation for essential and important entities across 18 sectors, with enforcement that EU member states began applying in late 2024.

In practice, Article 21 means you must assess the security posture of your direct vendors, include security requirements in contracts, and maintain a documented process for managing vendor-related incidents. For credential management specifically, this translates to: no shared accounts, documented access provisioning and revocation procedures, and audit logs that can be produced during a supervisory review.

For a detailed breakdown of how NIS2 maps to access control requirements, see Passwork's NIS2 compliance guide.

DORA (Digital Operational Resilience Act)

DORA applies to financial entities and their ICT third-party service providers operating in the EU. Articles 28 through 30 establish a detailed ICT third-party risk management framework, including requirements to maintain a register of all ICT providers, conduct risk assessments before onboarding, and ensure contracts include provisions for audit rights and incident notification.

DORA also introduces the concept of "critical ICT third-party providers" (CTPPs), which the European Supervisory Authorities can designate for direct oversight. If your organization is a CTPP — or relies on one — the scrutiny on your supply chain security controls is substantially higher. The availability disruption risk described above is a DORA concern as much as a security one: Article 28 explicitly requires documented continuity plans for critical third-party dependencies.

EU Cyber Resilience Act (CRA)

The CRA was adopted in 2024 and applies in a staggered timeline. Vulnerability and incident reporting obligations take effect from 11 September 2026. Full product requirements — including SBOM mandates and conformity assessments for products with digital elements — apply from 11 December 2027. Organizations selling connected hardware or software in the EU market need to begin compliance work now; the 2027 deadline arrives faster than most product development cycles allow.

NIST CSF 2.0 and NIST SP 800-161

NIST CSF 2.0, released in February 2024, added "Govern" as a sixth core function. The GV.SC subcategory explicitly addresses supply chain risk management, requiring organizations to integrate C-SCRM into enterprise risk governance — not treat it as a separate IT project. For EU organizations, CSF 2.0 is not a legal requirement but provides useful operational structure that maps well onto NIS2 and DORA obligations.

NIST SP 800-161 Rev. 1 provides the operational detail: how to conduct supplier assessments, what controls to require in contracts, and how to structure a C-SCRM program across the full acquisition lifecycle. For U.S. federal contractors, alignment with SP 800-161 is increasingly a procurement requirement.

How to secure vendor access: The technical blueprint

The four highest-impact controls for vendor access security are RBAC scoped to the engagement, just-in-time privileged access, centralized credential vaulting, and phishing-resistant MFA. Applied in that order, they address the most common failure modes — standing privileges, shared accounts, and authentication gaps — without requiring new infrastructure in most environments.

Enforce strict role-based access control (RBAC)

Role-based access control (RBAC) assigns permissions to roles, not individuals. A vendor support engineer gets the "read-only production monitoring" role, not a personal admin account. When the engagement ends, you remove the role assignment. When the vendor rotates their staff, you don't need to track individual accounts — the role defines what's accessible.

For vendor access specifically, RBAC should be scoped to the minimum required for the engagement. A database vendor performing a performance audit does not need write access to application configuration. Define the role before provisioning access, not after.

Implement just-in-time (JIT) privileged access

Just-in-time (JIT) access means privileged credentials are issued for a defined time window and automatically revoked when that window closes. A vendor engineer requests access for a two-hour maintenance window; the system grants it, logs the session, and revokes it at hour two regardless of whether the engineer remembers to log out.

JIT access eliminates standing privileges: the persistent, always-on access that attackers exploit during the 267-day average dwell time of a supply chain breach. There is nothing to steal if the credentials expire before the attacker can use them. JIT is particularly effective for break-glass scenarios: emergency vendor access during an incident, where speed matters but so does accountability.

Secure vendor credential vaulting

Shared vendor accounts are a liability. The alternative is a credential vault: a centralized, encrypted store where vendor credentials are held by your organization, not the vendor. The vendor authenticates to the vault, checks out credentials for their session, and the vault logs every access event.

This approach gives you a complete audit trail of who accessed what and when, the ability to rotate credentials without coordinating with the vendor, automatic revocation when the vendor relationship ends, and compliance evidence for NIS2 Article 21 and DORA Article 30 audit rights requirements.

Passwork's enterprise password and secrets manager supports time-limited credential sharing, session logging, and integration with AD/LDAP and SSO infrastructure — with AES-256 client-side encryption and a full REST API for integration into existing provisioning workflows.

Mandate phishing-resistant MFA for third parties

MFA is the single highest-ROI control for third-party access. Verizon's 2026 DBIR attributes the majority of third-party breach scenarios to authentication failures — and most of those failures are missing MFA, not bypassed MFA.

For privileged vendor access to production systems, the bar should be phishing-resistant MFA: FIDO2/WebAuthn hardware keys or passkeys, not SMS OTP. SMS-based MFA is vulnerable to SIM-swapping and real-time phishing proxies. Contractually require phishing-resistant MFA from vendors as a condition of access. Include it in your vendor security addendum, not just your internal policy.

Most of the access control failures described in this guide trace back to the same root cause: vendor credentials that were never properly vaulted, scoped, or revoked. Passwork addresses that directly — centralized credential vaulting, role-based access, time-limited sharing, and a full audit log tied to named identities. Available self-hosted or as a cloud deployment, it integrates with AD/LDAP and SAML SSO and is ISO 27001 certified.

Building a vendor risk assessment framework

A vendor risk assessment framework classifies third parties by access level and applies proportionate security requirements to each tier. The 5-tier model below scales from Tier 1 vendors with privileged production access, which require full security assessments and annual reviews — down to Tier 5 vendors with no data or system access, where standard procurement due diligence is sufficient.

The 5-tier vendor risk classification model:

The classification drives proportionate effort. You don't need a full penetration test report from your office supply vendor. You do need one from the MSP with admin access to your Active Directory.

Vendor access control checklist

The following pre-audit vendor access checklist maps directly to NIS2 Article 21, DORA Article 28, and NIST SP 800-161 requirements. Use it at vendor onboarding and at each annual review.

Pre-access provisioning:

•  Vendor classified by tier based on access level
•  Minimum necessary access scope defined in writing
•  Named individuals identified (no shared/generic accounts)
•  MFA requirement confirmed and tested
•  Access provisioned via credential vault, not direct credential sharing
•  Session logging enabled

During the engagement:

•  Access scope reviewed if engagement scope changes
•  Unusual access patterns flagged for review
•  Vendor incident notification clause active in contract

Access revocation:

•  Offboarding trigger defined (contract end, staff change, incident)
•  Credentials rotated immediately on offboarding
•  Vault access revoked and audit log exported
•  Access review documented for compliance records

Conclusion: Making supply chain security operational

Organizations that manage this well don't have fewer vendors; they have tighter controls on how those vendors authenticate, what they can access, and for how long.

The technical blueprint is clear: classify vendors by access tier, eliminate shared accounts, vault credentials centrally, enforce JIT access for privileged sessions, and require phishing-resistant MFA. NIS2, DORA, and the CRA provide the governance structure and the contractual leverage to hold vendors to the same standard.

Start with your Tier 1 vendors — the ones with privileged access to production systems. Audit their current access scope, confirm individual account assignment, and verify MFA is active. That single pass will surface more actionable risk than a year of questionnaires.

Frequently asked questions

What is the difference between supply chain security and vendor risk management?

Vendor risk management (VRM) is the broader discipline covering financial, operational, reputational, and cyber risks from third parties. Supply chain security is the cybersecurity-specific subset: protecting systems, data, and software integrity from threats that enter through supplier relationships. VRM informs procurement decisions; supply chain security governs technical access controls and software integrity.

Which regulations require supply chain security controls in 2025–2026?

NIS2 Directive Article 21 requires EU essential and important entities to assess and manage supplier security risks. DORA Articles 28–30 impose ICT third-party risk management obligations on EU financial entities. The EU Cyber Resilience Act requires vulnerability reporting from September 2026 and full SBOM and conformity requirements from December 2027. In the U.S., NIST SP 800-161 and Executive Order 14028 set C-SCRM expectations for federal contractors.

What is just-in-time (JIT) access and why does it matter for vendor security?

JIT access issues privileged credentials for a defined time window and revokes them automatically when that window closes. It eliminates standing privileges — persistent access that attackers exploit during the extended dwell time typical of supply chain breaches. IBM's 2025 data shows supply chain compromises average 267 days to identify and contain; JIT access reduces the exploitable window to hours, not months.

How do SBOMs reduce supply chain risk?

A Software Bill of Materials (SBOM) is a machine-readable inventory of all software components and their versions. When a new vulnerability is disclosed — such as Log4Shell in 2021 — an SBOM lets you determine within minutes whether any of your systems or vendor-supplied software contains the affected component. Without an SBOM, that same determination can take days or weeks, during which the vulnerability remains unpatched and exploitable.

What should a vendor security contract addendum include?

At minimum: a requirement for named individual accounts (no shared credentials), phishing-resistant MFA for privileged access, notification obligations within 24–72 hours of a security incident, audit rights allowing your organization to review access logs, and a defined offboarding process including credential rotation. NIS2 Article 21 and DORA Article 30 both require contractual security provisions — the addendum is your compliance evidence.

How should organizations classify vendors for risk assessment purposes?

Classify by access level, not by contract value or vendor size. A small consultancy with admin access to your production environment is higher risk than a large software vendor with no direct system access. The 5-tier vendor risk classification model above provides a practical structure: Tier 1 (privileged production access) through Tier 5 (no data or system access), with assessment requirements and review frequency scaled accordingly.

What is the most common access control failure in third-party breaches?

Shared credentials with no individual accountability. A single set of credentials issued to a vendor team, stored outside a vault, never rotated, and never revoked when the engagement ends. Verizon's 2026 DBIR identifies authentication failures as the primary mechanism in third-party breach scenarios. The fix is individual named accounts, credential vaulting, and a documented offboarding process — not more complex technology.

What is hardware supply chain risk and how is it different from software supply chain risk?

Hardware supply chain risk involves counterfeit or tampered physical components — network equipment, server hardware, firmware — that can introduce persistent backdoors invisible to software-layer security controls. Unlike software vulnerabilities, hardware tampering survives OS reinstallation. The EU Cyber Resilience Act addresses this directly, requiring manufacturers to document supply chain security for hardware products with digital elements.

Inside real supply chain attacks: Bitwarden CLI, Axios, and Vercel

Why breach your network when attackers can compromise a trusted dependency with millions of downloads and slip silently into thousands of organizations at once? Three 2026 campaigns prove supply chain attacks are no longer isolated incidents.

Passwork BlogAlex Muntyan

Shadow IT vs Shadow AI: Why AI is the bigger threat

Employees are using AI tools you didn’t approve, on accounts you can’t monitor, with data you can’t recover. Here’s what the risk actually looks like and what governance needs to address.

Passwork BlogAlex Muntyan

NIS2 access controls for supply chain security

48% of breaches now involve third parties. NIS2 Article 21 makes supplier access governance a legal obligation. Here’s how to map vendor access, enforce MFA and least privilege, and keep the audit evidence that proves your controls work.

Passwork BlogAlex Muntyan

Shadow AI bezeichnet die nicht genehmigte Nutzung von KI-Tools, Modellen und Agenten durch Mitarbeiter ohne Wissen oder Genehmigung der IT-Abteilung. Diese Praxis ist weit verbreitet und für Sicherheitsteams weitgehend unsichtbar — genau das macht sie so kostspielig.

Laut dem IBM-Bericht 2025 zahlen Organisationen mit hohem Shadow-AI-Anteil 670.000 $ mehr pro Datenpanne als solche mit geringem oder keinem Shadow-AI-Anteil. Das ergibt eine erwartete Gesamtsumme von 4,63 Mio. $. Diese Differenz spiegelt unkontrollierte Datenflüsse, ungesteuerten Modellzugriff und Zugangsdaten wider, die außerhalb jedes Sicherheitsperimeters an KI-Dienste Dritter übermittelt werden.

Das Ausmaß lässt sich schwerer abtun, als die meisten Sicherheitsteams erwarten. Entwickler, Finanzabteilungen, HR und der operative Bereich setzen KI-Tools nach eigenem Ermessen ein. Dieser Artikel erläutert, wie Shadow AI in Unternehmensumgebungen tatsächlich aussieht, warum es zu Sicherheits- und Compliance-Risiken führt und was IT-Teams tun können, um dem zuvorzukommen.

Was ist Shadow AI?

Shadow AI umfasst jedes KI-Tool, Modell, Plugin oder jeden Agenten, der innerhalb einer Organisation ohne ausdrückliche IT- oder Sicherheitsgenehmigung verwendet wird. Es befindet sich an der Schnittstelle zwischen Shadow IT und generativer KI und erbt die Governance-Blindstellen des ersteren, während es die Datenverarbeitungsrisiken der letzteren hinzufügt. Laut Varonis-Daten haben 98 % der Organisationen Mitarbeiter, die nicht genehmigte Apps nutzen, einschließlich Shadow AI.

Der Umfang ist größer, als die meisten Sicherheitsteams annehmen.

KI-Agenten stellen eine qualitative Verschiebung des Risikos dar. Eine Tabelle, die in einem nicht genehmigten Cloud-Speicher liegt, ist ein Datenexpositionsproblem. Ein KI-Agent mit delegiertem Zugriff auf E-Mail, Kalender und Dateisystem ist ein Access-Governance-Problem.

Shadow IT vs. Shadow AI: Den Risikomultiplikator verstehen

Shadow IT und Shadow AI haben gemeinsam, dass Mitarbeiter Tools außerhalb der Sichtbarkeit der IT nutzen. Das Risikoprofil ist jedoch grundlegend unterschiedlich.

Shadow IT (nicht genehmigte SaaS, privater Cloud-Speicher, nicht verwaltete Geräte) verursacht primär Datenhaltungs- und Compliance-Probleme. Daten liegen irgendwo, wo die IT keine Kontrolle hat. Die Exposition ist größtenteils statisch.

Shadow AI verarbeitet Daten. Es analysiert sie, fasst sie zusammen, generiert Ausgaben daraus und handelt im Fall von agentenbasierten Systemen autonom danach. Die Exposition ist dynamisch und oft irreversibel.

Das SaaS-Wildwuchs-Problem verstärkt dies. Mitarbeiter nutzen über 665 KI-Tools in einer typischen Unternehmensumgebung, laut der Analyse von Harmonic Security von 22 Millionen KI-Prompts in Unternehmen (2025). Sechs Anwendungen sind für 92,6 % der Exposition sensibler Daten verantwortlich, aber die verbleibenden 659 zu blockieren ist operativ zwecklos und zerstört die Produktivität. Die Governance-Herausforderung liegt in Sichtbarkeit, Klassifizierung und kontrolliertem Zugriff.

Die finanziellen Auswirkungen: Warum Shadow AI Unternehmen 670.000 $ pro Datenpanne kostet

Laut dem IBM-Bericht „Cost of a Data Breach" 2025 erhöhen Datenpannen mit hohem Shadow-AI-Anteil die durchschnittlichen Kosten um 670.000 $ im Vergleich zu solchen mit geringem oder keinem Shadow-AI-Anteil — ein Anstieg von 16 %, der die erwartete Gesamtsumme auf 4,63 Mio. $ pro Vorfall bringt.

Zwei zugrunde liegende Statistiken erklären den Mechanismus:

• 97 % der Organisationen, die einen KI-bezogenen Sicherheitsvorfall erlebten, hatten keine angemessenen KI-Zugriffskontrollen.
• 63 % der betroffenen Organisationen hatten keine Governance-Richtlinien für die Verwaltung von KI oder die Erkennung nicht autorisierter Nutzung.

Die Kausalkette ist direkt. Mitarbeiter führen KI-Tools schneller ein, als Sicherheitsteams sie bewerten können. Ohne Zugriffskontrollen fließen sensible Daten in Modelle, die die IT nie genehmigt hat und nicht auditieren kann. Wenn eine Datenpanne auftritt, verlängert das Fehlen von Logging und Governance die Erkennungs- und Eindämmungszeit — und in der Ökonomie von Datenpannen ist Zeit der primäre Kostentreiber.

Für CFOs ist die Rechnung eindeutig: Die erwarteten Kosten einer Shadow-AI-bezogenen Datenpanne betragen 4,63 Mio. $. Die Kosten eines KI-Governance-Programms für Unternehmen — Zugriffskontrollen, CASB-Bereitstellung, Lizenzierung genehmigter Tools, Credential-Management — sind nur ein Bruchteil davon. Das risikobereinigte Argument für Governance-Investitionen ist nicht mehrdeutig.

Sicherheitsteams haben auch eine DLP-Blindstelle (Data Loss Prevention): Die meisten DLP-Tools prüfen strukturierte Datenübertragungen. Konversationelle KI-Prompts sind unstrukturierter Text. Ein Mitarbeiter, der einen Datenbank-Verbindungsstring in einen Free-Tier-LLM-Account eingibt, löst keinen DLP-Alarm aus. Die Daten verlassen die Organisation unbemerkt.

Die versteckte Bedrohung: Credential-Exposition und KI-Agenten

Das direkteste und am wenigsten berichtete Shadow-AI-Risiko ist die Credential-Exposition. Mitarbeiter fügen ständig Secrets in öffentliche LLMs ein, weil es der schnellste Weg ist, Hilfe zu bekommen.

Ein Entwickler, der ein Produktionsproblem debuggt, fügt einen Datenbank-Verbindungsstring zusammen mit dem Fehlerprotokoll in ChatGPT ein. Ein DevOps-Ingenieur teilt eine Kubernetes-Konfigurationsdatei, einschließlich eingebetteter API-Keys, mit einem KI-Assistenten, um nach einem Deployment-Fehler zu fragen. Ein Finanzanalyst lädt eine Q3-Prognosetabelle in ein nicht genehmigtes KI-Zusammenfassungs-Tool hoch, um sich auf eine Vorstandssitzung vorzubereiten.

Laut der Analyse von Harmonic Security von 22,4 Millionen KI-Prompts in Unternehmen (2025) machen Code, juristische Dokumente und Finanzdaten 74,5 % der an KI-Tools exponierten sensiblen Daten aus. Quellcode allein enthält eingebettete Secrets (fest codierte API-Keys, Zugriffstokens und Dienstkonto-Credentials), die die meisten Entwickler als Konfigurationsdetails und nicht als sicherheitskritisches Material behandeln.

Die agentenbasierte Risikoebene fügt eine zweite Angriffsfläche hinzu. KI-Agenten — Systeme, die delegierte OAuth-Berechtigungen zum Lesen von Dateien, Senden von E-Mails, Abfragen von Datenbanken und Aufrufen externer APIs verwenden — arbeiten mit breiten Zugriffserteilungen, die nie für autonome Nutzung konzipiert wurden. Wenn ein Mitarbeiter einen Produktivitäts-KI-Agenten autorisiert, auf seine Unternehmens-E-Mails und seinen Dateispeicher zuzugreifen, hat dieser Agent möglicherweise breitere effektive Berechtigungen, als es die Rolle des Mitarbeiters rechtfertigen würde.

Die meisten Organisationen haben kein Inventar darüber, welche Agenten welche OAuth-Erteilungen halten, und keinen Prozess, um sie zu widerrufen, wenn ein Mitarbeiter ausscheidet.

16,9 % aller Expositionen sensibler Daten im Datensatz von Harmonic flossen durch private Free-Tier-Accounts — wo die IT keine Sichtbarkeit, keinen Audit-Trail hat und Daten zum Training öffentlicher Modelle verwendet werden können (Harmonic Security, 2025).

Die Kombination aus Credential-Exposition und agentenbasiertem Zugriff erzeugt ein kumulierendes Risiko: Ein kompromittierter KI-Agent mit Zugriff auf einen Tresor nicht verwalteter Secrets kann weit mehr exfiltrieren als ein einzelner geleakter API-Key.

Reale Datenpannen im Zusammenhang mit Shadow AI

Diese drei Vorfälle haben einen gemeinsamen Nenner: In jedem Fall griff eine KI-Komponente, die innerhalb einer vertrauenswürdigen Umgebung operierte, auf weit mehr Daten zu, als irgendjemand ausdrücklich autorisiert hatte.

Microsoft AI Research: 38 TB interner Daten exponiert

Was geschah. Ein Microsoft-KI-Forschungsteam veröffentlichte einen offenen Datensatz auf GitHub zum Training von Bilderkennungsmodellen. Um die Dateien zu teilen, verwendeten sie einen Azure-SAS-Token — konfigurierten ihn aber mit vollem Zugriff auf das gesamte Storage-Konto anstatt nur auf den Zielordner. Jeder, der dem Repository-Link folgte, erhielt uneingeschränkten Zugriff auf 38 TB privater Unternehmensdaten.

Was geleakt wurde. Workstation-Backups von zwei Mitarbeitern, über 30.000 interne Microsoft-Teams-Nachrichten von 359 Mitarbeitern, private Schlüssel, Dienstpasswörter und geheime Tokens. Der Token hatte „Vollzugriff"-Berechtigungen und war auf ein Ablaufdatum im Jahr 2051 eingestellt.

Warum dies ein Shadow-AI-Vorfall ist. Die Datenpanne geschah direkt im Rahmen der KI-Datensatzarbeit. Forscher, die schnell KI-Modelle ausliefern wollten, umgingen standardmäßige Zugriffsprüfungsverfahren. Wiz Research, das die Exposition entdeckte, beschrieb es als „eine neue Risikoklasse, der Organisationen bei beschleunigter KI-Einführung gegenüberstehen". Da der Token Schreibzugriff gewährte, hätte ein Angreifer bösartigen Code in KI-Modelle einschleusen können, die andere Entwickler aktiv herunterluden.

Reaktion. Wiz machte den Vorfall im September 2023 öffentlich. Microsoft widerrief den Token und schloss den Zugriff. Der Fall wurde zu einem Referenzbeispiel im IBM-Bericht „Cost of a Data Breach" 2025.

Slack AI: Datenexfiltration aus privaten Kanälen via Prompt Injection

Was geschah. Forscher bei PromptArmor fanden eine kritische Schwachstelle in Slack AI — dem integrierten Assistenten, der es Mitarbeitern ermöglicht, ihre gesamte Slack-Historie in natürlicher Sprache abzufragen. Die Angriffsklasse war indirekte Prompt Injection: Ein Bedrohungsakteur postet eine Nachricht in einem öffentlichen Kanal, die versteckte Anweisungen für das LLM enthält. Wenn ein Ziel Slack AI verwendet, um nach Informationen zu suchen, behandelt das Modell die bösartigen Anweisungen als legitim und führt sie aus.

Was gefährdet war. API-Keys und andere Secrets, die in privaten Kanälen gespeichert waren, auf die der Angreifer keinen direkten Zugriff hatte. Slack AI aggregierte Daten sowohl aus öffentlichen als auch aus privaten Kanälen bei der Beantwortung von Benutzeranfragen — dieser kanalübergreifende Zugriff war der Angriffsvektor. Ein zweites Szenario ermöglichte es Slack AI, einen Phishing-Link zu rendern, um Credentials abzufangen.

Warum dies ein Shadow-AI-Vorfall ist. Slack AI ist ein Lehrbuchfall für eingebettete Shadow AI: eine KI-Funktion, die innerhalb eines bereits genehmigten Unternehmenstools aktiviert wird, ohne separate Sicherheitsprüfung ihrer KI-Komponente. IT-Teams hatten keine Sichtbarkeit darüber, dass der Assistent auf private Kanäle zugreifen und als Exfiltrationsvektor dienen konnte. Am 14. August 2024 (am selben Tag, an dem die Schwachstelle offengelegt wurde) erweiterte Slack die Fähigkeiten des Assistenten, um hochgeladene Dokumente und Google-Drive-Dateien zu indexieren, was die Angriffsfläche weiter vergrößerte.

Reaktion. Slack klassifizierte das Verhalten zunächst als „beabsichtigt", veröffentlichte dann aber einen Patch. Das Unternehmen erklärte, es gebe „keine Hinweise auf unbefugten Zugriff auf Kundendaten". Der Vorfall wurde weithin als erster dokumentierter Fall von Datenexfiltration via Prompt Injection in einem produktiven Enterprise-SaaS-Produkt behandelt.

Microsoft 365 Copilot: EchoLeak, Zero-Click-Datenexfiltration

Was geschah. Forscher bei Aim Security veröffentlichten CVE-2025-32711 (CVSS 9.3 — Kritisch) in Microsoft 365 Copilot, genannt EchoLeak. Es ist die erste dokumentierte Zero-Click-Prompt-Injection mit bestätigter Datenexfiltration in einem produktiven KI-System. Der Angriff erforderte keine Aktion des Opfers.

Wie es funktionierte. Ein Angreifer sendete dem Ziel eine E-Mail mit versteckten Anweisungen, die als Markdown-Links im Referenzstil getarnt waren. Als Copilot die E-Mail verarbeitete, umging es den eingebauten XPIA-Klassifikator (Prompt-Injection-Schutz) und den Link-Schwärzungsmechanismus. Copilot griff dann automatisch auf die Dateien des Opfers in OneDrive, SharePoint und Teams zu, konstruierte eine URL über die Microsoft Teams Proxy API — die auf Copilots Whitelist steht — und sendete die Daten an den Server des Angreifers. Keine Klicks erforderlich.

Was gefährdet war. Jede Datei oder Konversation, auf die der Benutzer innerhalb von Microsoft 365 zugreifen konnte: OneDrive-Dokumente, SharePoint-Dateien, Teams-Nachrichten. Bis Mitte 2024 betrieben laut Netrix Global bereits mehr als 10.000 Unternehmen Microsoft 365 Copilot.

Warum dies ein Shadow-AI-Vorfall ist. EchoLeak repräsentiert die nächste Generation des Shadow-AI-Risikos: ein KI-Agent mit breitem Zugriff auf Unternehmensdaten, der innerhalb eines genehmigten Tools operiert, ohne angemessene Sicherheitsprüfung seiner KI-Komponente. Der Angriff hinterließ keine Spuren in Standard-Überwachungssystemen — der gesamte Datenverkehr lief über vertrauenswürdige Microsoft-Domains.

Reaktion. Microsoft veröffentlichte im Juni 2025 einen Notfall-Patch. Der Fall veränderte grundlegend, wie die Branche das Risiko für KI-Agenten mit breiten Zugriffsberechtigungen bewertet.

Shadow AI im Unternehmen erkennen und verhindern

Erkennung und Prävention erfordern einen strukturierten Ansatz. KI vollständig zu verbieten funktioniert nicht — die Daten von Harmonic zeigen, dass Mitarbeiter KI-Tools unabhängig von Richtlinien nutzen, oft über private Geräte und Accounts, die Unternehmenskontrollen vollständig umgehen. Das Ziel ist Governance, nicht Verbot.

Das 5-Schritte-Framework für Shadow-AI-Governance

1. KI-Exposition ermitteln. Setzen Sie Netzwerküberwachung ein, um ausgehenden Datenverkehr zu bekannten KI-Domains zu identifizieren. Verwenden Sie einen Cloud Access Security Broker (CASB), um Einblick in die SaaS-Nutzung auf verwalteten Geräten zu erhalten. Prüfen Sie Browser-Erweiterungen auf Unternehmens-Endpunkten — viele KI-Tools operieren als Erweiterungen mit breitem Zugriff auf Seiteninhalte. Erstellen Sie ein Inventar dessen, was tatsächlich verwendet wird, bevor Sie Richtlinien schreiben.
2. Richtlinien für akzeptable Nutzung definieren. Klassifizieren Sie KI-Tools in drei Stufen: genehmigt (Enterprise-lizenziert, Datenverarbeitungsvereinbarungen vorhanden), bedingt (nur für nicht sensible Aufgaben erlaubt) und verboten (keine Datensouveränitätskontrollen, öffentliches Modelltraining). Veröffentlichen Sie die Richtlinie.
3. RBAC für KI-Tools implementieren. Rollenbasierte Zugangskontrolle (RBAC) gilt für den Zugriff auf KI-Tools genauso wie für jedes andere System. Entwickler sollten keinen Zugriff auf Finanz-KI-Tools haben. Finanzteams sollten keinen Zugriff auf Code-Repositories haben, die in KI-Pipelines eingespeist werden. Beschränken Sie Zugriffserteilungen auf das für jede Rolle erforderliche Minimum. Prüfen Sie vierteljährlich.
4. Genehmigte Alternativen bereitstellen. Mitarbeiter setzen Shadow AI ein, weil genehmigte Tools zu langsam zu beschaffen oder für die Aufgabe unzureichend sind. Stellen Sie für jede verbotene Tool-Kategorie eine genehmigte Alternative mit gleichwertiger Funktionalität bereit. Wenn Entwickler einen KI-Coding-Assistenten benötigen, geben Sie ihnen einen mit Enterprise-Datenkontrollen. Governance ohne Befähigung erzeugt Unmut und Workarounds.
5. Die zugrunde liegenden Credentials sichern. Dies ist der Schritt, den die meisten Governance-Frameworks überspringen. Selbst mit Richtlinien und CASB können Mitarbeiter, die direkten Zugriff auf rohe API-Keys, Datenbankpasswörter und Dienstkonto-Credentials haben, diese in jedes Tool einfügen. Die Zentralisierung des Secrets-Managements — sodass Credentials gespeichert, injiziert und programmatisch rotiert werden, anstatt manuell kopiert zu werden — entfernt den direktesten Pfad von Shadow AI zur Credential-Kompromittierung.

Wie Passwork die Grundlage gegen Shadow-AI-Risiken sichert

Sie können einen Mitarbeiter nicht physisch daran hindern, einen Browser-Tab zu öffnen und in ein öffentliches LLM zu tippen. Was Sie kontrollieren können, ist, worauf er Zugriff zum Einfügen hat.

Das Kernprinzip: Klartext aus der Gleichung entfernen

Wenn API-Keys, Datenbank-Credentials, Produktions-Secrets und Dienstkonto-Passwörter in einem zentralisierten verschlüsselten Tresor liegen — auf den programmatisch zugegriffen wird anstatt manuell zu kopieren — sinkt das Credential-Expositionsrisiko durch Shadow AI erheblich. Der Entwickler, der ein Produktionsproblem mit einem KI-Assistenten debuggen möchte, kann den Datenbank-Verbindungsstring nicht einfügen, weil er ihn nie im Klartext hatte.

Was Passwork bietet

Passwork ist sowohl als Self-Hosted-Deployment als auch als Cloud-gehostete Lösung verfügbar. Beide teilen dieselbe Kernarchitektur: AES-256-Verschlüsselung unter einem Zero-Knowledge-Modell, bei dem Credentials clientseitig verschlüsselt werden, bevor sie das Gerät verlassen.

Vier Kontrollen sind im Shadow-AI-Kontext am wichtigsten:

• Rollenbasierte Zugangskontrolle. Administratoren beschränken den Tresorzugriff auf bestimmte Teams und Rollen. Ein Entwickler erhält Zugriff auf Entwicklungsumgebungs-Secrets, nicht auf Produktion. Der Zugriff wird nach Funktion gewährt, nicht nach Seniorität oder Bequemlichkeit.
• Audit-Logs. Jedes Zugriffsereignis wird aufgezeichnet: wer welches Credential abgerufen hat, wann und von welchem System. Wenn ein Credential an einem unerwarteten Ort auftaucht, haben Sie einen Nachweis.
• Dienstkonto-Management. Das Shadow-AI-Risiko beschränkt sich nicht auf Menschen, die Secrets in Chat-Fenster einfügen. KI-Agenten und automatisierte Pipelines laufen unter Dienstkonten — und diese Konten sammeln im Laufe der Zeit Berechtigungen an, ohne dass jemand sie aktiv überprüft. Passwork ermöglicht es, Dienstkonto-Credentials genauso zu speichern, zu rotieren und zu beschränken wie menschlichen Zugriff: mit expliziten Rollen, Ablaufrichtlinien und einer vollständigen Zugriffshistorie.
• API-first Credential-Bereitstellung. Die REST API von Passwork ermöglicht es Pipelines und Anwendungen, Secrets programmatisch zur Laufzeit abzurufen, anstatt sie aus Umgebungsdateien oder Konfigurations-Repositories zu lesen. Das Credential berührt nie die Zwischenablage eines Entwicklers. Es geht direkt vom Tresor zum Prozess, der es benötigt — und der Abruf wird protokolliert.

Self-Hosted vs. Cloud

Die Self-Hosted-Option hält alle Daten innerhalb der eigenen Infrastruktur der Organisation — die richtige Wahl für Teams mit strengen Datenstandortanforderungen oder regulierten Umgebungen. Die Cloud-Option entfernt den operativen Aufwand des Betriebs einer eigenen Instanz bei gleichzeitiger Beibehaltung derselben Verschlüsselungsgarantien und Zugriffskontrollen. Keine der Optionen sendet Klartext-Credentials an Passwork-Server.

Wie Passwork Shadow-AI-Risiken adressiert

Fazit

Die Mehrkosten von 670.000 $ pro Datenpanne durch Shadow AI sind die Kosten der KI-Nutzung ohne Governance. Die Organisationen, die diese Mehrkosten zahlen, sind keine Ausreißer. Es sind die 63 %, die keine KI-Governance-Richtlinien hatten, und die 97 %, denen es bei einem Vorfall an angemessenen Zugriffskontrollen mangelte.

Governance beginnt auf der Credential-Ebene. Ein Mitarbeiter, der keinen Zugriff auf rohe Produktions-Secrets hat, kann diese nicht versehentlich exponieren — unabhängig davon, welches KI-Tool er öffnet. Das ist der Kontrollpunkt, den die meisten Shadow-AI-Frameworks übersehen, und derjenige, der die unmittelbarste Risikoreduktion liefert.

Prüfen Sie noch heute, auf welche Credentials Ihre Teams im Klartext zugreifen können. Diese Liste ist Ihre Shadow-AI-Expositionsfläche.

FAQ: Shadow AI im Unternehmen

Wie erkennt man Shadow AI?

Organisationen können Shadow AI erkennen, indem sie Netzwerkprotokolle auf ungewöhnlichen ausgehenden Datenverkehr zu KI-Domains überwachen, einen Cloud Access Security Broker (CASB) einsetzen, um die SaaS-Nutzung auf verwalteten Geräten zu prüfen, und Browser-Erweiterungen auf Unternehmens-Endpunkten überprüfen. Endpoint-DLP-Tools können große Textübertragungen zu bekannten KI-Diensten markieren, obwohl private Free-Tier-Accounts eine hartnäckige Blindstelle bleiben.

Was ist ein Beispiel für Shadow AI?

Ein häufiges Beispiel ist ein Entwickler, der proprietären Quellcode in einen privaten ChatGPT-Account einfügt, um ein Produktionsproblem zu debuggen — dabei werden fest codierte API-Keys und interne Architektur exponiert. Ein weiteres ist ein Marketingteam, das vertrauliche Kundendaten in ein nicht genehmigtes KI-Zusammenfassungs-Tool hochlädt, oder ein Finanzanalyst, der Q3-Prognosen mit einem Free-Tier-KI-Assistenten teilt, um Vorstandsmaterialien vorzubereiten.

Warum ist Shadow AI gefährlicher als Shadow IT?

Shadow IT verursacht Datenstandortprobleme — Daten liegen irgendwo, wo die IT keine Kontrolle hat. Shadow AI verarbeitet Daten: Es analysiert sie, generiert Outputs daraus und handelt bei agentenbasierten Deployments autonom danach. Die Exposition durch Shadow AI ist oft irreversibel, besonders wenn Daten durch Free-Tier-Accounts fließen, wo sie zum Training öffentlicher Modelle verwendet werden können.

Welche Credentials sind am meisten durch Shadow AI gefährdet?

API-Keys, Datenbank-Verbindungsstrings, OAuth-Tokens und Dienstkonto-Passwörter sind die am höchsten gefährdeten Credentials. Dies sind die Secrets, die Entwickler und DevOps-Ingenieure am wahrscheinlichsten in KI-Prompts einfügen, wenn sie debuggen oder um Konfigurationshilfe bitten. Fest codierte Secrets im Quellcode sind besonders exponiert, da Code die größte Einzelkategorie sensibler Daten ist, die mit KI-Tools geteilt werden (Harmonic Security, 2025).

Verhindert das Verbot von KI-Tools Shadow AI?

Nein. Die Analyse von Harmonic Security von 22,4 Millionen Enterprise-Prompts ergab, dass Mitarbeiter in über 90 % der Organisationen aktiv KI-Tools nutzen, meist über private Accounts, die die IT nie genehmigt hat. Pauschale Verbote verlagern die Nutzung auf private Geräte und Accounts mit noch weniger Sichtbarkeit. Effektive Governance kombiniert genehmigte Alternativen, klare Richtlinien für akzeptable Nutzung und technische Kontrollen auf der Zugriffsebene.

Passwortverwaltung für Teams: Die Lösung, die jedes KMU braucht

Das Speichern von Passwörtern in Slack und Browsern setzt Ihr Unternehmen Datenpannen aus. Erfahren Sie, warum persönliche Tools für Teams versagen, wie Sie ausscheidende Mitarbeiter mit einem Klick sicher offboarden und warum die neuesten NIST-Richtlinien von erzwungener Passwortrotation abraten.

Passwork BlogAlex Muntyan

VaultJacking: Wie eine PIN einen Google Password Manager-Tresor exponieren kann

VaultJacking zielt auf die Google Password Manager-PIN ab, um Ihren gesamten Tresor zu entsperren. Eine abgefangene PIN exponiert jedes gespeicherte Passwort und jeden Passkey. Erfahren Sie, wie der Angriff funktioniert, wer gefährdet ist und was zu tun ist, wenn Sie gephisht wurden.

Passwork BlogAlex Muntyan

Mitarbeiter-Offboarding: Leitfaden zur sicheren Zugriffsentziehung 2026

Das Deaktivieren eines SSO-Accounts widerruft keinen Zugriff. API-Keys, KI-Agent-Credentials und geteilte Passwörter überleben es. Dieser Leitfaden behandelt das vollständige Offboarding-Playbook — von Zero-Hour-Triggern bis zur NHI-Bereinigung.

Passwork BlogAlex Muntyan

Shadow AI es el uso no autorizado de herramientas, modelos y agentes de IA por parte de empleados sin conocimiento ni aprobación del departamento de TI. Esta práctica está muy extendida y es en gran medida invisible para los equipos de seguridad — lo cual es precisamente lo que la hace costosa.

Según el informe de 2025 de IBM, las organizaciones con altos niveles de shadow AI pagan 670.000 $ más por brecha que aquellas con niveles bajos o sin shadow AI, elevando el total esperado a 4,63 millones de dólares. Esa diferencia refleja flujos de datos no monitoreados, acceso a modelos sin gobernanza y credenciales transferidas a servicios de IA de terceros fuera de cualquier perímetro de seguridad.

La magnitud es más difícil de ignorar de lo que la mayoría de los equipos de seguridad esperan. Desarrolladores, personal financiero, recursos humanos y operaciones están adoptando herramientas de IA según sus propios criterios. Este artículo analiza cómo se manifiesta realmente shadow AI en entornos empresariales, por qué genera exposición de seguridad y cumplimiento, y qué pueden hacer los equipos de TI para adelantarse.

¿Qué es Shadow AI?

Shadow AI es cualquier herramienta, modelo, plugin o agente de IA utilizado dentro de una organización sin aprobación explícita de TI o seguridad. Se sitúa en la intersección de Shadow IT y la IA generativa, heredando los puntos ciegos de gobernanza del primero y añadiendo los riesgos de procesamiento de datos de la segunda. Según datos de Varonis, el 98% de las organizaciones tienen empleados que utilizan aplicaciones no autorizadas, incluida shadow AI.

El alcance es más amplio de lo que la mayoría de los equipos de seguridad suponen.

Los agentes de IA representan un cambio cualitativo en el riesgo. Una hoja de cálculo almacenada en una unidad en la nube no aprobada es un problema de exposición de datos. Un agente de IA con acceso delegado a su correo electrónico, calendario y sistema de archivos es un problema de gobernanza de accesos.

Shadow IT vs. Shadow AI: comprender el multiplicador de riesgo

Shadow IT y Shadow AI implican que los empleados utilicen herramientas fuera de la visibilidad de TI. El perfil de riesgo es fundamentalmente diferente.

Shadow IT (SaaS no autorizado, almacenamiento personal en la nube, dispositivos no gestionados) genera principalmente problemas de residencia de datos y cumplimiento. Los datos residen en algún lugar que TI no controla. La exposición es en gran medida estática.

Shadow AI procesa datos. Razona sobre ellos, los resume, genera resultados a partir de ellos y, en el caso de sistemas agénticos, actúa sobre ellos. La exposición es dinámica y a menudo irreversible.

El problema de la proliferación de SaaS agrava esto. Los empleados utilizan más de 665 herramientas de IA en un entorno empresarial típico, según el análisis de Harmonic Security de 22 millones de prompts empresariales de IA (2025). Seis aplicaciones representan el 92,6% de la exposición de datos sensibles, pero bloquear las 659 restantes es operativamente inútil y destruye la productividad. El desafío de gobernanza es la visibilidad, la clasificación y el acceso controlado.

El impacto financiero: por qué Shadow AI cuesta a las empresas 670.000 $ por brecha

Según el Informe del Coste de una Brecha de Datos 2025 de IBM, las brechas que involucran altos niveles de shadow AI añaden 670.000 $ al coste medio de la brecha en comparación con aquellas con niveles bajos o sin shadow AI — un aumento del 16%, elevando el total esperado a 4,63 millones de dólares por incidente.

Dos estadísticas subyacentes explican el mecanismo:

• El 97% de las organizaciones que experimentaron un incidente de seguridad relacionado con IA carecían de controles de acceso a IA adecuados.
• El 63% de las organizaciones que sufrieron brechas no tenían políticas de gobernanza para gestionar la IA o detectar el uso no autorizado.

La cadena causal es directa. Los empleados adoptan herramientas de IA más rápido de lo que los equipos de seguridad pueden evaluarlas. Sin controles de acceso, los datos sensibles fluyen hacia modelos que TI nunca aprobó y no puede auditar. Cuando ocurre una brecha, la ausencia de registro y gobernanza extiende el tiempo de detección y contención — y en la economía de las brechas, el tiempo es el principal factor de coste.

Para los directores financieros, el cálculo es sencillo: el coste esperado de una brecha relacionada con shadow AI es de 4,63 millones de dólares. El coste de un programa de gobernanza de IA empresarial — controles de acceso, despliegue de CASB, licencias de herramientas aprobadas, gestión de credenciales — es una fracción de eso. El caso ajustado al riesgo para la inversión en gobernanza no es ambiguo.

Los equipos de seguridad también enfrentan un punto ciego de DLP (Prevención de Pérdida de Datos): la mayoría de las herramientas DLP inspeccionan transferencias de datos estructurados. Los prompts de IA conversacional son texto no estructurado. Un empleado que escribe una cadena de conexión de base de datos en una cuenta LLM de nivel gratuito no genera ninguna alerta DLP. Los datos abandonan la organización silenciosamente.

La amenaza oculta: exposición de credenciales y agentes de IA

El riesgo de shadow AI más directo y menos reportado es la exposición de credenciales. Los empleados pegan secretos en LLMs públicos constantemente porque es la forma más rápida de obtener ayuda.

Un desarrollador que depura un problema de producción pega una cadena de conexión de base de datos en ChatGPT junto con el registro de errores. Un ingeniero DevOps comparte un archivo de configuración de Kubernetes, incluidas las claves API incrustadas, con un asistente de IA para preguntar sobre un fallo de despliegue. Un analista financiero sube una hoja de proyecciones del tercer trimestre a una herramienta de resumen de IA no aprobada para preparar una reunión de la junta directiva.

Según el análisis de Harmonic Security de 22,4 millones de prompts empresariales de IA (2025), el código, los documentos legales y los datos financieros comprenden el 74,5% de los datos sensibles expuestos a herramientas de IA. El código fuente por sí solo contiene secretos incrustados (claves API hardcodeadas, tokens de acceso y credenciales de cuentas de servicio) que la mayoría de los desarrolladores tratan como detalles de configuración en lugar de material crítico para la seguridad.

La capa de riesgo agéntico añade una segunda superficie de ataque. Los agentes de IA — sistemas que utilizan permisos OAuth delegados para leer archivos, enviar correos electrónicos, consultar bases de datos y llamar a APIs externas — operan con concesiones de acceso amplias que nunca fueron diseñadas para uso autónomo. Cuando un empleado autoriza a un agente de IA de productividad a acceder a su correo electrónico corporativo y almacenamiento de archivos, ese agente puede tener permisos efectivos más amplios de lo que el rol del propio empleado justifica.

La mayoría de las organizaciones no tienen un inventario de qué agentes poseen qué concesiones OAuth, ni un proceso para revocarlas cuando un empleado se va.

El 16,9% de todas las exposiciones de datos sensibles en el conjunto de datos de Harmonic fluyeron a través de cuentas personales de nivel gratuito — donde TI no tiene visibilidad, no hay registro de auditoría y los datos pueden usarse para entrenar modelos públicos (Harmonic Security, 2025).

La combinación de exposición de credenciales y acceso agéntico crea un riesgo compuesto: un agente de IA comprometido con acceso a una bóveda de secretos no gestionados puede exfiltrar mucho más que una única clave API filtrada.

Brechas reales vinculadas a Shadow AI

Estos tres incidentes comparten un hilo común: en cada caso, un componente de IA operando dentro de un entorno de confianza accedió a muchos más datos de los que alguien había autorizado explícitamente.

Microsoft AI Research: 38 TB de datos internos expuestos

Qué ocurrió. Un equipo de investigación de IA de Microsoft publicó un conjunto de datos abierto en GitHub para entrenar modelos de reconocimiento de imágenes. Para compartir los archivos, utilizaron un token SAS de Azure — pero lo configuraron con acceso completo a toda la cuenta de almacenamiento en lugar de la carpeta objetivo. Cualquiera que siguiera el enlace del repositorio obtenía acceso sin restricciones a 38 TB de datos privados de la empresa.

Qué se filtró. Copias de seguridad de estaciones de trabajo de dos empleados, más de 30.000 mensajes internos de Microsoft Teams de 359 miembros del personal, claves privadas, contraseñas de servicios y tokens secretos. El token tenía permisos de «control total» y estaba configurado para expirar en 2051.

Por qué este es un incidente de Shadow AI. La brecha ocurrió directamente en el curso del trabajo con conjuntos de datos de IA. Los investigadores, moviéndose rápido para lanzar modelos de IA, eludieron los procedimientos estándar de revisión de acceso. Wiz Research, que descubrió la exposición, lo describió como «una nueva clase de riesgo que enfrentan las organizaciones a medida que aceleran la adopción de IA». Debido a que el token otorgaba acceso de escritura, un atacante podría haber inyectado código malicioso en modelos de IA que otros desarrolladores estaban descargando activamente.

Respuesta. Wiz divulgó el incidente públicamente en septiembre de 2023. Microsoft revocó el token y cerró el acceso. El caso se convirtió en un ejemplo de referencia en el informe del Coste de una Brecha de Datos 2025 de IBM.

Slack AI: exfiltración de datos de canales privados mediante inyección de prompts

Qué ocurrió. Investigadores de PromptArmor encontraron una vulnerabilidad crítica en Slack AI — el asistente integrado que permite a los empleados consultar todo su historial de Slack en lenguaje natural. La clase de ataque fue inyección indirecta de prompts: un actor de amenazas publica un mensaje en un canal público que contiene instrucciones ocultas para el LLM. Cuando un objetivo utiliza Slack AI para buscar información, el modelo trata las instrucciones maliciosas como legítimas y las ejecuta.

Qué estaba en riesgo. Claves API y otros secretos almacenados en canales privados a los que el atacante no tenía acceso directo. Slack AI agregaba datos tanto de canales públicos como privados al responder consultas de usuarios — ese acceso entre canales era el vector de ataque. Un segundo escenario permitía que Slack AI mostrara un enlace de phishing para capturar credenciales.

Por qué este es un incidente de Shadow AI. Slack AI es un caso de libro de texto de shadow AI incrustada: una función de IA activada dentro de una herramienta corporativa ya aprobada, sin una revisión de seguridad separada de su componente de IA. Los equipos de TI no tenían visibilidad del hecho de que el asistente podía acceder a canales privados y servir como vector de exfiltración. El 14 de agosto de 2024 (el mismo día en que se divulgó la vulnerabilidad), Slack amplió las capacidades del asistente para indexar documentos cargados y archivos de Google Drive, ampliando aún más la superficie de ataque.

Respuesta. Slack inicialmente clasificó el comportamiento como «previsto», y luego emitió un parche. La empresa declaró que «no había evidencia de acceso no autorizado a datos de clientes». El incidente fue ampliamente cubierto como el primer caso documentado de exfiltración de datos mediante inyección de prompts en un producto SaaS empresarial en producción.

Microsoft 365 Copilot: EchoLeak, exfiltración de datos sin clic

Qué ocurrió. Investigadores de Aim Security divulgaron CVE-2025-32711 (CVSS 9.3 — Crítico) en Microsoft 365 Copilot, denominado EchoLeak. Es la primera inyección de prompts sin clic documentada con exfiltración de datos confirmada en un sistema de IA en producción. El ataque no requería ninguna acción de la víctima.

Cómo funcionó. Un atacante enviaba al objetivo un correo electrónico que contenía instrucciones ocultas disfrazadas de enlaces Markdown de estilo referencia. Cuando Copilot procesaba el correo electrónico, eludía el clasificador XPIA integrado (protección contra inyección de prompts) y el mecanismo de redacción de enlaces. Copilot entonces accedía automáticamente a los archivos de la víctima en OneDrive, SharePoint y Teams, construía una URL a través de la API del Proxy de Microsoft Teams — que está en la lista de permitidos de Copilot — y enviaba los datos al servidor del atacante. Sin clics requeridos.

Qué estaba en riesgo. Cualquier archivo o conversación accesible para el usuario dentro de Microsoft 365: documentos de OneDrive, archivos de SharePoint, mensajes de Teams. Para mediados de 2024, más de 10.000 empresas ya estaban ejecutando Microsoft 365 Copilot, según Netrix Global.

Por qué este es un incidente de Shadow AI. EchoLeak representa la próxima generación de riesgo de shadow AI: un agente de IA con amplio acceso a datos corporativos, operando dentro de una herramienta autorizada, sin una revisión de seguridad adecuada de su componente de IA. El ataque no dejó rastros en los sistemas de monitorización estándar — todo el tráfico se movió a través de dominios de confianza de Microsoft.

Respuesta. Microsoft emitió un parche de emergencia en junio de 2025. El caso cambió fundamentalmente cómo la industria evalúa el riesgo de los agentes de IA con amplios permisos de acceso.

Cómo detectar y prevenir Shadow AI en la empresa

La detección y prevención requieren un enfoque estructurado. Prohibir la IA por completo no funciona — los datos de Harmonic muestran que los empleados utilizan herramientas de IA independientemente de la política, a menudo a través de dispositivos personales y cuentas que eluden completamente los controles corporativos. El objetivo es la gobernanza, no la prohibición.

El marco de gobernanza de Shadow AI en 5 pasos

1. Descubrir la exposición a IA. Despliegue monitorización de red para identificar tráfico saliente a dominios de IA conocidos. Utilice un Cloud Access Security Broker (CASB) para obtener visibilidad del uso de SaaS en dispositivos gestionados. Audite las extensiones de navegador en los endpoints corporativos — muchas herramientas de IA operan como extensiones con amplio acceso al contenido de las páginas. Construya un inventario de lo que realmente se está usando antes de escribir políticas.
2. Definir políticas de uso aceptable. Clasifique las herramientas de IA en tres niveles: aprobadas (con licencia empresarial, acuerdos de procesamiento de datos vigentes), condicionales (permitidas solo para tareas no sensibles) y prohibidas (sin controles de soberanía de datos, entrenamiento de modelos públicos). Publique la política.
3. Implementar RBAC para herramientas de IA. El control de acceso basado en roles (RBAC) se aplica al acceso a herramientas de IA de la misma manera que se aplica a cualquier otro sistema. Los desarrolladores no deberían tener acceso a herramientas de IA financieras. Los equipos de finanzas no deberían tener acceso a repositorios de código alimentados en pipelines de IA. Limite las concesiones de acceso al mínimo requerido para cada rol. Revise trimestralmente.
4. Proporcionar alternativas autorizadas. Los empleados adoptan shadow AI porque las herramientas aprobadas son lentas de adquirir o inadecuadas para la tarea. Para cada categoría de herramienta prohibida, proporcione una alternativa autorizada con capacidad equivalente. Si los desarrolladores necesitan un asistente de codificación con IA, deles uno con controles de datos empresariales. La gobernanza sin habilitación genera resentimiento y soluciones alternativas.
5. Asegurar las credenciales subyacentes. Este es el paso que la mayoría de los marcos de gobernanza omiten. Incluso con políticas y CASB implementados, los empleados que tienen acceso directo a claves API sin procesar, contraseñas de bases de datos y credenciales de cuentas de servicio pueden pegarlas en cualquier herramienta. Centralizar la gestión de secretos — para que las credenciales se almacenen, inyecten y roten programáticamente en lugar de copiarse manualmente — elimina la ruta más directa desde shadow AI hasta el compromiso de credenciales.

Cómo Passwork asegura la base contra los riesgos de Shadow AI

No se puede impedir físicamente que un empleado abra una pestaña del navegador y escriba en un LLM público. Lo que sí se puede controlar es a qué tiene acceso para pegar.

El principio fundamental: eliminar el texto plano de la ecuación

Si las claves API, las credenciales de bases de datos, los secretos de producción y las contraseñas de cuentas de servicio residen en una bóveda cifrada centralizada — accedida programáticamente en lugar de copiada manualmente — el riesgo de exposición de credenciales por shadow AI se reduce sustancialmente. El desarrollador que quiere depurar un problema de producción con un asistente de IA no puede pegar la cadena de conexión de la base de datos porque nunca la tuvo en texto plano para empezar.

Qué ofrece Passwork

Passwork está disponible tanto como despliegue autoalojado como solución alojada en la nube. Ambas comparten la misma arquitectura central: cifrado AES-256 bajo un modelo de conocimiento cero, donde las credenciales se cifran en el lado del cliente antes de abandonar el dispositivo.

Cuatro controles son los más importantes en el contexto de shadow AI:

• Control de acceso basado en roles. Los administradores limitan el acceso a la bóveda a equipos y roles específicos. Un desarrollador obtiene acceso a los secretos del entorno de desarrollo, no a los de producción. El acceso se otorga por función, no por antigüedad o conveniencia.
• Registros de auditoría. Cada evento de acceso se registra: quién recuperó qué credencial, cuándo y desde qué sistema. Si una credencial aparece en algún lugar donde no debería, tiene un rastro.
• Gestión de cuentas de servicio. El riesgo de shadow AI no se limita a humanos pegando secretos en ventanas de chat. Los agentes de IA y los pipelines automatizados se ejecutan bajo cuentas de servicio — y esas cuentas acumulan permisos con el tiempo sin que nadie los revise activamente. Passwork permite almacenar, rotar y limitar las credenciales de cuentas de servicio de la misma manera que gestiona el acceso humano: con roles explícitos, políticas de expiración y un historial de acceso completo.
• Entrega de credenciales basada en API. La REST API de Passwork permite que los pipelines y las aplicaciones recuperen secretos programáticamente en tiempo de ejecución en lugar de leerlos de archivos de entorno o repositorios de configuración. La credencial nunca toca el portapapeles del desarrollador. Va directamente desde la bóveda al proceso que la necesita — y la recuperación queda registrada.

Autoalojado vs. nube

La opción autoalojada mantiene todos los datos dentro de la propia infraestructura de la organización — la elección correcta para equipos con requisitos estrictos de residencia de datos o entornos regulados. La opción en la nube elimina la carga operativa de ejecutar su propia instancia mientras preserva las mismas garantías de cifrado y controles de acceso. Ninguna opción envía credenciales en texto plano a los servidores de Passwork.

Cómo Passwork aborda los riesgos de Shadow AI

Conclusión

El sobrecoste de 670.000 $ por brecha debido a shadow AI es el coste de usar IA sin gobernanza. Las organizaciones que pagan ese sobrecoste no son casos atípicos. Son el 63% que no tenía políticas de gobernanza de IA y el 97% que carecía de controles de acceso adecuados cuando ocurrió un incidente.

La gobernanza comienza en la capa de credenciales. Un empleado que no puede acceder a secretos de producción sin procesar no puede exponerlos accidentalmente — independientemente de qué herramienta de IA abra. Ese es el punto de control que la mayoría de los marcos de shadow AI omiten, y el que ofrece la reducción de riesgo más inmediata.

Audite a qué credenciales pueden acceder sus equipos en texto plano hoy. Esa lista es su superficie de exposición a shadow AI.

Preguntas frecuentes: Shadow AI en la empresa

¿Cómo se detecta Shadow AI?

Las organizaciones pueden detectar shadow AI monitorizando los registros de red en busca de tráfico saliente inusual hacia dominios de IA, desplegando un Cloud Access Security Broker (CASB) para auditar el uso de SaaS en dispositivos gestionados y revisando las extensiones de navegador en los endpoints corporativos. Las herramientas DLP de endpoint pueden marcar grandes transferencias de texto a servicios de IA conocidos, aunque las cuentas personales de nivel gratuito siguen siendo un punto ciego persistente.

¿Cuál es un ejemplo de Shadow AI?

Un ejemplo común es un desarrollador que pega código fuente propietario en una cuenta personal de ChatGPT para depurar un problema de producción — exponiendo claves API hardcodeadas y arquitectura interna en el proceso. Otro es un equipo de marketing que sube datos confidenciales de clientes a una herramienta de resumen de IA no aprobada, o un analista financiero que comparte proyecciones del tercer trimestre con un asistente de IA de nivel gratuito para preparar materiales para la junta directiva.

¿Por qué Shadow AI es más peligrosa que Shadow IT?

Shadow IT crea problemas de residencia de datos — los datos residen en algún lugar que TI no controla. Shadow AI procesa datos: razona sobre ellos, genera resultados a partir de ellos y, en despliegues agénticos, actúa sobre ellos de forma autónoma. La exposición a través de shadow AI es a menudo irreversible, especialmente cuando los datos fluyen a través de cuentas de nivel gratuito donde pueden usarse para entrenar modelos públicos.

¿Qué credenciales corren más riesgo por Shadow AI?

Las claves API, las cadenas de conexión de bases de datos, los tokens OAuth y las contraseñas de cuentas de servicio son las credenciales de mayor riesgo. Estos son los secretos que los desarrolladores e ingenieros DevOps tienen más probabilidades de incluir en prompts de IA cuando depuran o piden ayuda con configuraciones. Los secretos hardcodeados en el código fuente están particularmente expuestos, ya que el código es la categoría más grande de datos sensibles compartidos con herramientas de IA (Harmonic Security, 2025).

¿Prohibir las herramientas de IA previene Shadow AI?

No. El análisis de Harmonic Security de 22,4 millones de prompts empresariales encontró que los empleados de más del 90% de las organizaciones utilizan activamente herramientas de IA, principalmente a través de cuentas personales que TI nunca aprobó. Las prohibiciones generales empujan el uso hacia dispositivos y cuentas personales con aún menos visibilidad. Una gobernanza efectiva combina alternativas aprobadas, políticas claras de uso aceptable y controles técnicos en la capa de acceso.

Gestión de contraseñas para equipos: la solución que toda pyme necesita

Almacenar contraseñas en Slack y navegadores expone su negocio a brechas. Descubra por qué las herramientas personales fallan para los equipos, cómo dar de baja de forma segura a empleados que se van con un solo clic, y por qué las últimas directrices del NIST recomiendan no forzar la rotación de contraseñas.

Passwork BlogAlex Muntyan

VaultJacking: cómo un único PIN puede exponer una bóveda de Google Password Manager

VaultJacking ataca el PIN de Google Password Manager para desbloquear toda su bóveda. Un único PIN capturado expone todas las contraseñas y passkeys guardadas. Descubra cómo funciona el ataque, quién está en riesgo y qué hacer si ha sido víctima de phishing.

Passwork BlogAlex Muntyan

Baja de empleados: guía de revocación segura de accesos 2026

Deshabilitar una cuenta SSO no revoca el acceso. Las claves API, las credenciales de agentes de IA y las contraseñas compartidas sobreviven. Esta guía cubre el manual completo de baja — desde los disparadores de hora cero hasta la limpieza de NHI.

Passwork BlogAlex Muntyan

Shadow AI is the unsanctioned use of AI tools, models, and agents by employees without IT knowledge or approval. The practice is widespread and largely invisible to security teams — which is exactly what makes it expensive.

According to IBM's 2025 report, organizations with high levels of shadow AI pay $670,000 more per breach than those with low or no shadow AI, bringing the expected total to $4.63M. That gap reflects unmonitored data flows, ungoverned model access, and credentials passed to third-party AI services outside any security perimeter.

The scale is harder to dismiss than most security teams expect. Developers, finance staff, HR, and operations are all adopting AI tools on their own terms. This article breaks down what shadow AI actually looks like in enterprise environments, why it creates security and compliance exposure, and what IT teams can do to get ahead of it.

What is Shadow AI?

Shadow AI is any AI tool, model, plugin, or agent used within an organization without explicit IT or security approval. It sits at the intersection of Shadow IT and generative AI, inheriting the governance blind spots of the former and adding the data-processing risks of the latter. According to Varonis data, 98% of organizations have employees using unsanctioned apps, including shadow AI.

The scope is wider than most security teams assume.

AI agents represent a qualitative shift in risk. A spreadsheet stored in an unapproved cloud drive is a data exposure problem. An AI agent with delegated access to your email, calendar, and file system is an access governance problem.

Shadow IT vs. Shadow AI: Understanding the risk multiplier

Shadow IT and Shadow AI both involve employees using tools outside IT's visibility. The risk profile is fundamentally different.

Shadow IT (unauthorized SaaS, personal cloud storage, unmanaged devices) primarily creates data residency and compliance problems. Data sits somewhere IT doesn't control. The exposure is largely static.

Shadow AI processes data. It reasons over it, summarizes it, generates outputs from it, and in the case of agentic systems, acts on it. The exposure is dynamic and often irreversible.

The SaaS sprawl problem compounds this. Employees use 665+ AI tools across a typical enterprise environment, according to Harmonic Security's analysis of 22 million enterprise AI prompts (2025). Six applications account for 92.6% of sensitive data exposure but blocking the remaining 659 is operationally futile and destroys productivity. The governance challenge is visibility, classification, and controlled access.

The financial impact: Why Shadow AI costs enterprises $670K per breach

According to IBM's 2025 Cost of a Data Breach Report, breaches involving high levels of shadow AI add $670,000 to the average breach cost compared to those with low or no shadow AI — a 16% increase, bringing the expected total to $4.63M per incident.

Two underlying statistics explain the mechanism:

• 97% of organizations that experienced an AI-related security incident lacked proper AI access controls.
• 63% of breached organizations had no governance policies for managing AI or detecting unauthorized use.

The causal chain is direct. Employees adopt AI tools faster than security teams can evaluate them. Without access controls, sensitive data flows into models that IT never approved and cannot audit. When a breach occurs, the absence of logging and governance extends detection and containment time — and in breach economics, time is the primary cost driver.

For CFOs, the calculation is straightforward: the expected cost of a shadow AI-related breach is $4.63M. The cost of an enterprise AI governance program — access controls, CASB deployment, approved tool licensing, credential management — is a fraction of that. The risk-adjusted case for governance investment is not ambiguous.

Security teams also face a DLP (Data Loss Prevention) blind spot: most DLP tools inspect structured data transfers. Conversational AI prompts are unstructured text. An employee typing a database connection string into a free-tier LLM account generates no DLP alert. The data leaves the organization silently.

The hidden threat: Credential exposure and AI agents

The most direct and underreported shadow AI risk is credential exposure. Employees paste secrets into public LLMs constantly because it's the fastest path to getting help.

A developer debugging a production issue pastes a database connection string into ChatGPT along with the error log. A DevOps engineer shares a Kubernetes config file, including embedded API keys, with an AI assistant to ask about a deployment failure. A finance analyst uploads a Q3 projection spreadsheet to an unapproved AI summarization tool to prepare for a board meeting.

According to Harmonic Security's analysis of 22.4 million enterprise AI prompts (2025), code, legal documents, and financial data comprise 74.5% of sensitive data exposed to AI tools. Source code alone carries embedded secrets (hardcoded API keys, access tokens, and service account credentials) that most developers treat as configuration details rather than security-critical material.

The agentic risk layer adds a second attack surface. AI agents — systems that use delegated OAuth permissions to read files, send emails, query databases, and call external APIs — operate with broad access grants that were never designed for autonomous use. When an employee authorizes a productivity AI agent to access their corporate email and file storage, that agent may have broader effective permissions than the employee's own role warrants.

Most organizations have no inventory of which agents hold which OAuth grants, and no process for revoking them when an employee leaves.

16.9% of all sensitive data exposures in Harmonic's dataset flowed through personal free-tier accounts — where IT has zero visibility, no audit trail, and data may be used to train public models (Harmonic Security, 2025).

The combination of credential exposure and agentic access creates a compounding risk: a compromised AI agent with access to a vault of unmanaged secrets can exfiltrate far more than a single leaked API key.

Real breaches tied to Shadow AI

These three incidents share a common thread: in each case, an AI component operating inside a trusted environment accessed far more data than anyone had explicitly authorized.

Microsoft AI Research: 38 TB of internal data exposed

What happened. A Microsoft AI research team published an open dataset on GitHub for training image recognition models. To share the files, they used an Azure SAS token — but configured it with full access to the entire Storage Account instead of the target folder. Anyone following the repository link got unrestricted access to 38 TB of private company data.

What leaked. Workstation backups from two employees, over 30,000 internal Microsoft Teams messages from 359 staff members, private keys, service passwords, and secret tokens. The token carried "full control" permissions and was set to expire in 2051.

Why this is a Shadow AI incident. The breach happened directly in the course of AI dataset work. Researchers, moving fast to ship AI models, bypassed standard access review procedures. Wiz Research, which discovered the exposure, described it as "a new class of risk organizations face as they accelerate AI adoption." Because the token granted write access, an attacker could have injected malicious code into AI models that other developers were actively downloading.

Response. Wiz disclosed the incident publicly in September 2023. Microsoft revoked the token and closed access. The case became a reference example in IBM's Cost of a Data Breach 2025 report.

Slack AI: Data exfiltration from private channels via prompt injection

What happened. Researchers at PromptArmor found a critical vulnerability in Slack AI — the built-in assistant that lets employees query their entire Slack history in natural language. The attack class was indirect prompt injection: a threat actor posts a message in a public channel containing hidden instructions for the LLM. When a target uses Slack AI to search for information, the model treats the malicious instructions as legitimate and executes them.

What was at risk. API keys and other secrets stored in private channels the attacker had no direct access to. Slack AI aggregated data from both public and private channels when answering user queries — that cross-channel access was the attack vector. A second scenario allowed Slack AI to render a phishing link to capture credentials.

Why this is a Shadow AI incident. Slack AI is a textbook embedded shadow AI case: an AI feature activated inside an already-approved corporate tool, with no separate security review of its AI component. IT teams had no visibility into the fact that the assistant could reach private channels and serve as an exfiltration vector. On August 14, 2024 (the same day the vulnerability was disclosed) Slack expanded the assistant's capabilities to index uploaded documents and Google Drive files, widening the attack surface further.

Response. Slack initially classified the behavior as "intended," then issued a patch. The company stated there was "no evidence of unauthorized customer data access." The incident was widely covered as the first documented case of data exfiltration via prompt injection in a production enterprise SaaS product.

Microsoft 365 Copilot: EchoLeak, zero-click data exfiltration

What happened. Researchers at Aim Security disclosed CVE-2025-32711 (CVSS 9.3 — Critical) in Microsoft 365 Copilot, named EchoLeak. It is the first documented zero-click prompt injection with confirmed data exfiltration in a production AI system. The attack required no action from the victim.

How it worked. An attacker sent the target an email containing hidden instructions disguised as reference-style Markdown links. When Copilot processed the email, it bypassed the built-in XPIA classifier (prompt injection protection) and the link-redaction mechanism. Copilot then automatically accessed the victim's files in OneDrive, SharePoint, and Teams, constructed a URL through the Microsoft Teams Proxy API — which sits on Copilot's allowlist — and sent the data to the attacker's server. No clicks required.

What was at risk. Any file or conversation accessible to the user within Microsoft 365: OneDrive documents, SharePoint files, Teams messages. By mid-2024, more than 10,000 companies were already running Microsoft 365 Copilot, according to Netrix Global.

Why this is a Shadow AI incident. EchoLeak represents the next generation of shadow AI risk: an AI agent with broad access to corporate data, operating inside a sanctioned tool, with no adequate security review of its AI component. The attack left no traces in standard monitoring systems — all traffic moved through trusted Microsoft domains.

Response. Microsoft issued an emergency patch in June 2025. The case fundamentally changed how the industry assesses risk for AI agents with wide access permissions.

How to detect and prevent Shadow AI in the enterprise

Detection and prevention require a structured approach. Banning AI entirely does not work — Harmonic's data shows employees use AI tools regardless of policy, often through personal devices and accounts that bypass corporate controls entirely. The goal is governance, not prohibition.

The 5-step Shadow AI governance framework

1. Discover AI exposure. Deploy network monitoring to identify outbound traffic to known AI domains. Use a Cloud Access Security Broker (CASB) to gain visibility into SaaS usage across managed devices. Audit browser extensions on corporate endpoints — many AI tools operate as extensions with broad page-content access. Build an inventory of what's actually in use before writing policy.
2. Define acceptable use policies. Classify AI tools into three tiers: approved (enterprise-licensed, data processing agreements in place), conditional (permitted for non-sensitive tasks only), and prohibited (no data sovereignty controls, public model training). Publish the policy.
3. Implement RBAC for AI tools. Role-based access control (RBAC) applies to AI tool access the same way it applies to any other system. Developers should not have access to financial AI tools. Finance teams should not have access to code repositories fed into AI pipelines. Scope access grants to the minimum required for each role. Review quarterly.
4. Provide sanctioned alternatives. Employees adopt shadow AI because approved tools are slow to procure or inadequate for the task. For every prohibited tool category, provide a sanctioned alternative with equivalent capability. If developers need an AI coding assistant, give them one with enterprise data controls. Governance without enablement creates resentment and workarounds.
5. Secure the underlying credentials. This is the step most governance frameworks skip. Even with policies and CASB in place, employees who have direct access to raw API keys, database passwords, and service account credentials can paste them into any tool. Centralizing secrets management — so that credentials are stored, injected, and rotated programmatically rather than copied manually — removes the most direct path from shadow AI to credential compromise.

How Passwork secures the foundation against Shadow AI risks

You cannot physically prevent an employee from opening a browser tab and typing into a public LLM. What you can control is what they have access to paste.

The core principle: remove plaintext from the equation

If API keys, database credentials, production secrets, and service account passwords live in a centralized encrypted vault — accessed programmatically rather than copied manually — the credential exposure risk from shadow AI drops substantially. The developer who wants to debug a production issue with an AI assistant cannot paste the database connection string because they never had it in plaintext to begin with.

What Passwork provides

Passwork is available as both a self-hosted deployment and a cloud-hosted solution. Both share the same core architecture: AES-256 encryption under a zero-knowledge model, where credentials are encrypted client-side before leaving the device.

Four controls matter most in the shadow AI context:

• Role-based access control. Administrators scope vault access to specific teams and roles. A developer gets access to development environment secrets, not production. Access is granted by function, not by seniority or convenience.
• Audit logs. Every access event is recorded: who retrieved which credential, when, and from which system. If a credential surfaces somewhere it shouldn't, you have a trail.
• Service account management. Shadow AI risk isn't limited to humans pasting secrets into chat windows. AI agents and automated pipelines run under service accounts — and those accounts accumulate permissions over time with no one actively reviewing them. Passwork lets you store, rotate, and scope service account credentials the same way you manage human access: with explicit roles, expiry policies, and a full access history.
• API-first credential delivery. Passwork's REST API lets pipelines and applications retrieve secrets programmatically at runtime instead of reading them from environment files or config repositories. The credential never touches a developer's clipboard. It goes directly from the vault to the process that needs it — and the retrieval is logged.

Self-hosted vs. cloud

The self-hosted option keeps all data within the organization's own infrastructure — the right choice for teams with strict data residency requirements or regulated environments. The cloud option removes the operational overhead of running your own instance while preserving the same encryption guarantees and access controls. Neither option sends plaintext credentials to Passwork's servers.

How Passwork addresses Shadow AI risks

Conclusion

The $670K breach cost premium for shadow AI is the cost of using AI without governance. The organizations paying that premium are not outliers. They are the 63% that had no AI governance policies and the 97% that lacked proper access controls when an incident occurred.

Governance starts at the credential layer. An employee who cannot access raw production secrets cannot accidentally expose them — regardless of which AI tool they open. That is the control point that most shadow AI frameworks miss, and the one that delivers the most immediate risk reduction.

Audit which credentials your teams can access in plaintext today. That list is your shadow AI exposure surface.

FAQ: Shadow AI in the enterprise

How do you detect Shadow AI?

Organizations can detect shadow AI by monitoring network logs for unusual outbound traffic to AI domains, deploying a Cloud Access Security Broker (CASB) to audit SaaS usage across managed devices, and reviewing browser extensions on corporate endpoints. Endpoint DLP tools can flag large text transfers to known AI services, though free-tier personal accounts remain a persistent blind spot.

What is an example of Shadow AI?

A common example is a developer pasting proprietary source code into a personal ChatGPT account to debug a production issue — exposing hardcoded API keys and internal architecture in the process. Another is a marketing team uploading confidential customer data to an unapproved AI summarization tool, or a finance analyst sharing Q3 projections with a free-tier AI assistant to prepare board materials.

Why is Shadow AI more dangerous than Shadow IT?

Shadow IT creates data residency problems — data sits somewhere IT doesn't control. Shadow AI processes data: it reasons over it, generates outputs from it, and in agentic deployments, acts on it autonomously. Exposure through shadow AI is often irreversible, especially when data flows through free-tier accounts where it may be used to train public models.

What credentials are most at risk from Shadow AI?

API keys, database connection strings, OAuth tokens, and service account passwords are the highest-risk credentials. These are the secrets developers and DevOps engineers are most likely to include in AI prompts when debugging or asking for configuration help. Hardcoded secrets in source code are particularly exposed, since code is the single largest category of sensitive data shared with AI tools (Harmonic Security, 2025).

Does banning AI tools prevent Shadow AI?

No. Harmonic Security's analysis of 22.4 million enterprise prompts found that employees at over 90% of organizations actively use AI tools, mostly through personal accounts that IT never approved. Blanket bans push usage to personal devices and accounts with even less visibility. Effective governance combines approved alternatives, clear acceptable-use policies, and technical controls at the access layer.

Password management for teams: The fix every SMB needs

Storing passwords in Slack and browsers exposes your business to breaches. Discover why personal tools fail teams, how to securely offboard departing employees in one click, and why the latest NIST guidelines recommend against forced password rotation.

Passwork BlogAlex Muntyan

VaultJacking: How one PIN can expose a Google password manager vault

VaultJacking targets the Google Password Manager PIN to unlock your entire vault. One captured PIN exposes every saved password and passkey. Learn how the attack works, who’s at risk, and what to do if you’ve been phished.

Passwork BlogAlex Muntyan

Employee offboarding: Secure access revocation guide 2026

Disabling an SSO account doesn’t revoke access. API keys, AI agent credentials, and shared passwords survive it. This guide covers the full offboarding playbook — from zero-hour triggers to NHI cleanup.

Passwork BlogAlex Muntyan

Remote-Arbeit hat keine neuen Angriffsvektoren geschaffen — sie hat bestehende auf Tausende von Homeoffices, persönliche Geräte und Consumer-Router verteilt. Der DBIR 2026 von Verizon setzt Software-Schwachstellen mit 31% der Vorfälle an die Spitze der Einbruchsvektoren, wobei Ransomware in 48% der Fälle involviert ist. Die Angriffsfläche hat sich nicht in ihrer Art verändert. Sie hat sich in Umfang und Verteilung verändert.

Die meisten dieser Sicherheitsverletzungen beginnen mit einem Standard-Router-Passwort, einer Slack-Nachricht mit Zugangsdaten oder einem Mitarbeiter, der das VPN übersprungen hat, weil es zu langsam war.

Sicherheit versagt, wenn es schwieriger ist, das Richtige zu tun als das Falsche. Jeder der folgenden Fehler beschreibt den tatsächlichen Fehler, warum er passiert und wie eine realistische Lösung aussieht.

Fehler 1: Der ungesicherte Heimrouter (Standard-Zugangsdaten)

Heimrouter werden mit Standard-Admin-Zugangsdaten ausgeliefert, die öffentlich dokumentiert sind. Angreifer scannen ständig nach exponierten Router-Verwaltungsoberflächen. Ein kompromittierter Router gibt einem Angreifer eine Position zwischen dem Mitarbeiter und jedem System, auf das er zugreift — einschließlich Unternehmens-VPNs und Cloud-Diensten.

Warum das passiert

Die meisten Mitarbeiter ändern nie das Standardpasswort, weil ihnen niemand gesagt hat, dass sie es tun sollen, und der Router „einfach funktioniert". Das ist das Reibungsproblem: Die sichere Handlung erfordert bewussten Aufwand, zu dem das Gerät nie auffordert.

Die Lösung

Verteilen Sie eine einseitige Anleitung zur Router-Härtung an alle Remote-Mitarbeiter. Sie sollte drei Dinge abdecken: Ändern Sie das Admin-Passwort (mindestens 16 Zeichen, einzigartig), deaktivieren Sie die Fernverwaltung, wenn sie nicht verwendet wird, und aktualisieren Sie die Firmware. Die Anleitung zur Heimnetzwerksicherheit von CISA ist ein solider Ausgangspunkt. Für Rollen mit höherem Risiko sollten firmenverwaltete Reiserouter mit vorab gehärteten Konfigurationen in Betracht gezogen werden.

Fehler 2: Unsichere Passwortweitergabe über Chat und E-Mail

Ein Entwickler benötigt Datenbank-Zugangsdaten. Der schnellste Weg ist Slack. Ein Auftragnehmer braucht ein Admin-Konto. E-Mail funktioniert. Die Finanzabteilung speichert das Lohnbuchhaltungs-Login in einer gemeinsamen Tabelle. Jede dieser Übergaben erzeugt Zugangsdaten, die außerhalb jedes kontrollierten Systems existieren — in Chat-Protokollen, E-Mail-Archiven und Tabellenverläufen, die niemand prüft.

Warum das passiert

Das Problem ist, dass der Unternehmens-Tresor schwieriger zu nutzen ist als Slack. Wenn der sichere Weg mehr Reibung hat als der unsichere, gewinnt der unsichere jedes Mal.

Die Lösung

Machen Sie die tresorvermittelte Freigabe zur einfachsten Option. Mit einem richtig konfigurierten Passwort-Manager kann ein Benutzer den Zugriff auf Zugangsdaten teilen, ohne dass der Empfänger das Rohpasswort jemals sieht. Jedes Zugriffsereignis wird protokolliert und einer individuellen Identität zugeordnet. Wenn der Auftrag des Auftragnehmers endet, widerrufen Sie den Zugriff einmal — ohne den Chat-Verlauf durchsuchen zu müssen, um herauszufinden, was gesendet wurde.

Fehler 3: Vermischung von privaten und beruflichen Geräten (BYOD ohne Kontrollen)

Bring-your-own-device (BYOD)-Richtlinien sparen Hardwarekosten. Sie platzieren aber auch Unternehmenszugangsdaten auf Maschinen mit persönlichen Browser-Erweiterungen, Familienkonten und Software, die die IT nie gesehen hat. Die Angriffsfläche ist nicht das Unternehmensnetzwerk — es ist der private Laptop des Mitarbeiters, auf dem auch ein gecracktes Spiel und ein veralteter Browser laufen.

Warum das passiert

Organisationen akzeptieren BYOD-Risiken, ohne sie zu quantifizieren. Das Gerät, über das die IT keinerlei Sichtbarkeit hat, ist dasselbe Gerät, das auf Produktionssysteme, Unternehmens-E-Mail und Cloud-Speicher zugreift. Niemand meldet es, weil noch nichts schiefgegangen ist.

Die Lösung

Wenn BYOD unvermeidlich ist, setzen Sie Mindeststandards durch: Geräteverschlüsselung, Anforderungen an die Betriebssystemversion und eine Mobile-Device-Management (MDM)-Lösung, die Unternehmensdaten löschen kann, ohne persönliche Dateien zu berühren. Trennen Sie Arbeits- und Privataktivitäten mindestens auf Browser-Profil-Ebene. Für Rollen mit hohen Privilegien stellen Sie dedizierte Arbeitsgeräte bereit. Die Kosten eines verwalteten Endpunkts sind ein Bruchteil der Kosten eines Sicherheitsvorfalls, der auf einer privaten Maschine begann.

Fehler 4: Bildschirmfreigabe und Benachrichtigungslecks

Ein Zoom-Anruf läuft. Eine Slack-Benachrichtigung mit einem Link zum Zurücksetzen des Passworts erscheint. Eine Bildschirmfreigabe zeigt ein offenes Terminal mit sichtbaren Zugangsdaten. Diese sind in Sysadmin-Communities als echte Vorboten von Sicherheitsverletzungen dokumentiert.

Warum das passiert

Datenschutzfehler während der Bildschirmfreigabe werden als peinliche Unfälle behandelt, nicht als Sicherheitsvorfälle. Es gibt keine Warnung, keinen Protokolleintrag, keine ausgelöste Richtlinienverletzung. Die Daten gehen einfach nach außen.

Die Lösung

Konfigurieren Sie die Benachrichtigungseinstellungen so, dass Nachrichtenvorschauen während der Bildschirmfreigabe ausgeblendet werden. Schließen Sie sensible Tabs und Terminals, bevor Sie Ihren Bildschirm teilen — machen Sie es zur Gewohnheit, nicht zur Reaktion. Unter macOS unterdrückt „Nicht stören" Benachrichtigungsvorschauen. Unter Windows macht Focus Assist dasselbe. Das sind 30-Sekunden-Konfigurationsänderungen. Nehmen Sie sie in die Onboarding-Dokumentation für Remote-Arbeit auf, damit Mitarbeiter sie am ersten Tag einrichten, nicht nach dem ersten Vorfall.

Fehler 5: Vernachlässigung der Multi-Faktor-Authentifizierung (MFA)

Ohne MFA reicht ein geleaktes Passwort für vollen Kontozugriff. Die Sicherheitsforschung von Microsoft beziffert die Reduzierung von Kontokompromittierungen durch MFA auf 99,9%. Trotzdem bleibt die Einführung uneinheitlich — insbesondere bei internen Tools und Legacy-Systemen, die „es nicht unterstützen".

Warum das passiert

MFA fügt einen Schritt hinzu. Mitarbeiter finden Wege um Schritte herum, die sie verlangsamen. Die Lücke ist selten technischer Natur — sie ist verhaltensbedingt. Und wenn die Durchsetzung einzelnen Anwendungen überlassen wird statt einem zentralen Identitätsanbieter, ist die Abdeckung immer unvollständig.

Die Lösung

Setzen Sie MFA auf der Ebene des Identitätsanbieters durch. Wenn SSO die Authentifizierung übernimmt, gilt MFA automatisch für alles Nachgelagerte. Für Systeme, die nicht mit SSO integriert werden können, verwenden Sie Hardware-Sicherheitsschlüssel (FIDO2/WebAuthn) für privilegierte Konten — sie sind phishing-resistent auf eine Weise, die TOTP-Codes nicht sind. Dokumentieren Sie, welche Systeme von MFA ausgenommen sind, und behandeln Sie diese Liste als Risikoregister-Eintrag, nicht als Dauerzustand.

Fehler 6: Verbindung mit öffentlichem WLAN ohne VPN

Café-WLAN ist eine gemeinsam genutzte Broadcast-Domain. Jeder im selben Netzwerk kann unverschlüsselten Datenverkehr beobachten. Der meiste moderne HTTPS-Datenverkehr ist während der Übertragung verschlüsselt, aber DNS-Anfragen, unverschlüsselte Anwendungen und Metadaten können trotzdem durchsickern. Praktischer gesehen sind öffentliche Netzwerke ein häufiger Vektor für Evil-Twin-Angriffe — bösartige Zugangspunkte, die legitime Netzwerke nachahmen und alles abfangen, was durch sie hindurchgeht.

Warum das passiert

Das Netzwerk verbindet sich, der Laptop funktioniert, nichts sieht falsch aus. Es gibt kein sichtbares Signal dafür, dass der Datenverkehr beobachtet wird oder dass der Zugangspunkt gefälscht ist. Das Risiko ist unsichtbar, bis es das nicht mehr ist.

Die Lösung

Verlangen Sie die VPN-Nutzung in jedem Nicht-Heimnetzwerk als unverzichtbare Richtlinie. Split-Tunnel-VPNs, die nur Unternehmensdatenverkehr routen, sind in Ordnung — sie reduzieren die Latenz, ohne Unternehmensdaten dem offenen Netzwerk auszusetzen. Für Mitarbeiter, die häufig reisen, entfernt ein Hardware-Reiserouter mit Always-On-VPN die Entscheidung vollständig. Die sichere Option wird zum Standard.

Fehler 7: Ignorieren von Software-Updates und Patching

Der DBIR 2026 von Verizon identifiziert Software-Schwachstellen als den wichtigsten Einbruchsvektor mit 31%. Ungepatchte Endpunkte sind der Hauptgrund. Der Laptop eines Remote-Mitarbeiters, der eine sechs Monate alte Betriebssystemversion ausführt, ist eine dokumentierte Schwachstelle mit einer öffentlichen CVE, kein theoretisches Risiko.

Warum das passiert

Auto-Update-Aufforderungen unterbrechen die Arbeit. Mitarbeiter klicken unbegrenzt auf „Erinnere mich später". Niemand folgt nach. Sechs Monate später läuft auf dem Endpunkt Software mit einem Dutzend veröffentlichter Exploits und einem Patch, der seit Q1 verfügbar ist.

Die Lösung

Nehmen Sie die Wahl weg. Setzen Sie automatische Updates durch MDM oder Gruppenrichtlinien durch. Legen Sie ein maximales Aufschubfenster fest — 72 Stunden sind für die meisten Patches angemessen, 24 Stunden für kritische Sicherheitspatches. Für Drittanbieter-Software verwenden Sie ein Patch-Management-Tool, anstatt sich darauf zu verlassen, dass einzelne Anwendungen sich selbst aktualisieren.

Behandeln Sie ungepatchte Endpunkte als Compliance-Problem, nicht als Benutzerpräferenz. Wenn ein Gerät das Aufschubfenster verpasst, blockieren Sie seinen VPN-Zugang, bis es aktuell ist. Diese eine Richtlinienänderung behebt das Verhalten in der Regel schneller als jede Schulung.

Fehler 8: Auf Phishing und Social Engineering hereinfallen

Der Phishing Trends Report 2026 von Hoxhunt verfolgte über 50 Millionen echte und simulierte Angriffe bei 4 Millionen Benutzern und fand einen 14-fachen Anstieg von KI-generiertem Phishing Ende 2025 — ihr Anteil an allen gemeldeten Angriffen sprang innerhalb eines Monats von 4% auf 56%. Der DBIR 2026 bestätigt, dass das menschliche Element zentral für die Verursachung von Sicherheitsverletzungen bleibt.

Warum das passiert

Remote-Mitarbeiter sind exponierter als Büromitarbeiter. Es gibt keinen Kollegen zu fragen „Hast du diese E-Mail auch bekommen?". Der IT-Helpdesk ist ein Ticket, nicht eine Person den Flur hinunter. Verifizierungsreibung ist hoch, Klicken ist schnell.

Die Lösung

Security-Awareness-Schulungen müssen aktuell und spezifisch sein, nicht eine einmal jährliche Compliance-Checkbox. Simulierte Phishing-Kampagnen mit sofortigem Feedback sind effektiver als passive Schulungsmodule. Technisch reduzieren DMARC-, DKIM- und SPF-Einträge das Volumen gefälschter E-Mails.

Für hochwertige Ziele eliminieren Hardware-Sicherheitsschlüssel das Ergebnis des Zugangsdatendiebstahls eines erfolgreichen Phishings — selbst wenn der Mitarbeiter auf den Link klickt, gibt es kein Passwort zu stehlen. Speziell für Helpdesk-Teams setzen Sie Identitätsverifizierungsprotokolle vor jeder Kontoaktion durch: einen Rückruf an eine bekannte Nummer, nicht eine Nummer, die der Anrufer angibt.

Fehler 9: Schatten-IT und nicht genehmigte Cloud-Tools

Der Work Trend Index 2024 von Microsoft und LinkedIn fand heraus, dass 78% der Mitarbeiter bereits persönliche KI-Tools bei der Arbeit nutzen — die meisten ohne IT-Genehmigung. Der Treiber ist immer Reibung: Das genehmigte Tool ist langsamer, schwerer zugänglich oder verfügt nicht über eine Funktion, die der Mitarbeiter benötigt.

Warum das passiert

Schatten-IT ist kein Disziplinproblem. Es ist ein Signal dafür, dass das genehmigte Toolset Lücken hat. Daten, die in einem persönlichen Google Drive gespeichert sind, Zugangsdaten, die in einem persönlichen Passwort-Manager verwaltet werden, Dateien, die über einen Verbraucherdienst geteilt werden — all das existiert außerhalb der Sichtbarkeit, Sicherung und Zugriffskontrollen des Unternehmens. Die IT weiß nicht, dass die Daten dort sind, bis etwas schiefgeht.

Die Lösung

Prüfen Sie Schatten-IT, bevor Sie sie verbieten. Verstehen Sie, was Mitarbeiter nutzen und warum. In vielen Fällen ist die Lösung die Verbesserung des genehmigten Tools oder das Hinzufügen einer genehmigten Alternative — nicht ein weiteres Richtlinienmemo, das niemand liest.

Speziell für das Zugangsdatenmanagement: Wenn Mitarbeiter Arbeitspasswörter in persönlichen Tools speichern, versagt der Unternehmens-Tresor irgendwie. Das Onboarding ist zu komplex, der Zugriff ist zu langsam, oder das Tool passt nicht in ihren Workflow. Beheben Sie das Tool. Richtlinien allein haben noch nie gegen Bequemlichkeit gewonnen.

Fehler 10: Unverschlüsselter lokaler Speicher und Backups

Remote-Mitarbeiter akkumulieren sensible Daten auf lokalen Maschinen: Datenbankexporte, Zugangsdatenlisten, Konfigurationsdateien mit API-Schlüsseln, Backup-Archive. Wenn diese Daten unverschlüsselt auf der Festplatte eines Laptops liegen, wird ein gestohlenes oder verlorenes Gerät zu einem vollständigen Datenleck — kein Netzwerkzugriff erforderlich.

Warum das passiert

Verschlüsselung fühlt sich wie eine IT-Aufgabe an, nicht wie eine Benutzeraufgabe. Mitarbeiter denken nicht darüber nach, was auf ihrer Festplatte ist, bis es weg ist. Backups werden besonders vernachlässigt: Sie werden einmal erstellt, lokal oder auf einem persönlichen USB-Laufwerk gespeichert und nie wieder überprüft. Niemand prüft, was in ~/Downloads oder C:\Users\name\Desktop liegt.

Die Lösung

Aktivieren Sie Festplattenvollverschlüsselung standardmäßig (BitLocker unter Windows, FileVault unter macOS), durchgesetzt über MDM bei der Gerätebereitstellung, nicht dem Mitarbeiter überlassen. Für Backups verlangen Sie nur verschlüsselte Ziele: Unternehmens-Cloud-Speicher oder einen lokalen Backup-Server.

Persönliche USB-Laufwerke und unverschlüsselte externe Festplatten sollten per Richtlinie blockiert werden. Führen Sie regelmäßige Prüfungen durch, welche Daten Mitarbeiter lokal speichern und warum. In den meisten Fällen befinden sich sensible Dateien auf lokalen Laufwerken, weil die genehmigte Speicheroption unbequem war.

Wie Sie eine sichere Remote-Umgebung aufbauen: Die Lösungen, die tatsächlich greifen

Die 10 obigen Fehler teilen einen gemeinsamen Faden. Sicherheit bricht an dem Punkt zusammen, an dem das Richtige zu tun mehr Aufwand erfordert als das Falsche zu tun. Die Umgebung zu reparieren bedeutet, diese Reibung zu reduzieren — nicht nur mehr Richtlinien hinzuzufügen, die Mitarbeiter umgehen.

Ein praktisches Behebungs-Framework für IT-Teams — das 5-Schichten-Remote-Sicherheits-Baseline

1. Identitätsschicht — MFA durchgesetzt beim IdP, SSO für alle wichtigen Anwendungen, Hardware-Schlüssel für privilegierte Konten.
2. Zugangsdatenschicht — Zentralisierter Passwort-Manager mit tresorvermitteltem Teilen, RBAC auf Gruppenebene, automatisiertes Offboarding verknüpft mit Verzeichnisänderungen.
3. Endpunktschicht — MDM-durchgesetzte Verschlüsselung, automatisches Patching, Bildschirmsperr-Richtlinie, BYOD-Mindeststandards.
4. Netzwerkschicht — Erforderliches VPN in Nicht-Heimnetzwerken, DNS-Filterung, Router-Härtungsanleitung für alle Remote-Mitarbeiter.
5. Awareness-Schicht — Regelmäßige Phishing-Simulationen, aktualisierte Schulungen, die aktuelle KI-verstärkte Bedrohungen widerspiegeln, ein klarer Eskalationsweg für verdächtige Aktivitäten.

Keine dieser Schichten funktioniert isoliert. Ein Mitarbeiter mit MFA und gepatchtem Laptop, der Zugangsdaten über Slack teilt, hat eine Lücke bei Schicht 2. Ein Mitarbeiter mit einem sicheren Tresor, der sich ohne VPN mit öffentlichem WLAN verbindet, hat eine Lücke bei Schicht 4.

Für Teams, die privilegierte Konten über eine verteilte Belegschaft hinweg verwalten, verdient die Zugangsdatenschicht besondere Aufmerksamkeit. Die Risiken des Verwaltens administrativer Zugangsdaten aus der Ferne potenzieren sich schnell, wenn privilegierter Zugang nicht zentralisiert und geprüft wird.

Fazit

Die 10 obigen Fehler sind dieselben Fehler, die Jahr für Jahr in Breach-Post-Mortems auftauchen, jetzt verteilt über Homeoffices, wo die IT weniger Sichtbarkeit hat und Mitarbeiter mehr Autonomie. Das Muster ist konsistent: Sicherheit bricht am Reibungspunkt.

Das 5-Schichten-Baseline oben gibt Ihrem Team einen strukturierten Weg, zu prüfen, wo diese Reibungspunkte sind. Beginnen Sie mit der Zugangsdatenschicht — dort entstehen die vermeidbarsten Sicherheitsverletzungen, und dort amortisiert sich ein gut eingesetzter Passwort-Manager am schnellsten.

Häufig gestellte Fragen zur Remote-Arbeit-Sicherheit

Was sind die häufigsten Sicherheitsfehler bei der Remote-Arbeit?

Die häufigsten Sicherheitsfehler bei der Remote-Arbeit sind unsichere Passwortweitergabe (über Chat oder E-Mail), ungepatchte Endpunkte, fehlendes MFA und Verbindung zu öffentlichem WLAN ohne VPN. Der DBIR 2026 von Verizon identifiziert Software-Schwachstellen als den wichtigsten Einbruchsvektor mit 31%, während Phishing und Zugangsdatendiebstahl konsistente Beiträge zu Remote-Arbeitsvorfällen bleiben.

Wie sichere ich mein Heimnetzwerk für Remote-Arbeit?

Ändern Sie das Standard-Admin-Passwort Ihres Routers zu einem einzigartigen Zugangsdaten von mindestens 16 Zeichen, deaktivieren Sie die Fernverwaltung, wenn sie nicht verwendet wird, und halten Sie die Firmware aktuell. Verwenden Sie WPA3-Verschlüsselung, wenn Ihr Router sie unterstützt. Für Rollen mit höherem Risiko entfernt ein firmeneigener Reiserouter mit vorkonfiguriertem VPN die Konfigurationslast vollständig vom Mitarbeiter.

Was ist Schatten-IT und warum ist sie ein Sicherheitsrisiko für Remote-Teams?

Schatten-IT bezeichnet Anwendungen und Dienste, die Mitarbeiter für die Arbeit nutzen, ohne IT-Genehmigung. Sie ist ein Sicherheitsrisiko, weil Daten, die in nicht genehmigten Tools gespeichert sind, außerhalb von Unternehmenssicherung, Zugriffskontrollen und Prüfprotokollen existieren. Wenn ein Mitarbeiter Arbeitszugangsdaten in einem persönlichen Passwort-Manager speichert oder Dateien über einen Verbraucherdienst teilt, sind diese Daten für die IT unsichtbar und durch Unternehmenssicherheitsrichtlinien ungeschützt.

Verhindert MFA tatsächlich Sicherheitsverletzungen in Remote-Arbeitsumgebungen?

MFA blockiert die Mehrheit der zugangsdatenbasierten Angriffe. Die Forschung von Microsoft beziffert die Reduzierung von Kontokompromittierungen bei Konten mit aktiviertem MFA auf 99,9%. Es verhindert keine Phishing-Klicks, aber es beseitigt das Ergebnis des Zugangsdatendiebstahls — ein gestohlenes Passwort ohne den zweiten Faktor ist für den Kontozugriff nutzlos. FIDO2-Hardware-Schlüssel bieten den stärksten Schutz, da sie von Natur aus phishing-resistent sind.

Wie sollten Remote-Teams Passwörter sicher teilen?

Verwenden Sie einen Passwort-Manager mit tresorvermitteltem Teilen. Der Empfänger erhält Zugriff auf die Zugangsdaten über den Tresor, ohne das Rohpasswort zu sehen. Jedes Zugriffsereignis wird protokolliert und einer individuellen Identität zugeordnet. Wenn der Zugriff widerrufen werden muss — Auftragnehmer-Offboarding, Rollenwechsel, Ausscheiden — ist es eine einzelne Aktion im Tresor, keine manuelle Suche durch den Chat-Verlauf.

Was sind die finanziellen Auswirkungen einer Datenpanne bei Remote-Arbeit?

Der Cost of a Data Breach Report von IBM (2025) beziffert die globalen durchschnittlichen Kosten einer Datenpanne auf 4,44 Millionen Dollar, wobei US-Datenpannen durchschnittlich 10,22 Millionen Dollar kosten. Remote-Arbeit als beitragender Faktor erhöht die Kosten einer Datenpanne weiter. Datenpannen mit gestohlenen oder kompromittierten Zugangsdaten brauchen am längsten zur Behebung — laut IBM durchschnittlich 292 Tage Lebenszyklus — was die Gesamtkosten direkt in die Höhe treibt.

Was bedeutet „reibungslose Sicherheit" für Remote-Teams?

Reibungslose Sicherheit bedeutet, Kontrollen so zu gestalten, dass die sichere Option die einfachste Option ist. Wenn ein Passwort-Manager schneller ist als Slack für das Teilen von Zugangsdaten, nutzen Mitarbeiter den Passwort-Manager. Wenn VPN sich automatisch in nicht vertrauenswürdigen Netzwerken verbindet, umgehen Mitarbeiter es nicht. Sicherheit versagt, wenn sie bewussten Aufwand erfordert. Das Ziel ist, sicheres Verhalten zum Weg des geringsten Widerstands zu machen.

Schatten-IT vs. Schatten-KI: Warum KI die größere Bedrohung ist

Mitarbeiter nutzen KI-Tools, die Sie nicht genehmigt haben, mit Konten, die Sie nicht überwachen können, mit Daten, die Sie nicht wiederherstellen können. So sieht das Risiko tatsächlich aus und was Governance adressieren muss.

Passwork BlogAlex Muntyan

Brute-Force-Angriffe 2026: Arten, Beispiele und wie man sie verhindert

GPU-Cluster, KI-unterstützte Wortlisten, Botnets mit 2,8 Millionen Geräten. Brute Force hat skaliert. Dieser Leitfaden behandelt sechs Angriffsvarianten, reale Fälle aus 2025 und eine mehrschichtige Verteidigungsstrategie, die Ihr Team heute implementieren kann.

Passwork BlogAlex Muntyan

Unsichere Passwortweitergabe: Risiken 2026 und sichere Lösungen

Jedes Mal, wenn Zugangsdaten über Slack oder E-Mail übertragen werden, verlieren Sie Verantwortlichkeit, Prüfprotokoll und Compliance-Haltung in einem Schritt. Dieser Leitfaden behandelt die realen Risiken unsicherer Passwortweitergabe 2026, warum Mitarbeiter es trotzdem tun und wie Sie auf tresorvermittelten Zugriff umstellen, ohne Ihr Team zu stören.

Passwork BlogAlex Muntyan

El trabajo remoto no creó nuevos vectores de ataque — dispersó los existentes a través de miles de oficinas domésticas, dispositivos personales y routers de grado consumidor. El DBIR 2026 de Verizon sitúa las vulnerabilidades de software en la cima de la lista de vectores de entrada de brechas, representando el 31% de los incidentes, con ransomware involucrado en el 48% de los casos. La superficie de ataque no cambió en naturaleza. Cambió en escala y distribución.

La mayoría de estas brechas comienzan con una contraseña de router predeterminada, un mensaje de Slack que contiene credenciales o un empleado que se saltó la VPN porque era lenta.

La seguridad falla cuando es más difícil hacer lo correcto que lo incorrecto. Cada error descrito a continuación describe el fallo real, por qué ocurre y cómo es una solución realista.

Error 1: El router doméstico no asegurado (credenciales predeterminadas)

Los routers domésticos vienen con credenciales de administrador predeterminadas que están documentadas públicamente. Los atacantes escanean constantemente interfaces de gestión de routers expuestas. Un router comprometido le da al atacante una posición entre el empleado y cada sistema al que accede — incluyendo VPNs corporativas y servicios en la nube.

Por qué ocurre

La mayoría de los empleados nunca cambian la contraseña predeterminada porque nadie les dijo que lo hicieran, y el router «simplemente funciona». Ese es el problema de fricción: la acción segura requiere un esfuerzo deliberado que el dispositivo nunca solicita.

La solución

Distribuya una guía de hardening de routers de una página a todos los empleados remotos. Debe cubrir tres cosas: cambiar la contraseña de administrador (mínimo 16 caracteres, única), desactivar la gestión remota si no se usa y actualizar el firmware. La guía de seguridad de redes domésticas de CISA es un buen punto de partida. Para roles de mayor riesgo, considere proporcionar routers de viaje gestionados por la empresa con configuraciones pre-reforzadas.

Error 2: Compartir contraseñas de forma insegura vía chat y correo electrónico

Un desarrollador necesita credenciales de base de datos. La vía más rápida es Slack. Un contratista necesita una cuenta de administrador. El correo electrónico funciona. Finanzas guarda el login de nóminas en una hoja de cálculo compartida. Cada uno de estos traspasos crea una credencial que existe fuera de cualquier sistema controlado — en registros de chat, archivos de correo electrónico e historiales de hojas de cálculo que nadie está auditando.

Por qué ocurre

El problema es que la bóveda corporativa es más difícil de usar que Slack. Cuando la vía segura tiene más fricción que la insegura, la insegura gana siempre.

La solución

Haga que compartir a través de la bóveda sea la opción más fácil. Con un gestor de contraseñas correctamente configurado, un usuario puede compartir acceso a una credencial sin que el destinatario vea nunca la contraseña en texto plano. Cada evento de acceso queda registrado y vinculado a una identidad individual. Cuando termina el contrato del colaborador externo, se revoca el acceso una sola vez — sin necesidad de buscar en el historial de chat para averiguar qué se le envió.

Error 3: Mezclar dispositivos personales y de trabajo (BYOD sin controles)

Las políticas de traer-su-propio-dispositivo (BYOD) ahorran costes de hardware. También colocan credenciales corporativas en máquinas que ejecutan extensiones de navegador personales, cuentas familiares y software que TI nunca ha visto. La superficie de ataque no es la red corporativa — es el portátil personal del empleado que también ejecuta un juego crackeado y un navegador desactualizado.

Por qué ocurre

Las organizaciones aceptan el riesgo BYOD sin cuantificarlo. El dispositivo sobre el que TI no tiene ninguna visibilidad es el mismo dispositivo que accede a sistemas de producción, correo corporativo y almacenamiento en la nube. Nadie lo señala porque nada ha salido mal todavía.

La solución

Si BYOD es inevitable, aplique estándares mínimos: cifrado del dispositivo, requisitos de versión de SO y una solución de gestión de dispositivos móviles (MDM) que pueda borrar datos corporativos sin tocar los archivos personales. Separe la actividad laboral de la personal al menos a nivel de perfil de navegador. Para roles con privilegios elevados, proporcione dispositivos de trabajo dedicados. El coste de un endpoint gestionado es una fracción del coste de una brecha que comenzó en una máquina personal.

Error 4: Fugas por compartir pantalla y notificaciones

Una llamada de Zoom está en curso. Aparece una notificación de Slack que contiene un enlace de restablecimiento de contraseña. Una pantalla compartida muestra una terminal abierta con credenciales visibles. Estos casos están documentados en comunidades de administradores de sistemas como precursores reales de brechas.

Por qué ocurre

Los fallos de privacidad durante el compartir pantalla se tratan como accidentes vergonzosos, no como incidentes de seguridad. No hay alerta, no hay entrada en el registro, no se activa ninguna violación de política. Los datos simplemente se filtran.

La solución

Configure los ajustes de notificaciones para ocultar las vistas previas de mensajes durante el uso compartido de pantalla. Cierre las pestañas y terminales sensibles antes de compartir su pantalla — hágalo un hábito, no una reacción. En macOS, «No Molestar» suprime las vistas previas de notificaciones. En Windows, Asistente de concentración hace lo mismo. Estos son cambios de configuración de 30 segundos. Inclúyalos en la documentación de incorporación de trabajo remoto para que los empleados los configuren el primer día, no después del primer incidente.

Error 5: Descuidar la autenticación multifactor (MFA)

Sin MFA, una contraseña filtrada es suficiente para obtener acceso completo a la cuenta. La investigación de seguridad de Microsoft sitúa la reducción del compromiso de cuentas con MFA en el 99,9%. A pesar de ello, la adopción sigue siendo inconsistente — particularmente en herramientas internas y sistemas heredados que «no lo soportan».

Por qué ocurre

MFA añade un paso. Los empleados encuentran formas de evitar pasos que los ralentizan. La brecha rara vez es técnica — es conductual. Y cuando la aplicación se deja a las aplicaciones individuales en lugar de a un proveedor de identidad central, la cobertura siempre es incompleta.

La solución

Aplique MFA a nivel del proveedor de identidad. Cuando SSO gestiona la autenticación, MFA se aplica automáticamente a todo lo que hay detrás. Para sistemas que no pueden integrarse con SSO, use llaves de seguridad hardware (FIDO2/WebAuthn) para cuentas privilegiadas — son resistentes al phishing de una manera que los códigos TOTP no lo son. Documente qué sistemas están exentos de MFA y trate esa lista como un elemento del registro de riesgos, no como un estado permanente.

Error 6: Conectarse a Wi-Fi público sin VPN

El Wi-Fi de una cafetería es un dominio de difusión compartido. Cualquiera en la misma red puede observar el tráfico no cifrado. La mayoría del tráfico HTTPS moderno está cifrado en tránsito, pero las consultas DNS, las aplicaciones no cifradas y los metadatos aún pueden filtrarse. Más prácticamente, las redes públicas son un vector común para ataques de gemelo malvado — puntos de acceso falsos que imitan redes legítimas e interceptan todo lo que pasa a través de ellos.

Por qué ocurre

La red se conecta, el portátil funciona, nada parece mal. No hay señal visible de que el tráfico está siendo observado o de que el punto de acceso es falso. El riesgo es invisible hasta que deja de serlo.

La solución

Exija el uso de VPN en cualquier red que no sea doméstica como política no negociable. Las VPNs de túnel dividido que enrutan solo el tráfico corporativo son aceptables — reducen la latencia sin exponer los datos corporativos a la red abierta. Para empleados que viajan frecuentemente, un router de viaje hardware con VPN siempre activa elimina la decisión por completo. La opción segura se convierte en la predeterminada.

Error 7: Ignorar las actualizaciones de software y el parcheo

El DBIR 2026 de Verizon identifica las vulnerabilidades de software como el principal vector de entrada de brechas con un 31%. Los endpoints sin parchear son la razón principal. El portátil de un empleado remoto ejecutando una versión de SO de hace seis meses es una vulnerabilidad documentada con un CVE público, no un riesgo teórico.

Por qué ocurre

Los avisos de actualización automática interrumpen el trabajo. Los empleados hacen clic en «recordar más tarde» indefinidamente. Nadie hace seguimiento. Seis meses después, el endpoint está ejecutando software con una docena de exploits publicados y un parche que ha estado disponible desde el primer trimestre.

La solución

Elimine la elección. Aplique actualizaciones automáticas a través de MDM o política de grupo. Establezca una ventana de aplazamiento máximo — 72 horas es razonable para la mayoría de los parches, 24 horas para parches de seguridad críticos. Para software de terceros, use una herramienta de gestión de parches en lugar de depender de que las aplicaciones individuales se actualicen solas.

Trate los endpoints sin parchear como un problema de cumplimiento, no como una preferencia del usuario. Si un dispositivo supera la ventana de aplazamiento, bloquee su acceso VPN hasta que esté actualizado. Ese único cambio de política tiende a corregir el comportamiento más rápido que cualquier formación.

Error 8: Caer en phishing e ingeniería social

El Informe de Tendencias de Phishing 2026 de Hoxhunt rastreó más de 50 millones de ataques reales y simulados en 4 millones de usuarios y encontró un aumento de 14x en el phishing generado por IA durante finales de 2025 — su participación en todos los ataques reportados saltó del 4% al 56% en un solo mes. El DBIR 2026 confirma que el elemento humano sigue siendo central en la causación de brechas.

Por qué ocurre

Los trabajadores remotos están más expuestos que los trabajadores de oficina. No hay un colega al que preguntar «¿recibiste este correo también?» El servicio de soporte de TI es un ticket, no una persona al final del pasillo. La fricción de verificación es alta, hacer clic es rápido.

La solución

La formación en concienciación de seguridad debe ser actual y específica, no una casilla de verificación de cumplimiento anual. Las campañas de phishing simulado con retroalimentación inmediata son más efectivas que los módulos de formación pasiva. Técnicamente, los registros DMARC, DKIM y SPF reducen el volumen de correos electrónicos falsificados.

Para objetivos de alto valor, las llaves de seguridad hardware eliminan el resultado de robo de credenciales de un phishing exitoso — incluso si el empleado hace clic en el enlace, no hay contraseña que robar. Para los equipos de soporte específicamente, aplique protocolos de verificación de identidad antes de cualquier acción en la cuenta: una llamada de vuelta a un número conocido, no un número que proporciona el llamante.

Error 9: Shadow IT y herramientas cloud no autorizadas

El Work Trend Index 2024 de Microsoft y LinkedIn encontró que el 78% de los empleados ya usan herramientas de IA personales en el trabajo — la mayoría sin aprobación de TI. El impulsor siempre es la fricción: la herramienta aprobada es más lenta, más difícil de acceder o le falta una función que el empleado necesita.

Por qué ocurre

El shadow IT no es un problema de disciplina. Es una señal de que el conjunto de herramientas aprobadas tiene carencias. Los datos almacenados en un Google Drive personal, las credenciales gestionadas en un gestor de contraseñas personal, los archivos compartidos a través de un servicio de consumo — todo esto existe fuera de la visibilidad corporativa, las copias de seguridad y los controles de acceso. TI no sabe que los datos están ahí hasta que algo sale mal.

La solución

Audite el shadow IT antes de prohibirlo. Comprenda qué están usando los empleados y por qué. En muchos casos, la solución es mejorar la herramienta aprobada o añadir una alternativa autorizada — no otro memorando de política que nadie lee.

Para la gestión de credenciales específicamente: si los empleados están almacenando contraseñas de trabajo en herramientas personales, la bóveda corporativa les está fallando de alguna manera. La incorporación es demasiado compleja, el acceso es demasiado lento o la herramienta no encaja en su flujo de trabajo. Corrija la herramienta. La política por sí sola nunca ha vencido a la conveniencia.

Error 10: Almacenamiento local y copias de seguridad sin cifrar

Los empleados remotos acumulan datos sensibles en máquinas locales: exportaciones de bases de datos, listas de credenciales, archivos de configuración con claves API, archivos de copias de seguridad. Cuando esos datos permanecen sin cifrar en el disco duro de un portátil, un dispositivo robado o perdido se convierte en una brecha de datos completa — sin necesidad de acceso a la red.

Por qué ocurre

El cifrado se percibe como una tarea de TI, no una tarea del usuario. Los empleados no piensan en lo que hay en su disco hasta que desaparece. Las copias de seguridad en particular se descuidan: se crean una vez, se almacenan localmente o en una unidad USB personal y nunca se revisan. Nadie audita lo que hay en ~/Downloads o C:\Users\name\Desktop.

La solución

Habilite el cifrado de disco completo por defecto (BitLocker en Windows, FileVault en macOS) aplicado a través de MDM en el aprovisionamiento del dispositivo, no dejado al empleado. Para las copias de seguridad, exija solo destinos cifrados: almacenamiento en la nube corporativo o un servidor de copias de seguridad local.

Las unidades USB personales y los discos externos sin cifrar deben bloquearse por política. Ejecute una auditoría periódica de qué datos están almacenando los empleados localmente y por qué. En la mayoría de los casos, los archivos sensibles en unidades locales están ahí porque la opción de almacenamiento aprobada era inconveniente.

Cómo construir un entorno remoto seguro: las soluciones que realmente funcionan

Los 10 errores anteriores comparten un hilo común. La seguridad se rompe en el punto donde hacer lo correcto requiere más esfuerzo que hacer lo incorrecto. Arreglar el entorno significa reducir esa fricción — no solo añadir más políticas que los empleados evitan.

Un marco de remediación práctico para equipos de TI — la base de seguridad remota de 5 capas

1. Capa de identidad — MFA aplicado en el IdP, SSO cubriendo todas las aplicaciones principales, llaves hardware para cuentas privilegiadas.
2. Capa de credenciales — Gestor de contraseñas centralizado con compartición mediada por bóveda, RBAC a nivel de grupo, baja automatizada vinculada a cambios en el directorio.
3. Capa de endpoint — Cifrado aplicado por MDM, parcheo automático, política de bloqueo de pantalla, estándares mínimos de BYOD.
4. Capa de red — VPN obligatoria en redes que no sean domésticas, filtrado DNS, guía de hardening de router para todos los empleados remotos.
5. Capa de concienciación — Simulaciones de phishing regulares, formación actualizada que refleje las amenazas actuales mejoradas con IA, una ruta de escalado clara para actividad sospechosa.

Ninguna de estas capas funciona de forma aislada. Un empleado con MFA y un portátil parcheado que comparte credenciales por Slack tiene una brecha en la capa 2. Un empleado con una bóveda segura que se conecta a Wi-Fi público sin VPN tiene una brecha en la capa 4.

Para equipos que gestionan cuentas privilegiadas en una fuerza laboral distribuida, la capa de credenciales merece especial atención. Los riesgos de gestionar credenciales administrativas de forma remota se acumulan rápidamente cuando el acceso privilegiado no está centralizado y auditado.

Conclusión

Los 10 errores anteriores son los mismos fallos que aparecen en los informes post-mortem de brechas año tras año, ahora distribuidos en oficinas domésticas donde TI tiene menos visibilidad y los empleados tienen más autonomía. El patrón es consistente: la seguridad se rompe en el punto de fricción.

La base de 5 capas anterior proporciona a su equipo una forma estructurada de auditar dónde están esos puntos de fricción. Comience con la capa de credenciales — es donde se originan las brechas más prevenibles, y es donde un gestor de contraseñas bien desplegado se amortiza más rápido.

Preguntas frecuentes sobre seguridad en el trabajo remoto

¿Cuáles son los errores de seguridad en el trabajo remoto más comunes?

Los errores de seguridad en el trabajo remoto más comunes son compartir contraseñas de forma insegura (vía chat o correo electrónico), endpoints sin parchear, MFA ausente y conectarse a Wi-Fi público sin VPN. El DBIR 2026 de Verizon identifica las vulnerabilidades de software como el principal vector de entrada de brechas con un 31%, mientras que el phishing y el robo de credenciales siguen siendo contribuyentes consistentes a los incidentes de trabajo remoto.

¿Cómo aseguro mi red doméstica para el trabajo remoto?

Cambie la contraseña de administrador predeterminada de su router por una credencial única de al menos 16 caracteres, desactive la gestión remota si no se usa y mantenga el firmware actualizado. Use cifrado WPA3 si su router lo soporta. Para roles de mayor riesgo, un router de viaje proporcionado por la empresa con una VPN preconfigurada elimina la carga de configuración del empleado por completo.

¿Qué es el shadow IT y por qué es un riesgo de seguridad para los equipos remotos?

El shadow IT se refiere a aplicaciones y servicios que los empleados usan para el trabajo sin aprobación de TI. Es un riesgo de seguridad porque los datos almacenados en herramientas no autorizadas existen fuera de las copias de seguridad corporativas, los controles de acceso y las pistas de auditoría. Si un empleado almacena credenciales de trabajo en un gestor de contraseñas personal o comparte archivos a través de un servicio de consumo, esos datos son invisibles para TI y no están protegidos por las políticas de seguridad corporativas.

¿MFA realmente previene brechas en entornos de trabajo remoto?

MFA bloquea la mayoría de los ataques basados en credenciales. La investigación de Microsoft sitúa la reducción del compromiso de cuentas en el 99,9% para cuentas con MFA habilitado. No previene los clics en phishing, pero elimina el resultado de robo de credenciales — una contraseña robada sin el segundo factor es inútil para acceder a la cuenta. Las llaves hardware FIDO2 proporcionan la protección más fuerte porque son resistentes al phishing por diseño.

¿Cómo deben los equipos remotos manejar el compartir contraseñas de forma segura?

Use un gestor de contraseñas con compartición mediada por bóveda. El destinatario obtiene acceso a la credencial a través de la bóveda sin ver la contraseña en texto plano. Cada evento de acceso queda registrado y vinculado a una identidad individual. Cuando el acceso necesita ser revocado — baja de contratista, cambio de rol, salida — es una sola acción en la bóveda, no una búsqueda manual en el historial de chat.

¿Cuál es el impacto financiero de una brecha de datos en el trabajo remoto?

El Cost of a Data Breach Report de IBM (2025) sitúa el coste medio global de una brecha en 4,44 millones de dólares, con las brechas en EE. UU. promediando 10,22 millones de dólares. El trabajo remoto como factor contribuyente aumenta aún más los costes de las brechas. Las brechas que involucran credenciales robadas o comprometidas tardan más en resolverse — un ciclo de vida promedio de 292 días según IBM — lo que aumenta directamente el coste total.

¿Qué significa «seguridad sin fricción» para los equipos remotos?

Seguridad sin fricción significa diseñar controles para que la opción segura sea la más fácil. Cuando un gestor de contraseñas es más rápido que Slack para compartir credenciales, los empleados usan el gestor de contraseñas. Cuando la VPN se conecta automáticamente en redes no confiables, los empleados no la evitan. La seguridad falla cuando requiere un esfuerzo deliberado. El objetivo es hacer que el comportamiento seguro sea el camino de menor resistencia.

Shadow IT vs Shadow AI: Por qué la IA es la mayor amenaza

Los empleados están usando herramientas de IA que usted no aprobó, en cuentas que no puede monitorear, con datos que no puede recuperar. Aquí está cómo es realmente el riesgo y qué debe abordar la gobernanza.

Passwork BlogAlex Muntyan

Ataques de fuerza bruta en 2026: Tipos, ejemplos y cómo prevenirlos

Clústeres de GPU, listas de palabras asistidas por IA, botnets de 2,8 millones de dispositivos. La fuerza bruta ha escalado. Esta guía cubre seis variantes de ataque, casos reales de 2025 y una estrategia de defensa en capas que su equipo puede implementar hoy.

Passwork BlogAlex Muntyan

Compartir contraseñas de forma insegura: Riesgos y soluciones seguras en 2026

Cada vez que una credencial se mueve a través de Slack o correo electrónico, pierde responsabilidad, pista de auditoría y postura de cumplimiento en un solo paso. Esta guía cubre los riesgos reales de compartir contraseñas de forma insegura en 2026, por qué los empleados lo hacen de todos modos y cómo migrar al acceso mediado por bóveda sin interrumpir a su equipo.

Passwork BlogAlex Muntyan

Remote work didn't create new attack vectors — it scattered existing ones across thousands of home offices, personal devices, and consumer-grade routers. Verizon's 2026 DBIR puts software vulnerabilities at the top of the breach entry vector list, accounting for 31% of incidents, with ransomware involved in 48% of cases. The attack surface didn't change in kind. It changed in scale and distribution.

Most of these breaches start with a default router password, a Slack message containing credentials, or an employee who skipped the VPN because it was slow.

Security fails when it's harder to do the right thing than the wrong thing. Each fail below describes the actual mistake, why it happens, and what a realistic fix looks like.

Fail 1: The unsecured home router (default credentials)

Home routers ship with default admin credentials that are publicly documented. Attackers scan for exposed router management interfaces constantly. A compromised router gives an attacker a position between the employee and every system they access — including corporate VPNs and cloud services.

Why it happens

Most employees never change the default password because nobody told them to, and the router "just works." That's the friction problem: the secure action requires deliberate effort that the device never prompts for.

The fix

Push a one-page router hardening guide to all remote employees. It should cover three things: change the admin password (minimum 16 characters, unique), disable remote management if unused, and update the firmware. CISA's home network security guidance is a solid starting point. For higher-risk roles, consider issuing company-managed travel routers with pre-hardened configurations.

Fail 2: Insecure password sharing via chat and email

A developer needs database credentials. The fastest path is Slack. A contractor needs an admin account. Email works. Finance keeps the payroll login in a shared spreadsheet. Each of these handoffs creates a credential that exists outside any controlled system — in chat logs, email archives, and spreadsheet histories that nobody is auditing.

Why it happens

The problem is that the corporate vault is harder to use than Slack. When the secure path has more friction than the insecure one, the insecure one wins every time.

The fix

Make vault-mediated sharing the easiest option. With a properly configured password manager, a user can share access to a credential without the recipient ever seeing the raw password. Every access event is logged and tied to an /individual identity. When the contractor's engagement ends, you revoke access once — no hunting through chat history to figure out what they were sent.

Fail 3: Mixing personal and work devices (BYOD without controls)

Bring-your-own-device (BYOD) policies save hardware costs. They also put corporate credentials on machines running personal browser extensions, family accounts, and software that IT has never seen. The attack surface isn't the corporate network — it's the employee's personal laptop that also runs a cracked game and an outdated browser.

Why it happens

Organizations accept BYOD risk without quantifying it. The device IT has zero visibility into is the same device accessing production systems, corporate email, and cloud storage. Nobody flags it because nothing has gone wrong yet.

The fix

If BYOD is unavoidable, enforce minimum standards: device encryption, OS version requirements, and a mobile device management (MDM) solution that can wipe corporate data without touching personal files. Separate work and personal activity at the browser profile level at minimum. For high-privilege roles, issue dedicated work devices. The cost of a managed endpoint is a fraction of the cost of a breach that started on a personal machine.

Fail 4: Screen sharing and notification leaks

A Zoom call is running. A Slack notification pops up containing a password reset link. A screen share shows an open terminal with credentials visible. These are documented in sysadmin communities as real breach precursors.

Why it happens

Privacy failures during screen sharing get treated as embarrassing accidents, not security incidents. There's no alert, no log entry, no policy violation triggered. The data just leaves.

The fix

Configure notification settings to hide message previews during screen sharing. Close sensitive tabs and terminals before sharing your screen — make it a habit, not a reaction. On macOS, "Do Not Disturb" suppresses notification previews. On Windows, Focus Assist does the same. These are 30-second configuration changes. Put them in remote work onboarding documentation so employees set them up on day one, not after the first incident.

Fail 5: Neglecting multi-factor authentication (MFA)

Without MFA, one leaked password is enough for full account access. Microsoft's security research puts account compromise reduction from MFA at 99.9%. Despite that, adoption remains inconsistent — particularly on internal tools and legacy systems that "don't support it."

Why it happens

MFA adds a step. Employees find ways around steps that slow them down. The gap is rarely technical — it's behavioral. And when enforcement is left to individual applications rather than a central identity provider, coverage is always incomplete.

The fix

Enforce MFA at the identity provider level. When SSO handles authentication, MFA applies to everything downstream automatically. For systems that can't integrate with SSO, use hardware security keys (FIDO2/WebAuthn) for privileged accounts — they're phishing-resistant in a way that TOTP codes are not. Document which systems are MFA-exempt and treat that list as a risk register item, not a permanent state.

Fail 6: Connecting to public Wi-Fi without a VPN

Coffee shop Wi-Fi is a shared broadcast domain. Anyone on the same network can observe unencrypted traffic. Most modern HTTPS traffic is encrypted in transit, but DNS queries, unencrypted applications, and metadata can still leak. More practically, public networks are a common vector for evil twin attacks — rogue access points that mimic legitimate networks and intercept everything that passes through them.

Why it happens

The network connects, the laptop works, nothing looks wrong. There's no visible signal that traffic is being observed or that the access point is fake. The risk is invisible until it isn't.

The fix

Require VPN use on any non-home network as a non-negotiable policy. Split-tunnel VPNs that route only corporate traffic are fine — they reduce latency without exposing corporate data to the open network. For employees who travel frequently, a hardware travel router with always-on VPN removes the decision entirely. The secure option becomes the default.

Fail 7: Ignoring software updates and patching

Verizon's 2026 DBIR identifies software vulnerabilities as the top breach entry vector at 31%. Unpatched endpoints are the primary reason. A remote employee's laptop running a six-month-old OS version is a documented vulnerability with a public CVE, not a theoretical risk.

Why it happens

Auto-update prompts interrupt work. Employees click "remind me later" indefinitely. Nobody follows up. Six months later, the endpoint is running software with a dozen published exploits and a patch that's been available since Q1.

The fix

Remove the choice. Enforce automatic updates through MDM or group policy. Set a maximum deferral window — 72 hours is reasonable for most patches, 24 hours for critical security patches. For third-party software, use a patch management tool rather than relying on individual applications to self-update.

Treat unpatched endpoints as a compliance issue, not a user preference. If a device misses the deferral window, block its VPN access until it's current. That one policy change tends to fix the behavior faster than any training.

Fail 8: Falling for phishing and social engineering

Hoxhunt's 2026 Phishing Trends Report tracked over 50 million real and simulated attacks across 4 million users and found a 14x surge in AI-generated phishing during late 2025 — their share of all reported attacks jumped from 4% to 56% in a single month. The 2026 DBIR confirms the human element remains central to breach causation.

Why it happens

Remote workers are more exposed than office workers. There's no colleague to ask "did you get this email too?" The IT helpdesk is a ticket, not a person down the hall. Verification friction is high, clicking is fast.

The fix

Security awareness training needs to be current and specific, not a once-a-year compliance checkbox. Simulated phishing campaigns with immediate feedback are more effective than passive training modules. Technically, DMARC, DKIM, and SPF records reduce spoofed email volume.

For high-value targets, hardware security keys eliminate the credential-theft outcome of a successful phish — even if the employee clicks the link, there's no password to steal. For helpdesk teams specifically, enforce identity verification protocols before any account action: a callback to a known number, not a number the caller provides.

Fail 9: Shadow IT and unsanctioned cloud tools

Microsoft and LinkedIn's 2024 Work Trend Index found that 78% of employees already use personal AI tools on the job — most without IT approval. The driver is always friction: the approved tool is slower, harder to access, or missing a feature the employee needs.

Why it happens

Shadow IT isn't a discipline problem. It's a signal that the approved toolset has gaps. Data stored in a personal Google Drive, credentials managed in a personal password manager, files shared via a consumer service — all of these exist outside corporate visibility, backup, and access controls. IT doesn't know the data is there until something goes wrong.

The fix

Audit shadow IT before mandating against it. Understand what employees are using and why. In many cases, the fix is improving the approved tool or adding a sanctioned alternative — not another policy memo that nobody reads.

For credential management specifically: if employees are storing work passwords in personal tools, the corporate vault is failing them somehow. The onboarding is too complex, access is too slow, or the tool doesn't fit their workflow. Fix the tool. Policy alone has never beaten convenience.

Fail 10: Unencrypted local storage and backups

Remote employees accumulate sensitive data on local machines: database exports, credential lists, config files with API keys, backup archives. When that data sits unencrypted on a laptop's hard drive, a stolen or lost device becomes a full data breach — no network access required.

Why it happens

Encryption feels like an IT task, not a user task. Employees don't think about what's on their drive until it's gone. Backups in particular get neglected: they're created once, stored locally or on a personal USB drive, and never revisited. Nobody audits what's sitting in ~/Downloads or C:\Users\name\Desktop.

The fix

Enable full-disk encryption by default (BitLocker on Windows, FileVault on macOS) enforced through MDM at device provisioning, not left to the employee. For backups, require encrypted destinations only: corporate cloud storage or an on-premises backup server.

Personal USB drives and unencrypted external disks should be blocked by policy. Run a periodic audit of what data employees are storing locally and why. In most cases, sensitive files on local drives are there because the approved storage option was inconvenient.

How to build a secure remote environment: the fixes that actually stick

The 10 fails above share a common thread. Security breaks down at the point where doing the right thing requires more effort than doing the wrong thing. Fixing the environment means reducing that friction — not just adding more policies that employees route around.

A practical remediation framework for IT teams — the 5-layer remote security baseline

1. Identity layer — MFA enforced at the IdP, SSO covering all major applications, hardware keys for privileged accounts.
2. Credential layer — Centralized password manager with vault-mediated sharing, RBAC at the group level, automated offboarding tied to directory changes.
3. Endpoint layer — MDM-enforced encryption, automatic patching, screen lock policy, BYOD minimum standards.
4. Network layer — Required VPN on non-home networks, DNS filtering, router hardening guide for all remote employees.
5. Awareness layer — Regular phishing simulations, updated training that reflects current AI-enhanced threats, a clear escalation path for suspicious activity.

None of these layers work in isolation. An employee with MFA and a patched laptop who shares credentials over Slack has a gap at layer 2. An employee with a secure vault who connects to public Wi-Fi without a VPN has a gap at layer 4.

For teams managing privileged accounts across a distributed workforce, the credential layer deserves particular attention. The risks of managing administrative credentials remotely compound quickly when privileged access isn't centralized and audited.

Conclusion

The 10 fails above are the same mistakes that show up in breach post-mortems year after year, now distributed across home offices where IT has less visibility and employees have more autonomy. The pattern is consistent: security breaks at the friction point.

The 5-layer baseline above gives your team a structured way to audit where those friction points are. Start with the credential layer — it's where the most preventable breaches originate, and it's where a well-deployed password manager pays for itself fastest.

Frequently asked questions about remote work security

What are the most common remote work security fails?

The most common remote work security fails are insecure password sharing (via chat or email), unpatched endpoints, missing MFA, and connecting to public Wi-Fi without a VPN. Verizon's 2026 DBIR identifies software vulnerabilities as the top breach entry vector at 31%, while phishing and credential theft remain consistent contributors to remote-work incidents.

How do I secure my home network for remote work?

Change your router's default admin password to a unique credential of at least 16 characters, disable remote management if unused, and keep the firmware updated. Use WPA3 encryption if your router supports it. For higher-risk roles, a company-issued travel router with a pre-configured VPN removes the configuration burden from the employee entirely.

What is shadow IT and why is it a security risk for remote teams?

Shadow IT refers to applications and services employees use for work without IT approval. It's a security risk because data stored in unsanctioned tools exists outside corporate backup, access controls, and audit trails. If an employee stores work credentials in a personal password manager or shares files via a consumer service, that data is invisible to IT and unprotected by corporate security policies.

Does MFA actually prevent breaches in remote work environments?

MFA blocks the majority of credential-based attacks. Microsoft's research puts the reduction in account compromise at 99.9% for accounts with MFA enabled. It doesn't prevent phishing clicks, but it removes the credential-theft outcome — a stolen password without the second factor is useless for account access. FIDO2 hardware keys provide the strongest protection because they're phishing-resistant by design.

How should remote teams handle password sharing securely?

Use a password manager with vault-mediated sharing. The recipient gets access to the credential through the vault without seeing the raw password. Every access event is logged and tied to an individual identity. When access needs to be revoked — contractor offboarding, role change, departure — it's a single action in the vault, not a manual hunt through chat history.

What is the financial impact of a remote work data breach?

IBM's Cost of a Data Breach Report (2025) puts the global average breach cost at $4.44 million, with US breaches averaging $10.22 million. Remote work as a contributing factor increases breach costs further. Breaches involving stolen or compromised credentials take the longest to resolve — an average 292-day lifecycle according to IBM — which directly drives up total cost.

What does "frictionless security" mean for remote teams?

Frictionless security means designing controls so the secure option is the easiest option. When a password manager is faster than Slack for sharing credentials, employees use the password manager. When VPN connects automatically on untrusted networks, employees don't bypass it. Security fails when it requires deliberate effort. The goal is to make secure behavior the path of least resistance.

Shadow IT vs Shadow AI: Why AI is the bigger threat

Employees are using AI tools you didn’t approve, on accounts you can’t monitor, with data you can’t recover. Here’s what the risk actually looks like and what governance needs to address.

Passwork BlogAlex Muntyan

Brute force attacks in 2026: Types, examples & how to prevent them

GPU clusters, AI-assisted wordlists, botnets of 2.8M devices. Brute force has scaled. This guide covers six attack variants, real-world cases from 2025, and a layered defense strategy your team can implement today.

Passwork BlogAlex Muntyan

Insecure password sharing: 2026 risks and secure solutions

Every time a credential moves through Slack or email, you lose accountability, audit trail, and compliance posture in one step. This guide covers the real risks of insecure password sharing in 2026, why employees do it anyway, and how to migrate to vault-mediated access without disrupting your team.

Passwork BlogAlex Muntyan

Wenn ein Mitarbeiter das Unternehmen verlässt, sieht das Standardvorgehen so aus: HR schließt das Ticket, die IT deaktiviert das Active Directory-Konto, der Laptop kommt zurück ins Regal. Erledigt. Aber 2026 reicht das nicht mehr aus. Außerhalb des SSO-Perimeters existieren KI-Agenten, die auf lokal gespeicherten API-Schlüsseln laufen, Service-Accounts ohne Eigentümer, geteilte Passwörter, die kein IdP jemals widerrufen wird, und Compliance-Fenster, die in Stunden gemessen werden.

Dieser Leitfaden bietet IT-Administratoren und Sicherheitsteams einen strukturierten, umsetzbaren Ansatz für die Zugriffsentziehung, der all dies abdeckt.

Die wichtigsten Erkenntnisse

• Ein SSO-Konto zu deaktivieren ist nicht dasselbe wie Zugriff zu entziehen. API-Schlüssel, geteilte Passwörter und lokal gespeicherte Token überleben die IdP-Deaktivierung vollständig.
• Die meisten Offboarding-Checklisten übersehen KI-Agenten-Anmeldedaten komplett. MCP-verbundene Tools speichern API-Schlüssel außerhalb des SSO-Perimeters und erfordern explizite Widerrufsschritte.
• Nur 20 % der Organisationen haben formelle Prozesse für den Widerruf von API-Schlüsseln, wenn ein Mitarbeiter ausscheidet. OWASP stuft unsachgemäßes NHI-Offboarding als das höchste Einzelrisiko in seinen Non-Human Identities Top 10 (2025) ein.
• Compliance-Frameworks sind spezifisch und anspruchsvoll. FedRAMP PS-4 setzt ein 4-Stunden-Fenster; SOC 2 CC6.1 und ISO 27001 Anhang A 6.5 behandeln Same-Day-Widerruf als Mindeststandard; NIS2 Artikel 21 und DSGVO Artikel 32 erwarten dasselbe von EU-Organisationen.
• Geteilte Passwörter müssen rotiert werden, nicht nur der Zugriff entzogen. Wenn der Mitarbeiter das Passwort kannte, schließt das alleinige Entfernen der Tresor-Mitgliedschaft die Schwachstelle nicht.
• Vorausschauende Analyse vor dem Austritt macht die Ausführung zum Zeitpunkt null zuverlässig. Ohne die Erfassung jedes Tresors, API-Schlüssels, Service-Accounts und KI-Tool-Zugangsdatums vor dem letzten Tag ist Offboarding von vornherein reaktiv.
• Manuelle, ticket-basierte Prozesse können moderne Widerrufsfristen nicht einhalten. HRIS-zu-IAM-Automatisierung über SCIM ist die einzige Architektur, die das Latenzfenster konsequent eliminiert.

Die verborgenen Risiken verzögerter Zugriffsentziehung

Verzögerte Zugriffsentziehung hat ein vorhersehbares Ergebnis: Ein ehemaliger Mitarbeiter behält funktionierende Anmeldedaten, während Ihr Team davon ausgeht, dass das Konto geschlossen ist. Das Bedrohungsfenster öffnet sich in dem Moment, in dem der Austritt bestätigt wird, und die Konsequenzen reichen von Datenexfiltration bis hin zu regulatorischen Strafen.

Compliance-Fristen werden strenger

Die Dringlichkeit ist jetzt in großen Compliance-Frameworks kodifiziert. ISO 27001:2022 Anhang A 6.5 (Verantwortlichkeiten nach Beendigung oder Änderung des Beschäftigungsverhältnisses) verlangt die umgehende Entfernung von Zugriffsrechten. NIS2 Artikel 21 schreibt angemessene Zugangskontrollmaßnahmen als Teil der grundlegenden Sicherheitshygiene einer Organisation vor. DSGVO Artikel 32 verlangt technische und organisatorische Maßnahmen zum Schutz personenbezogener Daten — und ein aktives Konto eines ehemaligen Mitarbeiters stellt eine direkte Gefährdung unter dieser Verpflichtung dar.

„Informationssicherheitsverantwortlichkeiten und -pflichten, die nach Beendigung oder Änderung des Beschäftigungsverhältnisses gültig bleiben, sollten definiert, durchgesetzt und dem relevanten Personal und anderen interessierten Parteien mitgeteilt werden" — ISO/IEC 27001:2022, Anhang A, Control 6.5

Für Organisationen mit US-Bundesverträgen oder -Kunden haben FedRAMP und StateRAMP die PS-4-Implementierungserwartungen auf ein 4-Stunden-Widerrufsfenster verschärft, gemäß der von Paramify veröffentlichten Compliance-Anleitung. SOC 2 Trust Services Criteria CC6.1 setzt ähnliche Erwartungen bezüglich dokumentierter logischer Zugriffskontrollen, wobei Auditoren Same-Day-Widerruf zunehmend als akzeptablen Mindeststandard behandeln.

In all diesen Frameworks ist die operative Implikation dieselbe: Manuelle, ticket-basierte Offboarding-Prozesse können diese Fristen nicht zuverlässig einhalten. Ein Prozess, der davon abhängt, dass ein IT-Administrator eine Slack-Nachricht von HR bemerkt, wird scheitern.

Datenexfiltration und Insider-Bedrohungen

Die Angriffsfläche ist spezifisch: CRM-Plattformen mit Kundendaten, Code-Repositories mit proprietärer Logik, Cloud-Storage-Buckets und CI/CD-Pipeline-Anmeldedaten.

Cyberhavens Forschung ergab einen 720%igen Anstieg der Datenexfiltrationsaktivitäten in den 24 Stunden vor einer Entlassung — der größte Teil davon auf persönliche Cloud-Speicher, Wechselmedien und generative KI-Tools. Ein ehemaliger Mitarbeiter, der nach diesem Zeitfenster Zugang behält, muss nicht böswillig sein, um Schaden anzurichten; ein falsch konfiguriertes Skript, das unter seinem noch aktiven Token läuft, reicht aus.

Verizons Data Breach Investigations Report (DBIR) 2026 identifiziert Credential-Missbrauch als verantwortlich für 13 % der Sicherheitsverletzungen — eine Zahl, die sich stark auf Zugriffe konzentriert, die nie ordnungsgemäß entzogen wurden. Das Risiko ist nicht hypothetisch. Ein Entwickler, der ein gültiges Personal Access Token für ein GitHub-Repository behält, kann Wochen nach seinem letzten Tag die gesamte Codebasis klonen.

Offboarding-Blindspots 2026: KI-Agenten und NHIs

Standard-Offboarding-Checklisten (SSO-Konto deaktivieren, VPN widerrufen, Laptop zurückgeben) wurden für ein einfacheres Bedrohungsmodell entwickelt. Zwei Kategorien von Zugriff überleben diese Schritte jetzt routinemäßig vollständig.

Das Problem mit KI-Agenten-Zugriff

Entwickler verbinden 2026 KI-Codierassistenten und Automatisierungstools über das Model Context Protocol (MCP) mit externen Diensten. Diese Integrationen authentifizieren sich mit API-Schlüsseln, die der Entwickler manuell generiert und lokal speichert: in .env-Dateien, Shell-Konfigurationsdateien, IDE-Einstellungen oder im eigenen Credential-Store des KI-Tools auf dem Rechner des Entwicklers.

Wenn Sie das Okta- oder Entra ID-Konto dieses Entwicklers deaktivieren, werden keiner dieser lokal gespeicherten Schlüssel berührt. Die SSO-Schicht wusste nie, dass sie existieren. Wenn der Laptop des Entwicklers nicht umgehend gelöscht wird — oder wenn er einen persönlichen Rechner für die Arbeit verwendet hat — bleiben diese Schlüssel gültig und funktionsfähig. Der API-Schlüssel für Ihre Produktions-Cloud-Umgebung, Ihr Stripe-Konto oder Ihre interne Datenpipeline verfällt nicht, weil die SSO-Sitzung des Mitarbeiters beendet wurde.

Die praktische Lösung erfordert zwei Schritte, die die meisten Offboarding-Checklisten komplett überspringen: Auditieren, welche API-Schlüssel der ausscheidende Mitarbeiter generiert hat (über GitHub, AWS IAM, Cloud-Plattformen und interne Systeme), und jeden einzelnen davon vor dem letzten Tag des Mitarbeiters rotieren oder widerrufen, nicht erst nach der Geräterückgabe.

Verwaiste Non-Human Identities (NHIs)

OWASPs Non-Human Identities Top 10 (2025) platziert Improper Offboarding auf Position NHI1:2025 — das höchste Einzelrisiko im gesamten Framework. Die Definition ist präzise: unzureichende Deaktivierung oder Entfernung von Non-Human Identities wie Service-Accounts, API-Schlüsseln, OAuth-Token und Zertifikaten, wenn der Mensch, der sie erstellt oder verwaltet hat, die Organisation verlässt.

Die Cloud Security Alliance-Berichte, ein Jahr auseinander, zeigen, dass sich das Problem nicht verbessert. In ihrem 2024er State of Non-Human Identity Security-Bericht stellte CSA fest, dass nur 20 % der Organisationen formelle Prozesse für Offboarding und den Widerruf von API-Schlüsseln haben. Das Follow-up 2026, State of Non-Human Identity and AI Security, ergab, dass sich Governance-Lücken vergrößert hatten, da KI-Workloads die Identitätserstellung beschleunigten:

• Weniger als 25 % der Organisationen haben dokumentierte, formell verabschiedete Richtlinien für die Erstellung oder Entfernung von KI-Identitäten.
• Mehr als 16 % verfolgen die Erstellung neuer KI-bezogener Identitäten überhaupt nicht, wodurch eine wachsende Teilmenge von Token und Service-Accounts außerhalb jeglicher formeller Bestandsaufnahme bleibt.
• Nur 12 % der Organisationen berichten von hohem Vertrauen in ihre Fähigkeit, Angriffe über NHIs zu verhindern.

Wenn ein Senior Engineer ausscheidet, arbeiten die von ihm erstellten Service-Accounts, die registrierten Token und die bereitgestellten Zertifikate unbegrenzt weiter.

Das Risiko potenziert sich, weil NHIs routinemäßig überprivilegiert sind. Ein Engineer, der vor drei Jahren breiten Zugang zum Debuggen eines Produktionsproblems benötigte, hat möglicherweise einen Service-Account mit Admin-Berechtigungen erstellt. Dieses Konto ist jetzt eigentümerlos und für Standard-User-Access-Reviews unsichtbar. Legacy-IAM-Tools wurden nicht dafür gebaut — sie verfolgen Menschen, nicht die Anmeldedaten, die Menschen erstellen.

Die Behandlung von NHI-Offboarding erfordert einen dedizierten Discovery-Schritt vor dem Ausscheiden des Mitarbeiters: jeden Service-Account, jedes Token und jedes Zertifikat identifizieren, das mit dieser Person verbunden ist, einen neuen Eigentümer zuweisen und Anmeldedaten rotieren, bei denen der ausscheidende Mitarbeiter alleinige Kenntnis des Geheimnisses hatte.

Wie man geteilte Passwörter beim Offboarding behandelt

Geteilte Anmeldedaten sind die Kategorie, die bei einem Standard-Offboarding-Prozess am wahrscheinlichsten übersehen wird, und die am wahrscheinlichsten danach ausgenutzt wird.

Die Gefahr geteilter Anmeldedaten

Geteilte Passwörter können nicht über zentralisiertes SSO deaktiviert werden. Wenn vier Personen in einem Team einen Login für ein Anbieterportal, eine Netzwerkgeräte-Verwaltungsoberfläche oder eine Legacy-Anwendung teilen, ändert das Deaktivieren des SSO-Kontos einer Person nichts an diesen geteilten Anmeldedaten. Der ausgeschiedene Mitarbeiter kennt das Passwort. Das wird immer so bleiben, es sei denn, es wird geändert.

Das Problem skaliert mit Teamgröße und Betriebszugehörigkeit. Ein langjähriger Mitarbeiter kann Zugang zu Dutzenden geteilter Anmeldedaten haben, die über Jahre angesammelt wurden — Anmeldedaten, die nirgendwo dokumentiert sind, in einer Tabelle auf einem geteilten Laufwerk gespeichert oder nur den Personen bekannt sind, die sie täglich nutzen.

Enterprise-Passwortmanagement für geteilte Tresor-Kontrolle

Hier wird ein dedizierter Enterprise-Passwortmanager operativ unverzichtbar, nicht optional. Wenn geteilte Anmeldedaten in einem strukturierten Tresor mit rollenbasierter Zugriffskontrolle liegen, wird Offboarding zu einem definierten Verfahren statt einem Ratespiel.

Passwork deckt den gesamten Umfang der Offboarding-Credential-Arbeit auf einer einzigen Plattform ab:

• Geteilte Tresor-Mitgliedschaft — Jeder Tresor hat explizite Mitglieder. Das Entfernen eines ausgeschiedenen Mitarbeiters entzieht den Zugang sofort, ohne Abhängigkeit davon, dass er das Passwort vergisst oder sich entscheidet, es nicht wiederzuverwenden.
• Secrets Management — API-Schlüssel, Token, Datenbank-Anmeldedaten und Zertifikate befinden sich neben menschlichen Anmeldedaten in derselben Tresor-Hierarchie unter demselben RBAC-Modell. Kein separater Secrets Manager erforderlich.
• Service-Account-Kontrolle — Service-Accounts werden zentral in Passwork gespeichert und verwaltet. Jedes Konto hat einen zugewiesenen Eigentümer. Wenn dieser Eigentümer ausscheidet, taucht das Konto sofort in der Access Review auf, anstatt stillschweigend zu einer verwaisten Identität ohne Verantwortlichen zu werden.
• Vollständiges Audit-Log — Jede Anmeldedaten, auf die der ausscheidende Mitarbeiter zugegriffen hat, wird aufgezeichnet, was dem Sicherheitsteam eine klare Liste dessen gibt, was rotiert werden muss.
• REST API — Binden Sie Offboarding-Workflows direkt in Ihre HR- oder ITSM-Systeme ein. Lösen Sie den Tresor-Zugriffswiderruf automatisch aus, wenn ein Kündigungs-Ticket erstellt wird, ohne manuelles Eingreifen.
• Rotationsverfolgung — Das Entfernen des Tresor-Zugangs verhindert zukünftigen Zugriff. Der Audit-Trail bestätigt, welche Anmeldedaten wann rotiert wurden, und schließt die Compliance-Lücke.

Der Rotationsschritt selbst bleibt der kritische. Das Entfernen des Tresor-Zugangs verhindert zukünftigen Zugriff. Das Rotieren der Anmeldedaten schließt das Fenster für Anmeldedaten, die der Mitarbeiter bereits kennt.

Die Checkliste für sichere Zugriffsentziehung 2026

Das folgende vierphasige Framework — das Secure Offboarding Execution Model (SOEM) — gibt IT-Administratoren eine strukturierte Abfolge für die Zugriffsentziehung, die den gesamten Umfang moderner Credential-Risiken abdeckt.

Phase 1: Discovery vor dem Austritt

Beginnen Sie vor dem letzten Tag des Mitarbeiters. Das Ziel ist es, Überraschungen zum Zeitpunkt null zu eliminieren.

• Auditieren Sie Shadow IT: Verwenden Sie SaaS-Discovery-Tools oder Browser-Extension-Daten, um Anwendungen zu identifizieren, auf die der Mitarbeiter zugegriffen hat und die nicht in Ihrem offiziellen Inventar sind.
• Erfassen Sie NHIs: Fragen Sie AWS IAM, GitHub, GitLab, Azure AD und alle internen Entwicklerplattformen nach Service-Accounts, Personal Access Token und API-Schlüsseln ab, die mit der Identität des Mitarbeiters verbunden sind.
• Identifizieren Sie geteilte Tresor-Mitgliedschaft: Ziehen Sie einen Bericht aus Ihrem Passwortmanager, der jeden Tresor und Ordner zeigt, auf den der Mitarbeiter Zugriff hat.
• Markieren Sie Anmeldedaten, die rotiert werden müssen: Jedes geteilte Passwort oder Service-Account-Anmeldedaten, auf die der Mitarbeiter Zugriff hatte, sollte für die Rotation eingeplant werden, nicht nur für die Zugriffsentfernung.
• Weisen Sie NHI-Eigentümerschaft zu: Für jeden Service-Account oder Token, den der Mitarbeiter besitzt, bestimmen Sie einen neuen Eigentümer vor dem Austritt.

Phase 2: Trigger zum Zeitpunkt null (sofortige Aktionen)

Führen Sie diese Schritte genau in dem Moment aus, in dem die Kündigung wirksam wird — idealerweise automatisch durch Ihr Human Resources Information System (HRIS) ausgelöst.

• Deaktivieren Sie das Konto des Mitarbeiters in Ihrem Identity Provider (Okta, Microsoft Entra ID, Google Workspace). Dies beendet aktive SSO-Sitzungen über alle föderierten Anwendungen hinweg.
• Widerrufen Sie aktive Sitzungen explizit: SSO-Deaktivierung beendet nicht immer laufende Sitzungen. Erzwingen Sie die Sitzungsbeendigung in Ihrem IdP und in wertvollen Anwendungen (Microsoft 365, Google Workspace, Salesforce, GitHub) separat.
• Widerrufen Sie VPN-Zertifikate und Netzwerkzugangs-Anmeldedaten.
• Deaktivieren Sie den physischen Zugang: Badge-Deaktivierung, falls zutreffend.
• Benachrichtigen Sie das Sicherheitsteam und den Vorgesetzten des Mitarbeiters gleichzeitig.

Für FedRAMP-regulierte Umgebungen muss diese gesamte Phase gemäß PS-4-Implementierungsanleitung innerhalb von 4 Stunden nach dem Kündigungsereignis abgeschlossen sein. EU-Organisationen, die unter NIS2 operieren oder personenbezogene Daten gemäß DSGVO Artikel 32 verarbeiten, haben keine feste Frist, aber Regulierungsbehörden erwarten Same-Day-Ausführung — und jeder aktive Zugang nach der Kündigung ist bei einem Audit schwer zu verteidigen.

Phase 3: Tiefenreinigung (innerhalb von 24 Stunden)

Die Schritte zum Zeitpunkt null unterbrechen den aktiven Zugang. Phase 3 behandelt alles, was ein deaktiviertes Konto überdauert.

• Rotieren Sie alle geteilten Passwörter, auf die der Mitarbeiter Zugriff hatte, basierend auf dem in Phase 1 erstellten Tresor-Mitgliedschaftsbericht.
• Widerrufen Sie jeden API-Schlüssel, Personal Access Token und OAuth-Token, der mit dem Mitarbeiter verbunden ist — einschließlich derer, die lokal auf seinem Gerät oder in KI-Tool-Konfigurationen gespeichert sind. Prüfen Sie GitHub, GitLab, AWS IAM, GCP-Service-Accounts, Azure-App-Registrierungen und alle internen Entwicklerportale.
• Übertragen Sie die Eigentümerschaft von Service-Accounts und CI/CD-Pipeline-Anmeldedaten an ein bestimmtes Teammitglied.
• Prüfen Sie MCP-verbundene KI-Tools: Identifizieren Sie, welche KI-Assistenten der Mitarbeiter verwendet hat und ob diese Tools Anmeldedaten lokal gespeichert haben. Widerrufen Sie die zugrunde liegenden API-Schlüssel unabhängig vom Gerätestatus.
• Auditieren Sie Cloud-Speicher: Prüfen Sie auf geteilte Laufwerke, S3-Buckets oder Speicher-Container, bei denen der Mitarbeiter direkten Zugang außerhalb der SSO-Föderation hatte.
• Entfernen Sie den Mitarbeiter aus Verteilerlisten, Slack-Workspaces und allen externen Collaboration-Tools (Notion, Confluence, Jira, Figma), die sich unabhängig authentifizieren.

Phase 4: Geräterückgabe und -löschung

Der Umgang mit Geräten bestimmt, ob lokal gespeicherte Anmeldedaten (einschließlich KI-Agenten-API-Schlüssel) dauerhaft neutralisiert werden.

Für unternehmenseigene Geräte: Holen Sie das Gerät am oder vor dem letzten Tag ab. Führen Sie eine vollständige Remote-Löschung vor der Rückgabe durch, wenn irgendein Risiko besteht, dass der Mitarbeiter das Gerät physisch behält. Verlassen Sie sich nicht darauf, dass der Mitarbeiter das Gerät zurückgibt, bevor die Löschung eingeleitet wird.

Für BYOD-Umgebungen (Bring Your Own Device): Das Risikoprofil ist höher. Sie können ein persönliches Gerät nicht löschen, was bedeutet, dass lokal gespeicherte Anmeldedaten auf diesem Gerät unbegrenzt zugänglich bleiben. Dies macht Phase 3 (Widerruf jedes API-Schlüssels und Tokens) für BYOD-Offboarding unverzichtbar. MDM (Mobile Device Management)-registrierte BYOD-Geräte ermöglichen eine selektive Löschung von Unternehmensprofilen — Entfernung von Unternehmens-E-Mail, Apps und zwischengespeicherten Anmeldedaten, ohne persönliche Daten zu berühren. Führen Sie dies zum Zeitpunkt null aus.

Dokumentieren Sie den Gerätestatus im Offboarding-Protokoll. Wenn ein Gerät nicht innerhalb eines definierten Zeitraums zurückgegeben wird, eskalieren Sie an die Rechtsabteilung und behandeln Sie alle Anmeldedaten, die möglicherweise darauf gespeichert waren, als kompromittiert.

Prioritätsmatrix für Zugriffsentziehung

Automatisierung des Offboarding-Workflows

HRIS-zu-IAM-Integration

Manuelle Offboarding-Prozesse haben einen strukturellen Fehler: Sie hängen davon ab, dass ein Mensch bemerkt, dass ein anderer Mensch gegangen ist, und dann handelt. Diese Abhängigkeit führt zu Latenz — und Latenz ist die Schwachstelle.

Der einzige zuverlässige Weg, enge Widerrufsfristen einzuhalten, ist Automatisierung. Wenn Ihr HRIS (Workday, BambooHR, SAP SuccessFactors) ein Kündigungsereignis auslöst, sollte dieses Ereignis automatisch über SCIM-Provisioning oder eine direkte API-Integration an Ihre IAM-Plattform weitergegeben werden. Die IAM-Plattform führt dann Kontodeaktivierung, Sitzungswiderruf und Downstream-Deprovisionierung aus, ohne auf das Öffnen eines Tickets zu warten.

Das Integrationsmuster ist unkompliziert: HRIS-Kündigungsereignis → SCIM-Deprovisionierungsaufruf an IdP → IdP deaktiviert Konto und sendet Broadcast an föderierte Apps → automatisierter Webhook oder API-Aufruf an Passwortmanager, um den Benutzer für Tresor-Zugriffsentfernung zu markieren.

Diese Architektur reduziert die Phase zum Zeitpunkt null von einer mehrstufigen manuellen Checkliste auf einen einzigen Trigger. Die Rolle des IT-Administrators verschiebt sich vom Ausführenden zum Prüfer — Bestätigung, dass die automatisierten Schritte erfolgreich abgeschlossen wurden, und Behandlung der Randfälle (NHIs, KI-Agenten-Schlüssel, BYOD-Geräte), die die Automatisierung noch nicht erreichen kann.

Für Teams, die diese Integration aufbauen, unterstützen die REST API und CLI-Tools von Passwork automatisierte Benutzer-Deprovisionierung als Teil eines breiteren IAM-Workflows, wodurch die Tresor-Zugriffsentfernung in dieselbe automatisierte Sequenz wie die IdP-Kontodeaktivierung einbezogen werden kann. Passwork ist sowohl als Self-hosted-Lösung als auch in der Cloud verfügbar.

Fazit

Der Wandel von „AD-Konto deaktivieren" zu „vollständigen Credential-Fußabdruck widerrufen" ist nicht inkrementell — er spiegelt ein grundlegend anderes Bedrohungsmodell wider. KI-Agenten, NHIs und geteilte Anmeldedaten haben eine Kategorie von Zugriff geschaffen, die vollständig außerhalb des SSO-Perimeters existiert. Standard-Checklisten erreichen ihn nicht.

Die Teams, die dies gut handhaben, teilen ein Merkmal: Sie erledigen die Discovery-Arbeit vor dem letzten Tag. Sie wissen, auf welche Tresore der Mitarbeiter Zugriff hatte, welche API-Schlüssel er generiert hat und welche Service-Accounts ihm gehörten. Die Ausführung zum Zeitpunkt null ist schnell, weil das Inventar bereits existiert.

Beginnen Sie mit dem Audit. Die Erfassung des Zugriffs vor dem Austritt ist der einzige Weg, um sicherzustellen, dass nichts danach verwaist bleibt.

Häufig gestellte Fragen zu Mitarbeiter-Offboarding und Zugriffsentziehung

Was ist das größte Sicherheitsrisiko beim Offboarding eines Mitarbeiters?

Das größte Risiko ist Zugriff, der die Standard-SSO-Deaktivierung überlebt. Dazu gehören lokal gespeicherte API-Schlüssel, die von KI-Tools und Automatisierungsskripten verwendet werden, geteilte Passwörter, die nicht zentral widerrufen werden können, und verwaiste Service-Accounts, die der Mitarbeiter erstellt hat. Das Deaktivieren eines IdP-Kontos schließt eine Tür; diese Anmeldedaten stellen separate, oft undokumentierte Einstiegspunkte dar, die expliziten Widerruf erfordern.

Wie schnell sollte der Zugriff entzogen werden, wenn ein Mitarbeiter ausscheidet?

Für FedRAMP- und StateRAMP-Umgebungen verweist die PS-4-Implementierungsanleitung auf ein 4-Stunden-Fenster ab dem Kündigungsereignis. Für Organisationen unter SOC 2 oder ISO 27001 ist Same-Day-Widerruf der aktuelle Audit-Standard. EU-Organisationen, die unter NIS2 (Artikel 21) oder DSGVO (Artikel 32) operieren, haben keine feste Frist, aber Regulierungsbehörden erwarten Same-Day-Ausführung — aktiver Zugang nach Kündigung ist bei einem Audit schwer zu verteidigen. In der Praxis ist Widerruf zum Zeitpunkt null — automatisch ausgelöst im Moment der Kündigung — der einzige Ansatz, der das Risikofenster vollständig eliminiert.

Wie behandelt man geteilte Passwörter, wenn ein Mitarbeiter gekündigt wird?

Geteilte Passwörter müssen rotiert werden, nicht nur der Zugriff entzogen. Wenn der Mitarbeiter das Passwort kannte, kennt er es auch nach dem Widerruf seines Tresor-Zugangs noch. Der Rotationsschritt schließt die Schwachstelle. Ein Enterprise-Passwortmanager mit strukturierter Tresor-Mitgliedschaft macht diesen Prozess auditierbar: Sie können genau sehen, auf welche geteilten Anmeldedaten der Mitarbeiter Zugriff hatte, und diese systematisch rotieren, ohne den Rest des Teams zu stören.

Was ist das Problem mit KI-Agenten beim Offboarding?

KI-Codierassistenten und Automatisierungstools, die über MCP verbunden sind, speichern API-Schlüssel lokal auf dem Rechner des Entwicklers — in .env-Dateien, Shell-Profilen oder im eigenen Credential-Store des Tools. Diese Schlüssel werden nicht von SSO verwaltet. Das Deaktivieren des IdP-Kontos des Mitarbeiters widerruft sie nicht. Bis diese spezifischen API-Schlüssel identifiziert und widerrufen werden (und das Gerät gelöscht wird), bleiben die Anmeldedaten gültig. Dies ist eine Lücke in praktisch jeder Standard-Offboarding-Checkliste, die vor 2025 geschrieben wurde.

Entzieht das Deaktivieren eines SSO-Kontos allen Anwendungszugriff?

Nein. SSO-Deaktivierung beendet föderierte Sitzungen für Anwendungen, die sich über den IdP authentifizieren. Es betrifft nicht: Anwendungen, die sich unabhängig authentifizieren (Legacy-Tools, Anbieterportale), lokal gespeicherte API-Schlüssel und Token, aktive Sitzungen, die vor der Deaktivierung aufgebaut wurden und noch nicht abgelaufen sind, und geteilte Anmeldedaten, die der Mitarbeiter auswendig kannte. Jede dieser Kategorien erfordert einen separaten Widerrufsschritt.

Was sollte eine IT-Offboarding-Checkliste 2026 enthalten?

Eine vollständige IT-Offboarding-Checkliste 2026 muss abdecken: IdP/SSO-Kontodeaktivierung und aktive Sitzungsbeendigung, VPN- und physischen Zugangs-Widerruf, geteilte Passwort-Rotation über einen Passwortmanager, API-Schlüssel- und Personal-Access-Token-Widerruf über alle Entwicklerplattformen, NHI-Eigentümerschaftsübertragung, KI-Tool-Credential-Audit, Cloud-Speicher-Zugangs-Entfernung, SaaS-Anwendungs-Deprovisionierung und Geräte-Löschung oder selektive MDM-Löschung für BYOD. Die Discovery-Phase vor dem Austritt — all dies vor dem letzten Tag zu erfassen — macht die Ausführung zum Zeitpunkt null zuverlässig.

Shadow IT vs Shadow AI: Warum KI die größere Bedrohung ist

Mitarbeiter nutzen KI-Tools, die Sie nicht genehmigt haben, auf Konten, die Sie nicht überwachen können, mit Daten, die Sie nicht wiederherstellen können. So sieht das Risiko tatsächlich aus und was Governance adressieren muss.

Passwork BlogAlex Muntyan

Unsichere Passwort-Weitergabe: Risiken und sichere Lösungen 2026

Jedes Mal, wenn Anmeldedaten über Slack oder E-Mail übertragen werden, verlieren Sie Nachvollziehbarkeit, Audit-Trail und Compliance-Status in einem Schritt. Dieser Leitfaden behandelt die echten Risiken unsicherer Passwort-Weitergabe 2026, warum Mitarbeiter es trotzdem tun und wie Sie auf Tresor-vermittelten Zugang umstellen können, ohne Ihr Team zu stören.

Passwork BlogAlex Muntyan

Passwork gewinnt Top Performer Frühjahr 2026 auf SourceForge

Passwork wurde von SourceForge als Top Performer Frühjahr 2026 ausgezeichnet und gehört zu den Top 10 % von über 100.000 Lösungen. Das Badge basiert vollständig auf verifizierten Bewertungen — 4,8 Sterne insgesamt, mit einer perfekten 5,0 für Support.

Passwork BlogAlex Muntyan

Cuando un empleado se va, el procedimiento estándar es el siguiente: RR. HH. cierra el ticket, TI desactiva la cuenta de Active Directory y el portátil vuelve a la estantería. Listo. Pero en 2026, eso no es suficiente. Fuera del perímetro de SSO existen agentes de IA que funcionan con claves API almacenadas localmente, cuentas de servicio sin propietario, contraseñas compartidas que ningún IdP revocará jamás y ventanas de cumplimiento medidas en horas.

Esta guía proporciona a los administradores de TI y equipos de seguridad un enfoque estructurado y práctico para la revocación de accesos que abarca todo esto.

Puntos clave

• Desactivar una cuenta SSO no es lo mismo que revocar el acceso. Las claves API, las contraseñas compartidas y los tokens almacenados localmente sobreviven completamente a la desactivación del IdP.
• La mayoría de las listas de verificación de offboarding omiten por completo las credenciales de agentes de IA. Las herramientas conectadas por MCP almacenan claves API fuera del perímetro SSO y requieren pasos de revocación explícitos.
• Solo el 20 % de las organizaciones tiene procesos formales para revocar claves API cuando un empleado se va. OWASP clasifica el offboarding inadecuado de NHI como el riesgo más alto en su Top 10 de Identidades No Humanas (2025).
• Los marcos de cumplimiento son específicos y exigentes. FedRAMP PS-4 establece una ventana de 4 horas; SOC 2 CC6.1 e ISO 27001 Anexo A 6.5 tratan la revocación en el mismo día como el estándar mínimo; NIS2 Artículo 21 y GDPR Artículo 32 esperan lo mismo de las organizaciones de la UE.
• Las contraseñas compartidas deben rotarse, no solo eliminarse el acceso. Si el empleado conocía la contraseña, revocar únicamente la membresía de la bóveda no cierra la vulnerabilidad.
• El descubrimiento previo a la salida es lo que hace confiable la ejecución en hora cero. Sin mapear cada bóveda, clave API, cuenta de servicio y credencial de herramienta de IA antes del último día, el offboarding es reactivo por diseño.
• Los procesos manuales basados en tickets no pueden cumplir los plazos modernos de revocación. La automatización de HRIS a IAM vía SCIM es la única arquitectura que elimina la ventana de latencia de manera consistente.

Los riesgos ocultos de la revocación tardía de accesos

La revocación tardía de accesos tiene un resultado predecible: un exempleado conserva credenciales funcionales mientras su equipo asume que la cuenta está cerrada. La ventana de amenaza se abre en el momento en que se confirma la salida, y las consecuencias van desde la exfiltración de datos hasta sanciones regulatorias.

Los plazos de cumplimiento se están ajustando

La urgencia ahora está codificada en los principales marcos de cumplimiento. ISO 27001:2022 Anexo A 6.5 (Responsabilidades después de la terminación o cambio de empleo) requiere la eliminación rápida de los derechos de acceso. NIS2 Artículo 21 exige medidas apropiadas de control de acceso como parte de la higiene de seguridad básica de una organización. GDPR Artículo 32 requiere medidas técnicas y organizativas para proteger los datos personales — y una cuenta activa perteneciente a un exempleado es una exposición directa bajo esa obligación.

«Las responsabilidades y deberes de seguridad de la información que permanezcan válidos después de la terminación o cambio de empleo deben definirse, aplicarse y comunicarse al personal relevante y otras partes interesadas» — ISO/IEC 27001:2022, Anexo A, Control 6.5

Para organizaciones con contratos o clientes federales de EE. UU., FedRAMP y StateRAMP han ajustado las expectativas de implementación de PS-4 a una ventana de revocación de 4 horas, según la guía de cumplimiento publicada por Paramify. SOC 2 Trust Services Criteria CC6.1 establece expectativas similares en torno a los controles de acceso lógico documentados, y los auditores tratan cada vez más la revocación en el mismo día como el estándar mínimo aceptable.

En todos estos marcos, la implicación operativa es la misma: los procesos de offboarding manuales basados en tickets no pueden cumplir estos plazos de manera confiable. Un proceso que depende de que un administrador de TI note un mensaje de Slack de RR. HH. fallará.

Exfiltración de datos y amenazas internas

La superficie de ataque es específica: plataformas CRM que contienen datos de clientes, repositorios de código con lógica propietaria, buckets de almacenamiento en la nube y credenciales de pipelines CI/CD.

La investigación de Cyberhaven encontró un aumento del 720 % en la actividad de exfiltración de datos en las 24 horas previas a un despido — la mayoría hacia almacenamiento personal en la nube, medios extraíbles y herramientas de IA generativa. Un exempleado que conserva acceso después de esa ventana no necesita ser malicioso para causar daño; un script mal configurado ejecutándose bajo su token aún activo es suficiente.

El Informe de Investigaciones de Violaciones de Datos (DBIR) 2026 de Verizon identifica el abuso de credenciales como responsable del 13 % de las violaciones — una cifra que se concentra fuertemente en torno a accesos que nunca fueron revocados correctamente. El riesgo no es hipotético. Un desarrollador que conserva un token de acceso personal válido a un repositorio de GitHub puede clonar todo el código base semanas después de su último día.

Puntos ciegos del offboarding en 2026: Agentes de IA y NHIs

Las listas de verificación de offboarding estándar (desactivar la cuenta SSO, revocar VPN, devolver el portátil) fueron diseñadas para un modelo de amenazas más simple. Dos categorías de acceso ahora sobreviven rutinariamente a esos pasos por completo.

El problema del acceso de agentes de IA

Los desarrolladores en 2026 conectan asistentes de codificación de IA y herramientas de automatización a servicios externos a través del Model Context Protocol (MCP). Estas integraciones se autentican usando claves API que el desarrollador genera manualmente y almacena localmente: en archivos .env, archivos de configuración de shell, configuraciones del IDE o el propio almacén de credenciales de la herramienta de IA en la máquina del desarrollador.

Cuando desactiva la cuenta de Okta o Entra ID de ese desarrollador, ninguna de esas claves almacenadas localmente se toca. La capa SSO nunca supo que existían. Si el portátil del desarrollador no se borra rápidamente — o si usó una máquina personal para trabajar — esas claves permanecen válidas y funcionales. La clave API para su entorno de producción en la nube, su cuenta de Stripe o su pipeline de datos interno no expira porque la sesión SSO del empleado terminó.

La solución práctica requiere dos pasos que la mayoría de las listas de verificación de offboarding omiten por completo: auditar qué claves API generó el empleado que se va (en GitHub, AWS IAM, plataformas en la nube y sistemas internos), y rotar o revocar cada una de ellas antes del último día del empleado, no después de la recuperación del dispositivo.

Identidades no humanas (NHIs) huérfanas

El Top 10 de Identidades No Humanas de OWASP (2025) coloca el Offboarding Inadecuado en la posición NHI1:2025 — el riesgo más alto en todo el marco. La definición es precisa: desactivación o eliminación inadecuada de identidades no humanas como cuentas de servicio, claves API, tokens OAuth y certificados cuando el humano que las creó o gestionó abandona la organización.

Los informes de la Cloud Security Alliance, con un año de diferencia, muestran que el problema no está mejorando. En su informe State of Non-Human Identity Security de 2024, CSA encontró que solo el 20 % de las organizaciones tiene procesos formales para el offboarding y la revocación de claves API. El seguimiento de 2026, State of Non-Human Identity and AI Security, encontró que las brechas de gobernanza se habían ampliado a medida que las cargas de trabajo de IA aceleraron la creación de identidades:

• Menos del 25 % de las organizaciones tiene políticas documentadas y formalmente adoptadas para crear o eliminar identidades de IA
• Más del 16 % no rastrea en absoluto la creación de nuevas identidades relacionadas con IA, dejando un subconjunto creciente de tokens y cuentas de servicio fuera de cualquier inventario formal
• Solo el 12 % de las organizaciones reporta alta confianza en su capacidad para prevenir ataques vía NHIs

Cuando un ingeniero senior se va, las cuentas de servicio que creó, los tokens que registró y los certificados que aprovisionó continúan operando indefinidamente.

El riesgo se multiplica porque las NHIs están rutinariamente sobreprivilegiadas. Un ingeniero que necesitó acceso amplio para depurar un problema de producción hace tres años puede haber creado una cuenta de servicio con permisos de nivel administrador. Esa cuenta ahora no tiene propietario y es invisible para las revisiones estándar de acceso de usuarios. Las herramientas IAM heredadas no fueron construidas para manejar esto — rastrean personas, no las credenciales que las personas crean.

Abordar el offboarding de NHI requiere un paso de descubrimiento dedicado antes de que el empleado se vaya: identificar cada cuenta de servicio, token y certificado asociado con esa persona, asignar un nuevo propietario y rotar las credenciales donde el empleado que se va tenía conocimiento exclusivo del secreto.

Cómo manejar contraseñas compartidas durante el offboarding

Las credenciales compartidas son la categoría más propensa a pasarse por alto en un proceso de offboarding estándar, y la más propensa a ser explotada después.

El peligro de las credenciales compartidas

Las contraseñas compartidas no pueden desactivarse mediante SSO centralizado. Cuando cuatro personas de un equipo comparten un inicio de sesión para un portal de proveedores, una interfaz de gestión de dispositivos de red o una aplicación heredada, desactivar la cuenta SSO de una persona no hace nada a esa credencial compartida. El empleado que se fue conoce la contraseña. Siempre la conocerá, a menos que se cambie.

El problema escala con el tamaño del equipo y la antigüedad. Un empleado de larga trayectoria puede tener acceso a docenas de credenciales compartidas acumuladas durante años — credenciales que no están documentadas en ningún lugar, almacenadas en una hoja de cálculo en una unidad compartida, o conocidas solo por las personas que las usan diariamente.

Gestión empresarial de contraseñas para el control de bóvedas compartidas

Aquí es donde un gestor de contraseñas empresarial dedicado se vuelve operacionalmente esencial, no opcional. Cuando las credenciales compartidas residen en una bóveda estructurada con control de acceso basado en roles, el offboarding se convierte en un procedimiento definido en lugar de un juego de adivinanzas.

Passwork cubre todo el alcance del trabajo de credenciales de offboarding en una sola plataforma:

• Membresía de bóveda compartida — cada bóveda tiene miembros explícitos. Eliminar a un empleado dado de baja revoca el acceso instantáneamente, sin depender de que olvide o elija no reutilizar la contraseña.
• Gestión de secretos — claves API, tokens, credenciales de bases de datos y certificados se encuentran junto a las credenciales humanas en la misma jerarquía de bóvedas, bajo el mismo modelo RBAC. No se requiere un gestor de secretos separado.
• Control de cuentas de servicio — las cuentas de servicio se almacenan y gestionan centralmente en Passwork. Cada cuenta tiene un propietario asignado. Cuando ese propietario es dado de baja, la cuenta aparece inmediatamente en la revisión de acceso en lugar de convertirse silenciosamente en una identidad huérfana sin nadie responsable de ella.
• Registro de auditoría completo — cada credencial a la que accedió el empleado que se va queda registrada, dando al equipo de seguridad una lista clara de lo que necesita rotarse.
• REST API — conecte los flujos de trabajo de offboarding directamente a sus sistemas de RR. HH. o ITSM. Active la revocación de acceso a bóvedas automáticamente cuando se crea un ticket de terminación, sin intervención manual.
• Seguimiento de rotación — eliminar el acceso a la bóveda previene acceso futuro. La pista de auditoría confirma qué credenciales fueron rotadas y cuándo, cerrando la brecha de cumplimiento.

El paso de rotación en sí sigue siendo el crítico. Eliminar el acceso a la bóveda previene acceso futuro. Rotar las credenciales cierra la ventana para las credenciales que el empleado ya conoce.

Lista de verificación de revocación segura de accesos 2026

El siguiente marco de cuatro fases — el Modelo de Ejecución de Offboarding Seguro (SOEM) — proporciona a los administradores de TI una secuencia estructurada para la revocación de accesos que cubre todo el alcance del riesgo moderno de credenciales.

Fase 1: Descubrimiento previo a la salida

Comience antes del último día del empleado. El objetivo es eliminar sorpresas en la hora cero.

• Audite la TI en la sombra: use herramientas de descubrimiento de SaaS o datos de extensiones del navegador para identificar aplicaciones a las que el empleado accedió que no están en su inventario oficial.
• Mapee las NHIs: consulte AWS IAM, GitHub, GitLab, Azure AD y cualquier plataforma de desarrolladores interna para cuentas de servicio, tokens de acceso personal y claves API asociadas con la identidad del empleado.
• Identifique la membresía de bóvedas compartidas: extraiga un informe de su gestor de contraseñas que muestre cada bóveda y carpeta a la que el empleado tiene acceso.
• Marque las credenciales que requieren rotación: cualquier contraseña compartida o credencial de cuenta de servicio a la que el empleado tuvo acceso debe ponerse en cola para rotación, no solo para eliminación de acceso.
• Asigne propiedad de NHI: para cada cuenta de servicio o token que el empleado posee, designe un nuevo propietario antes de la salida.

Fase 2: Activador de hora cero (acciones inmediatas)

Ejecute estos pasos en el momento exacto en que la terminación entra en vigor — idealmente activado automáticamente por su Sistema de Información de Recursos Humanos (HRIS).

• Desactive la cuenta del empleado en su proveedor de identidad (Okta, Microsoft Entra ID, Google Workspace). Esto termina las sesiones SSO activas en todas las aplicaciones federadas.
• Revoque las sesiones activas explícitamente: desactivar SSO no siempre mata las sesiones en curso. Fuerce la terminación de sesiones en su IdP y en las aplicaciones de alto valor (Microsoft 365, Google Workspace, Salesforce, GitHub) por separado.
• Revoque los certificados VPN y las credenciales de acceso a la red.
• Desactive el acceso físico: desactivación de tarjeta de identificación, si aplica.
• Notifique al equipo de seguridad y al gerente del empleado simultáneamente.

Para entornos regulados por FedRAMP, esta fase completa debe completarse dentro de las 4 horas del evento de terminación según la guía de implementación PS-4. Las organizaciones de la UE que operan bajo NIS2 o que manejan datos personales bajo el GDPR Artículo 32 no tienen un plazo fijo, pero los reguladores esperan ejecución en el mismo día — y cualquier acceso activo después de la terminación es difícil de defender en una auditoría.

Fase 3: Limpieza profunda (dentro de 24 horas)

Los pasos de hora cero cortan el acceso activo. La Fase 3 trata con todo lo que sobrevive a una cuenta desactivada.

• Rote todas las contraseñas compartidas a las que el empleado tuvo acceso, trabajando desde el informe de membresía de bóveda generado en la Fase 1.
• Revoque cada clave API, token de acceso personal y token OAuth asociado con el empleado — incluidos los almacenados localmente en su dispositivo o en configuraciones de herramientas de IA. Verifique GitHub, GitLab, AWS IAM, cuentas de servicio de GCP, registros de aplicaciones de Azure y cualquier portal de desarrolladores interno.
• Transfiera la propiedad de las cuentas de servicio y las credenciales de pipelines CI/CD a un miembro designado del equipo.
• Verifique las herramientas de IA conectadas por MCP: identifique qué asistentes de IA usó el empleado y si esas herramientas almacenaron credenciales localmente. Revoque las claves API subyacentes independientemente del estado del dispositivo.
• Audite el almacenamiento en la nube: verifique si hay unidades compartidas, buckets S3 o contenedores de almacenamiento donde el empleado tenía acceso directo fuera de la federación SSO.
• Elimine al empleado de las listas de distribución, espacios de trabajo de Slack y cualquier herramienta de colaboración externa (Notion, Confluence, Jira, Figma) que se autentique de forma independiente.

Fase 4: Recuperación y borrado del dispositivo

El manejo del dispositivo determina si las credenciales almacenadas localmente (incluidas las claves API de agentes de IA) se neutralizan permanentemente.

Para dispositivos corporativos: recupere el dispositivo en o antes del último día. Realice un borrado remoto completo antes de la recuperación si existe algún riesgo de que el empleado retenga la posesión física. No confíe en que el empleado devuelva el dispositivo antes de iniciar el borrado.

Para entornos BYOD (Bring Your Own Device): el perfil de riesgo es mayor. No puede borrar un dispositivo personal, lo que significa que las credenciales almacenadas localmente en ese dispositivo permanecen accesibles indefinidamente. Esto hace que la Fase 3 (revocar cada clave API y token) sea innegociable para el offboarding BYOD. Los dispositivos BYOD registrados en MDM permiten el borrado selectivo de perfiles corporativos — eliminando correo electrónico corporativo, aplicaciones y credenciales en caché sin tocar los datos personales. Ejecute esto en hora cero.

Documente el estado del dispositivo en el registro de offboarding. Si un dispositivo no se devuelve dentro de una ventana definida, escale a legal y trate todas las credenciales que puedan haber sido almacenadas en él como comprometidas.

Matriz de prioridad de revocación de acceso

Automatización del flujo de trabajo de offboarding

Integración de HRIS a IAM

Los procesos de offboarding manuales tienen un defecto estructural: dependen de que un humano note que otro humano se ha ido y luego tome acción. Esa dependencia introduce latencia — y la latencia es la vulnerabilidad.

La única forma confiable de cumplir con ventanas de revocación ajustadas es la automatización. Cuando su HRIS (Workday, BambooHR, SAP SuccessFactors) activa un evento de terminación, ese evento debe propagarse automáticamente a su plataforma IAM vía aprovisionamiento SCIM o una integración directa de API. La plataforma IAM entonces ejecuta la desactivación de cuenta, revocación de sesión y desaprovisionamiento descendente sin esperar a que se abra un ticket.

El patrón de integración es sencillo: evento de terminación en HRIS → llamada de desaprovisionamiento SCIM al IdP → IdP desactiva la cuenta y transmite a las aplicaciones federadas → webhook automatizado o llamada API al gestor de contraseñas para marcar al usuario para eliminación de acceso a bóvedas.

Esta arquitectura reduce la fase de hora cero de una lista de verificación manual de múltiples pasos a un único activador. El rol del administrador de TI cambia de ejecutor a verificador — confirmando que los pasos automatizados se completaron exitosamente y manejando los casos extremos (NHIs, claves de agentes de IA, dispositivos BYOD) que la automatización aún no puede alcanzar.

Para los equipos que construyen esta integración, la REST API y las herramientas CLI de Passwork admiten el desaprovisionamiento automatizado de usuarios como parte de un flujo de trabajo IAM más amplio, permitiendo que la eliminación de acceso a bóvedas se incluya en la misma secuencia automatizada que la desactivación de cuenta del IdP. Passwork está disponible tanto como solución autoalojada como en la nube.

Conclusión

El cambio de «desactivar la cuenta de AD» a «revocar la huella completa de credenciales» no es incremental — refleja un modelo de amenazas fundamentalmente diferente. Los agentes de IA, las NHIs y las credenciales compartidas han creado una categoría de acceso que vive completamente fuera del perímetro SSO. Las listas de verificación estándar no la alcanzan.

Los equipos que manejan esto bien comparten una característica: hacen el trabajo de descubrimiento antes del último día. Saben a qué bóvedas tenía acceso el empleado, qué claves API generó y qué cuentas de servicio poseía. La ejecución en hora cero es rápida porque el inventario ya existe.

Comience con la auditoría. Mapear el acceso antes de la salida es la única forma de asegurar que nada quede huérfano después del hecho.

Preguntas frecuentes sobre offboarding de empleados y revocación de acceso

¿Cuál es el mayor riesgo de seguridad al dar de baja a un empleado?

El mayor riesgo es el acceso que sobrevive a la desactivación estándar de SSO. Esto incluye claves API almacenadas localmente usadas por herramientas de IA y scripts de automatización, contraseñas compartidas que no pueden revocarse centralmente, y cuentas de servicio huérfanas que el empleado creó. Desactivar una cuenta de IdP cierra una puerta; estas credenciales representan puntos de entrada separados, a menudo no documentados, que requieren revocación explícita.

¿Qué tan rápido debe revocarse el acceso cuando un empleado se va?

Para entornos FedRAMP y StateRAMP, la guía de implementación PS-4 apunta a una ventana de 4 horas desde el evento de terminación. Para organizaciones bajo SOC 2 o ISO 27001, la revocación en el mismo día es el estándar de auditoría actual. Las organizaciones de la UE que operan bajo NIS2 (Artículo 21) o GDPR (Artículo 32) no tienen un plazo fijo, pero los reguladores esperan ejecución en el mismo día — el acceso activo después de la terminación es difícil de defender en una auditoría. En la práctica, la revocación en hora cero — activada automáticamente en el momento de la terminación — es el único enfoque que elimina la ventana de riesgo por completo.

¿Cómo se manejan las contraseñas compartidas cuando se despide a un empleado?

Las contraseñas compartidas deben rotarse, no solo eliminarse el acceso. Si el empleado conocía la contraseña, aún la conoce después de que se revoque su acceso a la bóveda. El paso de rotación es lo que cierra la vulnerabilidad. Un gestor de contraseñas empresarial con membresía de bóveda estructurada hace que este proceso sea auditable: puede ver exactamente a qué credenciales compartidas tenía acceso el empleado y rotarlas sistemáticamente sin interrumpir al resto del equipo.

¿Cuál es el problema del offboarding de agentes de IA?

Los asistentes de codificación de IA y las herramientas de automatización conectadas vía MCP almacenan claves API localmente en la máquina del desarrollador — en archivos .env, perfiles de shell o el propio almacén de credenciales de la herramienta. Estas claves no son gestionadas por SSO. Desactivar la cuenta del IdP del empleado no las revoca. Hasta que esas claves API específicas sean identificadas y revocadas (y el dispositivo sea borrado), las credenciales permanecen válidas. Esta es una brecha en prácticamente todas las listas de verificación de offboarding estándar escritas antes de 2025.

¿Desactivar una cuenta SSO revoca todo el acceso a aplicaciones?

No. La desactivación de SSO termina las sesiones federadas para aplicaciones que se autentican a través del IdP. No afecta a: aplicaciones que se autentican de forma independiente (herramientas heredadas, portales de proveedores), claves API y tokens almacenados localmente, sesiones activas que se establecieron antes de la desactivación y aún no han expirado, y credenciales compartidas que el empleado conocía de memoria. Cada una de estas categorías requiere un paso de revocación separado.

¿Qué debe incluir una lista de verificación de offboarding de TI en 2026?

Una lista de verificación completa de offboarding de TI para 2026 debe cubrir: desactivación de cuenta IdP/SSO y terminación de sesiones activas, revocación de VPN y acceso físico, rotación de contraseñas compartidas vía gestor de contraseñas, revocación de claves API y tokens de acceso personal en todas las plataformas de desarrolladores, transferencia de propiedad de NHI, auditoría de credenciales de herramientas de IA, eliminación de acceso a almacenamiento en la nube, desaprovisionamiento de aplicaciones SaaS, y borrado de dispositivo o borrado selectivo de MDM para BYOD. La fase de descubrimiento previo a la salida — mapear todo esto antes del último día — es lo que hace confiable la ejecución en hora cero.

TI en la sombra vs IA en la sombra: Por qué la IA es la mayor amenaza

Los empleados están usando herramientas de IA que usted no aprobó, en cuentas que no puede monitorear, con datos que no puede recuperar. Aquí está cómo es realmente el riesgo y qué debe abordar la gobernanza.

Passwork BlogAlex Muntyan

Uso compartido inseguro de contraseñas: Riesgos y soluciones seguras en 2026

Cada vez que una credencial se mueve a través de Slack o correo electrónico, pierde responsabilidad, pista de auditoría y postura de cumplimiento en un solo paso. Esta guía cubre los riesgos reales del uso compartido inseguro de contraseñas en 2026, por qué los empleados lo hacen de todos modos y cómo migrar al acceso mediado por bóveda sin interrumpir a su equipo.

Passwork BlogAlex Muntyan

Passwork gana Top Performer Primavera 2026 en SourceForge

Passwork ha sido nombrado Top Performer Primavera 2026 por SourceForge, clasificándose en el 10 % superior de más de 100 000 soluciones. La insignia se basa completamente en reseñas verificadas — 4,8 estrellas en general, con un 5,0 perfecto para soporte.

Passwork BlogAlex Muntyan

When an employee leaves, the standard playbook looks like this: HR closes the ticket, IT disables the Active Directory account, the laptop goes back to the shelf. Done. But in 2026, that's not enough. Outside the SSO perimeter live AI agents running on locally stored API keys, service accounts with no owner, shared passwords that no IdP will ever revoke, and compliance windows measured in hours.

This guide gives IT administrators and security teams a structured, actionable approach to access revocation that covers all of it.

Key takeaways

• Disabling an SSO account is not the same as revoking access. API keys, shared passwords, and locally stored tokens survive IdP disable entirely.
• Most offboarding checklists miss AI agent credentials entirely. MCP-connected tools store API keys outside the SSO perimeter and require explicit revocation steps.
• Only 20% of organizations have formal processes for revoking API keys when an employee leaves. OWASP ranks improper NHI offboarding as the single highest risk in its Non-Human Identities Top 10 (2025).
• Compliance frameworks are specific and demanding. FedRAMP PS-4 sets a 4-hour window; SOC 2 CC6.1 and ISO 27001 Annex A 6.5 treat same-day revocation as the minimum standard; NIS2 Article 21 and GDPR Article 32 expect the same from EU organizations.
• Shared passwords must be rotated, not just access-removed. If the employee knew the password, revoking vault membership alone does not close the vulnerability.
• Pre-departure discovery is what makes zero-hour execution reliable. Without mapping every vault, API key, service account, and AI tool credential before the last day, offboarding is reactive by design.
• Manual, ticket-based processes cannot meet modern revocation timelines. HRIS-to-IAM automation via SCIM is the only architecture that eliminates the latency window consistently.

The hidden risks of delayed access revocation

Delayed access revocation has a predictable outcome: a former employee retains working credentials while your team assumes the account is closed. The threat window opens the moment departure is confirmed, and the consequences run from data exfiltration to regulatory penalties.

Compliance timelines are tightening

The urgency is now codified across major compliance frameworks. ISO 27001:2022 Annex A 6.5 (Responsibilities after termination or change of employment) requires prompt removal of access rights. NIS2 Article 21 mandates appropriate access control measures as part of an organization's baseline security hygiene. GDPR Article 32 requires technical and organisational measures to protect personal data — and an active account belonging to a former employee is a direct exposure under that obligation.

"Information security responsibilities and duties that remain valid after termination or change of employment should be defined, enforced and communicated to relevant personnel and other interested parties" — ISO/IEC 27001:2022, Annex A, Control 6.5

For organizations with US federal contracts or customers, FedRAMP and StateRAMP have tightened PS-4 implementation expectations to a 4-hour revocation window, according to compliance guidance published by Paramify. SOC 2 Trust Services Criteria CC6.1 sets similar expectations around documented logical access controls, with auditors increasingly treating same-day revocation as the minimum acceptable standard.

Across all of these frameworks, the operational implication is the same: manual, ticket-based offboarding processes cannot meet these timelines reliably. A process that depends on an IT administrator noticing a Slack message from HR will fail.

Data exfiltration and insider threats

The attack surface is specific: CRM platforms containing customer data, code repositories with proprietary logic, cloud storage buckets, and CI/CD pipeline credentials.

Cyberhaven's research found a 720% surge in data exfiltration activity in the 24 hours before a layoff — most of it to personal cloud storage, removable media, and generative AI tools. A former employee who retains access after that window does not need to be malicious to cause damage; a misconfigured script running under their still-active token is enough.

Verizon's 2026 Data Breach Investigations Report (DBIR) identifies credential abuse as responsible for 13% of breaches — a figure that concentrates heavily around access that was never properly revoked. The risk is not hypothetical. A developer who retains a valid personal access token to a GitHub repository can clone the entire codebase weeks after their last day.

2026 offboarding blind spots: AI agents and NHIs

Standard offboarding checklists (disable the SSO account, revoke VPN, return the laptop) were designed for a simpler threat model. Two categories of access now routinely survive those steps entirely.

The AI agent access problem

Developers in 2026 connect AI coding assistants and automation tools to external services via the Model Context Protocol (MCP). These integrations authenticate using API keys that the developer generates manually and stores locally: in .env files, shell configuration files, IDE settings, or the AI tool's own credential store on the developer's machine.

When you disable that developer's Okta or Entra ID account, none of those locally stored keys are touched. The SSO layer never knew they existed. If the developer's laptop is not wiped promptly — or if they used a personal machine for work — those keys remain valid and functional. The API key for your production cloud environment, your Stripe account, or your internal data pipeline does not expire because the employee's SSO session ended.

The practical fix requires two steps that most offboarding checklists skip entirely: auditing which API keys the departing employee generated (across GitHub, AWS IAM, cloud platforms, and internal systems), and rotating or revoking every one of them before the employee's last day, not after device retrieval.

Orphaned non-human identities (NHIs)

OWASP's Non-Human Identities Top 10 (2025) places Improper Offboarding at position NHI1:2025 — the single highest-ranked risk in the entire framework. The definition is precise: inadequate deactivation or removal of non-human identities such as service accounts, API keys, OAuth tokens, and certificates when the human who created or managed them leaves the organization.

The Cloud Security Alliance reports, a year apart, show the problem is not improving. In its 2024 State of Non-Human Identity Security report, CSA found that only 20% of organizations have formal processes for offboarding and revoking API keys. The 2026 follow-up, State of Non-Human Identity and AI Security, found governance gaps had widened as AI workloads accelerated identity creation:

• Fewer than 25% of organizations have documented, formally adopted policies for creating or removing AI identities
• More than 16% do not track the creation of new AI-related identities at all, leaving a growing subset of tokens and service accounts outside any formal inventory
• Only 12% of organizations report high confidence in their ability to prevent attacks via NHIs

When a senior engineer leaves, the service accounts they created, the tokens they registered, and the certificates they provisioned continue operating indefinitely.

The risk compounds because NHIs are routinely over-privileged. An engineer who needed broad access to debug a production issue three years ago may have created a service account with admin-level permissions. That account is now ownerless and invisible to standard user access reviews. Legacy IAM tools were not built to handle this — they track people, not the credentials people create.

Addressing NHI offboarding requires a dedicated discovery step before the employee leaves: identify every service account, token, and certificate associated with that person, assign a new owner, and rotate credentials where the departing employee had sole knowledge of the secret.

How to handle shared passwords during offboarding

Shared credentials are the category most likely to be missed in a standard offboarding process, and the most likely to be exploited afterward.

The danger of shared credentials

Shared passwords cannot be disabled via centralized SSO. When four people on a team share a login for a vendor portal, a network device management interface, or a legacy application, disabling one person's SSO account does nothing to that shared credential. The departed employee knows the password. They always will, unless it is changed.

The problem scales with team size and tenure. A long-serving employee may have access to dozens of shared credentials accumulated over years — credentials that are not documented anywhere, stored in a spreadsheet on a shared drive, or known only to the people who use them daily.

Enterprise password management for shared vault control

This is where a dedicated enterprise password manager becomes operationally essential, not optional. When shared credentials live in a structured vault with role-based access control, offboarding becomes a defined procedure rather than a guessing game.

Passwork covers the full scope of offboarding credential work in a single platform:

• Shared vault membership — each vault has explicit members. Removing an offboarded employee revokes access instantly, with no dependency on them forgetting or choosing not to reuse the password.
• Secrets management — API keys, tokens, database credentials, and certificates sit alongside human credentials in the same vault hierarchy, under the same RBAC model. No separate secrets manager required.
• Service account control — service accounts are stored and managed centrally in Passwork. Each account has an assigned owner. When that owner is offboarded, the account surfaces immediately in the access review rather than silently becoming an orphaned identity with no one responsible for it.
• Full audit log — every credential the departing employee accessed is recorded, giving the security team a clear list of what needs to be rotated.
• REST API — plug offboarding workflows directly into your HR or ITSM systems. Trigger vault access revocation automatically when a termination ticket is created, without manual intervention.
• Rotation tracking — removing vault access prevents future access. The audit trail confirms which credentials were rotated and when, closing the compliance gap.

The rotation step itself remains the critical one. Removing vault access prevents future access. Rotating the credentials closes the window for credentials the employee already knows.

The 2026 secure access revocation checklist

The following four-phase framework — the Secure Offboarding Execution Model (SOEM) — gives IT administrators a structured sequence for access revocation that covers the full scope of modern credential risk.

Phase 1: Pre-departure discovery

Start before the employee's last day. The goal is to eliminate surprises at zero-hour.

• Audit shadow IT: use SaaS discovery tools or browser extension data to identify applications the employee accessed that are not in your official inventory.
• Map NHIs: query AWS IAM, GitHub, GitLab, Azure AD, and any internal developer platforms for service accounts, personal access tokens, and API keys associated with the employee's identity.
• Identify shared vault membership: pull a report from your password manager showing every vault and folder the employee has access to.
• Flag credentials requiring rotation: any shared password or service account credential the employee had access to should be queued for rotation, not just access removal.
• Assign NHI ownership: for every service account or token the employee owns, designate a new owner before departure.

Phase 2: Zero-hour trigger (immediate actions)

Execute these steps at the exact moment the termination takes effect — ideally triggered automatically by your Human Resources Information System (HRIS).

• Disable the employee's account in your identity provider (Okta, Microsoft Entra ID, Google Workspace). This terminates active SSO sessions across all federated applications.
• Revoke active sessions explicitly: SSO disable does not always kill in-flight sessions. Force session termination in your IdP and in high-value applications (Microsoft 365, Google Workspace, Salesforce, GitHub) separately.
• Revoke VPN certificates and network access credentials.
• Disable physical access: badge deactivation, if applicable.
• Notify the security team and the employee's manager simultaneously.

For FedRAMP-regulated environments, this entire phase must complete within 4 hours of the termination event per PS-4 implementation guidance. EU organizations operating under NIS2 or handling personal data under GDPR Article 32 have no fixed deadline, but regulators expect same-day execution — and any active access after termination is difficult to defend in an audit.

Phase 3: Deep clean (within 24 hours)

The zero-hour steps cut off active access. Phase 3 deals with everything that outlasts a disabled account.

• Rotate all shared passwords the employee had access to, working from the vault membership report generated in Phase 1.
• Revoke every API key, personal access token, and OAuth token associated with the employee — including those stored locally on their device or in AI tool configurations. Check GitHub, GitLab, AWS IAM, GCP service accounts, Azure app registrations, and any internal developer portals.
• Transfer ownership of service accounts and CI/CD pipeline credentials to a designated team member.
• Check for MCP-connected AI tools: identify which AI assistants the employee used and whether those tools stored credentials locally. Revoke the underlying API keys regardless of device status.
• Audit cloud storage: check for any shared drives, S3 buckets, or storage containers where the employee had direct access outside of SSO federation.
• Remove the employee from distribution lists, Slack workspaces, and any external collaboration tools (Notion, Confluence, Jira, Figma) that authenticate independently.

Phase 4: Device retrieval and wipe

Device handling determines whether locally stored credentials (including AI agent API keys) are permanently neutralized.

For corporate-owned devices: retrieve the device on or before the last day. Perform a full remote wipe before retrieval if there is any risk of the employee retaining physical possession. Do not rely on the employee returning the device before the wipe is initiated.

For BYOD (Bring Your Own Device) environments: the risk profile is higher. You cannot wipe a personal device, which means locally stored credentials on that device remain accessible indefinitely. This makes Phase 3 (revoking every API key and token) non-negotiable for BYOD offboarding. MDM (Mobile Device Management)-enrolled BYOD devices allow selective wipe of corporate profiles — removing corporate email, apps, and cached credentials without touching personal data. Execute this at zero-hour.

Document device status in the offboarding record. If a device is not returned within a defined window, escalate to legal and treat all credentials that may have been stored on it as compromised.

Access revocation priority matrix

Automating the offboarding workflow

HRIS to IAM integration

Manual offboarding processes have a structural flaw: they depend on a human noticing that another human has left and then taking action. That dependency introduces latency — and latency is the vulnerability.

The only reliable way to meet tight revocation windows is automation. When your HRIS (Workday, BambooHR, SAP SuccessFactors) triggers a termination event, that event should propagate automatically to your IAM platform via SCIM provisioning or a direct API integration. The IAM platform then executes account disable, session revocation, and downstream deprovisioning without waiting for a ticket to be opened.

The integration pattern is straightforward: HRIS termination event → SCIM deprovisioning call to IdP → IdP disables account and broadcasts to federated apps → automated webhook or API call to password manager to flag the user for vault access removal.

This architecture reduces the zero-hour phase from a multi-step manual checklist to a single trigger. The IT administrator's role shifts from executor to verifier — confirming that the automated steps completed successfully and handling the edge cases (NHIs, AI agent keys, BYOD devices) that automation cannot yet reach.

For teams building this integration, Passwork's REST API and CLI tools support automated user deprovisioning as part of a broader IAM workflow, allowing vault access removal to be included in the same automated sequence as IdP account disable. Passwork is available both as a self-hosted solution and in the cloud.

Conclusion

The shift from "disable the AD account" to "revoke the full credential footprint" is not incremental — it reflects a fundamentally different threat model. AI agents, NHIs, and shared credentials have created a category of access that lives entirely outside the SSO perimeter. Standard checklists do not reach it.

The teams that handle this well share one characteristic: they do the discovery work before the last day. They know which vaults the employee had access to, which API keys they generated, and which service accounts they owned. Zero-hour execution is fast because the inventory already exists.

Start with the audit. Mapping access before departure is the only way to ensure nothing is left orphaned after the fact.

Frequently asked questions about employee offboarding and access revocation

What is the biggest security risk when offboarding an employee?

The biggest risk is access that survives the standard SSO disable. This includes locally stored API keys used by AI tools and automation scripts, shared passwords that cannot be centrally revoked, and orphaned service accounts the employee created. Disabling an IdP account closes one door; these credentials represent separate, often undocumented entry points that require explicit revocation.

How quickly should access be revoked when an employee leaves?

For FedRAMP and StateRAMP environments, PS-4 implementation guidance points to a 4-hour window from the termination event. For organizations under SOC 2 or ISO 27001, same-day revocation is the current audit standard. EU organizations operating under NIS2 (Article 21) or GDPR (Article 32) have no fixed deadline, but regulators expect same-day execution — active access after termination is difficult to defend in an audit. In practice, zero-hour revocation — triggered automatically at the moment of termination — is the only approach that eliminates the risk window entirely.

How do you handle shared passwords when an employee is terminated?

Shared passwords must be rotated, not just access-removed. If the employee knew the password, they still know it after their vault access is revoked. The rotation step is what closes the vulnerability. An enterprise password manager with structured vault membership makes this process auditable: you can see exactly which shared credentials the employee had access to and rotate them systematically without disrupting the rest of the team.

What is the AI agent offboarding problem?

AI coding assistants and automation tools connected via MCP store API keys locally on the developer's machine — in .env files, shell profiles, or the tool's own credential store. These keys are not managed by SSO. Disabling the employee's IdP account does not revoke them. Until those specific API keys are identified and revoked (and the device is wiped), the credentials remain valid. This is a gap in virtually every standard offboarding checklist written before 2025.

Does disabling an SSO account revoke all application access?

No. SSO disable terminates federated sessions for applications that authenticate through the IdP. It does not affect: applications that authenticate independently (legacy tools, vendor portals), locally stored API keys and tokens, active sessions that were established before the disable and have not yet expired, and shared credentials the employee knew by memory. Each of these categories requires a separate revocation step.

What should an IT offboarding checklist include in 2026?

A complete 2026 IT offboarding checklist must cover: IdP/SSO account disable and active session termination, VPN and physical access revocation, shared password rotation via a password manager, API key and personal access token revocation across all developer platforms, NHI ownership transfer, AI tool credential audit, cloud storage access removal, SaaS application deprovisioning, and device wipe or selective MDM wipe for BYOD. The pre-departure discovery phase — mapping all of this before the last day — is what makes zero-hour execution reliable.

Shadow IT vs Shadow AI: Why AI is the bigger threat

Employees are using AI tools you didn’t approve, on accounts you can’t monitor, with data you can’t recover. Here’s what the risk actually looks like and what governance needs to address.

Passwork BlogAlex Muntyan

Insecure password sharing: 2026 risks and secure solutions

Every time a credential moves through Slack or email, you lose accountability, audit trail, and compliance posture in one step. This guide covers the real risks of insecure password sharing in 2026, why employees do it anyway, and how to migrate to vault-mediated access without disrupting your team.

Passwork BlogAlex Muntyan

Passwork wins Top Performer Spring 2026 on SourceForge

Passwork has been named a Top Performer Spring 2026 by SourceForge, ranking in the top 10% of 100,000+ solutions. The badge is based entirely on verified reviews — 4.8 stars overall, with a perfect 5.0 for support.

Passwork BlogAlex Muntyan

Las credenciales se mueven entre personas todos los días. Un desarrollador recibe una credencial de base de datos por Slack. Un contratista recibe una cuenta de administrador por correo electrónico. Finanzas guarda el inicio de sesión del sistema de nóminas en una hoja de cálculo compartida. Cada traspaso es una brecha esperando ocurrir. En 2026, esa espera tiene un valor medible, y a menudo se cuenta en minutos.

Este artículo desglosa exactamente lo que está en juego en 2026, por qué los empleados siguen haciéndolo de todos modos, y cómo solucionarlo sin que la seguridad se sienta como un castigo.

Puntos clave

• Las credenciales compartidas son un problema de gobernanza de acceso, no un problema de comportamiento del usuario. Las políticas que dependen de que los empleados hagan lo correcto fallan a escala. La arquitectura que hace que lo correcto sea lo más fácil, no falla.
• El acceso mediado por bóveda elimina el traspaso de credenciales sin procesar. Los usuarios acceden a los sistemas a través de la bóveda. Nunca ven la contraseña. Cada acción se registra y se vincula a una identidad individual.
• RBAC a nivel de grupo es el único modelo que escala. Gestionar permisos por individuo se vuelve inmanejable con más de una docena de personas. La herencia basada en grupos significa que un cambio cubre a todos en el equipo.
• MFA en cuentas privilegiadas limita el radio de explosión cuando las credenciales se ven comprometidas. El compromiso de credenciales es cuestión de cuándo, no de si. Un segundo factor significa que una contraseña robada por sí sola no es suficiente.
• Los registros de auditoría necesitan existir antes del incidente, no después. La respuesta a incidentes sin registros es reconstrucción de memoria. Construya el registro ahora.
• Los sistemas heredados son una restricción, no una excusa. Una cuenta de servicio almacenada en una bóveda con acceso mediado no es perfecta, pero está documentada, es auditable y revocable.
• Shadow IT es una señal de fricción. Si los empleados usan herramientas personales para credenciales de trabajo, la bóveda corporativa es más difícil de usar de lo que debería ser. Arregle la incorporación, no la política.
• Automatice la baja a nivel de directorio. Cada día que un ex empleado retiene acceso es una responsabilidad abierta. La integración con AD/LDAP la cierra sin intervención manual.

Los peligros de compartir contraseñas de forma insegura en 2026

Compartir contraseñas de forma insegura expone a las organizaciones al credential stuffing, la toma de control de cuentas (ATO) y las amenazas internas — todas las cuales se han vuelto significativamente más fáciles de ejecutar a medida que las herramientas de ataque mejoradas con IA han madurado. El problema central es que las credenciales compartidas destruyen la responsabilidad individual: cuando cinco personas usan el mismo inicio de sesión, ningún registro de auditoría indica cuál causó la brecha.

El panorama de amenazas ha cambiado materialmente a medida que el hardware GPU y las herramientas de descifrado han avanzado. La Tabla de Contraseñas de Hive Systems de 2025 muestra que las contraseñas cortas siguen peligrosamente expuestas independientemente de la complejidad. NIST SP 800-63B (actualizado en agosto de 2025) refleja la misma realidad: las directrices ahora establecen un mínimo de 15 caracteres y abandonan explícitamente las reglas de complejidad obligatorias en favor de la longitud, reconociendo que la resistencia a la fuerza bruta escala exponencialmente con la longitud, no con la sustitución de caracteres.

Tiempo que tarda un hacker en descifrar su contraseña por fuerza bruta en 2025

El credential stuffing ha escalado con estas herramientas. Los atacantes alimentan bases de datos de credenciales filtradas — miles de millones de pares de nombre de usuario/contraseña están disponibles en mercados de la dark web — en herramientas automatizadas que las prueban en cientos de servicios simultáneamente. Las contraseñas compartidas amplifican el radio de explosión: una credencial filtrada puede comprometer cada sistema donde esa contraseña fue reutilizada.

Los ataques de fuerza bruta también se han beneficiado de la IA. Los algoritmos de descifrado modernos usan redes neuronales para modelar patrones de sustitución humanos. Reemplazar a por @ o añadir ! a una palabra del diccionario ya no proporciona resistencia significativa. El modelo del atacante ya lo tiene en cuenta.

Las amenazas internas son el riesgo menos discutido. Cuando las credenciales se comparten de manera informal (por chat, correo electrónico o verbalmente) no hay registro de quién las posee en un momento dado. Un empleado descontento, un contratista cuyo contrato terminó, o un ex colega que nunca fue dado de baja correctamente puede retener acceso indefinidamente. Sin cuentas individuales y registros de auditoría, no se puede detectar el acceso, y mucho menos atribuirlo.

Cómo el uso compartido inseguro se corresponde con vectores de ataque específicos

Más allá de la conveniencia: Por qué los empleados siguen compartiendo contraseñas (y el costo real)

Los empleados comparten contraseñas de trabajo por las mismas razones mundanas de siempre: emergencias, cuentas de equipo compartidas, tareas delegadas. Compartir es la respuesta racional cuando el camino seguro es más lento que la tarea en sí. Cuando el proceso formal de solicitud de acceso tarda más, la gente lo omite.

Esa fricción tiene nombre. Un estudio revisado por pares de 2025 «Digital detox: Exploring the impact of cybersecurity fatigue on employee productivity and mental health» publicado en Discover Mental Health (PMC/PubMed) encuestó a 351 empleados de TI, finanzas, salud y educación y encontró que la fatiga de ciberseguridad (definida como agotamiento mental y emocional por demandas de seguridad repetidas) contribuye directamente a la desconexión, la reducción del cumplimiento y el agotamiento.

La fatiga de ciberseguridad — un estado de agotamiento mental y emocional por la exposición repetida a demandas de seguridad — se manifiesta a través de sobrecarga cognitiva, estrés y desconexión, impactando significativamente la productividad de los empleados y la resiliencia organizacional.

Cuando los ciclos de rotación obligatorios, los avisos de autenticación y las colas de solicitudes de acceso se acumulan, la seguridad deja de sentirse como protección y comienza a sentirse como fricción. La solución alternativa se vuelve obvia: compartir la credencial directamente y hacer el trabajo.

Esto es un fallo de diseño, no un problema de disciplina. La investigación de Proofpoint sobre amenazas centradas en el ser humano muestra consistentemente que los empleados evitan los controles porque el camino seguro tarda más que el inseguro. La credencial se comparte, la tarea se hace, y nadie piensa mucho en ello.

Hasta que algo sale mal. El DBIR 2025 de Verizon encontró que las credenciales siguen siendo uno de los puntos de entrada más explotados en todas las industrias. El Informe sobre el Costo de una Brecha de Datos 2025 de IBM pone un número a lo que eso significa en la práctica: las brechas que involucran credenciales comprometidas tardan un promedio de 246 días en identificarse y contenerse — más de ocho meses de exposición no detectada — y tienen un costo total promedio de $4.57M.

La brecha de responsabilidad es lo que hace esto difícil de recuperar. Una vez que una credencial se comparte, se pierde la capacidad de vincular acciones a individuos. Eso importa para la respuesta a incidentes, para las auditorías de cumplimiento, y para la pregunta básica de «¿quién cambió esta configuración a las 2 a.m. del sábado?» Las credenciales compartidas no solo crean riesgo — destruyen el registro de auditoría que se necesita para entender qué pasó después del hecho.

El efecto dominó: Impactos empresariales del uso compartido inseguro de credenciales

El uso compartido inseguro de credenciales crea exposición financiera, legal y reputacional que se extiende mucho más allá de la brecha inicial. El compromiso de credenciales es el vector de ataque dominante en todas las industrias. La brecha en sí rara vez es la parte más costosa. La respuesta a incidentes, el escrutinio regulatorio y las brechas en el registro de auditoría dejadas por las cuentas compartidas agravan el daño mucho después de la intrusión inicial.

La dimensión de cumplimiento es específica y tiene consecuencias. El Artículo 32 del GDPR requiere «medidas técnicas y organizativas apropiadas» para proteger los datos personales — y las credenciales compartidas sin registro de auditoría no cumplen ese estándar directamente. Los Criterios de Servicios de Confianza SOC 2 CC6.1 requieren controles de acceso lógico vinculados a identidades individuales. Los requisitos de Salvaguardas Técnicas de HIPAA bajo 45 CFR §164.312(a)(2)(i) exigen identificación única de usuario. Compartir un único inicio de sesión en un equipo viola los tres marcos simultáneamente.

El daño reputacional sigue una línea temporal diferente al daño financiero. Los costos de la brecha son inmediatos. Los costos reputacionales se acumulan. Clientes, socios y reguladores consideran el historial de brechas en sus evaluaciones de riesgo. Una brecha basada en credenciales que podría haberse prevenido con una gobernanza de acceso básica es particularmente difícil de explicar a una junta directiva o a un regulador.

El escenario de baja ilustra el riesgo concretamente. Un empleado se va con acceso a cinco cuentas compartidas. Como las credenciales nunca fueron asignadas formalmente, nadie sabe a qué sistemas podía acceder. Revocar el acceso significa:

1. Identificar cada contraseña compartida que el empleado conocía
2. Encontrar cada sistema donde se usó esa contraseña
3. Notificar a cada equipo que depende de esas credenciales
4. Rotarlas todas sin romper nada en producción

En la práctica, muchas organizaciones omiten esto por completo. Así es como los ex empleados retienen acceso activo durante meses.

Implementando gobernanza sin fricción: Soluciones para compartir contraseñas de forma segura

La gobernanza sin fricción es un modelo de gestión de credenciales que elimina el uso compartido inseguro haciendo que el acceso seguro sea más rápido que la solución alternativa. Se basa en tres componentes: responsabilidad individual (cada usuario tiene su propia identidad), RBAC (permisos asignados a roles, no a individuos) y registro de auditoría (cada evento de acceso se registra y es atribuible).

La implementación práctica requiere cuatro cosas:

1. Una bóveda de contraseñas con control de acceso basado en roles. Los usuarios acceden a las credenciales a través de la bóveda, no recibiendo la contraseña directamente. RBAC (control de acceso basado en roles) significa que los permisos se heredan de la pertenencia al grupo — añadir a alguien al grupo DevOps le da acceso a la bóveda de DevOps. Eliminarlo, el acceso se revoca inmediatamente.
2. Cifrado de extremo a extremo con arquitectura de conocimiento cero. Las credenciales se cifran del lado del cliente antes de salir del dispositivo del usuario. El servidor almacena texto cifrado. Incluso un servidor comprometido no expone nada utilizable. AES-256 es el estándar actual para esto.
3. MFA en cada cuenta. La autenticación multifactor (MFA) no previene el uso compartido de credenciales, pero limita el daño cuando una credencial compartida se ve comprometida. Un atacante con una contraseña robada todavía necesita el segundo factor. Para cuentas privilegiadas, los tokens de hardware o las llaves FIDO2 son preferibles.
4. Frases de contraseña en lugar de contraseñas cortas complejas. Una frase de contraseña de 16 caracteres — cuatro palabras aleatorias — es más resistente a los ataques de fuerza bruta y más fácil de recordar para los usuarios que P@ssw0rd!2. La longitud proporciona resistencia exponencial; la complejidad proporciona resistencia lineal.

La integración de Gestión de Identidad y Acceso (IAM) extiende este modelo al nivel de directorio. Cuando Passwork está conectado a AD/LDAP, el aprovisionamiento y desaprovisionamiento de usuarios ocurre automáticamente. Un usuario deshabilitado en Active Directory pierde el acceso a la bóveda sin ninguna intervención manual. Ese es el problema de la baja resuelto a nivel de infraestructura.

Abordando sistemas heredados y shadow IT

Los sistemas heredados son la razón más común por la que los equipos justifican las credenciales compartidas. Un sistema construido en 2008 puede no tener concepto de cuentas de usuario individuales — tiene un inicio de sesión de administrador, y todos los que necesitan acceso lo usan. Esta es una restricción real, no un fallo de política.

La solución práctica es un patrón de cuenta de servicio con acceso mediado por bóveda. La credencial compartida vive en la bóveda, cifrada. Los usuarios acceden al sistema a través de la gestión de sesiones de la bóveda — nunca ven la contraseña sin procesar. El acceso se registra a nivel de bóveda incluso si el sistema objetivo no tiene capacidad de auditoría nativa. Cuando alguien se va, se rota la credencial en la bóveda. El sistema en sí no necesita cambiar.

Los secretos de un solo uso y los enlaces seguros abordan el problema adyacente: ocasionalmente, una credencial genuinamente necesita ser transmitida a alguien fuera de su bóveda. Un enlace de secreto de un solo uso expira después de una sola visualización o después de una ventana de tiempo definida. No es una solución permanente, pero es categóricamente más seguro que un mensaje de Slack que permanece en el historial del chat indefinidamente.

Shadow IT — empleados que usan gestores de credenciales personales para contraseñas de trabajo — es más difícil de detectar y conlleva sus propios riesgos. Una bóveda personal no tiene registro de auditoría organizacional, ni gancho de baja, ni garantía de estándares de cifrado. La solución es organizacional: hacer que la bóveda corporativa sea más fácil de usar que la personal. Si la incorporación toma cinco minutos y la extensión del navegador autocompleta las credenciales, la mayoría de los empleados la usarán. La fricción es el enemigo de la adopción.

Cómo Passwork hace del uso compartido seguro el valor predeterminado

Los problemas descritos anteriormente (credenciales compartidas, bajas defectuosas, registros de auditoría faltantes, restricciones de sistemas heredados) son exactamente para lo que Passwork está diseñado. Así es como cada uno se corresponde con una capacidad específica.

• Credenciales compartidas sin responsabilidad. Passwork reemplaza los traspasos directos de contraseñas con acceso mediado por bóveda. Los usuarios interactúan con los sistemas a través de la bóveda. Nunca reciben la credencial sin procesar. Cada evento de acceso se registra, tiene marca de tiempo y está vinculado a una identidad individual.
• Bajas defectuosas. Passwork se integra con AD/LDAP. Cuando un usuario se deshabilita en Active Directory, el acceso a la bóveda se revoca automáticamente. Sin rotación manual, sin conjeturas sobre a qué cuentas podía acceder.
• Sin registro de auditoría. Cada acción en Passwork se registra. Cuando ocurre un incidente, tiene un registro completo y atribuible. No «alguien del equipo DevOps», sino un usuario específico en un momento específico.
• Sistemas heredados con inicios de sesión compartidos. Passwork admite un patrón de cuenta de servicio: la credencial vive en la bóveda, cifrada. Los usuarios acceden al sistema a través de sesiones mediadas por la bóveda y nunca ven la contraseña. El sistema objetivo no necesita cambiar.
• Uso compartido externo ocasional. Para credenciales que genuinamente necesitan salir de la bóveda — un contratista, un traspaso único — Passwork genera enlaces de secreto de un solo uso que expiran después de una sola visualización o una ventana de tiempo definida. Más seguro que un mensaje de Slack por diseño.
• Brechas de cumplimiento. El control de acceso basado en roles, la vinculación de identidad individual y un registro de auditoría completo apoyan directamente los requisitos del Artículo 32 del GDPR, SOC 2 CC6.1 y HIPAA §164.312. El registro de auditoría que necesita para un regulador es el mismo que necesita para la respuesta a incidentes.

Pasando del uso compartido inseguro al seguro: Una migración práctica de 6 pasos

La mayoría de los equipos fracasan porque la transición del uso compartido informal al acceso estructurado se siente como un proyecto para el que nadie tiene tiempo. Esta guía lo divide en seis pasos que pueden ejecutarse de forma incremental, reduciendo la exposición en cada etapa sin interrumpir las operaciones.

1. Audite lo que realmente está compartiendo. Antes de poder solucionar el problema, necesita conocer su alcance. Encueste a sus equipos y documente cada credencial compartida: a qué sistema accede, quién la posee y cómo se distribuyó. Las hojas de cálculo, el historial de Slack y los hilos de correo electrónico son las fuentes más comunes. No omita este paso. No puede revocar el acceso que no sabe que existe.
2. Clasifique por riesgo. No todas las credenciales compartidas conllevan el mismo riesgo. Priorice por radio de explosión: primero las credenciales de bases de datos de producción y las cuentas de administrador, segundo las herramientas internas, al final las cuentas compartidas de baja sensibilidad. Esto le da una secuencia de migración que reduce la exposición rápidamente sin requerir que mueva todo a la vez.
3. Despliegue la bóveda e incorpore a su equipo. Configure Passwork y conéctelo a su servicio de directorio (AD/LDAP). Cree grupos basados en roles que reflejen su estructura de equipo existente. La incorporación funciona mejor cuando la bóveda ya está poblada antes de pedir a las personas que la usen. Importe las credenciales existentes en las bóvedas apropiadas antes de la reunión de implementación.
4. Migre las credenciales en orden de prioridad. Mueva primero las credenciales de alto riesgo a la bóveda. Para cada una: almacénela en Passwork, asigne acceso al grupo de rol relevante e inmediatamente deje de distribuir la contraseña sin procesar. Para sistemas heredados que no pueden admitir cuentas individuales, implemente el patrón de cuenta de servicio — credencial en la bóveda, acceso mediado a través de Passwork.
5. Imponga el nuevo proceso y retire el antiguo. Bloquee los canales informales. Esto significa una política clara: no credenciales en Slack, correo electrónico o documentos compartidos. Para el uso compartido externo, use los enlaces de secreto de un solo uso de Passwork en lugar de mensajes directos. La política solo funciona si la bóveda ya es más fácil de usar que la solución alternativa — por eso los pasos 3 y 4 vienen primero.
6. Audite, rote y mantenga. Una vez que las credenciales están en la bóveda, use las herramientas de auditoría de seguridad de Passwork para identificar contraseñas débiles, marcar credenciales que no se han rotado y revisar los registros de acceso en busca de anomalías. Establezca un calendario de rotación para cuentas privilegiadas. Revise las membresías de grupos de roles trimestralmente — o active una revisión automáticamente ante cualquier cambio organizacional.

La migración completa para un equipo de 50 personas típicamente toma de una a dos semanas cuando se ejecuta en este orden. La auditoría del paso 1 generalmente toma más tiempo.

Puntos clave para CISOs y líderes de TI

El cambio fundamental requerido es tratar el uso compartido de credenciales como un problema de gobernanza de acceso, no como un problema de comportamiento del usuario. Las políticas que dependen de que los empleados «hagan lo correcto» fallarán a escala. La arquitectura que hace que lo correcto sea lo fácil, no fallará.

• Reemplace las credenciales compartidas con acceso mediado por bóveda. Los usuarios obtienen acceso a los sistemas a través de la bóveda, no a través de la contraseña en sí.
• Implemente RBAC a nivel de grupo. La gestión de permisos individuales no escala; la herencia basada en grupos sí.
• Imponga MFA en todas las cuentas privilegiadas. El compromiso de credenciales es cuestión de cuándo, no de si — MFA limita el daño.
• Establezca registros de auditoría antes de necesitarlos. La respuesta a incidentes sin registros es conjetura.
• Aborde los sistemas heredados explícitamente. Una cuenta de servicio en una bóveda no es una solución perfecta, pero es documentada y auditable.
• Trate el shadow IT como una señal de diseño. Si los empleados usan herramientas personales para credenciales de trabajo, sus herramientas corporativas tienen un problema de fricción.
• Automatice las bajas. Cada día que un ex empleado retiene acceso es una responsabilidad. La integración con el directorio elimina el paso manual.

Conclusión

Las credenciales compartidas siempre han sido una responsabilidad. En 2026, con herramientas de descifrado mejoradas con IA y costos de brechas que promedian $4.57 millones por incidente, son indefendibles.

La solución no requiere pedir a los empleados que sean más disciplinados. Requiere construir sistemas donde el camino seguro también sea el más rápido. Cuando el acceso a la bóveda toma menos tiempo que un mensaje de Slack, la gente usa la bóveda. Cuando la baja activa la revocación automática, los ex empleados no retienen acceso durante meses. Cuando cada acción se registra, la respuesta a incidentes deja de ser conjetura.

Comience con sus credenciales compartidas de mayor riesgo: cuentas de administrador, acceso a bases de datos de producción, cualquier cosa que toque datos regulados. Muévalas a una bóveda con controles de acceso basados en roles primero. Luego trabaje hacia afuera, en orden de prioridad, usando la migración de seis pasos anterior.

Preguntas frecuentes

¿Por qué compartir contraseñas de forma insegura es un riesgo de seguridad significativo en 2026?

Las herramientas de descifrado mejoradas con IA pueden romper una contraseña de 8 caracteres en menos de 12 minutos en hardware de consumo (Hive Systems, 2025), y los ataques de credential stuffing se ejecutan a escala industrial usando miles de millones de pares filtrados. Las contraseñas compartidas eliminan la responsabilidad individual — cuando ocurre una brecha, no hay registro de auditoría para identificar quién tenía acceso o cuándo.

¿Cómo pueden las organizaciones gestionar de forma segura las contraseñas para sistemas heredados que solo admiten un único inicio de sesión compartido?

Use un patrón de cuenta de servicio: almacene la credencial compartida en una bóveda cifrada y otorgue a los usuarios acceso mediado por bóveda en lugar de la contraseña sin procesar. El acceso se registra a nivel de bóveda incluso cuando el sistema objetivo no tiene capacidad de auditoría nativa. Cuando hay cambios de personal, rote la credencial en la bóveda — el sistema en sí no necesita cambiar.

¿Qué es la gobernanza sin fricción en el contexto de la gestión de credenciales?

La gobernanza sin fricción es un modelo de gestión de credenciales que hace que el acceso seguro sea más rápido que la solución alternativa. Combina identidades de usuario individuales, RBAC para herencia de permisos basada en grupos y registro de auditoría completo — para que los empleados nunca necesiten compartir una contraseña sin procesar para hacer su trabajo.

¿Cómo crea el shadow IT riesgos de seguridad de credenciales?

Cuando los empleados almacenan contraseñas de trabajo en gestores de credenciales personales, la organización pierde registros de auditoría, ganchos de baja y control sobre los estándares de cifrado. La bóveda personal de un empleado que se va retiene cada credencial que guardó allí. La solución es hacer que la bóveda corporativa sea más fácil de usar que la alternativa personal — incorporación más rápida, autocompletado del navegador, acceso móvil.

¿Qué marcos de cumplimiento se violan con las credenciales compartidas?

Las credenciales compartidas sin atribución individual violan el Artículo 32 del GDPR (medidas técnicas apropiadas para la protección de datos), los Criterios de Servicios de Confianza SOC 2 CC6.1 (controles de acceso lógico vinculados a identidades individuales) y HIPAA 45 CFR §164.312(a)(2)(i) (identificación única de usuario). Los tres requieren la capacidad de vincular eventos de acceso a una persona específica.

¿Cuánto tiempo suele tardar en detectarse una brecha basada en credenciales?

Según el Informe sobre el Costo de una Brecha de Datos 2025 de IBM, las brechas que involucran credenciales comprometidas tardan un promedio de 246 días en identificarse y contenerse. Las cuentas compartidas lo empeoran: sin líneas base de comportamiento individual, la actividad anómala se mezcla con el tráfico normal de múltiples usuarios y rara vez activa alertas.

Shadow IT vs Shadow AI: Por qué la IA es la mayor amenaza

Los empleados están usando herramientas de IA que usted no aprobó, en cuentas que no puede monitorear, con datos que no puede recuperar. Así es como realmente se ve el riesgo y qué necesita abordar la gobernanza.

Passwork BlogAlex Muntyan

Ataques de fuerza bruta en 2026: Tipos, ejemplos y cómo prevenirlos

Clústeres de GPU, listas de palabras asistidas por IA, botnets de 2.8M de dispositivos. La fuerza bruta ha escalado. Esta guía cubre seis variantes de ataque, casos reales de 2025 y una estrategia de defensa en capas que su equipo puede implementar hoy.

Passwork BlogAlex Muntyan

Passwork gana Top Performer Primavera 2026 en SourceForge

Passwork ha sido nombrado Top Performer Primavera 2026 por SourceForge, ubicándose en el 10% superior de más de 100,000 soluciones. La insignia se basa completamente en reseñas verificadas — 4.8 estrellas en general, con un perfecto 5.0 en soporte.

Passwork BlogAlex Muntyan

Anmeldedaten werden täglich zwischen Personen weitergegeben. Ein Entwickler erhält eine Datenbank-Zugangsberechtigung über Slack. Ein Auftragnehmer bekommt ein Admin-Konto per E-Mail. Die Finanzabteilung speichert das Login für das Gehaltsabrechnungssystem in einer gemeinsamen Tabelle. Jede Weitergabe ist ein Sicherheitsvorfall, der nur darauf wartet, zu passieren. Im Jahr 2026 hat dieses Warten einen messbaren Wert — oft in Minuten gezählt.

Dieser Artikel zeigt genau, was 2026 auf dem Spiel steht, warum Mitarbeiter es trotzdem weiter tun, und wie das Problem gelöst werden kann, ohne dass sich Sicherheit wie eine Strafe anfühlt.

Wichtige Erkenntnisse

• Geteilte Anmeldedaten sind ein Problem der Zugriffsverwaltung, kein Problem des Benutzerverhaltens. Richtlinien, die darauf setzen, dass Mitarbeiter das Richtige tun, scheitern im großen Maßstab. Eine Architektur, die das Richtige zum Einfachsten macht, scheitert nicht.
• Tresor-vermittelter Zugriff eliminiert die direkte Weitergabe von Anmeldedaten. Benutzer greifen über den Tresor auf Systeme zu. Sie sehen das Passwort nie. Jede Aktion wird protokolliert und einer individuellen Identität zugeordnet.
• RBAC auf Gruppenebene ist das einzige Modell, das skaliert. Die Verwaltung von Berechtigungen pro Person bricht bei mehr als einem Dutzend Personen zusammen. Gruppenbasierte Vererbung bedeutet, dass eine Änderung alle im Team abdeckt.
• MFA bei privilegierten Konten begrenzt den Schadensradius bei kompromittierten Anmeldedaten. Die Kompromittierung von Anmeldedaten ist keine Frage des Ob, sondern des Wann. Ein zweiter Faktor bedeutet, dass ein gestohlenes Passwort allein nicht ausreicht.
• Audit-Trails müssen vor dem Vorfall existieren, nicht danach. Incident Response ohne Protokolle ist Rekonstruktion aus dem Gedächtnis. Der Trail muss jetzt aufgebaut werden.
• Legacy-Systeme sind eine Einschränkung, keine Ausrede. Ein Service-Konto, das in einem Tresor mit vermitteltem Zugriff gespeichert ist, ist nicht perfekt, aber es ist dokumentiert, überprüfbar und widerrufbar.
• Shadow IT ist ein Friktionssignal. Wenn Mitarbeiter persönliche Tools für Arbeits-Anmeldedaten verwenden, ist der Unternehmens-Tresor schwieriger zu nutzen, als er sein sollte. Das Onboarding muss verbessert werden, nicht die Richtlinie.
• Offboarding auf Verzeichnisebene automatisieren. Jeder Tag, an dem ein ehemaliger Mitarbeiter Zugriff behält, ist eine offene Haftung. AD/LDAP-Integration schließt sie ohne manuelle Eingriffe.

Die Gefahren unsicherer Passwortweitergabe im Jahr 2026

Unsichere Passwortweitergabe setzt Organisationen Credential Stuffing, Account Takeover (ATO) und Insider-Bedrohungen aus — all dies ist mit der Reifung KI-gestützter Angriffswerkzeuge deutlich einfacher geworden. Das Kernproblem ist, dass geteilte Anmeldedaten die individuelle Verantwortlichkeit zerstören: Wenn fünf Personen dasselbe Login verwenden, zeigt kein Audit-Trail, welche Person den Sicherheitsvorfall verursacht hat.

Die Bedrohungslandschaft hat sich mit dem Fortschritt von GPU-Hardware und Cracking-Tools wesentlich verändert. Die Passwort-Tabelle von Hive Systems für 2025 zeigt, dass kurze Passwörter unabhängig von ihrer Komplexität gefährlich exponiert bleiben. NIST SP 800-63B (aktualisiert im August 2025) spiegelt dieselbe Realität wider: Die Richtlinien setzen nun eine Mindestgrenze von 15 Zeichen fest und verzichten ausdrücklich auf obligatorische Komplexitätsregeln zugunsten der Länge. Dies erkennt an, dass Brute-Force-Resistenz exponentiell mit der Länge skaliert, nicht mit Zeichenersetzungen.

Zeit, die ein Hacker benötigt, um Ihr Passwort 2025 per Brute-Force zu knacken

Credential Stuffing hat mit diesen Werkzeugen skaliert. Angreifer speisen geleakte Anmeldedaten-Datenbanken — Milliarden von Benutzername/Passwort-Paaren sind auf Dark-Web-Märkten verfügbar — in automatisierte Tools ein, die sie gleichzeitig bei Hunderten von Diensten testen. Geteilte Passwörter verstärken den Schadensradius: Ein geleaktes Anmeldedatum kann jedes System kompromittieren, bei dem dieses Passwort wiederverwendet wurde.

Brute-Force-Angriffe haben ebenfalls von KI profitiert. Moderne Cracking-Algorithmen nutzen neuronale Netzwerke, um menschliche Ersetzungsmuster zu modellieren. Das Ersetzen von a durch @ oder das Anhängen von ! an ein Wörterbuchwort bietet keinen nennenswerten Widerstand mehr. Das Modell des Angreifers berücksichtigt dies bereits.

Insider-Bedrohungen sind das weniger diskutierte Risiko. Wenn Anmeldedaten informell geteilt werden (über Chat, E-Mail oder mündlich), gibt es keine Aufzeichnung darüber, wer sie zu einem bestimmten Zeitpunkt besitzt. Ein verärgerter Mitarbeiter, ein Auftragnehmer, dessen Engagement beendet wurde, oder ein ehemaliger Kollege, dessen Offboarding nie ordnungsgemäß durchgeführt wurde, kann auf unbestimmte Zeit Zugriff behalten. Ohne individuelle Konten und Audit-Trails kann der Zugriff weder erkannt noch zugeordnet werden.

Wie unsichere Weitergabe auf spezifische Angriffsvektoren abbildet

Jenseits der Bequemlichkeit: Warum Mitarbeiter immer noch Passwörter teilen (und die tatsächlichen Kosten)

Mitarbeiter teilen Arbeitspasswörter aus denselben banalen Gründen wie immer: Notfälle, gemeinsam genutzte Team-Konten, delegierte Aufgaben. Das Teilen ist die rationale Reaktion, wenn der sichere Weg langsamer ist als die Aufgabe selbst. Wenn der formale Zugriffsanfrageprozess länger dauert, überspringen ihn die Leute.

Diese Friktion hat einen Namen. Eine 2025 peer-reviewed veröffentlichte Studie „Digital detox: Exploring the impact of cybersecurity fatigue on employee productivity and mental health", publiziert in Discover Mental Health (PMC/PubMed), befragte 351 Mitarbeiter aus IT, Finanzen, Gesundheitswesen und Bildung und stellte fest, dass Cybersicherheits-Müdigkeit (definiert als mentale und emotionale Erschöpfung durch wiederholte Sicherheitsanforderungen) direkt zu Desengagement, reduzierter Compliance und Burnout beiträgt.

Cybersicherheits-Müdigkeit — ein Zustand mentaler und emotionaler Erschöpfung durch wiederholte Exposition gegenüber Sicherheitsanforderungen — manifestiert sich durch kognitive Überlastung, Stress und Desengagement und beeinflusst erheblich die Mitarbeiterproduktivität und organisatorische Resilienz.

Wenn sich obligatorische Rotationszyklen, Authentifizierungsaufforderungen und Zugriffsanfrage-Warteschlangen häufen, fühlt sich Sicherheit nicht mehr wie Schutz an und beginnt sich wie Friktion anzufühlen. Der Workaround wird offensichtlich: die Anmeldedaten direkt teilen und die Arbeit erledigen.

Dies ist ein Designfehler, kein Disziplinproblem. Die Forschung von Proofpoint zu menschenzentrierten Bedrohungen zeigt durchgängig, dass Mitarbeiter Kontrollen umgehen, weil der sichere Weg länger dauert als der unsichere. Die Anmeldedaten werden geteilt, die Aufgabe wird erledigt, und niemand denkt viel darüber nach.

Bis etwas schiefgeht. Der DBIR 2025 von Verizon stellte fest, dass Anmeldedaten branchenübergreifend einer der am häufigsten ausgenutzten Einstiegspunkte bleiben. Der Cost of a Data Breach Report 2025 von IBM beziffert, was das in der Praxis bedeutet: Sicherheitsvorfälle mit kompromittierten Anmeldedaten benötigen durchschnittlich 246 Tage zur Identifizierung und Eindämmung — über acht Monate unentdeckter Exposition — und verursachen durchschnittliche Gesamtkosten von 4,57 Mio. USD.

Die Verantwortlichkeitslücke ist das, was die Wiederherstellung so schwierig macht. Sobald Anmeldedaten geteilt werden, verliert man die Möglichkeit, Aktionen Einzelpersonen zuzuordnen. Das ist wichtig für Incident Response, für Compliance-Audits und für die grundlegende Frage „Wer hat diese Konfiguration am Samstag um 2 Uhr morgens geändert?" Geteilte Anmeldedaten schaffen nicht nur Risiken — sie zerstören den Audit-Trail, der benötigt wird, um im Nachhinein zu verstehen, was passiert ist.

Der Dominoeffekt: Geschäftliche Auswirkungen unsicherer Anmeldedaten-Weitergabe

Unsichere Anmeldedaten-Weitergabe schafft finanzielle, rechtliche und reputationsbezogene Risiken, die weit über den ursprünglichen Sicherheitsvorfall hinausgehen. Die Kompromittierung von Anmeldedaten ist branchenübergreifend der dominierende Angriffsvektor. Der Sicherheitsvorfall selbst ist selten der teuerste Teil. Incident Response, regulatorische Prüfungen und die Audit-Trail-Lücken, die von geteilten Konten hinterlassen werden, verstärken den Schaden lange nach dem ursprünglichen Eindringen.

Die Compliance-Dimension ist spezifisch und folgenreich. DSGVO Artikel 32 verlangt „geeignete technische und organisatorische Maßnahmen" zum Schutz personenbezogener Daten — und geteilte Anmeldedaten ohne Audit-Trail erfüllen diesen Standard direkt nicht. SOC 2 Trust Services Criteria CC6.1 erfordert logische Zugriffskontrollen, die an individuelle Identitäten gebunden sind. Die Technical Safeguard-Anforderungen von HIPAA gemäß 45 CFR §164.312(a)(2)(i) verlangen eine eindeutige Benutzeridentifikation. Das Teilen eines einzelnen Logins im Team verstößt gleichzeitig gegen alle drei Frameworks.

Reputationsschäden folgen einem anderen Zeitplan als finanzielle Schäden. Die Kosten des Sicherheitsvorfalls sind unmittelbar. Die Reputationskosten kumulieren sich. Kunden, Partner und Regulierungsbehörden berücksichtigen alle die Historie von Sicherheitsvorfällen in ihren Risikobewertungen. Ein anmeldedatenbasierter Sicherheitsvorfall, der mit grundlegender Zugriffsverwaltung hätte verhindert werden können, ist besonders schwer gegenüber einem Vorstand oder einer Regulierungsbehörde zu erklären.

Das Offboarding-Szenario veranschaulicht das Risiko konkret. Ein Mitarbeiter verlässt das Unternehmen mit Zugriff auf fünf geteilte Konten. Da Anmeldedaten nie formell zugewiesen wurden, weiß niemand, welche Systeme er erreichen konnte. Das Widerrufen des Zugriffs bedeutet:

1. Identifizieren jedes geteilten Passworts, das der Mitarbeiter kannte
2. Finden jedes Systems, bei dem dieses Passwort verwendet wurde
3. Benachrichtigen jedes Teams, das von diesen Anmeldedaten abhängt
4. Rotieren aller Anmeldedaten, ohne etwas in der Produktion zu beschädigen

In der Praxis überspringen viele Organisationen dies vollständig. So behalten ehemalige Mitarbeiter monatelang aktiven Zugriff.

Implementierung reibungsloser Governance: Lösungen für sichere Passwortweitergabe

Reibungslose Governance ist ein Anmeldedaten-Management-Modell, das unsichere Weitergabe eliminiert, indem sicherer Zugriff schneller als der Workaround gemacht wird. Es basiert auf drei Komponenten: individuelle Verantwortlichkeit (jeder Benutzer hat seine eigene Identität), RBAC (Berechtigungen werden Rollen zugewiesen, nicht Einzelpersonen) und Audit-Logging (jedes Zugriffsereignis wird aufgezeichnet und ist zuordenbar).

Die praktische Implementierung erfordert vier Dinge:

1. Einen Passwort-Tresor mit rollenbasierter Zugriffskontrolle. Benutzer greifen über den Tresor auf Anmeldedaten zu, nicht durch direkten Erhalt des Passworts. RBAC (rollenbasierte Zugriffskontrolle) bedeutet, dass Berechtigungen von der Gruppenmitgliedschaft geerbt werden — fügen Sie jemanden zur DevOps-Gruppe hinzu, erhält er DevOps-Tresor-Zugriff. Entfernen Sie ihn, wird der Zugriff sofort widerrufen.
2. Ende-zu-Ende-Verschlüsselung mit einer Zero-Knowledge-Architektur. Anmeldedaten werden clientseitig verschlüsselt, bevor sie das Gerät des Benutzers verlassen. Der Server speichert Chiffretext. Selbst ein kompromittierter Server exponiert nichts Verwertbares. AES-256 ist hierfür der aktuelle Standard.
3. MFA auf jedem Konto. Multi-Faktor-Authentifizierung (MFA) verhindert nicht die Weitergabe von Anmeldedaten, begrenzt aber den Schaden, wenn ein geteiltes Anmeldedatum kompromittiert wird. Ein Angreifer mit einem gestohlenen Passwort benötigt immer noch den zweiten Faktor. Für privilegierte Konten sind Hardware-Token oder FIDO2-Schlüssel vorzuziehen.
4. Passphrasen statt komplexer kurzer Passwörter. Eine 16-Zeichen-Passphrase — vier zufällige Wörter — ist sowohl resistenter gegen Brute-Force-Angriffe als auch einfacher für Benutzer zu merken als P@ssw0rd!2. Länge bietet exponentiellen Widerstand; Komplexität bietet linearen Widerstand.

Identity and Access Management (IAM)-Integration erweitert dieses Modell auf Verzeichnisebene. Wenn Passwork mit AD/LDAP verbunden ist, erfolgen Benutzerbereitstellung und -deaktivierung automatisch. Ein in Active Directory deaktivierter Benutzer verliert den Tresor-Zugriff ohne manuelle Eingriffe. Das ist das Offboarding-Problem, gelöst auf Infrastrukturebene.

Umgang mit Legacy-Systemen und Shadow IT

Legacy-Systeme sind der häufigste Grund, warum Teams geteilte Anmeldedaten rechtfertigen. Ein 2008 entwickeltes System hat möglicherweise kein Konzept für individuelle Benutzerkonten — es hat ein Admin-Login, und jeder, der Zugriff benötigt, nutzt es. Dies ist eine echte Einschränkung, kein Richtlinienversagen.

Die praktische Lösung ist ein Service-Account-Muster mit Tresor-vermitteltem Zugriff. Das geteilte Anmeldedatum befindet sich im Tresor, verschlüsselt. Benutzer greifen über das Session-Management des Tresors auf das System zu — sie sehen nie das rohe Passwort. Der Zugriff wird auf Tresor-Ebene protokolliert, auch wenn das Zielsystem keine native Audit-Fähigkeit hat. Wenn jemand das Unternehmen verlässt, wird das Anmeldedatum im Tresor rotiert. Das System selbst muss sich nicht ändern.

Einmal-Secrets und sichere Links adressieren das angrenzende Problem: Gelegentlich müssen Anmeldedaten wirklich an jemanden außerhalb Ihres Tresors übermittelt werden. Ein Einmal-Secret-Link läuft nach einer einzelnen Ansicht oder nach einem definierten Zeitfenster ab. Es ist keine dauerhafte Lösung, aber kategorisch sicherer als eine Slack-Nachricht, die auf unbestimmte Zeit im Chat-Verlauf verbleibt.

Shadow IT — Mitarbeiter, die persönliche Passwort-Manager für Arbeitspasswörter verwenden — ist schwieriger zu erkennen und birgt eigene Risiken. Ein persönlicher Tresor hat keinen organisatorischen Audit-Trail, keinen Offboarding-Hook und keine Garantie für Verschlüsselungsstandards. Die Lösung ist organisatorisch: Den Unternehmens-Tresor einfacher nutzbar machen als den persönlichen. Wenn das Onboarding fünf Minuten dauert und die Browser-Erweiterung Anmeldedaten automatisch ausfüllt, werden die meisten Mitarbeiter ihn nutzen. Friktion ist der Feind der Akzeptanz.

Wie Passwork sichere Weitergabe zum Standard macht

Die oben beschriebenen Probleme (geteilte Anmeldedaten, fehlerhaftes Offboarding, fehlende Audit-Trails, Legacy-System-Einschränkungen) sind genau das, wofür Passwork entwickelt wurde. Hier ist, wie jedes Problem einer spezifischen Fähigkeit zugeordnet wird.

• Geteilte Anmeldedaten ohne Verantwortlichkeit. Passwork ersetzt die direkte Passwortweitergabe durch Tresor-vermittelten Zugriff. Benutzer interagieren mit Systemen über den Tresor. Sie erhalten nie das rohe Anmeldedatum. Jedes Zugriffsereignis wird protokolliert, mit Zeitstempel versehen und einer individuellen Identität zugeordnet.
• Fehlerhaftes Offboarding. Passwork integriert sich mit AD/LDAP. Wenn ein Benutzer in Active Directory deaktiviert wird, wird der Tresor-Zugriff automatisch widerrufen. Keine manuelle Rotation, kein Rätselraten darüber, welche Konten er erreichen konnte.
• Kein Audit-Trail. Jede Aktion in Passwork wird aufgezeichnet. Wenn ein Vorfall auftritt, haben Sie ein vollständiges, zuordenbares Protokoll. Nicht „jemand im DevOps-Team", sondern ein spezifischer Benutzer zu einem bestimmten Zeitpunkt.
• Legacy-Systeme mit geteilten Logins. Passwork unterstützt ein Service-Account-Muster: Das Anmeldedatum befindet sich im Tresor, verschlüsselt. Benutzer greifen über Tresor-vermittelte Sitzungen auf das System zu und sehen nie das Passwort. Das Zielsystem muss sich nicht ändern.
• Gelegentliche externe Weitergabe. Für Anmeldedaten, die wirklich den Tresor verlassen müssen — ein Auftragnehmer, eine einmalige Übergabe — generiert Passwork Einmal-Secret-Links, die nach einer einzelnen Ansicht oder einem definierten Zeitfenster ablaufen. Sicherer als eine Slack-Nachricht — by Design.
• Compliance-Lücken. Rollenbasierte Zugriffskontrolle, individuelle Identitätsbindung und ein vollständiges Audit-Log unterstützen direkt die Anforderungen von DSGVO Artikel 32, SOC 2 CC6.1 und HIPAA §164.312. Der Audit-Trail, den Sie für eine Regulierungsbehörde benötigen, ist derselbe, den Sie für Incident Response benötigen.

Von unsicherer zu sicherer Weitergabe: Eine praktische 6-Schritte-Migration

Die meisten Teams scheitern, weil der Übergang von informeller Weitergabe zu strukturiertem Zugriff wie ein Projekt wirkt, für das niemand Zeit hat. Dieser Leitfaden unterteilt ihn in sechs Schritte, die inkrementell ausgeführt werden können und die Exposition in jeder Phase reduzieren, ohne den Betrieb zu stören.

1. Auditieren, was tatsächlich geteilt wird. Bevor das Problem behoben werden kann, muss sein Umfang bekannt sein. Befragen Sie Ihre Teams und dokumentieren Sie jedes geteilte Anmeldedatum: auf welches System es zugreift, wer es besitzt und wie es verteilt wurde. Tabellen, Slack-Verlauf und E-Mail-Threads sind die häufigsten Quellen. Überspringen Sie diesen Schritt nicht. Zugriff, der nicht bekannt ist, kann nicht widerrufen werden.
2. Nach Risiko klassifizieren. Nicht alle geteilten Anmeldedaten bergen das gleiche Risiko. Priorisieren Sie nach Schadensradius: Produktionsdatenbank-Anmeldedaten und Admin-Konten zuerst, interne Tooling-Anmeldedaten als zweites, wenig sensitive geteilte Konten zuletzt. Dies ergibt eine Migrationssequenz, die die Exposition schnell reduziert, ohne alles auf einmal verschieben zu müssen.
3. Den Tresor bereitstellen und Ihr Team onboarden. Richten Sie Passwork ein und verbinden Sie es mit Ihrem Verzeichnisdienst (AD/LDAP). Erstellen Sie rollenbasierte Gruppen, die Ihre bestehende Teamstruktur widerspiegeln. Das Onboarding funktioniert am besten, wenn der Tresor bereits befüllt ist, bevor Sie die Leute bitten, ihn zu nutzen. Importieren Sie bestehende Anmeldedaten in die entsprechenden Tresore vor dem Rollout-Meeting.
4. Anmeldedaten in Prioritätsreihenfolge migrieren. Verschieben Sie zuerst Hochrisiko-Anmeldedaten in den Tresor. Für jedes: In Passwork speichern, Zugriff der relevanten Rollengruppe zuweisen und sofort aufhören, das rohe Passwort zu verteilen. Für Legacy-Systeme, die keine individuellen Konten unterstützen können, implementieren Sie das Service-Account-Muster — Anmeldedaten im Tresor, Zugriff vermittelt durch Passwork.
5. Den neuen Prozess durchsetzen und den alten abschaffen. Blockieren Sie die informellen Kanäle. Das bedeutet eine klare Richtlinie: keine Anmeldedaten in Slack, E-Mail oder geteilten Dokumenten. Für externe Weitergabe nutzen Sie die Einmal-Secret-Links von Passwork anstelle von Direktnachrichten. Die Richtlinie funktioniert nur, wenn der Tresor bereits einfacher zu nutzen ist als der Workaround — weshalb die Schritte 3 und 4 zuerst kommen.
6. Auditieren, rotieren und pflegen. Sobald Anmeldedaten im Tresor sind, nutzen Sie die Sicherheits-Audit-Tools von Passwork, um schwache Passwörter zu identifizieren, Anmeldedaten zu kennzeichnen, die nicht rotiert wurden, und Zugriffsprotokolle auf Anomalien zu überprüfen. Legen Sie einen Rotationsplan für privilegierte Konten fest. Überprüfen Sie Rollengruppen-Mitgliedschaften vierteljährlich — oder lösen Sie eine Überprüfung automatisch bei jeder organisatorischen Änderung aus.

Die vollständige Migration für ein 50-Personen-Team dauert in dieser Reihenfolge typischerweise ein bis zwei Wochen. Das Audit in Schritt 1 dauert normalerweise am längsten.

Wichtige Erkenntnisse für CISOs und IT-Führungskräfte

Die erforderliche Kernverschiebung besteht darin, die Weitergabe von Anmeldedaten als Zugriffsverwaltungsproblem zu behandeln, nicht als Problem des Benutzerverhaltens. Richtlinien, die darauf setzen, dass Mitarbeiter „das Richtige tun", werden im großen Maßstab scheitern. Eine Architektur, die das Richtige zum Einfachen macht, wird nicht scheitern.

• Geteilte Anmeldedaten durch Tresor-vermittelten Zugriff ersetzen. Benutzer erhalten Zugriff auf Systeme über den Tresor, nicht über das Passwort selbst.
• RBAC auf Gruppenebene implementieren. Individuelle Berechtigungsverwaltung skaliert nicht; gruppenbasierte Vererbung schon.
• MFA auf allen privilegierten Konten erzwingen. Die Kompromittierung von Anmeldedaten ist eine Frage des Wann, nicht des Ob — MFA begrenzt den Schaden.
• Audit-Trails etablieren, bevor sie benötigt werden. Incident Response ohne Protokolle ist Raterei.
• Legacy-Systeme explizit adressieren. Ein Service-Account in einem Tresor ist keine perfekte Lösung, aber eine dokumentierte und überprüfbare.
• Shadow IT als Design-Signal behandeln. Wenn Mitarbeiter persönliche Tools für Arbeits-Anmeldedaten verwenden, hat das Unternehmens-Tooling ein Friktionsproblem.
• Offboarding automatisieren. Jeder Tag, an dem ein ehemaliger Mitarbeiter Zugriff behält, ist eine Haftung. Verzeichnisintegration eliminiert den manuellen Schritt.

Fazit

Geteilte Anmeldedaten waren schon immer eine Haftung. Im Jahr 2026, mit KI-gestützten Cracking-Tools und durchschnittlichen Kosten von 4,57 Millionen USD pro Sicherheitsvorfall, sind sie nicht mehr vertretbar.

Die Lösung erfordert nicht, Mitarbeiter zu mehr Disziplin aufzufordern. Sie erfordert den Aufbau von Systemen, in denen der sichere Weg auch der schnellere ist. Wenn der Tresor-Zugriff weniger Zeit kostet als eine Slack-Nachricht, nutzen die Leute den Tresor. Wenn das Offboarding automatische Widerrufung auslöst, behalten ehemalige Mitarbeiter keinen monatelangen Zugriff. Wenn jede Aktion protokolliert wird, hört Incident Response auf, Raterei zu sein.

Beginnen Sie mit Ihren Anmeldedaten mit dem höchsten Risiko: Admin-Konten, Produktionsdatenbank-Zugriff, alles, was regulierte Daten berührt. Verschieben Sie diese zuerst in einen Tresor mit rollenbasierter Zugriffskontrolle. Arbeiten Sie dann in Prioritätsreihenfolge nach außen, unter Verwendung der obigen 6-Schritte-Migration.

Häufig gestellte Fragen

Warum ist unsichere Passwortweitergabe 2026 ein erhebliches Sicherheitsrisiko?

KI-gestützte Cracking-Tools können ein 8-Zeichen-Passwort in unter 12 Minuten auf Consumer-Hardware knacken (Hive Systems, 2025), und Credential-Stuffing-Angriffe laufen im industriellen Maßstab mit Milliarden geleakter Paare. Geteilte Passwörter eliminieren individuelle Verantwortlichkeit — wenn ein Sicherheitsvorfall auftritt, gibt es keinen Audit-Trail, um zu identifizieren, wer Zugriff hatte oder wann.

Wie können Organisationen Passwörter für Legacy-Systeme sicher verwalten, die nur ein einzelnes geteiltes Login unterstützen?

Verwenden Sie ein Service-Account-Muster: Speichern Sie das geteilte Anmeldedatum in einem verschlüsselten Tresor und gewähren Sie Benutzern Tresor-vermittelten Zugriff anstelle des rohen Passworts. Der Zugriff wird auf Tresor-Ebene protokolliert, auch wenn das Zielsystem keine native Audit-Fähigkeit hat. Bei Personaländerungen rotieren Sie das Anmeldedatum im Tresor — das System selbst muss sich nicht ändern.

Was ist reibungslose Governance im Kontext des Anmeldedaten-Managements?

Reibungslose Governance ist ein Anmeldedaten-Management-Modell, das sicheren Zugriff schneller als den Workaround macht. Es kombiniert individuelle Benutzeridentitäten, RBAC für gruppenbasierte Berechtigungsvererbung und vollständiges Audit-Logging — sodass Mitarbeiter nie ein rohes Passwort teilen müssen, um ihre Arbeit zu erledigen.

Wie schafft Shadow IT Sicherheitsrisiken bei Anmeldedaten?

Wenn Mitarbeiter Arbeitspasswörter in persönlichen Passwort-Managern speichern, verliert die Organisation Audit-Trails, Offboarding-Hooks und die Kontrolle über Verschlüsselungsstandards. Der persönliche Tresor eines ausscheidenden Mitarbeiters behält jedes dort gespeicherte Anmeldedatum. Die Lösung besteht darin, den Unternehmens-Tresor einfacher nutzbar zu machen als die persönliche Alternative — schnelleres Onboarding, Browser-Autofill, mobiler Zugriff.

Gegen welche Compliance-Frameworks verstoßen geteilte Anmeldedaten?

Geteilte Anmeldedaten ohne individuelle Zuordnung verstoßen gegen DSGVO Artikel 32 (geeignete technische Maßnahmen zum Datenschutz), SOC 2 Trust Services Criteria CC6.1 (logische Zugriffskontrollen, die an individuelle Identitäten gebunden sind) und HIPAA 45 CFR §164.312(a)(2)(i) (eindeutige Benutzeridentifikation). Alle drei erfordern die Fähigkeit, Zugriffsereignisse einer bestimmten Person zuzuordnen.

Wie lange dauert es typischerweise, einen anmeldedatenbasierten Sicherheitsvorfall zu erkennen?

Laut dem Cost of a Data Breach Report 2025 von IBM benötigen Sicherheitsvorfälle mit kompromittierten Anmeldedaten durchschnittlich 246 Tage zur Identifizierung und Eindämmung. Geteilte Konten verschlimmern dies: Ohne individuelle Verhaltens-Baselines vermischt sich anomale Aktivität mit normalem Multi-User-Traffic und löst selten Alarme aus.

Shadow IT vs Shadow AI: Warum KI die größere Bedrohung ist

Mitarbeiter nutzen KI-Tools, die Sie nicht genehmigt haben, auf Konten, die Sie nicht überwachen können, mit Daten, die Sie nicht wiederherstellen können. So sieht das Risiko tatsächlich aus und was Governance adressieren muss.

Passwork BlogAlex Muntyan

Brute-Force-Angriffe 2026: Typen, Beispiele und wie man sie verhindert

GPU-Cluster, KI-gestützte Wortlisten, Botnets mit 2,8 Mio. Geräten. Brute-Force hat skaliert. Dieser Leitfaden behandelt sechs Angriffsvarianten, reale Fälle aus 2025 und eine mehrschichtige Verteidigungsstrategie, die Ihr Team heute implementieren kann.

Passwork BlogAlex Muntyan

Passwork gewinnt Top Performer Frühjahr 2026 auf SourceForge

Passwork wurde von SourceForge als Top Performer Frühjahr 2026 ausgezeichnet und gehört zu den besten 10 % von über 100.000 Lösungen. Das Badge basiert ausschließlich auf verifizierten Bewertungen — 4,8 Sterne insgesamt, mit perfekten 5,0 für Support.

Passwork BlogAlex Muntyan

Credentials move between people every day. A developer gets a database credential via Slack. A contractor receives an admin account through email. Finance keeps the payroll system login in a shared spreadsheet. Each handoff is a breach waiting to happen. In 2026, that wait has a measurable value, and often counted in minutes.

This article breaks down exactly what's at stake in 2026, why employees keep doing it anyway, and how to fix it without making security feel like punishment.

Key takeaways

• Shared credentials are an access governance problem, not a user behavior problem. Policies that rely on employees doing the right thing fail at scale. Architecture that makes the right thing the easiest thing does not.
• Vault-mediated access eliminates the raw credential handoff. Users get into systems through the vault. They never see the password. Every action is logged and tied to an individual identity.
• RBAC at the group level is the only model that scales. Managing permissions per individual breaks down past a dozen people. Group-based inheritance means one change covers everyone on the team.
• MFA on privileged accounts limits blast radius when credentials are compromised. Credential compromise is a matter of when, not if. A second factor means a stolen password alone is not enough.
• Audit trails need to exist before the incident, not after. Incident response without logs is reconstruction from memory. Build the trail now.
• Legacy systems are a constraint, not an excuse. A service account stored in a vault with mediated access is not perfect, but it is documented, auditable, and revocable.
• Shadow IT is a friction signal. If employees are using personal tools for work credentials, the corporate vault is harder to use than it should be. Fix the onboarding, not the policy.
• Automate offboarding at the directory level. Every day a former employee retains access is an open liability. AD/LDAP integration closes it without manual intervention.

The dangers of insecure password sharing in 2026

Insecure password sharing exposes organizations to credential stuffing, account takeover (ATO), and insider threats — all of which have become significantly easier to execute as AI-enhanced attack tooling has matured. The core problem is that shared credentials destroy individual accountability: when five people use the same login, no audit trail tells you which one caused the breach.

The threat landscape has shifted materially as GPU hardware and cracking tooling have both advanced. Hive Systems' 2025 Password Table shows that short passwords remain dangerously exposed regardless of complexity. NIST SP 800-63B (updated August 2025) reflects the same reality: the guidelines now set a minimum floor of 15 characters and explicitly drop mandatory complexity rules in favor of length, recognizing that brute-force resistance scales exponentially with length, not with character substitution.

Time it takes a hacker to bruteforce your password in 2025

Credential stuffing has scaled with this tooling. Attackers feed leaked credential databases — billions of username/password pairs are available on dark web markets — into automated tools that test them across hundreds of services simultaneously. Shared passwords amplify the blast radius: one leaked credential can compromise every system where that password was reused.

Brute-force attacks have similarly benefited from AI. Modern cracking algorithms use neural networks to model human substitution patterns. Replacing a with @ or appending ! to a dictionary word no longer provides meaningful resistance. The attacker's model already accounts for it.

Insider threats are the less-discussed risk. When credentials are shared informally (over chat, email, or verbally) there is no record of who holds them at any given time. A disgruntled employee, a contractor whose engagement ended, or a former colleague who was never properly offboarded can retain access indefinitely. Without individual accounts and audit trails, you cannot detect the access, let alone attribute it.

How insecure sharing maps to specific attack vectors

Beyond convenience: Why employees still share passwords (and the real cost)

Employees share work passwords for the same mundane reasons they always have: emergencies, shared team accounts, delegated tasks. Sharing is the rational response when the secure path is slower than the task itself. When the formal access request process takes longer, people skip it.

That friction has a name. A 2025 peer-reviewed study "Digital detox: Exploring the impact of cybersecurity fatigue on employee productivity and mental health" published in Discover Mental Health (PMC/PubMed) surveyed 351 employees across IT, finance, healthcare, and education and found that cybersecurity fatigue (defined as mental and emotional exhaustion from repeated security demands) directly contributes to disengagement, reduced compliance, and burnout.

Cybersecurity fatigue — a state of mental and emotional exhaustion from repeated exposure to security demands — manifests through cognitive overload, stress, and disengagement, significantly impacting employee productivity and organizational resilience.

When mandatory rotation cycles, authentication prompts, and access request queues pile up, security stops feeling like protection and starts feeling like friction. The workaround becomes obvious: share the credential directly and get the work done.

This is a design failure, not a discipline problem. Proofpoint's research on human-centric threats consistently shows that employees bypass controls because the secure path takes longer than the insecure one. The credential gets shared, the task gets done, and no one thinks much about it.

Until something goes wrong. Verizon's 2025 DBIR found that credentials remain one of the most exploited entry points across industries. IBM's 2025 Cost of a Data Breach Report puts a number on what that means in practice: breaches involving compromised credentials take an average of 246 days to identify and contain — over eight months of undetected exposure — and carry an average total cost of $4.57M.

The accountability gap is what makes this hard to recover from. Once a credential is shared, you lose the ability to tie actions to individuals. That matters for incident response, for compliance audits, and for the basic question of "who changed this configuration at 2 a.m. on Saturday?" Shared credentials don't just create risk — they destroy the audit trail you need to understand what happened after the fact.

The ripple effect: Business impacts of insecure credential sharing

Insecure credential sharing creates financial, legal, and reputational exposure that extends well beyond the initial breach. Credential compromise is the dominant attack vector across industries. The breach itself is rarely the most expensive part. Incident response, regulatory scrutiny, and the audit trail gaps left by shared accounts compound the damage long after the initial intrusion.

The compliance dimension is specific and consequential. GDPR Article 32 requires "appropriate technical and organisational measures" to protect personal data — and shared credentials with no audit trail fail that standard directly. SOC 2 Trust Services Criteria CC6.1 requires logical access controls tied to individual identities. HIPAA's Technical Safeguard requirements under 45 CFR §164.312(a)(2)(i) mandate unique user identification. Sharing a single login across a team violates all three frameworks simultaneously.

Reputational damage follows a different timeline than financial damage. The breach costs are immediate. The reputational costs compound. Customers, partners, and regulators all factor breach history into their risk assessments. A credential-based breach that could have been prevented with basic access governance is particularly difficult to explain to a board or a regulator.

The offboarding scenario illustrates the risk concretely. An employee leaves with access to five shared accounts. Because credentials were never formally assigned, no one knows which systems they could reach. Revoking access means:

1. Identifying every shared password the employee knew
2. Finding every system where that password was used
3. Notifying every team that depends on those credentials
4. Rotating all of them without breaking anything in production

In practice, many organizations skip this entirely. That's how former employees retain active access for months.

Implementing frictionless governance: Solutions for secure password sharing

Frictionless governance is a credential management model that eliminates insecure sharing by making secure access faster than the workaround. It rests on three components: individual accountability (every user has their own identity), RBAC (permissions assigned to roles, not individuals), and audit logging (every access event is recorded and attributable).

The practical implementation requires four things:

1. A password vault with role-based access control. Users access credentials through the vault, not by receiving the password directly. RBAC (role-based access control) means permissions are inherited from group membership — add someone to the DevOps group, they get DevOps vault access. Remove them, access is revoked immediately.
2. End-to-end encryption with a zero-knowledge architecture. Credentials are encrypted client-side before leaving the user's device. The server stores ciphertext. Even a compromised server exposes nothing usable. AES-256 is the current standard for this.
3. MFA on every account. Multi-factor authentication (MFA) doesn't prevent credential sharing, but it limits the damage when a shared credential is compromised. An attacker with a stolen password still needs the second factor. For privileged accounts, hardware tokens or FIDO2 keys are preferable.
4. Passphrases over complex short passwords. A 16-character passphrase — four random words — is both more resistant to brute-force attacks and easier for users to remember than P@ssw0rd!2. Length provides exponential resistance; complexity provides linear resistance.

Identity and Access Management (IAM) integration extends this model to the directory level. When Passwork is connected to AD/LDAP, user provisioning and deprovisioning happen automatically. A user disabled in Active Directory loses vault access without any manual intervention. That's the offboarding problem solved at the infrastructure level.

Addressing legacy systems and shadow IT

Legacy systems are the most common reason teams justify shared credentials. A system built in 2008 may have no concept of individual user accounts — it has one admin login, and everyone who needs access uses it. This is a real constraint, not a policy failure.

The practical solution is a service account pattern with vault-mediated access. The shared credential lives in the vault, encrypted. Users access the system through the vault's session management — they never see the raw password. Access is logged at the vault level even if the target system has no native audit capability. When someone leaves, you rotate the credential in the vault. The system itself doesn't need to change.

One-time secrets and secure links address the adjacent problem: occasionally, a credential genuinely needs to be transmitted to someone outside your vault. A one-time secret link expires after a single view or after a defined time window. It's not a permanent solution, but it's categorically safer than a Slack message that sits in chat history indefinitely.

Shadow IT — employees using personal credential managers for work passwords — is harder to detect and carries its own risks. A personal vault has no organizational audit trail, no offboarding hook, and no guarantee of encryption standards. The fix is organizational: make the corporate vault easier to use than the personal one. If onboarding takes five minutes and the browser extension autofills credentials, most employees will use it. Friction is the enemy of adoption.

How Passwork makes secure sharing the default

The issues described above (shared credentials, broken offboarding, missing audit trails, legacy system constraints) are exactly what Passwork is built to handle. Here's how each maps to a specific capability.

• Shared credentials without accountability. Passwork replaces direct password handoffs with vault-mediated access. Users interact with systems through the vault. They never receive the raw credential. Every access event is logged, timestamped, and tied to an individual identity.
• Broken offboarding. Passwork integrates with AD/LDAP. When a user is disabled in Active Directory, vault access is revoked automatically. No manual rotation, no guesswork about which accounts they could reach.
• No audit trail. Every action in Passwork is recorded. When an incident occurs, you have a complete, attributable log. Not "someone on the DevOps team," but a specific user at a specific time.
• Legacy systems with shared logins. Passwork supports a service account pattern: the credential lives in the vault, encrypted. Users access the system through vault-mediated sessions and never see the password. The target system doesn't need to change.
• Occasional external sharing. For credentials that genuinely need to leave the vault — a contractor, a one-time handoff — Passwork generates one-time secret links that expire after a single view or a defined time window. Safer than a Slack message by design.
• Compliance gaps. Role-based access control, individual identity binding, and a full audit log directly support GDPR Article 32, SOC 2 CC6.1, and HIPAA §164.312 requirements. The audit trail you need for a regulator is the same one you need for incident response.

Moving from insecure to secure sharing: A practical 6-step migration

Most teams fail because the transition from informal sharing to structured access feels like a project no one has time for. This guide breaks it into six steps that can be executed incrementally, educing exposure at each stage without disrupting operations.

1. Audit what you're actually sharing. Before you can fix the problem, you need to know its scope. Survey your teams and document every shared credential: what system it accesses, who holds it, and how it was distributed. Spreadsheets, Slack history, and email threads are the most common sources. Don't skip this step. You cannot revoke access you don't know exists.
2. Classify by risk. Not all shared credentials carry equal risk. Prioritize by blast radius: production database credentials and admin accounts first, internal tooling second, low-sensitivity shared accounts last. This gives you a migration sequence that reduces exposure quickly without requiring you to move everything at once.
3. Deploy the vault and onboard your team. Set up Passwork and connect it to your directory service (AD/LDAP). Create role-based groups that mirror your existing team structure. Onboarding works best when the vault is already populated before you ask people to use it. Import existing credentials into the appropriate vaults before the rollout meeting.
4. Migrate credentials in priority order. Move high-risk credentials into the vault first. For each one: store it in Passwork, assign access to the relevant role group, and immediately stop distributing the raw password. For legacy systems that can't support individual accounts, implement the service account pattern — credential in the vault, access mediated through Passwork.
5. Enforce the new process and retire the old one. Block the informal channels. This means a clear policy: no credentials in Slack, email, or shared documents. For external sharing, use Passwork's one-time secret links instead of direct messages. The policy only works if the vault is already easier to use than the workaround — which is why steps 3 and 4 come first.
6. Audit, rotate, and maintain. Once credentials are in the vault, use Passwork's security audit tools to identify weak passwords, flag credentials that haven't been rotated, and review access logs for anomalies. Set a rotation schedule for privileged accounts. Review role group memberships quarterly — or trigger a review automatically on any organizational change.

The full migration for a 50-person team typically takes one to two weeks when executed in this order. The audit in step 1 usually takes the longest.

Key takeaways for CISOs and IT leaders

The core shift required is treating credential sharing as an access governance problem, not a user behavior problem. Policies that rely on employees "doing the right thing" will fail at scale. Architecture that makes the right thing the easy thing will not.

• Replace shared credentials with vault-mediated access. Users get access to systems through the vault, not through the password itself.
• Implement RBAC at the group level. Individual permission management doesn't scale; group-based inheritance does.
• Enforce MFA on all privileged accounts. Credential compromise is a matter of when, not if — MFA limits the damage.
• Establish audit trails before you need them. Incident response without logs is guesswork.
• Address legacy systems explicitly. A service account in a vault is not a perfect solution, but it's a documented, auditable one.
• Treat shadow IT as a design signal. If employees are using personal tools forwork credentials, your corporate tooling has a friction problem.
• Automate offboarding. Every day a former employee retains access is a liability. Directory integration eliminates the manual step.

Conclusion

Shared credentials have always been a liability. In 2026, with AI-enhanced cracking tools and breach costs averaging $4.57 million per incident, they're an indefensible one.

The fix doesn't require asking employees to be more disciplined. It requires building systems where the secure path is also the faster one. When vault access takes less time than a Slack message, people use the vault. When offboarding triggers automatic revocation, former employees don't retain access for months. When every action is logged, incident response stops being guesswork.

Start with your highest-risk shared credentials: admin accounts, production database access, anything touching regulated data. Move those into a vault with role-based access controls first. Then work outward, in priority order, using the six-step migration above.

Frequently asked questions

Why is insecure password sharing a significant security risk in 2026?

AI-enhanced cracking tools can break an 8-character password in under 12 minutes on consumer hardware (Hive Systems, 2025), and credential stuffing attacks run at industrial scale using billions of leaked pairs. Shared passwords eliminate individual accountability — when a breach occurs, there is no audit trail to identify who had access or when.

How can organizations securely manage passwords for legacy systems that only support a single shared login?

Use a service account pattern: store the shared credential in an encrypted vault and grant users vault-mediated access rather than the raw password. Access is logged at the vault level even when the target system has no native audit capability. When personnel changes occur, rotate the credential in the vault — the system itself does not need to change.

What is frictionless governance in the context of credential management?

Frictionless governance is a credential management model that makes secure access faster than the workaround. It combines individual user identities, RBAC for group-based permission inheritance, and full audit logging — so employees never need to share a raw password to get their work done.

How does shadow IT create credential security risks?

When employees store work passwords in personal credential managers, the organization loses audit trails, offboarding hooks, and control over encryption standards. A departing employee's personal vault retains every credential they saved there. The fix is making the corporate vault easier to use than the personal alternative — faster onboarding, browser autofill, mobile access.

Which compliance frameworks are violated by shared credentials?

Shared credentials without individual attribution violate GDPR Article 32 (appropriate technical measures for data protection), SOC 2 Trust Services Criteria CC6.1 (logical access controls tied to individual identities), and HIPAA 45 CFR §164.312(a)(2)(i) (unique user identification). All three require the ability to tie access events to a specific person.

How long does it typically take to detect a credential-based breach?

According to IBM's 2025 Cost of a Data Breach Report, breaches involving compromised credentials take an average of 246 days to identify and contain. Shared accounts make this worse: without individual behavioral baselines, anomalous activity blends in with normal multi-user traffic and rarely triggers alerts.

Shadow IT vs Shadow AI: Why AI is the bigger threat

Employees are using AI tools you didn’t approve, on accounts you can’t monitor, with data you can’t recover. Here’s what the risk actually looks like and what governance needs to address.

Passwork BlogAlex Muntyan

Brute force attacks in 2026: Types, examples & how to prevent them

GPU clusters, AI-assisted wordlists, botnets of 2.8M devices. Brute force has scaled. This guide covers six attack variants, real-world cases from 2025, and a layered defense strategy your team can implement today.

Passwork BlogAlex Muntyan

Passwork wins Top Performer Spring 2026 on SourceForge

Passwork has been named a Top Performer Spring 2026 by SourceForge, ranking in the top 10% of 100,000+ solutions. The badge is based entirely on verified reviews — 4.8 stars overall, with a perfect 5.0 for support.

Passwork BlogAlex Muntyan

Shadow IT bezeichnet die Nutzung nicht genehmigter Technologie ohne Wissen oder Aufsicht der IT-Abteilung. Shadow AI ist die Nutzung nicht genehmigter KI-Tools, Modelle, Funktionen und Workflows — und sie ist oft risikoreicher, da sensible Daten verarbeitet, Entscheidungen beeinflusst, Ausgaben generiert und mit Anmeldedaten oder Systemen vollständig außerhalb der normalen Governance interagiert werden kann.

Das Ausmaß des Problems zeigt sich bereits in Daten zu Sicherheitsvorfällen:

• Jede fünfte Organisation meldete einen Sicherheitsvorfall aufgrund von Shadow AI, und eine hohe Shadow-AI-Nutzung erhöhte die durchschnittlichen Kosten eines Vorfalls um 670.000 US-Dollar — IBM's 2025 Cost of a Data Breach Report.
• Mehr als die Hälfte der Führungskräfte (58 %) gab an, dass ihre Organisation im vergangenen Jahr einen KI-bezogenen Sicherheitsvorfall oder einen Beinahe-Vorfall erlebt hat — Okta's AI Agents at Work 2026 Survey.
• Über 1,27 Millionen geleakte Secrets von KI-Diensten wurden auf öffentlichen GitHub-Repositories gefunden. Das sind 81 % mehr als im Vorjahr. Acht der zehn am schnellsten wachsenden Typen geleakter Secrets stehen im Zusammenhang mit KI-Diensten — GitGuardian's State of Secrets Sprawl 2026.
• Nur 5 % der Unternehmen haben vollständige Transparenz darüber, welche KI-Tools Mitarbeitende tatsächlich nutzen, und 78 % bestätigten entweder einen KI-bezogenen Sicherheitsvorfall oder konnten einen solchen nicht ausschließen — Check Point's 2026 Cloud Security Report.
• 92 % der Sicherheitsexperten sind besorgt über KI-Agenten und deren Auswirkungen auf die Sicherheit, doch nur 37 % der Organisationen haben eine formale KI-Richtlinie implementiert — Darktrace's State of AI Cybersecurity 2026.

Regierungen haben reagiert. Der EU AI Act wird nun aktiv durchgesetzt, mit Strafen für die nicht konforme Nutzung von Hochrisiko-KI-Systemen von bis zu 15 Millionen Euro oder 3 % des weltweiten Jahresumsatzes.

In den Vereinigten Staaten unterzeichnete Präsident Trump am 2. Juni 2026 eine Executive Order — „Promoting Advanced Artificial Intelligence Innovation and Security" — die CISA anweist, KI-gestützte Cyberabwehr für Bundessysteme und Betreiber kritischer Infrastrukturen auszubauen, und einen freiwilligen Rahmen für die Bewertung von Frontier-KI-Modellen vor der öffentlichen Freigabe etabliert. Die Verordnung reguliert nicht, wie Mitarbeitende KI in Unternehmen nutzen, signalisiert aber deutlich, dass KI-Sicherheit nun eine bundesweite Priorität ist und Organisationen, die kritische Infrastrukturen betreiben, bereits in den Geltungsbereich fallen.

Die Tools werden genutzt. Die Daten bewegen sich. Wohin? Die meisten Organisationen wissen es schlichtweg nicht.

Wichtige Erkenntnisse

• Shadow AI ist eine eigenständige Risikokategorie, nicht nur Shadow IT mit KI-Branding. Nicht genehmigte KI-Tools, Modelle und Agenten verarbeiten Daten, beeinflussen Entscheidungen und interagieren mit Anmeldedaten vollständig außerhalb der normalen Governance, während traditionelle Shadow IT nur unverwaltete Technologie-Wildwuchs verursacht.
• Die Daten zu Sicherheitsvorfällen sind bereits sichtbar. Jede fünfte Organisation meldete einen Sicherheitsvorfall aufgrund von Shadow AI. Die meisten Unternehmen haben kein klares Bild davon, welche KI-Tools Mitarbeitende tatsächlich nutzen.
• Persönliche Accounts sind die primäre Kontrolllücke. Die meiste KI-Tool-Nutzung erfolgt über persönliche Accounts, die SSO, DLP und zentralisiertes Logging umgehen, ohne Audit-Trail und ohne vertragliche Grundlage für Datenlöschung.
• KI-Agenten verlagern das Problem von der Dateneingabe zu Zugriff und Aktion. Agenten können Dateien lesen, APIs aufrufen und Code über delegierte OAuth-Berechtigungen ändern, und diese Aktionen werden möglicherweise nirgendwo protokolliert, wo das Sicherheitsteam Zugriff hat.
• Zugangsdaten-Exposition ist die schwerwiegendste Lücke. Logs, Code-Snippets, Umgebungsdateien und Browser-Autofill-Daten enthalten häufig Passwörter, API-Schlüssel oder Token. Werden diese in ein KI-Tool eingefügt, entsteht ein potenzieller dauerhafter Zugriffspfad — nicht nur ein Datenexpositions-Ereignis.
• Pauschale Verbote verlagern Shadow AI, sie eliminieren sie nicht. Mitarbeitende weichen auf persönliche Geräte und alternative Tools mit weniger Audit-Signalen aus. Effektive Governance bietet genehmigte Alternativen und überwacht die Bewegung sensibler Daten.
• Regulierungsbehörden haben reagiert. Der EU AI Act wird aktiv durchgesetzt, mit Strafen von bis zu 15 Millionen Euro oder 3 % des weltweiten Jahresumsatzes. Eine am 2. Juni 2026 unterzeichnete US-Executive-Order signalisiert, dass KI-Sicherheit nun eine bundesweite Priorität ist.
• Governance erfordert fünf spezifische Maßnahmen. Datenklassifizierung, Bereitstellung genehmigter Tools, Output-Governance, Überprüfung von Agenten-Berechtigungen und Secrets-Management. Bestehende Shadow-IT-Kontrollen sind notwendig, aber nicht ausreichend.

Was ist Shadow IT?

Shadow IT bezeichnet jede Technologie (Software, Hardware, Cloud-Dienste, SaaS-Anwendungen, Skripte oder Infrastruktur), die innerhalb einer Organisation ohne IT-Genehmigung, Wissen oder Aufsicht genutzt wird. Der Begriff umfasst ein breites Spektrum an Verhaltensweisen: Ein Mitarbeitender nutzt einen persönlichen Cloud-Speicher zum Teilen von Dateien, ein Team richtet ein nicht genehmigtes Projektmanagement-Tool ein, ein Entwickler führt Skripte auf unverwalteter Infrastruktur aus oder eine Abteilung abonniert ein SaaS-Produkt außerhalb des Beschaffungsprozesses.

Das Kernproblem bei Shadow IT ist der Verlust der Governance. Wenn die IT-Abteilung nicht weiß, dass ein Tool existiert, kann sie keine Zugriffskontrollen durchsetzen, keine Data Loss Prevention (DLP)-Richtlinien anwenden, den Datenlebenszyklus nicht verwalten oder den Zugriff entziehen, wenn ein Mitarbeitender das Unternehmen verlässt. Auch Lizenzierung, Compliance und Anforderungen an Audit-Trails fallen durch das Raster.

Shadow IT folgt einem vorhersehbaren Pfad. Ein Mitarbeitender benötigt ein Tool — schnellere Dateifreigabe, einen Projekt-Tracker, ein Skript, das auf etwas anderem als dem genehmigten Stack läuft. Der offizielle Prozess ist zu langsam oder das Tool ist einfach nicht verfügbar, also findet er eine eigene Lösung. Die IT erfährt davon nie.

Häufige Shadow-IT-Beispiele umfassen:

• Persönlicher Cloud-Speicher (Consumer-Accounts für Arbeitsdateien genutzt)
• Nicht genehmigte Messaging- und Collaboration-Apps
• Browser-Erweiterungen mit umfassenden Datenberechtigungen
• Unverwaltete SaaS-Abonnements, die vom Team-Budget bezahlt werden
• Von Entwicklern erstellte Skripte und Automatisierungstools, die außerhalb der IT-Sichtbarkeit laufen
• Consumer-Geräte, die mit Unternehmensnetzwerken verbunden sind

Shadow IT ist nicht immer böswillig. Das meiste beginnt als Produktivitäts-Workaround — ein Team benötigte ein Tool, die Beschaffung war langsam, und jemand fand eine kostenlose Alternative. Dieser Kontext ist wichtig für die Governance: Verbote ohne Ersatz funktionieren selten.

Was ist Shadow AI?

Shadow AI ist die nicht genehmigte Nutzung von KI-Tools, KI-Funktionen, Modellen, Prompts, Agenten und Workflows ohne IT-Genehmigung oder Aufsicht. Sie ist mit Shadow IT verwandt, aber unterschiedlich: Während Shadow IT hauptsächlich unverwalteten Technologie-Wildwuchs verursacht, verursacht Shadow AI unverwaltete Datenverarbeitung, unverwaltete Entscheidungsunterstützung und unverwaltete Aktionen.

Shadow AI umfasst eine breite und schnell wachsende Palette von Verhaltensweisen. Mitarbeitende nutzen öffentliche Large Language Models (LLMs) wie ChatGPT, Claude und Gemini über persönliche Accounts. Entwickler nutzen KI-Coding-Assistenten wie GitHub Copilot oder Cursor außerhalb von Enterprise-Tenants. Teams nutzen KI-Meeting-Assistenten, KI-Browser-Erweiterungen und KI-gestützte SaaS-Funktionen, die nie formal geprüft wurden. Einige Mitarbeitende bauen ihre eigenen KI-Workflows mit Consumer-Automatisierungstools.

Shadow AI folgt demselben Pfad wie Shadow IT, aber die Konsequenzen am Ende sind unterschiedlich. Ein Mitarbeitender muss schneller vorankommen — ein Dokument zusammenfassen, Code generieren, eine Antwort entwerfen. Es gibt kein genehmigtes Tool, oder das genehmigte Tool ist langsamer als das, das er bereits privat nutzt. Also verwendet er seinen eigenen Account, eine Browser-Erweiterung oder eine KI-Funktion, die in ein SaaS-Produkt eingebettet ist, das die IT zwar bereits genehmigt, aber nie geprüft hat.

Häufige Beispiele für Shadow AI in der Praxis:

• Mitarbeitende nutzen ChatGPT, Claude, Gemini oder Perplexity über persönliche Free-Tier-Accounts
• Entwickler nutzen KI-Coding-Assistenten außerhalb der Enterprise-Lizenzkontrolle
• Vertriebs- und Marketing-Teams nutzen KI-Schreibtools, die von der Sicherheitsabteilung nicht geprüft wurden
• HR- und Finanz-Teams nutzen KI, um Dokumente mit regulierten Daten zusammenzufassen
• KI-Meeting-Assistenten zeichnen Anrufe auf und transkribieren sie ohne Enterprise-Aufbewahrungskontrollen
• Browser-basierte KI-Erweiterungen mit Zugriff auf Seiteninhalte, Zwischenablage und Formularfelder
• Von Mitarbeitenden erstellte KI-Agenten, die sich mit SaaS-APIs oder internen Systemen verbinden

Das Ausmaß ist erheblich. Menlo Security's 2025 Report verzeichnete 10,53 Milliarden Besuche auf KI-Websites allein im Januar 2025, gegenüber 7 Milliarden im Februar 2024, wobei 80 % dieses Zugriffs über Browser erfolgten. Shadow AI ist kein Nischenverhalten — es ist die Art und Weise, wie die meisten Mitarbeitenden derzeit KI nutzen.

Shadow IT vs. Shadow AI: Die wichtigsten Unterschiede

Shadow IT und Shadow AI haben dieselbe Grundursache: Mitarbeitende lösen reale Probleme mit Tools, die die IT nicht genehmigt hat. Aber sie erzeugen unterschiedliche Risikoprofile und erfordern unterschiedliche Kontrollen.

Die Behebungslücke ist besonders signifikant. Wenn ein Mitarbeitender ein nicht genehmigtes SaaS-Tool nutzt, kann die IT den Zugriff entziehen und Daten migrieren. Wenn sensible Inhalte in den Workflow eines externen KI-Modells gelangen, ist es erheblich schwieriger, die Löschung zu bestätigen, die Nicht-Aufbewahrung nachzuweisen und den Vorfall einzugrenzen — insbesondere wenn der Zugriff über einen persönlichen Account erfolgte, ohne Enterprise-Audit-Trail.

Warum Shadow AI die größere Bedrohung ist

Shadow AI ist oft gefährlicher als traditionelle Shadow IT, da sie Daten nicht nur speichert oder verschiebt, sondern verarbeitet, generiert und darauf reagiert. Die folgenden fünf Dimensionen erklären, wo sich das Risikomodell ändert. Zusammen bilden sie das, was dieser Artikel als Shadow-AI-Risikomultiplikator bezeichnet.

1. Datenexfiltration erfolgt durch normale Arbeit

Mitarbeitende müssen Daten nicht absichtlich exfiltrieren. Sie fügen E-Mails, Verträge, Tabellen, Quellcode, Support-Tickets, Kundendaten, HR-Informationen und Systemprotokolle als Teil der normalen Arbeit in KI-Tools ein. Jeder Prompt ist ein potenzieller Datentransfer.

Harmonic Security's Analyse von 22.458.240 Enterprise-GenAI-Prompts aus 2025 erkannte 579.113 Fälle von sensiblen Datenexpositionen über 665 KI-Tools. Code, juristische Dokumente und Finanzdaten machten 74,5 % dessen aus, was exponiert wurde. Laut Cyberhaven's 2026 AI Adoption & Risk Report beinhalteten 39,7 % aller KI-Interaktionen sensible Daten, und Mitarbeitende gaben im Durchschnitt alle drei Tage sensible Daten in KI-Tools ein.

Sensible Daten und KI sind jetzt in tägliche Arbeitsabläufe eingebettet, und die Exposition ist nicht gelegentlich.

2. Persönliche Accounts brechen Enterprise-Kontrollen

Ein erheblicher Teil der KI-Nutzung erfolgt über persönliche Accounts statt Enterprise-Tenants. Cyberhavens 2026-Daten zeigten, dass 32,3 % der ChatGPT-Nutzung, 58,2 % der Claude-Nutzung und 60,9 % der Perplexity-Nutzung über persönliche Accounts erfolgte. Menlo Security's 2025 Report ergab, dass 68 % der Mitarbeitenden Free-Tier-KI-Tools über persönliche Accounts nutzten, wobei 57 % sensible Daten eingaben.

Persönliche Accounts umgehen SSO-Durchsetzung, Enterprise-Aufbewahrungsrichtlinien, zentralisiertes Logging, DLP-Kontrollen und Daten-Governance auf Admin-Ebene. Wenn ein Mitarbeitender Claude oder Perplexity über einen persönlichen Account nutzt, hat die Organisation keine Sichtbarkeit darüber, was eingereicht wurde, keinen Audit-Trail und keine vertragliche Grundlage für Datenlöschung oder Nicht-Training-Zusagen.

3. KI kann Entscheidungen beeinflussen, nicht nur Dateien speichern

Shadow IT erzeugt hauptsächlich unverwaltete Datenspeicherung oder -übertragung. Shadow AI tut etwas mehr: Sie fasst zusammen, klassifiziert, bewertet, empfiehlt, generiert Code und entwirft kundenorientierte oder juristische Inhalte. Ein nicht genehmigtes KI-Tool kann eine Geschäftsentscheidung auf Basis ungeprüfter Daten, einer unbekannten Modellversion und Annahmen, die der Benutzer nie untersucht hat, beeinflussen.

Halluzinationen, Modelldrift und Bias in KI-Outputs sind reale Fehlermodi. Wenn das Tool nicht genehmigt und der Output nicht zugeordnet ist, gibt es keine Möglichkeit, die Entscheidungskette im Nachhinein zu prüfen.

4. KI-Agenten erweitern das Problem von Eingabe zu Aktion

KI-Agenten können Dateien lesen, Zwischenablagen nutzen, APIs aufrufen, Nachrichten senden, Code ändern und sich mit SaaS-Systemen verbinden. Viele laufen auf Betriebssystemebene, pflegen persistente Kontextfenster und synchronisieren Daten mit Infrastruktur außerhalb der Aufsicht des Sicherheitsteams.

Dies verlagert Shadow AI von einem Dateneingabe-Problem zu einem Zugriffs-und-Aktions-Problem. Ein Agent mit delegierten OAuth-Berechtigungen oder einem API-Schlüssel kann im Namen eines Benutzers handeln, und diese Aktionen werden möglicherweise nirgendwo protokolliert, wo das Sicherheitsteam Zugriff hat.

5. Credential- und Secrets-Exposition verwandelt KI-Nutzung in Zugriffsrisiko

Logs, Code-Snippets, Umgebungsdateien, Browser-Autofill-Daten und Support-Tickets enthalten häufig Passwörter, API-Schlüssel oder Token. Werden diese in ein KI-Tool eingefügt — oft versehentlich — ist das Ergebnis nicht nur ein Datenexpositions-Ereignis. Es ist ein potenzieller dauerhafter Zugriffspfad.

IBM's 2025 Report ergab, dass 97 % der Organisationen, die über KI-Modelle oder -Anwendungen kompromittiert wurden, keine angemessenen KI-Zugriffskontrollen hatten, was bedeutet, dass die meisten Organisationen, die einen KI-bezogenen Sicherheitsvorfall erlebten, keine wirksame Kontrollschicht implementiert hatten.

Wenn Ihr Team beginnt, Shadow-AI-Exposition zu erfassen, sind Credentials und Secrets oft die schwerwiegendste Lücke. Passwork zentralisiert geteilte Passwörter, API-Schlüssel und Service-Account-Anmeldedaten in einem einzigen verschlüsselten Tresor mit RBAC, LDAP/SSO-Integration und einem vollständigen Audit-Log jedes Zugriffsereignisses. Wenn ein Mitarbeitender das Unternehmen verlässt oder ein KI-Workflow außer Betrieb genommen wird, wird der Zugriff an einem Ort entzogen, nicht über ein Dutzend Tools hinweg nachverfolgt. Passwork kostenlos testen

Praxisbeispiele für Shadow-AI-Risiken

Die folgenden Risikoszenarien sind repräsentativ für das, was Sicherheits- und IT-Teams abteilungsübergreifend erleben. Keines erfordert böswillige Absicht — jedes beginnt mit einem legitimen Produktivitätsziel.

Das Risiko konzentriert sich tendenziell auf eine kleine Anzahl stark genutzter Tools, was für die Governance-Priorisierung nützlich ist. Aber der Long Tail ist dennoch relevant — eine selten genutzte Integration kann dasselbe Credential-Expositionsrisiko bergen wie ein täglich genutzter Assistent.

Warum ein KI-Verbot Shadow AI meist verschlimmert

Ein pauschales Verbot von KI-Tools eliminiert Shadow AI nicht. Es verlagert sie. Mitarbeitende weichen auf persönliche Geräte, persönliche Accounts oder alternative Tools aus, in die die IT weniger Einblick hat. Das Ergebnis ist dieselbe Datenexposition mit weniger Audit-Signalen.

Laut einer im Mai 2026 veröffentlichten Okta-Umfrage gaben mehr als die Hälfte der Mitarbeitenden an, persönliche KI-Tools ohne Genehmigung zu nutzen. Zwei Drittel der US-amerikanischen Mitarbeitenden nutzen nicht genehmigte KI, und fast ein Viertel tut dies regelmäßig. Gleichzeitig gaben 58 % der Führungskräfte an, dass ihre Organisation im vergangenen Jahr einen KI-bezogenen Sicherheitsvorfall oder Beinahe-Vorfall hatte.

Die Okta-Studie ergab auch, dass mehr als die Hälfte der Mitarbeitenden sagt, die KI-Nutzungsrichtlinien ihrer Organisation seien unklar, schwer zu finden oder nicht vorhanden. Diese Lücke zwischen dem Vertrauen der Führungskräfte und der Erfahrung der Mitarbeitenden ist der Ort, an dem Shadow AI wächst.

Einige Hochrisiko-Anwendungsfälle sollten vollständig blockiert werden — das Einfügen von Kundendaten in ein öffentliches KI-Tool oder das Verbinden eines Consumer-KI-Agenten mit Produktionssystemen. Aber pauschale Verbote funktionieren nicht. Mitarbeitende nutzen Shadow AI aus rationalen Gründen: bessere Tools, schnellere Ergebnisse, eine Beschaffung, die zu langsam ist. Effektive Governance bietet genehmigte Alternativen, setzt klare Grenzen und überwacht die Bewegung sensibler Daten. Werden die zugrundeliegenden Anreize ignoriert, ändert sich das Verhalten nicht.

Wie Shadow AI im Unternehmen erkannt werden kann

Die Erkennung von Shadow AI erfordert Sichtbarkeit über Browser, Endpunkte, SaaS-Berechtigungen und Identitätssysteme hinweg. IBM's 2025-Studie ergab, dass nur 34 % der Organisationen mit KI-Governance-Richtlinien regelmäßige Audits auf nicht genehmigte KI durchführten — was bedeutet, dass die meisten Organisationen Richtlinien ohne operative Sichtbarkeit haben.

Ein praktischer Erkennungsansatz umfasst sieben Bereiche

1. Schritt 1. Inventarisieren Sie KI-Domains, Browser-Erweiterungen, SaaS-KI-Funktionen, KI-Meeting-Tools, KI-Coding-Assistenten und KI-Funktionen, die in bereits genehmigte Anwendungen eingebettet sind.
2. Schritt 2. Überwachen Sie browser-basierte GenAI-Nutzung, Kopieren/Einfügen-Ereignisse, Datei-Uploads und Downloads, wo dies rechtlich und ethisch nach den Mitarbeiterüberwachungsvorschriften Ihrer Rechtsordnung zulässig ist.
3. Schritt 3. Überprüfen Sie OAuth-Grants, API-Token, Service-Accounts und Drittanbieter-App-Berechtigungen. KI-Agenten und Integrationen fordern oft umfassende OAuth-Scopes an, die lange nach der Ersteinrichtung bestehen bleiben.
4. Schritt 4. Klassifizieren Sie sensible Datenkategorien, die niemals ohne ausdrückliche Genehmigung an externe KI-Tools übermittelt werden sollten: PII, Quellcode, Finanzprognosen, juristische Dokumente, regulierte Gesundheitsdaten und Credentials.
5. Schritt 5. Überprüfen Sie Identitätskontrollen: SSO-Abdeckung, MFA-Durchsetzung, SCIM/LDAP-Provisioning, RBAC-Zuweisungen und Vollständigkeit der Audit-Logs. Persönliche KI-Accounts umgehen all dies.
6. Schritt 6. Suchen Sie nach exponierten Credentials in Code-Repositories, Logs, Tickets und KI-bezogenen Workflows. Token und API-Schlüssel erscheinen an unerwarteten Stellen — Commit-History, Slack-Threads, Support-Tickets und KI-Prompt-Logs.
7. Schritt 7. Ordnen Sie die KI-Nutzung dem Geschäftsbedarf zu, bevor Sie sie blockieren. Das Verständnis, warum Mitarbeitende ein Tool nutzen, ist notwendig, um eine verwaltete Alternative bereitzustellen, die sie tatsächlich verwenden werden.

Wie Shadow-AI-Risiken reduziert werden können, ohne die Produktivität zu blockieren

Effektive Shadow-AI-Governance ist ebenso ein Enablement-Problem wie ein Sicherheitsproblem. Das Ziel ist es, Mitarbeitenden sichere, genehmigte Optionen zu geben und gleichzeitig Kontrollen dort anzuwenden, wo sensible Daten gefährdet sind.

Die Identitäts- und Zugriffsebene benötigt drei Dinge: SSO-Abdeckung über genehmigte KI-Tools, MFA-Durchsetzung und SCIM- oder LDAP-Provisioning, das den Zugriff direkt an den Beschäftigungsstatus bindet. Für Passwörter und Secrets verwandelt ein zentralisierter Tresor mit rollenbasierter Zugriffskontrolle, Active-Directory-Integration und Aktivitäts-Logs das Credential-Management von einer manuellen Aufgabe in einen auditierbaren Prozess.

Wo Passwörter und Secrets in die Shadow-AI-Governance passen

Bei der Shadow-AI-Governance geht es darum, welche Credentials und Berechtigungen KI-nahe Tools erreichen können.

Credential-Exposition in KI-Workflows geschieht oft indirekt:

• Ein Entwickler fügt eine Log-Datei in einen Coding-Assistenten ein — das Log enthält einen Datenbank-Connection-String
• Ein Support-Mitarbeiter teilt einen Screenshot in einem KI-Tool — der Screenshot zeigt einen API-Schlüssel in einem Browser-Tab
• Ein Mitarbeitender lädt eine Umgebungskonfigurationsdatei für KI-gestütztes Debugging hoch — die Datei enthält Service-Account-Credentials

Keines davon sind absichtliche Exfiltrations-Ereignisse. Alle schaffen echte Zugriffsrisiken.

KI-Coding-Assistenten und -Agenten verstärken dies. Sie können mit Repositories, Terminals, SaaS-APIs und lokalen Dateisystemen interagieren. Ein Agent mit Zugriff auf die Terminal-Sitzung eines Entwicklers kann Umgebungsvariablen, SSH-Schlüssel und Credential-Dateien lesen. Wenn dieser Agent über einen persönlichen Account ohne Enterprise-Audit-Trail läuft, hat die Organisation keinen Nachweis darüber, was zugegriffen wurde.

Das Governance-Ziel ist es zu verhindern, dass unverwaltete KI-Workflows ein eingefügtes Token oder geteiltes Passwort in einen dauerhaften Zugriffspfad verwandeln. Das erfordert spezifische Kontrollen: einzigartige Credentials pro Dienst, keine geteilten Passwörter in Chat oder Tickets, tresorbasiertes Teilen mit Zugriffskontrollen, Least Privilege bei Service-Accounts, MFA bei allen administrativen Zugriffen, regelmäßige Secret-Rotation, API-Schlüssel-Inventar, OAuth-Berechtigungsprüfungen und Audit-Logs, die den Credential-Zugriff abdecken.

Passwork ist als selbst gehostete Bereitstellung oder in der Cloud verfügbar, mit einer vollständigen REST API und CLI-Tools für Teams, die Credential-Management in bestehende DevOps-Workflows integrieren müssen. Zugriffsüberprüfungen, Audit-Logs und Rollenzuweisungen werden über eine einzige Oberfläche verwaltet — keine separaten Tools erforderlich. Mehr erfahren

Eine praktische Shadow-AI-Governance-Checkliste

Diese Checkliste ist für Sicherheitsingenieure und Compliance-Teams konzipiert, die ein Shadow-AI-Governance-Programm beginnen oder ausbauen. Überprüfen Sie sie vierteljährlich — KI-Tool-Funktionen und regulatorische Anforderungen ändern sich schneller, als jährliche Zyklen erfassen können.

Die Shadow-AI-Governance-Checkliste (10 Punkte)

1. Definieren Sie genehmigte, bedingte und verbotene KI-Anwendungsfälle nach Datentyp und Geschäftsfunktion.
2. Erstellen Sie eine Liste genehmigter KI-Tools nach Funktion: Schreiben, Coding, Datenanalyse, Meeting-Notizen, Kundensupport.
3. Verlangen Sie Enterprise-Accounts für genehmigte Tools, bei denen sensible Daten verarbeitet werden könnten.
4. Blockieren oder warnen Sie bei öffentlichem Upload eingeschränkter Datenkategorien (PII, Quellcode, Finanzprognosen, juristische Dokumente, Credentials).
5. Überprüfen Sie KI-Browser-Erweiterungen und OAuth-Berechtigungen — entziehen Sie solche ohne dokumentierten Geschäftsbedarf.
6. Auditieren Sie API-Token, Service-Accounts, geteilte Credentials und Secrets, die in der Nähe von KI-Workflows verwendet werden.
7. Fügen Sie DLP- oder Browser-Kontrollen für Prompts, Datei-Uploads und Kopieren/Einfügen-Ereignisse hinzu, wo angemessen und rechtlich zulässig.
8. Veröffentlichen Sie Beispiele für erlaubte und verbotene Prompts — konkrete Beispiele übertreffen abstrakte Richtlinien.
9. Schulen Sie Teams rollenspezifisch: Entwickler, Vertrieb, Recht, HR, Finanzen und Support stehen vor unterschiedlichen KI-Risikoszenarien.
10. Überprüfen Sie KI-Richtlinien vierteljährlich, da sich Tool-Funktionen, Anbieter-Aufbewahrungsbedingungen und Vorschriften schnell ändern.

Fazit

Shadow AI ist kein Grund, die KI-Einführung zu verlangsamen. Sie ist ein Grund, KI als Daten-, Identitäts- und Zugriffsproblem zu behandeln — dieselben Disziplinen, die Sicherheitsteams bereits auf andere Technologien anwenden, angewandt auf eine sich schneller bewegende und schwerer zu beobachtende Kategorie.

Die fünf Dimensionen des Shadow-AI-Risikomultiplikators — Datenexfiltration durch normale Arbeit, persönliche Accounts, die Enterprise-Kontrollen brechen, KI-beeinflusste Entscheidungen, agentische Aktionen und Credential-Exposition — erklären, warum bestehende Shadow-IT-Kontrollen notwendig, aber nicht ausreichend sind. Jede Dimension erfordert eine spezifische Antwort: Datenklassifizierung, Bereitstellung genehmigter Tools, Output-Governance, Überprüfung von Agenten-Berechtigungen und Secrets-Management.

Die Organisationen, die dies gut managen, sind diejenigen, die Mitarbeitenden sichere Optionen geben, klare Regeln definieren und die Monitoring-Fähigkeit aufbauen, um zu sehen, was tatsächlich passiert.

Wenn Ihr Team Shadow-AI-Kontrollen überprüft, beziehen Sie geteilte Passwörter, API-Schlüssel, Service-Accounts und Secrets in die Bewertung ein. Passwork unterstützt diesen Teil des Governance-Programms durch Zentralisierung des Credential-Zugriffs, Integration mit LDAP/SSO und Bereitstellung von Audit-Sichtbarkeit für passwortbezogene Workflows.

Häufig gestellte Fragen

Ist Shadow AI dasselbe wie Shadow IT?

Nein. Shadow AI ist mit Shadow IT verwandt, bezieht sich aber speziell auf nicht genehmigte KI-Tools, KI-Funktionen, Modelle, Prompts, Agenten und Workflows. Sie fügt eigenständige Risiken hinzu rund um die Datenverarbeitung durch Prompts und Datei-Uploads, Modell-Aufbewahrung, Qualität generierter Outputs und delegierte Berechtigungen für KI-Agenten. Traditionelle Shadow IT verursacht hauptsächlich unverwalteten Technologie-Wildwuchs.

Warum ist Shadow AI gefährlicher als Shadow IT?

Shadow AI ist oft gefährlicher, weil sie sensible Daten durch Prompts und Datei-Uploads exponieren, Geschäftsentscheidungen durch ungeprüfte Outputs beeinflussen und über Agenten und Integrationen mit Credentials oder Systemen interagieren kann. IBMs 2025-Studie ergab, dass Organisationen mit hoher Shadow-AI-Nutzung durchschnittlich 670.000 US-Dollar mehr an Kosten für Sicherheitsvorfälle hatten als solche mit geringer oder keiner Shadow-AI-Nutzung.

Welche Daten sollten Mitarbeitende niemals in öffentliche KI-Tools einfügen?

Mitarbeitende sollten keine Passwörter, API-Schlüssel, Token, Quellcode, Kundendaten, HR-Daten, juristische Dokumente, Finanzprognosen, regulierte Daten (Gesundheitsdaten, PII) oder vertrauliches geistiges Eigentum in öffentliche KI-Tools einfügen, es sei denn, die Organisation hat dieses Tool und den Anwendungsfall ausdrücklich mit angemessenen vertraglichen Datenschutzmaßnahmen genehmigt.

Können Unternehmen Shadow AI vollständig stoppen?

Die meisten Organisationen sollten sich nicht auf ein vollständiges Verbot verlassen. Harmonic Securitys 2025-Daten zeigten, dass zwar nur 40 % der Unternehmen offizielle KI-Abonnements erworben haben, Mitarbeitende bei über 90 % der Organisationen aber aktiv KI-Tools nutzen — meist über persönliche Accounts. Eine bessere Strategie ist es, genehmigte KI-Tools bereitzustellen, klare Anwendungsfälle zu definieren, die Bewegung sensibler Daten zu überwachen und Zugriffskontrollen durchzusetzen.

Wie können Sicherheitsteams Shadow AI erkennen?

Die Erkennung erfordert eine Kombination aus KI-Domain-Inventar, Browser-Sichtbarkeitstools, DLP, SaaS-Security-Posture-Review (SSPM), OAuth-Grant-Review, Endpunkt-Telemetrie und Mitarbeitermeldungen. Sicherheitsteams sollten auch KI-Funktionen auditieren, die in bereits genehmigte SaaS-Tools eingebettet sind — diese werden oft übersehen, weil die übergeordnete Anwendung genehmigt ist.

Wie helfen Passwort-Manager bei Shadow-AI-Risiken?

Passwort-Manager verwalten KI nicht direkt, reduzieren aber den Credential-Wildwuchs rund um KI-Workflows. Sie helfen dabei, geteilte Credentials zu zentralisieren, rollenbasierte Zugriffskontrollen durchzusetzen, Audit-Trails für Passwort- und Secret-Nutzung zu unterstützen, Secret-Rotation zu vereinfachen und Sichtbarkeit darüber zu bieten, welche Credentials mit wem geteilt werden — all das ist relevant, wenn KI-Tools oder -Agenten diese Credentials möglicherweise berührt haben.

Adressiert der EU AI Act Shadow AI?

Der EU AI Act (in Kraft seit August 2024, mit gestaffelten Verpflichtungen bis 2027) etabliert Anforderungen für KI-Systemanbieter und -betreiber, einschließlich Transparenz, Risikoklassifizierung und Governance-Verpflichtungen für Hochrisiko-KI-Systeme. Er reguliert nicht direkt die Nutzung von Consumer-KI-Tools durch Mitarbeitende, aber Organisationen, die dem Gesetz unterliegen, sollten sicherstellen, dass ihre KI-Governance-Programme nicht genehmigte Nutzung abdecken, insbesondere bei Hochrisiko-Anwendungsfällen. Rechtsabteilungen sollten die anwendbaren Verpflichtungen unter den spezifischen Artikeln prüfen, die für ihren KI-Einsatzkontext relevant sind.

VaultJacking: Wie eine PIN den Google Passwortmanager öffnet

VaultJacking zielt auf die PIN des Google Passwortmanagers ab, um Ihren gesamten Tresor zu entsperren. Eine abgefangene PIN legt alle gespeicherten Passwörter und Passkeys offen. Erfahren Sie, wie der Angriff funktioniert, wer gefährdet ist und was Sie tun können, wenn Sie Opfer von Phishing wurden.

Passwork BlogAlex Muntyan

NIS2 aktuelle Neuigkeiten: Updates Mai 2026

Bulgariens Sanktionsphase, Luxemburgs neues Gesetz, Cyberbeveiligingswet der Niederlande, ENISA NIS360 2026 — NIS2-Entwicklungen Mai 2026.

Passwork BlogAlex Muntyan

Passwork gewinnt Top Performer Spring 2026 auf SourceForge

Passwork wurde von SourceForge als Top Performer Spring 2026 ausgezeichnet und gehört damit zu den besten 10 % von über 100.000 Lösungen. Die Auszeichnung basiert ausschließlich auf verifizierten Bewertungen — 4,8 Sterne insgesamt, mit einer perfekten 5,0 für den Support.

Passwork BlogAlex Muntyan

Shadow IT es el uso de tecnología no aprobada sin conocimiento ni supervisión de TI. Shadow AI es el uso de herramientas, modelos, funciones y flujos de trabajo de IA no aprobados — y suele ser más arriesgado porque puede procesar datos sensibles, influir en decisiones, generar resultados e interactuar con credenciales o sistemas completamente fuera de la gobernanza normal.

La magnitud del problema ya es visible en los datos de brechas:

• Una de cada cinco organizaciones reportó una brecha debido a shadow AI, y el alto uso de shadow AI añadió un promedio de $670,000 a los costos de brechas — Informe del Costo de una Brecha de Datos 2025 de IBM.
• Más de la mitad de los ejecutivos (58%) reportaron que su organización experimentó un incidente de seguridad relacionado con IA o una situación cercana en el último año — encuesta AI Agents at Work 2026 de Okta.
• Se encontraron más de 1,27 millones de secretos de servicios de IA filtrados en GitHub público. Un 81% más que el año anterior. Ocho de los diez tipos de secretos filtrados de más rápido crecimiento están vinculados a servicios de IA — State of Secrets Sprawl 2026 de GitGuardian.
• Solo el 5% de las empresas tiene visibilidad completa sobre qué herramientas de IA están usando realmente los empleados, y el 78% confirmó un incidente de seguridad relacionado con IA o no pudo descartarlo — 2026 Cloud Security Report de Check Point.
• El 92% de los profesionales de seguridad están preocupados por los agentes de IA y su impacto en la seguridad, pero solo el 37% de las organizaciones tiene una política formal de IA implementada — State of AI Cybersecurity 2026 de Darktrace.

Los gobiernos han tomado nota. La Ley de IA de la UE está ahora en aplicación activa, con sanciones por uso no conforme de sistemas de IA de alto riesgo que alcanzan hasta 15 millones de euros o el 3% de la facturación anual global.

En Estados Unidos, el presidente Trump firmó una orden ejecutiva el 2 de junio de 2026 — «Promoting Advanced Artificial Intelligence Innovation and Security» — ordenando a CISA expandir las ciberdefensas habilitadas por IA en los sistemas federales y operadores de infraestructura crítica, y estableciendo un marco voluntario para evaluar modelos de IA de frontera antes de su lanzamiento público. La orden no regula cómo los empleados usan la IA dentro de las empresas, pero señala claramente que la seguridad de la IA es ahora una prioridad federal y que las organizaciones que operan infraestructura crítica ya están dentro del alcance.

Las herramientas están en uso. Los datos se están moviendo. ¿Hacia dónde? La mayoría de las organizaciones simplemente no lo sabe.

Puntos clave

• Shadow AI es una categoría de riesgo distinta, no solo Shadow IT con marca de IA. Las herramientas, modelos y agentes de IA no aprobados procesan datos, influyen en decisiones e interactúan con credenciales completamente fuera de la gobernanza normal, mientras que el Shadow IT tradicional solo crea dispersión tecnológica no gestionada.
• Los datos de brechas ya son visibles. Una de cada cinco organizaciones reportó una brecha debido a Shadow AI. La mayoría de las empresas no tiene una imagen clara de qué herramientas de IA están usando realmente los empleados.
• Las cuentas personales son la principal brecha de control. La mayoría del uso de herramientas de IA ocurre a través de cuentas personales que evitan SSO, DLP y registro centralizado, sin dejar rastro de auditoría ni base contractual para la eliminación de datos.
• Los agentes de IA desplazan el problema de la entrada de datos al acceso y la acción. Los agentes pueden leer archivos, llamar a APIs y modificar código mediante permisos OAuth delegados, y esas acciones pueden no registrarse en ningún lugar que el equipo de seguridad pueda ver.
• La exposición de credenciales es la brecha de mayor severidad. Los registros, fragmentos de código, archivos de entorno y datos de autocompletado del navegador frecuentemente contienen contraseñas, claves API o tokens. Cuando se pegan en una herramienta de IA, el resultado es una potencial ruta de acceso persistente, no solo un evento de exposición de datos.
• La prohibición total reubica el Shadow AI, no lo elimina. Los empleados migran a dispositivos personales y herramientas alternativas con menos señales de auditoría. Una gobernanza efectiva proporciona alternativas aprobadas y monitorea el movimiento de datos sensibles.
• Los reguladores han tomado nota. La Ley de IA de la UE está en aplicación activa, con sanciones que alcanzan 15 millones de euros o el 3% de la facturación anual global. Una orden ejecutiva de EE. UU. firmada el 2 de junio de 2026 señala que la seguridad de la IA es ahora una prioridad federal.
• La gobernanza requiere cinco respuestas específicas. Clasificación de datos, provisión de herramientas aprobadas, gobernanza de resultados, revisión de permisos de agentes y gestión de secretos. Los controles existentes de Shadow IT son necesarios pero no suficientes.

¿Qué es Shadow IT?

Shadow IT es cualquier tecnología (software, hardware, servicios en la nube, aplicaciones SaaS, scripts o infraestructura) utilizada dentro de una organización sin aprobación, conocimiento o supervisión de TI. El término abarca una amplia gama de comportamientos: un empleado que usa un almacenamiento personal en la nube para compartir archivos, un equipo que implementa una herramienta de gestión de proyectos no aprobada, un desarrollador que ejecuta scripts en infraestructura no gestionada, o un departamento que se suscribe a un producto SaaS fuera del proceso de adquisiciones.

El problema central del Shadow IT es la pérdida de gobernanza. Cuando TI no sabe que existe una herramienta, no puede aplicar controles de acceso, implementar políticas de Prevención de Pérdida de Datos (DLP), gestionar el ciclo de vida de los datos ni revocar el acceso cuando un empleado se va. Los requisitos de licencias, cumplimiento y rastro de auditoría también quedan sin cubrir.

El Shadow IT sigue un camino predecible. Un empleado necesita una herramienta — compartir archivos más rápido, un rastreador de proyectos, un script que funcione en algo diferente al stack aprobado. El proceso oficial es demasiado lento o la herramienta simplemente no está disponible, así que encuentran su propia solución. TI nunca se entera.

Ejemplos comunes de Shadow IT incluyen:

• Almacenamiento personal en la nube (cuentas de consumidor usadas para archivos de trabajo)
• Aplicaciones de mensajería y colaboración no aprobadas
• Extensiones de navegador con amplios permisos de datos
• Suscripciones SaaS no gestionadas pagadas con presupuesto del equipo
• Scripts y herramientas de automatización creados por desarrolladores que funcionan fuera de la visibilidad de TI
• Dispositivos de consumidor conectados a redes corporativas

El Shadow IT no siempre es malicioso. La mayoría comienza como una solución de productividad — un equipo necesitaba una herramienta, las adquisiciones eran lentas y alguien encontró una alternativa gratuita. Ese contexto importa para la gobernanza: la prohibición sin reemplazo rara vez funciona.

¿Qué es Shadow AI?

Shadow AI es el uso no autorizado de herramientas de IA, funciones de IA, modelos, prompts, agentes y flujos de trabajo sin aprobación ni supervisión de TI. Está relacionado con el Shadow IT pero es distinto: mientras que el Shadow IT principalmente crea dispersión tecnológica no gestionada, el Shadow AI crea procesamiento de datos no gestionado, soporte de decisiones no gestionado y acciones no gestionadas.

El Shadow AI incluye un conjunto amplio y de rápido crecimiento de comportamientos. Los empleados usan modelos de lenguaje grandes públicos (LLMs) como ChatGPT, Claude y Gemini a través de cuentas personales. Los desarrolladores usan asistentes de codificación con IA como GitHub Copilot o Cursor fuera de los tenants empresariales. Los equipos usan asistentes de reuniones con IA, extensiones de navegador con IA y funciones SaaS potenciadas por IA que nunca fueron revisadas formalmente. Algunos empleados construyen sus propios flujos de trabajo de IA usando herramientas de automatización de consumidor.

El Shadow AI sigue el mismo camino que el Shadow IT, pero las consecuencias al final son diferentes. Un empleado necesita moverse más rápido — resumir un documento, generar código, redactar una respuesta. No hay herramienta aprobada, o la herramienta aprobada es más lenta que la que ya usan personalmente. Así que usan su propia cuenta, una extensión de navegador o una función de IA integrada en un producto SaaS que TI ya aprobó pero nunca auditó.

Ejemplos comunes de Shadow AI en la práctica:

• Empleados usando ChatGPT, Claude, Gemini o Perplexity a través de cuentas personales de nivel gratuito
• Desarrolladores usando asistentes de codificación con IA fuera de los controles de licencia empresarial
• Equipos de ventas y marketing usando herramientas de escritura con IA no revisadas por seguridad
• Equipos de RR. HH. y finanzas usando IA para resumir documentos que contienen datos regulados
• Asistentes de reuniones con IA grabando y transcribiendo llamadas sin controles de retención empresarial
• Extensiones de IA basadas en navegador con acceso al contenido de la página, portapapeles y campos de formulario
• Agentes de IA construidos por empleados conectándose a APIs SaaS o sistemas internos

La escala es significativa. El informe 2025 de Menlo Security registró 10,53 mil millones de visitas a sitios de IA solo en enero de 2025, frente a 7 mil millones en febrero de 2024, con el 80% de ese acceso ocurriendo a través de navegadores. El Shadow AI no es un comportamiento de nicho — es la forma en que la mayoría de los empleados actualmente usa la IA.

Shadow IT vs Shadow AI: Las diferencias clave

El Shadow IT y el Shadow AI comparten la misma causa raíz: empleados resolviendo problemas reales con herramientas que TI no ha aprobado. Pero crean diferentes perfiles de riesgo y requieren diferentes controles.

La brecha de remediación es particularmente significativa. Cuando un empleado usa una herramienta SaaS no aprobada, TI puede revocar el acceso y migrar los datos. Cuando el contenido sensible entra en el flujo de trabajo de un modelo de IA externo, confirmar la eliminación, demostrar la no retención y delimitar el incidente es sustancialmente más difícil, especialmente cuando se accedió a la herramienta a través de una cuenta personal sin rastro de auditoría empresarial.

Por qué Shadow AI es la amenaza mayor

El Shadow AI es a menudo más peligroso que el Shadow IT tradicional porque no solo almacena o mueve datos — los procesa, genera y actúa sobre ellos. Las siguientes cinco dimensiones explican dónde cambia el modelo de riesgo. Juntas, forman lo que este artículo llama el multiplicador de riesgo del Shadow AI.

1. La exfiltración de datos ocurre a través del trabajo ordinario

Los empleados no necesitan exfiltrar datos intencionalmente. Pegan correos electrónicos, contratos, hojas de cálculo, código fuente, tickets de soporte, registros de clientes, información de RR. HH. y registros del sistema en herramientas de IA como parte del trabajo normal. Cada prompt es una potencial transferencia de datos.

El análisis de Harmonic Security de 22.458.240 prompts de IA generativa empresarial de 2025 detectó 579.113 instancias de exposición de datos sensibles en 665 herramientas de IA. El código, los documentos legales y los datos financieros representaron el 74,5% de lo expuesto. Según el AI Adoption & Risk Report 2026 de Cyberhaven, el 39,7% de todas las interacciones con IA involucraron datos sensibles, y los empleados introducen datos sensibles en herramientas de IA una vez cada tres días en promedio.

Los datos sensibles y la IA están ahora integrados en los flujos de trabajo diarios, y la exposición no es ocasional.

2. Las cuentas personales rompen los controles empresariales

Una parte significativa del uso de IA ocurre a través de cuentas personales en lugar de tenants empresariales. Los datos de 2026 de Cyberhaven encontraron que el 32,3% del uso de ChatGPT, el 58,2% del uso de Claude y el 60,9% del uso de Perplexity ocurrieron a través de cuentas personales. El informe 2025 de Menlo Security encontró que el 68% de los empleados usaron herramientas de IA de nivel gratuito a través de cuentas personales, con el 57% introduciendo datos sensibles.

Las cuentas personales evitan la aplicación de SSO, las políticas de retención empresarial, el registro centralizado, los controles DLP y la gobernanza de datos a nivel de administrador. Cuando un empleado usa Claude o Perplexity a través de una cuenta personal, la organización no tiene visibilidad de lo que se envió, no tiene rastro de auditoría y no tiene base contractual para la eliminación de datos o compromisos de no entrenamiento.

3. La IA puede influir en decisiones, no solo almacenar archivos

El Shadow IT principalmente crea almacenamiento o transferencia de datos no gestionados. El Shadow AI hace algo más: resume, clasifica, clasifica, recomienda, genera código y redacta contenido dirigido a clientes o legal. Una herramienta de IA no aprobada puede dar forma a una decisión empresarial basada en datos no verificados, una versión de modelo desconocida y suposiciones que el usuario nunca examinó.

Las alucinaciones, la deriva del modelo y el sesgo en los resultados de IA son modos de fallo reales. Cuando la herramienta no está sancionada y el resultado no está atribuido, no hay forma de auditar la cadena de decisiones después del hecho.

4. Los agentes de IA extienden el problema de la entrada a la acción

Los agentes de IA pueden leer archivos, usar portapapeles, llamar a APIs, enviar mensajes, modificar código y conectarse a sistemas SaaS. Muchos funcionan a nivel del sistema operativo, mantienen ventanas de contexto persistentes y sincronizan datos con infraestructura fuera de la supervisión del equipo de seguridad.

Esto mueve el Shadow AI de un problema de entrada de datos a un problema de acceso y acción. Un agente con permisos OAuth delegados o una clave API puede actuar en nombre de un usuario, y esas acciones pueden no registrarse en ningún lugar que el equipo de seguridad pueda ver.

5. La exposición de credenciales y secretos convierte el uso de IA en riesgo de acceso

Los registros, fragmentos de código, archivos de entorno, datos de autocompletado del navegador y tickets de soporte frecuentemente contienen contraseñas, claves API o tokens. Cuando estos se pegan en una herramienta de IA — a menudo accidentalmente — el resultado no es solo un evento de exposición de datos. Es una potencial ruta de acceso persistente.

El informe 2025 de IBM encontró que el 97% de las organizaciones comprometidas a través de modelos o aplicaciones de IA carecían de controles de acceso de IA adecuados, lo que significa que la mayoría de las organizaciones que experimentaron una brecha relacionada con IA no tenían ninguna capa de control significativa implementada.

Si su equipo está comenzando a mapear la exposición al Shadow AI, las credenciales y los secretos suelen ser la brecha de mayor severidad. Passwork centraliza contraseñas compartidas, claves API y credenciales de cuentas de servicio en una única bóveda cifrada con RBAC, integración LDAP/SSO y un registro de auditoría completo de cada evento de acceso. Cuando un empleado se va o se da de baja un flujo de trabajo de IA, el acceso se revoca en un solo lugar, sin necesidad de rastrearlo en una docena de herramientas. Pruebe Passwork gratis

Ejemplos reales de riesgo de Shadow AI

Los escenarios de riesgo a continuación son representativos de lo que los equipos de seguridad y TI encuentran en todos los departamentos. Ninguno requiere intención maliciosa — cada uno comienza con un objetivo de productividad legítimo.

El riesgo tiende a concentrarse en un pequeño número de herramientas de alto uso, lo cual es útil para la priorización de la gobernanza. Pero la larga cola todavía importa — una integración raramente usada puede conllevar el mismo riesgo de exposición de credenciales que un asistente de uso diario.

Por qué prohibir la IA generalmente empeora el Shadow AI

Una prohibición total de las herramientas de IA no elimina el Shadow AI. Lo reubica. Los empleados migran a dispositivos personales, cuentas personales o herramientas alternativas en las que TI tiene menos visibilidad. El resultado es la misma exposición de datos con menos señales de auditoría.

Según la encuesta de Okta publicada en mayo de 2026, más de la mitad de los empleados reportaron usar herramientas de IA personales sin aprobación. Dos tercios de los empleados en EE. UU. usan IA no sancionada, y casi una cuarta parte lo hace regularmente. Al mismo tiempo, el 58% de los ejecutivos dijo que su organización tuvo un incidente de seguridad relacionado con IA o una situación cercana en el año anterior.

La investigación de Okta también encontró que más de la mitad de los empleados dicen que las políticas de uso de IA de su organización son poco claras, difíciles de encontrar o inexistentes. Esa brecha entre la confianza ejecutiva y la experiencia del empleado es donde crece el Shadow AI.

Algunos casos de uso de alto riesgo deberían bloquearse directamente — pegar registros de clientes en una herramienta de IA pública, o conectar un agente de IA de consumidor a sistemas de producción. Pero la prohibición total no funciona. Los empleados adoptan shadow AI por razones racionales: mejores herramientas, resultados más rápidos, adquisiciones que se mueven demasiado lento. Una gobernanza efectiva proporciona alternativas aprobadas, establece límites claros y monitorea el movimiento de datos sensibles. Ignore los incentivos subyacentes y el comportamiento no cambiará.

Cómo detectar Shadow AI en la empresa

Detectar shadow AI requiere visibilidad en navegadores, endpoints, permisos SaaS y sistemas de identidad. La investigación de 2025 de IBM encontró que solo el 34% de las organizaciones con políticas de gobernanza de IA realizaron auditorías regulares para IA no sancionada — lo que significa que la mayoría de las organizaciones tienen política sin visibilidad operativa.

Un enfoque de detección práctico cubre siete áreas

1. Paso 1. Inventariar dominios de IA, extensiones de navegador, funciones de IA en SaaS, herramientas de reuniones con IA, asistentes de codificación con IA y funciones de IA integradas en aplicaciones ya aprobadas.
2. Paso 2. Monitorear el uso de IA generativa basada en navegador, eventos de copiar/pegar, cargas de archivos y descargas cuando sea legal y éticamente apropiado bajo las reglas de monitoreo de empleados de su jurisdicción.
3. Paso 3. Revisar concesiones OAuth, tokens API, cuentas de servicio y permisos de aplicaciones de terceros. Los agentes e integraciones de IA a menudo solicitan amplios alcances OAuth que persisten mucho después de la configuración inicial.
4. Paso 4. Clasificar las categorías de datos sensibles que nunca deberían enviarse a herramientas de IA externas sin aprobación explícita: datos de identificación personal, código fuente, pronósticos financieros, documentos legales, datos de salud regulados y credenciales.
5. Paso 5. Verificar los controles de identidad: cobertura de SSO, aplicación de MFA, aprovisionamiento SCIM/LDAP, asignaciones RBAC y completitud del registro de auditoría. Las cuentas de IA personales evitan todos estos.
6. Paso 6. Buscar credenciales expuestas en repositorios de código, registros, tickets y flujos de trabajo relacionados con IA. Los tokens y las claves API aparecen en lugares inesperados — historial de commits, hilos de Slack, tickets de soporte y registros de prompts de IA.
7. Paso 7. Mapear el uso de IA a la necesidad empresarial antes de bloquearlo. Comprender por qué los empleados usan una herramienta es necesario para proporcionar una alternativa gobernada que realmente usarán.

Cómo reducir el riesgo de Shadow AI sin bloquear la productividad

La gobernanza efectiva del Shadow AI es un problema de habilitación tanto como un problema de seguridad. El objetivo es dar a los empleados opciones seguras y aprobadas mientras se aplican controles donde los datos sensibles están en riesgo.

La capa de identidad y acceso necesita tres cosas: cobertura de SSO en las herramientas de IA aprobadas, aplicación de MFA y aprovisionamiento SCIM o LDAP que vincule el acceso directamente al estado de empleo. Para contraseñas y secretos, una bóveda centralizada con control de acceso basado en roles, integración con Active Directory y registros de actividad convierte la gestión de credenciales de una tarea manual en un proceso auditable.

Dónde encajan las contraseñas y los secretos en la gobernanza del Shadow AI

La gobernanza del Shadow AI trata sobre qué credenciales y permisos pueden alcanzar las herramientas adyacentes a la IA.

La exposición de credenciales en flujos de trabajo de IA a menudo ocurre indirectamente:

• Un desarrollador pega un archivo de registro en un asistente de codificación — el registro contiene una cadena de conexión a la base de datos
• Un ingeniero de soporte comparte una captura de pantalla en una herramienta de IA — la captura de pantalla muestra una clave API en una pestaña del navegador
• Un empleado carga un archivo de configuración de entorno para depuración asistida por IA — el archivo contiene credenciales de cuenta de servicio

Ninguno de estos es un evento de exfiltración deliberada. Todos ellos crean un riesgo de acceso real.

Los asistentes de codificación y agentes de IA agravan esto. Pueden interactuar con repositorios, terminales, APIs SaaS y sistemas de archivos locales. Un agente con acceso a la sesión de terminal de un desarrollador puede leer variables de entorno, claves SSH y archivos de credenciales. Si ese agente funciona a través de una cuenta personal sin rastro de auditoría empresarial, la organización no tiene registro de lo que se accedió.

El objetivo de la gobernanza es evitar que los flujos de trabajo de IA no gestionados conviertan un token pegado o una contraseña compartida en una ruta de acceso persistente. Eso requiere controles específicos: credenciales únicas por servicio, sin contraseñas compartidas en chat o tickets, compartición basada en bóveda con controles de acceso, privilegio mínimo en cuentas de servicio, MFA en todo acceso administrativo, rotación regular de secretos, inventario de claves API, revisiones de permisos OAuth y registros de auditoría que cubran el acceso a credenciales.

Passwork está disponible como despliegue autoalojado o en la nube, con una REST API completa y herramientas CLI para equipos que necesitan integrar la gestión de credenciales en flujos de trabajo DevOps existentes. Las revisiones de acceso, los registros de auditoría y las asignaciones de roles se gestionan a través de una única interfaz — sin necesidad de herramientas separadas. Más información

Una lista de verificación práctica para la gobernanza del Shadow AI

Esta lista de verificación está diseñada para ingenieros de seguridad y equipos de cumplimiento que comienzan o maduran un programa de gobernanza de Shadow AI. Revísela trimestralmente — las capacidades de las herramientas de IA y los requisitos regulatorios cambian más rápido de lo que los ciclos anuales pueden rastrear.

La lista de verificación de gobernanza de Shadow AI (10 puntos)

1. Definir casos de uso de IA aprobados, condicionales y prohibidos por tipo de datos y función empresarial.
2. Crear una lista de herramientas de IA aprobadas por función: redacción, codificación, análisis de datos, notas de reuniones, soporte al cliente.
3. Requerir cuentas empresariales para herramientas aprobadas donde se puedan procesar datos sensibles.
4. Bloquear o advertir sobre la carga pública de categorías de datos restringidos (datos de identificación personal, código fuente, pronósticos financieros, documentos legales, credenciales).
5. Revisar las extensiones de navegador de IA y los permisos OAuth — revocar aquellos sin una necesidad empresarial documentada.
6. Auditar tokens API, cuentas de servicio, credenciales compartidas y secretos usados cerca de flujos de trabajo de IA.
7. Añadir DLP o controles de navegador para prompts, cargas de archivos y eventos de copiar/pegar donde sea apropiado y legalmente permitido.
8. Publicar ejemplos de prompts permitidos y prohibidos — los ejemplos concretos superan a la política abstracta.
9. Formar a los equipos por rol: desarrolladores, ventas, legal, RR. HH., finanzas y soporte enfrentan diferentes escenarios de riesgo de IA.
10. Revisar las políticas de IA trimestralmente porque las capacidades de las herramientas, los términos de retención del proveedor y las regulaciones cambian rápidamente.

Conclusión

Shadow AI no es una razón para frenar la adopción de IA. Es una razón para gobernar la IA como un problema de datos, identidad y acceso — las mismas disciplinas que los equipos de seguridad ya aplican a otras tecnologías, aplicadas a una categoría que se mueve más rápido y es más difícil de observar.

Las cinco dimensiones del multiplicador de riesgo del Shadow AI — exfiltración de datos a través del trabajo ordinario, cuentas personales que rompen los controles empresariales, decisiones influenciadas por IA, acción agéntica y exposición de credenciales — explican por qué los controles existentes de Shadow IT son necesarios pero no suficientes. Cada dimensión requiere una respuesta específica: clasificación de datos, provisión de herramientas aprobadas, gobernanza de resultados, revisión de permisos de agentes y gestión de secretos.

Las organizaciones que gestionan esto bien son las que dan a los empleados opciones seguras, definen reglas claras y construyen la capacidad de monitoreo para ver lo que realmente está sucediendo.

Si su equipo está revisando los controles de Shadow AI, incluya contraseñas compartidas, claves API, cuentas de servicio y secretos en la evaluación. Passwork apoya esta parte del programa de gobernanza centralizando el acceso a credenciales, integrándose con LDAP/SSO y proporcionando visibilidad de auditoría para flujos de trabajo relacionados con contraseñas.

Preguntas frecuentes

¿Es Shadow AI lo mismo que Shadow IT?

No. Shadow AI está relacionado con Shadow IT pero involucra específicamente herramientas de IA, funciones de IA, modelos, prompts, agentes y flujos de trabajo no aprobados. Añade riesgos distintos en torno al procesamiento de datos a través de prompts y cargas de archivos, retención de modelos, calidad de resultados generados y permisos delegados para agentes de IA. El Shadow IT tradicional principalmente crea dispersión tecnológica no gestionada.

¿Por qué Shadow AI es más peligroso que Shadow IT?

Shadow AI es a menudo más peligroso porque puede exponer datos sensibles a través de prompts y cargas de archivos, influir en decisiones empresariales a través de resultados no verificados e interactuar con credenciales o sistemas a través de agentes e integraciones. La investigación de 2025 de IBM encontró que las organizaciones con alto uso de shadow AI incurrieron en un promedio de $670,000 más en costos de brechas que aquellas con bajo o ningún uso de shadow AI.

¿Qué datos nunca deberían pegar los empleados en herramientas de IA públicas?

Los empleados no deberían pegar contraseñas, claves API, tokens, código fuente, registros de clientes, registros de RR. HH., documentos legales, pronósticos financieros, datos regulados (registros de salud, datos de identificación personal) o propiedad intelectual confidencial en herramientas de IA públicas a menos que la organización haya aprobado explícitamente esa herramienta y caso de uso con protecciones de datos contractuales apropiadas.

¿Pueden las empresas detener completamente el Shadow AI?

La mayoría de las organizaciones no deberían depender de la prohibición completa. Los datos de 2025 de Harmonic Security encontraron que mientras solo el 40% de las empresas han comprado suscripciones oficiales de IA, los empleados en más del 90% de las organizaciones usan activamente herramientas de IA — principalmente a través de cuentas personales. Una mejor estrategia es proporcionar herramientas de IA aprobadas, definir casos de uso claros, monitorear el movimiento de datos sensibles y aplicar controles de acceso.

¿Cómo pueden los equipos de seguridad detectar Shadow AI?

La detección requiere una combinación de inventario de dominios de IA, herramientas de visibilidad del navegador, DLP, revisión de postura de seguridad SaaS (SSPM), revisión de concesiones OAuth, telemetría de endpoints e informes de empleados. Los equipos de seguridad también deberían auditar las funciones de IA integradas en herramientas SaaS ya aprobadas — estas a menudo se pasan por alto porque la aplicación principal está sancionada.

¿Cómo ayudan los gestores de contraseñas con el riesgo de Shadow AI?

Los gestores de contraseñas no gobiernan la IA por sí mismos, pero reducen la dispersión de credenciales en torno a los flujos de trabajo de IA. Ayudan a centralizar credenciales compartidas, aplicar controles de acceso basados en roles, soportar rastros de auditoría para el uso de contraseñas y secretos, simplificar la rotación de secretos y proporcionar visibilidad sobre qué credenciales se comparten y con quién — todo lo cual importa cuando las herramientas o agentes de IA pueden haber tocado esas credenciales.

¿Aborda la Ley de IA de la UE el Shadow AI?

La Ley de IA de la UE (en vigor desde agosto de 2024, con obligaciones escalonadas hasta 2027) establece requisitos para proveedores y desplegadores de sistemas de IA, incluyendo obligaciones de transparencia, clasificación de riesgos y gobernanza para sistemas de IA de alto riesgo. No regula directamente el uso de herramientas de IA de consumidor por parte de empleados, pero las organizaciones sujetas a la Ley deberían asegurar que sus programas de gobernanza de IA cubran el uso no sancionado, particularmente para casos de uso de alto riesgo. Los equipos legales deberían revisar las obligaciones aplicables bajo los artículos específicos relevantes para su contexto de despliegue de IA.

VaultJacking: cómo un PIN expone la bóveda de Google

VaultJacking ataca el PIN de Google Password Manager para desbloquear toda la bóveda. Un solo PIN capturado expone todas las contraseñas y passkeys guardadas. Descubra cómo funciona el ataque, quién está en riesgo y qué hacer si ha sido víctima de phishing.

Passwork BlogAlex Muntyan

Últimas noticias NIS2: actualizaciones de mayo 2026

Sanciones en Bulgaria, nueva ley en Luxemburgo, Cyberbeveiligingswet en Países Bajos, ENISA NIS360 2026: novedades de aplicación de NIS2 en mayo de 2026.

Passwork BlogAlex Muntyan

Passwork gana Top Performer Primavera 2026 en SourceForge

Passwork ha sido nombrado Top Performer Primavera 2026 por SourceForge, posicionándose en el 10% superior de más de 100.000 soluciones. La insignia se basa exclusivamente en reseñas verificadas — 4,8 estrellas en general, con un 5,0 perfecto en soporte.

Passwork BlogAlex Muntyan

Shadow IT is the use of unapproved technology without IT knowledge or oversight. Shadow AI is the use of unapproved AI tools, models, features, and workflows — and it is often riskier because it can process sensitive data, influence decisions, generate outputs, and interact with credentials or systems entirely outside normal governance.

The scale of the problem is already visible in breach data:

• One in five organizations reported a breach due to shadow AI, and high shadow AI usage added an average of $670,000 to breach costs — IBM's 2025 Cost of a Data Breach Report.
• More than half of executives (58%) reported that their organization experienced an AI-related security incident or a close call in the past year — Okta's AI Agents at Work 2026 survey.
• Over 1.27 million AI service secrets were found leaked on public GitHub. 81% more than the year before. Eight of the ten fastest-growing leaked secret types are tied to AI services — GitGuardian's State of Secrets Sprawl 2026.
• Only 5% of businesses have full visibility into which AI tools employees are actually using, and 78% either confirmed an AI-related security incident or could not rule one out — Check Point's 2026 Cloud Security Report.
• 92% of security professionals are concerned about AI agents and their security impact, yet only 37% of organizations have a formal AI policy in place — Darktrace's State of AI Cybersecurity 2026.

Governments have taken notice. The EU AI Act is now in active enforcement, with penalties for non-compliant use of high-risk AI systems reaching up to €15 million or 3% of global annual turnover.

In the United States, President Trump signed an executive order on June 2, 2026 — "Promoting Advanced Artificial Intelligence Innovation and Security" — directing CISA to expand AI-enabled cyber defenses across federal systems and critical infrastructure operators, and establishing a voluntary framework for assessing frontier AI models before public release. The order does not regulate how employees use AI inside enterprises, but it signals clearly that AI security is now a federal priority and that organizations operating critical infrastructure are already in scope.

The tools are in use. The data is moving. Where? Most organizations just don't know.

Key takeaways

• Shadow AI is a distinct risk category, not just Shadow IT with AI branding. Unapproved AI tools, models, and agents process data, influence decisions, and interact with credentials entirely outside normal governance, where traditional Shadow IT only creates unmanaged technology sprawl.
• The breach data is already visible. One in five organizations reported a breach due to Shadow AI. Most businesses have no clear picture of which AI tools employees are actually using.
• Personal accounts are the primary control gap. Most AI tool usage happens through personal accounts that bypass SSO, DLP, and centralized logging, leaving no audit trail and no contractual basis for data deletion.
• AI agents shift the problem from data input to access and action. Agents can read files, call APIs, and modify code through delegated OAuth permissions, and those actions may not be logged anywhere the security team can see.
• Credential exposure is the highest-severity gap. Logs, code snippets, environment files, and browser autofill data frequently contain passwords, API keys, or tokens. When pasted into an AI tool, the result is a potential persistent access path, not just a data exposure event.
• Blanket prohibition relocates Shadow AI, it doesn't eliminate it. Employees move to personal devices and alternative tools with fewer audit signals. Effective governance provides approved alternatives and monitors sensitive data movement.
• Regulators have taken notice. The EU AI Act is in active enforcement, with penalties reaching €15 million or 3% of global annual turnover. A U.S. executive order signed June 2, 2026 signals that AI security is now a federal priority.
• Governance requires five specific responses. Data classification, approved tool provisioning, output governance, agent permission review, and secrets management. Existing Shadow IT controls are necessary but not sufficient.

What is Shadow IT?

Shadow IT is any technology (software, hardware, cloud services, SaaS applications, scripts, or infrastructure) used within an organization without IT approval, knowledge, or oversight. The term covers a wide range of behavior: an employee using a personal cloud drive to share files, a team spinning up an unapproved project management tool, a developer running scripts on unmanaged infrastructure, or a department subscribing to a SaaS product outside the procurement process.

The core problem with Shadow IT is governance loss. When IT doesn't know a tool exists, it can't enforce access controls, apply Data Loss Prevention (DLP) policies, manage the data lifecycle, or revoke access when an employee leaves. Licensing, compliance, and audit trail requirements also fall through the gaps.

Shadow IT follows a predictable path. An employee needs a tool — faster file sharing, a project tracker, a script that runs on something other than the approved stack. The official process is too slow or the tool simply isn't available, so they find their own solution. IT never finds out.

Common Shadow IT examples include:

• Personal cloud storage (consumer accounts used for work files)
• Unapproved messaging and collaboration apps
• Browser extensions with broad data permissions
• Unmanaged SaaS subscriptions paid by a team budget
• Developer-built scripts and automation tools running outside IT visibility
• Consumer devices connected to corporate networks

Shadow IT is not always malicious. Most of it starts as a productivity workaround — a team needed a tool, procurement was slow, and someone found a free alternative. That context matters for governance: prohibition without replacement rarely works.

What is Shadow AI?

Shadow AI is the unsanctioned use of AI tools, AI features, models, prompts, agents, and workflows without IT approval or oversight. It is related to Shadow IT but distinct: where Shadow IT mainly creates unmanaged technology sprawl, Shadow AI creates unmanaged data processing, unmanaged decision support, and unmanaged action.

Shadow AI includes a broad and fast-growing set of behaviors. Employees use public large language models (LLMs) like ChatGPT, Claude, and Gemini through personal accounts. Developers use AI coding assistants such as GitHub Copilot or Cursor outside enterprise tenants. Teams use AI meeting assistants, AI browser extensions, and AI-powered SaaS features that were never formally reviewed. Some employees build their own AI workflows using consumer automation tools.

Shadow AI follows the same path as Shadow IT, but the consequences at the end are different. An employee needs to move faster — summarize a document, generate code, draft a response. There's no approved tool, or the approved tool is slower than the one they already use personally. So they use their own account, a browser extension, or an AI feature embedded in a SaaS product IT already approved but never audited.

Common examples of Shadow AI in practice:

• Employees using ChatGPT, Claude, Gemini, or Perplexity through personal free-tier accounts
• Developers using AI coding assistants outside enterprise license controls
• Sales and marketing teams using AI writing tools not reviewed by security
• HR and finance teams using AI to summarize documents containing regulated data
• AI meeting assistants recording and transcribing calls without enterprise retention controls
• Browser-based AI extensions with access to page content, clipboard, and form fields
• Employee-built AI agents connecting to SaaS APIs or internal systems

The scale is significant. Menlo Security's 2025 report recorded 10.53 billion visits to AI sites in January 2025 alone, up from 7 billion in February 2024, with 80% of that access happening through browsers. Shadow AI is not a niche behavior — it is how most employees currently use AI.

Shadow IT vs Shadow AI: The key differences

Shadow IT and Shadow AI share the same root cause: employees solving real problems with tools IT hasn't approved. But they create different risk profiles and require different controls.

The remediation gap is particularly significant. When an employee uses an unapproved SaaS tool, IT can revoke access and migrate data. When sensitive content enters an external AI model's workflow, confirming deletion, proving non-retention, and scoping the incident is substantially harder, especially when the tool was accessed through a personal account with no enterprise audit trail.

Why Shadow AI is the bigger threat

Shadow AI is often more dangerous than traditional Shadow IT because it doesn't just store or move data — it processes, generates, and acts on it. The following five dimensions explain where the risk model changes. Together, they form what this article calls the Shadow AI risk multiplier.

1. Data exfiltration happens through ordinary work

Employees don't need to exfiltrate data intentionally. They paste emails, contracts, spreadsheets, source code, support tickets, customer records, HR information, and system logs into AI tools as part of normal work. Each prompt is a potential data transfer.

Harmonic Security's analysis of 22,458,240 enterprise GenAI prompts from 2025 detected 579,113 sensitive data exposure instances across 665 AI tools. Code, legal documents, and financial data accounted for 74.5% of what was exposed. According to Cyberhaven's 2026 AI Adoption & Risk Report, 39.7% of all AI interactions involved sensitive data, and employees input sensitive data into AI tools once every three days on average.

Sensitive data and AI are now embedded in daily workflows, and the exposure is not occasional.

2. Personal accounts break enterprise controls

A significant share of AI usage happens through personal accounts rather than enterprise tenants. Cyberhaven's 2026 data found that 32.3% of ChatGPT usage, 58.2% of Claude usage, and 60.9% of Perplexity usage occurred through personal accounts. Menlo Security's 2025 report found that 68% of employees used free-tier AI tools via personal accounts, with 57% inputting sensitive data.

Personal accounts bypass SSO enforcement, enterprise retention policies, centralized logging, DLP controls, and admin-level data governance. When an employee uses Claude or Perplexity through a personal account, the organization has no visibility into what was submitted, no audit trail, and no contractual basis for data deletion or non-training commitments.

3. AI can influence decisions, not just store files

Shadow IT mainly creates unmanaged data storage or transfer. Shadow AI does something more: it summarizes, classifies, ranks, recommends, generates code, and drafts customer-facing or legal content. An unapproved AI tool can shape a business decision based on unverified data, an unknown model version, and assumptions the user never examined.

Hallucinations, model drift, and bias in AI output are real failure modes. When the tool is unsanctioned and the output is unattributed, there is no way to audit the decision chain after the fact.

4. AI agents extend the problem from input to action

AI agents can read files, use clipboards, call APIs, send messages, modify code, and connect to SaaS systems. Many run at the operating system level, maintain persistent context windows, and synchronize data to infrastructure outside security team oversight.

This moves Shadow AI from a data-input problem to an access-and-action problem. An agent with delegated OAuth permissions or an API key can act on behalf of a user, and those actions may not be logged anywhere the security team can see.

5. Credential and secrets exposure turns AI use into access risk

Logs, code snippets, environment files, browser autofill data, and support tickets frequently contain passwords, API keys, or tokens. When these get pasted into an AI tool — often accidentally — the result is not just a data exposure event. It is a potential persistent access path.

IBM's 2025 report found that 97% of organizations compromised through AI models or applications lacked proper AI access controls, which means most organizations that experienced an AI-related breach had no meaningful control layer in place.

If your team is starting to map Shadow AI exposure, credentials and secrets are often the highest-severity gap. Passwork centralizes shared passwords, API keys, and service account credentials in a single encrypted vault with RBAC, LDAP/SSO integration, and a full audit log of every access event. When an employee leaves or an AI workflow is decommissioned, access is revoked in one place, not tracked down across a dozen tools. Try Passwork free

Real-world examples of Shadow AI risk

The risk scenarios below are representative of what security and IT teams encounter across departments. None require malicious intent — each starts with a legitimate productivity goal.

Risk tends to concentrate in a small number of high-usage tools, which is useful for governance prioritization. But the long tail still matters — a rarely used integration can carry the same credential exposure risk as a daily-use assistant.

Why banning AI usually makes Shadow AI worse

A blanket ban on AI tools does not eliminate Shadow AI. It relocates it. Employees move to personal devices, personal accounts, or alternative tools that IT has less visibility into. The result is the same data exposure with fewer audit signals.

According to Okta survey published in May 2026, more than half of employees reported using personal AI tools without approval. Two-thirds of U.S.-based employees use unsanctioned AI, and nearly a quarter do so regularly. At the same time, 58% of executives said their organization had an AI-related security incident or close call in the previous year.

The Okta research also found that more than half of employees say their organization's AI usage policies are unclear, difficult to find, or non-existent. That gap between executive confidence and employee experience is where Shadow AI grows.

Some high-risk use cases should be blocked outright — pasting customer records into a public AI tool, or connecting a consumer AI agent to production systems. But blanket prohibition doesn't work. Employees adopt shadow AI for rational reasons: better tools, faster results, procurement that moves too slowly. Effective governance provides approved alternatives, sets clear boundaries, and monitors sensitive data movement. Ignore the underlying incentives and the behavior won't change.

How to detect Shadow AI in the enterprise

Detecting shadow AI requires visibility across browsers, endpoints, SaaS permissions, and identity systems. IBM's 2025 research found that only 34% of organizations with AI governance policies performed regular audits for unsanctioned AI — meaning most organizations have policy without operational visibility.

A practical detection approach covers seven areas

1. Step 1. Inventory AI domains, browser extensions, SaaS AI features, AI meeting tools, AI coding assistants, and AI features embedded in already-approved applications.
2. Step 2. Monitor browser-based GenAI usage, copy/paste events, file uploads, and downloads where legally and ethically appropriate under your jurisdiction's employee monitoring rules.
3. Step 3. Review OAuth grants, API tokens, service accounts, and third-party app permissions. AI agents and integrations often request broad OAuth scopes that persist long after initial setup.
4. Step 4. Classify sensitive data categories that should never be submitted to external AI tools without explicit approval: PII, source code, financial forecasts, legal documents, regulated health data, and credentials.
5. Step 5. Check identity controls: SSO coverage, MFA enforcement, SCIM/LDAP provisioning, RBAC assignments, and audit log completeness. Personal AI accounts bypass all of these.
6. Step 6. Search for exposed credentials in code repositories, logs, tickets, and AI-related workflows. Tokens and API keys appear in unexpected places — commit history, Slack threads, support tickets, and AI prompt logs.
7. Step 7. Map AI usage to business need before blocking it. Understanding why employees use a tool is necessary for providing a governed alternative that they will actually use.

How to reduce Shadow AI risk without blocking productivity

Effective Shadow AI governance is an enablement problem as much as a security problem. The goal is to give employees safe, approved options while applying controls where sensitive data is at risk.

The identity and access layer needs three things: SSO coverage across approved AI tools, MFA enforcement, and SCIM or LDAP provisioning that ties access directly to employment status. For passwords and secrets, a centralized vault with role-based access control, Active Directory integration, and activity logs turns credential management from a manual chore into an auditable process.

Where passwords and secrets fit into Shadow AI governance

Shadow AI governance is about what credentials and permissions AI-adjacent tools can reach.

Credential exposure in AI workflows often happens indirectly:

• A developer pastes a log file into a coding assistant — the log contains a database connection string
• A support engineer shares a screenshot in an AI tool — the screenshot shows an API key in a browser tab
• An employee uploads an environment configuration file for AI-assisted debugging — the file contains service account credentials

None of these are deliberate exfiltration events. All of them create real access risk.

AI coding assistants and agents compound this. They can interact with repositories, terminals, SaaS APIs, and local file systems. An agent with access to a developer's terminal session can read environment variables, SSH keys, and credential files. If that agent runs through a personal account with no enterprise audit trail, the organization has no record of what was accessed.

The governance goal is to prevent unmanaged AI workflows from turning a pasted token or shared password into a persistent access path. That requires specific controls: unique credentials per service, no shared passwords in chat or tickets, vault-based sharing with access controls, least privilege on service accounts, MFA on all administrative access, regular secret rotation, API key inventory, OAuth permission reviews, and audit logs covering credential access.

Passwork is available as a self-hosted deployment or in the cloud, with a full REST API and CLI tools for teams that need to integrate credential management into existing DevOps workflows. Access reviews, audit logs, and role assignments are managed through a single interface — no separate tooling required. Learn more

A practical Shadow AI governance checklist

This checklist is designed for security engineers and compliance teams beginning or maturing a Shadow AI governance program. Review it quarterly — AI tool capabilities and regulatory requirements change faster than annual cycles can track.

The Shadow AI governance checklist (10 points)

1. Define approved, conditional, and prohibited AI use cases by data type and business function.
2. Create a list of approved AI tools by function: writing, coding, data analysis, meeting notes, customer support.
3. Require enterprise accounts for approved tools where sensitive data may be processed.
4. Block or warn on public upload of restricted data categories (PII, source code, financial forecasts, legal documents, credentials).
5. Review AI browser extensions and OAuth permissions — revoke those without a documented business need.
6. Audit API tokens, service accounts, shared credentials, and secrets used near AI workflows.
7. Add DLP or browser controls for prompts, file uploads, and copy/paste events where appropriate and legally permitted.
8. Publish examples of allowed and prohibited prompts — concrete examples outperform abstract policy.
9. Train teams by role: developers, sales, legal, HR, finance, and support face different AI risk scenarios.
10. Review AI policies quarterly because tool capabilities, vendor retention terms, and regulations change quickly.

Conclusion

Shadow AI is not a reason to slow AI adoption. It is a reason to govern AI as a data, identity, and access problem — the same disciplines that security teams already apply to other technology, applied to a faster-moving and harder-to-observe category.

The five dimensions of the Shadow AI risk multiplier — data exfiltration through ordinary work, personal accounts that break enterprise controls, AI-influenced decisions, agentic action, and credential exposure — explain why existing Shadow IT controls are necessary but not sufficient. Each dimension requires a specific response: data classification, approved tool provisioning, output governance, agent permission review, and secrets management.

The organizations that manage this well are the ones that give employees safe options, define clear rules, and build the monitoring capability to see what is actually happening.

If your team is reviewing Shadow AI controls, include shared passwords, API keys, service accounts, and secrets in the assessment. Passwork supports this part of the governance program by centralizing credential access, integrating with LDAP/SSO, and providing audit visibility for password-related workflows.

Frequently Asked Questions

Is Shadow AI the same as Shadow IT?

No. Shadow AI is related to Shadow IT but specifically involves unapproved AI tools, AI features, models, prompts, agents, and workflows. It adds distinct risks around data processing through prompts and file uploads, model retention, generated output quality, and delegated permissions for AI agents. Traditional Shadow IT mainly creates unmanaged technology sprawl.

Why is Shadow AI more dangerous than Shadow IT?

Shadow AI is often more dangerous because it can expose sensitive data through prompts and file uploads, influence business decisions through unverified outputs, and interact with credentials or systems through agents and integrations. IBM's 2025 research found that organizations with high shadow AI usage incurred an average of $670,000 more in breach costs than those with low or no shadow AI usage.

What data should employees never paste into public AI tools?

Employees should not paste passwords, API keys, tokens, source code, customer records, HR records, legal documents, financial forecasts, regulated data (health records, PII), or confidential IP into public AI tools unless the organization has explicitly approved that tool and use case with appropriate contractual data protections in place.

Can companies completely stop Shadow AI?

Most organizations should not rely on complete prohibition. Harmonic Security's 2025 data found that while only 40% of companies have purchased official AI subscriptions, employees at over 90% of organizations actively use AI tools — mostly through personal accounts. A better strategy is to provide approved AI tools, define clear use cases, monitor sensitive data movement, and enforce access controls.

How can security teams detect Shadow AI?

Detection requires a combination of AI domain inventory, browser visibility tools, DLP, SaaS security posture review (SSPM), OAuth grant review, endpoint telemetry, and employee reporting. Security teams should also audit AI features embedded in already-approved SaaS tools — these are often overlooked because the parent application is sanctioned.

How do password managers help with Shadow AI risk?

Password managers do not govern AI by themselves, but they reduce credential sprawl around AI workflows. They help centralize shared credentials, enforce role-based access controls, support audit trails for password and secret use, simplify secret rotation, and provide visibility into which credentials are shared and with whom — all of which matter when AI tools or agents may have touched those credentials.

Does the EU AI Act address Shadow AI?

The EU AI Act (in force from August 2024, with phased obligations through 2027) establishes requirements for AI system providers and deployers, including transparency, risk classification, and governance obligations for high-risk AI systems. It does not directly regulate employee use of consumer AI tools, but organizations subject to the Act should ensure their AI governance programs cover unsanctioned use, particularly for high-risk use cases. Legal teams should review applicable obligations under the specific articles relevant to their AI deployment context.

VaultJacking: How one PIN can expose a Google password manager vault

VaultJacking targets the Google Password Manager PIN to unlock your entire vault. One captured PIN exposes every saved password and passkey. Learn how the attack works, who’s at risk, and what to do if you’ve been phished.

Passwork BlogAlex Muntyan

NIS2 latest news: May 2026 enforcement updates

Bulgaria’s full sanctions phase, Luxembourg’s new law, Netherlands’ Cyberbeveiligingswet, ENISA NIS360 2026 — NIS2 enforcement developments from May 2026.

Passwork BlogAlex Muntyan

Passwork wins Top Performer Spring 2026 on SourceForge

Passwork has been named a Top Performer Spring 2026 by SourceForge, ranking in the top 10% of 100,000+ solutions. The badge is based entirely on verified reviews — 4.8 stars overall, with a perfect 5.0 for support.

Passwork BlogAlex Muntyan

VaultJacking ist eine Phishing-Technik, die auf den Tresor des Google Passwortmanagers abzielt, indem sie die PIN abfängt, die ihn entsperrt. Am 20. Mai 2026 von PhishU demonstriert, zeigt der Angriff, wie ein einziges sechsstelliges Geheimnis — während einer Adversary-in-the-Middle-Phishing-Sitzung (AiTM) abgefangen — einem Angreifer Zugang zu jedem synchronisierten Passwort und Passkey verschaffen kann, den ein Opfer im Google Passwortmanager gespeichert hat.

Für Unternehmen ist das Risiko größer als es erscheint. Der Browser-Tresor eines einzelnen Mitarbeiters kann SSO-Anmeldedaten, Cloud-Konsolen-Zugang, Logins für Finanzplattformen und Code-Repository-Schlüssel enthalten: alles an einem Ort und durch eine einzige abgefangene PIN offengelegt. Dies ist ein organisatorisches Risiko, das außerhalb der meisten bestehenden Incident-Response-Playbooks liegt und außerhalb der Sichtbarkeit der meisten IT- und Sicherheitsteams.

Wichtigste Erkenntnisse

VaultJacking ist relevant, weil Browser-Passwortmanager Passwörter, Passkeys und Wiederherstellungsabläufe in einem einzigen hochwertigen Ziel konzentrieren. Bevor Sie weiterlesen, hier das Wichtigste:

• VaultJacking zielt auf die Tresor-Synchronisierungsebene. Der Angriff bricht nicht die WebAuthn-Kryptographie. Er missbraucht den Geräteregistrierungsablauf, der bestimmt, wer den synchronisierten Tresor lesen kann.
• Die Google-Passwortmanager-PIN ist ein Tresor-Zugangsgeheimnis. Google verwendet die PIN zum Schutz verschlüsselter Anmeldedaten. Behandeln Sie sie entsprechend — nicht als belanglosen Code.
• Eine abgefangene PIN kann den gesamten Tresor offenlegen. Die Demonstration von PhishU zeigt, dass eine einzige PIN-Eingabe einem Angreifer ermöglichen kann, jedes synchronisierte Passwort und jeden Passkey auf einer vom Angreifer kontrollierten Infrastruktur zu entschlüsseln.
• Das Unternehmensrisiko skaliert mit Governance-Lücken. Die Vermischung von persönlichen und beruflichen Profilen, nicht verwaltete Chrome-Profile und privilegierte Anmeldedaten in Browser-Tresoren erhöhen den Schadensradius.
• Die Incident Response muss über einen Passwortwechsel hinausgehen. Ein vermutetes VaultJacking-Ereignis erfordert die Überprüfung von Geräten, Sitzungen, Passkeys, Tresorinhalten und nachgelagerten Logins — nicht nur das Ändern eines Passworts.

Was ist VaultJacking?

VaultJacking ist eine Phishing-Technik, die auf den Tresor-Zugang und die Wiederherstellungserfahrung des Google Passwortmanagers abzielt. Anstatt eine einzelne Website-Anmeldung zu stehlen, fängt der Angreifer die Google-Passwortmanager-PIN während einer AiTM-Phishing-Sitzung ab und verwendet sie, um ein vom Angreifer kontrolliertes Gerät in die Google-Sicherheitsdomäne des Opfers einzuschreiben. Dadurch erhält er Zugang zum gesamten synchronisierten Anmeldedaten-Tresor. Der Begriff und die End-to-End-Demonstration stammen aus der veröffentlichten Forschung von PhishU.

Traditionelles Credential-Phishing zielt auf ein Konto nach dem anderen. VaultJacking ist eine andere Angriffsklasse: Der Angreifer umgeht einzelne Anmeldedaten vollständig und greift direkt auf das Repository zu, das alle enthält.

Die Forschung von PhishU beschreibt den Angriff als vollständig konsistent mit Standard-AiTM-Phishing. Der AiTM-Proxy fängt die PIN zusammen mit Session-Cookies ab. Ein Hintergrundprozess fügt dann einen Passkey des Angreifers zum Google-Konto des Opfers für Persistenz hinzu, tritt der Sicherheitsdomäne von der Angreifer-Infrastruktur aus mit der abgefangenen PIN bei und entschlüsselt den gesamten Tresor. Der Betreiber sieht alle synchronisierten Anmeldedaten in einer einzigen Ansicht.

Browser Syncjacking, eine separate Technik, auf die PhishU verweist, erreicht dieselbe Google-Sync-Ebene über eine bösartige Browser-Erweiterung. VaultJacking erfordert weder einen Geräte-Zugang noch eine Erweiterung.

Was ist die Google-Passwortmanager-PIN?

Die Google-Passwortmanager-PIN ist ein separates Geheimnis, das sich von Ihrem Google-Kontopasswort und Ihrer Geräte-Bildschirmsperre unterscheidet. Googles Dokumentation beschreibt sie als eine Möglichkeit, verschlüsselte Google-Passwortmanager-Daten zu schützen, Passkeys auf einem neuen Gerät zu verwenden und die Identität zu verifizieren.

Benutzer verwechseln häufig drei verschiedene Geheimnisse, und diese Verwirrung ist Teil dessen, was VaultJacking so effektiv macht:

Die Aufforderung zur Eingabe der Google-Passwortmanager-PIN erscheint beim Erstellen Ihres ersten Passkeys auf einem neuen Gerät, beim Zugriff auf verschlüsselte gespeicherte Anmeldedaten in bestimmten Wiederherstellungskontexten oder wenn ein neues Gerät Ihrer Google-Sicherheitsdomäne beitritt. Das letzte Szenario ist genau das, was VaultJacking ausnutzt.

Der strukturelle Grund, warum dies funktioniert, liegt laut der Analyse von PhishU des Chromium-Quellcodes (chrome/browser/webauthn/enclave_manager.cc und components/trusted_vault/) darin, dass Googles Sicherheitsdomänen-Beitrittsablauf zwei Prüfungen erfordert: eine Google-Kontoanmeldung und eine erfolgreiche PIN-Eingabe. Es gibt keine geräteübergreifende Genehmigungsaufforderung, keine Push-Benachrichtigung an bestehende Geräte, keine „Von einem anderen Gerät genehmigen"-Bestätigung.

Apples iCloud-Schlüsselbund erfordert, dass bestehende Geräte neue genehmigen. Googles Modell nicht. Google hat einen bewussten UX-Kompromiss getroffen: Eine PIN mit einem serverseitigen Wiederholungslimit ist einfacher zu handhaben als ein Push-to-Approve-Modell, wenn ein Benutzer alle seine Geräte verloren hat. VaultJacking ist die Konsequenz dieses Kompromisses.

Wie die VaultJacking-Angriffskette funktioniert

Das Folgende beschreibt den Angriff konzeptionell für Verteidigungszwecke. Es sind keine offensiven Implementierungsdetails enthalten.

1. Köder. Das Opfer erhält einen Phishing-Link und landet auf einer Seite, die einen legitimen Google-Anmelde- oder Kontoablauf imitiert. Behandeln Sie jeden unerwarteten Anmeldeablauf, der per E-Mail, Chat oder Werbelink ankommt, mit Misstrauen.
2. Vertrauenstransfer. Der AiTM-Proxy rendert eine PIN-Aufforderung, die dem Stil von Googles eigener Oberfläche entspricht: gleiche Schriftart, gleiche sechs-Zellen-Eingabe, gleicher Text. Die Benutzerschulung muss Passwortmanager-PIN-Aufforderungen abdecken, nicht nur Passwörter und OTP-Codes.
3. PIN-Abfang. Das Opfer gibt die PIN in den Phishing-Ablauf ein. Die PIN ist ein Tresor-Zugangsgeheimnis, das in seiner Sensibilität einem Masterpasswort entspricht.
4. Angreifer-Geräteregistrierung. Der Angreifer verwendet die abgefangene PIN, um der Google-Sicherheitsdomäne des Opfers von einer vom Angreifer kontrollierten Infrastruktur aus beizutreten. Ein Passkey des Angreifers wird ebenfalls für Persistenz registriert. Überprüfen Sie angemeldete Geräte und registrierte Passkeys sofort nach jedem vermuteten Phishing-Kontakt.
5. Tresor-Entschlüsselung. Das Security Domain Secret wird von Googles Cloud-Authenticator freigegeben, und das Gerät des Angreifers entschlüsselt jedes synchronisierte Passwort und jeden Passkey. Der Tresor kann Anmeldedaten für E-Mail, SSO, Cloud-Konsolen, Finanzplattformen und Code-Repositories enthalten.
6. Nachgelagerte Kompromittierung. Gespeicherte Drittanbieter-Anmeldedaten werden gegen andere Dienste verwendet. Rotieren Sie hochwertige Anmeldedaten und überwachen Sie Drittanbieter-Logins.

PhishU hat dies End-to-End gegen Live-Google-Passwortmanager-Konten getestet, einschließlich der Wiedergabe von abgefangenen Drittanbieter-Passkeys, unabhängig davon, ob die ursprünglichen Anmeldedaten hardwaregestützt waren. Behandeln Sie dies als eine demonstrierte Technik. Es gibt zum Zeitpunkt des Schreibens keine öffentlichen Beweise für eine weit verbreitete aktive Ausnutzung, aber die Technik erfordert keinen spezialisierten Zugang oder Geräte-Zugriff.

Bedeutet VaultJacking, dass Passkeys unsicher sind?

Nein. VaultJacking bricht nicht die Passkey-Kryptographie. Passkeys basieren auf ursprungsgebundener Public-Key-Authentifizierung, wie in der W3C WebAuthn-Spezifikation definiert: Der private Schlüssel verlässt niemals das Gerät, und die Authentifizierungszeremonie ist an den legitimen Website-Ursprung gebunden. Eine Phishing-Seite kann eine WebAuthn-Assertion nicht gegen die echte Website wiedergeben, weil die Ursprungsprüfung fehlschlägt. Dieser Schutz bleibt bestehen.

Was VaultJacking demonstriert, ist, dass Passkeys nicht isoliert existieren. Sie existieren in einem Tresor, der über Geräte synchronisiert wird, der auf einem Wiederherstellungsmechanismus basiert, der durch eine PIN gesteuert wird. Der Angreifer umgeht die kryptographische Zeremonie vollständig, indem er stattdessen auf die Tresor-Verwaltungsebene abzielt.

Google beschreibt Passkeys als eine Möglichkeit, sich mit Fingerabdruck, Gesichtserkennung oder Bildschirmsperre anzumelden — einfacher und sicherer als Passwörter. Diese Beschreibung ist auf der Ebene der Einzelsite-Authentifizierung korrekt. Das Problem, das VaultJacking aufzeigt, liegt eine Ebene höher: Was steuert den Zugang zum Speicher, der diese Passkeys enthält.

Warum eine PIN einen großen Schadensradius erzeugen kann

Ein Passwortmanager-Tresor ist ein konzentrierter Speicher für Zugang. Eine abgefangene PIN legt alle Anmeldedaten offen, die das Opfer jemals im Google Passwortmanager gespeichert hat.

Der Identity Threat Landscape Report 2025 von Recorded Future stellte fest, dass das durchschnittliche kompromittierte Gerät 87 gestohlene Anmeldedaten ergab und dass 276 Millionen der 2025 indexierten Anmeldedaten aktive Session-Cookies enthielten — was bedeutet, dass Angreifer MFA für diese Konten vollständig umgehen konnten.

Verizons DBIR 2026 setzt die nachgelagerten Auswirkungen in einen Kontext: Der Missbrauch von Anmeldedaten erscheint irgendwann in 39 % aller bestätigten Sicherheitsverletzungen, über mehr als 22.000 Vorfälle in 145 Ländern hinweg. Angreifer bleiben selten bei der ersten Tür stehen, die gestohlene Anmeldedaten öffnen. Sie bewegen sich lateral, eskalieren Privilegien und arbeiten sich durch jeden gespeicherten Login, bis sie etwas Wertvolles finden.

Wer ist am stärksten gefährdet?

Das Risiko konzentriert sich dort, wo drei Bedingungen zusammentreffen: Browser-Tresor-Daten sind der primäre Anmeldedatenspeicher, Arbeits- und persönliche Anmeldedaten teilen ein Profil, und privilegierte Anmeldedaten sind in einem Consumer-System gelandet.

1. Das Problem der Vermischung von Anmeldedaten. Mitarbeiter speichern Arbeits-Anmeldedaten in persönlichen Chrome-Profilen. Administratoren haben keine Sichtbarkeit oder Kontrolle über Tresorinhalte oder synchronisierte Geräte. Dies bedeutet, dass Unternehmenspasswörter außerhalb des Sicherheitsperimeters leben, auf Googles Servern gesichert werden und von jedem Gerät aus zugänglich sind, bei dem sich der Mitarbeiter jemals angemeldet hat.
2. Privilegierte Benutzer sind das hochwertigste Ziel. Im Google Passwortmanager gespeicherte Admin-Passwörter stellen die gefährlichste Risikokonzentration dar. Eine Tresor-Kompromittierung legt die Schlüssel zu Identitätsplattformen, Cloud-Infrastruktur, Finanzsystemen und Sicherheits-Tools offen. Ein einziges kompromittiertes Admin-Konto wird zum Drehpunkt für laterale Bewegung in der gesamten Organisation.
3. Sicherheitstraining deckt diese Angriffsfläche nicht ab. Security-Awareness-Programme lehren Benutzer, Phishing-E-Mails zu erkennen und OTP-Codes zu schützen. Sie lehren Benutzer nicht, Passwortmanager-PIN-Aufforderungen als sensible Ziele zu erkennen. Benutzer sehen eine PIN-Anfrage und kommen ihr nach — sie sehen es nicht als ein Sicherheitsereignis, das Skepsis auslösen sollte.
4. Richtlinienlücken lassen Anmeldedaten am falschen Ort. Die meisten Organisationen haben keine Richtlinie, die Browser-Tresore von der Unternehmens-Anmeldedatenverwaltung trennt. Geteilte Anmeldedaten, Admin-Passwörter und Break-Glass-Konten werden möglicherweise dort gespeichert, wo es Mitarbeitern bequem erscheint. Es existiert kein Audit-Trail, der zeigt, wo diese Anmeldedaten liegen oder wer darauf zugegriffen hat.
5. Geräte- und Sitzungsüberprüfungsprozesse sind zu langsam. Verdächtige Geräteregistrierungen oder Tresorzugriffe können wochenlang unbemerkt bleiben.

Der letzte Punkt ist wichtiger, als es erscheinen mag. PhishU merkt an, dass Google eine einzige E-Mail „Neue Anmeldung unter Windows" sendet, wenn ein neues Gerät der Sicherheitsdomäne beitritt — dieselbe Benachrichtigung, die für jede neue Chrome-Anmeldung gesendet wird. Auf bestehenden Geräten wird keine Push-Benachrichtigung ausgelöst. In einem AiTM-Angriff, bei dem der Angreifer auch die Posteingangs-Sitzung des Opfers abgefangen hat, kann diese E-Mail unterdrückt werden, bevor der Benutzer sie sieht.

Was zu tun ist, wenn eine Google-Passwortmanager-PIN möglicherweise gephisht wurde

Behandeln Sie ein vermutetes VaultJacking-Ereignis nicht als Einzelpasswort-Vorfall. Behandeln Sie es als mögliche Tresor-Exposition, bis das Gegenteil bewiesen ist.

Die folgende Triage-Sequenz richtet sich an Sicherheitsteams und Einzelpersonen. Google-Workspace-Ereignisnamen sollten anhand der aktuellen Google-Admin-Dokumentation überprüft werden, bevor eine automatisierte Erkennung erstellt wird.

Die Schritte 5 und 7 sind dort, wo die meisten Incident Responses zu kurz greifen. Das Google-Kontopasswort zu rotieren, ohne die nachgelagerten Anmeldedaten zu rotieren, die es schützt, ist wie das Schloss an einem Safe zu wechseln, nachdem der Inhalt bereits fotografiert wurde.

Passwork gibt Ihnen Einblick in alle Anmeldedaten, wer darauf zugegriffen hat und wann. Rollenbasierter Zugriff bedeutet, dass geteilte Anmeldedaten an einem Ort mit vollständigem Audit-Trail bleiben — nicht über persönliche Browser-Profile verstreut. Erfahren Sie, wie es funktioniert

Wie Einzelpersonen das VaultJacking-Risiko reduzieren können

Der praktische Rat hier ist kurz. Das meiste läuft darauf hinaus, die Google-Passwortmanager-PIN genauso zu behandeln wie ein Masterpasswort.

• Geben Sie die Google-Passwortmanager-PIN nicht auf einer Seite ein, die Sie durch Klicken auf einen Link in einer E-Mail, einem Chat oder einer Werbung erreicht haben. Navigieren Sie direkt zu den Google-Kontoeinstellungen.
• Überprüfen Sie Ihre angemeldeten Geräte und registrierten Passkeys unter myaccount.google.com regelmäßig. Ein unbekanntes Gerät oder ein unbekannter Passkey ist eine Untersuchung wert.
• Halten Sie persönliche und berufliche Browser-Profile getrennt. Wenn ein persönliches Profil kompromittiert wird, sollten Arbeits-Anmeldedaten nicht im Schadensradius sein.
• Vermeiden Sie das Speichern hochsensibler Admin- oder privilegierter Anmeldedaten in einem Consumer-Browser-Tresor. Diese Anmeldedaten benötigen Auditierbarkeit und Zugriffskontrollen, die Browser-Tresore nicht bieten.
• Verwenden Sie weiterhin Passkeys. Sie bleiben auf der Einzelsite-Ebene sicherer als wiederverwendbare Passwörter. Verstehen Sie nur, welche Aufforderungen legitim sind und welche nicht.

Unternehmenskontrollen und Richtlinienempfehlungen

Oktas Secure Sign-in Trends Report 2025 stellte fest, dass die Einführung von phishing-resistenten Authentifikatoren in einem Jahr von 8,6 % auf 14,0 % der Benutzer wuchs — ein Anstieg von 63 %. Dieses Wachstum ist eine gute Nachricht. Das Governance-Problem ist, dass Organisationen Passkeys schneller einführen, als sie die Richtlinien zur Verwaltung der Tresore aufbauen, die sie speichern.

Die folgenden Kontrollen sind proportional zur Sensibilität der beteiligten Anmeldedaten. Nicht jede Organisation benötigt jede Kontrolle, aber jede Organisation, die privilegierte Anmeldedaten in Browser-Tresoren speichert, benötigt eine Richtlinie, die dies speziell adressiert.

• Browser-Profil-Governance. Erzwingen Sie separate verwaltete Arbeitsprofile. Entmutigen Sie die Vermischung von persönlichen und Arbeits-Tresoren durch Richtlinien und Benutzerschulung.
• Speicherung privilegierter Anmeldedaten. Verbieten Sie das Speichern von Admin-, Break-Glass-, Cloud-Root-, Finanz- und Service-Account-Anmeldedaten in nicht verwalteten Browser-Tresoren. Browser-Tresore sind bequem für die persönliche Nutzung. Sie sind nicht für geteilte Anmeldedaten, privilegierten Zugang oder Audit-Trails konzipiert.
• Enterprise-Passwort-Management. Verwenden Sie einen dedizierten Enterprise-Passwortmanager für geteilte, privilegierte und auditierte Anmeldedaten. Passwork ist eine selbst gehostete Lösung, die genau für diese Trennung entwickelt wurde: privilegierte Anmeldedaten in einem kontrollierten, auditierbaren Tresor mit rollenbasierter Zugriffskontrolle, AD/LDAP-Integration und vollständigem Audit-Log.
• Phishing-resistente MFA. Setzen Sie die Einführung von WebAuthn und FIDO2 fort. Erweitern Sie die Benutzerschulung auf Wiederherstellungsabläufe und Tresor-Aufforderungen, nicht nur auf Passwörter und OTP-Codes.
• Geräte- und Sitzungssichtbarkeit. Überwachen Sie auf unbekannte Geräteregistrierungen, ungewöhnliche Sitzungsaktivitäten und unerwartete Kontosicherheitsänderungen. Google sendet eine „Neue Anmeldung"-E-Mail für jede neue Chrome-Anmeldung. In einem AiTM-Angriff, bei dem der Angreifer auch die Posteingangs-Sitzung des Opfers abgefangen hat, kann diese E-Mail unterdrückt werden, bevor der Benutzer sie sieht.
• Incident Response. Erstellen Sie ein Tresor-Expositions-Runbook, das Anmeldedaten-Rotation, Sitzungswiderruf, Passkey-Überprüfung und Drittanbieter-Kontoüberwachung umfasst.
• Security Awareness. Schulen Sie Benutzer, dass PINs, Passwortmanager-Aufforderungen und Wiederherstellungsabläufe Phishing-Ziele sind. Sie tragen dasselbe Risiko wie Passwörter und OTP-Codes.

Der Punkt zum Enterprise-Passwortmanager verdient Betonung. Browser-Tresore sind bequem und verbessern die Passwort-Einzigartigkeit für viele Benutzer. Sie sind nicht für geteilte Anmeldedaten, privilegierten Zugang oder Audit-Trails konzipiert.

Warum ein Enterprise-Passwortmanager sicherer ist als ein Browser-Tresor für Arbeits-Anmeldedaten

Ein Browser-Passwortmanager löst ein persönliches Komfortproblem: Autofill, Gerätesynchronisation, mühelose Speicherung. Für einen einzelnen Benutzer ist das eine vernünftige Wahl. Für eine Unternehmensumgebung wird dieselbe Einfachheit zu einer strukturellen Schwachstelle.

Passwork ist die Enterprise-Alternative zu persönlichen Browser-Tresoren. Die Passwork-Browser-Erweiterung funktioniert genau wie ein integrierter Browser-Passwortmanager — sie füllt Logins auf Websites automatisch aus, bietet an, neue Anmeldedaten zu speichern — speichert sie aber in einem geschützten Unternehmens-Tresor anstatt in einem persönlichen Browser-Profil.

Passwork unterstützt selbst gehostete Bereitstellung, AES-256-Verschlüsselung, Active Directory- und LDAP-Integration, SSO-Autorisierung, rollenbasierte Zugriffskontrolle, vollständiges Audit-Logging, SIEM-Integration sowie REST API- und CLI-Tools für DevOps-Workflows.

Der Unterschied ist architektonisch. Ein Browser-Tresor priorisiert individuellen Komfort. Ein Enterprise-Passwortmanager priorisiert organisatorische Kontrolle und Sichtbarkeit. Wenn privilegierte Anmeldedaten in einem Browser-Tresor landen, wurde das falsche Werkzeug für die Aufgabe gewählt — nicht weil das Werkzeug schlecht ist, sondern weil es für ein anderes Problem konzipiert wurde.

Fazit: Was gegen VaultJacking zu tun ist

Die Bedrohung, die VaultJacking beschreibt, ist spezifisch: eine Phishing-Technik, die eine abgefangene PIN in tresorweite Anmeldedaten-Exposition verwandelt. Die Reaktion sollte ebenso spezifisch sein — keine Panik über Passkeys und keine Verharmlosung des Browser-Tresor-Risikos, sondern eine klare Richtlinie, die persönlichen Anmeldedaten-Komfort von privilegierter Anmeldedaten-Governance trennt.

Beginnen Sie mit dem Audit. Finden Sie heraus, welche privilegierten Anmeldedaten derzeit in Browser-Tresoren liegen. Welche Admin-Konten sind mit persönlichen Geräten synchronisiert? Welche Break-Glass-Anmeldedaten sind im Google Passwortmanager gespeichert? Diese Antwort wird Ihnen sagen, wie viel Arbeit noch zu tun ist.

Von dort aus ist der Weg klar: Verbieten Sie privilegierte Anmeldedaten in Browser-Tresoren, verschieben Sie sie in einen Enterprise-Passwortmanager mit Audit-Trails und Zugriffskontrollen, und erweitern Sie Ihr Security-Awareness-Training auf Tresor-Aufforderungen und Wiederherstellungsabläufe.

VaultJacking ist kein Grund, Browser-Passwortmanager aufzugeben. Es ist ein Grund, sie für das zu verwenden, wofür sie konzipiert wurden — persönliche Anmeldedaten — und ein separates, auditierbares System für alles andere aufzubauen.

Passwork ist ein selbst gehosteter Enterprise-Passwort- und Secrets-Manager, der für privilegierte Anmeldedaten-Governance entwickelt wurde. Er bietet rollenbasierten Zugriff, vollständige Audit-Logs und vollständige Trennung von Consumer-Browser-Tresoren. Erfahren Sie, wie er in Ihre Infrastruktur passt

Häufig gestellte Fragen

Was ist VaultJacking?

VaultJacking ist eine Phishing-Technik, die auf den Tresor des Google Passwortmanagers abzielt, indem sie die Google-Passwortmanager-PIN des Benutzers während einer Adversary-in-the-Middle-Phishing-Sitzung abfängt. Die abgefangene PIN wird verwendet, um ein vom Angreifer kontrolliertes Gerät in die Google-Sicherheitsdomäne des Opfers einzuschreiben, wodurch jedes synchronisierte Passwort und jeder Passkey im Tresor entschlüsselt wird. Die Technik wurde im Mai 2026 End-to-End von PhishU demonstriert.

Ist VaultJacking eine Google-Schwachstelle?

Basierend auf veröffentlichten Berichten ist VaultJacking eine demonstrierte Phishing- und Workflow-Missbrauchstechnik, keine klassifizierte Schwachstelle in Googles Systemen. Sie nutzt das Design von Googles Geräteregistrierungsablauf aus — insbesondere das Fehlen einer geräteübergreifenden Genehmigung für neue Sicherheitsdomänen-Beitritte — was Google bewusst als UX-Kompromiss für die Wiederherstellung bei verlorenem Gerät gewählt hat. Ob Google dies als Schwachstelle klassifiziert, die eine Behebung erfordert, ist eine separate Frage, die zum Zeitpunkt des Schreibens nicht öffentlich beantwortet wurde.

Bricht VaultJacking Passkeys?

Nein. Passkeys basieren auf ursprungsgebundener Public-Key-Kryptographie, wie in der W3C WebAuthn-Spezifikation definiert. Eine Phishing-Seite kann eine WebAuthn-Assertion nicht gegen die echte Website wiedergeben, weil die Ursprungsbindung fehlschlägt. VaultJacking zielt auf den Tresor und die Wiederherstellungsebene ab, die Passkeys speichert — nicht auf die kryptographische Authentifizierungszeremonie selbst. Passkeys bleiben auf der Einzelsite-Login-Ebene phishing-resistent.

Was ist die Google-Passwortmanager-PIN?

Die Google-Passwortmanager-PIN ist ein Geheimnis, das verschlüsselte Google-Passwortmanager-Daten schützt. Laut Googles Dokumentation wird sie erstellt, wenn ein Benutzer seinen ersten Passkey auf einem Computer, iPhone oder iPad speichert, und sie wird verwendet, um auf Passkeys auf neuen Geräten zuzugreifen, die Identität zu verifizieren und sicherzustellen, dass nicht einmal Google den verschlüsselten Tresorinhalt lesen kann. Sie unterscheidet sich vom Google-Kontopasswort und von der Geräte-Bildschirmsperre.

Kann eine PIN alle meine gespeicherten Passwörter offenlegen?

Die Demonstration von PhishU zeigt, dass eine abgefangene sechsstellige Google-Passwortmanager-PIN einem Angreifer ermöglichen kann, den gesamten synchronisierten Tresor zu entschlüsseln — jedes gespeicherte Passwort und jeden synchronisierten Passkey — von einer vom Angreifer kontrollierten Infrastruktur aus. Die PIN gibt das Security Domain Secret frei, das den Tresor in einer einzigen Operation entschlüsselt. Wenn Sie die PIN auf einer Seite eingegeben haben, zu der Sie nicht direkt navigiert sind, behandeln Sie dies als mögliche vollständige Tresor-Exposition.

Was sollte ich tun, wenn ich die PIN auf einer verdächtigen Seite eingegeben habe?

Überprüfen Sie sofort Ihre angemeldeten Geräte und registrierten Passkeys unter myaccount.google.com. Widerrufen Sie alle unbekannten Geräte oder Sitzungen. Ändern Sie Ihr Google-Kontopasswort. Rotieren Sie hochwertige Anmeldedaten, die im Tresor gespeichert sind — priorisieren Sie SSO, E-Mail, Cloud-Konsolen, Finanzplattformen und Admin-Konten. Überprüfen Sie Drittanbieterdienste auf ungewöhnliche Login-Aktivitäten. Wenn Sie in einer Organisation sind, eröffnen Sie einen Incident-Response-Fall, anstatt dies als Einzelkonto-Problem zu behandeln.

Sollten Unternehmen den Google Passwortmanager verbieten?

Ein pauschales Verbot ist für die meisten Organisationen nicht die richtige Richtlinie. Ein risikobasierter Ansatz funktioniert besser: Beschränken Sie die Speicherung privilegierter und geteilter Anmeldedaten auf einen Enterprise-Passwortmanager mit Audit-Kontrollen, erzwingen Sie separate verwaltete Browser-Profile für die Arbeit und erweitern Sie das Phishing-Awareness-Training auf Passwortmanager-Aufforderungen und Wiederherstellungsabläufe. Der Google Passwortmanager ist für persönliche Anmeldedaten geeignet; er ist nicht für Break-Glass-Konten oder geteilten Admin-Zugang konzipiert.

Reichen Hardware-Sicherheitsschlüssel aus, um dies zu stoppen?

Hardware-Sicherheitsschlüssel stärken die Sicherheitsgarantie bei der Google-Kontoanmeldung, aber sie steuern nicht automatisch die Browser-Tresor-Synchronisation, Wiederherstellungsabläufe oder die im Tresor gespeicherten Anmeldedaten. VaultJacking zielt auf die Tresor-Verwaltungsebene ab, nicht auf den Kontoanmeldeschritt. Ein Hardware-Schlüssel für das Google-Konto reduziert das Risiko einer Kontoübernahme, verhindert aber nicht, dass ein Benutzer dazu verleitet wird, seine Google-Passwortmanager-PIN auf einer Phishing-Seite einzugeben.

Passwort- und Zugangsverwaltung für KMUs: Reicht KeePass aus?

Verwenden Sie KeePass für Ihr Team? Entdecken Sie die versteckten Risiken von KeePass für KMUs im Jahr 2026 — Synchronisierungsfehler, Compliance-Lücken und wann Sie zu einem Unternehmens-Passwortmanager wechseln sollten.

Passwork BlogAlex Muntyan

Passwork gewinnt Top Performer Frühling 2026 auf SourceForge

Passwork wurde von SourceForge als Top Performer Frühling 2026 ausgezeichnet und gehört zu den besten 10 % von über 100.000 Lösungen. Die Auszeichnung basiert ausschließlich auf verifizierten Bewertungen — 4,8 Sterne insgesamt, mit einer perfekten 5,0 für Support.

Passwork BlogAlex Muntyan

Secrets-Rotations-Lebenszyklus: Von der Erstellung bis zum Widerruf

Secret-Rotation scheitert, wenn sie als geplante Aufgabe statt als Lebenszyklus behandelt wird. Dieser Leitfaden behandelt alle sieben Phasen — von Erstellung und Besitz bis hin zu sicherer Rotation, Notfall-Widerruf und Audit-Nachweisen.

Passwork BlogAlex Muntyan