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

Bulgariens NIS2-Übergangsfrist endete am 1. Juni 2026 — Vorstandsmitglieder sind nun mit vollen persönlichen Bußgeldern konfrontiert, nicht mehr mit dem ermäßigten Satz von 50 %, der bis Mai galt. Luxemburgs NIS2-Richtlinien-Umsetzungsgesetz trat am 10. Mai 2026 in Kraft, womit vier Mitgliedstaaten noch ohne Umsetzungsgesetzgebung verbleiben. Die NIS-Kooperationsgruppe der EU hat gemeinsame Vorlagen für die Vorfallmeldung verabschiedet, die die Kommission durch einen Durchführungsrechtsakt verbindlich machen will.

Dieser Artikel behandelt alle wesentlichen NIS2-Updates vom Mai 2026: was sich geändert hat, welche Fristen aktuell gelten und worauf Ihr Team jetzt reagieren muss.

Wichtigste Erkenntnisse

Diese NIS2-Updates vom Mai 2026 bringen konkrete Compliance-Auslöser mit sich: spezifische Daten und spezifische Verpflichtungen. Hier ist, was sich geändert hat.

• Bulgariens vollständiges Sanktionsregime ist aktiv. Ab dem 1. Juni 2026 gelten persönliche Bußgelder für Mitglieder von Leitungsorganen zu 100 % der gesetzlichen Beträge — bis zu 5.000 € pro Person, getrennt von Bußgeldern auf Unternehmensebene von bis zu 10 Millionen €. Der 50 %-Übergangsrabatt ist entfallen.
• Luxemburgs NIS2-Gesetz trat am 10. Mai 2026 in Kraft. Betroffene Einrichtungen haben bis zum 10. Juli 2026 Zeit, sich beim ILR selbst zu registrieren. Eine Nichtregistrierung stellt bereits einen sanktionsfähigen Verstoß dar.
• Vier EU-Mitgliedstaaten haben NIS2 noch nicht umgesetzt — mehr als 19 Monate nach der Frist vom Oktober 2024, laut dem Tracker von Cullen International vom Mai 2026.
• Gemeinsame Vorlagen für die Vorfallmeldung wurden EU-weit verabschiedet. Die NIS-Kooperationsgruppe einigte sich auf standardisierte Formate bei ihrer 39. Plenarsitzung in Zypern am 26. Mai 2026. Ein Durchführungsrechtsakt der Kommission wird diese verbindlich machen.
• Der NIS360 2026-Bericht von ENISA identifiziert acht Risikosektoren. Gesundheit, Eisenbahn, Seefahrt, ICT-Dienstleistungsmanagement, Raumfahrt, öffentliche Verwaltung, Trinkwasser und Abwasser weisen die niedrigste Cybersicherheitsreife im Verhältnis zu ihrer Kritikalität auf.
• Die Niederlande haben ihr verzögertes Cyberbeveiligingswet vorangebracht. Die niederländische Zweite Kammer stimmte dem Gesetzentwurf am 15. April 2026 zu; die Zustimmung des Senats steht noch aus.
• Irland bestätigte das National Cyber Security Bill als NIS2-Vehikel. Das Justizministerium erarbeitet die Gesetzgebung und verleiht dem NCSC eine gesetzliche Grundlage.
• DigitalEurope forderte eine tiefere NIS2-Harmonisierung. Der Branchenverband veröffentlichte eine formelle Stellungnahme, die Anwendungsbereich, Größenschwellen, Vorfallmeldung und Konformitätsbewertung als die Bereiche mit dem größten Standardisierungsbedarf über die Mitgliedstaaten hinweg identifiziert.

Bulgariens vollständige Durchsetzungsphase begann am 1. Juni 2026

Bulgariens NIS2-Durchsetzung ist am 1. Juni 2026 in ihre finale Phase eingetreten. Bußgelder und Sanktionen für alle Verstöße gelten nun in voller gesetzlicher Höhe — die 50 %-Ermäßigung für Verstöße vor diesem Datum ist entfallen.

Die zugrundeliegende Gesetzgebung ist das Gesetz zur Änderung und Ergänzung des Cybersicherheitsgesetzes, das von der 51. Nationalversammlung am 5. Februar 2026 verabschiedet und im Staatsanzeiger (Ausgabe 17) am 13. Februar 2026 verkündet wurde und am selben Tag in Kraft trat.

Wer ist betroffen

Das Cybersicherheitsgesetz erfasst öffentliche und private Einrichtungen in den Sektoren nach Anhang I und Anhang II, die die Schwellenwerte für mittlere Unternehmen erreichen oder überschreiten. Bestimmte Anbieter fallen unabhängig von ihrer Größe in den Anwendungsbereich: öffentliche elektronische Kommunikationsnetze, Vertrauensdiensteanbieter, Top-Level-Domain-Registrierungsstellen, DNS-Diensteanbieter, Einrichtungen, die der einzige Anbieter eines kritischen Dienstes in Bulgarien sind, oder deren Ausfall die öffentliche Ordnung, öffentliche Sicherheit oder Gesundheit oder die Wirtschaft erheblich beeinträchtigen würde.

Verwaltungsbehörden (einschließlich Gemeinden) werden gemäß Artikel 4a(1)(4) unabhängig von ihrer Größe als wesentliche Einrichtungen eingestuft.

Vollständige Durchsetzung ohne vollständiges Regelwerk

Eine praktische Komplikation bleibt bestehen. Das Gesetz delegiert die Definition von Mindestmaßnahmen für Cybersicherheit für bestimmte Einrichtungskategorien ausdrücklich an eine Sekundärverordnung des Ministerrats, die gemeinsam von der Kommission für Kommunikationsregulierung und dem Minister für E-Governance vorgeschlagen werden soll. Diese Verordnung wurde noch nicht veröffentlicht. Organisationen traten in die vollständige Durchsetzungsphase ein, ohne das vollständige operative Regelwerk, das das Gesetz selbst vorgesehen hatte.

Das setzt die Verpflichtungen nicht aus. Das Primärgesetz ist in Kraft, Sanktionen sind real. Eine Gap-Analyse gegen das bestehende NIS2-Framework ist jetzt sowohl möglich als auch ratsam, bevor der aufsichtliche Druck zunimmt. ISO/IEC 27001 und ISO 22301 bieten eine praktikable Grundlage neben den Anforderungen des Cybersicherheitsgesetzes.

Was Leitungsorgane nun nachweisen müssen

Bulgariens Cybersicherheitsgesetz legt eine ausdrückliche persönliche Verantwortlichkeit auf einzelne Mitglieder von Leitungsorganen, nicht nur auf die Organisation als juristische Person. Leitungsorgane müssen:

• Die nach Artikel 21 erforderlichen Maßnahmen zum Cybersicherheits-Risikomanagement formell genehmigen
• Die Umsetzung dieser Maßnahmen überwachen
• Mindestens alle zwei Jahre eine Cybersicherheitsschulung absolvieren
• Regelmäßig gleichwertige Schulungen für Mitarbeiter organisieren

Die Maßnahmen, die Vorstände genehmigen müssen, umfassen Risikoanalyse und Informationssicherheitsrichtlinien, Vorfallbehandlung, Geschäftskontinuität und Krisenmanagement, Lieferkettensicherheit, Cyberhygiene-Praktiken und Multi-Faktor-Authentifizierung, wo angemessen.

Die Struktur persönlicher Bußgelder

Wenn ein Mitglied des Leitungsorgans einer wesentlichen oder wichtigen Einrichtung gegen diese Governance-Pflichten verstößt, kann ein persönliches Bußgeld von 500 € bis 5.000 € verhängt werden. Dies ist getrennt von Sanktionen auf Unternehmensebene und kumuliert sich zu diesen: bis zu 10 Millionen € oder 2 % des weltweiten Umsatzes für wesentliche Einrichtungen und bis zu 7 Millionen € oder 1,4 % für wichtige Einrichtungen.

Die zuständige nationale Behörde kann auch bei Gericht beantragen, dass einer natürlichen Person vorübergehend die Ausübung von Leitungsfunktionen in einer wesentlichen Einrichtung untersagt wird.

Die praktische Konsequenz: Ein Vorstandsmitglied kann sich nicht durch Delegation aus der Haftung befreien. Ob ein Bußgeld verhängt wird und wie schwer es ausfällt, hängt von der Fähigkeit der Person ab, konkrete Handlungen nachzuweisen — Vorstandsbeschlüsse, verabschiedete Richtlinien, Auditprotokolle, zugewiesene Verantwortlichkeiten, absolvierte Schulungen und dokumentierte Korrekturmaßnahmen.

EU-weit: Gemeinsame Vorlagen für die Vorfallmeldung verabschiedet

Am 26. Mai 2026 verabschiedete die NIS-Kooperationsgruppe bei ihrer 39. Plenarsitzung in Zypern gemeinsame Vorlagen für die NIS2-Vorfallmeldung. Die Gruppe bringt EU-Mitgliedstaaten, die Europäische Kommission und ENISA zusammen.

Die Vorlagen bieten ein standardisiertes Format für die Meldung von Cybervorfällen in der gesamten EU. Bis jetzt bedeutete das Fehlen eines gemeinsamen Formats, dass Organisationen, die in mehreren Mitgliedstaaten tätig sind, mit unterschiedlichen nationalen Meldeformularen, Feldsätzen und Einreichungsportalen umgehen mussten — eine erhebliche administrative Belastung für jeden grenzüberschreitenden Betrieb.

Die Kommission hat erklärt, dass sie plant, diese Vorlagen durch einen Durchführungsrechtsakt zu verabschieden, wodurch sie für alle Mitgliedstaaten verbindlich würden. Sobald dieser Rechtsakt in Kraft ist, werden die Vorlagen einen einheitlichen Rahmen für die Vorfallmeldung in der gesamten EU etablieren.

Diese Entwicklung steht auch im Zusammenhang mit dem breiteren Digital-Omnibus-Vorschlag, der einen einzigen Zugangspunkt für die Vorfallmeldung vorsieht. Die gemeinsamen Vorlagen sind darauf ausgelegt, mit dieser zukünftigen Architektur übereinzustimmen.

Was das für Ihren Incident-Response-Prozess bedeutet: Wenn Ihr Team Benachrichtigungs-Workflows um das aktuelle Formular eines bestimmten Mitgliedstaats herum aufgebaut hat, ist damit zu rechnen, dass diese Workflows aktualisiert werden müssen, sobald der Durchführungsrechtsakt veröffentlicht wird. Die grundlegenden NIS2-Compliance-Zeitvorgaben gemäß Artikel 23 (24-Stunden-Frühwarnung, 72-Stunden-Vorfallmeldung, Ein-Monats-Abschlussbericht) ändern sich nicht. Das Format für deren Einreichung jedoch schon.

ENISA NIS360 2026: Acht Sektoren noch in der Risikozone

ENISA veröffentlichte die dritte Ausgabe ihres NIS360-Berichts am 28. Mai 2026. Der Bericht bewertet die Cybersicherheitsreife und Kritikalität in allen Sektoren von hoher Kritikalität, die in Anhang I von NIS2 aufgeführt sind.

Die Bewertung 2026 umfasst das gesamte Ökosystem jedes Sektors (nationale Behörden, regulierte Einrichtungen und anwendbare EU-Gesetzgebung) anstatt einzelner Organisationen. Sie identifiziert Sektoren, in denen sich die Reife verbessert hat, und Sektoren, in denen die Lücke zwischen Kritikalität und tatsächlicher Sicherheitslage noch groß ist.

Acht Sektoren werden als Risikozonen identifiziert: Gesundheit, Eisenbahn, Seefahrt, ICT-Dienstleistungsmanagement, Raumfahrt, öffentliche Verwaltung, Trinkwasser und Abwasser. Dies sind Sektoren, in denen die Folgen eines erfolgreichen Angriffs schwerwiegend sind, aber das Sicherheitsniveau im gesamten Sektor unter dem bleibt, was das Bedrohungsniveau erfordert.

Für IT- und Sicherheitsverantwortliche in diesen Sektoren ist die NIS360-Bewertung ein nützlicher Benchmark. Wenn Ihr Sektor auf der Risikozonenliste erscheint, ist mit erhöhter aufsichtlicher Aufmerksamkeit seitens der nationalen zuständigen Behörden zu rechnen — nicht weil der Bericht direkt eine Durchsetzung auslöst, sondern weil Regulierungsbehörden sektorale Reifedaten nutzen, um ihre Audit- und Inspektionskalender zu priorisieren.

Luxemburg: NIS2-Gesetz in Kraft, Registrierungsfrist ist der 10. Juli 2026

Luxemburg veröffentlichte sein NIS2-Umsetzungsgesetz am 6. Mai 2026 im Journal officiel du Grand-Duché de Luxembourg. Das Gesetz trat am 10. Mai 2026 in Kraft und ersetzt das NIS1-Gesetz vom 28. Mai 2019.

Wer ist betroffen

NIS2 gilt in Luxemburg für Organisationen mit 50 oder mehr Mitarbeitern oder einem Jahresumsatz von über 10 Millionen €, die in einem von 18 kritischen Sektoren tätig sind. Größenschwellen werden auf konsolidierter Konzernebene bewertet: Eine Tochtergesellschaft mit 40 Mitarbeitern kann dennoch betroffen sein, wenn der Mutterkonzern die Schwellenwerte überschreitet.

Die zweistufige Struktur

Wesentliche Einrichtungen — große Organisationen in Anhang-I-Sektoren mit mehr als 250 Mitarbeitern und entweder 50 Millionen € Umsatz oder 43 Millionen € Bilanzsumme — unterliegen proaktiver Aufsicht und Sanktionen von bis zu 10 Millionen € oder 2 % des weltweiten Umsatzes. Wichtige Einrichtungen — mittelgroße Anhang-I-Organisationen und alle qualifizierenden Anhang-II-Einrichtungen — unterliegen reaktiver Aufsicht und Sanktionen von bis zu 7 Millionen € oder 1,4 % des weltweiten Umsatzes.

Beide Stufen müssen dieselben zehn Maßnahmenkategorien gemäß Artikel 12 umsetzen: Risikoanalyse, Vorfallbehandlung, Geschäftskontinuität, Lieferkettensicherheit, sichere Entwicklung, Wirksamkeitsbewertung, Cyberhygiene, Kryptografie, Zugangskontrolle und Multi-Faktor-Authentifizierung.

Zeitrahmen für die Vorfallmeldung

Luxemburg folgt exakt der Struktur von NIS2 Artikel 23: 24-Stunden-Frühwarnung, 72-Stunden-formelle Meldung, Ein-Monats-Abschlussbericht. Das Versäumen einer Frist ist selbst ein sanktionsfähiger Verstoß.

Die Selbstregistrierungsfrist am 10. Juli 2026

Einrichtungen haben bis zum 10. Juli 2026 Zeit, sich bei ihrer zuständigen Behörde selbst zu registrieren. Das ILR (Institut Luxembourgeois de Régulation) fungiert als zuständige Behörde für die meisten Sektoren; die CSSF überwacht das Bank- und Finanzmarktinfrastrukturwesen. Nichtregistrierung ist ein sanktionsfähiger Verstoß gemäß Artikel 11.

Leitungsorgane müssen Cybersicherheitsmaßnahmen formell genehmigen, deren Umsetzung überwachen und regelmäßige Schulungen absolvieren. Für wesentliche Einrichtungen können leitende Führungskräfte bei schwerwiegenden Versäumnissen mit einem vorübergehenden Verbot der Ausübung von Leitungsfunktionen belegt werden.

Niederlande: Cyberbeveiligingswet erreicht Senats-Plenarphase

Die niederländische Zweite Kammer stimmte dem Cyberbeveiligingswet (dem niederländischen NIS2-Umsetzungsgesetz) am 15. April 2026 mit 140 zu 10 Stimmen zu. Der Gesetzentwurf ist nun in die Senats-Plenarphase vorgerückt.

Stand des Gesetzentwurfs

Die Tweede Kamer verabschiedete den Gesetzentwurf mit breiter fraktionsübergreifender Unterstützung; nur zwei Parteien stimmten dagegen. Die für Digitalisierung und Justiz zuständigen Senatsausschüsse schlossen ihre schriftliche Prüfung am 19. Mai 2026 ab. Der Gesetzentwurf ist seitdem in die Senats-Plenarphase übergegangen, wo er auf eine Schlussabstimmung wartet.

Der Gesetzentwurf wird parallel zu separater Gesetzgebung zur Umsetzung der EU-CER-Richtlinie zur Resilienz kritischer Einrichtungen bearbeitet.

Hintergrund

Die Niederlande reichten den Gesetzentwurf am 2. Juni 2025 beim Parlament ein und verfehlten damit die EU-Umsetzungsfrist vom 17. Oktober 2024 um über ein Jahr. Der Gesetzentwurf verbrachte fast zehn Monate im Verfahren der Zweiten Kammer, bevor er verabschiedet wurde.

Zentrale Bestimmungen

Anstatt eine einzige nationale Cybersicherheitsbehörde zu schaffen, überträgt das Gesetz die Durchsetzung auf bestehende sektorspezifische Regulierungsbehörden — die Energieregulierungsbehörde für Energieunternehmen, die Gesundheitsregulierungsbehörde für Krankenhäuser und so weiter. Das genaue Datum des Inkrafttretens des Gesetzes wird nach der Senatszustimmung per Regierungserlass festgelegt, und verschiedene Bestimmungen können zu unterschiedlichen Zeitpunkten in Kraft treten.

Was als Nächstes kommt

Die Senatszustimmung ist der letzte legislative Schritt. Sobald die Abstimmung erfolgt ist und die Regierung ein Datum des Inkrafttretens festlegt, werden betroffene Organisationen mit sofortigen Compliance-Verpflichtungen konfrontiert — Risikomanagementmaßnahmen, Vorfallmeldung und Anforderungen an die Verantwortlichkeit des Managements.

Irland: National Cyber Security Bill als NIS2-Vehikel bestätigt

In einer schriftlichen parlamentarischen Antwort an das Dáil Éireann (das Unterhaus des irischen Parlaments) am 13. Mai 2026 bestätigte Irlands Minister für Justiz, Inneres und Migration, dass das Justizministerium das National Cyber Security Bill als gesetzliches Vehikel für die NIS2-Umsetzung erarbeitet.

Das Gesetz ist als Priorität für die Veröffentlichung im Gesetzgebungsprogramm Sommer 2026 aufgeführt. Es wird das National Cyber Security Centre (NCSC) als nationale zuständige Behörde und als Irlands Computer Security Incident Response Team (CSIRT) benennen. Es wird das NCSC auch erstmals auf eine gesetzliche Grundlage stellen — das Zentrum arbeitet derzeit ohne eine eigene legislative Basis.

Irland verfehlte die EU-Umsetzungsfrist vom 17. Oktober 2024. Eine Kabinettsentscheidung im Juli 2024 wies die vorrangige Erarbeitung der Gesetzgebung an, und die Arbeiten sind seitdem im Gange. Der Gesetzesentwurf wurde noch nicht veröffentlicht, aber die Regierung veröffentlichte im September 2024 das General Scheme des National Cyber Security Bill, das dessen beabsichtigte Struktur darlegt.

Managementhaftung

Gemäß NIS2 Artikel 20, wie in Head 28 des General Scheme widergespiegelt, müssen Leitungsgremien Cybersicherheits-Risikomanagementmaßnahmen genehmigen und überwachen, regelmäßige Cybersicherheitsschulungen absolvieren und können bei Compliance-Versäumnissen persönlich haftbar gemacht werden — einschließlich vorübergehender Verbote und Verwaltungsbußgelder. Das General Scheme definiert „Leitungsgremium" als „ein Gremium oder eine Gruppe von Einzelpersonen, die mit der Befugnis und Verantwortung für die Aufsicht, Leitung und Kontrolle einer Einrichtung betraut sind".

Sektorregulierungsbehörden bereits aktiv

Sektorregulierungsbehörden wurden bereits als Nationale Zuständige Behörden benannt und bereiten sich darauf vor, Aufsichts- und Durchsetzungsfunktionen zu übernehmen. Die NIS2-Registrierungs- und Vorfallmeldeportale sind noch nicht live — sie werden nach Inkrafttreten der Gesetzgebung eröffnet — aber das NCSC hat Entwürfe von Leitlinien zu Risikomanagementmaßnahmen und das Cyber Fundamentals (CyFun) Framework veröffentlicht, um Organisationen bei der Vorbereitung in der Zwischenzeit zu unterstützen.

Das Gesetz wird auch parallel zur dritten nationalen Cybersicherheitsstrategie Irlands entwickelt, koordiniert durch ein interministerielles Komitee unter dem Vorsitz des Justizministeriums.

Für Organisationen mit irischen Niederlassungen bedeutet das Fehlen einer erlassenen Gesetzgebung nicht, dass die Vorbereitungspflicht entfällt. Sektorale NCAs sind bereits aktiv, und der Erlass des Gesetzes wird als Regierungspriorität bezeichnet.

DigitalEurope: NIS2 braucht noch tiefere Harmonisierung

Am 13. Mai 2026 veröffentlichte DigitalEurope eine formelle Stellungnahme zum EU-Cybersicherheitspaket, das den vorgeschlagenen Cybersecurity Act 2 (CSA2), das ICT-Lieferkettensicherheits-Framework und gezielte NIS2-Änderungen umfasst.

Speziell zu NIS2 ist DigitalEuropes Position direkt: Die im aktuellen Paket vorgeschlagenen gezielten Änderungen reagieren „minimal" auf die Bedenken, die die Industrie seit mehreren Jahren geäußert hat. Die Bereiche, die eine strengere Harmonisierung erfordern, sind:

• Anwendungsbereich: NIS2 sollte sich nur auf Kerngeschäftsaktivitäten konzentrieren und Nebentätigkeiten ausschließen, die unverhältnismäßige Verpflichtungen schaffen.
• Größenschwellen: Nationale Unterschiede in der Anwendung der Schwellenwerte führen zu inkonsistenter Abdeckung über die Mitgliedstaaten hinweg.
• Vorfallmeldung: Meldefelder, Zeitrahmen und Einreichungsprozesse variieren noch auf nationaler Ebene — ein Problem, das die gemeinsamen Vorlagen (siehe oben) teilweise angehen.
• Regelungen zur Hauptniederlassung: Organisationen, die in mehreren Mitgliedstaaten tätig sind, sind mit Unsicherheit darüber konfrontiert, welche nationale Behörde die primäre Zuständigkeit hat.
• Konformitätsbewertung: Die Anforderungen unterscheiden sich je nach Mitgliedstaat, was Compliance-Komplexität für grenzüberschreitende Operationen schafft.

DigitalEurope forderte außerdem, dass ENISA Folgenabschätzungen für alle relevanten EU-Cybersicherheitsgesetze durchführt und die Umsetzung aktiver koordiniert — um die Agentur als Koordinierungszentrum zu positionieren, anstatt als rein beratende Stelle.

Für Compliance-Verantwortliche, die den regulatorischen Verlauf verfolgen: Die von DigitalEurope identifizierten Harmonisierungslücken sind echte operative Reibungspunkte. Die am 26. Mai verabschiedeten gemeinsamen Vorlagen für die Vorfallmeldung sind ein Schritt zur Schließung einer davon. Die anderen erfordern entweder die Durchführungsrechtsakte oder das NIS2-Änderungsverfahren zur Lösung.

Was das jetzt für Ihr Team bedeutet

Die Entwicklungen vom Mai 2026 folgen einem Muster, das seit Beginn der Durchsetzung konsistent ist: Der Text der Richtlinie ist stabil, aber die nationale Umsetzungsebene bewegt sich weiter. Bulgariens vollständige Sanktionsphase, Luxemburgs live geltende Registrierungsfrist und die ausstehende Senatsabstimmung in den Niederlanden stellen alle konkrete Compliance-Auslöser dar, jeweils mit einem nun festgelegten spezifischen Datum.

Die gemeinsamen Vorlagen für die Vorfallmeldung sind die operativ bedeutsamste EU-weite Entwicklung des Zeitraums. Sobald der Durchführungsrechtsakt der Kommission veröffentlicht wird, muss der Workflow für Vorfallmeldungen jeder Organisation aktualisiert werden, um dem standardisierten Format zu entsprechen. Planen Sie diese Aktualisierung jetzt in Ihre Incident-Response-Planung ein, bevor Sie ein tatsächlicher Vorfall dazu zwingt, dies unter Druck zu tun.

Die ENISA NIS360-Risikozonenliste ist es wert, ernst genommen zu werden, wenn Ihre Organisation im Gesundheitswesen, in der öffentlichen Verwaltung oder in einem der anderen markierten Sektoren tätig ist. Aufsichtliche Aufmerksamkeit folgt Reifelücken — und ENISAs Bewertung fließt direkt in die Priorisierung der Audit-Kalender der nationalen zuständigen Behörden ein.

Häufig gestellte Fragen

Was ist im Mai 2026 mit NIS2 passiert?

Im Mai 2026 gab es vier bedeutende NIS2-Entwicklungen: Luxemburgs Umsetzungsgesetz trat am 10. Mai in Kraft; die NIS-Kooperationsgruppe verabschiedete am 26. Mai gemeinsame Vorlagen für die Vorfallmeldung; ENISA veröffentlichte am 28. Mai die NIS360 2026-Sektorreifebewertung; und die Niederlande brachten ihr Cyberbeveiligingswet durch die Zweite Kammer. Bulgariens vollständige Sanktionsphase begann am 1. Juni 2026, direkt nach dem Mai-Zeitraum.

Was ist die Luxemburger NIS2-Selbstregistrierungsfrist?

Luxemburgs NIS2-Umsetzungsgesetz, das am 10. Mai 2026 in Kraft trat, verlangt von allen betroffenen Einrichtungen, sich bis zum 10. Juli 2026 bei ihrer zuständigen Behörde selbst zu registrieren. Das ILR (Institut Luxembourgeois de Régulation) ist die primäre zuständige Behörde. Nichtregistrierung ist ein sanktionsfähiger Verstoß gemäß Artikel 11 des Umsetzungsgesetzes.

Was sind die neuen NIS2-Vorlagen für die Vorfallmeldung?

Am 26. Mai 2026 verabschiedete die NIS-Kooperationsgruppe bei ihrer 39. Plenarsitzung in Zypern gemeinsame Vorlagen für die NIS2-Vorfallmeldung. Die Vorlagen bieten ein standardisiertes Format für die Meldung von Cybervorfällen in allen EU-Mitgliedstaaten. Die Europäische Kommission plant, diese durch einen Durchführungsrechtsakt verbindlich zu machen. Die zugrundeliegenden Zeitrahmen gemäß NIS2 Artikel 23 — 24-Stunden-Frühwarnung, 72-Stunden-Meldung, Ein-Monats-Abschlussbericht — bleiben unverändert.

Welche Sektoren identifiziert ENISAs NIS360 2026 als höchstes Risiko?

Der NIS360 2026-Bericht von ENISA, veröffentlicht am 28. Mai 2026, identifiziert acht Sektoren als Risikozonen, in denen die Cybersicherheitsreife im Verhältnis zur Kritikalität niedrig bleibt: Gesundheit, Eisenbahn, Seefahrt, ICT-Dienstleistungsmanagement, Raumfahrt, öffentliche Verwaltung, Trinkwasser und Abwasser. Dies sind alles Anhang-I-Sektoren unter NIS2 und unterliegen als wesentliche Einrichtungen proaktiver Aufsicht.

Was sind die persönlichen Haftungsregeln für Manager unter Bulgariens NIS2?

Gemäß Bulgariens geändertem Cybersicherheitsgesetz drohen Mitgliedern des Leitungsorgans wesentlicher und wichtiger Einrichtungen persönliche Bußgelder von 500 € bis 5.000 € bei Verstoß gegen ihre Governance-Pflichten — getrennt von Bußgeldern auf Unternehmensebene. Ab dem 1. Juni 2026 gelten diese Bußgelder in voller gesetzlicher Höhe; der 50 %-Übergangsrabatt, der für Verstöße vor Juni galt, existiert nicht mehr. Die zuständige Behörde kann auch ein gerichtlich angeordnetes vorübergehendes Verbot der Ausübung von Leitungsfunktionen für einen Manager beantragen.

Wie viele EU-Mitgliedstaaten haben NIS2 umgesetzt?

Bis Ende Mai 2026 haben 23 von 27 EU-Mitgliedstaaten NIS2 in nationales Recht umgesetzt, laut dem Tracker von Cullen International vom Mai 2026. Luxemburgs Umsetzung trat am 10. Mai 2026 in Kraft und brachte die Gesamtzahl auf 23. Vier Mitgliedstaaten befinden sich noch im Gesetzgebungsprozess, mehr als 19 Monate nach der Umsetzungsfrist vom Oktober 2024.

Was ist das niederländische Cyberbeveiligingswet?

Das Cyberbeveiligingswet ist die nationale Gesetzgebung der Niederlande zur Umsetzung von NIS2. Die niederländische Zweite Kammer stimmte dem Gesetzentwurf 2026 zu, nachdem die Niederlande die ursprüngliche EU-Umsetzungsfrist vom Oktober 2024 verpasst hatten. Der Gesetzentwurf erfordert noch die Senatszustimmung, bevor er in Kraft treten kann. Das niederländische Modell verwendet eine dezentralisierte Aufsichtsstruktur, bei der sektorspezifische Regulierungsbehörden die Durchsetzung übernehmen.

NIS2-Compliance-Leitfaden: Die Zugangsmanagement-Roadmap für 2026

Gestohlene Zugangsdaten dominieren Sicherheitsverletzungen im Jahr 2026. NIS2 Artikel 21 schreibt 10 Sicherheitsmaßnahmen vor, um Angriffsvektoren auf Basis von Zugangsdaten zu eliminieren. Dieser Leitfaden behandelt technische Anforderungen, die 24-Stunden-Vorfallmeldepflicht, ENISAs MFA-Stufen und eine 5-Phasen-Roadmap zur auditbereiten Compliance.

Passwork BlogAlex Muntyan

Passwork gewinnt Top Performer Frühjahr 2026 auf SourceForge

Passwork wurde von SourceForge als Top Performer Frühjahr 2026 ausgezeichnet und rangiert damit unter den besten 10 % von über 100.000 Lösungen. Das Abzeichen basiert ausschließlich auf verifizierten Bewertungen — 4,8 Sterne insgesamt, mit perfekten 5,0 für Support.

Passwork BlogAlex Muntyan

Brute-Force-Angriffe 2026: Arten, Beispiele und wie Sie sich schützen

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

Passwork BlogAlex Muntyan

El período de gracia de NIS2 en Bulgaria finalizó el 1 de junio de 2026 — los miembros del consejo de administración ahora enfrentan multas personales completas, no la tasa reducida del 50% que se aplicaba hasta mayo. La ley de transposición de la Directiva NIS2 de Luxemburgo entró en vigor el 10 de mayo de 2026, dejando a cuatro estados miembros todavía sin legislación de implementación. El Grupo de Cooperación NIS de la UE adoptó plantillas comunes de notificación de incidentes que la Comisión tiene previsto hacer obligatorias mediante un acto de ejecución.

Este artículo cubre todas las actualizaciones importantes de NIS2 de mayo de 2026: qué cambió, qué plazos están vigentes y qué debe hacer su equipo ahora.

Puntos clave

Estas actualizaciones de NIS2 de mayo de 2026 conllevan desencadenantes concretos de cumplimiento: fechas específicas y obligaciones específicas. Esto es lo que cambió.

