La criptografía en España no es un asunto técnico que pueda delegarse al equipo de IT. Es una obligación legal con consecuencias directas para el consejo de administración: multas de hasta 10 millones de euros, responsabilidad personal de los directivos y exclusión de la contratación pública. Este artículo cubre cada capa del marco normativo: algoritmos aprobados, leyes aplicables, organismos supervisores, sectores obligados, sanciones reales y en qué se diferencia el modelo español del resto del mundo.

1. La estructura de autoridad criptográfica: quién decide qué es legal

El Centro Criptológico Nacional (CCN)

El CCN es la autoridad criptológica nacional de España, constituido bajo el Real Decreto 421/2004 como división del Centro Nacional de Inteligencia (CNI). Tiene tres poderes que todo directivo debe conocer.

Aprobación de algoritmos. El CCN publica la lista definitiva de mecanismos criptográficos autorizados en la serie de guías CCN-STIC 221. Ningún algoritmo tiene respaldo legal para su uso en el sector público español ni en entornos regulados sin figurar en esta guía. La edición de noviembre de 2025 es la referencia en vigor.

Certificación de productos. El CCN gestiona el Catálogo de Productos de Seguridad TIC (CPSTIC), la lista oficial de productos autorizados para la administración pública. Los productos se clasifican como Cualificados (para ENS Medio/Alto) o Aprobados (para información clasificada nacional). La inclusión requiere superar uno de dos esquemas: LINCE (el esquema ligero español, válido para ENS Medio) o Common Criteria / EUCC bajo el acuerdo de reconocimiento mutuo SOG-IS (obligatorio para ENS Alto). Desde 2024–2025, el CCN exige adicionalmente la MEMeC (CCN-STIC 2100) — Metodología para la Evaluación de Mecanismos Criptográficos — para cualquier producto que solicite inclusión en el CPSTIC cuando el cifrado sea su función principal.

Respuesta a incidentes. El CCN-CERT gestiona los incidentes de ciberseguridad de la administración pública, los sistemas clasificados y las infraestructuras críticas nacionales. El CCN es también la Autoridad Nacional de Certificación de Ciberseguridad de la UE, conforme al Reglamento de Ciberseguridad (2019/881).

Otros organismos reguladores clave

2. El marco legal en detalle

2.1 Derecho de la UE de aplicación directa

2.2 Legislación nacional primaria

Real Decreto 311/2022 — Esquema Nacional de Seguridad (ENS)

El ENS es el marco maestro de seguridad de la información del sector público. Actualizado en mayo de 2022, sustituye al RD 3/2010 y se aplica a todas las administraciones públicas (central, autonómica, local) y a todo proveedor privado de servicios TIC a las mismas. Aspectos clave para el cumplimiento criptográfico:

• Tres categorías de seguridad: Básica, Media, Alta, determinadas por la evaluación de impacto del Anexo I en las dimensiones de confidencialidad, integridad, disponibilidad, autenticidad y trazabilidad.
• Los controles de criptografía del Anexo II escalan significativamente de Básica a Alta.
• Para sistemas ENS Alto: solo se aceptan algoritmos aprobados por el CCN (CCN-STIC 221) y productos del CPSTIC; los módulos criptográficos deben superar evaluación MEMeC/LINCE o CC/SOG-IS.
• Auditorías externas obligatorias cada dos años en categorías Media y Alta.
• La certificación de conformidad es requisito en licitaciones públicas: un proveedor sin certificado ENS queda excluido del proceso, con independencia del precio.

Ley Orgánica 3/2018 — LOPDGDD

La ley española de implementación del RGPD. Añade obligaciones específicas más allá del RGPD: el Título X (Derechos digitales) refuerza los principios de seguridad de datos que sustentan las obligaciones de cifrado. La AEPD ha consolidado mediante su práctica sancionadora que el cifrado de datos personales en reposo y en tránsito es la medida técnica mínima exigida — y que su ausencia, incluso con posterioridad a una brecha, constituye una infracción independiente del artículo 5(1)(f) adicional a la del artículo 32.

Ley 6/2020 sobre servicios de confianza electrónicos

Aprobada en noviembre de 2020, derogó la histórica Ley 59/2003 de Firma Electrónica. Adapta el derecho nacional a la taxonomía eIDAS: firmas simples, avanzadas y cualificadas, sellos, marcas de tiempo y entregas certificadas. En España, las firmas electrónicas cualificadas (QES) tienen el mismo valor legal que las manuscritas y requieren un dispositivo QSCD — en la práctica, el DNIe o un certificado software cualificado emitido por la FNMT-RCM. Los requisitos criptográficos de estos dispositivos los fija ETSI EN 419 241.

Real Decreto-Ley 14/2019 — Soberanía de datos

Exige que los sistemas que procesan datos biométricos y otras categorías especiales en nombre del sector público estén alojados en territorio español o en infraestructura que cumpla estándares de soberanía específicos. Esto prohíbe de facto ciertos modelos de gestión extraterritorial de claves criptográficas para el procesamiento de datos especiales del sector público.

Real Decreto-Ley 12/2018 — Transposición NIS1

Estableció la división de responsabilidades entre CCN-CERT (sector público) e INCIBE-CERT (sector privado) y creó la obligación de notificación de incidentes para operadores de servicios esenciales. Formalmente en vigor, pero en la práctica superado por el anteproyecto NIS2.

Ley 8/2011 + RD 704/2011 — Protección de infraestructuras críticas

Marco legal para los 12 sectores críticos designados (energía, agua, transporte, TIC, sistema financiero, alimentación, salud, nuclear, espacio, investigación, químico, administración pública). Los operadores de infraestructuras críticas (OCI) deben contar con un Plan de Seguridad del Operador (PSO) aprobado por el CNPIC.

Ley 34/2002 (LSSI-CE)

La ley de servicios de la sociedad de la información. La AEPD ha impuesto sanciones bajo esta norma por transmitir parámetros sensibles por canales sin cifrar en servicios web.

2.3 La transposición NIS2 pendiente: lo que viene

Este es el desarrollo normativo más relevante a corto plazo. El Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad fue aprobado por el Consejo de Ministros el 14 de enero de 2025. A mayo de 2026, sigue pendiente de aprobación parlamentaria — la Comisión Europea emitió un dictamen motivado contra España en mayo de 2025 por no haber transpuesto la NIS2 antes del plazo del 17 de octubre de 2024, y el riesgo de procedimiento ante el Tribunal de Justicia de la UE permanece abierto.

Disposiciones clave del borrador relevantes para la criptografía:

• Ámbito: Las organizaciones con 50 o más empleados y más de 10 millones de euros de facturación anual que operen en sectores de alta criticidad se clasifican como entidades esenciales; las medianas empresas de sectores importantes, como entidades importantes.
• Art. 15 (Medidas generales de gestión de riesgos): Referencia explícita al art. 21(2)(h) de NIS2 — la criptografía y el cifrado son medidas obligatorias, no opcionales.
• Art. 14 (Gobernanza): Los órganos de dirección deben aprobar las estrategias de ciberseguridad y son personalmente responsables de las infracciones; los miembros del consejo responden solidariamente por las infracciones cometidas por la entidad.
• Art. 16 (Responsable de seguridad): Las entidades esenciales e importantes deben designar un Responsable de Seguridad de la Información (equivalente al CISO) con autoridad definida por ley.
• Art. 18 (Notificación de incidentes): Alerta temprana en 24 horas, notificación en 72 horas e informe final en un mes a la autoridad competente.
• Sanciones: Entidades esenciales — hasta 10 millones de euros o el 2 % del volumen de negocios global anual (el mayor de los dos); entidades importantes — hasta 7 millones de euros o el 1,4 %. Las sanciones operativas incluyen la suspensión de certificaciones o autorizaciones ligadas al servicio.

3. Algoritmos aprobados: qué está permitido y qué está prohibido

3.1 La lista CCN-STIC 221 desglosada

La CCN-STIC 221 es la referencia definitiva española. Es un superconjunto de los SOG-IS Agreed Cryptographic Mechanisms (ACM) v1.2, que añade algoritmos poscuánticos y ciertos mecanismos clásicos no incluidos en la lista SOG-IS. A continuación, el desglose por tipo de primitiva.

Cifrado simétrico

Funciones hash

Criptografía asimétrica

• RSA: Claves mínimas de 3.072 bits para nuevos despliegues. El CCN indica explícitamente que los prestadores de servicios de confianza que usan RSA-2048 deben migrar cuanto antes. Se recomienda RSA-4096 para seguridad a largo plazo. Relleno: RSASSA-PSS (PKCS#1 v2.1) obligatorio para nuevas firmas; PKCS#1 v1.5 tolerado solo para verificar firmas heredadas.
• ECDSA / ECDH: Aprobado en curvas NIST P-256, P-384, P-521 y curvas Brainpool brainpoolP256r1, brainpoolP384r1, brainpoolP512r1.
• EdDSA (Ed25519, Ed448): Aprobado; especialmente recomendado para contextos de alto rendimiento.

Derivación de claves (KDF)

• HKDF (RFC 5869): Aprobado.
• PBKDF2 con HMAC-SHA-256 y mínimo 600.000 iteraciones: Aprobado para cifrado basado en contraseña.
• scrypt: Incorporado a CCN-STIC 221 en 2023 como KDF aprobado para contraseñas.
• Argon2id: En revisión; no listado formalmente, pero no está prohibido.

Seguridad en la capa de transporte (TLS)

• TLS 1.3: Obligatorio para nuevas implementaciones.
• TLS 1.2 con suites de cifrado aprobadas (ECDHE + AES-GCM + HMAC-SHA-256/384): Tolerado en sistemas heredados.
• TLS 1.0/1.1: Prohibidos.
• Suites TLS 1.3 aprobadas: TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256.

3.2 Criptografía poscuántica (PQC): ya es oficial en España

La actualización de noviembre de 2025 de la CCN-STIC 221 supone un cambio de paradigma: España ha adoptado formalmente los estándares poscuánticos finalizados por el NIST.

Esquemas híbridos — obligatorios durante la transición. El CCN exige la construcción híbrida «CAT-then-KDF» para acuerdo de claves en sistemas críticos: un acuerdo de claves clásico (ECDH) combinado con un KEM poscuántico, cuyos resultados se combinan mediante un KDF aprobado. Así se garantiza que un atacante clásico no pueda debilitar el esquema aunque la primitiva PQC resulte vulnerable en el futuro.

La posición del CCN es inequívoca: los sistemas nacionales críticos y los prestadores de servicios de confianza deben comenzar la planificación de migración híbrida PQC de inmediato, con especial urgencia para datos clasificados de larga vida útil.

4. El ecosistema de certificación CPSTIC

El CPSTIC no es una lista de recomendaciones — para sistemas ENS Alto e información clasificada, el uso de productos que no figuren en él está efectivamente prohibido. Comprender los niveles de certificación es fundamental para el diseño de contratos y la gestión de compras.

Nivel 1 — Productos Aprobados

Productos autorizados para gestionar información clasificada nacional. Requieren evaluación de: requisitos de seguridad funcionales, análisis TEMPEST (emanaciones electromagnéticas) y evaluación criptológica que verifica la conformidad con CCN-STIC 221 mediante MEMeC. El proceso está regulado por CCN-STIC 102/103. Es el nivel más exigente; solo un número reducido de productos — típicamente nacionales o de países aliados — lo alcanzan. La reevaluación es periódica y obligatoria; el proceso es circular, no puntual.

Nivel 2 — Cualificados ENS Alto

Productos válidos para sistemas de categoría ENS Alto. Requieren certificación Common Criteria / EUCC en EAL4+ (o equivalente bajo SOG-IS MRA) más una evaluación STIC complementaria para los requisitos específicos del CCN. La MEMeC (CCN-STIC 2100) es ahora obligatoria para el componente de evaluación del módulo criptográfico. La administración pública debe patrocinar la inclusión del producto; el CCN realiza evaluaciones caso por caso que pueden incluir pruebas de penetración o revisión criptográfica adicional.

Nivel 3 — Cualificados ENS Medio

Productos válidos para sistemas de categoría ENS Medio. Requieren certificación LINCE, que incluye análisis de vulnerabilidades, pruebas de penetración y, opcionalmente, el Módulo de Evaluación Criptográfica (MEC) para productos donde el cifrado es la función principal. LINCE es más rápido y económico que Common Criteria: plazos típicos de 3–6 meses frente a 12–24 meses para CC.

Los grandes proveedores cloud ya están certificados. AWS obtuvo la certificación ENS Alto 311/2022 en 172 servicios; Microsoft Azure y Microsoft 365 también cuentan con certificación ENS Alto (auditados por BDO); AWS ha certificado 25 servicios de seguridad en el CPSTIC. Esto es estratégicamente relevante: las administraciones públicas españolas solo pueden contratar servicios cloud ENS-certificados para sistemas de categoría media y alta.

5. Dónde es obligatorio cifrar: análisis por sectores

5.1 Administración pública (ENS obligatorio)

Todas las administraciones públicas y sus proveedores privados que manejen datos del sector público están sujetos al ENS. Las obligaciones de cifrado por categoría:

ENS Básico — Cifrado recomendado; controles específicos según análisis de riesgos.

ENS Medio — Cifrado del dato en tránsito obligatorio (TLS 1.2+/1.3); cifrado de datos sensibles en reposo requerido; dispositivos móviles y soportes extraíbles deben estar completamente cifrados.

ENS Alto — Cifrado completo de datos en reposo y en tránsito con algoritmos conformes a CCN-STIC 221 y productos del CPSTIC; procedimientos de gestión de claves documentados y auditados; HSMs requeridos para el almacenamiento de claves en muchas configuraciones.

El cumplimiento ENS es un requisito de contratación pública. Sin certificado ENS válido, no es posible participar en licitaciones de categoría media y alta.

5.2 Sector financiero

El sector financiero español opera bajo un régimen de cifrado superpuesto de múltiples normas.

DORA (Reglamento 2022/2554) — en vigor desde enero de 2025. El artículo 9 exige cifrado de datos en reposo y en tránsito; el artículo 6 exige controles criptográficos como parte de la gestión de riesgos TIC; el artículo 10 requiere capacidades de detección que incluyan verificación de integridad. DORA se aplica a bancos, aseguradoras, firmas de inversión, entidades de pago, proveedores de criptoactivos y, de forma crítica, a sus proveedores TIC terceros (nube, centros de datos, proveedores de software).

Banco de España / CNMV. Los sistemas de pago electrónico, la conectividad SWIFT y TARGET2/T2S exigen HSMs certificados con FIPS 140-3 / Common Criteria EAL4+ como mínimo. Los requisitos de autenticación reforzada de clientes (SCA) bajo PSD2 exigen firmas ECDSA o RSA para el dynamic linking.

PCI-DSS v4.0. Obligatorio para procesadores de pagos con tarjeta; exige TLS 1.2+ como mínimo (TLS 1.3 ampliamente recomendado), AES-256 para datos de titulares de tarjetas en reposo, y procedimientos específicos de gestión de claves.

5.3 Sanidad

• HCDSNS (Historia Clínica Digital del SNS): Clasificado ENS Alto en dimensión de confidencialidad; requiere cifrado extremo a extremo con productos del CPSTIC.
• Receta electrónica: Las implementaciones regionales deben cumplir ENS Medio o Alto según la clasificación; se exige integridad y autenticidad criptográfica de los datos de prescripción.
• Datos de salud bajo el RGPD: Los datos de salud son categoría especial según el art. 9 del RGPD; la AEPD trata sistemáticamente la ausencia de cifrado para datos sanitarios como infracción grave.
• RD-Ley 14/2019 (soberanía de datos): El procesamiento de datos especiales de salud del sector público debe realizarse en territorio español o en infraestructura que cumpla los estándares de soberanía del CCN; esto tiene implicaciones directas sobre la jurisdicción de la gestión de claves.

5.4 Telecomunicaciones

• Los operadores bajo la Ley 11/2022 General de Telecomunicaciones deben implementar medidas de seguridad para la integridad de redes y servicios, incluido el cifrado de interfaces de gestión y datos operativos sensibles.
• 5G: GSMA FS.33 y ETSI TS 133 501 rigen los requisitos criptográficos del 5G: protección SUPI/SUCI mediante ECIES, autenticación 5G-AKA (AES-128/256 + ECDH P-256). Los operadores españoles deben cumplir adicionalmente el EU 5G Security Toolbox, que incluye restricciones sobre proveedores de alto riesgo.
• Interceptación legal (LI): Los operadores deben implementar interfaces ETSI normalizadas (ETSI ES 201 158, TS 101 671) que exigen integridad y confidencialidad criptográfica en la entrega del producto interceptado a las fuerzas del orden.
• SIM/eSIM: GSMA SGP.02 y SGP.22 requieren AES-128 para la gestión de perfiles OTA y ECDH P-256 para el acuerdo de claves.

5.5 Infraestructuras críticas (energía, agua, transporte, nuclear)

Los operadores de infraestructuras críticas deben implementar medidas de ciberseguridad conforme a la Ley 8/2011 y la guía del CNPIC. En el sector energético se aplican adicionalmente requisitos análogos al NERC CIP para sistemas de control industrial (SCADA/ICS), donde el cifrado de comunicaciones de tecnología operacional (OT) es una exigencia creciente.

5.6 Administración electrónica: identidad digital y firma

España dispone de una infraestructura criptográfica de identidad digital entre las más avanzadas de Europa.

• DNIe: La tarjeta de identidad electrónica española, emitida por la Dirección General de la Policía, contiene claves RSA-2048 para autenticación y creación de firmas cualificadas; las versiones DNIe 3.x recientes soportan ECC. Funciona como dispositivo QSCD bajo eIDAS.
• Certificados FNMT-RCM: La Casa de la Moneda emite certificados electrónicos cualificados para ciudadanos, organizaciones y empleados públicos. Los algoritmos de certificado están migrando de RSA-2048 a RSA-4096/ECC.
• Plataforma Cl@ve: El sistema unificado de identidad ciudadana. Incluye Cl@ve PIN (OTP), Cl@ve Permanente (usuario/contraseña + OTP) y Cl@ve Firma (servicio de firma cualificada remota en la nube mediante claves protegidas en HSM). Todos los canales interoperan con el nodo eIDAS español para el reconocimiento transfronterizo. El servicio de firma en la nube cumple ETSI EN 419 241-2.
• Plataforma @firma: El servicio de validación de firma electrónica empleado por la mayoría de administraciones públicas. Soporta PAdES (ETSI TS 102 778), XAdES (ETSI TS 101 903) y contenedores ASiC (ETSI TS 102 918).

6. Estándares aplicables: tabla de referencia

7. Sanciones y exposición financiera real

7.1 Aplicación del RGPD/LOPDGDD por la AEPD

La AEPD es uno de los cinco organismos de protección de datos más activos de Europa. La tendencia es claramente alcista: 21.590 reclamaciones en 2023 (+47 % interanual); 367 multas por un total de 29,8 millones de euros en 2023; un récord de 35,5 millones de euros en 2024 (+19,4 %). En 2025, se registraron 2.765 notificaciones de brechas de datos, que afectaron a más de 200 millones de personas — el doble de 2024 — impulsadas por ransomware y exfiltración de datos.

Marco máximo de sanciones bajo el RGPD/LOPDGDD:

• Nivel 1 (infracciones más graves — art. 83(5)): Hasta 20 millones de euros o el 4 % del volumen de negocios global anual, el mayor de los dos. Aplica a violaciones de principios básicos (art. 5), condiciones del consentimiento (art. 7), derechos del interesado (arts. 12–22) o transferencias internacionales (arts. 44–49).
• Nivel 2: Hasta 10 millones de euros o el 2 % del volumen de negocios global anual. Aplica a incumplimientos de seguridad (art. 32), fallos en evaluaciones de impacto (art. 35), etc.

Casos paradigmáticos con dimensión criptográfica o de seguridad:

Principio jurisprudencial crítico. La AEPD ha consolidado — y los tribunales españoles lo han confirmado — que ser víctima de un ciberataque no exime del cumplimiento de las obligaciones de seguridad del RGPD. El análisis relevante es si la organización implementó medidas preventivas proporcionales al riesgo antes del incidente. La remediación posterior al ataque se valora, pero es insuficiente por sí sola.

7.2 Sanciones NIS2 (transposición pendiente)

Bajo el anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad:

• Entidades esenciales: Hasta 10 millones de euros o el 2 % del volumen de negocios global anual.
• Entidades importantes: Hasta 7 millones de euros o el 1,4 % del volumen de negocios global anual.
• Infracciones muy graves: Entre 500.001 y 2.000.000 euros para infracciones específicas (texto legislativo final pendiente).
• Sanciones operativas: Suspensión de certificaciones o autorizaciones vinculadas al servicio — para muchas empresas tecnológicas, equivale al cierre de la actividad de contratación pública.
• Responsabilidad personal: Los miembros del consejo de administración responden solidariamente por las infracciones; los directivos individuales pueden recibir sanciones personales y medidas disciplinarias.

El borrador introduce además una obligación de autorregistro: las entidades que cumplan los umbrales de alcance deben registrarse proactivamente ante la autoridad competente dentro de los tres meses siguientes a la entrada en vigor de la ley.

7.3 Sanciones DORA

DORA faculta al Banco de España y la CNMV para imponer:

• Pagos periódicos coercitivos de hasta el 1 % del volumen de negocios diario global por incumplimiento continuado.
• Multas estructurales por fallos sistémicos.
• Suspensión de servicios para proveedores TIC terceros críticos.

7.4 Infracciones en servicios de confianza (Ley 6/2020)

Multas administrativas de hasta 150.000 euros para prestadores cualificados de servicios de confianza; la responsabilidad civil por daños derivados de protecciones criptográficas inadecuadas en firmas o certificados electrónicos es ilimitada.

7.5 Incumplimiento ENS

No existe un marco de sanciones económicas directas por incumplimiento ENS en sí mismo, pero las consecuencias comerciales son graves:

• Exclusión de la contratación pública: Los proveedores no conformes no pueden competir en contratos que requieran certificación ENS Medio/Alto.
• Resolución de contratos: Los contratos públicos vigentes pueden rescindirse si la certificación ENS caduca.
• Daño reputacional: El incumplimiento es visible públicamente a través del registro de conformidad ENS.

8. Práctica sectorial: banca, sanidad, administración y telecomunicaciones

8.1 Banca y servicios financieros

Las entidades financieras españolas son las primeras en adoptar controles criptográficos, impulsadas por mandatos superpuestos (DORA, PCI-DSS, Banco de España, SSM del BCE).

• HSMs (Thales, Utimaco, AWS CloudHSM) certificados con FIPS 140-3 Nivel 3 / CC EAL4+ para gestión de claves. Al menos FIPS 140-3 Nivel 2 para servicios HSM en la nube.
• TLS 1.3 estándar para todos los servicios de cara al cliente; vida de los certificados limitada a 398 días; gestión automatizada de certificados (protocolo ACME).
• PSD2/SCA: ECDSA P-256 o RSA-2048 como mínimo para el dynamic linking; migración a RSA-4096/P-384 en nuevas implementaciones.
• Preparación poscuántica: El BCE y el Banco de España han emitido orientación alentando los programas de inventario de activos criptográficos (Crypto-Agility). Los principales bancos españoles (Santander, BBVA, CaixaBank) tienen grupos de trabajo PQC activos, con pilotos iniciales de TLS 1.3 híbrido + ML-KEM.

8.2 Sanidad y Seguridad Social

• MUFACE, ISFAS, MUGEJU (mutualidades de funcionarios): Historiales sanitarios clasificados ENS Alto; obligatorios productos del CPSTIC.
• Nodo de interoperabilidad del HCDSNS: TLS 1.3 extremo a extremo con autenticación mutua de cliente mediante certificados cualificados; integridad de la historia clínica protegida por firmas digitales.
• Seudonimización para investigación: Los datos clínicos de investigación deben seudonimizarse (no solo anonimizarse) conforme al art. 9 de la LOPDGDD; claves de seudonimización en HSMs del CPSTIC cifradas con AES-256.
• Datos biométricos en sanidad: La AEPD exige EIPDs y protección criptográfica de las plantillas biométricas para el reconocimiento facial de pacientes.

8.3 Administración electrónica

• Cl@ve Firma procesa millones de firmas cualificadas anuales; claves en HSMs aprobados por el CCN operados por la FNMT-RCM bajo ETSI EN 419 241-2.
• Notific@: El sistema nacional de notificaciones electrónicas usa marcas de tiempo cualificadas CAdES/XAdES (ETSI) como prueba legal de entrega.
• Contratación pública (PLACE/ROLECE): Requiere firmas electrónicas cualificadas para la presentación de ofertas; los funcionarios deben usar el DNIe o certificados cualificados de la FNMT-RCM.
• Agencia Tributaria: Las declaraciones fiscales en línea se tramitan a través de Cl@ve; los sistemas de respaldo procesan datos tributarios clasificados bajo ENS Alto con cifrado completo en reposo y en tránsito.

8.4 Telecomunicaciones

Telefónica (Movistar), Vodafone España y Orange/MásMóvil/Masorange:

• 5G: Elementos de red cifrados conforme a GSMA FS.33 / ETSI TS 133 501; protección SUPI/SUCI mediante ECIES, autenticación 5G-AKA (AES-128/256 + ECDH P-256).
• Core IP: IPsec ESP (AES-GCM-128/256) para backhaul e interfaces entre operadores; MACsec (IEEE 802.1AE con AES-128/GCM) para transporte óptico en la capa 2.
• Interceptación legal: Los operadores están sujetos a los requisitos de la Ley 11/2022; las interfaces ETSI LI deben garantizar la confidencialidad e integridad criptográfica del producto interceptado entregado a las fuerzas del orden bajo autorización judicial.

9. España frente al mundo: diferencias con EE. UU. y Reino Unido

España/UE frente a Estados Unidos

España/UE frente al Reino Unido (post-Brexit)

La salida del Reino Unido de la UE ha creado divergencia real:

• Firmas electrónicas: El eIDAS del Reino Unido fue incorporado al derecho nacional tal como estaba el 31 de diciembre de 2020. El Reino Unido mantiene su propia lista de confianza y no reconoce mutuamente de forma automática los certificados o firmas cualificados de la UE.
• Certificación de productos: El NCSC del Reino Unido opera CAPS y Foundation Grade; estos esquemas no son reconocidos mutuamente con CPSTIC ni con SOG-IS MRA.
• Transferencias de datos: El Reino Unido es actualmente considerado adecuado bajo la decisión de adecuación de la UE (vigente hasta junio de 2027 salvo renovación); las entidades que operen en ambos mercados deben monitorizar activamente una posible divergencia.

El diferenciador único del modelo español: el CPSTIC

La característica más distintiva del régimen español frente a la mayoría de los países de la OCDE es el requisito prescriptivo de certificación de producto para las compras del sector público — el CPSTIC. La mayoría de los países, incluso en la UE, no disponen de un catálogo obligatorio equivalente; se apoyan en el reconocimiento de Common Criteria y la contratación de mercado. Este requisito español genera:

• Una barrera de entrada estructural para proveedores extranjeros que no hayan superado la evaluación del CCN.
• Un incentivo estratégico para que los grandes proveedores cloud (AWS, Microsoft, Google, Oracle) obtengan la certificación española — y lo han hecho.
• Una ventaja de mercado para las empresas de productos de seguridad de ámbito español y europeo.

10. Hoja de ruta para la dirección: acciones inmediatas y a medio plazo

Acciones inmediatas (0–6 meses)

1. Realizar un inventario de activos criptográficos (evaluación de Crypto-Agility).
Mapee cada implementación de cifrado de su patrimonio tecnológico: algoritmos, longitudes de clave, bibliotecas, vidas útiles de certificados, certificaciones de HSM. Es el requisito previo para el cumplimiento ENS, la gestión de riesgos TIC bajo DORA y el futuro registro NIS2.

2. Clasificar su exposición ENS.
Si presta servicios TIC a algún organismo público español, determine la categoría ENS requerida (Básica, Media, Alta) e inicie el proceso de certificación. Los plazos habituales son 2–3 meses para Básica, 3–6 meses para Media y 6–18+ meses para Alta. Las brechas de certificación suponen un riesgo comercial inmediato.

3. Revisar la exposición ante la AEPD.
Audite los controles de cifrado para el tratamiento de datos personales. La trayectoria sancionadora de la AEPD (récord de 35,5 millones de euros en multas en 2024; 200 millones de afectados notificados en 2025) convierte esto en el riesgo de cumplimiento de mayor probabilidad. Verifique que todos los datos personales están cifrados en reposo y en tránsito con algoritmos conformes a CCN-STIC 221, y que no existan soportes extraíbles sin cifrar con datos personales en su organización.

4. Análisis de brechas DORA (sector financiero).
Si está en el ámbito de aplicación, la norma lleva en vigor desde enero de 2025. Mapee los controles de gestión de riesgos TIC respecto a los requisitos de cifrado del artículo 9 de DORA; revise los contratos con terceros TIC para incluir obligaciones de cifrado; y verifique que las certificaciones de los HSMs estén vigentes.

Acciones a medio plazo (6–18 meses)

5. Prepararse para la transposición NIS2.
Incluso sin promulgación formal, alinee su postura de seguridad con el borrador de ley. Identifique si es una entidad esencial o importante. Designe un Responsable de Seguridad de la Información. Documente los controles criptográficos para su aprobación formal por el órgano de dirección. Establezca una capacidad de notificación de incidentes en 24/72 horas.

6. Planificación de migración poscuántica.
Encargue una evaluación de riesgos PQC. Identifique datos y claves con requisitos de seguridad superiores a 10 años (documentos clasificados, contratos a largo plazo, historiales de pacientes). Priorice la migración a esquemas híbridos para esos activos. Consulte a sus proveedores de HSM y PKI sobre sus hojas de ruta PQC — la mayoría de los proveedores de primer nivel ya tienen soporte ML-KEM en beta o producción.

7. Diligencia debida criptográfica en la cadena de suministro.
Bajo NIS2 y DORA, la seguridad de la cadena de suministro es una obligación legal, no una buena práctica. Mapee las prácticas de cifrado de sus proveedores clave e imponga contractualmente la alineación con CCN-STIC 221 o estándares aprobados equivalentes.

Compromisos de gobernanza para el consejo de administración

8. La responsabilidad personal de los directivos es real.
Bajo la transposición NIS2 pendiente, los miembros del consejo responden solidariamente por las infracciones de ciberseguridad. Esto significa que los controles criptográficos inadecuados son un riesgo fiduciario del consejero, no solo un problema operativo. El consejo debe aprobar formalmente la política criptográfica de la organización, recibir informes periódicos sobre el estado de cumplimiento y asegurarse de que el seguro de D&O cubra adecuadamente la responsabilidad regulatoria cibernética.

9. Ciclos de auditoría y certificación.
ENS Medio/Alto exige auditorías externas cada dos años. Planifique los presupuestos de certificación y asigne recursos internos — un programa típico de certificación ENS Alto para un proveedor tecnológico mediano cuesta entre 150.000 y 400.000 euros, incluidos honorarios de consultoría, adaptación del producto y costes de auditoría.

10. Relacionarse proactivamente con el CCN e INCIBE.
Ambos organismos ofrecen orientación, asistencia técnica y servicios de preevaluación. Para las organizaciones que buscan la certificación de productos en el CPSTIC, el contacto temprano con el departamento CCN-PYTEC reduce significativamente los plazos de certificación. INCIBE ofrece herramientas gratuitas de ciberseguridad y guías sectoriales a través de su portal.

Conclusión

El panorama de cumplimiento criptográfico en España atraviesa su fase más exigente simultáneamente en tres frentes: la tendencia sancionadora récord de la AEPD bajo el RGPD/LOPDGDD, la inminente aprobación de la NIS2 con su responsabilidad personal para los directivos y la transición poscuántica global para la que el CCN ya ha publicado orientación formal.

Para las organizaciones con operaciones en España, la pregunta no es si hay que invertir en cumplimiento criptográfico, sino con qué rapidez. Las que saldrán mejor paradas son aquellas que traten la CCN-STIC 221 no como un formulario burocrático sino como el suelo técnico real que representa, integren la agilidad criptográfica en sus arquitecturas ahora para reducir los costes de migración futuros, y eleven la gobernanza del cifrado a la agenda del consejo antes de que los eventos regulatorios fuercen la cuestión.

El coste del incumplimiento — medido en multas de la AEPD, sanciones NIS2, exclusión de la contratación pública y responsabilidad personal de los directivos — supera con creces el coste del cumplimiento proactivo.

Abril de 2026 quedará grabado en la memoria de los equipos de seguridad españoles. En apenas treinta días, más de seis millones de registros de clientes quedaron expuestos, la Comisión Europea amenazó a España con una sanción por incumplimiento normativo y el Gobierno aprobó dos proyectos de ley que cambiarán las reglas del juego para miles de empresas. Todo al mismo tiempo.

Este artículo resume lo que ocurrió, por qué importa y qué pueden hacer hoy las organizaciones para no protagonizar el próximo titular.

Un mes de brechas en cadena

El sector energético, en el punto de mira

El mismo actor que en enero filtró datos de millones de clientes de Endesa volvió a golpear en abril, esta vez contra Naturgy. El hacker conocido como «Spain» exfiltró aproximadamente 74,2 GB de información sensible: nombres, números de DNI/NIF, cuentas bancarias (IBAN), datos de suministro (CUPS) y direcciones físicas de más de 1,8 millones de clientes.

Al mismo tiempo, Iberdrola reconoció una brecha a través de su partner comercial Zirconite, que comprometió los datos de unos 150.000 clientes actuales y antiguos. El patrón es idéntico en ambos casos: el vector de entrada no fue la empresa matriz, sino un tercero de su cadena de suministro.

Retail y fitness: sectores inesperados, consecuencias reales

El 15 de abril, Inditex comunicó un acceso no autorizado a bases de datos alojadas en un proveedor externo. La compañía aseguró que no se vieron afectados datos financieros ni personales sensibles, pero el incidente pone sobre la mesa los riesgos inherentes a delegar el almacenamiento de datos en terceros.

Un día después, la cadena de gimnasios Basic Fit —con más de 150 centros en España— confirmó la exposición de datos bancarios, nombres y fechas de nacimiento de más de 4,5 millones de usuarios en toda Europa. Una sola brecha, consecuencias continentales.

Mapfre y el ultimátum de Lapsus$

La aseguradora Mapfre recibió un ultimátum del conocido grupo Lapsus$: 15 días para evitar la publicación de datos supuestamente robados. Un recordatorio de que el ransomware y la extorsión basada en datos siguen siendo las tácticas preferidas de los grupos más organizados.

El marco regulatorio cambia de velocidad

Dos proyectos de ley en un mismo mes

El Gobierno aprobó en abril el Proyecto de Ley de Protección y Resiliencia de Entidades Críticas, que transpone la Directiva CER (2022/2557) al ordenamiento jurídico español, con el Secretariado de Estado de Seguridad (SES) como autoridad competente.

En paralelo avanza el Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad, vehículo de transposición de la Directiva NIS2. Los expertos que participaron en el foro CIO ForwardTech & ThreatScape Spain subrayaron dos implicaciones directas para las empresas: mayor responsabilidad de los consejos de administración y requisitos de auditoría más estrictos sobre la cadena de suministro.

La UE aprieta las tuercas

La Comisión Europea solicitó la imposición de una multa a España por no haber transpuesto la Directiva CER antes de octubre de 2024, fecha límite incumplida. La presión de Bruselas es ahora un factor regulatorio tan real como cualquier inspección de la AEPD.

Hablando de la AEPD: el organismo estrenó una herramienta interactiva para consultar notificaciones de brechas de datos y sancionó en abril a un centro educativo con 5.000 euros por una filtración derivada del robo de un equipo informático.

Las cifras que contextualizan el problema

El INCIBE publicó su informe anual con datos de 2025: 122.223 incidentes de ciberseguridad gestionados, un 26% más que en 2024. El sector bancario concentró el 34% de los incidentes en empresas; el malware y el fraude online fueron los vectores dominantes.

En Cataluña, la Agencia de Ciberseguridad bloqueó el 80% de los 9.100 millones de ciberataques registrados contra el sector público en 2025, aunque los incidentes con éxito se duplicaron hasta 6.544, con sanidad y universidades como principales víctimas.

Soberanía digital y criptografía postcuántica

Abril también trajo movimientos estratégicos en el mercado. La empresa española S2 Grupo y el proveedor de nube europeo OVHcloud anunciaron una alianza para ofrecer soluciones cloud y de ciberseguridad 100% europeas a sectores críticos, en respuesta directa a los requisitos de NIS2 y al RGPD.

La red de SOC de Vodafone España fue incorporada al registro europeo TF-CSIRT, un reconocimiento de madurez operativa relevante para sus clientes empresariales.

En el horizonte más lejano, España avanza en criptografía postcuántica (PQC) a través del proyecto ARQADE, liderado por la Fundación CTIC. Cataluña ha comprometido 18 millones de euros para preparar su infraestructura ante las amenazas que traerá la computación cuántica. El Centro Nacional de Inteligencia (CNI), por su parte, ha recomendado limitar el uso de equipos de Huawei en sectores críticos de telecomunicaciones.

Qué lecciones extraer para su organización

Los incidentes de abril tienen un denominador común que debería preocupar a cualquier CISO o responsable de IT:

1. La cadena de suministro es el eslabón débil. Naturgy, Iberdrola e Inditex no fueron comprometidas directamente, sino a través de partners y proveedores externos. NIS2 ya exige auditar estos terceros; los incidentes de abril demuestran que no es burocracia, es necesidad.
2. Los datos de acceso son el objetivo real. DNIs, IBANs, credenciales de usuario: lo que los atacantes buscan son los datos que permiten suplantar identidades o acceder a otros sistemas. Gestionar, rotar y centralizar el acceso a credenciales corporativas —especialmente en entornos con múltiples proveedores— es más urgente que nunca.
3. El marco normativo ya no es una opción. Con NIS2, CER y la presión de la Comisión Europea, las empresas que operen en sectores esenciales o importantes en España afrontan auditorías reales y sanciones reales. Documentar los controles y demostrar cumplimiento ya no puede postergarse.
4. El sector público también es objetivo. Municipios, universidades, hospitales: los actores con menores presupuestos de seguridad son blanco recurrente. La inversión pública a través del programa RETECH (162 millones de euros vía NextGenerationEU) es una respuesta sistémica, pero cada entidad necesita también su propia línea de defensa.

Conclusión

Abril de 2026 ha sido un mes de avisos. Avisos en forma de brecha de datos, de multas europeas y de legislación que ya no puede ignorarse. Las organizaciones que salgan mejor paradas serán las que ya hayan ordenado su casa: accesos controlados, proveedores auditados, credenciales gestionadas de forma centralizada y equipos con capacidad de respuesta ante incidentes.

La pregunta no es si su empresa será objetivo. La pregunta es si estará preparada cuando lo sea.

¿Quiere saber cómo Passwork ayuda a las organizaciones a centralizar y proteger el acceso a credenciales corporativas en entornos multi-proveedor? Solicite una demo gratuita

Ataque a la cadena de suministro: Bitwarden CLI y Checkmarx

Cómo los atacantes convierten paquetes de confianza, GitHub Actions y pipelines CI/CD en puntos de entrada silenciosos. Por qué la arquitectura, las dependencias fijadas y la gobernanza de secretos son los únicos controles que realmente contienen el radio de impacto.

Passwork BlogAlex Muntyan

Últimas noticias NIS2: Cambios y su impacto en empresas de la UE

Bélgica estableció el primer plazo de evaluación de conformidad para el 18 de abril de 2026. Los Países Bajos están a días de iniciar la aplicación. Aquí se explica dónde se encuentra la oleada regulatoria en este momento y qué deben abordar ahora los responsables de TI.

Passwork BlogAlex Muntyan

Ataques de fuerza bruta en 2026: tipos, ejemplos y prevención

Clústeres de GPU, diccionarios asistidos 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

Am 22. April 2026 wurde ein Credential Stealer in einem Paket mit 250.000 monatlichen Downloads ausgeliefert. Er wurde bei der Installation unbemerkt ausgeführt, erforderte keine Benutzerinteraktion und wurde automatisch von CI-Runnern in Dutzenden von Pipelines heruntergeladen. Als das Paket aus der Registry entfernt wurde, waren bereits echte Systeme kompromittiert worden.

Nur ein routinemäßiges Dependency-Update.

Moderne Infrastruktur ist nur so sicher wie ihre schwächste Abhängigkeit. Wenn Angreifer Ihren Perimeter nicht direkt durchbrechen können, kompromittieren sie etwas, dem Sie bereits vertrauen, und gelangen so direkt in Ihre Umgebung.

Ein Supply-Chain-Angriff ist die Kompromittierung eines vertrauenswürdigen Drittanbieters, einer Softwarekomponente oder eines Dienstes, um nachgelagerte Ziele zu infiltrieren. Der Angreifer benötigt nicht Ihre Zugangsdaten. Er braucht Zugang zu etwas, das Ihre Build-Pipeline automatisch um 3 Uhr morgens abruft. Er braucht einen Preinstall-Hook, der ausgeführt wird, bevor Sie ihn überprüfen können.

Der Bitwarden CLI-Vorfall ist der jüngste Beweis dafür, dass diese Bedrohung operativ, koordiniert und beschleunigt ist. In diesem Artikel analysieren wir, wie der Angriff funktionierte, was er uns über moderne Infrastruktur lehrt und welche Kontrollen Supply-Chain-Kompromittierungen tatsächlich davon abhalten, in Ihre Umgebung zu gelangen.

Wichtigste Erkenntnisse

• Supply-Chain-Angriffe umgehen Ihren Perimeter, indem sie das ausnutzen, dem Sie bereits vertrauen — Pakete, CI-Workflows und Plugins werden in Ihrer Umgebung mit vollen Privilegien ausgeführt, ohne einen einzigen Phishing-Link.
• Die Bitwarden CLI-Kompromittierung im April 2026 war eine koordinierte, mehrstufige Operation — Angreifer kaperten eine GitHub Action eines Drittanbieters, stahlen ein npm-Token und veröffentlichten @bitwarden/cli@2026.4.0 mit einem Credential Stealer, der bei der Installation unbemerkt ausgeführt wurde.
• Transitive Dependencies sind Ihre größte ungeprüfte Angriffsfläche — Ihre Anwendung importiert möglicherweise zehn Pakete direkt, aber jedes davon lädt Dutzende weitere, von denen keines die gleiche Prüfung wie First-Party-Code erhält.
• Architektur ist eine stärkere Kontrolle als Prozesse — Ein System, das so konzipiert ist, dass die Kompromittierung einer Komponente nichts Brauchbares liefert, ist grundlegend widerstandsfähiger als eines, das darauf angewiesen ist, dass alle Kontrollen gleichzeitig halten.
• Secrets in CI/CD-Pipelines sind das primäre Ziel — GitHub-Tokens, SSH-Schlüssel und Cloud-Zugangsdaten, die in einem einzigen Build-Job abgegriffen werden, können eine Kompromittierung auf jedes Repository und jede Pipeline ausweiten, die dieses Token erreichen kann.
• Verteidigung erfordert kontinuierliche Kontrollen, keine periodischen — Gepinnte Dependencies, signierte Builds, SBOM-Tracking, zeitlich begrenzte Tokens mit begrenztem Umfang und Secrets-Rotation müssen bei jedem Commit ausgeführt werden, nicht jedes Quartal.

Was ist ein Supply-Chain-Angriff

Ein Supply-Chain-Angriff tritt auf, wenn ein Angreifer einen vertrauenswürdigen Drittanbieter, ein Open-Source-Paket oder eine Softwarekomponente kompromittiert, um eine bösartige Nutzlast an nachgelagerte Organisationen zu liefern. Der Angreifer nutzt die Vertrauensbeziehung zwischen einem Lieferanten und seinen Nutzern aus, was die Erkennung deutlich schwieriger macht als bei einem direkten Eindringen.

Die Angriffsfläche ist groß, weil moderne Software auf Schichten von Abhängigkeiten aufgebaut ist. Ihre Anwendung importiert möglicherweise direkt zehn Pakete, aber jedes davon importiert Dutzende weitere. Diese transitiven Dependencies (Komponenten, auf die Ihr Code indirekt angewiesen ist) werden selten mit der gleichen Sorgfalt geprüft wie First-Party-Code.

Supply-Chain-Angriffe fallen in mehrere Kategorien:

• Software-Supply-Chain-Angriffe — Bösartiger Code, der in Open-Source-Bibliotheken, Paket-Registries (npm, PyPI) oder Vendor-Software-Updates eingeschleust wird.
• CI/CD-Pipeline-Angriffe — Kompromittierung von Build-Systemen, GitHub-Actions-Workflows oder Container-Registries, um den Build-Prozess abzufangen.
• Drittanbieter-Service-Angriffe — Ausnutzung von SaaS-Tools, Plugins oder Managed Services, die privilegierten Zugriff auf Kundenumgebungen haben.
• Hardware-Supply-Chain-Angriffe — Physische Manipulation von Firmware oder Komponenten, bevor sie den Endbenutzer erreichen (seltener im Software-Kontext, aber bei staatlichen Operationen dokumentiert).

Der gemeinsame Nenner: Das Opfer installiert, führt aus oder vertraut etwas, das bereits als Waffe eingesetzt wurde.

Die Anatomie eines modernen Supply-Chain-Angriffs

Ein Supply-Chain-Angriff folgt einem vorhersehbaren Lebenszyklus. Die Kenntnis der Phasen macht ihn vermeidbar.

1. Aufklärung. Angreifer scannen öffentliche Repositories, Paket-Registries und CI/CD-Konfigurationen nach Schwachstellen: ungeschützte GitHub-Tokens, Pakete mit hohen Download-Zahlen und minimaler Maintainer-Beteiligung oder Actions-Workflows mit übermäßigen Berechtigungen.
2. Upstream-Kompromittierung. Der Angreifer erhält Schreibzugriff auf ein vertrauenswürdiges Artefakt, indem er Maintainer-Zugangsdaten stiehlt, einen bösartigen Pull Request einreicht oder Code direkt in eine Build-Pipeline einschleust. Die bösartige Nutzlast wird dort eingebettet, wo sie automatisch ausgeführt wird: ein Preinstall-Hook, ein Workflow-Schritt, ein Plugin-Update.
3. Ruhephase. Das kompromittierte Artefakt wird veröffentlicht und wartet. Automatisierte Systeme (CI-Runner, Dependency-Manager, Entwickler-Workstations) laden das Update ohne menschliche Überprüfung herunter. Der bösartige Code bleibt inaktiv, bis er ausgelöst wird.
4. Downstream-Auslieferung. Entwickler und Pipelines installieren die infizierte Version über normale, vertrauenswürdige Kanäle. Es gibt keinen Phishing-Link zum Anklicken, keinen verdächtigen Anhang zum Öffnen. Der Credential Stealer wird als Teil des Standard-Build-Prozesses ausgeführt.
5. Privilegien-Eskalation. Mit dem etablierten Erstzugang sammelt der Angreifer Secrets: API-Tokens, SSH-Schlüssel, Umgebungsvariablen, Cloud-Zugangsdaten. GitHub-Tokens sind besonders wertvoll — sie können genutzt werden, um bösartige Workflows in jedes Repository einzuschleusen, das das Token erreichen kann, und die Kompromittierung weiter downstream zu verbreiten.

Ungeschützte Secrets in CI/CD-Pipelines sind genau das, was Angreifer in Phase fünf abgreifen. Testen Sie Passwork kostenlos und sehen Sie, wie strukturiertes Secrets-Management Ihre Angriffsfläche reduziert → passwork.pro

Fallstudie: Die Bitwarden CLI- und Checkmarx-Kampagne 2026

Der Bitwarden CLI-Supply-Chain-Angriff, bestätigt von JFrog und Socket am 23. April 2026, ist eine der technisch präzisesten Credential-Harvesting-Operationen, die bisher dokumentiert wurden. Er zielte direkt auf Entwickler ab: ihre Tokens, ihre KI-Tools, ihre Pipelines. Und er enthielt eine wichtige architektonische Lektion für die gesamte Branche.

Der Angriff entfaltete sich in Phasen, wobei jede eine andere Vertrauensebene in der Software-Supply-Chain ausnutzte.

Was passierte

Am 22. April 2026 wurde eine bösartige Version des Bitwarden CLI (@bitwarden/cli@2026.4.0) in der npm-Registry veröffentlicht. Das Paket hat über 250.000 monatliche Downloads, was es zu einem hochwertigen Ziel macht. Der bösartige Code war in bw1.js eingebettet und wurde über einen Preinstall-Hook in package.json ausgelöst, der zuerst bw_setup.js ausführte, um die Bun-Runtime zu installieren, und dann bw1.js — die eigentliche bösartige Nutzlast (OX Security, 2026). Keine Benutzerinteraktion erforderlich.

Die Angreifer drangen nicht direkt in Bitwarden ein. Sie kompromittierten eine GitHub Action eines Drittanbieters, die in Bitwardens CI/CD-Pipeline verwendet wurde, erlangten Zugriff auf Workflow-Secrets einschließlich eines npm-Tokens und verwendeten es, um das bösartige Paket zu veröffentlichen. Der Angriff nutzte die CI/CD-Pipeline als Einstiegspunkt — konsistent mit dem breiteren Muster, das in der Checkmarx-Supply-Chain-Kampagne identifiziert wurde. Die Zeichenkette "Shai-Hulud: The Third Coming", die im Paket eingebettet war, bestätigte, dass dies die dritte Iteration einer laufenden, organisierten Kampagne war — kein opportunistischer Einzelfall.

Entscheidend ist, dass keine Benutzer-Tresore betroffen waren. Bitwardens Zero-Knowledge-Architektur bedeutete, dass der Server niemals Masterpasswörter oder Zugriff auf entschlüsselte Benutzerdaten hatte. Selbst bei kompromittiertem CI/CD konnte der Angreifer nicht an das gelangen, was die Architektur schützen sollte.

Was die Malware tat

Die bösartige Nutzlast (die dritte Phase des „Shai-Hulud"-Wurms) führte folgende Sequenz aus:

1. Russische Sprachprüfung. Bevor irgendetwas anderes getan wurde, prüfte die Malware, ob auf dem Host-Rechner die russische Sprache konfiguriert war. Falls ja, wurde sie sofort beendet. Dies ist eine Standard-Selbstschutztechnik: Die Autoren vermeiden es, ihre eigenen Entwicklungsrechner zu infizieren, und dies deutet stark auf einen russischsprachigen Bedrohungsakteur hin.
2. Credential Harvesting. Sie zielte auf GitHub- und npm-Tokens, .ssh-Verzeichnisse, .env-Dateien, Shell-History, GitHub-Actions-Umgebungsvariablen, AWS-, GCP- und Azure-Zugangsdaten sowie GitHub-Runner-Informationen ab.
3. KI-Tool-Targeting. Konfigurationsdateien für KI-Coding-Assistenten (Claude, Kiro, Cursor, Codex CLI und Aider) wurden explizit ins Visier genommen, was widerspiegelt, wie tief diese Tools mittlerweile in Entwickler-Workflows eingebettet sind und wie viel sensiblen Kontext sie lokal speichern.
4. Verschlüsselte Exfiltration über GitHub. Alle gestohlenen Daten wurden mit AES-256-GCM unter Verwendung asymmetrischer Verschlüsselung verschlüsselt — was bedeutet, dass nur der private Schlüssel des Bedrohungsakteurs sie entschlüsseln kann. Die Daten wurden in ein neu erstelltes öffentliches GitHub-Repository auf dem eigenen Account des Opfers hochgeladen, mit Dateien namens results-TIMESTAMP-ID.json. Ein sekundärer Kanal exfiltrierte Daten an audit.checkmarx[.]cx, eine Domain, die die legitime Checkmarx-Plattform imitierte. Die Verwendung von GitHub als C2-Server ist beabsichtigt: Datenverkehr zu github.com wird selten von Sicherheitstools markiert und kann nicht zu einer vom Bedrohungsakteur kontrollierten Domain zurückverfolgt werden.
5. Selbstverbreitung. Das macht Shai-Hulud zu einem Wurm, nicht nur zu einem Stealer. Wenn gültige npm-Tokens gefunden wurden, lud die Malware eines der eigenen npm-Pakete des Opfers herunter, schleuste bösartigen Code ein und veröffentlichte automatisch eine neue Version — wodurch die Infektion auf die Downstream-Benutzer des Opfers übertragen wurde.
6. Pipeline-Verbreitung. Wenn GitHub-Tokens gefunden wurden, schleuste die Malware bösartige Actions-Workflows in zugängliche Repositories ein, extrahierte CI/CD-Secrets und weitete die Kompromittierung auf jede Pipeline aus, die das Token des Entwicklers erreichen konnte.

Wie StepSecurity anmerkte: „Ein einzelner Entwickler mit installiertem @bitwarden/cli@2026.4.0 kann zum Einstiegspunkt für eine breitere Supply-Chain-Kompromittierung werden, wobei der Angreifer dauerhaften Workflow-Injection-Zugriff auf jede CI/CD-Pipeline erhält, die das Token des Entwicklers erreichen kann."

OX Security bestätigte, dass verschlüsselte Exfiltrationsdaten zum Zeitpunkt der Entdeckung bereits in öffentlichen GitHub-Repositories vorhanden waren — echte Rechner waren kompromittiert worden, bevor das Paket entfernt wurde.

Der Checkmarx-Vorfall: 23. März 2026

Diese Kampagne begann nicht im April. Laut dem Checkmarx-Sicherheitsupdate wurden am 23. März 2026 bösartige Versionen von zwei OpenVSX-Plugins etwa um 02:53 UTC veröffentlicht und blieben bis 15:41 UTC verfügbar. Zwei GitHub-Actions-Workflows (ast-github-action und kics-github-action) wurden ebenfalls kompromittiert. Organisationen, die diese Artefakte während dieses Zeitfensters heruntergeladen und ausgeführt haben, waren gefährdet.

Der Bitwarden CLI-Vorfall im April folgte demselben GitHub-Actions-Supply-Chain-Vektor und bestätigte eine aktive, sich entwickelnde Kampagne statt eines isolierten Vorfalls.

Die architektonische Lektion

Der Bitwarden-Vorfall spiegelt ein Muster wider, das die Branche immer wieder neu lernt: Sicherheitskontrollen auf Prozessebene können umgangen werden. Architektonische Einschränkungen nicht. Ein System, das so konzipiert ist, dass die Kompromittierung einer Komponente nichts Brauchbares liefert, ist grundlegend widerstandsfähiger als eines, das darauf angewiesen ist, dass alle Kontrollen gleichzeitig halten.

Passwork basiert auf diesem Prinzip. Zugangsdaten werden clientseitig verschlüsselt, bevor sie den Server erreichen. Der Server speichert Chiffretext. Ein Datenbank-Breach, ein kompromittierter Server oder ein böswilliger Administrator liefert nichts ohne die clientseitigen Schlüssel. Die Passwork CLI-Veröffentlichung auf PyPI folgt einem halbmanuellen Prozess von vertrauenswürdigen Rechnern — eine CI/CD-Kompromittierung kann keine automatische Veröffentlichung eines bösartigen Artefakts auslösen.

Die Frage, die Sie zu jedem Tool in Ihrem Stack stellen sollten: Wenn diese Komponente kompromittiert wird, was erhält der Angreifer tatsächlich?

Sie wechseln von einem anderen Passwort-Manager? Passwork bietet Teams, die von einer konkurrierenden Lösung wechseln, einen Migrationsrabatt von 10 %. Passwork kostenlos testen

Weitere bemerkenswerte Supply-Chain-Angriffe (2020–2026)

Der Bitwarden CLI-Vorfall ist der jüngste in einer Reihe von schwerwiegenden Supply-Chain-Kompromittierungen, die die Sichtweise von Sicherheitsteams auf Drittanbieter-Risiken verändert haben.

Jeder Vorfall teilt ein strukturelles Muster: Angreifer fanden einen vertrauenswürdigen, automatisierten Auslieferungsmechanismus und fügten ihre Nutzlast dort ein, wo sie ohne Prüfung ausgeführt werden würde:

• event-stream etablierte, dass das Vertrauen in Open-Source-Maintainer im großen Maßstab ausnutzbar ist
• SolarWinds zeigte, dass selbst signierte, vom Anbieter verteilte Updates als Waffe eingesetzt werden können
• XZ Utils demonstrierte, dass langfristiges Social Engineering von Maintainern ein gangbarer Angriffsweg ist
• Codecov bewies, dass CI/CD-Infrastruktur selbst ein hochwertiges Ziel ist — aus Build-Pipelines abgegriffene Secrets können ganze Organisationen öffnen
• Der 3CX-Fall führte ein neues Bedrohungsmodell ein: ein Supply-Chain-Angriff als Einstiegspunkt für einen weiteren Supply-Chain-Angriff

Die Angriffsfläche hat sich mit jeder Iteration erweitert. Was als isolierte Paket-Hijacks begann, hat sich zu koordinierten, mehrstufigen Kampagnen entwickelt, die auf die gesamte Software-Lieferkette abzielen.

Die wahren Kosten von Supply-Chain-Schwachstellen

Supply-Chain-Angriffe sind teuer — und die Kosten steigen. Laut der Wiz-Analyse von 2025 werden die globalen Kosten von Software-Supply-Chain-Angriffen auf 60 Milliarden Dollar im Jahr 2025 geschätzt und sollen bis 2031 138 Milliarden Dollar erreichen.

Diese Zahlen spiegeln direkte Incident-Response-Kosten, regulatorische Strafen, Reputationsschäden und die nachgelagerten Kosten der betroffenen Kunden wider — nicht nur die des kompromittierten Anbieters.

Die regulatorische Dimension verstärkt das finanzielle Risiko. Organisationen, die unter DSGVO, HIPAA, SOC 2 oder ISO 27001 operieren, unterliegen obligatorischen Meldepflichten bei Datenschutzverletzungen und potenziellen Bußgeldern, wenn Supply-Chain-Vorfälle zu unbefugtem Zugriff auf persönliche oder regulierte Daten führen. Eine kompromittierte CI/CD-Pipeline, die Umgebungsvariablen mit Datenbank-Zugangsdaten exfiltriert, ist nicht nur ein operativer Vorfall — sie ist ein Compliance-Ereignis.

Für Organisationen mit ausgereiften Sicherheitsprogrammen sind die schwerer zu quantifizierenden Kosten der Vertrauensverlust. Wenn ein Entwickler-Tool, das in Hunderten von Pipelines verwendet wird, kompromittiert wird, geht die Behebung weit über das Patchen hinaus: Jedes Secret, das hätte exponiert werden können, muss als kompromittiert behandelt und rotiert werden.

So verhindern Sie Supply-Chain-Angriffe in CI/CD-Umgebungen

Die Verhinderung von Supply-Chain-Angriffen erfordert Kontrollen auf jeder Ebene des Software-Auslieferungsprozesses. Die folgenden Praktiken adressieren die spezifischen Angriffsvektoren, die in den Kampagnen von 2026 beobachtet wurden.

• Pinnen Sie Dependency-Versionen und verifizieren Sie Hashes. Verwenden Sie niemals flexible Versionsbereiche in Produktions-Pipelines. Pinnen Sie exakte Versionen und validieren Sie Prüfsummen gegen einen bekannten guten Zustand. Dies verhindert nicht die Kompromittierung eines Maintainer-Accounts, eliminiert aber die automatische Exposition gegenüber neu veröffentlichten bösartigen Versionen.
• Erzwingen Sie signierte Builds und Provenance-Attestierung. Ein signiertes Artefakt mit einer verifizierbaren Build-Kette ist deutlich schwerer unbemerkt zu manipulieren.
• Erstellen und pflegen Sie eine Software Bill of Materials (SBOM). Eine SBOM gibt Ihnen eine vollständige Inventur jeder Komponente in Ihrer Software, einschließlich transitiver Dependencies. Wenn eine neue Schwachstelle oder ein bösartiges Paket bekannt wird, können Sie sofort feststellen, ob Sie betroffen sind — ohne manuelles Auditing.
• Führen Sie kontinuierliche Software Composition Analysis (SCA) durch. Statische, einmalige Scans sind unzureichend. SCA-Tools sollten bei jedem Pull Request und jedem Dependency-Update laufen und neue Pakete, ungewöhnliche Preinstall-Hooks und unerwartete Netzwerkaufrufe in Paket-Skripten markieren.
• Wenden Sie Zero-Trust-Prinzipien auf CI/CD-Workflows an. GitHub-Actions-Workflows sollten mit den minimal erforderlichen Berechtigungen arbeiten. Verwenden Sie kurzlebige Tokens mit Geltungsbereich für einzelne Jobs, keine langlebigen persönlichen Zugangs-Tokens. Prüfen Sie Workflow-Dateien auf Drittanbieter-Action-Referenzen und pinnen Sie sie auf spezifische Commit-SHAs, nicht auf veränderbare Tags.
• Rotieren Sie CI/CD-Secrets regelmäßig und nach jedem Vorfall. Behandeln Sie Secrets in CI/CD-Umgebungen als kurzlebige Zugangsdaten. Jedes Token, jeder API-Schlüssel oder SSH-Schlüssel, der hätte exponiert werden können, sollte sofort rotiert werden. Ein strukturierter Secrets-Management-Prozess macht dies operativ machbar statt zu einem manuellen Scramble.
• Überwachen Sie auf anomales Exfiltrationsverhalten. Die Bitwarden CLI-Malware stellte ausgehende Verbindungen zu audit.checkmarx[.]cx her. Netzwerk-Level-Überwachung des CI-Runner-Egress-Traffics hätte dies markiert. Erstellen Sie eine Allowlist erwarteter ausgehender Ziele für Build-Umgebungen und alarmieren Sie bei Abweichungen.
• Prüfen Sie KI-Coding-Tool-Konfigurationen. Die Kampagne von 2026 zielte explizit auf Konfigurationsdateien für Claude, Cursor, Aider und ähnliche Tools ab. Diese Dateien enthalten oft API-Schlüssel und Kontext über die Codebasis. Behandeln Sie sie als sensible Artefakte und beziehen Sie sie in Ihren Secrets-Scanning-Umfang ein.

Fazit

Supply-Chain-Angriffe funktionieren, weil sie das Einzige ausnutzen, was Organisationen nicht einfach prüfen können: das in automatisierte Systeme eingebettete Vertrauen. Jede Dependency, die Ihre Pipeline abruft, jede GitHub Action, die Ihr Workflow referenziert, jedes Plugin, das Ihre IDE lädt — jedes ist ein potenzieller Einstiegspunkt.

Die Bitwarden CLI- und Checkmarx-Kampagnen von 2026 machen die Bedrohung konkret. Ein einzelnes kompromittiertes Paket, das unbemerkt von einem CI-Runner installiert wird, kann jedes Secret in der Umgebung eines Entwicklers exponieren und sich durch jede Pipeline verbreiten, die dieses Token erreichen kann. Der Angriff kündigt sich nicht an. Er wird als Teil Ihres normalen Build-Prozesses ausgeführt.

Die Verteidigung dagegen erfordert mehr als periodische Audits. Sie erfordert Zero-Trust-Architektur, angewandt auf die Software-Supply-Chain: gepinnte Dependencies, signierte Artefakte, SBOM-Tracking, kontinuierliche SCA und kurzlebige Tokens mit begrenztem Umfang. Secrets müssen als vergänglich behandelt werden — regelmäßig rotiert, sicher gespeichert und niemals ohne Governance in Code oder Umgebungsdateien eingebettet.

Robustes Secrets-Management ist hier eine grundlegende Kontrolle. Wenn Zugangsdaten in einem strukturierten, zugangskontrollierten Tresor wie Passwork gespeichert werden, anstatt über .env-Dateien und Entwickler-Workstations verstreut zu sein, schrumpft der Explosionsradius einer Supply-Chain-Kompromittierung erheblich. Angreifer können stehlen, was sie erreichen können. Machen Sie es zu nichts.

Bereit, Ihren Explosionsradius zu reduzieren? Passwork bietet Ihrem Team einen strukturierten Secrets-Tresor mit rollenbasiertem Zugriff, vollständigem Audit-Logging und einer Self-Hosted-Bereitstellung, die Zugangsdaten von Drittanbieter-Infrastruktur fernhält. Teams, die von einem anderen Passwort-Manager migrieren, erhalten 10 % Rabatt. Passwork entdecken

FAQ: Supply-Chain-Angriffe

Was ist ein Supply-Chain-Angriff in der Cybersicherheit?

Ein Supply-Chain-Angriff ist ein Cyberangriff, der einen vertrauenswürdigen Drittanbieter, ein Open-Source-Paket oder eine Softwarekomponente kompromittiert, um Zugriff auf nachgelagerte Ziele zu erlangen. Anstatt eine Organisation direkt anzugreifen, schleusen Angreifer bösartige Nutzlasten in Software-Updates, Build-Pipelines oder Dependencies ein, die das Ziel automatisch installiert.

Wie funktionierte der Bitwarden CLI-Supply-Chain-Angriff?

Das bösartige Paket @bitwarden/cli@2026.4.0 wurde am 22. April 2026 auf npm mit einem in bw1.js eingebetteten Credential Stealer veröffentlicht und über einen Preinstall-Hook ausgeführt. Es sammelte GitHub-Tokens, SSH-Schlüssel, Umgebungsvariablen, Cloud-Secrets und KI-Coding-Tool-Konfigurationen und exfiltrierte die Daten — mit AES-256-GCM verschlüsselt — an eine Domain, die Checkmarx imitierte.

Was ist der Unterschied zwischen einem Supply-Chain-Angriff und einem direkten Cyberangriff?

Ein direkter Angriff zielt auf die eigenen Systeme des Opfers ab — sein Netzwerk, seine Zugangsdaten oder seine Anwendungen. Ein Supply-Chain-Angriff zielt stattdessen auf einen vertrauenswürdigen Lieferanten oder eine Dependency ab und nutzt dieses Vertrauen, um die Abwehr des Opfers zu umgehen. Das Opfer installiert oder führt die kompromittierte Komponente freiwillig über normale Prozesse aus, was die Erkennung erheblich erschwert.

Was sind transitive Dependencies und warum sind sie für die Sicherheit wichtig?

Transitive Dependencies sind Softwarekomponenten, auf die Ihr Code indirekt angewiesen ist — Bibliotheken, die von Ihren direkten Dependencies importiert werden, die wiederum andere importieren. Sie werden selten mit der gleichen Sorgfalt wie First-Party-Code geprüft, werden aber in Ihrer Umgebung mit denselben Privilegien ausgeführt. Eine Kompromittierung irgendwo in dieser Kette kann Ihre Anwendung betreffen.

Was ist eine SBOM und wie hilft sie, Supply-Chain-Angriffe zu verhindern?

Eine Software Bill of Materials (SBOM) ist ein strukturiertes Inventar jeder Komponente in einem Softwareprodukt, einschließlich aller direkten und transitiven Dependencies. Wenn ein bösartiges Paket oder eine Schwachstelle bekannt wird, ermöglicht eine SBOM Sicherheitsteams sofort festzustellen, ob ihre Software betroffen ist — ohne manuelles Durchsuchen von Dependency-Trees in jedem Projekt.

Welche GitHub-Actions-Sicherheitspraktiken reduzieren das Supply-Chain-Risiko?

Pinnen Sie alle Drittanbieter-Actions auf spezifische Commit-SHAs statt auf veränderbare Versions-Tags. Verwenden Sie kurzlebige, job-spezifische Tokens anstelle von langlebigen persönlichen Zugangs-Tokens. Beschränken Sie Workflow-Berechtigungen auf das erforderliche Minimum. Prüfen Sie alle Workflow-Dateien auf unerwartete Drittanbieter-Referenzen und überwachen Sie CI-Runner-Egress-Traffic auf anomale ausgehende Verbindungen.

Wie sollten Organisationen reagieren, wenn ein kompromittiertes Paket in ihrer CI/CD-Pipeline installiert wurde?

Behandeln Sie alle Secrets, die während der betroffenen Build-Jobs zugänglich waren, als kompromittiert. Rotieren Sie jedes Token, jeden API-Schlüssel, SSH-Schlüssel und jede Cloud-Zugangsdaten, die hätten exponiert werden können. Überprüfen Sie GitHub-Actions-Workflow-Dateien auf unautorisierte Änderungen. Prüfen Sie Repository-Zugriffsprotokolle auf unerwartete Commits oder Workflow-Läufe. Melden Sie den Vorfall gemäß Ihren regulatorischen Verpflichtungen unter DSGVO, HIPAA oder anwendbaren Frameworks.

Brute-Force-Angriffe 2026: Typen, Beispiele und wie Sie sie verhindern

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

Passwork BlogAlex Muntyan

NIS2 aktuelle Nachrichten: Was sich geändert hat und was es für EU-Unternehmen bedeutet

84 % der betroffenen Organisationen geben zu, dass sie nicht bereit sind. Belgien setzte die erste Konformitätsbewertungsfrist auf den 18. April 2026. Die Niederlande stehen kurz vor der Durchsetzung. Hier ist der aktuelle Stand der Regulierungswelle und was IT-Führungskräfte jetzt tun müssen.

Passwork BlogAlex Muntyan

Passwort-Chaos: Warum es ein Geschäftsproblem ist und wie Sie es lösen

Ein vergessenes Passwort kostet 70 $. Ein Datenleck kostet 4,44 Millionen $. Beides beginnt auf die gleiche Weise — Zugangsdaten, die über Slack geteilt, in Tabellenkalkulationen gespeichert und nie rotiert werden. Hier erfahren Sie, was Passwort-Chaos wirklich kostet und wie Sie es eliminieren.

Passwork BlogAlex Muntyan

El 22 de abril de 2026, un ladrón de credenciales se distribuyó dentro de un paquete con 250.000 descargas mensuales. Se ejecutó silenciosamente durante la instalación, no requirió interacción del usuario y fue descargado automáticamente por ejecutores de CI en docenas de pipelines. Para cuando el paquete fue retirado del registro, máquinas reales ya habían sido comprometidas.

Solo una actualización rutinaria de dependencias.

La infraestructura moderna es tan segura como su dependencia más débil. Cuando los atacantes no pueden vulnerar su perímetro directamente, comprometen algo en lo que usted ya confía y lo utilizan para entrar directamente en su entorno.

Un ataque a la cadena de suministro es el compromiso de un proveedor externo de confianza, un componente de software o un servicio para infiltrarse en objetivos aguas abajo. El atacante no necesita sus credenciales. Necesita acceso a algo que su pipeline de compilación descarga automáticamente a las 3 de la madrugada. Necesita un hook de preinstalación que se ejecute antes de que usted pueda inspeccionarlo.

El incidente de Bitwarden CLI es la última prueba de que esta amenaza es operativa, coordinada y se está acelerando. En este artículo, analizamos cómo funcionó el ataque, qué nos enseña sobre la infraestructura moderna y qué controles realmente previenen que los compromisos de la cadena de suministro lleguen a su entorno.

Puntos clave

• Los ataques a la cadena de suministro evaden su perímetro al convertir en arma lo que usted ya confía — paquetes, flujos de trabajo de CI y plugins se ejecutan en su entorno con privilegios completos, sin un solo enlace de phishing.
• El compromiso de Bitwarden CLI de abril de 2026 fue una operación coordinada y multietapa — los atacantes secuestraron una GitHub Action de terceros, robaron un token de npm y publicaron @bitwarden/cli@2026.4.0 con un ladrón de credenciales que se ejecutaba silenciosamente durante la instalación.
• Las dependencias transitivas son su mayor superficie de ataque sin auditar — su aplicación puede importar diez paquetes directamente, pero cada uno de ellos incorpora docenas más, ninguno de los cuales recibe el mismo escrutinio que el código propio.
• La arquitectura es un control más fuerte que el proceso — un sistema diseñado de manera que comprometer un componente no proporcione nada útil es fundamentalmente más resiliente que uno que depende de que todos los controles se mantengan simultáneamente.
• Los secretos en pipelines de CI/CD son el objetivo principal — los tokens de GitHub, las claves SSH y las credenciales de nube recolectados en un solo trabajo de compilación pueden propagar un compromiso a través de cada repositorio y pipeline al que ese token pueda acceder.
• La defensa requiere controles continuos, no periódicos — dependencias fijadas, compilaciones firmadas, seguimiento de SBOM, tokens efímeros con alcance limitado y rotación de secretos deben ejecutarse en cada commit, no cada trimestre.

Qué es un ataque a la cadena de suministro

Un ataque a la cadena de suministro ocurre cuando un adversario compromete un proveedor externo de confianza, un paquete de código abierto o un componente de software para entregar una carga maliciosa a organizaciones aguas abajo. El atacante explota la relación de confianza entre un proveedor y sus consumidores, lo que hace que la detección sea significativamente más difícil que con una intrusión directa.

La superficie de ataque es amplia porque el software moderno se construye sobre capas de dependencias. Su aplicación puede importar directamente diez paquetes, pero cada uno de ellos importa docenas más. Estas dependencias transitivas (componentes de los que su código depende indirectamente) rara vez se auditan con el mismo rigor que el código propio.

Los ataques a la cadena de suministro se dividen en varias categorías:

• Ataques a la cadena de suministro de software — Código malicioso inyectado en bibliotecas de código abierto, registros de paquetes (npm, PyPI) o actualizaciones de software de proveedores.
• Ataques a pipelines de CI/CD — Compromiso de sistemas de compilación, flujos de trabajo de GitHub Actions o registros de contenedores para interceptar el proceso de compilación.
• Ataques a servicios de terceros — Explotación de herramientas SaaS, plugins o servicios gestionados que tienen acceso privilegiado a los entornos de los clientes.
• Ataques a la cadena de suministro de hardware — Manipulación física del firmware o componentes antes de que lleguen al usuario final (menos común en contextos de software, pero documentado en operaciones de estados-nación).

El hilo común: la víctima instala, ejecuta o confía en algo que ya ha sido convertido en arma.

La anatomía de un ataque moderno a la cadena de suministro

Un ataque a la cadena de suministro sigue un ciclo de vida predecible. Conocer las fases es lo que lo hace prevenible.

1. Reconocimiento. Los atacantes escanean repositorios públicos, registros de paquetes y configuraciones de CI/CD en busca de eslabones débiles: tokens de GitHub desprotegidos, paquetes con alto número de descargas y mínimos mantenedores, o flujos de trabajo de Actions con permisos excesivos.
2. Compromiso aguas arriba. El atacante obtiene acceso de escritura a un artefacto de confianza robando credenciales de mantenedores, enviando una solicitud de extracción maliciosa o inyectando código directamente en un pipeline de compilación. La carga maliciosa se incrusta donde se ejecutará automáticamente: un hook de preinstalación, un paso de flujo de trabajo, una actualización de plugin.
3. Latencia. El artefacto comprometido se publica y espera. Los sistemas automatizados (ejecutores de CI, gestores de dependencias, estaciones de trabajo de desarrolladores) descargan la actualización sin revisión humana. El código malicioso permanece latente hasta que se activa.
4. Entrega aguas abajo. Los desarrolladores y los pipelines instalan la versión infectada a través de canales normales y de confianza. No hay ningún enlace de phishing en el que hacer clic, ningún archivo adjunto sospechoso que abrir. El ladrón de credenciales se ejecuta como parte del proceso de compilación estándar.
5. Escalada de privilegios. Con el acceso inicial establecido, el atacante recolecta secretos: tokens de API, claves SSH, variables de entorno, credenciales de nube. Los tokens de GitHub son particularmente valiosos — pueden convertirse en arma para inyectar flujos de trabajo maliciosos en cada repositorio al que el token pueda acceder, propagando el compromiso más aguas abajo.

Los secretos desprotegidos en pipelines de CI/CD son exactamente lo que los atacantes recolectan en la fase cinco. Pruebe Passwork gratis y vea cómo la gestión estructurada de secretos reduce su exposición → passwork.pro

Caso de estudio: la campaña de Bitwarden CLI y Checkmarx de 2026

El ataque a la cadena de suministro de Bitwarden CLI, confirmado por JFrog y Socket el 23 de abril de 2026, es una de las operaciones de recolección de credenciales técnicamente más precisas documentadas hasta la fecha. Se dirigió directamente a los desarrolladores: sus tokens, sus herramientas de IA, sus pipelines. Y conllevó una importante lección arquitectónica para toda la industria.

El ataque se desarrolló en etapas, cada una explotando una capa diferente de confianza en la cadena de suministro de software.

Qué ocurrió

El 22 de abril de 2026, se publicó una versión maliciosa de Bitwarden CLI (@bitwarden/cli@2026.4.0) en el registro de npm. El paquete tiene más de 250.000 descargas mensuales, lo que lo convierte en un objetivo de alto valor. El código malicioso estaba incrustado en bw1.js y se activaba mediante un hook de preinstalación en package.json, que primero ejecutaba bw_setup.js para instalar el runtime Bun, y luego ejecutaba bw1.js — la carga maliciosa real (OX Security, 2026). No se requería interacción del usuario.

Los atacantes no vulneraron directamente a Bitwarden. Comprometieron una GitHub Action de terceros utilizada en el pipeline de CI/CD de Bitwarden, obtuvieron acceso a los secretos del flujo de trabajo, incluyendo un token de npm, y lo usaron para publicar el paquete malicioso. El ataque utilizó el pipeline de CI/CD como punto de entrada — consistente con el patrón más amplio identificado en la campaña de cadena de suministro de Checkmarx. La cadena "Shai-Hulud: The Third Coming" incrustada en el paquete confirmó que esta era la tercera iteración de una campaña organizada y continua — no un incidente aislado oportunista.

De manera crítica, ninguna bóveda de usuarios se vio afectada. La arquitectura de conocimiento cero de Bitwarden significaba que el servidor nunca almacenó contraseñas maestras ni acceso a datos de usuario descifrados. Incluso con el CI/CD comprometido, el atacante no pudo alcanzar lo que la arquitectura estaba diseñada para proteger.

Qué hizo el malware

La carga maliciosa (la tercera fase del gusano «Shai-Hulud») realizó la siguiente secuencia:

1. Verificación de idioma ruso. Antes de hacer cualquier otra cosa, el malware verificaba si la máquina anfitriona tenía configurado el idioma ruso. Si era así, salía inmediatamente. Esta es una técnica estándar de autoprotección: los autores evitan infectar sus propias máquinas de desarrollo, y apunta fuertemente a un actor de amenazas de habla rusa.
2. Recolección de credenciales. Se dirigió a tokens de GitHub y npm, directorios .ssh, archivos .env, historial del shell, variables de entorno de GitHub Actions, credenciales de AWS, GCP y Azure, e información del GitHub Runner.
3. Targeting de herramientas de IA. Los archivos de configuración para asistentes de codificación con IA (Claude, Kiro, Cursor, Codex CLI y Aider) fueron objetivo explícito, reflejando cuán profundamente estas herramientas están ahora integradas en los flujos de trabajo de los desarrolladores y cuánto contexto sensible almacenan localmente.
4. Exfiltración cifrada vía GitHub. Todos los datos robados fueron cifrados con AES-256-GCM usando cifrado asimétrico — lo que significa que solo la clave privada del actor de amenazas puede descifrarlos. Los datos se cargaron a un repositorio público de GitHub recién creado en la propia cuenta de la víctima, con archivos nombrados results-TIMESTAMP-ID.json. Un canal secundario exfiltró datos a audit.checkmarx[.]cx, un dominio que suplantaba la plataforma legítima de Checkmarx. Usar GitHub como servidor de C2 es deliberado: el tráfico a github.com rara vez es marcado por herramientas de seguridad y no puede rastrearse hasta un dominio controlado por el actor de amenazas.
5. Auto-propagación. Esto es lo que convierte a Shai-Hulud en un gusano, no solo un ladrón. Si se encontraban tokens de npm válidos, el malware descargaba uno de los propios paquetes de npm de la víctima, inyectaba código malicioso en él y republicaba una nueva versión — propagando la infección a los usuarios aguas abajo de la víctima automáticamente.
6. Propagación por pipeline. Si se encontraban tokens de GitHub, el malware inyectaba flujos de trabajo maliciosos de Actions en repositorios accesibles, extrayendo secretos de CI/CD y extendiendo el compromiso a cada pipeline al que el token del desarrollador pudiera acceder.

Como señaló StepSecurity: «Un solo desarrollador con @bitwarden/cli@2026.4.0 instalado puede convertirse en el punto de entrada para un compromiso más amplio de la cadena de suministro, con el atacante obteniendo acceso persistente de inyección de flujos de trabajo a cada pipeline de CI/CD al que el token del desarrollador pueda acceder».

OX Security confirmó que los datos de exfiltración cifrados ya estaban presentes en repositorios públicos de GitHub en el momento del descubrimiento — máquinas reales habían sido comprometidas antes de que el paquete fuera retirado.

El incidente de Checkmarx: 23 de marzo de 2026

Esta campaña no comenzó en abril. Según la actualización de seguridad de Checkmarx, el 23 de marzo de 2026, se publicaron versiones maliciosas de dos plugins de OpenVSX aproximadamente a las 02:53 UTC y permanecieron disponibles hasta las 15:41 UTC. Dos flujos de trabajo de GitHub Actions (ast-github-action y kics-github-action) también fueron comprometidos. Las organizaciones que descargaron estos artefactos durante ese período y los ejecutaron quedaron expuestas.

El incidente de Bitwarden CLI de abril siguió el mismo vector de cadena de suministro de GitHub Actions, confirmando una campaña activa y en evolución en lugar de un incidente aislado.

La lección arquitectónica

El incidente de Bitwarden refleja un patrón que la industria sigue reaprendiendo: los controles de seguridad a nivel de proceso pueden eludirse. Las restricciones arquitectónicas no. Un sistema diseñado de manera que comprometer un componente no proporcione nada útil es fundamentalmente más resiliente que uno que depende de que todos los controles se mantengan simultáneamente.

Passwork está construido sobre este principio. Las credenciales se cifran del lado del cliente antes de que lleguen al servidor. El servidor almacena texto cifrado. Una brecha de base de datos, un servidor comprometido o un administrador desleal no obtiene nada sin las claves del lado del cliente. La publicación de Passwork CLI en PyPI sigue un proceso semimanual desde máquinas de confianza — el compromiso de CI/CD no puede desencadenar una publicación automatizada de un artefacto malicioso.

La pregunta que debe hacerse sobre cualquier herramienta en su stack: si este componente se compromete, ¿qué obtiene realmente el atacante?

¿Está migrando desde otro gestor de contraseñas? Passwork ofrece un descuento del 10 % a los equipos que cambien desde una solución de la competencia. Prueba Passwork gratis

Otros ataques notables a la cadena de suministro (2020–2026)

El incidente de Bitwarden CLI es el más reciente en una serie de compromisos de alto impacto a la cadena de suministro que han reconfigurado cómo los equipos de seguridad piensan sobre el riesgo de terceros.

Cada incidente comparte un patrón estructural: los atacantes encontraron un mecanismo de entrega automatizado y de confianza e insertaron su carga donde se ejecutaría sin escrutinio:

• event-stream estableció que la confianza en los mantenedores de código abierto es explotable a escala
• SolarWinds demostró que incluso las actualizaciones firmadas y distribuidas por el proveedor pueden convertirse en arma
• XZ Utils demostró que la ingeniería social a largo plazo de los mantenedores es una vía de ataque viable
• Codecov probó que la propia infraestructura de CI/CD es un objetivo de alto valor — los secretos recolectados de los pipelines de compilación pueden desbloquear organizaciones enteras
• El caso de 3CX introdujo un nuevo modelo de amenaza: un ataque a la cadena de suministro utilizado como punto de entrada para otro ataque a la cadena de suministro

La superficie de ataque se ha expandido con cada iteración. Lo que comenzó como secuestros aislados de paquetes ha evolucionado hacia campañas coordinadas y multietapa que apuntan a toda la cadena de entrega de software.

El verdadero coste de las vulnerabilidades en la cadena de suministro

Los ataques a la cadena de suministro son costosos — y el coste se está acelerando. Según el análisis de Wiz de 2025, los costes globales de los ataques a la cadena de suministro de software se estiman en 60.000 millones de dólares en 2025 y se proyecta que alcancen los 138.000 millones de dólares para 2031.

Estas cifras reflejan los costes directos de respuesta a incidentes, sanciones regulatorias, daño reputacional y los costes derivados que soportan los clientes afectados — no solo el proveedor vulnerado.

La dimensión regulatoria agrava la exposición financiera. Las organizaciones que operan bajo GDPR, HIPAA, SOC 2 o ISO 27001 enfrentan requisitos obligatorios de notificación de brechas y posibles multas cuando los incidentes de la cadena de suministro resultan en acceso no autorizado a datos personales o regulados. Un pipeline de CI/CD comprometido que exfiltra variables de entorno que contienen credenciales de base de datos no es solo un incidente operativo — es un evento de cumplimiento.

Para organizaciones con programas de seguridad maduros, el coste más difícil de cuantificar es la confianza. Cuando una herramienta de desarrollo utilizada en cientos de pipelines se compromete, el esfuerzo de remediación se extiende mucho más allá de parchear: cada secreto que podría haber sido expuesto debe tratarse como comprometido y rotarse.

Cómo prevenir ataques a la cadena de suministro en entornos de CI/CD

Prevenir ataques a la cadena de suministro requiere controles en cada capa del proceso de entrega de software. Las siguientes prácticas abordan los vectores de ataque específicos vistos en las campañas de 2026.

• Fije las versiones de dependencias y verifique los hashes. Nunca use rangos de versión flotantes en pipelines de producción. Fije versiones exactas y valide las sumas de verificación contra un estado conocido como bueno. Esto no evitará el compromiso de una cuenta de mantenedor, pero elimina la exposición automática a versiones maliciosas recién publicadas.
• Aplique compilaciones firmadas y atestación de procedencia. Un artefacto firmado con una cadena de compilación verificable es significativamente más difícil de manipular sin ser detectado.
• Genere y mantenga una lista de materiales de software (SBOM). Un SBOM le proporciona un inventario completo de cada componente en su software, incluyendo dependencias transitivas. Cuando se divulga un nuevo paquete malicioso o vulnerabilidad, puede determinar inmediatamente si está afectado — sin auditoría manual.
• Ejecute análisis continuo de composición de software (SCA). Los escaneos estáticos y únicos son insuficientes. Las herramientas SCA deben ejecutarse en cada solicitud de extracción y cada actualización de dependencia, marcando nuevos paquetes, hooks de preinstalación inusuales y llamadas de red inesperadas en scripts de paquetes.
• Aplique principios de confianza cero a los flujos de trabajo de CI/CD. Los flujos de trabajo de GitHub Actions deben operar con los permisos mínimos requeridos. Use tokens efímeros con alcance a trabajos individuales, no tokens de acceso personal de larga duración. Audite los archivos de flujo de trabajo para referencias a Actions de terceros y fíjelos a SHAs de commit específicos, no a etiquetas mutables.
• Rote los secretos de CI/CD regularmente y después de cada incidente. Trate los secretos en entornos de CI/CD como credenciales de corta duración. Cualquier token, clave de API o clave SSH que pudiera haber sido expuesto debe rotarse inmediatamente. Un proceso estructurado de gestión de secretos hace esto operacionalmente factible en lugar de una carrera manual.
• Monitorice comportamientos anómalos de exfiltración. El malware de Bitwarden CLI hizo conexiones salientes a audit.checkmarx[.]cx. El monitoreo a nivel de red del tráfico de salida del ejecutor de CI habría marcado esto. Cree una lista blanca de destinos salientes esperados para entornos de compilación y alerte sobre desviaciones.
• Audite las configuraciones de herramientas de codificación con IA. La campaña de 2026 se dirigió explícitamente a archivos de configuración de Claude, Cursor, Aider y herramientas similares. Estos archivos a menudo contienen claves de API y contexto sobre la base de código. Trátelos como artefactos sensibles e inclúyalos en el alcance de su escaneo de secretos.

Conclusión

Los ataques a la cadena de suministro funcionan porque explotan lo único que las organizaciones no pueden auditar fácilmente: la confianza incorporada en los sistemas automatizados. Cada dependencia que su pipeline descarga, cada GitHub Action que su flujo de trabajo referencia, cada plugin que su IDE carga — cada uno es un punto de entrada potencial.

Las campañas de Bitwarden CLI y Checkmarx de 2026 hacen concreta la amenaza. Un solo paquete comprometido, instalado silenciosamente por un ejecutor de CI, puede exponer cada secreto en el entorno de un desarrollador y propagarse a través de cada pipeline al que ese token pueda acceder. El ataque no se anuncia. Se ejecuta como parte de su proceso de compilación normal.

Defenderse contra esto requiere más que auditorías periódicas. Requiere arquitectura de confianza cero aplicada a la cadena de suministro de software: dependencias fijadas, artefactos firmados, seguimiento de SBOM, SCA continuo y credenciales efímeras con alcance limitado. Los secretos deben tratarse como perecederos — rotados regularmente, almacenados de forma segura y nunca incrustados en código o archivos de entorno sin gobernanza.

Una gestión robusta de secretos es un control fundamental aquí. Cuando las credenciales se almacenan en una bóveda estructurada con acceso controlado como Passwork en lugar de estar dispersas en archivos .env y estaciones de trabajo de desarrolladores, el radio de explosión de un compromiso de la cadena de suministro se reduce significativamente. Los atacantes pueden robar lo que pueden alcanzar. Haga que sea nada.

¿Listo para reducir su radio de explosión? Passwork proporciona a su equipo una bóveda de secretos estructurada con acceso basado en roles, registro de auditoría completo y una implementación autoalojada que mantiene las credenciales fuera de la infraestructura de terceros. Los equipos que migran desde otro gestor de contraseñas reciben un 10 % de descuento. Explorar Passwork

Preguntas frecuentes: ataques a la cadena de suministro

¿Qué es un ataque a la cadena de suministro en ciberseguridad?

Un ataque a la cadena de suministro es un ciberataque que compromete un proveedor externo de confianza, un paquete de código abierto o un componente de software para obtener acceso a objetivos aguas abajo. En lugar de atacar directamente a una organización, los adversarios insertan cargas maliciosas en actualizaciones de software, pipelines de compilación o dependencias que el objetivo instala automáticamente.

¿Cómo funcionó el ataque a la cadena de suministro de Bitwarden CLI?

El paquete malicioso @bitwarden/cli@2026.4.0 se publicó en npm el 22 de abril de 2026, con un ladrón de credenciales incrustado en bw1.js y ejecutado mediante un hook de preinstalación. Recolectó tokens de GitHub, claves SSH, variables de entorno, secretos de nube y configuraciones de herramientas de codificación con IA, y luego exfiltró los datos — cifrados con AES-256-GCM — a un dominio que suplantaba a Checkmarx.

¿Cuál es la diferencia entre un ataque a la cadena de suministro y un ciberataque directo?

Un ataque directo apunta a los propios sistemas de la víctima — su red, credenciales o aplicaciones. Un ataque a la cadena de suministro apunta en cambio a un proveedor o dependencia de confianza, utilizando esa confianza para eludir las defensas de la víctima. La víctima instala o ejecuta el componente comprometido voluntariamente, a través de procesos normales, lo que hace que la detección sea significativamente más difícil.

¿Qué son las dependencias transitivas y por qué importan para la seguridad?

Las dependencias transitivas son componentes de software de los que su código depende indirectamente — bibliotecas importadas por sus dependencias directas, que a su vez importan otras. Rara vez se auditan con el mismo rigor que el código propio, pero se ejecutan en su entorno con los mismos privilegios. Un compromiso en cualquier parte de esa cadena puede afectar a su aplicación.

¿Qué es un SBOM y cómo ayuda a prevenir ataques a la cadena de suministro?

Una lista de materiales de software (SBOM) es un inventario estructurado de cada componente en un producto de software, incluyendo todas las dependencias directas y transitivas. Cuando se divulga un paquete malicioso o vulnerabilidad, un SBOM permite a los equipos de seguridad determinar inmediatamente si su software está afectado — sin rastrear manualmente árboles de dependencias en cada proyecto.

¿Qué prácticas de seguridad de GitHub Actions reducen el riesgo de la cadena de suministro?

Fije todas las Actions de terceros a SHAs de commit específicos en lugar de etiquetas de versión mutables. Use tokens efímeros con alcance de trabajo en lugar de tokens de acceso personal de larga duración. Restrinja los permisos de flujo de trabajo al mínimo requerido. Audite todos los archivos de flujo de trabajo para referencias inesperadas de terceros, y monitorice el tráfico de salida del ejecutor de CI para conexiones salientes anómalas.

¿Cómo deben responder las organizaciones si se instaló un paquete comprometido en su pipeline de CI/CD?

Trate todos los secretos accesibles durante los trabajos de compilación afectados como comprometidos. Rote cada token, clave de API, clave SSH y credencial de nube que pudiera haber sido expuesto. Revise los archivos de flujo de trabajo de GitHub Actions para modificaciones no autorizadas. Audite los registros de acceso del repositorio para commits o ejecuciones de flujo de trabajo inesperados. Reporte el incidente según sus obligaciones regulatorias bajo GDPR, HIPAA o los marcos aplicables.

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

Últimas noticias de NIS2: qué cambió y qué significa para las empresas de la UE

El 84% de las organizaciones en el ámbito admiten que no están preparadas. Bélgica estableció la primera fecha límite de evaluación de conformidad el 18 de abril de 2026. Los Países Bajos están a días de la aplicación. Aquí está dónde se encuentra la ola regulatoria y qué deben hacer los líderes de TI ahora.

Passwork BlogAlex Muntyan

Caos de contraseñas: por qué es un problema empresarial y cómo solucionarlo

Una contraseña olvidada cuesta 70 dólares. Una brecha cuesta 4,44 millones de dólares. Ambas empiezan de la misma manera — credenciales compartidas por Slack, almacenadas en hojas de cálculo, nunca rotadas. Aquí está lo que realmente cuesta el caos de contraseñas y cómo eliminarlo.

Passwork BlogAlex Muntyan

Why breach a well-defended corporate network when you can compromise an npm package with millions of weekly downloads and slip silently into thousands of those networks at once?

On April 22, 2026, a credential stealer shipped inside a package with 250,000 monthly downloads. It executed silently at install time, required no user interaction, and was pulled automatically by CI runners across dozens of pipelines. By the time security teams detected the compromise, real machines had already been compromised. Just a routine dependency update.

This is the core vulnerability of modern infrastructure: you are only as secure as your weakest dependency. When attackers can't breach your perimeter directly, they compromise something you already trust and ride it straight into your environment.

The 2026 supply chain campaigns prove this isn't theoretical. Three coordinated attacks across different vectors hit production systems within weeks of each other. Each one followed the same pattern: identify a trusted package, inject malicious code, wait for automation to do the work.

These aren't isolated incidents. They're proof that supply chain attacks have become industrialized, coordinated, and accelerating.

Key takeaways

• Supply chain attacks bypass your perimeter by weaponizing trust. Packages, CI workflows, and plugins execute in your environment with full privileges. No phishing link required. The attacker becomes part of your normal build process.
• The 2026 campaigns exposed three distinct attack surfaces simultaneously. CI/CD pipeline compromise (Bitwarden CLI), transitive dependency injection (Axios), and OAuth token theft (Vercel/Context.ai) demonstrate that attackers are no longer targeting single vectors.
• Transitive dependencies are your largest blind spot. Your application imports ten packages directly, but each pulls in dozens more. These invisible layers execute with the same privileges as your code, yet most teams never audit them. One compromised transitive dependency can propagate through hundreds of downstream projects.
• Secrets in CI/CD pipelines are the primary target. A single build job that harvests a GitHub token can propagate a compromise across every repository and pipeline that token can reach. The attacker doesn't need to break into your infrastructure. They just need to extract what's already there.
• Architecture beats process. A system designed so that compromising one component yields nothing useful is fundamentally more resilient than one that relies on every control holding simultaneously. Secrets should be encrypted, scoped, and rotated, not scattered across environment files and developer machines.
• Defence requires continuous controls, not periodic audits. Pinned dependencies, signed builds, SBOM tracking, scoped ephemeral tokens, and secrets rotation must run on every commit, not every quarter. The attack window is measured in hours. Your response window must be faster.

What is a supply chain attack

A supply chain attack occurs when an adversary compromises a trusted third-party vendor, open-source package, or software component to deliver a malicious payload to downstream organizations. Instead of attacking your infrastructure directly, the attacker inserts malicious code into something you already trust, and your own systems pull it in automatically.

The attack exploits a fundamental asymmetry: you audit your own code rigorously, but you install third-party dependencies with minimal scrutiny. The attacker knows this. They know that compromising a single trusted package reaches thousands of organizations in parallel, through their own build pipelines, with their own credentials.

Why transitive dependencies make the attack surface exponential

Modern software is built on layers of dependencies. Your application may directly import ten packages, but each of those imports dozens more. These transitive dependencies execute in your environment with the same privileges as first-party code, yet they are rarely audited at all.

A single compromised transitive dependency can propagate through hundreds of downstream projects without any of them knowing they've imported it. The attacker doesn't need to compromise the packages you explicitly depend on. They can compromise something three or four layers deep in your dependency tree, and the malicious code still executes in your CI/CD pipeline.

Supply chain attack vectors

The scale of the threat in 2025–2026

Supply chain attacks are no longer rare incidents. They are now an industrialized threat.

• Over 70% of organizations experienced at least one material third-party cybersecurity incident in the past year (SecurityScorecard, 2025).
• 454,600+ new malicious packages were identified in registries in 2025, representing a 75% year-over-year increase. These packages were cumulatively downloaded 9.8 trillion times across npm, PyPI, Maven Central, NuGet, and Hugging Face (Sonatype, 2026).
• $60 billion estimated global cost of software supply chain attacks in 2025, projected to reach $138 billion by 2031 (Cybersecurity Ventures, 2025).
• 2.6 billion weekly downloads affected by the Shai-Hulud worm campaign targeting npm packages (Trend Micro, 2025).

The regulatory dimension compounds the financial exposure. Organizations operating under GDPR, HIPAA, SOC 2, or ISO 27001 face mandatory breach notification requirements and potential fines when supply chain incidents result in unauthorized access to personal or regulated data.

The anatomy of a modern supply chain attack

A supply chain attack follows a predictable lifecycle:

• Phase 1: Reconnaissance. Attackers scan public repositories, package registries, and CI/CD configurations for weak links: unprotected GitHub tokens in workflow logs, packages with high download counts and minimal maintainers, Actions workflows with excessive permissions.
• Phase 2: Upstream compromise. The attacker gains write access to a trusted artifact by stealing maintainer credentials, submitting a malicious pull request that passes code review, or compromising a CI/CD pipeline.
• Phase 3: Dormancy. The compromised artifact is published and waits. Automated systems pull the update without human review.
• Phase 4: Downstream delivery. Developers and pipelines install the infected version through normal, trusted channels. The credential stealer executes as part of the standard build process.
• Phase 5: Privilege escalation and propagation. With initial access established, the attacker harvests secrets: API tokens, SSH keys, environment variables, cloud credentials. GitHub tokens are particularly valuable because they can be weaponized to inject malicious workflows into every repository the token can reach.

Unprotected secrets in CI/CD pipelines are exactly what attackers harvest in phase five. Passwork centralizes credential management and audit logging, so you can track which secrets were accessed, when, and by whom. This turns CI/CD from a blind spot into a controlled environment. Try Passwork free

Three major supply chain attacks of 2026

The 2026 campaigns demonstrate a coordinated shift in attack sophistication. Rather than isolated package hijacks, threat actors targeted three distinct vectors simultaneously, each exposing different layers of the software supply chain.

Bitwarden CLI compromise (April 2026)

On April 22, 2026, a malicious version of the Bitwarden CLI (@bitwarden/cli@2026.4.0) was published to the npm registry. The package has over 250,000 monthly downloads. The malicious code was embedded in bw1.js and triggered via a preinstall hook in package.json (OX Security).

The attackers didn't breach Bitwarden directly. They compromised a third-party GitHub Action used in Bitwarden's CI/CD pipeline, gained access to workflow secrets including an npm token, and used it to publish the malicious package. The string "Shai-Hulud: The Third Coming" embedded in the package confirmed this was the third iteration of an ongoing, organized campaign.

What the malware did

The malicious payload performed the following sequence:

• Russian-language check. Before doing anything else, the malware checked whether the host machine had Russian language configured. If so, it exited immediately. This is a standard self-protection technique: the authors avoid infecting their own development machines, and it points strongly to a Russian-speaking threat actor.
• Credential harvesting. It targeted GitHub and npm tokens, .ssh directories and private keys, .env files and shell history, GitHub Actions environment variables, and AWS, GCP, and Azure credentials. Configuration files for AI coding assistants (Claude, Cursor, Aider, Codex CLI, and Kiro) were explicitly targeted, reflecting how deeply these tools are now embedded in developer workflows and how much sensitive context they store locally.
• Encrypted exfiltration via GitHub. All stolen data was encrypted with AES-256-GCM using asymmetric encryption, meaning only the threat actor's private key can decrypt it. The data was uploaded to a newly created public GitHub repository on the victim's own account, with files named results-TIMESTAMP-ID.json. A secondary channel exfiltrated data to audit.checkmarx[.]cx, a domain impersonating the legitimate Checkmarx platform. Using GitHub as a C2 server is deliberate: traffic to github.com is rarely flagged by security tools and cannot be traced to a threat-actor-controlled domain.
• Self-propagation. This is what makes Shai-Hulud a worm, not just a stealer. If valid npm tokens were found, the malware downloaded one of the victim's own npm packages, injected malicious code into it, and republished a new version, spreading the infection to the victim's downstream users automatically.
• Pipeline propagation. If GitHub tokens were found, the malware injected malicious Actions workflows into accessible repositories, extracting CI/CD secrets and extending the compromise to every pipeline the developer's token could reach.

As StepSecurity noted: "A single developer with @bitwarden/cli@2026.4.0 installed can become the entry point for a broader supply chain compromise, with the attacker gaining persistent workflow injection access to every CI/CD pipeline the developer's token can reach."

OX Security confirmed that encrypted exfiltration data was already present in public GitHub repositories at the time of discovery. Real machines had been compromised before the package was pulled.

The architectural lesson

The Bitwarden incident reflects a pattern the industry keeps relearning: process-level security controls can be bypassed. Architectural constraints cannot. A system designed so that compromising one component yields nothing useful is fundamentally more resilient than one that relies on every control holding simultaneously.

Passwork is built on this principle. Credentials are encrypted client-side before they ever reach the server. The server stores ciphertext. A database breach, a compromised server, or a rogue administrator yields nothing without the client-side keys. Passwork CLI publishing to PyPI follows a semi-manual process from trusted machines — CI/CD compromise cannot trigger an automated release of a malicious artifact.

Axios (March 2026)

On March 31, 2026, the widely used Axios npm package (100+ million weekly downloads) was compromised when an attacker hijacked the maintainer's credentials and published malicious versions. But the attack's true sophistication lay in how it exploited transitive dependencies.

Instead of embedding malware directly in Axios, the attackers created a fake npm package named plain-crypto-js@4.2.1, designed to appear legitimate and similar to the real crypto-js library. They then modified Axios to import plain-crypto-js as a dependency.

When developers installed the compromised Axios version, npm automatically resolved and installed plain-crypto-js. The fake package contained a post-install script that executed before any other code ran, downloading and executing a Remote Access Trojan (RAT) payload.

Transitive dependencies are your largest unaudited attack surface. Security teams often audit direct dependencies carefully, but transitive dependencies are rarely inspected. The plain-crypto-js attack exploited this blind spot by combining typosquatting, automated execution, transitive insertion, and ephemeral distribution. The attack was attributed to Sapphire Sleet, a threat actor group known for supply chain targeting.

Vercel and Context.ai (February–April 2026)

The Vercel breach began not at Vercel, but at Context.ai, a small AI startup that provides AI-powered development tools. In February 2026, an employee at Context.ai was infected with Lumma Stealer, an infostealer malware that harvested credentials and OAuth tokens from the infected machine.

With access to Context.ai's OAuth tokens, the attacker could access Vercel's internal systems, retrieve OAuth tokens that Vercel customers had granted to Context.ai, exfiltrate environment variables containing deployment secrets, and access customer AWS and Google Workspace credentials.

The breach remained undetected for approximately two months. By the time Vercel discovered the compromise in April 2026, OAuth tokens from multiple customers had been stolen.

Why OAuth trust is a critical vulnerability

OAuth tokens are designed to delegate access without sharing passwords. If the application is compromised, the token is compromised. The token looks legitimate because it is legitimate. It's just being used by an attacker instead of the intended application. OAuth provides no mechanism to distinguish between authorized and unauthorized use of a valid token once it's been stolen.

What makes the Vercel incident significant is the speed of the attack chain. From initial infection at Context.ai to full compromise of Vercel customers took approximately two months, faster than many organizations' quarterly security review cycles. The attack demonstrates how a single compromised third-party application can weaponize trust relationships between platforms, turning OAuth delegation into a supply chain vector.

Historical context: Notable supply chain attacks (2017–2025)

Each incident shares a structural pattern: attackers found a trusted, automated delivery mechanism and inserted their payload where it would execute without scrutiny.

How to defend against supply chain attacks

Preventing supply chain attacks requires controls at every layer of the software delivery process.

Level 1: Dependency control

• Pin exact versions and verify checksums. Never use floating version ranges in production. Pin exact versions and validate checksums against a known-good state. This won't prevent a maintainer account compromise, but it eliminates automatic exposure to newly published malicious versions.
• Generate and maintain a software bill of materials (SBOM). An SBOM gives you a complete inventory of every component in your software, including transitive dependencies. When a vulnerability or malicious package is disclosed, you can immediately determine whether you're affected without manual auditing.
• Run continuous software composition analysis (SCA). SCA tools should run on every pull request and every dependency update, flagging new packages and their provenance, unusual preinstall hooks or post-install scripts, unexpected network calls in package scripts, and known malicious packages.

Level 2: Artifact integrity

• Enforce signed builds and provenance attestation. A signed artifact with a verifiable build chain is significantly harder to tamper with undetected. Use tools like Sigstore to sign and verify build artifacts.
• Verify package signatures at install time. npm, PyPI, and other registries support package signing. Verify signatures before installing dependencies.

Level 3: CI/CD infrastructure protection

• Apply zero-trust principles to CI/CD workflows. GitHub Actions workflows should operate with minimum permissions required: use ephemeral tokens scoped to individual jobs, not long-lived personal access tokens; pin third-party Actions to specific commit SHAs, not mutable tags; and use OIDC tokens instead of static credentials where possible.
• Rotate CI/CD secrets regularly and after every incident. Treat secrets in CI/CD environments as short-lived credentials. Any token, API key, or SSH key that could have been exposed should be rotated immediately.
• Monitor for anomalous exfiltration behavior. Allowlist expected outbound destinations for build environments and alert on deviations.

Level 4: Developer perimeter defense

• Audit AI coding tool configurations. The 2026 campaign explicitly targeted configuration files for Claude, Cursor, and Aider. Treat them as sensitive artifacts and include them in your secrets scanning scope.
• Audit OAuth applications and grants. Review which third-party applications have OAuth access to your GitHub, Vercel, and cloud accounts. Revoke access for applications no longer in use.
• Implement secrets scanning in your development environment. Scan developer workstations, local Git repositories, and IDE configurations for exposed credentials.

Centralized secrets management as the foundation

All of these controls depend on one critical principle: secrets must be stored securely, accessed with minimal privilege, and rotated rapidly.

Process controls fail without architectural constraints. A developer who needs to rotate a GitHub token shouldn't have to manually update it in five different .env files, three CI/CD platforms, and two deployment tools. That friction creates incentives to skip rotation or reuse tokens across environments.

Centralized secrets management solves this. A structured vault provides a single source of truth for all credentials, role-based access control so developers only access the secrets they need, audit logging of every access and modification, and rapid rotation of secrets across all systems that use them.

When a supply chain incident occurs and you need to rotate every GitHub token, npm token, and cloud credential that could have been exposed, a centralized vault makes this operationally feasible. Without it, rotation becomes a manual, error-prone scramble, and incomplete rotations leave attack vectors open.

Conclusion

Supply chain attacks work because they exploit the one thing organizations can't easily audit: the trust embedded in automated systems. Every dependency your pipeline pulls, every GitHub Action your workflow references, every plugin your IDE loads — each is a potential entry point.

The 2026 Bitwarden CLI, Axios, and Vercel campaigns make the threat concrete. A single compromised package, installed silently by a CI runner, can expose every secret in a developer's environment and propagate through every pipeline that token can reach. The attack doesn't announce itself. It executes as part of your normal build process.

Defending against this requires zero-trust architecture applied to the software supply chain: pinned dependencies, signed artifacts, SBOM tracking, continuous SCA, and short-lived scoped credentials. Secrets must be treated as perishable — rotated regularly, stored securely, and never embedded in code or environment files without governance.

Robust secrets management is a foundational control here. When credentials are stored in a structured, access-controlled vault like Passwork rather than scattered across .env files and developer workstations, the blast radius of a supply chain compromise shrinks significantly. Attackers can steal what they can reach. Make it nothing.

Ready to reduce your blast radius? Passwork gives your team a structured secrets vault with role-based access, full audit logging, and a self-hosted deployment that keeps credentials off third-party infrastructure. Teams migrating from a another password manager receive a 10% migration discount. Try Passwork free

FAQ: Supply chain attacks

What is a supply chain attack in cybersecurity?

A supply chain attack is a cyberattack that compromises a trusted third-party vendor, open-source package, or software component to gain access to downstream targets. Instead of attacking an organization directly, adversaries insert malicious payloads into software updates, build pipelines, or dependencies that the target installs automatically.

What is the Shai-Hulud worm?

Shai-Hulud is a worm campaign that compromised the Bitwarden CLI npm package in April 2026. It's called a worm because it self-propagates: after harvesting credentials, it injects malicious code into the victim's own npm packages and republishes them, spreading the infection to downstream users automatically. The name "Shai-Hulud: The Third Coming" indicates this was the third iteration of an ongoing, organized campaign.

Why are OAuth tokens a dangerous attack vector?

OAuth tokens are designed to delegate access without sharing passwords. If an application (like Context.ai) is compromised, the OAuth tokens it holds are compromised. The token looks legitimate because it is legitimate — it's just being used by an attacker instead of the intended application. The victim has no way to know their OAuth grant has been weaponized until the damage is discovered.

What is a transitive dependency?

A transitive dependency is a software component that your code relies on indirectly — a library imported by your direct dependencies, which in turn imports others. Transitive dependencies are rarely audited with the same rigor as first-party code, yet they execute in your environment with the same privileges. The Axios attack exploited this by injecting a fake transitive dependency (plain-crypto-js) that was automatically installed when developers installed the compromised Axios package.

How did the Bitwarden CLI supply chain attack work?

The malicious @bitwarden/cli@2026.4.0 package was published to npm on April 22, 2026, with a credential stealer embedded in bw1.js and executed via a preinstall hook. It harvested GitHub tokens, SSH keys, environment variables, cloud secrets, and AI coding tool configurations, then exfiltrated the data — encrypted with AES-256-GCM — to a domain impersonating Checkmarx.

What is the difference between a supply chain attack and a direct cyberattack?

A direct attack targets the victim's own systems — their network, credentials, or applications. A supply chain attack targets a trusted supplier or dependency instead, using that trust to bypass the victim's defenses. The victim installs or runs the compromised component voluntarily, through normal processes, which makes detection significantly harder.

What are transitive dependencies and why do they matter for security?

Transitive dependencies are software components that your code relies on indirectly — libraries imported by your direct dependencies, which in turn import others. They are rarely audited with the same rigor as first-party code, yet they execute in your environment with the same privileges. A compromise anywhere in that chain can affect your application.

What is an SBOM and how does it help prevent supply chain attacks?

A software bill of materials (SBOM) is a structured inventory of every component in a software product, including all direct and transitive dependencies. When a malicious package or vulnerability is disclosed, an SBOM lets security teams immediately determine whether their software is affected — without manually tracing dependency trees across every project.

What GitHub Actions security practices reduce supply chain risk?

Pin all third-party Actions to specific commit SHAs rather than mutable version tags. Use ephemeral, job-scoped tokens instead of long-lived personal access tokens. Restrict workflow permissions to the minimum required. Audit all workflow files for unexpected third-party references, and monitor CI runner egress traffic for anomalous outbound connections.

How should organizations respond if a compromised package was installed in their CI/CD pipeline?

Treat all secrets accessible during the affected build jobs as compromised. Rotate every token, API key, SSH key, and cloud credential that could have been exposed. Review GitHub Actions workflow files for unauthorized modifications. Audit repository access logs for unexpected commits or workflow runs. Report the incident per your regulatory obligations under GDPR, HIPAA, or applicable frameworks.

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

NIS2 latest news: What changed and what it means for EU businesses

84% of in-scope organizations admit they’re not ready. Belgium set the first conformity assessment deadline on April 18, 2026. The Netherlands is days away from enforcement. Here’s where the regulatory wave stands and what IT leaders need to act on now.

Passwork BlogAlex Muntyan

Password chaos: Why it’s a business problem and how to fix it

A forgotten password costs $70. A breach costs $4.44 million. Both start the same way — credentials shared over Slack, stored in spreadsheets, never rotated. Here’s what password chaos actually costs and how to eliminate it.

Passwork BlogAlex Muntyan

18. April 2026 — Belgiens erste NIS2-Durchsetzungsfrist. Wesentliche Einrichtungen waren verpflichtet, verifizierte Dokumentation einzureichen, die bestätigt, dass Cybersicherheitskontrollen implementiert sind — geprüft durch eine akkreditierte Stelle oder direkt durch das Centre for Cybersecurity Belgium. Selbsterklärungen wurden nicht akzeptiert.

22 von 27 Mitgliedstaaten haben die NIS2-Umsetzung abgeschlossen. Die Durchsetzung ist in Deutschland, Frankreich und den Niederlanden aktiv — Regulierungsbehörden führen Audits durch und verhängen Bußgelder.

Gleichzeitig sind 84 % der Organisationen, die einer aktiven Durchsetzung unterliegen, nach eigener Aussage nicht bereit — laut der CyberSmart-Umfrage vom April 2026 unter 670 betroffenen Führungskräften aus acht Ländern. Diese Zahl hat sich in sechs Monaten nicht wesentlich verändert.

Dieser Artikel behandelt den aktuellen Stand der Durchsetzung, was als Nächstes kommt und was IT- und Sicherheitsverantwortliche vor der nächsten Frist angehen müssen.

Wichtigste Erkenntnisse

• Belgien setzte die erste Frist. Am 18. April 2026 waren wesentliche Einrichtungen verpflichtet, verifizierte Selbstbewertungen über CyberFundamentals (CyFun), ISO/IEC 27001 oder direkte CCB-Inspektion einzureichen.
• Die Bereitschaft bleibt kritisch niedrig. Nur 16 % der Unternehmen fühlen sich vollständig vorbereitet, dennoch sehen 75 % die Compliance als Wettbewerbsvorteil. Die Lücke liegt in der Umsetzung: Budgetbeschränkungen, fehlende Implementierungsleitfäden und blinde Flecken in der Lieferkette sind die eigentlichen Hindernisse.
• Polen erweiterte den Geltungsbereich auf 42.000 Organisationen. Das geänderte KSC-Gesetz trat am 3. April 2026 in Kraft und umfasst nun auch Lebensmittelproduktion, Abfallwirtschaft und weitere Sektoren. Die offizielle Entitätenliste wurde am 13. April 2026 veröffentlicht.
• Lieferkettenrisiko ist die am schwierigsten zu schließende Lücke. Nur etwa 1 von 10 Unternehmen bewertete 2024 die Sicherheitslage ihrer Lieferanten angemessen (UK NCSC). NIS2 Artikel 21 verlangt dokumentierte Sicherheitsverpflichtungen gegenüber Dritten und kontinuierliche Überwachung.
• Die Vorstandshaftung ist persönlich. NIS2 Artikel 20 macht Leitungsorgane direkt verantwortlich für die Genehmigung von Cybersicherheitsmaßnahmen und die Absolvierung entsprechender Schulungen. In Deutschland drohen einzelnen Führungskräften Bußgelder von bis zu 500.000 € für Governance-Versäumnisse — zusätzlich zu organisatorischen Strafen.
• Das Vereinigte Königreich entwickelt ein strengeres Parallelregime — und multinationale Unternehmen müssen beides verfolgen. Das UK Cyber Security and Resilience Bill führt zweistufige Strafen ein (bis zu 17 Mio. £ oder 4 % des weltweiten Umsatzes bei schweren Verstößen), direkte MSP-Regulierung und eine breitere Definition von Vorfällen, die auch potenzielle Vorfälle erfasst — nicht nur bestätigte. Eine einzige NIS2-Compliance-Strategie reicht für grenzüberschreitende Geschäfte nicht aus.
• Die Kontrollen, die Auditoren zuerst prüfen, lassen sich auch am schnellsten implementieren. Zugriffsmanagement, Passwortrichtlinien und MFA sind in Artikel 21 explizit gefordert — und sie erzeugen den Audit-Trail, der sowohl Artikel 21 als auch die Vorstandsaufsichtspflichten nach Artikel 20 erfüllt.

Was ist NIS2 und wer ist betroffen

NIS2 (Richtlinie EU 2022/2555) ist der aktualisierte Rechtsrahmen der EU für Netz- und Informationssicherheit. Sie ersetzt die ursprüngliche NIS-Richtlinie und erweitert sowohl den Kreis der erfassten Einrichtungen als auch die Schwere der Verpflichtungen. Die Richtlinie gilt für mittlere und große Organisationen in 18 kritischen Sektoren.

Ihre Organisation fällt unter die NIS2-Richtlinie, wenn:

• Sie in einem in Anhang I oder Anhang II der Richtlinie aufgeführten Sektor tätig ist
• Sie den Größenschwellenwert erfüllt — mindestens 50 Beschäftigte oder ein Jahresumsatz und/oder eine Jahresbilanzsumme von mehr als 10 Millionen Euro (Anhang zur Empfehlung 2003/361/EG)
• Sie als kritische Einrichtung gemäß Richtlinie (EU) 2022/2557 (CER-Richtlinie) eingestuft ist, unabhängig von ihrer Größe

Sobald bestätigt ist, dass Ihre Organisation in den Geltungsbereich fällt, hängt die Einstufung als wesentliche oder wichtige Einrichtung von zwei Faktoren ab: dem Anhang, unter den Ihr Sektor fällt, und der Größe Ihrer Organisation.

Einige Organisationen fallen unabhängig von ihrer Größe unter NIS2:

• Ein Anbieter öffentlicher elektronischer Kommunikationsnetze oder öffentlich zugänglicher elektronischer Kommunikationsdienste
• Ein Vertrauensdiensteanbieter
• Eine Top-Level-Domain-(TLD)-Namenregistrierungsstelle oder ein DNS-Dienstanbieter
• Der einzige Anbieter eines Dienstes in einem Mitgliedstaat, der für die Aufrechterhaltung kritischer gesellschaftlicher oder wirtschaftlicher Aktivitäten unerlässlich ist
• Eine Einrichtung, deren Störung erhebliche Auswirkungen auf die öffentliche Sicherheit, die öffentliche Ordnung oder die öffentliche Gesundheit haben könnte
• Eine Einrichtung, deren Störung ein erhebliches systemisches Risiko auslösen könnte, insbesondere in Sektoren, in denen eine solche Störung grenzüberschreitende Auswirkungen haben könnte

Wenn Ihre Organisation Teil eines größeren Konzerns ist, müssen Beschäftigtenzahl und Finanzkennzahlen über alle verbundenen Unternehmen aggregiert werden — eine Tochtergesellschaft mit 40 Beschäftigten kann dennoch in den Geltungsbereich fallen, wenn der Mutterkonzern die Schwellenwerte überschreitet.

Stand März 2026 haben 22 von 27 EU-Mitgliedstaaten nationale Umsetzungsgesetze verabschiedet. Frankreich, Irland, Luxemburg, die Niederlande und Spanien befinden sich noch im Gesetzgebungsverfahren, gemäß der Analyse von Skadden vom März 2026.

Hauptthema: Belgiens Frist am 18. April

Am 18. April 2026 lief in Belgien die NIS2-Konformitätsbewertungsfrist ab. Wesentliche Einrichtungen waren verpflichtet, die aktive Umsetzung von Cybersicherheits-Risikomanagementmaßnahmen nachzuweisen und entsprechende Belege beim Centre for Cybersecurity Belgium (CCB) einzureichen — über einen von drei anerkannten Compliance-Wegen:

• CyberFundamentals (CyFun®): Mindestens eine Basic- oder Important-Verifizierung erlangen oder eine unterschriebene Vereinbarung mit einer akkreditierten Bewertungsstelle vorlegen.
• ISO/IEC 27001: Den Zertifizierungsumfang, die Erklärung zur Anwendbarkeit (SoA) und den jüngsten internen Auditbericht einreichen. Die vollständige Zertifizierung muss bis April 2027 abgeschlossen sein.
• Direkte Inspektion: Eine Selbstbewertung mit unterstützender Dokumentation vorlegen und formell eine CCB-Inspektion beantragen — ein Weg, der direkt zu Aufsichtsmaßnahmen führen kann.

Reine Selbstbescheinigungen werden nicht akzeptiert. Das Versäumnis, vollständige und fristgerechte Dokumentation einzureichen, kann zu Verwaltungsmaßnahmen, finanziellen Sanktionen und weiteren Aufsichtsmaßnahmen führen.

Das von Belgien etablierte Muster (formelle Drittbewertung, dokumentierte Nachweise, Unterzeichnung durch die Geschäftsleitung, persönliche Haftung) ist die Vorlage, der der Rest der EU folgt.

Die NIS2-Bereitschaftslücke: 84 % der Unternehmen sind nicht bereit

16 % der europäischen Unternehmen, die NIS2 einhalten müssen, fühlen sich vollständig vorbereitet, während 11 % der betroffenen Organisationen sich noch unsicher sind, was NIS2 überhaupt ist. Diese Zahlen stammen aus der CyberSmart-Umfrage unter 670 Führungskräften aus dem Vereinigten Königreich, Polen, den Niederlanden, Irland, Frankreich, Deutschland, Italien, Dänemark und Belgien, durchgeführt Ende 2025 — alle aus Organisationen, die in den NIS2-Geltungsbereich fallen.

Das Problem ist die Umsetzung

Die naheliegende Annahme, dass Unternehmen NIS2 einfach nicht ernst nehmen, hält einer Prüfung nicht stand. 75 % der Befragten sehen zumindest einen gewissen Wettbewerbsvorteil in der Compliance, und 27 % betrachten diesen Vorteil als erheblich. Die größten Bedenken hinsichtlich Nicht-Compliance waren operativer und reputationsbezogener Natur.

Nur 3 % der Befragten gaben an, keinerlei Bedenken hinsichtlich der Folgen einer Nicht-Compliance zu haben.

Warum Organisationen scheitern

Auf die Frage, warum sie noch nicht vollständig compliant seien, gaben die Befragten in allen untersuchten Regionen konsistente Antworten. Die Hindernisse sind praktischer Natur:

Budget ist das größte Hindernis, signalisiert aber etwas Tieferliegendes. Für einen Teil der Organisationen wird NIS2-Compliance immer noch nicht als unverzichtbarer Budgetposten behandelt. Die Lücke bei den Leitfäden ist ebenso aufschlussreich: 16 % fehlt die Implementierungsanleitung und 11 % sind unsicher, was NIS2 von ihnen verlangt — obwohl sie gesetzlich zur Compliance verpflichtet sind.

Das Lieferkettenrisiko verschärft die Herausforderung. Nur etwa 1 von 10 Unternehmen bewertete 2024 die Sicherheitsmaßnahmen ihrer Lieferanten angemessen, laut NCSC des Vereinigten Königreichs — und 10 % der Umfrageteilnehmer nannten die Unfähigkeit, ihre gesamte Lieferkette zu bewerten, als Hauptgrund für Nicht-Compliance.

Was Organisationen tatsächlich tun

Das Bild zeigt einen teilweisen Fortschritt. Gängige Sicherheitsprotokolle (Schulungen, Verschlüsselung, Risikobewertungen) werden angewandt, oft unabhängig von NIS2. Die anspruchsvolleren Anforderungen (Lieferkettenbewertung, formelle Gap-Analyse, MFA-Durchsetzung) hinken deutlich hinterher.

MFA-Durchsetzung und Zugangskontrolle gehören zu den am wenigsten umgesetzten NIS2-Maßnahmen — dennoch sind sie das Erste, was Auditoren prüfen. Erfahren Sie, wie Passwork die Zugangsdaten-Governance handhabt

Regulierungsmüdigkeit ist real

Organisationen, die in der EU tätig sind, können gleichzeitig Verpflichtungen unter NIS2, DSGVO, DORA, dem EU Cybersecurity Act und ISO 27001 unterliegen. Diese Rahmenwerke überschneiden sich erheblich, doch die Navigation erfordert Zeit, Expertise und Ressourcen, die die meisten Organisationen intern nicht haben.

42 % der Befragten sagen, es gebe zu viele Vorschriften, 35 % sagen, sie überschneiden sich zu stark, und 27 % sind der Meinung, dass ihnen zu viel Gewicht beigemessen wird.

Compliance ist jetzt eine geschäftliche Anforderung

Nicht nur Regulierungsbehörden fordern Nachweise. Der Marktdruck kommt von allen Seiten:

• 42 % wurden von Partnern aufgefordert, NIS2-Compliance nachzuweisen
• 41 % wurden von Investoren dazu aufgefordert
• 36 % wurden von Kunden oder Interessenten dazu aufgefordert

NIS2 ist noch ein relativ neuer Standard. Je mehr Organisationen ihn in die Lieferanten- und Partner-Due-Diligence einbetten, desto mehr wird der Compliance-Nachweis von außergewöhnlich zu routinemäßig. In vielen Sektoren ist er bereits eine Geschäftsbedingung.

Regionale Highlights

Die Umfrage zeigt bedeutende Unterschiede zwischen den Märkten:

• Polen zeichnet sich durch die stärkste Compliance-Kultur aus: Kein einziger polnischer Befragter gab an, 5 % oder weniger seines IT-Budgets für Sicherheit auszugeben. In der Mehrheit der polnischen Organisationen ist der Vorstand oder die Geschäftsleitung für Compliance verantwortlich.
• Benelux zeigt eine Diskrepanz: CEOs sind am häufigsten verantwortlich (43 %), dennoch geben 10 % der Unternehmen zu wenig für Sicherheit aus — der höchste Wert in der Umfrage gemeinsam mit anderen Regionen.
• Deutschland, Frankreich und Italien zeigen die höchste Regulierungsmüdigkeit: 44 % sagen, es gebe zu viele Vorschriften, 39 % sagen, sie überschneiden sich zu stark.
• Dänemark verzeichnet die höchste regulatorische Skepsis: 34 % sehen keinen Wettbewerbsvorteil in der Compliance, und 55 % sagen, es gebe zu viele Vorschriften — der höchste Wert in allen untersuchten Regionen.
• Vereinigtes Königreich und Irland zeigen Investorendruck als besonders starken Treiber: 58 % der Unternehmen in der Region wurden von Investoren aufgefordert, NIS2-Compliance nachzuweisen, verglichen mit 41 % in allen Regionen.

Die regulatorische Divergenz zwischen EU und UK: Was multinationale Unternehmen wissen müssen

Für Organisationen, die sowohl in der EU als auch im Vereinigten Königreich tätig sind, ist NIS2-Compliance nur ein Teil des Bildes. Das Vereinigte Königreich entwickelt seinen eigenen Cyber Security and Resilience Bill — der im Januar 2026 seine zweite Lesung passierte und sich seit Februar im Ausschussstadium befindet — und schlägt wesentliche Änderungen der NIS Regulations 2018 vor.

Die beiden Rahmenwerke teilen gemeinsame Ziele, unterscheiden sich aber in Punkten, die eine einheitliche Compliance-Strategie unzureichend machen.

Wesentliche Unterschiede zwischen NIS2 und dem UK Bill

Zweistufige Strafen — strenger als NIS2

Der UK Bill führt eine zweistufige Strafstruktur ein: ein Standardmaximum von 10 Mio. £ oder 2 % des weltweiten Umsatzes für weniger schwere Verstöße und ein höheres Maximum von 17 Mio. £ oder 4 % des weltweiten Umsatzes für schwere Verstöße — einschließlich Sicherheitsverletzungen und Meldeversäumnissen.

Regulierungsbehörden können zusätzlich tägliche Bußgelder von bis zu 100.000 £ für andauernde Nicht-Compliance verhängen. Dies übertrifft die einstufige Struktur von NIS2.

Direkte MSP-Regulierung: Schließung einer Lücke, die NIS2 offen ließ

Der Bill reguliert Managed Service Provider direkt — eine Lücke in NIS2, die das Vereinigte Königreich explizit adressiert. Schätzungsweise 900 bis 1.100 MSPs werden als Relevant Managed Service Providers (RMSPs) unter direkte ICO-Aufsicht gestellt, mit dem vollen Spektrum an Verpflichtungen einschließlich obligatorischer Registrierung, definierter Sicherheitsstandards und Vorfallmeldung innerhalb vorgeschriebener Fristen.

Organisationen, die externe IT-Anbieter nutzen, sollten diese Anbieter fragen, wie sie sich vorbereiten.

Breitere Vorfalldefinition

Die aktuellen NIS Regulations definieren einen Vorfall als jedes Ereignis mit einer tatsächlichen nachteiligen Auswirkung auf die Sicherheit. Der Bill erweitert dies, um jedes Ereignis zu erfassen, das eine nachteilige Auswirkung hat oder haben könnte — was bedeutet, dass Organisationen potenzielle Vorfälle bewerten und darauf reagieren müssen, nicht nur bestätigte. Dies wird das Volumen meldepflichtiger Ereignisse wesentlich erhöhen.

Die Bedrohungslandschaft im Vereinigten Königreich

Die regulatorische Verschärfung spiegelt ein echtes Risikobild wider. Cyberangriffe kosten britische Unternehmen schätzungsweise 14,7 Milliarden £ jährlich — etwa 0,5 % des BIP — basierend auf unabhängiger Forschung, die von der britischen Regierung in Auftrag gegeben wurde. Die durchschnittlichen Kosten eines erheblichen Cyberangriffs für ein einzelnes Unternehmen liegen bei fast 195.000 £.

Regulatorische Fragmentierung in den EU-Mitgliedstaaten

Die Divergenz besteht nicht nur zwischen der EU und dem Vereinigten Königreich. Trotz der Umsetzungsfrist im Oktober 2024 bleibt die NIS2-Implementierung in den 27 Mitgliedstaaten stark fragmentiert. Österreichs NISG 2026, Polens KSC-Gesetz und das niederländische Cyberbeveiligingswet führen jeweils nationale Variationen bei Strafen, Durchsetzungsverfahren und sektorspezifischen Anforderungen ein — was unverhältnismäßige Compliance-Kosten für grenzüberschreitend tätige Organisationen verursacht.

Polen: KSC-Gesetz in Kraft, Entitätenliste veröffentlicht

Polens geändertes Gesetz über das nationale Cybersicherheitssystem (KSC) trat am 3. April 2026 in Kraft. Die offizielle Liste der wesentlichen und wichtigen Einrichtungen wurde am 13. April 2026 veröffentlicht.

Das Ausmaß der Änderung ist erheblich. Der vorherige KSC-Rahmen umfasste etwa 400 Einrichtungen. Das geänderte Gesetz bringt schätzungsweise 42.000 Organisationen in den Geltungsbereich — darunter fast 28.000 öffentliche Einrichtungen.

Neue Sektoren nun abgedeckt

Fünf Sektoren werden erstmals vom polnischen Cybersicherheitsrecht erfasst:

Polen erweiterte auch mehrere bestehende Sektoren über die NIS2-Basis hinaus — Energie umfasst nun den Kohlebergbau; Banken und Finanzmarktinfrastruktur erhielten zusätzliche Einrichtungstypen. Die Klassifizierung ist nicht immer offensichtlich: Organisationen in neu abgedeckten Sektoren sollten eine vorläufige Selbstbewertung durchführen, bevor sie davon ausgehen, außerhalb des Geltungsbereichs zu liegen.

Wichtige Compliance-Fristen

Die Registrierung erfolgt nicht automatisch — die meisten Organisationen müssen sich selbst bewerten und innerhalb von 6 Monaten nach Erfüllung der Kriterien einen Antrag stellen. Die Nichtregistrierung befreit eine Organisation nicht von ihren Verpflichtungen; sie fügt einen Verstoß hinzu.

Niederlande: Das Cyberbeveiligingswet steht kurz vor dem Inkrafttreten

Das niederländische Cyberbeveiligingswet (Cbw) — die niederländische Umsetzung von NIS2 — passierte am 15. April 2026 das Repräsentantenhaus und soll voraussichtlich im Q2 2026 in Kraft treten.

Das Gesetz führt vier Kernverpflichtungen für alle betroffenen Organisationen ein:

• 10 verpflichtende Sorgfaltspflichtmaßnahmen — Risikoanalyse, Zugriffsmanagement, MFA, Incident Response, Lieferkettensicherheit, Verschlüsselung und vier weitere. Eine ISO 27001-Zertifizierung hilft, stellt aber allein keine vollständige Compliance dar.
• Dreistufige Vorfallmeldung — Frühwarnung innerhalb von 24 Stunden, Folgemeldung innerhalb von 72 Stunden, Abschlussbericht innerhalb von 30 Tagen, alle über das NCSC-Portal eingereicht.
• Persönliche Vorstandshaftung — Leitungsorgane müssen Cybersicherheitsmaßnahmen formell genehmigen, die Umsetzung überwachen und Cybersicherheitsschulungen absolvieren. Die vollständige Delegation an die IT ohne aktive Aufsicht schafft direkte persönliche Haftung.

Bußgelder erreichen bis zu 10 Mio. € oder 2 % des weltweiten Umsatzes für wesentliche Einrichtungen und 7 Mio. € oder 1,4 % für wichtige Einrichtungen.

Die meisten Organisationen benötigen vier bis sechs Monate, um das erforderliche Compliance-Niveau zu erreichen. Wer noch keine Gap-Analyse gestartet hat, dem läuft die Zeit davon.

Vorstandshaftung: Artikel 20 macht es persönlich

NIS2 Artikel 20 macht Leitungsorgane direkt und persönlich verantwortlich für die Cybersicherheits-Governance. Drei Haftungsebenen gelten:

• Genehmigungshaftung. Leitungsorgane müssen Cybersicherheits-Risikomanagementmaßnahmen formell genehmigen. Wenn sich diese Maßnahmen als unzureichend erweisen und zu einem Vorfall führen, werden die Genehmigungsentscheidung und die Personen, die sie getroffen haben, von Regulierungsbehörden geprüft.
• Schulungshaftung. Artikel 20(2) verlangt, dass Führungskräfte Cybersicherheitsschulungen absolvieren, die ausreichen, um Risiken zu erkennen und Risikomanagementpraktiken zu bewerten. Unkenntnis technischer Details ist keine vertretbare Position mehr.
• Aufsichtshaftung. Die vollständige Delegation an die IT oder einen externen MSSP ohne Aufrechterhaltung der Governance-Aufsicht schafft direkte persönliche Haftung. In Deutschland drohen einzelnen Führungskräften Bußgelder von bis zu 500.000 € für Governance-Versäumnisse — getrennt von organisatorischen Strafen. Geschäftsführer können auch vorübergehend von Führungspositionen ausgeschlossen werden bei grober Fahrlässigkeit.

Die Analyse von KPMG Law vom April 2026 zur deutschen Umsetzung bestätigt, dass dies keine Theorie ist. MSI Global Alliance formuliert den Wandel klar: Cybersicherheit steht jetzt auf derselben Governance-Ebene wie die Finanzberichterstattung. Geschäftsführer sind für die Cybersicherheitslage ihrer Organisation verantwortlich, mit Verpflichtungen einschließlich dokumentierter Risikomanagementrichtlinien und nachweisbarer Überwachung von Dritten.

Wie Passwork die NIS2-Compliance unterstützt

Der schnellste Weg, die häufigsten NIS2-Lücken zu schließen, besteht darin, den Zugriff unter Kontrolle zu bringen. Artikel 21 der Richtlinie verlangt ausdrücklich, dass Organisationen Zugriffsmanagementrichtlinien implementieren, starke Authentifizierung durchsetzen und dokumentierte Audit-Trails führen. Dies sind auch die Kontrollen, die Regulierungsbehörden zuerst prüfen — und diejenigen, die die meisten Organisationen immer noch manuell oder uneinheitlich handhaben.

Ein Passwort-Manager adressiert dies direkt. Er zentralisiert die Speicherung von Zugangsdaten, setzt rollenbasierte Zugriffsrichtlinien durch und erstellt einen verifizierbaren Nachweis darüber, wer wann auf was zugegriffen hat — die Art von Belegen, die Auditoren erwarten.

Zugriffsmanagement und Audit-Trails

Passwork bietet strukturierte, rollenbasierte Zugriffskontrolle für alle gemeinsam genutzten Zugangsdaten. Administratoren vergeben Berechtigungen auf Tresor-, Ordner- und individueller Passwortebene. Jedes Zugriffsereignis — Anzeigen, Kopieren, Bearbeiten, Teilen, Löschen — wird mit Zeitstempel und Benutzeridentität protokolliert.

Dieser Audit-Trail ist direkt relevant für NIS2 Artikel 21(2)(i), der von Organisationen verlangt, „Richtlinien und Verfahren für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung" zu implementieren und Zugriffskontrollen über sensible Systeme aufrechtzuerhalten. Wenn eine Regulierungsbehörde nach Belegen für die Zugriffs-Governance fragt, ist ein vollständiges, durchsuchbares Protokoll die Antwort.

Kontinuierliche Überwachung

NIS2 erfordert eine fortlaufende Sicherheitsüberwachung. Passwork unterstützt dies durch einen Echtzeit-Aktivitätsfeed und konfigurierbare Benachrichtigungen für jedes Zugangsdaten-Ereignis: ein Passwort, das von einem unerwarteten Benutzer angezeigt wurde, ein gemeinsamer Tresor, auf den außerhalb der Arbeitszeiten zugegriffen wurde, ein privilegiertes Konto, das ohne Change-Ticket geändert wurde.

Das Passwort-Sicherheits-Dashboard kennzeichnet schwache, wiederverwendete, veraltete und potenziell kompromittierte Zugangsdaten in der gesamten Organisation — und gibt Sicherheitsteams kontinuierliche Transparenz ohne manuelle Audits.

ISO 27001-zertifiziert und kontinuierlich getestet

Passwork besitzt eine ISO/IEC 27001-Zertifizierung — derselbe Standard, den Belgien als NIS2-Compliance-Weg unter seinem CyFun-Rahmenwerk akzeptiert. Die Zertifizierung bestätigt einen systematischen, auditierbaren Ansatz für das Informationssicherheitsmanagement.

Für Organisationen, die ihre Sicherheitslage gegenüber Regulierungsbehörden, Partnern oder Kunden nachweisen müssen, bietet die ISO 27001-Zertifizierung von Passwork unabhängig verifizierbare Belege.

Self-hosted Bereitstellung

Passwork wird vollständig in Ihrer eigenen Infrastruktur bereitgestellt. Alle Daten werden mit AES-256 verschlüsselt und verlassen niemals Ihre Server. Es gibt keine Abhängigkeit von Cloud-Diensten Dritter — was sowohl für die NIS2-Compliance als auch für die Lieferkettenrisikobestimmungen relevant ist, die von Organisationen verlangen, die Sicherheit ihrer Dienstleister zu bewerten.

Der Quellcode ist auditierbar. Ihr Sicherheitsteam kann vor der Bereitstellung überprüfen, dass keine versteckten Schwachstellen vorhanden sind.

Passwork bietet Ihrem Team strukturierte Zugriffskontrolle, ein vollständiges Audit-Protokoll und kontinuierliche Überwachung der Zugangsdaten — alles innerhalb Ihrer eigenen Infrastruktur. Erfahren Sie, wie Passwork die NIS2-Compliance unterstützt

Compliance-Kalender

Die folgende Tabelle zeigt die wichtigsten Compliance-Ereignisse in chronologischer Reihenfolge. Unsichere oder geschätzte Daten sind entsprechend gekennzeichnet.

Fazit

Belgiens Frist am 18. April ist verstrichen. Es wird nicht die letzte sein. Regulierungsbehörden in 27 Mitgliedstaaten wechseln von Leitlinien zu Audits, und die Bereitschaftsquote von 16 % bedeutet, dass die große Mehrheit der betroffenen Organisationen genau jetzt exponiert ist.

Das Muster ist bei jeder frühen Durchsetzungsmaßnahme konsistent: Die Kontrollen, die Regulierungsbehörden zuerst prüfen, sind Zugriffsmanagement, Governance privilegierter Zugangsdaten und Audit-Trails. Dies sind nicht die schwierigsten Anforderungen in NIS2 — sie sind die konkretesten, die am besten dokumentierbaren und die am unmittelbarsten umsetzbaren.

Den Zugriff unter Kontrolle zu bringen, ist der schnellste Weg, die am besten auditierbaren Compliance-Lücken zu schließen. Es erfüllt die Anforderungen von Artikel 21 direkt, unterstützt die Lieferkettenüberwachung und erzeugt den Nachweis-Trail, den die Vorstandshaftung nach Artikel 20 verlangt. Ein Passwort-Manager mit rollenbasiertem Zugriff, einem vollständigen Audit-Protokoll und kontinuierlicher Überwachung adressiert alle drei Punkte.

Passwork ist ISO/IEC 27001-zertifiziert und wird vollständig in Ihrer eigenen Infrastruktur bereitgestellt. Die Lösung wurde genau für die Art von Zugriffs-Governance entwickelt, nach der NIS2-Auditoren suchen.

Passwork ist ein selbst gehosteter Passwort-Manager für Unternehmen. Er setzt rollenbasierte Zugriffsrichtlinien durch, führt ein vollständiges Audit-Protokoll aller Zugangsdaten-Aktivitäten und wird vollständig in Ihrer eigenen Infrastruktur bereitgestellt. Testen Sie Passwork in Ihrer Infrastruktur

Häufig gestellte Fragen

Was ist die NIS2-Richtlinie und für wen gilt sie?

NIS2 (Richtlinie EU 2022/2555) ist der Rechtsrahmen der EU für Netz- und Informationssicherheit und ersetzt die ursprüngliche NIS-Richtlinie von 2016. Sie gilt für mittlere und große Organisationen in 18 kritischen Sektoren — einschließlich Energie, Gesundheitswesen, Finanzwesen, Verkehr, digitale Infrastruktur und Fertigung — mit mindestens 50 Beschäftigten oder 10 Millionen Euro Jahresumsatz oder Bilanzsumme.

Was sind die wichtigsten Cybersicherheitsverpflichtungen unter NIS2?

NIS2 Artikel 21 verlangt von Organisationen die Umsetzung von Risikoanalyse, Incident Response, Geschäftskontinuitätsmaßnahmen, Lieferkettensicherheit, Zugriffsrichtlinien, MFA, Verschlüsselung und Schwachstellenmanagement. Diese Maßnahmen müssen vom Leitungsorgan gemäß Artikel 20 formell genehmigt werden, mit dokumentierten Nachweisen der Umsetzung für behördliche Prüfungen.

Welche Bußgelder drohen Organisationen bei NIS2-Nicht-Compliance?

Wesentlichen Einrichtungen drohen Bußgelder von bis zu 10 Millionen € oder 2 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Wichtigen Einrichtungen drohen bis zu 7 Millionen € oder 1,4 % des weltweiten Umsatzes. Mehrere Mitgliedstaaten überschreiten diese Mindestgrenzen — Deutschland erlaubt Bußgelder von bis zu 20 Millionen € für wesentliche Einrichtungen sowie individuelle Bußgelder von bis zu 500.000 € für Führungskräfte bei Governance-Versäumnissen.

Was verlangt NIS2 für Zugriffsmanagement und Zugangsdatensicherheit?

Artikel 21(2)(i) verlangt Richtlinien für Zugriffskontrolle, Authentifizierung und den Einsatz von Kryptografie. In der Praxis bedeutet dies rollenbasierten Zugriff auf kritische Systeme, durchgesetzte MFA, dokumentierte Zugangsdatenrichtlinien und einen vollständigen Audit-Trail privilegierter Zugriffsereignisse. Gemeinsam genutzte Passwörter, nicht verwaltete Dienstkonten und undokumentierte Zugriffspfade sind direkte Compliance-Verstöße unter diesem Artikel.

Wie adressiert NIS2 die Lieferkettensicherheit?

Artikel 21(2)(d) verlangt von Organisationen, die Cybersicherheitslage ihrer direkten Lieferanten und Dienstleister zu bewerten und zu managen. Dies umfasst die Abbildung kritischer Abhängigkeiten von Dritten, die Verankerung von Sicherheitsverpflichtungen in Verträgen und die kontinuierliche Überwachung der Lieferantenlage. Nur etwa 1 von 10 Unternehmen bewertete 2024 die Sicherheitsmaßnahmen ihrer Lieferanten angemessen, laut UK NCSC.

Was sind die NIS2-Vorfallmeldefristen?

NIS2 schreibt einen dreistufigen Prozess vor: eine 24-Stunden-Frühwarnung an die nationale Behörde nach Erkennung eines erheblichen Vorfalls, eine 72-Stunden-Detailmeldung mit einer ersten Auswirkungsbewertung und einen 30-Tage-Abschlussbericht mit Ursachenanalyse und Behebungsschritten. Diese Fristen gelten sowohl für wesentliche als auch für wichtige Einrichtungen und erfordern vorab getestete, automatisierte Reaktionsworkflows, um sie zuverlässig einzuhalten.

Welche persönliche Haftung tragen Führungskräfte unter NIS2?

Artikel 20 macht Leitungsorgane direkt verantwortlich für die Genehmigung von Cybersicherheits-Risikomanagementmaßnahmen, die Überwachung ihrer Umsetzung und die Absolvierung von Cybersicherheitsschulungen. Führungskräfte können persönlich für Governance-Versäumnisse haftbar gemacht werden. In Deutschland drohen einzelnen Führungskräften Bußgelder von bis zu 500.000 € unter dem nationalen NIS2-Umsetzungsgesetz, und Geschäftsführer können bei grober Fahrlässigkeit vorübergehend von Führungspositionen ausgeschlossen werden.

Erfüllt eine ISO 27001-Zertifizierung die NIS2-Anforderungen?

Eine ISO 27001-Zertifizierung wird in einigen Mitgliedstaaten als Compliance-Weg anerkannt — Belgien akzeptiert sie als Nachweis der NIS2-Konformität, sofern Organisationen den Zertifizierungsumfang, die Erklärung zur Anwendbarkeit und den jüngsten internen Auditbericht einreichen. Eine Zertifizierung allein stellt jedoch in den meisten Rechtsordnungen keine vollständige NIS2-Compliance dar. Sie reduziert die Compliance-Lücke erheblich und bietet Auditoren eine anerkannte Nachweisbasis, doch Organisationen müssen weiterhin die Umsetzung aller Artikel-21-Maßnahmen nachweisen.

18 de abril de 2026 — Primer plazo de aplicación de NIS2 en Bélgica. Las entidades esenciales debían presentar documentación verificada que confirmara la implementación de controles de ciberseguridad, evaluados por un organismo acreditado o directamente por el Centre for Cybersecurity Belgium. No se aceptaron autodeclaraciones.

22 de los 27 estados miembros han completado la transposición de NIS2. La aplicación está activa en Alemania, Francia y los Países Bajos — los reguladores están realizando auditorías y aplicando sanciones.

Mientras tanto, el 84% de las organizaciones que enfrentan aplicación activa no están preparadas, según su propia admisión — de acuerdo con la encuesta de CyberSmart de abril de 2026 a 670 líderes empresariales dentro del alcance en ocho países. Esa cifra no ha variado significativamente en seis meses.

Este artículo cubre el estado actual de la aplicación, lo que viene a continuación y lo que los líderes de TI y seguridad deben abordar antes de que llegue el próximo plazo.

Conclusiones clave

• Bélgica estableció el primer plazo. El 18 de abril de 2026, las entidades esenciales debían presentar autoevaluaciones verificadas a través de CyberFundamentals (CyFun), ISO/IEC 27001 o inspección directa del CCB.
• La preparación sigue siendo críticamente baja. Solo el 16% de las empresas se sienten completamente preparadas, aunque el 75% ve el cumplimiento como una ventaja competitiva. El problema está en la ejecución: las restricciones presupuestarias, la falta de orientación para la implementación y los puntos ciegos en la cadena de suministro son los verdaderos obstáculos.
• Polonia amplió el alcance a 42.000 organizaciones. La Ley KSC modificada entró en vigor el 3 de abril de 2026, añadiendo producción de alimentos, gestión de residuos y otros sectores. La lista oficial de entidades se publicó el 13 de abril de 2026.
• El riesgo de la cadena de suministro es la brecha más difícil de cerrar. Solo alrededor de 1 de cada 10 empresas evaluaba adecuadamente la postura de seguridad de sus proveedores en 2024 (UK NCSC). El Artículo 21 de NIS2 requiere obligaciones de seguridad documentadas para terceros y monitoreo continuo.
• La responsabilidad de la dirección es personal. El Artículo 20 de NIS2 hace que los órganos de dirección sean directamente responsables de aprobar las medidas de ciberseguridad y completar la formación pertinente. En Alemania, los directivos individuales enfrentan multas de hasta 500.000 € por fallos de gobernanza — independientes de las sanciones organizacionales.
• El Reino Unido está construyendo un régimen paralelo más estricto — y las multinacionales deben seguir ambos. El UK Cyber Security and Resilience Bill introduce sanciones de dos niveles (hasta 17 millones de libras o el 4% de la facturación global por fallos graves), regulación directa de MSP y una definición de incidente más amplia que captura incidentes potenciales — no solo los confirmados. Una única estrategia de cumplimiento de NIS2 no es suficiente para operaciones transfronterizas.
• Los controles que los auditores examinan primero son también los más rápidos de implementar. La gestión de accesos, las políticas de credenciales y MFA están explícitamente requeridos en el Artículo 21 — y generan la pista de auditoría que satisface tanto los requisitos de supervisión del Artículo 21 como del Artículo 20.

Qué es NIS2 y a quién cubre

NIS2 (Directiva UE 2022/2555) es el marco legal actualizado de la UE para la seguridad de redes e información. Reemplaza la Directiva NIS original y amplía tanto el alcance de las entidades cubiertas como la severidad de las obligaciones. La directiva se aplica a organizaciones medianas y grandes en 18 sectores críticos.

Su organización está cubierta por la directiva NIS2 si:

• Opera en un sector listado en el Anexo I o Anexo II de la directiva
• Cumple con el umbral de tamaño — al menos 50 empleados, o una facturación anual y/o balance total anual que supere los 10 millones de euros (Anexo de la Recomendación 2003/361/CE)
• Está identificada como entidad crítica bajo la Directiva (UE) 2022/2557 (Directiva CER), independientemente de su tamaño

Una vez confirmado que su organización está dentro del alcance, su clasificación como entidad esencial o importante depende de dos factores: el anexo en el que se encuentra su sector y el tamaño de su organización.

Algunas organizaciones están dentro del alcance de NIS2 independientemente de su tamaño:

• Un proveedor de redes públicas de comunicaciones electrónicas o servicios de comunicaciones electrónicas disponibles públicamente
• Un proveedor de servicios de confianza
• Un registro de nombres de dominio de nivel superior (TLD) o proveedor de servicios DNS
• El único proveedor de un servicio en un Estado miembro que es esencial para el mantenimiento de actividades sociales o económicas críticas
• Una entidad cuya interrupción podría tener un impacto significativo en la seguridad pública, la seguridad ciudadana o la salud pública
• Una entidad cuya interrupción podría inducir un riesgo sistémico significativo, en particular para sectores donde dicha interrupción podría tener un impacto transfronterizo

Si su organización pertenece a un grupo corporativo más grande, el número de empleados y las cifras financieras deben agregarse entre las entidades vinculadas — una filial con 40 empleados puede estar dentro del alcance si el grupo matriz supera los umbrales.

A marzo de 2026, 22 de los 27 estados miembros de la UE han adoptado legislación nacional de implementación. Francia, Irlanda, Luxemburgo, los Países Bajos y España permanecen en proceso legislativo, según el análisis de Skadden de marzo de 2026.

Noticia principal: Plazo del 18 de abril en Bélgica

El 18 de abril de 2026, Bélgica alcanzó el plazo de evaluación de conformidad de NIS2. Las entidades esenciales debían demostrar la implementación activa de medidas de gestión de riesgos de ciberseguridad y presentar evidencia de respaldo al Centre for Cybersecurity Belgium (CCB) — a través de una de las tres vías de cumplimiento reconocidas:

• CyberFundamentals (CyFun®): Obtener al menos una verificación de nivel Basic o Important, o contar con un acuerdo firmado con un organismo de evaluación acreditado.
• ISO/IEC 27001: Presentar el alcance de la certificación, la Declaración de Aplicabilidad (SoA) y el informe de auditoría interna más reciente. La certificación completa debe completarse antes de abril de 2027.
• Inspección directa: Proporcionar una autoevaluación con documentación de respaldo y solicitar formalmente una inspección del CCB — una vía que puede conducir directamente a medidas de supervisión.

La autoatestación por sí sola no se acepta. No presentar documentación completa y oportuna puede resultar en medidas administrativas, sanciones financieras y acciones de supervisión adicionales.

El patrón que Bélgica ha establecido (evaluación formal por terceros, evidencia documentada, aprobación de la dirección, responsabilidad personal) es la plantilla que sigue el resto de la UE.

La brecha de preparación de NIS2: El 84% de las empresas no están preparadas

El 16% de las empresas europeas obligadas a cumplir con NIS2 se sienten completamente preparadas, mientras que el 11% de las organizaciones dentro del alcance todavía no están seguras de qué es NIS2. Estas cifras provienen de la encuesta de CyberSmart a 670 líderes empresariales del Reino Unido, Polonia, los Países Bajos, Irlanda, Francia, Alemania, Italia, Dinamarca y Bélgica, realizada a finales de 2025 — todos de organizaciones dentro del alcance de NIS2.

El problema está en la ejecución

La suposición obvia de que las empresas simplemente no se toman NIS2 en serio no se sostiene. El 75% de los encuestados ve al menos cierta ventaja competitiva en el cumplimiento, y el 27% considera que esa ventaja es significativa. Las principales preocupaciones sobre el incumplimiento fueron operativas y reputacionales.

Solo el 3% de los encuestados afirmó no tener ninguna preocupación sobre las repercusiones del incumplimiento.

Por qué las organizaciones se quedan cortas

Cuando se les preguntó por qué no habían cumplido completamente, los encuestados dieron respuestas consistentes en todas las regiones encuestadas. Las barreras son prácticas:

El presupuesto es el principal obstáculo, pero indica algo más profundo. Para una parte de las organizaciones, el cumplimiento de NIS2 todavía no se trata como una partida presupuestaria innegociable. La brecha de orientación es igualmente reveladora: el 16% carece de dirección para la implementación, y el 11% no está seguro de qué les exige NIS2 a pesar de estar legalmente obligados a cumplir.

El riesgo de la cadena de suministro agrava el desafío. Solo alrededor de 1 de cada 10 empresas evaluaba adecuadamente las medidas de seguridad de sus proveedores en 2024, según el NCSC del Reino Unido — y el 10% de los encuestados citó la incapacidad de evaluar toda su cadena de suministro como la razón principal del incumplimiento.

Qué están haciendo realmente las organizaciones

El panorama muestra un progreso parcial. Los protocolos de seguridad comunes (formación, cifrado, evaluaciones de riesgo) se están aplicando, a menudo de forma independiente a NIS2. Los requisitos más exigentes (evaluación de la cadena de suministro, análisis formal de brechas, aplicación de MFA) van significativamente por detrás.

La aplicación de MFA y el control de acceso están entre las medidas NIS2 menos implementadas — sin embargo, son lo primero que comprueban los auditores. Descubra cómo Passwork gestiona la gobernanza de credenciales

La fatiga regulatoria es real

Las organizaciones que operan en la UE pueden enfrentar simultáneamente obligaciones bajo NIS2, GDPR, DORA, la Ley de Ciberseguridad de la UE e ISO 27001. Estos marcos se superponen significativamente, pero navegarlos aún requiere tiempo, experiencia y recursos que la mayoría de las organizaciones no tienen internamente.

El 42% de los encuestados dice que hay demasiadas regulaciones que cumplir, el 35% dice que muchas se superponen y el 27% siente que se les da demasiado énfasis.

El cumplimiento es ahora un requisito comercial

Los reguladores no son los únicos que exigen pruebas. La presión del mercado crece desde todas las direcciones:

• El 42% ha sido solicitado para demostrar cumplimiento de NIS2 por socios
• El 41% ha sido solicitado por inversores
• El 36% ha sido solicitado por clientes o prospectos

NIS2 sigue siendo un estándar relativamente nuevo. A medida que más organizaciones lo incorporen en la debida diligencia de proveedores y socios, demostrar el cumplimiento pasará de ser excepcional a rutinario. Ya es una condición para hacer negocios en muchos sectores.

Aspectos destacados regionales

La encuesta revela diferencias significativas entre mercados:

• Polonia destaca como la cultura de cumplimiento más fuerte: ningún encuestado polaco informó gastar el 5% o menos de su presupuesto de TI en seguridad. El consejo de administración o la alta dirección es responsable del cumplimiento en la mayoría de las organizaciones polacas.
• Benelux muestra una desconexión: los CEO son los más comúnmente responsables (43%), pero el 10% de las empresas está subinvirtiendo en seguridad — la tasa más alta conjunta en la encuesta.
• Alemania, Francia e Italia muestran la mayor fatiga regulatoria: el 44% dice que hay demasiadas regulaciones, el 39% dice que se superponen demasiado.
• Dinamarca registra el mayor escepticismo regulatorio: el 34% no ve una ventaja competitiva en el cumplimiento, y el 55% dice que hay demasiadas regulaciones — la cifra más alta en todas las regiones encuestadas.
• Reino Unido e Irlanda muestran la presión de los inversores como un motor particularmente fuerte: el 58% de las empresas en la región han sido solicitadas por inversores para demostrar cumplimiento de NIS2, comparado con el 41% en todas las regiones.

La divergencia regulatoria UE vs. Reino Unido: Lo que las multinacionales deben saber

Para las organizaciones que operan tanto en la UE como en el Reino Unido, el cumplimiento de NIS2 es solo parte del panorama. El Reino Unido está avanzando con su propio Cyber Security and Resilience Bill — que pasó su segunda lectura en enero de 2026 y ha estado progresando a través de la etapa de comité desde febrero — propone enmiendas significativas a las NIS Regulations 2018.

Los dos marcos comparten objetivos comunes pero difieren de maneras que hacen insuficiente una única estrategia de cumplimiento.

Diferencias clave entre NIS2 y el proyecto de ley del Reino Unido

Sanciones de dos niveles — más estrictas que NIS2

El proyecto de ley del Reino Unido introduce una estructura de sanciones de dos niveles: un máximo estándar de 10 millones de libras o el 2% de la facturación global para fallos menos graves, y un máximo superior de 17 millones de libras o el 4% de la facturación global para fallos graves — incluyendo brechas de seguridad y fallos en la notificación de incidentes.

Los reguladores pueden imponer adicionalmente multas diarias de hasta 100.000 libras por incumplimiento continuado. Esto supera la estructura de nivel único de NIS2.

Regulación directa de MSP: Cerrando una brecha que NIS2 dejó abierta

El proyecto de ley regula directamente a los proveedores de servicios gestionados — una brecha en NIS2 que el Reino Unido está abordando explícitamente. Se estima que entre 900 y 1.100 MSP quedarán bajo supervisión directa del ICO como Proveedores de Servicios Gestionados Relevantes (RMSPs), sujetos al conjunto completo de obligaciones incluyendo registro obligatorio, estándares de seguridad definidos y notificación de incidentes dentro de plazos establecidos.

Las organizaciones que utilizan proveedores de TI externos deberían preguntar a esos proveedores cómo se están preparando.

Definición de incidente más amplia

Las actuales NIS Regulations definen un incidente como cualquier evento que tenga un efecto adverso real en la seguridad. El proyecto de ley amplía esto para capturar cualquier evento que tenga, o pueda tener, un efecto adverso — lo que significa que las organizaciones deben evaluar y responder a incidentes potenciales, no solo a los confirmados. Esto aumentará materialmente el volumen de eventos notificables.

El panorama de amenazas en el Reino Unido

El endurecimiento regulatorio refleja un panorama de riesgo genuino. Se estima que los ciberataques cuestan a las empresas del Reino Unido 14.700 millones de libras anuales — equivalente a aproximadamente el 0,5% del PIB — según investigación independiente encargada por el gobierno del Reino Unido. El coste medio de un ciberataque significativo para una empresa individual es de casi 195.000 libras.

Fragmentación regulatoria entre los estados miembros de la UE

La divergencia no es solo entre la UE y el Reino Unido. A pesar del plazo de transposición de octubre de 2024, la implementación de NIS2 en los 27 estados miembros sigue muy fragmentada. La NISG 2026 de Austria, la Ley KSC de Polonia y la Cyberbeveiligingswet holandesa introducen variaciones nacionales en sanciones, procedimientos de aplicación y requisitos específicos del sector — creando costes de cumplimiento desproporcionados para las organizaciones transfronterizas.

Polonia: Ley KSC en vigor, lista de entidades publicada

La Ley modificada del Sistema Nacional de Ciberseguridad (KSC) de Polonia entró en vigor el 3 de abril de 2026. La lista oficial de entidades esenciales e importantes se publicó el 13 de abril de 2026.

La escala del cambio es sustancial. El marco KSC anterior cubría aproximadamente 400 entidades. La ley modificada incluye en su alcance aproximadamente 42.000 organizaciones — incluyendo casi 28.000 organismos del sector público.

Nuevos sectores ahora cubiertos

Cinco sectores entran en la legislación polaca de ciberseguridad por primera vez:

Polonia también amplió varios sectores existentes más allá de la base de NIS2 — energía ahora incluye minería del carbón; banca e infraestructura del mercado financiero incorporaron tipos de entidades adicionales. La clasificación no siempre es obvia: las organizaciones en sectores recién cubiertos deben realizar una autoevaluación preliminar antes de asumir que están fuera del alcance.

Plazos clave de cumplimiento

El registro no es automático — la mayoría de las organizaciones deben autoevaluarse y solicitar dentro de los 6 meses siguientes al cumplimiento de los criterios. No registrarse no exime a una organización de sus obligaciones; añade una infracción adicional.

Países Bajos: La Cyberbeveiligingswet está casi en vigor

La Cyberbeveiligingswet (Cbw) holandesa — la transposición de NIS2 de los Países Bajos — fue aprobada por la Cámara de Representantes el 15 de abril de 2026 y se espera que entre en vigor en el segundo trimestre de 2026.

La ley introduce cuatro obligaciones fundamentales para todas las organizaciones dentro del alcance:

• 10 medidas obligatorias de deber de diligencia — análisis de riesgos, gestión de accesos, MFA, respuesta a incidentes, seguridad de la cadena de suministro, cifrado y otras cuatro. La certificación ISO 27001 ayuda pero no constituye cumplimiento total por sí sola.
• Notificación de incidentes en tres pasos — alerta temprana en 24 horas, notificación de seguimiento en 72 horas, informe final en 30 días, todo enviado a través del portal NCSC.
• Responsabilidad personal del consejo — los órganos de dirección deben aprobar formalmente las medidas de ciberseguridad, supervisar la implementación y completar formación en ciberseguridad. Delegar completamente a TI sin supervisión activa crea exposición personal directa.

Las multas alcanzan hasta 10 millones de euros o el 2% de la facturación global para entidades esenciales, y 7 millones de euros o el 1,4% para entidades importantes.

La mayoría de las organizaciones necesitan de cuatro a seis meses para alcanzar el nivel de cumplimiento requerido. Aquellas que aún no han comenzado un análisis de brechas se están quedando sin tiempo.

Responsabilidad del consejo: El Artículo 20 lo hace personal

El Artículo 20 de NIS2 hace que los órganos de dirección sean directa y personalmente responsables de la gobernanza de ciberseguridad. Se aplican tres niveles de exposición:

• Responsabilidad de aprobación. Los órganos de dirección deben aprobar formalmente las medidas de gestión de riesgos de ciberseguridad. Si esas medidas resultan inadecuadas y conducen a un incidente, la decisión de aprobación y las personas que la tomaron serán examinadas por los reguladores.
• Responsabilidad de formación. El Artículo 20(2) requiere que los ejecutivos completen formación en ciberseguridad suficiente para identificar riesgos y evaluar prácticas de gestión de riesgos. La ignorancia de los detalles técnicos ya no es una posición defendible.
• Responsabilidad de supervisión. Delegar completamente a TI o a un MSSP externo sin mantener la supervisión de gobernanza crea exposición personal directa. En Alemania, los directivos individuales enfrentan multas de hasta 500.000 € por fallos de gobernanza — independientes de cualquier sanción organizacional. Los directores también pueden ser inhabilitados temporalmente de funciones directivas por negligencia grave.

El análisis de KPMG Law de abril de 2026 sobre la implementación alemana confirma que esto no es teórico. MSI Global Alliance plantea el cambio claramente: la ciberseguridad ahora se sitúa al mismo nivel de gobernanza que la información financiera. Los directores son responsables de la postura de ciberseguridad de su organización, con obligaciones que incluyen políticas documentadas de gestión de riesgos y supervisión demostrable de terceros.

Cómo Passwork apoya el cumplimiento de NIS2

La forma más rápida de cerrar las brechas más comunes de NIS2 es poner el acceso bajo control. El Artículo 21 de la directiva requiere explícitamente que las organizaciones implementen políticas de gestión de accesos, apliquen autenticación fuerte y mantengan pistas de auditoría documentadas. Estos son también los controles que los reguladores examinan primero y los que la mayoría de las organizaciones todavía manejan manualmente o de forma inconsistente.

Un gestor de contraseñas aborda esto directamente. Centraliza el almacenamiento de credenciales, aplica políticas de acceso basadas en roles y crea un registro verificable de quién accedió a qué y cuándo — el tipo de evidencia que los auditores esperan ver.

Gestión de accesos y pistas de auditoría

Passwork ofrece control de acceso estructurado y basado en roles en todas las credenciales compartidas. Los administradores asignan permisos a nivel de bóveda, carpeta y contraseña individual. Cada evento de acceso — visualización, copia, edición, compartición, eliminación — se registra con una marca de tiempo e identidad de usuario.

Esta pista de auditoría es directamente relevante para el Artículo 21(2)(i) de NIS2, que requiere que las organizaciones implementen «políticas y procedimientos relativos al uso de criptografía y, en su caso, cifrado» y mantengan controles de acceso sobre sistemas sensibles. Cuando un regulador solicita evidencia de gobernanza de accesos, un registro completo y consultable es la respuesta.

Monitoreo continuo

NIS2 requiere monitoreo de seguridad continuo. Passwork lo apoya a través de un feed de actividad en tiempo real y notificaciones configurables para cualquier evento de credenciales: una contraseña visualizada por un usuario inesperado, una bóveda compartida accedida fuera del horario laboral, una cuenta privilegiada modificada sin un ticket de cambio.

El panel de seguridad de contraseñas marca las credenciales débiles, reutilizadas, obsoletas y potencialmente comprometidas en toda la organización — dando a los equipos de seguridad visibilidad continua sin auditoría manual.

Certificado ISO 27001 y probado continuamente

Passwork cuenta con certificación ISO/IEC 27001 — el mismo estándar que Bélgica acepta como vía de cumplimiento de NIS2 bajo su marco CyFun. La certificación confirma un enfoque sistemático y auditable de la gestión de la seguridad de la información.

Para las organizaciones que necesitan demostrar su postura de seguridad ante reguladores, socios o clientes, la certificación ISO 27001 de Passwork proporciona evidencia verificable de forma independiente.

Implementación autoalojada

Passwork se implementa completamente dentro de su propia infraestructura. Todos los datos están cifrados con AES-256 y nunca salen de sus servidores. No hay dependencia de servicios en la nube de terceros — lo cual importa tanto para el cumplimiento de NIS2 como para las disposiciones de riesgo de la cadena de suministro que requieren que las organizaciones evalúen la seguridad de sus proveedores de servicios.

El código fuente es auditable. Su equipo de seguridad puede verificar que no hay vulnerabilidades ocultas antes de la implementación.

Passwork proporciona a su equipo control de acceso estructurado, un registro de auditoría completo y monitoreo continuo de credenciales — todo dentro de su propia infraestructura. Descubra cómo Passwork apoya el cumplimiento de NIS2

Calendario de cumplimiento

La siguiente tabla describe los eventos clave de cumplimiento, ordenados cronológicamente. Las fechas inciertas o estimadas se indican como corresponde.

Conclusión

El plazo del 18 de abril de Bélgica ha pasado. No será el último. Los reguladores en los 27 estados miembros están pasando de la orientación a las auditorías, y la cifra de preparación del 16% significa que la gran mayoría de las organizaciones dentro del alcance están expuestas en este momento.

El patrón es consistente en cada acción de aplicación temprana: los controles que los reguladores examinan primero son la gestión de accesos, la gobernanza de credenciales privilegiadas y las pistas de auditoría. Estos no son los requisitos más difíciles de NIS2 — son los más concretos, los más documentables y los más inmediatamente accionables.

Poner el acceso bajo control es la forma más rápida de cerrar las brechas de cumplimiento más auditables. Satisface directamente los requisitos del Artículo 21, apoya la supervisión de la cadena de suministro y genera la pista de evidencia que exige la responsabilidad del consejo del Artículo 20. Un gestor de contraseñas con acceso basado en roles, un registro de auditoría completo y monitoreo continuo aborda los tres aspectos.

Passwork tiene certificación ISO/IEC 27001 y se implementa completamente dentro de su propia infraestructura. Fue diseñado exactamente para el tipo de gobernanza de accesos que buscan los auditores de NIS2.

Passwork es un gestor de contraseñas autoalojado diseñado para empresas. Aplica políticas de acceso basadas en roles, mantiene un registro de auditoría completo de toda la actividad de credenciales y se implementa completamente dentro de su propia infraestructura. Pruebe Passwork en su infraestructura

Preguntas frecuentes

¿Qué es la Directiva NIS2 y a quién se aplica?

NIS2 (Directiva UE 2022/2555) es el marco legal de la UE para la seguridad de redes e información, que reemplaza la Directiva NIS original de 2016. Se aplica a organizaciones medianas y grandes en 18 sectores críticos — incluyendo energía, salud, finanzas, transporte, infraestructura digital y manufactura — con al menos 50 empleados o 10 millones de euros en facturación anual o balance total.

¿Cuáles son las principales obligaciones de ciberseguridad bajo NIS2?

El Artículo 21 de NIS2 requiere que las organizaciones implementen análisis de riesgos, respuesta a incidentes, medidas de continuidad del negocio, seguridad de la cadena de suministro, políticas de control de acceso, MFA, cifrado y gestión de vulnerabilidades. Estas medidas deben ser aprobadas formalmente por el órgano de dirección bajo el Artículo 20, con evidencia documentada de implementación disponible para inspección regulatoria.

¿Qué multas pueden enfrentar las organizaciones por incumplimiento de NIS2?

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 global. Varios estados miembros superan estos mínimos — Alemania permite multas de hasta 20 millones de euros para entidades esenciales, más multas individuales a directivos de hasta 500.000 € por fallos de gobernanza.

¿Qué requiere NIS2 para la gestión de accesos y la seguridad de credenciales?

El Artículo 21(2)(i) requiere políticas que cubran el control de acceso, la autenticación y el uso de criptografía. En la práctica, esto significa acceso basado en roles a sistemas críticos, MFA aplicado, políticas de credenciales documentadas y una pista de auditoría completa de eventos de acceso privilegiado. Las contraseñas compartidas, las cuentas de servicio no gestionadas y las rutas de acceso no documentadas son fallos de cumplimiento directos bajo este artículo.

¿Cómo aborda NIS2 la seguridad de la cadena de suministro?

El Artículo 21(2)(d) requiere que las organizaciones evalúen y gestionen la postura de ciberseguridad de sus proveedores directos y proveedores de servicios. Esto incluye mapear las dependencias críticas de terceros, incorporar obligaciones de seguridad en los contratos y monitorear la postura del proveedor de forma continua. Solo alrededor de 1 de cada 10 empresas evaluaba adecuadamente las medidas de seguridad de sus proveedores en 2024, según el UK NCSC.

¿Cuáles son los plazos de notificación de incidentes de NIS2?

NIS2 establece un proceso de tres etapas: una alerta temprana de 24 horas a la autoridad nacional tras detectar un incidente significativo, una notificación detallada de 72 horas con una evaluación inicial del impacto, y un informe final de 30 días que cubra el análisis de causa raíz y los pasos de remediación. Estos plazos se aplican tanto a entidades esenciales como importantes y requieren flujos de trabajo de respuesta automatizados y pre-probados para cumplirse de manera fiable.

¿Qué responsabilidad personal enfrentan los ejecutivos bajo NIS2?

El Artículo 20 hace que los órganos de dirección sean directamente responsables de aprobar las medidas de gestión de riesgos de ciberseguridad, supervisar su implementación y completar formación en ciberseguridad. Los ejecutivos pueden ser considerados personalmente responsables por fallos de gobernanza. En Alemania, los directivos individuales enfrentan multas de hasta 500.000 € bajo la ley nacional de implementación de NIS2, y los directores pueden ser inhabilitados temporalmente de funciones directivas por negligencia grave.

¿Satisface la certificación ISO 27001 los requisitos de NIS2?

La certificación ISO 27001 se reconoce como una vía de cumplimiento en algunos estados miembros — Bélgica la acepta como evidencia de conformidad con NIS2, siempre que las organizaciones presenten el alcance de la certificación, la Declaración de Aplicabilidad y el informe de auditoría interna más reciente. Sin embargo, la certificación por sí sola no constituye cumplimiento total de NIS2 en la mayoría de las jurisdicciones. Reduce significativamente la brecha de cumplimiento y proporciona a los auditores una base de evidencia reconocida, pero las organizaciones aún deben demostrar la implementación de todas las medidas del Artículo 21.

April 18, 2026 — Belgium's first NIS2 enforcement deadline. Essential entities were required to submit verified documentation confirming that cybersecurity controls are in place, assessed by an accredited body or the Centre for Cybersecurity Belgium directly. Self-declarations were not accepted.

22 of 27 member states have completed NIS2 transposition. Enforcement is active in Germany, France, and the Netherlands — regulators are auditing, and fines are being applied.

Meanwhile, 84% of organizations facing active enforcement are, by their own admission, not ready — according to CyberSmart's April 2026 survey of 670 in-scope business leaders across eight countries. That number has not moved meaningfully in six months.

This article covers where enforcement stands today, what is coming next, and what IT and security leaders need to address before the next deadline arrives.

Key takeaways

• Belgium set the first deadline. On April 18, 2026, essential entities were required to submit verified self-assessments via CyberFundamentals (CyFun), ISO/IEC 27001, or direct CCB inspection.
• Readiness remains critically low. Only 16% of businesses feel fully prepared, yet 75% see compliance as a competitive advantage. The gap is execution: budget constraints, missing implementation guidance, and supply chain blind spots are the real blockers.
• Poland expanded scope to 42,000 organizations. The amended KSC Act entered into force on April 3, 2026, adding food production, waste management, and other sectors. The official entity list launched April 13, 2026.
• Supply chain risk is the hardest gap to close. Only around 1 in 10 businesses were adequately assessing their suppliers' security posture as recently as 2024 (UK NCSC). NIS2 Article 21 requires documented third-party security obligations and continuous monitoring.
• Board liability is personal. NIS2 Article 20 makes management bodies directly accountable for approving cybersecurity measures and completing relevant training. In Germany, individual managers face fines of up to €500,000 for governance failures — separate from organizational penalties.
• The UK is building a stricter parallel regime — and multinationals must track both. The UK Cyber Security and Resilience Bill introduces two-tier penalties (up to £17M or 4% of global turnover for serious failures), direct MSP regulation, and a broader incident definition that captures potential incidents — not just confirmed ones. A single NIS2 compliance strategy is not sufficient for cross-border operations.
• The controls auditors examine first are also the fastest to implement. Access management, credential policies, and MFA are explicitly required under Article 21 — and they generate the audit trail that satisfies both Article 21 and Article 20 board oversight requirements.

What is NIS2 and who does it cover

NIS2 (Directive EU 2022/2555) is the EU's updated legal framework for network and information security. It replaces the original NIS Directive and expands both the scope of covered entities and the severity of obligations. The directive applies to medium-sized and larger organizations across 18 critical sectors.

You organisation is covered by the NIS2 directive if:

• It operates in a sector listed in Annex I or Annex II of the directive
• It meets the size threshold — at least 50 employees, or an annual turnover and/or annual balance sheet total exceed €10 million (Annex to Recommendation 2003/361/EC)
• It is identified as a critical entity under Directive (EU) 2022/2557 (CER Directive), regardless of its size

Once your organisation is confirmed in scope, its classification as an essential or important entity depends on two factors: the annex your sector falls under, and your organisation's size.

Some organisations fall within NIS2 scope regardless of size:

• A provider of public electronic communications networks or publicly available electronic communications services
• A trust service provider
• A top-level domain (TLD) name registry or DNS service provider
• The sole provider of a service in a Member State that is essential for the maintenance of critical societal or economic activities
• An entity whose disruption could have a significant impact on public safety, public security, or public health
• An entity whose disruption could induce a significant systemic risk, in particular for sectors where such disruption could have a cross-border impact

If your organisation belongs to a larger corporate group, headcount and financials must be aggregated across linked entities — a subsidiary with 40 employees may still be in scope if the parent group exceeds the thresholds.

As of March 2026, 22 of 27 EU member states have adopted national implementing legislation. France, Ireland, Luxembourg, the Netherlands, and Spain remain in the legislative process, according to Skadden's March 2026 analysis.

Top story: Belgium's April 18 deadline

On April 18, 2026, Belgium hit the NIS2 conformity assessment deadline. Essential entities were required to demonstrate active implementation of cybersecurity risk-management measures and submit supporting evidence to the Centre for Cybersecurity Belgium (CCB) — via one of three recognised compliance pathways:

• CyberFundamentals (CyFun®): Obtain at least a Basic or Important verification, or hold a signed agreement with an accredited assessment body.
• ISO/IEC 27001: Submit the certification scope, Statement of Applicability (SoA), and the most recent internal audit report. Full certification must be completed by April 2027.
• Direct inspection: Provide a self-assessment with supporting documentation and formally request a CCB inspection — a pathway that may lead directly to supervisory measures.

Self-attestation alone is not accepted. Failure to submit complete and timely documentation may result in administrative measures, financial penalties, and further supervisory action.

The pattern Belgium has set (formal third-party assessment, documented evidence, management sign-off, personal liability) is the template the rest of the EU is following.

The NIS2 readiness gap: 84% of businesses are not ready

16% of European businesses required to comply with NIS2 feel fully prepared while 11% of in-scope organizations are still unsure what NIS2 is. These figures come from CyberSmart's survey of 670 business leaders across the UK, Poland, the Netherlands, Ireland, France, Germany, Italy, Denmark, and Belgium, conducted in late 2025 — all from organizations within NIS2's scope.

The problem is execution

The obvious assumption that businesses simply aren't taking NIS2 seriously doesn't hold up. 75% of respondents see at least some competitive advantage in compliance, and 27% consider that advantage significant. The top concerns around non-compliance were operational and reputational.

Only 3% of respondents said they have no concerns about the repercussions of non-compliance at all.

Why organizations are falling short

When asked why they hadn't fully complied, respondents gave consistent answers across every region surveyed. The barriers are practical:

Budget is the leading obstacle but it signals something deeper. For a portion of organizations, NIS2 compliance is still not treated as a non-negotiable budget line. The guidance gap is equally telling: 16% lack implementation direction, and 11% are unsure what NIS2 requires of them despite being legally obligated to comply.

Supply chain risk compounds the challenge. Only around 1 in 10 businesses were adequately assessing their suppliers' security measures as recently as 2024, according to the UK's NCSC — and 10% of survey respondents cited inability to assess their full supply chain as the primary reason for non-compliance.

What organizations are actually doing

The picture is one of partial progress. Common security protocols (training, encryption, risk assessments) are being applied, often independently of NIS2. The more demanding requirements (supply chain assessment, formal gap analysis, MFA enforcement) lag significantly behind.

MFA enforcement and access control are among the least-implemented NIS2 measures — yet they're the first thing auditors check. See how Passwork handles credential governance

Regulatory fatigue is real

Organizations operating in the EU can simultaneously face obligations under NIS2, GDPR, DORA, the EU Cybersecurity Act, and ISO 27001. These frameworks overlap significantly, but navigating them still requires time, expertise, and resources that most organizations don't have in-house.

42% of respondents say there are too many regulations to comply with, 35% say too many overlap, and 27% feel there is too much emphasis placed on them.

Compliance is now a commercial requirement

Regulators are not the only ones demanding proof. Market pressure is building from every direction:

• 42% have been asked to prove NIS2 compliance by partners
• 41% have been asked by investors
• 36% have been asked by customers or prospects

NIS2 is still a relatively new standard. As more organizations embed it into supplier and partner due diligence, demonstrating compliance will shift from exceptional to routine. It is already a condition of doing business in many sectors.

Regional highlights

The survey reveals meaningful differences across markets:

• Poland stands out as the strongest compliance culture: not a single Polish respondent reported spending 5% or less of their IT budget on security. The board or C-suite is responsible for compliance in the majority of Polish organizations.
• Benelux shows a disconnect: CEOs are most commonly accountable (43%), yet 10% of businesses are underspending on security — the joint-highest rate in the survey.
• Germany, France and Italy show the highest regulatory fatigue: 44% say there are too many regulations, 39% say they overlap too much.
• Denmark records the highest regulatory skepticism: 34% do not see a competitive advantage in compliance, and 55% say there are too many regulations — the highest figure across all regions surveyed.
• UK and Ireland show investor pressure as a particularly strong driver: 58% of businesses in the region have been asked by investors to prove NIS2 compliance, compared to 41% across all regions.

The EU vs. UK regulatory divergence: What multinationals must know

For organizations operating across both the EU and the UK, NIS2 compliance is only part of the picture. The UK is advancing its own Cyber Security and Resilience Bill — which passed its second reading in January 2026 and has been progressing through committee stage since February — proposes significant amendments to the NIS Regulations 2018.

The two frameworks share common objectives but differ in ways that make a single compliance strategy insufficient.

Key differences between NIS2 and the UK Bill

Two-tier penalties — stricter than NIS2

The UK Bill introduces a two-tier penalty structure: a standard maximum of £10M or 2% of global turnover for less serious failures, and a higher maximum of £17M or 4% of global turnover for serious failures — including security breaches and incident notification failures.

Regulators can additionally impose daily fines of up to £100,000 for ongoing non-compliance. This exceeds NIS2's single-tier structure.

Direct MSP regulation: closing a gap NIS2 left open

The Bill directly regulates managed service providers — a gap in NIS2 that the UK is explicitly addressing. An estimated 900 to 1,100 MSPs will come under direct ICO oversight as Relevant Managed Service Providers (RMSPs), subject to the full suite of obligations including mandatory registration, defined security standards, and incident reporting within prescribed timeframes.

Organizations using external IT providers should be asking those providers how they are preparing.

Broader incident definition

The current NIS Regulations define an incident as any event having an actual adverse effect on security. The Bill broadens this to capture any event having, or capable of having, an adverse effect — meaning organizations must assess and respond to potential incidents, not only confirmed ones. This will materially increase the volume of reportable events.

The UK threat landscape

The regulatory tightening reflects a genuine risk picture. Cyber attacks are estimated to cost UK businesses £14.7 billion annually — equivalent to approximately 0.5% of GDP — based on independent research commissioned by the UK government. The average cost of a significant cyber attack for an individual business is nearly £195,000.

Regulatory fragmentation across EU member states

The divergence is not only between the EU and UK. Despite the October 2024 transposition deadline, NIS2 implementation across the 27 member states remains highly fragmented. Austria's NISG 2026, Poland's KSC Act, and the Dutch Cyberbeveiligingswet each introduce national variations in penalties, enforcement procedures, and sector-specific requirements — creating disproportionate compliance costs for cross-border organizations.

Poland: KSC Act in force, entity list published

Poland's amended Act on the National Cybersecurity System (KSC) entered into force on April 3, 2026. The official list of key and important entities launched on April 13, 2026.

The scale of change is substantial. The previous KSC framework covered approximately 400 entities. The amended law brings an estimated 42,000 organizations into scope — including nearly 28,000 public sector bodies.

New sectors now covered

Five sectors enter Polish cybersecurity law for the first time:

Poland also expanded several existing sectors beyond the NIS2 baseline — energy now includes coal mining; banking and financial market infrastructure picked up additional entity types. Classification is not always obvious: organizations in newly covered sectors should conduct a preliminary self-assessment before assuming they fall outside scope.

Key compliance deadlines

Registration is not automatic — most organizations must self-assess and apply within 6 months of meeting the criteria. Failing to register does not exempt an organization from its obligations; it adds a violation on top.

Netherlands: The Cyberbeveiligingswet is almost in force

The Dutch Cyberbeveiligingswet (Cbw) — the Netherlands' transposition of NIS2 — passed the House of Representatives on April 15, 2026 and is expected to take effect on Q2 2026.

The law introduces four core obligations for all in-scope organizations:

• 10 mandatory duty-of-care measures — risk analysis, access management, MFA, incident response, supply chain security, encryption, and four others. ISO 27001 certification helps but does not constitute full compliance on its own.
• Three-step incident reporting — early warning within 24 hours, follow-up notification within 72 hours, final report within 30 days, all submitted via the NCSC portal.
• Personal board liability — governing bodies must formally approve cybersecurity measures, oversee implementation, and complete cybersecurity training. Delegating entirely to IT without active oversight creates direct personal exposure.

Fines reach up to €10M or 2% of global turnover for essential entities, and €7M or 1.4% for important entities.

Most organizations need four to six months to reach the required compliance level. Those that haven't started a gap analysis yet are running out of time.

Board liability: Article 20 makes it personal

NIS2 Article 20 makes management bodies directly and personally accountable for cybersecurity governance. Three layers of exposure apply:

• Approval liability. Management bodies must formally approve cybersecurity risk-management measures. If those measures prove inadequate and lead to an incident, the approval decision and the people who made it will be examined by regulators.
• Training liability. Article 20(2) requires executives to complete cybersecurity training sufficient to identify risks and assess risk-management practices. Ignorance of technical details is no longer a defensible position.
• Oversight liability. Delegating entirely to IT or a third-party MSSP without maintaining governance oversight creates direct personal exposure. In Germany, individual managers face fines of up to €500,000 for governance failures — separate from any organizational penalty. Directors can also be temporarily banned from management roles for serious negligence.

KPMG Law's April 2026 analysis of the German implementation confirms this is not theoretical. MSI Global Alliance frames the shift plainly: cybersecurity now sits at the same governance level as financial reporting. Directors are responsible for their organization's cybersecurity posture, with obligations including documented risk management policies and demonstrable oversight of third parties.

How Passwork supports NIS2 compliance

The fastest way to close the most common NIS2 gaps is to bring access under control. Article 21 of the directive explicitly requires organizations to implement access management policies, enforce strong authentication, and maintain documented audit trails. These are also the controls regulators examine first and the ones most organizations still handle manually or inconsistently.

A password manager addresses this directly. It centralizes credential storage, enforces role-based access policies, and creates a verifiable record of who accessed what and when — the kind of evidence auditors expect to see.

Access management and audit trails

Passwork offers structured, role-based access control across all shared credentials. Admins assign permissions at the vault, folder, and individual password level. Every access event — view, copy, edit, share, deletion — is logged with a timestamp and user identity.

This audit trail is directly relevant to NIS2 Article 21(2)(i), which requires organizations to implement "policies and procedures regarding the use of cryptography and, where appropriate, encryption" and to maintain access controls over sensitive systems. When a regulator asks for evidence of access governance, a complete, searchable log is the answer.

Continuous monitoring

NIS2 requires ongoing security monitoring. Passwork supports this through a real-time activity feed and configurable notifications for any credential event: a password viewed by an unexpected user, a shared vault accessed outside working hours, a privileged account modified without a change ticket.

The password security dashboard flags weak, reused, outdated, and potentially compromised credentials across the entire organization — giving security teams continuous visibility without manual auditing.

ISO 27001 certified and continuously tested

Passwork holds ISO/IEC 27001 certification — the same standard Belgium accepts as a NIS2 compliance pathway under its CyFun framework. The certification confirms a systematic, auditable approach to information security management

For organizations that need to demonstrate security posture to regulators, partners, or customers, Passwork's ISO 27001 certification provides independently verifiable evidence.

Self-hosted deployment

Passwork deploys entirely within your own infrastructure. All data is encrypted with AES-256 and never leaves your servers. There is no dependency on third-party cloud services — which matters both for NIS2 compliance and for the supply chain risk provisions that require organizations to assess the security of their service providers.

The source code is auditable. Your security team can verify there are no hidden vulnerabilities before deployment.

Passwork gives your team structured access control, a full audit log, and continuous credential monitoring — all within your own infrastructure. See how Passwork supports NIS2 compliance

Compliance calendar

The following table outlines the key compliance events, sorted chronologically. Uncertain or estimated dates are flagged accordingly.

Conclusion

Belgium's April 18 deadline has passed. It will not be the last. Regulators across 27 member states are moving from guidance to audits, and the 16% readiness figure means the vast majority of in-scope organizations are exposed right now.

The pattern is consistent across every early enforcement action: the controls regulators examine first are access management, privileged credential governance, and audit trails. These are not the hardest requirements in NIS2 — they are the most concrete, the most documentable, and the most immediately actionable.

Getting access under control is the fastest way to close the most auditable compliance gaps. It satisfies Article 21 requirements directly, supports supply chain oversight, and generates the evidence trail that Article 20 board liability demands. A password manager with role-based access, a complete audit log, and continuous monitoring addresses all three.

Passwork is ISO/IEC 27001 certified and deploys entirely within your own infrastructure. It was designed for exactly the kind of access governance NIS2 auditors look for.

Passwork is a self-hosted password manager built for businesses. It enforces role-based access policies, maintains a complete audit log of all credential activity, and deploys entirely within your own infrastructure. Try Passwork in your infrastructure

Frequently Asked Questions

What is the NIS2 Directive and who does it apply to?

NIS2 (Directive EU 2022/2555) is the EU's legal framework for network and information security, replacing the original NIS Directive from 2016. It applies to medium and large organizations in 18 critical sectors — including energy, healthcare, finance, transport, digital infrastructure, and manufacturing — with at least 50 employees or €10 million in annual turnover or balance sheet total.

What are the main cybersecurity obligations under NIS2?

NIS2 Article 21 requires organizations to implement risk analysis, incident response, business continuity measures, supply chain security, access control policies, MFA, encryption, and vulnerability management. These measures must be formally approved by the management body under Article 20, with documented evidence of implementation available for regulatory inspection.

What fines can organizations face for NIS2 non-compliance?

Essential entities face fines of 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 turnover. Several member states exceed these minimums — Germany allows fines up to €20 million for essential entities, plus individual manager fines of up to €500,000 for governance failures.

What does NIS2 require for access management and credential security?

Article 21(2)(i) requires policies covering access control, authentication, and the use of cryptography. In practice, this means role-based access to critical systems, enforced MFA, documented credential policies, and a complete audit trail of privileged access events. Shared passwords, unmanaged service accounts, and undocumented access paths are direct compliance failures under this article.

How does NIS2 address supply chain security?

Article 21(2)(d) requires organizations to assess and manage the cybersecurity posture of their direct suppliers and service providers. This includes mapping critical third-party dependencies, embedding security obligations in contracts, and monitoring supplier posture on an ongoing basis. Only around 1 in 10 businesses were adequately assessing their suppliers' security measures as recently as 2024, according to the UK NCSC.

What are the NIS2 incident reporting deadlines?

NIS2 mandates a three-stage process: a 24-hour early warning to the national authority after detecting a significant incident, a 72-hour detailed notification with an initial impact assessment, and a 30-day final report covering root cause analysis and remediation steps. These deadlines apply to both essential and important entities and require pre-tested, automated response workflows to meet reliably.

What personal liability do executives face under NIS2?

Article 20 makes management bodies directly accountable for approving cybersecurity risk-management measures, overseeing their implementation, and completing cybersecurity training. Executives can be held personally liable for governance failures. In Germany, individual managers face fines of up to €500,000 under national NIS2 implementation law, and directors can be temporarily banned from management roles for serious negligence.

Does ISO 27001 certification satisfy NIS2 requirements?

ISO 27001 certification is recognized as a compliance pathway in some member states — Belgium accepts it as evidence of NIS2 conformity, provided organizations submit the certification scope, Statement of Applicability, and the most recent internal audit report. However, certification alone does not constitute full NIS2 compliance in most jurisdictions. It significantly reduces the compliance gap and provides auditors with a recognized evidence baseline, but organizations must still demonstrate implementation of all Article 21 measures.

Spring 2026 EU cybersecurity update: What changed

Spring 2026 brought the EU’s most significant institutional breach, its first cyber sanctions of the year, and four major cybersecurity regulations enforcing simultaneously. NIS2, DORA, CRA, and CSA2 now set hard deadlines — and real penalties. Here’s what changed, who’s affected, and what to do.

Passwork BlogAlex Muntyan

NIS2 password requirements: What European companies must do in 2026

Credential gaps are the leading NIS2 audit failure point in 2026. This guide covers Article 21 password requirements, NIST SP 800-63B alignment, AD hardening steps, and the audit evidence regulators ask for first.

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

Einleitung

Um 3:14 Uhr nachts beobachtet niemand die Authentifizierungs-Logs. Ein Skript, das auf einer gemieteten Cloud-Instanz läuft, sendet seinen zehntausendsten Anmeldeversuch an ein VPN-Portal. Um 3:17 Uhr erhält es eine Antwort, die sich von den anderen unterscheidet. Zugriff gewährt. Keine Malware, kein Social Engineering, keine Insider-Bedrohung. Nur ein schwaches Passwort, automatisierte Geduld und eine Lücke im Monitoring.

Einer von drei erfolgreichen Angriffen auf Webanwendungen beginnt heute auf die gleiche Weise: Ein automatisiertes Skript durchläuft Anmeldedaten, bis etwas funktioniert. Laut dem Verizon Data Breach Investigations Report 2025 haben sich Brute-Force-Angriffe auf einfache Webanwendungen im letzten Jahr fast verdreifacht — von etwa 20 % auf 60 %. Dies signalisiert, dass automatisierte Credential-Angriffe zur primären Waffe geworden sind, nicht zum Ausweichplan.

Die zugrundeliegende Mechanik hat sich nicht geändert: Kombinationen ausprobieren, bis eine funktioniert. Was sich geändert hat, ist die Geschwindigkeit, Skalierung und Intelligenz hinter diesen Versuchen. Moderne GPU-Cluster, KI-gestützte Wordlist-Generierung und Botnets mit Millionen kompromittierter Geräte haben das, was einst ein langsamer, auffälliger Angriff war, in etwas Schnelles, Verteiltes und schwer Erkennbares verwandelt.

Dieser Artikel behandelt, was Brute-Force-Angriffe sind, wie sie sich 2026 entwickelt haben, die sechs Hauptvarianten, Praxisbeispiele aus 2025–2026 und eine mehrschichtige Verteidigungsstrategie, die Ihr Team heute implementieren kann.

Wichtigste Erkenntnisse

• Brute-Force-Angriffe sind automatisierte Credential-Angriffe — Skripte durchlaufen systematisch Benutzernamen- und Passwortkombinationen, bis eine funktioniert, und nutzen schwache, wiederverwendete oder vorhersagbare Passwörter aus — nicht Software-Schwachstellen.
• Sechs verschiedene Varianten zielen auf unterschiedliche Schwachstellen ab: Einfache Brute-Force, Dictionary-Angriffe, Credential Stuffing, Password Spraying, Reverse Brute Force und Hybrid-Angriffe — jede darauf ausgelegt, einen bestimmten Satz von Abwehrmaßnahmen zu umgehen.
• Moderne Hardware hat schwache Passwörter unhaltbar gemacht: Ein GPU-Cluster kann ein 8-Zeichen-MD5-gehashtes Passwort in Minuten knacken. Passwortlänge und sicheres Hashing bestimmen den realen Widerstand.
• Mehrschichtige Abwehrmaßnahmen funktionieren, aber nur bei konsequenter Durchsetzung. MFA, starke Passwortrichtlinien, Breach-Datenbank-Prüfung, Kontosperren, Rate Limiting und ein Passwort-Manager machen Brute-Force-Angriffe gemeinsam unpraktikabel. Jede einzelne Lücke reicht einem Angreifer zur Ausnutzung.
• Erkennung ist eine präventive Kontrolle, nicht nur eine reaktive. Das Erkennen von Angriffssignaturen — Spitzen bei fehlgeschlagenen Anmeldungen, langsame Spraying-Muster, unmögliche Reisen — gibt Ihrem Team Zeit, die Quelle zu blockieren, bevor Anmeldedaten validiert werden.
• Ein Passwort-Manager ist die strukturelle Lösung für Credential-Wiederverwendung — die Hauptursache hinter Credential Stuffing. Für Teams erzwingt er auch Rotation, markiert kompromittierte Anmeldedaten und schließt die Offboarding-Lücke, die veraltete Anmeldedaten jahrelang gültig lässt.

Was ist ein Brute-Force-Angriff?

Ein Brute-Force-Angriff verschafft unbefugten Zugriff auf ein System durch systematisches Ausprobieren jeder möglichen Kombination von Anmeldedaten (Benutzernamen, Passwörter oder Verschlüsselungsschlüssel), bis die richtige gefunden ist. Er nutzt menschliches Verhalten aus: schwache, wiederverwendete oder vorhersagbare Passwörter.

Stellen Sie es sich vor wie das Ausprobieren jedes Schlüssels an einem Schlüsselbund. Mit genügend Zeit und Rechenleistung wird irgendwann einer passen. Das Ziel des Angreifers ist es, diese Zeit auf etwas Praktikables zu reduzieren — und 2026 macht moderne Hardware das zunehmend erreichbar.

Brute-Force-Angriffe zielen auf Authentifizierungs-Endpunkte: Anmeldeseiten, SSH- und RDP-Dienste, VPN-Portale, API-Gateways und Admin-Panels. Jedes System, das einen Benutzernamen und ein Passwort akzeptiert, ist ein potenzielles Ziel.

Wie Brute-Force-Angriffe 2026 funktionieren

Im Kern ist ein Brute-Force-Angriff Automatisierung im großen Maßstab. Ein Angreifer setzt ein Skript oder Tool ein, das Credential-Kombinationen in schneller Folge an den Authentifizierungs-Endpunkt eines Zielsystems sendet. Das Skript protokolliert erfolgreiche Treffer und macht weiter.

Was 2026 von vor einem Jahrzehnt unterscheidet, ist die Infrastruktur hinter diesen Skripten.

Der KI- und Hardware-Faktor

Moderne Grafikkarten (ursprünglich für Gaming und maschinelles Lernen entwickelt) sind außergewöhnlich effizient bei paralleler Berechnung — genau das, was Password Cracking erfordert. Ein Cluster aus 12 NVIDIA RTX 5090 GPUs kann Hunderte Milliarden MD5-Hash-Kombinationen pro Sekunde testen (Hive Systems).

Bei schwach gehashten Anmeldedaten fällt ein 8-Zeichen-Passwort in Minuten — oder weniger. Gegen bcrypt mit modernen Kosteneinstellungen kann dieselbe Hardware Jahre benötigen. Der Unterschied liegt nicht an der Hardware des Angreifers. Es geht darum, ob das Zielsystem Passwörter sicher speichert.

Machine-Learning-Modelle, die auf geleakten Passwort-Datensätzen trainiert wurden (Tools wie PassGAN, basierend auf Generative Adversarial Networks), lernen reale Passwortverteilungen ohne menschengeschriebene Regeln. Sie sagen wahrscheinliche Muster voraus: An Namen angehängte Geburtstage, gängige Zeichensubstitutionen, kulturspezifische Phrasen.

In Tests gegen den RockYou-Breach-Datensatz traf PassGAN 47 % der echten Passwörter. In Kombination mit konventionellen Cracking-Tools wurden 24 % mehr Treffer erzielt als mit beiden Ansätzen allein. Der Suchraum schrumpft nicht durch Brute Force — er schrumpft durch Vorhersage.

Die Quantenbedrohung

Quantencomputing nutzt quantenmechanische Phänomene zur Informationsverarbeitung auf eine Weise, die klassische Computer nicht können. Während ein klassischer Prozessor Möglichkeiten sequenziell durcharbeitet, wertet ein Quantensystem viele Zustände gleichzeitig aus. Angewendet auf Kryptografie wird diese Parallelität zur direkten Bedrohung für die mathematischen Probleme, die der aktuellen Verschlüsselung zugrunde liegen.

Quantencomputing führt ein längerfristiges Risiko ein. IBMs Quanten-Roadmap prognostiziert, dass kryptografisch relevante Quantencomputer aktuelle asymmetrische Verschlüsselungsstandards noch in diesem Jahrzehnt untergraben könnten.

Quantenangriffe auf gehashte Passwörter bleiben theoretisch, aber Organisationen, die langlebige Geheimnisse und Verschlüsselungsschlüssel verwalten, sollten mit der Evaluierung von Post-Quanten-Kryptografiestandards beginnen — NIST hat seine ersten Post-Quanten-Standards 2024 finalisiert.

Botnets und verteilte Angriffe

Ein Botnet ist ein Netzwerk kompromittierter Geräte (Server, Router, IoT-Endpunkte, PCs), die ohne Wissen ihrer Besitzer von einem Angreifer ferngesteuert werden. Jedes Gerät fungiert als unabhängiger Knoten, der Anfragen senden, Systeme sondieren oder Anmeldeversuche übermitteln kann. Die Skalierung kann Millionen koordiniert arbeitender Maschinen erreichen.

Angreifer operieren selten von einer einzelnen IP aus. Moderne Brute-Force-Kampagnen nutzen Botnets, um Anmeldeversuche über verschiedene Quelladressen zu verteilen und so IP-basiertes Rate Limiting und geografische Sperren zu umgehen.

Anfang 2025 verfolgte die Shadowserver Foundation eine Kampagne, die täglich 2,8 Millionen IP-Adressen nutzte, um VPN-Anmeldeportale von Palo Alto Networks, Ivanti und SonicWall anzugreifen (BleepingComputer).

Die angreifenden Knoten waren überwiegend kompromittierte MikroTik-, Huawei- und Cisco-Router — gekaperte Geräte verteilt über Dutzende Länder, wobei der größte Cluster aus Brasilien stammte. Der Traffic wurde über Residential-Proxy-Netzwerke geleitet, sodass jeder Versuch wie normaler Heimanwender-Traffic aussah statt wie ein Bot. Standard-IP-basierte Abwehrmaßnahmen sahen etwas, das wie normaler Traffic aussah.

Arten von Brute-Force-Angriffen

Brute-Force-Angriffe teilen ein Prinzip: Zugang durch systematisches Testen von Anmeldedaten erlangen, bis etwas funktioniert. Die Methoden unterscheiden sich darin, was sie testen, woher sie ihre Daten beziehen und welche Abwehrmaßnahmen sie umgehen sollen.

1. Einfacher Brute-Force-Angriff

Die direkteste Variante: Jede mögliche Zeichenkombination wird der Reihe nach ausprobiert — aaa, aab, aac — bis ein Treffer gefunden wird. Keine Vorkenntnisse über das Ziel sind erforderlich. Der Angriff verlässt sich vollständig auf Rechenleistung.

Er ist nur gegen kurze oder einfache Passwörter effektiv. Bei einem 8-Zeichen-Passwort mit gemischten Zeichen können moderne GPU-Cluster die Suche in Stunden abschließen. Ab 12 Zeichen wird derselbe Ansatz rechnerisch unpraktikabel — der Suchraum wächst exponentiell mit jedem hinzugefügten Zeichen.

2. Dictionary-Angriff

Ein Dictionary-Angriff ersetzt die erschöpfende Aufzählung durch eine kuratierte Liste wahrscheinlicher Passwörter (Wörter, Phrasen und bekannte Anmeldedaten) und verengt so den Suchraum dramatisch. Der Angreifer setzt auf menschliche Vorhersagbarkeit statt auf rohe Rechenleistung.

Diese Listen reichen von einfachen Zusammenstellungen der 10.000 häufigsten Passwörter bis zu Multi-Gigabyte-Datensätzen aus geleakten Anmeldedaten, regionalen Slang und branchenspezifischer Terminologie. Jedes Passwort, das natürlicher Sprache ähnelt, ist anfällig. Zufälligkeit ist die einzige zuverlässige Verteidigung.

3. Credential Stuffing

Credential Stuffing ist die automatisierte Wiederverwendung von Benutzernamen-Passwort-Paaren, die bei früheren Datenschutzverletzungen gestohlen wurden. Angreifer nehmen Benutzernamen-Passwort-Paare und testen sie gegen andere Dienste und nutzen die Tatsache aus, dass viele Benutzer dieselben Anmeldedaten über mehrere Konten hinweg wiederverwenden.

Im Juli 2024 wurde eine Zusammenstellung von fast 10 Milliarden einzigartigen Passwörtern — genannt RockYou2024 — in einem kriminellen Forum veröffentlicht und bot Angreifern einen beispiellosen Pool an Anmeldedaten (Cybernews, 2024).

Das Verständnis der Gefahren der Passwortwiederverwendung ist hier wesentlicher Kontext — ein einziges kompromittiertes Konto auf einer Plattform kann sich kaskadenartig auf den gesamten digitalen Fußabdruck auswirken.

4. Password Spraying

Password Spraying kehrt den typischen Ansatz um. Anstatt viele Passwörter gegen ein Konto zu probieren (was Sperren auslöst), probiert der Angreifer ein oder zwei gängige Passwörter — Password1!, Welcome2026 — über Tausende von Konten.

Es bleibt unter Sperrschwellen und ist besonders effektiv gegen große Organisationen mit schwachen Passwortrichtlinien. Über 97 % der Identitätsangriffe beinhalten Password Spray oder Brute Force, laut dem Microsoft Digital Defence Report 2025.

5. Reverse-Brute-Force-Angriff

Ein Reverse-Brute-Force-Angriff beginnt mit einem bekannten Passwort (typischerweise aus einem Breach oder einem bekannten Standard stammend) und testet es systematisch gegen eine Liste von Benutzernamen. Die Anmeldedaten sind fix; die Identität ist die Unbekannte.

Diese Methode ist am effektivsten, wenn das Zielpasswort weit verbreitet ist: Ein Standard-Firmenpasswort, das beim Onboarding verteilt wurde, ein gängiges durch eine schwache Richtlinie vorgeschriebenes Muster oder ein Credential, das in einem früheren Leak auftauchte. Während ein Standardangriff ein Konto tief sondiert, sondiert ein Reverse-Angriff viele Konten mit chirurgischer Präzision.

6. Hybrid-Brute-Force-Angriff

Ein Hybrid-Brute-Force-Angriff kombiniert Wörterbuch-Wörter mit programmatischen Mutationen — Anhängen von Zahlen, Jahren oder Sonderzeichen (Summer2026!, admin@123), Ersetzen von Buchstaben durch Symbole oder Verschieben der Groß-/Kleinschreibung. Er ist darauf ausgelegt, Passwörter zu knacken, die komplex erscheinen, aber vorhersagbaren Konstruktionsmustern folgen.

Diese Angriffe zielen auf die Lücke zwischen Passwortrichtlinie und menschlichem Verhalten. Wenn Benutzer aufgefordert werden, ein Passwort zu „verkomplizieren", führen sie selten echte Zufälligkeit ein — sie hängen 1! an ein bekanntes Wort an oder schreiben den ersten Buchstaben groß. Hybrid-Angriffe sind genau darauf ausgelegt, diesen Instinkt auszunutzen, was regelbasierte Komplexitätsanforderungen zu einer schwächeren Verteidigung als Länge allein macht.

Vergleichstabelle für Brute-Force-Angriffe

Die Verwaltung von Anmeldedaten in einem großen Team schafft genau die Angriffsfläche, die Brute-Force-Kampagnen ausnutzen. Erfahren Sie, wie Passwork Team-Tresore mit rollenbasiertem Zugriff und durchgesetzten Passwortrichtlinien strukturiert

Praxisbeispiele für Brute-Force-Angriffe (2025)

Brute-Force- und Credential-Stuffing-Angriffe stellen weiterhin eine erhebliche Bedrohung dar und entwickeln sich in Raffinesse und Umfang weiter. Die folgenden Fälle aus 2025 und 2026 verdeutlichen die anhaltenden Risiken und die kritische Bedeutung robuster Authentifizierung und Sicherheitspraktiken.

Australische Superannuation-Fonds — März 2025

Angriffstyp: Credential Stuffing (koordiniert, Multi-Target).

Am Wochenende vom 29.–30. März 2025 wurden fünf große australische Pensionsfonds (AustralianSuper, REST Super, Hostplus, Australian Retirement Trust und Insignia Financial) gleichzeitig mit Combo-Listen aus unabhängigen früheren Breaches angegriffen. Über 20.000 Konten wurden kompromittiert.

Vier AustralianSuper-Mitglieder verloren zusammen 500.000 AUD. REST schaltete sein MemberAccess-Portal vollständig ab, nachdem bei ca. 8.000 Mitgliedern persönliche Daten offengelegt worden waren.

23andMe — 2023 → regulatorische Konsequenzen 2025

Angriffstyp: Credential Stuffing

Zwischen April und September 2023 testeten Angreifer Anmeldedaten aus unabhängigen Breaches gegen 23andMe-Konten. Durch die DNA-Relatives-Funktion kaskadierten anfängliche Kompromittierungen in die Offenlegung genetischer und Abstammungsdaten von etwa 6,9 Millionen Nutzern — von denen die meisten nie direkt angegriffen worden waren.

„Mega Leak" — 16 Milliarden Anmeldedaten offengelegt — Juni 2025

Angriffstyp: Credential Stuffing (Quelldaten)

Im Juni 2025 entdeckten Cybernews-Forscher ca. 30 Datensätze mit über 16 Milliarden Anmeldedatensätzen — URLs, Benutzernamen und Klartext-Passwörter. Die Daten wurden hauptsächlich durch Infostealer-Malware gesammelt, die auf Verbrauchergeräte abzielte. Betroffene Plattformen waren unter anderem Google, Apple und Facebook. Bemerkenswert: BleepingComputer bestätigte, dass die Datensätze einen erheblichen Anteil recycelter Anmeldedaten aus älteren Breaches enthalten — nicht alle Datensätze stellen also frische Offenlegungen dar.

Jaguar Land Rover — März 2025 + September 2025

Angriffstyp: Credential Stuffing / gestohlene Anmeldedaten (Infostealer-Herkunft)

Im März 2025 durchbrach die HELLCAT-Ransomware-Gruppe JLR mit gestohlenen Jira-Anmeldedaten, die durch Infostealer-Malware gesammelt wurden. Bedrohungsakteur „Rey" leakte am 10. März ca. 700 interne Dokumente. Tage später nutzte ein zweiter Akteur „APTS" Anmeldedaten aus dem Jahr 2021 — die einem Drittanbieter-Auftragnehmer gehörten — um auf denselben Jira-Server zuzugreifen und weitere ca. 350 GB Daten zu leaken, darunter Quellcode, Entwicklungsprotokolle und Mitarbeiterdaten.

Im September 2025 legte ein separater Angriff, der einer Gruppe namens „Scattered Spider Lapsus$ Hunters" zugeschrieben wurde, globale IT-Systeme lahm und stoppte die Produktion im Halewood-Werk, wobei Mitarbeiter nach Hause geschickt wurden.

Zusammenfassungstabelle

Wie erkennt man einen Brute-Force-Angriff?

Prävention ist das Ziel, aber Erkennung ist das Sicherheitsnetz. Brute-Force-Angriffe hinterlassen konsistente Signaturen in Authentifizierungs-Logs — wenn Sie wissen, worauf Sie achten müssen.

• Spitzen bei fehlgeschlagenen Anmeldeversuchen — Ein plötzlicher Anstieg von Authentifizierungsfehlern gegen ein einzelnes Konto oder verteilt über viele ist der direkteste Indikator. Legen Sie eine Baseline für Ihre Umgebung fest und alarmieren Sie bei Abweichungen.
• Mehrere Sperren von derselben Quell-IP — Selbst verteilte Angriffe hinterlassen teilweise Muster. Wiederholte Sperren, die vom selben IP-Bereich oder ASN (Autonomous System Number) stammen, deuten auf automatisierte Aktivität hin.
• Unmögliche Reisen — Ein Benutzer, der sich von London und dann innerhalb von 30 Minuten von Singapur authentifiziert, löst in modernen SIEM- und Identity-Plattformen automatisch eine Markierung aus. Das Signal allein ist nicht schlüssig: VPN-Exit-Nodes, Split-Tunneling-Konfigurationen und Cloud-Proxy-Dienste produzieren routinemäßig False Positives. Der Wert liegt in der Untersuchung, die es auslöst — nicht in der Annahme, die es bestätigt.
• Hohes Anfragevolumen an Authentifizierungs-Endpunkte — Hunderte von POST-Anfragen pro Minute an /login oder /api/auth von einer einzelnen Quelle sind kein organischer Traffic. Überwachen Sie Ihre Login-Endpunkte auf Anfrageraten, die die menschliche Tippgeschwindigkeit überschreiten.
• Verteilte Low-and-Slow-Muster — Password Spraying vermeidet gezielt das Auslösen von Sperren pro Konto. Achten Sie auf ein Muster, bei dem viele verschiedene Konten jeweils genau einen oder zwei fehlgeschlagene Versuche innerhalb eines kurzen Zeitfensters erhalten — dies ist die Spraying-Signatur.
• Ungewöhnliche User-Agent-Strings oder fehlende Header — Automatisierte Tools senden oft Anfragen mit generischen oder fehlenden User-Agent-Strings, fehlenden Standard-Browser-Headern oder mit ungewöhnlichen TLS-Fingerprints.

Wie verhindert man Brute-Force-Angriffe?

Die Verteidigung gegen Brute Force ist ein Stack. Jede Schicht kompensiert die Schwächen der anderen.

Starke Passwortrichtlinien durchsetzen

Länge ist wichtiger als Komplexität. Eine 16-Zeichen-Passphrase ist exponentiell schwerer zu knacken als ein 8-Zeichen-String mit gemischten Zeichen. Bewegen Sie Ihre Organisation weg von Mindestlängen-Richtlinien, die technisch P@ssw0rd erlauben, hin zu Mindest-Entropie-Richtlinien, die echte Unvorhersehbarkeit erfordern. Lesen Sie Best Practices für Enterprise Password Management für ein strukturiertes Framework.

Schlüsselanforderungen gemäß NIST SP 800-63B:

• Mindestens 15 Zeichen für Konten ohne MFA; mindestens 8 mit durchgesetztem MFA
• Keine willkürlichen Komplexitätsregeln, die vorhersagbare Muster erzeugen
• Maximale Länge von mindestens 64 Zeichen zur Unterstützung von Passphrasen
• Blockieren von Passwörtern, die in Breach-Datenbanken erscheinen — neue Anmeldedaten bei der Erstellung gegen Dienste wie Have I Been Pwned prüfen, nicht erst danach

Anmeldedaten gegen Breach-Datenbanken prüfen

Bevor ein Passwort akzeptiert wird, überprüfen Sie, ob es nicht bereits in einem bekannten Datenleck aufgetaucht ist. NIST SP 800-63B und OWASP verlangen dies als separate Kontrolle — getrennt von Passwortlänge- oder Komplexitätsregeln. Ein Angreifer, der einen Dictionary-Angriff gegen Ihre Systeme ausführt, arbeitet mit denselben geleakten Datensätzen. Das Blockieren dieser Passwörter bei der Registrierung entfernt sie vollständig von der Angriffsfläche.

Multi-Faktor-Authentifizierung implementieren

MFA ist die wirksamste Einzelkontrolle gegen Credential-basierte Angriffe — ein kompromittiertes Passwort allein reicht nicht für den Zugang. Allerdings ist MFA nicht unfehlbar. MFA-Fatigue-Angriffe — bei denen Angreifer wiederholte Push-Benachrichtigungen senden, bis ein Benutzer aus Frustration eine genehmigt — haben MFA bei großen Organisationen umgangen. Phishing-resistente MFA-Methoden wie FIDO2 und Passkeys eliminieren diesen Vektor vollständig.

Kontosperren und progressive Verzögerungen konfigurieren

Konfigurieren Sie Authentifizierungssysteme so, dass Konten nach einer definierten Anzahl fehlgeschlagener Versuche (typischerweise 5–10) gesperrt werden, oder implementieren Sie progressive Verzögerungen, die mit jedem Fehlversuch exponentiell zunehmen. Progressive Verzögerungen sind oft vorzuziehen gegenüber harten Sperren, die selbst für Denial-of-Service gegen legitime Benutzer missbraucht werden können.

Rate Limiting auf IP- und ASN-Ebene anwenden

Kontosperren schützen einzelne Konten. Rate Limiting schützt den Authentifizierungs-Endpunkt selbst. Dies sind unterschiedliche Kontrollen mit unterschiedlichen Zielen. Begrenzen Sie die Anzahl der Anmeldeanfragen pro IP-Adresse pro Zeitfenster. Eskalieren Sie zu ASN-Level-Blockierung, wenn verteilte Muster auftreten.

CAPTCHA und Bot-Management einsetzen

CAPTCHA-Challenges unterscheiden menschliche Benutzer von automatisierten Skripten auf der Authentifizierungsebene. Moderne Bot-Management-Plattformen gehen weiter und analysieren Verhaltenssignale — Mausbewegung, Tipprhythmus, TLS-Fingerprints — um nicht-menschlichen Traffic zu identifizieren, bevor er das Anmeldeformular erreicht.

Zero-Trust-Architektur implementieren

Zero Trust basiert auf dem Prinzip, dass kein Benutzer, Gerät oder Netzwerksegment von Natur aus vertrauenswürdig ist. Selbst nach erfolgreicher Authentifizierung wird der Zugriff kontinuierlich basierend auf Kontext verifiziert: Gerätezustand, Standort, Verhalten und Least-Privilege-Zugriffsregeln. Wenn ein Brute-Force-Angriff ein Konto kompromittiert, begrenzt Zero Trust den Explosionsradius, indem laterale Bewegung zu anderen Systemen und Ressourcen verhindert wird.

Authentifizierungs-Logs überwachen und bei Anomalien alarmieren

Erkennung ist eine präventive Kontrolle, nicht nur eine reaktive. Das Erkennen eines laufenden Angriffs gibt Ihrem Team Zeit, die Quelle zu blockieren, Sitzungen ungültig zu machen und den Schaden einzudämmen. Konfigurieren Sie SIEM-Alarme für: Spitzen bei fehlgeschlagenen Authentifizierungsversuchen, Unmögliche-Reisen-Ereignisse, hohes Anfragevolumen an Login-Endpunkte und das Low-and-Slow-Spraying-Muster, bei dem viele Konten jeweils genau einen oder zwei Fehlversuche innerhalb eines kurzen Zeitfensters erhalten.

Einen Passwort-Manager verwenden

Passwortwiederverwendung ist der Treibstoff, der Credential Stuffing im großen Maßstab praktikabel macht. Wenn ein Breach Anmeldedaten offenlegt, wird jeder andere Dienst, bei dem dieses Passwort wiederverwendet wird, automatisch verwundbar — ohne zusätzlichen Aufwand des Angreifers. Ein Passwort-Manager eliminiert dies, indem er ein einzigartiges Passwort mit hoher Entropie für jedes Konto generiert und speichert, wodurch Wiederverwendung strukturell unmöglich wird.

Für einzelne Benutzer erreicht jeder seriöse Passwort-Manager dies. Für Teams und Organisationen sind die Anforderungen anders und die Einsätze höher.

Passwork wurde speziell für diese Umgebung entwickelt. Es bietet IT-Teams einen zentralisierten, strukturierten Tresor, in dem Anmeldedaten mit granularer, rollenbasierter Zugriffskontrolle organisiert sind: Jeder Benutzer sieht nur das, was seine Rolle erlaubt, nicht mehr. Geteilte Anmeldedaten werden in geteilten Tresoren mit definierten Berechtigungen gespeichert.

Mehrere Funktionen von Passwork adressieren direkt die in diesem Artikel behandelten Angriffsvektoren:

• Anpassbarer Passwort-Generator — erzwingt Längen- und Komplexitätsanforderungen bei der Erstellung, sodass die Richtlinien-Compliance nicht dem individuellen Urteil überlassen wird.
• Passwortsicherheits-Dashboard — verfolgt kontinuierlich den Status aller gespeicherten Anmeldedaten und markiert schwache, wiederverwendete, veraltete und potenziell kompromittierte Passwörter im gesamten Tresor. Wenn ein Mitarbeiter das Unternehmen verlässt, markiert Passwork automatisch jede Anmeldedaten, auf die diese Person Zugriff hatte, als potenziell kompromittiert und fordert zur Rotation auf.
• Zero-Knowledge-Client-seitige Verschlüsselung — Anmeldedaten werden auf der Client-Seite verschlüsselt, bevor sie den Server erreichen. Selbst mit vollem Zugriff auf die Datenbank oder die zugrundeliegende Infrastruktur erhält ein Angreifer nichts Lesbares. Der Verschlüsselungsschlüssel verlässt nie das Gerät des Benutzers.
• Vollständiges Audit-Log — jede Aktion im Tresor wird protokolliert: Wer hat auf was zugegriffen, wann und von wo. Dies ist die Sichtbarkeitsebene, die Post-Incident-Untersuchungen ermöglicht und die Compliance mit DSGVO, NIS2 und ähnlichen Frameworks unterstützt.
• Zwei-Faktor-Authentifizierung, Passkeys und Hardware-Sicherheitsschlüssel — Passwork unterstützt 2FA über Authenticator-Apps und WebAuthn-basierte Authentifizierung einschließlich Biometrie und FIDO2-Hardware-Schlüssel und fügt eine zweite Schicht über das Tresor-Passwort selbst hinaus hinzu.
• Konfigurierbare Kontosperre — Administratoren legen den Schwellenwert für fehlgeschlagene Anmeldeversuche fest, nach dem ein Konto gesperrt wird. Dies wendet Brute-Force- und Credential-Stuffing-Schutz auf Tresor-Ebene an — nicht nur am Netzwerkperimeter.
• Self-Hosted-Deployment — Passwork läuft vollständig innerhalb Ihrer eigenen Infrastruktur. Anmeldedaten verlassen nie Ihre Umgebung, werden auf Server- und Client-Seite mit AES-256 verschlüsselt (Zero-Knowledge-Architektur) und werden ausschließlich von Ihrem Team verwaltet.

Der JLR-Breach illustrierte, was ohne diese Struktur passiert: Anmeldedaten aus 2021, die einem Drittanbieter-Auftragnehmer gehörten, waren vier Jahre später noch gültig, ohne Rotation und ohne MFA auf der Jira-Instanz. Ein zentralisierter Tresor mit durchgesetzten Rotationsrichtlinien und einem Offboarding-Workflow hätte dieses Fenster geschlossen, bevor es ausgenutzt wurde.

Fazit

Brute-Force-Angriffe sind in der Praxis skalierbarer geworden. Günstige GPU-Rechenleistung, KI-gestützte Wordlist-Generierung und massive Botnets bedeuten, dass das, was einst erhebliche Ressourcen erforderte, jetzt fast keine mehr benötigt. Der 37-%-Anteil von Webanwendungsangriffen, die im Verizon DBIR 2025 Brute Force zugeschrieben werden, ist das Ergebnis dieser Zugänglichkeit.

Die gute Nachricht: Die Abwehrmaßnahmen funktionieren. MFA, starke und einzigartige Passwörter, Kontosperr-Richtlinien und Verhaltensüberwachung machen Brute-Force-Angriffe gemeinsam unpraktikabel gegen ein gehärtetes Ziel. Angreifer bewegen sich in Richtung des geringsten Widerstands — was bedeutet, dass Organisationen, die mehrschichtige Authentifizierungssicherheit effektiv implementieren, sich selbst aus dem Pool leichter Ziele entfernen.

Das eigentliche Risiko besteht darin, dass sie inkonsistent angewendet werden — ein Team nutzt MFA, ein anderes nicht. Geteilte Anmeldedaten in Tabellenkalkulationen gespeichert; Passwortrichtlinien, die auf dem Papier existieren, aber technisch nicht durchgesetzt werden. Das Schließen dieser Lücken ist, wo die eigentliche Arbeit liegt.

Passwork bietet IT-Teams einen strukturierten, prüffähigen Credential-Tresor mit rollenbasiertem Zugriff — entwickelt für Umgebungen, in denen Inkonsistenz Risiken schafft. Vollständiges Self-Hosted-Deployment und Zero-Knowledge-Verschlüsselung — auf Ihrer Infrastruktur vom ersten Tag an. Kostenlose Testversion erhalten

Häufig gestellte Fragen

Was ist der Unterschied zwischen einem Brute-Force-Angriff und einem Dictionary-Angriff?

Ein einfacher Brute-Force-Angriff probiert systematisch jede mögliche Zeichenkombination ohne Vorkenntnisse. Ein Dictionary-Angriff verwendet eine kuratierte Liste wahrscheinlicher Passwörter — gängige Wörter, bekannte Phrasen, geleakte Anmeldedaten — um den Suchraum zu reduzieren. Dictionary-Angriffe sind schneller und gezielter; einfache Brute Force ist erschöpfend, aber langsamer. Beide werden durch lange, zufällige Passwörter besiegt, die nicht natürlicher Sprache ähneln.

Können Brute-Force-Angriffe MFA umgehen?

Standard-Brute-Force kann MFA nicht direkt umgehen — ein korrektes Passwort allein reicht nicht für den Zugang. Allerdings nutzen Angreifer benachbarte Techniken: MFA-Fatigue (wiederholtes Senden von Push-Benachrichtigungen, bis der Benutzer eine genehmigt), Echtzeit-Phishing (Abfangen und Wiederverwenden von MFA-Token) und Session-Hijacking (Stehlen authentifizierter Sitzungscookies nach dem Login). Phishing-resistente MFA-Methoden wie FIDO2-Hardware-Schlüssel und Passkeys eliminieren die Phishing- und Fatigue-Vektoren vollständig.

Sind Brute-Force-Angriffe illegal?

Ja. Unbefugte Brute-Force-Angriffe gegen Systeme, die Sie nicht besitzen oder für die Sie keine ausdrückliche Genehmigung zum Testen haben, sind nach der Computerbetruggesetzgebung in den meisten Rechtsordnungen illegal — einschließlich des Computer Fraud and Abuse Act (CFAA) in den Vereinigten Staaten, des Computer Misuse Act im Vereinigten Königreich und der EU-Richtlinie über Angriffe auf Informationssysteme (2013/40/EU). Die Strafen umfassen erhebliche Geldstrafen und Freiheitsstrafen. Autorisierte Penetrationstests erfordern eine schriftliche Genehmigung des Systemeigentümers.

Wie lange dauert es, ein Passwort mit Brute Force zu knacken?

Das hängt von der Passwortlänge, dem Zeichensatz und der Art der Hash-Speicherung ab. Ein 8-Zeichen-MD5-gehashtes Passwort fällt in unter einer Stunde gegen einen modernen GPU-Cluster. Dasselbe Passwort, mit bcrypt bei hohem Kostenfaktor gehasht, kann auf derselben Hardware Jahre dauern. Länge ist die zuverlässigste Variable unter Ihrer Kontrolle: Jedes zusätzliche Zeichen multipliziert den Suchraum exponentiell. Eine 16-Zeichen-Passphrase gegen bcrypt ist mit aktueller Hardware rechnerisch unpraktikabel zu knacken.

Was ist Credential Stuffing und wie unterscheidet es sich von Brute Force?

Credential Stuffing verwendet verifizierte Benutzernamen/Passwort-Paare aus früheren Datenschutzverletzungen und testet sie gegen andere Dienste. Es rät nicht — es verwendet wieder. Brute Force generiert oder durchläuft Kombinationen ohne Vorkenntnisse über gültige Anmeldedaten. Credential Stuffing ist schneller und gezielter, weil es mit echten Anmeldedaten arbeitet, und es hat speziell wegen der Passwortwiederverwendung über Dienste hinweg Erfolg.

Welche Systeme werden am häufigsten von Brute-Force-Angriffen angegriffen?

Authentifizierungs-Endpunkte mit öffentlicher Exposition tragen das höchste Risiko: SSH- und RDP-Dienste, VPN-Portale, Webanwendungs-Anmeldeseiten, Admin-Panels (WordPress /wp-admin, cPanel) und API-Authentifizierungs-Endpunkte. Die Kampagne 2025, die 2,8 Millionen IPs nutzte, konzentrierte sich speziell auf VPN-Gateways und Firewalls — Perimeter-Geräte, die bei Kompromittierung direkten Zugang zu internen Netzwerken bieten.

Introducción

A las 3:14 AM, nadie está vigilando los registros de autenticación. Un script ejecutándose en una instancia en la nube alquilada envía su intento de inicio de sesión número diez mil a un portal VPN. A las 3:17 AM, recibe una respuesta diferente a las demás. Acceso concedido. No hay malware, ni ingeniería social, ni amenaza interna. Solo una contraseña débil, paciencia automatizada y una brecha en la supervisión.

Uno de cada tres ataques exitosos contra aplicaciones web ahora comienza de la misma manera: un script automatizado probando credenciales hasta que algo funciona. Según el Informe de Investigaciones de Filtraciones de Datos 2025 de Verizon, los ataques de fuerza bruta contra aplicaciones web básicas casi se triplicaron durante el último año — saltando de aproximadamente 20% a 60%. Es una señal de que los ataques automatizados de credenciales se han convertido en un arma principal, no en un recurso de respaldo.

La mecánica subyacente no ha cambiado: probar combinaciones hasta que una funcione. Lo que ha cambiado es la velocidad, escala e inteligencia detrás de esos intentos. Los clústeres de GPU modernos, la generación de listas de palabras asistida por IA y las botnets que abarcan millones de dispositivos comprometidos han transformado lo que alguna vez fue un ataque lento y ruidoso en algo rápido, distribuido y difícil de detectar.

Este artículo cubre qué son los ataques de fuerza bruta, cómo han evolucionado en 2026, las seis variantes principales, ejemplos del mundo real de 2025–2026 y una estrategia de defensa por capas que su equipo puede implementar hoy.

Puntos clave

• Los ataques de fuerza bruta son ataques automatizados de credenciales — los scripts prueban sistemáticamente combinaciones de nombre de usuario y contraseña hasta que una funciona, explotando contraseñas débiles, reutilizadas o predecibles en lugar de vulnerabilidades de software.
• Seis variantes distintas atacan diferentes debilidades: fuerza bruta simple, ataques de diccionario, credential stuffing, password spraying, fuerza bruta inversa y ataques híbridos — cada uno diseñado para evadir un conjunto específico de defensas.
• El hardware moderno ha hecho indefendibles las contraseñas débiles: un clúster de GPU puede descifrar una contraseña de 8 caracteres con hash MD5 en minutos. La longitud de la contraseña y el hash seguro son lo que determina la resistencia en el mundo real.
• Las defensas por capas funcionan, pero solo cuando se aplican consistentemente. MFA, políticas de contraseñas robustas, verificación contra bases de datos de filtraciones, bloqueo de cuentas, limitación de velocidad y un gestor de contraseñas hacen colectivamente que los ataques de fuerza bruta sean imprácticos. Cualquier brecha individual es suficiente para que un atacante la explote.
• La detección es un control preventivo, no solo reactivo. Reconocer las firmas de ataque — picos de inicios de sesión fallidos, patrones de spraying lentos y graduales, viajes imposibles — le da a su equipo tiempo para bloquear la fuente antes de que las credenciales sean validadas.
• Un gestor de contraseñas es la solución estructural para la reutilización de credenciales — la causa raíz detrás del credential stuffing. Para equipos, también impone la rotación, marca credenciales comprometidas y cierra la brecha de desvinculación que deja credenciales obsoletas válidas durante años.

¿Qué es un ataque de fuerza bruta?

Un ataque de fuerza bruta obtiene acceso no autorizado a un sistema probando sistemáticamente todas las combinaciones posibles de credenciales (nombres de usuario, contraseñas o claves de cifrado) hasta encontrar la correcta. Explota el comportamiento humano: contraseñas débiles, reutilizadas o predecibles.

Piénselo como probar cada llave de un llavero. Dado suficiente tiempo y potencia de cómputo, una eventualmente encajará. El objetivo del atacante es reducir ese tiempo a algo práctico y, en 2026, el hardware moderno lo hace cada vez más alcanzable.

Los ataques de fuerza bruta apuntan a endpoints de autenticación: páginas de inicio de sesión, servicios SSH y RDP, portales VPN, puertas de enlace API y paneles de administración. Cualquier sistema que acepte un nombre de usuario y contraseña es un objetivo potencial.

Cómo funcionan los ataques de fuerza bruta en 2026

En esencia, un ataque de fuerza bruta es automatización a escala. Un atacante despliega un script o herramienta que envía combinaciones de credenciales al endpoint de autenticación de un sistema objetivo en rápida sucesión. El script registra las coincidencias exitosas y continúa.

Lo que separa 2026 de hace una década es la infraestructura detrás de esos scripts.

El factor de la IA y el hardware

Las tarjetas gráficas modernas (originalmente diseñadas para juegos y aprendizaje automático) son excepcionalmente eficientes en computación paralela, que es exactamente lo que requiere el descifrado de contraseñas. Un clúster de 12 GPU NVIDIA RTX 5090 puede probar cientos de miles de millones de combinaciones de hash MD5 por segundo (Hive Systems).

Contra credenciales con hash débil, una contraseña de 8 caracteres cae en minutos — o menos. Contra bcrypt con configuraciones de costo modernas, el mismo hardware puede tardar años. La diferencia no está en el hardware del atacante. Está en si el sistema objetivo almacena las contraseñas de forma segura.

Los modelos de aprendizaje automático entrenados con conjuntos de datos de contraseñas filtradas (herramientas como PassGAN, construidas sobre redes generativas adversarias) aprenden distribuciones de contraseñas del mundo real sin reglas escritas por humanos. Predicen patrones probables: fechas de nacimiento añadidas a nombres, sustituciones comunes de caracteres, frases culturalmente específicas.

En pruebas contra el conjunto de datos de la filtración RockYou, PassGAN coincidió con el 47% de las contraseñas reales. Combinado con herramientas de descifrado convencionales, descubrió un 24% más de coincidencias que cualquiera de los enfoques por separado. El espacio de búsqueda no se reduce por fuerza bruta — se reduce por predicción.

La amenaza cuántica

La computación cuántica utiliza fenómenos mecánico-cuánticos para procesar información de maneras que las computadoras clásicas no pueden. Mientras un procesador clásico trabaja a través de posibilidades secuencialmente, un sistema cuántico evalúa muchos estados simultáneamente. Aplicado a la criptografía, ese paralelismo se convierte en una amenaza directa a los problemas matemáticos que sustentan el cifrado actual.

La computación cuántica introduce un riesgo a más largo plazo. La hoja de ruta cuántica de IBM proyecta que las computadoras cuánticas criptográficamente relevantes podrían socavar los estándares actuales de cifrado asimétrico dentro de esta década.

Los ataques cuánticos a contraseñas hasheadas siguen siendo teóricos, pero las organizaciones que gestionan secretos de larga duración y claves de cifrado deberían comenzar a evaluar los estándares de criptografía post-cuántica — NIST finalizó sus primeros estándares post-cuánticos en 2024.

Botnets y ataques distribuidos

Una botnet es una red de dispositivos comprometidos (servidores, routers, endpoints IoT, computadoras personales) controlados remotamente por un atacante sin el conocimiento de sus propietarios. Cada dispositivo actúa como un nodo independiente, capaz de enviar solicitudes, sondear sistemas o enviar intentos de inicio de sesión. La escala puede alcanzar millones de máquinas operando de forma coordinada.

Los atacantes rara vez operan desde una sola IP. Las campañas modernas de fuerza bruta usan botnets para distribuir intentos de inicio de sesión a través de diferentes direcciones de origen, evadiendo la limitación de velocidad basada en IP y el bloqueo geográfico.

A principios de 2025, la Shadowserver Foundation rastreó una campaña que utilizaba 2,8 millones de direcciones IP diariamente para atacar portales de inicio de sesión VPN de Palo Alto Networks, Ivanti y SonicWall (BleepingComputer).

Los nodos atacantes eran predominantemente routers MikroTik, Huawei y Cisco comprometidos — dispositivos secuestrados distribuidos en docenas de países, con el clúster más grande originándose en Brasil. El tráfico se enrutaba a través de redes de proxy residenciales, haciendo que cada intento pareciera provenir de un usuario doméstico normal en lugar de un bot. Las defensas estándar basadas en IP veían lo que parecía tráfico normal.

Tipos de ataques de fuerza bruta

Los ataques de fuerza bruta comparten un principio: obtener acceso probando sistemáticamente credenciales hasta que algo funcione. Los métodos difieren en qué prueban, cómo obtienen sus datos y qué defensas están diseñados para evadir.

1. Ataque de fuerza bruta simple

La variante más directa: cada combinación de caracteres posible se prueba en secuencia — aaa, aab, aac — hasta encontrar una coincidencia. No se requiere conocimiento previo del objetivo. El ataque depende enteramente de la potencia computacional.

Es efectivo solo contra contraseñas cortas o simples. Contra una contraseña de 8 caracteres usando caracteres mixtos, los clústeres de GPU modernos pueden completar la búsqueda en horas. Más allá de 12 caracteres, el mismo enfoque se vuelve computacionalmente impráctico — el espacio de búsqueda crece exponencialmente con cada carácter añadido.

2. Ataque de diccionario

Un ataque de diccionario reemplaza la enumeración exhaustiva con una lista curada de contraseñas probables (palabras, frases y credenciales conocidas), reduciendo drásticamente el espacio de búsqueda. El atacante apuesta por la previsibilidad humana en lugar de la computación bruta.

Estas listas van desde compilaciones básicas de las 10.000 contraseñas más comunes hasta conjuntos de datos de varios gigabytes construidos a partir de credenciales filtradas, jerga regional y terminología específica de la industria. Cualquier contraseña que se parezca al lenguaje natural es vulnerable. La aleatoriedad es la única defensa confiable.

3. Credential stuffing

El credential stuffing es la reutilización automatizada de pares de nombre de usuario y contraseña robados de filtraciones de datos anteriores. Los atacantes toman pares de nombre de usuario y contraseña y los prueban contra otros servicios, explotando el hecho de que muchos usuarios reutilizan las mismas credenciales en múltiples cuentas.

En julio de 2024, una compilación de casi 10 mil millones de contraseñas únicas — denominada RockYou2024 — fue publicada en un foro criminal, proporcionando a los atacantes un conjunto de credenciales sin precedentes del cual trabajar (Cybernews, 2024).

Comprender los peligros de la reutilización de contraseñas es un contexto esencial aquí — una sola cuenta comprometida en una plataforma puede propagarse en acceso a través de toda una huella digital.

4. Password spraying

El password spraying invierte el enfoque típico. En lugar de probar muchas contraseñas contra una cuenta (lo que activa bloqueos), el atacante prueba una o dos contraseñas comunes — Password1!, Welcome2026 — en miles de cuentas.

Se mantiene por debajo de los umbrales de bloqueo y es particularmente efectivo contra grandes organizaciones con políticas de contraseñas débiles. Más del 97% de los ataques de identidad involucran password spraying o fuerza bruta, según el Informe de Defensa Digital de Microsoft 2025.

5. Ataque de fuerza bruta inversa

Un ataque de fuerza bruta inversa comienza con una contraseña conocida (típicamente obtenida de una filtración o un valor predeterminado conocido) y la prueba sistemáticamente contra una lista de nombres de usuario. La credencial está fija; la identidad es la incógnita.

Este método es más efectivo cuando la contraseña objetivo es ampliamente compartida: una contraseña corporativa predeterminada distribuida durante la incorporación, un patrón común exigido por una política débil, o una credencial que apareció en una filtración anterior. Donde un ataque estándar sondea una cuenta en profundidad, un ataque inverso sondea muchas cuentas con precisión quirúrgica.

6. Ataque híbrido de fuerza bruta

Un ataque híbrido de fuerza bruta combina palabras de diccionario con mutaciones programáticas — añadiendo números, años o caracteres especiales (Summer2026!, admin@123), sustituyendo letras con símbolos o cambiando mayúsculas. Está diseñado para descifrar contraseñas que parecen complejas pero siguen patrones de construcción predecibles.

Estos ataques apuntan a la brecha entre la política de contraseñas y el comportamiento humano. Cuando se requiere que los usuarios «compliquen» una contraseña, rara vez introducen verdadera aleatoriedad — añaden 1! a una palabra familiar o ponen en mayúscula la primera letra. Los ataques híbridos están construidos para explotar exactamente ese instinto, haciendo que los requisitos de complejidad basados en reglas sean una defensa más débil que la longitud sola.

Tabla comparativa de ataques de fuerza bruta

Gestionar credenciales en un equipo grande crea exactamente la superficie de ataque que explotan las campañas de fuerza bruta. Vea cómo Passwork estructura bóvedas de equipo con acceso basado en roles y políticas de contraseñas aplicadas

Ejemplos reales de ataques de fuerza bruta (2025)

Los ataques de fuerza bruta y credential stuffing continúan siendo una amenaza significativa, evolucionando en sofisticación y escala. Los siguientes casos de 2025 y 2026 destacan los riesgos persistentes y la importancia crítica de prácticas robustas de autenticación y seguridad.

Fondos de jubilación australianos — marzo 2025

Tipo de ataque: Credential stuffing (coordinado, multi-objetivo).

Durante el fin de semana del 29–30 de marzo de 2025, cinco importantes fondos de pensiones australianos (AustralianSuper, REST Super, Hostplus, Australian Retirement Trust e Insignia Financial) fueron atacados simultáneamente usando listas combinadas de filtraciones anteriores no relacionadas. Más de 20.000 cuentas fueron comprometidas.

Cuatro miembros de AustralianSuper perdieron colectivamente 500.000 AUD. REST cerró su portal MemberAccess por completo después de que ~8.000 miembros tuvieran datos personales expuestos.

23andMe — 2023 → consecuencias regulatorias en 2025

Tipo de ataque: Credential stuffing

Entre abril y septiembre de 2023, los atacantes probaron credenciales de filtraciones no relacionadas contra cuentas de 23andMe. A través de la función DNA Relatives, los compromisos iniciales se propagaron en exposición de datos genéticos y de ascendencia pertenecientes a aproximadamente 6,9 millones de usuarios — la mayoría de los cuales nunca habían sido atacados directamente.

«Mega filtración» — 16 mil millones de credenciales expuestas — junio 2025

Tipo de ataque: Credential stuffing (datos fuente)

En junio de 2025, investigadores de Cybernews descubrieron ~30 conjuntos de datos que contenían más de 16 mil millones de registros de inicio de sesión — URL, nombres de usuario y contraseñas en texto plano. Los datos fueron recolectados principalmente por malware infostealer dirigido a dispositivos de consumidores. Las plataformas afectadas incluyeron Google, Apple, Facebook y otras. Notablemente, BleepingComputer confirmó que los conjuntos de datos incluyen una proporción significativa de credenciales recicladas de filtraciones anteriores, lo que significa que no todos los registros representan exposiciones nuevas.

Jaguar Land Rover — marzo 2025 + septiembre 2025

Tipo de ataque: Credential stuffing / credenciales robadas (fuente infostealer)

En marzo de 2025, el grupo de ransomware HELLCAT vulneró JLR usando credenciales de Jira robadas recolectadas mediante malware infostealer. El actor de amenazas «Rey» filtró ~700 documentos internos el 10 de marzo. Días después, un segundo actor «APTS» usó credenciales que databan de 2021 — pertenecientes a un contratista externo — para acceder al mismo servidor Jira y filtrar ~350 GB adicionales de datos incluyendo código fuente, registros de desarrollo y expedientes de empleados.

En septiembre de 2025, un ataque separado atribuido a un grupo que se autodenominaba «Scattered Spider Lapsus$ Hunters» paralizó los sistemas de TI globales y detuvo la fabricación en la planta de Halewood, enviando a los empleados a casa.

Tabla resumen

Cómo detectar un ataque de fuerza bruta

La prevención es el objetivo, pero la detección es la red de seguridad. Los ataques de fuerza bruta dejan firmas consistentes en los registros de autenticación — si sabe qué buscar.

• Picos en intentos de inicio de sesión fallidos — Un aumento repentino en fallos de autenticación contra una sola cuenta, o distribuidos en muchas, es el indicador más directo. Establezca una línea base para su entorno y alerte sobre desviaciones.
• Múltiples bloqueos desde la misma IP de origen — Incluso los ataques distribuidos dejan patrones parciales. Bloqueos repetidos originados desde el mismo rango de IP o ASN (Número de Sistema Autónomo) sugieren actividad automatizada.
• Viaje imposible — Un usuario autenticándose desde Londres y luego desde Singapur en 30 minutos activa una alerta automática en plataformas SIEM y de identidad modernas. La señal por sí sola no es concluyente: los nodos de salida VPN, las configuraciones de túnel dividido y los servicios de proxy en la nube producen rutinariamente falsos positivos. El valor está en la investigación que provoca — no en la suposición que confirma.
• Alto volumen de solicitudes a endpoints de autenticación — Cientos de solicitudes POST por minuto a /login o /api/auth desde una sola fuente no es tráfico orgánico. Supervise sus endpoints de inicio de sesión para tasas de solicitud que excedan la velocidad de escritura humana.
• Patrones distribuidos lentos y graduales — El password spraying específicamente evita activar bloqueos por cuenta. Busque un patrón donde muchas cuentas diferentes reciben exactamente uno o dos intentos fallidos dentro de una ventana corta — esta es la firma del spraying.
• Cadenas de user-agent inusuales o encabezados faltantes — Las herramientas automatizadas a menudo envían solicitudes con cadenas de user-agent genéricas o ausentes, encabezados de navegador estándar faltantes o con huellas TLS inusuales.

Cómo prevenir ataques de fuerza bruta

La defensa contra la fuerza bruta es una pila. Cada capa compensa las debilidades de las otras.

Aplicar políticas de contraseñas robustas

La longitud importa más que la complejidad. Una frase de contraseña de 16 caracteres es exponencialmente más difícil de descifrar que una cadena de 8 caracteres de caracteres mixtos. Aleje a su organización de políticas de longitud mínima que técnicamente permiten P@ssw0rd y muévase hacia políticas de entropía mínima que requieran verdadera imprevisibilidad. Revise las mejores prácticas de gestión de contraseñas empresariales para un marco estructurado.

Requisitos clave según NIST SP 800-63B:

• Mínimo 15 caracteres para cuentas sin MFA; mínimo 8 con MFA aplicado
• Sin reglas de complejidad arbitrarias que produzcan patrones predecibles
• Longitud máxima de al menos 64 caracteres para soportar frases de contraseña
• Bloquear contraseñas que aparezcan en bases de datos de filtraciones — verificar nuevas credenciales contra servicios como Have I Been Pwned en el momento de creación, no después

Verificar credenciales contra bases de datos de filtraciones

Antes de aceptar una contraseña, verifique que no haya aparecido ya en una filtración de datos conocida. NIST SP 800-63B y OWASP requieren esto como un control distinto — separado de las reglas de longitud o complejidad de contraseña. Un atacante ejecutando un ataque de diccionario contra sus sistemas está trabajando con los mismos conjuntos de datos filtrados. Bloquear esas contraseñas en el registro las elimina de la superficie de ataque por completo.

Implementar autenticación multifactor

MFA es el control individual más efectivo contra ataques basados en credenciales — una contraseña comprometida por sí sola no es suficiente para el acceso. Dicho esto, MFA no es infalible. Los ataques de fatiga MFA — donde los atacantes envían notificaciones push repetidas hasta que un usuario aprueba una por frustración — han evadido MFA en organizaciones importantes. Los métodos MFA resistentes al phishing como FIDO2 y passkeys eliminan este vector por completo.

Configurar bloqueos de cuenta y retrasos progresivos

Configure los sistemas de autenticación para bloquear cuentas después de un número definido de intentos fallidos (típicamente 5–10), o implemente retrasos progresivos que aumenten exponencialmente con cada fallo. Los retrasos progresivos son a menudo preferibles a los bloqueos duros, que pueden ser utilizados como arma para denegación de servicio contra usuarios legítimos.

Aplicar limitación de velocidad a nivel de IP y ASN

El bloqueo de cuenta protege cuentas individuales. La limitación de velocidad protege el endpoint de autenticación en sí. Estos son controles diferentes con objetivos diferentes. Restrinja el número de solicitudes de inicio de sesión por dirección IP por ventana de tiempo. Escale al bloqueo a nivel de ASN cuando surjan patrones distribuidos.

Desplegar CAPTCHA y gestión de bots

Los desafíos CAPTCHA diferencian usuarios humanos de scripts automatizados en la capa de autenticación. Las plataformas modernas de gestión de bots van más allá, analizando señales de comportamiento — movimiento del ratón, cadencia de escritura, huellas TLS — para identificar tráfico no humano antes de que llegue al formulario de inicio de sesión.

Implementar arquitectura de confianza cero

La confianza cero opera bajo el principio de que ningún usuario, dispositivo o segmento de red es inherentemente confiable. Incluso después de una autenticación exitosa, el acceso se verifica continuamente según el contexto: salud del dispositivo, ubicación, comportamiento y reglas de acceso de mínimo privilegio. Si un ataque de fuerza bruta compromete una cuenta, la confianza cero limita el radio de explosión previniendo el movimiento lateral a otros sistemas y recursos.

Supervisar registros de autenticación y alertar sobre anomalías

La detección es un control preventivo, no solo reactivo. Detectar un ataque en progreso le da a su equipo tiempo para bloquear la fuente, invalidar sesiones y contener el daño. Configure alertas SIEM para: picos en intentos de autenticación fallidos, eventos de viaje imposible, alto volumen de solicitudes a endpoints de inicio de sesión y el patrón de spraying lento y gradual donde muchas cuentas reciben exactamente uno o dos fallos dentro de una ventana corta.

Usar un gestor de contraseñas

La reutilización de contraseñas es el combustible que hace viable el credential stuffing a escala. Cuando una filtración expone una credencial, cada otro servicio donde esa contraseña se reutiliza se vuelve vulnerable — automáticamente, sin ningún esfuerzo adicional del atacante. Un gestor de contraseñas elimina esto generando y almacenando una contraseña única de alta entropía para cada cuenta, haciendo la reutilización estructuralmente imposible.

Para usuarios individuales, cualquier gestor de contraseñas de buena reputación logra esto. Para equipos y organizaciones, los requisitos son diferentes y los riesgos son mayores.

Passwork está construido específicamente para este entorno. Proporciona a los equipos de TI una bóveda centralizada y estructurada donde las credenciales se organizan con control de acceso granular basado en roles: cada usuario ve solo lo que su rol permite, nada más. Las credenciales compartidas se almacenan en bóvedas compartidas con permisos definidos.

Varias características de Passwork abordan directamente los vectores de ataque cubiertos en este artículo:

• Generador de contraseñas personalizable — aplica requisitos de longitud y complejidad en el momento de creación, para que el cumplimiento de políticas no quede al juicio individual.
• Panel de seguridad de contraseñas — rastrea continuamente el estado de todas las credenciales almacenadas, marcando contraseñas débiles, reutilizadas, obsoletas y potencialmente comprometidas en toda la bóveda. Cuando un empleado se va, Passwork marca automáticamente cada credencial a la que tenía acceso como potencialmente comprometida y solicita la rotación.
• Cifrado de conocimiento cero del lado del cliente — las credenciales se cifran en el lado del cliente antes de llegar al servidor. Incluso con acceso completo a la base de datos o la infraestructura subyacente, un atacante no recupera nada legible. La clave de cifrado nunca sale del dispositivo del usuario.
• Registro de auditoría completo — cada acción en la bóveda se registra: quién accedió a qué, cuándo y desde dónde. Esta es la capa de visibilidad que hace posible la investigación post-incidente y apoya el cumplimiento con GDPR, NIS2 y marcos similares.
• Autenticación de dos factores, passkeys y llaves de seguridad de hardware — Passwork soporta 2FA mediante aplicaciones de autenticación y autenticación basada en WebAuthn incluyendo biometría y llaves de hardware FIDO2, añadiendo una segunda capa más allá de la contraseña de la bóveda en sí.
• Bloqueo de cuenta configurable — los administradores establecen el umbral de intentos de inicio de sesión fallidos después del cual una cuenta se bloquea. Esto aplica protección contra fuerza bruta y credential stuffing a nivel de la bóveda misma — no solo en el perímetro de red.
• Despliegue autoalojado — Passwork se ejecuta completamente dentro de su propia infraestructura. Los datos de credenciales nunca salen de su entorno, se cifran con AES-256 tanto en el lado del servidor como del cliente (arquitectura de conocimiento cero), y son gestionados exclusivamente por su equipo.

La filtración de JLR ilustró lo que sucede sin esta estructura: las credenciales de 2021 pertenecientes a un contratista externo seguían siendo válidas cuatro años después, sin rotación y sin MFA en la instancia de Jira. Una bóveda centralizada con políticas de rotación aplicadas y un flujo de trabajo de desvinculación habría cerrado esa ventana antes de que fuera explotada.

Conclusión

Los ataques de fuerza bruta se han vuelto más escalables en la práctica. La computación GPU barata, la generación de listas de palabras asistida por IA y las botnets masivas significan que lo que antes requería recursos significativos ahora no requiere casi ninguno. El 37% de los ataques a aplicaciones web atribuidos a fuerza bruta en el DBIR 2025 de Verizon es el resultado de esa accesibilidad.

La buena noticia: las defensas funcionan. MFA, contraseñas robustas y únicas, políticas de bloqueo de cuenta y supervisión del comportamiento hacen colectivamente que los ataques de fuerza bruta sean imprácticos contra un objetivo endurecido. Los atacantes se mueven hacia la menor resistencia — lo que significa que las organizaciones que implementan seguridad de autenticación por capas efectivamente se eliminan del grupo de objetivos fáciles.

El riesgo real es que se aplican inconsistentemente — un equipo usando MFA, otro no. Credenciales compartidas almacenadas en hojas de cálculo; políticas de contraseñas que existen en papel pero no se aplican técnicamente. Cerrar esas brechas es donde está el verdadero trabajo.

Passwork proporciona a los equipos de TI una bóveda de credenciales estructurada y auditable con acceso basado en roles — construida para los entornos donde la inconsistencia crea riesgo. Despliegue autoalojado completo y cifrado de conocimiento cero — en su infraestructura desde el primer día. Obtener prueba gratuita

Preguntas frecuentes

¿Cuál es la diferencia entre un ataque de fuerza bruta y un ataque de diccionario?

Un ataque de fuerza bruta simple prueba cada combinación de caracteres posible sistemáticamente, sin conocimiento previo. Un ataque de diccionario usa una lista curada de contraseñas probables — palabras comunes, frases conocidas, credenciales filtradas — para reducir el espacio de búsqueda. Los ataques de diccionario son más rápidos y dirigidos; la fuerza bruta simple es exhaustiva pero más lenta. Ambos son derrotados por contraseñas largas y aleatorias que no se parezcan al lenguaje natural.

¿Pueden los ataques de fuerza bruta evadir MFA?

La fuerza bruta estándar no puede evadir MFA directamente — una contraseña correcta por sí sola no es suficiente para el acceso. Sin embargo, los atacantes usan técnicas adyacentes: fatiga MFA (enviar notificaciones push repetidas hasta que el usuario apruebe una), phishing en tiempo real (capturar y reproducir tokens MFA), y secuestro de sesión (robar cookies de sesión autenticadas después del inicio de sesión). Los métodos MFA resistentes al phishing como las llaves de hardware FIDO2 y passkeys eliminan los vectores de phishing y fatiga por completo.

¿Son ilegales los ataques de fuerza bruta?

Sí. Los ataques de fuerza bruta no autorizados contra sistemas que usted no posee o no tiene permiso explícito para probar son ilegales bajo la legislación de fraude informático en la mayoría de las jurisdicciones — incluyendo la Ley de Fraude y Abuso Informático (CFAA) en Estados Unidos, la Ley de Uso Indebido de Computadoras en el Reino Unido, y la Directiva de la UE sobre Ataques contra Sistemas de Información (2013/40/UE). Las sanciones incluyen multas significativas y prisión. Las pruebas de penetración autorizadas requieren permiso escrito del propietario del sistema.

¿Cuánto tiempo lleva descifrar una contraseña con fuerza bruta?

Depende de la longitud de la contraseña, el conjunto de caracteres y cómo se almacena el hash. Una contraseña de 8 caracteres con hash MD5 cae en menos de una hora contra un clúster de GPU moderno. La misma contraseña hasheada con bcrypt a un factor de costo alto puede tardar años en el mismo hardware. La longitud es la variable más confiable bajo su control: cada carácter adicional multiplica el espacio de búsqueda exponencialmente. Una frase de contraseña de 16 caracteres contra bcrypt es computacionalmente impráctico de descifrar con el hardware actual.

¿Qué es el credential stuffing y en qué se diferencia de la fuerza bruta?

El credential stuffing usa pares verificados de nombre de usuario/contraseña de filtraciones de datos anteriores y los prueba contra otros servicios. No adivina — reutiliza. La fuerza bruta genera o cicla a través de combinaciones sin conocimiento previo de credenciales válidas. El credential stuffing es más rápido y dirigido porque trabaja con credenciales reales, y tiene éxito específicamente debido a la reutilización de contraseñas entre servicios.

¿Qué sistemas son más comúnmente atacados por ataques de fuerza bruta?

Los endpoints de autenticación con exposición pública conllevan el mayor riesgo: servicios SSH y RDP, portales VPN, páginas de inicio de sesión de aplicaciones web, paneles de administración (WordPress /wp-admin, cPanel) y endpoints de autenticación API. La campaña de 2025 que utilizó 2,8 millones de IP se centró específicamente en puertas de enlace VPN y firewalls — dispositivos perimetrales que, si se comprometen, proporcionan acceso directo a las redes internas.

Introduction

At 3:14 AM, no one is watching the authentication logs. A script running on a rented cloud instance sends its ten-thousandth login attempt to a VPN portal. At 3:17 AM, it gets a response that's different from the others. Access granted. There is no malware, no social engineering, no insider threat. Just a weak password, automated patience, and a gap in monitoring.

One in three successful attacks against web applications now begins the same way: an automated script cycling through credentials until something works. According to the 2025 Verizon Data Breach Investigations Report, brute force attacks against basic web applications nearly tripled over the last year — jumping from roughly 20% to 60%. It's a signal that automated credential attacks have become a primary weapon, not a fallback.

The underlying mechanics haven't changed: try combinations until one works. What has changed is the speed, scale, and intelligence behind those attempts. Modern GPU clusters, AI-assisted wordlist generation, and botnets spanning millions of compromised devices have transformed  what was once a slow, noisy attack into something fast, distributed, and difficult to detect.

This article covers what brute force attacks are, how they’ve evolved in 2026, the six main variants, real-world examples from 2025–2026, and a layered defense strategy your team can implement today.

Key takeaways

• Brute force attacks are automated credential attacks — scripts systematically cycle through username and password combinations until one works, exploiting weak, reused, or predictable passwords rather than software vulnerabilities.
• Six distinct variants target different weaknesses: simple brute force, dictionary attacks, credential stuffing, password spraying, reverse brute force, and hybrid attacks — each designed to bypass a specific set of defenses.
• Modern hardware has made weak passwords indefensible: a GPU cluster can crack an 8-character MD5-hashed password in minutes. Password length and secure hashing are what determine real-world resistance.
• Layered defenses work but only when consistently enforced. MFA, strong password policies, breach database screening, account lockouts, rate limiting, and a password manager collectively make brute force attacks impractical. Any single gap is enough for an attacker to exploit.
• Detection is a preventive control, not just a reactive one. Recognizing attack signatures — failed login spikes, low-and-slow spraying patterns, impossible travel — gives your team time to block the source before credentials are validated.
• A password manager is the structural fix for credential reuse — the root cause behind credential stuffing. For teams, it also enforces rotation, flags compromised credentials, and closes the offboarding gap that leaves stale credentials valid for years.

What is a brute force attack?

A brute force attack gains unauthorized access to a system by systematically trying every possible combination of credentials (usernames, passwords, or encryption keys) until the correct one is found. It exploits  human behavior: weak, reused, or predictable passwords.

Think of it as trying every key on a keyring. Given enough time and computing power, one will eventually fit. The attacker's goal is to reduce that time to something practical and in 2026, modern hardware makes that increasingly achievable.

Brute force attacks target authentication endpoints: login pages, SSH and RDP services, VPN portals, API gateways, and admin panels. Any system that accepts a username and password is a potential target.

How brute force attacks work in 2026

At its core, a brute force attack is automation at scale. An attacker deploys a script or tool that sends credential combinations to a target system's authentication endpoint in rapid succession. The script logs successful matches and moves on.

What separates 2026 from a decade ago is the infrastructure behind those scripts.

The AI and hardware factor

Modern graphics cards (originally designed for gaming and machine learning) are exceptionally efficient at parallel computation, which is exactly what password cracking requires. A cluster of 12 NVIDIA RTX 5090 GPUs can test hundreds of billions of MD5 hash combinations per second (Hive Systems).

Against weakly hashed credentials, an 8-character password falls in minutes — or less. Against bcrypt with modern cost settings, the same hardware may take years. The difference isn't the attacker's hardware. It's whether the target system stores passwords securely.

Machine learning models trained on leaked password datasets (tools like PassGAN, built on generative adversarial networks) learn real-world password distributions without human-written rules. They predict likely patterns: birthdays appended to names, common character substitutions, culturally specific phrases.

In testing against the RockYou breach dataset, PassGAN matched 47% of real passwords. Сombined with conventional cracking tools, it uncovered 24% more matches than either approach alone. The search space doesn't shrink by brute force — it shrinks by prediction.

The quantum threat

Quantum computing uses quantum-mechanical phenomena to process information in ways classical computers cannot. Where a classical processor works through possibilities sequentially, a quantum system evaluates many states simultaneously. Applied to cryptography, that parallelism becomes a direct threat to the mathematical problems that underpin current encryption.

Quantum computing introduces a longer-term risk. IBM's quantum roadmap projects that cryptographically relevant quantum computers could undermine current asymmetric encryption standards within this decade.

Quantum  attacks on hashed passwords remain theoretical, but organizations managing long-lived secrets and encryption keys should begin evaluating post-quantum cryptography standards — NIST finalized its first post-quantum standards in 2024.

Botnets and distributed attacks

A botnet is a network of compromised devices (servers, routers, IoT endpoints, personal computers) controlled remotely by an attacker without their owners' knowledge. Each device acts as an independent node, capable of sending requests, probing systems, or submitting login attempts. The scale can reach millions of machines operating in coordination.

Attackers rarely operate from a single IP. Modern brute force campaigns use botnets to distribute login attempts across different source addresses, bypassing IP-based rate limiting and geographic blocking.

In early 2025, the Shadowserver Foundation tracked a campaign using 2.8 million IP addresses daily to target  VPN login portals from Palo Alto Networks, Ivanti, and SonicWall (BleepingComputer).

The attacking nodes were predominantly compromised MikroTik, Huawei, and Cisco routers — hijacked devices spread across dozens of countries, with the largest cluster originating from Brazil. The traffic was routed through residential proxy networks, making each attempt appear to come from a regular home user rather than a bot. Standard IP-based defenses saw what looked like normal traffic.

Types of brute force attacks

Brute force attacks share one principle: gain access by systematically testing credentials until something works. The methods differ in what they test, how they source their data, and which defenses they're designed to bypass.

1. Simple brute force attack

The most straightforward variant: every possible character combination is tried in sequence — aaa, aab, aac — until a match is found. No prior knowledge of the target is required. The attack relies entirely on computational power.

It is effective only against short or simple passwords. Against an 8-character password using mixed characters, modern GPU clusters can complete the search in hours. Beyond 12 characters, the same approach becomes computationally impractical — the search space grows exponentially with each added character.

2. Dictionary attack

A dictionary attack replaces exhaustive enumeration with a curated list of likely passwords (words, phrases, and known credentials) dramatically narrowing the search space. The attacker bets on human predictability rather than raw computation.

These lists range from basic compilations of the 10,000 most common passwords to multi-gigabyte datasets built from leaked credentials, regional slang, and industry-specific terminology. Any password that resembles natural language is vulnerable. Randomness is the only reliable defense.

3. Credential stuffing

Credential stuffing is the automated reuse of username and password pairs stolen from previous data breaches. Attackers take username and password pairs and test them against other services, exploiting the fact that many users reuse the same credentials across multiple accounts.

In July 2024, a compilation of nearly 10 billion unique passwords — dubbed RockYou2024 — was posted on a criminal forum, providing attackers with an unprecedented pool of credentials to work from (Cybernews, 2024).

Understanding the dangers of password reuse is essential context here — a single compromised account on one platform can cascade into access across an entire digital footprint.

4. Password spraying

Password spraying inverts the typical approach. Rather than trying many passwords against one account (which triggers lockouts), the attacker tries one or two common passwords — Password1!, Welcome2026 — across thousands of accounts.

It stays below lockout thresholds and is particularly effective against large organizations with weak password policies. Over 97% of identity attacks involve password spray or brute force, according to Microsoft Digital Defence Report 2025.

5. Reverse brute force attack

A reverse brute force attack starts with a known password (typically sourced from a breach or a known default) and tests it systematically against a list of usernames. The credential is fixed; the identity is the unknown.

This method is most effective when the target password is widely shared: a default corporate password distributed during onboarding, a common pattern mandated by a weak policy, or a credential that appeared in a previous leak. Where a standard attack probes one account deeply, a reverse attack probes many accounts with surgical precision.

6. Hybrid brute force attack

A hybrid brute force attack combines dictionary words with programmatic mutations — appending numbers, years, or special characters (Summer2026!, admin@123), substituting letters with symbols, or shifting capitalization. It is designed to crack passwords that appear complex but follow predictable construction patterns.

These attacks target the gap between password policy and human behavior. When users are required to "complicate" a password, they rarely introduce true randomness — they append 1! to a familiar word or capitalize the first letter. Hybrid attacks are built to exploit exactly that instinct, making rule-based complexity requirements a weaker defense than length alone.

Brute force attack comparison table

Managing credentials across a large team creates exactly the attack surface brute force campaigns exploit. See how Passwork structures team vaults with role-based access and enforced password policies

Real-world brute force attack examples (2025)

Brute force and credential stuffing attacks continue to be a significant threat, evolving in sophistication and scale. The following cases from 2025 and 2026 highlight the persistent risks and the critical importance of robust authentication and security practices.

Australian superannuation funds — March 2025

Attack type: Credential stuffing (coordinated, multi-target).

Over the weekend of 29–30 March 2025, five major Australian pension funds (AustralianSuper, REST Super, Hostplus, Australian Retirement Trust, and Insignia Financial) were simultaneously targeted using combo lists from unrelated prior breaches. Over 20,000 accounts were compromised.

Four AustralianSuper members collectively lost AUD 500,000. REST shut down its MemberAccess portal entirely after ~8,000 members had personal data exposed.

23andMe — 2023 → regulatory consequences in 2025

Attack type: Credential stuffing

Between April and September 2023, attackers tested credentials from unrelated breaches against 23andMe accounts. Through the DNA Relatives feature, initial compromises cascaded into exposure of genetic and ancestry data belonging to approximately 6.9 million users — most of whom had never been directly targeted.

"Mega Leak" — 16 billion credentials exposed — June 2025

Attack type: Credential stuffing (source data)

In June 2025, Cybernews researchers discovered ~30 datasets containing over 16 billion login records — URLs, usernames, and plaintext passwords. The data was harvested primarily by infostealer malware targeting consumer devices. Platforms affected included Google, Apple, Facebook, and others. Notably, BleepingComputer confirmed the datasets include a significant proportion of recycled credentials from older breaches, meaning not all records represent fresh exposures.

Jaguar Land Rover — March 2025 + September 2025

Attack type: Credential stuffing / stolen credentials (infostealer-sourced)

In March 2025, the HELLCAT ransomware group breached JLR using stolen Jira credentials harvested via infostealer malware. Threat actor "Rey" leaked ~700 internal documents on 10 March. Days later, a second actor "APTS" used credentials dating back to 2021 — belonging to a third-party contractor — to access the same Jira server and leak an additional ~350 GB of data including source code, development logs, and employee records.

In September 2025, a separate attack attributed to a group calling itself "Scattered Spider Lapsus$ Hunters" shut down global IT systems and halted manufacturing at the Halewood plant, with employees sent home.

Summary table

How to detect a brute force attack

Prevention is the goal, but detection is the safety net. Brute force attacks leave consistent signatures in authentication logs — if you know what to look for.

• Spikes in failed login attempts — A sudden increase in authentication failures against a single account, or spread across many, is the most direct indicator. Establish a baseline for your environment and alert on deviations.
• Multiple lockouts from the same source IP — Even distributed attacks leave partial patterns. Repeated lockouts originating from the same IP range or ASN (Autonomous System Number) suggest automated activity.
• Impossible travel — A user authenticating from London and then from Singapore within 30 minutes triggers an automatic flag in modern SIEM and identity platforms. The signal alone is not conclusive: VPN exit nodes, split-tunneling configurations, and cloud proxy services routinely produce false positives. The value is in the investigation it prompts — not the assumption it confirms.
• High request volume to authentication endpoints — Hundreds of POST requests per minute to /login or /api/auth from a single source is not organic traffic. Monitor your login endpoints for request rates that exceed human typing speed.
• Distributed low-and-slow patterns — Password spraying specifically avoids triggering per-account lockouts. Look for a pattern where many different accounts each receive exactly one or two failed attempts within a short window — this is the spraying signature.
• Unusual user-agent strings or missing headers — Automated tools often send requests with generic or absent user-agent strings, missing standard browser headers, or with unusual TLS fingerprints.

How to prevent brute force attacks

Defense against brute force is a stack. Each layer compensates for the weaknesses of the others.

Enforce strong password policies

Length matters more than complexity. A 16-character passphrase is exponentially harder to crack than an 8-character string of mixed characters. Move your organization away from minimum-length policies that technically permit P@ssw0rd and toward minimum-entropy policies that require genuine unpredictability. Review enterprise password management best practices for a structured framework.

Key requirements per NIST SP 800-63B:

• Minimum 15 characters for accounts without MFA; minimum 8 with MFA enforced
• No arbitrary complexity rules that produce predictable patterns
• Maximum length of at least 64 characters to support passphrases
• Block passwords that appear in breach databases — check new credentials against services like Have I Been Pwned at the point of creation, not after the fact

Screen credentials against breach databases

Before a password is accepted, verify it hasn't already appeared in a known data breach. NIST SP 800-63B and OWASP both require this as a distinct control — separate from password length or complexity rules. An attacker running a dictionary attack against your systems is working from the same leaked datasets. Blocking those passwords at registration removes them from the attack surface entirely.

Implement multi-factor authentication

MFA is the single most effective control against credential-based attacks — a compromised password alone is not enough  for access. That said , MFA is not infallible. MFA fatigue attacks — where attackers send repeated push notifications until a user approves one out of frustration — have bypassed MFA at major organizations. Phishing-resistant MFA methods such as FIDO2 and passkeys  eliminate this vector entirely. 

Configure account lockouts and progressive delays

Configure authentication systems to lock accounts after a defined number of failed attempts (typically 5–10), or implement progressive delays that increase exponentially with each failure. Progressive delays are often preferable to hard lockouts, which can themselves be weaponized for denial-of-service against legitimate users.

Apply rate limiting at the IP and ASN level

Account lockout protects individual accounts. Rate limiting protects the authentication endpoint itself. These are different controls with different targets. Restrict the number of login requests per IP address per time window. Escalate to ASN-level blocking when distributed patterns emerge.

Deploy CAPTCHA and bot management

CAPTCHA challenges differentiate human users from automated scripts at the authentication layer. Modern bot management platforms go further, analyzing behavioral signals — mouse movement, typing cadence, TLS fingerprints — to identify non-human traffic before it reaches the login form.

Implement zero trust architecture

Zero trust operates on the principle that no user, device, or network segment is inherently trusted. Even after successful authentication, access is continuously verified based on context: device health, location, behavior, and least-privilege access rules. If a brute force attack does compromise  one account, zero trust limits the blast radius by preventing lateral movement to other systems and resources.

Monitor authentication logs and alert on anomalies

Detection is a preventive control, not just a reactive one. Catching an attack in progress gives your team time to block the source, invalidate sessions, and contain the damage. Configure SIEM alerts for: spikes in failed authentication attempts, impossible travel events, high request volume to login endpoints, and the low-and-slow spraying pattern where many accounts each receive exactly one or two failures within a short window.

Use a password manager

Password reuse is the fuel that makes credential stuffing viable at scale. When one breach exposes a credential, every other service where that password is reused becomes vulnerable — automatically, without any additional effort from the attacker. A password manager eliminates this by generating and storing a unique, high-entropy password for every account, making reuse structurally impossible.

For individual users, any reputable password manager achieves this. For teams and organizations, the requirements are different and the stakes are higher.

Passwork is built specifically for this environment. It gives IT teams a centralized, structured vault where credentials are organized with granular, role-based access control: each user sees only what their role permits, nothing more. Shared credentials are stored in shared vaults with defined permissions.

Several of Passwork's features directly address the attack vectors covered in this article:

• Customizable password generator — enforces length and complexity requirements at the point of creation, so policy compliance isn't left to individual judgment.
• Password security dashboard — continuously tracks the status of all stored credentials, flagging weak, reused, outdated, and potentially compromised passwords across the entire vault. When an employee leaves, Passwork automatically marks every credential they had access to as potentially compromised and prompts rotation.
• Zero-knowledge client-side encryption — credentials are encrypted on the client side before they ever reach the server. Even with full access to the database or underlying infrastructure, an attacker retrieves nothing readable. The encryption key never leaves the user's device.
• Full audit log — every action in the vault is logged: who accessed what, when, and from where. This is the visibility layer that makes post-incident investigation possible and supports compliance with GDPR, NIS2, and similar frameworks.
• Two-factor authentication, passkeys, and hardware security keys — Passwork supports 2FA via authenticator apps and WebAuthn-based authentication including biometrics and FIDO2 hardware keys, adding a second layer beyond the vault password itself.
• Configurable account lockout — administrators set the threshold of failed login attempts after which an account is locked. This applies brute-force and credential stuffing protection at the vault level itself — not just at the network perimeter.
• Self-hosted deployment — Passwork runs entirely within your own infrastructure. Credential data never leaves your environment, is encrypted with AES-256 on both server and client sides (zero-knowledge architecture), and is managed exclusively by your team.

The JLR breach illustrated what happens without this structure: credentials from 2021 belonging to a third-party contractor were still valid four years later, with no rotation and no MFA on the Jira instance. A centralized vault with enforced rotation policies and an offboarding workflow would have closed that window before it was exploited.

Conclusion

Brute force attacks have become more scalable in practice. Cheap GPU compute, AI-assisted wordlist generation, and massive botnets mean that what once required significant resources now requires almost none. The 37% share of web application attacks attributed to brute force in the 2025 Verizon DBIR is the result of that accessibility.

The good news: the defenses work. MFA, strong and unique passwords, account lockout policies, and behavioral monitoring collectively make brute force attacks impractical against a hardened target. Attackers move toward lowest resistance  — which means organizations that implement layered authentication security effectively remove themselves from the easy-target pool.

The real risk is that they're inconsistently applied — one team using MFA, another not. Shared credentials stored in spreadsheets; password policies that exist on paper but aren't enforced technically. Closing those gaps is where the real work lies.

Passwork gives IT teams a structured, auditable credential vault with role-based access — built for the environments where inconsistency creates risk. Full self-hosted deployment and zero-knowledge encryption — on your infrastructure from day one. Get free trial

Frequently asked questions

What is the difference between a brute force attack and a dictionary attack?

A simple brute force attack tries every possible character combination systematically, with no prior knowledge. A dictionary attack uses a curated list of likely passwords — common words, known phrases, leaked credentials — to reduce the search space. Dictionary attacks are faster and more targeted; simple brute force is exhaustive but slower. Both are defeated by long, random passwords that don't resemble natural language.

Can brute force attacks bypass MFA?

Standard brute force cannot bypass MFA directly — a correct password alone isn't enough  for access. However, attackers use adjacent techniques: MFA fatigue (sending repeated push notifications until the user approves), real-time phishing (capturing and replaying MFA tokens), and session hijacking (stealing authenticated session cookies after login). Phishing-resistant MFA methods such as FIDO2 hardware keys and passkeys eliminate the phishing and fatigue vectors entirely.

Are brute force attacks illegal?

Yes. Unauthorized brute force attacks against systems you do not own or have explicit permission to test are illegal under computer fraud legislation in most jurisdictions — including the Computer Fraud and Abuse Act (CFAA) in the United States, the Computer Misuse Act in the United Kingdom, and the EU Directive on Attacks Against Information Systems (2013/40/EU). Penalties include significant fines and imprisonment. Authorized penetration testing requires written permission from the system owner.

How long does it take to crack a password with brute force?

It depends on password length, character set, and how the hash is stored. A 8-character MD5-hashed password falls in under an hour against a modern GPU cluster. The same password hashed with bcrypt at a high cost factor may take years on the same hardware. Length is the most reliable variable under your control: every additional character multiplies the search space exponentially. A 16-character passphrase against bcrypt is computationally impractical to crack with current hardware.

What is credential stuffing and how does it differ from brute force?

Credential stuffing uses verified username/password pairs from previous data breaches and tests them against other services. It doesn't guess — it reuses. Brute force generates or cycles through combinations without prior knowledge of valid credentials. Credential stuffing is faster and more targeted because it works with real credentials, and it succeeds specifically because of password reuse across services.

What systems are most commonly targeted by brute force attacks?

Authentication endpoints with public exposure carry the highest risk: SSH and RDP services, VPN portals, web application login pages, admin panels (WordPress /wp-admin, cPanel), and API authentication endpoints. The 2025 campaign utilizing  2.8 million IPs focused specifically on VPN gateways and firewalls — perimeter devices that, if compromised, provide direct access to internal networks.

NIS2 latest news: What changed and what it means for EU businesses

84% of in-scope organizations admit they’re not ready. Belgium set the first conformity assessment deadline on April 18, 2026. The Netherlands is days away from enforcement. Here’s where the regulatory wave stands and what IT leaders need to act on now.

Passwork BlogAlex Muntyan

Spring 2026 EU cybersecurity update: What changed

Spring 2026 brought the EU’s most significant institutional breach, its first cyber sanctions of the year, and four major cybersecurity regulations enforcing simultaneously. NIS2, DORA, CRA, and CSA2 now set hard deadlines — and real penalties. Here’s what changed, who’s affected, and what to do.

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

Einleitung

Es ist Montagmorgen. Ein Entwickler kann sich nicht in die Produktionsdatenbank einloggen. Das Passwort wurde letzte Woche rotiert, die Aktualisierung erreichte nie die gemeinsame Tabelle, und das System ist ausgefallen. Jemand eröffnet ein Help-Desk-Ticket. IT-Ingenieure unterbrechen ihre Arbeit. Vierzig Minuten später ist die Krise gelöst.

Die Rechnung: 70 $ — ein Ticket, ein Ingenieur, ein frustrierter Entwickler, der fast eine Stunde lang nichts produziert hat.

Multiplizieren Sie das mit jedem vergessenen, abgelaufenen oder falsch kommunizierten Zugangsdaten in Ihrer Organisation, und das Passwort-Chaos hört auf, ein IT-Ärgernis zu sein, und beginnt wie ein Bilanzproblem auszusehen.

Und das Ticket ist nur der sichtbare Teil. Es zählt nicht den verlorenen Kontext des Entwicklers nach einem unterbrochenen Morgen, das Deployment, das sich verzögerte, oder das Kundengespräch, das verschoben wurde. Es blutet still, über alle Teams hinweg, das ganze Jahr lang.

Passwort-Chaos ist die unorganisierte, unsichere und kostspielige Ausbreitung von Zugangsdaten in einer Organisation — unverwaltet, dupliziert und über unsichere Kanäle geteilt. Laut dem Verizon Data Breach Investigations Report waren kompromittierte Passwörter im Jahr 2025 an 28 % aller Datenschutzverletzungen beteiligt. Das finanzielle Risiko ist real: Die globalen durchschnittlichen Kosten einer Datenschutzverletzung erreichten 2025 4,44 Millionen Dollar (IBM).

Dieser Artikel schlüsselt auf, warum Passwort-Chaos trotz Sicherheitsrichtlinien fortbesteht, was es tatsächlich in Bezug auf Sicherheit, Produktivität und Compliance kostet — und wie man es strukturell behebt, nicht nur symptomatisch.

Wichtige Erkenntnisse

• Kompromittierte Passwörter stecken hinter der Mehrheit der Sicherheitsverletzungen — nicht ausgefeilte Exploits, sondern Zugangsdaten, die wiederverwendet, sorglos geteilt oder nie rotiert wurden.
• Passwortbezogene Probleme beanspruchen einen unverhältnismäßig großen Anteil der IT-Kapazität — Zurücksetzungen, Sperrungen und Zugriffsanfragen, die gar nicht erst existieren sollten.
• Veraltete Passwortrichtlinien verschlimmern das Problem, anstatt es zu lösen — erzwungene Rotation und Komplexitätsregeln führen zu Workarounds, die die tatsächliche Sicherheit verringern.
• Unverwaltete Zugangsdaten machen Compliance-Audits nahezu unmöglich — ohne ein zentralisiertes Audit-Log gibt es keine Möglichkeit nachzuweisen, wer auf was Zugriff hatte.
• Die Lösung ist strukturell — zentralisierte Speicherung, rollenbasierte Zugriffskontrolle und ein klarer Offboarding-Prozess beseitigen die Ursachen, nicht nur die Symptome.

Warum Passwort-Chaos ein stiller Geschäftskiller ist

Passwort-Chaos ist die unkontrollierte Ausbreitung von Zugangsdaten in einer Organisation — gespeichert in Tabellen, über Chat geteilt, über Systeme hinweg dupliziert und ohne konsistenten Prozess verwaltet. Es ist ein Zustand, der sich im Laufe der Zeit verstärkt und gleichzeitig Sicherheit, Produktivität und Compliance gefährdet.

Sicherheitsrisiken

Unverwaltete Zugangsdaten bleiben nicht eingedämmt. Sie verbreiten sich, werden schwächer und werden ausgenutzt:

• Passwort-Müdigkeit führt zu Wiederverwendung. Wenn Mitarbeiter Dutzende von Konten verwalten, greifen sie auf vertraute, schwache Zugangsdaten zurück — oft dasselbe Passwort für mehrere Systeme.
• Wiederverwendung ermöglicht Credential Stuffing im großen Stil. Angreifer nehmen gestohlene Benutzername-Passwort-Paare aus einer Sicherheitsverletzung und automatisieren Login-Versuche bei Hunderten anderer Dienste. Verizons Forschung bestätigt, dass gestohlene Zugangsdaten mit 86 % der Sicherheitsverletzungen bei webbasierten Anwendungen verbunden sind.
• Geteilte Zugangsdaten in unkontrollierten Kanälen schaffen dauerhafte Exposition. Sobald ein Passwort ein sicheres System verlässt — über Slack, E-Mail oder eine Tabelle — gibt es keinen Audit-Trail und keinen Widerrufsmechanismus. Es existiert irgendwo, wo Sie es nicht sehen oder kontrollieren können.

Produktivitäts- und Betriebsrisiken

• 40 % aller Help-Desk-Anrufe sind passwortbezogen (Gartner). Das ist ein erheblicher Anteil der IT-Kapazität, der von einem Problem absorbiert wird, dessen Ursache bekannt und lösbar ist.
• Wenn der Zugang blockiert ist, stoppt die Arbeit. Die nachgelagerten Kosten eines Ingenieurs oder Analysten, der auf eine Zurücksetzung wartet — verlorener Kontext, verzögerte Deployments, verschobene Deadlines — verstärken die direkten Kosten des Tickets selbst.
• Workarounds werden zu dauerhaften Einrichtungen. Temporäre gemeinsame Konten, im Browser gespeicherte Passwörter und angepinnte Slack-Nachrichten beginnen als Abkürzungen und enden als nicht nachverfolgte Zugriffspunkte.

Compliance-Risiken

Die Ausbreitung von Zugangsdaten macht die Einhaltung von Vorschriften schwerer nachweisbar und leichter zu verfehlen:

• Unverwaltete Zugangsdaten machen Zugriffskontrolle unmöglich nachweisbar unter DSGVO, NIS2, SOC 2, HIPAA oder ISO 27001. Prüfer akzeptieren kein „wir glauben, der Zugriff war begrenzt" — sie verlangen Beweise.
• Ohne ein zentralisiertes Audit-Log gibt es keine Aufzeichnung darüber, wer wann auf was Zugriff hatte. Diese Lücke ist sowohl ein Compliance-Versagen als auch ein forensischer blinder Fleck bei der Incident-Response.
• Offboarding ohne Zugangsdaten-Rotation lässt den Zugang unbegrenzt offen. Ehemalige Mitarbeiter, Auftragnehmer und Lieferanten behalten den Zugriff auf Systeme lange nach Ende ihrer Zusammenarbeit.

Der Kumulationseffekt

Jede Risikodimension verstärkt die anderen. Ein wiederverwendetes Passwort wird zum Credential-Stuffing-Vektor. Ein gestopftes Zugangsdaten umgeht Zugriffskontrollen. Eine umgangene Kontrolle hinterlässt keinen Audit-Trail. Bis die Sicherheitsverletzung erkannt wird, ist der Schaden bereits angerichtet. Passwort-Chaos ist ein systemischer Zustand, der eine systemische Reaktion erfordert.

Passwort-Chaos in der Praxis

Passwort-Chaos kündigt sich selten als Sicherheitsereignis an. Es sieht aus wie ein gewöhnlicher Dienstag.

Ein mittelständisches SaaS-Unternehmen betreibt seine Infrastruktur über AWS, drei interne Tools, ein CRM und eine Staging-Umgebung, die vom Entwicklerteam gemeinsam genutzt wird. Zugangsdaten werden so verwaltet wie immer: eine gemeinsame Tabelle auf Google Drive, ein paar angepinnte Einträge in einem Team-Slack-Kanal und eine Handvoll Passwörter, die nur im Kopf eines Senior-Ingenieurs existieren.

So sieht das aus:

• Woche 1. Ein neuer Auftragnehmer tritt dem Backend-Team bei. Jemand teilt das Staging-Datenbank-Passwort über Slack-DM. Der Auftragnehmer beendet seinen Einsatz sechs Wochen später. Niemand rotiert die Zugangsdaten. Sie bleiben gültig.
• Woche 3. Der CRM-Anbieter erzwingt eine Passwortzurücksetzung. Der Teamleiter aktualisiert die Tabelle. Zwei Entwickler verpassen die Aktualisierung vollständig und verbringen den größten Teil eines Vormittags damit, etwas zu beheben, das sie für ein API-Problem halten. Ein Release wird verschoben.
• Woche 5. Ein Senior-Ingenieur nimmt zwei Wochen Urlaub. Drei Systeme benötigen in dieser Zeit Zugriff. Jemand findet einen Workaround: Ein zweites Konto mit Admin-Rechten wird erstellt. Es wird vier Monate lang nicht entfernt.
• Woche 7. Ein Entwickler verlässt das Unternehmen. HR benachrichtigt die IT. Die IT deaktiviert das Active-Directory-Konto. Niemand prüft, auf welche gemeinsamen Zugangsdaten der Entwickler Zugriff hatte — die Staging-Umgebung, das AWS-Testkonto, das interne Monitoring-Tool. Alle drei bleiben unter diesen Zugangsdaten zugänglich.
• Woche 9. Ein IT-Audit markiert die gemeinsame Google-Drive-Tabelle als Compliance-Lücke vor einer SOC-2-Überprüfung. Das Sicherheitsteam verbringt drei Tage damit, manuell zu ermitteln, wer wann auf welche Zugangsdaten Zugriff hatte und ob seit dem letzten Mitarbeiteraustritt welche rotiert wurden. Mehrere wurden es nicht.
• Woche 10. Ein Phishing-Angriff kompromittiert das Google-Konto eines Mitarbeiters. Der Angreifer hat nun Lesezugriff auf die Zugangsdaten-Tabelle. Das Team weiß dies 19 Tage lang nicht.

Die meisten der früheren Ereignisse hatten eine vernünftige Erklärung: Ein Auftragnehmer brauchte Zugriff, jemand war im Urlaub. Woche 10 ist der Punkt, an dem diese Erklärungen nicht mehr greifen. Sie ist auch vollständig vorhersehbar — jede Lücke, die sich in den vorherigen neun Wochen angesammelt hatte, war noch offen, als der Angreifer eintraf.

Das Chaos baut sich nicht dramatisch auf. Es sammelt sich still an, ein Workaround nach dem anderen.

Passwort-Chaos kostet mehr, als die meisten Teams ahnen. Passwork bietet IT-Teams einen strukturierten Tresor mit rollenbasierter Zugriffskontrolle und vollständigem Audit-Log — vollständig in Ihrer eigenen Infrastruktur bereitgestellt. Sehen Sie, wie es funktioniert

Warum traditionelle Passwortrichtlinien 2026 versagen

Veraltete Passwortrichtlinien wurden für ein anderes Bedrohungsmodell entwickelt. Obligatorische 30-Tage-Rotation, Komplexitätsregeln mit Symbolen und Zahlen und das Verbot der Wiederverwendung — diese Regeln waren gut gemeint, aber es hat sich gezeigt, dass sie das Risiko erhöhen, anstatt es zu reduzieren.

Die aktuellen NIST-Richtlinien (SP 800-63B) empfehlen ausdrücklich, auf obligatorische periodische Passwortänderungen zu verzichten, es sei denn, es gibt Hinweise auf eine Kompromittierung. Erzwungene Rotation führt zu vorhersehbaren Mustern: Password1! wird im nächsten Zyklus zu Password2!. Benutzer schreiben Passwörter auf. Die Wiederverwendung nimmt zu.

Das Ergebnis veralteter Richtlinien: Mitarbeiter umgehen sie, die Sicherheit wird schwächer, und IT-Teams verbringen Zeit mit der Durchsetzung von Regeln, die das tatsächliche Risiko nicht reduzieren.

Passwort-Chaos dauerhaft beheben: der 4-Schritte-Plan

Die Behebung von Passwort-Chaos erfordert einen strukturierten Ansatz und eine bewusste Änderung der Art und Weise, wie Zugangsdaten in der Organisation erstellt, gespeichert, geteilt und widerrufen werden.

1. Prüfen Sie Ihre aktuelle Zugangsdaten-Landschaft

Erfassen Sie jedes System, jede Anwendung und jedes gemeinsame Konto. Identifizieren Sie Zugangsdaten, die außerhalb eines sicheren Tresors gespeichert sind: Tabellen, E-Mail-Threads, Chat-Protokolle, im Browser gespeicherte Passwörter. Quantifizieren Sie die Exposition, bevor Sie versuchen, sie zu beheben.

2. Zentralisieren Sie in einem sicheren Tresor

Verschieben Sie alle Zugangsdaten in einen zentralisierten Passwort-Manager mit verschlüsselter Speicherung. Für Organisationen in regulierten Branchen oder mit strengen Anforderungen an den Datenstandort hält eine On-Premise- oder selbstgehostete Bereitstellung alle Daten innerhalb des Unternehmensperimeters — ohne Abhängigkeit von einer Drittanbieter-Cloud.

3. Setzen Sie Zugriffskontrolle mit RBAC durch

Rollenbasierte Zugriffskontrolle (RBAC) stellt sicher, dass Mitarbeiter nur auf die Zugangsdaten zugreifen, die ihre Rolle erfordert. Wenn jemand die Organisation verlässt, wird der Zugriff sofort widerrufen — und das System markiert alle Zugangsdaten, auf die er Zugriff hatte, zur Rotation.

4. Automatisieren Sie mit MFA und Integrationen

Verlangen Sie Multi-Faktor-Authentifizierung (MFA) für den Tresor-Zugriff. Integrieren Sie Ihren bestehenden Verzeichnisdienst über LDAP oder Active Directory, um Benutzer und Gruppen automatisch zu synchronisieren. Nutzen Sie API-Zugriff, um das Zugangsdaten-Management in CI/CD-Pipelines und DevOps-Workflows einzubetten.

Warum Passwork die richtige Wahl für Unternehmenskontrolle ist

Passwork ist ein On-Premise-Passwort-Manager, der für Unternehmen entwickelt wurde, die volle Kontrolle über ihre Zugangsdaten benötigen. Jedes Datenelement bleibt innerhalb der unternehmenseigenen Infrastruktur, und Ihr Team ist in Minuten einsatzbereit, nicht in Wochen.

Passwörter erstellen und teilen ohne Reibungsverluste

Das meiste Zugangsdaten-Chaos beginnt nicht mit einer Sicherheitsverletzung. Es beginnt damit, dass ein Mitarbeiter ein Passwort in Slack einfügt, weil es keine schnellere Option gab. Passwork beseitigt diese Versuchung, indem der sichere Weg der einfache wird.

Passwörter speichern

Das Hinzufügen eines Passworts dauert Sekunden: Füllen Sie die Felder aus, fügen Sie Tags oder Farbmarkierungen zur schnellen Filterung hinzu und speichern Sie es im entsprechenden Ordner. Die Ordnerstruktur spiegelt wider, wie Teams tatsächlich arbeiten — organisiert nach Projekt, Umgebung, Abteilung oder Kunde. Mitarbeiter finden, was sie brauchen, über Suche oder Tags.

Zugriff teilen

Müssen Sie den Zugriff mit einem Kollegen oder einem ganzen Team teilen? Laden Sie sie zu einem gemeinsamen Ordner ein — sie erhalten Zugriff auf alle Zugangsdaten darin, mit der von Ihnen definierten Berechtigungsstufe. Für Einzelfälle senden Sie Zugangsdaten direkt an einen anderen Benutzer.

Onboarding und Offboarding

Wenn jemand einem Projekt beitritt, fügen Sie ihn zum Tresor oder Ordner hinzu. Wenn er das Unternehmen verlässt, markiert Passwork automatisch alle Zugangsdaten, auf die er Zugriff hatte, als potenziell kompromittiert und fordert das Team auf, sie zu rotieren.

Zugriff über Geräte und Workflows hinweg

Browser-Erweiterungen und Mobile Apps halten Passwörter geräteübergreifend zugänglich — das automatische Ausfüllen erledigt den Rest. Für DevOps-Teams bringen CLI und Python SDK denselben Zugriff direkt in Terminal-Workflows und Skripte.

Der On-Premise-Vorteil

Für Organisationen in Finanzwesen, Regierung, Gesundheitswesen und anderen regulierten Sektoren ist es eine zwingende Anforderung, Zugangsdaten innerhalb des Unternehmensperimeters zu halten — keine Präferenz. Passwork läuft auf den unternehmenseigenen Servern (Linux oder Windows, mit oder ohne Docker), verschlüsselt mit AES-256 auf Server- und Client-Seite. Die Zero-Knowledge-Architektur bedeutet, dass selbst das Passwork-Team keinen Zugriff auf Ihre Daten hat.

Passwork beseitigt diese Abhängigkeit vollständig. Die Anwendung läuft auf den unternehmenseigenen Servern (Linux oder Windows, mit oder ohne Docker), verschlüsselt mit AES-256 auf Server- und Client-Seite. Die Zero-Knowledge-Architektur bedeutet, dass selbst das Passwork-Team keinen Zugriff auf Ihre Daten hat.

Wichtige Funktionen für IT- und Sicherheitsteams

• LDAP/AD-Integration und SAML SSO — synchronisieren Sie Benutzer und Gruppen aus Ihrem Verzeichnisdienst; authentifizieren Sie sich über Ihren bestehenden Identity-Provider.
• Rollenbasierte Zugriffskontrolle — granulare Berechtigungen auf Benutzer- und Gruppenebene; benutzerdefinierte Tresortypen mit automatischer Administratorzuweisung.
• Vollständiges Audit-Log — jede Aktion im System wird protokolliert und ist auswertbar, was SOC 2, ISO 27001 und interne Sicherheitsrichtlinien unterstützt.
• Secrets Management — speichern Sie API-Schlüssel, Zugriffs-Token, Datenbankzugangsdaten, SSH-Schlüssel, TLS-Zertifikate und Service-Account-Zugangsdaten zusammen mit Benutzerpasswörtern in einem einheitlichen Tresor.
• Passwort-Sicherheits-Dashboard — markiert schwache, wiederverwendete, veraltete und kompromittierte Zugangsdaten in der gesamten Organisation.
• Prüfbarer Quellcode — Organisationen können ihr eigenes Sicherheitsaudit des Passwork-Quellcodes durchführen, um vor der Bereitstellung zu überprüfen, dass keine Schwachstellen vorhanden sind.

Passwork besitzt die ISO/IEC 27001-Zertifizierung, die einen systematischen, geprüften Ansatz für das Informationssicherheitsmanagement bestätigt.

Fazit

Passwort-Chaos ist eine finanzielle und sicherheitstechnische Belastung — und eine vollständig vermeidbare. Das 70-$-Reset-Ticket, die 4,44-Millionen-Dollar-Sicherheitsverletzung, das Audit, das offenbart, dass niemand weiß, wer auf was Zugriff hatte: Nichts davon ist unvermeidlich. Es sind die vorhersehbaren Folgen davon, Zugangsdaten als Nebensache zu behandeln.

Das Muster ist über Organisationen jeder Größe hinweg konsistent. Passwörter werden über die falschen Kanäle geteilt. Richtlinien werden inkonsistent durchgesetzt. Zugriffsrechte sammeln sich im Laufe der Zeit an und werden nie bereinigt. Jemand geht, und niemand rotiert die Zugangsdaten, die er berührt hat. Jede Lücke ist für sich klein. Zusammen schaffen sie die Bedingungen für eine Sicherheitsverletzung — oder ein Compliance-Versagen, das genauso kostspielig ist.

Die Lösung ist eine strukturelle Änderung: zentralisierte Speicherung, definierter Zugriff, ein vollständiger Audit-Trail und ein Prozess, der die sichere Option zur Standardoption macht — nicht zur unbequemen.

Passwork ist darauf ausgelegt, diese Änderung unkompliziert zu machen. Ob Sie in Ihrer eigenen Infrastruktur oder in der Cloud bereitstellen, Ihr Team erhält einen strukturierten Tresor, rollenbasierten Zugriff und die Transparenz, um genau zu wissen, wer auf was zugreifen kann — bevor etwas schiefgeht.

Bereit, die Zugangsdaten-Ausbreitung durch strukturierte Kontrolle zu ersetzen? Testen Sie Passwork in Ihrer eigenen Infrastruktur — unser Team unterstützt Sie bei Installation und Konfiguration. Kostenlose Demo anfordern

FAQ: das Zugangsdaten-Chaos bändigen

Wie verwaltet man Passwörter für ein Team, ohne sie unsicher zu teilen?

Verwenden Sie einen zentralisierten Passwort-Manager mit rollenbasierter Zugriffskontrolle. Jedes Teammitglied greift nur auf die Zugangsdaten zu, die seiner Rolle zugewiesen sind — kein direktes Teilen erforderlich. Gemeinsame Tresore mit granularen Berechtigungen ersetzen Tabellen und Chat-basierte Zugangsdaten-Verteilung. Wenn jemand geht, wird sein Zugriff widerrufen und betroffene Zugangsdaten werden automatisch zur Rotation markiert.

Ist es sicher, Geschäftspasswörter in einem Browser zu speichern?

Nein. Im Browser gespeicherte Passwörter bieten keine Zugriffskontrolle, keinen Audit-Trail und keine Verschlüsselung über das eigene Sicherheitsmodell des Browsers hinaus. Sie synchronisieren sich über Geräte hinweg durch Cloud-Konten, die möglicherweise nicht den Sicherheitsstandards von Unternehmen entsprechen. Eine Browser-Kompromittierung legt alle gespeicherten Zugangsdaten gleichzeitig offen.

Was ist Credential Stuffing und wie verhindert ein Passwort-Manager es?

Credential Stuffing ist ein Angriff, bei dem gestohlene Benutzername/Passwort-Paare aus einer Sicherheitsverletzung automatisch bei anderen Diensten getestet werden. Er ist erfolgreich wegen Passwort-Wiederverwendung. Ein Passwort-Manager generiert und speichert einzigartige, starke Zugangsdaten für jedes Konto und eliminiert die Wiederverwendung, die Credential Stuffing effektiv macht. Kombiniert mit MFA wird der primäre Angriffsvektor eliminiert.

Wie unterstützt ein Passwort-Manager die DSGVO- und SOC-2-Compliance?

Ein Passwort-Manager mit vollständigem Audit-Log, RBAC und On-Premise-Bereitstellung unterstützt Compliance-Anforderungen direkt. Die DSGVO erfordert nachweisbare Kontrolle darüber, wer auf personenbezogene Daten zugreift. SOC 2 erfordert Nachweise für Zugriffsmanagement und Überwachung. Ein Audit-Log mit Aktivitätsverfolgung auf Benutzerebene liefert die Dokumentation, die Prüfer benötigen — und die Transparenz, die Sicherheitsteams brauchen, um auf Anomalien zu reagieren.

Was passiert mit gemeinsamen Zugangsdaten, wenn ein Mitarbeiter geht?

Bei Passwork löst das Offboarding einen sofortigen Zugriffsentzug aus. Das System identifiziert alle Zugangsdaten, auf die der ausscheidende Mitarbeiter Zugriff hatte, und markiert sie als potenziell kompromittiert, was das Team zur Rotation auffordert. Ohne ein zentralisiertes System ist dieser Prozess manuell, fehleranfällig und oft unvollständig.

Macht ein Passwort-Manager MFA überflüssig?

Nein — und das sollte er auch nicht. Ein Passwort-Manager sichert die Speicherung und den Zugriff auf Zugangsdaten; MFA sichert die Authentifizierung. Sie adressieren unterschiedliche Angriffsflächen. Ein starkes, einzigartiges Passwort verhindert Credential Stuffing; MFA verhindert unbefugten Zugriff, selbst wenn ein Passwort kompromittiert wurde. Die beiden Kontrollen ergänzen sich, sind aber nicht austauschbar.

Wie lange dauert es, einen Passwort-Manager in einer Organisation bereitzustellen?

Eine selbstgehostete Lösung wie Passwork kann auf bestehender Infrastruktur — Linux oder Windows, mit oder ohne Docker — in unter einer Stunde bereitgestellt werden. LDAP- und Active-Directory-Integration synchronisiert Benutzer und Gruppen automatisch, sodass keine manuelle Bereitstellung von Konten erforderlich ist. Die meisten Teams sind innerhalb eines Tages nach der Bereitstellung voll einsatzbereit.

Was ist Passwort-Wiederverwendung und warum ist es ein großes Sicherheitsrisiko?

Passwort-Wiederverwendung gefährdet 88 % der Sicherheitsverletzungen. Erfahren Sie, warum die Verwendung desselben Passworts für mehrere Konten gefährlich ist und wie Sie diese Gewohnheit heute noch ablegen.

Passwork BlogEirik Salmi

Passwork 7.6 Release: Service-Accounts

Das neueste Passwork-Release fügt Service-Accounts mit Multi-Token-API-Unterstützung, gespeicherte Filter, mobile Web-UI und automatische Papierkorb-Bereinigung hinzu. Sehen Sie, was sich geändert hat.

Passwork BlogEirik Salmi

Ist passwortlose Authentifizierung nach NIS2 für Compliance erforderlich?

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

Passwork BlogAlex Muntyan

Introducción

Es lunes por la mañana. Un desarrollador no puede iniciar sesión en la base de datos de producción. La contraseña se rotó la semana pasada, la actualización nunca llegó a la hoja de cálculo compartida y el sistema está caído. Alguien abre un ticket de soporte. Los ingenieros de TI dejan lo que están haciendo. Cuarenta minutos después, la crisis está resuelta.

La factura: $70 — un ticket, un ingeniero, un desarrollador frustrado que no produjo nada durante la mayor parte de una hora.

Multiplique esto por cada credencial olvidada, expirada o mal comunicada en toda su organización, y el caos de contraseñas deja de ser una molestia de TI para convertirse en un problema de balance financiero.

Y el ticket es solo la parte visible. No cuenta el contexto perdido del desarrollador tras una mañana interrumpida, el despliegue que se retrasó o la llamada con el cliente que se pospuso. Se filtra silenciosamente, en todos los equipos, durante todo el año.

El caos de contraseñas es la dispersión desorganizada, insegura y costosa de credenciales en una organización — sin gestionar, duplicadas y compartidas a través de canales inseguros. Según el Informe de Investigaciones de Brechas de Datos de Verizon, las contraseñas comprometidas estuvieron involucradas en el 28% de todas las brechas de datos en 2025. La exposición financiera es real: el coste promedio global de una brecha de datos alcanzó los $4.44 millones en 2025 (IBM).

Este artículo analiza por qué el caos de contraseñas persiste a pesar de las políticas de seguridad, qué cuesta realmente en términos de seguridad, productividad y cumplimiento — y cómo solucionarlo de forma estructural, no solo sintomática.

Puntos clave

• Las contraseñas comprometidas están detrás de la mayoría de las brechas — no exploits sofisticados, sino credenciales reutilizadas, compartidas descuidadamente o nunca rotadas.
• Los problemas relacionados con contraseñas consumen una parte desproporcionada de la capacidad de TI — restablecimientos, bloqueos y solicitudes de acceso que no deberían existir en primer lugar.
• Las políticas de contraseñas heredadas empeoran el problema, no lo mejoran — la rotación forzada y las reglas de complejidad impulsan soluciones alternativas que reducen la seguridad real.
• Las credenciales no gestionadas hacen que las auditorías de cumplimiento sean casi imposibles — sin un registro de auditoría centralizado, no hay forma de demostrar quién tuvo acceso a qué.
• La solución es estructural — almacenamiento centralizado, control de acceso basado en roles y un proceso claro de desvinculación eliminan las causas raíz, no solo los síntomas.

Por qué el caos de contraseñas es un asesino silencioso de empresas

El caos de contraseñas es la dispersión descontrolada de credenciales en una organización — almacenadas en hojas de cálculo, compartidas por chat, duplicadas en múltiples sistemas y gestionadas sin un proceso consistente. Es una condición que se agrava con el tiempo, creando exposición simultánea en seguridad, productividad y cumplimiento.

Riesgos de seguridad

Las credenciales no gestionadas no permanecen contenidas. Se dispersan, se debilitan y son explotadas:

• La fatiga de contraseñas impulsa la reutilización. Cuando los empleados gestionan docenas de cuentas, recurren a credenciales familiares y débiles — a menudo la misma contraseña en múltiples sistemas.
• La reutilización permite el credential stuffing a gran escala. Los atacantes toman pares de nombre de usuario y contraseña filtrados de una brecha y automatizan intentos de inicio de sesión en cientos de otros servicios. La investigación de Verizon confirma que las credenciales robadas están vinculadas al 86% de las brechas de seguridad que involucran aplicaciones basadas en web.
• Las credenciales compartidas en canales no controlados crean exposición permanente. Una vez que una contraseña sale de un sistema seguro — vía Slack, correo electrónico o una hoja de cálculo — no hay registro de auditoría ni mecanismo de revocación. Existe en algún lugar que no se puede ver ni controlar.

Riesgos de productividad y operacionales

• El 40% de todas las llamadas al servicio de soporte están relacionadas con contraseñas (Gartner). Eso representa una parte significativa de la capacidad de TI absorbida por un problema con una causa raíz conocida y solucionable.
• Cuando se bloquea el acceso, el trabajo se detiene. El coste indirecto de un ingeniero o analista esperando un restablecimiento — contexto perdido, despliegues retrasados, plazos pospuestos — se suma al coste directo del ticket en sí.
• Las soluciones alternativas se convierten en elementos permanentes. Cuentas compartidas temporales, contraseñas guardadas en el navegador y mensajes fijados en Slack comienzan como atajos y terminan como puntos de acceso no rastreados.

Riesgos de cumplimiento

La dispersión de credenciales hace que el cumplimiento normativo sea más difícil de demostrar y más fácil de incumplir:

• Las credenciales no gestionadas hacen imposible demostrar el control de acceso bajo GDPR, NIS2, SOC 2, HIPAA o ISO 27001. Los auditores no aceptan «creemos que el acceso estaba limitado» — requieren evidencia.
• Sin un registro de auditoría centralizado, no hay constancia de quién tuvo acceso a qué y cuándo. Esa brecha es tanto un fallo de cumplimiento como un punto ciego forense durante la respuesta a incidentes.
• La desvinculación sin rotación de credenciales deja el acceso abierto indefinidamente. Exempleados, contratistas y proveedores mantienen acceso a los sistemas mucho después de que termine su compromiso.

El efecto acumulativo

Cada dimensión de riesgo amplifica las otras. Una contraseña reutilizada se convierte en un vector de credential stuffing. Una credencial comprometida elude los controles de acceso. Un control eludido no deja rastro de auditoría. Para cuando se detecta la brecha, el daño ya está hecho. El caos de contraseñas es una condición sistémica que requiere una respuesta sistémica.

El caos de contraseñas en la práctica

El caos de contraseñas rara vez se anuncia como un evento de seguridad. Parece un martes rutinario.

Una empresa SaaS mediana ejecuta su infraestructura en AWS, tres herramientas internas, un CRM y un entorno de staging compartido por el equipo de desarrollo. Las credenciales se gestionan como siempre se ha hecho: una hoja de cálculo compartida en Google Drive, algunas entradas fijadas en un canal de Slack del equipo y un puñado de contraseñas que existen solo en la memoria de un ingeniero senior.

Así es como se ve:

• Semana 1. Un nuevo contratista se une al equipo de backend. Alguien comparte la contraseña de la base de datos de staging por mensaje directo de Slack. El contratista termina su compromiso seis semanas después. Nadie rota la credencial. Sigue siendo válida.
• Semana 3. El proveedor del CRM fuerza un restablecimiento de contraseña. El líder del equipo actualiza la hoja de cálculo. Dos desarrolladores se pierden la actualización por completo y pasan la mayor parte de una mañana solucionando lo que asumen es un problema de API. Se retrasa un lanzamiento.
• Semana 5. Un ingeniero senior toma dos semanas de vacaciones. Tres sistemas necesitan acceso durante ese tiempo. Alguien encuentra una solución alternativa: se crea una segunda cuenta con derechos de administrador. No se eliminará durante cuatro meses.
• Semana 7. Un desarrollador deja la empresa. RRHH notifica a TI. TI desactiva la cuenta de Active Directory. Nadie verifica a qué credenciales compartidas tenía acceso el desarrollador — el entorno de staging, la cuenta de prueba de AWS, la herramienta de monitorización interna. Las tres siguen siendo accesibles con esas credenciales.
• Semana 9. Una auditoría de TI señala la hoja de cálculo compartida de Google Drive como una brecha de cumplimiento antes de una revisión de SOC 2. El equipo de seguridad pasa tres días mapeando manualmente quién tuvo acceso a qué credenciales, cuándo y si alguna ha sido rotada desde la última salida de un empleado. Varias no lo han sido.
• Semana 10. Un ataque de phishing compromete la cuenta de Google de un empleado. El atacante ahora tiene acceso de lectura a la hoja de cálculo de credenciales. El equipo no lo sabe durante 19 días.

La mayoría de los eventos anteriores tenían una explicación razonable: un contratista necesitaba acceso, alguien estaba de vacaciones. La semana 10 es donde esas explicaciones se agotan. También es completamente predecible — cada brecha que se acumuló durante las nueve semanas anteriores seguía abierta cuando llegó el atacante.

El caos no se construye dramáticamente. Se acumula silenciosamente, una solución alternativa a la vez.

El caos de contraseñas cuesta más de lo que la mayoría de los equipos creen. Passwork ofrece a los equipos de TI una bóveda estructurada con acceso basado en roles y un registro de auditoría completo — desplegado completamente dentro de su propia infraestructura. Vea cómo funciona

Por qué las políticas tradicionales de contraseñas están fallando en 2026

Las políticas de contraseñas heredadas fueron diseñadas para un modelo de amenazas diferente. Rotación obligatoria cada 30 días, reglas de complejidad que requieren símbolos y números, y prohibición de reutilización — estas reglas tenían buenas intenciones, pero se ha demostrado que aumentan el riesgo en lugar de reducirlo.

Las directrices actuales de NIST (SP 800-63B) recomiendan explícitamente no realizar cambios periódicos obligatorios de contraseñas a menos que haya evidencia de compromiso. La rotación forzada conduce a patrones predecibles: Password1! se convierte en Password2! en el siguiente ciclo. Los usuarios anotan las contraseñas. La reutilización aumenta.

El resultado de las políticas obsoletas: los empleados las eluden, la seguridad se debilita y los equipos de TI pasan tiempo aplicando reglas que no reducen el riesgo real.

Cómo solucionar el caos de contraseñas definitivamente: el plan de 4 pasos

Solucionar el caos de contraseñas requiere un enfoque estructurado y un cambio deliberado en cómo se crean, almacenan, comparten y revocan las credenciales en toda la organización.

1. Audite su panorama actual de credenciales

Mapee cada sistema, aplicación y cuenta compartida. Identifique las credenciales almacenadas fuera de una bóveda segura: hojas de cálculo, hilos de correo electrónico, registros de chat, contraseñas guardadas en el navegador. Cuantifique la exposición antes de intentar solucionarla.

2. Centralice en una bóveda segura

Mueva todas las credenciales a un gestor de contraseñas centralizado con almacenamiento cifrado. Para organizaciones en industrias reguladas o con requisitos estrictos de residencia de datos, un despliegue on-premise o autoalojado mantiene todos los datos dentro del perímetro de la empresa — sin dependencia de la nube de terceros.

3. Aplique control de acceso con RBAC

El control de acceso basado en roles (RBAC) garantiza que los empleados accedan solo a las credenciales que su rol requiere. Cuando alguien deja la organización, el acceso se revoca inmediatamente — y el sistema marca todas las credenciales a las que tenía acceso para rotación.

4. Automatice con MFA e integraciones

Requiera autenticación multifactor (MFA) para el acceso a la bóveda. Integre con su servicio de directorio existente vía LDAP o Active Directory para sincronizar usuarios y grupos automáticamente. Use el acceso API para integrar la gestión de credenciales en pipelines CI/CD y flujos de trabajo DevOps.

Por qué Passwork es la opción adecuada para el control empresarial

Passwork es un gestor de contraseñas on-premise diseñado para empresas que requieren control total sobre sus datos de credenciales. Cada dato permanece dentro de la propia infraestructura de la empresa y poner en marcha a su equipo lleva minutos, no semanas.

Crear y compartir contraseñas sin fricción

La mayoría del caos de credenciales no comienza con una brecha. Comienza con un empleado pegando una contraseña en Slack porque no había una opción más rápida. Passwork elimina esa tentación haciendo que el camino seguro sea el fácil.

Almacenar contraseñas

Añadir una contraseña lleva segundos: complete los campos, adjunte etiquetas o etiquetas de color para un filtrado rápido y guárdela en la carpeta correspondiente. La estructura de carpetas refleja cómo trabajan realmente los equipos — organizado por proyecto, entorno, departamento o cliente. Los empleados encuentran lo que necesitan mediante búsqueda o etiquetas.

Compartir acceso

¿Necesita compartir acceso con un colega o un equipo completo? Invítelos a una carpeta compartida — obtienen acceso a todas las credenciales dentro de ella, al nivel de permiso que usted defina. Para casos puntuales, envíe una credencial directamente a otro usuario.

Incorporación y desvinculación

Cuando alguien se une a un proyecto, añádalo a la bóveda o carpeta. Cuando deja la empresa, Passwork marca automáticamente cada credencial a la que tenía acceso como potencialmente comprometida y solicita al equipo que las rote.

Acceso en dispositivos y flujos de trabajo

Las extensiones de navegador y las aplicaciones móviles mantienen las contraseñas accesibles en todos los dispositivos — el autocompletado se encarga del resto. Para los equipos de DevOps, la CLI y el SDK de Python llevan el mismo acceso directamente a los flujos de trabajo de terminal y scripts.

La ventaja on-premise

Para organizaciones en finanzas, gobierno, salud y otros sectores regulados, mantener los datos de credenciales dentro del perímetro de la empresa es un requisito estricto — no una preferencia. Passwork se ejecuta en los propios servidores de la organización (Linux o Windows, con o sin Docker), cifrado con AES-256 tanto en el lado del servidor como del cliente. La arquitectura de conocimiento cero significa que ni siquiera el propio equipo de Passwork puede acceder a sus datos.

Passwork elimina esa dependencia por completo. La aplicación se ejecuta en los propios servidores de la organización (Linux o Windows, con o sin Docker), cifrada con AES-256 tanto en el lado del servidor como del cliente. La arquitectura de conocimiento cero significa que ni siquiera el propio equipo de Passwork puede acceder a sus datos.

Capacidades clave para equipos de TI y seguridad

• Integración LDAP/AD y SAML SSO — sincronice usuarios y grupos desde su servicio de directorio; autentique a través de su proveedor de identidad existente.
• Control de acceso basado en roles — permisos granulares a nivel de usuario y grupo; tipos de bóveda personalizados con asignación automática de administrador.
• Registro de auditoría completo — cada acción dentro del sistema se registra y es reportable, cumpliendo con los requisitos de SOC 2, ISO 27001 y políticas de seguridad internas.
• Gestión de secretos — almacene claves API, tokens de acceso, credenciales de bases de datos, claves SSH, certificados TLS y credenciales de cuentas de servicio junto con las contraseñas de usuario en una bóveda unificada.
• Panel de seguridad de contraseñas — marca credenciales débiles, reutilizadas, desactualizadas y comprometidas en toda la organización.
• Código fuente auditable — las organizaciones pueden realizar su propia auditoría de seguridad del código base de Passwork para verificar que no hay vulnerabilidades antes del despliegue.

Passwork cuenta con certificación ISO/IEC 27001, confirmando un enfoque sistemático y auditado de la gestión de seguridad de la información.

Conclusión

El caos de contraseñas es una responsabilidad financiera y de seguridad — y completamente prevenible. El ticket de restablecimiento de $70, la brecha de $4.44 millones, la auditoría que revela que nadie sabe quién tuvo acceso a qué: nada de esto es inevitable. Son el resultado predecible de tratar las credenciales como algo secundario.

El patrón es consistente en organizaciones de todos los tamaños. Las contraseñas se comparten a través de canales incorrectos. Las políticas se aplican de manera inconsistente. El acceso se acumula con el tiempo y nunca se limpia. Alguien se va, y nadie rota las credenciales que tocó. Cada brecha es pequeña por sí sola. Juntas, crean las condiciones para una violación — o un fallo de cumplimiento igual de costoso.

La solución es un cambio estructural: almacenamiento centralizado, acceso definido, un registro de auditoría completo y un proceso que haga que la opción segura sea la predeterminada — no la inconveniente.

Passwork está diseñado para hacer ese cambio sencillo. Ya sea que despliegue en su propia infraestructura o en la nube, su equipo obtiene una bóveda estructurada, acceso basado en roles y la visibilidad para saber exactamente quién puede acceder a qué — antes de que algo salga mal.

¿Listo para reemplazar la dispersión de credenciales con un control estructurado? Pruebe Passwork en su propia infraestructura — nuestro equipo le asistirá con la instalación y configuración. Solicite una demostración gratuita

FAQ: domando el caos de credenciales

¿Cómo se gestionan las contraseñas de un equipo sin compartirlas de forma insegura?

Use un gestor de contraseñas centralizado con control de acceso basado en roles. Cada miembro del equipo accede solo a las credenciales asignadas a su rol — sin necesidad de compartir directamente. Las bóvedas compartidas con permisos granulares reemplazan las hojas de cálculo y la distribución de credenciales basada en chat. Cuando alguien se va, su acceso se revoca y las credenciales afectadas se marcan para rotación automáticamente.

¿Es seguro almacenar contraseñas empresariales en un navegador?

No. Las contraseñas almacenadas en el navegador no ofrecen control de acceso, ni registro de auditoría, ni cifrado más allá del propio modelo de seguridad del navegador. Se sincronizan entre dispositivos a través de cuentas en la nube que pueden no cumplir con los estándares de seguridad empresarial. Un compromiso del navegador expone todas las credenciales guardadas simultáneamente.

¿Qué es el credential stuffing y cómo lo previene un gestor de contraseñas?

El credential stuffing es un ataque donde los pares de nombre de usuario/contraseña robados de una brecha se prueban automáticamente en otros servicios. Tiene éxito debido a la reutilización de contraseñas. Un gestor de contraseñas genera y almacena credenciales únicas y fuertes para cada cuenta, eliminando la reutilización que hace efectivo el credential stuffing. Combinado con MFA, elimina el vector de ataque principal.

¿Cómo apoya un gestor de contraseñas el cumplimiento de GDPR y SOC 2?

Un gestor de contraseñas con registro de auditoría completo, RBAC y despliegue on-premise apoya directamente los requisitos de cumplimiento. GDPR requiere control demostrable sobre quién accede a los datos personales. SOC 2 requiere evidencia de gestión y monitorización del acceso. Un registro de auditoría con seguimiento de actividad a nivel de usuario proporciona la documentación que los auditores necesitan — y la visibilidad que los equipos de seguridad necesitan para actuar ante anomalías.

¿Qué sucede con las credenciales compartidas cuando un empleado se va?

En Passwork, la desvinculación activa una revocación inmediata del acceso. El sistema identifica todas las credenciales a las que el empleado saliente tenía acceso y las marca como potencialmente comprometidas, solicitando al equipo que las rote. Sin un sistema centralizado, este proceso es manual, propenso a errores y a menudo incompleto.

¿Un gestor de contraseñas elimina la necesidad de MFA?

No — y no debería. Un gestor de contraseñas asegura el almacenamiento y acceso de credenciales; MFA asegura la autenticación. Abordan superficies de ataque diferentes. Una contraseña fuerte y única previene el credential stuffing; MFA previene el acceso no autorizado incluso cuando una contraseña está comprometida. Los dos controles son complementarios, no intercambiables.

¿Cuánto tiempo lleva desplegar un gestor de contraseñas en toda una organización?

Una solución autoalojada como Passwork puede desplegarse en la infraestructura existente — Linux o Windows, con o sin Docker — en menos de una hora. La integración con LDAP y Active Directory sincroniza usuarios y grupos automáticamente, por lo que no es necesario aprovisionar cuentas manualmente. La mayoría de los equipos están completamente operativos en un día desde el despliegue.

What is password reuse and why is it a major security risk?

Password reuse puts 88% of breaches at risk. Learn why using the same password across accounts is dangerous and how to break the habit today.

Passwork BlogEirik Salmi

Passwork 7.6 release: Service accounts

The latest Passwork release adds service accounts with multi-token API support, saved filters, mobile web UI, and automatic Bin cleanup. See what changed.

Passwork BlogEirik Salmi

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

Introduction

It's Monday morning. A developer can't log in to the production database. The password was rotated last week, the update never reached the shared spreadsheet, and the system is down. Someone opens a help desk ticket. IT engineers drops what they're doing. Forty minutes later, the crisis is resolved.

The bill: $70 — one ticket, one engineer, one frustrated developer who produced nothing for the better part of an hour.

Multiply that by every forgotten, expired, or miscommunicated credential across your organization, and password chaos stops being an IT annoyance and starts looking like a balance sheet problem.

And the ticket is just the visible part. It doesn't count the developer's lost context after an interrupted morning, the deployment that slipped, or the client call that got pushed. It bleeds quietly, across every team, all year long.

Password chaos is the disorganized, insecure, and costly sprawl of credentials across an organization — unmanaged, duplicated, and shared through unsafe channels. According to the Verizon Data Breach Investigations Report, compromised passwords were involved in 28% of all data breaches in 2025. The financial exposure is real: the global average cost of a data breach reached $4.44 million in 2025, (IBM).

This article breaks down why password chaos persists despite security policies, what it actually costs across security, productivity, and compliance — and how to fix it structurally, not just symptomatically.

Key takeaways

• Compromised passwords are behind the majority of breaches — not sophisticated exploits, but credentials that were reused, shared carelessly, or never rotated.
• Password-related issues consume a disproportionate share of IT capacity — resets, lockouts, and access requests that shouldn't exist in the first place.
• Legacy password policies make the problem worse, not better — forced rotation and complexity rules drive workarounds that reduce actual security.
• Unmanaged credentials make compliance audits nearly impossible — without a centralized audit log, there's no way to prove who had access to what.
• The fix is structural — centralized storage, role-based access control, and a clear offboarding process eliminate the root causes, not just the symptoms.

Why password chaos is a silent business killer

Password chaos is the uncontrolled sprawl of credentials across an organization — stored in spreadsheets, shared over chat, duplicated across systems, and managed without a consistent process. It's a condition that compounds over time, creating simultaneous exposure across security, productivity, and compliance.

Security risks

Unmanaged credentials don't stay contained. They spread, weaken, and get exploited:

• Password fatigue drives reuse. When employees manage dozens of accounts, they default to familiar, weak credentials — often the same password across multiple systems.
• Reuse enables credential stuffing at scale. Attackers take leaked username and password pairs from one breach and automate login attempts across hundreds of other services. Verizon's research confirms that stolen credentials are tied to 86% of security breaches involving web-based applications.
• Shared credentials in uncontrolled channels create permanent exposure. Once a password leaves a secure system — via Slack, email, or a spreadsheet — there's no audit trail and no revocation mechanism. It exists somewhere you can't see or control.

Productivity and operational risks

• 40% of all help desk calls are password-related (Gartner). That's a significant share of IT capacity absorbed by a problem with a known, solvable root cause.
• When access is blocked, work stops. The downstream cost of an engineer or analyst waiting for a reset — lost context, delayed deployments, pushed deadlines — compounds the direct cost of the ticket itself.
• Workarounds become permanent fixtures. Temporary shared accounts, browser-saved passwords, and pinned Slack messages start as shortcuts and end as untracked access points.

Compliance risks

Credential sprawl makes regulatory compliance harder to demonstrate and easier to fail:

• Unmanaged credentials make access control impossible to prove under GDPR, NIS2, SOC 2, HIPAA, or ISO 27001. Auditors don't accept "we think access was limited" — they require evidence.
• Without a centralized audit log, there's no record of who had access to what and when. That gap is both a compliance failure and a forensic blind spot during incident response.
• Offboarding without credential rotation leaves access open indefinitely. Former employees, contractors, and vendors retain access to systems long after their engagement ends.

The compounding effect

Each risk dimension amplifies the others. A reused password becomes a credential stuffing vector. A stuffed credential bypasses access controls. A bypassed control leaves no audit trail. By the time the breach is detected the damage is already done. Password chaos is a systemic condition that requires a systemic response.

Password chaos in practice

Password chaos rarely announces itself as a security event. It looks like a routine Tuesday.

A mid-size SaaS company runs its infrastructure across AWS, three internal tools, a CRM, and a staging environment shared by the dev team. Credentials are managed the way they always have been: a shared spreadsheet on Google Drive, a few pinned entries in a team Slack channel, and a handful of passwords that exist only in one senior engineer's memory.

Here's what it looks like:

• Week 1. A new contractor joins the backend team. Someone shares the staging database password over Slack DM. The contractor finishes the engagement six weeks later. No one rotates the credential. It stays valid.
• Week 3. The CRM vendor forces a password reset. The team lead updates the spreadsheet. Two developers miss the update entirely and spend the better part of a morning troubleshooting what they assume is an API issue. A release gets pushed.
• Week 5. A senior engineer takes two weeks of leave. Three systems need access during that time. Someone finds a workaround: a second account gets created with admin rights. It won't be removed for four months.
• Week 7. A developer leaves the company. HR notifies IT. IT disables the Active Directory account. Nobody checks which shared credentials the developer had access to — the staging environment, the AWS test account, the internal monitoring tool. All three remain accessible under those credentials.
• Week 9. An IT audit flags the shared Google Drive spreadsheet as a compliance gap ahead of a SOC 2 review. The security team spends three days manually mapping who had access to which credentials, when, and whether any have been rotated since the last employee departure. Several haven't.
• Week 10. A phishing attack compromises one employee's Google account. The attacker now has read access to the credential spreadsheet. The team doesn't know this for 19 days.

Most of the earlier events had a reasonable explanation: a contractor needed access, someone was on leave. Week 10 is where those explanations run out. It's also entirely predictable — every gap that accumulated over the previous nine weeks was still open when the attacker arrived.

The chaos doesn't build dramatically. It accumulates quietly, one workaround at a time.

Password chaos costs more than most teams realize. Passwork gives IT teams a structured vault with role-based access and a full audit log — deployed entirely within your own infrastructure. See how it works

Why traditional password policies are failing in 2026

Legacy password policies were designed for a different threat model. Mandatory 30-day rotation, complexity rules requiring symbols and numbers, and prohibition of reuse — these rules were well-intentioned, but they've been shown to increase risk rather than reduce it.

NIST's current guidelines (SP 800-63B) explicitly recommend against mandatory periodic password changes unless there's evidence of compromise. Forced rotation leads to predictable patterns: Password1! becomes Password2! on the next cycle. Users write passwords down. Reuse increases.

The result of outdated policies: employees work around them, security weakens, and IT teams spend time enforcing rules that don't reduce actual risk.

How to fix password chaos for good: the 4-step blueprint

Fixing password chaos requires a structured approach and a deliberate change to how credentials are created, stored, shared, and revoked across the organization.

1. Audit your current credential landscape

Map every system, application, and shared account. Identify credentials stored outside a secure vault: spreadsheets, email threads, chat logs, browser-saved passwords. Quantify exposure before attempting to fix it.

2. Centralize into a secure vault

Move all credentials into a centralized password manager with encrypted storage. For organizations in regulated industries or with strict data residency requirements, an on-premise or self-hosted deployment keeps all data within the company perimeter — no third-party cloud dependency.

3. Enforce access control with RBAC

Role-based access control (RBAC) ensures that employees access only the credentials their role requires. When someone leaves the organization, access is revoked immediately — and the system flags all credentials they had access to for rotation.

4. Automate with MFA and integrations

Require multi-factor authentication (MFA) for vault access. Integrate with your existing directory service via LDAP or Active Directory to synchronize users and groups automatically. Use API access to embed credential management into CI/CD pipelines and DevOps workflows.

Why Passwork is the right fit for enterprise control

Passwork is an on-premise password manager built for businesses that require full control over their credential data. Every piece of data stays within the company's own infrastructure and getting your team up and running takes minutes, not weeks.

Creating and sharing passwords without the friction

Most credential chaos doesn't start with a breach. It starts with an employee pasting a password into Slack because there was no faster option. Passwork removes that temptation by making the secure path the easy one.

Storing passwords

Adding a password takes seconds: fill in the fields, attach tags or color labels for quick filtering, and save it to the relevant folder. he folder structure mirrors how teams actually work — organized by project, environment, department, or client. Employees find what they need through search or tags.

Sharing access

Need to share access with a colleague or an entire team? Invite them to a shared folder — they get access to every credential inside it, at the permission level you define. For one-off cases, send a credential directly to another user.

Onboarding and offboarding

When someone joins a project, add them to the vault or folder. When they leave the company, Passwork automatically flags every credential they had access to as potentially compromised and prompts the team to rotate them.

Access across devices and workflows

Browser extensions and mobile apps keep passwords accessible across devices — autofill handles the rest. For DevOps teams, the CLI and Python SDK bring the same access directly into terminal workflows and scripts.

The on-premise advantage

For organizations in finance, government, healthcare, and other regulated sectors, keeping credential data within the company perimeter is a hard requirement — not a preference. Passwork runs on the organization's own servers (Linux or Windows, with or without Docker), encrypted with AES-256 on both server and client sides. Zero-knowledge architecture means that even Passwork's own team cannot access your data.

Passwork eliminates that dependency entirely. The application runs on the organization's own servers (Linux or Windows, with or without Docker), encrypted with AES-256 on both server and client sides. Zero-knowledge architecture means that even Passwork's own team cannot access your data.

Key capabilities for IT and security teams

• LDAP/AD integration and SAML SSO — synchronize users and groups from your directory service; authenticate through your existing identity provider.
• Role-based access control — granular permissions at the user and group level; custom vault types with automatic administrator assignment.
• Full audit log — every action within the system is logged and reportable, supporting SOC 2, ISO 27001, and internal security policy requirements.
• Secrets management — store API keys, access tokens, database credentials, SSH keys, TLS certificates, and service account credentials alongside user passwords in a unified vault.
• Password security dashboard — flags weak, reused, outdated, and compromised credentials across the entire organization.
• Auditable source code — organizations can conduct their own security audit of the Passwork codebase to verify there are no vulnerabilities before deployment.

Passwork holds ISO/IEC 27001 certification, confirming a systematic, audited approach to information security management.

Conclusion

Password chaos is a financial and security liability — and an entirely preventable one. The $70 reset ticket, the $4.44 million breach, the audit that reveals no one knows who had access to what: none of these are inevitable. They're the predictable outcome of treating credentials as an afterthought.

The pattern is consistent across organizations of every size. Passwords get shared through the wrong channels. Policies get enforced inconsistently. Access accumulates over time and never gets cleaned up. Someone leaves, and no one rotates the credentials they touched. Each gap is small on its own. Together, they create the conditions for a breach — or a compliance failure that's just as costly.

The fix is a structural change: centralized storage, defined access, a full audit trail, and a process that makes the secure option the default one — not the inconvenient one.

Passwork is built to make that change straightforward. Whether you deploy on your own infrastructure or in the cloud, your team gets a structured vault, role-based access, and the visibility to know exactly who can reach what — before something goes wrong.

Ready to replace credential sprawl with structured control? Try Passwork on your own infrastructure — our team will assist with installation and configuration. Request a free demo

FAQ: taming the credential chaos

How do you manage passwords for a team without sharing them insecurely?

Use a centralized password manager with role-based access control. Each team member accesses only the credentials assigned to their role — no direct sharing required. Shared vaults with granular permissions replace spreadsheets and chat-based credential distribution. When someone leaves, their access is revoked and affected credentials are flagged for rotation automatically.

Is it safe to store business passwords in a browser?

No. Browser-stored passwords offer no access control, no audit trail, and no encryption beyond the browser's own security model. They sync across devices through cloud accounts that may not meet enterprise security standards. A browser compromise exposes every saved credential simultaneously.

What is credential stuffing and how does a password manager prevent it?

Credential stuffing is an attack where stolen username/password pairs from one breach are automatically tested against other services. It succeeds because of password reuse. A password manager generates and stores unique, strong credentials for every account, eliminating the reuse that makes credential stuffing effective. Combined with MFA, it removes the primary attack vector.

How does a password manager support GDPR and SOC 2 compliance?

A password manager with a full audit log, RBAC, and on-premise deployment directly supports compliance requirements. GDPR requires demonstrable control over who accesses personal data. SOC 2 requires evidence of access management and monitoring. An audit log with user-level activity tracking provides the documentation auditors need — and the visibility security teams need to act on anomalies.

What happens to shared credentials when an employee leaves?

In Passwork offboarding triggers an immediate access revocation. The system identifies all credentials the departing employee had access to and marks them as potentially compromised, prompting the team to rotate them. Without a centralized system, this process is manual, error-prone, and often incomplete.

Does a password manager eliminate the need for MFA?

No — and it shouldn't. A password manager secures credential storage and access; MFA secures authentication. They address different attack surfaces. A strong, unique password prevents credential stuffing; MFA prevents unauthorized access even when a password is compromised. The two controls are complementary, not interchangeable.

How long does it take to deploy a password manager across an organization?

A self-hosted solution like Passwork can be deployed on existing infrastructure — Linux or Windows, with or without Docker — in under an hour. LDAP and Active Directory integration synchronizes users and groups automatically, so there's no need to provision accounts manually. Most teams are fully operational within a day of deployment.

What is password reuse and why is it a major security risk?

Password reuse puts 88% of breaches at risk. Learn why using the same password across accounts is dangerous and how to break the habit today.

Passwork BlogEirik Salmi

Passwork 7.6 release: Service accounts

The latest Passwork release adds service accounts with multi-token API support, saved filters, mobile web UI, and automatic Bin cleanup. See what changed.

Passwork BlogEirik Salmi

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

Einleitung

NIS2 Artikel 21(2)(j) schreibt MFA „wo angemessen" vor — passwortlose Authentifizierung wird nicht explizit gefordert. Allerdings empfiehlt ENISAs Leitfaden von 2025 nachdrücklich Phishing-resistente MFA, wodurch passwortlose Verfahren zum Standard für die Compliance werden. Organisationen, die FIDO2 oder Passkeys einsetzen, sind bei Audits besser aufgestellt als solche, die auf SMS OTP oder veralteten reinen Passwort-Zugang setzen.

Die Frist für formelle NIS2-Compliance-Audits rückt schnell näher. Identitäts- und Zugangsverwaltung taucht regelmäßig als einer der am genauesten geprüften Bereiche auf — fehlende MFA, überprivilegierte Accounts und unverwaltete Anmeldedaten sind die Kontrollen, die Auditoren zuerst prüfen.

Sie prüfen, ob Organisationen nachweisen können, dass Kontrollen kontinuierlich und verhältnismäßig über alle Systeme hinweg funktionieren, einschließlich Legacy-Infrastruktur, die niemals FIDO2 unterstützen wird.

Diese Lücke zwischen moderner und Legacy-Authentifizierung ist der Punkt, an dem die meisten Organisationen exponiert sind.

Kernpunkte

• NIS2 schreibt keine passwortlose Authentifizierung vor — es schreibt MFA „wo angemessen" gemäß Artikel 21(2)(j) vor.
• ENISAs Leitfaden von 2025 positioniert Phishing-resistente MFA (FIDO2, Passkeys) als bevorzugte Implementierung.
• „Wo angemessen" ist keine Schlupfloch — es bedeutet verpflichtend für privilegierten Zugang, Remote-Zugang und sensible Systeme.
• Legacy-Systeme, die FIDO2 nicht unterstützen können, müssen durch kompensierende Kontrollen abgedeckt werden: zentralisierte Anmeldedatenverwaltung, Zugriffsüberprüfungen und dokumentierte Audit-Trails.
• Auditoren verlangen Nachweise, nicht nur eingesetzte Kontrollen. Logs, Zugriffsüberprüfungen und Berichte zur Anmeldedatenhygiene sind das, was Audits besteht.

Artikel 21(2)(j) entschlüsselt: Ist passwortlos verpflichtend?

NIS2 Artikel 21(2)(j) erfordert „die Verwendung von Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierungslösungen… wo angemessen." Eine bestimmte Technologie wird nicht vorgeschrieben. Passwortlose Authentifizierung wird nicht explizit gefordert — aber ENISAs technischer Leitfaden von 2025 identifiziert Phishing-resistente MFA als empfohlenen Standard, und Auditoren behandeln FIDO2 und Passkeys als Maßstab, an dem andere Implementierungen gemessen werden.

Der vollständige Text von Artikel 21 formuliert Sicherheitsanforderungen als ergebnisorientiert: Organisationen müssen „angemessene und verhältnismäßige technische, operative und organisatorische Maßnahmen" ergreifen, um Risiken zu managen. Die Richtlinie vermeidet bewusst die Vorschrift bestimmter Werkzeuge und überlässt die Implementierung der Risikobewertung der jeweiligen Organisation.

„Die Verwendung von Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierungslösungen, gesicherter Sprach-, Video- und Textkommunikation und gesicherter Notfallkommunikationssysteme innerhalb der Einrichtung, wo angemessen." — Artikel 21(2)(j), Richtlinie (EU) 2022/2555

Der Ausdruck „wo angemessen" hat in der Praxis eine spezifische Bedeutung. ENISAs technischer Implementierungsleitfaden interpretiert ihn durchgehend als verpflichtend für:

• Privilegierte und administrative Accounts (§11.3.2)
• Remote-Zugang, VPN und internetexponierte Zugangspunkte (§11.4)
• Zugang zu sensiblen Daten und kritischen Systemen, wobei die Authentifizierungsmethode der Klassifizierung des Assets entsprechen muss (§11.7.2)
• Zugang von Dritten und Auftragnehmern — abgedeckt unter den Verpflichtungen zur Lieferkettensicherheit (Art. 21(2)(d))

Für Standardbenutzer auf risikoarmen Systemen gewährt die Verhältnismäßigkeitsklausel Organisationen eine gewisse Flexibilität, aber diese Flexibilität muss in einer formellen Risikobewertung dokumentiert werden.

Die „Verhältnismäßigkeits"-Klausel: Legacy-Systeme in einer passwortlosen Welt verwalten

Die Verhältnismäßigkeitsanforderung in Artikel 21 ist das am meisten missverstandene Element der NIS2-Compliance und das praktisch wichtigste für Organisationen mit gemischter Infrastruktur. Verhältnismäßig bedeutet nicht „optional". Es bedeutet, dass die Sicherheitsmaßnahme dem Risikoprofil des Systems, den darin enthaltenen Daten sowie der Größe und Exposition der Organisation entsprechen muss.

Das ist wichtig, weil viele Unternehmensumgebungen Systeme beinhalten, die FIDO2 oder Passkeys nicht unterstützen können: ältere ERP-Plattformen, industrielle Steuerungssysteme, Legacy-Webanwendungen und On-Premises-Tools, die vor der Existenz von WebAuthn entwickelt wurden. Passwortlos auf diese Systeme zu erzwingen ist technisch unmöglich. Sie unkontrolliert zu lassen ist ein Compliance-Verstoß.

Für Legacy-Systeme erfordert der verhältnismäßige Ansatz:

• Dokumentierte Risikobewertung — jedes Legacy-System nach Risikolevel formal klassifizieren und begründen, warum eine vollständige passwortlose Einführung technisch nicht machbar ist
• Kompensierende Kontrollen — starke Passwortrichtlinien (15+ Zeichen, keine Wiederverwendung, Rotation bei Kompromittierung), zentralisierte Anmeldedatenspeicherung und Zugriffsbeschränkungen
• Zugriffsüberprüfungen — regelmäßige, dokumentierte Überprüfungen, wer auf was Zugriff hat, mit Nachweisen, die für Audits aufbewahrt werden
• Audit-Trail — jeder Zugriff auf Anmeldedaten, jede Änderung und jedes Teilen-Ereignis wird protokolliert und ist abrufbar

Das Schlüsselwort für Auditoren ist „dokumentiert". Eine nicht dokumentierte kompensierende Kontrolle ist keine Kontrolle.

Die Verwaltung von Anmeldedaten über Legacy- und moderne Systeme hinweg erfordert einen zentralisierten Ansatz. Passwork bietet strukturierte Tresore, rollenbasierten Zugriff und einen vollständigen Audit-Trail — und liefert Ihnen die dokumentierten Nachweise, die Auditoren für jedes System in Ihrer Infrastruktur benötigen. So funktioniert es

Phishing-resistente MFA: Warum passwortlos der Favorit der Auditoren ist

Phishing-resistente MFA — hauptsächlich FIDO2/WebAuthn Hardware-Keys und gerätegebundene Passkeys — ist die Implementierung, die Auditoren bevorzugen, weil sie das Problem des geteilten Geheimnisses vollständig eliminiert. Im Gegensatz zu SMS OTP oder TOTP-Codes sind FIDO2-Anmeldedaten kryptografisch an die Ursprungsdomain gebunden, was Echtzeit-Phishing-Proxy-Angriffe technisch unmöglich macht.

Die Unterscheidung ist operativ relevant. SMS OTPs sind anfällig für SIM-Swapping und SS7-Interception. TOTP-Codes können von Adversary-in-the-Middle-Proxies abgefangen werden. Push-Benachrichtigungen sind anfällig für MFA-Fatigue-Angriffe — bei denen Benutzer Anfragen genehmigen, nur um die Benachrichtigungen zu stoppen. Keine dieser Angriffsklassen funktioniert gegen FIDO2.

Passkeys gewinnen rapide an Bedeutung: 92 % der Organisationen planen laut dem 2026 CISO Perspectives Report (Portnox) die Einführung passwortloser Authentifizierung im Jahr 2026. Auditoren, die 2026 die NIS2-Compliance überprüfen, verwenden diese Entwicklung als Maßstab. Organisationen, die für privilegierten Zugang ausschließlich auf SMS MFA setzen, werden mit Fragen konfrontiert, die sie nicht leicht beantworten können.

MFA-Fatigue

MFA-Fatigue ist eine Social-Engineering-Technik: Ein Angreifer löst wiederholt Push-Authentifizierungsanfragen aus, bis der Benutzer eine genehmigt. Es erfordert keine Malware und keinen Diebstahl von Anmeldedaten — nur einen abgelenkten Administrator und eine schlecht konfigurierte Eingabeaufforderung. Aufsehenerregende Sicherheitsverletzungen bei Uber und Cisco nutzten beide Push-Fatigue als initialen Zugriffsvektor.

MFA-Fatigue ist ein reales operatives Problem im Kontext von NIS2-Audits. Organisationen, die Push-basierte MFA ohne Nummernabgleich einsetzen oder MFA inkonsistent über Systeme hinweg anwenden, schaffen sowohl Sicherheitslücken als auch Benutzer-Widerstand. Die Lösung ist der Einsatz Phishing-resistenter Methoden, die überhaupt keine Benutzerentscheidung erfordern.

FIDO2 und Passkeys eliminieren die menschliche Entscheidung vollständig — die Authentifizierung ist kryptografisch an die legitime Domain gebunden, ohne etwas zu genehmigen und ohne etwas, das durch Social Engineering manipuliert werden könnte.

Die hybride Compliance-Strategie mit Passwork

Die meisten Unternehmensumgebungen werden vor dem Audit-Zyklus keine 100-prozentige passwortlose Abdeckung erreichen. Die realistische Compliance-Position ist hybrid: passwortlos, wo technisch machbar, streng kontrollierte Passwortverwaltung überall sonst. Die kritische Anforderung ist, dass das „überall sonst" dokumentiert, auditierbar und nachweislich verwaltet wird.

Hier wird ein unternehmensweiter Passwort-Manager zu einer Compliance-Kontrolle und nicht nur zu einem Convenience-Tool. Systeme, die FIDO2 nicht unterstützen können, benötigen weiterhin Anmeldedaten — und diese Anmeldedaten müssen sicher gespeichert, zugangskontrolliert, bei Kompromittierung rotiert und vollständig auditierbar sein.

Passwork adressiert die hybride Compliance-Lücke durch vier spezifische Funktionen:

1. Passwortlose Authentifizierung — der Zugang zum Tresor selbst kann über Biometrie, Passkeys oder Hardware-Sicherheitsschlüssel (einschließlich YubiKey und andere WebAuthn-kompatible Geräte) gesichert werden, wodurch das Passwort als schwächstes Glied am Einstiegspunkt eliminiert wird
2. Zentralisierte Anmeldedatenverwaltung — alle Passwörter für Legacy-Systeme, Service-Accounts, API-Keys und gemeinsam genutzte Anmeldedaten werden in verschlüsselten Tresoren gespeichert, niemals in Tabellen oder gemeinsamen Posteingängen
3. Rollenbasierte Zugriffskontrolle — granulare Berechtigungen stellen sicher, dass jeder Benutzer nur auf die Anmeldedaten zugreift, die seine Rolle erfordert; überprivilegierte Accounts werden strukturell verhindert
4. Vollständiger Audit-Trail — jeder Zugriff auf Anmeldedaten, jede Änderung, jedes Teilen-Ereignis und jeder fehlgeschlagene Anmeldeversuch wird mit Zeitstempel und Benutzerzuordnung protokolliert und liefert die dokumentierten Nachweise, die Auditoren benötigen
5. Zugriffsüberprüfungen — periodische Überprüfungen des Tresor-Zugangs können durchgeführt und exportiert werden, um die Anforderung von Artikel 21(2)(i) nach dokumentierten Zugriffskontrollrichtlinien zu erfüllen

Für Organisationen, die Active Directory- oder LDAP-Umgebungen betreiben, integriert sich Passwork direkt — das bedeutet, dass Benutzerbereitstellung und -deprovisionierung durch die bestehende Identitätsinfrastruktur fließen, anstatt eine parallele Verwaltungsbelastung zu schaffen.

Passwork ist als Self-Hosted-Lösung mit voller Kontrolle über Ihre Daten verfügbar — keine Abhängigkeit von Drittanbieter-Clouds, keine Daten verlassen Ihren Perimeter. Deployment-Optionen erkunden

5 Schritte zur NIS2-Authentifizierungs-Compliance 2026

NIS2 erfordert Maßnahmen, die dem Risiko angemessen sind. In der Praxis bedeutet das, dass Auditoren nicht bewerten, ob Sie MFA haben, sondern ob Ihre MFA-Implementierung dem Bedrohungsmodell standhält. Die folgenden fünf Schritte übersetzen diese Anforderung in eine konkrete Handlungssequenz, geordnet nach Audit-Priorität.

1. Erfassen Sie Ihre Authentifizierungsoberfläche. Inventarisieren Sie jedes System, jede Anwendung und jeden Zugangspunkt nach der aktuell verwendeten Authentifizierungsmethode. Klassifizieren Sie jeweils nach Risikolevel: privilegierter Zugang, Remote-Zugang, sensible Daten, Standard intern. Dieses Inventar ist die Grundlage Ihrer Verhältnismäßigkeitsargumentation.
2. Setzen Sie Phishing-resistente MFA zuerst auf Hochrisiko-Zugangspunkten ein. Priorisieren Sie FIDO2/WebAuthn Hardware-Keys oder Passkeys für privilegierte Accounts, Remote-Zugang und sensible Systeme. Hier schauen Auditoren zuerst hin und hier ist das Risiko am höchsten. TOTP ist als Übergangsmaßnahme für Standardbenutzer akzeptabel, während der Rollout fortgesetzt wird.
3. Implementieren Sie einen zentralisierten Passwort-Manager für Legacy-Systeme. Jedes System, das passwortlose Authentifizierung nicht unterstützen kann, muss seine Anmeldedaten in einem strukturierten Tresor mit rollenbasiertem Zugriff und vollständigem Audit-Log verwaltet haben. Anmeldedaten in Tabellen, gemeinsamen Posteingängen oder Klartextdateien sind ein sofortiger Audit-Fehler.
4. Dokumentieren Sie Ihre Risikobewertungen und kompensierenden Kontrollen. Erstellen Sie für jedes System, bei dem passwortlos technisch nicht machbar ist, eine schriftliche Risikobewertung, die erklärt, warum und welche kompensierenden Kontrollen vorhanden sind. Diese Dokumentation ist das, was Auditoren überprüfen — nicht nur die Kontrollen selbst.
5. Etablieren und belegen Sie periodische Zugriffsüberprüfungen. Planen Sie vierteljährliche Zugriffsüberprüfungen für privilegierte Accounts und halbjährliche Überprüfungen für Standard-Accounts. Exportieren und bewahren Sie die Überprüfungsaufzeichnungen auf. Artikel 21(2)(i) erfordert dokumentierte Zugriffskontrollrichtlinien — „wir überprüfen den Zugriff" ist ohne Aufzeichnungen, die beweisen, dass es stattgefunden hat, nicht ausreichend.

Fazit

NIS2-Compliance bei der Authentifizierung ist eine Risikomanagement-Übung, keine Technologie-Checkliste. Die Richtlinie erfordert, dass Organisationen verhältnismäßige, dokumentierte Entscheidungen darüber treffen, wie sie den Zugang zu jedem System in ihrer Umgebung sichern. Für Hochrisiko-Zugangspunkte ist Phishing-resistente MFA der erwartete Standard. Für Legacy-Systeme, die sie nicht unterstützen können, sind dokumentierte kompensierende Kontrollen die Anforderung.

Die Organisationen, die 2026 Vorabprüfungen nicht bestehen, scheitern nicht, weil ihnen Kontrollen fehlen. Sie scheitern, weil sie keine Nachweise vorlegen können, dass diese Kontrollen konsistent funktionieren: Zugriffsprotokolle, Zugriffsüberprüfungsaufzeichnungen, Berichte zur Anmeldedatenhygiene und dokumentierte Risikobewertungen.

Passwork liefert genau diese Nachweisebene: strukturierte Tresore, rollenbasierten Zugriff, vollständige Audit-Logs und Zugriffsüberprüfungs-Exporte, die Auditoren das geben, was sie brauchen. In Kombination mit Phishing-resistenter MFA auf Ihren Hochrisiko-Zugangspunkten ist dies das, was eine vertretbare hybride Compliance-Position ausmacht.

Bereit, die Lücke in der Anmeldedatenverwaltung vor Ihrem NIS2-Audit zu schließen? Passwork gibt Ihrem Team zentralisierte Anmeldedatenkontrolle, einen vollständigen Audit-Trail und Self-Hosted-Deployment — alle dokumentierten Nachweise, die Auditoren benötigen. Passwork in Ihrer Infrastruktur testen

FAQ: Häufige Fragen zur NIS2-Authentifizierung

Erfordert NIS2 MFA für interne Systeme?

Artikel 21(2)(j) erfordert MFA „wo angemessen". ENISA-Leitlinien und nationale Umsetzungen interpretieren dies durchgehend als verpflichtend für privilegierte Accounts und Remote-Zugang, unabhängig davon, ob der Zugang intern oder extern ist. Für Standardbenutzer auf risikoarmen Systemen gilt Verhältnismäßigkeit — aber die Entscheidung muss in einer formellen Risikobewertung dokumentiert werden, nicht angenommen.

Welche Bußgelder drohen bei nicht-konformer MFA unter NIS2?

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. Über regulatorische Bußgelder hinaus erreichten die durchschnittlichen Kosten einer Datenschutzverletzung in den USA 2025 10,22 Millionen Dollar (IBM Cost of a Data Breach Report 2025) — Anmeldedatenkontrollen kosten einen Bruchteil beider Beträge.

Können wir SMS MFA für die NIS2-Compliance verwenden?

SMS OTP wird unter NIS2 für privilegierten Zugang oder sensible Systeme nicht empfohlen. Es ist anfällig für SIM-Swapping, SS7-Angriffe und Echtzeit-Phishing-Proxies. Die ENISA-Leitlinien stimmen mit NIST SP 800-63B überein, das SMS als eingeschränkten Authentifikator klassifiziert. Für Standardbenutzer in risikoarmen Kontexten kann SMS als Übergangsmaßnahme akzeptabel sein — aber es sollte nicht der Endpunkt Ihrer MFA-Strategie sein und wird bei Audits genau geprüft.

Was gilt als „Phishing-resistente" MFA unter NIS2?

Phishing-resistente MFA bedeutet Authentifizierungsmethoden, bei denen die Anmeldedaten nicht von einem Angreifer in Echtzeit abgefangen und wiedergegeben werden können. FIDO2/WebAuthn Hardware-Sicherheitsschlüssel und gerätegebundene Passkeys erfüllen diese Definition — sie verwenden Public-Key-Kryptografie, die an die Ursprungsdomain gebunden ist. TOTP-Codes, SMS OTPs und Push-Benachrichtigungen erfüllen diesen Standard nicht, da sie einen Wert übertragen oder anzeigen, der von einem Angreifer erfasst und verwendet werden kann.

Wie handhaben wir NIS2 MFA für Service-Accounts und API-Keys?

Service-Accounts und API-Keys sind ein häufiger Audit-Fehlerpunkt — sie haben oft erhöhte Berechtigungen und keine MFA, weil sie nicht-interaktiv sind. NIS2-Compliance für diese Accounts erfordert zentralisierte Speicherung in einem verschlüsselten Tresor mit Zugriffskontrollen und Audit-Logging, regelmäßige Rotation ausgelöst durch Risikobewertung oder Kompromittierungserkennung sowie dokumentierte Eigentümerschaft. Jede Service-Anmeldedaten sollte einen benannten Eigentümer haben, der für ihren Lebenszyklus verantwortlich ist.

NIS2-Passwortanforderungen: Was europäische Unternehmen 2026 tun müssen

Lücken bei Anmeldedaten sind der führende Punkt für NIS2-Audit-Versagen 2026. Dieser Leitfaden behandelt die Passwortanforderungen nach Artikel 21, die Angleichung an NIST SP 800-63B, AD-Härtungsschritte und die Audit-Nachweise, die Regulierungsbehörden zuerst anfordern.

Passwork BlogAlex Muntyan

Prävention von Datenschutzverletzungen für Unternehmen: Über den einfachen Virenschutz hinaus

82 % der Angriffe 2026 sind malwarefrei — Virenschutz wird sie nicht abfangen. Dieser Leitfaden behandelt eine 7-Schichten-Verteidigungsstrategie für Anmeldedatendiebstahl, Lateral Movement und Lieferkettenangriffe.

Passwork BlogAlex Muntyan

Passwork 7.6 Release: Service-Accounts

Die neueste Passwork-Version fügt Service-Accounts mit Multi-Token-API-Unterstützung, gespeicherte Filter, mobile Web-UI und automatische Papierkorb-Bereinigung hinzu. Sehen Sie, was sich geändert hat.

Passwork BlogEirik Salmi

Introducción

El Artículo 21(2)(j) de NIS2 exige MFA «cuando proceda» — no requiere explícitamente la autenticación sin contraseña. Sin embargo, la guía de ENISA de 2025 recomienda encarecidamente MFA resistente al phishing, convirtiendo la autenticación sin contraseña en el estándar para el cumplimiento. Las organizaciones que implementan FIDO2 o passkeys están mejor posicionadas para las auditorías que aquellas que dependen de SMS OTP o del acceso heredado solo con contraseña.

La fecha límite para las auditorías formales de cumplimiento de NIS2 se acerca rápidamente. La gestión de identidades y accesos surge constantemente como una de las áreas más examinadas — la falta de MFA, las cuentas con privilegios excesivos y las credenciales no gestionadas son los controles que los auditores verifican primero.

Los auditores verifican si las organizaciones pueden demostrar que los controles operan de forma continua y proporcionada en todos los sistemas, incluida la infraestructura heredada que nunca admitirá FIDO2.

Esa brecha entre la autenticación moderna y heredada es donde la mayoría de las organizaciones están expuestas.

Puntos clave

• NIS2 no exige la autenticación sin contraseña — exige MFA «cuando proceda» según el Artículo 21(2)(j).
• La guía de ENISA de 2025 posiciona el MFA resistente al phishing (FIDO2, passkeys) como la implementación preferida.
• «Cuando proceda» no es una laguna legal — significa obligatorio para el acceso privilegiado, el acceso remoto y los sistemas sensibles.
• Los sistemas heredados que no pueden soportar FIDO2 deben estar cubiertos por controles compensatorios: gestión centralizada de credenciales, revisiones de acceso y registros de auditoría documentados.
• Los auditores exigen evidencia, no solo controles implementados. Los registros, las revisiones de acceso y los informes de higiene de credenciales son lo que aprueba las auditorías.

Decodificando el Artículo 21(2)(j): ¿Es obligatoria la autenticación sin contraseña?

El Artículo 21(2)(j) de NIS2 requiere «el uso de autenticación multifactor o soluciones de autenticación continua… cuando proceda.» No prescribe una tecnología específica. La autenticación sin contraseña no se exige explícitamente — pero la guía técnica de ENISA de 2025 identifica el MFA resistente al phishing como el estándar recomendado, y los auditores tratan FIDO2 y passkeys como el punto de referencia contra el cual se miden otras implementaciones.

El texto completo del Artículo 21 enmarca los requisitos de seguridad como basados en resultados: las organizaciones deben tomar «medidas técnicas, operativas y organizativas apropiadas y proporcionadas» para gestionar el riesgo. La directiva evita deliberadamente prescribir herramientas específicas, dejando la implementación a la evaluación de riesgos de la entidad.

«El uso de autenticación multifactor o soluciones de autenticación continua, comunicaciones de voz, vídeo y texto seguras y sistemas de comunicaciones de emergencia seguros dentro de la entidad, cuando proceda.» — Artículo 21(2)(j), Directiva (UE) 2022/2555

La frase «cuando proceda» tiene un significado específico en la práctica. La Guía de Implementación Técnica de ENISA la interpreta consistentemente como obligatoria para:

• Cuentas privilegiadas y administrativas (§11.3.2)
• Acceso remoto, VPN y puntos de entrada con conexión a Internet (§11.4)
• Acceso a datos sensibles y sistemas críticos, donde el método de autenticación debe coincidir con la clasificación del activo (§11.7.2)
• Acceso de terceros y contratistas — cubierto bajo las obligaciones de seguridad de la cadena de suministro (Art. 21(2)(d))

Para usuarios internos estándar en sistemas de bajo riesgo, la cláusula de proporcionalidad otorga cierta flexibilidad a las organizaciones, pero esa flexibilidad debe documentarse en una evaluación de riesgos formal.

La cláusula de «proporcionalidad»: Gestión de sistemas heredados en un mundo sin contraseñas

El requisito de proporcionalidad en el Artículo 21 es el elemento más malinterpretado del cumplimiento de NIS2 y el más prácticamente importante para las organizaciones que operan infraestructura mixta. Proporcionado no significa «opcional». Significa que la medida de seguridad debe coincidir con el perfil de riesgo del sistema, los datos que contiene y el tamaño y exposición de la entidad.

Esto importa porque muchos entornos empresariales incluyen sistemas que no pueden soportar FIDO2 o passkeys: plataformas ERP antiguas, sistemas de control industrial, aplicaciones web heredadas y herramientas locales construidas antes de que existiera WebAuthn. Forzar la autenticación sin contraseña en estos sistemas es técnicamente imposible. Dejarlos sin control es un fallo de cumplimiento.

Para sistemas heredados, el enfoque proporcionado requiere:

• Evaluación de riesgos documentada — clasificar formalmente cada sistema heredado por nivel de riesgo y justificar por qué la adopción completa de autenticación sin contraseña no es técnicamente factible
• Controles compensatorios — políticas de contraseñas robustas (más de 15 caracteres, sin reutilización, rotación activada por compromiso), almacenamiento centralizado de credenciales y restricciones de acceso
• Revisiones de acceso — revisiones periódicas y documentadas de quién tiene acceso a qué, con evidencia conservada para auditoría
• Registro de auditoría — cada acceso a credenciales, cambio y evento de compartición registrado y recuperable

La palabra clave para los auditores es «documentado». Un control compensatorio no documentado no es un control.

Gestionar credenciales en sistemas heredados y modernos requiere un enfoque centralizado. Passwork proporciona bóvedas estructuradas, control de acceso basado en roles y un registro de auditoría completo — brindando la evidencia documentada que los auditores requieren para cada sistema en su infraestructura. Vea cómo funciona

MFA resistente al phishing: Por qué la autenticación sin contraseña es la favorita del auditor

El MFA resistente al phishing — principalmente llaves de hardware FIDO2/WebAuthn y passkeys vinculados al dispositivo — es la implementación que prefieren los auditores porque elimina por completo el problema del secreto compartido. A diferencia de SMS OTP o códigos TOTP, las credenciales FIDO2 están criptográficamente vinculadas al dominio de origen, haciendo técnicamente imposibles los ataques de proxy de phishing en tiempo real.

La distinción importa operativamente. Los SMS OTP son vulnerables al intercambio de SIM y la interceptación SS7. Los códigos TOTP pueden ser interceptados por proxies de adversario en el medio. Las notificaciones push son susceptibles a ataques de fatiga de MFA — donde los usuarios aprueban solicitudes simplemente para detener las notificaciones. Ninguna de estas clases de ataque funciona contra FIDO2.

Los passkeys están ganando tracción rápidamente: el 92% de las organizaciones planea adoptar la autenticación sin contraseña en 2026 según el Informe de Perspectivas CISO 2026 (Portnox). Los auditores que revisan el cumplimiento de NIS2 en 2026 están utilizando esta trayectoria como punto de referencia. Las organizaciones que aún dependen exclusivamente de SMS MFA para el acceso privilegiado enfrentarán preguntas que no pueden responder fácilmente.

Fatiga de MFA

La fatiga de MFA es una técnica de ingeniería social: un atacante activa repetidamente solicitudes de autenticación push hasta que el usuario aprueba una. No requiere malware ni robo de credenciales — solo un administrador distraído y un aviso mal configurado. Las brechas de alto perfil en Uber y Cisco utilizaron la fatiga push como vector de acceso inicial.

La fatiga de MFA es una preocupación operativa real en los contextos de auditoría de NIS2. Las organizaciones que implementan MFA basado en push sin coincidencia de números, o que aplican MFA de manera inconsistente entre sistemas, crean tanto brechas de seguridad como resistencia del usuario. La solución es implementar métodos resistentes al phishing que no requieran ninguna decisión del usuario.

FIDO2 y passkeys eliminan completamente la decisión humana — la autenticación está criptográficamente vinculada al dominio legítimo, sin nada que aprobar y nada que manipular mediante ingeniería social

La estrategia de cumplimiento híbrida con Passwork

La mayoría de los entornos empresariales no lograrán una cobertura 100% sin contraseña antes del ciclo de auditoría. La postura de cumplimiento realista es híbrida: sin contraseña donde sea técnicamente factible, gestión de contraseñas estrictamente controlada en todo lo demás. El requisito crítico es que ese «todo lo demás» esté documentado, sea auditable y esté demostrablemente gestionado.

Aquí es donde un gestor de contraseñas corporativo se convierte en un control de cumplimiento, no solo en una herramienta de conveniencia. Los sistemas que no pueden soportar FIDO2 aún requieren credenciales — y esas credenciales deben almacenarse de forma segura, con control de acceso, rotarse ante compromiso y ser completamente auditables.

Passwork aborda la brecha de cumplimiento híbrido a través de cuatro capacidades específicas:

1. Autenticación sin contraseña — el acceso a la propia bóveda puede asegurarse mediante biometría, passkeys o llaves de seguridad de hardware (incluyendo YubiKey y otros dispositivos compatibles con WebAuthn), eliminando la contraseña como el eslabón más débil en el punto de entrada
2. Gestión centralizada de credenciales — todas las contraseñas para sistemas heredados, cuentas de servicio, claves API y credenciales compartidas almacenadas en bóvedas cifradas, nunca en hojas de cálculo o bandejas de entrada compartidas
3. Control de acceso basado en roles — los permisos granulares aseguran que cada usuario acceda solo a las credenciales que su rol requiere; las cuentas con privilegios excesivos se previenen estructuralmente
4. Registro de auditoría completo — cada acceso a credenciales, modificación, evento de compartición e intento de inicio de sesión fallido se registra con marcas de tiempo y atribución de usuario, proporcionando la evidencia documentada que los auditores requieren
5. Revisiones de acceso — se pueden realizar y exportar revisiones periódicas del acceso a la bóveda, satisfaciendo el requisito del Artículo 21(2)(i) para políticas de control de acceso documentadas

Para organizaciones que ejecutan entornos Active Directory o LDAP, Passwork se integra directamente — lo que significa que el aprovisionamiento y desaprovisionamiento de usuarios fluye a través de la infraestructura de identidad existente en lugar de crear una carga de gestión paralela.

Passwork está disponible como solución autoalojada con control total sobre sus datos — sin dependencia de nube de terceros, sin datos que salgan de su perímetro. Explore las opciones de implementación

5 pasos para el cumplimiento de autenticación NIS2 en 2026

NIS2 requiere medidas proporcionadas al riesgo. En la práctica, eso significa que los auditores evaluarán no si tiene MFA, sino si su implementación de MFA resiste el modelo de amenazas. Los siguientes cinco pasos traducen ese requisito en una secuencia de acciones concreta, ordenada por prioridad de auditoría.

1. Mapee su superficie de autenticación. Haga un inventario de cada sistema, aplicación y punto de acceso por método de autenticación actualmente en uso. Clasifique cada uno por nivel de riesgo: acceso privilegiado, acceso remoto, datos sensibles, interno estándar. Este inventario es la base de su argumento de proporcionalidad.
2. Implemente MFA resistente al phishing en los puntos de acceso de alto riesgo primero. Priorice las llaves de hardware FIDO2/WebAuthn o passkeys para cuentas privilegiadas, acceso remoto y sistemas sensibles. Aquí es donde los auditores miran primero y donde el riesgo es mayor. TOTP es aceptable como medida provisional para usuarios estándar mientras continúa el despliegue.
3. Implemente un gestor de contraseñas centralizado para sistemas heredados. Cada sistema que no puede soportar autenticación sin contraseña debe tener sus credenciales gestionadas en una bóveda estructurada con acceso basado en roles y un registro de auditoría completo. Las credenciales en hojas de cálculo, bandejas de entrada compartidas o archivos de texto plano son un fallo de auditoría inmediato.
4. Documente sus evaluaciones de riesgos y controles compensatorios. Para cada sistema donde la autenticación sin contraseña no es técnicamente factible, produzca una evaluación de riesgos escrita explicando por qué y qué controles compensatorios están implementados. Esta documentación es lo que revisan los auditores — no solo los controles en sí.
5. Establezca y evidencie revisiones de acceso periódicas. Programe revisiones de acceso trimestrales para cuentas privilegiadas y revisiones semestrales para cuentas estándar. Exporte y conserve los registros de revisión. El Artículo 21(2)(i) requiere políticas de control de acceso documentadas — «revisamos el acceso» no es suficiente sin registros que demuestren que sucedió.

Conclusión

El cumplimiento de NIS2 en autenticación es un ejercicio de gestión de riesgos, no una lista de verificación tecnológica. La directiva requiere que las organizaciones tomen decisiones proporcionadas y documentadas sobre cómo aseguran el acceso a cada sistema en su entorno. Para puntos de acceso de alto riesgo, el MFA resistente al phishing es el estándar esperado. Para sistemas heredados que no pueden soportarlo, los controles compensatorios documentados son el requisito.

Las organizaciones que están fallando las pre-auditorías en 2026 no están fallando porque carecen de controles. Están fallando porque no pueden producir evidencia de que esos controles operan de manera consistente: registros de acceso, registros de revisión de acceso, informes de higiene de credenciales y evaluaciones de riesgos documentadas.

Passwork proporciona exactamente esa capa de evidencia: bóvedas estructuradas, acceso basado en roles, registros de auditoría completos y exportaciones de revisión de acceso que dan a los auditores lo que necesitan. Combinado con MFA resistente al phishing en sus puntos de acceso de alto riesgo, esto es lo que parece una postura de cumplimiento híbrida defendible.

¿Listo para cerrar la brecha de gestión de credenciales antes de su auditoría NIS2? Passwork brinda a su equipo control centralizado de credenciales, un registro de auditoría completo e implementación autoalojada — toda la evidencia documentada que los auditores requieren. Pruebe Passwork en su infraestructura

Preguntas frecuentes: Preguntas comunes sobre autenticación NIS2

¿Requiere NIS2 MFA para sistemas internos?

El Artículo 21(2)(j) requiere MFA «cuando proceda». La guía de ENISA y las transposiciones nacionales interpretan consistentemente esto como obligatorio para cuentas privilegiadas y acceso remoto, independientemente de si el acceso es interno o externo. Para usuarios internos estándar en sistemas de bajo riesgo, se aplica la proporcionalidad — pero la decisión debe documentarse en una evaluación de riesgos formal, no asumirse.

¿Cuáles son las multas por MFA no conforme bajo NIS2?

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. Más allá de las multas regulatorias, el costo promedio de una brecha de datos en EE. UU. alcanzó los 10,22 millones de dólares en 2025 (Informe de Costo de una Brecha de Datos de IBM 2025) — los controles de credenciales cuestan una fracción de cualquiera de las cifras.

¿Podemos usar SMS MFA para el cumplimiento de NIS2?

SMS OTP no se recomienda bajo NIS2 para acceso privilegiado o sistemas sensibles. Es vulnerable al intercambio de SIM, ataques SS7 y proxies de phishing en tiempo real. La guía de ENISA se alinea con NIST SP 800-63B, que clasifica SMS como un autenticador restringido. Para usuarios estándar en contextos de bajo riesgo, SMS puede ser aceptable como medida de transición — pero no debería ser el punto final de su estrategia de MFA, y atraerá escrutinio en las auditorías.

¿Qué cuenta como MFA «resistente al phishing» bajo NIS2?

MFA resistente al phishing significa métodos de autenticación donde la credencial no puede ser interceptada y reproducida por un atacante en tiempo real. Las llaves de seguridad de hardware FIDO2/WebAuthn y los passkeys vinculados al dispositivo cumplen esta definición — utilizan criptografía de clave pública vinculada al dominio de origen. Los códigos TOTP, SMS OTP y las notificaciones push no cumplen este estándar porque transmiten o muestran un valor que puede ser capturado y utilizado por un atacante.

¿Cómo manejamos el MFA de NIS2 para cuentas de servicio y claves API?

Las cuentas de servicio y las claves API son un punto de fallo común en las auditorías — a menudo tienen permisos elevados y no tienen MFA porque no son interactivas. El cumplimiento de NIS2 para estas cuentas requiere almacenamiento centralizado en una bóveda cifrada con controles de acceso y registro de auditoría, rotación regular activada por evaluación de riesgos o detección de compromiso, y propiedad documentada. Cada credencial de servicio debe tener un propietario nombrado responsable de su ciclo de vida.

Requisitos de contraseñas NIS2: Lo que las empresas europeas deben hacer en 2026

Las brechas de credenciales son el principal punto de fallo en las auditorías NIS2 en 2026. Esta guía cubre los requisitos de contraseñas del Artículo 21, la alineación con NIST SP 800-63B, los pasos de fortalecimiento de AD y la evidencia de auditoría que los reguladores solicitan primero.

Passwork BlogAlex Muntyan

Prevención de brechas de datos para empresas: Más allá del antivirus básico

El 82% de los ataques en 2026 no usan malware — el antivirus no los detectará. Esta guía cubre una estrategia de defensa de 7 capas diseñada para el robo de credenciales, el movimiento lateral y el compromiso de la cadena de suministro.

Passwork BlogAlex Muntyan

Lanzamiento de Passwork 7.6: Cuentas de servicio

La última versión de Passwork añade cuentas de servicio con soporte API de múltiples tokens, filtros guardados, interfaz web móvil y limpieza automática de la papelera. Vea qué cambió.

Passwork BlogEirik Salmi

Introduction

NIS2 Article 21(2)(j) mandates MFA "where appropriate" — it does not explicitly require passwordless authentication. However, ENISA's 2025 guidance strongly recommends phishing-resistant MFA, making passwordless the standard for compliance. Organizations that deploy FIDO2 or passkeys are better positioned for audit than those relying on SMS OTP or legacy password-only access.

The deadline for formal NIS2 compliance audits is approaching fast. Identity and access management consistently surfaces as one of the most scrutinized areas — missing MFA, over-privileged accounts, and unmanaged credentials are the controls auditors check first.

They are checking whether organizations can prove controls operate continuously and proportionately across every system, including legacy infrastructure that will never support FIDO2.

That gap between modern and legacy authentication is where most organizations are exposed.

Key takeaways

• NIS2 does not mandate passwordless authentication — it mandates MFA "where appropriate" under Article 21(2)(j).
• ENISA's 2025 guidance positions phishing-resistant MFA (FIDO2, passkeys) as the preferred implementation.
• "Where appropriate" is not a loophole — it means mandatory for privileged access, remote access, and sensitive systems.
• Legacy systems that cannot support FIDO2 must be covered by compensating controls: centralized credential management, access reviews, and documented audit trails.
• Auditors demand evidence, not just deployed controls. Logs, access reviews, and credential hygiene reports are what pass audits.

Decoding Article 21(2)(j): Is passwordless mandatory?

NIS2 Article 21(2)(j) requires "the use of multi-factor authentication or continuous authentication solutions… where appropriate." It does not prescribe a specific technology. Passwordless authentication is not explicitly mandated — but ENISA's 2025 technical guidance identifies phishing-resistant MFA as the recommended standard, and auditors treat FIDO2 and passkeys as the benchmark against which other implementations are measured.

The full text of Article 21 frames security requirements as outcome-based: organizations must take "appropriate and proportionate technical, operational and organisational measures" to manage risk. The directive deliberately avoids prescribing specific tools, leaving implementation to the entity's risk assessment.

"The use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate." — Article 21(2)(j), Directive (EU) 2022/2555

The phrase "where appropriate" has a specific meaning in practice. ENISA's Technical Implementation Guidance consistently interprets it as mandatory for:

• Privileged and administrative accounts (§11.3.2)
• Remote access, VPN, and internet-facing entry points (§11.4)
• Access to sensitive data and critical systems, where the authentication method must match the asset's classification (§11.7.2)
• Third-party and contractor access — covered under supply chain security obligations (Art. 21(2)(d))

For standard internal users on low-risk systems, the proportionality clause gives organizations some flexibility but that flexibility must be documented in a formal risk assessment.

The "proportionate" clause: Managing legacy systems in a passwordless world

The proportionality requirement in Article 21 is the most misunderstood element of NIS2 compliance and the most practically important for organizations running mixed infrastructure. Proportionate does not mean "optional." It means the security measure must match the risk profile of the system, the data it holds, and the entity's size and exposure.

This matters because many enterprise environments include systems that cannot support FIDO2 or passkeys: older ERP platforms, industrial control systems, legacy web applications, and on-premises tools built before WebAuthn existed. Forcing passwordless on these systems is technically impossible. Leaving them uncontrolled is a compliance failure.

For legacy systems, the proportionate approach requires:

• Documented risk assessment — formally classify each legacy system by risk level and justify why full passwordless adoption is not technically feasible
• Compensating controls — strong password policies (15+ characters, no reuse, compromise-triggered rotation), centralized credential storage, and access restrictions
• Access reviews — periodic, documented reviews of who has access to what, with evidence retained for audit
• Audit trail — every credential access, change, and sharing event logged and retrievable

The key word for auditors is "documented." An undocumented compensating control is not a control.

Managing credentials across legacy and modern systems requires a centralized approach. Passwork provides structured vaults, role-based access, and a full audit trail — giving you the documented evidence auditors require for every system in your infrastructure. See how it works

Phishing-resistant MFA: Why passwordless is the auditor's favorite

Phishing-resistant MFA — primarily FIDO2/WebAuthn hardware keys and device-bound passkeys — is the implementation auditors prefer because it eliminates the shared-secret problem entirely. Unlike SMS OTP or TOTP codes, FIDO2 credentials are cryptographically bound to the origin domain, making real-time phishing proxy attacks technically impossible.

The distinction matters operationally. SMS OTPs are vulnerable to SIM swapping and SS7 interception. TOTP codes can be intercepted by adversary-in-the-middle proxies. Push notifications are susceptible to MFA fatigue attacks — where users approve requests simply to stop the notifications. None of these attack classes work against FIDO2.

Passkeys are gaining rapid traction: 92% of organizations plan to adopt passwordless authentication in 2026 according to 2026 CISO Perspectives Report (Portnox). Auditors reviewing NIS2 compliance in 2026 are using this trajectory as a benchmark. Organizations still relying exclusively on SMS MFA for privileged access will face questions they cannot easily answer.

MFA fatigue

MFA fatigue is a social engineering technique: an attacker repeatedly triggers push authentication requests until the user approves one. It requires no malware and no credential theft — only a distracted administrator and a poorly configured prompt. High-profile breaches at Uber and Cisco both used push fatigue as the initial access vector.

MFA fatigue is a real operational concern in NIS2 audit contexts. Organizations that deploy push-based MFA without number matching, or that apply MFA inconsistently across systems, create both security gaps and user resistance. The solution is to deploy phishing-resistant methods that require no user decision at all.

FIDO2 and passkeys remove the human decision entirely — authentication is cryptographically bound to the legitimate domain, with nothing to approve and nothing to socially engineer

The hybrid compliance strategy with Passwork

Most enterprise environments will not achieve 100% passwordless coverage before the audit cycle. The realistic compliance posture is hybrid: passwordless where technically feasible, tightly controlled password management everywhere else. The critical requirement is that the "everywhere else" is documented, auditable, and demonstrably managed.

This is where a corporate password manager becomes a compliance control, not just a convenience tool. Systems that cannot support FIDO2 still require credentials — and those credentials must be stored securely, access-controlled, rotated on compromise, and fully auditable.

Passwork addresses the hybrid compliance gap through four specific capabilities:

1. Passwordless authentication — access to the vault itself can be secured via biometrics, passkeys, or hardware security keys (including YubiKey and other WebAuthn-compatible devices), eliminating the password as the weakest link at the entry point
2. Centralized credential management — all passwords for legacy systems, service accounts, API keys, and shared credentials stored in encrypted vaults, never in spreadsheets or shared inboxes
3. Role-based access control — granular permissions ensure that each user accesses only the credentials their role requires; over-privileged accounts are structurally prevented
4. Full audit trail — every credential access, modification, sharing event, and failed login attempt is logged with timestamps and user attribution, providing the documented evidence auditors require
5. Access reviews — periodic reviews of vault access can be conducted and exported, satisfying the Article 21(2)(i) requirement for documented access control policies

For organizations running Active Directory or LDAP environments, Passwork integrates directly — meaning user provisioning and deprovisioning flows through existing identity infrastructure rather than creating a parallel management burden.

Passwork is available as a self-hosted solution with full control over your data — no third-party cloud dependency, no data leaving your perimeter. Explore deployment options

5 steps to NIS2 authentication compliance in 2026

NIS2 requires measures proportionate to the risk. In practice, that means auditors will evaluate not whether you have MFA, but whether your MFA implementation holds up against the threat model. The following five steps translate that requirement into a concrete action sequence, ordered by audit priority.

1. Map your authentication surface. Inventory every system, application, and access point by authentication method currently in use. Classify each by risk level: privileged access, remote access, sensitive data, standard internal. This inventory is the foundation of your proportionality argument.
2. Deploy phishing-resistant MFA on high-risk access points first. Prioritize FIDO2/WebAuthn hardware keys or passkeys for privileged accounts, remote access, and sensitive systems. This is where auditors look first and where the risk is highest. TOTP is acceptable as an interim measure for standard users while rollout continues.
3. Implement a centralized password manager for legacy systems. Every system that cannot support passwordless authentication must have its credentials managed in a structured vault with role-based access and a full audit log. Credentials in spreadsheets, shared inboxes, or plaintext files are an immediate audit failure.
4. Document your risk assessments and compensating controls. For every system where passwordless is not technically feasible, produce a written risk assessment explaining why and what compensating controls are in place. This documentation is what auditors review — not just the controls themselves.
5. Establish and evidence periodic access reviews. Schedule quarterly access reviews for privileged accounts and semi-annual reviews for standard accounts. Export and retain the review records. Article 21(2)(i) requires documented access control policies — "we review access" is not sufficient without records proving it happened.

Conclusion

NIS2 compliance on authentication is a risk management exercise, not a technology checklist. The directive requires that organizations make proportionate, documented decisions about how they secure access to every system in their environment. For high-risk access points, phishing-resistant MFA is the expected standard. For legacy systems that cannot support it, documented compensating controls are the requirement.

The organizations failing pre-audits in 2026 are not failing because they lack controls. They are failing because they cannot produce evidence that those controls are operating consistently: access logs, access review records, credential hygiene reports, and documented risk assessments.

Passwork provides exactly that evidence layer: structured vaults, role-based access, complete audit logs, and access review exports that give auditors what they need. Combined with phishing-resistant MFA on your high-risk access points, this is what a defensible hybrid compliance posture looks like.

Ready to close the credential management gap before your NIS2 audit? Passwork gives your team centralized credential control, a full audit trail, and self-hosted deployment — all the documented evidence auditors require. Try Passwork in your infrastructure

FAQ: Common NIS2 authentication questions

Does NIS2 require MFA for internal systems?

Article 21(2)(j) requires MFA "where appropriate." ENISA guidance and national transpositions consistently interpret this as mandatory for privileged accounts and remote access, regardless of whether the access is internal or external. For standard internal users on low-risk systems, proportionality applies — but the decision must be documented in a formal risk assessment, not assumed.

What are the fines for non-compliant MFA under NIS2?

Essential entities face fines of 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. Beyond regulatory fines, the average cost of a data breach in the US reached $10.22 million in 2025 (IBM Cost of a Data Breach Report 2025) — credential controls cost a fraction of either figure.

Can we use SMS MFA for NIS2 compliance?

SMS OTP is not recommended under NIS2 for privileged access or sensitive systems. It is vulnerable to SIM swapping, SS7 attacks, and real-time phishing proxies. ENISA guidance aligns with NIST SP 800-63B, which classifies SMS as a restricted authenticator. For standard users in low-risk contexts, SMS may be acceptable as a transitional measure — but it should not be the endpoint of your MFA strategy, and it will attract scrutiny in audits.

What counts as "phishing-resistant" MFA under NIS2?

Phishing-resistant MFA means authentication methods where the credential cannot be intercepted and replayed by an attacker in real time. FIDO2/WebAuthn hardware security keys and device-bound passkeys meet this definition — they use public-key cryptography bound to the origin domain. TOTP codes, SMS OTPs, and push notifications do not meet this standard because they transmit or display a value that can be captured and used by an attacker.

How do we handle NIS2 MFA for service accounts and API keys?

Service accounts and API keys are a common audit failure point — they often have elevated permissions and no MFA because they are non-interactive. NIS2 compliance for these accounts requires centralized storage in an encrypted vault with access controls and audit logging, regular rotation triggered by risk assessment or compromise detection, and documented ownership. Every service credential should have a named owner responsible for its lifecycle.

NIS2 password requirements: What European companies must do in 2026

Credential gaps are the leading NIS2 audit failure point in 2026. This guide covers Article 21 password requirements, NIST SP 800-63B alignment, AD hardening steps, and the audit evidence regulators ask for first.

Passwork BlogAlex Muntyan

Data breach prevention for business: Beyond basic antivirus

82% of attacks in 2026 are malware-free — antivirus won’t catch them. This guide covers a 7-layer defense strategy built for credential theft, lateral movement, and supply chain compromise.

Passwork BlogAlex Muntyan

Passwork 7.6 release: Service accounts

The latest Passwork release adds service accounts with multi-token API support, saved filters, mobile web UI, and automatic Bin cleanup. See what changed.

Passwork BlogEirik Salmi

The new release brings independent token lifecycle management, flexible SSL certificate verification, and multi-URL support for password items.

Token lifecycle management

Previously, the only way to extend an active session was to call the full token refresh — which replaced both the access token and the refresh token at once. Version 0.2.0 introduces two new methods for independent, fine-grained control over session lifetime.

update_access_token()

Extends the access token using the current access token, without touching the refresh token. Useful when you want to keep a long-lived session alive in a background service without cycling the refresh token.

result = client.update_access_token()
# result contains: accessToken, accessTokenExpiredAt

update_refresh_token()

Extends the refresh token using the current refresh token, without affecting the access token. Useful in scripts that run infrequently and need to maintain a valid refresh token between runs.

result = client.update_refresh_token()
# result contains: refreshToken, refreshTokenExpiredAt

Both methods automatically update the internal client state and re-save the session file if one is configured.

SSL certificate verification

The PassworkClient now accepts a string path as the verify_ssl parameter in addition to True and False. This allows you to specify a custom CA certificate bundle — useful in corporate environments with internal PKI or self-signed certificates.

# Use system default CA bundle (default behavior)
client = PassworkClient("https://passwork.example.com", verify_ssl=True)

# Use a custom CA bundle
client = PassworkClient("https://passwork.example.com", verify_ssl="/etc/ssl/certs/ca-bundle.crt")

# Disable verification (not recommended for production)
client = PassworkClient("https://passwork.example.com", verify_ssl=False)

Multiple URLs per item

Password items now expose a urls field — a list of all URLs associated with the item. The existing url field (primary URL) remains unchanged for backward compatibility.

item = client.get_item(item_id)

print(item["url"])   # https://example.com  (primary)
print(item["urls"])  # ["https://example.com", "https://staging.example.com"]

Requirements

• Python ≥ 3.10
• Passwork 7 server

Useful links

• Python connector documentation
• CLI utility documentation
• Integration examples

Spring 2026 EU cybersecurity update: What changed

Spring 2026 brought the EU’s most significant institutional breach, its first cyber sanctions of the year, and four major cybersecurity regulations enforcing simultaneously. NIS2, DORA, CRA, and CSA2 now set hard deadlines — and real penalties. Here’s what changed, who’s affected, and what to do.

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

NIS2 latest news: What changed and what it means for EU businesses

84% of in-scope organizations admit they’re not ready. Belgium set the first conformity assessment deadline on April 18, 2026. The Netherlands is days away from enforcement. Here’s where the regulatory wave stands and what IT leaders need to act on now.

Passwork BlogAlex Muntyan