• El régimen de sanciones completo de Bulgaria está activo. Desde el 1 de junio de 2026, las multas personales para los miembros del órgano de dirección se aplican al 100% de los importes legales — hasta 5.000 € por individuo, separadas de las multas a nivel de entidad de hasta 10 millones de €. El descuento transitorio del 50% ha desaparecido.
• La ley NIS2 de Luxemburgo entró en vigor el 10 de mayo de 2026. Las entidades dentro del ámbito de aplicación tienen hasta el 10 de julio de 2026 para autoregistrarse en el ILR. El no registro es en sí mismo una infracción sancionable.
• Cuatro estados miembros de la UE aún no han transpuesto NIS2 — más de 19 meses después del plazo de octubre de 2024, según el rastreador de mayo de 2026 de Cullen International.
• Se adoptaron plantillas comunes de notificación de incidentes en toda la UE. El Grupo de Cooperación NIS acordó formatos estandarizados en su 39ª reunión plenaria en Chipre el 26 de mayo de 2026. Un acto de ejecución de la Comisión las hará obligatorias.
• El informe NIS360 2026 de ENISA identifica ocho sectores en zona de riesgo. Salud, ferrocarril, marítimo, gestión de servicios TIC, espacio, administración pública, agua potable y aguas residuales muestran la madurez en ciberseguridad más baja en relación con su criticidad.
• Los Países Bajos avanzaron en su retrasada Cyberbeveiligingswet. La Cámara de Representantes neerlandesa aprobó el proyecto de ley el 15 de abril de 2026; la aprobación del Senado aún está pendiente.
• Irlanda confirmó el proyecto de ley de Seguridad Cibernética Nacional como su vehículo NIS2. El Departamento de Justicia está redactando la legislación y estableciendo al NCSC sobre una base estatutaria.
• DigitalEurope pidió una armonización más profunda de NIS2. El organismo de la industria publicó una posición formal identificando el ámbito de aplicación, los umbrales de tamaño, la notificación de incidentes y la evaluación de conformidad como las áreas que más necesitan estandarización entre los estados miembros.

La fase de aplicación completa de Bulgaria comenzó el 1 de junio de 2026

La aplicación de NIS2 en Bulgaria entró en su fase final el 1 de junio de 2026. Las multas y sanciones por todas las infracciones ahora se aplican en sus importes legales completos — la reducción del 50% que se aplicaba a las violaciones cometidas antes de esa fecha ha desaparecido.

La legislación subyacente es la Ley de Modificación y Complemento de la Ley de Ciberseguridad, adoptada por la 51ª Asamblea Nacional el 5 de febrero de 2026 y promulgada en el Boletín Oficial del Estado (número 17) el 13 de febrero de 2026, entrando en vigor en la misma fecha.

Quién está dentro del ámbito de aplicación

La Ley de Ciberseguridad cubre a entidades públicas y privadas en sectores del Anexo I y Anexo II que cumplen o superan los umbrales de mediana empresa. Ciertos proveedores están dentro del ámbito independientemente del tamaño: redes públicas de comunicaciones electrónicas, proveedores de servicios de confianza, registros de dominios de nivel superior, proveedores de servicios DNS, entidades que son el único proveedor de un servicio crítico en Bulgaria, o cuya interrupción afectaría significativamente al orden público, la seguridad pública o la salud, o la economía.

Los organismos administrativos (incluidos los municipios) se clasifican como entidades esenciales según el Artículo 4a(1)(4), independientemente del tamaño.

Aplicación completa sin un reglamento completo

Queda una complicación práctica. La ley delega explícitamente la definición de medidas mínimas de ciberseguridad para ciertas categorías de entidades a una ordenanza secundaria del Consejo de Ministros, que será propuesta conjuntamente por la Comisión de Regulación de Comunicaciones y el Ministro de Gobernanza Electrónica. Esa ordenanza aún no se ha publicado. Las organizaciones entraron en la fase de aplicación completa sin el reglamento operativo completo que la propia ley anticipaba.

Esto no suspende las obligaciones. La ley principal está en vigor, las sanciones son reales. El análisis de brechas contra el marco NIS2 existente es posible y aconsejable ahora, antes de que aumente la presión supervisora. ISO/IEC 27001 e ISO 22301 proporcionan una base de referencia viable junto con los requisitos de la Ley de Ciberseguridad.

Lo que los órganos de dirección deben demostrar ahora

La Ley de Ciberseguridad de Bulgaria establece una responsabilidad personal explícita para los miembros individuales de los órganos de dirección, no solo para la organización como entidad legal. Los órganos de dirección deben:

• Aprobar formalmente las medidas de gestión de riesgos de ciberseguridad requeridas según el Artículo 21
• Supervisar la implementación de dichas medidas
• Completar formación en ciberseguridad al menos cada dos años
• Organizar formación equivalente para los empleados de forma regular

Las medidas que los consejos deben aprobar cubren el análisis de riesgos y las políticas de seguridad de la información, la gestión de incidentes, la continuidad del negocio y la gestión de crisis, la seguridad de la cadena de suministro, las prácticas de higiene cibernética y la autenticación multifactor cuando sea apropiado.

La estructura de multas personales

Cuando un miembro del órgano de dirección de una entidad esencial o importante incumple estas obligaciones de gobernanza, puede imponerse una multa personal de 500 € a 5.000 €. Esto es independiente de las sanciones a nivel de entidad y se suma a ellas: hasta 10 millones de € o el 2% de la facturación global para entidades esenciales, y hasta 7 millones de € o el 1,4% para entidades importantes.

La autoridad nacional competente también puede solicitar a un tribunal que imponga una prohibición temporal a una persona física para ejercer funciones de dirección en una entidad esencial.

La implicación práctica: un miembro del consejo no puede delegar su responsabilidad. Si se impone una multa, y su gravedad, dependerá de la capacidad del individuo para demostrar acciones tangibles — resoluciones del consejo, políticas adoptadas, protocolos de auditoría, responsabilidades asignadas, formación completada y medidas correctivas documentadas.

A nivel de la UE: Se adoptan plantillas comunes de notificación de incidentes

El 26 de mayo de 2026, el Grupo de Cooperación NIS adoptó plantillas comunes para la notificación de incidentes NIS2 en su 39ª reunión plenaria en Chipre. El Grupo reúne a los estados miembros de la UE, la Comisión Europea y ENISA.

Las plantillas proporcionan un formato estandarizado para notificar incidentes cibernéticos en toda la UE. Hasta ahora, la ausencia de un formato común significaba que las organizaciones que operaban en múltiples estados miembros tenían que navegar por diferentes formularios de notificación nacionales, conjuntos de campos y portales de envío — una carga administrativa significativa para cualquier operación transfronteriza.

La Comisión ha declarado que planea adoptar estas plantillas mediante un acto de ejecución, lo que las haría obligatorias para todos los estados miembros. Una vez que ese acto entre en vigor, las plantillas establecerán un marco unificado de notificación de incidentes en toda la UE.

Este desarrollo también se conecta con la propuesta más amplia del Digital Omnibus, que incluye un punto único de entrada para la notificación de incidentes. Las plantillas comunes están diseñadas para alinearse con esa arquitectura futura.

Lo que esto significa para su proceso de respuesta a incidentes: Si su equipo ha construido flujos de trabajo de notificación en torno al formulario actual de un estado miembro específico, espere que esos flujos de trabajo se actualicen una vez que se publique el acto de ejecución. Las obligaciones básicas del cronograma de cumplimiento de NIS2 según el Artículo 23 (alerta temprana de 24 horas, notificación de incidentes de 72 horas, informe final de un mes) no cambian. El formato para presentarlas sí cambia.

ENISA NIS360 2026: Ocho sectores todavía en la zona de riesgo

ENISA publicó la tercera edición de su informe NIS360 el 28 de mayo de 2026. El informe evalúa la madurez en ciberseguridad y la criticidad en todos los sectores de alta criticidad enumerados en el Anexo I de NIS2.

La evaluación de 2026 cubre el ecosistema completo de cada sector (autoridades nacionales, entidades reguladas y legislación de la UE aplicable) en lugar de organizaciones individuales. Identifica sectores donde la madurez ha mejorado y sectores donde la brecha entre la criticidad y la postura de seguridad real sigue siendo amplia.

Ocho sectores se identifican como zonas de riesgo: salud, ferrocarril, marítimo, gestión de servicios TIC, espacio, administración pública, agua potable y aguas residuales. Estos son sectores donde las consecuencias de un ataque exitoso son graves, pero donde la línea base de seguridad en todo el sector permanece por debajo de lo que exige el nivel de amenaza.

Para los líderes de TI y seguridad en estos sectores, la evaluación NIS360 es un punto de referencia útil. Si su sector aparece en la lista de zonas de riesgo, espere una mayor atención supervisora de las autoridades nacionales competentes — no porque el informe desencadene directamente la aplicación, sino porque los reguladores utilizan los datos de madurez sectorial para priorizar sus calendarios de auditoría e inspección.

Luxemburgo: Ley NIS2 en vigor, el plazo de registro es el 10 de julio de 2026

Luxemburgo publicó su ley de transposición NIS2 el 6 de mayo de 2026 en el Journal officiel du Grand-Duché de Luxembourg. La ley entró en vigor el 10 de mayo de 2026, reemplazando la ley NIS1 del 28 de mayo de 2019.

Quién está dentro del ámbito de aplicación

NIS2 se aplica en Luxemburgo a organizaciones con 50 o más empleados o una facturación anual superior a 10 millones de €, que operan en uno de los 18 sectores críticos. Los umbrales de tamaño se evalúan a nivel de grupo consolidado: una filial con 40 empleados puede estar dentro del ámbito si el grupo matriz supera los umbrales.

La estructura de dos niveles

Las entidades esenciales — grandes organizaciones en sectores del Anexo I con más de 250 empleados y ya sea 50 millones de € en facturación o 43 millones de € en balance — están sujetas a supervisión proactiva y sanciones de hasta 10 millones de € o el 2% de la facturación global. Las entidades importantes — organizaciones medianas del Anexo I y todas las entidades cualificadas del Anexo II — están sujetas a supervisión reactiva y sanciones de hasta 7 millones de € o el 1,4% de la facturación global.

Ambos niveles deben implementar las mismas diez categorías de medidas según el Artículo 12: análisis de riesgos, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, desarrollo seguro, evaluación de la eficacia, higiene cibernética, criptografía, control de acceso y autenticación multifactor.

Plazos de notificación de incidentes

Luxemburgo sigue exactamente la estructura del Artículo 23 de NIS2: alerta temprana de 24 horas, notificación formal de 72 horas, informe final de un mes. Incumplir cualquier plazo es en sí mismo una infracción sancionable.

El plazo de autoregistro del 10 de julio de 2026

Las entidades tienen hasta el 10 de julio de 2026 para autoregistrarse ante su autoridad competente. El ILR (Institut Luxembourgeois de Régulation) actúa como autoridad competente para la mayoría de los sectores; la CSSF supervisa la banca y la infraestructura del mercado financiero. El no registro es una infracción sancionable según el Artículo 11.

Los órganos de dirección deben aprobar formalmente las medidas de ciberseguridad, supervisar su implementación y someterse a formación regular. Para las entidades esenciales, los directivos pueden enfrentarse a una prohibición temporal de ejercer funciones de dirección por fallos graves.

Países Bajos: La Cyberbeveiligingswet alcanza la fase plenaria del Senado

La Cámara de Representantes neerlandesa aprobó la Cyberbeveiligingswet (la ley de transposición NIS2 de los Países Bajos) el 15 de abril de 2026 por 140 votos contra 10. El proyecto de ley ha avanzado ahora a la fase plenaria del Senado.

En qué punto se encuentra el proyecto de ley

La Tweede Kamer aprobó el proyecto de ley con amplio apoyo multipartidista; solo dos partidos votaron en contra. Las comisiones del Senado responsables de digitalización y justicia completaron su revisión escrita el 19 de mayo de 2026. El proyecto de ley ha pasado desde entonces a la fase plenaria del Senado, donde espera una votación final.

El proyecto de ley se está tramitando en paralelo con legislación separada que transpone la Directiva CER de la UE sobre la resiliencia de entidades críticas.

Antecedentes

Los Países Bajos presentaron el proyecto de ley al parlamento el 2 de junio de 2025, incumpliendo el plazo de transposición de la UE del 17 de octubre de 2024 por más de un año. El proyecto de ley pasó casi diez meses en el procedimiento de la cámara baja antes de ser aprobado.

Disposiciones clave

En lugar de crear una única autoridad nacional de ciberseguridad, la ley asigna la aplicación a los reguladores sectoriales existentes — el regulador de energía para las empresas energéticas, el regulador sanitario para los hospitales, y así sucesivamente. La fecha exacta de entrada en vigor de la ley se establecerá por decreto gubernamental después de la aprobación del Senado, y diferentes disposiciones pueden entrar en vigor en diferentes fechas.

Qué viene a continuación

La aprobación del Senado es el último paso legislativo. Una vez que pase la votación y el gobierno establezca una fecha de entrada en vigor, las organizaciones dentro del ámbito enfrentarán obligaciones de cumplimiento inmediatas — medidas de gestión de riesgos, notificación de incidentes y requisitos de responsabilidad de la dirección.

Irlanda: Proyecto de ley de Seguridad Cibernética Nacional confirmado como vehículo NIS2

En una respuesta parlamentaria escrita al Dáil Éireann (la cámara baja del parlamento irlandés) el 13 de mayo de 2026, el Ministro de Justicia, Asuntos de Interior y Migración de Irlanda confirmó que el Departamento de Justicia está redactando el proyecto de ley de Seguridad Cibernética Nacional como el vehículo legislativo para la transposición de NIS2.

El proyecto de ley está catalogado como prioridad para su publicación en el programa legislativo del verano de 2026. Designará al Centro Nacional de Seguridad Cibernética (NCSC) como la autoridad nacional competente y como el Equipo de Respuesta a Incidentes de Seguridad Informática (CSIRT) de Irlanda. También establecerá al NCSC sobre una base estatutaria por primera vez — el centro actualmente opera sin una base legislativa dedicada.

Irlanda incumplió el plazo de transposición de la UE del 17 de octubre de 2024. Una decisión del Gabinete en julio de 2024 ordenó la redacción prioritaria de la legislación, y el trabajo ha progresado desde entonces. El borrador del proyecto de ley aún no se ha publicado, pero el gobierno publicó el Esquema General del proyecto de ley de Seguridad Cibernética Nacional en septiembre de 2024, estableciendo su estructura prevista.

Responsabilidad de la dirección

Según el Artículo 20 de NIS2, tal como se refleja en el Head 28 del Esquema General, los consejos de dirección estarán obligados a aprobar y supervisar las medidas de gestión de riesgos de ciberseguridad, asistir a formación regular en ciberseguridad y pueden enfrentarse a responsabilidad personal por fallos de cumplimiento — incluyendo prohibiciones temporales y multas administrativas. El Esquema General define «consejo de dirección» como «un órgano o grupo de individuos investidos con la autoridad y responsabilidad para la supervisión, dirección y control de una entidad».

Reguladores sectoriales ya activos

Los reguladores sectoriales ya han sido designados como Autoridades Nacionales Competentes y se están preparando para asumir funciones de supervisión y aplicación. Los portales de registro y notificación de incidentes de NIS2 aún no están activos — se abrirán una vez que se promulgue la legislación — pero el NCSC ha publicado un borrador de guía sobre Medidas de Gestión de Riesgos y el marco Cyber Fundamentals (CyFun) para ayudar a las organizaciones a prepararse mientras tanto.

El proyecto de ley también se está desarrollando junto con la tercera Estrategia Nacional de Seguridad Cibernética de Irlanda, coordinada a través de un Comité Interdepartamental presidido por el Departamento de Justicia.

Para las organizaciones con operaciones en Irlanda, la ausencia de legislación promulgada no elimina la obligación de prepararse. Las ANC sectoriales ya están activas, y la promulgación del proyecto de ley se describe como una prioridad del gobierno.

DigitalEurope: NIS2 todavía necesita una armonización más profunda

El 13 de mayo de 2026, DigitalEurope publicó una posición política formal sobre el paquete de ciberseguridad de la UE, que abarca la propuesta de Ley de Ciberseguridad 2 (CSA2), el marco de seguridad de la cadena de suministro de TIC y las enmiendas específicas de NIS2.

Sobre NIS2 específicamente, la posición de DigitalEurope es directa: las enmiendas específicas propuestas en el paquete actual responden «mínimamente» a las preocupaciones que la industria ha planteado durante varios años. Las áreas que requieren una armonización más rigurosa son:

• Ámbito de aplicación: NIS2 debería centrarse únicamente en las actividades comerciales principales, excluyendo las operaciones auxiliares que crean obligaciones desproporcionadas.
• Umbrales de tamaño: La divergencia nacional en la aplicación de los umbrales crea una cobertura inconsistente entre los estados miembros.
• Notificación de incidentes: Los campos de notificación, los plazos y los procesos de envío todavía varían a nivel nacional — un problema que las plantillas comunes (ver arriba) abordan parcialmente.
• Reglas del establecimiento principal: Las organizaciones que operan en múltiples estados miembros enfrentan incertidumbre sobre qué autoridad nacional tiene jurisdicción principal.
• Evaluación de conformidad: Los requisitos difieren según el estado miembro, creando complejidad de cumplimiento para las operaciones transfronterizas.

DigitalEurope también pidió a ENISA que realice evaluaciones de impacto para toda la legislación de ciberseguridad de la UE relevante y que coordine la implementación de manera más activa — posicionando a la agencia como un centro de coordinación en lugar de un organismo puramente consultivo.

Para los responsables de cumplimiento que siguen la trayectoria regulatoria: las brechas de armonización que identifica DigitalEurope son puntos de fricción operativa reales. Las plantillas comunes de notificación de incidentes adoptadas el 26 de mayo son un paso hacia el cierre de una de ellas. Las demás requerirán los actos de ejecución o el proceso de enmienda de NIS2 para resolverse.

Qué significa esto para su equipo ahora mismo

Los desarrollos de mayo de 2026 siguen un patrón que ha sido consistente desde que comenzó la aplicación: el texto de la directiva es estable, pero la capa de implementación nacional sigue moviéndose. La fase de sanciones completas de Bulgaria, el plazo de registro activo de Luxemburgo y la votación pendiente del Senado en los Países Bajos representan todos desencadenantes concretos de cumplimiento, cada uno con una fecha específica ahora adjunta.

Las plantillas comunes de notificación de incidentes son el desarrollo a nivel de la UE más significativo operativamente del período. Una vez que se publique el acto de ejecución de la Comisión, el flujo de trabajo de notificación de incidentes de cada organización deberá actualizarse para coincidir con el formato estandarizado. Incorpore esa actualización en su planificación de respuesta a incidentes ahora, antes de que un incidente real le obligue a hacerlo bajo presión.

La lista de zonas de riesgo de ENISA NIS360 merece tomarse en serio si su organización opera en salud, administración pública o cualquiera de los otros sectores señalados. La atención supervisora sigue las brechas de madurez — y la evaluación de ENISA alimenta directamente cómo las autoridades nacionales competentes priorizan sus calendarios de auditoría.

Preguntas frecuentes

¿Qué pasó con NIS2 en mayo de 2026?

Mayo de 2026 vio cuatro desarrollos significativos de NIS2: la ley de transposición de Luxemburgo entró en vigor el 10 de mayo; el Grupo de Cooperación NIS adoptó plantillas comunes de notificación de incidentes el 26 de mayo; ENISA publicó la evaluación de madurez sectorial NIS360 2026 el 28 de mayo; y los Países Bajos avanzaron su Cyberbeveiligingswet a través de la Cámara de Representantes. La fase de sanciones completas de Bulgaria comenzó el 1 de junio de 2026, directamente después del período de mayo.

¿Cuál es el plazo de autoregistro NIS2 de Luxemburgo?

La ley de transposición NIS2 de Luxemburgo, que entró en vigor el 10 de mayo de 2026, requiere que todas las entidades dentro del ámbito se autoregistren ante su autoridad competente antes del 10 de julio de 2026. El ILR (Institut Luxembourgeois de Régulation) es la autoridad competente principal. El no registro es una infracción sancionable según el Artículo 11 de la ley de transposición.

¿Cuáles son las nuevas plantillas de notificación de incidentes NIS2?

El 26 de mayo de 2026, el Grupo de Cooperación NIS adoptó plantillas comunes para la notificación de incidentes NIS2 en su 39ª reunión plenaria en Chipre. Las plantillas proporcionan un formato estandarizado para notificar incidentes cibernéticos en todos los estados miembros de la UE. La Comisión Europea planea hacerlas obligatorias mediante un acto de ejecución. Los plazos subyacentes del Artículo 23 de NIS2 — alerta temprana de 24 horas, notificación de 72 horas, informe final de un mes — permanecen sin cambios.

¿Qué sectores identifica el NIS360 2026 de ENISA como de mayor riesgo?

El informe NIS360 2026 de ENISA, publicado el 28 de mayo de 2026, identifica ocho sectores como zonas de riesgo donde la madurez en ciberseguridad permanece baja en relación con la criticidad: salud, ferrocarril, marítimo, gestión de servicios TIC, espacio, administración pública, agua potable y aguas residuales. Todos estos son sectores del Anexo I bajo NIS2 y están sujetos a supervisión proactiva como entidades esenciales.

¿Cuáles son las reglas de responsabilidad personal para directivos bajo el NIS2 de Bulgaria?

Según la Ley de Ciberseguridad enmendada de Bulgaria, los miembros del órgano de dirección de entidades esenciales e importantes enfrentan multas personales de 500 € a 5.000 € por incumplir sus obligaciones de gobernanza — separadas de las multas a nivel de entidad. Desde el 1 de junio de 2026, estas multas se aplican a los importes legales completos; el descuento transitorio del 50% que se aplicaba a las violaciones anteriores a junio ya no existe. La autoridad competente también puede solicitar una prohibición temporal ordenada por el tribunal para que un directivo ejerza funciones de dirección.

¿Cuántos estados miembros de la UE han transpuesto NIS2?

A finales de mayo de 2026, 23 de los 27 estados miembros de la UE han transpuesto NIS2 a la legislación nacional, según el rastreador de mayo de 2026 de Cullen International. La transposición de Luxemburgo entró en vigor el 10 de mayo de 2026, elevando el total a 23. Cuatro estados miembros permanecen en el proceso legislativo, más de 19 meses después del plazo de transposición de octubre de 2024.

¿Qué es la Cyberbeveiligingswet de los Países Bajos?

La Cyberbeveiligingswet es la legislación nacional de los Países Bajos que implementa NIS2. La Cámara de Representantes neerlandesa aprobó el proyecto de ley en 2026 después de que los Países Bajos incumplieran el plazo de transposición original de la UE de octubre de 2024. El proyecto de ley todavía requiere la aprobación del Senado antes de poder entrar en vigor. El modelo de los Países Bajos utiliza una estructura de supervisión descentralizada, con reguladores específicos del sector manejando la aplicación.

Guía de cumplimiento NIS2: La hoja de ruta de gestión de acceso para 2026

Las credenciales robadas dominan las brechas de seguridad en 2026. El Artículo 21 de NIS2 exige 10 medidas de seguridad para eliminar los vectores de ataque basados en credenciales. Esta guía cubre los requisitos técnicos, la obligación de notificación de incidentes en 24 horas, los niveles de MFA de ENISA y una hoja de ruta de 5 fases para el cumplimiento listo para auditoría.

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

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

Bulgaria's NIS2 grace period ended on 1 June 2026 — board members now face full personal fines, not the discounted 50% rate that applied through May. Luxembourg's NIS2 Directive transposition law entered into force on 10 May 2026, leaving four member states still without implementing legislation. The EU's NIS Cooperation Group adopted common incident-reporting templates that the Commission intends to make mandatory through an implementing act.

This article covers every material NIS2 update from May 2026: what changed, which deadlines are live, and what your team needs to act on now.

Key takeaways

These NIS2 updates from May 2026 carry concrete compliance triggers: specific dates and specific obligations. Here is what changed.

• Bulgaria's full sanctions regime is active. From 1 June 2026, personal fines for management body members apply at 100% of statutory amounts — up to €5,000 per individual, separate from entity-level fines of up to €10 million. The 50% transitional discount is gone.
• Luxembourg's NIS2 law entered into force on 10 May 2026. In-scope entities have until 10 July 2026 to self-register with the ILR. Non-registration is itself a sanctionable breach.
• Four EU member states have still not transposed NIS2 — more than 19 months after the October 2024 deadline, according to Cullen International's May 2026 tracker.
• Common incident-reporting templates were adopted EU-wide. The NIS Cooperation Group agreed on standardised formats at its 39th plenary in Cyprus on 26 May 2026. A Commission implementing act will make them mandatory.
• ENISA's NIS360 2026 report identifies eight risk-zone sectors. Health, railway, maritime, ICT service management, space, public administration, drinking water, and wastewater show the lowest cybersecurity maturity relative to their criticality.
• The Netherlands advanced its delayed Cyberbeveiligingswet. The Dutch House of Representatives approved the bill on 15 April 2026; Senate approval remains pending.
• Ireland confirmed the National Cyber Security Bill as its NIS2 vehicle. The Department of Justice is drafting the legislation and placing the NCSC on a statutory footing.
• DigitalEurope called for deeper NIS2 harmonisation. The industry body published a formal position identifying scope, size thresholds, incident reporting, and conformity assessment as the areas most in need of standardisation across member states.

Bulgaria's full enforcement phase began 1 June 2026

Bulgaria's NIS2 enforcement entered its final phase on 1 June 2026. Fines and sanctions for all infringements now apply at their full statutory amounts — the 50% reduction that applied to violations committed before that date is gone.

The underlying legislation is the Law Amending and Supplementing the Cybersecurity Act, adopted by the 51st National Assembly on 5 February 2026 and promulgated in the State Gazette (issue 17) on 13 February 2026, entering into force on the same date.

Who is in scope

The Cybersecurity Act covers public and private entities in Annex I and Annex II sectors that meet or exceed medium-enterprise thresholds. Certain providers are in scope regardless of size: public electronic communications networks, trust service providers, top-level domain registries, DNS service providers, entities that are the sole provider of a critical service in Bulgaria, or whose disruption would significantly affect public order, public safety or health, or the economy.

Administrative bodies (including municipalities) are classified as essential entities under Article 4a(1)(4), regardless of size.

Full enforcement without a complete rulebook

One practical complication remains. The law explicitly delegates the definition of minimum cybersecurity measures for certain entity categories to a secondary ordinance of the Council of Ministers, to be proposed jointly by the Communications Regulation Commission and the Minister of e-Governance. That ordinance has not yet been published. Organizations entered the full enforcement phase without the complete operational rulebook the law itself anticipated.

That does not suspend the obligations. The primary law is in force, sanctions are real. Gap analysis against the existing NIS2 framework is both possible and advisable now, before supervisory pressure builds. ISO/IEC 27001 and ISO 22301 provide a workable baseline alongside the Cybersecurity Act's requirements.

What management bodies must now demonstrate

Bulgaria's Cybersecurity Act places explicit personal accountability on individual members of management bodies, not just on the organization as a legal entity. Management bodies must:

• Formally approve the cybersecurity risk-management measures required under Article 21
• Oversee implementation of those measures
• Complete cybersecurity training at least every two years
• Organize equivalent training for employees on a regular basis

The measures that boards must approve cover risk analysis and information security policies, incident handling, business continuity and crisis management, supply chain security, cyber hygiene practices, and multi-factor authentication where appropriate.

The personal fine structure

Where a management body member of an essential or important entity breaches these governance obligations, a personal fine of €500 to €5,000 may be imposed. This is separate from entity-level sanctions and stacks on top of them: up to €10 million or 2% of global turnover for essential entities, and up to €7 million or 1.4% for important entities.

The competent national authority can also request a court to impose a temporary prohibition on a natural person from exercising management functions in an essential entity.

The practical implication: a board member cannot delegate their way out of liability. Whether a fine is imposed, and how severe, will depend on the individual's ability to show tangible actions — board resolutions, adopted policies, audit protocols, assigned responsibilities, completed training, and documented corrective measures.

EU-wide: Common incident-reporting templates adopted

On 26 May 2026, the NIS Cooperation Group adopted common templates for NIS2 incident reporting at its 39th plenary meeting in Cyprus. The Group brings together EU member states, the European Commission, and ENISA.

The templates provide a standardised format for reporting cyber incidents across the EU. Until now, the absence of a common format meant that organizations operating in multiple member states had to navigate different national reporting forms, field sets, and submission portals — a significant administrative burden for any cross-border operation.

The Commission has stated it plans to adopt these templates through an implementing act, which would make them mandatory for all member states. Once that act is in force, the templates will establish a unified incident-reporting framework across the EU.

This development also connects to the broader Digital Omnibus proposal, which includes a single-entry point for incident reporting. The common templates are designed to align with that future architecture.

What this means for your incident response process: If your team has built notification workflows around a specific member state's current form, expect those workflows to be updated once the implementing act is published. The core NIS2 compliance timeline obligations under Article 23 (24-hour early warning, 72-hour incident notification, one-month final report) do not change. The format for submitting them does.

ENISA NIS360 2026: Eight sectors still in the risk zone

ENISA published the third edition of its NIS360 report on 28 May 2026. The report assesses cybersecurity maturity and criticality across all sectors of high criticality listed under Annex I of NIS2.

The 2026 assessment covers the full ecosystem of each sector (national authorities, regulated entities, and applicable EU legislation) rather than individual organizations. It identifies sectors where maturity has improved and sectors where the gap between criticality and actual security posture remains wide.

Eight sectors are identified as risk zones: health, railway, maritime, ICT service management, space, public administration, drinking water, and wastewater. These are sectors where the consequences of a successful attack are severe, but where the security baseline across the sector remains below what the threat level demands.

For IT and security leaders in these sectors, the NIS360 assessment is a useful benchmark. If your sector appears in the risk-zone list, expect heightened supervisory attention from national competent authorities — not because the report triggers enforcement directly, but because regulators use sector-level maturity data to prioritize their audit and inspection calendars.

Luxembourg: NIS2 law in force, registration deadline is 10 July 2026

Luxembourg published its NIS2 transposition law on 6 May 2026 in the Journal officiel du Grand-Duché de Luxembourg. The law entered into force on 10 May 2026, replacing the NIS1 law of 28 May 2019.

Who is in scope

NIS2 applies in Luxembourg to organizations with 50 or more employees or annual turnover exceeding €10 million, operating in one of 18 critical sectors. Size thresholds are assessed at consolidated group level: a subsidiary with 40 employees may still be in scope if the parent group exceeds the thresholds.

The two-tier structure

Essential entities — large organizations in Annex I sectors with more than 250 employees and either €50 million in turnover or €43 million in balance sheet — face proactive supervision and sanctions of up to €10 million or 2% of global turnover. Important entities — medium-sized Annex I organizations and all qualifying Annex II entities — face reactive supervision and sanctions of up to €7 million or 1.4% of global turnover.

Both tiers must implement the same ten categories of measures under Article 12: risk analysis, incident handling, business continuity, supply chain security, secure development, effectiveness assessment, cyber hygiene, cryptography, access control, and multi-factor authentication.

Incident reporting timelines

Luxembourg follows the NIS2 Article 23 structure exactly: 24-hour early warning, 72-hour formal notification, one-month final report. Missing any deadline is itself a sanctionable breach.

The 10 July 2026 self-registration deadline

Entities have until 10 July 2026 to self-register with their competent authority. The ILR (Institut Luxembourgeois de Régulation) acts as the competent authority for most sectors; the CSSF oversees banking and financial market infrastructure. Non-registration is a sanctionable breach under Article 11.

Management bodies must formally approve cybersecurity measures, supervise their implementation, and undergo regular training. For essential entities, senior managers can face a temporary ban from exercising management functions for serious failures.

Netherlands: Cyberbeveiligingswet reaches Senate plenary stage

The Dutch House of Representatives approved the Cyberbeveiligingswet (the Netherlands' NIS2 transposition law) on 15 April 2026 by 140 votes to 10. The bill has now advanced to the Senate plenary stage.

Where the bill stands

The Tweede Kamer passed the bill with broad cross-party support; only two parties voted against. The Senate committees responsible for digitalisation and justice completed their written review on 19 May 2026. The bill has since moved to the Senate plenary stage, where it awaits a final vote.

The bill is being processed in parallel with separate legislation transposing the EU's CER Directive on the resilience of critical entities.

Background

The Netherlands submitted the bill to parliament on 2 June 2025, missing the EU transposition deadline of 17 October 2024 by over a year. The bill spent nearly ten months in lower house procedure before passing.

Key provisions

Rather than creating a single national cybersecurity authority, the law assigns enforcement to existing sector-specific regulators — the energy regulator for energy companies, the healthcare regulator for hospitals, and so on. The exact date the law enters into force will be set by government decree after Senate approval, and different provisions may take effect on different dates.

What comes next

Senate approval is the last legislative step. Once the vote passes and the government sets an entry-into-force date, organizations in scope will face immediate compliance obligations — risk management measures, incident reporting, and management accountability requirements.

Ireland: National Cyber Security Bill confirmed as NIS2 vehicle

In a written parliamentary answer to Dáil Éireann (the lower house of the Irish parliament) on 13 May 2026, Ireland's Minister for Justice, Home Affairs and Migration confirmed that the Department of Justice is drafting the National Cyber Security Bill as the legislative vehicle for NIS2 transposition.

The Bill is listed as a priority for publication in the Summer 2026 legislation programme. It will appoint the National Cyber Security Centre (NCSC) as the national competent authority and as Ireland's Computer Security Incident Response Team (CSIRT). It will also place the NCSC on a statutory footing for the first time — the centre currently operates without a dedicated legislative basis.

Ireland missed the EU transposition deadline of 17 October 2024. A Cabinet decision in July 2024 directed priority drafting of the legislation, and work has been progressing since. The draft Bill has not yet been published, but the government released the General Scheme of the National Cyber Security Bill in September 2024, setting out its intended structure.

Management liability

Under NIS2 Article 20, as reflected in Head 28 of the General Scheme, management boards will be required to approve and oversee cybersecurity risk management measures, attend regular cybersecurity training, and may face personal liability for compliance failures — including temporary bans and administrative fines. The General Scheme defines "management board" as "a body or group of individuals vested with the authority and responsibility for the oversight, direction and control of an entity."

Sectoral regulators already active

Sectoral regulators have already been designated as National Competent Authorities and are preparing to take on supervision and enforcement functions. The NIS2 registration and incident reporting portals are not yet live — they will open once the legislation is enacted — but the NCSC has published draft Risk Management Measures guidance and the Cyber Fundamentals (CyFun) framework to help organizations prepare in the interim.

The Bill is also being developed alongside Ireland's third National Cyber Security Strategy, coordinated through an Inter-Departmental Committee chaired by the Department of Justice.

For organizations with Irish operations, the absence of enacted legislation does not remove the obligation to prepare. Sectoral NCAs are already active, and the Bill's enactment is described as a government priority.

DigitalEurope: NIS2 still needs deeper harmonisation

On 13 May 2026, DigitalEurope published a formal policy position on the EU cybersecurity package, covering the proposed Cybersecurity Act 2 (CSA2), the ICT supply chain security framework, and targeted NIS2 amendments.

On NIS2 specifically, DigitalEurope's position is direct: the targeted amendments proposed in the current package respond "minimally" to the concerns industry has raised over several years. The areas requiring more rigorous harmonisation are:

• Scope: NIS2 should focus on core business activities only, excluding ancillary operations that create disproportionate obligations.
• Size thresholds: National divergence in how thresholds are applied creates inconsistent coverage across member states.
• Incident reporting: Reporting fields, timelines, and submission processes still vary at national level — a problem the common templates (see above) partially address.
• Main establishment rules: Organizations operating across multiple member states face uncertainty about which national authority has primary jurisdiction.
• Conformity assessment: Requirements differ by member state, creating compliance complexity for cross-border operations.

DigitalEurope also called for ENISA to conduct impact assessments for all relevant EU cybersecurity legislation and to coordinate implementation more actively — positioning the agency as a coordination hub rather than a purely advisory body.

For compliance officers tracking the regulatory trajectory: the harmonisation gaps DigitalEurope identifies are real operational friction points. The common incident-reporting templates adopted on 26 May are a step toward closing one of them. The others will require either the implementing acts or the NIS2 amendment process to resolve.

What this means for your team right now

The May 2026 developments follow a pattern that has been consistent since enforcement began: the directive's text is stable, but the national implementation layer keeps moving. Bulgaria's full sanctions phase, Luxembourg's live registration deadline, and the pending Senate vote in the Netherlands all represent concrete compliance triggers, each with a specific date now attached.

The common incident-reporting templates are the most operationally significant EU-wide development of the period. Once the Commission implementing act is published, every organization's incident notification workflow will need to be updated to match the standardised format. Build that update into your incident response planning now, before an actual incident forces you to do it under pressure.

The ENISA NIS360 risk-zone list is worth taking seriously if your organization operates in health, public administration, or any of the other flagged sectors. Supervisory attention follows maturity gaps — and ENISA's assessment feeds directly into how national competent authorities prioritize their audit calendars.

Frequently asked questions

What happened with NIS2 in May 2026?

May 2026 saw four significant NIS2 developments: Luxembourg's transposition law entered into force on 10 May; the NIS Cooperation Group adopted common incident-reporting templates on 26 May; ENISA published the NIS360 2026 sector maturity assessment on 28 May; and the Netherlands advanced its Cyberbeveiligingswet through the House of Representatives. Bulgaria's full sanctions phase began on 1 June 2026, directly following the May period.

What is the Luxembourg NIS2 self-registration deadline?

Luxembourg's NIS2 transposition law, which entered into force on 10 May 2026, requires all in-scope entities to self-register with their competent authority by 10 July 2026. The ILR (Institut Luxembourgeois de Régulation) is the primary competent authority. Non-registration is a sanctionable breach under Article 11 of the transposition law.

What are the new NIS2 incident-reporting templates?

On 26 May 2026, the NIS Cooperation Group adopted common templates for NIS2 incident reporting at its 39th plenary meeting in Cyprus. The templates provide a standardised format for reporting cyber incidents across all EU member states. The European Commission plans to make them mandatory through an implementing act. The underlying NIS2 Article 23 timelines — 24-hour early warning, 72-hour notification, one-month final report — remain unchanged.

Which sectors does ENISA's NIS360 2026 identify as highest risk?

ENISA's NIS360 2026 report, published 28 May 2026, identifies eight sectors as risk zones where cybersecurity maturity remains low relative to criticality: health, railway, maritime, ICT service management, space, public administration, drinking water, and wastewater. These are all Annex I sectors under NIS2 and are subject to proactive supervision as essential entities.

What are the personal liability rules for managers under Bulgaria's NIS2?

Under Bulgaria's amended Cybersecurity Act, members of the management body of essential and important entities face personal fines of €500 to €5,000 for breaching their governance obligations — separate from entity-level fines. From 1 June 2026, these fines apply at full statutory amounts; the 50% transitional discount that applied to pre-June violations no longer exists. The competent authority can also seek a court-ordered temporary ban on a manager from exercising management functions.

How many EU member states have transposed NIS2?

As of late May 2026, 23 of 27 EU member states have transposed NIS2 into national law, according to Cullen International's May 2026 tracker. Luxembourg's transposition entered into force on 10 May 2026, bringing the total to 23. Four member states remain in the legislative process, more than 19 months after the October 2024 transposition deadline.

What is the Netherlands' Cyberbeveiligingswet?

The Cyberbeveiligingswet is the Netherlands' national legislation implementing NIS2. The Dutch House of Representatives approved the bill in 2026 after the Netherlands missed the original EU transposition deadline of October 2024. The bill still requires Senate approval before it can enter into force. The Netherlands' model uses a decentralised supervisory structure, with sector-specific regulators handling enforcement.

NIS2 compliance guide: The access management roadmap for 2026

Stolen credentials dominate breaches in 2026. NIS2 Article 21 mandates 10 security measures to eliminate credential-based attack vectors. This guide covers technical requirements, the 24-hour incident reporting obligation, ENISA’s MFA tiers, and a 5-phase roadmap to audit-ready compliance.

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

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

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

VaultJacking es una técnica de phishing que ataca la bóveda de Google Password Manager capturando el PIN que la desbloquea. Demostrada por PhishU el 20 de mayo de 2026, el ataque muestra cómo un único secreto de seis dígitos, capturado durante una sesión de phishing adversary-in-the-middle (AiTM), puede dar a un atacante acceso a cada contraseña y passkey sincronizada que la víctima haya almacenado en Google Password Manager.

Para las empresas, los riesgos son mayores de lo que parecen. La bóveda del navegador de un solo empleado puede contener credenciales SSO, acceso a consolas en la nube, inicios de sesión de plataformas financieras y claves de repositorios de código: todo en un solo lugar y expuesto por un único PIN capturado. Es un riesgo organizacional que queda fuera de la mayoría de los manuales de respuesta a incidentes existentes, y fuera de la visibilidad de la mayoría de los equipos de TI y seguridad.

Puntos clave

VaultJacking importa porque los gestores de contraseñas del navegador concentran contraseñas, passkeys y flujos de recuperación en un único objetivo de alto valor. Antes de continuar leyendo, esto es lo que necesita saber.

• VaultJacking ataca la capa de sincronización de la bóveda. El ataque no rompe la criptografía WebAuthn. Abusa del flujo de inscripción de dispositivos que gobierna quién puede leer la bóveda sincronizada.
• El PIN de Google Password Manager es un secreto de acceso a la bóveda. Google utiliza el PIN para proteger los datos de credenciales cifrados. Trátelo en consecuencia, no como un código desechable.
• Un único PIN capturado puede exponer toda la bóveda. La demostración de PhishU muestra que una única entrada de PIN puede permitir a un atacante descifrar cada contraseña y passkey sincronizada en infraestructura controlada por el operador.
• El riesgo empresarial escala con las brechas de gobernanza. La mezcla de perfiles personales y laborales, los perfiles de Chrome no gestionados y las credenciales privilegiadas almacenadas en bóvedas del navegador aumentan el radio de impacto.
• La respuesta a incidentes debe ir más allá de un restablecimiento de contraseña. Un evento sospechoso de VaultJacking requiere revisar dispositivos, sesiones, passkeys, contenidos de la bóveda e inicios de sesión posteriores, no solo cambiar una contraseña.

¿Qué es VaultJacking?

VaultJacking es una técnica de phishing que ataca la experiencia de acceso y recuperación de la bóveda de Google Password Manager. En lugar de robar una credencial de un sitio, el atacante captura el PIN de Google Password Manager durante una sesión de phishing AiTM y lo utiliza para inscribir un dispositivo controlado por el atacante en el dominio de seguridad de Google de la víctima, obteniendo acceso a toda la bóveda de credenciales sincronizadas. El término y la demostración completa se originan en la investigación publicada por PhishU.

El phishing tradicional de credenciales ataca una cuenta a la vez. VaultJacking es una clase diferente de ataque: el atacante evita las credenciales individuales por completo y va directamente al repositorio que las contiene todas.

La investigación de PhishU describe el ataque como totalmente consistente con el phishing AiTM estándar. El proxy AiTM captura el PIN junto con las cookies de sesión. Un proceso en segundo plano añade entonces una passkey propiedad del atacante a la cuenta de Google de la víctima para persistencia, se une al dominio de seguridad desde la infraestructura del atacante usando el PIN capturado, y descifra toda la bóveda. El operador ve cada credencial sincronizada en una sola vista.

Browser Syncjacking, una técnica separada que PhishU referencia, alcanza la misma capa de sincronización de Google mediante una extensión de navegador maliciosa. VaultJacking no requiere ni un punto de apoyo en el dispositivo ni una extensión.

¿Qué es el PIN de Google Password Manager?

El PIN de Google Password Manager es un secreto separado de la contraseña de su cuenta de Google y del bloqueo de pantalla de su dispositivo. La documentación de Google lo describe como una forma de proteger los datos cifrados de Google Password Manager, usar passkeys en un nuevo dispositivo y verificar la identidad.

Los usuarios frecuentemente confunden tres secretos diferentes, y esa confusión es parte de lo que hace efectivo a VaultJacking:

Verá el aviso del PIN de Google Password Manager al crear su primera passkey en un nuevo dispositivo, al acceder a credenciales guardadas cifradas en ciertos contextos de recuperación, o cuando un nuevo dispositivo se une a su dominio de seguridad de Google. Este último escenario es exactamente lo que VaultJacking explota.

La razón estructural por la que esto funciona, según el análisis de PhishU del código fuente de Chromium (chrome/browser/webauthn/enclave_manager.cc y components/trusted_vault/), es que el flujo de unión al dominio de seguridad de Google requiere dos verificaciones: un inicio de sesión en la cuenta de Google y una entrada exitosa del PIN. No hay aviso de aprobación entre dispositivos, ni notificación push a los dispositivos existentes, ni confirmación de «aprobar desde otro dispositivo».

El Llavero de iCloud de Apple requiere que los dispositivos existentes aprueben los nuevos. El modelo de Google no lo hace. Google hizo una elección deliberada de experiencia de usuario: un PIN con un límite de reintentos del lado del servidor es más fácil de recuperar que un modelo de aprobación por push cuando un usuario ha perdido todos sus dispositivos. VaultJacking es la consecuencia de esa decisión.

Cómo funciona la cadena de ataque de VaultJacking

Lo siguiente describe el ataque conceptualmente con fines defensivos. No se incluyen detalles de implementación ofensiva.

1. Señuelo. La víctima recibe un enlace de phishing y llega a una página que imita un flujo legítimo de inicio de sesión o cuenta de Google. Trate cualquier flujo de inicio de sesión inesperado que llegue por correo electrónico, chat o enlace de anuncio con sospecha.
2. Transferencia de confianza. El proxy AiTM presenta un aviso de PIN con el mismo estilo que la propia interfaz de Google: misma fuente, misma entrada de seis celdas, mismo texto. La educación del usuario debe cubrir los avisos de PIN del gestor de contraseñas, no solo las contraseñas y los códigos OTP.
3. Captura del PIN. La víctima introduce el PIN en el flujo de phishing. El PIN es un secreto de acceso a la bóveda, equivalente en sensibilidad a una contraseña maestra.
4. Inscripción del dispositivo del atacante. El atacante utiliza el PIN capturado para unirse al dominio de seguridad de Google de la víctima desde infraestructura controlada por el atacante. También se registra una passkey propiedad del atacante para persistencia. Revise los dispositivos conectados y las passkeys registradas inmediatamente después de cualquier contacto sospechoso de phishing.
5. Descifrado de la bóveda. El Security Domain Secret es liberado por el autenticador en la nube de Google, y el dispositivo del atacante descifra cada contraseña y passkey sincronizada. La bóveda puede contener credenciales para correo electrónico, SSO, consolas en la nube, plataformas financieras y repositorios de código.
6. Compromiso posterior. Las credenciales de terceros guardadas se utilizan contra otros servicios. Rote las credenciales de alto valor y monitorice los inicios de sesión de terceros.

PhishU probó esto de extremo a extremo contra cuentas reales de Google Password Manager, incluyendo la reproducción de passkeys de terceros capturadas independientemente de si la credencial original estaba respaldada por hardware. Trate esto como una técnica demostrada. No hay evidencia pública de explotación activa generalizada en el momento de escribir esto, pero la técnica no requiere acceso especializado ni punto de apoyo en el dispositivo.

¿VaultJacking significa que las passkeys están rotas?

No. VaultJacking no rompe la criptografía de las passkeys. Las passkeys se basan en autenticación de clave pública vinculada al origen según se define en la especificación W3C WebAuthn: la clave privada nunca sale del dispositivo, y la ceremonia de autenticación está vinculada al origen del sitio legítimo. Una página de phishing no puede reproducir una aserción WebAuthn contra el sitio real porque la verificación de origen falla. Esa protección se mantiene.

Lo que demuestra VaultJacking es que las passkeys no existen de forma aislada. Existen dentro de una bóveda, que se sincroniza entre dispositivos, que depende de un mecanismo de recuperación, que está gobernado por un PIN. El atacante evita la ceremonia criptográfica por completo al atacar la capa de gestión de la bóveda en su lugar.

Google describe las passkeys como una forma de iniciar sesión con huella dactilar, escaneo facial o bloqueo de pantalla — más simple y más seguro que las contraseñas. Esa descripción es precisa en la capa de autenticación por sitio. El problema que VaultJacking expone está un nivel más arriba: qué gobierna el acceso al almacén que contiene esas passkeys.

Por qué un único PIN puede crear un gran radio de impacto

Una bóveda de gestor de contraseñas es un almacén concentrado de accesos. Un único PIN capturado expone cada credencial que la víctima haya guardado en Google Password Manager.

El Informe del Panorama de Amenazas de Identidad 2025 de Recorded Future encontró que el dispositivo comprometido promedio proporcionaba 87 credenciales robadas, y que 276 millones de las credenciales indexadas en 2025 incluían cookies de sesión activas — lo que significa que los atacantes podían eludir completamente el MFA para esas cuentas.

El DBIR 2026 de Verizon pone el efecto posterior en contexto: el abuso de credenciales aparece en algún momento en el 39% de todas las brechas confirmadas, en más de 22.000 incidentes en 145 países. Los atacantes rara vez se detienen en la primera puerta que abre una credencial robada. Se mueven lateralmente, escalan privilegios y trabajan a través de cada inicio de sesión guardado hasta que encuentran algo valioso.

¿Quién está en mayor riesgo?

El riesgo se concentra donde se superponen tres condiciones: los datos de la bóveda del navegador son el almacén principal de credenciales, las credenciales de trabajo y personales comparten un perfil, y las credenciales privilegiadas han terminado en un sistema de nivel consumidor.

1. El problema de mezcla de credenciales. Los empleados guardan credenciales de trabajo en perfiles personales de Chrome. Los administradores no tienen visibilidad ni control sobre el contenido de la bóveda o los dispositivos sincronizados. Esto significa que las contraseñas corporativas viven fuera del perímetro de seguridad, respaldadas en los servidores de Google, y accesibles desde cualquier dispositivo en el que el empleado haya iniciado sesión.
2. Los usuarios privilegiados son el objetivo de mayor valor. Las contraseñas de administrador almacenadas en Google Password Manager representan la concentración de riesgo más peligrosa. Un compromiso de bóveda expone las llaves a plataformas de identidad, infraestructura en la nube, sistemas financieros y herramientas de seguridad. Una única cuenta de administrador comprometida se convierte en un punto de pivote para el movimiento lateral a través de toda la organización.
3. La formación en seguridad no cubre esta superficie de ataque. Los programas de concienciación de seguridad enseñan a los usuarios a reconocer correos de phishing y proteger códigos OTP. No enseñan a los usuarios a reconocer los avisos de PIN del gestor de contraseñas como objetivos sensibles. Los usuarios ven una solicitud de PIN y cumplen — no lo ven como un evento de seguridad que debería activar el escepticismo.
4. Las brechas de políticas dejan las credenciales en el lugar equivocado. La mayoría de las organizaciones no tienen una política que separe las bóvedas del navegador de la gestión de credenciales empresariales. Las credenciales compartidas, contraseñas de administrador y cuentas de emergencia pueden almacenarse donde los empleados encuentren conveniente. No existe un registro de auditoría que muestre dónde viven estas credenciales o quién las ha accedido.
5. Los procesos de revisión de dispositivos y sesiones son demasiado lentos. La inscripción sospechosa de dispositivos o el acceso a la bóveda puede pasar desapercibido durante semanas.

El último punto importa más de lo que podría parecer. PhishU señala que Google envía un único correo electrónico de «nuevo inicio de sesión en Windows» cuando un nuevo dispositivo se une al dominio de seguridad — la misma notificación enviada para cualquier nuevo inicio de sesión en Chrome. No se dispara ninguna notificación push en los dispositivos existentes. En un compromiso AiTM donde el atacante también ha capturado la sesión del buzón de la víctima, ese correo puede ser suprimido antes de que el usuario lo vea.

Qué hacer si un PIN de Google Password Manager puede haber sido phisheado

No trate un evento sospechoso de VaultJacking como un incidente de una sola contraseña. Trátelo como posible exposición de la bóveda hasta que se demuestre lo contrario.

La siguiente secuencia de triaje es para equipos de seguridad e individuos. Los nombres de eventos de Google Workspace deben verificarse contra la documentación actual del Administrador de Google antes de construir detección automatizada.

Los pasos 5 y 7 son donde la mayoría de las respuestas a incidentes fallan. Rotar la contraseña de la cuenta de Google sin rotar las credenciales posteriores que protege es como cambiar la cerradura de una caja fuerte después de que el contenido ya haya sido fotografiado.

Passwork le proporciona visibilidad de cada credencial, quién accedió a ella y cuándo. El control de acceso basado en roles significa que las credenciales compartidas permanecen en un solo lugar con un registro de auditoría completo — no dispersas en perfiles de navegador personales. Explore cómo funciona

Cómo los individuos pueden reducir el riesgo de VaultJacking

El consejo práctico aquí es breve. La mayor parte se reduce a tratar el PIN de Google Password Manager de la misma manera que trataría una contraseña maestra.

• No introduzca el PIN de Google Password Manager en ninguna página a la que haya llegado haciendo clic en un enlace de correo electrónico, chat o anuncio. Navegue directamente a la configuración de la cuenta de Google.
• Revise sus dispositivos conectados y passkeys registradas en myaccount.google.com periódicamente. Un dispositivo o passkey desconocido vale la pena investigar.
• Mantenga los perfiles de navegador personales y de trabajo separados. Si un perfil personal se ve comprometido, las credenciales de trabajo no deberían estar en el radio de impacto.
• Evite guardar credenciales de administrador o privilegiadas altamente sensibles en una bóveda de navegador de consumidor. Esas credenciales necesitan auditabilidad y controles de acceso que las bóvedas del navegador no proporcionan.
• Continúe usando passkeys. Siguen siendo más seguras que las contraseñas reutilizables en la capa por sitio. Solo comprenda qué avisos son legítimos y cuáles no.

Controles empresariales y recomendaciones de políticas

El Informe de Tendencias de Inicio de Sesión Seguro 2025 de Okta encontró que la adopción de autenticadores resistentes al phishing creció del 8,6% al 14,0% de usuarios en un año — un aumento del 63%. Ese crecimiento es una buena noticia. El problema de gobernanza es que las organizaciones están adoptando passkeys más rápido de lo que están construyendo las políticas para gestionar las bóvedas que las almacenan.

Los siguientes controles son proporcionales a la sensibilidad de las credenciales involucradas. No todas las organizaciones necesitan todos los controles, pero toda organización que almacene credenciales privilegiadas en bóvedas del navegador necesita una política que aborde eso específicamente.

• Gobernanza del perfil del navegador. Imponga perfiles de trabajo gestionados separados. Desaconseje la mezcla de bóvedas personales y de trabajo a través de políticas y educación del usuario.
• Almacenamiento de credenciales privilegiadas. Prohíba almacenar credenciales de administrador, emergencia, root de nube, finanzas y cuentas de servicio en bóvedas de navegador no gestionadas. Las bóvedas del navegador son convenientes para uso personal. No están diseñadas para credenciales compartidas, acceso privilegiado o registros de auditoría.
• Gestión empresarial de contraseñas. Use un gestor de contraseñas empresarial dedicado para credenciales compartidas, privilegiadas y auditadas. Passwork es una solución autoalojada construida exactamente para esta separación: credenciales privilegiadas en una bóveda controlada y auditable con control de acceso basado en roles, integración AD/LDAP y registro de auditoría completo.
• MFA resistente al phishing. Continúe adoptando WebAuthn y FIDO2. Extienda la educación del usuario para cubrir flujos de recuperación y avisos de bóveda, no solo contraseñas y códigos OTP.
• Visibilidad de dispositivos y sesiones. Monitorice inscripciones de dispositivos desconocidos, actividad de sesión inusual y cambios inesperados en la seguridad de la cuenta. Google envía un correo de «nuevo inicio de sesión» para cualquier nuevo inicio de sesión en Chrome. En un compromiso AiTM donde el atacante también ha capturado la sesión del buzón de la víctima, ese correo puede ser suprimido antes de que el usuario lo vea.
• Respuesta a incidentes. Construya un manual de exposición de bóveda que incluya rotación de credenciales, revocación de sesiones, revisión de passkeys y monitorización de cuentas de terceros.
• Concienciación de seguridad. Capacite a los usuarios de que los PINs, avisos del gestor de contraseñas y flujos de recuperación son objetivos de phishing. Conllevan el mismo riesgo que las contraseñas y los códigos OTP.

El punto sobre el gestor de contraseñas empresarial merece énfasis. Las bóvedas del navegador son convenientes y mejoran la unicidad de las contraseñas para muchos usuarios. No están diseñadas para credenciales compartidas, acceso privilegiado o registros de auditoría.

Por qué un gestor de contraseñas empresarial es más seguro que una bóveda del navegador para credenciales de trabajo

Un gestor de contraseñas del navegador resuelve un problema de conveniencia personal: autocompletado, sincronización entre dispositivos, almacenamiento sin esfuerzo. Para un usuario individual, esa es una elección razonable. Para un entorno corporativo, esa misma simplicidad se convierte en una vulnerabilidad estructural.

Passwork es la alternativa empresarial a las bóvedas personales del navegador. La extensión de navegador de Passwork funciona exactamente como un gestor de contraseñas integrado del navegador — autocompleta inicios de sesión en sitios web, ofrece guardar nuevas credenciales — pero las almacena en una bóveda corporativa protegida en lugar de un perfil personal del navegador.

Passwork soporta despliegue autoalojado, cifrado AES-256, integración con Active Directory y LDAP, autorización SSO, control de acceso basado en roles, registro de auditoría completo, integración SIEM y herramientas REST API y CLI para flujos de trabajo DevOps.

La diferencia es arquitectónica. Una bóveda del navegador prioriza la conveniencia individual. Un gestor de contraseñas empresarial prioriza el control y la visibilidad organizacional. Cuando las credenciales privilegiadas terminan en una bóveda del navegador, se ha elegido la herramienta incorrecta para el trabajo — no porque la herramienta sea mala, sino porque fue diseñada para un problema diferente.

Conclusión: Qué hacer ante VaultJacking

La amenaza que describe VaultJacking es específica: una técnica de phishing que convierte un único PIN capturado en exposición de credenciales a nivel de bóveda. La respuesta debe ser igualmente específica — no pánico sobre las passkeys, y no descarte del riesgo de la bóveda del navegador, sino una política clara que separe la conveniencia de credenciales personales de la gobernanza de credenciales privilegiadas.

Comience con la auditoría. Descubra qué credenciales privilegiadas viven actualmente en bóvedas del navegador. ¿Qué cuentas de administrador están sincronizadas con dispositivos personales? ¿Qué credenciales de emergencia están almacenadas en Google Password Manager? Esa respuesta le dirá cuánto trabajo hay por hacer.

A partir de ahí, el camino es directo: prohíba las credenciales privilegiadas en bóvedas del navegador, muévalas a un gestor de contraseñas empresarial con registros de auditoría y controles de acceso, y extienda su formación de concienciación de seguridad para cubrir avisos de bóveda y flujos de recuperación.

VaultJacking no es una razón para abandonar los gestores de contraseñas del navegador. Es una razón para usarlos para lo que fueron diseñados — credenciales personales — y para construir un sistema separado y auditable para todo lo demás.

Passwork es un gestor de contraseñas y secretos empresarial autoalojado construido para la gobernanza de credenciales privilegiadas. Proporciona acceso basado en roles, registros de auditoría completos y separación total de las bóvedas de navegador de consumidor. Vea cómo encaja en su infraestructura

Preguntas frecuentes

¿Qué es VaultJacking?

VaultJacking es una técnica de phishing que ataca la bóveda de Google Password Manager capturando el PIN de Google Password Manager del usuario durante una sesión de phishing adversary-in-the-middle. El PIN capturado se utiliza para inscribir un dispositivo controlado por el atacante en el dominio de seguridad de Google de la víctima, descifrando cada contraseña y passkey sincronizada almacenada en la bóveda. La técnica fue demostrada de extremo a extremo por PhishU en mayo de 2026.

¿Es VaultJacking una vulnerabilidad de Google?

Según los informes publicados, VaultJacking es una técnica demostrada de phishing y abuso de flujos de trabajo, no una vulnerabilidad clasificada en los sistemas de Google. Explota el diseño del flujo de inscripción de dispositivos de Google — específicamente la ausencia de aprobación entre dispositivos para nuevas uniones al dominio de seguridad — que Google eligió deliberadamente como una decisión de experiencia de usuario para la recuperación de dispositivos perdidos. Si Google clasifica esto como una vulnerabilidad que requiere una corrección es una cuestión separada que no ha sido respondida públicamente en el momento de escribir esto.

¿VaultJacking rompe las passkeys?

No. Las passkeys se basan en criptografía de clave pública vinculada al origen según se define en la especificación W3C WebAuthn. Una página de phishing no puede reproducir una aserción WebAuthn contra el sitio real porque la vinculación al origen falla. VaultJacking ataca la capa de bóveda y recuperación que almacena las passkeys — no la ceremonia de autenticación criptográfica en sí. Las passkeys siguen siendo resistentes al phishing en la capa de inicio de sesión por sitio.

¿Qué es el PIN de Google Password Manager?

El PIN de Google Password Manager es un secreto que protege los datos cifrados de Google Password Manager. Según la documentación de Google, se crea cuando un usuario guarda su primera passkey en un ordenador, iPhone o iPad, y se utiliza para acceder a passkeys en nuevos dispositivos, verificar la identidad y asegurar que ni siquiera Google pueda leer el contenido cifrado de la bóveda. Es distinto de la contraseña de la cuenta de Google y del bloqueo de pantalla del dispositivo.

¿Puede un único PIN exponer todas mis contraseñas guardadas?

La demostración de PhishU muestra que un PIN de Google Password Manager de seis dígitos capturado puede permitir a un atacante descifrar toda la bóveda sincronizada — cada contraseña guardada y cada passkey sincronizada — desde infraestructura controlada por el atacante. El PIN libera el Security Domain Secret, que descifra la bóveda en una sola operación. Si introdujo el PIN en una página a la que no navegó directamente, trátelo como posible exposición completa de la bóveda.

¿Qué debo hacer si introduje el PIN en una página sospechosa?

Revise sus dispositivos conectados y passkeys registradas en myaccount.google.com inmediatamente. Revoque cualquier dispositivo o sesión desconocida. Cambie su contraseña de la cuenta de Google. Rote las credenciales de alto valor guardadas en la bóveda — priorice SSO, correo electrónico, consolas en la nube, plataformas financieras y cuentas de administrador. Compruebe los servicios de terceros en busca de actividad de inicio de sesión inusual. Si está en una organización, abra un caso de respuesta a incidentes en lugar de tratar esto como un problema de una sola cuenta.

¿Deberían las empresas prohibir Google Password Manager?

Una prohibición general no es la política correcta para la mayoría de las organizaciones. Un enfoque basado en riesgos funciona mejor: restrinja el almacenamiento de credenciales privilegiadas y compartidas a un gestor de contraseñas empresarial con controles de auditoría, imponga perfiles de navegador gestionados separados para uso laboral, y extienda la formación de concienciación sobre phishing para cubrir avisos del gestor de contraseñas y flujos de recuperación. Google Password Manager es apropiado para credenciales personales; no está diseñado para cuentas de emergencia o acceso de administrador compartido.

¿Son las llaves de seguridad de hardware suficientes para detener esto?

Las llaves de seguridad de hardware fortalecen la garantía de inicio de sesión de la cuenta de Google, pero no gobiernan automáticamente la sincronización de la bóveda del navegador, los flujos de recuperación o las credenciales almacenadas dentro de la bóveda. VaultJacking ataca la capa de gestión de la bóveda, no el paso de inicio de sesión de la cuenta. Una llave de hardware en la cuenta de Google reduce el riesgo de toma de control de la cuenta pero no impide que un usuario sea engañado para introducir su PIN de Google Password Manager en una página de phishing.

Gestión de contraseñas y accesos para pymes: ¿Es KeePass suficiente?

¿Usa KeePass para su equipo? Descubra los riesgos ocultos de KeePass para pymes en 2026 — fallos de sincronización, brechas de cumplimiento y cuándo cambiar a un gestor de contraseñas corporativo.

Passwork BlogAlex Muntyan

Passwork gana Top Performer primavera 2026 en SourceForge

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

Passwork BlogAlex Muntyan

Ciclo de vida de la rotación de secretos: De la creación a la revocación

La rotación de secretos falla cuando se trata como una tarea programada en lugar de un ciclo de vida. Esta guía cubre las siete etapas — desde la creación y propiedad hasta la rotación segura, revocación de emergencia y evidencia de auditoría.

Passwork BlogAlex Muntyan

VaultJacking is a phishing technique that targets the Google Password Manager vault by capturing the PIN that unlocks it. Demonstrated by PhishU on May 20, 2026, the attack shows how a single six-digit secret, captured during an adversary-in-the-middle (AiTM) phishing session, can give an attacker access to every synced password and passkey a victim has stored in Google Password Manager.

For businesses, the stakes are higher than they appear. A single employee's browser vault can hold SSO credentials, cloud console access, finance platform logins, and code repository keys: all in one place and exposed by one captured PIN. It is an organizational risk that sits outside most existing incident-response playbooks, and outside the visibility of most IT and security teams.

Key takeaways

VaultJacking matters because browser password managers concentrate passwords, passkeys, and recovery flows into a single high-value target. Before reading further, here is what you need to know.

• VaultJacking targets the vault sync layer. The attack does not break WebAuthn cryptography. It abuses the device-enrollment flow that governs who can read the synced vault.
• The Google Password Manager PIN is a vault-access secret. Google uses the PIN to protect encrypted credential data. Treat it accordingly, not as a throwaway code.
• One captured PIN can expose the entire vault. PhishU's demonstration shows that a single PIN entry can allow an attacker to decrypt every synced password and passkey on operator-controlled infrastructure.
• Enterprise risk scales with governance gaps. Personal/work profile mixing, unmanaged Chrome profiles, and privileged credentials stored in browser vaults all increase the blast radius.
• Incident response must go beyond a password reset. A suspected VaultJacking event requires reviewing devices, sessions, passkeys, vault contents, and downstream logins, not just changing one password.

What is VaultJacking?

VaultJacking is a phishing technique that targets the Google Password Manager vault access and recovery experience. Instead of stealing one site credential, the attacker captures the Google Password Manager PIN during an AiTM phishing session and uses it to enroll an attacker-controlled device into the victim's Google security domain, gaining access to the entire synced credential vault. The term and the end-to-end demonstration originate from PhishU's published research.

Traditional credential phishing targets one account at a time. VaultJacking is a different class of attack: the attacker bypasses individual credentials entirely and goes straight for the repository that holds all of them.

PhishU's research describes the attack as fully consistent with standard AiTM phishing. The AiTM proxy captures the PIN alongside session cookies. A background worker then adds an attacker-owned passkey to the victim's Google account for persistence, joins the security domain from attacker infrastructure using the captured PIN, and decrypts the entire vault. The operator sees every synced credential in a single view.

Browser Syncjacking, a separate technique PhishU references, reaches the same Google sync layer via a malicious browser extension. VaultJacking requires neither a device foothold nor an extension.

What is the Google Password Manager PIN?

The Google Password Manager PIN is a separate secret from your Google account password and your device screen lock. Google's documentation describes it as a way to protect encrypted Google Password Manager data, use passkeys on a new device, and verify identity.

Users frequently confuse three different secrets, and that confusion is part of what makes VaultJacking effective:

You will see the Google Password Manager PIN prompt when creating your first passkey on a new device, when accessing encrypted saved credentials in certain recovery contexts, or when a new device joins your Google security domain. That last scenario is exactly what VaultJacking exploits.

The structural reason this works, according to PhishU's analysis of the Chromium source (chrome/browser/webauthn/enclave_manager.cc and components/trusted_vault/), is that Google's security domain join flow requires two checks: a Google account sign-in and a successful PIN entry. There is no cross-device approval prompt, no push notification to existing devices, no "approve from another device" confirmation.

Apple's iCloud Keychain requires existing devices to approve new ones. Google's model does not. Google made a deliberate UX trade-off: a PIN with a server-side retry cap is easier to recover from than a push-to-approve model when a user has lost all their devices. VaultJacking is the consequence of that trade-off.

How the VaultJacking attack chain works

The following describes the attack conceptually for defensive purposes. No offensive implementation details are included.

1. Lure. The victim receives a phishing link and lands on a page that imitates a legitimate Google sign-in or account workflow. Treat any unexpected sign-in flow arriving via email, chat, or ad link with suspicion.
2. Trust transfer. The AiTM proxy renders a PIN prompt styled to match Google's own interface: same font, same six-cell input, same copy. User education must cover password-manager PIN prompts, not only passwords and OTP codes.
3. PIN capture. The victim enters the PIN into the phishing flow. The PIN is a vault-access secret, equivalent in sensitivity to a master password.
4. Attacker device enrollment. The attacker uses the captured PIN to join the victim's Google security domain from attacker-controlled infrastructure. An attacker-owned passkey is also registered for persistence. Review signed-in devices and registered passkeys immediately after any suspected phishing contact.
5. Vault decryption. The Security Domain Secret is released by Google's cloud authenticator, and the attacker's device decrypts every synced password and passkey. The vault may contain credentials for email, SSO, cloud consoles, financial platforms, and code repositories.
6. Downstream compromise. Saved third-party credentials are used against other services. Rotate high-value credentials and monitor third-party logins.

PhishU tested this end to end against live Google Password Manager accounts, including replay of captured third-party passkeys regardless of whether the original credential was hardware-backed. Treat this as a demonstrated technique. There is no public evidence of widespread active exploitation at the time of writing, but the technique requires no specialized access or device foothold.

Does VaultJacking mean passkeys are broken?

No. VaultJacking does not break passkey cryptography. Passkeys are based on origin-bound public-key authentication as defined in the W3C WebAuthn specification: the private key never leaves the device, and the authentication ceremony is bound to the legitimate site origin. A phishing page cannot replay a WebAuthn assertion against the real site because the origin check fails. That protection holds.

What VaultJacking demonstrates is that passkeys do not exist in isolation. They exist inside a vault, which syncs across devices, which relies on a recovery mechanism, which is governed by a PIN. The attacker bypasses the cryptographic ceremony entirely by targeting the vault management layer instead.

Google describes passkeys as a way to sign in with a fingerprint, face scan, or screen lock — simpler and safer than passwords. That description is accurate at the per-site authentication layer. The issue VaultJacking surfaces is one level up: what governs access to the store that holds those passkeys.

Why one PIN can create a large blast radius

A password-manager vault is a concentrated store of access. One captured PIN exposes every credential the victim has ever saved in Google Password Manager.

Recorded Future's 2025 Identity Threat Landscape Report found that the average compromised device yielded 87 stolen credentials, and that 276 million of the credentials indexed in 2025 included active session cookies — meaning attackers could bypass MFA entirely for those accounts.

Verizon's 2026 DBIR puts the downstream effect in context: credential abuse appears at some point in 39% of all confirmed breaches, across more than 22,000 incidents in 145 countries. Attackers rarely stop at the first door a stolen credential opens. They move laterally, escalate privileges, and work through every saved login until they hit something valuable.

Who is most at risk?

Risk concentrates where three conditions overlap: browser vault data is the primary credential store, work and personal credentials share a profile, and privileged credentials have ended up in a consumer-grade system.

1. The credential mixing problem. Employees save work credentials in personal Chrome profiles. Admins have no visibility or control over vault contents or synced devices. This means corporate passwords live outside the security perimeter, backed up to Google's servers, and accessible from any device the employee has ever logged into.
2. Privileged users are the highest-value target. Admin passwords stored in Google Password Manager represent the most dangerous concentration of risk. One vault compromise exposes the keys to identity platforms, cloud infrastructure, finance systems, and security tooling. A single compromised admin account becomes a pivot point for lateral movement across the entire organization.
3. Security training doesn't cover this attack surface. Security awareness programs teach users to recognize phishing emails and protect OTP codes. They don't teach users to recognize password-manager PIN prompts as sensitive targets. Users see a PIN request and comply — they don't see it as a security event that should trigger skepticism.
4. Policy gaps leave credentials in the wrong place. Most organizations have no policy separating browser vaults from enterprise credential management. Shared credentials, admin passwords, and break-glass accounts may be stored wherever employees find it convenient. No audit trail exists to show where these credentials live or who has accessed them.
5. Device and session review processes are too slow. Suspicious device enrollment or vault access may go unnoticed for weeks.

The last point matters more than it might appear. PhishU notes that Google sends a single "new sign-in on Windows" email when a new device joins the security domain — the same notification sent for any new Chrome login. No push notification fires on existing devices. In an AiTM engagement where the attacker has also captured the victim's inbox session, that email can be suppressed before the user sees it.

What to do if a Google Password Manager PIN may have been phished

Do not treat a suspected VaultJacking event as a single-password incident. Treat it as possible vault exposure until proven otherwise.

The following triage sequence is for security teams and individuals. Google Workspace event names should be verified against current Google Admin documentation before building automated detection.

Steps 5 and 7 are where most incident responses fall short. Rotating the Google account password without rotating the downstream credentials it protects is like changing the lock on a safe after the contents have already been photographed.

Passwork gives you visibility into every credential, who accessed it, and when. Role-based access means shared credentials stay in one place with a complete audit trail — not scattered across personal browser profiles. Explore how it works

Stopping the breach: step-by-step technical response

When a VaultJacking event is suspected, the first 60 minutes determine how far the damage spreads. These steps are for security engineers and IT administrators. Execute them in order — later steps depend on evidence preserved in earlier ones.

1. Force sign-out of all active sessions. Navigate to myaccount.google.com/security → "Manage all devices" → revoke every session you cannot physically account for. Do not delegate this to the affected user — do it from an admin console where possible. Session revocation cuts off an attacker who has vault access but has not yet finished extracting credentials.
2. Audit registered passkeys before revoking anything else. Go to myaccount.google.com/security → "Passkeys and security keys." Screenshot the full list first, then revoke every entry the user cannot identify by device name and registration date. An attacker-registered passkey survives a password reset and re-establishes persistence. PhishU's research confirms that the background worker registers an operator-owned passkey as part of the standard VaultJacking flow — persistence is built in by design.
3. Pull the Google Workspace audit log. In admin.google.com → Reports → Audit → Login, filter for the affected user's account within the 24-hour window around the reported phishing event. Look for any login_type event combined with a source IP outside your organization's known ranges. A new device enrollment from an unrecognized IP within minutes of a phishing click timestamp is a strong indicator of vault compromise. Verify current Google Workspace event field names against Google Admin SDK documentation before building automated queries.
4. Configure a SIEM alert for future detection. Create a high-priority correlation rule: new Google account device enrollment event + source IP not in corporate IP allowlist + time delta under 10 minutes from a known phishing click. Most organizations currently have no detection for vault-layer events — this rule closes that gap. F5 Labs' threat bulletin format recommends building SIEM detection rules tied to specific behavioral indicators rather than relying on email notifications alone.
5. Rotate credentials in strict priority order. Do not rotate in bulk without logging each action — you need the audit trail for the incident report and for downstream notification decisions.
   1. SSO and identity provider accounts
   2. Cloud console root and admin credentials
   3. Code repository tokens and CI/CD pipeline secrets
   4. Finance and payroll platform logins
   5. VPN and remote access credentials
   6. Any break-glass or shared service accounts stored in the vault
6. Check downstream third-party services. Review login events from the affected account on all third-party services for the 48-hour window after the phishing event. Attackers typically test saved credentials within hours of vault access. Verizon's 2026 DBIR found credential abuse appears in 39% of confirmed breaches — lateral movement through saved logins is the expected next step, not an edge case.
7. Step 7. Preserve forensic evidence before full remediation. Screenshot the device list, export the audit log, record the phishing URL and timestamp, and document which credentials were in the vault at the time of the event. Revocation destroys attacker persistence — but it also destroys some evidence. Preserve first, remediate second.

Passwork gives your security team a full audit log of every credential access event — who opened what, when, and from which device. When an incident happens, you have the evidence trail ready. See how it works

How individuals can reduce VaultJacking risk

The practical advice here is short. Most of it comes down to treating the Google Password Manager PIN the same way you would treat a master password — because functionally, it is one.

• Do not enter the Google Password Manager PIN into any page you reached by clicking a link in email, chat, or an ad. Navigate to Google account settings directly by typing myaccount.google.com into the address bar.
• Review your signed-in devices and registered passkeys at myaccount.google.com periodically. An unfamiliar device or a passkey you do not recognize is worth investigating — not ignoring. PhishU's research shows that attacker-registered passkeys are added silently, with no notification to existing devices and no push prompt.
• Keep personal and work browser profiles separate. If a personal profile is compromised, work credentials should not be in the blast radius. Okta's 2025 Secure Sign-in Trends Report found phishing-resistant authenticator adoption grew from 8.6% to 14.0% in one year — but adoption at the authentication layer does not protect a vault that is governed by a PIN.
• Avoid saving highly sensitive admin or privileged credentials in a consumer browser vault. Those credentials need auditability and access controls that browser vaults do not provide. Continue using passkeys — they remain safer than reusable passwords at the per-site layer. The issue is not passkeys. The issue is what governs the store that holds them.

Building the controls that prevent the next one: policy and governance checklist

Okta's 2025 Secure Sign-in Trends Report found that phishing-resistant authenticator adoption grew from 8.6% to 14.0% of users in one year — a 63% increase. That growth is real progress. The governance gap is that organizations are adopting passkeys faster than they are building policies to manage the vaults that store them.

The following steps are proportional to the sensitivity of credentials involved. Not every organization needs every control. Every organization that stores privileged credentials in browser vaults needs a policy that addresses that specifically.

1. Audit which privileged credentials currently live in browser vaults. Use your MDM or endpoint tooling to identify Chrome profile sync status on all managed devices. If you cannot answer "which admin accounts are synced to personal Google profiles," that is the first gap to close — before writing any policy.
2. Write a policy that names specific credential categories. Prohibit storage of break-glass accounts, admin credentials, shared service accounts, cloud-root credentials, and CI/CD secrets in any consumer browser vault. A policy that says "sensitive data" without naming categories produces inconsistent compliance. Name the categories. Set an enforcement date.
3. Migrate covered credentials before the enforcement date. A policy without a migration path produces shadow credential stores. Move all credentials covered by Step 2 into an enterprise password manager with role-based access control and a full audit log before the policy takes effect. Passwork supports self-hosted deployment with AES-256 encryption, AD/LDAP integration, and complete audit logging — built specifically for this separation between privileged corporate credentials and personal browser convenience.
4. Enforce separate managed browser profiles for work use. Prevent personal and work vault mixing through MDM policy and user education. When a personal profile is compromised, work credentials should not be in scope. This is a configuration change, not just a recommendation.
5. Update phishing awareness training to cover vault prompts. Security awareness programs teach users to recognize phishing emails and protect OTP codes. They do not teach users that a password-manager PIN prompt carries the same risk as a master password. Add vault prompts, recovery flows, and PIN requests to your training curriculum explicitly. Users who understand what the PIN unlocks are significantly harder to VaultJack.
6. Build a vault-exposure runbook into your incident response plan. The runbook must cover: session revocation, device enrollment audit, passkey review, downstream credential rotation, and third-party account monitoring — as a single coordinated response. Walk through detection, containment, and rotation. Identify which steps your team cannot currently execute.
7. Configure detection for new device enrollments on privileged accounts. Set your CASB or identity platform to alert on new Google account device enrollments from unmanaged or unrecognized devices for all users with privileged access.
8. Review browser profile governance quarterly. Employees change roles, devices, and credential habits faster than annual reviews capture. A quarterly check on which managed devices have Chrome sync enabled and what profile type is active costs less than one vault-exposure incident response.

Why an enterprise password manager is safer than a browser vault for work credentials

A browser password manager solves a personal convenience problem: autofill, device sync, effortless storage. For an individual user, that is a reasonable choice. For a corporate environment, that same simplicity becomes a structural vulnerability.

Passwork is the enterprise alternative to personal browser vaults. The Passwork browser extension works exactly like a built-in browser password manager — it autofills logins on websites, offers to save new credentials — but stores them in a protected corporate vault instead of a personal browser profile.

Passwork supports self-hosted deployment, AES-256 encryption, Active Directory and LDAP integration, SSO authorization, role-based access control, full audit logging, SIEM integration, and REST API and CLI tools for DevOps workflows.

The difference is architectural. A browser vault prioritizes individual convenience. An enterprise password manager prioritizes organizational control and visibility. When privileged credentials end up in a browser vault, you have chosen the wrong tool for the job — not because the tool is bad, but because it was designed for a different problem.

Conclusion: What to do about VaultJacking

The threat VaultJacking describes is specific: a phishing technique that turns one captured PIN into vault-wide credential exposure. The response should be equally specific — not panic about passkeys, and not dismissal of browser vault risk, but a clear-eyed policy that separates personal credential convenience from privileged credential governance.

Start with the audit. Find out which privileged credentials currently live in browser vaults.Which admin accounts are synced to personal devices? Which break-glass credentials are stored in Google Password Manager? That answer will tell you how much work there is to do.

From there, the path is straightforward: prohibit privileged credentials in browser vaults, move them to an enterprise password manager with audit trails and access controls, and extend your security awareness training to cover vault prompts and recovery flows.

VaultJacking is not a reason to abandon browser password managers. It is a reason to use them for what they were designed for — personal credentials — and to build a separate, auditable system for everything else.

Passwork is a self-hosted enterprise password and secrets manager built for privileged credential governance. It provides role-based access, full audit logs, and complete separation from consumer browser vaults. See how it fits into your infrastructure

Frequently Asked Questions

What is VaultJacking?

VaultJacking is a phishing technique that targets the Google Password Manager vault by capturing the user's Google Password Manager PIN during an adversary-in-the-middle phishing session. The captured PIN is used to enroll an attacker-controlled device into the victim's Google security domain, decrypting every synced password and passkey stored in the vault. The technique was demonstrated end to end by PhishU in May 2026.

Is VaultJacking a Google vulnerability?

Based on published reporting, VaultJacking is a demonstrated phishing and workflow-abuse technique, not a classified vulnerability in Google's systems. It exploits the design of Google's device-enrollment flow — specifically the absence of cross-device approval for new security domain joins — which Google chose deliberately as a UX trade-off for lost-device recovery. Whether Google classifies this as a vulnerability requiring a fix is a separate question that has not been publicly answered at the time of writing.

Does VaultJacking break passkeys?

No. Passkeys are based on origin-bound public-key cryptography as defined in the W3C WebAuthn specification. A phishing page cannot replay a WebAuthn assertion against the real site because the origin binding fails. VaultJacking targets the vault and recovery layer that stores passkeys — not the cryptographic authentication ceremony itself. Passkeys remain phishing-resistant at the per-site login layer.

What is the Google Password Manager PIN?

The Google Password Manager PIN is a secret that protects encrypted Google Password Manager data. According to Google's documentation, it is created when a user saves their first passkey on a computer, iPhone, or iPad, and it is used to access passkeys on new devices, verify identity, and ensure that not even Google can read the encrypted vault contents. It is distinct from the Google account password and from the device screen lock.

Can one PIN expose all my saved passwords?

PhishU's demonstration shows that a captured six-digit Google Password Manager PIN can allow an attacker to decrypt the entire synced vault — every saved password and every synced passkey — from attacker-controlled infrastructure. The PIN releases the Security Domain Secret, which decrypts the vault in a single operation. If you entered the PIN on a page you did not navigate to directly, treat it as possible full vault exposure.

What should I do if I entered the PIN on a suspicious page?

Review your signed-in devices and registered passkeys at myaccount.google.com immediately. Revoke any unfamiliar devices or sessions. Change your Google account password. Rotate high-value credentials saved in the vault — prioritize SSO, email, cloud consoles, financial platforms, and admin accounts. Check third-party services for unusual login activity. If you are in an organization, open an incident-response case rather than treating this as a single-account issue.

Should companies ban Google Password Manager?

A blanket ban is not the right policy for most organizations. A risk-based approach works better: restrict privileged and shared credential storage to an enterprise password manager with audit controls, enforce separate managed browser profiles for work use, and extend phishing awareness training to cover password-manager prompts and recovery flows. Google Password Manager is appropriate for personal credentials; it is not designed for break-glass accounts or shared admin access.

Are hardware security keys enough to stop this?

Hardware security keys strengthen Google account sign-in assurance, but they do not automatically govern browser-vault synchronization, recovery flows, or the credentials stored inside the vault. VaultJacking targets the vault management layer, not the account sign-in step. A hardware key on the Google account reduces the risk of account takeover but does not prevent a user from being tricked into entering their Google Password Manager PIN on a phishing page.

Password and access management for SMBs: Is KeePass enough?

Using KeePass for your team? Discover the hidden risks of KeePass for SMBs in 2026 — sync failures, compliance gaps, and when to switch to a corporate password manager.

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

Secrets rotation lifecycle: From creation to revocation

Secret rotation fails when it’s treated as a scheduled task rather than a lifecycle. This guide covers all seven stages — from creation and ownership to safe rotation, emergency revocation, and audit evidence.

Passwork BlogAlex Muntyan

Die NIS2-Richtlinie (EU 2022/2555) ist jetzt in ganz Europa in Kraft. Wesentliche und wichtige Einrichtungen haben eine verbindliche Frist: Bis Oktober 2024 müssen robuste Maßnahmen zum Management von Cybersicherheitsrisiken implementiert werden — andernfalls drohen Bußgelder von bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes. Die meisten Organisationen unterschätzen die operativen Kosten der Compliance. Ein Passwortmanager bildet das Fundament, das die Einhaltung von Artikel 21 ermöglicht — ohne das Budget zu sprengen oder Ihr IT-Team zu überlasten.

Kernaussagen

• NIS2 Artikel 21 ist ergebnisorientiert, nicht werkzeugspezifisch. Regulierungsbehörden verlangen den Nachweis, dass Ihre Organisation kontrolliert, wer auf was, wann und warum zugreift. Ein zentraler Passwortmanager mit RBAC und Audit-Protokollierung verwandelt dies von einer Compliance-Schwachstelle in einen dokumentierten, auditierbaren Prozess.
• Die Kosten der Nichteinhaltung übersteigen die Compliance-Investition bei Weitem. Direkte Bußgelder erreichen 10 Millionen Euro für wesentliche Einrichtungen, hinzu kommen durchschnittlich 5,1 Millionen Euro an Kosten für die Behebung von Sicherheitsverletzungen. Eine einzige vermeidbare Kompromittierung von Anmeldedaten kostet mehr als die Implementierung eines Passwortmanagers — der ROI ist sofort und unbestreitbar.
• 81 Prozent der Datenschutzverletzungen lassen sich auf gestohlene oder schwache Anmeldedaten zurückführen. Ein Passwortmanager eliminiert diesen Angriffsvektor, indem er starke Passwortrichtlinien durchsetzt, die Wiederverwendung von Anmeldedaten verhindert, unbefugten Zugriff durch Audit-Protokolle erkennt und die Massenrotation von Passwörtern innerhalb von Stunden nach einer Kompromittierung ermöglicht.
• Passwortbezogene Helpdesk-Tickets verbrauchen 30–50 % der IT-Support-Kapazität. Ein Passwortmanager reduziert diese Tickets um bis zu 40 % und gibt IT-Mitarbeitern Freiraum für strategische Aufgaben. Die jährlichen Einsparungen erreichen 210.000 Euro für eine typische mittelständische Organisation, wenn Helpdesk-Arbeitskosten, Audit-Zeitaufwand und Incident-Response-Kosten berücksichtigt werden.
• EU-Datensouveränität ist ohne operative Komplexität erreichbar. Passwork Cloud hostet Daten vollständig in EU-Rechenzentren ohne grenzüberschreitende Übertragungen und erfüllt damit DSGVO Artikel 32 und NIS2 Artikel 21. Sie behalten die Kontrolle über die Verschlüsselungsschlüssel und unveränderliche Audit-Trails, während Sie den Patching-Aufwand einer On-Premise-Bereitstellung vermeiden.
• Die Wahl ist binär: Proaktive Compliance oder reaktive Compliance. Investieren Sie jetzt, um Bußgelder zu vermeiden, oder zahlen Sie später nach einer Sicherheitsverletzung 15 Millionen Euro. Europäische Organisationen entscheiden sich für Ersteres — sie bauen Compliance auf einem Passwortmanager-Fundament auf, das den operativen Aufwand reduziert und gleichzeitig regulatorische Anforderungen erfüllt.

NIS2 Artikel 21 verstehen: Der Kern des Cybersicherheits-Risikomanagements

NIS2 Artikel 21 schreibt vor, dass wesentliche und wichtige Einrichtungen technische, operative und organisatorische Maßnahmen zum Management von Cybersicherheitsrisiken implementieren. Diese Maßnahmen umfassen zehn grundlegende Sicherheitsbereiche: Zugriffskontrolle, Authentifizierung, Verschlüsselung, Incident-Handling, Lieferkettensicherheit und andere. Die Richtlinie schreibt keine spezifischen Tools vor — sie definiert Ergebnisse. Ein Passwortmanager erfüllt direkt mehrere Anforderungen von Artikel 21, indem er das Anmeldedaten-Management zentralisiert, starke Authentifizierungsrichtlinien durchsetzt und unveränderliche Audit-Trails führt.

Die zentrale Herausforderung: Artikel 21 ist ergebnisorientiert, nicht werkzeugorientiert. Compliance-Beauftragte müssen nachweisen, dass ihre Organisation kontrolliert, wer auf was, wann und warum zugreift. Manuelles Teilen von Passwörtern per E-Mail, Tabellenkalkulation oder Haftnotizen besteht diesen Test sofort nicht. Ein zentraler Credential-Tresor mit rollenbasierter Zugriffskontrolle (RBAC) und umfassender Protokollierung verwandelt dies von einer Compliance-Schwachstelle in einen dokumentierten, auditierbaren Prozess.

Die versteckten Kosten der NIS2-Nichteinhaltung

Nichteinhaltung verursacht zwei unterschiedliche Kostenkategorien: direkte Bußgelder und indirekte Kosten durch Sicherheitsverletzungen.

• Direkte Bußgelder sind erheblich. NIS2 Artikel 34 legt Strafen von bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes für wesentliche Einrichtungen fest, sowie 5 Millionen Euro oder 1 % für wichtige Einrichtungen. Ein mittelständisches Finanzdienstleistungsunternehmen mit 500 Millionen Euro Umsatz riskiert ein potenzielles Bußgeld von 10 Millionen Euro für einen einzigen wesentlichen Compliance-Verstoß.
• Indirekte Kosten übersteigen die Bußgelder bei Weitem. Laut IBMs Cost of a Data Breach Report 2025 erreichten die durchschnittlichen globalen Kosten einer Sicherheitsverletzung 5,1 Millionen Dollar — und das vor Inkrafttreten der NIS2-Strafen. Schwaches Anmeldedaten-Management ist die Hauptursache: 81 % der Datenschutzverletzungen lassen sich auf gestohlene oder schwache Anmeldedaten zurückführen. Ein Passwortmanager eliminiert diesen Angriffsvektor vollständig, indem er starke Passwortrichtlinien durchsetzt, die Wiederverwendung von Anmeldedaten verhindert und unbefugte Zugriffsversuche durch Audit-Protokolle erkennt.

Betrachten Sie die Rechnung: Eine einzige vermeidbare Sicherheitsverletzung kostet 5,1 Millionen Euro an Behebung, Benachrichtigung und Geschäftsverlust. Ein NIS2-Bußgeld addiert weitere 10 Millionen Euro. Die Implementierung eines Passwortmanagers ist nur ein Bruchteil dieser Kosten — und der ROI ist sofort und unbestreitbar.

Den ROI quantifizieren: Wie ein Passwortmanager Ihnen Geld und Zeit spart

Passwortbezogene Helpdesk-Tickets verbrauchen 30–50 % der IT-Support-Kapazität. Ein typisches Ticket kostet 50–100 Euro an Arbeitsaufwand. Für eine 100-Personen-Organisation bedeutet das jährlich 1.500–2.500 Tickets — 75.000–250.000 Euro an reinem Helpdesk-Overhead. Die Implementierung eines Passwortmanagers reduziert diese Tickets um bis zu 40 % und gibt IT-Mitarbeitern Freiraum für strategische Aufgaben.

Über operative Einsparungen hinaus senken Passwortmanager die Versicherungsprämien. Cyberversicherungsanbieter gewähren mittlerweile 10–15 % Rabatt für Organisationen, die zentrales Anmeldedaten-Management mit Audit-Protokollierung einsetzen — ein direktes Abbild des reduzierten Risikos von Sicherheitsverletzungen.

Zeiteinsparungen summieren sich. Endbenutzer müssen vergessene Passwörter nicht mehr zurücksetzen — sie authentifizieren sich einmal am Tresor und greifen auf alle Anmeldedaten zu. IT-Administratoren müssen nicht mehr nachverfolgen, wer auf was Zugriff hat — RBAC und Audit-Protokolle bieten sofortige Transparenz. Das Onboarding eines neuen Entwicklers dauert Stunden statt Tage.

Passwortmanager-Funktionen auf NIS2-Artikel-21-Anforderungen abbilden

NIS2 Artikel 21 verlangt „geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen" zur Bewältigung von Cybersicherheitsrisiken. Alle 10 Maßnahmen sind für jede betroffene Einrichtung obligatorisch. Passwortmanager adressieren die zentralen Angriffsvektoren auf Basis von Anmeldedaten über diese Anforderungen hinweg:

Passwork liefert direkte Compliance-Nachweise für 9 der 10 NIS2-Maßnahmen. Zugriffsprotokolle und unveränderliche Audit-Trails erfüllen die Maßnahmen 1, 2 und 6. Verschlüsselte Speicherung deckt Maßnahme 8 ab. RBAC, MFA-Durchsetzung und Zugriffskontrolle auf Asset-Ebene schließen die Maßnahmen 9 und 10 ab — dort, wo Regulierungsbehörden technische Nachweise verlangen.

On-Premise vs. Cloud: Die richtige Passwortverwaltung für EU-Datensouveränität wählen

Die Debatte On-Premise vs. Cloud dreht sich um Datenresidenz, Kontrolle und regulatorische Konformität.

Cloud-Passwortmanager bieten Geschwindigkeit und Einfachheit, führen aber zu einer Abhängigkeit von einem Drittanbieter. Daten verlassen Ihre Infrastruktur, überqueren Grenzen und lösen möglicherweise DSGVO-Übertragungsbeschränkungen aus. Standard-Cloud-Bereitstellungen, die außerhalb der EU gehostet werden, erzeugen Compliance-Reibung für Organisationen, die sensible EU-Daten verarbeiten.

Allerdings ändern EU-souveräne Cloud-Lösungen diese Gleichung. Passwork Cloud, vollständig in EU-Rechenzentren gehostet ohne Datenübertragung außerhalb des Blocks, eliminiert Bedenken bezüglich grenzüberschreitender Übertragungen und behält gleichzeitig die Cloud-Vorteile: automatisierte Backups, Failover-Clustering und reduzierter IT-Overhead. Passworks EU-souveräne Bereitstellung erfüllt DSGVO Artikel 32 (Datenschutzmaßnahmen) und NIS2 Artikel 21 (Datenresidenz-Erwartungen) ohne die operative Belastung einer On-Premise-Verwaltung. Ihre Verschlüsselungsschlüssel bleiben unter Ihrer Kontrolle, und Audit-Trails sind unveränderlich.

On-Premise-Passwortmanager halten alle Anmeldedaten innerhalb Ihrer Infrastruktur. Passwork On-Premise gibt Ihnen vollständige Kontrolle über Verschlüsselungsschlüssel, Backup-Zeitpläne, Zugriffsrichtlinien und physische Sicherheit. Für Organisationen, die kritische Infrastruktur oder klassifizierte Daten verarbeiten oder in Air-Gapped-Netzwerken arbeiten, ist On-Premise die einzige Option. Es entspricht dem Prinzip der Datenminimierung (ein DSGVO-Kernprinzip) und bietet maximale Compliance-Sicherheit.

Der Kompromiss: Passwork On-Premise erfordert mehr IT-operativen Overhead (Patching, Backups, Disaster Recovery, Kapazitätsplanung). Passwork Cloud reduziert diesen Overhead bei gleichzeitiger Datenresidenz. Standard-Cloud außerhalb der EU führt zu regulatorischen Risiken.

Für EU-Organisationen: Passwork Cloud bietet die Compliance-Sicherheit von On-Premise mit der operativen Einfachheit der Cloud. Daten verlassen niemals die EU, Verschlüsselungsschlüssel bleiben unter Ihrer Kontrolle, und Audit-Trails sind unveränderlich — was sowohl DSGVO als auch NIS2 erfüllt, ohne den Patching-Aufwand.

NIS2-Compliance: Die Kosten des Handelns vs. Nichthandelns

NIS2-Compliance ist obligatorisch. Die Kosten der Nichteinhaltung — Bußgelder von bis zu 15 Millionen Euro plus Kosten für die Behebung von Sicherheitsverletzungen — übersteigen bei Weitem die Investition in ordnungsgemäßes Anmeldedaten-Management. Organisationen, die Compliance auf einem Passwortmanager-Fundament aufbauen, reduzieren die Gesamtbetriebskosten und erfüllen gleichzeitig die Anforderungen von Artikel 21.

Ein zentraler Credential-Tresor mit RBAC, MFA und unveränderlicher Audit-Protokollierung adressiert die Kern-NIS2-Maßnahmen: Risikoanalyse, Incident Response, Wirksamkeit der Kontrollen, Verschlüsselung, Zugriffsgovernance und MFA-Durchsetzung. Der operative Vorteil: IT-Teams verbringen weniger Zeit mit manueller Zugriffsbereitstellung und mehr Zeit mit strategischer Sicherheitsarbeit.

Die Wahl ist binär: Proaktive Compliance (jetzt investieren, Bußgelder vermeiden) oder reaktive Compliance (erst Sicherheitsverletzung, dann zahlen).

Passwork liefert dieses Fundament mit flexibler Bereitstellung: On-Premise für Organisationen, die Datensouveränität benötigen, oder EU-souveräne Cloud für Teams, die operative Einfachheit priorisieren. Beide Modelle liefern die technischen Nachweise, die Regulierungsbehörden verlangen — unveränderliche Audit-Trails, RBAC bis auf Ordnerebene, FIDO2/WebAuthn-MFA-Unterstützung und AES-256-Verschlüsselung.

Passwork ist als On-Premise (vollständige Infrastrukturkontrolle) oder EU-souveräne Cloud (Datenresidenz garantiert, DSGVO- und NIS2-konform) verfügbar. Bereitstellungsoptionen vergleichen und kostenlose Demo anfordern

Häufig gestellte Fragen

Was ist NIS2 und wer muss die Vorgaben erfüllen?

NIS2 (Network and Information Security Directive 2) ist eine EU-Gesetzgebung (EU 2022/2555), die von wesentlichen und wichtigen Einrichtungen verlangt, robuste Maßnahmen zum Management von Cybersicherheitsrisiken zu implementieren. Wesentliche Einrichtungen umfassen Betreiber in den Bereichen Energie, Transport, Wasser, Gesundheit und digitale Infrastruktur. Wichtige Einrichtungen umfassen Finanzen, Gesundheitswesen, Lebensmittelproduktion und andere kritische Sektoren. Die Frist für die Umsetzung war Oktober 2024. Bei Nichteinhaltung drohen Bußgelder von bis zu 10 Millionen Euro (wesentliche Einrichtungen) oder 5 Millionen Euro (wichtige Einrichtungen), zuzüglich Kosten für die Behebung von Sicherheitsverletzungen.

Was ist NIS2 Artikel 21?

NIS2 Artikel 21 schreibt zehn grundlegende Maßnahmen zum Management von Cybersicherheitsrisiken vor: Risikoanalyse und Richtlinien, Incident-Handling, Geschäftskontinuität, Lieferkettensicherheit, sichere Entwicklung, Überprüfung der Wirksamkeit von Kontrollen, Cyberhygiene und Schulung, Verschlüsselung, Zugriffskontrolle und Multi-Faktor-Authentifizierung. Diese Maßnahmen sind ergebnisorientiert, nicht werkzeugspezifisch — Organisationen müssen nachweisen, dass sie kontrollieren, wer auf was, wann und warum zugreift. Ein Passwortmanager adressiert direkt sechs dieser zehn Maßnahmen durch zentrales Anmeldedaten-Management, Audit-Protokollierung und Zugriffsgovernance.

Wie hoch kann ein NIS2-Bußgeld ausfallen?

Wesentliche Einrichtungen riskieren Bußgelder von bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes — je nachdem, welcher Betrag höher ist. Wichtige Einrichtungen riskieren bis zu 5 Millionen Euro oder 1 % des Umsatzes. Ein mittelständisches Finanzdienstleistungsunternehmen mit 500 Millionen Euro Umsatz könnte ein Bußgeld von 10 Millionen Euro für einen einzigen wesentlichen Compliance-Verstoß erhalten. Diese Bußgelder kommen zusätzlich zu den Kosten für die Behebung von Sicherheitsverletzungen, die laut IBMs Cost of a Data Breach Report 2025 global durchschnittlich 5,1 Millionen Euro betragen.

Warum passieren die meisten Sicherheitsverletzungen durch Anmeldedaten?

81 Prozent der Datenschutzverletzungen lassen sich auf gestohlene oder schwache Anmeldedaten zurückführen (IBM 2025 DBIR). Die Hauptursachen sind: gemeinsam genutzte Passwörter per E-Mail oder Tabellenkalkulation, Wiederverwendung von Passwörtern über Systeme hinweg, fehlende Zugriffsprotokollierung und verzögerter Widerruf von Anmeldedaten, wenn Mitarbeiter das Unternehmen verlassen. Ein zentraler Passwortmanager eliminiert diese Vektoren, indem er starke Passwortrichtlinien durchsetzt, das Teilen von Anmeldedaten verhindert, jeden Zugriff protokolliert und die Massenrotation von Passwörtern innerhalb von Stunden ermöglicht.

Sollten wir On-Premise oder Cloud bereitstellen?

On-Premise gibt Ihnen maximale Kontrolle über Verschlüsselungsschlüssel, Backup-Zeitpläne und physische Sicherheit — unverzichtbar für Organisationen, die klassifizierte Daten verarbeiten oder in Air-Gapped-Netzwerken arbeiten. Cloud reduziert den operativen Overhead (Patching, Backups, Disaster Recovery). EU-souveräne Cloud (wie Passwork Cloud) bietet einen Kompromiss: Daten verlassen niemals EU-Rechenzentren, Verschlüsselungsschlüssel bleiben unter Ihrer Kontrolle, und Sie vermeiden den Patching-Aufwand von On-Premise. Für EU-Organisationen, die regulierte Daten verarbeiten, erfüllt EU-souveräne Cloud sowohl DSGVO als auch NIS2 ohne operative Komplexität.

Können wir stattdessen eine Tabellenkalkulation oder E-Mail für das Anmeldedaten-Management verwenden?

Nein. Manuelles Teilen von Anmeldedaten über Tabellenkalkulationen, E-Mail oder Haftnotizen besteht die NIS2-Artikel-21-Compliance sofort nicht. Regulierungsbehörden verlangen den Nachweis von Zugriffskontrolle (wer hat auf was zugegriffen), Audit-Trails (wann und warum) und Widerrufsfähigkeit (sofortige Entfernung des Zugriffs). Eine Tabellenkalkulation bietet nichts davon. Ein zentraler Passwortmanager mit RBAC und unveränderlicher Audit-Protokollierung ist das minimal erforderliche Compliance-Fundament.

Was ist RBAC und warum verlangt NIS2 es?

RBAC (rollenbasierte Zugriffskontrolle) bedeutet, Berechtigungen Gruppen statt Einzelpersonen zu gewähren. Wenn ein Entwickler dem DevOps-Team beitritt, erbt er automatisch den Tresorzugriff des Teams. Wenn er das Team verlässt, widerrufen Sie den Zugriff einmal. NIS2 Artikel 21 (Maßnahme 9) verlangt dokumentierte Zugriffsrechte und sofortigen Widerruf. RBAC erfüllt dies, indem es die manuelle Bereitstellung pro Benutzer eliminiert und sofortige Transparenz darüber bietet, wer auf was Zugriff hat.

Verlangt NIS2 Multi-Faktor-Authentifizierung?

Ja. NIS2 Artikel 21 (Maßnahme 10) schreibt Multi-Faktor-Authentifizierung für alle betroffenen Einrichtungen vor. Die technischen Leitlinien der ENISA spezifizieren drei Stufen der MFA-Stärke, wobei Phishing-resistente Authentifizierung (FIDO2/WebAuthn) für alle privilegierten Konten obligatorisch ist. Ein Passwortmanager setzt MFA auf Tresorebene durch und stellt sicher, dass jeder Zugriff auf Anmeldedaten einen zweiten Faktor erfordert — womit diese Anforderung für die gesamte Organisation erfüllt wird.

Wie hilft Passwork bei der NIS2-Compliance?

Passwork liefert unveränderliche Audit-Trails, RBAC bis auf Ordnerebene, FIDO2/WebAuthn-MFA-Unterstützung und AES-256-Verschlüsselung — die technischen Nachweise, die Regulierungsbehörden verlangen. Es adressiert direkt neun der zehn Maßnahmen von Artikel 21. Passwork ist als On-Premise (vollständige Infrastrukturkontrolle) oder EU-souveräne Cloud (Datenresidenz garantiert, DSGVO- und NIS2-konform) verfügbar. Beide Bereitstellungen bieten die Anmeldedaten-Governance, Zugriffsprotokollierung und Compliance-Dokumentation, die erforderlich sind, um ein regulatorisches Audit zu bestehen.

La Directiva NIS2 (UE 2022/2555) ya está en vigor en toda Europa. Las entidades esenciales e importantes se enfrentan a un plazo estricto: implementar medidas sólidas de gestión de riesgos de ciberseguridad antes de octubre de 2024 o enfrentar multas de hasta 10 millones de euros o el 2% de la facturación anual global. La mayoría de las organizaciones subestiman el coste operativo del cumplimiento. Un gestor de contraseñas es la base que hace alcanzable el cumplimiento del Artículo 21 sin agotar el presupuesto ni sobrecargar a su equipo de TI.

Puntos clave

• El Artículo 21 de NIS2 se centra en resultados, no prescribe herramientas. Los reguladores exigen pruebas de que su organización controla quién accede a qué, cuándo y por qué. Un gestor de contraseñas centralizado con RBAC y registro de auditoría transforma esto de un problema de cumplimiento en un proceso documentado y auditable.
• Los costes del incumplimiento superan con creces la inversión en cumplimiento. Las multas directas alcanzan los 10 millones de euros para entidades esenciales, más 5,1 millones de euros en costes medios de remediación de brechas. Una sola brecha de credenciales prevenible cuesta más que implementar un gestor de contraseñas — el ROI es inmediato e innegable.
• El ochenta y uno por ciento de las brechas de datos se originan por credenciales robadas o débiles. Un gestor de contraseñas elimina este vector aplicando políticas de contraseñas fuertes, previniendo la reutilización de credenciales, detectando accesos no autorizados mediante registros de auditoría y permitiendo la rotación masiva de contraseñas en cuestión de horas tras un compromiso.
• Los tickets de soporte relacionados con contraseñas consumen entre el 30 y el 50% de la capacidad del servicio de TI. Un gestor de contraseñas reduce estos tickets hasta en un 40%, liberando al personal de TI para trabajo estratégico. El ahorro anual alcanza los 210.000 euros para una organización mediana típica, considerando la mano de obra del servicio de asistencia, el tiempo de auditoría de cumplimiento y los costes de respuesta a incidentes.
• La soberanía de datos en la UE es alcanzable sin complejidad operativa. Passwork Cloud aloja los datos íntegramente en centros de datos de la UE sin transferencias transfronterizas, cumpliendo el Artículo 32 del RGPD y el Artículo 21 de NIS2. Usted mantiene el control de las claves de cifrado y las pistas de auditoría inmutables, evitando la carga de actualización del despliegue local.
• La elección es binaria: cumplimiento proactivo o cumplimiento reactivo. Invierta ahora para evitar multas, o sufra una brecha primero y pague 15 millones de euros después. Las organizaciones europeas están eligiendo lo primero — construyendo el cumplimiento sobre una base de gestor de contraseñas que reduce la carga operativa mientras satisface los requisitos regulatorios.

Comprender el Artículo 21 de NIS2: El núcleo de la gestión de riesgos de ciberseguridad

El Artículo 21 de NIS2 exige que las entidades esenciales e importantes implementen medidas técnicas, operativas y organizativas de gestión de riesgos de ciberseguridad. Estas medidas abarcan diez áreas de seguridad básicas: control de acceso, autenticación, cifrado, gestión de incidentes, seguridad de la cadena de suministro y otras. La directiva no prescribe herramientas específicas — define resultados. Un gestor de contraseñas aborda directamente múltiples requisitos del Artículo 21 al centralizar la gestión de credenciales, aplicar políticas de autenticación fuertes y mantener pistas de auditoría inmutables.

El desafío principal: El Artículo 21 se centra en resultados, no en herramientas. Los responsables de cumplimiento deben demostrar que su organización controla quién accede a qué, cuándo y por qué. El intercambio manual de contraseñas por correo electrónico, hojas de cálculo o notas adhesivas falla esta prueba inmediatamente. Una bóveda de credenciales centralizada con control de acceso basado en roles (RBAC) y registro completo transforma esto de un problema de cumplimiento en un proceso documentado y auditable.

Los costes ocultos del incumplimiento de NIS2

El incumplimiento conlleva dos categorías de costes distintas: multas directas y costes indirectos por brechas.

• Las multas directas son severas. El Artículo 34 de NIS2 establece sanciones de hasta 10 millones de euros o el 2% de la facturación anual global total para entidades esenciales, y 5 millones de euros o el 1% para entidades importantes. Una empresa de servicios financieros de tamaño mediano con 500 millones de euros de ingresos enfrenta una multa potencial de 10 millones de euros por un solo incumplimiento material.
• Los costes indirectos superan a las multas. Según el Informe del Coste de una Brecha de Datos 2025 de IBM, el coste medio global de una brecha alcanzó los 5,1 millones de dólares — y eso es antes de que se apliquen las sanciones de NIS2. La gestión deficiente de credenciales es la causa raíz: el 81% de las brechas de datos se originan por credenciales robadas o débiles. Un gestor de contraseñas elimina este vector por completo aplicando políticas de contraseñas fuertes, previniendo la reutilización de credenciales y detectando intentos de acceso no autorizado mediante registros de auditoría.

Considere los números: una sola brecha prevenible cuesta 5,1 millones de euros en remediación, notificación y pérdida de negocio. Una multa de NIS2 añade 10 millones de euros. La implementación de un gestor de contraseñas es una fracción de estos costes — y el ROI es inmediato e innegable.

Cuantificando el ROI: Cómo un gestor de contraseñas le ahorra dinero y tiempo

Los tickets de soporte relacionados con contraseñas consumen entre el 30 y el 50% de la capacidad del servicio de TI. Un ticket típico cuesta entre 50 y 100 euros en mano de obra. Para una organización de 100 personas, eso son entre 1.500 y 2.500 tickets anuales — entre 75.000 y 250.000 euros en gastos generales de soporte técnico. Implementar un gestor de contraseñas reduce estos tickets hasta en un 40%, liberando al personal de TI para trabajo estratégico.

Más allá del ahorro operativo, los gestores de contraseñas reducen las primas de seguro. Las aseguradoras de ciberriesgos ahora ofrecen descuentos del 10-15% para organizaciones que utilizan gestión centralizada de credenciales con registro de auditoría — un reflejo directo de la reducción del riesgo de brechas.

El ahorro de tiempo se acumula. Los usuarios finales ya no restablecen contraseñas olvidadas — se autentican una vez en la bóveda y acceden a todas las credenciales. Los administradores de TI ya no persiguen quién tiene acceso a qué — el RBAC y los registros de auditoría proporcionan visibilidad instantánea. La incorporación de un nuevo desarrollador toma horas en lugar de días.

Correspondencia entre las funciones del gestor de contraseñas y los requisitos del Artículo 21 de NIS2

El Artículo 21 de NIS2 requiere «medidas técnicas, operativas y organizativas apropiadas y proporcionadas» para gestionar los riesgos de ciberseguridad. Las 10 medidas son obligatorias para toda entidad cubierta. Los gestores de contraseñas abordan los vectores de ataque basados en credenciales principales a través de estos requisitos:

Passwork proporciona evidencia directa de cumplimiento en 9 de las 10 medidas de NIS2. Los registros de acceso y las pistas de auditoría inmutables satisfacen las medidas 1, 2 y 6. El almacenamiento cifrado cubre la medida 8. El RBAC, la aplicación de MFA y el control de acceso a nivel de activo completan las medidas 9 y 10 — donde los reguladores exigen pruebas técnicas.

Local vs. nube: Elegir la gestión de contraseñas adecuada para la soberanía de datos en la UE

El debate entre local y nube gira en torno a la residencia de datos, el control y la alineación regulatoria.

Los gestores de contraseñas en la nube ofrecen velocidad y simplicidad, pero introducen dependencia de un proveedor externo. Los datos salen de su infraestructura, cruzan fronteras y potencialmente activan restricciones de transferencia del RGPD. Los despliegues estándar en la nube alojados fuera de la UE crean fricciones de cumplimiento para organizaciones que manejan datos sensibles de la UE.

Sin embargo, las soluciones de nube con soberanía en la UE cambian esta ecuación. Passwork Cloud, alojado íntegramente en centros de datos de la UE sin transferencia de datos fuera del bloque, elimina las preocupaciones sobre transferencias transfronterizas mientras mantiene los beneficios de la nube: copias de seguridad automatizadas, clústeres de conmutación por error y menor carga de TI. El despliegue con soberanía en la UE de Passwork satisface el Artículo 32 del RGPD (medidas de protección de datos) y el Artículo 21 de NIS2 (expectativas de residencia de datos) sin la carga operativa de la gestión local. Sus claves de cifrado permanecen bajo su control y las pistas de auditoría son inmutables.

Los gestores de contraseñas locales mantienen todos los datos de credenciales dentro de su infraestructura. Passwork local le proporciona control total sobre las claves de cifrado, calendarios de respaldo, políticas de acceso y seguridad física. Para organizaciones que manejan infraestructura crítica, datos clasificados u operan en redes aisladas, la opción local es la única alternativa. Se alinea con el principio de minimización de datos (un principio fundamental del RGPD) y proporciona la máxima certeza de cumplimiento.

El compromiso: Passwork local requiere mayor carga operativa de TI (parches, copias de seguridad, recuperación ante desastres, planificación de capacidad). Passwork Cloud reduce esta carga manteniendo la residencia de datos. La nube estándar fuera de la UE introduce riesgo regulatorio.

Para organizaciones de la UE: Passwork Cloud ofrece la certeza de cumplimiento del despliegue local con la simplicidad operativa de la nube. Los datos nunca salen de la UE, las claves de cifrado permanecen bajo su control y las pistas de auditoría son inmutables — satisfaciendo tanto el RGPD como NIS2 sin la carga de actualización.

Cumplimiento de NIS2: El coste de actuar vs. no actuar

El cumplimiento de NIS2 es obligatorio. El coste del incumplimiento — multas de hasta 15 millones de euros más la remediación de brechas — supera con creces la inversión en una gestión adecuada de credenciales. Las organizaciones que construyen el cumplimiento sobre una base de gestor de contraseñas reducen el coste total de propiedad mientras satisfacen los requisitos del Artículo 21.

Una bóveda de credenciales centralizada con RBAC, MFA y registro de auditoría inmutable aborda las medidas principales de NIS2: análisis de riesgos, respuesta a incidentes, eficacia de controles, cifrado, gobernanza de acceso y aplicación de MFA. El beneficio operativo: los equipos de TI dedican menos tiempo al aprovisionamiento manual de accesos y más tiempo al trabajo de seguridad estratégico.

La elección es binaria: cumplimiento proactivo (invertir ahora, evitar multas) o cumplimiento reactivo (sufrir una brecha primero, pagar después).

Passwork proporciona esta base con despliegue flexible: local para organizaciones que requieren soberanía de datos, o nube con soberanía en la UE para equipos que priorizan la simplicidad operativa. Ambos modelos proporcionan las pruebas técnicas que exigen los reguladores — pistas de auditoría inmutables, RBAC hasta nivel de carpeta, soporte de MFA FIDO2/WebAuthn y cifrado AES-256.

Passwork está disponible como local (control total de infraestructura) o nube con soberanía en la UE (residencia de datos garantizada, compatible con RGPD y NIS2). Compare las opciones de despliegue y solicite una demostración gratuita

Preguntas frecuentes

¿Qué es NIS2 y quién debe cumplir?

NIS2 (Directiva de Seguridad de Redes y de la Información 2) es la legislación de la UE (UE 2022/2555) que exige a las entidades esenciales e importantes implementar medidas sólidas de gestión de riesgos de ciberseguridad. Las entidades esenciales incluyen operadores de energía, transporte, agua, salud e infraestructura digital. Las entidades importantes abarcan finanzas, salud, producción alimentaria y otros sectores críticos. El plazo de implementación fue octubre de 2024. El incumplimiento desencadena multas de hasta 10 millones de euros (entidades esenciales) o 5 millones de euros (entidades importantes), más los costes de remediación de brechas.

¿Qué es el Artículo 21 de NIS2?

El Artículo 21 de NIS2 establece diez medidas básicas de gestión de riesgos de ciberseguridad: análisis de riesgos y políticas, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, desarrollo seguro, verificación de la eficacia de controles, higiene cibernética y formación, cifrado, control de acceso y autenticación multifactor. Estas medidas se centran en resultados, no prescriben herramientas — las organizaciones deben demostrar que controlan quién accede a qué, cuándo y por qué. Un gestor de contraseñas aborda directamente seis de estas diez medidas mediante la gestión centralizada de credenciales, el registro de auditoría y la gobernanza de acceso.

¿Cuánto puede costar una multa de NIS2?

Las entidades esenciales enfrentan multas de hasta 10 millones de euros o el 2% de la facturación anual global total — lo que sea mayor. Las entidades importantes enfrentan hasta 5 millones de euros o el 1% de la facturación. Una empresa de servicios financieros de tamaño mediano con 500 millones de euros de ingresos podría enfrentar una multa de 10 millones de euros por un solo incumplimiento material. Estas multas son adicionales a los costes de remediación de brechas, que promedian 5,1 millones de euros a nivel global según el Informe del Coste de una Brecha de Datos 2025 de IBM.

¿Por qué ocurren la mayoría de las brechas de credenciales?

El ochenta y uno por ciento de las brechas de datos se originan por credenciales robadas o débiles (IBM 2025 DBIR). Las causas raíz incluyen contraseñas compartidas por correo electrónico u hojas de cálculo, reutilización de contraseñas entre sistemas, falta de registro de accesos y revocación tardía de credenciales cuando los empleados se van. Un gestor de contraseñas centralizado elimina estos vectores aplicando políticas de contraseñas fuertes, previniendo el intercambio de credenciales, registrando cada acceso y permitiendo la rotación masiva de contraseñas en horas.

¿Debemos desplegar local o en la nube?

El despliegue local proporciona control máximo sobre claves de cifrado, calendarios de respaldo y seguridad física — esencial para organizaciones que manejan datos clasificados u operan en redes aisladas. La nube reduce la carga operativa (parches, copias de seguridad, recuperación ante desastres). La nube con soberanía en la UE (como Passwork Cloud) divide la diferencia: los datos nunca salen de los centros de datos de la UE, las claves de cifrado permanecen bajo su control y se evita la carga de actualización del despliegue local. Para organizaciones de la UE que manejan datos regulados, la nube con soberanía en la UE satisface tanto el RGPD como NIS2 sin complejidad operativa.

¿Podemos usar una hoja de cálculo o correo electrónico para la gestión de credenciales en su lugar?

No. El intercambio manual de credenciales mediante hojas de cálculo, correo electrónico o notas adhesivas incumple inmediatamente el Artículo 21 de NIS2. Los reguladores exigen pruebas de control de acceso (quién accedió a qué), pistas de auditoría (cuándo y por qué) y capacidad de revocación (eliminación inmediata del acceso). Una hoja de cálculo no proporciona nada de esto. Un gestor de contraseñas centralizado con RBAC y registro de auditoría inmutable es la base mínima viable de cumplimiento.

¿Qué es RBAC y por qué lo exige NIS2?

RBAC (control de acceso basado en roles) significa otorgar permisos a grupos en lugar de individuos. Cuando un desarrollador se une al equipo de DevOps, hereda automáticamente el acceso a la bóveda del equipo. Cuando se va, se revoca una sola vez. El Artículo 21 de NIS2 (Medida 9) exige derechos de acceso documentados y revocación inmediata. El RBAC satisface esto eliminando el aprovisionamiento manual por usuario y proporcionando visibilidad instantánea de quién tiene acceso a qué.

¿NIS2 exige autenticación multifactor?

Sí. El Artículo 21 de NIS2 (Medida 10) establece la autenticación multifactor como obligatoria para todas las entidades cubiertas. La guía técnica de ENISA especifica tres niveles de fortaleza de MFA, siendo la autenticación resistente al phishing (FIDO2/WebAuthn) obligatoria para todas las cuentas privilegiadas. Un gestor de contraseñas aplica MFA a nivel de bóveda, asegurando que cada acceso a credenciales requiera un segundo factor — satisfaciendo este requisito en toda la organización.

¿Cómo ayuda Passwork con el cumplimiento de NIS2?

Passwork proporciona pistas de auditoría inmutables, RBAC hasta nivel de carpeta, soporte de MFA FIDO2/WebAuthn y cifrado AES-256 — las pruebas técnicas que exigen los reguladores. Aborda nueve de las diez medidas del Artículo 21 directamente. Passwork está disponible como local (control total de infraestructura) o nube con soberanía en la UE (residencia de datos garantizada, compatible con RGPD y NIS2). Ambos despliegues proporcionan la gobernanza de credenciales, el registro de accesos y la documentación de cumplimiento necesarios para pasar una auditoría regulatoria.

The NIS2 Directive (EU 2022/2555) is now live across Europe. Essential and important entities face a hard deadline: implement robust cybersecurity risk-management measures by October 2024 or face fines up to €10 million or 2% of global annual turnover. Most organizations underestimate the operational cost of compliance. A password manager is the foundation that makes Article 21 compliance achievable without breaking the budget or burning out your IT team.

Key Takeaways

• NIS2 Article 21 is outcome-focused, not tool-prescriptive. Regulators demand proof that your organization controls who accesses what, when, and why. A centralized password manager with RBAC and audit logging transforms this from a compliance liability into a documented, auditable process.
• Non-compliance costs far exceed compliance investment. Direct fines reach €10 million for essential entities, plus €5.1 million in average breach remediation costs. A single preventable credential breach costs more than implementing a password manager — the ROI is immediate and undeniable.
• Eighty-one percent of data breaches trace back to stolen or weak credentials. A password manager eliminates this vector by enforcing strong password policies, preventing credential reuse, detecting unauthorized access through audit logs, and enabling bulk password rotation within hours of a compromise.
• Password-related helpdesk tickets consume 30–50% of IT support capacity. A password manager reduces these tickets by up to 40%, freeing IT staff for strategic work. Annual savings reach €210,000 for a typical mid-sized organization when accounting for helpdesk labor, compliance audit time, and incident response costs.
• EU data sovereignty is achievable without operational complexity. Passwork Cloud hosts data entirely within EU data centers with no cross-border transfers, satisfying GDPR Article 32 and NIS2 Article 21. You retain encryption key control and immutable audit trails while avoiding the patching burden of on-premise deployment.
• The choice is binary: proactive compliance or reactive compliance. Invest now to avoid fines, or breach first and pay €15 million later. European organizations are choosing the former — building compliance on a password manager foundation that reduces operational overhead while satisfying regulatory requirements.

Understanding NIS2 Article 21: The core of cybersecurity risk management

NIS2 Article 21 mandates that essential and important entities implement technical, operational, and organizational cybersecurity risk-management measures. These measures span ten baseline security areas: access control, authentication, encryption, incident handling, supply chain security, and others. The directive doesn't prescribe specific tools — it defines outcomes. A password manager directly addresses multiple Article 21 requirements by centralizing credential management, enforcing strong authentication policies, and maintaining immutable audit trails.

The core challenge: Article 21 is outcome-focused, not tool-focused. Compliance officers must demonstrate that their organization controls who accesses what, when, and why. Manual password sharing via email, spreadsheets, or sticky notes fails this test immediately. A centralized credential vault with role-based access control (RBAC) and comprehensive logging transforms this from a compliance liability into a documented, auditable process.

The hidden costs of NIS2 non-compliance

Non-compliance carries two distinct cost categories: direct fines and indirect breach costs.

• Direct fines are brutal. NIS2 Article 34 establishes penalties up to €10 million or 2% of total global annual turnover for essential entities, and €5 million or 1% for important entities. A mid-sized financial services firm with €500 million in revenue faces a potential €10 million fine for a single material compliance failure.
• Indirect costs dwarf the fines. According to IBM's 2025 Cost of a Data Breach Report, the global average breach cost reached $5.1 million — and that's before NIS2 penalties kick in. Weak credential management is the root cause: 81% of data breaches trace back to stolen or weak credentials. A password manager eliminates this vector entirely by enforcing strong password policies, preventing credential reuse, and detecting unauthorized access attempts through audit logs.

Consider the math: a single preventable breach costs €5.1 million in remediation, notification, and lost business. A NIS2 fine adds €10 million. A password manager implementation is a fraction of these costs — and the ROI is immediate and undeniable.

Quantifying the ROI: How a password manager saves you money and time

Password-related helpdesk tickets consume 30–50% of IT support capacity. A typical ticket costs €50–€100 in labor. For a 100-person organization, that's 1,500–2,500 tickets annually — €75,000–€250,000 in pure helpdesk overhead. Implementing a password manager reduces these tickets by up to 40%, freeing IT staff for strategic work.

Beyond operational savings, password managers reduce insurance premiums. Cyber insurance carriers now offer 10–15% discounts for organizations using centralized credential management with audit logging — a direct reflection of reduced breach risk.

Time savings compound. End-users no longer reset forgotten passwords — they authenticate once to the vault and access all credentials. IT administrators no longer chase down who has access to what — RBAC and audit logs provide instant visibility. Onboarding a new developer takes hours instead of days.

Mapping password manager features to NIS2 Article 21 requirements

NIS2 Article 21 requires "appropriate and proportionate technical, operational and organisational measures" to manage cybersecurity risks. All 10 measures are mandatory for every covered entity. Password managers address the core credential-based attack vectors across these requirements:

Passwork delivers direct compliance evidence across 9 of the 10 NIS2 measures. Access logs and immutable audit trails satisfy measures 1, 2, and 6. Encrypted storage covers measure 8. RBAC, MFA enforcement, and asset-level access control close out measures 9 and 10 — where regulators demand technical proof.

On-premise vs. cloud: Choosing the right password management for EU data sovereignty

The on-premise vs. cloud debate hinges on data residency, control, and regulatory alignment.

Cloud password managers offer speed and simplicity but introduce dependency on a third-party provider. Data leaves your infrastructure, crossing borders and potentially triggering GDPR transfer restrictions. Standard cloud deployments hosted outside the EU create compliance friction for organizations handling sensitive EU data.

However, EU-sovereign cloud solutions change this equation. Passwork Cloud, hosted entirely within EU data centers with no data transfer outside the bloc, eliminates cross-border transfer concerns while retaining cloud benefits: automated backups, failover clustering, and reduced IT overhead. Passwork's EU-sovereign deployment satisfies GDPR Article 32 (data protection measures) and NIS2 Article 21 (data residency expectations) without the operational burden of on-premise management. Your encryption keys remain under your control, and audit trails are immutable.

On-premise password managers keep all credential data within your infrastructure. Passwork on-premise gives you complete control over encryption keys, backup schedules, access policies, and physical security. For organizations handling critical infrastructure, classified data, or operating in air-gapped networks, on-premise is the only option. It aligns with the principle of data minimization (a core GDPR tenet) and provides maximum compliance certainty.

The trade-off: Passwork on-premise requires more IT operational overhead (patching, backups, disaster recovery, capacity planning). Passwork Cloud reduces this overhead while maintaining data residency. Standard cloud outside the EU introduces regulatory risk.

For EU organizations: Passwork Cloud offers the compliance certainty of on-premise with the operational simplicity of cloud. Data never leaves the EU, encryption keys remain under your control, and audit trails are immutable — satisfying both GDPR and NIS2 without the patching burden.

NIS2 compliance: The cost of action vs. inaction

NIS2 compliance is mandatory. The cost of non-compliance — fines up to €15 million plus breach remediation — far exceeds the investment in proper credential management. Organizations that build compliance on a password manager foundation reduce total cost of ownership while satisfying Article 21 requirements.

A centralized credential vault with RBAC, MFA, and immutable audit logging addresses the core NIS2 measures: risk analysis, incident response, control effectiveness, encryption, access governance, and MFA enforcement. The operational benefit: IT teams spend less time on manual access provisioning and more time on strategic security work.

The choice is binary: proactive compliance (invest now, avoid fines) or reactive compliance (breach first, pay later).

Passwork delivers this foundation with flexible deployment: on-premise for organizations requiring data sovereignty, or EU-sovereign cloud for teams prioritizing operational simplicity. Both models provide the technical proof regulators demand — immutable audit trails, RBAC down to folder level, FIDO2/WebAuthn MFA support, and AES-256 encryption.

Passwork is available as on-premise (full infrastructure control) or EU-sovereign cloud (data residency guaranteed, GDPR and NIS2 compliant). Compare deployment options and request a free demo

Frequently Asked Questions

What is NIS2 and who must comply?

NIS2 (Network and Information Security Directive 2) is EU legislation (EU 2022/2555) requiring essential and important entities to implement robust cybersecurity risk-management measures. Essential entities include energy, transport, water, health, and digital infrastructure operators. Important entities span finance, healthcare, food production, and other critical sectors. The deadline for implementation was October 2024. Non-compliance triggers fines up to €10 million (essential entities) or €5 million (important entities), plus breach remediation costs.

What is NIS2 Article 21?

NIS2 Article 21 mandates ten baseline cybersecurity risk-management measures: risk analysis and policies, incident handling, business continuity, supply chain security, secure development, control effectiveness verification, cyber hygiene and training, encryption, access control, and multi-factor authentication. These measures are outcome-focused, not tool-prescriptive — organizations must demonstrate they control who accesses what, when, and why. A password manager directly addresses six of these ten measures through centralized credential management, audit logging, and access governance.

How much can a NIS2 fine cost?

Essential entities face fines up to €10 million or 2% of total global annual turnover — whichever is higher. Important entities face up to €5 million or 1% of turnover. A mid-sized financial services firm with €500 million in revenue could face a €10 million fine for a single material compliance failure. These fines are in addition to breach remediation costs, which average €5.1 million globally according to IBM's 2025 Cost of a Data Breach Report.

Why do most credential breaches happen?

Eighty-one percent of data breaches trace back to stolen or weak credentials (IBM 2025 DBIR). Root causes include shared passwords via email or spreadsheets, password reuse across systems, lack of access logging, and delayed credential revocation when employees leave. A centralized password manager eliminates these vectors by enforcing strong password policies, preventing credential sharing, logging every access, and enabling bulk password rotation within hours.

Should we deploy on-premise or cloud?

On-premise gives you maximum control over encryption keys, backup schedules, and physical security — essential for organizations handling classified data or operating in air-gapped networks. Cloud reduces operational overhead (patching, backups, disaster recovery). EU-sovereign cloud (like Passwork Cloud) splits the difference: data never leaves EU data centers, encryption keys remain under your control, and you avoid the patching burden of on-premise. For EU organizations handling regulated data, EU-sovereign cloud satisfies both GDPR and NIS2 without operational complexity.

Can we use a spreadsheet or email for credential management instead?

No. Manual credential sharing via spreadsheets, email, or sticky notes fails NIS2 Article 21 compliance immediately. Regulators require proof of access control (who accessed what), audit trails (when and why), and revocation capability (immediate removal of access). A spreadsheet provides none of these. A centralized password manager with RBAC and immutable audit logging is the minimum viable compliance foundation.

What is RBAC and why does NIS2 require it?

RBAC (role-based access control) means granting permissions to groups instead of individuals. When a developer joins the DevOps team, they inherit the team's vault access automatically. When they leave, you revoke it once. NIS2 Article 21 (Measure 9) requires documented access rights and immediate revocation. RBAC satisfies this by eliminating manual per-user provisioning and providing instant visibility into who has access to what.

Does NIS2 require multi-factor authentication?

Yes. NIS2 Article 21 (Measure 10) mandates multi-factor authentication for all covered entities. ENISA's technical guidance specifies three tiers of MFA strength, with phishing-resistant authentication (FIDO2/WebAuthn) mandatory for all privileged accounts. A password manager enforces MFA at the vault level, ensuring every credential access requires a second factor — satisfying this requirement across the entire organization.

How does Passwork help with NIS2 compliance?

Passwork delivers immutable audit trails, RBAC down to folder level, FIDO2/WebAuthn MFA support, and AES-256 encryption — the technical proof regulators demand. It addresses nine of the ten Article 21 measures directly. Passwork is available as on-premise (full infrastructure control) or EU-sovereign cloud (data residency guaranteed, GDPR and NIS2 compliant). Both deployments provide the credential governance, access logging, and compliance documentation needed to pass a regulatory audit.

Die NIS2-Richtlinie (EU 2022/2555) ist keine Zukunftsangelegenheit mehr. Seit Oktober 2024 müssen Organisationen in 18 europäischen Sektoren die Einhaltung verbindlicher Cybersicherheitskontrollen nachweisen. Strafen erreichen 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes, und Vorstandsmitglieder haften persönlich bei Nichteinhaltung.

Im Kern von NIS2 steht Artikel 21, der 10 spezifische Sicherheitsmaßnahmen vorschreibt. Davon ist das Zugriffsmanagement (Credential-Governance, rollenbasierte Zugriffskontrolle, Multi-Faktor-Authentifizierung und Audit-Protokollierung) am besten prüfbar und am direktesten mit Sicherheitsvorfällen verbunden.

Dieser Leitfaden ordnet diese Anforderungen praktischen Umsetzungsschritten zu und zeigt, wie Sie Compliance-Nachweise erstellen, die Regulierungsbehörden erwarten.

Wichtigste Erkenntnisse

• Gestohlene Anmeldedaten erscheinen in 39 % aller Sicherheitsvorfälle — nicht nur beim initialen Zugang, sondern als primärer Mechanismus für laterale Bewegung, Rechteausweitung und Persistenz.
• Die Beteiligung Dritter hat 2026 48 % erreicht, ein Anstieg von 60 % im Jahresvergleich, der direkt die Supply-Chain-Zugangs-Governance unter NIS2 Artikel 21(2)(d) betrifft.
• NIS2 Artikel 21 schreibt 10 spezifische Sicherheitsmaßnahmen vor, die alle für jede betroffene Organisation verbindlich sind. Die am besten prüfbaren und sicherheitskritischsten Maßnahmen sind Zugriffskontrolle, MFA und unveränderliche Audit-Protokollierung — diese liefern exportierbare Compliance-Nachweise, die Regulierungsbehörden erwarten.
• Zugriffskontrolle ist der Bereich, in dem NIS2-Compliance messbar wird. Im Gegensatz zu Richtliniendokumenten erzeugt Credential-Governance überprüfbare Nachweise: Audit-Protokolle, Berechtigungsmatrizen, MFA-Durchsetzungsberichte. Regulierungsbehörden können bestätigen, dass Kontrollen aktiv durchgesetzt werden.
• Artikel 23 führt eine 24-Stunden-Meldepflicht für Vorfälle ein. Organisationen ohne zentralisiertes Credential-Management, unveränderliche Audit-Trails und automatisierte Rotationsfähigkeiten können diese Frist nicht einhalten. Massenhafte Passwortrotation muss innerhalb von Stunden durchführbar sein, nicht Tagen.
• ENISA spezifiziert drei MFA-Stufen. Stufe 1 (Phishing-resistentes FIDO2/WebAuthn) ist für alle privilegierten Konten obligatorisch. Stufe 2 (TOTP) ist für Standardbenutzer akzeptabel. SMS- und E-Mail-OTPs sind explizit zur Auslaufphase gekennzeichnet und erfüllen die Mindestanforderungen nicht.
• Persönliche Haftung für Vorstandsmitglieder ist beispiellos. Artikel 20 macht C-Level-Führungskräfte persönlich für Cybersicherheitsmängel verantwortlich, einschließlich temporärer Verbote von Managementfunktionen. Diese Bestimmung hat keinen Präzedenzfall in NIS1.
• Strafen erreichen 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes für Wesentliche Einrichtungen, wobei die Durchsetzung ab 2026 aktiv ist. Nationale zuständige Behörden in der gesamten EU haben mit proaktiven Audits begonnen. Nichteinhaltung ist kein Zukunftsthema mehr.
• On-Premise-Bereitstellung eliminiert die Datenverwahrung durch Dritte. Anmeldedaten verbleiben in Ihrem Netzwerk ohne externe Übertragung. Audit-Protokolle werden lokal gespeichert und direkt an Ihr SIEM weitergeleitet, ohne Vermittler des Anbieters, was Audit-Unabhängigkeit garantiert.
• Die 5-Phasen-Implementierungs-Roadmap dauert 30–60 Tage von der Bewertung bis zur audit-bereiten Compliance: Vor-Bereitstellungs-Bewertung, Zugriffs-Audit, Credential-System-Bereitstellung, NIS2-Konfiguration und laufende Überwachung. Die meisten Organisationen können innerhalb dieses Zeitrahmens von fragmentiertem Zugriffsmanagement zur Durchsetzung übergehen.

Warum NIS2 sich auf Zugriffsmanagement konzentriert

Zugriffskontrolle ist der Bereich, in dem NIS2-Compliance messbar wird. Im Gegensatz zu Richtliniendokumenten oder Risikobewertungen erzeugt Credential-Governance exportierbare Nachweise: Audit-Protokolle, Berechtigungsmatrizen, MFA-Durchsetzungsberichte. Regulierungsbehörden können überprüfen, dass Kontrollen aktiv durchgesetzt werden.

Die Bedrohungslandschaft macht diese Dringlichkeit deutlich. Laut Verizons Data Breach Investigations Report 2026 ist die Ausnutzung von Schwachstellen mit 31 % der Sicherheitsvorfälle zum führenden initialen Zugriffsvektor geworden, gegenüber 20 % im Jahr 2025. Dieser Schlagzeilenvergleich verdeckt jedoch eine kritischere Erkenntnis: Gestohlene Anmeldedaten erscheinen in 39 % aller Sicherheitsvorfälle über den gesamten Angriffslebenszyklus — nicht nur beim initialen Zugang, sondern als primärer Mechanismus für laterale Bewegung, Rechteausweitung und Persistenz.

Sobald Angreifer Zugang erhalten, werden Anmeldedaten ihr dominantes Werkzeug, um sich durch die Infrastruktur zu bewegen. Die Beteiligung Dritter hat 2026 48 % erreicht, gegenüber 30 % im Jahr 2025 — ein Anstieg von 60 %, der direkt die Supply-Chain-Zugangs-Governance unter NIS2 Artikel 21(2)(d) betrifft.

Gestohlene Anmeldedaten treiben die Ausweitung von Sicherheitsvorfällen voran — wiederverwendet, geteilt oder nie widerrufen, wenn Mitarbeiter das Unternehmen verlassen. NIS2 Artikel 21 wurde entwickelt, um dies durch strenge Zugriffskontrolle, obligatorische MFA und unveränderliche Audit-Protokollierung zu eliminieren.

NIS2 Artikel 21 verstehen: Die 10 obligatorischen Sicherheitsmaßnahmen

NIS2 Artikel 21 verlangt „angemessene und verhältnismäßige technische, operative und organisatorische Maßnahmen" zur Bewältigung von Cybersicherheitsrisiken. Alle 10 Maßnahmen sind für jede betroffene Organisation verbindlich. Hier ist, was jede einzelne verlangt:

• Maßnahme 1: Risikoanalyse und Sicherheitsrichtlinien für Informationssysteme. Organisationen müssen Cybersicherheitsrisiken kontinuierlich identifizieren und dokumentieren. Dies bedeutet Credential-Erkennung: Erfassung aller privilegierten Konten, Identifizierung gemeinsam genutzter Anmeldedaten und Dokumentation, welche Systeme den risikoreichsten Zugang haben.
• Maßnahme 2: Vorfallbehandlung — Prävention, Erkennung und Reaktion. Organisationen müssen dokumentierte Verfahren für die Reaktion auf Sicherheitsvorfälle haben. Bei Credential-basierten Sicherheitsvorfällen bedeutet dies die Fähigkeit, kompromittierte Passwörter massenhaft innerhalb von Stunden zu rotieren, nicht Tagen.
• Maßnahme 3: Geschäftskontinuität, Backup-Management und Disaster Recovery. Anmeldedaten müssen auch bei Ausfall primärer Systeme zugänglich bleiben. Dies erfordert Failover-Clustering, Replikation und getestete Backup-Verfahren.
• Maßnahme 4: Supply-Chain-Sicherheit. Organisationen müssen die Cybersicherheitsrisiken durch direkte Lieferanten und Dienstleister bewerten und managen. Für Anmeldedaten bedeutet dies die Isolierung des Zugriffs durch Dritte, zeitliche Begrenzung und automatischen Widerruf bei Vertragsende.
• Maßnahme 5: Sicherheit bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen. Systeme müssen mit Sicherheit im Blick gebaut und gewartet werden. Für Credential-Systeme bedeutet dies sichere Entwicklungspraktiken und regelmäßige Penetrationstests.
• Maßnahme 6: Richtlinien und Verfahren zur Bewertung der Wirksamkeit von Cybersicherheits-Risikomanagementmaßnahmen. Organisationen müssen überprüfen, dass Kontrollen tatsächlich funktionieren. Dies erfordert Audit-Trails: Nachweis, dass Zugriffskontrollen durchgesetzt werden und jede Credential-Aktion protokolliert wird.
• Maßnahme 7: Grundlegende Cyber-Hygiene-Praktiken und Cybersicherheitsschulungen. Schwache Passwörter sind der häufigste Credential-Fehler. Organisationen müssen Passwortkomplexität, Rotationspläne und Sicherheitsbewusstsein der Benutzer durchsetzen.
• Maßnahme 8: Richtlinien und Verfahren für den Einsatz von Kryptographie und Verschlüsselung. Anmeldedaten müssen im Ruhezustand und während der Übertragung verschlüsselt sein. Dies bedeutet AES-256-Verschlüsselung, TLS für alle Kommunikationen und Zero-Knowledge-Architektur, bei der der Server niemals Entschlüsselungsschlüssel hält.
• Maßnahme 9: Personalsicherheit, Zugriffskontrollrichtlinien und Asset-Management. Dies ist der Kern der NIS2-Zugangs-Governance: Jeder Benutzer muss dokumentierte Zugriffsrechte haben, jede Zugriffsänderung muss protokolliert werden, und jede Anmeldung muss widerrufen werden, wenn der Zugang nicht mehr benötigt wird.
• Maßnahme 10: Einsatz von MFA oder kontinuierlichen Authentifizierungslösungen. Multi-Faktor-Authentifizierung ist nicht mehr optional. Die technische Anleitung der ENISA spezifiziert drei Stufen der MFA-Stärke, wobei Phishing-resistente Authentifizierung (FIDO2/WebAuthn) für alle privilegierten Konten obligatorisch ist.

Kurzreferenztabelle

Passwork liefert direkte Compliance-Nachweise für 9 der 10 NIS2-Maßnahmen. Zugriffsprotokolle und unveränderliche Audit-Trails erfüllen die Maßnahmen 1, 2 und 6. Verschlüsselte Speicherung deckt Maßnahme 8 ab. RBAC, MFA-Durchsetzung und Zugriffskontrolle auf Asset-Ebene schließen die Maßnahmen 9 und 10 ab — wo Regulierungsbehörden technische Nachweise fordern. Erhalten Sie eine kostenlose Demo und erleben Sie es in Aktion

Die 24-Stunden-Meldepflicht für Vorfälle

NIS2 Artikel 23 führt einen dreistufigen Meldezeitplan ein, der grundlegend verändert, wie Organisationen auf Credential-Sicherheitsvorfälle reagieren.

• Frühwarnung (24 Stunden). Innerhalb von 24 Stunden nach Entdeckung eines erheblichen Vorfalls müssen Organisationen das nationale CSIRT benachrichtigen. Keine vollständige Bewertung erforderlich — nur Bestätigung, dass ein Vorfall stattgefunden hat und ob kriminelle Aktivitäten vermutet werden.
• Vorfallmeldung (72 Stunden). Eine erste Bewertung bereitstellen: Schweregrad, Auswirkungen, Indicators of Compromise (IoCs) und betroffene Systeme. Hier wird der Umfang des Credential-Sicherheitsvorfalls kritisch. Wenn Admin-Anmeldedaten kompromittiert wurden, ist der Umfang potenziell unternehmensweit.
• Abschlussbericht (1 Monat). Vollständige Ursachenanalyse, ergriffene Abhilfemaßnahmen, Bewertung grenzüberschreitender Auswirkungen und gewonnene Erkenntnisse. Dies ist das Dokument, das Regulierungsbehörden genau prüfen werden. Bei Credential-Sicherheitsvorfällen muss es den Nachweis enthalten, dass alle kompromittierten Passwörter rotiert wurden und dass der Zugang für alle Konten widerrufen wurde, die keinen Zugang mehr hätten haben sollen.

Organisationen ohne zentralisiertes Credential-Management, unveränderliche Audit-Trails und automatisierte Rotationsfähigkeiten können die 24-Stunden-Frist nicht einhalten.

Technische ENISA-Leitlinien: MFA, PAM und Audit-Protokollierung

Die Agentur der Europäischen Union für Cybersicherheit (ENISA) hat detaillierte technische Implementierungsleitlinien für NIS2 veröffentlicht. Für das Zugriffsmanagement dominieren drei Bereiche: MFA-Stärke, Privileged Access Management (PAM) und Audit-Protokollierung.

MFA: Drei Stärkestufen

ENISA klassifiziert MFA in drei Stufen basierend auf Phishing-Resistenz:

1. Stark (Phishing-resistent). FIDO2, WebAuthn und Hardware-Sicherheitsschlüssel. Diese können nicht durch Phishing-Angriffe abgefangen werden, da sie kryptografische Challenge-Response-Protokolle verwenden. ENISA schreibt Stufe 1 für alle privilegierten und administrativen Konten vor. Keine Ausnahmen.
2. Mittel. TOTP-Authenticator-Apps und Push-Benachrichtigungen. Akzeptabel für Standard-Benutzerkonten. Anfällig für Echtzeit-Phishing, aber deutlich besser als nur Passwörter.
3. Letzte Option (Auslaufphase). SMS- und E-Mail-Einmalpasswörter. Anfällig für SIM-Swap-Angriffe und Abfangen. ENISA empfiehlt ausdrücklich deren Auslaufphase für alle regulierten Umgebungen.

Organisationen müssen dokumentieren, welche MFA-Stufe für jede Benutzergruppe durchgesetzt wird. Prüfer werden überprüfen, dass alle privilegierten Konten Stufe 1 verwenden und dass SMS/E-Mail-OTPs nicht mehr verwendet werden.

Privileged Access Management (PAM)

ENISA spezifiziert vier PAM-Anforderungen:

1. Funktionstrennung. Admin-Konten dürfen niemals für allgemeine Aufgaben wie E-Mail oder Browsen verwendet werden. Separate, dedizierte Konten sind für alle privilegierten Operationen erforderlich.
2. Vollständige Audit-Protokollierung. Jede privilegierte Aktion muss mit Benutzeridentität, Zeitstempel, Quell-IP und durchgeführter Aktion protokolliert werden. Protokolle müssen unveränderlich und manipulationssicher sein.
3. Just-In-Time (JIT)-Zugang. Berechtigungen werden auf Ereignisbasis gewährt und nach Verwendung automatisch widerrufen. Kein dauerhafter Admin-Zugang.
4. Drittanbieter-Zugangs-Governance. Anbieterzugang muss umfangsbegrenzt, zeitlich begrenzt und bei Vertragsende oder Projektabschluss automatisch widerrufen werden.

Audit-Protokollierung (ENISA §11.4)

Protokolle müssen:

• Zentralisiert sein. Alle Credential-Aktionen werden in einem einzigen, geschützten System protokolliert.
• Unveränderlich sein. Kein Benutzer, einschließlich Administratoren, kann Protokolleinträge ändern oder löschen.
• Exportierbar sein. Strukturierte Formate (JSON, CSV, Syslog) für SIEM-Integration und regulatorische Einreichung.
• Aufbewahrt werden. Die minimale Aufbewahrungsdauer wird durch die Risikobewertung der Organisation definiert (typischerweise 1–3 Jahre).

Unvollständige oder manipulierbare Protokolle erfüllen ENISA §11.4 nicht. Regulierungsbehörden werden sie ablehnen.

NIS2-Anforderungen auf technische Kontrollen abbilden

So erfüllen spezifische technische Kontrollen die Verpflichtungen aus Artikel 21:

Jede Kontrolle in der obigen Tabelle ist in Passworks Kernarchitektur integriert. Sie erhalten Passwortsicherheits-Dashboards, unveränderliche Audit-Trails, RBAC, MFA-Durchsetzung und AES-256-Verschlüsselung standardmäßig. Das Ergebnis: Compliance-Nachweise, die Regulierungsbehörden erwarten, keine Richtliniendokumente, die sie interpretieren müssen.

Die 5-Phasen-Implementierungs-Roadmap: Von der Bewertung zur audit-bereiten Compliance

Der Übergang von fragmentiertem Zugriffsmanagement zu audit-bereiter NIS2-Compliance erfordert keine vollständige Infrastrukturumstellung. Ein strukturierter 5-Phasen-Ansatz führt die meisten Organisationen innerhalb von 30–60 Tagen von der Bewertung zur Durchsetzung.

Phase 1: Vor-Bereitstellungs-Bewertung (Woche 1)

1. NIS2-Umfangsgrenzen definieren. Welche Geschäftsbereiche, Systeme und Benutzergruppen fallen unter die Richtlinie? Klassifizieren Sie Ihre Organisation als Wesentliche oder Wichtige Einrichtung und bestätigen Sie die anwendbaren Verpflichtungen.
2. Verantwortlichkeit zuweisen. Bestimmen Sie einen Compliance-Verantwortlichen mit Artikel-20-Verantwortlichkeit — typischerweise der CISO oder IT-Direktor. Stimmen Sie IT-, Sicherheits-, Personal- und Rechtsteams auf Rollen, Verantwortlichkeiten und Eskalationspfade ab.
3. Infrastrukturbereitschaft bestätigen. Überprüfen Sie Serverspezifikationen und Netzwerktopologie für die On-Premise-Bereitstellung. Bestätigen Sie die Active-Directory- oder LDAP-Bereitschaft für automatisierte Benutzerbereitstellung.

Phase 2: Zugriffs-Audit — wo Sie heute stehen (Woche 2)

1. Alle privilegierten Konten erfassen. Identifizieren Sie jedes Konto mit Admin-Zugang über alle Systeme und Infrastrukturen. Schließen Sie Dienstkonten und gemeinsam genutzte Anmeldedaten ein — dies sind Ihre risikoreichsten Anmeldedaten.
2. Drittanbieterzugang identifizieren. Überprüfen Sie alle aktiven Drittanbieter- und Lieferantenzugänge. Dokumentieren Sie Umfang, Dauer und aktuellen MFA-Status. Hier entdecken die meisten Organisationen unkontrollierten Zugang.
3. Aktuelle Protokollierung bewerten. Was wird heute protokolliert, wo und wie lange? Dokumentieren Sie die Lücke zwischen aktuellem Zustand und den technischen Anforderungen der ENISA.

Phase 3: Passwork in Ihrer Umgebung bereitstellen (Woche 3)

1. On-Premise installieren. Bereitstellen über Docker Compose oder Bare-Metal-Server (Linux/Windows). Passwork läuft vollständig innerhalb Ihrer Infrastruktur ohne externe Credential-Übertragung.
2. Mit Identity-Systemen integrieren. Mit Active Directory oder LDAP für automatisierte Benutzerbereitstellung verbinden. SSO über SAML 2.0 für nahtlose, prüfbare Authentifizierung konfigurieren.
3. Anmeldedaten importieren und organisieren. Vorhandene Anmeldedaten in strukturierte Tresore nach Team, System und Kritikalität migrieren. Initiale Tresorstruktur und Eigentümerhierarchie definieren.

Phase 4: Für NIS2-Compliance konfigurieren (Woche 4)

1. RBAC definieren und durchsetzen. Das Least-Privilege-Prinzip durchgehend anwenden. Jeder Benutzer greift nur auf die Anmeldedaten zu, die seine Rolle erfordert.
2. MFA vorschreiben. Stufe 1 (FIDO2) für alle privilegierten Konten durchsetzen. Stufe 2 (TOTP) für alle Standardbenutzer durchsetzen. Durchsetzung als Audit-Nachweis dokumentieren.
3. Drittanbieterzugang isolieren. Dedizierte, zeitlich begrenzte Tresore für Lieferanten und Auftragnehmer mit automatischem Ablauf bei Vertragsende erstellen.
4. Passwortrichtlinien konfigurieren. Komplexitätsregeln, Rotationspläne und automatischen Ablauf durchsetzen. Vollständige Audit-Trail-Protokollierung aktivieren und SIEM-Integration über Syslog konfigurieren.

Phase 5: Laufende Überwachung und Berichterstattung (fortlaufend)

1. Vierteljährliche Zugriffsüberprüfungen planen. Validieren, dass RBAC-Zuweisungen korrekt bleiben. Sicherstellen, dass kein verwaister Zugang nach dem Ausscheiden von Mitarbeitern verbleibt.
2. Automatisierte Compliance-Berichte generieren. MFA-Durchsetzung, Zugangs-Governance und Kontrollwirksamkeit demonstrieren. Exportierbare Nachweispakete auf Abruf für regulatorische Einreichung bereithalten.
3. Audit-Protokolle überwachen. Warnungen mit SIEM für anomale Zugriffsmuster integrieren. Jährliche NIS2-Bereitschaftsbewertungen gegen aktualisierte ENISA-Leitlinien durchführen.

Die NIS2-Compliance-Checkliste

Verwenden Sie diese Checkliste, um Ihren Compliance-Status in den drei kritischen Bereichen zu verfolgen: Zugriffsmanagement, Supply-Chain-Sicherheit und Vorfallbereitschaft.

Zugriffskontrolle (Artikel 21(2)(i))

• Alle privilegierten Konten über alle Systeme und Infrastrukturen erfassen
• Strenge RBAC implementieren — jeder Benutzer greift nur auf Anmeldedaten zu, die seine Rolle erfordert
• Alle gemeinsam genutzten Konten eliminieren — durch individuellen Zugang ersetzen
• Identitätslebenszyklus über AD/LDAP automatisieren — sofortiger Zugriffswiderruf beim Ausscheiden von Mitarbeitern
• Berechtigungsmatrizen als prüferfertige Nachweise exportieren

Supply Chain (Artikel 21(2)(d))

• Alle Drittanbieterzugänge in dedizierten, zeitlich begrenzten Tresoren isolieren
• Alle aktiven Lieferanten-Credentials auditieren — jeden Zugang widerrufen, der nicht mehr operativ gerechtfertigt ist
• Lieferantenzugangsumfang, Dauer und MFA-Status für jede aktive Drittanbieter-Credential dokumentieren
• Automatischen Ablauf bei Vertragsende konfigurieren

MFA (Artikel 21(2)(j))

• Stufe-1-MFA (FIDO2/WebAuthn) für alle administrativen Konten durchsetzen
• Stufe-2-MFA (TOTP) für alle Standardbenutzer durchsetzen
• SMS- und E-Mail-OTPs auslaufen lassen — beide erfüllen die Mindestanforderungen der ENISA nicht
• Compliance-Bericht erstellen, der MFA für alle aktiven Konten bestätigt

Vorfallbereitschaft (Artikel 23)

• Überprüfen, dass Audit-Protokolle ausreichend Details für die 24-Stunden-Frühwarnung liefern
• Workflow für massenhafte Credential-Rotation für die Reaktion nach Vorfällen etablieren und testen
• Benannte Person für Artikel-23-Meldung bestimmen
• Exportierbare Nachweispakete auf Abruf für regulatorische Einreichung vorbereiten

Audit-Protokollierung (ENISA §11.4)

• Audit-Protokolle zentralisieren und schützen — unveränderliche, exportierbare Protokollierung konfigurieren
• Mit SIEM über Syslog integrieren — sicherstellen, dass kein Benutzer Protokolleinträge ändern oder löschen kann
• Bestätigen, dass jeder Eintrag Identität, Zeitstempel, Aktion und Quell-IP erfasst
• Automatisierte Berichte erstellen, die MFA-Durchsetzung, RBAC-Compliance und Zugriffsüberprüfungen abdecken

Strafen: Was Nichteinhaltung tatsächlich kostet

Die finanziellen und persönlichen Konsequenzen der NIS2-Nichteinhaltung sind gravierend:

• Für Wesentliche Einrichtungen: Bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Regulierungsbehörden können auch temporäre Betriebseinschränkungen verhängen.
• Für Wichtige Einrichtungen: Bis zu 7 Millionen Euro oder 1,4 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Reaktive Aufsicht bedeutet nicht geringeres Risiko.
• Persönliche Haftung für das Management (Artikel 20). Vorstandsmitglieder und C-Level-Führungskräfte können persönlich für Cybersicherheitsmängel haftbar gemacht werden. Zuständige Behörden können temporäre Verbote von Managementfunktionen verhängen. Diese Bestimmung hat keinen Präzedenzfall in NIS1 und verändert grundlegend, wie Führungskräfte Compliance angehen müssen.

Ab 2026 haben nationale zuständige Behörden in der gesamten EU mit proaktiven Audits von Wesentlichen Einrichtungen begonnen. Die Durchsetzungsphase ist aktiv.

Ihr NIS2-Nachweispaket erstellen

Regulierungsbehörden wollen Beweise. Ihr Compliance-Nachweispaket muss enthalten:

1. RBAC-Konfigurationsexport. Berechtigungsmatrizen, die zeigen, welche Benutzer/Rollen Zugang zu welchen Anmeldedaten haben.
2. MFA-Durchsetzungsbericht. Systemkonfiguration, die bestätigt, dass MFA global durchgesetzt wird, mit MFA-Methode pro Benutzer.
3. Audit-Protokollmuster. Repräsentative Protokolle, die Identität, Zeitstempel, Aktion und Quell-IP für Credential-Zugriff und -Änderungen zeigen.
4. Drittanbieterzugangs-Inventar. Dokumentierter Umfang, Dauer und MFA-Status für jede aktive Lieferanten-Credential.
5. Passwortrichtlinien-Dokumentation. Durchgesetzte Komplexitätsregeln, Rotationspläne und automatische Ablaufeinstellungen.
6. Vorfallreaktionsfähigkeit. Nachweis, dass massenhafte Credential-Rotation innerhalb von Stunden durchgeführt werden kann.
7. Backup- und Failover-Aufzeichnungen. Nachweis, dass Anmeldedaten während Systemausfällen zugänglich bleiben.

Der On-Premise-Vorteil für NIS2-Compliance

Organisationen fragen oft: Warum betont NIS2 die On-Premise-Bereitstellung? Die Antwort ist Datensouveränität und Audit-Unabhängigkeit.

1. Daten bleiben, wo Sie sie kontrollieren. Alle Anmeldedaten verbleiben in Ihrem Netzwerk ohne externe Übertragung, ohne Drittanbieter-Verwahrung und ohne jurisdiktionelle Unklarheiten.
2. Audit-Protokolle, die Sie besitzen und kontrollieren. Protokolle werden lokal gespeichert, direkt an Ihr SIEM über Syslog weitergeleitet, ohne Anbieter-Vermittler, ohne Einschränkungen und ohne dass Daten Ihren Perimeter verlassen.
3. Keine Drittanbieter-Datenabhängigkeit. Da das Credential-System innerhalb Ihrer Infrastruktur läuft, hält es keine Verwahrung über Ihre Anmeldedaten, wodurch die Drittanbieter-Datenabhängigkeit eliminiert wird, die Supply-Chain-Bewertungsanforderungen unter Artikel 21(2)(d) auslöst.
4. Compliance-Nachweise zu Ihren Bedingungen. Jeder Bericht, jedes Protokoll und jeder Konfigurationsexport wird aus Ihrer eigenen Infrastruktur generiert und ist auf Abruf für Prüfer verfügbar, ohne Abhängigkeit vom Support-Team oder der Datenaufbewahrungsrichtlinie eines Anbieters.
5. Isolierte Umgebungen unterstützt. Air-Gapped-Bereitstellung für OT/ICS-Infrastrukturen mit null Netzwerkexposition. Anmeldedaten bleiben auch dort zugänglich, wo Internetkonnektivität konstruktionsbedingt verboten ist.

Fazit: Von Compliance zum Wettbewerbsvorteil

NIS2 ist ein Mandat zur Sicherung der Infrastruktur, von der die europäische Gesellschaft abhängt. Credential-basierte Angriffsvektoren dominieren die Bedrohungslandschaft 2026 — und sie sind genau das, wofür Artikel 21 konzipiert wurde.

Organisationen, die Credential-Governance zentralisieren, Phishing-resistente MFA durchsetzen und unveränderliche Audit-Trails pflegen, tun mehr als nur das Audit zu bestehen. Sie eliminieren ihre bedeutendste Angriffsfläche. Die 5-Phasen-Implementierungs-Roadmap in diesem Leitfaden führt Sie innerhalb von 30–60 Tagen von fragmentiertem Zugriffsmanagement zu audit-bereiter Compliance.

Das technische Fundament für dieses Ergebnis erfordert drei Elemente: On-Premise-Bereitstellung, die Datensouveränität garantiert, RBAC, das Least Privilege im großen Maßstab durchsetzt, und Audit-Protokolle, die Regulierungsbehörden genau die Nachweise liefern, die sie benötigen.

Passwork liefert alle 9 technischen Kontrollen in dieser Tabelle: Passwortsicherheits-Dashboards, Massenrotation, Failover-Clustering, On-Premise-Bereitstellung, unveränderliche Audit-Trails, Richtliniendurchsetzung, AES-256-Verschlüsselung, RBAC und MFA. Erhalten Sie eine kostenlose Demo und erleben Sie es in Aktion.

Bereit, von der Compliance-Planung zur Implementierung überzugehen? Laden Sie den vollständigen NIS2-Compliance-Leitfaden herunter für detaillierte technische Zuordnung, branchenspezifische Anleitungen und eine anpassbare Compliance-Checkliste.

Häufig gestellte Fragen

Was verlangt NIS2 Artikel 21 tatsächlich von meiner Organisation?

Artikel 21 schreibt 10 spezifische Sicherheitsmaßnahmen vor: Risikoanalyse, Vorfallbehandlung, Geschäftskontinuität, Supply-Chain-Sicherheit, sichere Entwicklung, Überprüfung der Kontrollwirksamkeit, Cyber-Hygiene, Verschlüsselung, Zugriffskontrolle und MFA. Alle 10 sind für jede betroffene Organisation verbindlich. Die am besten prüfbaren und sicherheitskritischsten Maßnahmen sind Zugriffskontrolle (Artikel 21(2)(i)), MFA (Artikel 21(2)(j)) und Audit-Protokollierung (Artikel 21(2)(f)).

Wer muss NIS2 einhalten?

Organisationen in 18 europäischen Sektoren, die als Wesentliche Einrichtungen klassifiziert sind, müssen sofort die Vorgaben einhalten. Dazu gehören Energie, Verkehr, Wasser, Gesundheit, digitale Infrastruktur und öffentliche Verwaltung. Wichtige Einrichtungen (Finanzdienstleistungen, Lebensmittelversorgung, Fertigung, Chemie, Raumfahrt) haben bis Oktober 2025 Zeit für die vollständige Einhaltung. Nicht-EU-Organisationen, die in diesen Sektoren innerhalb der EU-Jurisdiktion tätig sind, fallen ebenfalls in den Geltungsbereich.

Welche Strafen drohen bei Nichteinhaltung?

Wesentliche Einrichtungen riskieren Bußgelder von bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Wichtige Einrichtungen riskieren bis zu 7 Millionen Euro oder 1,4 % des weltweiten Jahresumsatzes. Vorstandsmitglieder und C-Level-Führungskräfte haften persönlich nach Artikel 20, einschließlich temporärer Verbote von Managementfunktionen. Die Durchsetzung ist ab 2026 aktiv.

Wie lange dauert die Implementierung der NIS2-Compliance für das Zugriffsmanagement?

Die meisten Organisationen erreichen mit einem strukturierten 5-Phasen-Ansatz innerhalb von 30–60 Tagen audit-bereite Compliance: Vor-Bereitstellungs-Bewertung (Woche 1), Zugriffs-Audit (Woche 2), Credential-System-Bereitstellung (Woche 3), NIS2-Konfiguration (Woche 4) und laufende Überwachung. Der Zeitrahmen hängt von der Infrastrukturkomplexität und dem Volumen der zu migrierenden vorhandenen Anmeldedaten ab.

Was ist der Unterschied zwischen Wesentlichen und Wichtigen Einrichtungen unter NIS2?

Wesentliche Einrichtungen betreiben kritische Infrastruktur (Energie, Verkehr, Wasser, Gesundheit, digitale Infrastruktur, öffentliche Verwaltung). Wichtige Einrichtungen erbringen wesentliche Dienstleistungen (Finanzdienstleistungen, Lebensmittelversorgung, Fertigung, Chemie, Raumfahrt). Wesentliche Einrichtungen sehen sich höheren Strafen (10 Millionen Euro vs. 7 Millionen Euro) und strengeren Durchsetzungszeitplänen gegenüber. Beide müssen alle 10 Maßnahmen nach Artikel 21 umsetzen.

Warum betont NIS2 das On-Premise-Credential-Management?

On-Premise-Bereitstellung garantiert Datensouveränität: Anmeldedaten verbleiben in Ihrem Netzwerk ohne externe Übertragung oder Drittanbieter-Verwahrung. Audit-Protokolle werden lokal gespeichert und direkt an Ihr SIEM weitergeleitet, ohne Anbieter-Vermittler. Dies eliminiert die Drittanbieter-Datenabhängigkeit, die Supply-Chain-Bewertungsanforderungen unter Artikel 21(2)(d) auslöst, und gibt Ihnen vollständige Audit-Unabhängigkeit.

Welche MFA-Stufe verlangt NIS2?

ENISA spezifiziert drei Stufen: Stufe 1 (Phishing-resistent) — FIDO2, WebAuthn, Hardware-Sicherheitsschlüssel — ist für alle privilegierten und administrativen Konten obligatorisch. Stufe 2 (TOTP-Authenticator-Apps, Push-Benachrichtigungen) ist für Standardbenutzer akzeptabel. SMS- und E-Mail-OTPs sind explizit zur Auslaufphase gekennzeichnet und erfüllen die Mindestanforderungen der ENISA nicht.

Wie weise ich NIS2-Compliance gegenüber Regulierungsbehörden nach?

Ihr Nachweispaket muss enthalten: RBAC-Konfigurationsexporte mit Berechtigungsmatrizen, MFA-Durchsetzungsberichte, die globale Durchsetzung bestätigen, repräsentative Audit-Protokolle mit Identität/Zeitstempel/Aktion/Quell-IP, Drittanbieterzugangs-Inventar mit Umfang und Dauer, Passwortrichtlinien-Dokumentation, Nachweis der massenhaften Credential-Rotationsfähigkeit sowie Backup-/Failover-Aufzeichnungen. Alle Nachweise müssen exportierbar und auf Abruf prüferbereit sein.

Wie sieht der Meldezeitplan nach Artikel 23 aus?

Artikel 23 führt drei Stufen ein: Frühwarnung (24 Stunden) — das nationale CSIRT benachrichtigen, dass ein Vorfall stattgefunden hat. Vorfallmeldung (72 Stunden) — erste Bewertung einschließlich Schweregrad, Auswirkungen und betroffene Systeme bereitstellen. Abschlussbericht (1 Monat) — vollständige Ursachenanalyse, Abhilfemaßnahmen und gewonnene Erkenntnisse. Organisationen ohne zentralisiertes Credential-Management und automatisierte Rotation können die 24-Stunden-Frist nicht einhalten.

Passwort- und Zugriffsmanagement für KMUs: Reicht KeePass aus?

Sie nutzen KeePass für Ihr Team? Entdecken Sie die versteckten Risiken von KeePass für KMUs im Jahr 2026 — Synchronisierungsfehler, Compliance-Lücken und wann der Wechsel zu einem Unternehmens-Passwortmanager sinnvoll ist.

Passwork BlogAlex Muntyan

Ist passwortlose Authentifizierung für NIS2-Compliance erforderlich?

NIS2 Artikel 21(2)(j) schreibt MFA „wo angemessen" vor — nicht standardmäßig passwortlos. Erfahren Sie, was die ENISA-Leitlinien tatsächlich verlangen, wie Prüfer Ihre Implementierung bewerten und wie Sie eine vertretbare hybride Compliance-Position für 2026 aufbauen.

Passwork BlogAlex Muntyan

Passwork gewinnt Top Performer Frühjahr 2026 auf SourceForge

Passwork wurde von SourceForge als Top Performer Frühjahr 2026 ausgezeichnet und rangiert unter den Top 10 % von über 100.000 Lösungen. Das Abzeichen basiert ausschließlich auf verifizierten Bewertungen — 4,8 Sterne insgesamt, mit einer perfekten 5,0 für Support.

Passwork BlogAlex Muntyan

La Directiva NIS2 (UE 2022/2555) ya no es una preocupación futura. Desde octubre de 2024, las organizaciones de 18 sectores europeos deben demostrar el cumplimiento de controles de ciberseguridad obligatorios. Las sanciones alcanzan los 10 millones de euros o el 2% de la facturación anual global, y los miembros del consejo de administración enfrentan responsabilidad personal por incumplimiento.

En el núcleo de NIS2 está el Artículo 21, que establece 10 medidas de seguridad específicas. De estas, la gestión de acceso (gobernanza de credenciales, control de acceso basado en roles, autenticación multifactor y registro de auditoría) es la más auditable y la más directamente vinculada a los resultados de las brechas de seguridad.

Esta guía relaciona esos requisitos con pasos de implementación prácticos y muestra cómo generar evidencia de cumplimiento que los reguladores esperan.

Puntos clave

• Las credenciales robadas aparecen en el 39% de todas las brechas — no solo en el acceso inicial, sino como el mecanismo principal para el movimiento lateral, la escalada de privilegios y la persistencia.
• La participación de terceros ha alcanzado el 48% en 2026, un aumento interanual del 60% que implica directamente la gobernanza del acceso a la cadena de suministro según el Artículo 21(2)(d) de NIS2.
• El Artículo 21 de NIS2 establece 10 medidas de seguridad específicas, todas obligatorias para cada entidad cubierta. Las medidas más auditables y críticas para las brechas son el control de acceso, MFA y el registro de auditoría inmutable — estas producen evidencia de cumplimiento exportable que los reguladores esperan.
• El control de acceso es donde el cumplimiento de NIS2 se vuelve medible. A diferencia de los documentos de políticas, la gobernanza de credenciales produce evidencia verificable: registros de auditoría, matrices de permisos, informes de aplicación de MFA. Los reguladores pueden confirmar que los controles se aplican activamente.
• El Artículo 23 introduce una obligación de notificación de incidentes en 24 horas. Las organizaciones sin gestión centralizada de credenciales, registros de auditoría inmutables y capacidades de rotación automatizada no pueden cumplir este plazo. La rotación masiva de contraseñas debe ser ejecutable en horas, no en días.
• ENISA especifica tres niveles de MFA. El Nivel 1 (FIDO2/WebAuthn resistente al phishing) es obligatorio para todas las cuentas privilegiadas. El Nivel 2 (TOTP) es aceptable para usuarios estándar. Los OTP por SMS y correo electrónico están explícitamente marcados para eliminación progresiva y no cumplen el umbral mínimo.
• La responsabilidad personal de los miembros del consejo de administración no tiene precedentes. El Artículo 20 responsabiliza personalmente a los ejecutivos de nivel C por fallos de ciberseguridad, incluyendo prohibiciones temporales de funciones directivas. Esta disposición no tiene precedente en NIS1.
• Las sanciones alcanzan los 10 millones de euros o el 2% de la facturación anual global para Entidades Esenciales, con aplicación activa desde 2026. Las autoridades competentes nacionales en toda la UE han comenzado auditorías proactivas. El incumplimiento ya no es una preocupación futura.
• El despliegue en las instalaciones propias elimina la custodia de datos por terceros. Las credenciales permanecen dentro de su red sin transmisión externa. Los registros de auditoría se almacenan localmente y se envían directamente a su SIEM sin intermediario del proveedor, garantizando la independencia de la auditoría.
• La hoja de ruta de implementación en 5 fases toma de 30 a 60 días desde la evaluación hasta el cumplimiento listo para auditoría: evaluación previa al despliegue, auditoría de acceso, despliegue del sistema de credenciales, configuración NIS2 y monitoreo continuo. La mayoría de las organizaciones pueden pasar de una gestión de acceso fragmentada a la aplicación dentro de este plazo.

Por qué NIS2 se centra en la gestión de acceso

El control de acceso es donde el cumplimiento de NIS2 se vuelve medible. A diferencia de los documentos de políticas o las evaluaciones de riesgos, la gobernanza de credenciales produce evidencia exportable: registros de auditoría, matrices de permisos, informes de aplicación de MFA. Los reguladores pueden verificar que los controles se aplican activamente.

El panorama de amenazas hace evidente esta urgencia. Según el Informe de Investigaciones de Brechas de Datos de Verizon de 2026, la explotación de vulnerabilidades se ha convertido en el vector de acceso inicial líder con el 31% de las brechas, frente al 20% en 2025. Sin embargo, esta comparación general oculta un hallazgo más crítico: las credenciales robadas aparecen en el 39% de todas las brechas a lo largo de todo el ciclo de vida del ataque — no solo en el acceso inicial, sino como el mecanismo principal para el movimiento lateral, la escalada de privilegios y la persistencia.

Una vez que los atacantes obtienen entrada, las credenciales se convierten en su herramienta dominante para moverse a través de la infraestructura. La participación de terceros ha alcanzado el 48% en 2026, frente al 30% en 2025 — un aumento del 60% que implica directamente la gobernanza del acceso a la cadena de suministro según el Artículo 21(2)(d) de NIS2.

Las credenciales robadas impulsan la expansión de las brechas — reutilizadas, compartidas o nunca revocadas cuando los empleados se van. El Artículo 21 de NIS2 fue diseñado para eliminar esto mediante un control de acceso estricto, MFA obligatorio y registro de auditoría inmutable.

Comprendiendo el Artículo 21 de NIS2: Las 10 medidas de seguridad obligatorias

El Artículo 21 de NIS2 requiere «medidas técnicas, operativas y organizativas apropiadas y proporcionadas» para gestionar los riesgos de ciberseguridad. Las 10 medidas son obligatorias para cada entidad cubierta. Esto es lo que exige cada una:

• Medida 1: Análisis de riesgos y políticas de seguridad de los sistemas de información. Las organizaciones deben identificar y documentar continuamente los riesgos de ciberseguridad. Esto se traduce en el descubrimiento de credenciales: mapear todas las cuentas privilegiadas, identificar credenciales compartidas y documentar qué sistemas contienen el acceso de mayor riesgo.
• Medida 2: Gestión de incidentes — prevención, detección y respuesta. Las organizaciones deben tener procedimientos documentados para responder a incidentes de seguridad. Para las brechas basadas en credenciales, esto significa la capacidad de rotar contraseñas comprometidas de forma masiva en horas, no en días.
• Medida 3: Continuidad del negocio, gestión de copias de seguridad y recuperación ante desastres. Las credenciales deben permanecer accesibles incluso cuando los sistemas principales fallan. Esto requiere clustering de conmutación por error, replicación y procedimientos de copia de seguridad probados.
• Medida 4: Seguridad de la cadena de suministro. Las organizaciones deben evaluar y gestionar los riesgos de ciberseguridad que plantean los proveedores directos y prestadores de servicios. Para las credenciales, esto significa aislar el acceso de terceros, limitarlo en el tiempo y revocarlo automáticamente cuando terminan los contratos.
• Medida 5: Seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas de información. Los sistemas deben construirse y mantenerse teniendo en cuenta la seguridad. Para los sistemas de credenciales, esto significa prácticas de desarrollo seguro y pruebas de penetración regulares.
• Medida 6: Políticas y procedimientos para evaluar la efectividad de las medidas de gestión de riesgos de ciberseguridad. Las organizaciones deben verificar que los controles realmente funcionan. Esto requiere registros de auditoría: prueba de que los controles de acceso se aplican y que cada acción de credenciales se registra.
• Medida 7: Prácticas básicas de higiene cibernética y formación en ciberseguridad. Las contraseñas débiles son el fallo de credenciales más común. Las organizaciones deben aplicar complejidad de contraseñas, programas de rotación y concienciación de seguridad del usuario.
• Medida 8: Políticas y procedimientos relativos al uso de criptografía y cifrado. Las credenciales deben estar cifradas en reposo y en tránsito. Esto significa cifrado AES-256, TLS para todas las comunicaciones y arquitectura de conocimiento cero donde el servidor nunca tiene las claves de descifrado.
• Medida 9: Seguridad de recursos humanos, políticas de control de acceso y gestión de activos. Este es el núcleo de la gobernanza de acceso de NIS2: cada usuario debe tener derechos de acceso documentados, cada cambio de acceso debe registrarse y cada credencial debe revocarse cuando el acceso ya no es necesario.
• Medida 10: Uso de MFA o soluciones de autenticación continua. La autenticación multifactor ya no es opcional. La guía técnica de ENISA especifica tres niveles de fortaleza de MFA, con autenticación resistente al phishing (FIDO2/WebAuthn) obligatoria para todas las cuentas privilegiadas.

Tabla de referencia rápida

Passwork proporciona evidencia de cumplimiento directa en 9 de las 10 medidas de NIS2. Los registros de acceso y los registros de auditoría inmutables satisfacen las medidas 1, 2 y 6. El almacenamiento cifrado cubre la medida 8. RBAC, la aplicación de MFA y el control de acceso a nivel de activos cierran las medidas 9 y 10 — donde los reguladores exigen pruebas técnicas. Obtenga una demostración gratuita y véalo en acción

La obligación de notificación de incidentes en 24 horas

El Artículo 23 de NIS2 introduce un cronograma de notificación en tres etapas que cambia fundamentalmente cómo las organizaciones responden a las brechas de credenciales.

• Alerta temprana (24 horas). Dentro de las 24 horas posteriores al descubrimiento de un incidente significativo, las organizaciones deben notificar al CSIRT nacional. No se requiere evaluación completa — solo confirmación de que ocurrió un incidente y si se sospecha actividad criminal.
• Notificación de incidente (72 horas). Proporcionar una evaluación inicial: gravedad, impacto, indicadores de compromiso (IoCs) y sistemas afectados. Aquí es donde el alcance de la brecha de credenciales se vuelve crítico. Si las credenciales de administrador fueron comprometidas, el alcance es potencialmente empresarial.
• Informe final (1 mes). Análisis completo de la causa raíz, pasos de remediación tomados, evaluación del impacto transfronterizo y lecciones aprendidas. Este es el documento que los reguladores examinarán. Para las brechas de credenciales, debe incluir prueba de que todas las contraseñas comprometidas fueron rotadas y que el acceso fue revocado para cualquier cuenta que ya no debería haber tenido acceso.

Las organizaciones sin gestión centralizada de credenciales, registros de auditoría inmutables y capacidades de rotación automatizada no pueden cumplir el plazo de 24 horas.

Guía técnica de ENISA: MFA, PAM y registro de auditoría

La Agencia de la Unión Europea para la Ciberseguridad (ENISA) publicó guía detallada de implementación técnica para NIS2. Para la gestión de acceso, tres áreas dominan: fortaleza de MFA, gestión de acceso privilegiado (PAM) y registro de auditoría.

MFA: Tres niveles de fortaleza

ENISA clasifica MFA en tres niveles según la resistencia al phishing:

1. Fuerte (resistente al phishing). FIDO2, WebAuthn y llaves de seguridad de hardware. Estos no pueden ser interceptados por ataques de phishing porque utilizan protocolos criptográficos de desafío-respuesta. ENISA exige el Nivel 1 para todas las cuentas privilegiadas y administrativas. Sin excepciones.
2. Medio. Aplicaciones autenticadoras TOTP y notificaciones push. Aceptable para cuentas de usuarios estándar. Vulnerable al phishing en tiempo real pero significativamente mejor que solo contraseñas.
3. Último recurso (eliminar progresivamente). Contraseñas de un solo uso por SMS y correo electrónico. Vulnerable a ataques de SIM-swap e interceptación. ENISA recomienda explícitamente eliminar estos para todos los entornos regulados.

Las organizaciones deben documentar qué nivel de MFA se aplica para cada grupo de usuarios. Los auditores verificarán que todas las cuentas privilegiadas usen el Nivel 1 y que los OTP por SMS/correo electrónico ya no estén en uso.

Gestión de acceso privilegiado (PAM)

ENISA especifica cuatro requisitos de PAM:

1. Separación de funciones. Las cuentas de administrador nunca deben usarse para tareas generales como correo electrónico o navegación. Se requieren cuentas separadas y dedicadas para todas las operaciones privilegiadas.
2. Registro de auditoría completo. Cada acción privilegiada debe registrarse con identidad del usuario, marca de tiempo, IP de origen y acción realizada. Los registros deben ser inmutables y a prueba de manipulaciones.
3. Acceso Just-In-Time (JIT). Privilegios otorgados por evento y revocados automáticamente después del uso. Sin acceso de administrador permanente.
4. Gobernanza de acceso de terceros. El acceso de proveedores debe estar delimitado, limitado en el tiempo y revocado automáticamente al finalizar el contrato o el proyecto.

Registro de auditoría (ENISA §11.4)

Los registros deben ser:

• Centralizados. Todas las acciones de credenciales registradas en un único sistema protegido.
• Inmutables. Ningún usuario, incluidos los administradores, puede modificar o eliminar entradas de registro.
• Exportables. Formatos estructurados (JSON, CSV, Syslog) para integración con SIEM y presentación regulatoria.
• Retenidos. Período mínimo de retención definido por la evaluación de riesgos de la entidad (típicamente 1-3 años).

Los registros incompletos o manipulables no satisfarán ENISA §11.4. Los reguladores los rechazarán.

Mapeo de requisitos NIS2 a controles técnicos

Así es como los controles técnicos específicos satisfacen las obligaciones del Artículo 21:

Cada control en la tabla anterior está integrado en la arquitectura central de Passwork. Obtiene paneles de seguridad de contraseñas, registros de auditoría inmutables, RBAC, aplicación de MFA y cifrado AES-256 de serie. El resultado: evidencia de cumplimiento que los reguladores esperan, no documentos de políticas que tienen que interpretar.

La hoja de ruta de implementación en 5 fases: De la evaluación al cumplimiento listo para auditoría

Pasar de una gestión de acceso fragmentada a un cumplimiento NIS2 listo para auditoría no requiere una reconstrucción completa de la infraestructura. Un enfoque estructurado en 5 fases lleva a la mayoría de las organizaciones de la evaluación a la aplicación en 30-60 días.

Fase 1: Evaluación previa al despliegue (semana 1)

1. Definir los límites del alcance NIS2. ¿Qué unidades de negocio, sistemas y grupos de usuarios están bajo la directiva? Clasifique su organización como Entidad Esencial o Importante y confirme las obligaciones aplicables.
2. Asignar responsabilidad. Designe un responsable de cumplimiento con responsabilidad del Artículo 20 — típicamente el CISO o Director de TI. Alinee los equipos de TI, seguridad, RRHH y legal en roles, responsabilidades y rutas de escalación.
3. Confirmar preparación de infraestructura. Verifique las especificaciones del servidor y la topología de red para el despliegue en las instalaciones propias. Confirme la preparación de Active Directory o LDAP para el aprovisionamiento automatizado de usuarios.

Fase 2: Auditoría de acceso — dónde está hoy (semana 2)

1. Mapear todas las cuentas privilegiadas. Identifique cada cuenta con acceso de administrador en todos los sistemas e infraestructura. Incluya cuentas de servicio y credenciales compartidas — estas son sus credenciales de mayor riesgo.
2. Identificar acceso de terceros. Revise todo el acceso activo de terceros y proveedores. Documente el alcance, la duración y el estado actual de MFA. Aquí es donde la mayoría de las organizaciones descubren acceso no controlado.
3. Evaluar el registro actual. ¿Qué se está registrando hoy, dónde y por cuánto tiempo? Documente la brecha entre el estado actual y los requisitos técnicos de ENISA.

Fase 3: Desplegando Passwork en su entorno (semana 3)

1. Instalar en las instalaciones propias. Despliegue mediante Docker Compose o servidor bare-metal (Linux/Windows). Passwork se ejecuta completamente dentro de su infraestructura sin transmisión externa de credenciales.
2. Integrar con sistemas de identidad. Conecte con Active Directory o LDAP para aprovisionamiento automatizado de usuarios. Configure SSO mediante SAML 2.0 para autenticación fluida y auditable.
3. Importar y organizar credenciales. Migre las credenciales existentes a bóvedas estructuradas por equipo, sistema y criticidad. Defina la estructura inicial de bóvedas y la jerarquía de propiedad.

Fase 4: Configurando para cumplimiento NIS2 (semana 4)

1. Definir y aplicar RBAC. Aplique el principio de mínimo privilegio en toda la organización. Cada usuario accede solo a las credenciales que su rol requiere.
2. Exigir MFA. Aplique Nivel 1 (FIDO2) para todas las cuentas privilegiadas. Aplique Nivel 2 (TOTP) para todos los usuarios estándar. Documente la aplicación como evidencia de auditoría.
3. Aislar acceso de terceros. Cree bóvedas dedicadas y con límite de tiempo para proveedores y contratistas con expiración automática al fin del contrato.
4. Configurar políticas de contraseñas. Aplique reglas de complejidad, programas de rotación y expiración automática. Habilite el registro completo de auditoría y configure la integración SIEM vía Syslog.

Fase 5: Monitoreo e informes continuos (continuo)

1. Programar revisiones de acceso trimestrales. Valide que las asignaciones de RBAC permanezcan precisas. Asegúrese de que no quede acceso huérfano después de las salidas de empleados.
2. Generar informes de cumplimiento automatizados. Demuestre la aplicación de MFA, gobernanza de acceso y efectividad de controles. Tenga paquetes de evidencia exportables listos para presentación regulatoria bajo demanda.
3. Monitorear registros de auditoría. Integre alertas con SIEM para patrones de acceso anómalos. Realice evaluaciones anuales de preparación NIS2 contra la guía actualizada de ENISA.

La lista de verificación de cumplimiento NIS2

Use esta lista de verificación para rastrear su postura de cumplimiento en las tres áreas críticas: gestión de acceso, seguridad de la cadena de suministro y preparación para incidentes.

Control de acceso (Artículo 21(2)(i))

• Mapear todas las cuentas privilegiadas en todos los sistemas e infraestructura
• Implementar RBAC estricto — cada usuario accede solo a las credenciales que su rol requiere
• Eliminar todas las cuentas compartidas — reemplazar con acceso individualizado
• Automatizar el ciclo de vida de identidad vía AD/LDAP — revocación inmediata del acceso tras la salida del empleado
• Exportar matrices de permisos como evidencia lista para auditores

Cadena de suministro (Artículo 21(2)(d))

• Aislar todo el acceso de terceros en bóvedas dedicadas con límite de tiempo
• Auditar todas las credenciales activas de proveedores — revocar cualquier acceso que ya no esté operativamente justificado
• Documentar el alcance del acceso de proveedores, duración y estado de MFA para cada credencial activa de terceros
• Configurar expiración automática al fin del contrato

MFA (Artículo 21(2)(j))

• Aplicar MFA Nivel 1 (FIDO2/WebAuthn) para todas las cuentas administrativas
• Aplicar MFA Nivel 2 (TOTP) para todos los usuarios estándar
• Eliminar progresivamente SMS y OTP por correo electrónico — ambos no cumplen el umbral mínimo de ENISA
• Generar informe de cumplimiento que confirme MFA en todas las cuentas activas

Preparación para incidentes (Artículo 23)

• Verificar que los registros de auditoría proporcionen detalle suficiente para la alerta temprana de 24 horas
• Establecer y probar el flujo de trabajo de rotación masiva de credenciales para respuesta post-incidente
• Designar individuo nombrado responsable de la notificación del Artículo 23
• Preparar paquetes de evidencia exportables listos para presentación regulatoria bajo demanda

Registro de auditoría (ENISA §11.4)

• Centralizar y proteger registros de auditoría — configurar registro inmutable y exportable
• Integrar con SIEM vía Syslog — asegurar que ningún usuario pueda modificar o eliminar entradas de registro
• Confirmar que cada entrada captura identidad, marca de tiempo, acción e IP de origen
• Generar informes automatizados que cubran aplicación de MFA, cumplimiento de RBAC y revisiones de acceso

Sanciones: Lo que realmente cuesta el incumplimiento

Las consecuencias financieras y personales del incumplimiento de NIS2 son severas:

• Para Entidades Esenciales: Hasta 10 millones de euros o el 2% de la facturación anual global, lo que sea mayor. Los reguladores también pueden imponer restricciones operativas temporales.
• Para Entidades Importantes: Hasta 7 millones de euros o el 1,4% de la facturación anual global, lo que sea mayor. La supervisión reactiva no significa menor riesgo.
• Responsabilidad personal de la dirección (Artículo 20). Los miembros del consejo de administración y los ejecutivos de nivel C pueden ser considerados personalmente responsables por fallos de ciberseguridad. Las autoridades competentes pueden imponer prohibiciones temporales de funciones directivas. Esta disposición no tiene precedente en NIS1, y cambia fundamentalmente cómo el liderazgo debe abordar el cumplimiento.

Desde 2026, las autoridades competentes nacionales en toda la UE han comenzado auditorías proactivas de Entidades Esenciales. La fase de aplicación está activa.

Construyendo su paquete de evidencia NIS2

Los reguladores quieren pruebas. Su paquete de evidencia de cumplimiento debe incluir:

1. Exportación de configuración RBAC. Matrices de permisos que muestren qué usuarios/roles tienen acceso a qué credenciales.
2. Informe de aplicación de MFA. Configuración del sistema que confirme que MFA se aplica globalmente, con método MFA por usuario.
3. Muestras de registros de auditoría. Registros representativos que muestren identidad, marca de tiempo, acción e IP de origen para acceso y modificaciones de credenciales.
4. Inventario de acceso de terceros. Alcance documentado, duración y estado de MFA para cada credencial activa de proveedor.
5. Documentación de política de contraseñas. Reglas de complejidad aplicadas, programas de rotación y configuración de expiración automática.
6. Capacidad de respuesta a incidentes. Prueba de que la rotación masiva de credenciales puede ejecutarse en horas.
7. Registros de copia de seguridad y conmutación por error. Evidencia de que las credenciales permanecen accesibles durante fallos del sistema.

La ventaja del despliegue en las instalaciones propias para el cumplimiento NIS2

Las organizaciones a menudo preguntan: ¿por qué NIS2 enfatiza el despliegue en las instalaciones propias? La respuesta es soberanía de datos e independencia de auditoría.

1. Los datos permanecen donde usted los gobierna. Todas las credenciales permanecen dentro de su red sin transmisión externa, sin custodia de terceros y sin ambigüedad jurisdiccional.
2. Registros de auditoría que usted posee y controla. Los registros se almacenan localmente, se envían directamente a su SIEM vía Syslog sin intermediario del proveedor, sin restricciones y sin datos que salgan de su perímetro.
3. Sin dependencia de datos de terceros. Debido a que el sistema de credenciales se ejecuta dentro de su infraestructura, no tiene custodia sobre sus credenciales, eliminando la dependencia de datos de terceros que desencadena los requisitos de evaluación de la cadena de suministro bajo el Artículo 21(2)(d).
4. Evidencia de cumplimiento en sus términos. Cada informe, registro y exportación de configuración se genera desde su propia infraestructura y está disponible bajo demanda para auditores, sin dependencia del equipo de soporte del proveedor o política de retención de datos.
5. Entornos aislados soportados. Despliegue con air gap para infraestructuras OT/ICS con cero exposición de red. Las credenciales permanecen accesibles incluso donde la conectividad a internet está prohibida por diseño.

Conclusión: Del cumplimiento a la ventaja competitiva

NIS2 es un mandato para asegurar la infraestructura de la que depende la sociedad europea. Los vectores de ataque basados en credenciales dominan el panorama de amenazas de 2026 — y son precisamente lo que el Artículo 21 fue diseñado para abordar.

Las organizaciones que centralizan la gobernanza de credenciales, aplican MFA resistente al phishing y mantienen registros de auditoría inmutables hacen más que pasar la auditoría. Eliminan su superficie de ataque más significativa. La hoja de ruta de implementación en 5 fases de esta guía le lleva de una gestión de acceso fragmentada a un cumplimiento listo para auditoría en 30-60 días.

La base técnica para ese resultado requiere tres elementos: despliegue en las instalaciones propias que garantice la soberanía de datos, RBAC que aplique el mínimo privilegio a escala y registros de auditoría que proporcionen a los reguladores exactamente la evidencia que necesitan.

Passwork ofrece los 9 controles técnicos de esta tabla: paneles de seguridad de contraseñas, rotación masiva, clustering de conmutación por error, despliegue en las instalaciones propias, registros de auditoría inmutables, aplicación de políticas, cifrado AES-256, RBAC y MFA. Obtenga una demostración gratuita y véalo en acción.

¿Listo para pasar de la planificación del cumplimiento a la implementación? Descargue la guía completa de cumplimiento NIS2 para mapeo técnico detallado, orientación específica por sector y una lista de verificación de cumplimiento personalizable.

Preguntas frecuentes

¿Qué exige realmente el Artículo 21 de NIS2 a mi organización?

El Artículo 21 establece 10 medidas de seguridad específicas: análisis de riesgos, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, desarrollo seguro, verificación de efectividad de controles, higiene cibernética, cifrado, control de acceso y MFA. Las 10 son obligatorias para cada entidad cubierta. Las medidas más auditables y críticas para las brechas son el control de acceso (Artículo 21(2)(i)), MFA (Artículo 21(2)(j)) y registro de auditoría (Artículo 21(2)(f)).

¿Quién está obligado a cumplir con NIS2?

Las organizaciones en 18 sectores europeos clasificadas como Entidades Esenciales deben cumplir inmediatamente. Estas incluyen energía, transporte, agua, salud, infraestructura digital y administración pública. Las Entidades Importantes (servicios financieros, suministro de alimentos, manufactura, productos químicos, espacio) tienen hasta octubre de 2025 para el cumplimiento total. Las organizaciones no pertenecientes a la UE que operan en estos sectores dentro de la jurisdicción de la UE también están en el ámbito de aplicación.

¿Cuáles son las sanciones por incumplimiento?

Las Entidades Esenciales enfrentan multas de hasta 10 millones de euros o el 2% de la facturación anual global, lo que sea mayor. Las Entidades Importantes enfrentan hasta 7 millones de euros o el 1,4% de la facturación anual global. Los miembros del consejo de administración y los ejecutivos de nivel C enfrentan responsabilidad personal bajo el Artículo 20, incluyendo prohibiciones temporales de funciones directivas. La aplicación está activa desde 2026.

¿Cuánto tiempo lleva implementar el cumplimiento NIS2 para la gestión de acceso?

La mayoría de las organizaciones pasan de la evaluación al cumplimiento listo para auditoría en 30-60 días utilizando un enfoque estructurado en 5 fases: evaluación previa al despliegue (semana 1), auditoría de acceso (semana 2), despliegue del sistema de credenciales (semana 3), configuración NIS2 (semana 4) y monitoreo continuo. El plazo depende de la complejidad de la infraestructura y el volumen de credenciales existentes a migrar.

¿Cuál es la diferencia entre Entidades Esenciales e Importantes bajo NIS2?

Las Entidades Esenciales operan infraestructura crítica (energía, transporte, agua, salud, infraestructura digital, administración pública). Las Entidades Importantes proporcionan servicios esenciales (servicios financieros, suministro de alimentos, manufactura, productos químicos, espacio). Las Entidades Esenciales enfrentan sanciones más altas (10 millones de euros vs. 7 millones de euros) y plazos de aplicación más estrictos. Ambas deben implementar las 10 medidas del Artículo 21.

¿Por qué NIS2 enfatiza la gestión de credenciales en las instalaciones propias?

El despliegue en las instalaciones propias garantiza la soberanía de datos: las credenciales permanecen dentro de su red sin transmisión externa ni custodia de terceros. Los registros de auditoría se almacenan localmente y se envían directamente a su SIEM sin intermediario del proveedor. Esto elimina la dependencia de datos de terceros que desencadena los requisitos de evaluación de la cadena de suministro bajo el Artículo 21(2)(d) y le proporciona independencia de auditoría completa.

¿Qué nivel de MFA requiere NIS2?

ENISA especifica tres niveles: Nivel 1 (resistente al phishing) — FIDO2, WebAuthn, llaves de seguridad de hardware — es obligatorio para todas las cuentas privilegiadas y administrativas. Nivel 2 (aplicaciones autenticadoras TOTP, notificaciones push) es aceptable para usuarios estándar. Los OTP por SMS y correo electrónico están explícitamente marcados para eliminación progresiva y no cumplen el umbral mínimo de ENISA.

¿Cómo demuestro el cumplimiento NIS2 a los reguladores?

Su paquete de evidencia debe incluir: exportaciones de configuración RBAC que muestren matrices de permisos, informes de aplicación de MFA que confirmen la aplicación global, registros de auditoría representativos con identidad/marca de tiempo/acción/IP de origen, inventario de acceso de terceros con alcance y duración, documentación de política de contraseñas, prueba de capacidad de rotación masiva de credenciales y registros de copia de seguridad/conmutación por error. Toda la evidencia debe ser exportable y estar lista para auditores bajo demanda.

¿Cuál es el cronograma de notificación del Artículo 23?

El Artículo 23 introduce tres etapas: Alerta temprana (24 horas) — notificar al CSIRT nacional que ocurrió un incidente. Notificación de incidente (72 horas) — proporcionar evaluación inicial incluyendo gravedad, impacto y sistemas afectados. Informe final (1 mes) — análisis completo de causa raíz, pasos de remediación y lecciones aprendidas. Las organizaciones sin gestión centralizada de credenciales y rotación automatizada no pueden cumplir el plazo de 24 horas.

Gestión de contraseñas y acceso para pymes: ¿Es suficiente KeePass?

¿Usa KeePass para su equipo? Descubra los riesgos ocultos de KeePass para pymes en 2026 — fallos de sincronización, brechas de cumplimiento y cuándo cambiar a un gestor de contraseñas corporativo.

Passwork BlogAlex Muntyan

¿Es obligatoria la autenticación sin contraseña para el cumplimiento de NIS2?

El Artículo 21(2)(j) de NIS2 exige MFA «cuando sea apropiado» — no sin contraseña por defecto. Conozca lo que realmente requiere la guía de ENISA, cómo evalúan los auditores su implementación y cómo construir una postura de cumplimiento híbrida defendible para 2026.

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

The NIS2 Directive (EU 2022/2555) is no longer a future concern. As of October 2024, organizations across 18 European sectors must demonstrate compliance with mandatory cybersecurity controls. Penalties reach €10 million or 2% of global annual turnover, and board members face personal liability for non-compliance.

At the core of NIS2 is Article 21, which mandates 10 specific security measures. Of these, access management (credential governance, role-based access control, multi-factor authentication, and audit logging) is the most auditable and the most directly linked to breach outcomes.

This guide maps those requirements to practical implementation steps and shows how to generate compliance evidence that regulators expect.

Key takeaways

• Stolen credentials appear in 39% of all breaches — not just at initial access, but as the primary mechanism for lateral movement, privilege escalation, and persistence.
• Third-party involvement has reached 48% in 2026, a 60% year-over-year increase that directly implicates supply chain access governance under NIS2 Article 21(2)(d).
• NIS2 Article 21 mandates 10 specific security measures, all mandatory for every covered entity. The most auditable and breach-critical measures are access control, MFA, and immutable audit logging — these produce exportable compliance evidence regulators expect.
• Access control is where NIS2 compliance becomes measurable. Unlike policy documents, credential governance produces verifiable evidence: audit logs, permission matrices, MFA enforcement reports. Regulators can confirm that controls are actively enforced.
• Article 23 introduces a 24-hour incident reporting obligation. Organizations without centralized credential management, immutable audit trails, and automated rotation capabilities cannot meet this deadline. Bulk password rotation must be executable within hours, not days.
• ENISA specifies three MFA tiers. Tier 1 (phishing-resistant FIDO2/WebAuthn) is mandatory for all privileged accounts. Tier 2 (TOTP) is acceptable for standard users. SMS and email OTPs are explicitly flagged for phase-out and do not meet the minimum threshold.
• Personal liability for board members is unprecedented. Article 20 holds C-suite executives personally accountable for cybersecurity failures, including temporary bans from management roles. This provision has no precedent in NIS1.
• Penalties reach €10 million or 2% of global annual turnover for Essential Entities, with enforcement active as of 2026. National competent authorities across the EU have begun proactive audits. Non-compliance is no longer a future concern.
• On-premise deployment eliminates third-party data custody. Credentials remain inside your network with no external transmission. Audit logs are stored locally and piped directly to your SIEM with no vendor intermediary, guaranteeing audit independence.
• The 5-phase implementation roadmap takes 30–60 days from assessment to audit-ready compliance: pre-deployment assessment, access audit, credential system deployment, NIS2 configuration, and ongoing monitoring. Most organizations can move from fragmented access management to enforcement within this timeline.

Why NIS2 focuses on access management

Access control is where NIS2 compliance becomes measurable. Unlike policy documents or risk assessments, credential governance produces exportable evidence: audit logs, permission matrices, MFA enforcement reports. Regulators can verify that controls are actively enforced.

The threat landscape makes this urgency clear. According to Verizon's 2026 Data Breach Investigations Report, vulnerability exploitation has become the leading initial access vector at 31% of breaches, up from 20% in 2025. However, this headline comparison obscures a more critical finding: stolen credentials appear in 39% of all breaches across the entire attack lifecycle — not just at initial access, but as the primary mechanism for lateral movement, privilege escalation, and persistence.

Once attackers gain entry, credentials become their dominant tool for moving through the infrastructure. Third-party involvement has reached 48% in 2026, up from 30% in 2025 — a 60% increase that directly implicates supply chain access governance under NIS2 Article 21(2)(d). ,

Stolen credentials drive breach expansion — reused, shared, or never revoked when employees leave. NIS2 Article 21 was designed to eliminate this through strict access control, mandatory MFA, and immutable audit logging.

Understanding NIS2 Article 21: The 10 mandatory security measures

NIS2 Article 21 requires "appropriate and proportionate technical, operational and organisational measures" to manage cybersecurity risks. All 10 measures are mandatory for every covered entity. Here's what each one demands:

• Measure 1: Risk analysis and information system security policies. Organizations must continuously identify and document cybersecurity risks. This translates to credential discovery: mapping all privileged accounts, identifying shared credentials, and documenting which systems hold the highest-risk access.
• Measure 2: Incident handling — prevention, detection, and response. Organizations must have documented procedures for responding to security incidents. For credential-based breaches, this means the ability to rotate compromised passwords in bulk within hours, not days.
• Measure 3: Business continuity, backup management, and disaster recovery. Credentials must remain accessible even when primary systems fail. This requires failover clustering, replication, and tested backup procedures.
• Measure 4: Supply chain security. Organizations must assess and manage the cybersecurity risks posed by direct suppliers and service providers. For credentials, this means isolating third-party access, time-bounding it, and revoking it automatically when contracts end.
• Measure 5: Security in network and information systems acquisition, development, and maintenance. Systems must be built and maintained with security in mind. For credential systems, this means secure development practices and regular penetration testing.
• Measure 6: Policies and procedures to assess the effectiveness of cybersecurity risk-management measures. Organizations must verify that controls actually work. This requires audit trails: proof that access controls are enforced and that every credential action is logged.
• Measure 7: Basic cyber hygiene practices and cybersecurity training. Weak passwords are the most common credential failure. Organizations must enforce password complexity, rotation schedules, and user security awareness.
• Measure 8: Policies and procedures regarding the use of cryptography and encryption. Credentials must be encrypted at rest and in transit. This means AES-256 encryption, TLS for all communications, and zero-knowledge architecture where the server never holds decryption keys.
• Measure 9: Human resources security, access control policies, and asset management. This is the core of NIS2 access governance: every user must have documented access rights, every access change must be logged, and every credential must be revoked when access is no longer needed.
• Measure 10: Use of MFA or continuous authentication solutions. Multi-factor authentication is no longer optional. ENISA's technical guidance specifies three tiers of MFA strength, with phishing-resistant authentication (FIDO2/WebAuthn) mandatory for all privileged accounts.

Quick reference table

Passwork delivers direct compliance evidence across 9 of the 10 NIS2 measures. Access logs and immutable audit trails satisfy measures 1, 2, and 6. Encrypted storage covers measure 8. RBAC, MFA enforcement, and asset-level access control close out measures 9 and 10 — where regulators demand technical proof. Get a free demo and see it in action

The 24-hour incident reporting obligation

NIS2 Article 23 introduces a three-stage reporting timeline that fundamentally changes how organizations respond to credential breaches.

• Early Warning (24 hours). Within 24 hours of discovering a significant incident, organizations must notify the national CSIRT. No full assessment required — just confirmation that an incident occurred and whether criminal activity is suspected.
• Incident Notification (72 hours). Provide an initial assessment: severity, impact, indicators of compromise (IoCs), and affected systems. This is where credential breach scope becomes critical. If admin credentials were compromised, the scope is potentially enterprise-wide.
• Final Report (1 month). Full root cause analysis, remediation steps taken, cross-border impact assessment, and lessons learned. This is the document regulators will scrutinize. For credential breaches, it must include proof that all compromised passwords were rotated and that access was revoked for any accounts that should no longer have had access.

Organizations without centralized credential management, immutable audit trails, and automated rotation capabilities cannot meet the 24-hour deadline.

ENISA Technical Guidance: MFA, PAM, and audit logging

The European Union Agency for Cybersecurity (ENISA) published detailed technical implementation guidance for NIS2. For access management, three areas dominate: MFA strength, privileged access management (PAM), and audit logging.

MFA: Three tiers of strength

ENISA classifies MFA into three tiers based on phishing resistance:

1. Strong (Phishing-Resistant). FIDO2, WebAuthn, and hardware security keys. These cannot be intercepted by phishing attacks because they use cryptographic challenge-response protocols. ENISA mandates Tier 1 for all privileged and administrative accounts. No exceptions.
2. Medium. TOTP authenticator apps and push notifications. Acceptable for standard user accounts. Vulnerable to real-time phishing but significantly better than passwords alone.
3. Last Resort (Phase Out). SMS and email one-time passwords. Vulnerable to SIM-swap attacks and interception. ENISA explicitly recommends phasing these out for all regulated environments.

Organizations must document which MFA tier is enforced for each user group. Auditors will verify that all privileged accounts use Tier 1 and that SMS/email OTPs are no longer in use.

Privileged Access Management (PAM)

ENISA specifies four PAM requirements:

1. Separation of duties. Admin accounts must never be used for general tasks like email or browsing. Separate, dedicated accounts required for all privileged operations.
2. Full audit logging. Every privileged action must be logged with user identity, timestamp, source IP, and action taken. Logs must be immutable and tamper-evident.
3. Just-In-Time (JIT) access. Privileges granted on a per-event basis and automatically revoked after use. No standing admin access.
4. Third-party access governance. Vendor access must be scoped, time-limited, and automatically revoked upon contract end or project completion.

Audit logging (ENISA §11.4)

Logs must be:

• Centralized. All credential actions logged to a single, protected system.
• Immutable. No user, including administrators, can modify or delete log entries.
• Exportable. Structured formats (JSON, CSV, Syslog) for SIEM integration and regulatory submission.
• Retained. Minimum retention period defined by the entity's risk assessment (typically 1–3 years).

Incomplete or tamper-able logs will not satisfy ENISA §11.4. Regulators will reject them.

Mapping NIS2 requirements to technical controls

Here's how specific technical controls satisfy Article 21 obligations:

Every control in the table above is built into Passwork's core architecture. You get password security dashboards, immutable audit trails, RBAC, MFA enforcement, and AES-256 encryption out of the box. The result: compliance evidence that regulators expect, not policy documents they have to interpret.

The 5-phase implementation roadmap: From assessment to audit-ready compliance

Moving from fragmented access management to audit-ready NIS2 compliance doesn't require a complete infrastructure rebuild. A structured 5-phase approach takes most organizations from assessment to enforcement within 30–60 days.

Phase 1: Pre-deployment assessment (week 1)

1. Define NIS2 scope boundaries. Which business units, systems, and user groups fall under the directive? Classify your organization as Essential or Important entity and confirm applicable obligations.
2. Assign accountability. Designate a compliance owner with Article 20 accountability — typically the CISO or IT Director. Align IT, security, HR, and legal teams on roles, responsibilities, and escalation paths.
3. Confirm infrastructure readiness. Verify server specifications and network topology for on-premise deployment. Confirm Active Directory or LDAP readiness for automated user provisioning.

Phase 2: Access audit — where you stand today (week 2)

1. Map all privileged accounts. Identify every account with admin access across all systems and infrastructure. Include service accounts and shared credentials — these are your highest-risk credentials.
2. Identify third-party access. Review all active third-party and vendor access. Document scope, duration, and current MFA status. This is where most organizations discover uncontrolled access.
3. Assess current logging. What is being logged today, where, and for how long? Document the gap between current state and ENISA's technical requirements.

Phase 3: Deploying Passwork in your environment (week 3)

1. Install on-premise. Deploy via Docker Compose or bare-metal server (Linux/Windows). Passwork runs entirely within your infrastructure with no external credential transmission.
2. Integrate with identity systems. Connect to Active Directory or LDAP for automated user provisioning. Configure SSO via SAML 2.0 for seamless, auditable authentication.
3. Import and organize credentials. Migrate existing credentials into structured vaults by team, system, and criticality. Define initial vault structure and ownership hierarchy.

Phase 4: Configuring for NIS2 compliance (week 4)

1. Define and enforce RBAC. Apply the least-privilege principle throughout. Every user accesses only the credentials their role requires.
2. Mandate MFA. Enforce Tier 1 (FIDO2) for all privileged accounts. Enforce Tier 2 (TOTP) for all standard users. Document enforcement as audit evidence.
3. Isolate third-party access. Create dedicated, time-bound vaults for vendors and contractors with automatic expiry at contract end.
4. Configure password policies. Enforce complexity rules, rotation schedules, and automatic expiry. Enable full audit trail logging and configure SIEM integration via Syslog.

Phase 5: Ongoing monitoring and reporting (ongoing)

1. Schedule quarterly access reviews. Validate that RBAC assignments remain accurate. Ensure no orphaned access remains after employee departures.
2. Generate automated compliance reports. Demonstrate MFA enforcement, access governance, and control effectiveness. Have exportable evidence packages ready for regulatory submission on demand.
3. Monitor audit logs. Integrate alerts with SIEM for anomalous access patterns. Conduct annual NIS2 readiness assessments against updated ENISA guidance.

The NIS2 compliance checklist

Use this checklist to track your compliance posture across the three critical areas: access management, supply chain security, and incident readiness.

Access control (Article 21(2)(i))

• Map all privileged accounts across all systems and infrastructure
• Implement strict RBAC — every user accesses only credentials their role requires
• Eliminate all shared accounts — replace with individualized access
• Automate identity lifecycle via AD/LDAP — immediate access revocation upon employee exit
• Export permission matrices as auditor-ready evidence

Supply chain (Article 21(2)(d))

• Isolate all third-party access in dedicated, time-bound vaults
• Audit all active vendor credentials — revoke any access no longer operationally justified
• Document vendor access scope, duration, and MFA status for every active third-party credential
• Configure automatic expiry at contract end

MFA (Article 21(2)(j))

• Enforce Tier 1 MFA (FIDO2/WebAuthn) for all administrative accounts
• Enforce Tier 2 MFA (TOTP) for all standard users
• Phase out SMS and email OTPs — both fail ENISA's minimum threshold
• Generate compliance report confirming MFA across all active accounts

Incident readiness (Article 23)

• Verify audit logs provide sufficient detail for 24-hour early warning
• Establish and test bulk credential rotation workflow for post-incident response
• Designate named individual responsible for Article 23 notification
• Prepare exportable evidence packages ready for regulatory submission on demand

Audit logging (ENISA §11.4)

• Centralize and protect audit logs — configure immutable, exportable logging
• Integrate with SIEM via Syslog — ensure no user can modify or delete log entries
• Confirm every entry captures identity, timestamp, action, and source IP
• Generate automated reports covering MFA enforcement, RBAC compliance, and access reviews

Penalties: What non-compliance actually costs

The financial and personal consequences of NIS2 non-compliance are severe:

• For Essential Entities: Up to €10 million or 2% of global annual turnover, whichever is higher. Regulators may also impose temporary operational restrictions.
• For Important Entities: Up to €7 million or 1.4% of global annual turnover, whichever is higher. Reactive supervision does not mean lower risk.
• Personal liability for management (Article 20). Board members and C-suite executives can be held personally liable for cybersecurity failures. Competent authorities may impose temporary bans from management roles. This provision has no precedent in NIS1, and it fundamentally changes how leadership must approach compliance.

As of 2026, national competent authorities across the EU have begun proactive audits of Essential Entities. The enforcement phase is active.

Building your NIS2 evidence package

Regulators want proof. Your compliance evidence package must include:

1. RBAC configuration export. Permission matrices showing which users/roles have access to which credentials.
2. MFA enforcement report. System configuration confirming MFA is globally enforced, with MFA method per user.
3. Audit log samples. Representative logs showing identity, timestamp, action, and source IP for credential access and modifications.
4. Third-party access inventory. Documented scope, duration, and MFA status for every active vendor credential.
5. Password policy documentation. Enforced complexity rules, rotation schedules, and automatic expiry settings.
6. Incident response capability. Proof that bulk credential rotation can be executed within hours.
7. Backup and failover records. Evidence that credentials remain accessible during system failures.

The On-Premise advantage for NIS2 compliance

Organizations often ask: why does NIS2 emphasize on-premise deployment? The answer is data sovereignty and audit independence.

1. Data stays where you govern it. All credentials remain inside your network with no external transmission, no third-party custody, and no jurisdictional ambiguity.
2. Audit logs you own and control. Logs are stored locally, pipe directly to your SIEM via Syslog with no vendor intermediary, no restrictions, and no data leaving your perimeter.
3. No third-party data dependency. Because the credential system runs within your infrastructure, it holds no custody over your credentials, eliminating the third-party data dependency that triggers supply chain assessment requirements under Article 21(2)(d).
4. Compliance evidence on your terms. Every report, log, and configuration export is generated from your own infrastructure and available on demand for auditors, without dependency on a vendor's support team or data retention policy.
5. Isolated environments supported. Air-gapped deployment for OT/ICS infrastructures with zero network exposure. Credentials remain accessible even where internet connectivity is prohibited by design.

Conclusion: From compliance to competitive advantage

NIS2 is a mandate to secure the infrastructure that European society depends on. Credential-based attack vectors dominate the 2026 threat landscape — and they are precisely what Article 21 was designed to address.

Organizations that centralize credential governance, enforce phishing-resistant MFA, and maintain immutable audit trails do more than pass the audit. They eliminate their most significant attack surface. The 5-phase implementation roadmap in this guide takes you from fragmented access management to audit-ready compliance within 30–60 days.

The technical foundation for that outcome requires three elements: on-premise deployment that guarantees data sovereignty, RBAC that enforces least privilege at scale, and audit logs that give regulators exactly the evidence they need.

Passwork delivers all 9 technical controls in this table: password security dashboards, bulk rotation, failover clustering, on-premise deployment, immutable audit trails, policy enforcement, AES-256 encryption, RBAC, and MFA. Get a free demo and see it in action.

Ready to move from compliance planning to implementation? Download the full NIS2 compliance guide for detailed technical mapping, sector-specific guidance, and a customizable compliance checklist.

Frequently asked questions

What does NIS2 Article 21 actually require from my organization?

Article 21 mandates 10 specific security measures: risk analysis, incident handling, business continuity, supply chain security, secure development, control effectiveness verification, cyber hygiene, encryption, access control, and MFA. All 10 are mandatory for every covered entity. The most auditable and breach-critical measures are access control (Article 21(2)(i)), MFA (Article 21(2)(j)), and audit logging (Article 21(2)(f)).

Who is required to comply with NIS2?

Organizations in 18 European sectors classified as Essential Entities must comply immediately. These include energy, transport, water, health, digital infrastructure, and public administration. Important Entities (financial services, food supply, manufacturing, chemicals, space) have until October 2025 for full compliance. Non-EU organizations operating in these sectors within EU jurisdiction are also in scope.

What are the penalties for non-compliance?

Essential Entities face fines up to €10 million or 2% of global annual turnover, whichever is higher. Important Entities face up to €7 million or 1.4% of global annual turnover. Board members and C-suite executives face personal liability under Article 20, including temporary bans from management roles. Enforcement is active as of 2026.

How long does it take to implement NIS2 compliance for access management?

Most organizations move from assessment to audit-ready compliance within 30–60 days using a structured 5-phase approach: pre-deployment assessment (week 1), access audit (week 2), credential system deployment (week 3), NIS2 configuration (week 4), and ongoing monitoring. The timeline depends on infrastructure complexity and the volume of existing credentials to migrate.

What is the difference between Essential and Important Entities under NIS2?

Essential Entities operate critical infrastructure (energy, transport, water, health, digital infrastructure, public administration). Important Entities provide essential services (financial services, food supply, manufacturing, chemicals, space). Essential Entities face higher penalties (€10 million vs. €7 million) and stricter enforcement timelines. Both must implement all 10 Article 21 measures.

Why does NIS2 emphasize on-premise credential management?

On-premise deployment guarantees data sovereignty: credentials remain inside your network with no external transmission or third-party custody. Audit logs are stored locally and piped directly to your SIEM with no vendor intermediary. This eliminates the third-party data dependency that triggers supply chain assessment requirements under Article 21(2)(d) and gives you complete audit independence.

What MFA tier does NIS2 require?

ENISA specifies three tiers: Tier 1 (phishing-resistant) — FIDO2, WebAuthn, hardware security keys — is mandatory for all privileged and administrative accounts. Tier 2 (TOTP authenticator apps, push notifications) is acceptable for standard users. SMS and email OTPs are explicitly flagged for phase-out and do not meet ENISA's minimum threshold.

How do I prove NIS2 compliance to regulators?

Your evidence package must include: RBAC configuration exports showing permission matrices, MFA enforcement reports confirming global enforcement, representative audit logs with identity/timestamp/action/source IP, third-party access inventory with scope and duration, password policy documentation, proof of bulk credential rotation capability, and backup/failover records. All evidence must be exportable and auditor-ready on demand.

What is the Article 23 reporting timeline?

Article 23 introduces three stages: Early Warning (24 hours) — notify the national CSIRT that an incident occurred. Incident Notification (72 hours) — provide initial assessment including severity, impact, and affected systems. Final Report (1 month) — full root cause analysis, remediation steps, and lessons learned. Organizations without centralized credential management and automated rotation cannot meet the 24-hour deadline.

Password and access management for SMBs: Is KeePass enough?

Using KeePass for your team? Discover the hidden risks of KeePass for SMBs in 2026 — sync failures, compliance gaps, and when to switch to a corporate password manager.

Passwork BlogAlex Muntyan

Is NIS2 passwordless authentication required for compliance?

NIS2 Article 21(2)(j) mandates MFA “where appropriate” — not passwordless by default. Learn what ENISA guidance actually requires, how auditors evaluate your implementation, and how to build a defensible hybrid compliance posture for 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