Passwork Team

Esta semana trajo varios incidentes importantes, y todos apuntan en la misma dirección. La escala del compromiso de credenciales sigue batiendo récords. FortiBleed: 86.000 dispositivos en 194 países. La filtración de Elasticsearch: 24 mil millones de registros de decenas de fuentes. HIBP añadió 124 millones de contraseñas robadas por infostealers en el momento de uso. Estos datos ya están en circulación.

• Dos métodos de ataque recibieron confirmación concreta esta semana. Los atacantes cada vez más evitan las contraseñas por completo: la brecha de Klue comenzó con una cuenta de servicio olvidada y terminó con tokens OAuth robados — sin introducir ninguna contraseña en ningún momento.
• Los agentes de IA se han convertido en un vector de ataque independiente: un repositorio de prueba de código envenenado permitió a un atacante exfiltrar credenciales de AWS desde la estación de trabajo de un desarrollador en 111 segundos, sin generar alertas en el endpoint.
• La presión regulatoria avanza en dos frentes. En Europa, el Consejo de Europa y la plataforma gubernamental francesa Tchap fueron vulnerados, la autoridad italiana Garante multó a una empresa por almacenar contraseñas en texto plano, y se publicaron nuevas plantillas de notificación de incidentes del EDPB y NIS2 — todo en una sola semana.
• En EE. UU., el presidente Trump firmó dos órdenes ejecutivas estableciendo plazos federales estrictos para la migración a criptografía poscuántica, señalando que la ventana de preparación es más corta de lo que la mayoría de las organizaciones habían asumido.

Este resumen cubre los 14 eventos más significativos del 15 al 22 de junio de 2026.

EE. UU. establece plazos federales para la migración a criptografía poscuántica (PQC)

El 22 de junio de 2026, el presidente Trump firmó dos órdenes ejecutivas sobre tecnología cuántica. La orden ejecutiva «Securing the Nation Against Advanced Cryptographic Attacks» requiere que las agencias federales designen un responsable de migración PQC, transicionen los activos de alto valor a criptografía poscuántica para 2030 y completen la migración total para 2031.

Una segunda orden dirige el desarrollo de un ordenador cuántico tolerante a fallos para 2028. Ambas órdenes citan los ataques «harvest now, decrypt later» como el principal factor de amenaza — adversarios recopilando datos cifrados hoy para descifrarlos en el futuro. Barron's informa que algunos analistas sitúan la capacidad viable de descifrado cuántico tan pronto como 2029.

Por qué es importante: Los plazos federales de 2030-2031 no permanecerán dentro del gobierno. Los contratos de adquisición y la regulación sectorial específica tienden a seguir el precedente federal, por lo que cualquier organización que interactúe con infraestructura gubernamental u opere en una industria regulada debería tratar esto como una señal temprana. El punto de partida práctico es saber qué se tiene: qué sistemas dependen de RSA o ECC, dónde residen realmente las claves criptográficas y los certificados, y quién los controla.

Fuente: Reuters / White House — 22 jun 2026

FortiBleed: Más de 86.000 credenciales de dispositivos Fortinet comprometidas en 194 países

Una campaña de robo de credenciales a gran escala ha compilado una base de datos verificada de más de 86.644 credenciales funcionales para firewalls FortiGate de Fortinet y dispositivos SSL VPN expuestos a internet — aproximadamente el 50% de todos esos dispositivos expuestos a internet. La campaña incluyó interceptación de autenticación SSL VPN, descifrado de hashes en un clúster de 45 GPU y pivoteo en Active Directory.

Los atacantes ejecutaron aproximadamente 1.160 millones de intentos de credenciales contra más de 320.000 objetivos FortiGate. CISA emitió un aviso urgente el 18 de junio de 2026, requiriendo que las organizaciones terminen las sesiones activas, restablezcan todas las credenciales, habiliten MFA resistente al phishing y apliquen hash de contraseñas PBKDF2 para cuentas de administrador. Huntress confirmó que 845 organizaciones asociadas fueron directamente afectadas.

Por qué es importante: Las organizaciones que parchearon las vulnerabilidades de Fortinet pero nunca rotaron las credenciales permanecen completamente expuestas. Este es el evento de seguridad de credenciales definitorio de la semana. Cualquier organización con infraestructura Fortinet expuesta a internet debería tratar esto como un incidente activo que requiere rotación inmediata de credenciales — no como una tarea de mantenimiento programada.

Fuente: SecurityWeek — 19 jun 2026

24 mil millones de credenciales robadas expuestas en una filtración colosal de Elasticsearch

Investigadores de Cybernews descubrieron un clúster de Elasticsearch públicamente accesible que contenía 24 mil millones de registros de credenciales robadas en 8,3 terabytes de datos, extraídos de 36 fuentes distintas incluyendo registros de malware infostealer, canales de cibercrimen en Telegram y compilaciones de brechas. Más de 1.700 millones de registros se originaron en canales de Telegram.

Críticamente, el clúster también contenía aproximadamente 9.500 registros CVE vinculados a repositorios activos de GitHub — evidencia de que el operador estaba construyendo un pipeline de priorización de ataques para cruzar referencias de vulnerabilidades explotables con credenciales robadas disponibles. La base de datos ha sido desconectada, pero las credenciales permanecen en circulación activa.

Por qué es importante: El pipeline de ataque enriquecido con CVE cambia el cálculo de riesgo: rotar credenciales después de una brecha puede ser demasiado tarde si un atacante ya sabe qué servicios sin parchear desbloquean. Los registros frescos de infostealer también contienen cookies de sesión activas que evitan el MFA por completo. Las credenciales únicas por servicio siguen siendo la defensa estructural principal.

Fuente: Cybernews — 17 jun 2026

124 millones de contraseñas únicas de infostealer añadidas a Have I Been Pwned

El 15 de junio de 2026, Have I Been Pwned (HIBP) incorporó 56,3 millones de direcciones de correo electrónico únicas y 124 millones de contraseñas únicas provenientes de registros de malware infostealer. A diferencia de los datos de brechas tradicionales, estas credenciales fueron robadas directamente de los dispositivos de las víctimas en el momento de uso — lo que significa que son actuales y no han sido rotadas. El conjunto de datos ahora es consultable a través de la API de Pwned Passwords, que está integrada en numerosos gestores de contraseñas empresariales y plataformas de identidad.

Por qué es importante: Las organizaciones que utilizan gestores de contraseñas con integración HIBP ahora verán alertas para un grupo sustancialmente mayor de credenciales en riesgo. El peligro aquí es la frescura: los empleados que no han cambiado sus contraseñas desde que su dispositivo fue infectado permanecen completamente expuestos. Este es un impulso directo para ejecutar una auditoría de credenciales comprometidas en toda su organización.

Fuente: Have I Been Pwned — 15 jun 2026

Ataque a la cadena de suministro SaaS de Klue: Tokens OAuth robados, datos CRM exfiltrados de múltiples proveedores de seguridad

Un nuevo grupo de extorsión llamado Icarus (activo desde abril de 2026) obtuvo acceso inicial a la plataforma de inteligencia de mercado Klue a través de una credencial heredada comprometida asociada con una cuenta de servicio de integración abandonada. Los atacantes luego robaron tokens OAuth utilizados por los clientes de Klue para conectarse a Salesforce y Gong, y ejecutaron scripts automatizados contra la REST API de Salesforce durante hasta 24 horas de extracción masiva de datos CRM.

Las víctimas confirmadas incluyen Huntress, Recorded Future, Tanium, Gong, Sprout Social, Jamf e Insurity. Salesforce deshabilitó la integración de Klue.

Por qué es importante: Una credencial de cuenta de servicio heredada olvidada fue el vector de acceso inicial. Una vez dentro, el atacante no necesitó contraseñas ni códigos MFA — el token OAuth robado era la identidad desde la perspectiva de Salesforce. El ataque se ejecutó sin ser detectado durante 24 horas. Las credenciales de cuentas de servicio y las integraciones OAuth de terceros merecen la misma disciplina de monitoreo que las cuentas de empleados.

Fuente: The Hacker News — 19 jun 2026

Más de 1.230 claves API y tokens JWT codificados encontrados en archivos de instrucciones de agentes IA en más de 7.000 repositorios públicos

Mitiga Labs escaneó más de 50.000 archivos de instrucciones de IA (reglas de Cursor, CLAUDE.md, configuraciones MCP, archivos de cerebro de agentes) en más de 7.000 repositorios públicos de GitHub y encontró más de 1.230 claves API y tokens JWT codificados en servicios que incluyen Anthropic Claude, OpenAI GPT-5, Google Gemini, Databricks, Supabase, Vercel y Google Cloud Storage.

Por separado, GitGuardian informó que 28,65 millones de secretos fueron filtrados en GitHub público en 2025 (un aumento interanual del 34%) con filtraciones de servicios de IA aumentando un 81%.

Por qué es importante: Los archivos de configuración de agentes de IA se están convirtiendo en un vector principal para la exposición de credenciales codificadas. Estos archivos son frecuentemente creados por usuarios sin conciencia de seguridad — product managers, investigadores, fundadores — que no aplican las prácticas estándar de higiene de secretos. Las políticas de escaneo de secretos de la mayoría de las organizaciones aún no cubren archivos de instrucciones, configuraciones MCP y archivos de contexto de agentes. Deberían hacerlo.

Fuente: Mitiga Labs — 15 jun 2026

Una prueba de código envenenada causa que un agente IA robe credenciales de AWS en menos de 2 minutos

Mitiga documentó un ataque del mundo real en el que un repositorio falso de evaluación de código para llevar a casa contenía instrucciones ocultas en archivos .cursor/rules, README.md y CLAUDE.md. Cuando un desarrollador abrió el repositorio en Cursor con la ejecución automática habilitada, el agente de codificación IA ejecutó de forma autónoma cat ~/.aws/credentials, aws sts get-caller-identity, cat ~/.kube/config, terraform state list y un grep de secretos — luego exfiltró todos los datos recopilados a un endpoint controlado por el atacante a través de una llamada de herramienta MCP envenenada. Toda la cadena se completó en 1 minuto y 51 segundos. No se instaló malware; no se generaron alertas en el endpoint.

Por qué es importante: Las credenciales de nube de larga duración almacenadas en estaciones de trabajo de desarrolladores son ahora un objetivo principal para ataques mediados por agentes IA. Cada acción fue realizada por una herramienta legítima usando comandos legítimos — ningún control de endpoint se activó. La mitigación principal es reemplazar las credenciales de larga duración con tokens OIDC de corta duración y autenticación federada.

Fuente: Mitiga Labs — 19 jun 2026

ShinyHunters reclama la brecha del Consejo de Europa: 297 GB de registros de RRHH, nóminas y médicos expuestos

El colectivo hacker ShinyHunters reclamó la responsabilidad de una brecha en el Consejo de Europa, alegando el robo de 297 GB de datos que comprenden más de 429.000 archivos — incluyendo 409.000 nóminas que cubren más de 10.000 empleados durante 15 años, 14.000 CVs, 3.700 expedientes de personal y registros sensibles incluyendo direcciones domiciliarias, salarios, datos bancarios, información fiscal y registros médicos. A fecha del 21 de junio de 2026, ShinyHunters publicó los datos de forma permanente después de que el Consejo de Europa no respondiera a las demandas de rescate.

Por qué es importante: Los registros expuestos crean vectores efectivos de spear-phishing contra una institución sensible. ShinyHunters ahora ha reclamado la Comisión Europea (marzo de 2026), el Consejo de Europa (junio de 2026) y la teleco holandesa Odido (febrero de 2026) en un solo año. Los equipos de seguridad europeos deberían tratar esto como una campaña de ataque sostenida, no como incidentes aislados.

Fuente: Cybernews — 15 jun 2026

La plataforma de mensajería gubernamental francesa Tchap vulnerada: 73.467 cuentas de funcionarios comprometidas

La plataforma soberana de mensajería gubernamental de Francia, Tchap (utilizada por más de 825.000 empleados gubernamentales), fue vulnerada el 7 de junio de 2026 por un actor de amenazas autodenominado «misere». DINUM confirmó que 73.467 cuentas gubernamentales fueron afectadas, con datos expuestos que incluyen nombres, direcciones de correo electrónico y entidades gubernamentales afiliadas.

El actor de amenazas además afirma haber robado 13,5 GB de archivos incluyendo más de 643.000 mensajes. Se cree que el vector de ataque involucra el secuestro de cuentas, posiblemente a través de credenciales obtenidas de registros de stealer.

Por qué es importante: La brecha ilustra cómo el compromiso de credenciales (potencialmente a través de registros de stealer) puede ser utilizado como arma contra la infraestructura de comunicación gubernamental soberana a escala. Los expertos en seguridad señalaron que el ataque puede no haber requerido zero-days: la extracción de datos basada en API utilizando credenciales legítimas es suficiente para esta escala de exfiltración. Bajo NIS2, los servicios digitales gubernamentales están clasificados como entidades esenciales, lo que activa la notificación obligatoria de incidentes a ANSSI.

Fuente: SecurityWeek — 15 jun 2026

Velvet Ant (nexo con China) instala puertas traseras en módulos PAM de Linux y OpenSSH para robo de credenciales durante una década

El equipo de respuesta a incidentes de Sygnia descubrió la Operación Highland, una campaña de espionaje de casi una década por el actor de amenazas Velvet Ant vinculado a China. Activo desde al menos 2016-2017, el grupo modificó los Módulos de Autenticación Conectables (PAM) de Linux — específicamente pam_unix.so — para aceptar una contraseña de puerta trasera codificada, recolectar credenciales de intentos de autenticación legítimos y suprimir todo el registro de actividad del atacante. Se encontraron nueve instancias del módulo PAM con puerta trasera en los hosts comprometidos. El grupo también instaló puertas traseras en binarios de OpenSSH para mantener acceso persistente.

Por qué es importante: Este ataque no robó contraseñas — subvirtió la capa de autenticación en sí. Al modificar los módulos PAM, Velvet Ant podía autenticarse como cualquier usuario y recolectar cada contraseña introducida en los hosts comprometidos. Las contraseñas fuertes no ofrecen protección cuando la pila de autenticación está comprometida. Los operadores de infraestructura crítica en energía, manufactura y defensa enfrentan riesgos directamente análogos.

Fuente: CyberSecurityNews / Sygnia — 15 jun 2026

La autoridad italiana Garante multa a una consultora con 85.000 € por almacenar contraseñas en texto plano tras una brecha de 61.000 usuarios

La autoridad de protección de datos de Italia, la Garante, impuso una multa de 85.000 € a una consultora tras una brecha de datos que expuso datos personales de más de 61.000 usuarios. La Garante encontró que ciertas contraseñas estaban almacenadas en texto plano o protegidas con algoritmos criptográficos obsoletos, y que las credenciales de sistemas no utilizados se habían conservado más allá de su período necesario. Los individuos afectados fueron notificados aproximadamente dos meses después del descubrimiento — y solo después de que se emitiera una orden correctiva.

Por qué es importante: La Garante citó explícitamente el almacenamiento de contraseñas en texto plano y la criptografía obsoleta como las principales infracciones del RGPD. Esto establece un precedente claro de aplicación: el Artículo 32 requiere hash moderno de contraseñas, y retener credenciales para sistemas fuera de servicio viola el principio de limitación del almacenamiento. Las organizaciones de la UE deberían auditar sus implementaciones de almacenamiento de contraseñas contra esta decisión.

Fuente: Gibson Dunn Europe Data Protection — 15 jun 2026

El EDPB adopta una plantilla armonizada de notificación de brechas de datos para toda la UE bajo el RGPD

El Comité Europeo de Protección de Datos (EDPB) ha adoptado una plantilla estandarizada para las notificaciones de brechas de datos personales bajo el Artículo 33 del RGPD, abierta a consulta pública hasta el 5 de agosto de 2026. La plantilla proporciona a las organizaciones de toda la UE un único formulario estructurado para informar brechas de datos personales a las autoridades de supervisión, reemplazando los formatos nacionales actualmente fragmentados.

Por qué es importante: La plantilla armonizada afecta directamente cómo las organizaciones informan incidentes de exposición de credenciales bajo el Artículo 33 del RGPD, requiriendo divulgación estructurada de tipos de datos comprometidos, individuos afectados y consecuencias probables. Los equipos de cumplimiento y legales deberían revisar el borrador antes de la fecha límite de consulta del 5 de agosto.

Fuente: LexisNexis UK/EU Risk & Compliance — 18 jun 2026

ANSSI dejará de certificar productos de seguridad sin cifrado resistente a la computación cuántica a partir de 2027

La agencia nacional de ciberseguridad de Francia, ANSSI, anunció que dejará de certificar productos de seguridad (incluyendo gestores de contraseñas, VPNs y soluciones de autenticación) que no incorporen criptografía resistente a la computación cuántica (poscuántica) a partir de 2027.

El anuncio acompaña a la estrategia cibernética nacional más amplia de Francia, que incluye una inversión gubernamental de 200 millones de euros en infraestructura de ciberseguridad y herramientas de criptografía poscuántica.

Por qué es importante: Los gestores de contraseñas y bóvedas de credenciales dependen de primitivas criptográficas teóricamente vulnerables a ataques de computación cuántica. El requisito de certificación de ANSSI exige algoritmos poscuánticos para la aprobación del gobierno francés, convirtiendo a Francia en el primer estado miembro de la UE en establecer una fecha límite estricta. El marco de ANSSI es ampliamente referenciado en toda Europa y se espera que influya en el Esquema Europeo de Certificación de Ciberseguridad de ENISA.

Fuente: Reuters — 16 jun 2026

Gartner identifica tres cambios en la gestión de secretos que los equipos de seguridad no pueden ignorar

Gartner identifica tres cambios estratégicos en la gestión de secretos:

1. Gestión de acceso de cargas de trabajo — pasar de secretos estáticos a emisión de credenciales dinámicas y justo a tiempo para cargas de trabajo.
2. Arquitectura sin secretos — eliminar completamente los secretos de larga duración en favor del acceso basado en identidad usando SPIFFE/SPIRE.
3. Gobernanza multi-bóveda — gestionar secretos de forma consistente a través de múltiples plataformas de bóvedas a medida que las organizaciones acumulan almacenes de secretos dispares en HashiCorp Vault, AWS Secrets Manager, Azure Key Vault y otros.

Por qué es importante: Estos tres cambios mapean directamente a los modos de fallo expuestos esta semana. FortiBleed demuestra el riesgo de credenciales estáticas nunca rotadas (Cambio 1). La brecha OAuth de Klue demuestra el riesgo de credenciales heredadas de larga duración (Cambio 2). La deriva de credenciales a través de entornos multi-nube es el problema que aborda el Cambio 3. Este marco proporciona a los líderes de seguridad y TI una forma estructurada de evaluar su madurez actual en gestión de secretos frente a los incidentes de la semana.

Fuente: Akeyless Blog (citando investigación de Gartner) — 17 jun 2026

Resumen de esta semana

El patrón a través de los incidentes de esta semana es lo suficientemente consistente como para nombrarlo: credenciales estáticas, cuentas de servicio olvidadas y tokens de larga duración son los puntos de entrada que los atacantes están explotando activamente.

La aplicación regulatoria está alcanzando. La multa de 85.000 € de la Garante italiana por almacenamiento de contraseñas en texto plano, los plazos federales de PQC de EE. UU. y el límite de certificación de ANSSI para 2027 añaden una dimensión prospectiva: los fundamentos criptográficos del almacenamiento de credenciales están bajo un plazo estricto.

Tres acciones se derivan directamente de los eventos de esta semana:

• Primero, audite las cuentas de servicio e integraciones OAuth de terceros — el ataque de Klue comenzó con una olvidada.
• Segundo, ejecute una verificación de credenciales comprometidas contra el conjunto de datos de HIBP ahora expandido con 124 millones de contraseñas provenientes de infostealers.
• Tercero, revise cómo viven los secretos en las estaciones de trabajo de los desarrolladores. Las credenciales de nube de larga duración son ahora un objetivo explícito de agentes IA.

Las credenciales fuera de cualquier sistema gestionado son la raíz común — claves API codificadas, credenciales de VPN no rotadas, contraseñas en texto plano en servicios fuera de servicio. Passwork proporciona a los equipos de TI y seguridad visibilidad centralizada sobre las contraseñas corporativas y los secretos técnicos, con registros de acceso, seguimiento de rotación y alertas de credenciales comprometidas integrados. Comience con lo que puede controlar

Ciclo de vida de rotación de secretos: Desde la creación hasta la revocación

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

Passwork BlogAlex Muntyan

10 fallos de seguridad en el trabajo remoto (y cómo solucionarlos)

10 fallos de seguridad en el trabajo remoto — y el único principio detrás de todos ellos: la seguridad se rompe donde el camino seguro tiene más fricción que el inseguro. Casos reales, soluciones realistas, una línea base de 5 capas contra la que su equipo puede auditar.

Passwork BlogAlex Muntyan

Controles de acceso NIS2 para la seguridad de la cadena de suministro

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

Passwork BlogAlex Muntyan

Diese Woche brachte mehrere schwerwiegende Vorfälle, und alle weisen in dieselbe Richtung. Das Ausmaß der Credential-Kompromittierung bricht weiterhin Rekorde. FortiBleed: 86.000 Geräte in 194 Ländern. Das Elasticsearch-Leck: 24 Milliarden Datensätze aus Dutzenden von Quellen. HIBP fügte 124 Millionen Passwörter hinzu, die von Infostealern zum Zeitpunkt der Nutzung gestohlen wurden. Diese Daten sind bereits im Umlauf.

• Zwei Angriffsmethoden erhielten diese Woche konkrete Bestätigung. Angreifer umgehen Passwörter zunehmend vollständig: Der Klue-Breach begann mit einem vergessenen Dienstkonto und endete mit gestohlenen OAuth-Tokens — ohne dass an irgendeinem Punkt ein Passwort eingegeben wurde.
• KI-Agenten sind zu einem eigenständigen Angriffsvektor geworden: Ein vergiftetes Coding-Test-Repository ermöglichte es einem Angreifer, AWS-Credentials von der Workstation eines Entwicklers in 111 Sekunden zu exfiltrieren, ohne dass Endpoint-Alerts ausgelöst wurden.
• Der regulatorische Druck bewegt sich an zwei Fronten. In Europa wurden der Europarat und die französische Regierungsplattform Tchap kompromittiert, die italienische Garante verhängte eine Geldstrafe gegen ein Unternehmen wegen Speicherung von Passwörtern im Klartext, und neue EDPB- sowie NIS2-Meldepflichtvorlagen wurden veröffentlicht — alles innerhalb einer einzigen Woche.
• In den USA unterzeichnete Präsident Trump zwei Executive Orders, die verbindliche Bundesfristen für die Migration zur Post-Quanten-Kryptographie festlegen. Dies signalisiert, dass das Zeitfenster zur Vorbereitung kürzer ist, als die meisten Organisationen angenommen haben.

Dieser Digest behandelt die 14 bedeutendsten Ereignisse vom 15. bis 22. Juni 2026.

USA setzen Bundesfristen für die Migration zur Post-Quanten-Kryptographie (PQC)

Am 22. Juni 2026 unterzeichnete Präsident Trump zwei Executive Orders zur Quantentechnologie. Die EO „Securing the Nation Against Advanced Cryptographic Attacks" verpflichtet Bundesbehörden, einen PQC-Migrationsverantwortlichen zu benennen, hochwertige Vermögenswerte bis 2030 auf Post-Quanten-Kryptographie umzustellen und die vollständige Migration bis 2031 abzuschließen.

Eine zweite Anordnung weist die Entwicklung eines fehlertoleranten Quantencomputers bis 2028 an. Beide Anordnungen nennen „Harvest Now, Decrypt Later"-Angriffe als primären Bedrohungstreiber — Angreifer sammeln heute verschlüsselte Daten für eine zukünftige Entschlüsselung. Barron's berichtet, dass einige Analysten eine funktionsfähige Quantenentschlüsselungsfähigkeit bereits für 2029 prognostizieren.

Warum es wichtig ist: Die Bundesfristen 2030–2031 werden nicht innerhalb der Regierung bleiben. Beschaffungsverträge und branchenspezifische Regulierungen folgen typischerweise dem Bundesvorbild, daher sollte jede Organisation, die mit Regierungsinfrastruktur zu tun hat oder in einer regulierten Branche tätig ist, dies als frühes Signal betrachten. Der praktische Ausgangspunkt ist zu wissen, was man hat: Welche Systeme von RSA oder ECC abhängen, wo sich kryptographische Schlüssel und Zertifikate tatsächlich befinden und wer sie kontrolliert.

Quelle: Reuters / White House — 22. Jun 2026

FortiBleed: Über 86.000 Fortinet-Geräte-Credentials in 194 Ländern kompromittiert

Eine groß angelegte Credential-Diebstahl-Kampagne hat eine verifizierte Datenbank mit über 86.644 funktionierenden Credentials für internetfähige Fortinet FortiGate Firewalls und SSL-VPN-Appliances zusammengestellt — etwa 50 % aller solcher dem Internet ausgesetzten Geräte. Die Kampagne umfasste das Abfangen von SSL-VPN-Authentifizierung, Hash-Cracking auf einem 45-GPU-Cluster und Active-Directory-Pivoting.

Angreifer führten ungefähr 1,16 Milliarden Credential-Versuche gegen über 320.000 FortiGate-Ziele durch. CISA gab am 18. Juni 2026 eine dringende Warnung heraus, die Organisationen verpflichtet, aktive Sitzungen zu beenden, alle Credentials zurückzusetzen, Phishing-resistente MFA zu aktivieren und PBKDF2-Passwort-Hashing für Admin-Accounts anzuwenden. Huntress bestätigte, dass 845 Partnerorganisationen direkt betroffen waren.

Warum es wichtig ist: Organisationen, die Fortinet-Schwachstellen gepatcht, aber ihre Credentials nie rotiert haben, bleiben vollständig exponiert. Dies ist das entscheidende Credential-Sicherheitsereignis der Woche. Jede Organisation mit internetfähiger Fortinet-Infrastruktur sollte dies als aktiven Vorfall behandeln, der eine sofortige Credential-Rotation erfordert — nicht als geplante Wartungsaufgabe.

Quelle: SecurityWeek — 19. Jun 2026

24 Milliarden gestohlene Credentials durch massives Elasticsearch-Leck exponiert

Cybernews-Forscher entdeckten einen öffentlich zugänglichen Elasticsearch-Cluster mit 24 Milliarden gestohlenen Credential-Datensätzen über 8,3 Terabyte an Daten, die aus 36 verschiedenen Quellen stammten, darunter Infostealer-Malware-Logs, Telegram-Cybercrime-Kanäle und Breach-Sammlungen. Mehr als 1,7 Milliarden Datensätze stammten von Telegram-Kanälen.

Kritisch ist, dass der Cluster auch ungefähr 9.500 CVE-Datensätze enthielt, die mit aktiven GitHub-Repositories verknüpft waren — ein Beweis dafür, dass der Betreiber eine Angriffs-Priorisierungspipeline aufbaute, um ausnutzbare Schwachstellen mit verfügbaren gestohlenen Credentials abzugleichen. Die Datenbank wurde offline genommen, aber die Credentials befinden sich weiterhin im aktiven Umlauf.

Warum es wichtig ist: Die CVE-angereicherte Angriffspipeline verändert die Risikokalkulation: Die Rotation von Credentials nach einem Breach kann zu spät sein, wenn ein Angreifer bereits weiß, welche ungepatchten Dienste sie entsperren. Frische Infostealer-Logs enthalten auch aktive Session-Cookies, die MFA vollständig umgehen. Einzigartige Credentials pro Dienst bleiben die primäre strukturelle Verteidigung.

Quelle: Cybernews — 17. Jun 2026

124 Millionen einzigartige Infostealer-Passwörter zu Have I Been Pwned hinzugefügt

Am 15. Juni 2026 nahm Have I Been Pwned (HIBP) 56,3 Millionen einzigartige E-Mail-Adressen und 124 Millionen einzigartige Passwörter auf, die aus Infostealer-Malware-Logs stammen. Anders als traditionelle Breach-Daten wurden diese Credentials direkt von den Geräten der Opfer zum Zeitpunkt der Nutzung gestohlen — was bedeutet, dass sie aktuell und nicht rotiert sind. Der Datensatz ist jetzt über die Pwned Passwords API durchsuchbar, die in zahlreiche Unternehmens-Passwort-Manager und Identitätsplattformen integriert ist.

Warum es wichtig ist: Organisationen, die Passwort-Manager mit HIBP-Integration verwenden, werden nun Warnungen für einen wesentlich größeren Pool gefährdeter Credentials anzeigen. Die Gefahr hier ist die Aktualität: Mitarbeiter, die ihre Passwörter seit der Infektion ihres Geräts nicht geändert haben, bleiben vollständig exponiert. Dies ist ein direkter Anlass, ein Audit kompromittierter Credentials in Ihrer gesamten Organisation durchzuführen.

Quelle: Have I Been Pwned — 15. Jun 2026

Klue-SaaS-Supply-Chain-Angriff: OAuth-Tokens gestohlen, CRM-Daten von mehreren Sicherheitsanbietern exfiltriert

Eine neue Erpressergruppe namens Icarus (aktiv seit April 2026) verschaffte sich über ein kompromittiertes Legacy-Credential, das mit einem aufgegebenen Integrations-Dienstkonto verknüpft war, Erstzugang zur Market-Intelligence-Plattform Klue. Die Angreifer stahlen dann OAuth-Tokens, die von Klues Kunden zur Verbindung mit Salesforce und Gong verwendet wurden, und führten automatisierte Skripte gegen die Salesforce REST API für bis zu 24 Stunden Massen-CRM-Datenextraktion aus.

Bestätigte Opfer sind Huntress, Recorded Future, Tanium, Gong, Sprout Social, Jamf und Insurity. Salesforce deaktivierte die Klue-Integration.

Warum es wichtig ist: Ein vergessenes Legacy-Dienstkonto-Credential war der initiale Zugangsvektor. Einmal eingedrungen, benötigte der Angreifer keine Passwörter und keine MFA-Codes — das gestohlene OAuth-Token war aus Salesforce-Perspektive die Identität. Der Angriff lief 24 Stunden unentdeckt. Dienstkonto-Credentials und OAuth-Integrationen von Drittanbietern verdienen dieselbe Überwachungsdisziplin wie Mitarbeiterkonten.

Quelle: The Hacker News — 19. Jun 2026

Über 1.230 hartcodierte API-Schlüssel und JWT-Tokens in KI-Agenten-Anweisungsdateien in über 7.000 öffentlichen Repos gefunden

Mitiga Labs scannte über 50.000 KI-Anweisungsdateien (Cursor-Regeln, CLAUDE.md, MCP-Configs, Agent-Brain-Dateien) in über 7.000 öffentlichen GitHub-Repositories und fand über 1.230 hartcodierte API-Schlüssel und JWT-Tokens für Dienste wie Anthropic Claude, OpenAI GPT-5, Google Gemini, Databricks, Supabase, Vercel und Google Cloud Storage.

Separat berichtete GitGuardian, dass 28,65 Millionen Secrets 2025 auf öffentlichem GitHub geleakt wurden (ein Anstieg von 34 % im Jahresvergleich), wobei Leaks von KI-Diensten um 81 % zunahmen.

Warum es wichtig ist: KI-Agenten-Konfigurationsdateien werden zu einem primären Vektor für die Exponierung hartcodierter Credentials. Diese Dateien werden häufig von Benutzern ohne Sicherheitsbewusstsein erstellt — Produktmanager, Forscher, Gründer — die keine standardmäßigen Secrets-Hygienepraktiken anwenden. Die Secrets-Scanning-Richtlinien der meisten Organisationen decken Anweisungsdateien, MCP-Configs und Agent-Kontextdateien noch nicht ab. Das sollten sie.

Quelle: Mitiga Labs — 15. Jun 2026

Vergifteter Coding-Test veranlasst KI-Agenten, AWS-Credentials in unter 2 Minuten zu stehlen

Mitiga dokumentierte einen realen Angriff, bei dem ein gefälschtes Take-Home-Coding-Assessment-Repository versteckte Anweisungen in .cursor/rules-, README.md- und CLAUDE.md-Dateien enthielt. Als ein Entwickler das Repository in Cursor mit aktiviertem Auto-Run öffnete, führte der KI-Coding-Agent autonom cat ~/.aws/credentials, aws sts get-caller-identity, cat ~/.kube/config, terraform state list und einen Grep nach Secrets aus — und exfiltrierte dann alle gesammelten Daten über einen vergifteten MCP-Tool-Aufruf zu einem vom Angreifer kontrollierten Endpunkt. Die gesamte Kette wurde in 1 Minute 51 Sekunden abgeschlossen. Es wurde keine Malware installiert; es wurden keine Endpoint-Alerts generiert.

Warum es wichtig ist: Langlebige Cloud-Credentials, die auf Entwickler-Workstations gespeichert sind, sind jetzt ein primäres Ziel für KI-Agenten-vermittelte Angriffe. Jede Aktion wurde von einem legitimen Tool mit legitimen Befehlen durchgeführt — keine Endpoint-Kontrollen wurden ausgelöst. Die primäre Gegenmaßnahme ist das Ersetzen langlebiger Credentials durch kurzlebige OIDC-Tokens und föderierte Authentifizierung.

Quelle: Mitiga Labs — 19. Jun 2026

ShinyHunters beansprucht Europarat-Breach: 297 GB an HR-, Gehalts- und Medizindaten exponiert

Das Hackerkollektiv ShinyHunters übernahm die Verantwortung für einen Breach des Europarats und behauptete, 297 GB an Daten mit über 429.000 Dateien gestohlen zu haben — darunter 409.000 Gehaltsabrechnungen für über 10.000 Mitarbeiter über 15 Jahre, 14.000 Lebensläufe, 3.700 Personalakten und sensible Datensätze einschließlich Privatadressen, Gehälter, Bankdaten, Steuerinformationen und Krankenakten. Zum 21. Juni 2026 veröffentlichte ShinyHunters die Daten dauerhaft, nachdem der Europarat nicht auf Lösegeldforderungen reagiert hatte.

Warum es wichtig ist: Die exponierten Datensätze schaffen effektive Spear-Phishing-Vektoren gegen eine sensible Institution. ShinyHunters hat nun innerhalb eines einzigen Jahres die Europäische Kommission (März 2026), den Europarat (Juni 2026) und den niederländischen Telekommunikationsanbieter Odido (Februar 2026) für sich beansprucht. Europäische Sicherheitsteams sollten dies als eine anhaltende gezielte Kampagne betrachten, nicht als isolierte Vorfälle.

Quelle: Cybernews — 15. Jun 2026

Frankreichs Tchap-Regierungs-Messaging-Plattform gehackt: 73.467 Beamtenkonten kompromittiert

Frankreichs souveräne Regierungs-Messaging-Plattform Tchap (genutzt von über 825.000 Regierungsangestellten) wurde am 7. Juni 2026 von einem Bedrohungsakteur namens „misere" gehackt. DINUM bestätigte, dass 73.467 Regierungskonten betroffen waren, wobei die exponierten Daten Namen, E-Mail-Adressen und zugehörige Regierungsstellen umfassten.

Der Bedrohungsakteur behauptet zusätzlich, 13,5 GB an Dateien einschließlich über 643.000 Nachrichten gestohlen zu haben. Der Angriffsvektor soll Account-Hijacking beinhalten, möglicherweise über Infostealer-gestützte Credentials.

Warum es wichtig ist: Der Breach illustriert, wie Credential-Kompromittierung (möglicherweise über Stealer-Logs) gegen souveräne Regierungs-Kommunikationsinfrastruktur in großem Maßstab als Waffe eingesetzt werden kann. Sicherheitsexperten stellten fest, dass der Angriff möglicherweise keine Zero-Days erforderte: API-basierte Datenextraktion mit legitimen Credentials reicht für dieses Ausmaß an Exfiltration aus. Unter NIS2 werden digitale Regierungsdienste als wesentliche Einrichtungen klassifiziert, was eine obligatorische Vorfallsmeldung an ANSSI auslöst.

Quelle: SecurityWeek — 15. Jun 2026

Velvet Ant (China-Nexus) installiert Backdoors in Linux-PAM-Modulen und OpenSSH für jahrzehntelangen Credential-Diebstahl

Das Incident-Response-Team von Sygnia deckte Operation Highland auf, eine fast zehn Jahre andauernde Spionagekampagne des mit China verbundenen Bedrohungsakteurs Velvet Ant. Seit mindestens 2016–2017 aktiv, modifizierte die Gruppe Linux Pluggable Authentication Modules (PAM) — insbesondere pam_unix.so — um ein hartcodiertes Backdoor-Passwort zu akzeptieren, Credentials aus legitimen Authentifizierungsversuchen zu sammeln und jegliche Protokollierung von Angreiferaktivitäten zu unterdrücken. Neun Instanzen des mit Backdoor versehenen PAM-Moduls wurden auf kompromittierten Hosts gefunden. Die Gruppe installierte auch Backdoors in OpenSSH-Binärdateien, um persistenten Zugang aufrechtzuerhalten.

Warum es wichtig ist: Dieser Angriff stahl keine Passwörter — er unterwanderte die Authentifizierungsschicht selbst. Durch die Modifizierung von PAM-Modulen konnte Velvet Ant sich als beliebiger Benutzer authentifizieren und jedes auf kompromittierten Hosts eingegebene Passwort abgreifen. Starke Passwörter bieten keinen Schutz, wenn der Authentifizierungs-Stack kompromittiert ist. Betreiber kritischer Infrastrukturen in den Bereichen Energie, Fertigung und Verteidigung stehen vor direkt analogen Risiken.

Quelle: CyberSecurityNews / Sygnia — 15. Jun 2026

Italienische Garante verhängt Geldstrafe von 85.000 € gegen Beratungsfirma wegen Speicherung von Passwörtern im Klartext nach 61.000-Benutzer-Breach

Italiens Datenschutzbehörde, die Garante, verhängte eine Geldstrafe von 85.000 € gegen eine Beratungsfirma nach einem Datenschutzvorfall, bei dem personenbezogene Daten von mehr als 61.000 Benutzern exponiert wurden. Die Garante stellte fest, dass bestimmte Passwörter im Klartext gespeichert oder mit veralteten kryptographischen Algorithmen geschützt waren und dass Credentials für nicht mehr genutzte Systeme über ihre notwendige Aufbewahrungsdauer hinaus gespeichert worden waren. Betroffene Personen wurden etwa zwei Monate nach der Entdeckung benachrichtigt — und erst nach Erlass einer Korrekturanordnung.

Warum es wichtig ist: Die Garante nannte ausdrücklich die Speicherung von Passwörtern im Klartext und veraltete Kryptographie als primäre DSGVO-Verstöße. Dies etabliert einen klaren Durchsetzungspräzedenzfall: Artikel 32 erfordert modernes Passwort-Hashing, und das Aufbewahren von Credentials für stillgelegte Systeme verstößt gegen das Grundprinzip der Speicherbegrenzung. EU-Organisationen sollten ihre Implementierungen zur Passwortspeicherung anhand dieser Entscheidung überprüfen.

Quelle: Gibson Dunn Europe Data Protection — 15. Jun 2026

EDPB verabschiedet harmonisierte EU-weite Vorlage für Datenschutzverletzungsmeldungen gemäß DSGVO

Der Europäische Datenschutzausschuss (EDPB) hat eine standardisierte Vorlage für Meldungen von Verletzungen des Schutzes personenbezogener Daten gemäß DSGVO Artikel 33 verabschiedet, die bis zum 5. August 2026 zur öffentlichen Konsultation steht. Die Vorlage bietet Organisationen in der gesamten EU ein einheitliches strukturiertes Formular zur Meldung von Verletzungen des Schutzes personenbezogener Daten an Aufsichtsbehörden und ersetzt die derzeit fragmentierten nationalen Formate.

Warum es wichtig ist: Die harmonisierte Vorlage wirkt sich direkt darauf aus, wie Organisationen Credential-Expositionsvorfälle gemäß DSGVO Artikel 33 melden. Sie erfordert eine strukturierte Offenlegung der kompromittierten Datentypen, betroffenen Personen und wahrscheinlichen Folgen. Compliance- und Rechtsteams sollten den Entwurf vor Ablauf der Konsultationsfrist am 5. August prüfen.

Quelle: LexisNexis UK/EU Risk & Compliance — 18. Jun 2026

ANSSI wird ab 2027 keine Sicherheitsprodukte mehr ohne quantenresistente Verschlüsselung zertifizieren

Frankreichs nationale Cybersicherheitsbehörde ANSSI kündigte an, dass sie ab 2027 keine Sicherheitsprodukte (einschließlich Passwort-Manager, VPNs und Authentifizierungslösungen) mehr zertifizieren wird, die keine quantenresistente (Post-Quanten) Kryptographie integrieren.

Die Ankündigung begleitet Frankreichs breitere nationale Cyber-Strategie, die eine staatliche Investition von 200 Millionen Euro in Cybersicherheitsinfrastruktur und Post-Quanten-Kryptographie-Tools umfasst.

Warum es wichtig ist: Passwort-Manager und Credential-Tresore basieren auf kryptographischen Primitiven, die theoretisch anfällig für Quantencomputing-Angriffe sind. ANSSIs Zertifizierungsanforderung schreibt Post-Quanten-Algorithmen für die französische Regierungszulassung vor, womit Frankreich der erste EU-Mitgliedstaat ist, der eine harte Frist setzt. Das ANSSI-Rahmenwerk wird in ganz Europa weithin referenziert und wird voraussichtlich das Europäische Cybersicherheits-Zertifizierungsschema der ENISA beeinflussen.

Quelle: Reuters — 16. Jun 2026

Gartner identifiziert drei Veränderungen im Secrets-Management, die Sicherheitsteams nicht ignorieren können

Gartner identifiziert drei strategische Veränderungen im Secrets-Management:

1. Workload Access Management — der Wechsel von statischen Secrets zu dynamischer, Just-in-Time-Credential-Ausgabe für Workloads.
2. Secretless Architecture — die vollständige Eliminierung langlebiger Secrets zugunsten von identitätsbasiertem Zugriff mittels SPIFFE/SPIRE.
3. Multi-Vault Governance — konsistentes Management von Secrets über mehrere Tresor-Plattformen hinweg, da Organisationen unterschiedliche Secrets-Speicher über HashiCorp Vault, AWS Secrets Manager, Azure Key Vault und andere ansammeln.

Warum es wichtig ist: Diese drei Veränderungen korrespondieren direkt mit den diese Woche aufgedeckten Fehlermodi. FortiBleed demonstriert das Risiko statischer, nie rotierter Credentials (Veränderung 1). Der Klue-OAuth-Breach demonstriert das Risiko langlebiger Legacy-Credentials (Veränderung 2). Credential-Drift über Multi-Cloud-Umgebungen ist das Problem, das Veränderung 3 adressiert. Dieses Rahmenwerk gibt Sicherheits- und IT-Führungskräften eine strukturierte Möglichkeit, ihre aktuelle Secrets-Management-Reife anhand der Vorfälle dieser Woche zu bewerten.

Quelle: Akeyless Blog (unter Berufung auf Gartner-Forschung) — 17. Jun 2026

Zusammenfassung dieser Woche

Das Muster über die Vorfälle dieser Woche hinweg ist konsistent genug, um es zu benennen: Statische Credentials, vergessene Dienstkonten und langlebige Tokens sind die Einstiegspunkte, die Angreifer aktiv ausnutzen.

Die regulatorische Durchsetzung holt auf. Die Geldstrafe von 85.000 € der italienischen Garante für Klartext-Passwortspeicherung, die US-Bundesfristen für PQC und ANSSIs Zertifizierungsfrist 2027 fügen eine zukunftsorientierte Dimension hinzu: Die kryptographischen Grundlagen der Credential-Speicherung selbst stehen unter einer harten Frist.

Drei Maßnahmen ergeben sich direkt aus den Ereignissen dieser Woche:

• Erstens: Prüfen Sie Dienstkonten und OAuth-Integrationen von Drittanbietern — der Klue-Angriff begann mit einem vergessenen Konto.
• Zweitens: Führen Sie eine Prüfung kompromittierter Credentials gegen den HIBP-Datensatz durch, der jetzt um 124 Millionen Infostealer-gestützte Passwörter erweitert wurde.
• Drittens: Überprüfen Sie, wie Secrets auf Entwickler-Workstations gespeichert werden. Langlebige Cloud-Credentials sind jetzt ein explizites KI-Agenten-Ziel.

Credentials außerhalb jedes verwalteten Systems sind die gemeinsame Wurzel — hartcodierte API-Schlüssel, nicht rotierte VPN-Credentials, Klartext-Passwörter in stillgelegten Diensten. Passwork bietet IT- und Sicherheitsteams zentrale Transparenz über Unternehmenspasswörter und technische Secrets, mit integrierten Zugriffsprotokollen, Rotations-Tracking und Warnungen zu kompromittierten Credentials. Beginnen Sie mit dem, was Sie kontrollieren können

Secrets-Rotations-Lebenszyklus: Von der Erstellung bis zum Widerruf

Secret-Rotation scheitert, wenn sie als geplante Aufgabe statt als Lebenszyklus behandelt wird. Dieser Leitfaden behandelt alle sieben Phasen — von der Erstellung und Eigentümerschaft bis zur sicheren Rotation, Notfall-Widerruf und Audit-Nachweisen.

Passwork BlogAlex Muntyan

10 Sicherheitsfehler bei Remote-Arbeit (und wie man sie behebt)

10 Sicherheitsfehler bei Remote-Arbeit — und das eine Prinzip hinter allen: Sicherheit bricht dort zusammen, wo der sichere Weg mehr Reibung hat als der unsichere. Echte Fälle, realistische Lösungen, eine 5-Schichten-Baseline, gegen die Ihr Team prüfen kann.

Passwork BlogAlex Muntyan

NIS2-Zugriffskontrollen für Supply-Chain-Sicherheit

48 % der Breaches betreffen mittlerweile Drittparteien. NIS2 Artikel 21 macht Lieferanten-Zugangs-Governance zur rechtlichen Pflicht. So kartieren Sie Lieferantenzugang, setzen MFA und Least Privilege durch und bewahren die Audit-Nachweise auf, die belegen, dass Ihre Kontrollen funktionieren.

Passwork BlogAlex Muntyan

This week brought several major incidents, and all of them point in the same direction. The scale of credential compromise keeps breaking records. FortiBleed: 86,000 devices across 194 countries. The Elasticsearch leak: 24 billion records from dozens of sources. HIBP added 124 million passwords stolen by infostealers at the moment of use. This data is already in circulation.

• Two attack methods received concrete confirmation this week. Attackers are increasingly bypassing passwords altogether: the Klue breach started with a forgotten service account and ended with stolen OAuth tokens — no password entered at any point. 
• AI agents have become an independent attack vector: a poisoned coding test repository allowed an attacker to exfiltrate AWS credentials from a developer's workstation in 111 seconds, with no endpoint alerts generated.
• Regulatory pressure is moving on two fronts. In Europe, the Council of Europe and French government platform Tchap were breached, the Italian Garante fined a firm for storing passwords in cleartext, and new EDPB and NIS2 incident reporting templates dropped — all within a single week. 
• In the U.S., President Trump signed two executive orders setting hard federal deadlines for post-quantum cryptography migration, signaling that the window for preparation is shorter than most organizations have assumed.

This digest covers the 14 most significant events from 15 to 22 June 2026.

U.S. sets federal deadlines for post-quantum cryptography (PQC) migration

On 22 June 2026, President Trump signed two executive orders on quantum technology. EO "Securing the Nation Against Advanced Cryptographic Attacks" requires federal agencies to designate a PQC migration lead, transition high-value assets to post-quantum cryptography by 2030, and complete full migration by 2031.

A second order directs development of a fault-tolerant quantum computer by 2028. Both orders cite "harvest now, decrypt later" attacks as the primary threat driver — adversaries collecting encrypted data today for future decryption. Barron's reports that some analysts put viable quantum decryption capability as early as 2029.

Why it matters: The 2030–2031 federal deadlines will not stay inside the government. Procurement contracts and sector-specific regulation tend to follow federal precedent, so any organization that touches government infrastructure or operates in a regulated industry should treat this as an early signal. The practical starting point is knowing what you have: which systems depend on RSA or ECC, where cryptographic keys and certificates actually live, and who controls them.

Source: Reuters / White House — 22 Jun 2026

FortiBleed: 86,000+ fortinet device credentials compromised across 194 countries

A large-scale credential theft campaign has compiled a verified database of over 86,644 working credentials for internet-facing Fortinet FortiGate firewalls and SSL VPN appliances — roughly 50% of all such devices exposed to the internet. The campaign involved SSL VPN authentication interception, hash-cracking on a 45-GPU cluster, and Active Directory pivoting.

Attackers executed approximately 1.16 billion credential attempts against 320,000+ FortiGate targets. CISA issued an urgent advisory on 18 June 2026, requiring organizations to terminate active sessions, reset all credentials, enable phishing-resistant MFA, and apply PBKDF2 password hashing for admin accounts. Huntress confirmed 845 partner organizations were directly impacted.

Why it matters: Organizations that patched Fortinet vulnerabilities but never rotated credentials remain fully exposed. This is the defining credential security event of the week. Any organization with internet-facing Fortinet infrastructure should treat this as an active incident requiring immediate credential rotation — not a scheduled maintenance task.

Source: SecurityWeek — 19 Jun 2026

24 billion stolen credentials exposed in colossal Elasticsearch leak

Cybernews researchers discovered a publicly accessible Elasticsearch cluster containing 24 billion stolen credential records across 8.3 terabytes of data, drawn from 36 distinct sources including infostealer malware logs, Telegram cybercrime channels, and breach compilations. More than 1.7 billion records originated from Telegram channels.

Critically, the cluster also contained approximately 9,500 CVE records linked to active GitHub repositories — evidence the operator was building an attack-prioritization pipeline to cross-reference exploitable vulnerabilities with available stolen credentials. The database has been taken offline, but the credentials remain in active circulation.

Why it matters: The CVE-enriched attack pipeline changes the risk calculation: rotating credentials after a breach may be too late if an attacker already knows which unpatched services they unlock. Fresh infostealer logs also contain active session cookies that bypass MFA entirely. Unique credentials per service remain the primary structural defense.

Source: Cybernews — 17 Jun 2026

124 million unique infostealer passwords added to Have I Been Pwned

On 15 June 2026, Have I Been Pwned (HIBP) ingested 56.3 million unique email addresses and 124 million unique passwords sourced from infostealer malware logs. Unlike traditional breach data, these credentials were stolen directly from victims' devices at the time of use — meaning they are current and unrotated. The dataset is now searchable via the Pwned Passwords API, which is integrated into numerous enterprise password managers and identity platforms.

Why it matters: Organizations using password managers with HIBP integration will now surface alerts for a substantially larger pool of at-risk credentials. The danger here is freshness: employees who have not changed passwords since their device was infected remain fully exposed. This is a direct prompt to run a compromised credential audit across your organization.

Source: Have I Been Pwned — 15 Jun 2026

Klue SaaS supply chain attack: OAuth tokens stolen, CRM data exfiltrated from multiple security vendors

A new extortion group called Icarus (active since April 2026) gained initial access to market intelligence platform Klue via a compromised legacy credential associated with an abandoned integration service account. Attackers then stole OAuth tokens used by Klue's customers to connect to Salesforce and Gong, and ran automated scripts against the Salesforce REST API for up to 24 hours of bulk CRM data extraction.

Confirmed victims include Huntress, Recorded Future, Tanium, Gong, Sprout Social, Jamf, and Insurity. Salesforce disabled the Klue integration.

Why it matters: A forgotten legacy service account credential was the initial access vector. Once inside, the attacker needed no passwords and no MFA codes — the stolen OAuth token was the identity from Salesforce's perspective. The attack ran undetected for 24 hours. Service account credentials and third-party OAuth integrations warrant the same monitoring discipline as employee accounts.

Source: The Hacker News — 19 Jun 2026

1,230+ hardcoded API keys and JWT tokens found in AI agent instruction files across 7,000+ public repos

Mitiga Labs scanned 50,000+ AI instruction files (Cursor rules, CLAUDE.md, MCP configs, agent brain files) across 7,000+ public GitHub repositories and found over 1,230 hardcoded API keys and JWT tokens across services including Anthropic Claude, OpenAI GPT-5, Google Gemini, Databricks, Supabase, Vercel, and Google Cloud Storage.

Separately, GitGuardian reported that 28.65 million secrets were leaked on public GitHub in 2025 (a 34% year-on-year increase) with AI service leaks up 81%.

Why it matters: AI agent configuration files are becoming a primary vector for hardcoded credential exposure. These files are frequently created by non-security-aware users — product managers, researchers, founders — who do not apply standard secrets hygiene. Most organizations' secrets scanning policies do not yet cover instruction files, MCP configs, and agent context files. They should.

Source: Mitiga Labs — 15 Jun 2026

Poisoned coding test causes AI agent to steal AWS credentials in under 2 minutes

Mitiga documented a real-world attack in which a fake take-home coding assessment repository contained hidden instructions in .cursor/rules, README.md, and CLAUDE.md files. When a developer opened the repository in Cursor with auto-run enabled, the AI coding agent autonomously executed cat ~/.aws/credentials, aws sts get-caller-identity, cat ~/.kube/config, terraform state list, and a grep for secrets — then exfiltrated all collected data to an attacker-controlled endpoint via a poisoned MCP tool call. The entire chain completed in 1 minute 51 seconds. No malware was dropped; no endpoint alerts were generated.

Why it matters: Long-lived cloud credentials stored on developer workstations are now a primary target for AI-agent-mediated attacks. Every action was performed by a legitimate tool using legitimate commands — no endpoint controls triggered. The primary mitigation is replacing long-lived credentials with short-lived OIDC tokens and federated authentication.

Source: Mitiga Labs — 19 Jun 2026

ShinyHunters claims Council of Europe breach: 297 GB of HR, payroll, and medical records exposed

The hacker collective ShinyHunters claimed responsibility for a breach of the Council of Europe, alleging theft of 297 GB of data comprising over 429,000 files — including 409,000 payslips covering 10,000+ staff over 15 years, 14,000 CVs, 3,700 personnel files, and sensitive records including home addresses, salaries, bank details, tax information, and medical records. As of 21 June 2026, ShinyHunters published the data permanently after the Council of Europe did not respond to ransom demands.

Why it matters: The exposed records create effective spear-phishing vectors against a sensitive institution. ShinyHunters has now claimed the European Commission (March 2026), the Council of Europe (June 2026), and Dutch telecom Odido (February 2026) within a single year. European security teams should treat this as a sustained targeting campaign, not isolated incidents.

Source: Cybernews — 15 Jun 2026

France's Tchap government messaging platform breached: 73,467 officials' accounts compromised

France's sovereign government messaging platform Tchap (used by over 825,000 government employees) was breached on 7 June 2026 by a threat actor calling itself "misere." DINUM confirmed 73,467 government accounts were affected, with exposed data including names, email addresses, and affiliated government entities.

The threat actor additionally claims to have stolen 13.5 GB of files including over 643,000 messages. The attack vector is believed to involve account hijacking, possibly via infostealer-sourced credentials.

Why it matters: The breach illustrates how credential compromise (potentially via stealer logs) can be weaponized against sovereign government communication infrastructure at scale. Security experts noted the attack may not have required zero-days: API-based data extraction using legitimate credentials is sufficient for this scale of exfiltration. Under NIS2, government digital services are classified as essential entities, triggering mandatory incident reporting to ANSSI.

Source: SecurityWeek — 15 Jun 2026

Velvet Ant (China-Nexus) backdoors Linux PAM modules and OpenSSH for decade-long credential theft

Sygnia's incident response team uncovered Operation Highland, a near-decade-long espionage campaign by the China-linked Velvet Ant threat actor. Active since at least 2016–2017, the group modified Linux Pluggable Authentication Modules (PAM) — specifically pam_unix.so — to accept a hardcoded backdoor password, harvest credentials from legitimate authentication attempts, and suppress all logging of attacker activity. Nine instances of the backdoored PAM module were found across compromised hosts. The group also backdoored OpenSSH binaries to maintain persistent access.

Why it matters: This attack did not steal passwords — it subverted the authentication layer itself. By modifying PAM modules, Velvet Ant could authenticate as any user and harvest every password entered on compromised hosts. Strong passwords offer no protection when the authentication stack is compromised. Critical infrastructure operators in energy, manufacturing, and defense face directly analogous risks.

Source: CyberSecurityNews / Sygnia — 15 Jun 2026

Italian Garante fines consulting firm €85,000 for storing passwords in cleartext after 61,000-user breach

Italy's data protection authority, the Garante, imposed an €85,000 fine on a consulting firm following a data breach exposing personal data of more than 61,000 users. The Garante found that certain passwords were stored in cleartext or protected with outdated cryptographic algorithms, and that credentials for unused systems had been retained beyond their necessary period. Affected individuals were notified approximately two months after discovery — and only after a corrective order was issued.

Why it matters: The Garante explicitly cited cleartext password storage and obsolete cryptography as the primary GDPR infringements. This establishes a clear enforcement precedent: Article 32 requires modern password hashing, and retaining credentials for decommissioned systems violates the storage limitation principle. EU organizations should audit their password storage implementations against this decision.

Source: Gibson Dunn Europe Data Protection — 15 Jun 2026

EDPB adopts harmonized EU-wide data breach notification template under GDPR

The European Data Protection Board (EDPB) has adopted a standardized template for personal data breach notifications under GDPR Article 33, open for public consultation until 5 August 2026. The template provides organizations across the EU with a single structured form for reporting personal data breaches to supervisory authorities, replacing the currently fragmented national formats.

Why it matters: The harmonized template directly affects how organizations report credential exposure incidents under GDPR Article 33, requiring structured disclosure of compromised data types, affected individuals, and likely consequences. Compliance and legal teams should review the draft before the 5 August consultation deadline.

Source: LexisNexis UK/EU Risk & Compliance — 18 Jun 2026

ANSSI will stop certifying security products without quantum-resistant encryption from 2027

France's national cybersecurity agency ANSSI announced it will cease certifying security products (including password managers, VPNs, and authentication solutions) that do not incorporate quantum-resistant (post-quantum) cryptography starting from 2027.

The announcement accompanies France's broader national cyber strategy, which includes a €200 million government investment in cybersecurity infrastructure and post-quantum cryptography tooling.

Why it matters: Password managers and credential vaults rely on cryptographic primitives theoretically vulnerable to quantum computing attacks. ANSSI's certification requirement mandates post-quantum algorithms for French government approval, making France the first EU member state to set a hard deadline. ANSSI's framework is widely referenced across Europe and is expected to influence ENISA's European Cybersecurity Certification Scheme.

Source: Reuters — 16 Jun 2026

Gartner identifies three shifts in secrets management security teams cannot ignore

Gartner identifies three strategic shifts in secrets management:

1. Workload Access Management — moving from static secrets to dynamic, just-in-time credential issuance for workloads.
2. Secretless Architecture — eliminating long-lived secrets entirely in favor of identity-based access using SPIFFE/SPIRE.
3. Multi-Vault Governance — managing secrets consistently across multiple vault platforms as organizations accumulate disparate secrets stores across HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and others.

Why it matters: These three shifts map directly to the failure modes exposed this week. FortiBleed demonstrates the risk of static credentials never rotated (Shift 1). The Klue OAuth breach demonstrates the risk of long-lived legacy credentials (Shift 2). Credential drift across multi-cloud environments is the problem Shift 3 addresses. This framework gives security and IT leadership a structured way to assess their current secrets management maturity against the week's incidents.

Source: Akeyless Blog (citing Gartner research) — 17 Jun 2026

This week's recap

The pattern across this week's incidents is consistent enough to name: static credentials, forgotten service accounts, and long-lived tokens are the entry points attackers are actively exploiting.

Regulatory enforcement is catching up. The Italian Garante's €85,000 fine for cleartext password storage, the U.S. federal PQC deadlines, and ANSSI's 2027 certification cutoff add a forward-looking dimension: the cryptographic foundations of credential storage are themselves under a hard timeline.

Three actions follow directly from this week's events:

• First, audit service accounts and third-party OAuth integrations — the Klue attack started with a forgotten one.
• Second, run a compromised credential check against the HIBP dataset now expanded by 124 million infostealer-sourced passwords.
• Third, review how secrets live on developer workstations. Long-lived cloud credentials are now an explicit AI-agent target.

Credentials outside any managed system are the common root — hardcoded API keys, unrotated VPN credentials, cleartext passwords in decommissioned services. Passwork gives IT and security teams centralized visibility over corporate passwords and technical secrets, with access logs, rotation tracking, and compromised credential alerts built in. Start with what you can control

Secrets rotation lifecycle: From creation to revocation

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

Passwork BlogAlex Muntyan

10 Remote Work Security Fails (And How to Fix Them)

10 remote work security fails — and the one principle behind all of them: security breaks where the secure path has more friction than the insecure one. Real cases, realistic fixes, a 5-layer baseline your team can audit against.

Passwork BlogAlex Muntyan

NIS2 access controls for supply chain security

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

Passwork BlogAlex Muntyan

LDAP (Lightweight Directory Access Protocol) ist ein Client-Server-Protokoll zum Lesen und Schreiben von Verzeichnisdiensten über ein Netzwerk. Definiert in RFC 4511, bietet es Anwendungen eine standardisierte Möglichkeit, ein Verzeichnis abzufragen — mit Fragen wie „Existiert dieser Benutzer?", „Zu welchen Gruppen gehört er?" und „Auf welche Ressourcen hat er Zugriff?"

Obwohl LDAP erstmals Anfang der 1990er Jahre standardisiert wurde, bleibt es auch 2026 das Rückgrat der Unternehmens-Identitätsinfrastruktur. Active Directory, das auf LDAP basiert, ist nach wie vor bei etwa 90 % der Organisationen weltweit im Einsatz.

Wichtigste Erkenntnisse

• LDAP ist ein Protokoll. Es definiert, wie Anwendungen ein Verzeichnis abfragen — Benutzerkonten, Gruppenmitgliedschaften, Zugriffsrechte. Active Directory implementiert es, aber LDAP läuft unabhängig auf OpenLDAP und anderen Servern ohne jegliche Microsoft-Software.
• AD kann ohne LDAP nicht funktionieren. Jedes Nicht-Windows-System, das sich gegen Active Directory authentifiziert, tut dies über LDAP. Ohne LDAP verliert AD die Fähigkeit, Drittanbieteranwendungen, Netzwerkgeräte und Linux-Infrastruktur zu bedienen.
• Port 389 ist in Produktionsumgebungen nicht akzeptabel. Standard-LDAP überträgt Anmeldedaten im Klartext. LDAPS auf Port 636 verschlüsselt die gesamte Sitzung. Microsoft setzt seit 2020 Anforderungen für Signierung und Channel Binding durch.
• Zwei kritische Schwachstellen wurden 2025 gepatcht. CVE-2025-26663 ermöglicht nicht authentifizierte Remote-Code-Ausführung auf Domänencontrollern durch einen Speicherfehler im Windows-LDAP-Dienst. CVE-2025-54918 umgeht Channel-Binding- und Signierungsschutz durch NTLM-Relay. Für beide gibt es Patches — ungepatchte Domänencontroller haben höchste Priorität bei der Behebung.
• LDAP und moderne Protokolle sind keine Alternativen. SAML übernimmt browserbasiertes SSO. OAuth übernimmt API-Autorisierung. LDAP übernimmt Verzeichnisabfragen für Systeme, die keines von beiden sprechen. Die meisten Unternehmensumgebungen betreiben alle drei gleichzeitig.
• Manuelle Zugriffsverwaltung schafft Lücken. Wenn AD-Gruppenänderungen nicht automatisch an abhängige Systeme weitergegeben werden, bleiben Konten länger aktiv als sie sollten. Die Synchronisierung des Anmeldedatenzugriffs mit der Verzeichnis-Gruppenmitgliedschaft eliminiert diese Verzögerung.

LDAP verstehen: Die Grundlagen

LDAP ist ein Standardprotokoll für den Zugriff auf und die Verwaltung von verteilten Verzeichnisinformationsdiensten. Es arbeitet mit einem hierarchischen Datenmodell, das vom X.500-Standard abgeleitet ist, und ermöglicht Clients die Authentifizierung von Benutzern, das Nachschlagen von Attributen und das Abrufen von Gruppenmitgliedschaften aus einem zentralen Verzeichnis. Organisationen nutzen es, um eine grundlegende Frage im großen Maßstab zu beantworten: Wer darf was tun und wo?

Die Daten, die LDAP organisiert, befinden sich in einem Directory Information Tree (DIT) — einer hierarchischen Struktur von Einträgen, die jeweils durch einen Distinguished name (DN) identifiziert werden. Ein typischer DN sieht so aus:

Copycn=jane.doe,ou=engineering,dc=company,dc=com

Jeder Eintrag enthält Attribute: Ein Benutzereintrag könnte mail, uid, memberOf und userPassword enthalten. Anwendungen fragen diese Attribute ab, um Authentifizierungs- und Autorisierungsentscheidungen zu treffen.

Wie funktioniert LDAP? (Client-Server-Modell)

Ein LDAP-Client sendet eine Anfrage an einen LDAP-Server (genannt Directory System Agent oder DSA). Der Server verarbeitet die Operation gegen seine Verzeichnisdatenbank und gibt eine Antwort zurück. Die in RFC 4511 definierten Kernoperationen umfassen:

• Bind — authentifiziert einen Client beim Verzeichnis
• Search — fragt Einträge ab, die einem Filter entsprechen
• Compare — prüft, ob ein Eintrag einen bestimmten Attributwert hat
• Modify / Add / Delete — Schreiboperationen auf Verzeichniseinträgen
• Unbind — beendet die Sitzung

Die Bind-Operation ist der Ort, an dem die Authentifizierung stattfindet. Ein Client sendet einen DN und Anmeldedaten. Der Server validiert diese und gewährt oder verweigert die Sitzung. Die meisten Unternehmensanwendungen verwenden LDAP-Bind, um die Benutzeridentität vor der Gewährung des Zugriffs zu überprüfen.

LDAP-Port 389 vs. LDAPS-Port 636

Standard-LDAP läuft auf TCP-Port 389 und überträgt Daten im Klartext. Das bedeutet, dass Anmeldedaten, einschließlich Passwörter, unverschlüsselt über das Netzwerk übertragen werden. In jeder Umgebung, in der Netzwerkverkehr abgefangen werden könnte (was jede Umgebung ist), ist dies inakzeptabel.

LDAPS (LDAP über SSL/TLS) läuft auf TCP-Port 636 und umhüllt die gesamte LDAP-Sitzung mit TLS, wodurch der gesamte Datenverkehr einschließlich der Bind-Anmeldedaten verschlüsselt wird. Eine dritte Option, StartTLS, aktualisiert eine bestehende Port-389-Verbindung mitten in der Sitzung auf TLS, führt jedoch zu Verhandlungskomplexität und ist fehleranfälliger bei der korrekten Konfiguration.

Microsoft schreibt seit 2020 schrittweise LDAP-Channel-Binding und LDAP-Signierung vor, wobei die Durchsetzung in nachfolgenden Windows-Server-Updates verschärft wurde. Unverschlüsseltes LDAP auf Port 389 in der Produktion zu betreiben, ist eine Sicherheitslücke. Port 636 ist die korrekte Standardeinstellung.

LDAP vs. Active Directory: Was ist der Unterschied?

Active Directory (AD) ist kein Ersatz für LDAP — es ist ein Verzeichnisdienst, der LDAP als eines seiner Zugriffsprotokolle verwendet. Die Verwechslung beider ist eines der häufigsten Missverständnisse in der Unternehmens-IT. Die Abhängigkeit besteht nur in eine Richtung: LDAP steht für sich allein, AD nicht.

Kann LDAP ohne AD betrieben werden?

Ja. LDAP ist ein Protokoll — es definiert, wie ein Client einen Verzeichnisserver nach Informationen fragt und wie dieser Server antwortet. Es kann unabhängig von jeglicher Microsoft-Software eingesetzt werden.

OpenLDAP ist die am weitesten verbreitete Open-Source-Implementierung. 389 Directory Server und Apache Directory Server sind gängige Alternativen. Diese eigenständigen Server speichern Benutzeridentitäten und Gruppenmitgliedschaften und stellen sie Linux/Unix-Systemen, Mailservern und benutzerdefinierten Anwendungen zur Verfügung.

Kann AD ohne LDAP betrieben werden?

Nein. Active Directory ist ein vollständiger Verzeichnisdienst, der von Microsoft auf Basis des X.500-Datenmodells entwickelt wurde. Domänencontroller verwenden LDAP intern zum Lesen, Schreiben und Replizieren von Verzeichnisdaten: Benutzer, Computer, Gruppenrichtlinien. Jede Drittanbieteranwendung oder Nicht-Windows-Maschine, die sich gegen AD authentifiziert, tut dies über LDAP.

Ohne LDAP kann AD nicht mit dem Rest Ihrer Infrastruktur kommunizieren.

Wie sie in der Praxis zusammenhängen

Wenn sich ein Linux-Server gegen Active Directory authentifiziert, spricht er LDAP. Wenn sich eine Windows-Workstation anmeldet, verwendet sie Kerberos. AD unterstützt beides — aber LDAP ist das, was AD für den Rest Ihrer Infrastruktur zugänglich macht.

Moderne Alternativen: LDAP vs. SAML, OAuth und OpenID Connect

LDAP wurde für die interne Netzwerkauthentifizierung konzipiert — das Abfragen eines Verzeichnisses innerhalb eines Unternehmensperimeters. Die Protokolle, die ihm folgten, wurden für eine andere Welt entwickelt: föderierte Identität über Organisationsgrenzen hinweg, Webanwendungen und mobile Clients.

Diese Protokolle ersetzen LDAP nicht — sie arbeiten auf einer anderen Ebene. SAML und OpenID Connect übernehmen browserbasiertes SSO. LDAP übernimmt Verzeichnisabfragen und Anwendungsauthentifizierung für Systeme, die SAML nicht sprechen können. Die meisten Unternehmensumgebungen betreiben alle gleichzeitig.

Ist LDAP 2026 noch relevant? (Die Hybrid-Cloud-Realität)

LDAP ist nach wie vor das dominierende Unternehmens-Authentifizierungsprotokoll, das durch Active-Directory-Implementierungen bei etwa 90 % der Organisationen weltweit präsent ist. Die Cloud-Adoption hat daran nichts geändert.

Die meisten Unternehmen sind nicht vollständig cloud-nativ. Sie betreiben ein Hybridmodell: einige Workloads in Azure oder AWS, andere vor Ort, mit Active Directory als Identitätsanker für beide. Microsoft Entra ID (ehemals Azure AD) verbindet sich über Synchronisation mit dem lokalen AD, aber das lokale AD (und damit LDAP) bleibt für viele Identitätsentscheidungen die maßgebliche Quelle.

Die Rolle von LDAP in der Zero-Trust-Architektur

Zero Trust erfordert kontinuierliche Verifizierung: Jede Zugriffsanfrage muss authentifiziert und autorisiert werden, unabhängig vom Netzwerkstandort. LDAP sitzt an einem kritischen Knotenpunkt in diesem Modell, da es oft das System ist, das diese Verifizierungsanfragen beantwortet.

Die Herausforderung besteht darin, dass LDAP nicht mit Zero-Trust-Prinzipien im Sinn entwickelt wurde. Es setzt Netzwerknähe voraus, verwendet persistente Verbindungen und exponiert in seiner unverschlüsselten Form Anmeldedaten bei der Übertragung. Die Einbindung von LDAP in eine Zero-Trust-Architektur erfordert kompensierende Kontrollen:

• Obligatorisches LDAPS
• Strikte Firewall-Regeln
• Einschränkung, welche Systeme Port 636 erreichen können
• Durchsetzung der LDAP-Signierung
• Überwachung von Bind-Versuchen auf anomale Muster

LDAP bricht Zero Trust nicht, erfordert aber gezielte Härtung, um es zu unterstützen. Organisationen, die LDAP als Legacy-Komponente behandeln und es unkonfiguriert lassen, schaffen genau die Art von implizitem Vertrauen, das Zero Trust beseitigen soll.

DevOps und CI/CD-Secrets-Management

Automatisierte Pipelines stellen eine spezifische LDAP-Herausforderung dar. CI/CD-Systeme (Jenkins, GitLab CI, GitHub Actions Runner) müssen sich oft gegen LDAP authentifizieren, um auf interne Ressourcen zuzugreifen. Diese Authentifizierung umfasst typischerweise ein Dienstkonto: einen dedizierten LDAP-Bind-DN mit einem statischen Passwort.

Statische Dienstkonto-Anmeldedaten sind ein anhaltendes Risiko. Sie werden selten rotiert, werden oft über Pipelines hinweg gemeinsam genutzt, und wenn sie in Build-Logs oder Konfigurationsdateien erscheinen, sind sie schwer zu erkennen und zu widerrufen. Die Lösung besteht darin, diese Anmeldedaten über einen dedizierten Secrets-Manager zu verwalten, anstatt sie in der Pipeline-Konfiguration hart zu kodieren.

Kritische LDAP-Sicherheitsrisiken 2026

LDAP ist nicht nur ein Legacy-Protokoll mit theoretischen Risiken. Es ist eine aktive Angriffsfläche mit dokumentierten, ausgenutzten Schwachstellen.

Die Bedrohung durch Anmeldedatendiebstahl und Ransomware

Laut dem X-Force Threat Intelligence Index 2026 von IBM war das Abgreifen von Anmeldedaten die häufigste Angriffsauswirkung, die 2025 beobachtet wurde. Bedrohungsakteure sammelten Anmeldedaten durch Phishing und Infostealer und fügten sich dann in normale Authentifizierungsströme ein, um sich lateral zu bewegen. LDAP-Dienstkonto-Anmeldedaten passen genau in dieses Muster: anwendungsübergreifend wiederverwendet, selten rotiert und fast nie auf anomale Bind-Aktivitäten überwacht.

Die Angriffskette ist gut dokumentiert: Kompromittierung einer LDAP-Anmeldedaten durch Phishing oder Password Spraying, Nutzung zur Aufzählung des Verzeichnisses, Identifizierung privilegierter Konten und Eskalation. Der Digital Defense Report von Microsoft hat durchgängig die Kompromittierung von AD/LDAP-Anmeldedaten mit Ransomware-Bereitstellung in Verbindung gebracht. Das Verzeichnis ist eine Karte der gesamten Zugriffsstruktur einer Organisation, und Angreifer lesen sie, bevor sie handeln.

Aktuelle Schwachstellen: CVE-2025-26663 und CVE-2025-54918

Zwei kritische Schwachstellen, die 2025 offengelegt wurden, zeigen, dass die Angriffsfläche von LDAP aktiv wächst.

CVE-2025-26663 ist eine Use-after-free-Schwachstelle für Remote-Code-Ausführung in Windows LDAP, die im April 2025 offengelegt wurde. Ein Angreifer kann einen Speicherverwaltungsfehler im Windows-LDAP-Dienst (speziell in wldap32.dll) ausnutzen, um beliebigen Code auf einem Zielserver ohne gültige Anmeldedaten auszuführen.

Der Angriff erfordert nur Netzwerkzugriff auf den LDAP-Dienst. Domänencontroller, die LDAP naturgemäß exponieren, sind die Hauptziele. Ungepatchte Domänencontroller mit dieser Schwachstelle sind praktisch offen für nicht authentifizierte Remote-Code-Ausführung (RCE) von jedem System, das Port 389 oder 636 erreichen kann.

CVE-2025-54918, offengelegt im September 2025, ist eine Privilegieneskalations-Schwachstelle, die NT LAN Manager Relay mit erzwungener Authentifizierung kombiniert, um LDAP-Channel-Binding- und Signierungsschutz zu umgehen. Ein Angreifer mit einem niedrig privilegierten Domänenkonto kann einen Domänencontroller zwingen, sich bei einem vom Angreifer kontrollierten System zu authentifizieren, die NTLM-Authentifizierungspakete während der Übertragung manipulieren und die modifizierte Authentifizierung zurück an den Domänencontroller weiterleiten — und so SYSTEM-Level-Zugriff erlangen. Der Angriff ist besonders gefährlich, weil er Kontrollen umgeht, auf die sich Organisationen üblicherweise als Härtungsmaßnahmen verlassen.

Best Practices zur Absicherung von LDAP im Unternehmen

Die folgende Checkliste umfasst die Mindestkontrollen für eine LDAP-Produktionsbereitstellung. Dies sind Empfehlungen, die einen spezifischen, dokumentierten Angriffsvektor adressieren.

1. LDAPS auf Port 636 durchsetzen. Klartext-LDAP auf Port 389 für den gesamten Produktionsverkehr deaktivieren. TLS-Zertifikate von Ihrer internen CA oder einer vertrauenswürdigen öffentlichen CA konfigurieren.
2. LDAP-Signierung und Channel Binding aktivieren. Verhindert Relay-Angriffe. Erforderlich zur Minderung von CVE-2025-54918 — wobei zu beachten ist, dass CVE-2025-54918 diese Kontrollen auf ungepatchten Systemen umgeht, sodass das Patchen weiterhin obligatorisch ist.
3. Alle Windows-Sicherheitsupdates anwenden. Für CVE-2025-26663 und CVE-2025-54918 gibt es Patches. Ungepatchte Domänencontroller sind das Behebungselement mit höchster Priorität.
4. LDAP-Zugriff nach IP einschränken. Nur Systeme, die legitimerweise LDAP abfragen müssen, sollten Port 636 erreichen können. Firewall-Regeln sollten dies durchsetzen, nicht nur Annahmen zur Netzwerksegmentierung.
5. Dienstkonto-Anmeldedaten auditieren. Jeden Bind-DN identifizieren, der in Ihrer Umgebung verwendet wird. Passwörter nach einem Zeitplan rotieren. Konten entfernen, die nicht mehr benötigt werden.
6. Bind-Versuche überwachen. Ungewöhnliche Bind-Muster — wiederholte Fehlschläge, Binds von unerwarteten Quell-IPs, Binds zu ungewöhnlichen Zeiten — sind frühe Indikatoren für Credential Stuffing oder laterale Bewegung.
7. Anonyme LDAP-Binds deaktivieren. Anonyme Abfragen ermöglichen nicht authentifizierte Aufzählung von Verzeichnisinhalten. Die meisten modernen Implementierungen haben keine legitime Verwendung für anonyme Binds.
8. Dienstkonten nach Funktion trennen. Ein Dienstkonto, das von einem VPN verwendet wird, sollte nicht die gleichen Berechtigungen haben wie eines, das von einem Backup-System verwendet wird. Das Prinzip der geringsten Rechte gilt auch für LDAP-Bind-Konten.

Unternehmens-Zugriff mit der Passwork-LDAP-Integration optimieren

Der operative Aufwand der LDAP-basierten Zugriffsverwaltung summiert sich im Laufe der Zeit. Benutzer wechseln Teams, treten Projekten bei und verlassen die Organisation — und jeder Übergang erfordert Zugriffsänderungen über mehrere Systeme hinweg. Wenn diese Änderungen manuell erfolgen, hinken sie hinterher. Konten bleiben länger aktiv als sie sollten. Anmeldedaten sammeln sich an Orten an, die niemand verfolgt.

Passwork verbindet sich direkt mit Active Directory oder jedem LDAP-kompatiblen Verzeichnis und ordnet Gruppenmitgliedschaften automatisch dem Tresor-Zugriff zu:

• Fügen Sie einen Benutzer zur SRE-Gruppe in AD hinzu — die korrekten Anmeldedaten erscheinen in seinem Passwork-Tresor, keine separate Admin-Aktion erforderlich
• Entfernen Sie ihn aus der Gruppe — der Zugriff wird widerrufen
• Das Verzeichnis bleibt die einzige Wahrheitsquelle dafür, wer auf was Zugriff hat

Für selbst gehostete Umgebungen wird Passwork vollständig innerhalb Ihres eigenen Perimeters bereitgestellt. Anmeldedaten verlassen ihn nie. SAML SSO wird neben LDAP unterstützt, sodass Teams, die beide Protokolle für verschiedene Anwendungsebenen verwenden, ihre Identitätsarchitektur nicht neu aufbauen müssen.

Jedes Lesen, Schreiben, Teilen und Exportieren wird im Audit-Log aufgezeichnet — relevant sowohl für interne Sicherheitsüberprüfungen als auch zum Nachweis der Compliance mit SOC 2 CC6.1 und DSGVO Artikel 32.

Fazit

LDAP wird nicht verschwinden. Der Markt für Verzeichnissoftware wurde 2025 auf 8,4 Milliarden US-Dollar geschätzt und soll laut der Marktforschung von Dataintelo bis 2034 19,7 Milliarden US-Dollar erreichen — eine Zahl, die fortgesetzte Unternehmensinvestitionen in Verzeichnisinfrastruktur widerspiegelt, nicht eine Technologie im Niedergang. Mit 90 % der Unternehmen, die noch Active Directory betreiben, bleibt LDAP das verbindende Gewebe des Unternehmens-Identitätsmanagements.

Was sich geändert hat, ist die Bedrohungsumgebung. CVE-2025-26663 und CVE-2025-54918 sind aktiv gepatchte Schwachstellen, die auf die LDAP-Dienste abzielen, die Ihre Domänencontroller gerade jetzt exponieren.

Die praktische Maßnahme ist einfach: LDAPS durchsetzen, Ihre Domänencontroller patchen, Ihre Dienstkonto-Anmeldedaten auditieren und sicherstellen, dass Zugriffsänderungen in Ihrem Verzeichnis automatisch an die Systeme weitergegeben werden, die davon abhängen. Manuelle Zugriffsverwaltung im Maßstab, in dem die meisten Unternehmen operieren, ist dort, wo Lücken entstehen.

Häufig gestellte Fragen zu LDAP

Wofür wird LDAP verwendet?

LDAP wird zur Authentifizierung von Benutzern und zum Nachschlagen von Verzeichnisinformationen verwendet — Gruppenmitgliedschaften, E-Mail-Adressen, Kontoattribute — über Unternehmensanwendungen hinweg. Häufige Anwendungsfälle umfassen VPN-Authentifizierung, Mailserver-Benutzerabfrage, Anwendungs-SSO und zentralisierte Benutzerverwaltung. Die meisten Unternehmensanwendungen, die eine Identität gegen ein Unternehmensverzeichnis verifizieren müssen, verwenden LDAP.

Was ist der Unterschied zwischen LDAP und Active Directory?

LDAP ist ein offenes Protokoll (RFC 4511) für den Zugriff auf Verzeichnisdienste. Active Directory ist der Verzeichnisdienst von Microsoft, der LDAP als eines seiner Zugriffsprotokolle verwendet. AD verwendet auch Kerberos für die Windows-Authentifizierung. LDAP kann ohne Active Directory verwendet werden (z. B. über OpenLDAP), aber Active Directory ist auf LDAP angewiesen, um Verzeichnisabfragen an Nicht-Windows-Anwendungen zu bedienen.

Was ist LDAPS und warum ist es wichtig?

LDAPS ist LDAP über TLS, läuft auf Port 636. Standard-LDAP auf Port 389 überträgt Anmeldedaten im Klartext, wodurch sie für jeden sichtbar sind, der Netzwerkverkehr abfangen kann. LDAPS verschlüsselt die gesamte Sitzung. Im Jahr 2026 ist das Betreiben von unverschlüsseltem LDAP in der Produktion nicht vertretbar — Microsoft setzt seit 2020 Anforderungen für LDAP-Signierung und Channel Binding durch, und sowohl CVE-2025-26663 als auch CVE-2025-54918 zielen direkt auf LDAP-Dienste ab.

Wird LDAP 2026 noch verwendet?

Ja. Active Directory, das auf LDAP angewiesen ist, wird bei etwa 90 % der Unternehmen weltweit eingesetzt. Die Cloud-Adoption hat dies nicht verdrängt — die meisten Organisationen betreiben Hybridumgebungen, in denen das lokale AD die maßgebliche Identitätsquelle bleibt. LDAP ist auch in Tausenden von Anwendungen eingebettet, die sich gegen Unternehmensverzeichnisse authentifizieren und ohne erhebliche Umgestaltung nicht durch SAML oder OAuth ersetzt werden.

Wie passt LDAP in eine Zero-Trust-Architektur?

LDAP kann Zero Trust unterstützen, wenn es korrekt gehärtet wird. Zero Trust erfordert kontinuierliche Verifizierung jeder Zugriffsanfrage, und LDAP ist oft das System, das diese Anfragen beantwortet. Die Anforderungen: LDAPS durchsetzen (Port 636), Signierung und Channel Binding aktivieren, Verzeichniszugriff nach Quell-IP einschränken, Bind-Versuche überwachen und Dienstkonto-Anmeldedaten regelmäßig rotieren. Die Standardkonfiguration von LDAP ist nicht Zero-Trust-kompatibel — aber das Protokoll selbst ist nicht das Hindernis.

Was sind die wichtigsten Sicherheitsrisiken bei LDAP?

Die primären Risiken sind die Exponierung von Anmeldedaten über unverschlüsselte Verbindungen (Port 389), Diebstahl von Dienstkonto-Anmeldedaten, NTLM-Relay-Angriffe (CVE-2025-54918) und nicht authentifizierte RCE über Speicherkorruptions-Schwachstellen (CVE-2025-26663). Der X-Force Threat Intelligence Index 2025 von IBM ergab, dass identitätsbasierte Angriffe — viele auf Verzeichnis-Anmeldedaten abzielend — 2024 30 % aller Einbrüche ausmachten. Patchen, LDAPS-Durchsetzung und Dienstkonto-Hygiene adressieren die Mehrheit dieser Risiken.

Kann LDAP durch SAML oder OAuth ersetzt werden?

Nicht vollständig. SAML und OAuth übernehmen browserbasierte föderierte Authentifizierung bzw. API-Autorisierung. LDAP übernimmt Verzeichnisabfragen und Anwendungsauthentifizierung für Systeme, die SAML nicht sprechen können. Die meisten Unternehmensumgebungen betreiben alle drei Protokolle für verschiedene Ebenen ihres Anwendungsstacks. Die Frage ist nicht, welches gewählt werden soll — sondern welche Anwendungen LDAP erfordern und ob diese Verbindungen ordnungsgemäß gesichert sind.

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

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

Passwork BlogAlex Muntyan

Unsichere Passwortweitergabe: Risiken und sichere Lösungen 2026

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

Passwork BlogAlex Muntyan

Passwork gewinnt Top Performer Frühjahr 2026 auf SourceForge

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

Passwork BlogAlex Muntyan

LDAP (Lightweight Directory Access Protocol) es un protocolo cliente-servidor para leer y escribir servicios de directorio a través de una red. Definido en RFC 4511, proporciona a las aplicaciones una forma estándar de consultar un directorio — respondiendo preguntas como «¿existe este usuario?», «¿a qué grupos pertenece?» y «¿a qué recursos puede acceder?»

A pesar de haber sido estandarizado por primera vez a principios de los años 90, LDAP sigue siendo la columna vertebral de la infraestructura de identidad empresarial en 2026. Active Directory, que funciona sobre LDAP, todavía está implementado en aproximadamente el 90% de las organizaciones en todo el mundo.

Puntos clave

• LDAP es un protocolo. Define cómo las aplicaciones consultan un directorio — cuentas de usuario, membresías de grupos, derechos de acceso. Active Directory lo implementa, pero LDAP funciona de forma independiente en OpenLDAP y otros servidores sin ningún software de Microsoft.
• AD no puede funcionar sin LDAP. Cada sistema que no es Windows y que se autentica contra Active Directory lo hace a través de LDAP. Si se elimina, AD pierde la capacidad de servir a aplicaciones de terceros, dispositivos de red e infraestructura Linux.
• El puerto 389 no es aceptable en producción. LDAP estándar transmite credenciales en texto plano. LDAPS en el puerto 636 cifra toda la sesión. Microsoft ha estado aplicando requisitos de firma y vinculación de canal desde 2020.
• Dos vulnerabilidades críticas fueron parcheadas en 2025. CVE-2025-26663 permite la ejecución remota de código no autenticada en controladores de dominio a través de un fallo de memoria en el servicio LDAP de Windows. CVE-2025-54918 elude las protecciones de vinculación de canal y firma mediante retransmisión NTLM. Ambas tienen parches — los controladores de dominio sin parchear son el elemento de remediación de mayor prioridad.
• LDAP y los protocolos modernos no son alternativas. SAML maneja SSO basado en navegador. OAuth maneja la autorización de API. LDAP maneja las búsquedas de directorio para sistemas que no hablan ninguno de los dos. La mayoría de los entornos empresariales ejecutan los tres simultáneamente.
• La gestión manual de accesos crea brechas. Cuando los cambios en grupos de AD no se propagan automáticamente a los sistemas dependientes, las cuentas permanecen activas más tiempo del debido. Sincronizar el acceso a credenciales con la membresía de grupos del directorio elimina ese retraso.

Entendiendo LDAP: Los fundamentos

LDAP es un protocolo estándar para acceder y gestionar servicios de información de directorio distribuidos. Opera en un modelo de datos jerárquico derivado del estándar X.500 y permite a los clientes autenticar usuarios, buscar atributos y recuperar membresías de grupos desde un directorio central. Las organizaciones lo utilizan para responder una pregunta fundamental a escala: ¿quién tiene permitido hacer qué y dónde?

Los datos que LDAP organiza residen en un Árbol de Información de Directorio (DIT) — una estructura jerárquica de entradas, cada una identificada por un Distinguished Name (DN). Un DN típico tiene este aspecto:

Copycn=jane.doe,ou=engineering,dc=company,dc=com

Cada entrada contiene atributos: una entrada de usuario puede contener mail, uid, memberOf y userPassword. Las aplicaciones consultan estos atributos para tomar decisiones de autenticación y autorización.

¿Cómo funciona LDAP? (modelo cliente-servidor)

Un cliente LDAP envía una solicitud a un servidor LDAP (llamado Directory System Agent, o DSA). El servidor procesa la operación contra su base de datos de directorio y devuelve una respuesta. Las operaciones principales definidas en RFC 4511 incluyen:

• Bind — autenticar un cliente en el directorio
• Search — consultar entradas que coincidan con un filtro
• Compare — verificar si una entrada tiene un valor de atributo específico
• Modify / Add / Delete — operaciones de escritura en entradas del directorio
• Unbind — terminar la sesión

La operación bind es donde ocurre la autenticación. Un cliente envía un DN y credenciales. El servidor las valida y concede o deniega la sesión. La mayoría de las aplicaciones empresariales utilizan LDAP bind para verificar la identidad del usuario antes de conceder acceso.

Puerto LDAP 389 vs. puerto LDAPS 636

LDAP estándar funciona en el puerto TCP 389 y transmite datos en texto plano. Esto significa que las credenciales, incluidas las contraseñas, viajan por la red sin cifrar. En cualquier entorno donde el tráfico de red pueda ser interceptado (que es cualquier entorno) esto es inaceptable.

LDAPS (LDAP sobre SSL/TLS) funciona en el puerto TCP 636 y envuelve toda la sesión LDAP en TLS, cifrando todo el tráfico incluyendo las credenciales de bind. Una tercera opción, StartTLS, actualiza una conexión existente del puerto 389 a TLS a mitad de sesión, pero introduce complejidad en la negociación y es más propenso a errores de configuración.

Microsoft ha estado exigiendo progresivamente la vinculación de canal LDAP y la firma LDAP desde 2020, con aplicación reforzada en actualizaciones posteriores de Windows Server. Ejecutar LDAP sin cifrar en el puerto 389 en producción es una brecha de seguridad. El puerto 636 es el valor predeterminado correcto.

LDAP vs. Active Directory: ¿Cuál es la diferencia?

Active Directory (AD) no es un reemplazo de LDAP — es un servicio de directorio que utiliza LDAP como uno de sus protocolos de acceso. Confundir los dos es uno de los conceptos erróneos más comunes en TI empresarial. La dependencia solo va en una dirección: LDAP funciona de forma independiente, AD no.

¿Se puede ejecutar LDAP sin AD?

Sí. LDAP es un protocolo — define cómo un cliente solicita información a un servidor de directorio y cómo ese servidor responde. Se puede implementar independientemente de cualquier software de Microsoft.

OpenLDAP es la implementación de código abierto más utilizada. 389 Directory Server y Apache Directory Server son alternativas comunes. Estos servidores independientes almacenan identidades de usuarios y membresías de grupos y los sirven a sistemas Linux/Unix, servidores de correo y aplicaciones personalizadas.

¿Se puede ejecutar AD sin LDAP?

No. Active Directory es un servicio de directorio completo construido por Microsoft sobre el modelo de datos X.500. Los controladores de dominio utilizan LDAP internamente para leer, escribir y replicar datos del directorio: usuarios, equipos, políticas de grupo. Cualquier aplicación de terceros o máquina que no sea Windows que se autentique contra AD lo hace hablando LDAP.

Si se elimina LDAP, AD no puede comunicarse con el resto de la infraestructura.

Cómo se relacionan en la práctica

Cuando un servidor Linux se autentica contra Active Directory, habla LDAP. Cuando una estación de trabajo Windows inicia sesión, utiliza Kerberos. AD soporta ambos — pero LDAP es lo que hace que AD sea accesible para el resto de la infraestructura.

Alternativas modernas: LDAP vs. SAML, OAuth y OpenID Connect

LDAP fue diseñado para la autenticación de red interna — consultar un directorio dentro de un perímetro corporativo. Los protocolos que le siguieron fueron diseñados para un mundo diferente: identidad federada a través de límites organizacionales, aplicaciones web y clientes móviles.

Estos protocolos no reemplazan a LDAP — operan en una capa diferente. SAML y OpenID Connect manejan SSO basado en navegador. LDAP maneja búsquedas de directorio y autenticación de aplicaciones para sistemas que no pueden hablar SAML. La mayoría de los entornos empresariales ejecutan todos ellos simultáneamente.

¿Sigue siendo relevante LDAP en 2026? (la realidad de la nube híbrida)

LDAP sigue siendo el protocolo de autenticación empresarial dominante, presente en aproximadamente el 90% de las organizaciones en todo el mundo a través de sus implementaciones de Active Directory. La adopción de la nube no ha cambiado esto.

La mayoría de las empresas no son completamente nativas de la nube. Ejecutan un modelo híbrido: algunas cargas de trabajo en Azure o AWS, otras en las instalaciones, con Active Directory como ancla de identidad para ambos. Microsoft Entra ID (anteriormente Azure AD) se conecta al AD local a través de sincronización, pero el AD local (y por lo tanto LDAP) sigue siendo la fuente autorizada para muchas decisiones de identidad.

El rol de LDAP en la arquitectura de confianza cero

La confianza cero requiere verificación continua: cada solicitud de acceso debe ser autenticada y autorizada, independientemente de la ubicación en la red. LDAP se encuentra en una intersección crítica en este modelo porque a menudo es el sistema que responde a esas solicitudes de verificación.

El desafío es que LDAP no fue diseñado con los principios de confianza cero en mente. Asume proximidad de red, utiliza conexiones persistentes y en su forma sin cifrar expone credenciales en tránsito. Adaptar LDAP a una arquitectura de confianza cero requiere controles compensatorios:

• LDAPS obligatorio
• reglas de firewall estrictas
• limitar qué sistemas pueden alcanzar el puerto 636
• aplicación de firma LDAP
• monitorización de intentos de bind para detectar patrones anómalos

LDAP no rompe la confianza cero pero requiere un endurecimiento deliberado para soportarla. Las organizaciones que tratan LDAP como un componente heredado y lo dejan sin configurar están creando exactamente el tipo de confianza implícita que la confianza cero está diseñada para eliminar.

DevOps y gestión de secretos en CI/CD

Los pipelines automatizados presentan un desafío específico de LDAP. Los sistemas CI/CD (Jenkins, GitLab CI, ejecutores de GitHub Actions) a menudo necesitan autenticarse contra LDAP para acceder a recursos internos. Esa autenticación típicamente implica una cuenta de servicio: un DN de bind LDAP dedicado con una contraseña estática.

Las credenciales estáticas de cuentas de servicio son un riesgo persistente. Rara vez se rotan, a menudo se comparten entre pipelines, y cuando aparecen en registros de compilación o archivos de configuración, son difíciles de detectar y revocar. La respuesta es gestionar estas credenciales a través de un gestor de secretos dedicado en lugar de codificarlas en la configuración del pipeline.

Riesgos críticos de seguridad de LDAP en 2026

LDAP no es solo un protocolo heredado con riesgos teóricos. Es una superficie de ataque activa con vulnerabilidades documentadas y explotadas.

La amenaza del robo de credenciales y ransomware

Según el X-Force Threat Intelligence Index 2026 de IBM, la recolección de credenciales fue el impacto de ataque más común observado en 2025. Los actores de amenazas recolectaron datos de inicio de sesión mediante phishing e infostealers, luego se mezclaron en flujos de autenticación normales para moverse lateralmente. Las credenciales de cuentas de servicio LDAP encajan precisamente en este patrón: reutilizadas entre aplicaciones, rara vez rotadas y casi nunca monitorizadas para detectar actividad de bind anómala.

La cadena de ataque está bien documentada: comprometer una credencial LDAP a través de phishing o password spraying, usarla para enumerar el directorio, identificar cuentas privilegiadas y escalar. El Digital Defense Report de Microsoft ha vinculado consistentemente el compromiso de credenciales AD/LDAP con el despliegue de ransomware. El directorio es un mapa de toda la estructura de acceso de la organización, y los atacantes lo leen antes de actuar.

Vulnerabilidades recientes: CVE-2025-26663 y CVE-2025-54918

Dos vulnerabilidades críticas divulgadas en 2025 demuestran que la superficie de ataque de LDAP se está expandiendo activamente.

CVE-2025-26663 es una vulnerabilidad de ejecución remota de código use-after-free en Windows LDAP, divulgada en abril de 2025. Un atacante puede explotar un fallo de gestión de memoria en el servicio LDAP de Windows (específicamente en wldap32.dll) para ejecutar código arbitrario en un servidor objetivo sin credenciales válidas.

El ataque solo requiere acceso de red al servicio LDAP. Los controladores de dominio, que exponen LDAP por diseño, son los objetivos principales. Los controladores de dominio sin parchear que ejecutan esta vulnerabilidad están efectivamente abiertos a Ejecución Remota de Código (RCE) no autenticada desde cualquier sistema que pueda alcanzar el puerto 389 o 636.

CVE-2025-54918, divulgada en septiembre de 2025, es una vulnerabilidad de escalada de privilegios que combina retransmisión NT LAN Manager con autenticación forzada para eludir las protecciones de vinculación de canal y firma LDAP. Un atacante con una cuenta de dominio de bajo privilegio puede forzar a un controlador de dominio a autenticarse en un sistema controlado por el atacante, manipular los paquetes de autenticación NTLM en tránsito y retransmitir la autenticación modificada de vuelta al controlador de dominio — logrando acceso de nivel SYSTEM. El ataque es particularmente peligroso porque elude controles en los que las organizaciones comúnmente confían como medidas de endurecimiento.

Mejores prácticas para asegurar LDAP en la empresa

La siguiente lista de verificación cubre los controles mínimos para una implementación LDAP en producción. Estas son recomendaciones que abordan un vector de ataque específico y documentado.

1. Aplicar LDAPS en el puerto 636. Deshabilitar LDAP en texto plano en el puerto 389 para todo el tráfico de producción. Configurar certificados TLS de su CA interna o una CA pública de confianza.
2. Habilitar firma LDAP y vinculación de canal. Previene ataques de retransmisión. Requerido para la mitigación de CVE-2025-54918 — aunque tenga en cuenta que CVE-2025-54918 elude estos controles en sistemas sin parchear, por lo que el parcheo sigue siendo obligatorio.
3. Aplicar todas las actualizaciones de seguridad de Windows. CVE-2025-26663 y CVE-2025-54918 tienen parches. Los controladores de dominio sin parchear son el elemento de remediación de mayor prioridad.
4. Restringir el acceso LDAP por IP. Solo los sistemas que legítimamente necesitan consultar LDAP deberían poder alcanzar el puerto 636. Las reglas de firewall deberían aplicar esto, no solo las suposiciones de segmentación de red.
5. Auditar credenciales de cuentas de servicio. Identificar cada DN de bind en uso en su entorno. Rotar contraseñas según un calendario. Eliminar cuentas que ya no se necesitan.
6. Monitorizar intentos de bind. Patrones de bind inusuales — fallos repetidos, binds desde IPs de origen inesperadas, binds a horas inusuales — son indicadores tempranos de credential stuffing o movimiento lateral.
7. Deshabilitar binds LDAP anónimos. Las consultas anónimas permiten la enumeración no autenticada del contenido del directorio. La mayoría de las implementaciones modernas no tienen un uso legítimo para binds anónimos.
8. Separar cuentas de servicio por función. Una cuenta de servicio utilizada por una VPN no debería tener los mismos permisos que una utilizada por un sistema de respaldo. El principio de mínimo privilegio también aplica a las cuentas de bind LDAP.

Optimizando el acceso empresarial con la integración LDAP de Passwork

La carga operativa de la gestión de acceso basada en LDAP se acumula con el tiempo. Los usuarios cambian de equipo, se unen a proyectos y abandonan la organización, y cada transición requiere cambios de acceso en múltiples sistemas. Cuando esos cambios son manuales, se retrasan. Las cuentas permanecen activas más tiempo del debido. Las credenciales se acumulan en lugares que nadie está rastreando.

Passwork se conecta directamente a Active Directory o cualquier directorio compatible con LDAP y mapea la membresía de grupos al acceso a bóvedas automáticamente:

• Añadir un usuario al grupo SRE en AD — las credenciales correctas aparecen en su bóveda de Passwork, sin necesidad de acción administrativa separada
• Eliminarlo del grupo — el acceso se revoca
• El directorio permanece como la única fuente de verdad para quién tiene acceso a qué

Para entornos autoalojados, Passwork se implementa completamente dentro de su propio perímetro. Las credenciales nunca lo abandonan. SSO SAML está soportado junto con LDAP, por lo que los equipos que usan ambos protocolos para diferentes capas de aplicación no necesitan reconstruir su arquitectura de identidad.

Cada lectura, escritura, compartición y exportación se registra en el registro de auditoría — relevante tanto para revisiones de seguridad internas como para demostrar cumplimiento con SOC 2 CC6.1 y GDPR Artículo 32.

Conclusión

LDAP no va a desaparecer. El mercado de software de directorio se valoró en 8,4 mil millones de dólares en 2025 y se proyecta que alcanzará los 19,7 mil millones de dólares para 2034, según la investigación de mercado de Dataintelo — una cifra que refleja la inversión empresarial continua en infraestructura de directorio, no una tecnología en declive. Con el 90% de las empresas todavía ejecutando Active Directory, LDAP sigue siendo el tejido conectivo de la gestión de identidad corporativa.

Lo que ha cambiado es el entorno de amenazas. CVE-2025-26663 y CVE-2025-54918 son vulnerabilidades activamente parcheadas que apuntan a los servicios LDAP que sus controladores de dominio exponen ahora mismo.

La acción práctica es sencilla: aplicar LDAPS, parchear los controladores de dominio, auditar las credenciales de cuentas de servicio y asegurarse de que los cambios de acceso en el directorio se propaguen automáticamente a los sistemas que dependen de él. La gestión manual de acceso a la escala a la que operan la mayoría de las empresas es donde aparecen las brechas.

Preguntas frecuentes sobre LDAP

¿Para qué se utiliza LDAP?

LDAP se utiliza para autenticar usuarios y buscar información de directorio — membresías de grupos, direcciones de correo electrónico, atributos de cuentas — en aplicaciones empresariales. Los casos de uso comunes incluyen autenticación VPN, búsqueda de usuarios en servidores de correo, SSO de aplicaciones y gestión centralizada de usuarios. La mayoría de las aplicaciones empresariales que necesitan verificar identidad contra un directorio corporativo utilizan LDAP.

¿Cuál es la diferencia entre LDAP y Active Directory?

LDAP es un protocolo abierto (RFC 4511) para acceder a servicios de directorio. Active Directory es el servicio de directorio de Microsoft, que utiliza LDAP como uno de sus protocolos de acceso. AD también utiliza Kerberos para la autenticación de Windows. Se puede usar LDAP sin Active Directory (a través de OpenLDAP, por ejemplo), pero Active Directory depende de LDAP para servir consultas de directorio a aplicaciones que no son de Windows.

¿Qué es LDAPS y por qué es importante?

LDAPS es LDAP sobre TLS, funcionando en el puerto 636. LDAP estándar en el puerto 389 transmite credenciales en texto plano, haciéndolas visibles para cualquiera que pueda interceptar el tráfico de red. LDAPS cifra toda la sesión. En 2026, ejecutar LDAP sin cifrar en producción es indefendible — Microsoft ha estado aplicando requisitos de firma LDAP y vinculación de canal desde 2020, y tanto CVE-2025-26663 como CVE-2025-54918 apuntan directamente a servicios LDAP.

¿Todavía se usa LDAP en 2026?

Sí. Active Directory, que depende de LDAP, está implementado en aproximadamente el 90% de las empresas en todo el mundo. La adopción de la nube no lo ha desplazado — la mayoría de las organizaciones ejecutan entornos híbridos donde el AD local sigue siendo la fuente de identidad autorizada. LDAP también está integrado en miles de aplicaciones que se autentican contra directorios empresariales y no será reemplazado por SAML u OAuth sin una reingeniería significativa.

¿Cómo encaja LDAP en una arquitectura de confianza cero?

LDAP puede soportar la confianza cero si se endurece correctamente. La confianza cero requiere verificación continua de cada solicitud de acceso, y LDAP a menudo es el sistema que responde a esas solicitudes. Los requisitos: aplicar LDAPS (puerto 636), habilitar firma y vinculación de canal, restringir el acceso al directorio por IP de origen, monitorizar intentos de bind y rotar credenciales de cuentas de servicio regularmente. La configuración predeterminada de LDAP no es compatible con la confianza cero — pero el protocolo en sí no es el obstáculo.

¿Cuáles son los principales riesgos de seguridad con LDAP?

Los riesgos principales son la exposición de credenciales a través de conexiones sin cifrar (puerto 389), robo de credenciales de cuentas de servicio, ataques de retransmisión NTLM (CVE-2025-54918) y RCE no autenticado a través de vulnerabilidades de corrupción de memoria (CVE-2025-26663). El X-Force Threat Intelligence Index 2025 de IBM encontró que los ataques basados en identidad — muchos dirigidos a credenciales de directorio — representaron el 30% de todas las intrusiones en 2024. El parcheo, la aplicación de LDAPS y la higiene de cuentas de servicio abordan la mayoría de estos riesgos.

¿Puede LDAP ser reemplazado por SAML u OAuth?

No completamente. SAML y OAuth manejan la autenticación federada basada en navegador y la autorización de API respectivamente. LDAP maneja búsquedas de directorio y autenticación de aplicaciones para sistemas que no pueden hablar SAML. La mayoría de los entornos empresariales ejecutan los tres protocolos para diferentes capas de su stack de aplicaciones. La pregunta no es cuál elegir — es qué aplicaciones requieren LDAP y si esas conexiones están debidamente aseguradas.

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

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

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

Passwork gana Top Performer Primavera 2026 en SourceForge

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

Passwork BlogAlex Muntyan

LDAP (Lightweight Directory Access Protocol) is a client-server protocol for reading and writing directory services over a network. Defined in RFC 4511, it gives applications a standard way to query a directory — asking questions like "does this user exist?", "what groups do they belong to?", and "what resources can they access?"

Despite being first standardized in the early 1990s, LDAP remains the backbone of enterprise identity infrastructure in 2026. Active Directory, which runs on LDAP, is still deployed at approximately 90% of organizations worldwide.

Key takeaways

• LDAP is a protocol. It defines how applications query a directory — user accounts, group memberships, access rights. Active Directory implements it, but LDAP runs independently on OpenLDAP and other servers without any Microsoft software.
• AD cannot function without LDAP. Every non-Windows system that authenticates against Active Directory does so over LDAP. Remove it, and AD loses the ability to serve third-party applications, network devices, and Linux infrastructure.
• Port 389 is not acceptable in production. Standard LDAP transmits credentials in plaintext. LDAPS on port 636 encrypts the entire session. Microsoft has been enforcing signing and channel binding requirements since 2020.
• Two critical vulnerabilities were patched in 2025. CVE-2025-26663 allows unauthenticated remote code execution on domain controllers via a memory flaw in the Windows LDAP service. CVE-2025-54918 bypasses channel binding and signing protections through NTLM relay. Both have patches — unpatched domain controllers are the highest-priority remediation item.
• LDAP and modern protocols are not alternatives. SAML handles browser-based SSO. OAuth handles API authorization. LDAP handles directory lookups for systems that speak neither. Most enterprise environments run all three simultaneously.
• Manual access management creates gaps. When AD group changes don't propagate automatically to dependent systems, accounts stay active longer than they should. Synchronizing credential access to directory group membership eliminates that lag.

Understanding LDAP: The basics

LDAP is a standard protocol for accessing and managing distributed directory information services. It operates on a hierarchical data model derived from the X.500 standard and allows clients to authenticate users, look up attributes, and retrieve group memberships from a central directory. Organizations use it to answer one fundamental question at scale: who is allowed to do what, and where?

The data LDAP organizes sits in a Directory Information Tree (DIT) — a hierarchical structure of entries, each identified by a Distinguished Name (DN). A typical DN looks like this:

Copycn=jane.doe,ou=engineering,dc=company,dc=com

Each entry holds attributes: a user entry might contain mail, uid, memberOf, and userPassword. Applications query these attributes to make authentication and authorization decisions.

How does LDAP work? (client-server model)

An LDAP client sends a request to an LDAP server (called a Directory System Agent, or DSA). The server processes the operation against its directory database and returns a response. Core operations defined in RFC 4511 include:

• Bind — authenticate a client to the directory
• Search — query entries matching a filter
• Compare — check whether an entry has a specific attribute value
• Modify / Add / Delete — write operations on directory entries
• Unbind — terminate the session

The bind operation is where authentication happens. A client sends a DN and credentials. The server validates them and either grants or denies the session. Most enterprise applications use LDAP bind to verify user identity before granting access.

LDAP port 389 vs. LDAPS port 636

Standard LDAP runs on TCP port 389 and transmits data in plaintext. That means credentials, including passwords, travel across the network unencrypted. In any environment where network traffic could be intercepted (which is every environment) this is unacceptable.

LDAPS (LDAP over SSL/TLS) runs on TCP port 636 and wraps the entire LDAP session in TLS, encrypting all traffic including bind credentials. A third option, StartTLS, upgrades an existing port 389 connection to TLS mid-session, but it introduces negotiation complexity and is more error-prone to configure correctly.

Microsoft has been progressively mandating LDAP channel binding and LDAP signing since 2020, with enforcement tightened in subsequent Windows Server updates. Running unencrypted LDAP on port 389 in production is a security gap. Port 636 is the correct default.

LDAP vs. Active Directory: What's the difference?

Active Directory (AD) is not a replacement for LDAP — it is a directory service that uses LDAP as one of its access protocols. Conflating the two is one of the most common misconceptions in enterprise IT. The dependency only runs one way: LDAP stands alone, AD does not.

Can you run LDAP without AD?

Yes. LDAP is a protocol — it defines how a client asks a directory server for information and how that server responds. You can deploy it independently of any Microsoft software.

OpenLDAP is the most widely used open-source implementation. 389 Directory Server and Apache Directory Server are common alternatives. These standalone servers store user identities and group memberships and serve them to Linux/Unix systems, mail servers, and custom applications.

Can you run AD without LDAP?

No. Active Directory is a full directory service built by Microsoft on top of the X.500 data model. Domain controllers use LDAP internally to read, write, and replicate directory data: users, computers, group policies. Any third-party application or non-Windows machine that authenticates against AD does so by speaking LDAP to it.

Remove LDAP, and AD cannot communicate with the rest of your infrastructure.

How they relate in practice

When a Linux server authenticates against Active Directory, it speaks LDAP. When a Windows workstation logs in, it uses Kerberos. AD supports both — but LDAP is what makes AD accessible to the rest of your infrastructure.

Modern alternatives: LDAP vs. SAML, OAuth, and OpenID Connect

LDAP was designed for internal network authentication — querying a directory inside a corporate perimeter. The protocols that followed it were designed for a different world: federated identity across organizational boundaries, web applications, and mobile clients.

These protocols do not replace LDAP — they operate at a different layer. SAML and OpenID Connect handle browser-based SSO. LDAP handles directory lookups and application authentication for systems that cannot speak SAML. Most enterprise environments run all of them simultaneously.

Is LDAP still relevant in 2026? (the hybrid cloud reality)

LDAP is still the dominant enterprise authentication protocol, present in approximately 90% of organizations worldwide through their Active Directory deployments. Cloud adoption has not changed this.

Most enterprises are not fully cloud-native. They run a hybrid model: some workloads in Azure or AWS, others on-premises, with Active Directory as the identity anchor for both. Microsoft Entra ID (formerly Azure AD) connects to on-premises AD through synchronization, but the on-premises AD (and therefore LDAP) remains the authoritative source for many identity decisions.

The role of LDAP in zero trust architecture

Zero trust requires continuous verification: every access request must be authenticated and authorized, regardless of network location. LDAP sits at a critical junction in this model because it is often the system that answers those verification requests.

The challenge is that LDAP was not designed with zero trust principles in mind. It assumes network adjacency, uses persistent connections, and in its unencrypted form exposes credentials in transit. Fitting LDAP into a zero trust architecture requires compensating controls:

• mandatory LDAPS
• strict firewall rules
• limiting which systems can reach port 636
• LDAP signing enforcement
• monitoring of bind attempts for anomalous patterns

LDAP does not break zero trust but it requires deliberate hardening to support it. Organizations that treat LDAP as a legacy component and leave it unconfigured are creating exactly the kind of implicit trust that zero trust is designed to eliminate.

DevOps and CI/CD secrets management

Automated pipelines present a specific LDAP challenge. CI/CD systems (Jenkins, GitLab CI, GitHub Actions runners) often need to authenticate against LDAP to access internal resources. That authentication typically involves a service account: a dedicated LDAP bind DN with a static password.

Static service account credentials are a persistent risk. They rarely rotate, they are often shared across pipelines, and when they appear in build logs or configuration files, they are difficult to detect and revoke. The answer is to manage these credentials through a dedicated secrets manager rather than hardcoding them in pipeline configuration.

Critical LDAP security risks in 2026

LDAP is not just a legacy protocol with theoretical risks. It is an active attack surface with documented, exploited vulnerabilities.

The threat of credential theft and ransomware

According to IBM's X-Force Threat Intelligence Index 2026, credential harvesting was the most common attack impact observed in 2025. Threat actors harvested login data via phishing and infostealers, then blended into normal authentication flows to move laterally. LDAP service account credentials fit this pattern precisely: reused across applications, rarely rotated, and almost never monitored for anomalous bind activity.

The attack chain is well-documented: compromise an LDAP credential through phishing or password spraying, use it to enumerate the directory, identify privileged accounts, and escalate. Microsoft's Digital Defense Report has consistently linked AD/LDAP credential compromise to ransomware deployment. The directory is a map of the entire organization's access structure, and attackers read it before they act.

Recent vulnerabilities: CVE-2025-26663 and CVE-2025-54918

Two critical vulnerabilities disclosed in 2025 demonstrate that LDAP's attack surface is actively expanding.

CVE-2025-26663 is a use-after-free remote code execution vulnerability in Windows LDAP, disclosed in April 2025. An attacker can exploit a memory management flaw in the Windows LDAP service (specifically in wldap32.dll) to execute arbitrary code on a target server without valid credentials.

The attack requires only network access to the LDAP service. Domain controllers, which expose LDAP by design, are the primary targets. Unpatched domain controllers running this vulnerability are effectively open to unauthenticated Remote Code Execution (RCE) from any system that can reach port 389 or 636.

CVE-2025-54918, disclosed in September 2025, is a privilege escalation vulnerability that combines NT LAN Manager relay with coerced authentication to bypass LDAP channel binding and signing protections. An attacker with a low-privileged domain account can coerce a domain controller into authenticating to an attacker-controlled system, manipulate the NTLM authentication packets in transit, and relay the modified authentication back to the domain controller — achieving SYSTEM-level access. The attack is particularly dangerous because it bypasses controls that organizations commonly rely on as hardening measures.

Best practices for securing LDAP in the enterprise

The following checklist covers the minimum controls for a production LDAP deployment. These are recommendations that address a specific, documented attack vector.

1. Enforce LDAPS on port 636. Disable plaintext LDAP on port 389 for all production traffic. Configure TLS certificates from your internal CA or a trusted public CA.
2. Enable LDAP signing and channel binding. Prevents relay attacks. Required for CVE-2025-54918 mitigation — though note that CVE-2025-54918 bypasses these controls on unpatched systems, so patching is still mandatory.
3. Apply all Windows security updates. CVE-2025-26663 and CVE-2025-54918 both have patches. Unpatched domain controllers are the highest-priority remediation item.
4. Restrict LDAP access by IP. Only systems that legitimately need to query LDAP should be able to reach port 636. Firewall rules should enforce this, not just network segmentation assumptions.
5. Audit service account credentials. Identify every bind DN in use across your environment. Rotate passwords on a schedule. Remove accounts that are no longer needed.
6. Monitor bind attempts. Unusual bind patterns — repeated failures, binds from unexpected source IPs, binds at unusual hours — are early indicators of credential stuffing or lateral movement.
7. Disable anonymous LDAP binds. Anonymous queries allow unauthenticated enumeration of directory contents. Most modern deployments have no legitimate use for anonymous binds.
8. Separate service accounts by function. A service account used by a VPN should not have the same permissions as one used by a backup system. Least privilege applies to LDAP bind accounts too.

Streamlining enterprise access with Passwork LDAP integration

The operational burden of LDAP-based access management compounds over time. Users change teams, join projects, and leave the organization and each transition requires access changes across multiple systems. When those changes are manual, they lag. Accounts stay active longer than they should. Credentials accumulate in places no one is tracking.

Passwork connects directly to Active Directory or any LDAP-compatible directory and maps group membership to vault access automatically:

• Add a user to the SRE group in AD — the correct credentials appear in their Passwork vault, no separate admin action required
• Remove them from the group — access is revoked
• The directory stays the single source of truth for who has access to what

For self-hosted environments, Passwork deploys entirely within your own perimeter. Credentials never leave it. SAML SSO is supported alongside LDAP, so teams using both protocols for different application layers don't need to rebuild their identity architecture.

Every read, write, share, and export is recorded in the audit log — relevant both for internal security reviews and for demonstrating compliance with SOC 2 CC6.1 and GDPR Article 32.

Conclusion

LDAP is not going away. The directory software market was valued at $8.4 billion in 2025 and is projected to reach $19.7 billion by 2034, according to Dataintelo's market research — a figure that reflects continued enterprise investment in directory infrastructure, not a technology in decline. With 90% of enterprises still running Active Directory, LDAP remains the connective tissue of corporate identity management.

What has changed is the threat environment. CVE-2025-26663 and CVE-2025-54918 are actively patched vulnerabilities targeting the LDAP services your domain controllers expose right now.

The practical action is straightforward: enforce LDAPS, patch your domain controllers, audit your service account credentials, and make sure access changes in your directory propagate automatically to the systems that depend on it. Manual access management at the scale most enterprises operate is where gaps appear.

Frequently asked questions about LDAP

What is LDAP used for?

LDAP is used to authenticate users and look up directory information — group memberships, email addresses, account attributes — across enterprise applications. Common use cases include VPN authentication, email server user lookup, application SSO, and centralized user management. Most enterprise applications that need to verify identity against a corporate directory use LDAP.

What is the difference between LDAP and Active Directory?

LDAP is an open protocol (RFC 4511) for accessing directory services. Active Directory is Microsoft's directory service, which uses LDAP as one of its access protocols. AD also uses Kerberos for Windows authentication. You can use LDAP without Active Directory (via OpenLDAP, for example), but Active Directory relies on LDAP to serve directory queries to non-Windows applications.

What is LDAPS and why does it matter?

LDAPS is LDAP over TLS, running on port 636. Standard LDAP on port 389 transmits credentials in plaintext, making them visible to anyone who can intercept network traffic. LDAPS encrypts the entire session. In 2026, running unencrypted LDAP in production is indefensible — Microsoft has been enforcing LDAP signing and channel binding requirements since 2020, and both CVE-2025-26663 and CVE-2025-54918 target LDAP services directly.

Is LDAP still used in 2026?

Yes. Active Directory, which relies on LDAP, is deployed at approximately 90% of enterprises worldwide. Cloud adoption has not displaced it — most organizations run hybrid environments where on-premises AD remains the authoritative identity source. LDAP is also embedded in thousands of applications that authenticate against enterprise directories and will not be replaced by SAML or OAuth without significant re-engineering.

How does LDAP fit into a zero trust architecture?

LDAP can support zero trust if hardened correctly. Zero trust requires continuous verification of every access request, and LDAP is often the system answering those requests. The requirements: enforce LDAPS (port 636), enable signing and channel binding, restrict directory access by source IP, monitor bind attempts, and rotate service account credentials regularly. LDAP's default configuration is not zero trust-compatible — but the protocol itself is not the obstacle.

What are the main security risks with LDAP?

The primary risks are credential exposure over unencrypted connections (port 389), service account credential theft, NTLM relay attacks (CVE-2025-54918), and unauthenticated RCE via memory corruption vulnerabilities (CVE-2025-26663). IBM's X-Force Threat Intelligence Index 2025 found that identity-based attacks — many targeting directory credentials — accounted for 30% of all intrusions in 2024. Patching, LDAPS enforcement, and service account hygiene address the majority of these risks.

Can LDAP be replaced by SAML or OAuth?

Not entirely. SAML and OAuth handle browser-based federated authentication and API authorization respectively. LDAP handles directory lookups and application authentication for systems that cannot speak SAML. Most enterprise environments run all three protocols for different layers of their application stack. The question is not which to choose — it is which applications require LDAP and whether those connections are secured properly.

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

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

Passwork BlogAlex Muntyan

Insecure password sharing: 2026 risks and secure solutions

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

Passwork BlogAlex Muntyan

Passwork wins Top Performer Spring 2026 on SourceForge

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

Passwork BlogAlex Muntyan

Wenn eine Datenbank kompromittiert wird, lautet die erste Frage immer gleich: Sind die gehashten Passwörter sicher? Die Antwort hängt vollständig davon ab, wie diese Hashes erzeugt wurden. SHA-256 selbst kann nicht entschlüsselt werden — es ist eine kryptografische Einweg-Hashfunktion, kein Verschlüsselungsalgorithmus. Aber „kann nicht entschlüsselt werden" bedeutet nicht dasselbe wie „kann nicht geknackt werden".

Was ist SHA-256

SHA-256 (Secure Hash Algorithm 256-bit) ist eine kryptografische Hashfunktion aus der SHA-2-Familie, die von der NSA entwickelt und 2001 vom NIST unter FIPS 180-4 veröffentlicht wurde. Sie nimmt eine Eingabe beliebiger Länge und erzeugt eine feste 256-Bit-(32-Byte-)Ausgabe — den Hash oder Digest. Die Ausgabe erscheint immer zufällig, und dieselbe Eingabe erzeugt immer dieselbe Ausgabe.

SHA-256 ist kein Verschlüsselungsalgorithmus. Es gibt keinen Schlüssel, und die Ausgabe kann nicht umgekehrt werden. Seine Aufgabe ist es, einen einzigartigen Fingerabdruck eines Datensatzes zu erzeugen — nicht diese Daten für eine spätere Wiederherstellung zu schützen.

Drei Eigenschaften definieren seine Sicherheit:

• Urbildresistenz. Bei gegebenem Hash kann die ursprüngliche Eingabe nicht gefunden werden.
• Kollisionsresistenz. Es können keine zwei verschiedenen Eingaben gefunden werden, die denselben Hash erzeugen.
• Lawineneffekt. Eine Änderung eines einzelnen Bits in der Eingabe kippt etwa die Hälfte der Ausgabe-Bits, wodurch das Ergebnis völlig unvorhersehbar wird.

SHA-256 wird in TLS-Zertifikaten, Code-Signierung, Git-Commit-Integrität, Bitcoins Proof-of-Work-Mechanismus und (in Kombination mit korrekter Schlüsselableitung) bei der Passwortspeicherung verwendet. Es ist eines der am weitesten verbreiteten kryptografischen Primitive in Produktivsystemen heute.

Hashing vs. Verschlüsselung: Warum SHA-256 nicht entschlüsselt werden kann

SHA-256 ist eine kryptografische Hashfunktion — eine Einweg-Transformation. Verschlüsselung ist eine Zweiwege-Operation: Daten werden mit einem Schlüssel verschlüsselt und mit einem Schlüssel entschlüsselt. Hashing hat keinen Schlüssel und keinen Rückweg. Bei einem gegebenen SHA-256-Digest gibt es keine mathematische Operation, die die ursprüngliche Eingabe wiederherstellt.

Die Eigenschaft, die dies ermöglicht, heißt Urbildresistenz: Es muss rechnerisch unmöglich sein, eine Eingabe m zu finden, sodass SHA256(m) = h für einen gegebenen Hash h gilt. Eine verwandte Eigenschaft, der Lawineneffekt, bedeutet, dass die Änderung eines einzelnen Bits in der Eingabe etwa die Hälfte der Ausgabe-Bits kippt — was es unmöglich macht, durch kleine Anpassungen „rückwärts zu arbeiten".

Die Unterscheidung ist in der Praxis wichtig. Wenn ein Entwickler Passwörter mittels AES-Verschlüsselung statt Hashing speichert, legt ein Verlust des Verschlüsselungsschlüssels jedes Passwort in der Datenbank offen. Ein Hash hat keinen Schlüssel, der gestohlen werden kann.

Wie der SHA-256-Algorithmus funktioniert (Schritt für Schritt)

SHA-256 ist in NIST FIPS 180-4 definiert und gehört zur SHA-2-Familie. Er verarbeitet Eingaben beliebiger Länge und erzeugt eine deterministische 256-Bit-Ausgabe. Die Kernstruktur ist die Merkle-Damgård-Konstruktion: Die Nachricht wird in Blöcke fester Größe aufgeteilt, jeder Block wird durch eine Kompressionsfunktion verarbeitet, und die Ausgaben werden verkettet.

Schritt 1: Vorverarbeitung und Padding

Die Eingabenachricht wird aufgefüllt, sodass ihre Gesamtlänge ein Vielfaches von 512 Bits ist. Das Padding beginnt immer mit einem 1-Bit, gefolgt von genügend 0-Bits, gefolgt von einer 64-Bit-Darstellung der ursprünglichen Nachrichtenlänge. Dieser Schritt ist obligatorisch, auch wenn die Nachricht bereits genau passt — der Algorithmus muss immer wissen, wo die Nachricht endet.

Schritt 2: Nachrichtenplanung

Die aufgefüllte Nachricht wird in 512-Bit-Blöcke zerlegt. Jeder Block wird in sechzehn 32-Bit-Wörter unterteilt. Diese sechzehn Wörter werden dann mithilfe einer Mischung aus bitweisen Rotationen und XOR-Operationen zu einem 64-Wort-Nachrichtenplan erweitert. Diese Erweiterung stellt sicher, dass jedes Bit der ursprünglichen Eingabe den Kompressionsschritt beeinflusst.

Schritt 3: Die Kompressionsfunktion

Hier findet die eigentliche Arbeit statt. SHA-256 verwaltet acht 32-Bit-Arbeitsvariablen (a bis h), die mit Konstanten initialisiert werden, die aus den Nachkommastellen der Quadratwurzeln der ersten acht Primzahlen abgeleitet sind. Über 64 Runden werden diese Variablen mithilfe von bitweisen AND-, OR-, XOR- und NOT-Operationen sowie modularer Addition aktualisiert. Zwei nichtlineare Funktionen — Ch(e, f, g) und Maj(a, b, c) — führen eine Komplexität ein, die die Beziehung zwischen Eingabe und Ausgabe undurchsichtig macht. Nach allen 64 Runden werden die Arbeitsvariablen wieder zu den Anfangswerten für diesen Block addiert.

Schritt 4: Endgültige Ausgabe

Nachdem alle Blöcke verarbeitet wurden, werden die acht Arbeitsvariablen verkettet, um den endgültigen 256-Bit-Digest zu erzeugen. Dieselbe Eingabe erzeugt immer dieselbe Ausgabe. Jede Änderung an der Eingabe — selbst ein einzelnes Zeichen — erzeugt einen völlig anderen Hash.

Wenn SHA-256 nicht entschlüsselt werden kann, wie knacken Hacker es dann?

SHA-256 ist mathematisch solide. Der Algorithmus selbst hat nach mehr als zwei Jahrzehnten Kryptoanalyse keine bekannten praktischen Schwächen. Was versagt, ist nicht der Algorithmus — es ist die Art und Weise, wie Passwörter damit gespeichert werden.

Brute-Force-Angriffe

Ein Brute-Force-Angriff kehrt den Hash nicht um. Er rät. Der Angreifer hasht Passwortkandidaten (Wörterbuchwörter, gängige Muster, Zeichenkombinationen) und vergleicht die Ausgabe mit dem gestohlenen Hash. Wenn die Hashes übereinstimmen, ist das Passwort gefunden. Die Geschwindigkeit von SHA-256 ist hier das Problem: Eine einzelne Nvidia RTX 4090 GPU kann etwa 164 Milliarden SHA-256-Hashes pro Sekunde berechnen (Specops Software, 2025). Bei dieser Rate wird ein achtstelliges Kleinbuchstaben-Passwort in Sekunden geknackt.

Rainbow-Table-Angriffe

Eine Rainbow Table ist eine vorberechnete Datenbank von Hash-zu-Klartext-Zuordnungen. Anstatt spontan zu hashen, schlägt der Angreifer den gestohlenen Hash in der Tabelle nach und liest das ursprüngliche Passwort ab. Tabellen für gängige Passwortformate können im Voraus generiert und für mehrere Datenlecks wiederverwendet werden. Kollisionsresistenz — die Eigenschaft, dass keine zwei Eingaben denselben Hash erzeugen sollten — ist nicht das, was Rainbow Tables ausnutzen. Sie nutzen die Tatsache aus, dass gängige Passwörter vorhersehbare, wiederholbare Hashes erzeugen.

Beide Angriffe haben eine gemeinsame Voraussetzung: Der Hash muss ungesalzen sein. Fügen Sie ein Salt hinzu, und beide Angriffe werden dramatisch teurer.

Warum reines SHA-256 für die Passwortspeicherung ungeeignet ist

SHA-256 wurde für Geschwindigkeit entwickelt. Für seine vorgesehenen Anwendungen — Überprüfung der Dateiintegrität, Signierung von Zertifikaten, Absicherung von Blockchain-Transaktionen — ist Geschwindigkeit ein Vorteil. Für die Passwortspeicherung ist Geschwindigkeit ein Nachteil.

Das Problem: SHA-256 ist zu schnell

Bei 164 Milliarden Hashes pro Sekunde auf Consumer-Hardware kann ein Angreifer den gesamten Raum von achtstelligen Passwörtern mit Groß- und Kleinbuchstaben, Ziffern und Symbolen in weniger als einer Stunde durchprobieren. Das OWASP Password Storage Cheat Sheet ist eindeutig: „Schnelle Hash-Algorithmen wie SHA-256 sind für die Passwortspeicherung nicht geeignet, da sie Angreifern ermöglichen, schnell eine große Anzahl von Versuchen durchzuführen."

Lösung 1: Salting

Ein Salt ist eine eindeutige, zufällig generierte Zeichenkette, die vor dem Hashen an jedes Passwort angehängt wird. SHA256("password") erzeugt immer denselben Hash. SHA256("password" + "x7kQ2mNp") erzeugt einen völlig anderen — und jeder Benutzer erhält ein anderes Salt. Dies macht Rainbow Tables vollständig wirkungslos: Der Angreifer kann keine Hashes für gesalzene Eingaben vorberechnen, ohne das Salt jedes Benutzers zu kennen. Es bedeutet auch, dass zwei Benutzer mit demselben Passwort unterschiedliche Hashes in der Datenbank haben.

Lösung 2: Key Stretching mit PBKDF2

Salting verhindert vorberechnete Lookups, verlangsamt aber keine Brute-Force-Angriffe. Dafür ist Key Stretching erforderlich. PBKDF2 (Password-Based Key Derivation Function 2) wendet eine pseudozufällige Funktion — typischerweise HMAC-SHA-256 — tausende Male nacheinander an. Jede Iteration kostet Zeit. Die 164 Milliarden Hashes pro Sekunde des Angreifers sinken auf einen Bruchteil davon, wenn jeder „Versuch" 600.000 Iterationen erfordert.

OWASP empfiehlt PBKDF2 mit HMAC-SHA-256 und mindestens 600.000 Iterationen für FIPS-140-Konformität. Argon2id ist die bevorzugte Wahl, wenn keine FIPS-Konformität erforderlich ist, da es zusätzlich Speicherhärte bietet.

Reines SHA-256 vs. PBKDF2-HMAC-SHA256: Sicherheitsvergleich bei der Passwortspeicherung

Ist SHA-256 anfällig für Quantencomputer?

Grovers Algorithmus gibt einem Quantencomputer eine quadratische Beschleunigung bei unstrukturierten Suchproblemen. Angewandt auf SHA-256 reduziert er die effektive Sicherheit von 2²⁵⁶ Operationen auf 2¹²⁸ Operationen. Das klingt alarmierend, bis man das Ausmaß berücksichtigt: 2¹²⁸ sind ungefähr 3,4×10³⁸. Ein Quantencomputer, der mit 10 Milliarden Operationen pro Sekunde läuft, würde etwa 3,4×10²⁸ Jahre benötigen, um die Hälfte des Suchraums zu durchsuchen — Größenordnungen länger als das Alter des Universums.

Shors Algorithmus, der RSA und Elliptische-Kurven-Kryptografie durch effizientes Faktorisieren großer ganzer Zahlen bricht, gilt nicht für Hashfunktionen. Die Sicherheit von SHA-256 basiert nicht auf der Faktorisierung ganzer Zahlen.

NIST standardisiert aktiv Post-Quanten-Algorithmen (FIPS 203, 204, 205 wurden 2024 finalisiert), hauptsächlich mit Fokus auf asymmetrische Kryptografie. SHA-256 steht für die absehbare Zukunft nicht auf der Ersatzliste. Die praktische Bedrohung für SHA-256 durch Quantencomputing bleibt theoretisch.

Wie Enterprise-Passwortmanager Kryptografie sicher einsetzen

Enterprise-Passwortmanager, die Zero-Knowledge-Prinzipien befolgen, wenden dieselben kryptografischen Bausteine an, die in diesem Artikel behandelt werden (SHA-256, PBKDF2, HMAC, AES-256), kombinieren sie jedoch zu einer mehrschichtigen Architektur, bei der der Server niemals Klartextdaten oder die Schlüssel zur Entschlüsselung besitzt. Die Sicherheitsgarantie ergibt sich aus dem Design, nicht aus dem Vertrauen in den Server.

Das Passwork-Zwei-Ebenen-Verschlüsselungsmodell

Zu wissen, dass reines SHA-256 für die Passwortspeicherung unzureichend ist, ist eine Sache. Die korrekte Alternative unternehmensweit zu implementieren, ist eine andere. Hier ist die Architektur des Tools genauso wichtig wie der Algorithmus.

Passwork basiert auf einer Zero-Knowledge-Architektur: Der Server besitzt niemals genügend Informationen, um Benutzerdaten zu entschlüsseln. Das Masterpasswort verlässt niemals das Gerät des Benutzers. Alle kryptografischen Schlüssel werden clientseitig generiert. Der Server speichert nur verschlüsselte Daten und verschlüsselte Schlüssel — die Entschlüsselung ist nur auf dem Client möglich.

Die Verschlüsselungskette funktioniert wie folgt, wie in Passworks Kryptografie-Übersicht dokumentiert:

1. Masterpasswort (vom Benutzer eingegeben) → PBKDF2 mit SHA-256, 300.000 Iterationen
2. Masterschlüssel (512 Bits) → AES-256-CBC
3. Privater RSA-Schlüssel (2048 Bits, RSA-OAEP)
4. Tresorschlüssel (256 Bits) → AES-256-CBC
5. Datensatzschlüssel (256 Bits) → AES-256-CBC
6. Datensatzdaten (Passwörter, Geheimnisse, Dateien — verschlüsselt im Ruhezustand)

Auf der Serverseite verschlüsselt eine separate AES-256-CFB-Schicht die Datenbank unabhängig. Jeder Datensatz ist doppelt verschlüsselt: einmal vom Client, bevor er das Gerät verlässt, einmal vom Server, bevor er auf die Festplatte geschrieben wird.

PBKDF2 mit 300.000 clientseitigen Iterationen entspricht den NIST-Empfehlungen (≥310.000 für SHA-256) und übertrifft das OWASP-Minimum für die meisten Einsatzszenarien. Das serverseitige PBKDF2 läuft mit 600.000 Iterationen — und erfüllt damit direkt die FIPS-140-Schwelle.

Diese Architektur bedeutet, dass ein Datenbankleck nichts Verwertbares liefert. Ein Angreifer, der die Datenbank exfiltriert, erhält AES-256-verschlüsselte Blobs, die von Schlüsseln abgeleitet wurden, die niemals auf dem Server gespeichert waren.

Fazit

SHA-256 ist theoretisch unknackbar. Der Algorithmus hat über zwei Jahrzehnte Kryptoanalyse ohne einen praktischen Angriff überstanden. Aber der Algorithmus ist nur so stark wie seine Implementierung. Speichern Sie Passwörter als reine SHA-256-Hashes, und eine einzelne GPU kann Milliarden von Kandidaten pro Sekunde testen. Fügen Sie ein Salt hinzu und wenden Sie PBKDF2 mit ausreichenden Iterationen an, und dieselbe Hardware wird gegen Ihre Datenbank nutzlos.

Die Lücke zwischen „SHA-256 ist sicher" und „unsere Passwörter sind sicher" wird durch korrekte Implementierung gefüllt — Salting, Key Stretching und eine Zero-Knowledge-Architektur, die sicherstellt, dass der Server niemals die Schlüssel besitzt, die zur Entschlüsselung von Benutzerdaten benötigt werden.

Wenn Ihr Team Unternehmensanmeldedaten verwaltet, schützt Passwork diese durch Zero-Knowledge-Architektur, clientseitige AES-256-Verschlüsselung und PBKDF2-Key-Stretching mit 300.000 Iterationen — sodass eine Serverkompromittierung nichts Verwertbares offenlegt. Passwork ist sowohl als selbstgehostete Bereitstellung für Organisationen verfügbar, die vollständige Infrastrukturkontrolle benötigen, als auch als Cloud-Lösung für Teams, die dieselben kryptografischen Garantien ohne eigene Serververwaltung wünschen.

FAQ: SHA-256 erklärt

Kann man SHA-256 entschlüsseln?

Nein. SHA-256 ist eine kryptografische Einweg-Hashfunktion. Es gibt keinen Schlüssel, keinen Umkehralgorithmus und keine mathematische Operation, die die ursprüngliche Eingabe aus einem Hash wiederherstellt. Was Angreifer tun können, ist raten — indem sie Passwortkandidaten hashen und die Ausgabe vergleichen. Das ist Knacken, nicht Entschlüsselung, und es funktioniert nur gegen schwache oder ungesalzene Hashes.

Was ist der Unterschied zwischen SHA-256-Hashing und Verschlüsselung?

Verschlüsselung ist mit dem richtigen Schlüssel umkehrbar. Hashing ist unter keinen Umständen umkehrbar. SHA-256 nimmt eine Eingabe beliebiger Länge und erzeugt eine feste 256-Bit-Ausgabe. Dieselbe Eingabe erzeugt immer dieselbe Ausgabe, aber der Prozess kann nicht rückwärts ausgeführt werden. Verschlüsselung bewahrt die Fähigkeit, die Originaldaten wiederherzustellen; Hashing zerstört sie absichtlich.

Was ist der Lawineneffekt bei SHA-256?

Der Lawineneffekt bedeutet, dass eine Änderung eines einzelnen Bits in der Eingabe etwa die Hälfte der Ausgabe-Bits kippt. Ändern Sie ein Zeichen in einem Passwort, und der resultierende SHA-256-Hash sieht völlig anders aus als der ursprüngliche. Diese Eigenschaft verhindert, dass Angreifer Teilwissen über eine Eingabe nutzen können, um den Hash-Suchraum einzugrenzen.

Was ist PBKDF2 und warum ist es für die Passwortsicherheit wichtig?

PBKDF2 (Password-Based Key Derivation Function 2) wendet eine pseudozufällige Funktion — typischerweise HMAC-SHA-256 — iterativ auf ein Passwort und Salt an. Jede Iteration erhöht den Rechenaufwand. Bei 600.000 Iterationen steigt die benötigte Zeit pro Versuch um den Faktor 600.000 im Vergleich zu einem einzelnen SHA-256-Hash. Dies macht Brute-Force-Angriffe gegen korrekt gespeicherte Passwörter selbst mit GPU-Rechenleistung unpraktikabel.

Ist SHA-256 anfällig für Quantencomputer-Angriffe?

Praktisch nicht. Grovers Algorithmus reduziert die effektive Sicherheit von SHA-256 von 2²⁵⁶ auf 2¹²⁸ Operationen. Bei 2¹²⁸ würde selbst ein hypothetischer Quantencomputer mit 10 Milliarden Operationen pro Sekunde mehr Zeit als das Alter des Universums benötigen, um den Suchraum zu durchsuchen. NISTʼs Post-Quanten-Kryptografie-Standardisierungsinitiative zielt auf asymmetrische Algorithmen ab, nicht auf SHA-256.

Was ist die Merkle-Damgård-Konstruktion?

Die Merkle-Damgård-Konstruktion ist das strukturelle Rahmenwerk, das SHA-256 zugrunde liegt. Die Eingabenachricht wird in 512-Bit-Blöcke unterteilt. Jeder Block wird durch eine Kompressionsfunktion verarbeitet, die den aktuellen Block und die Ausgabe des vorherigen Blocks als Eingaben nimmt. Die Ausgaben werden sequenziell verkettet, sodass der endgültige Hash von jedem Bit der gesamten Eingabenachricht abhängt.

Mitarbeiter-Offboarding: Leitfaden zur sicheren Zugriffsentziehung 2026

Das Deaktivieren eines SSO-Kontos entzieht nicht den Zugriff. API-Schlüssel, KI-Agenten-Anmeldedaten und geteilte Passwörter überleben es. Dieser Leitfaden behandelt das vollständige Offboarding-Playbook — von Stunde-Null-Auslösern bis zur NHI-Bereinigung.

Passwork BlogAlex Muntyan

Secrets-Rotation-Lebenszyklus: Von der Erstellung bis zum Widerruf

Secret-Rotation scheitert, wenn sie als geplante Aufgabe statt als Lebenszyklus behandelt wird. Dieser Leitfaden behandelt alle sieben Phasen — von Erstellung und Besitz bis zu sicherer Rotation, Notfallwiderruf und Audit-Nachweis.

Passwork BlogAlex Muntyan

Brute-Force-Angriffe 2026: Arten, Beispiele und Prävention

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

Passwork BlogAlex Muntyan

Cuando se produce una brecha en una base de datos, la primera pregunta siempre es la misma: ¿están seguras las contraseñas hasheadas? La respuesta depende completamente de cómo se generaron esos hashes. SHA-256 en sí no se puede descifrar — es una función hash criptográfica unidireccional, no un algoritmo de cifrado. Pero «no se puede descifrar» no es lo mismo que «no se puede crackear».

Qué es SHA-256

SHA-256 (Secure Hash Algorithm de 256 bits) es una función hash criptográfica de la familia SHA-2, desarrollada por la NSA y publicada por el NIST en 2001 bajo FIPS 180-4. Toma una entrada de cualquier longitud y produce una salida fija de 256 bits (32 bytes) — el hash, o resumen. La salida siempre parece aleatoria, y la misma entrada siempre produce la misma salida.

SHA-256 no es un algoritmo de cifrado. No tiene clave, y su salida no puede revertirse. Su función es producir una huella digital única de un dato — no proteger ese dato para su recuperación posterior.

Tres propiedades definen su seguridad:

• Resistencia a la preimagen. Dado un hash, no se puede encontrar la entrada original.
• Resistencia a colisiones. No se pueden encontrar dos entradas diferentes que produzcan el mismo hash.
• Efecto avalancha. Un cambio de un solo bit en la entrada modifica aproximadamente la mitad de los bits de salida, haciendo el resultado completamente impredecible.

SHA-256 se utiliza en certificados TLS, firma de código, integridad de commits en Git, el mecanismo de prueba de trabajo de Bitcoin y (cuando se combina con una derivación de claves adecuada) almacenamiento de contraseñas. Es una de las primitivas criptográficas más ampliamente desplegadas en sistemas de producción actualmente.

Hash vs. cifrado: Por qué SHA-256 no se puede descifrar

SHA-256 es una función hash criptográfica — una transformación unidireccional. El cifrado es una operación bidireccional: se cifran datos con una clave y se descifran con una clave. El hashing no tiene clave ni camino de retorno. Dado un resumen SHA-256, no existe ninguna operación matemática que recupere la entrada original.

La propiedad que hace esto posible se llama resistencia a la preimagen: debe ser computacionalmente inviable encontrar cualquier entrada m tal que SHA256(m) = h para un hash dado h. Una propiedad relacionada, el efecto avalancha, significa que cambiar un solo bit en la entrada modifica aproximadamente la mitad de los bits de salida — haciendo imposible «trabajar hacia atrás» mediante pequeños ajustes.

La distinción es importante en la práctica. Si un desarrollador almacena contraseñas usando cifrado AES en lugar de hashing, una brecha de la clave de cifrado expone todas las contraseñas de la base de datos. Un hash no tiene clave que robar.

Cómo funciona el algoritmo SHA-256 (paso a paso)

SHA-256 está definido en NIST FIPS 180-4 y pertenece a la familia SHA-2. Procesa entradas de cualquier longitud y produce una salida determinista de 256 bits. La estructura central es la construcción Merkle-Damgård: el mensaje se divide en bloques de tamaño fijo, cada bloque se procesa a través de una función de compresión, y las salidas se encadenan.

Paso 1. Preprocesamiento y relleno

El mensaje de entrada se rellena para que su longitud total sea múltiplo de 512 bits. El relleno siempre comienza con un bit 1, seguido de suficientes bits 0, seguidos de una representación de 64 bits de la longitud del mensaje original. Este paso es obligatorio incluso si el mensaje ya encaja perfectamente — el algoritmo siempre debe saber dónde termina el mensaje.

Paso 2. Programación del mensaje

El mensaje rellenado se divide en bloques de 512 bits. Cada bloque se divide en dieciséis palabras de 32 bits. Esas dieciséis palabras se expanden luego en una programación de mensajes de 64 palabras usando una combinación de rotaciones a nivel de bits y operaciones XOR. Esta expansión asegura que cada bit de la entrada original influya en el paso de compresión.

Paso 3. La función de compresión

Aquí es donde ocurre el trabajo. SHA-256 mantiene ocho variables de trabajo de 32 bits (a hasta h), inicializadas con constantes derivadas de las partes fraccionarias de las raíces cuadradas de los primeros ocho números primos. A lo largo de 64 rondas, estas variables se actualizan usando operaciones AND, OR, XOR y NOT a nivel de bits, más suma modular. Dos funciones no lineales — Ch(e, f, g) y Maj(a, b, c) — introducen complejidad que hace opaca la relación entre entrada y salida. Después de las 64 rondas, las variables de trabajo se suman de nuevo a los valores iniciales de ese bloque.

Paso 4. Salida final

Después de procesar todos los bloques, las ocho variables de trabajo se concatenan para producir el resumen final de 256 bits. La misma entrada siempre produce la misma salida. Cualquier cambio en la entrada — incluso un solo carácter — produce un hash completamente diferente.

Si SHA-256 no se puede descifrar, ¿cómo lo crackean los hackers?

SHA-256 es matemáticamente sólido. El algoritmo en sí no tiene debilidades prácticas conocidas después de más de dos décadas de criptoanálisis. Lo que falla no es el algoritmo — es la forma en que se almacenan las contraseñas usándolo.

Ataques de fuerza bruta

Un ataque de fuerza bruta no revierte el hash. Adivina. El atacante hashea contraseñas candidatas (palabras de diccionario, patrones comunes, combinaciones de caracteres) y compara la salida con el hash robado. Si los hashes coinciden, la contraseña está encontrada. La velocidad de SHA-256 es el problema aquí: una sola GPU Nvidia RTX 4090 puede calcular aproximadamente 164 mil millones de hashes SHA-256 por segundo (Specops Software, 2025). A ese ritmo, una contraseña de ocho caracteres en minúsculas se crackea en segundos.

Ataques de tablas rainbow

Una tabla rainbow es una base de datos precalculada de mapeos hash-a-texto-plano. En lugar de hashear sobre la marcha, el atacante busca el hash robado en la tabla y lee la contraseña original. Las tablas para formatos de contraseña comunes pueden generarse con anticipación y reutilizarse en múltiples brechas. La resistencia a colisiones — la propiedad de que ninguna entrada debería producir el mismo hash — no es lo que explotan las tablas rainbow. Explotan el hecho de que las contraseñas comunes producen hashes predecibles y repetibles.

Ambos ataques comparten un único prerrequisito: el hash debe estar sin sal. Añada una sal, y ambos ataques se vuelven dramáticamente más costosos.

Por qué SHA-256 simple es malo para el almacenamiento de contraseñas

SHA-256 fue diseñado para ser rápido. Para sus usos previstos — verificar integridad de archivos, firmar certificados, asegurar transacciones blockchain — la velocidad es una característica. Para el almacenamiento de contraseñas, la velocidad es una vulnerabilidad.

El problema: SHA-256 es demasiado rápido

A 164 mil millones de hashes por segundo en hardware de consumo, un atacante puede agotar todo el espacio de contraseñas de ocho caracteres que contienen mayúsculas, minúsculas, dígitos y símbolos en menos de una hora. La guía de almacenamiento de contraseñas de OWASP es explícita: «Los algoritmos de hash rápidos como SHA-256 no son adecuados para el almacenamiento de contraseñas porque permiten a los atacantes realizar grandes cantidades de intentos rápidamente».

Solución 1: Salting

Una sal es una cadena única generada aleatoriamente que se añade a cada contraseña antes del hashing. SHA256("password") siempre produce el mismo hash. SHA256("password" + "x7kQ2mNp") produce uno completamente diferente — y cada usuario obtiene una sal diferente. Esto anula completamente las tablas rainbow: el atacante no puede precalcular hashes para entradas con sal sin conocer la sal de cada usuario. También significa que dos usuarios con la misma contraseña terminan con hashes diferentes en la base de datos.

Solución 2: Estiramiento de claves con PBKDF2

El salting anula las búsquedas precalculadas, pero no ralentiza los ataques de fuerza bruta. Eso requiere estiramiento de claves. PBKDF2 (Password-Based Key Derivation Function 2) aplica una función pseudoaleatoria — típicamente HMAC-SHA-256 — miles de veces en secuencia. Cada iteración toma tiempo. Los 164 mil millones de hashes por segundo del atacante se reducen a una fracción cuando cada «intento» requiere 600.000 iteraciones.

OWASP recomienda PBKDF2 con HMAC-SHA-256 y al menos 600.000 iteraciones para cumplimiento FIPS-140. Argon2id es la opción preferida donde no se requiere cumplimiento FIPS, ya que también añade resistencia de memoria.

SHA-256 simple vs. PBKDF2-HMAC-SHA256: Comparación de seguridad en almacenamiento de contraseñas

¿Es SHA-256 vulnerable a las computadoras cuánticas?

El algoritmo de Grover proporciona a una computadora cuántica una aceleración cuadrática en problemas de búsqueda no estructurada. Aplicado a SHA-256, reduce la seguridad efectiva de 2²⁵⁶ operaciones a 2¹²⁸ operaciones. Eso suena alarmante hasta que se considera la escala: 2¹²⁸ es aproximadamente 3,4×10³⁸. Una computadora cuántica funcionando a 10 mil millones de operaciones por segundo necesitaría aproximadamente 3,4×10²⁸ años para agotar la mitad del espacio de búsqueda — órdenes de magnitud más que la edad del universo.

El algoritmo de Shor, que rompe RSA y la criptografía de curva elíptica factorizando eficientemente números enteros grandes, no se aplica a las funciones hash. La seguridad de SHA-256 no se basa en la factorización de enteros.

El NIST está estandarizando activamente algoritmos post-cuánticos (FIPS 203, 204, 205 fueron finalizados en 2024), principalmente dirigidos a criptografía asimétrica. SHA-256 no está en la lista de reemplazo para el futuro previsible. La amenaza práctica a SHA-256 por la computación cuántica sigue siendo teórica.

Cómo los gestores de contraseñas empresariales usan la criptografía de forma segura

Los gestores de contraseñas empresariales que siguen principios de conocimiento cero aplican los mismos bloques de construcción criptográficos cubiertos en este artículo (SHA-256, PBKDF2, HMAC, AES-256) pero los combinan en una arquitectura por capas donde el servidor nunca tiene datos en texto plano ni las claves para descifrarlos. La garantía de seguridad proviene del diseño, no de confiar en el servidor.

El modelo de cifrado de dos niveles de Passwork

Saber que SHA-256 simple es insuficiente para el almacenamiento de contraseñas es una cosa. Implementar la alternativa correcta en toda una empresa es otra. Aquí es donde la arquitectura de la herramienta importa tanto como el algoritmo.

Passwork está construido sobre una arquitectura de conocimiento cero: el servidor nunca tiene suficiente información para descifrar los datos del usuario. La contraseña maestra nunca abandona el dispositivo del usuario. Todas las claves criptográficas se generan del lado del cliente. El servidor almacena solo datos cifrados y claves cifradas — el descifrado solo es posible en el cliente.

La cadena de cifrado funciona de la siguiente manera, como se documenta en la descripción general de criptografía de Passwork:

1. Contraseña maestra (introducida por el usuario) → PBKDF2 con SHA-256, 300.000 iteraciones
2. Clave maestra (512 bits) → AES-256-CBC
3. Clave privada RSA (2048 bits, RSA-OAEP)
4. Clave de bóveda (256 bits) → AES-256-CBC
5. Clave de registro (256 bits) → AES-256-CBC
6. Datos de registro (contraseñas, secretos, archivos — cifrados en reposo)

En el lado del servidor, una capa separada AES-256-CFB cifra la base de datos de forma independiente. Cada registro está doblemente cifrado: una vez por el cliente antes de que abandone el dispositivo, una vez por el servidor antes de escribirse en disco.

PBKDF2 a 300.000 iteraciones del lado del cliente se alinea con las recomendaciones del NIST (≥310.000 para SHA-256) y supera el mínimo de OWASP para la mayoría de los contextos de implementación. El PBKDF2 del lado del servidor se ejecuta a 600.000 iteraciones — cumpliendo directamente con el umbral FIPS-140.

Esta arquitectura significa que una brecha de base de datos no produce nada utilizable. Un atacante que exfiltra la base de datos obtiene blobs cifrados con AES-256 derivados de claves que nunca se almacenaron en el servidor.

Conclusión

SHA-256 es teóricamente irrompible. El algoritmo ha sobrevivido más de dos décadas de criptoanálisis sin un ataque práctico. Pero el algoritmo solo es tan fuerte como su implementación. Almacene contraseñas como hashes SHA-256 simples, y una sola GPU puede probar miles de millones de candidatos por segundo. Añada una sal y aplique PBKDF2 con suficientes iteraciones, y el mismo hardware se vuelve inútil contra su base de datos.

La brecha entre «SHA-256 es seguro» y «nuestras contraseñas son seguras» se llena con una implementación correcta — salting, estiramiento de claves y una arquitectura de conocimiento cero que asegure que el servidor nunca tenga las claves necesarias para descifrar los datos del usuario.

Si su equipo gestiona credenciales corporativas, Passwork las protege mediante arquitectura de conocimiento cero, cifrado AES-256 del lado del cliente y estiramiento de claves PBKDF2 a 300.000 iteraciones — de modo que un compromiso del servidor no expone nada utilizable. Passwork está disponible tanto como implementación autoalojada para organizaciones que requieren control total de la infraestructura, como solución en la nube para equipos que desean las mismas garantías criptográficas sin gestionar sus propios servidores.

Preguntas frecuentes: SHA-256 explicado

¿Se puede descifrar SHA-256?

No. SHA-256 es una función hash criptográfica unidireccional. No hay clave, no hay algoritmo inverso, y no hay operación matemática que recupere la entrada original de un hash. Lo que los atacantes pueden hacer es adivinar — hasheando contraseñas candidatas y comparando la salida. Eso es cracking, no descifrado, y solo funciona contra hashes débiles o sin sal.

¿Cuál es la diferencia entre el hashing SHA-256 y el cifrado?

El cifrado es reversible con la clave correcta. El hashing no es reversible bajo ninguna circunstancia. SHA-256 toma una entrada de cualquier longitud y produce una salida fija de 256 bits. La misma entrada siempre produce la misma salida, pero el proceso no puede ejecutarse en reversa. El cifrado preserva la capacidad de recuperar los datos originales; el hashing los destruye deliberadamente.

¿Qué es el efecto avalancha en SHA-256?

El efecto avalancha significa que un cambio de un solo bit en la entrada modifica aproximadamente la mitad de los bits de salida. Cambie un carácter en una contraseña, y el hash SHA-256 resultante parece completamente no relacionado con el original. Esta propiedad impide que los atacantes usen conocimiento parcial de una entrada para reducir el espacio de búsqueda del hash.

¿Qué es PBKDF2 y por qué importa para la seguridad de contraseñas?

PBKDF2 (Password-Based Key Derivation Function 2) aplica una función pseudoaleatoria — típicamente HMAC-SHA-256 — iterativamente a una contraseña y sal. Cada iteración añade coste computacional. A 600.000 iteraciones, el tiempo requerido por intento aumenta por un factor de 600.000 comparado con un solo hash SHA-256. Esto hace que los ataques de fuerza bruta contra contraseñas almacenadas correctamente sean impracticables incluso con hardware a escala de GPU.

¿Es SHA-256 vulnerable a ataques de computación cuántica?

No prácticamente. El algoritmo de Grover reduce la seguridad efectiva de SHA-256 de 2²⁵⁶ a 2¹²⁸ operaciones. A 2¹²⁸, incluso una hipotética computadora cuántica funcionando a 10 mil millones de operaciones por segundo requeriría más tiempo que la edad del universo para agotar el espacio de búsqueda. El esfuerzo de estandarización de criptografía post-cuántica del NIST se dirige a algoritmos asimétricos, no a SHA-256.

¿Qué es la construcción Merkle-Damgård?

La construcción Merkle-Damgård es el marco estructural subyacente a SHA-256. El mensaje de entrada se divide en bloques de 512 bits. Cada bloque se procesa a través de una función de compresión que toma el bloque actual y la salida del bloque anterior como entradas. Las salidas se encadenan secuencialmente, de modo que el hash final depende de cada bit de todo el mensaje de entrada.

Employee offboarding: Secure access revocation guide 2026

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

Passwork BlogAlex Muntyan

Secrets rotation lifecycle: From creation to revocation

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

Passwork BlogAlex Muntyan

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

When a database is breached, the first question is always the same: are the hashed passwords safe? The answer depends entirely on how those hashes were generated. SHA-256 itself cannot be decrypted — it is a one-way cryptographic hash function, not an encryption algorithm. But "cannot be decrypted" is not the same as "cannot be cracked."

What is SHA-256

SHA-256 (Secure Hash Algorithm 256-bit) is a cryptographic hash function from the SHA-2 family, developed by the NSA and published by NIST in 2001 under FIPS 180-4. It takes an input of any length and produces a fixed 256-bit (32-byte) output — the hash, or digest. The output always looks random, and the same input always produces the same output.

SHA-256 is not an encryption algorithm. It has no key, and its output cannot be reversed. Its job is to produce a unique fingerprint of a piece of data — not to protect that data for later retrieval.

Three properties define its security:

• Preimage resistance. Given a hash, you cannot find the original input.
• Collision resistance. You cannot find two different inputs that produce the same hash.
• Avalanche effect. A single-bit change in the input flips roughly half the output bits, making the result completely unpredictable.

SHA-256 is used in TLS certificates, code signing, Git commit integrity, Bitcoin's proof-of-work mechanism, and (when combined with proper key derivation) password storage. It is one of the most widely deployed cryptographic primitives in production systems today.

Hashing vs. encryption: Why SHA-256 cannot be decrypted

SHA-256 is a cryptographic hash function — a one-way transformation. Encryption is a two-way operation: you encrypt data with a key, and you decrypt it with a key. Hashing has no key and no reverse path. Given a SHA-256 digest, there is no mathematical operation that recovers the original input.

The property that makes this possible is called preimage resistance: it must be computationally infeasible to find any input m such that SHA256(m) = h for a given hash h. A related property, the avalanche effect, means that changing a single bit in the input flips roughly half of the output bits — making it impossible to "work backwards" by making small adjustments.

The distinction matters in practice. If a developer stores passwords using AES encryption rather than hashing, a breach of the encryption key exposes every password in the database. A hash has no key to steal.

How the SHA-256 algorithm works (step-by-step)

SHA-256 is defined in NIST FIPS 180-4 and belongs to the SHA-2 family. It processes input of any length and produces a deterministic 256-bit output. The core structure is the Merkle-Damgård construction: the message is split into fixed-size blocks, each block is processed through a compression function, and the outputs are chained together.

Step 1. Preprocessing and padding

The input message is padded so its total length is a multiple of 512 bits. Padding always begins with a 1 bit, followed by enough 0 bits, followed by a 64-bit representation of the original message length. This step is mandatory even if the message already fits neatly — the algorithm must always know where the message ends.

Step 2. Message scheduling

The padded message is parsed into 512-bit blocks. Each block is divided into sixteen 32-bit words. Those sixteen words are then expanded into a 64-word message schedule using a mix of bitwise rotations and XOR operations. This expansion ensures that every bit of the original input influences the compression step.

Step 3. The compression function

This is where the work happens. SHA-256 maintains eight 32-bit working variables (a through h), initialized to constants derived from the fractional parts of the square roots of the first eight prime numbers. Over 64 rounds, these variables are updated using bitwise AND, OR, XOR, and NOT operations, plus modular addition. Two non-linear functions — Ch(e, f, g) and Maj(a, b, c) — introduce complexity that makes the relationship between input and output opaque. After all 64 rounds, the working variables are added back to the initial values for that block.

Step 4. Final output

After all blocks are processed, the eight working variables are concatenated to produce the final 256-bit digest. The same input always produces the same output. Any change to the input — even a single character — produces a completely different hash.

If SHA-256 can't be decrypted, how do hackers crack it?

SHA-256 is mathematically sound. The algorithm itself has no known practical weaknesses after more than two decades of cryptanalysis. What fails is not the algorithm — it is the way passwords are stored using it.

Brute-force attacks

A brute-force attack does not reverse the hash. It guesses. The attacker hashes candidate passwords (dictionary words, common patterns, character combinations) and compares the output against the stolen hash. If the hashes match, the password is found. The speed of SHA-256 is the problem here: a single Nvidia RTX 4090 GPU can calculate approximately 164 billion SHA-256 hashes per second (Specops Software, 2025). At that rate, an eight-character lowercase password is cracked in seconds.

Rainbow table attacks

A rainbow table is a precomputed database of hash-to-plaintext mappings. Rather than hashing on the fly, the attacker looks up the stolen hash in the table and reads off the original password. Tables for common password formats can be generated in advance and reused across multiple breaches. Collision resistance — the property that no two inputs should produce the same hash — is not what rainbow tables exploit. They exploit the fact that common passwords produce predictable, repeatable hashes.

Both attacks share a single prerequisite: the hash must be unsalted. Add a salt, and both attacks become dramatically more expensive.

Why plain SHA-256 is bad for password storage

SHA-256 was designed to be fast. For its intended uses — verifying file integrity, signing certificates, securing blockchain transactions — speed is a feature. For password storage, speed is a liability.

The problem: SHA-256 is too fast

At 164 billion hashes per second on consumer hardware, an attacker can exhaust the entire space of eight-character passwords containing uppercase, lowercase, digits, and symbols in under an hour. OWASP's Password Storage Cheat Sheet is explicit: "Fast hashing algorithms such as SHA-256 are not suitable for password storage because they allow attackers to perform large numbers of guesses quickly."

Solution 1: Salting

A salt is a unique, randomly generated string appended to each password before hashing. SHA256("password") always produces the same hash. SHA256("password" + "x7kQ2mNp") produces a completely different one — and every user gets a different salt. This defeats rainbow tables entirely: the attacker cannot precompute hashes for salted inputs without knowing each user's salt. It also means two users with the same password end up with different hashes in the database.

Solution 2: Key stretching with PBKDF2

Salting defeats precomputed lookups, but it does not slow down brute-force attacks. That requires key stretching. PBKDF2 (Password-Based Key Derivation Function 2) applies a pseudorandom function — typically HMAC-SHA-256 — thousands of times in sequence. Each iteration takes time. The attacker's 164 billion hashes per second drops to a fraction of that when each "guess" requires 600,000 iterations.

OWASP recommends PBKDF2 with HMAC-SHA-256 and at least 600,000 iterations for FIPS-140 compliance. Argon2id is the preferred choice where FIPS compliance is not required, as it also adds memory hardness.

Plain SHA-256 vs. PBKDF2-HMAC-SHA256: password storage security comparison

Is SHA-256 vulnerable to quantum computers?

Grover's algorithm gives a quantum computer a quadratic speedup on unstructured search problems. Applied to SHA-256, it reduces the effective security from 2²⁵⁶ operations to 2¹²⁸ operations. That sounds alarming until you consider the scale: 2¹²⁸ is approximately 3.4×10³⁸. A quantum computer running at 10 billion operations per second would need roughly 3.4×10²⁸ years to exhaust half the search space — orders of magnitude longer than the age of the universe.

Shor's algorithm, which breaks RSA and elliptic-curve cryptography by factoring large integers efficiently, does not apply to hash functions. SHA-256's security is not based on integer factorization.

NIST is actively standardizing post-quantum algorithms (FIPS 203, 204, 205 were finalized in 2024), primarily targeting asymmetric cryptography. SHA-256 is not on the replacement list for the foreseeable future. The practical threat to SHA-256 from quantum computing remains theoretical.

How enterprise password managers use cryptography securely

Enterprise password managers that follow zero-knowledge principles apply the same cryptographic building blocks covered in this article (SHA-256, PBKDF2, HMAC, AES-256) but combine them into a layered architecture where the server never holds plaintext data or the keys to decrypt it. The security guarantee comes from the design, not from trusting the server.

The Passwork two-level encryption model

Knowing that plain SHA-256 is insufficient for password storage is one thing. Implementing the correct alternative across an enterprise is another. This is where the architecture of the tool matters as much as the algorithm.

Passwork is built on a zero-knowledge architecture: the server never holds enough information to decrypt user data. The master password never leaves the user's device. All cryptographic keys are generated client-side. The server stores only encrypted data and encrypted keys — decryption is only possible on the client.

The encryption chain works as follows, as documented in Passwork's cryptography overview:

1. Master password (entered by the user) → PBKDF2 with SHA-256, 300,000 iterations
2. Master key (512 bits) → AES-256-CBC
3. Private RSA key (2048 bits, RSA-OAEP)
4. Vault key (256 bits) → AES-256-CBC
5. Record key (256 bits) → AES-256-CBC
6. Record data (passwords, secrets, files — encrypted at rest)

On the server side, a separate AES-256-CFB layer encrypts the database independently. Every record is double-encrypted: once by the client before it leaves the device, once by the server before it is written to disk.

PBKDF2 at 300,000 client-side iterations aligns with NIST's recommendations (≥310,000 for SHA-256) and exceeds the OWASP minimum for most deployment contexts. The server-side PBKDF2 runs at 600,000 iterations — meeting the FIPS-140 threshold directly.

This architecture means that a database breach yields nothing actionable. An attacker who exfiltrates the database gets AES-256-encrypted blobs derived from keys that were never stored on the server.

Conclusion

SHA-256 is theoretically unbreakable. The algorithm has survived over two decades of cryptanalysis without a practical attack. But the algorithm is only as strong as its implementation. Store passwords as plain SHA-256 hashes, and a single GPU can test billions of candidates per second. Add a salt and apply PBKDF2 with sufficient iterations, and the same hardware becomes useless against your database.

The gap between "SHA-256 is secure" and "our passwords are secure" is filled by correct implementation — salting, key stretching, and a zero-knowledge architecture that ensures the server never holds the keys needed to decrypt user data.

If your team manages corporate credentials, Passwork protects them through zero-knowledge architecture, client-side AES-256 encryption, and PBKDF2 key stretching at 300,000 iterations — so a server compromise exposes nothing actionable. Passwork is available both as a self-hosted deployment for organizations that require full infrastructure control, and as a cloud solution for teams that want the same cryptographic guarantees without managing their own servers.

FAQ: SHA-256 explained

Can you decrypt SHA-256?

No. SHA-256 is a one-way cryptographic hash function. There is no key, no reverse algorithm, and no mathematical operation that recovers the original input from a hash. What attackers can do is guess — by hashing candidate passwords and comparing the output. That is cracking, not decryption, and it only works against weak or unsalted hashes.

What is the difference between SHA-256 hashing and encryption?

Encryption is reversible with the correct key. Hashing is not reversible under any circumstances. SHA-256 takes an input of any length and produces a fixed 256-bit output. The same input always produces the same output, but the process cannot be run in reverse. Encryption preserves the ability to recover the original data; hashing deliberately destroys it.

What is the avalanche effect in SHA-256?

The avalanche effect means that a single-bit change in the input flips approximately half of the output bits. Change one character in a password, and the resulting SHA-256 hash looks completely unrelated to the original. This property prevents attackers from using partial knowledge of an input to narrow down the hash search space.

What is PBKDF2 and why does it matter for password security?

PBKDF2 (Password-Based Key Derivation Function 2) applies a pseudorandom function — typically HMAC-SHA-256 — iteratively to a password and salt. Each iteration adds computational cost. At 600,000 iterations, the time required per guess increases by a factor of 600,000 compared to a single SHA-256 hash. This makes brute-force attacks against properly stored passwords impractical even with GPU-scale hardware.

Is SHA-256 vulnerable to quantum computing attacks?

Not practically. Grover's algorithm reduces SHA-256's effective security from 2²⁵⁶ to 2¹²⁸ operations. At 2¹²⁸, even a hypothetical quantum computer running at 10 billion operations per second would require more time than the age of the universe to exhaust the search space. NIST's post-quantum cryptography standardization effort targets asymmetric algorithms, not SHA-256.

What is the Merkle-Damgård construction?

The Merkle-Damgård construction is the structural framework underlying SHA-256. The input message is divided into 512-bit blocks. Each block is processed through a compression function that takes the current block and the output of the previous block as inputs. The outputs are chained sequentially, so the final hash depends on every bit of the entire input message.

Employee offboarding: Secure access revocation guide 2026

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

Passwork BlogAlex Muntyan

Secrets rotation lifecycle: From creation to revocation

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

Passwork BlogAlex Muntyan

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

AES-256-Verschlüsselung ist eine symmetrische Blockchiffre, die einen 256-Bit-Schlüssel verwendet, um Daten in 14 Transformationsrunden zu verschlüsseln. Kein klassischer oder Quantencomputer kann sie innerhalb eines praktisch relevanten Zeitrahmens per Brute-Force knacken. Dennoch erleiden Organisationen, die AES-256 verwenden, weiterhin katastrophale Datenschutzverletzungen — weil Angreifer selten versuchen, die Chiffre zu brechen. Sie brechen die Systeme drumherum.

Diese Unterscheidung ist 2026 wichtiger denn je. KI-gesteuerte Angriffe beschleunigen den Diebstahl von Anmeldedaten und die Kompromittierung von Endpunkten. Die „Harvest Now, Decrypt Later"-Strategie bedeutet, dass Gegner heute verschlüsselte Daten horten und auf zukünftige Entschlüsselungsfähigkeiten setzen. Und NIST hat seine ersten Post-Quanten-Kryptografiestandards finalisiert, was berechtigte Fragen aufwirft, ob AES-256 noch in Ihre Sicherheitsarchitektur gehört.

Die kurze Antwort: ja. Die längere Antwort erfordert ein genaues Verständnis dessen, wovor AES-256 schützt, wovor nicht, und wie man es so einsetzt, dass die theoretische Stärke des Algorithmus in tatsächliche Sicherheit übersetzt wird.

Wichtigste Erkenntnisse

• AES-256 hat keine praktische Schwachstelle. Kein klassischer oder Quantencomputer kann einen 256-Bit-Schlüssel innerhalb eines machbaren Zeitrahmens per Brute-Force knacken. Der Algorithmus selbst ist nicht das Risiko.
• Grovers Algorithmus halbiert die Sicherheit von AES-256, eliminiert sie aber nicht. Ein Quanten-Angreifer reduziert die effektive Sicherheit auf 128 Bit — immer noch unknackbar durch jede bekannte oder prognostizierte Hardware.
• Die eigentliche Bedrohung ist Harvest Now, Decrypt Later (HNDL), nicht der Q-Day. Gegner archivieren heute verschlüsselte Daten. Die Migration des asymmetrischen Schlüsselaustauschs zu Post-Quanten-Algorithmen ist eine gegenwärtige Priorität, keine zukünftige.
• AES-256-GCM ist der richtige Modus für neue Implementierungen. CBC bietet nur Vertraulichkeit. GCM fügt integrierte Authentifizierung hinzu und ist in TLS 1.3 obligatorisch.
• 62 % der Datenschutzverletzungen betreffen den menschlichen Faktor. Angreifer umgehen die Verschlüsselung durch gestohlene Anmeldedaten, kompromittierte Endpunkte und schlechtes Schlüsselmanagement — nicht durch das Brechen der Chiffre.
• Schlüsselmanagement ist das schwächste Glied. Hardcodierte Schlüssel, Schlüssel, die neben den zu schützenden Daten gespeichert werden, und Schlüssel, die nie rotiert werden, sind gefährlicher als jeder bekannte kryptoanalytische Angriff.
• Zero-Knowledge-Architektur eliminiert das serverseitige Risiko. Wenn der Server niemals Klartext oder Entschlüsselungsschlüssel besitzt, liefert eine vollständige Serverkompromittierung nur nutzlosen Chiffretext.
• AES-256 erfüllt HIPAA, DSGVO und PCI DSS. Compliance erfordert eine korrekte Implementierung — Verschlüsselung im Ruhezustand, während der Übertragung und dokumentiertes Schlüsselmanagement — nicht nur das Vorhandensein des Algorithmus.

Was ist AES-256?

AES-256 (Advanced Encryption Standard mit einem 256-Bit-Schlüssel) ist eine symmetrische Blockchiffre, die in NIST FIPS 197 standardisiert ist. Sie verschlüsselt Daten in 128-Bit-Blöcken unter Verwendung eines 256-Bit-Schlüssels über 14 Transformationsrunden. Derselbe Schlüssel verschlüsselt und entschlüsselt die Daten. Kein bekannter klassischer oder Quantenangriff kann sie innerhalb eines praktisch relevanten Zeitrahmens brechen.

AES-256 ist der Verschlüsselungsstandard, der in der gesamten US-Bundesregierung (einschließlich NSA-klassifizierter Systeme), TLS 1.3, bei der Festplattenverschlüsselung auf allen großen Betriebssystemen und bei Enterprise-Credential-Management-Tools verwendet wird. Wenn ein Anbieter sagt, sein Produkt verwende „Verschlüsselung auf Militärniveau", meint er fast immer AES-256.

Woher der Name stammt

Der AES-Teil bezieht sich auf den Algorithmus selbst — ein Substitutions-Permutations-Netzwerk, das von Joan Daemen und Vincent Rijmen entworfen wurde (ursprünglich Rijndael genannt) und 2001 von NIST nach einem fünfjährigen öffentlichen Wettbewerb ausgewählt wurde. Die „256" bezieht sich auf die Schlüssellänge in Bit. AES gibt es auch in 128-Bit- und 192-Bit-Varianten; die 256-Bit-Version verwendet 14 Transformationsrunden statt 10 (AES-128) oder 12 (AES-192). Mehr Runden bedeuten eine größere Sicherheitsmarge.

Was der 256-Bit-Schlüssel tatsächlich bedeutet

Ein 256-Bit-Schlüssel hat 2²⁵⁶ mögliche Werte — ungefähr 1,16×10⁷⁷. Um das physisch einzuordnen: Wenn jedes Atom im beobachtbaren Universum ein Computer wäre, der eine Milliarde Milliarden Schlüsselversuche pro Sekunde durchführt, würde das Durchprobieren des AES-256-Schlüsselraums immer noch um viele Größenordnungen länger dauern als das Alter des Universums. Deshalb beschreiben Kryptografen AES-256 als praktisch nicht durch Brute-Force angreifbar.

Die Schlüssellänge bestimmt auch die Quantenresistenz. Grovers Algorithmus — der bekannteste Quantenangriff auf symmetrische Chiffren — bietet eine quadratische Beschleunigung, die die Schlüssellänge effektiv halbiert. Gegen AES-256 reduziert diese Reduzierung die effektive Sicherheit auf 128 Bit. AES-128-Sicherheit ist selbst durch keine bekannte oder prognostizierte Hardware zu brechen. Die eigene Post-Quanten-Kryptografie-Dokumentation des NIST bestätigt, dass AES-256 gegen Quanten-Angreifer sicher bleibt.

AES-256 vs. AES-128: Ist der Unterschied bedeutsam?

Für die meisten Enterprise-Anwendungsfälle sind beide rechnerisch unknackbar. Die praktischen Gründe, AES-256 zu bevorzugen, sind:

• Regulatorische Anforderungen. NSAs CNSA 2.0 (2022, aktualisiert 2025) schreibt AES-256 für alle National Security Systems auf allen Klassifizierungsstufen vor. PCI DSS akzeptiert AES-128 als Minimum, aber AES-256 als empfohlenen Standard.
• Quantenmarge. AES-256 behält nach Grover 128-Bit-Sicherheit; AES-128 fällt auf 64 Bit, was sich der Machbarkeit für einen ausreichend fortgeschrittenen Quanten-Angreifer nähert.
• Langlebige Daten. Wenn die Daten, die Sie heute verschlüsseln, 20+ Jahre vertraulich bleiben müssen, ist AES-256 die konservative Wahl.

Der Leistungsunterschied zwischen AES-128 und AES-256 ist auf moderner Hardware mit AES-NI-Beschleunigung vernachlässigbar — typischerweise unter 20 % Durchsatzunterschied. Es gibt keinen praktischen Grund, AES-128 für neue Implementierungen zu wählen.

Wie AES-256 in eine breitere Sicherheitsarchitektur passt

AES-256 ist eine symmetrische Chiffre. Sie verarbeitet Massendatenverschlüsselung effizient, erfordert jedoch, dass beide Parteien denselben geheimen Schlüssel teilen — was ein Schlüsselverteilungsproblem schafft. In der Praxis wird asymmetrische Kryptografie (RSA, ECC oder Post-Quanten-Algorithmen wie ML-KEM aus FIPS 203) verwendet, um den AES-Schlüssel sicher auszutauschen, wonach AES-256 die eigentlichen Daten verarbeitet. Genau so funktioniert TLS 1.3: asymmetrischer Handshake, symmetrische Datenübertragung.

Die Chiffre ist nur so stark wie das System drumherum. AES-256 schützt Daten im Ruhezustand und während der Übertragung. Es schützt nicht gegen einen gestohlenen Schlüssel, einen kompromittierten Endpunkt oder einen autorisierten Benutzer mit böswilliger Absicht. Das ist keine Schwäche des Algorithmus — es ist die Grenze dessen, was jede Chiffre leisten kann.

Wie AES-256 funktioniert: Die Mathematik hinter der Chiffre

Die Chiffre verarbeitet Daten in festen 128-Bit-Blöcken. Jeder Block durchläuft 14 sequenzielle Transformationsrunden — mehr Runden als AES-128 (10) oder AES-192 (12). Jede Runde wendet vier Operationen an: Substitution, Zeilenverschiebung, Spaltenmischung und Schlüsseladdition. Das Kippen eines einzelnen Eingabebits ändert bis zum Ende der ersten Runde etwa die Hälfte der Ausgabebits.

Die 14 Transformationsrunden

AES-256 wendet 14 Runden von vier Operationen auf jeden 128-Bit-Datenblock an. Jede Runde besteht aus:

1. SubBytes — jedes Byte wird über eine feste Substitutionstabelle (S-Box) ersetzt, was Nichtlinearität einführt
2. ShiftRows — Zeilen der 4×4-Zustandsmatrix werden zyklisch verschoben, was Diffusion bewirkt
3. MixColumns — Spalten werden in einem Galois-Feld multipliziert, was die Daten weiter über Bytes hinweg mischt
4. AddRoundKey — der Rundenschlüssel (abgeleitet vom ursprünglichen 256-Bit-Schlüssel über Schlüsselexpansion) wird mit dem Zustand XOR-verknüpft

Die letzte Runde lässt MixColumns aus. Dieses Substitutions-Permutations-Netzwerk (SPN)-Design bedeutet, dass das Kippen eines einzelnen Eingabebits etwa die Hälfte der Ausgabebits ändert — der Lawineneffekt. Nach 14 Runden ist die Beziehung zwischen Klartext und Chiffretext ohne den Schlüssel rechnerisch nicht umkehrbar.

AES-GCM vs. AES-CBC: Warum der Modus genauso wichtig ist wie die Schlüssellänge

Die Chiffre selbst ist nur ein Teil der Geschichte. Wie Sie sie verwenden — der Betriebsmodus — bestimmt, ob Ihre Implementierung tatsächlich sicher ist.

AES-256-GCM ist ein Authenticated Encryption with Associated Data (AEAD)-Modus. Er verschlüsselt gleichzeitig die Daten und erzeugt einen Message Authentication Code (MAC), der sowohl Vertraulichkeit als auch Integrität in einer einzigen Operation garantiert. Wenn ein Angreifer den Chiffretext manipuliert, schlägt die Entschlüsselung fehl — der MAC wird nicht verifiziert.

AES-256-CBC bietet nur Vertraulichkeit. Ohne einen separaten MAC (zum Beispiel über HMAC-SHA256) ist eine CBC-verschlüsselte Nachricht anfällig für Padding-Oracle-Angriffe und Bit-Flipping. CBC erfordert auch sequenzielle Verarbeitung, was die Leistung auf moderner Multi-Core-Hardware einschränkt.

Für neue Implementierungen im Jahr 2026 ist AES-256-GCM die richtige Wahl. TLS 1.3 hat CBC-Cipher-Suites aus genau diesem Grund vollständig entfernt. Der einzige praktische Vorbehalt: GCM ist katastrophal gebrochen, wenn eine Nonce (Initialisierungsvektor) mit demselben Schlüssel wiederverwendet wird. Ihre Implementierung muss Nonce-Eindeutigkeit garantieren — typischerweise über einen kryptografisch sicheren Zufallszahlengenerator oder einen Zähler.

Quantencomputing und AES-256: Risiko von Rauschen trennen

Die Quantencomputer-Bedrohung für Verschlüsselung ist real, aber sie ist nicht einheitlich. Zu verstehen, welche Algorithmen verwundbar sind und in welchem Maße, ist essenziell für fundierte architektonische Entscheidungen heute.

Quantencomputer bedrohen asymmetrische Kryptografie (RSA, ECC, Diffie-Hellman) durch Shors Algorithmus, der große Zahlen faktorisieren und diskrete Logarithmusprobleme in polynomieller Zeit lösen kann. Ein ausreichend leistungsfähiger Quantencomputer, der Shors Algorithmus ausführt, würde RSA-2048 vollständig brechen. Dies ist die echte Krise, die die Post-Quanten-Kryptografie (PQC)-Standardisierungsarbeit des NIST antreibt, die FIPS 203, 204 und 205 im Jahr 2024 finalisiert hat.

Symmetrische Verschlüsselung steht einem anderen Algorithmus und einer anderen Bedrohungsstufe gegenüber.

Was Grovers Algorithmus tatsächlich mit AES-256 macht

Grovers Algorithmus ist die Quantenbedrohung für symmetrische Verschlüsselung. Er bietet eine quadratische Beschleunigung für unstrukturierte Suchprobleme: Wo ein klassischer Computer N Operationen benötigt, um einen Schlüsselraum zu durchsuchen, benötigt ein Quantencomputer mit Grovers Algorithmus ungefähr die Quadratwurzel von N. Auf AES-256 angewendet, halbiert dies effektiv die Schlüssellänge aus Sicherheitsperspektive — ein 256-Bit-Schlüssel bietet gegen einen Quanten-Angreifer etwa 128 Bit Sicherheit.

128-Bit-Sicherheit ist immer noch unknackbar. Konkret ausgedrückt: Ein klassischer Angriff auf AES-128 erfordert etwa 2¹²⁸ Operationen. Selbst wenn Sie eine Milliarde Milliarden (10¹⁸) Operationen pro Sekunde durchführen könnten, würde das Durchprobieren dieses Schlüsselraums länger dauern als das Alter des Universums. Grovers Algorithmus reduziert AES-256 auf dieses Niveau — er bricht es nicht. Die PQC-FAQ des NIST bestätigt ausdrücklich, dass AES mit 128-, 192- oder 256-Bit-Schlüsseln gegen Quantenangriffe sicher ist.

Die CNSA 2.0-Empfehlung der NSA (2022, aktualisiert 2025) schreibt AES-256 für alle National Security Systems auf allen Klassifizierungsstufen, einschließlich Top Secret, mit einer Übergangsfrist bis 2035 vor. Die Tatsache, dass die NSA AES-256 nicht ersetzt (nur die asymmetrischen Algorithmen), ist das klarste mögliche Signal über seine Quantenresistenz.

Harvest Now, Decrypt Later (HNDL): Die Bedrohung, die heute existiert

Der Q-Day (der Zeitpunkt, an dem ein kryptoanalytisch relevanter Quantencomputer existiert) wird von den meisten Forschern auf 10–20 Jahre geschätzt, obwohl die Zeitpläne wirklich unsicher sind. Die unmittelbarere Bedrohung ist HNDL: Nationalstaatliche Akteure und ausgeklügelte kriminelle Gruppen fangen heute verschlüsselten Datenverkehr ab und archivieren ihn, mit der Absicht, ihn zu entschlüsseln, sobald Quantenhardware ausgereift ist.

Für Daten mit einem langen Sensibilitätshorizont — klassifizierte Regierungskommunikation, geistiges Eigentum, Krankenakten, langfristige Finanzdaten — ist HNDL ein gegenwärtiges operatives Risiko, kein zukünftiges Hypothetisches. Die Reaktion besteht darin, asymmetrische Schlüsselaustauschprotokolle jetzt auf Post-Quanten-Algorithmen zu migrieren, während AES-256 weiterhin für symmetrische Verschlüsselung verwendet wird.

Wenn AES-256 unknackbar ist, warum passieren dann immer noch Datenschutzverletzungen?

AES-256-Verschlüsselung ist mathematisch solide. Die Verletzungen passieren überall sonst. Der 2026 Data Breach Investigations Report von Verizon stellte fest, dass der menschliche Faktor bei 62 % der Verletzungen präsent war — gestohlene Anmeldedaten, Privilegienmissbrauch, Social Engineering. Angreifer brechen nicht die Chiffre. Sie stehlen den Schlüssel, kompromittieren den Endpunkt oder nutzen die Person aus, die das Passwort hält.

Der 2026 DBIR markiert auch einen strukturellen Wandel: Zum ersten Mal in den 19 Jahren der Berichtsveröffentlichung hat die Ausnutzung von Schwachstellen gestohlene Anmeldedaten als Top-Erstzugriffsvektor überholt und macht 31 % aller Verletzungen aus, gegenüber 20 % im Vorjahr. KI beschleunigt dies — Bedrohungsakteure nutzen sie jetzt, um das Fenster zwischen Schwachstellenoffenlegung und aktiver Ausnutzung von Monaten auf Stunden zu verkürzen.

Der 2025 Cost of a Data Breach Report von IBM beziffert die finanziellen Auswirkungen dieser Versäumnisse auf durchschnittlich 4,44 Millionen Dollar pro Vorfall. Organisationen mit hohem Niveau an Shadow AI (Mitarbeiter, die nicht genehmigte KI-Tools auf Firmengeräten nutzen) zahlten zusätzliche 670.000 Dollar pro Verletzung. Der 2026 DBIR fügt Kontext hinzu: Shadow AI ist jetzt die dritthäufigste nicht-böswillige Insider-Datenleckage-Aktivität, wobei die regelmäßige KI-Tool-Nutzung unter Mitarbeitern innerhalb eines Jahres von 15 % auf 45 % gestiegen ist.

Diese Zahlen rahmen das eigentliche Problem: Verschlüsselung schützt Daten im Ruhezustand und während der Übertragung, aber sie kann nicht gegen einen autorisierten Benutzer schützen, der etwas Unautorisiertes tut, eine Schwachstelle, die acht Monate lang ungepatcht bleibt, oder einen Endpunkt, der bereits kompromittiert ist.

Die sechs Lücken, die Verschlüsselung umgehen

Hier ist ein strukturierter Ansatz, um zu verstehen, wo AES-256 in der Praxis versagt — nicht weil der Algorithmus schwach ist, sondern weil die umgebende Architektur es ist.

Das „Verschlüsselung ist nicht genug"-Lückenmodell:

1. Schlüsselmanagement-Versäumnisse. Hardcodierte Verschlüsselungsschlüssel im Quellcode, Schlüssel, die neben den zu schützenden Daten gespeichert werden, Schlüssel, die nie rotiert werden. Wenn der Schlüssel kompromittiert ist, ist die Verschlüsselung wertlos. Hardware Security Modules (HSMs) und Schlüsselableitungsfunktionen wie PBKDF2 existieren genau, um dies zu adressieren. Passwork beispielsweise leitet seinen Masterschlüssel vom Masterpasswort des Benutzers über PBKDF2 mit 300.000 Iterationen und SHA-256 ab — was Brute-Force des Masterpassworts selbst bei extrahierter verschlüsselter Datenbank rechenintensiv macht.
2. Kompromittierte Endpunkte. Malware, die auf einem Endpunkt läuft, liest Daten nach der Entschlüsselung, im RAM. Die Daten waren im Ruhezustand verschlüsselt, wurden zur Nutzung entschlüsselt, die Malware erfasste sie im Klartext. AES-256 bietet hier null Schutz. Deshalb sind Endpoint Detection and Response (EDR) und Privileged Access Workstations (PAWs) keine optionalen Schichten.
3. Insider-Bedrohungen. Autorisierte Benutzer mit legitimem Entschlüsselungszugang können Daten exfiltrieren. Verschlüsselung unterscheidet nicht zwischen einem legitimen Administrator und einem böswilligen. Rollenbasierte Zugriffskontrolle (RBAC), Least-Privilege-Prinzipien und Audit-Protokollierung sind die Kontrollen, die diese Lücke adressieren.
4. Schlechte Zugriffskontrolle. Geteilte Anmeldedaten, zu breite Berechtigungen und veraltete Konten, die nach dem Ausscheiden von Mitarbeitern aktiv bleiben, schaffen Exposition, die Verschlüsselung nicht mindern kann.
5. Metadaten-Exposition. Selbst wenn Inhalte verschlüsselt sind, können Metadaten (wer mit wem kommuniziert hat, wann, wie oft, Dateigrößen, Zugriffsmuster) sensible Informationen offenbaren. Verschlüsselung schützt die Nutzlast, nicht den Umschlag.
6. Kontrollverlust nach dem Teilen. Sobald eine verschlüsselte Datei geteilt und vom Empfänger entschlüsselt wurde, haben Sie keine Kontrolle mehr darüber, was als nächstes passiert. Digital Rights Management (DRM) und Zero-Trust-Dateifreigabe-Architekturen adressieren dies teilweise, aber keine Lösung ist vollständig.

Bekannte kryptoanalytische Angriffe auf AES-256 — und warum sie in der Praxis keine Rolle spielen

Der Vollständigkeit halber: Die bekanntesten Angriffe gegen vollständiges AES-256 sind der Biclique-Angriff (Rechenkomplexität von etwa 2²⁵⁴⋅⁴, knapp unter der Brute-Force-Grenze von 2²⁵⁶) und Related-Key-Angriffe (Komplexität um 2⁹⁹⋅⁵ unter hochspezifischen Bedingungen).

Keiner ist praktisch relevant. Der Biclique-Angriff erfordert mehr Rechenleistung als physisch machbar ist. Related-Key-Angriffe erfordern, dass der Angreifer die Beziehung zwischen mehreren Schlüsseln kontrolliert — eine Bedingung, die in keinem richtig konzipierten System existiert. Seitenkanalangriffe (Leistungsanalyse, Timing-Angriffe, Cache-Timing) sind ein echtes Problem, aber sie zielen auf die Implementierung, nicht auf den Algorithmus. Constant-Time-Implementierungen und Hardware-AES-Beschleunigung (AES-NI) mindern die meisten davon.

Enterprise-Best-Practices für AES-256 im Jahr 2026

AES-256 im Jahr 2026 korrekt einzusetzen bedeutet, in drei Ebenen zu denken: Daten im Ruhezustand, Daten während der Übertragung und Daten in Nutzung. Die meisten Organisationen haben die ersten beiden teilweise abgedeckt. Die dritte ist der Bereich, in dem die nächste Generation von Verletzungen auftreten wird.

Daten im Ruhezustand

Verwenden Sie AES-256-GCM für neue Implementierungen. Stellen Sie sicher, dass Schlüssel getrennt von den zu schützenden Daten verwaltet werden — idealerweise in einem HSM oder einem dedizierten Key-Management-Service. Rotieren Sie Schlüssel nach einem definierten Zeitplan und sofort bei Verdacht auf Kompromittierung. Verwenden Sie PBKDF2, bcrypt oder Argon2, um Verschlüsselungsschlüssel aus Passwörtern abzuleiten. Verwenden Sie niemals das Passwort direkt als Schlüssel.

Festplattenverschlüsselung (BitLocker unter Windows, FileVault unter macOS) bietet eine Baseline für Endpunktschutz, schützt aber nur gegen physischen Diebstahl eines ausgeschalteten Geräts. Sie schützt nicht gegen einen angemeldeten Benutzer oder einen laufenden Malware-Prozess.

Daten während der Übertragung

TLS 1.3 ist der aktuelle Standard. Es schreibt AEAD-Cipher-Suites vor (AES-256-GCM oder ChaCha20-Poly1305), entfernt schwache Cipher-Suites aus TLS 1.2 und bietet standardmäßig Forward Secrecy. Wenn Ihre Infrastruktur noch TLS 1.2 mit CBC-Cipher-Suites unterstützt, ist das eine Konfigurationsschuld, die es jetzt zu beheben gilt.

Daten in Nutzung — das ungelöste Problem

Daten in Nutzung sind Klartext im Speicher während der Verarbeitung. Confidential-Computing-Frameworks — Intel SGX (Software Guard Extensions) und AMD SEV (Secure Encrypted Virtualization) — schaffen hardware-isolierte Ausführungsumgebungen (Trusted Execution Environments oder TEEs), in denen selbst der Hypervisor oder das Betriebssystem die verarbeiteten Daten nicht lesen können. Dies ist die Frontier der Verschlüsselungsarchitektur und wird zunehmend relevant für Cloud-Workloads, die sensible Daten verarbeiten.

Zero-Knowledge-Architektur

Eine Zero-Knowledge-Architektur bedeutet, dass der Dienstanbieter (oder Server) niemals Zugriff auf Klartextdaten oder die Schlüssel zu deren Entschlüsselung hat. Client-seitige Verschlüsselung ist der Mechanismus: Daten werden auf dem Client vor der Übertragung verschlüsselt, und der Server speichert nur Chiffretext. Der Client-seitige Verschlüsselungsmodus von Passwork implementiert dies — der Masterschlüssel wird vom Masterpasswort des Benutzers abgeleitet und nie an den Server übertragen, was bedeutet, dass selbst eine vollständige Serverkompromittierung nur verschlüsselte Daten liefert.

Compliance-Anforderungen

AES-256 ist nicht nur eine technische Best Practice — es ist eine Compliance-Anforderung in mehreren Frameworks:

• HIPAA Safe Harbor (45 CFR §164.312(a)(2)(iv)) bezeichnet AES-256 als gültige Verschlüsselungsmethode für geschützte Gesundheitsinformationen (PHI), wodurch verletzte Daten als „nicht nutzbar, unlesbar oder unentschlüsselbar" gelten.
• DSGVO Artikel 32 verlangt „geeignete technische Maßnahmen" einschließlich Verschlüsselung zum Schutz personenbezogener Daten. AES-256 ist der De-facto-Standard zur Erfüllung dieser Anforderung.
• PCI DSS Anforderung 3 schreibt starke Kryptografie für gespeicherte Karteninhaberdaten vor. AES-256 erfüllt diese Anforderung; AES-128 ist das Minimum.
• NSA CNSA 2.0 schreibt AES-256 (nicht AES-128) für alle National Security Systems auf allen Klassifizierungsstufen vor.

Fazit

AES-256 bleibt 2026 das richtige Fundament für Datenverschlüsselung. Der Algorithmus hat keine praktische Schwachstelle (klassisch oder quantenbasiert) und diese Position wird sich innerhalb jedes für Ihre Organisation heute relevanten Planungshorizonts wahrscheinlich nicht ändern.

Die härtere Wahrheit ist, dass der Algorithmus nie das Problem war. Der 2026 DBIR fand den menschlichen Faktor bei 62 % der Verletzungen. Das ist kein Kryptografie-Versagen. Es ist ein Versagen beim Schlüsselmanagement, der Zugriffskontrolle, der Endpunkthygiene und der operativen Disziplin.

Drei Dinge sind es wert, jetzt priorisiert zu werden:

1. Prüfen Sie, wo Ihre Verschlüsselungsschlüssel liegen. Wenn welche hardcodiert sind oder neben den zu schützenden Daten gespeichert werden, ist das die dringendste Korrektur auf dieser Liste.
2. Migrieren Sie den asymmetrischen Schlüsselaustausch zu Post-Quanten-Algorithmen. HNDL ist ein gegenwärtiges Risiko für alle Daten mit mehrjährigem Sensibilitätshorizont.
3. Verlagern Sie das Credential-Management in einen strukturierten Tresor. Wenn Ihr Team sich immer noch auf Tabellenkalkulationen oder geteilte Dokumente verlässt, ist das Zugriffskontrollproblem dringender als jede kryptografische Frage.

AES-256 erfüllt seinen Zweck. Die Frage ist, ob alles drumherum das auch tut.

Häufig gestellte Fragen zur AES-256-Verschlüsselung

Ist AES-256-Verschlüsselung wirklich unknackbar?

AES-256 hat keinen bekannten praktischen Angriff, der es innerhalb eines machbaren Zeitrahmens bricht. Der beste klassische Angriff (Biclique) erreicht eine Komplexität von etwa 2²⁵⁴⋅⁴ Operationen — geringfügig unter Brute-Force, aber rechnerisch unmöglich auszuführen. Kein heute gebauter oder für das nächste Jahrzehnt prognostizierter klassischer oder Quantencomputer kann AES-256 durch direkten Angriff auf den Algorithmus brechen.

Können Quantencomputer AES-256 brechen?

Nein. Grovers Algorithmus — die relevante Quantenbedrohung für symmetrische Verschlüsselung — reduziert die effektive Sicherheit von AES-256 von 256 Bit auf etwa 128 Bit. 128-Bit-Sicherheit bleibt durch jede bekannte oder prognostizierte Quantenhardware unknackbar. NIST bestätigt ausdrücklich, dass AES mit 128-, 192- oder 256-Bit-Schlüsseln gegen Quantenangriffe sicher ist. Asymmetrische Algorithmen wie RSA sind diejenigen, die einem echten Quantenrisiko ausgesetzt sind.

Was ist der Unterschied zwischen AES-256-GCM und AES-256-CBC?

AES-256-GCM bietet authentifizierte Verschlüsselung (AEAD): Es verschlüsselt Daten und erzeugt einen Message Authentication Code in einem Durchgang, der sowohl Vertraulichkeit als auch Integrität garantiert. AES-256-CBC verschlüsselt nur — ohne separaten MAC ist es anfällig für Padding-Oracle- und Bit-Flipping-Angriffe. TLS 1.3 hat die CBC-Unterstützung vollständig entfernt. Für neue Deployments ist GCM die richtige Wahl.

Was ist „Harvest Now, Decrypt Later" und sollte ich mir Sorgen machen?

HNDL ist eine Strategie, bei der Gegner heute verschlüsselte Daten abfangen und speichern, mit der Absicht, sie zu entschlüsseln, sobald Quantencomputer dazu fähig werden. Für Daten mit einem langen Sensibilitätshorizont — klassifizierte Informationen, Krankenakten, langfristige Finanzdaten — ist dies ein gegenwärtiges Risiko. Die Mitigation besteht darin, asymmetrische Schlüsselaustauschprotokolle jetzt auf Post-Quanten-Algorithmen (FIPS 203/204/205) zu migrieren, während AES-256 weiterhin für symmetrische Verschlüsselung verwendet wird.

Warum werden Organisationen, die AES-256 verwenden, immer noch gehackt?

Weil Angreifer die Verschlüsselung umgehen, anstatt sie zu brechen. Gestohlene Anmeldedaten, kompromittierte Endpunkte, schlechtes Schlüsselmanagement, Insider-Bedrohungen und zu breite Zugriffsberechtigungen exponieren alle Klartextdaten, ohne jemals die Chiffre zu berühren.

Was ist eine Zero-Knowledge-Architektur in einem Passwort-Manager?

Eine Zero-Knowledge-Architektur bedeutet, dass der Server niemals Klartext-Anmeldedaten oder die Schlüssel zu deren Entschlüsselung empfängt oder speichert. Die Verschlüsselung erfolgt auf dem Client (im Browser oder der Anwendung), bevor die Daten übertragen werden. Selbst wenn der Server vollständig kompromittiert wird, erhält der Angreifer nur Chiffretext. Dies ist die Architektur, die für jedes Credential-Management-Tool erforderlich ist, das sensible Unternehmensgeheimnisse verarbeitet.

Erfüllt AES-256 die Anforderungen von HIPAA, DSGVO und PCI DSS?

Ja, für alle drei. HIPAAs Safe-Harbor-Bestimmung (45 CFR §164.312) bezeichnet AES-256 als gültigen Verschlüsselungsstandard für PHI. DSGVO Artikel 32 verlangt geeignete technische Maßnahmen einschließlich Verschlüsselung — AES-256 erfüllt dies. PCI DSS Anforderung 3 schreibt starke Kryptografie für gespeicherte Karteninhaberdaten vor, wobei AES-256 der akzeptierte Standard ist. Compliance erfordert eine korrekte Implementierung, nicht nur das Vorhandensein von Verschlüsselung.

Mitarbeiter-Offboarding: Leitfaden zur sicheren Zugriffsentziehung 2026

Das Deaktivieren eines SSO-Kontos entzieht keinen Zugriff. API-Schlüssel, KI-Agenten-Anmeldedaten und geteilte Passwörter überleben es. Dieser Leitfaden behandelt das vollständige Offboarding-Playbook — von Zero-Hour-Triggern bis zur NHI-Bereinigung.

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

Secrets-Rotations-Lebenszyklus: Von der Erstellung bis zum Widerruf

Secret-Rotation scheitert, wenn sie als geplante Aufgabe statt als Lebenszyklus behandelt wird. Dieser Leitfaden behandelt alle sieben Phasen — von der Erstellung und Eigentümerschaft bis zur sicheren Rotation, Notfall-Widerruf und Audit-Nachweis.

Passwork BlogAlex Muntyan

El cifrado AES-256 es un cifrado de bloques simétrico que utiliza una clave de 256 bits para cifrar datos en 14 rondas de transformación. Ningún ordenador clásico o cuántico puede descifrarlo por fuerza bruta en un plazo de tiempo práctico. Sin embargo, las organizaciones que utilizan AES-256 siguen sufriendo filtraciones de datos catastróficas — porque los atacantes rara vez intentan romper el cifrado. Atacan los sistemas que lo rodean.

Esa distinción importa más en 2026 que nunca. Los ataques impulsados por IA están acelerando el robo de credenciales y el compromiso de endpoints. La estrategia «Harvest Now, Decrypt Later» (recopilar ahora, descifrar después) significa que los adversarios están almacenando datos cifrados hoy, apostando por futuras capacidades de descifrado. Y NIST ha finalizado sus primeros estándares de criptografía post-cuántica, lo que genera preguntas legítimas sobre si AES-256 todavía tiene lugar en su arquitectura de seguridad.

La respuesta corta: sí. La respuesta más larga requiere entender exactamente contra qué protege AES-256, contra qué no protege, y cómo implementarlo para que la fortaleza teórica del algoritmo se traduzca en seguridad real.

Puntos clave

• AES-256 no tiene debilidad práctica. Ningún ordenador clásico o cuántico puede descifrar por fuerza bruta una clave de 256 bits en un plazo de tiempo viable. El algoritmo en sí no es el riesgo.
• El algoritmo de Grover reduce a la mitad la seguridad de AES-256, no la elimina. Un adversario cuántico reduce la seguridad efectiva a 128 bits — todavía inquebrantable por cualquier hardware conocido o proyectado.
• La amenaza real es Harvest Now, Decrypt Later (HNDL), no el día Q. Los adversarios están archivando datos cifrados hoy. Migrar el intercambio de claves asimétricas a algoritmos post-cuánticos es una prioridad presente, no futura.
• AES-256-GCM es el modo correcto para nuevas implementaciones. CBC proporciona solo confidencialidad. GCM añade autenticación integrada y es obligatorio en TLS 1.3.
• El 62% de las filtraciones involucran el elemento humano. Los atacantes evitan el cifrado a través de credenciales robadas, endpoints comprometidos y mala gestión de claves — no rompiendo el cifrado.
• La gestión de claves es el eslabón más débil. Las claves codificadas de forma fija, las claves almacenadas junto a los datos que protegen y las claves que nunca se rotan son más peligrosas que cualquier ataque criptoanalítico conocido.
• La arquitectura de conocimiento cero elimina el riesgo del lado del servidor. Si el servidor nunca tiene acceso al texto plano ni a las claves de descifrado, un compromiso total del servidor solo produce texto cifrado inútil.
• AES-256 cumple con HIPAA, GDPR y PCI DSS. El cumplimiento requiere una implementación correcta — cifrado en reposo, en tránsito y gestión de claves documentada — no solo la presencia del algoritmo.

¿Qué es AES-256?

AES-256 (Advanced Encryption Standard con una clave de 256 bits) es un cifrado de bloques simétrico estandarizado en NIST FIPS 197. Cifra datos en bloques de 128 bits utilizando una clave de 256 bits a lo largo de 14 rondas de transformación. La misma clave cifra y descifra los datos. Ningún ataque clásico o cuántico conocido puede romperlo en un plazo de tiempo práctico.

AES-256 es el estándar de cifrado utilizado en todo el gobierno federal de EE. UU. (incluidos los sistemas clasificados de la NSA), TLS 1.3, el cifrado de disco completo en todos los sistemas operativos principales y las herramientas empresariales de gestión de credenciales. Cuando un proveedor dice que su producto utiliza «cifrado de grado militar», casi siempre se refiere a AES-256.

De dónde viene el nombre

La parte AES se refiere al algoritmo en sí — una red de sustitución-permutación diseñada por Joan Daemen y Vincent Rijmen (originalmente llamada Rijndael), seleccionada por NIST en 2001 después de una competición pública de cinco años. El «256» se refiere a la longitud de la clave en bits. AES también viene en variantes de 128 bits y 192 bits; la versión de 256 bits utiliza 14 rondas de transformación en lugar de 10 (AES-128) o 12 (AES-192). Más rondas significan un mayor margen de seguridad.

Qué significa realmente la clave de 256 bits

Una clave de 256 bits tiene 2²⁵⁶ valores posibles — aproximadamente 1,16×10⁷⁷. Para ponerlo en términos físicos: si cada átomo del universo observable fuera un ordenador realizando mil millones de miles de millones (10¹⁸) de intentos de clave por segundo, agotar el espacio de claves de AES-256 todavía llevaría más tiempo que la edad del universo por muchos órdenes de magnitud. Por eso los criptógrafos describen AES-256 como sin vulnerabilidad práctica de fuerza bruta.

La longitud de la clave también determina la resiliencia cuántica. El algoritmo de Grover — el mejor ataque cuántico conocido contra cifrados simétricos — proporciona una aceleración cuadrática, reduciendo efectivamente la longitud de la clave a la mitad. Contra AES-256, esa reducción lleva la seguridad efectiva a 128 bits. La seguridad de AES-128 en sí misma es inquebrantable por cualquier hardware conocido o proyectado. La documentación de criptografía post-cuántica del propio NIST confirma que AES-256 sigue siendo seguro contra adversarios cuánticos.

AES-256 vs. AES-128: ¿Es significativa la diferencia?

Para la mayoría de los casos de uso empresarial, ambos son computacionalmente inquebrantables. Las razones prácticas para preferir AES-256 son:

• Requisitos regulatorios. CNSA 2.0 de la NSA (2022, actualizado en 2025) exige AES-256 para todos los Sistemas de Seguridad Nacional en todos los niveles de clasificación. PCI DSS acepta AES-128 como mínimo pero AES-256 como el estándar recomendado.
• Margen cuántico. AES-256 retiene 128 bits de seguridad post-Grover; AES-128 cae a 64 bits, lo que se acerca a la viabilidad para un adversario cuántico suficientemente avanzado.
• Datos de larga duración. Si los datos que cifra hoy necesitan permanecer confidenciales durante más de 20 años, AES-256 es la opción conservadora.

La diferencia de rendimiento entre AES-128 y AES-256 es insignificante en hardware moderno con aceleración AES-NI — típicamente menos del 20% de diferencia en rendimiento. No hay razón práctica para elegir AES-128 en nuevas implementaciones.

Cómo encaja AES-256 en una arquitectura de seguridad más amplia

AES-256 es un cifrado simétrico. Maneja el cifrado masivo de datos de manera eficiente, pero requiere que ambas partes compartan la misma clave secreta — lo que crea un problema de distribución de claves. En la práctica, la criptografía asimétrica (RSA, ECC o algoritmos post-cuánticos como ML-KEM de FIPS 203) se utiliza para intercambiar de forma segura la clave AES, después de lo cual AES-256 maneja los datos reales. Así es exactamente como funciona TLS 1.3: handshake asimétrico, transferencia de datos simétrica.

El cifrado es tan fuerte como el sistema que lo rodea. AES-256 protege los datos en reposo y en tránsito. No protege contra una clave robada, un endpoint comprometido o un usuario autorizado con intenciones maliciosas. Eso no es una debilidad del algoritmo — es el límite de lo que cualquier cifrado puede hacer.

Cómo funciona AES-256: Las matemáticas detrás del cifrado

El cifrado procesa datos en bloques fijos de 128 bits. Cada bloque pasa por 14 rondas secuenciales de transformación — más rondas que AES-128 (10) o AES-192 (12). Cada ronda aplica cuatro operaciones: sustitución, desplazamiento de filas, mezcla de columnas y adición de clave. Cambiar un solo bit de entrada cambia aproximadamente la mitad de los bits de salida al final de la primera ronda.

Las 14 rondas de transformación

AES-256 aplica 14 rondas de cuatro operaciones a cada bloque de datos de 128 bits. Cada ronda consiste en:

1. SubBytes — cada byte se reemplaza mediante una tabla de sustitución fija (S-box), introduciendo no linealidad
2. ShiftRows — las filas de la matriz de estado 4×4 se desplazan cíclicamente, proporcionando difusión
3. MixColumns — las columnas se multiplican en un Campo de Galois, mezclando aún más los datos entre bytes
4. AddRoundKey — la clave de ronda (derivada de la clave original de 256 bits mediante expansión de clave) se combina mediante XOR con el estado

La ronda final omite MixColumns. Este diseño de red de sustitución-permutación (SPN) significa que cambiar un solo bit de entrada cambia aproximadamente la mitad de los bits de salida — el efecto avalancha. Después de 14 rondas, la relación entre el texto plano y el texto cifrado es computacionalmente intratable de revertir sin la clave.

AES-GCM vs. AES-CBC: Por qué el modo importa tanto como la longitud de la clave

El cifrado en sí es solo parte de la historia. Cómo se utiliza — el modo de operación — determina si su implementación es realmente segura.

AES-256-GCM es un modo de Cifrado Autenticado con Datos Asociados (AEAD). Cifra simultáneamente los datos y produce un código de autenticación de mensaje (MAC), garantizando tanto confidencialidad como integridad en una sola operación. Si un atacante manipula el texto cifrado, el descifrado falla — el MAC no se verificará.

AES-256-CBC proporciona solo confidencialidad. Sin un MAC separado (mediante HMAC-SHA256, por ejemplo), un mensaje cifrado con CBC es vulnerable a ataques de oráculo de relleno y manipulación de bits. CBC también requiere procesamiento secuencial, lo que limita el rendimiento en hardware moderno multinúcleo.

Para nuevas implementaciones en 2026, AES-256-GCM es la opción correcta. TLS 1.3 eliminó los conjuntos de cifrado CBC por completo por esta razón. La única advertencia práctica: GCM se rompe catastróficamente si un nonce (vector de inicialización) se reutiliza con la misma clave. Su implementación debe garantizar la unicidad del nonce — típicamente mediante un generador de números aleatorios criptográficamente seguro o un contador.

Computación cuántica y AES-256: Separando el riesgo del ruido

La amenaza de la computación cuántica al cifrado es real, pero no es uniforme. Entender qué algoritmos son vulnerables, y en qué medida, es esencial para tomar decisiones arquitectónicas sólidas hoy.

Los ordenadores cuánticos amenazan la criptografía asimétrica (RSA, ECC, Diffie-Hellman) a través del algoritmo de Shor, que puede factorizar grandes enteros y resolver problemas de logaritmo discreto en tiempo polinómico. Un ordenador cuántico suficientemente potente ejecutando el algoritmo de Shor rompería RSA-2048 por completo. Esta es la crisis genuina que impulsa el esfuerzo de estandarización de criptografía post-cuántica (PQC) de NIST, que finalizó FIPS 203, 204 y 205 en 2024.

El cifrado simétrico enfrenta un algoritmo diferente y un nivel de amenaza diferente.

Qué hace realmente el algoritmo de Grover a AES-256

El algoritmo de Grover es la amenaza cuántica al cifrado simétrico. Proporciona una aceleración cuadrática para problemas de búsqueda no estructurada: donde un ordenador clásico necesita N operaciones para buscar en un espacio de claves, un ordenador cuántico ejecutando Grover necesita aproximadamente la raíz cuadrada de N. Aplicado a AES-256, esto reduce efectivamente la longitud de la clave a la mitad desde una perspectiva de seguridad — una clave de 256 bits proporciona aproximadamente 128 bits de seguridad contra un adversario cuántico.

128 bits de seguridad siguen siendo inquebrantables. Para ser concretos: un ataque clásico a AES-128 requiere aproximadamente 2¹²⁸ operaciones. Incluso si pudiera realizar mil millones de miles de millones (10¹⁸) de operaciones por segundo, agotar ese espacio de claves llevaría más tiempo que la edad del universo. El algoritmo de Grover reduce AES-256 a ese nivel — no lo rompe. Las preguntas frecuentes de PQC del propio NIST afirman explícitamente que AES con claves de 128, 192 o 256 bits permanece seguro contra ataques cuánticos.

El aviso CNSA 2.0 de la NSA (2022, actualizado en 2025) exige AES-256 para todos los Sistemas de Seguridad Nacional en todos los niveles de clasificación, incluido Alto Secreto, con una fecha límite de transición de 2035. El hecho de que la NSA no esté reemplazando AES-256 (solo los algoritmos asimétricos) es la señal más clara posible sobre su resiliencia cuántica.

Harvest Now, Decrypt Later (HNDL): La amenaza que existe hoy

El día Q (el punto en el que existe un ordenador cuántico criptoanalíticamente relevante) se estima por la mayoría de los investigadores que está a 10-20 años de distancia, aunque los plazos son genuinamente inciertos. La amenaza más inmediata es HNDL: actores estatales y grupos criminales sofisticados están interceptando y archivando tráfico cifrado hoy, con la intención de descifrarlo una vez que el hardware cuántico madure.

Para datos con un horizonte de sensibilidad largo — comunicaciones gubernamentales clasificadas, propiedad intelectual, registros médicos, datos financieros a largo plazo — HNDL es un riesgo operativo presente, no un hipotético futuro. La respuesta es migrar los protocolos de intercambio de claves asimétricas a algoritmos post-cuánticos ahora, mientras se continúa utilizando AES-256 para el cifrado simétrico.

Si AES-256 es inquebrantable, ¿por qué siguen ocurriendo filtraciones de datos?

El cifrado AES-256 es matemáticamente sólido. Las filtraciones ocurren en todas partes menos ahí. El Informe de Investigaciones de Filtraciones de Datos 2026 de Verizon encontró que el elemento humano estuvo presente en el 62% de las filtraciones — credenciales robadas, mal uso de privilegios, ingeniería social. Los atacantes no rompen el cifrado. Roban la clave, comprometen el endpoint o explotan a la persona que tiene la contraseña.

El DBIR 2026 también marca un cambio estructural: por primera vez en 19 años de publicación del informe, la explotación de vulnerabilidades ha superado a las credenciales robadas como el principal vector de acceso inicial, representando el 31% de todas las filtraciones, frente al 20% del año anterior. La IA está acelerando esto — los actores de amenazas ahora la usan para reducir la ventana entre la divulgación de vulnerabilidades y la explotación activa de meses a horas.

El Informe de Costo de una Filtración de Datos 2025 de IBM cuantifica el peso financiero de estos fallos en 4,44 millones de dólares por incidente en promedio. Las organizaciones con altos niveles de shadow AI (empleados usando herramientas de IA no aprobadas en dispositivos corporativos) pagaron 670.000 dólares adicionales por filtración. El DBIR 2026 añade contexto: el shadow AI es ahora la tercera actividad de fuga de datos internos no maliciosa más común, con el uso regular de herramientas de IA entre empleados saltando del 15% al 45% en un solo año.

Estas cifras enmarcan el problema real: el cifrado protege los datos en reposo y en tránsito, pero no puede proteger contra un usuario autorizado haciendo algo no autorizado, una vulnerabilidad sin parchear durante ocho meses, o un endpoint que ya está comprometido.

Las seis brechas que evitan el cifrado

Aquí hay una forma estructurada de pensar sobre dónde falla AES-256 en la práctica — no porque el algoritmo sea débil, sino porque la arquitectura circundante lo es.

El modelo de brechas «El cifrado no es suficiente»:

1. Fallos en la gestión de claves. Claves de cifrado codificadas de forma fija en el código fuente, claves almacenadas junto a los datos que protegen, claves que nunca se rotan. Si la clave está comprometida, el cifrado no vale nada. Los Módulos de Seguridad Hardware (HSM) y las funciones de derivación de claves como PBKDF2 existen precisamente para abordar esto. Passwork, por ejemplo, deriva su clave maestra de la contraseña maestra del usuario mediante PBKDF2 con 300.000 iteraciones y SHA-256 — haciendo que la fuerza bruta de la contraseña maestra sea computacionalmente costosa incluso si la base de datos cifrada es exfiltrada.
2. Endpoints comprometidos. El malware que opera en un endpoint lee los datos después del descifrado, en RAM. Los datos estaban cifrados en reposo, se descifraron para ser utilizados, el malware los capturó en texto plano. AES-256 proporciona cero protección aquí. Por eso la detección y respuesta de endpoints (EDR) y las estaciones de trabajo de acceso privilegiado (PAWs) no son capas opcionales.
3. Amenazas internas. Los usuarios autorizados con acceso legítimo de descifrado pueden exfiltrar datos. El cifrado no distingue entre un administrador legítimo y uno malicioso. El control de acceso basado en roles (RBAC), los principios de mínimo privilegio y el registro de auditoría son los controles que abordan esta brecha.
4. Control de acceso deficiente. Credenciales compartidas, permisos demasiado amplios y cuentas obsoletas que permanecen activas después de la salida de empleados crean exposición que el cifrado no puede mitigar.
5. Exposición de metadatos. Incluso cuando el contenido está cifrado, los metadatos (quién se comunicó con quién, cuándo, con qué frecuencia, tamaños de archivo, patrones de acceso) pueden revelar información sensible. El cifrado protege la carga útil, no el sobre.
6. Pérdida de control post-compartición. Una vez que un archivo cifrado se comparte y el destinatario lo descifra, no tiene control sobre lo que sucede después. La gestión de derechos digitales (DRM) y las arquitecturas de compartición de archivos de confianza cero abordan parcialmente esto, pero ninguna solución es completa.

Ataques criptoanalíticos conocidos contra AES-256 — y por qué no importan en la práctica

Para ser exhaustivos: los mejores ataques conocidos contra AES-256 completo son el ataque biclique (complejidad computacional de aproximadamente 2²⁵⁴⋅⁴, apenas por debajo del límite de fuerza bruta de 2²⁵⁶) y los ataques de clave relacionada (complejidad de alrededor de 2⁹⁹⋅⁵ bajo condiciones muy específicas).

Ninguno es prácticamente relevante. El ataque biclique requiere más computación de la que es físicamente viable. Los ataques de clave relacionada requieren que el atacante controle la relación entre múltiples claves — una condición que no existe en ningún sistema correctamente diseñado. Los ataques de canal lateral (análisis de potencia, ataques de tiempo, temporización de caché) son una preocupación genuina, pero atacan la implementación, no el algoritmo. Las implementaciones de tiempo constante y la aceleración hardware de AES (AES-NI) mitigan la mayoría de estos.

Mejores prácticas empresariales para AES-256 en 2026

Implementar AES-256 correctamente en 2026 significa pensar en tres planos: datos en reposo, datos en tránsito y datos en uso. La mayoría de las organizaciones tienen los dos primeros parcialmente cubiertos. El tercero es donde ocurrirá la próxima generación de filtraciones.

Datos en reposo

Utilice AES-256-GCM para nuevas implementaciones. Asegúrese de que las claves se gestionen por separado de los datos que protegen — idealmente en un HSM o un servicio de gestión de claves dedicado. Rote las claves según un calendario definido e inmediatamente ante sospecha de compromiso. Utilice PBKDF2, bcrypt o Argon2 para derivar claves de cifrado de contraseñas. Nunca use la contraseña directamente como clave.

El cifrado de disco completo (BitLocker en Windows, FileVault en macOS) proporciona una línea base para la protección de endpoints, pero solo protege contra el robo físico de un dispositivo apagado. No protege contra un usuario conectado o un proceso de malware en ejecución.

Datos en tránsito

TLS 1.3 es el estándar actual. Exige conjuntos de cifrado AEAD (AES-256-GCM o ChaCha20-Poly1305), elimina los conjuntos de cifrado débiles presentes en TLS 1.2 y proporciona secreto perfecto hacia adelante por defecto. Si su infraestructura todavía soporta TLS 1.2 con conjuntos de cifrado CBC, esa es una deuda de configuración que vale la pena abordar ahora.

Datos en uso — el problema sin resolver

Los datos en uso son texto plano en memoria mientras se procesan. Los frameworks de computación confidencial — Intel SGX (Software Guard Extensions) y AMD SEV (Secure Encrypted Virtualization) — crean entornos de ejecución aislados por hardware (entornos de ejecución confiable, o TEEs) donde ni siquiera el hipervisor o el sistema operativo pueden leer los datos que se procesan. Esta es la frontera de la arquitectura de cifrado, y es cada vez más relevante para cargas de trabajo en la nube que manejan datos sensibles.

Arquitectura de conocimiento cero

Una arquitectura de conocimiento cero significa que el proveedor del servicio (o servidor) nunca tiene acceso a los datos en texto plano ni a las claves para descifrarlos. El cifrado del lado del cliente es el mecanismo: los datos se cifran en el cliente antes de la transmisión, y el servidor almacena solo texto cifrado. El modo de cifrado del lado del cliente de Passwork implementa esto — la clave maestra se deriva de la contraseña maestra del usuario y nunca se transmite al servidor, lo que significa que incluso un compromiso total del servidor solo produce datos cifrados.

Anclas de cumplimiento

AES-256 no es solo una mejor práctica técnica — es un requisito de cumplimiento en múltiples marcos:

• HIPAA Safe Harbor (45 CFR §164.312(a)(2)(iv)) designa AES-256 como un método de cifrado válido para información de salud protegida (PHI), haciendo que los datos filtrados sean «no utilizables, ilegibles o indescifrables».
• GDPR Artículo 32 requiere «medidas técnicas apropiadas» incluyendo cifrado para proteger datos personales. AES-256 es el estándar de facto para satisfacer este requisito.
• PCI DSS Requisito 3 exige criptografía fuerte para los datos de titulares de tarjetas almacenados. AES-256 cumple este requisito; AES-128 es el mínimo.
• NSA CNSA 2.0 exige AES-256 (no AES-128) para todos los Sistemas de Seguridad Nacional en todos los niveles de clasificación.

Conclusión

AES-256 sigue siendo la base correcta para el cifrado de datos en 2026. El algoritmo no tiene debilidad práctica (clásica o cuántica) y esa posición es poco probable que cambie dentro de cualquier horizonte de planificación que importe a su organización hoy.

La verdad más difícil es que el algoritmo nunca fue el problema. El DBIR 2026 encontró el elemento humano en el 62% de las filtraciones. Eso no es un fallo de criptografía. Es un fallo en la gestión de claves, el control de acceso, la higiene de endpoints y la disciplina operativa.

Tres cosas vale la pena priorizar ahora mismo:

1. Audite dónde residen sus claves de cifrado. Si alguna está codificada de forma fija o almacenada junto a los datos que protege, esa es la corrección más urgente de esta lista.
2. Migre el intercambio de claves asimétricas a algoritmos post-cuánticos. HNDL es un riesgo presente para cualquier dato con un horizonte de sensibilidad de varios años.
3. Traslade la gestión de credenciales a una bóveda estructurada. Si su equipo todavía depende de hojas de cálculo o documentos compartidos, el problema de control de acceso es más inmediato que cualquier cuestión criptográfica.

AES-256 hace su trabajo. La pregunta es si todo lo que lo rodea también lo hace.

Preguntas frecuentes sobre el cifrado AES-256

¿Es el cifrado AES-256 verdaderamente inquebrantable?

AES-256 no tiene ningún ataque práctico conocido que lo rompa en un plazo de tiempo viable. El mejor ataque clásico (biclique) logra una complejidad de aproximadamente 2²⁵⁴⋅⁴ operaciones — marginalmente por debajo de la fuerza bruta pero computacionalmente imposible de ejecutar. Ningún ordenador clásico o cuántico construido hoy, o proyectado para la próxima década, puede romper AES-256 atacando directamente el algoritmo.

¿Pueden los ordenadores cuánticos romper AES-256?

No. El algoritmo de Grover — la amenaza cuántica relevante para el cifrado simétrico — reduce la seguridad efectiva de AES-256 de 256 bits a aproximadamente 128 bits. 128 bits de seguridad siguen siendo inquebrantables por cualquier hardware cuántico conocido o proyectado. NIST confirma explícitamente que AES con claves de 128, 192 o 256 bits es seguro contra ataques cuánticos. Los algoritmos asimétricos como RSA son los que enfrentan un riesgo cuántico genuino.

¿Cuál es la diferencia entre AES-256-GCM y AES-256-CBC?

AES-256-GCM proporciona cifrado autenticado (AEAD): cifra los datos y produce un código de autenticación de mensaje en un solo paso, garantizando tanto confidencialidad como integridad. AES-256-CBC solo cifra — sin un MAC separado, es vulnerable a ataques de oráculo de relleno y manipulación de bits. TLS 1.3 eliminó el soporte de CBC por completo. Para nuevas implementaciones, GCM es la opción correcta.

¿Qué es «Harvest Now, Decrypt Later» y debería preocuparme?

HNDL es una estrategia donde los adversarios interceptan y almacenan datos cifrados hoy, con la intención de descifrarlos una vez que los ordenadores cuánticos sean capaces. Para datos con un horizonte de sensibilidad largo — información clasificada, registros médicos, datos financieros a largo plazo — este es un riesgo presente. La mitigación es migrar los protocolos de intercambio de claves asimétricas a algoritmos post-cuánticos (FIPS 203/204/205) ahora, mientras se continúa utilizando AES-256 para el cifrado simétrico.

¿Por qué las organizaciones que usan AES-256 siguen siendo vulneradas?

Porque los atacantes evitan el cifrado en lugar de romperlo. Las credenciales robadas, los endpoints comprometidos, la mala gestión de claves, las amenazas internas y los permisos excesivamente amplios exponen datos en texto plano sin siquiera tocar el cifrado.

¿Qué es una arquitectura de conocimiento cero en un gestor de contraseñas?

Una arquitectura de conocimiento cero significa que el servidor nunca recibe ni almacena credenciales en texto plano ni las claves para descifrarlas. El cifrado ocurre en el cliente (en el navegador o aplicación) antes de que los datos se transmitan. Incluso si el servidor es completamente comprometido, el atacante obtiene solo texto cifrado. Esta es la arquitectura requerida para cualquier herramienta de gestión de credenciales que maneje secretos corporativos sensibles.

¿Cumple AES-256 con los requisitos de HIPAA, GDPR y PCI DSS?

Sí, para los tres. La disposición Safe Harbor de HIPAA (45 CFR §164.312) designa AES-256 como un estándar de cifrado válido para PHI. El Artículo 32 del GDPR requiere medidas técnicas apropiadas incluyendo cifrado — AES-256 satisface esto. El Requisito 3 de PCI DSS exige criptografía fuerte para los datos de titulares de tarjetas almacenados, siendo AES-256 el estándar aceptado. El cumplimiento requiere una implementación correcta, no solo la presencia del cifrado.

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

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

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

Ciclo de vida de rotación de secretos: Desde la creación hasta la revocación

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

Passwork BlogAlex Muntyan

AES-256 encryption is a symmetric block cipher that uses a 256-bit key to encrypt data in 14 transformation rounds. No classical or quantum computer can brute-force it within any practical timeframe. Yet organizations using AES-256 still suffer catastrophic data breaches — because attackers rarely try to break the cipher. They break the systems around it.

That distinction matters more in 2026 than it ever has. AI-driven attacks are accelerating credential theft and endpoint compromise. The "Harvest Now, Decrypt Later" strategy means adversaries are stockpiling encrypted data today, betting on future decryption capabilities. And NIST has finalized its first post-quantum cryptography standards, prompting legitimate questions about whether AES-256 still belongs in your security architecture.

The short answer: yes. The longer answer requires understanding exactly what AES-256 protects against, what it doesn't, and how to deploy it so that the algorithm's theoretical strength translates into actual security.

Key takeaways

• AES-256 has no practical weakness. No classical or quantum computer can brute-force a 256-bit key within any feasible timeframe. The algorithm itself is not the risk.
• Grover's algorithm halves AES-256's security, not eliminates it. A quantum adversary reduces effective security to 128 bits — still unbreakable by any known or projected hardware.
• The real threat is Harvest Now, Decrypt Later (HNDL), not Q-Day. Adversaries are archiving encrypted data today. Migrating asymmetric key exchange to post-quantum algorithms is a present priority, not a future one.
• AES-256-GCM is the correct mode for new implementations. CBC provides confidentiality only. GCM adds built-in authentication and is mandatory in TLS 1.3.
• 62% of breaches involve the human element. Attackers bypass encryption through stolen credentials, compromised endpoints, and poor key management — not by breaking the cipher.
• Key management is the weakest link. Hardcoded keys, keys stored next to the data they protect, and keys that never rotate are more dangerous than any known cryptanalytic attack.
• Zero-knowledge architecture eliminates server-side risk. If the server never holds plaintext or decryption keys, a full server compromise yields only useless ciphertext.
• AES-256 satisfies HIPAA, GDPR, and PCI DSS. Compliance requires correct implementation — encryption at rest, in transit, and documented key management — not just the presence of the algorithm.

What is AES-256?

AES-256 (Advanced Encryption Standard with a 256-bit key) is a symmetric block cipher standardized in NIST FIPS 197. It encrypts data in 128-bit blocks using a 256-bit key across 14 transformation rounds. The same key encrypts and decrypts the data. No known classical or quantum attack can break it within any practical timeframe.

AES-256 is the encryption standard used across the U.S. federal government (including NSA-classified systems), TLS 1.3, full-disk encryption on every major OS, and enterprise credential management tools. When a vendor says their product uses "military-grade encryption," they almost always mean AES-256.

Where the name comes from

The AES part refers to the algorithm itself — a substitution-permutation network designed by Joan Daemen and Vincent Rijmen (originally named Rijndael), selected by NIST in 2001 after a five-year public competition. The "256" refers to the key length in bits. AES also comes in 128-bit and 192-bit variants; the 256-bit version uses 14 rounds of transformation instead of 10 (AES-128) or 12 (AES-192). More rounds mean a larger security margin.

What the 256-bit key actually means

A 256-bit key has 2²⁵⁶ possible values — approximately 1.16×10⁷⁷. To put that in physical terms: if every atom in the observable universe were a computer performing a billion billion key guesses per second, exhausting the AES-256 keyspace would still take longer than the age of the universe by many orders of magnitude. This is why cryptographers describe AES-256 as having no practical brute-force vulnerability.

The key length also determines quantum resilience. Grover's algorithm — the best known quantum attack on symmetric ciphers — provides a quadratic speedup, effectively halving the key length. Against AES-256, that reduction brings effective security to 128 bits. AES-128 security is itself unbreakable by any known or projected hardware. NIST's own post-quantum cryptography documentation confirms AES-256 remains secure against quantum adversaries.

AES-256 vs. AES-128: Is the difference meaningful?

For most enterprise use cases, both are computationally unbreakable. The practical reasons to prefer AES-256 are:

• Regulatory requirements. NSA's CNSA 2.0 (2022, updated 2025) mandates AES-256 for all National Security Systems at all classification levels. PCI DSS accepts AES-128 as a minimum but AES-256 as the recommended standard.
• Quantum margin. AES-256 retains 128-bit security post-Grover; AES-128 drops to 64 bits, which approaches feasibility for a sufficiently advanced quantum adversary.
• Long-lived data. If the data you encrypt today needs to remain confidential for 20+ years, AES-256 is the conservative choice.

The performance difference between AES-128 and AES-256 is negligible on modern hardware with AES-NI acceleration — typically under 20% throughput difference. There is no practical reason to choose AES-128 for new implementations.

How AES-256 fits into a broader security architecture

AES-256 is a symmetric cipher. It handles bulk data encryption efficiently, but it requires both parties to share the same secret key — which creates a key distribution problem. In practice, asymmetric cryptography (RSA, ECC, or post-quantum algorithms like ML-KEM from FIPS 203) is used to securely exchange the AES key, after which AES-256 handles the actual data. This is exactly how TLS 1.3 works: asymmetric handshake, symmetric data transfer.

The cipher is only as strong as the system around it. AES-256 protects data at rest and in transit. It does not protect against a stolen key, a compromised endpoint, or an authorized user with malicious intent. That's not a weakness in the algorithm — it's the boundary of what any cipher can do.

How AES-256 works: The math behind the cipher

The cipher processes data in fixed 128-bit blocks. Each block passes through 14 sequential rounds of transformation — more rounds than AES-128 (10) or AES-192 (12). Each round applies four operations: substitution, row shifting, column mixing, and key addition. Flipping a single input bit changes roughly half the output bits by the end of round one.

The 14 rounds of transformation

AES-256 applies 14 rounds of four operations to each 128-bit data block. Each round consists of:

1. SubBytes — each byte is replaced via a fixed substitution table (S-box), introducing non-linearity
2. ShiftRows — rows of the 4×4 state matrix are cyclically shifted, providing diffusion
3. MixColumns — columns are multiplied in a Galois Field, further mixing data across bytes
4. AddRoundKey — the round key (derived from the original 256-bit key via key expansion) is XORed with the state

The final round omits MixColumns. This substitution-permutation network (SPN) design means that flipping a single input bit changes roughly half the output bits — the avalanche effect. After 14 rounds, the relationship between plaintext and ciphertext is computationally intractable to reverse without the key.

AES-GCM vs. AES-CBC: Why the mode matters as much as the key length

The cipher itself is only part of the story. How you use it — the mode of operation — determines whether your implementation is actually secure.

AES-256-GCM is an Authenticated Encryption with Associated Data (AEAD) mode. It simultaneously encrypts the data and produces a message authentication code (MAC), guaranteeing both confidentiality and integrity in a single operation. If an attacker tampers with the ciphertext, decryption fails — the MAC won't verify.

AES-256-CBC provides confidentiality only. Without a separate MAC (via HMAC-SHA256, for example), a CBC-encrypted message is vulnerable to padding oracle attacks and bit-flipping. CBC also requires sequential processing, which limits performance on modern multi-core hardware.

For new implementations in 2026, AES-256-GCM is the correct choice. TLS 1.3 removed CBC cipher suites entirely for this reason. The one practical caveat: GCM is catastrophically broken if a nonce (initialization vector) is reused with the same key. Your implementation must guarantee nonce uniqueness — typically via a cryptographically secure random number generator or a counter.

Quantum computing and AES-256: Separating risk from noise

The quantum computing threat to encryption is real, but it is not uniform. Understanding which algorithms are vulnerable, and by how much, is essential for making sound architectural decisions today.

Quantum computers threaten asymmetric cryptography (RSA, ECC, Diffie-Hellman) through Shor's algorithm, which can factor large integers and solve discrete logarithm problems in polynomial time. A sufficiently powerful quantum computer running Shor's algorithm would break RSA-2048 entirely. This is the genuine crisis driving NIST's post-quantum cryptography (PQC) standardization effort, which finalized FIPS 203, 204, and 205 in 2024.

Symmetric encryption faces a different algorithm and a different threat level.

What Grover's algorithm actually does to AES-256

Grover's algorithm is the quantum threat to symmetric encryption. It provides a quadratic speedup for unstructured search problems: where a classical computer needs N operations to search a keyspace, a quantum computer running Grover's needs roughly the square root of N. Applied to AES-256, this effectively halves the key length from a security perspective — a 256-bit key provides approximately 128 bits of security against a quantum adversary.

128-bit security is still unbreakable. To put it concretely: a classical attack on AES-128 requires roughly 2¹²⁸ operations. Even if you could perform a billion billion (10¹⁸) operations per second, exhausting that keyspace would take longer than the age of the universe. Grover's algorithm reduces AES-256 to that level — it does not break it. NIST's own PQC FAQ explicitly states that AES with 128, 192, or 256-bit keys remains secure against quantum attacks.

The NSA's CNSA 2.0 advisory (2022, updated 2025) mandates AES-256 for all National Security Systems at all classification levels, including Top Secret, with a transition deadline of 2035. The fact that NSA is not replacing AES-256 (only the asymmetric algorithms) is the clearest possible signal about its quantum resilience.

Harvest Now, Decrypt Later (HNDL): The threat that exists today

Q-Day (the point at which a cryptanalytically relevant quantum computer exists) is estimated by most researchers to be 10–20 years away, though timelines are genuinely uncertain. The more immediate threat is HNDL: nation-state actors and sophisticated criminal groups are intercepting and archiving encrypted traffic today, with the intention of decrypting it once quantum hardware matures.

For data with a long sensitivity horizon — classified government communications, intellectual property, medical records, long-term financial data — HNDL is a present operational risk, not a future hypothetical. The response is to migrate asymmetric key exchange to post-quantum algorithms now, while continuing to use AES-256 for symmetric encryption.

If AES-256 is unbreakable, why do data breaches still happen?

AES-256 encryption is mathematically sound. The breaches happen everywhere else. Verizon's 2026 Data Breach Investigations Report found that the human element was present in 62% of breaches — stolen credentials, privilege misuse, social engineering. Attackers don't break the cipher. They steal the key, compromise the endpoint, or exploit the person holding the password.

The 2026 DBIR also marks a structural shift: for the first time in 19 years of the report's publication, vulnerability exploitation has overtaken stolen credentials as the top initial access vector, accounting for 31% of all breaches, up from 20% the prior year. AI is accelerating this — threat actors now use it to shrink the window between vulnerability disclosure and active exploitation from months to hours.

IBM's 2025 Cost of a Data Breach Report puts the financial weight on these failures at $4.44 million per incident on average. Organizations with high levels of shadow AI (employees using unapproved AI tools on corporate devices) paid an additional $670,000 per breach. The 2026 DBIR adds context: shadow AI is now the third most common non-malicious insider data leakage activity, with regular AI tool usage among employees jumping from 15% to 45% in a single year.

These numbers frame the real problem: encryption protects data at rest and in transit, but it cannot protect against an authorized user doing something unauthorized, a vulnerability left unpatched for eight months, or an endpoint that's already compromised.

The six gaps that bypass encryption

Here is a structured way to think about where AES-256 fails in practice — not because the algorithm is weak, but because the surrounding architecture is.

The "Encryption Is Not Enough" gap model:

1. Key management failures. Hardcoded encryption keys in source code, keys stored alongside the data they protect, keys that never rotate. If the key is compromised, the encryption is worthless. Hardware Security Modules (HSMs) and key derivation functions like PBKDF2 exist precisely to address this. Passwork, for example, derives its master key from the user's master password via PBKDF2 with 300,000 iterations and SHA-256 — making brute-force of the master password computationally expensive even if the encrypted database is exfiltrated.
2. Compromised endpoints. Malware operating on an endpoint reads data after decryption, in RAM. The data was encrypted at rest, it was decrypted to be used, the malware captured it in plaintext. AES-256 provides zero protection here. This is why endpoint detection and response (EDR) and privileged access workstations (PAWs) are not optional layers.
3. Insider threats. Authorized users with legitimate decryption access can exfiltrate data. Encryption does not distinguish between a legitimate administrator and a malicious one. Role-based access control (RBAC), least-privilege principles, and audit logging are the controls that address this gap.
4. Poor access control. Shared credentials, overly broad permissions, and stale accounts left active after employee departures all create exposure that encryption cannot mitigate.
5. Metadata exposure. Even when content is encrypted, metadata (who communicated with whom, when, how often, file sizes, access patterns) can reveal sensitive information. Encryption protects the payload, not the envelope.
6. Post-sharing loss of control. Once an encrypted file is shared and the recipient decrypts it, you have no control over what happens next. Digital rights management (DRM) and zero-trust file-sharing architectures partially address this, but no solution is complete.

Known cryptanalytic attacks on AES-256 — and why they don't matter in practice

For completeness: the best known attacks against full AES-256 are the biclique attack (computational complexity of approximately 2²⁵⁴⋅⁴, barely below the brute-force bound of 2²⁵⁶) and related-key attacks (complexity around 2⁹⁹⋅⁵ under highly specific conditions).

Neither is practically relevant. The biclique attack requires more computation than is physically feasible. Related-key attacks require the attacker to control the relationship between multiple keys — a condition that does not exist in any properly designed system. Side-channel attacks (power analysis, timing attacks, cache-timing) are a genuine concern, but they target the implementation, not the algorithm. Constant-time implementations and hardware AES acceleration (AES-NI) mitigate most of these.

Enterprise best practices for AES-256 in 2026

Deploying AES-256 correctly in 2026 means thinking in three planes: data at rest, data in transit, and data in use. Most organizations have the first two partially covered. The third is where the next generation of breaches will occur.

Data at rest

Use AES-256-GCM for new implementations. Ensure keys are managed separately from the data they protect — ideally in an HSM or a dedicated key management service. Rotate keys on a defined schedule and immediately upon suspected compromise. Use PBKDF2, bcrypt, or Argon2 to derive encryption keys from passwords. Never use the password directly as a key.

Full-disk encryption (BitLocker on Windows, FileVault on macOS) provides a baseline for endpoint protection, but it only protects against physical theft of a powered-off device. It does not protect against a logged-in user or a running malware process.

Data in transit

TLS 1.3 is the current standard. It mandates AEAD cipher suites (AES-256-GCM or ChaCha20-Poly1305), removes weak cipher suites present in TLS 1.2, and provides forward secrecy by default. If your infrastructure still supports TLS 1.2 with CBC cipher suites, that is a configuration debt worth addressing now.

Data in use — the unsolved problem

Data in use is plaintext in memory while being processed. Confidential computing frameworks — Intel SGX (Software Guard Extensions) and AMD SEV (Secure Encrypted Virtualization) — create hardware-isolated execution environments (trusted execution environments, or TEEs) where even the hypervisor or operating system cannot read the data being processed. This is the frontier of encryption architecture, and it is increasingly relevant for cloud workloads handling sensitive data.

Zero-knowledge architecture

A zero-knowledge architecture means the service provider (or server) never has access to plaintext data or the keys to decrypt it. Client-side encryption is the mechanism: data is encrypted on the client before transmission, and the server stores only ciphertext. Passwork's client-side encryption mode implements this — the master key is derived from the user's master password and never transmitted to the server, meaning even a full server compromise yields only encrypted data.

Compliance anchors

AES-256 is not just a technical best practice — it is a compliance requirement across multiple frameworks:

• HIPAA Safe Harbor (45 CFR §164.312(a)(2)(iv)) designates AES-256 as a valid encryption method for protected health information (PHI), rendering breached data "not usable, unreadable, or indecipherable."
• GDPR Article 32 requires "appropriate technical measures" including encryption to protect personal data. AES-256 is the de facto standard for satisfying this requirement.
• PCI DSS Requirement 3 mandates strong cryptography for stored cardholder data. AES-256 meets this requirement; AES-128 is the minimum.
• NSA CNSA 2.0 mandates AES-256 (not AES-128) for all National Security Systems at all classification levels.

Conclusion

AES-256 remains the right foundation for data encryption in 2026. The algorithm has no practical weakness (classical or quantum) and that position is unlikely to shift within any planning horizon that matters to your organization today.

The harder truth is that the algorithm was never the problem. The 2026 DBIR found the human element in 62% of breaches. That's not a cryptography failure. It's a failure in key management, access control, endpoint hygiene, and operational discipline.

Three things are worth prioritizing right now:

1. Audit where your encryption keys live. If any are hardcoded or stored adjacent to the data they protect, that is the most urgent fix on this list.
2. Migrate asymmetric key exchange to post-quantum algorithms. HNDL is a present risk for any data with a multi-year sensitivity horizon.
3. Move credential management into a structured vault. If your team still relies on spreadsheets or shared documents, the access control problem is more immediate than any cryptographic question.

AES-256 does its job. The question is whether everything around it does too.

Frequently asked questions about AES-256 encryption

Is AES-256 encryption truly unbreakable?

AES-256 has no known practical attack that breaks it within a feasible timeframe. The best classical attack (biclique) achieves a complexity of approximately 2²⁵⁴⋅⁴ operations — marginally below brute force but computationally impossible to execute. No classical or quantum computer built today, or projected for the next decade, can break AES-256 by attacking the algorithm directly.

Can quantum computers break AES-256?

No. Grover's algorithm — the relevant quantum threat to symmetric encryption — reduces AES-256's effective security from 256 bits to approximately 128 bits. 128-bit security remains unbreakable by any known or projected quantum hardware. NIST explicitly confirms that AES with 128, 192, or 256-bit keys is secure against quantum attacks. Asymmetric algorithms like RSA are the ones facing genuine quantum risk.

What is the difference between AES-256-GCM and AES-256-CBC?

AES-256-GCM provides authenticated encryption (AEAD): it encrypts data and produces a message authentication code in a single pass, guaranteeing both confidentiality and integrity. AES-256-CBC encrypts only — without a separate MAC, it is vulnerable to padding oracle and bit-flipping attacks. TLS 1.3 removed CBC support entirely. For new deployments, GCM is the correct choice.

What is "Harvest Now, Decrypt Later" and should I be worried?

HNDL is a strategy where adversaries intercept and store encrypted data today, intending to decrypt it once quantum computers become capable. For data with a long sensitivity horizon — classified information, medical records, long-term financial data — this is a present risk. The mitigation is migrating asymmetric key exchange protocols to post-quantum algorithms (FIPS 203/204/205) now, while continuing to use AES-256 for symmetric encryption.

Why do organizations using AES-256 still get breached?

Because attackers bypass the encryption rather than breaking it. Stolen credentials, compromised endpoints, poor key management, insider threats, and overly broad access permissions all expose plaintext data without ever touching the cipher.

What is a zero-knowledge architecture in a password manager?

A zero-knowledge architecture means the server never receives or stores plaintext credentials or the keys to decrypt them. Encryption happens on the client (in the browser or application) before data is transmitted. Even if the server is fully compromised, the attacker obtains only ciphertext. This is the architecture required for any credential management tool handling sensitive corporate secrets.

Does AES-256 satisfy HIPAA, GDPR, and PCI DSS requirements?

Yes, for all three. HIPAA's Safe Harbor provision (45 CFR §164.312) designates AES-256 as a valid encryption standard for PHI. GDPR Article 32 requires appropriate technical measures including encryption — AES-256 satisfies this. PCI DSS Requirement 3 mandates strong cryptography for stored cardholder data, with AES-256 as the accepted standard. Compliance requires correct implementation, not just the presence of encryption.

Employee offboarding: Secure access revocation guide 2026

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

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

Secrets rotation lifecycle: From creation to revocation

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

Passwork BlogAlex Muntyan

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

Das neue Release führt Servicekonten, gespeicherte Filter, automatische Papierkorb-Bereinigung, eine mobile Version der Weboberfläche sowie eine Reihe weiterer Verbesserungen und Fehlerbehebungen ein.

Servicekonto

Passwork unterstützt jetzt einen neuen Kontotyp — Servicekonto. Diese sind für Automatisierung und Integration mit externen Systemen über API konzipiert. Im Gegensatz zu regulären Benutzerkonten kann ein einzelnes Servicekonto mehrere API-Token haben, die jeweils auf eine bestimmte Integration oder Umgebung beschränkt sind.

Warum Sie ein Servicekonto benötigen

Bisher erforderte jede Integration ein eigenes Konto. Zehn Integrationen bedeuteten zehn Konten, die erstellt, konfiguriert und gepflegt werden mussten — mit separaten Anmeldungen nur um Token zu generieren oder zu widerrufen.

Servicekonten lösen dieses Problem: Ein Konto, mehrere unabhängige Token, alle vom Administrator verwaltet. Widerrufen Sie ein Token für eine Integration und die übrigen laufen ohne Unterbrechung weiter.

So erstellen Sie ein Servicekonto

Servicekonten werden in der Benutzerverwaltung erstellt — am selben Ort wie reguläre Konten.

So erstellen Sie ein API-Token

Token werden in den Einstellungen eines bestimmten Service Accounts erstellt und widerrufen.

Neue Rollenberechtigungen

Drei neue Berechtigungen wurden zu den Rolleneinstellungen hinzugefügt:

• Service Accounts erstellen — ermöglicht das Erstellen von Service Accounts
• API-Token verwalten — ermöglicht das Generieren und Widerrufen von Token
• API-Token anzeigen — ermöglicht das Anzeigen vorhandener Token

Gespeicherte Filter

Benutzer können jetzt ihre ausgewählten Filter speichern und sofort erneut anwenden. Gespeicherte Filter sind privat — nur der Benutzer, der sie erstellt hat, kann sie sehen und verwenden.

Um die aktuellen Filtereinstellungen zu speichern, klicken Sie auf die Schaltfläche + im Filterauswahlmenü.

Automatische Papierkorb-Bereinigung

Passwork kann jetzt automatisch Elemente aus dem Papierkorb nach einem festgelegten Zeitraum löschen. Die neuen Einstellungen sind in den Tresor-Einstellungen verfügbar — aktivieren Sie die automatische Löschung und konfigurieren Sie die Aufbewahrungsdauer von 1 bis 1.461 Tagen (standardmäßig 30 Tage).

Nach Ablauf der Aufbewahrungsdauer werden Passwörter, Ordner und Shortcuts dauerhaft aus dem Papierkorb gelöscht.

Mobile Weboberfläche

Die Passwork-Weboberfläche passt sich jetzt an mobile Browser an. Beim Öffnen auf einem mobilen Gerät wechselt sie automatisch zum mobilen Layout.

Verbesserungen

• Verbesserte Links: Eine Webseite mit einem einmaligen oder abgelaufenen Link wechselt jetzt automatisch in den Status „Link abgelaufen" — 30 Minuten nach dem Öffnen oder Ablaufen, ohne dass die Seite aktualisiert werden muss.
• Die Schaltfläche „Mit Passkey anmelden" auf der Anmeldeseite wird jetzt ausgeblendet, wenn die Einstellung „Passkey anstelle von Passwort verwenden" für alle Rollen deaktiviert ist.
• Vereinfachte Browsererweiterungs-Verbindung: Unnötige Schritte zur Benutzerauswahl und erneuten Authentifizierung nach der Anmeldung in einer Web-Sitzung wurden entfernt.
• Verbesserte Anzeige des Sperrstatus für die Authentifizierungseinstellungen.
• Aktualisierte Standardwerte für Masterpasswort- und Authentifizierungssperrrichtlinien.
• Tooltips für lange Gruppennamen in den LDAP-Einstellungen hinzugefügt.
• Fehlende Tooltips für inaktive Oberflächenelemente hinzugefügt.
• Aktualisierte Tooltip-Anzeige zur Verbesserung der Lesbarkeit.
• Verschiedene UI-Verbesserungen und -Korrekturen.

Fehlerbehebungen

• Ein Problem wurde behoben, bei dem das Bearbeiten von Nicht-Passwort-Feldern eines Elements dessen Bedrohungsmarkierung im Sicherheits-Dashboard entfernte.
• Ein Problem wurde behoben, bei dem der Status der Authentifizierungsbeschränkungseinstellung für LDAP-Benutzer falsch angezeigt werden konnte.
• Ein Problem wurde behoben, bei dem Spaltenreihenfolge und -breite nicht zwischen Sitzungen gespeichert wurden.
• Ein Problem wurde behoben, bei dem Browser-Navigationsschaltflächen auf bestimmten Einstellungsseiten nicht mehr funktionierten.

Desktop-App 1.3.0

• Unterstützung für nicht-standardmäßige Ports in der Host-URL hinzugefügt.
• Verbesserter App-Update-Mechanismus und automatische Prüfung auf die neueste Version hinzugefügt.

EU-Cybersicherheits-Update Frühjahr 2026: Was sich geändert hat

Das Frühjahr 2026 brachte den bedeutendsten institutionellen Sicherheitsvorfall der EU, die ersten Cyber-Sanktionen des Jahres und vier große Cybersicherheitsverordnungen, die gleichzeitig in Kraft treten. NIS2, DORA, CRA und CSA2 setzen jetzt verbindliche Fristen — und echte Strafen. Hier erfahren Sie, was sich geändert hat, wer betroffen ist und was zu tun ist.

Passwork BlogAlex Muntyan

Bereitstellungsmodelle für Passwort-Manager: Cloud, Self-Hosted & Hybrid

Die Entscheidung, wo Ihr Passwort-Manager betrieben wird, ist genauso wichtig wie die Auswahl des richtigen Produkts. Dieser Leitfaden erläutert Cloud-, Self-Hosted- und Hybrid-Bereitstellung — mit einer Compliance-Matrix für DSGVO, HIPAA und NIS2 sowie einem klaren Überblick über die Kompromisse jedes Modells.

Passwork BlogAlex Muntyan

NIS2-Passwortanforderungen: Was europäische Unternehmen 2026 tun müssen

Credential-Lücken sind der häufigste NIS2-Audit-Fehlergrund im Jahr 2026. Dieser Leitfaden behandelt die Passwortanforderungen nach Artikel 21, die Ausrichtung an NIST SP 800-63B, AD-Härtungsschritte und die Audit-Nachweise, die Regulierungsbehörden zuerst anfordern.

Passwork BlogAlex Muntyan

La nueva versión introduce cuentas de servicio, filtros guardados, limpieza automática de la papelera, una versión móvil de la interfaz web y varias mejoras y correcciones adicionales.

Cuentas de servicio

Passwork ahora admite un nuevo tipo de cuenta — cuentas de servicio. Están diseñadas para la automatización e integración con sistemas externos a través de API. A diferencia de las cuentas de usuario regulares, una sola cuenta de servicio puede tener múltiples tokens de API, cada uno con un alcance específico para una integración o entorno determinado.

Por qué necesita una cuenta de servicio

Anteriormente, cada integración requería su propia cuenta. Diez integraciones significaban diez cuentas que crear, configurar y mantener — con inicios de sesión separados necesarios solo para generar o revocar tokens.

Las cuentas de servicio resuelven esto: una cuenta, múltiples tokens independientes, todos gestionados por el administrador. Revoque un token para una integración y el resto seguirá funcionando sin interrupción.

Cómo crear una cuenta de servicio

Las cuentas de servicio se crean en la Gestión de usuarios — el mismo lugar que las cuentas regulares.

Cómo crear un token de API

Los tokens se crean y revocan en la configuración de una cuenta de servicio específica.

Nuevos permisos de rol

Se han añadido tres nuevos permisos a la configuración de roles:

• Crear cuentas de servicio — permite crear cuentas de servicio.
• Gestionar tokens de API — permite generar y revocar tokens.
• Ver tokens de API — permite visualizar los tokens existentes.

Filtros guardados

Los usuarios ahora pueden guardar los filtros seleccionados y volver a aplicarlos de forma instantánea. Los filtros guardados son privados — solo el usuario que los creó puede verlos y utilizarlos.

Para guardar la configuración del filtro actual, haga clic en el botón + en el menú de selección de filtros.

Limpieza automática de la papelera

Passwork ahora puede eliminar automáticamente los elementos de la papelera después de un período establecido. Las nuevas opciones están disponibles en Configuración de bóvedas — active la eliminación automática y configure el período de retención de 1 a 1.461 días (30 días por defecto).

Una vez que expire el período de retención, las contraseñas, carpetas y accesos directos se eliminan permanentemente de la papelera.

Interfaz web móvil

La interfaz web de Passwork ahora se adapta a los navegadores móviles. Al abrirla en un dispositivo móvil, cambia automáticamente al diseño móvil.

Mejoras

• Enlaces mejorados: una página web con un enlace de un solo uso o caducado ahora pasa automáticamente al estado «Enlace caducado» 30 minutos después de abrirse o caducar, sin necesidad de actualizar la página.
• El botón «Iniciar sesión con passkey» en la página de inicio de sesión ahora se oculta si la opción «Usar passkey en lugar de contraseña» está desactivada para todos los roles.
• Conexión simplificada de la extensión del navegador: se eliminaron los pasos innecesarios para seleccionar un usuario y volver a autenticarse después de iniciar sesión en una sesión web.
• Se mejoró la visualización del estado de bloqueo para la configuración de autenticación.
• Se actualizaron los valores predeterminados para las políticas de bloqueo de contraseña maestra y autenticación.
• Se añadieron tooltips para nombres de grupos largos en la configuración de LDAP.
• Se añadieron tooltips faltantes para elementos de interfaz inactivos.
• Se actualizó la visualización de tooltips para mejorar la legibilidad.
• Se realizaron varias mejoras y correcciones de la interfaz de usuario.

Corrección de errores

• Se corrigió un problema donde editar campos que no son contraseña de un elemento eliminaba su marca de amenaza en el panel de seguridad.
• Se corrigió un problema donde el estado de la configuración de restricción de autenticación para usuarios de LDAP podía mostrarse incorrectamente.
• Se corrigió un problema donde el orden y ancho de las columnas no se guardaban entre sesiones.
• Se corrigió un problema donde los botones de navegación del navegador dejaban de funcionar en ciertas páginas de configuración.

Aplicación de escritorio 1.3.0

• Se añadió compatibilidad con puertos no estándar en la URL del host.
• Se mejoró el mecanismo de actualización de la aplicación y se añadieron comprobaciones automáticas de la última versión.

Actualización de ciberseguridad de la UE primavera 2026: Qué ha cambiado

La primavera de 2026 trajo la brecha institucional más significativa de la UE, sus primeras sanciones cibernéticas del año y cuatro regulaciones importantes de ciberseguridad aplicándose simultáneamente. NIS2, DORA, CRA y CSA2 ahora establecen plazos firmes — y sanciones reales. Esto es lo que cambió, a quién afecta y qué hacer.

Passwork BlogAlex Muntyan

Modelos de implementación de gestores de contraseñas: Nube, autoalojado e híbrido

Elegir dónde ejecutar su gestor de contraseñas es tan importante como elegir cuál usar. Esta guía analiza la implementación en la nube, autoalojada e híbrida — con una matriz de cumplimiento para GDPR, HIPAA y NIS2, y una visión clara de las ventajas y desventajas de cada modelo.

Passwork BlogAlex Muntyan

Requisitos de contraseñas de NIS2: Lo que las empresas europeas deben hacer en 2026

Las brechas de credenciales son el principal punto de fallo en las auditorías de 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

The new release introduces service accounts, saved filters, automatic Bin cleanup, a mobile version of the web interface, and a number of other improvements and fixes.

Service accounts

Passwork now supports a new account type — service accounts. They are designed for automation and integration with external systems via API. Unlike regular user accounts, a single service account can have multiple API tokens, each scoped to a specific integration or environment.

Why you need a service account

Previously, each integration required its own account. Ten integrations meant ten accounts to create, configure, and maintain — with separate sign-ins needed just to generate or revoke tokens.

Service accounts solve this: one account, multiple independent tokens, all managed by the administrator. Revoke a token for one integration and the rest keep running without interruption.

How to create a service account

Service accounts are created in the User management — the same place as regular accounts.

How to create an API token

Tokens are created and revoked in the settings of a specific service account.

New role permissions

Three new permissions have been added to role settings:

• Create service accounts — allows creating service accounts
• Manage API tokens — allows generating and revoking tokens
• View API tokens — allows viewing existing tokens

Saved filters

Users can now save their selected filters and reapply them instantly. Saved filters are private — only the user who created them can see and use them.

To save the current filter settings, click the + button in the filter selection menu.

Automatic Bin cleanup

Passwork can now automatically delete items from the Bin after a set period. The new settings are available in Vaults settings — enable automatic deletion and configure the retention period from 1 to 1,461 days (30 days by default).

Once the retention period expires, passwords, folders, and shortcuts are permanently deleted from the Bin.

Mobile web interface

The Passwork web interface now adapts to mobile browsers. When opened on a mobile device, it switches to the mobile layout automatically.

Improvements

• Improved links: a webpage with a one-time or expired link now automatically transitions to the "Link expired" state 30 minutes after being opened or expiring, without requiring a page refresh
• The "Sign in with passkey" button on the sign-in page is now hidden if the "Use passkey instead of password" setting is disabled for all roles
• Simplified browser extension connection: removed unnecessary steps for selecting a user and re-authenticating after signing into a web session
• Improved the display of the lock state for the Authentication settings
• Updated the default values for master password and authentication lockout policies
• Added tooltips for long group names in LDAP settings
• Added missing tooltips for inactive interface element
• Updated the tooltip display to improve readability
• Made various UI improvements and fixes

Bug fixes

• Fixed an issue where editing non-password fields of a item removed its threat flag in the Security dashboard
• Fixed an issue where the state of the authentication restriction setting for LDAP users could be displayed incorrectly
• Fixed an issue where column order and width were not saved between sessions
• Fixed an issue where browser navigation buttons stopped working in certain settings pages

Desktop app 1.3.0

• Added support for non-standard ports in the host URL
• Improved the app update mechanism and added automatic checks for the latest version

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

Password Manager Deployment Models: Cloud, Self-Hosted & Hybrid

Choosing where to run your password manager matters as much as choosing which one. This guide breaks down cloud, self-hosted, and hybrid deployment — with a compliance matrix for GDPR, HIPAA, and NIS2, and a clear look at the trade-offs each model carries.

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

La mayoría de las filtraciones de datos comienzan de la misma manera: con credenciales débiles o mal gestionadas. Solo en ataques básicos a aplicaciones web, el informe DBIR 2025 de Verizon rastreó el 88% de los incidentes hasta contraseñas robadas. Para cualquier organización que maneje datos sensibles, la seguridad informática comienza con el control de credenciales. Y la seguridad de contraseñas ha pasado de ser una recomendación a convertirse en un requisito básico.

Un gestor de contraseñas aborda este riesgo. Para cada cuenta, genera, almacena y completa automáticamente credenciales únicas — todo protegido por una contraseña maestra. En lugar de hojas de cálculo, notas adhesivas y restablecimientos de contraseña repetidos, los equipos obtienen un proceso controlado y auditable en todo el flujo de trabajo.

Puntos principales:

• Una contraseña maestra reemplaza cientos de credenciales débiles y reutilizadas
• El cifrado AES-256 y la arquitectura de conocimiento cero mantienen su bóveda ilegible, incluso para el proveedor
• La configuración requiere planificación, pero la recompensa son menos tickets de soporte, mayor cumplimiento normativo y menor riesgo de filtraciones

Comprender los gestores de contraseñas

Un gestor de contraseñas funciona como una bóveda cifrada — una caja fuerte digital que almacena credenciales de inicio de sesión, notas seguras y otros datos sensibles. Cuando inicia sesión en algún lugar, el gestor recupera la contraseña correcta y completa el formulario automáticamente. Detrás de esa bóveda hay dos tecnologías: cifrado y arquitectura de conocimiento cero.

Cómo los gestores de contraseñas protegen su identidad digital

Antes de que los datos salgan de su dispositivo, el cifrado AES-256 (Estándar de Cifrado Avanzado con una clave de 256 bits) los convierte en texto cifrado ilegible. El mismo algoritmo es utilizado por gobiernos e instituciones financieras.

La arquitectura de conocimiento cero añade una segunda capa. Bajo este modelo, el proveedor no puede descifrar sus datos. Debido a que todas las operaciones criptográficas ocurren localmente, incluso el acceso completo al servidor solo revelaría bloques cifrados. Publicamos nuestra documentación de criptografía abiertamente para que los equipos puedan verificar exactamente cómo funciona.

Qué pueden y qué no pueden hacer los gestores de contraseñas

Un gestor de contraseñas es una capa de defensa confiable, aunque no cubre todas las amenazas por sí solo. Conocer sus limitaciones ayuda a planificar salvaguardas adicionales.

La autenticación multifactor (MFA) añade un segundo paso de verificación, como una contraseña de un solo uso basada en tiempo (TOTP), y aborda brechas que un gestor de contraseñas por sí solo no puede cubrir. Juntos, forman una defensa mucho más sólida.

Crear su contraseña maestra

Su contraseña maestra es la única credencial que desbloquea toda la bóveda — una débil socava todas las demás medidas de seguridad.

Publicado en agosto de 2025, NIST SP 800-63B-4 establece una longitud mínima de 15 caracteres para contraseñas utilizadas como autenticador de factor único. La misma revisión indica que los verificadores no deben imponer reglas de composición de contraseñas (por ejemplo, requerir letras mayúsculas, números o símbolos) y en su lugar deben comparar las contraseñas con listas de valores comúnmente usados o comprometidos. Una contraseña como "P@ssw0rd123" no pasaría dicha verificación.

En lugar de requisitos aleatorios de caracteres, el método de frase de contraseña funciona mejor: elija cuatro o cinco palabras no relacionadas y combínelas. Un generador de contraseñas puede producir combinaciones de palabras aleatorias, pero muchos usuarios prefieren la selección manual. "correct-horse-battery-staple" es un ejemplo clásico — alta entropía.

Creación de contraseña maestra paso a paso:

1. Elija 4-5 palabras aleatorias y no relacionadas (evite letras de canciones o citas famosas)
2. Añada un separador entre palabras (guiones, puntos o espacios)
3. Opcionalmente inserte un número o símbolo en una posición aleatoria — no al final
4. Pruebe: ¿puede escribirla de memoria tres veces seguidas?
5. Escríbala una vez, guarde ese papel en un lugar físicamente seguro, luego memorícela en una semana

Mejores prácticas para la contraseña maestra

Haga:

• Memorícela, nunca la almacene digitalmente en texto plano
• Mantenga una copia de seguridad física en un lugar seguro (un sobre sellado en una caja fuerte, por ejemplo)
• Practique escribirla regularmente durante la primera semana

No haga:

• Reutilizar su contraseña maestra para cualquier otra cuenta
• Compartirla con nadie, incluido el personal de TI
• Cambiarla en un horario fijo sin razón: según NIST SP 800-63B-4, las contraseñas solo deben cambiarse cuando existe evidencia de compromiso

Las opciones de recuperación son limitadas por diseño. Con una arquitectura de conocimiento cero, el proveedor no puede restablecer su contraseña maestra porque nunca tuvo acceso a ella.

Elegir el gestor de contraseñas adecuado para sus necesidades

Antes de comprometerse con cualquier software de gestión de contraseñas, defina lo que su organización realmente necesita. El modelo de implementación, los estándares de cifrado y la integración con la infraestructura existente deben ser factores en la decisión.

Cuando la flexibilidad de implementación y la arquitectura de seguridad importan, deben estar disponibles tanto las opciones locales como en la nube. Passwork admite ambos modelos, para que pueda elegir dónde residen sus datos. La plataforma cuenta con una interfaz fácil de usar que los equipos pueden adoptar rápidamente. Combina la gestión de contraseñas con la gestión de secretos de DevOps, claves API, tokens y certificados en un solo sistema.

Si está evaluando múltiples soluciones, vea cómo funcionamos en un escenario de implementación real. Obtenga un entorno de demostración y pruebe junto con otros gestores de contraseñas empresariales. No se requiere tarjeta de crédito.

Gestores de contraseñas basados en navegador vs. dedicados

Los gestores de contraseñas integrados en el navegador (como los de Chrome o Edge) son convenientes, pero carecen de funciones empresariales. Dentro de un único perfil de navegador, las credenciales permanecen aisladas — el uso compartido, el acceso basado en roles y el registro de auditoría están ausentes o limitados.

Con un gestor de contraseñas dedicado, el cifrado ocurre independientemente del navegador, junto con controles de acceso granulares y sincronización multiplataforma. El autocompletado y la captura de credenciales aún se ejecutan a través de una extensión del navegador, pero la bóveda se encuentra en un entorno más controlado.

Comenzar con su gestor de contraseñas

Con la contraseña maestra lista y la solución seleccionada, comienza la configuración. El proceso sigue un camino predecible.

1. Instale la aplicación principal: cliente de escritorio, interfaz web o instancia autoalojada
2. Cree su cuenta con la contraseña maestra que preparó
3. Habilite MFA inmediatamente antes de añadir cualquier credencial a la bóveda
4. Instale extensiones del navegador para Chrome, Firefox, Edge o Safari
5. Instale aplicaciones móviles para iOS y Android si necesita acceso remoto
6. Configure la estructura de la bóveda: cree bóvedas compartidas y personales por departamento, proyecto o nivel de acceso

Configurar extensiones del navegador y aplicaciones móviles

Después de instalar la extensión, ajuste algunos parámetros:

• Habilite el bloqueo automático después de inactividad — cinco minutos es un valor predeterminado razonable
• Active el bloqueo por PIN o biométrico para la aplicación móvil
• Confirme que la extensión se conecta a la URL correcta del servidor (requerido para implementaciones locales)
• Desactive el autocompletado en dispositivos públicos o compartidos

Una contraseña guardada en su portátil aparece en su teléfono en segundos a través de la sincronización multiplataforma. Todos los datos viajan cifrados, por lo que incluso un paquete de sincronización interceptado es inútil sin la contraseña maestra.

Configurar la autenticación de dos factores para su gestor de contraseñas

MFA añade un segundo bloqueo a su bóveda a través de un paso adicional de verificación de seguridad. Incluso si alguien descubre su contraseña maestra, el acceso aún requiere ese segundo factor.

Las aplicaciones de autenticación (Google Authenticator, Authy) generan códigos TOTP de seis dígitos que se actualizan cada 30 segundos. Durante la configuración, escanee el código QR, verifique el primer código y guarde los códigos de recuperación de respaldo en un lugar físicamente seguro. Sin esos códigos, perder su teléfono podría significar perder el acceso a la bóveda.

Importar y organizar sus contraseñas existentes

La migración desde navegadores, hojas de cálculo u otro gestor de contraseñas a su bóveda de almacenamiento de contraseñas generalmente comienza con una exportación CSV (valores separados por comas). La mayoría de los gestores aceptan este formato y mapean campos (URL, nombre de usuario, contraseña) automáticamente.

Antes de importar, audite lo que tiene. Cuentas antiguas, entradas duplicadas y credenciales reutilizadas en varios servicios necesitan atención. La etapa de importación es el momento ideal para reemplazar contraseñas débiles por otras generadas.

Las herramientas de administración permiten configurar estructuras de bóveda que reflejan la organización de su equipo. Con acceso basado en roles, el equipo de finanzas ve solo las credenciales de finanzas, mientras que los administradores de TI mantienen supervisión de todo. Esta combinación con un enfoque rentable le proporciona control de nivel empresarial sin pagar por funciones que no necesita.

Para equipos que implementan gestión de contraseñas por primera vez, configurar la estructura correcta desde el principio previene futuros problemas de acceso. Reserve una consulta para definir su modelo de acceso, enfoque de implementación y plan de despliegue.

Priorizar sus cuentas más críticas

No todas las cuentas conllevan el mismo riesgo. Comience la migración con las credenciales que causarían más daño si se vieran comprometidas:

1. Cuentas de correo electrónico principales (a menudo el método de recuperación para todo lo demás)
2. Servicios financieros y plataformas de pago
3. Infraestructura en la nube y paneles de administración
4. Herramientas de comunicación empresarial (Slack, Teams, servidores de correo)
5. Redes sociales y cuentas públicas

Según el Informe del Costo de una Filtración de Datos 2025 de IBM, el costo promedio global de una filtración alcanzó los 4,44 millones de dólares, y el tiempo promedio para identificar y contener un incidente fue de 241 días. La migración temprana de cuentas de alto valor reduce esa ventana de exposición.

Usar herramientas de salud de contraseñas y filtraciones de datos

Una vez que las credenciales están en la bóveda, ejecute un informe de salud de la bóveda de contraseñas — una verificación rutinaria de seguridad informática. El monitoreo integrado de filtraciones de datos escanea sus entradas contra bases de datos de filtraciones conocidas, mientras que la detección de contraseñas comprometidas marca credenciales reutilizadas o débiles. Aborde primero los hallazgos críticos, especialmente cualquier cuenta donde la misma contraseña proteja múltiples servicios.

Generar y gestionar contraseñas seguras

Para cada nueva cuenta o reemplazo de contraseña, use el generador de contraseñas integrado. Una configuración sólida para cuentas de alta seguridad: más de 20 caracteres, mayúsculas y minúsculas mezcladas, números y símbolos. Donde los servicios impongan límites de caracteres, ajuste — pero nunca baje de 15 caracteres.

Una contraseña generada como "g7#Kp!2xVmNqR9bW" no tiene estructura predecible, lo que hace que los ataques de fuerza bruta sean impracticables. El gestor de contraseñas la recuerda, por lo que la complejidad no cuesta nada en usabilidad.

Usar las funciones de autocompletado de forma segura

El autocompletado acelera el llenado de formularios, pero requiere atención. Antes de dejar que la extensión complete un inicio de sesión, verifique estos indicadores:

• La URL en la barra de direcciones coincide exactamente con el dominio esperado
• La conexión usa HTTPS (busque el icono del candado)
• El gestor de contraseñas reconoce el sitio; si no ofrece autocompletado, el dominio puede estar falsificado
• No ocurrieron redirecciones inesperadas antes de que cargara la página de inicio de sesión

Una página de phishing en g00gle.com parece convincente, pero el gestor de contraseñas coincide con dominios exactos y no autocompletará en un sitio falso. En dispositivos personales y de trabajo, mantenga la extensión bloqueada cuando no esté en uso activo.

Compartir contraseñas de forma segura con otros

Para cuentas conjuntas, paneles de administración y servicios de terceros, los equipos necesitan compartir credenciales. Enviar contraseñas por correo electrónico, Slack o mensajes de texto es el enfoque incorrecto. A través de las funciones de uso compartido integradas, el cifrado permanece intacto — las credenciales permanecen protegidas en tránsito.

Los controles de acceso basados en roles están diseñados para gestionar credenciales específicas de departamento y acceso temporal de contratistas. Con la implementación local, los secretos compartidos nunca transitan a través de servidores externos. Obtenga más información sobre el enfoque de gestión de contraseñas empresariales.

Gestionar el acceso familiar y de equipo

Las bóvedas de contraseñas compartidas funcionan como carpetas compartidas: cada bóveda tiene sus propios permisos de acceso. Un administrador de TI podría tener acceso completo, mientras que un miembro del equipo de marketing ve solo la bóveda de credenciales de redes sociales. Según el GDPR, las organizaciones deben tanto proteger los datos personales del acceso no autorizado como demostrar que esa protección está implementada. Los controles de acceso granulares y los registros de auditoría abordan ambos requisitos a la vez.

Funciones avanzadas que vale la pena usar

Más allá de almacenar contraseñas, la mayoría de los gestores de contraseñas empresariales incluyen funciones que los equipos a menudo pasan por alto. Las notas seguras permiten almacenar credenciales Wi-Fi, detalles del servidor, claves de licencia de software o códigos de recuperación — todo protegido por cifrado AES-256.

A través de la integración SSO (Single Sign-On), el gestor de contraseñas se conecta con su proveedor de identidad, reduciendo la fricción para usuarios que ya se autentican a través de AD o LDAP. Los registros de auditoría rastrean cada acción: quién accedió a qué credencial, cuándo y desde qué dispositivo — esto simplifica los informes de GDPR y PCI-DSS (Estándar de Seguridad de Datos de la Industria de Tarjetas de Pago).

Notas seguras y almacenamiento de documentos

Claves Secure Shell (SSH), tokens API, frases de recuperación o procedimientos internos — todo esto pertenece a las notas seguras en lugar de estar disperso en hilos de correo electrónico o unidades compartidas. El cifrado los protege de manera idéntica a las contraseñas, y los controles de acceso determinan quién ve qué.

Sincronización de dispositivos y gestión de acceso

Cuando un miembro del equipo actualiza una contraseña en su portátil, cada dispositivo autorizado refleja ese cambio en segundos. Cifrados en tránsito, los datos viajan al servidor (o su instancia local) y llegan a otros dispositivos aún protegidos. El descifrado ocurre solo localmente.

La gestión adecuada de dispositivos requiere verificación MFA antes de que cualquier dispositivo nuevo obtenga acceso a la bóveda. Sin este paso, un atacante que clone un token de sesión podría alcanzar silenciosamente las credenciales almacenadas.

Solución de problemas comunes del gestor de contraseñas

Mantener su seguridad de contraseñas a largo plazo

La seguridad no es una configuración única. Las revisiones trimestrales mantienen su bóveda en buen estado:

1. Ejecute la auditoría de seguridad de la bóveda para identificar contraseñas débiles, reutilizadas o antiguas
2. Reemplace cualquier credencial marcada usando el generador de contraseñas integrado
3. Revise el acceso a la bóveda compartida — elimine exempleados o contratistas
4. Verifique que MFA siga activo y que los códigos de respaldo sean accesibles
5. Compruebe si hay cuentas en bases de datos de filtraciones conocidas y rote esas contraseñas inmediatamente

Qué hacer si su gestor de contraseñas se ve comprometido

Si sospecha que su contraseña maestra ha sido expuesta, el control de daños inmediato es crítico para su seguridad informática:

1. Cambie la contraseña maestra inmediatamente desde un dispositivo de confianza
2. Habilite o vuelva a verificar MFA en la cuenta de la bóveda
3. Rote las contraseñas de sus cuentas de mayor prioridad (correo electrónico, financieras, infraestructura)
4. Revise el registro de auditoría de la bóveda en busca de accesos no autorizados
5. Notifique a su equipo de seguridad y comience una respuesta a incidentes según el protocolo de su organización

Conclusión: sus próximos pasos hacia la seguridad de contraseñas

Un gestor de contraseñas reemplaza las conjeturas con estructura, una mejora directa a la protección digital de su organización. En lugar de esperar que los empleados elijan contraseñas seguras, les proporciona una herramienta que lo hace automáticamente y mantiene cada credencial cifrada, auditable y bajo control.

El primer paso es el más simple: elija una solución, cree una contraseña maestra fuerte y comience a migrar sus cuentas más críticas hoy.

Preguntas frecuentes

Passwork: Gestión de secretos y automatización para DevOps

Introducción En el entorno corporativo, el número de contraseñas, claves y certificados digitales está aumentando rápidamente, y la gestión de secretos se está convirtiendo en una de las tareas críticas para los equipos de TI. La gestión de secretos aborda el ciclo de vida completo de los datos sensibles: desde la generación segura y el almacenamiento cifrado hasta la rotación automatizada y los registros de auditoría. A medida que

Passwork BlogEirik Salmi

¿Qué es la gestión de contraseñas?

Aprenda qué es la gestión de contraseñas, por qué es importante y cómo protege sus cuentas con cifrado, almacenamiento seguro y control de acceso.

Passwork BlogEirik Salmi

Passwork 7.1: Tipos de bóvedas

Tipos de bóvedas Passwork 7.1 introduce una arquitectura robusta de tipos de bóvedas, proporcionando control de acceso de nivel empresarial para mayor seguridad y gestión. Los tipos de bóvedas abordan un desafío clave para los administradores: controlar el acceso a datos y delegar la gestión de bóvedas en grandes organizaciones. Anteriormente, la elección estaba limitada a dos tipos. Ahora, puede crear

Passwork BlogEirik Salmi

Die meisten Datenschutzverletzungen beginnen auf dieselbe Weise: mit schwachen oder schlecht verwalteten Anmeldedaten. Allein bei einfachen Angriffen auf Webanwendungen führte der 2025 Verizon DBIR 88 % der Vorfälle auf gestohlene Passwörter zurück. Für jede Organisation, die mit sensiblen Daten umgeht, beginnt Computersicherheit mit der Kontrolle von Anmeldedaten. Und Passwortsicherheit ist über eine Empfehlung hinausgegangen und zu einer grundlegenden Anforderung geworden.

Ein Passwort-Manager adressiert dieses Risiko. Für jedes Konto generiert, speichert und füllt er automatisch einzigartige Anmeldedaten aus — alles geschützt durch ein Masterpasswort. Anstelle von Tabellen, Haftnotizen und wiederholten Passwort-Zurücksetzungen erhalten Teams einen kontrollierten und auditierbaren Prozess über den gesamten Arbeitsablauf.

Wichtigste Punkte:

• Ein Masterpasswort ersetzt Hunderte von schwachen, wiederverwendeten Anmeldedaten
• AES-256-Verschlüsselung und Zero-Knowledge-Architektur halten Ihren Tresor unlesbar — selbst für den Anbieter
• Die Einrichtung erfordert Planung, aber der Nutzen sind weniger Support-Tickets, stärkere Compliance und reduziertes Risiko von Datenschutzverletzungen

Passwort-Manager verstehen

Ein Passwort-Manager funktioniert als verschlüsselter Tresor — ein digitaler Safe, der Anmeldedaten, sichere Notizen und andere sensible Daten speichert. Wenn Sie sich irgendwo anmelden, ruft der Manager das richtige Passwort ab und füllt das Formular automatisch aus. Hinter diesem Tresor stehen zwei Technologien: Verschlüsselung und Zero-Knowledge-Architektur.

Wie Passwort-Manager Ihre digitale Identität schützen

Bevor Daten Ihr Gerät verlassen, verschlüsselt die AES-256-Verschlüsselung (Advanced Encryption Standard mit einem 256-Bit-Schlüssel) sie in unlesbaren Chiffretext. Der gleiche Algorithmus wird von Regierungen und Finanzinstitutionen verwendet.

Zero-Knowledge-Architektur fügt eine zweite Schicht hinzu. Unter diesem Modell kann der Anbieter Ihre Daten nicht entschlüsseln. Da alle kryptografischen Operationen lokal stattfinden, würde selbst voller Serverzugriff nur verschlüsselte Blobs offenbaren. Wir veröffentlichen unsere Kryptografie-Dokumentation offen, damit Teams genau überprüfen können, wie dies funktioniert.

Was Passwort-Manager können und was nicht

Ein Passwort-Manager ist eine zuverlässige Verteidigungsschicht, deckt aber nicht jede Bedrohung allein ab. Das Wissen um seine Grenzen hilft Ihnen, zusätzliche Schutzmaßnahmen zu planen.

Multi-Faktor-Authentifizierung (MFA) fügt einen zweiten Verifizierungsschritt hinzu, wie ein zeitbasiertes Einmalpasswort (TOTP), und adressiert Lücken, die ein Passwort-Manager allein nicht abdecken kann. Zusammen bilden sie eine wesentlich stärkere Verteidigung.

Ihr Masterpasswort erstellen

Ihr Masterpasswort ist die einzige Anmeldeinformation, die den gesamten Tresor entsperrt — ein schwaches untergräbt jede andere Sicherheitsmaßnahme.

Im August 2025 veröffentlicht, legt NIST SP 800-63B-4 eine Mindestlänge von 15 Zeichen für Passwörter fest, die als Einzelfaktor-Authentifikator verwendet werden. Die gleiche Überarbeitung besagt, dass Prüfer keine Passwort-Zusammensetzungsregeln auferlegen sollen (z. B. Großbuchstaben, Zahlen oder Symbole erforderlich) und stattdessen Passwörter gegen Listen häufig verwendeter oder kompromittierter Werte prüfen müssen. Ein Passwort wie „P@ssw0rd123" würde eine solche Prüfung nicht bestehen.

Anstelle zufälliger Zeichenanforderungen funktioniert die Passphrasen-Methode besser: Wählen Sie vier oder fünf unzusammenhängende Wörter und kombinieren Sie diese. Ein Passwort-Generator kann zufällige Wortkombinationen erzeugen, aber viele Benutzer bevorzugen manuelle Auswahl. „correct-horse-battery-staple" ist ein klassisches Beispiel — hohe Entropie.

Schritt-für-Schritt-Anleitung zur Masterpasswort-Erstellung:

1. Wählen Sie 4–5 zufällige, unzusammenhängende Wörter (vermeiden Sie Songtexte oder berühmte Zitate)
2. Fügen Sie ein Trennzeichen zwischen den Wörtern hinzu (Bindestriche, Punkte oder Leerzeichen)
3. Fügen Sie optional eine Zahl oder ein Symbol an einer zufälligen Position ein — nicht am Ende
4. Test: Können Sie es dreimal hintereinander aus dem Gedächtnis eingeben?
5. Schreiben Sie es einmal auf, bewahren Sie das Papier an einem physisch sicheren Ort auf, dann prägen Sie es sich innerhalb einer Woche ein

Best Practices für Masterpasswörter

Tun Sie:

• Prägen Sie es sich ein, speichern Sie es niemals digital im Klartext
• Bewahren Sie eine physische Sicherungskopie an einem sicheren Ort auf (z. B. ein versiegelter Umschlag in einem Safe)
• Üben Sie das Eintippen regelmäßig in der ersten Woche

Vermeiden Sie:

• Ihr Masterpasswort für ein anderes Konto wiederzuverwenden
• Es mit jemandem zu teilen, einschließlich IT-Personal
• Es nach festem Zeitplan ohne Grund zu ändern: Laut NIST SP 800-63B-4 sollten Passwörter nur geändert werden, wenn Hinweise auf eine Kompromittierung vorliegen

Wiederherstellungsoptionen sind konstruktionsbedingt begrenzt. Bei einer Zero-Knowledge-Architektur kann der Anbieter Ihr Masterpasswort nicht zurücksetzen, weil er niemals Zugang dazu hatte.

Den richtigen Passwort-Manager für Ihre Anforderungen wählen

Bevor Sie sich für eine Passwortverwaltungs-Software entscheiden, definieren Sie, was Ihre Organisation tatsächlich benötigt. Bereitstellungsmodell, Verschlüsselungsstandards und Integration in die bestehende Infrastruktur sollten alle in die Entscheidung einfließen.

Wenn Bereitstellungsflexibilität und Sicherheitsarchitektur wichtig sind, sollten sowohl On-Premise- als auch Cloud-Optionen verfügbar sein. Passwork unterstützt beide Modelle, sodass Sie wählen können, wo Ihre Daten liegen. Die Plattform verfügt über eine benutzerfreundliche Oberfläche, die Teams schnell übernehmen können. Sie kombiniert Passwortverwaltung mit DevOps-Secrets-Management, API-Schlüsseln, Tokens und Zertifikaten in einem System.

Wenn Sie mehrere Lösungen evaluieren, sehen Sie, wie wir in einem realen Bereitstellungsszenario abschneiden. Holen Sie sich eine Demo-Umgebung und testen Sie neben anderen Enterprise-Passwort-Managern. Keine Kreditkarte erforderlich.

Browserbasierte vs. dedizierte Passwort-Manager

In Browser integrierte Passwort-Manager (wie die in Chrome oder Edge) sind praktisch, aber es fehlen ihnen Enterprise-Funktionen. Innerhalb eines einzelnen Browserprofils bleiben Anmeldedaten isoliert — Teilen, rollenbasierter Zugriff und Audit-Protokollierung sind entweder nicht vorhanden oder begrenzt.

Mit einem dedizierten Passwort-Manager erfolgt die Verschlüsselung unabhängig vom Browser, zusammen mit granularen Zugriffskontrollen und plattformübergreifender Synchronisierung. Automatisches Ausfüllen und Erfassen von Anmeldedaten laufen weiterhin über eine Browser-Erweiterung, aber der Tresor befindet sich in einer kontrollierteren Umgebung.

Erste Schritte mit Ihrem Passwort-Manager

Mit dem vorbereiteten Masterpasswort und der ausgewählten Lösung beginnt die Einrichtung. Der Prozess folgt einem vorhersehbaren Ablauf.

1. Installieren Sie die Kernanwendung: Desktop-Client, Web-Oberfläche oder selbst gehostete Instanz
2. Erstellen Sie Ihr Konto mit dem Masterpasswort, das Sie vorbereitet haben
3. Aktivieren Sie MFA sofort, bevor Sie Anmeldedaten zum Tresor hinzufügen
4. Installieren Sie Browser-Erweiterungen für Chrome, Firefox, Edge oder Safari
5. Installieren Sie mobile Apps für iOS und Android, wenn Fernzugriff benötigt wird
6. Konfigurieren Sie die Tresor-Struktur: Erstellen Sie geteilte und persönliche Tresore nach Abteilung, Projekt oder Zugangslevel

Browser-Erweiterungen und mobile Apps einrichten

Nach der Installation der Erweiterung passen Sie einige Einstellungen an:

• Aktivieren Sie die automatische Sperre nach Inaktivität — fünf Minuten ist ein vernünftiger Standard
• Aktivieren Sie PIN- oder biometrische Sperre für die mobile App
• Bestätigen Sie, dass die Erweiterung mit der richtigen Server-URL verbunden ist (erforderlich für On-Premise-Bereitstellungen)
• Deaktivieren Sie das automatische Ausfüllen auf öffentlichen oder gemeinsam genutzten Geräten

Ein auf Ihrem Laptop gespeichertes Passwort erscheint durch plattformübergreifende Synchronisierung innerhalb von Sekunden auf Ihrem Telefon. Alle Daten werden verschlüsselt übertragen, sodass selbst ein abgefangenes Sync-Paket ohne das Masterpasswort nutzlos ist.

Zwei-Faktor-Authentifizierung für Ihren Passwort-Manager einrichten

MFA fügt Ihrem Tresor durch einen zusätzlichen Sicherheitsverifizierungsschritt ein zweites Schloss hinzu. Selbst wenn jemand Ihr Masterpasswort erfährt, erfordert der Zugang immer noch diesen zweiten Faktor.

Authenticator-Apps (Google Authenticator, Authy) generieren sechsstellige TOTP-Codes, die alle 30 Sekunden aktualisiert werden. Scannen Sie während der Einrichtung den QR-Code, verifizieren Sie den ersten Code und speichern Sie die Backup-Wiederherstellungscodes an einem physisch sicheren Ort. Ohne diese Codes könnte der Verlust Ihres Telefons den Verlust des Tresorzugangs bedeuten.

Importieren und Organisieren Ihrer vorhandenen Passwörter

Die Migration von Browsern, Tabellen oder einem anderen Passwort-Manager in Ihren Passwortspeicher-Tresor beginnt normalerweise mit einem CSV-Export (Comma-Separated Values). Die meisten Manager akzeptieren dieses Format und ordnen Felder (URL, Benutzername, Passwort) automatisch zu.

Vor dem Import prüfen Sie, was Sie haben. Alte Konten, doppelte Einträge und über Dienste hinweg wiederverwendete Anmeldedaten erfordern alle Aufmerksamkeit. Die Importphase ist der ideale Zeitpunkt, um schwache Passwörter durch generierte zu ersetzen.

Unsere Admin-Tools ermöglichen es Ihnen, Tresor-Strukturen zu konfigurieren, die die Organisation Ihres Teams widerspiegeln. Mit rollenbasiertem Zugriff sieht das Finanzteam nur Finanz-Anmeldedaten, während IT-Administratoren den Überblick über alles behalten. Diese Kombination mit einem kosteneffizienten Ansatz gibt Ihnen Enterprise-Grade-Kontrolle, ohne für Funktionen zu bezahlen, die Sie nicht benötigen.

Für Teams, die zum ersten Mal Passwortverwaltung implementieren, verhindert die frühzeitige Einrichtung der richtigen Struktur zukünftige Zugriffsprobleme. Buchen Sie eine Beratung, um Ihr Zugriffsmodell, Ihren Bereitstellungsansatz und Ihren Rollout-Plan zu definieren.

Ihre kritischsten Konten priorisieren

Nicht alle Konten tragen das gleiche Risiko. Beginnen Sie die Migration mit den Anmeldedaten, die bei Kompromittierung den größten Schaden verursachen würden:

1. Primäre E-Mail-Konten (oft die Wiederherstellungsmethode für alles andere)
2. Finanzdienstleistungen und Zahlungsplattformen
3. Cloud-Infrastruktur und Admin-Panels
4. Geschäftskommunikationstools (Slack, Teams, E-Mail-Server)
5. Soziale Medien und öffentlich zugängliche Konten

Laut IBMs 2025 Cost of a Data Breach Report erreichten die globalen durchschnittlichen Kosten einer Datenschutzverletzung 4,44 Millionen US-Dollar, und die durchschnittliche Zeit zur Identifizierung und Eindämmung eines Vorfalls betrug 241 Tage. Die frühzeitige Migration von hochwertigen Konten reduziert dieses Expositionsfenster.

Tools für Passwort-Gesundheit und Datenschutzverletzungen nutzen

Sobald die Anmeldedaten im Tresor sind, führen Sie einen Passwort-Tresor-Gesundheitsbericht durch — eine routinemäßige Computersicherheitsprüfung. Integrierte Überwachung von Datenschutzverletzungen scannt Ihre Einträge gegen bekannte Breach-Datenbanken, während die Erkennung kompromittierter Passwörter wiederverwendete oder schwache Anmeldedaten markiert. Beheben Sie kritische Befunde zuerst, insbesondere bei Konten, bei denen dasselbe Passwort mehrere Dienste schützt.

Starke Passwörter generieren und verwalten

Verwenden Sie für jedes neue Konto oder jeden Passwortersatz den integrierten Passwort-Generator. Eine starke Konfiguration für hochsichere Konten: 20+ Zeichen, Groß-/Kleinschreibung, Zahlen und Symbole. Wo Dienste Zeichenbeschränkungen auferlegen, passen Sie an — aber gehen Sie niemals unter 15 Zeichen.

Ein generiertes Passwort wie „g7#Kp!2xVmNqR9bW" hat keine vorhersehbare Struktur, was Brute-Force-Angriffe unpraktisch macht. Der Passwort-Manager merkt es sich, sodass Komplexität nichts an Benutzerfreundlichkeit kostet.

Autofill-Funktionen sicher nutzen

Automatisches Ausfüllen beschleunigt das Ausfüllen von Formularen, erfordert aber Aufmerksamkeit. Bevor Sie die Erweiterung ein Login vervollständigen lassen, überprüfen Sie diese Indikatoren:

• Die URL in der Adressleiste stimmt exakt mit der erwarteten Domain überein
• Die Verbindung verwendet HTTPS (achten Sie auf das Schlosssymbol)
• Der Passwort-Manager erkennt die Website; wenn er kein automatisches Ausfüllen anbietet, könnte die Domain gefälscht sein
• Vor dem Laden der Login-Seite erfolgten keine unerwarteten Weiterleitungen

Eine Phishing-Seite unter g00gle.com sieht überzeugend aus, doch der Passwort-Manager gleicht exakte Domains ab und füllt auf einer gefälschten Website nicht automatisch aus. Halten Sie die Erweiterung auf privaten und Arbeitsgeräten gesperrt, wenn sie nicht aktiv genutzt wird.

Passwörter sicher mit anderen teilen

Für gemeinsame Konten, Admin-Panels und Dienste von Drittanbietern müssen Teams Anmeldedaten teilen. Das Senden von Passwörtern über E-Mail, Slack oder Textnachrichten ist der falsche Ansatz. Durch integrierte Freigabefunktionen bleibt die Verschlüsselung intakt — Anmeldedaten bleiben während der Übertragung geschützt.

Wir haben unsere rollenbasierten Zugriffskontrollen entwickelt, um abteilungsspezifische Anmeldedaten und temporären Zugriff für Auftragnehmer zu verwalten. Mit On-Premise-Bereitstellung werden geteilte Geheimnisse niemals über externe Server übertragen. Erfahren Sie mehr über unseren Ansatz zur geschäftlichen Passwortverwaltung.

Familien- und Teamzugriff verwalten

Geteilte Passwort-Tresore funktionieren wie geteilte Ordner: Jeder Tresor hat seine eigenen Zugriffsberechtigungen. Ein IT-Administrator könnte vollen Zugriff haben, während ein Marketingteam-Mitglied nur den Tresor für Social-Media-Anmeldedaten sieht. Gemäß DSGVO müssen Organisationen personenbezogene Daten sowohl vor unbefugtem Zugriff schützen als auch nachweisen, dass dieser Schutz besteht. Granulare Zugriffskontrollen und Audit-Logs erfüllen beide Anforderungen gleichzeitig.

Erweiterte Funktionen, die sich lohnen

Über das Speichern von Passwörtern hinaus enthalten die meisten Enterprise-Passwort-Manager Funktionen, die Teams oft übersehen. Sichere Notizen ermöglichen das Speichern von WLAN-Anmeldedaten, Serverdetails, Software-Lizenzschlüsseln oder Wiederherstellungscodes — alle durch AES-256-Verschlüsselung geschützt.

Durch SSO-Integration (Single Sign-On) verbindet sich der Passwort-Manager mit Ihrem Identitätsanbieter und reduziert die Reibung für Benutzer, die sich bereits über AD oder LDAP authentifizieren. Audit-Logs verfolgen jede Aktion: Wer hat auf welche Anmeldedaten zugegriffen, wann und von welchem Gerät — dies vereinfacht die DSGVO- und PCI-DSS-Berichterstattung (Payment Card Industry Data Security Standard).

Sichere Notizen und Dokumentenspeicherung

Secure Shell-Schlüssel (SSH), API-Tokens, Wiederherstellungsphrasen oder interne Verfahren — all dies gehört in sichere Notizen und nicht verstreut über E-Mail-Threads oder geteilte Laufwerke. Die Verschlüsselung schützt sie identisch zu Passwörtern, und Zugriffskontrollen bestimmen, wer was sieht.

Gerätesynchronisierung und Zugriffsverwaltung

Wenn ein Teammitglied ein Passwort auf seinem Laptop aktualisiert, spiegelt jedes autorisierte Gerät diese Änderung innerhalb von Sekunden wider. Verschlüsselt während der Übertragung, gelangen die Daten zum Server (oder Ihrer On-Premise-Instanz) und kommen auf anderen Geräten weiterhin geschützt an. Die Entschlüsselung erfolgt nur lokal.

Ordnungsgemäße Geräteverwaltung erfordert MFA-Verifizierung, bevor ein neues Gerät Tresorzugang erhält. Ohne diesen Schritt könnte ein Angreifer, der ein Sitzungstoken klont, unbemerkt auf gespeicherte Anmeldedaten zugreifen.

Häufige Probleme mit Passwort-Managern beheben

Ihre Passwortsicherheit langfristig aufrechterhalten

Sicherheit ist keine einmalige Einrichtung. Vierteljährliche Überprüfungen halten Ihren Tresor in gutem Zustand:

1. Führen Sie das Sicherheitsaudit des Tresors durch, um schwache, wiederverwendete oder alte Passwörter zu identifizieren
2. Ersetzen Sie alle markierten Anmeldedaten mit dem integrierten Passwort-Generator
3. Überprüfen Sie den Zugriff auf geteilte Tresore — entfernen Sie ehemalige Mitarbeiter oder Auftragnehmer
4. Überprüfen Sie, ob MFA noch aktiv ist und Backup-Codes zugänglich sind
5. Prüfen Sie, ob Konten in bekannten Breach-Datenbanken vorhanden sind, und rotieren Sie diese Passwörter sofort

Was tun, wenn Ihr Passwort-Manager kompromittiert wird

Wenn Sie vermuten, dass Ihr Masterpasswort offengelegt wurde, ist sofortige Schadensbegrenzung entscheidend für Ihre Computersicherheit:

1. Ändern Sie das Masterpasswort sofort von einem vertrauenswürdigen Gerät aus
2. Aktivieren oder verifizieren Sie MFA auf dem Tresor-Konto erneut
3. Rotieren Sie Passwörter für Ihre höchstpriorisierten Konten (E-Mail, Finanzen, Infrastruktur)
4. Überprüfen Sie das Audit-Log des Tresors auf unbefugten Zugriff
5. Benachrichtigen Sie Ihr Sicherheitsteam und beginnen Sie mit der Incident Response gemäß dem Protokoll Ihrer Organisation

Fazit: Ihre nächsten Schritte zur Passwortsicherheit

Ein Passwort-Manager ersetzt Mutmaßungen durch Struktur — ein direktes Upgrade für den digitalen Schutz Ihrer Organisation. Anstatt zu hoffen, dass Mitarbeiter starke Passwörter wählen, geben Sie ihnen ein Werkzeug, das dies automatisch erledigt und jede Anmeldeinformation verschlüsselt, auditierbar und unter Kontrolle hält.

Der erste Schritt ist der einfachste: Wählen Sie eine Lösung, erstellen Sie ein starkes Masterpasswort und beginnen Sie noch heute mit der Migration Ihrer kritischsten Konten.

Häufig gestellte Fragen

Passwork: Secrets-Management und Automatisierung für DevOps

Introduction In corporate environment, the number of passwords, keys, and digital certificates is rapidly increasing, and secrets management is becoming one of the critical tasks for IT teams. Secrets management addresses the complete lifecycle of sensitive data: from secure generation and encrypted storage to automated rotation and audit trails. As

Passwork BlogEirik Salmi

Was ist Passwortverwaltung?

Learn what password management is, why it matters, and how it protects your accounts with encryption, secure storage, and access control.

Passwork BlogEirik Salmi

Passwork 7.1: Tresor-Typen

Vault types Passwork 7.1 introduces a robust vault types architecture, providing enterprise-grade access control for enhanced security and management. Vault types address a key challenge for administrators: controlling data access and delegating vault management across large organizations. Previously, the choice was limited to two types. Now, you can create

Passwork BlogEirik Salmi

El Esquema Nacional de Seguridad (ENS) es el marco normativo de seguridad de la información para los sistemas y servicios digitales en España. Se aplica en todo el sector público español y también a las organizaciones del sector privado que prestan servicios o proporcionan soluciones tecnológicas a entidades públicas bajo las condiciones establecidas en el Real Decreto 311/2022. Para las empresas que venden al sector público español, la preparación para la conformidad con el ENS no es una opción; suele ser parte de la base legal y contractual para los sistemas dentro del alcance que soportan dichos servicios.

Esta guía está dirigida a responsables de seguridad, directores de cumplimiento normativo y directores de TI que necesitan una respuesta práctica a una pregunta sencilla: ¿qué se necesita para prepararse para la conformidad con el ENS en 2026? Se basa en el texto normativo oficial — el Real Decreto 311/2022— y en las guías técnicas publicadas por el Centro Criptológico Nacional (CCN) de España.

Al final de esta guía, usted dispondrá de:

• Un test rápido para determinar si el ENS le aplica.
• Un conocimiento claro de la categorización de sistemas en BÁSICA, MEDIA y ALTA.
• Una hoja de ruta para estructurar su paquete de evidencias.
• Un plan de adecuación realista de seis semanas para ejecutar el proceso oficial.
• Una lista de los controles que con más frecuencia no superan las auditorías.

¿Qué es el ENS y a Quién se Aplica?

El ENS está regulado por el Real Decreto 311/2022, que entró en vigor el 5 de mayo de 2022. Este real decreto sigue siendo el texto legal principal para la preparación y la conformidad con el ENS.

Según el artículo 2, el ENS se aplica a todo el sector público español y también a las entidades del sector privado que, en virtud de la normativa aplicable y una relación contractual, presten servicios o provean soluciones a entidades del sector público para el ejercicio de sus competencias y potestades administrativas. El real decreto también exige que los contratos del sector público incluyan los requisitos necesarios para asegurar la conformidad con el ENS de los sistemas de información que los soportan.

El portal oficial del ENS lo resume en un lenguaje sencillo: el ENS se aplica a todo el sector público, así como a los proveedores que colaboran con la Administración. Las preguntas frecuentes (FAQ) oficiales van un paso más allá, señalando que la cadena de suministro de dichos proveedores privados también puede entrar en el alcance cuando un análisis de riesgos previo determine que es necesario.

Un Test Práctico de Alcance

Debería tratar la preparación para la conformidad con el ENS como un requisito vigente si se cumple una o más de las siguientes condiciones:

1. Tiene un contrato con una administración pública española.
2. Proporciona un sistema, ya sea alojado o en las instalaciones del cliente, que soporta un servicio del sector público.
3. Procesa o almacena información en nombre de un organismo público.
4. Su contrato o la documentación de una licitación hace referencia a la conformidad con el ENS.
5. Es un subcontratista en una cadena de servicios que da soporte a un contratista del sector público, y el análisis de riesgos puede extender las expectativas del ENS a su función.

Si la respuesta a cualquiera de estas preguntas es afirmativa, la pregunta correcta no es "¿Necesitamos el ENS?", sino "¿Qué sistemas nuestros están dentro del alcance, en qué categoría se encuadran y qué evidencias debemos presentar?"

Adecuación al ENS vs. Conformidad con el ENS: Uso de los Términos Correctos

"Adecuación al ENS" es un término empresarial útil, pero no es el estatus legal formal que utiliza el marco. Usar la terminología correcta es fundamental para la precisión legal y reputacional. Los resultados formales de conformidad son:

Esa distinción es importante. En la práctica, la adecuación significa que su gobernanza, controles y evidencias están implementados y son defendibles. La conformidad significa que ha completado el proceso formal que el ENS exige para la categoría del sistema dentro del alcance. El lenguaje más seguro para un proveedor no es "somos cumplidores del ENS" en abstracto, sino:

• "Este sistema dentro del alcance ha obtenido la conformidad con el ENS mediante una [Declaración/Certificación de Conformidad]".
• "Estamos preparando este sistema dentro del alcance para su conformidad con el ENS".

La conformidad debe renovarse mediante una verificación ordinaria al menos cada dos años, y se requieren auditorías extraordinarias cuando se producen cambios sustanciales que afectan al sistema.

El Proceso Oficial de Adecuación: Su Plan de Proyecto Fundamental

Antes de crear listas de verificación o buscar herramientas, debe anclar su proyecto en el Plan de Adecuación oficial. La página del proceso de conformidad del ENS establece que la certificación y la conformidad requieren un plan de adecuación previo. Describe una secuencia práctica:

1. Definir el sistema dentro del alcance y sus límites.
2. Categorizar el sistema correctamente (BÁSICA, MEDIA o ALTA).
3. Obtener una Declaración de Aplicabilidad (DdA) provisional, mapeando los controles del Anexo II.
4. Realizar un análisis de riesgos formal.
5. Validar la Declaración de Aplicabilidad final.
6. Preparar y aprobar la Política de Seguridad formal.

Esta secuencia oficial proporciona un modelo operativo claro para cualquier proyecto interno de adecuación. El plan de 6 semanas de esta guía es una superposición práctica para ejecutar este proceso oficial.

Paso 1: Categorizar el Sistema (BÁSICA / MEDIA / ALTA)

La categorización del sistema es la primera gran decisión, ya que determina el conjunto de controles requeridos y la vía de conformidad. Un sistema es de categoría ALTA si alguna dimensión de seguridad alcanza el nivel ALTO; MEDIA si alguna dimensión alcanza el nivel MEDIO y ninguna es superior; y BÁSICA si todas las dimensiones son de nivel BAJO. En otras palabras, la categoría general viene determinada por la dimensión de seguridad más alta que sea relevante.

El marco funciona a través de cinco dimensiones de seguridad:

Un taller práctico de categorización debería responder a cuatro preguntas:

• ¿Qué información se está procesando?
• ¿Qué servicios dependen de este sistema?
• ¿Cuál sería el impacto si la confidencialidad, la integridad, la disponibilidad, la autenticidad o la trazabilidad se vieran comprometidas?
• ¿Qué dimensión alcanza el nivel requerido más alto?

Plantilla de Categorización del ENS — una plantilla estructurada para guiar su proceso de clasificac.

Paso 2: Construir el Paquete de Evidencias

El paquete de evidencias es el resultado operacionalmente más importante de su programa de adecuación. Es lo que presentará a un auditor o a un posible cliente. La forma más clara de presentarlo es como una matriz de evidencias organizada en seis bloques.

1. Gobernanza y Políticas

El artículo 12 del RD 311/2022 exige una Política de Seguridad de la Información formal, aprobada por el máximo órgano ejecutivo de la organización. Este es el documento fundamental de su paquete de evidencias.

Evidencias típicas:

• Política de Seguridad firmada y versionada.
• Matriz de roles y responsabilidades (RACI).
• Políticas de apoyo (control de acceso, respuesta a incidentes, seguridad de proveedores).

2. Alcance e Inventario de Activos

El proceso oficial de adecuación comienza con la identificación del alcance del sistema. En la práctica, eso significa un inventario de sistemas, aplicaciones, usuarios, cuentas privilegiadas y terceros dentro de los límites definidos.

Evidencias típicas:

• Declaración de alcance del sistema y diagrama de arquitectura.
• Inventario de aplicaciones e infraestructura.
• Inventario de usuarios y cuentas privilegiadas.
• Registro de terceros/proveedores de servicios.

3. Identidad y Control de Acceso

El ENS es explícito en que cada usuario o proceso debe tener un identificador único. La familia de controles de control de acceso (op.acc) exige autorización formal, revisión periódica de permisos y políticas explícitas de acceso remoto.

Evidencias típicas:

• Modelo de Control de Acceso Basado en Roles (RBAC).
• Documentación del proceso de altas, bajas y cambios de personal.
• Registros de revisiones periódicas de acceso.
• Reglas de MFA y acceso remoto.
• Registros de aprobación de acceso privilegiado.

4. Trazabilidad y Registro de Actividad

El control op.exp.8 exige que los registros de auditoría incluyan, como mínimo, el identificador del usuario, la fecha y hora, la información afectada, el tipo de evento y el resultado. Los períodos de retención deben definirse en función del análisis de riesgos y las obligaciones legales.

Evidencias típicas:

• Estándar de registro de logs e inventario de fuentes de logs.
• Política documentada de retención de logs.
• Registros de revisiones periódicas de logs.
• Evidencia de sincronización horaria (NTP).

5. Análisis de Riesgos y Declaración de Aplicabilidad

El proceso oficial de adecuación exige explícitamente un análisis de riesgos y una Declaración de Aplicabilidad (DdA) final. La DdA mapea cada control del Anexo II con su estado de implementación (aplicable, no aplicable, compensado) y debe incluir justificaciones para cualquier exclusión.

Evidencias típicas:

• Registro de riesgos e informe de análisis de riesgos.
• Decisiones de tratamiento de riesgos.
• La Declaración de Aplicabilidad final y aprobada.

6. Controles Operacionales y de Protección

Este bloque cubre las evidencias del día a día en copias de seguridad, continuidad, gestión de vulnerabilidades, incidentes y criptografía, tal como se detalla en las secciones de medidas operacionales (op) y de protección (mp) del Anexo II.

Evidencias típicas:

• Evidencias de pruebas de copia de seguridad y restauración.
• Informes de escaneo de vulnerabilidades y planes de remediación.
• Registros de incidentes, incluidas las notificaciones al CCN-CERT cuando sea necesario.
• Estándares de configuración criptográfica.

Checklist del Paquete de Evidencias del ENS — una hoja de cálculo completa que cubre los seis bloque.

Paso 3: Priorizar las Brechas que Suelen Bloquear la Adecuación

Los programas de adecuación se estancan cuando las organizaciones no pueden demostrar propiedad, repetibilidad o trazabilidad. Las áreas de mayor fricción suelen ser:

Paso 4: Un Plan Práctico de Adecuación al ENS de 6 Semanas

El siguiente plan de seis semanas es un ritmo operativo práctico para ejecutar el Plan de Adecuación oficial.

• Semana 1: Alcance, Categoría, Propietarios. Defina el sistema dentro del alcance, realice el taller de categorización y asigne propietarios para las políticas, los riesgos y las áreas operativas clave. Entregables: Declaración de alcance, plantilla de categorización.
• Semana 2: Política de Seguridad y Modelo de Acceso. Redacte o revise la Política de Seguridad formal, documente el modelo RBAC y formalice los procesos de altas, bajas y cambios. Entregables: Borrador de la Política de Seguridad, documentación del modelo de acceso.
• Semana 3: Análisis de Riesgos y Declaración de Aplicabilidad. Realice el análisis de riesgos formal y produzca una Declaración de Aplicabilidad (DdA) provisional. Entregables: Registro de riesgos, DdA provisional.
• Semana 4: Logs, Incidentes y Evidencias Operacionales. Estandarice el registro de actividad, defina la retención y alinee la gestión de incidentes con los requisitos de captura de evidencias y notificación. Entregables: Estándar de registro de logs, plantilla de evidencia de incidentes.
• Semana 5: Copias de Seguridad, Continuidad y Proveedores. Recopile evidencias de copias de seguridad/restauración, material de planificación de continuidad y documentación de control de proveedores. Entregables: Registros de pruebas de copias de seguridad, checklist de seguridad de proveedores.
• Semana 6: Ensayo Interno y Vía de Conformidad. Realice un simulacro de auditoría interna con el paquete de evidencias. Decida si el sistema está listo para una Declaración de Conformidad o una Certificación de Conformidad formal. Entregables: Lista de brechas, plan de remediación.

Plan de Adecuación al ENS de 6 Semanas + Plantilla RACI — un plan de proyecto estructurado con hitos y propietarios.

Paso 5: Preparación de Proveedores para Contratos con el Sector Público

Para los proveedores, la adecuación al ENS es una cuestión de credibilidad en la contratación. El artículo 2 del RD 311/2022 exige que los contratos del sector público aseguren la conformidad con el ENS. En la práctica, los clientes del sector público y los procesos de contratación a menudo requieren que los proveedores documenten su estado de conformidad con el ENS o su hoja de ruta.

Esto significa que un proveedor debe preparar un Paquete ENS para Proveedores compacto que contenga:

• El sistema dentro del alcance y su categoría.
• El estado de conformidad actual (Declaración/Certificado) o la hoja de ruta de adecuación.
• Un resumen de los controles clave para la gobernanza de acceso, logs y análisis de riesgos.

Plantilla del Paquete ENS para Proveedores del Sector Público — una plantilla lista para usar para demostrar su estado de conformidad.

Dónde Encaja un Gestor de Contraseñas y Secretos

Un gestor de contraseñas y secretos apoya algunas de las áreas de evidencia más difíciles en la adecuación al ENS: responsabilidad individual, mínimo privilegio, gobernanza del acceso privilegiado y trazabilidad. El ENS exige explícitamente identificadores únicos y registros de actividad que puedan vincularse a usuarios específicos.

Una lista de verificación útil para la selección de productos es:

• Impone cuentas individuales (sin compartir credenciales).
• RBAC granular y acceso privilegiado basado en aprobaciones.
• Acceso seguro y temporal para usuarios externos.
• Registros de auditoría a prueba de manipulaciones vinculados a usuarios nominativos.
• Exportación rápida de evidencias de acceso para auditorías.

ENS e ISO 27001 / NIS2

Si su organización ya tiene la certificación ISO/IEC 27001, es útil, pero no equivale automáticamente a la conformidad con el ENS. El CCN ha publicado una guía de mapeo oficial (CCN-STIC 825) entre ISO 27001:2022 y el RD 311/2022. La formulación más segura es: La ISO 27001 puede reducir el esfuerzo requerido para la adecuación al ENS, pero la conformidad con el ENS aún depende de la categoría, el alcance y los requisitos específicos del sistema.

La relación entre el ENS y la Directiva NIS2 es de complementariedad. Para las organizaciones sujetas a ambas, el cumplimiento del ENS proporciona una base sólida para cumplir muchos de los requisitos técnicos y organizativos de NIS2, pero NIS2 tiene su propio alcance, gobernanza y obligaciones de notificación que deben abordarse por separado.

Preguntas Frecuentes

¿Las empresas privadas necesitan prepararse para la conformidad con el ENS?
Sí, cuando prestan servicios o proporcionan soluciones a entidades del sector público español bajo las condiciones del artículo 2 del Real Decreto 311/2022.

¿Deben estar cubiertos todos los sistemas de una empresa?
No necesariamente. La conformidad con el ENS se evalúa para el sistema de información específico que soporta el servicio relevante, no automáticamente para todos los sistemas de la empresa.

¿Cómo sabemos si nuestro sistema es de categoría BÁSICA, MEDIA o ALTA?
Se clasifica el sistema a través de las cinco dimensiones de seguridad y se toma el nivel más alto aplicable como la categoría general.

¿Se puede certificar un sistema de categoría BÁSICA?
Sí. Los sistemas de categoría BÁSICA solo requieren una autoevaluación para una Declaración de Conformidad, pero también pueden someterse a certificación voluntariamente.

¿Con qué frecuencia se renueva la conformidad?
Los sistemas deben someterse a una verificación ordinaria al menos cada dos años, y puede requerirse una auditoría extraordinaria tras cambios sustanciales.

¿Qué herramientas oficiales apoyan la adecuación al ENS?
El CCN proporciona las herramientas nacionales de gobernanza de ciberseguridad INES, AMPARO y PILAR para apoyar los procesos de adecuación, implementación y auditoría.

Conclusión

En 2026, el ENS ya no es una historia de "requisitos futuros". El marco actual bajo el RD 311/2022 está en vigor desde mayo de 2022, y el período de transición para los sistemas preexistentes ha finalizado. Para los proveedores que venden al sector público español, el desafío ahora es práctico: definir el alcance correctamente, categorizar el sistema, construir las evidencias adecuadas y seguir la vía de conformidad correcta.

Las organizaciones que avanzan más rápido no son las que tienen más documentos de políticas. Son las que pueden conectar la gobernanza, los controles y las evidencias en un paquete limpio y listo para el proveedor.

Reserve una demostración en vivo o inicie un piloto — en español.

Referencias

Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad. (Texto oficial del Real Decreto)

ENS - Preguntas Frecuentes (Portal Oficial)

ENS - Proceso de Adecuación (Portal Oficial)

CCN-STIC 825 - Mapeo entre ISO 27001:2022 y RD 311/2022

ENS - Qué es el ENS (Portal Oficial)

En la nueva versión, se ha mejorado el proceso de migración desde versiones anteriores de Passwork, se han perfeccionado las descripciones en el registro de actividad y se han realizado correcciones menores en la interfaz de usuario y la localización.

Mejoras

• Se ha añadido una restricción que impide a los usuarios cambiar su propio tipo de autorización
• Se ha mejorado la migración a Passwork 7 para versiones anteriores a la 5.3
• Se han mejorado las descripciones de ciertos eventos en el registro de actividad

Corrección de errores

• Se ha corregido un problema que impedía mover una carpeta a la papelera mediante arrastrar y soltar si la configuración «Nivel de acceso requerido para copiar carpetas y contraseñas» estaba establecida en «Acción prohibida»
• Se ha corregido el botón duplicado «Guardar configuración» en la configuración de la bóveda
• Se ha corregido la visualización de indicadores de cambio de parámetros en la configuración de la bóveda y la gestión de usuarios en el navegador Safari
• Se ha corregido la redirección incorrecta a Recientes después de una autorización exitosa de la extensión

Lectura adicional

Passwork 7.1: Tipos de bóvedas

Table of contents * What are vault types * Basic vault types * Advantages of vault types * Managing vault types * Migration from previous versions * Conclusion: Data control and efficiency Vault types Passwork 7.1 introduces a robust vault types architecture, providing enterprise-grade access control for enhanced security and management. Vault types address a

Passwork BlogEirik Salmi

Lanzamiento de la extensión de navegador 2.0.26

Version 2.0.27 * Further improved clickjacking protection: added blocking of clicks on hidden elements and checking for element overlap and CSS transformations * Fixed an issue when following a link from a notification to a deleted vault or password * Fixed an issue that could cause the extension to log out

Passwork BlogEirik Salmi

Seguridad de contraseñas según el RGPD: Guía para la formación efectiva del personal

Learn proven strategies to train employees for GDPR password security compliance. Reduce breach risks with practical training methods.

Passwork BlogAna Moore

In der neuen Version wurde der Migrationsprozess von älteren Passwork-Versionen verbessert, die Beschreibungen im Aktivitätsprotokoll erweitert sowie kleinere Korrekturen an der Benutzeroberfläche und Lokalisierung vorgenommen.

Verbesserungen

• Eine Einschränkung wurde hinzugefügt, die Benutzer daran hindert, ihren eigenen Autorisierungstyp zu ändern
• Die Migration zu Passwork 7 für Versionen vor 5.3 wurde verbessert
• Die Beschreibungen für bestimmte Ereignisse im Aktivitätsprotokoll wurden verbessert

Fehlerbehebungen

• Ein Problem wurde behoben, bei dem es nicht möglich war, einen Ordner per Drag-and-Drop in den Papierkorb zu verschieben, wenn die Einstellung „Zugangslevel erforderlich zum Kopieren von Ordnern und Passwörtern" auf „Verboten" gesetzt war
• Die doppelte Schaltfläche „Einstellungen speichern" in den Tresor-Einstellungen wurde behoben
• Die Anzeige von Parameteränderungsindikatoren in den Tresor-Einstellungen und der Benutzerverwaltung im Safari-Browser wurde korrigiert
• Eine fehlerhafte Weiterleitung zu „Kürzlich" nach erfolgreicher Autorisierung über die Erweiterung wurde behoben

Weiterführende Lektüre

Passwork 7.1: Tresor-Typen

Table of contents * What are vault types * Basic vault types * Advantages of vault types * Managing vault types * Migration from previous versions * Conclusion: Data control and efficiency Vault types Passwork 7.1 introduces a robust vault types architecture, providing enterprise-grade access control for enhanced security and management. Vault types address a

Passwork BlogEirik Salmi

Browser-Erweiterung 2.0.26 Release

Version 2.0.27 * Further improved clickjacking protection: added blocking of clicks on hidden elements and checking for element overlap and CSS transformations * Fixed an issue when following a link from a notification to a deleted vault or password * Fixed an issue that could cause the extension to log out

Passwork BlogEirik Salmi

DSGVO-Passwortsicherheit: Leitfaden für effektive Mitarbeiterschulungen

Learn proven strategies to train employees for GDPR password security compliance. Reduce breach risks with practical training methods.

Passwork BlogAna Moore

Die neueste Version führt zusätzliche Zugriffskontrollen für die Desktop-App ein und enthält mehrere UI-Verbesserungen sowie Fehlerbehebungen.

Zugriffskontrolle für die Desktop-App

Passwork-Administratoren können nun den Zugriff auf die Desktop-App verwalten. Der Bereich „Account" in den Rolleneinstellungen enthält zwei neue Parameter, mit denen Sie den Desktop-Client aktivieren oder deaktivieren und dessen Download aus der Web-Version einschränken können.

Wenden Sie diese Berechtigungen über die Rolleneinstellungen unter Einstellungen und Benutzer → Rollen → Rolle auswählen → Account an.

Verbesserungen

• Option zum direkten Kopieren der URL aus dem Kontextmenü „In Zwischenablage kopieren" hinzugefügt
• Automatische Masterpasswort-Migration für Benutzer hinzugefügt, die von Passwork 5.3 und früheren Versionen aktualisieren
• Kleinere UI-Verbesserungen

Fehlerbehebungen

• Problem behoben, bei dem Ordnernamen im Importfenster bei Verwendung des dunklen Themes falsch angezeigt wurden
• Browser-Navigation vor und zurück zwischen Passwörtern in Kürzlich, Favoriten und Posteingang behoben
• Problem behoben, bei dem Account-Einstellungen für die Besitzer-Rolle nach einer Seitenaktualisierung nicht gespeichert wurden
• Anzeige einiger Systemmeldungen behoben
• Fehler beim Avatar-Upload behoben

Desktop-App 1.2.0

• Problem behoben, bei dem die macOS-App beim ersten Start eine manuelle Bestätigung in den Datenschutz- & Sicherheitseinstellungen erforderte
• Problem behoben, das eine fehlerhafte Sitzungsbeendigung verursachte
• Problem in den Tresor-Einstellungen behoben, bei dem die Schaltflächen „Speichern" und „Abbrechen" im Tab „Alle Tresore" beim Scrollen andere Elemente überlagern konnten
• Falsches App-Symbol in der Windows-Taskleistenvorschau behoben

Einführung der Passwork Desktop-App

Passwork ist jetzt als vollwertige Desktop-App für Windows, macOS und Linux verfügbar. Die Desktop-App bietet vollständige Passwortverwaltungsfunktionen: Zugangsdaten verwalten, auf Tresore zugreifen, mit Ihrem Team zusammenarbeiten — alles mit der nativen Leistung und dem Komfort einer Desktop-Umgebung.

Passwork BlogEirik Salmi

Unternehmens-Passwortsicherheit: Best Practices für 2026

Cyberkriminalität zielt zunehmend auf menschliches Verhalten ab. Technische Kontrollen allein können diese Lücke nicht schließen. Gute Passwortgewohnheiten im gesamten Unternehmen reduzieren das Risiko mehr als jedes einzelne Tool.

Passwork BlogMike Shikun

So verwenden Sie einen Passwort-Manager: Vollständiger Sicherheitsleitfaden

Ein Passwort-Manager ersetzt Unsicherheit durch Struktur — ein direktes Upgrade für den digitalen Schutz Ihrer Organisation.

Passwork BlogMike Shikun

La última versión introduce controles de acceso adicionales para la aplicación de escritorio y añade varias mejoras y correcciones de la interfaz de usuario.

Control de acceso a la aplicación de escritorio

Los administradores de Passwork ahora pueden gestionar el acceso a la aplicación de escritorio. La sección Cuenta en la configuración de roles incluye dos nuevos parámetros que permiten habilitar o deshabilitar el cliente de escritorio y restringir su descarga desde la versión web.

Aplique estos permisos a través de la configuración de roles en Configuración y usuarios → Roles → Seleccionar rol → Cuenta.

Mejoras

• Se añadió la opción de copiar URL directamente desde el menú contextual Copiar al portapapeles
• Se añadió la migración automática de la contraseña maestra para usuarios que actualizan desde Passwork 5.3 y versiones anteriores
• Mejoras menores de la interfaz de usuario

Corrección de errores

• Se corrigió un problema donde los nombres de las carpetas se mostraban incorrectamente en la ventana de importación al usar el tema oscuro
• Se corrigió la navegación del navegador hacia atrás y adelante entre contraseñas en Recientes, Favoritos y Bandeja de entrada
• Se corrigió un problema donde la configuración de cuenta para el rol Propietario no se guardaba después de actualizar la página
• Se corrigió la visualización de algunas notificaciones del sistema
• Se corrigió un fallo en la carga del avatar

Aplicación de escritorio 1.2.0

• Se corrigió un problema donde la aplicación de macOS requería confirmación manual en la configuración de Privacidad y seguridad en el primer inicio
• Se corrigió un problema que causaba una terminación de sesión incorrecta
• Se corrigió un problema en la configuración de bóvedas donde los botones Guardar y Cancelar en la pestaña Todas las bóvedas podían superponerse a otros elementos durante el desplazamiento
• Se corrigió el icono incorrecto de la aplicación mostrado en la vista previa de la barra de tareas de Windows

Presentamos la aplicación de escritorio Passwork

Passwork ahora está disponible como una aplicación de escritorio con todas las funciones para Windows, macOS y Linux. La aplicación de escritorio ofrece funcionalidad completa de gestión de contraseñas: gestione credenciales, acceda a bóvedas, colabore con su equipo, todo con el rendimiento nativo y la comodidad de un entorno de escritorio.

Passwork BlogEirik Salmi

Seguridad de contraseñas empresariales: Mejores prácticas para 2026

El cibercrimen se dirige cada vez más al comportamiento humano. Los controles técnicos por sí solos no pueden cerrar esta brecha. En toda la organización, los buenos hábitos de contraseñas reducen el riesgo más que cualquier herramienta individual.

Passwork BlogMike Shikun

Cómo usar un gestor de contraseñas: Guía completa de seguridad

Un gestor de contraseñas reemplaza la improvisación con estructura, una mejora directa para la protección digital de su organización.

Passwork BlogMike Shikun

The latest release introduces additional access controls for the desktop app and adds several UI improvements and fixes.

Desktop app access control

Passwork administrators can now manage access to the desktop app. The Account section in role settings includes two new parameters that allow you to enable or disable the desktop client and restrict its download from the web version.

Apply these permissions via role settings under Settings and users → Roles → Select role → Account.

Improvements

• Added the option to copy URL directly from the Copy to clipboard context menu
• Added automatic master password migration for users upgrading from Passwork 5.3 and earlier versions
• Minor UI improvements

Bug fixes

• Fixed an issue where folder names displayed incorrectly in the import window when using the dark theme
• Fixed browser back and forward navigation between passwords in Recents, Favorites, and Inbox
• Fixed an issue where account settings for the Owner role failed to save after a page refresh
• Fixed the display of some system notifications
• Fixed an avatar upload failure

Desktop app 1.2.0

• Fixed an issue where the macOS app required manual confirmation in Privacy & Security settings on first launch
• Fixed an issue causing incorrect session termination
• Fixed an issue in Vault settings where the Save and Cancel buttons in the All vaults tab could overlap other elements during scrolling
• Fixed the incorrect app icon displayed in the Windows taskbar preview

Introducing Passwork Desktop app

Passwork is now available as a full-featured desktop app for Windows, macOS, and Linux. The desktop app delivers complete password management functionality: manage credentials, access vaults, collaborate with your team, all with the native performance and convenience of a desktop environment.

Passwork BlogEirik Salmi

Enterprise password security: Best practices for 2026

Cybercrime increasingly targets human behavior. Technical controls alone cannot close this gap. Across the organization, strong password habits reduce risk more than any single tool.

Passwork BlogMike Shikun

How to use a password manager: complete security guide

A password manager replaces guesswork with structure, a direct upgrade to your organization’s digital protection.

Passwork BlogMike Shikun

In der neuen Version wurde das automatische Ausfüllen von TOTP verbessert und eine Fehlerprotokollierung zur Browser-Erweiterung hinzugefügt. Protokolle können jetzt direkt aus der Service-Worker-Konsole exportiert und mit unserem Team geteilt werden — was die Fehlerbehebung erheblich beschleunigt.

• Verbesserte Leistung beim automatischen Ausfüllen von TOTP in der Browser-Erweiterung
• Möglichkeit hinzugefügt, Fehlerprotokolle über die Service-Worker-Konsole mit dem Befehl downloadErrors() herunterzuladen
• Problem behoben, bei dem das automatische Ausfüllen von TOTP für Elemente aus dem Posteingang nicht funktionierte
• Problem behoben, bei dem die Erweiterung fälschlicherweise zum Speichern oder automatischen Ausfüllen von Daten in Formularen auffordern konnte, die nicht mit der Authentifizierung zusammenhängen
• Problem behoben, das die Funktionalität der Erweiterung nach dem Verbinden blockieren konnte
• Problem behoben, bei dem Benachrichtigungsdaten falsch angezeigt werden konnten
• Problem behoben, das die Funktion der Erweiterung im Firefox-Inkognito-Modus verhinderte
• Kleinere Fehlerbehebungen und Leistungsverbesserungen

Einführung der Passwork Desktop-App

Passwork ist jetzt als vollwertige Desktop-App für Windows, macOS und Linux verfügbar. Die Desktop-App bietet vollständige Passwortverwaltungsfunktionen: Anmeldedaten verwalten, auf Tresore zugreifen, mit Ihrem Team zusammenarbeiten — alles mit der nativen Leistung und dem Komfort einer Desktop-Umgebung.

Passwork BlogEirik Salmi

Leitfaden zur Passwortsicherheit: Expertenmethoden für Ihren Schutz

Passwortsicherheit ist Ihre erste Verteidigungslinie gegen Cyberbedrohungen. Ein umfassender Ansatz kombiniert die Erstellung starker Passwörter, verschlüsselte Speicherung durch Passwort-Manager und Multi-Faktor-Authentifizierung, um immer ausgefeilteren Angriffen auf Ihre digitale Identität entgegenzuwirken.

Passwork BlogMike Shikun

So verwenden Sie einen Passwort-Manager: Vollständiger Sicherheitsleitfaden

Ein Passwort-Manager ersetzt Ratespiele durch Struktur — ein direktes Upgrade für den digitalen Schutz Ihrer Organisation.

Passwork BlogMike Shikun

En la nueva versión, se ha mejorado el autocompletado de TOTP y se ha añadido el registro de errores a la extensión del navegador. Ahora puede exportar los registros directamente desde la consola del service worker y compartirlos con nuestro equipo — lo que acelera significativamente la resolución de problemas.

• Mejora del rendimiento del autocompletado de TOTP en la extensión del navegador.
• Añadida la capacidad de descargar registros de errores a través de la consola del service worker utilizando el comando downloadErrors().
• Corregido un problema donde el autocompletado de TOTP no funcionaba para elementos de la bandeja de entrada.
• Corregido un problema donde la extensión podía solicitar incorrectamente guardar o autocompletar datos en algunos formularios no relacionados con la autenticación.
• Corregido un problema que podía bloquear la funcionalidad de la extensión después de conectarla.
• Corregido un problema donde las fechas de las notificaciones podían mostrarse incorrectamente.
• Corregido un problema que impedía que la extensión funcionara en el modo incógnito de Firefox.
• Correcciones menores de errores y mejoras de rendimiento.

Presentamos la aplicación de escritorio Passwork

Passwork ahora está disponible como una aplicación de escritorio completa para Windows, macOS y Linux. La aplicación de escritorio ofrece funcionalidad completa de gestión de contraseñas: gestione credenciales, acceda a bóvedas, colabore con su equipo, todo con el rendimiento nativo y la comodidad de un entorno de escritorio.

Passwork BlogEirik Salmi

Guía de seguridad de contraseñas: métodos expertos para protegerle

La seguridad de las contraseñas constituye su primera línea de defensa contra las ciberamenazas. Un enfoque integral combina la creación de contraseñas seguras, el almacenamiento cifrado mediante gestores de contraseñas y la autenticación multifactor para contrarrestar ataques cada vez más sofisticados dirigidos a su identidad digital.

Passwork BlogMike Shikun

Cómo usar un gestor de contraseñas: guía completa de seguridad

Un gestor de contraseñas reemplaza las suposiciones con estructura, una mejora directa en la protección digital de su organización.

Passwork BlogMike Shikun

In the new version, we’ve improved TOTP autofill and added error logging to the browser extension. You can now export logs directly from the service worker console and share them with our team — significantly speeding up troubleshooting.

• Improved TOTP autofill performance in the browser extension
• Added the capability to download error logs through the service worker console using the downloadErrors() command
• Fixed an issue where TOTP autofill did not work for items from the Inbox
• Fixed an issue where the extension could incorrectly prompt to save or autofill data in some forms not related to authentication
• Fixed an issue that could block extension functionality after connecting it
• Fixed an issue where notification dates could display incorrectly
• Fixed an issue preventing the extension from working in Firefox Incognito mode
• Minor bug fixes and performance improvements

Introducing Passwork Desktop app

Passwork is now available as a full-featured desktop app for Windows, macOS, and Linux. The desktop app delivers complete password management functionality: manage credentials, access vaults, collaborate with your team, all with the native performance and convenience of a desktop environment.

Passwork BlogEirik Salmi

Security password guide: Expert methods to protect you

Password security stands as your first line of defense against cyber threats. A comprehensive approach combines strong password creation, encrypted storage through password managers, and multi-factor authentication to counter increasingly sophisticated attacks targeting your digital identity.

Passwork BlogMike Shikun

How to use a password manager: complete security guide

A password manager replaces guesswork with structure, a direct upgrade to your organization’s digital protection.

Passwork BlogMike Shikun

Bring Your Own Device (BYOD) hat sich von einem Arbeitsplatztrend zu einer geschäftlichen Notwendigkeit entwickelt. Bis 2026 werden über 82 % der Unternehmen formelle BYOD-Richtlinien eingeführt haben, wobei mehr als 80 % diesen Ansatz aktiv fördern. Dies spiegelt eine grundlegende Veränderung wider, wie Organisationen Arbeitsplatzflexibilität und Produktivität angehen.

Die Vorteile liegen auf der Hand: Mitarbeiter arbeiten auf Geräten, die sie kennen, IT-Abteilungen reduzieren Hardwarekosten, und Unternehmen gewinnen Talente, die Flexibilität suchen. Doch dieser Komfort bringt Sicherheitsherausforderungen mit sich, die sensible Daten offenlegen, Netzwerke kompromittieren und Compliance-Probleme verursachen können.

Dieser Leitfaden führt Sie durch die Sicherheitslandschaft von BYOD — vom Verständnis der Kernrisiken bis zur Implementierung von Frameworks, die Ihre Organisation schützen, ohne die Autonomie der Mitarbeiter zu opfern.

BYOD verstehen und seine Sicherheitsimplikationen

BYOD ermöglicht es Mitarbeitern, persönliche Smartphones, Tablets und Laptops für Arbeitsaufgaben zu nutzen. Diese Geräte greifen auf Unternehmens-E-Mails, Cloud-Anwendungen, interne Netzwerke und sensible Daten zu — und befinden sich dabei außerhalb der traditionellen IT-Kontrolle.

Der aktuelle Stand von BYOD in modernen Arbeitsumgebungen

Organisationen stehen nun vor der Realität, dass persönliche Geräte integraler Bestandteil des täglichen Betriebs sind und keine Ausnahmen von der Richtlinie darstellen.

Mitarbeiter erwarten nahtlose Übergänge zwischen Zuhause und Büro und nutzen Geräte, die zu ihren Arbeitsabläufen passen. IT-Abteilungen haben sich angepasst, indem sie Sicherheitsarchitekturen aufgebaut haben, die diese Flexibilität ermöglichen, anstatt sie zu blockieren.

Warum Organisationen BYOD einführen

Kostensenkung treibt viele BYOD-Programme an. Unternehmen sparen bei der Hardwarebeschaffung, Wartung und Austauschzyklen. Mitarbeiter tragen die anfänglichen Gerätekosten, während Organisationen in Sicherheitsinfrastruktur und Management-Tools investieren.

Die Mitarbeiterzufriedenheit verbessert sich, wenn Mitarbeiter vertraute Geräte nutzen. Lernkurven entfallen, die Produktivität steigt und die Arbeitszufriedenheit nimmt zu. Dies ist wichtig in wettbewerbsintensiven Arbeitsmärkten, wo Arbeitsplatzflexibilität Einstellungsentscheidungen beeinflusst.

Die betriebliche Agilität steigt, da Mitarbeiter von überall auf Arbeitsressourcen zugreifen können. Die Geschäftskontinuität verbessert sich, weil Mitarbeiter nicht an unternehmenseigene Geräte gebunden sind. Bei Störungen läuft der Betrieb mit minimaler Unterbrechung weiter.

Hauptsicherheitsherausforderungen bei BYOD

• Mangelnde Standardisierung. Persönliche Geräte unterscheiden sich in Betriebssystemen, Sicherheitspatch-Levels und Konfigurationen, was zu inkonsistenten Sicherheitslagen führt.
• Sichtbarkeitslücken. IT-Teams haben Schwierigkeiten, den Gerätezustand, installierte Apps und Sicherheitseinstellungen zu überwachen, wodurch blinde Flecken in der Sicherheitslandschaft entstehen.
• Herausforderungen bei der Richtliniendurchsetzung. Die Balance zwischen Sicherheitsanforderungen und Mitarbeiterprivatsphäre kann zu Widerstand oder Schwachstellen führen.
• Probleme beim Lebenszyklus-Management. Die Verwaltung der Sicherheit, wenn Mitarbeiter Geräte upgraden, Plattformen wechseln oder die Organisation verlassen, erfordert sorgfältige Planung und technische Fähigkeiten.

Wichtige BYOD-Sicherheitsrisiken und Schwachstellen

Datenverlust und -abfluss in BYOD-Umgebungen

Unternehmensdaten befinden sich neben persönlichen Informationen auf BYOD-Geräten. Mitarbeiter könnten unbeabsichtigt vertrauliche Dateien über persönlichen Cloud-Speicher, Messaging-Apps oder E-Mail-Konten teilen. Die Grenze zwischen beruflicher und privater Nutzung verschwimmt und schafft Möglichkeiten für Daten, der Unternehmenskontrolle zu entgleiten.

Verlorene oder gestohlene Geräte stellen unmittelbare Sicherheitsvorfälle dar. Ohne angemessene Schutzmaßnahmen erhält jeder, der auf das Gerät zugreift, Zugang zu Unternehmensressourcen. Das Risiko verstärkt sich, wenn Geräte grundlegende Schutzmaßnahmen wie Bildschirmsperren oder Verschlüsselung nicht haben.

Malware- und Phishing-Bedrohungen, die auf persönliche Geräte abzielen

Persönliche Geräte haben oft schwächere Sicherheit als Unternehmensgeräte. Mitarbeiter könnten Sicherheitsfunktionen aus Bequemlichkeit deaktivieren, Apps aus nicht vertrauenswürdigen Quellen installieren oder Software-Updates ignorieren. Diese Verhaltensweisen schaffen Einfallstore für Malware.

Phishing-Angriffe nutzen die persönliche Natur von BYOD aus. Angreifer senden überzeugende Nachrichten an persönliche E-Mail- oder Messaging-Apps, wohlwissend, dass Mitarbeiter dasselbe Gerät für die Arbeit nutzen. Einmal kompromittiert, bietet das Gerät Zugang zu Unternehmensnetzwerken und -daten.

Veraltete Geräte und ungepatchte Schwachstellen

Mitarbeiter kontrollieren die Update-Zeitpläne auf persönlichen Geräten. Kritische Sicherheitspatches könnten Tage oder Wochen warten, während Benutzer Updates aus Bequemlichkeit verzögern. Während dieses Zeitfensters bleiben bekannte Schwachstellen ausnutzbar.

Ältere Geräte stellen zusätzliche Herausforderungen dar. Hersteller stellen irgendwann die Unterstützung von Geräten mit Sicherheitsupdates ein, wodurch diese dauerhaft anfällig bleiben. Wenn Mitarbeiter diese Geräte weiterhin für die Arbeit nutzen, führen sie ungepatchte Risiken in Ihre Umgebung ein.

Schatten-IT und nicht genehmigte Anwendungen

Mitarbeiter installieren Anwendungen, die unmittelbare Probleme lösen, ohne Sicherheitsimplikationen zu berücksichtigen. Dateifreigabedienste, Kollaborationstools und Produktivitäts-Apps könnten IT-Genehmigungsprozesse vollständig umgehen.

Diese nicht genehmigten Anwendungen verfügen oft nicht über angemessene Sicherheitskontrollen, Compliance-Zertifizierungen oder Integration mit Unternehmenssicherheitssystemen. Daten fließen durch Dienste, die Ihr Sicherheitsteam weder überwacht noch schützt.

Vermischung von privater und geschäftlicher Nutzung

Eine der häufigsten Schwachstellen in BYOD-Umgebungen ist das unsachgemäße Management von Anmeldedaten. Mitarbeiter speichern häufig Unternehmenspasswörter aus Bequemlichkeit in persönlichen Browser-Schlüsselbunden oder unverschlüsselten Notizen. Währenddessen existiert ein Unternehmens-Passwort-Manager separat auf ihrem Gerät, mit eigener Verschlüsselung, Zugangskontrolle und biometrischem Schutz. Mit Passwork greifen Mitarbeiter über eine mobile App auf Unternehmenstresore zu und halten Arbeitsanmeldedaten vollständig von persönlichen Daten getrennt.

Ein effektives BYOD-Sicherheitsframework aufbauen

Eine umfassende BYOD-Sicherheitsrichtlinie erstellen

Ihre BYOD-Richtlinie definiert akzeptable Nutzung, Sicherheitsanforderungen und Verantwortlichkeiten. Sie sollte die Geräteberechtigung, erforderliche Sicherheitsmaßnahmen, zulässige Anwendungen und Datenverarbeitungsverfahren behandeln.

Abschnitte zu Umfang und Berechtigung klären, welche Geräte für BYOD-Programme qualifiziert sind und welche Rollen teilnehmen können. Nicht jede Position erfordert BYOD-Zugang, und nicht jedes Gerät erfüllt die Mindestsicherheitsstandards.

Sicherheitsanforderungen müssen spezifisch und durchsetzbar sein. Definieren Sie obligatorische Funktionen wie Verschlüsselung, Bildschirmsperren, biometrische Authentifizierung und automatische Updates. Spezifizieren Sie verbotene Aktivitäten wie Jailbreaking oder Rooten von Geräten.

Die Datenklassifizierung leitet Mitarbeiter beim Umgang mit verschiedenen Informationstypen an. Unterscheiden Sie klar zwischen öffentlichen, internen, vertraulichen und eingeschränkten Daten. Definieren Sie, welche Datentypen über BYOD zugänglich sind und welche unternehmenseigene Geräte erfordern.

Incident-Response-Verfahren beschreiben die Schritte, die Mitarbeiter unternehmen müssen, wenn Geräte verloren gehen, gestohlen werden oder kompromittiert sind. Fügen Sie Meldefristen, Kontaktinformationen und Erwartungen zur Zusammenarbeit bei Untersuchungen hinzu.

Geräte- und Softwareanforderungen definieren

• Betriebssystemanforderungen. Nur Geräte mit aktiv unterstützten Betriebssystemen sollten in BYOD-Programmen zugelassen werden. Veraltete Systeme müssen ausgeschlossen werden.
• Obligatorische Sicherheitsfunktionen. Geräte müssen Verschlüsselung, Secure Boot und hardwaregestützte Anmeldedatenspeicherung beinhalten. Stellen Sie sicher, dass diese Funktionen durch Richtlinien durchgesetzt werden.
• Genehmigte Anwendungen. Stellen Sie Mitarbeitern eine Liste sicherer, genehmigter Apps und Alternativen zu nicht genehmigten Tools zur Verfügung, um die Compliance zu fördern.

Technische Lösungen für BYOD-Sicherheit

Netzwerkzugang sichern und Compliance gewährleisten

Persönliche Geräte sollten nicht denselben Netzwerkzugang wie Unternehmensgeräte haben. Implementieren Sie Netzwerksegmentierung und strenge Zugriffskontrollen, damit BYOD-Benutzer nur auf die notwendigen Ressourcen zugreifen können. Fordern Sie ein VPN für den Fernzugriff, um den Datenverkehr zu verschlüsseln und Einstiegspunkte zu kontrollieren. Kontinuierliche Netzwerküberwachung sollte ungewöhnliche Aktivitäten erkennen und Warnmeldungen auslösen.

Diese Kontrollen helfen Organisationen auch, regulatorische Anforderungen wie HIPAA, DSGVO und andere zu erfüllen. Eine robuste Netzwerkstrategie unterstützt Datenresidenzregeln und gewährleistet ordnungsgemäße Protokollierung und Berichterstattung für Audits, einschließlich Zugriffsaufzeichnungen und Vorfallsverfolgung.

Best Practices für die Implementierung von BYOD-Sicherheit

Sicherheitsrichtlinien scheitern ohne die Zustimmung der Mitarbeiter. Konzentrieren Sie Schulungen auf praktische Compliance und reale Bedrohungen:

• Onboarding zuerst: Führen Sie BYOD-Richtlinien, Datenschutzgrenzen und Vorfallsmeldungen ein, bevor Mitarbeiter Geräte anmelden.
• Kontinuierliche Sensibilisierung: Teilen Sie regelmäßig relevante Bedrohungsinformationen und heben Sie aktuelle Vorfälle hervor, um Sicherheit präsent zu halten.
• Szenariobasiertes Lernen: Schulen Sie Mitarbeiter mit branchenspezifischen Beispielen — wie gezielte Phishing-Versuche oder gängige Social-Engineering-Taktiken.

BYOD-Sicherheitsrisiken überwachen und verwalten

Proaktive Überwachung verhindert, dass kleine Probleme zu Sicherheitsverletzungen eskalieren:

• Kontinuierliche Verfolgung: Überwachen Sie die Geräte-Compliance, markieren Sie veraltete Software und identifizieren Sie verdächtige Aktivitäten in Echtzeit.
• Sichtbarkeits-Dashboards: Verfolgen Sie wichtige Kennzahlen wie Anmelderaten, Richtlinien-Compliance und Betriebssystemversionen in Ihrer gesamten Umgebung.
• Automatische Behebung: Konfigurieren Sie Systeme so, dass sie automatisch den Zugriff einschränken oder Benutzer benachrichtigen, wenn Geräte nicht mehr compliant sind.
• Regelmäßige Audits: Überprüfen Sie Zugriffsprotokolle und testen Sie Remote-Löschfunktionen, um sicherzustellen, dass technische Kontrollen sich an sich entwickelnde Bedrohungen anpassen.

Sicherheit und Mitarbeiterprivatsphäre in Einklang bringen

Erfolgreiche BYOD-Programme schützen Unternehmensdaten und respektieren gleichzeitig die persönliche Privatsphäre:

• Containerisierung: Isolieren Sie Unternehmensdaten in verwalteten Containern — halten Sie persönliche Informationen vollständig außerhalb der IT-Sichtbarkeit.
• Transparente Richtlinien: Dokumentieren Sie explizit, auf welche Daten die IT zugreifen kann, und stellen Sie klar, dass die Überwachung sich strikt auf Unternehmensressourcen konzentriert.
• Informierte Einwilligung: Fordern Sie, dass Mitarbeiter die Überwachungsfunktionen und Remote-Löschszenarien vor der Geräteanmeldung bestätigen.

Zero-Trust-Architektur für BYOD-Umgebungen

Zero-Trust-Prinzipien gehen davon aus, dass kein Gerät oder Benutzer von Natur aus vertrauenswürdig ist. Jede Zugriffsanfrage erfordert eine Überprüfung, unabhängig vom Netzwerkstandort oder früherer Authentifizierung.

Multi-Faktor-Authentifizierung (MFA) ist nicht mehr optional. Sie ist die Grundlage. Biometrie, Hardware-Token und Authentifizierungs-Apps sollten als mehrschichtiger Schutz zusammenwirken.

In BYOD-Umgebungen benötigen Mitarbeiter sicheren Zugang zu Unternehmensanmeldedaten auf ihren persönlichen Geräten. Die mobilen Apps von Passwork für iOS und Android bieten biometrische Entsperrung mit Face ID und Touch ID, sodass Benutzer sich einmal authentifizieren und dann sicher auf gemeinsame Unternehmenstresore zugreifen können, ohne Unterbrechung. Dies spiegelt einen Zero-Trust-Ansatz in der Praxis wider: Die Identität wird auf Geräteebene verifiziert, während die Benutzererfahrung nahtlos bleibt.

Kontinuierliche Authentifizierung überwacht das Benutzerverhalten und den Gerätezustand während der gesamten Sitzung. Anomalien lösen eine erneute Authentifizierung oder Zugriffsbeschränkungen aus. Wenn ein Gerät während einer Sitzung weniger sicher wird, wird der Zugriff automatisch angepasst.

Least-Privilege-Zugang begrenzt, worauf BYOD-Benutzer basierend auf Rolle und Notwendigkeit zugreifen können. Mitarbeiter erhalten Zugang zu Ressourcen, die für ihre Arbeit erforderlich sind, nicht mehr. Dies minimiert potenzielle Schäden durch kompromittierte Geräte.

Mobile Threat Defense und Endpoint Security

Mobile Threat Defense (MTD)-Lösungen schützen BYOD-Geräte vor Bedrohungen, die spezifisch für mobile Umgebungen sind. Diese Plattformen erkennen und reagieren auf Bedrohungen, die traditionelle Sicherheitstools übersehen.

Die Bedrohungserkennung identifiziert bösartige Apps, Netzwerkangriffe und Gerätekompromittierungen. MTD-Lösungen analysieren Anwendungsverhalten, Netzwerkverbindungen und Gerätekonfigurationen, um Indikatoren für Kompromittierungen zu erkennen.

Der Phishing-Schutz erstreckt sich auf mobile Browser und Messaging-Anwendungen. MTD-Plattformen erkennen und blockieren den Zugang zu bekannten Phishing-Websites, warnen Benutzer vor verdächtigen Links und verhindern Anmeldedatendiebstahl.

Die Netzwerksicherheit bewertet Wi-Fi- und Mobilfunkverbindungen auf Risiken. MTD-Lösungen identifizieren Man-in-the-Middle-Angriffe, bösartige Zugangspunkte und unsichere Netzwerkkonfigurationen, die Daten offenlegen könnten.

Datenschutzstrategien für BYOD

Stellen Sie sich Containerisierung als einen sicheren Tresor im Smartphone Ihres Mitarbeiters vor. Arbeits-Apps und -Daten bleiben in ihrem eigenen Bereich gesperrt — vollständig getrennt von persönlichen Fotos, Nachrichten und Apps.

Application Wrapping fügt bestehenden Anwendungen Sicherheitskontrollen hinzu, ohne den Quellcode zu ändern. Gewrappte Anwendungen erzwingen Verschlüsselung, verhindern Datenlecks und integrieren sich in Authentifizierungssysteme.

Data Loss Prevention (DLP) innerhalb geschützter Bereiche verhindert unbefugte Datenübertragungen. Benutzer können keine Unternehmensdaten in persönliche Anwendungen kopieren, Dateien zu nicht genehmigten Cloud-Diensten hochladen oder Informationen über nicht verwaltete Kanäle teilen.

Remote-Löschung und Datenwiederherstellung

Die Zukunft der BYOD-Sicherheit: Aufkommende Trends und Technologien

KI-gestützte Bedrohungserkennung wird die BYOD-Sicherheit verbessern, indem sie subtile Verhaltensanomalien und Zero-Day-Bedrohungen identifiziert. Maschinelle Lernmodelle werden sich schneller an sich entwickelnde Angriffsmuster anpassen als signaturbasierte Ansätze.

Passwortlose Authentifizierung mit Biometrie und Hardware-Token wird traditionelle Passwörter ersetzen. Diese Umstellung reduziert Phishing-Risiken und verbessert die Benutzererfahrung auf persönlichen Geräten.

Edge Computing wird Sicherheitsentscheidungen in Echtzeit ermöglichen, ohne den gesamten Datenverkehr durch zentralisierte Systeme zu leiten. Geräte werden lokale Sicherheitsbewertungen durchführen, was die Leistung verbessert und gleichzeitig den Schutz aufrechterhält.

Die Integration mit SASE (Secure Access Service Edge)-Architekturen wird umfassende Sicherheit für BYOD-Benutzer unabhängig vom Standort bieten. Cloud-basierte Sicherheitsdienste werden Geräte schützen, die von überall auf Ressourcen zugreifen.

Fazit: Eine ausgewogene BYOD-Sicherheitsstrategie aufbauen

Effektive BYOD-Sicherheit erfordert ein Gleichgewicht zwischen Schutz und Benutzerfreundlichkeit. Übermäßig restriktive Ansätze führen zu Nichteinhaltung, und unzureichende Sicherheit setzt Ihre Organisation inakzeptablen Risiken aus.

Beginnen Sie mit klaren Richtlinien, die Mitarbeiter verstehen und akzeptieren. Implementieren Sie technische Kontrollen, die Daten schützen, ohne unnötig in die Privatsphäre einzugreifen. Bieten Sie Schulungen an, die Mitarbeiter befähigen, Bedrohungen zu erkennen und darauf zu reagieren.

Überwachen Sie Ihre BYOD-Umgebung kontinuierlich und passen Sie sich an neue Bedrohungen und sich ändernde Geschäftsanforderungen an. Regelmäßige Bewertungen stellen sicher, dass Ihre Sicherheitsmaßnahmen wirksam bleiben, während sich Technologie und Angriffsmethoden weiterentwickeln.

Richtig umgesetztes BYOD liefert Flexibilität, Kosteneinsparungen und Mitarbeiterzufriedenheit, ohne die Sicherheit zu gefährden. Der Schlüssel ist, BYOD-Sicherheit als fortlaufendes Programm zu behandeln, nicht als einmalige Implementierung.

Häufig gestellte Fragen

Einführung der Passwork Desktop-App

Passwork ist jetzt als vollwertige Desktop-App für Windows, macOS und Linux verfügbar. Die Desktop-App bietet vollständige Passwort-Management-Funktionalität: Anmeldedaten verwalten, auf Tresore zugreifen, mit Ihrem Team zusammenarbeiten — alles mit der nativen Leistung und Bequemlichkeit einer Desktop-Umgebung.

Passwork BlogEirik Salmi

Fallstudie: Stadt Melle und Passwork

Passwork hat die interne Sicherheit der Stadt Melle verbessert, indem ein zuverlässiges System für das Passwort-Management geschaffen wurde.

Passwork BlogAna Moore

Passwork: Secrets Management und Automatisierung für DevOps

Einführung In Unternehmensumgebungen steigt die Anzahl von Passwörtern, Schlüsseln und digitalen Zertifikaten rapide an, und Secrets Management wird zu einer der kritischen Aufgaben für IT-Teams. Secrets Management umfasst den gesamten Lebenszyklus sensibler Daten: von der sicheren Generierung und verschlüsselten Speicherung bis zur automatischen Rotation und Audit-Trails. Da

Passwork BlogEirik Salmi

Bring Your Own Device (BYOD) ha pasado de ser una tendencia laboral a convertirse en una necesidad empresarial. Para 2026, más del 82% de las empresas habrán adoptado políticas formales de BYOD, y más del 80% promoverán activamente este enfoque. Esto refleja un cambio fundamental en cómo las organizaciones abordan la flexibilidad y productividad en el lugar de trabajo.

El atractivo es evidente: los empleados trabajan en dispositivos que conocen, los departamentos de TI reducen costos de hardware y las empresas atraen talento que busca flexibilidad. Sin embargo, esta comodidad introduce desafíos de seguridad que pueden exponer datos sensibles, comprometer redes y crear problemas de cumplimiento normativo.

Esta guía le orienta a través del panorama de seguridad de BYOD — desde comprender los riesgos principales hasta implementar marcos que protejan su organización sin sacrificar la autonomía de los empleados.

Comprensión de BYOD y sus implicaciones de seguridad

BYOD permite a los empleados utilizar smartphones, tablets y laptops personales para tareas laborales. Estos dispositivos acceden al correo corporativo, aplicaciones en la nube, redes internas y datos sensibles — todo mientras permanecen fuera del control tradicional de TI.

El estado actual de BYOD en los lugares de trabajo modernos

Las organizaciones ahora enfrentan una realidad donde los dispositivos personales son parte integral de las operaciones diarias, no excepciones a la política.

Los empleados esperan transiciones fluidas entre el hogar y la oficina, utilizando dispositivos que se adapten a sus flujos de trabajo. Los departamentos de TI se han adaptado construyendo arquitecturas de seguridad que acomodan esta flexibilidad en lugar de resistirse a ella.

Por qué las organizaciones están adoptando BYOD

La reducción de costos impulsa muchos programas BYOD. Las empresas ahorran en adquisición de hardware, mantenimiento y ciclos de reemplazo. Los empleados asumen el costo inicial del dispositivo, mientras que las organizaciones invierten en infraestructura de seguridad y herramientas de gestión.

La satisfacción de los empleados mejora cuando los trabajadores utilizan dispositivos familiares. Las curvas de aprendizaje desaparecen, la productividad aumenta y la satisfacción laboral crece. Esto importa en mercados laborales competitivos donde la flexibilidad en el lugar de trabajo influye en las decisiones de contratación.

La agilidad operativa aumenta cuando los empleados acceden a recursos laborales desde cualquier lugar. La continuidad del negocio mejora porque los trabajadores no dependen de equipos propiedad de la empresa. Durante interrupciones, las operaciones continúan con mínima interrupción.

Principales desafíos de seguridad BYOD

• Falta de estandarización. Los dispositivos personales varían en sistemas operativos, niveles de parches de seguridad y configuraciones, lo que genera posturas de seguridad inconsistentes.
• Brechas de visibilidad. Los equipos de TI tienen dificultades para monitorear el estado del dispositivo, las aplicaciones instaladas y la configuración de seguridad, dejando puntos ciegos en el panorama de seguridad.
• Desafíos en la aplicación de políticas. Equilibrar los requisitos de seguridad con la privacidad de los empleados puede generar resistencia o vulnerabilidades.
• Problemas de gestión del ciclo de vida. Gestionar la seguridad cuando los empleados actualizan dispositivos, cambian de plataformas o abandonan la organización requiere una planificación cuidadosa y capacidades técnicas.

Principales riesgos y vulnerabilidades de seguridad BYOD

Fuga y pérdida de datos en entornos BYOD

Los datos corporativos conviven con la información personal en los dispositivos BYOD. Los empleados podrían compartir involuntariamente archivos confidenciales a través de almacenamiento personal en la nube, aplicaciones de mensajería o cuentas de correo electrónico. El límite entre el uso laboral y personal se difumina, creando oportunidades para que los datos escapen de los controles corporativos.

Los dispositivos perdidos o robados representan incidentes de seguridad inmediatos. Sin las protecciones adecuadas, cualquier persona que acceda al dispositivo obtiene entrada a los recursos corporativos. El riesgo se intensifica cuando los dispositivos carecen de protecciones básicas, como bloqueos de pantalla o cifrado.

Amenazas de malware y phishing dirigidas a dispositivos personales

Los dispositivos personales a menudo tienen una seguridad más débil que los equipos corporativos. Los empleados podrían desactivar funciones de seguridad por comodidad, instalar aplicaciones de fuentes no confiables o ignorar las actualizaciones de software. Estos comportamientos crean puntos de entrada para el malware.

Los ataques de phishing explotan la naturaleza personal de BYOD. Los atacantes envían mensajes convincentes al correo electrónico personal o aplicaciones de mensajería, sabiendo que los empleados utilizan el mismo dispositivo para trabajar. Una vez comprometido, el dispositivo proporciona acceso a redes y datos corporativos.

Dispositivos obsoletos y vulnerabilidades sin parches

Los empleados controlan los programas de actualización en dispositivos personales. Los parches de seguridad críticos podrían esperar días o semanas mientras los usuarios retrasan las actualizaciones por comodidad. Durante esta ventana, las vulnerabilidades conocidas permanecen explotables.

Los dispositivos más antiguos presentan desafíos adicionales. Los fabricantes eventualmente dejan de soportar los dispositivos con actualizaciones de seguridad, dejándolos permanentemente vulnerables. Cuando los empleados continúan utilizando estos dispositivos para trabajar, introducen riesgos sin parches en su entorno.

Shadow IT y aplicaciones no autorizadas

Los empleados instalan aplicaciones que resuelven problemas inmediatos sin considerar las implicaciones de seguridad. Los servicios de intercambio de archivos, herramientas de colaboración y aplicaciones de productividad podrían eludir completamente los procesos de aprobación de TI.

Estas aplicaciones no autorizadas a menudo carecen de controles de seguridad adecuados, certificaciones de cumplimiento o integración con los sistemas de seguridad corporativos. Los datos fluyen a través de servicios que su equipo de seguridad no monitorea ni protege.

Mezcla de uso personal y empresarial

Una de las vulnerabilidades más comunes en entornos BYOD es la mala gestión de credenciales. Los empleados frecuentemente guardan contraseñas corporativas en llaveros de navegadores personales o notas sin cifrar por comodidad. Mientras tanto, un gestor de contraseñas corporativo reside por separado en su dispositivo, con su propio cifrado, control de acceso y protección biométrica. Con Passwork, los empleados acceden a las bóvedas de la empresa a través de una aplicación móvil, manteniendo las credenciales de trabajo completamente separadas de los datos personales.

Construcción de un marco de seguridad BYOD efectivo

Creación de una política de seguridad BYOD integral

Su política BYOD define el uso aceptable, los requisitos de seguridad y las responsabilidades. Debe abordar la elegibilidad de dispositivos, las medidas de seguridad requeridas, las aplicaciones aceptables y los procedimientos de manejo de datos.

Las secciones de alcance y elegibilidad aclaran qué dispositivos califican para los programas BYOD y qué roles pueden participar. No todas las posiciones requieren acceso BYOD, y no todos los dispositivos cumplen con los estándares mínimos de seguridad.

Los requisitos de seguridad deben ser específicos y aplicables. Defina características obligatorias como cifrado, bloqueos de pantalla, autenticación biométrica y actualizaciones automáticas. Especifique actividades prohibidas como hacer jailbreak o rootear dispositivos.

La clasificación de datos guía a los empleados en el manejo de diferentes tipos de información. Distinga claramente entre datos públicos, internos, confidenciales y restringidos. Defina qué tipos de datos son accesibles mediante BYOD y cuáles requieren dispositivos propiedad de la empresa.

Los procedimientos de respuesta a incidentes describen los pasos que los empleados deben seguir cuando los dispositivos se pierden, son robados o están comprometidos. Incluya plazos de notificación, información de contacto y expectativas de cooperación durante las investigaciones.

Definición de requisitos de dispositivos y software

• Requisitos del sistema operativo. Solo los dispositivos con sistemas operativos activamente soportados deben permitirse en los programas BYOD. Los sistemas obsoletos deben excluirse.
• Características de seguridad obligatorias. Los dispositivos deben incluir cifrado, arranque seguro y almacenamiento de credenciales respaldado por hardware. Asegúrese de que estas características se apliquen mediante política.
• Aplicaciones aprobadas. Proporcione a los empleados una lista de aplicaciones seguras y aprobadas, así como alternativas a herramientas no autorizadas para fomentar el cumplimiento.

Soluciones técnicas para la seguridad BYOD

Protección del acceso a la red y garantía de cumplimiento

Los dispositivos personales no deberían tener el mismo acceso a la red que los equipos corporativos. Implemente segmentación de red y controles de acceso estrictos para que los usuarios BYOD solo puedan acceder a los recursos necesarios. Requiera una VPN para el acceso remoto con el fin de cifrar el tráfico y controlar los puntos de entrada. El monitoreo continuo de la red debe detectar actividad inusual y activar alertas.

Estos controles también ayudan a las organizaciones a cumplir con los requisitos regulatorios, como HIPAA, GDPR y otros. Una estrategia de red robusta apoya las reglas de residencia de datos y garantiza el registro y los informes adecuados para auditorías, incluyendo registros de acceso y seguimiento de incidentes.

Mejores prácticas para la implementación de seguridad BYOD

Las políticas de seguridad fracasan sin la aceptación de los empleados. Enfoque la capacitación en el cumplimiento práctico y las amenazas del mundo real:

• Incorporación primero: Presente las políticas BYOD, los límites de privacidad y los informes de incidentes antes de que los empleados registren dispositivos.
• Concienciación continua: Comparta inteligencia de amenazas relevante y destaque incidentes recientes regularmente para mantener la seguridad presente.
• Aprendizaje basado en escenarios: Capacite a los empleados utilizando ejemplos específicos de la industria — como intentos de phishing dirigidos o tácticas comunes de ingeniería social.

Monitoreo y gestión de riesgos de seguridad BYOD

El monitoreo proactivo evita que problemas menores escalen a brechas:

• Seguimiento continuo: Monitoree el cumplimiento del dispositivo, marque software desactualizado e identifique actividades sospechosas en tiempo real.
• Paneles de visibilidad: Rastree métricas clave como tasas de registro, cumplimiento de políticas y versiones de sistemas operativos en todo su entorno.
• Remediación automatizada: Configure sistemas para restringir automáticamente el acceso o notificar a los usuarios cuando los dispositivos dejen de cumplir.
• Auditorías regulares: Revise los registros de acceso y pruebe las capacidades de borrado remoto para asegurar que los controles técnicos se adapten a las amenazas en evolución.

Equilibrio entre seguridad y privacidad del empleado

Los programas BYOD exitosos protegen los datos corporativos mientras respetan la privacidad personal:

• Contenedorización: Aísle los datos corporativos dentro de contenedores gestionados — manteniendo la información personal completamente fuera de la visibilidad de TI.
• Políticas transparentes: Documente explícitamente a qué datos puede acceder TI, aclarando que el monitoreo se enfoca estrictamente en recursos corporativos.
• Consentimiento informado: Requiera que los empleados reconozcan las capacidades de monitoreo y los escenarios de borrado remoto antes del registro del dispositivo.

Arquitectura de confianza cero para entornos BYOD

Los principios de confianza cero asumen que ningún dispositivo o usuario es inherentemente confiable. Cada solicitud de acceso requiere verificación independientemente de la ubicación en la red o autenticación previa.

La autenticación multifactor (MFA) ya no es opcional. Es la línea base. La biometría, los tokens de hardware y las aplicaciones de autenticación deben trabajar juntos como protección en capas.

En entornos BYOD, los empleados necesitan acceso seguro a credenciales corporativas en sus dispositivos personales. Las aplicaciones móviles de Passwork para iOS y Android proporcionan desbloqueo biométrico con Face ID y Touch ID, permitiendo a los usuarios autenticarse una vez y luego acceder de forma segura a las bóvedas compartidas de la empresa sin interrupciones. Esto refleja un enfoque de confianza cero en la práctica: la identidad se verifica a nivel del dispositivo mientras la experiencia del usuario permanece fluida.

La autenticación continua monitorea el comportamiento del usuario y la postura del dispositivo durante las sesiones. Las anomalías activan la reautenticación o restricciones de acceso. Si un dispositivo se vuelve menos seguro durante una sesión, el acceso se ajusta automáticamente.

El acceso de privilegio mínimo limita lo que los usuarios BYOD pueden acceder según su rol y necesidad. Los empleados reciben acceso a los recursos requeridos para sus trabajos, nada más. Esto minimiza el daño potencial de dispositivos comprometidos.

Defensa contra amenazas móviles y seguridad de endpoints

Las soluciones de Mobile Threat Defense (MTD) protegen los dispositivos BYOD de amenazas específicas de entornos móviles. Estas plataformas detectan y responden a amenazas que las herramientas de seguridad tradicionales pasan por alto.

La detección de amenazas identifica aplicaciones maliciosas, ataques de red y compromisos de dispositivos. Las soluciones MTD analizan el comportamiento de las aplicaciones, las conexiones de red y las configuraciones de dispositivos para detectar indicadores de compromiso.

La protección contra phishing se extiende a navegadores móviles y aplicaciones de mensajería. Las plataformas MTD detectan y bloquean el acceso a sitios de phishing conocidos, advierten a los usuarios sobre enlaces sospechosos y previenen el robo de credenciales.

La seguridad de red evalúa las conexiones Wi-Fi y celulares en busca de riesgos. Las soluciones MTD identifican ataques de intermediario, puntos de acceso no autorizados y configuraciones de red inseguras que podrían exponer datos.

Estrategias de protección de datos para BYOD

Piense en la contenedorización como una bóveda segura dentro del teléfono de su empleado. Las aplicaciones y datos de trabajo permanecen bloqueados en su propio espacio — completamente separados de fotos personales, mensajes y aplicaciones.

El wrapping de aplicaciones agrega controles de seguridad a aplicaciones existentes sin modificar el código fuente. Las aplicaciones envueltas aplican cifrado, previenen la fuga de datos e integran con sistemas de autenticación.

La Prevención de Pérdida de Datos (DLP) dentro de espacios protegidos previene transferencias de datos no autorizadas. Los usuarios no pueden copiar datos corporativos a aplicaciones personales, subir archivos a servicios en la nube no autorizados o compartir información a través de canales no gestionados.

Borrado remoto y recuperación de datos

El futuro de la seguridad BYOD: Tendencias y tecnologías emergentes

La detección de amenazas impulsada por IA mejorará la seguridad BYOD al identificar anomalías conductuales sutiles y amenazas de día cero. Los modelos de aprendizaje automático se adaptarán a los patrones de ataque en evolución más rápido que los enfoques basados en firmas.

La autenticación sin contraseña utilizando biometría y tokens de hardware reemplazará las contraseñas tradicionales. Este cambio reduce los riesgos de phishing y mejora la experiencia del usuario en dispositivos personales.

La computación en el borde permitirá decisiones de seguridad en tiempo real sin enrutar todo el tráfico a través de sistemas centralizados. Los dispositivos realizarán evaluaciones de seguridad locales, mejorando el rendimiento mientras mantienen la protección.

La integración con arquitecturas SASE (Secure Access Service Edge) proporcionará seguridad integral para usuarios BYOD independientemente de su ubicación. Los servicios de seguridad entregados desde la nube protegerán los dispositivos que acceden a recursos desde cualquier lugar.

Conclusión: Construcción de una estrategia de seguridad BYOD equilibrada

La seguridad BYOD efectiva requiere equilibrar la protección con la usabilidad. Los enfoques excesivamente restrictivos impulsan el incumplimiento, y la seguridad insuficiente expone a su organización a riesgos inaceptables.

Comience con políticas claras que los empleados entiendan y acepten. Implemente controles técnicos que protejan los datos sin invadir innecesariamente la privacidad. Proporcione capacitación que empodere a los empleados para reconocer y responder a las amenazas.

Monitoree su entorno BYOD continuamente, adaptándose a nuevas amenazas y necesidades empresariales cambiantes. Las evaluaciones regulares aseguran que sus medidas de seguridad permanezcan efectivas a medida que la tecnología y los métodos de ataque evolucionan.

BYOD bien implementado ofrece flexibilidad, ahorro de costos y satisfacción de los empleados sin comprometer la seguridad. La clave es tratar la seguridad BYOD como un programa continuo, no como una implementación única.

Preguntas frecuentes

Presentamos la aplicación de escritorio Passwork

Passwork ahora está disponible como una aplicación de escritorio completa para Windows, macOS y Linux. La aplicación de escritorio ofrece funcionalidad completa de gestión de contraseñas: gestione credenciales, acceda a bóvedas, colabore con su equipo, todo con el rendimiento nativo y la comodidad de un entorno de escritorio.

Passwork BlogEirik Salmi

Caso de estudio: Ciudad de Melle y Passwork

Passwork ha mejorado la seguridad interna en la Ciudad de Melle creando un sistema confiable para la gestión de contraseñas.

Passwork BlogAna Moore

Passwork: Gestión de secretos y automatización para DevOps

Introducción En el entorno corporativo, el número de contraseñas, claves y certificados digitales está aumentando rápidamente, y la gestión de secretos se está convirtiendo en una de las tareas críticas para los equipos de TI. La gestión de secretos aborda el ciclo de vida completo de los datos sensibles: desde la generación segura y el almacenamiento cifrado hasta la rotación automatizada y los registros de auditoría. A medida que

Passwork BlogEirik Salmi

Bring Your Own Device (BYOD) has transformed from a workplace trend into a business necessity. By 2026, over 82% of companies will have adopted formal BYOD policies, with more than 80% actively promoting this approach. This reflects a fundamental change in how organizations approach workplace flexibility and productivity.

The appeal is clear: employees work on devices they know, IT departments reduce hardware costs, and companies attract talent seeking flexibility. But this convenience introduces security challenges that can expose sensitive data, compromise networks, and create compliance headaches.

This guide walks you through the security landscape of BYOD — from understanding core risks to implementing frameworks that protect your organization without sacrificing employee autonomy.

Understanding BYOD and its security implications

BYOD allows employees to use personal smartphones, tablets, and laptops for work tasks. These devices access corporate email, cloud applications, internal networks, and sensitive data — all while living outside traditional IT control.

The current state of BYOD in modern workplaces

Organizations now face a reality where personal devices are integral to daily operations, not exceptions to policy.

Employees expect seamless transitions between home and office, using devices that fit their workflows. IT departments adapted by building security architectures that accommodate this flexibility rather than resist it.

Why organizations are adopting BYOD

Cost reduction drives many BYOD programs. Companies save on hardware procurement, maintenance, and replacement cycles. Employees bear the initial device cost, while organizations invest in security infrastructure and management tools.

Employee satisfaction improves when workers use familiar devices. Learning curves disappear, productivity increases, and job satisfaction rises. This matters in competitive talent markets where workplace flexibility influences hiring decisions.

Operational agility increases as employees access work resources from anywhere. Business continuity improves because workers aren't tied to corporate-owned equipment. During disruptions, operations continue with minimal interruption.

Main BYOD security challenges

• Lack of standardization. Personal devices vary in operating systems, security patch levels, and configurations, leading to inconsistent security postures.
• Visibility gaps. IT teams have difficulties monitoring device health, installed apps, and security settings, leaving blind spots in the security landscape.
• Policy enforcement challenges. Balancing security requirements with employee privacy can lead to resistance or vulnerabilities.
• Lifecycle management issues. Managing security when employees upgrade devices, switch platforms, or leave the organization requires careful planning and technical capabilities.

Key BYOD security risks and vulnerabilities

Data leakage and loss in BYOD environments

Corporate data lives alongside personal information on BYOD devices. Employees might unintentionally share confidential files through personal cloud storage, messaging apps, or email accounts. The boundary between work and personal use blurs, creating opportunities for data to escape corporate controls.

Lost or stolen devices represent immediate security incidents. Without proper safeguards, anyone accessing the device gains entry to corporate resources. The risk intensifies when devices lack basic protections for example screen locks or encryption.

Malware and phishing threats targeting personal devices

Personal devices often have weaker security than corporate equipment. Employees might disable security features for convenience, install apps from untrusted sources, or ignore software updates. These behaviors create entry points for malware.

Phishing attacks exploit the personal nature of BYOD. Attackers send convincing messages to personal email or messaging apps, knowing employees use the same device for work. Once compromised, the device provides access to corporate networks and data.

Out-of-date devices and unpatched vulnerabilities

Employees control update schedules on personal devices. Critical security patches might wait days or weeks while users delay updates for convenience. During this window, known vulnerabilities remain exploitable.

Older devices present additional challenges. Manufacturers eventually stop supporting devices with security updates, leaving them permanently vulnerable. When employees continue using these devices for work, they introduce unpatched risks into your environment.

Shadow IT and unsanctioned applications

Employees install applications that solve immediate problems without considering security implications. File-sharing services, collaboration tools, and productivity apps might bypass IT approval processes entirely.

These unsanctioned applications often lack proper security controls, compliance certifications, or integration with corporate security systems. Data flows through services your security team doesn't monitor or protect.

Mixing personal and business use

One of the most common vulnerabilities in BYOD environments is credential mismanagement. Employees frequently save corporate passwords in personal browser keychains or unencrypted notes for convenience. Meanwhile, a corporate password manager lives separately on their device, featuring its own encryption, access control, and biometric protection. With Passwork, employees access company vaults through a mobile app, keeping work credentials completely separate from personal data.

Building an effective BYOD security framework

Creating a comprehensive BYOD security policy

Your BYOD policy defines acceptable use, security requirements, and responsibilities. It should address device eligibility, required security measures, acceptable applications, and data handling procedures.

Scope and eligibility sections clarify which devices qualify for BYOD programs and which roles can participate. Not every position requires BYOD access, and not every device meets minimum security standards.

Security requirements must be specific and enforceable. Define mandatory features such as encryption, screen locks, biometric authentication, and automatic updates. Specify prohibited activities such as jailbreaking or rooting devices.

Data classification guides employees in handling different information types. Clearly distinguish between public, internal, confidential, and restricted data. Define which data types are accessible via BYOD and which require corporate-owned devices.

Incident response procedures outline steps employees must take when devices are lost, stolen, or compromised. Include reporting timelines, contact information, and expectations for cooperation during investigations.

Defining device and software requirements

• Operating system requirements. Only devices with actively supported operating systems should be allowed in BYOD programs. Outdated systems must be excluded.
• Mandatory security features. Devices must include encryption, secure boot, and hardware-backed credential storage. Ensure these features are enforced by policy.
• Approved applications. Provide employees with a list of secure, approved apps and alternatives to unsanctioned tools to encourage compliance.

Technical solutions for BYOD security

Securing Network Access and Ensuring Compliance

Personal devices should not have the same network access as corporate equipment. Implement network segmentation and strict access controls so that BYOD users can only access the necessary resources. Require a VPN for remote access in order to encrypt traffic and control entry points. Continuous network monitoring should detect unusual activity and trigger alerts.

These controls also help organizations meet regulatory requirements, such as HIPAA, GDPR, and others. A robust network strategy supports data residency rules and ensures proper logging and reporting for audits, including access records and incident tracking.

Best practices for BYOD security implementation

Security policies fail without employee buy-in. Focus training on practical compliance and real-world threats:

• Onboarding first: Introduce BYOD policies, privacy boundaries, and incident reporting before employees enroll devices.
• Continuous awareness: Share relevant threat intelligence and highlight recent incidents regularly to keep security top-of-mind.
• Scenario-based learning: Train employees using industry-specific examples — like targeted phishing attempts or common social engineering tactics.

Monitoring and managing BYOD security risks

Proactive monitoring prevents minor issues from escalating into breaches:

• Continuous tracking: Monitor device compliance, flag outdated software, and identify suspicious activities in real time.
• Visibility dashboards: Track key metrics like enrollment rates, policy compliance, and OS versions across your environment.
• Automated remediation: Configure systems to automatically restrict access or notify users when devices fall out of compliance.
• Regular audits: Review access logs and test remote wipe capabilities to ensure technical controls adapt to evolving threats.

Balancing security with employee privacy

Successful BYOD programs protect corporate data while respecting personal privacy:

• Containerization: Isolate corporate data within managed containers — keeping personal information entirely outside IT visibility.
• Transparent policies: Explicitly document what data IT can access, clarifying that monitoring focuses strictly on corporate resources.
• Informed consent: Require employees to acknowledge monitoring capabilities and remote wipe scenarios before device enrollment.

Zero-trust architecture for BYOD environments

Zero-trust principles assume no device or user is inherently trustworthy. Every access request requires verification regardless of network location or previous authentication.

Multi-factor authentication (MFA) is no longer optional. It is the baseline. Biometrics, hardware tokens, and authenticator apps should work together as layered protection.

In BYOD environments, employees need secure access to corporate credentials on their personal devices. Passwork mobile apps for iOS and Android provide biometric unlock with Face ID and Touch ID, allowing users to authenticate once and then securely access shared company vaults without disruption. This reflects a zero-trust approach in practice: identity is verified at the device level while the user experience remains seamless.

Continuous authentication monitors user behavior and device posture throughout sessions. Anomalies trigger re-authentication or access restrictions. If a device becomes less secure during a session, access is automatically adjusted.

Least privilege access limits what BYOD users can access based on role and necessity. Employees receive access to resources required for their jobs, nothing more. This minimizes potential damage from compromised devices.

Mobile threat defense and endpoint security

Mobile Threat Defense (MTD) solutions protect BYOD devices from threats specific to mobile environments. These platforms detect and respond to threats that traditional security tools miss.

Threat detection identifies malicious apps, network attacks, and device compromises. MTD solutions analyze application behavior, network connections, and device configurations to spot indicators of compromise.

Phishing protection extends to mobile browsers and messaging applications. MTD platforms detect and block access to known phishing sites, warn users about suspicious links, and prevent credential theft.

Network security evaluates Wi-Fi and cellular connections for risks. MTD solutions identify man-in-the-middle attacks, rogue access points, and insecure network configurations that could expose data.

Data protection strategies for BYOD

Think of containerization as a secure vault inside your employee's phone. Work apps and data stay locked in their own space — completely separate from personal photos, messages, and apps.

Application wrapping adds security controls to existing applications without modifying source code. Wrapped applications enforce encryption, prevent data leakage, and integrate with authentication systems.

Data Loss Prevention (DLP) within protected spaces prevents unauthorized data transfers. Users can't copy corporate data to personal applications, upload files to unsanctioned cloud services, or share information through unmanaged channels.

Remote wiping and data recovery

The future of BYOD security: Emerging trends and technologies

AI-powered threat detection will enhance BYOD security by identifying subtle behavioral anomalies and zero-day threats. Machine learning models will adapt to evolving attack patterns faster than signature-based approaches.

Passwordless authentication using biometrics and hardware tokens will replace traditional passwords. This shift reduces phishing risks and improves user experience on personal devices.

Edge computing will enable real-time security decisions without routing all traffic through centralized systems. Devices will make local security assessments, improving performance while maintaining protection.

Integration with SASE (Secure Access Service Edge) architectures will provide comprehensive security for BYOD users regardless of location. Cloud-delivered security services will protect devices accessing resources from anywhere.

Conclusion: Building a balanced BYOD security strategy

Effective BYOD security requires balancing protection with usability. Overly restrictive approaches drive non-compliance, and insufficient security exposes your organization to unacceptable risks.

Start with clear policies that employees understand and accept. Implement technical controls that protect data without unnecessarily invading privacy. Provide training that empowers employees to recognize and respond to threats.

Monitor your BYOD environment continuously, adapting to new threats and changing business needs. Regular assessments ensure your security measures remain effective as technology and attack methods evolve.

BYOD done right delivers flexibility, cost savings, and employee satisfaction without compromising security. The key is treating BYOD security as an ongoing program, not a one-time implementation.

Frequently Asked Questions

Introducing Passwork Desktop app

Passwork is now available as a full-featured desktop app for Windows, macOS, and Linux. The desktop app delivers complete password management functionality: manage credentials, access vaults, collaborate with your team, all with the native performance and convenience of a desktop environment.

Passwork BlogEirik Salmi

Case study: City of Melle and Passwork

Passwork has improved the internal security at the City of Melle by creating a reliable system for password management.

Passwork BlogAna Moore

Passwork: Secrets management and automation for DevOps

Introduction In corporate environment, the number of passwords, keys, and digital certificates is rapidly increasing, and secrets management is becoming one of the critical tasks for IT teams. Secrets management addresses the complete lifecycle of sensitive data: from secure generation and encrypted storage to automated rotation and audit trails. As

Passwork BlogEirik Salmi

Most data breaches start the same way: with weak or poorly managed credentials. In basic web application attacks alone, the 2025 Verizon DBIR traced 88% of incidents back to stolen passwords. For any organization handling sensitive data, computer security starts with credential control. And password security has shifted beyond a recommendation and become a baseline requirement.

A password manager addresses this risk. For every account, it generates, stores, and auto-fills unique credentials — all protected by one master password. Instead of spreadsheets, sticky notes, and repeated password resets, teams get a controlled and auditable process across the entire workflow.

Main points:

• One master password replaces hundreds of weak, reused credentials
• AES-256 encryption and zero-knowledge architecture keep your vault unreadable, even to the provider
• Setup takes planning, but the payoff is fewer support tickets, stronger compliance, and reduced breach risk

Understanding password managers

A password manager works as an encrypted vault — a digital safe that holds login credentials, secure notes, and other sensitive data. When you sign in somewhere, the manager retrieves the right password and fills the form automatically. Behind that vault stand two technologies: encryption and zero-knowledge architecture.

How password managers protect your digital identity

Before data leaves your device, AES-256 encryption (Advanced Encryption Standard with a 256-bit key) scrambles it into unreadable ciphertext. The same algorithm is used by governments and financial institutions.

Zero-knowledge architecture adds a second layer. Under this model, the provider cannot decrypt your data. Because all cryptographic operations happen locally, even full server access would reveal only encrypted blobs. We publish our cryptography documentation openly so teams can verify exactly how this works.

What password managers can and cannot do

A password manager is a reliable layer of defense, though it does not cover every threat on its own. Knowing its limitations helps you plan additional safeguards.

Multi-factor authentication (MFA) adds a second verification step, such as a time-based one-time password (TOTP), and addresses gaps that a password manager alone cannot cover. Together, they form a much stronger defense.

Creating your master password

Your master password is the single credential that unlocks the entire vault — a weak one undermines every other security measure.

Released in August 2025, NIST SP 800-63B-4 sets a minimum length of 15 characters for passwords used as a single-factor authenticator. The same revision states that verifiers shall not impose password composition rules (e.g., requiring uppercase letters, numbers, or symbols) and instead must screen passwords against lists of commonly used or compromised values. A password like "P@ssw0rd123" would fail such screening.

Instead of random character requirements, the passphrase method works better: pick four or five unrelated words and combine them. A password generator can produce random word combinations, but many users prefer manual selection. "correct-horse-battery-staple" is a classic example — high entropy.

Step-by-step master password creation:

1. Choose 4–5 random, unrelated words (avoid song lyrics or famous quotes)
2. Add a separator between words (hyphens, dots, or spaces)
3. Optionally insert one number or symbol at a random position — not at the end
4. Test: can you type it from memory three times in a row?
5. Write it down once, store that paper in a physically secure location, then memorize it within a week

Master password best practices

Do:

• Memorize it, never store it digitally in plain text
• Keep one physical backup in a secure place (a sealed envelope in a safe, for example)
• Practice typing it regularly during the first week

Don't:

• Reuse your master password for any other account
• Share it with anyone, including IT staff
• Change it on a fixed schedule without reason: according to NIST SP 800-63B-4, passwords should change only when evidence of compromise exists

Recovery options are limited by design. With a zero-knowledge architecture, the provider cannot reset your master password because they never had access to it.

Choosing the right password manager for your needs

Before committing to any password management software, define what your organization actually requires. Deployment model, encryption standards, and integration with existing infrastructure should all factor into the decision.

When deployment flexibility and security architecture matter, both on-premise and cloud options should be available. Passwork supports both models, so you can choose where your data lives. The platform features a user-friendly interface that teams can quickly adopt. It combines password management with DevOps secrets management, API keys, tokens, and certificates in one system.

If you're evaluating multiple solutions, see how we perform in a real deployment scenario. Get a demo environment and test alongside other enterprise password managers. No credit card required.

Browser-based vs. dedicated password managers

Browser-built password managers (like the ones in Chrome or Edge) are convenient, but they lack enterprise features. Within a single browser profile, credentials remain isolated — sharing, role-based access, and audit logging are either absent or limited.

With a dedicated password manager, encryption happens independently of the browser, alongside granular access controls and multi-platform sync. Auto-fill and credential capture still run through a browser extension, but the vault sits in a more controlled environment.

Getting started with your password manager

With the master password ready and the solution selected, setup begins. The process follows a predictable path.

1. Install the core application: desktop client, web interface, or self-hosted instance
2. Create your account with the master password you prepared
3. Enable MFA immediately before adding any credentials to the vault
4. Install browser extensions for Chrome, Firefox, Edge, or Safari
5. Install mobile apps for iOS and Android if remote access is needed
6. Configure vault structure: create shared and personal vaults by department, project, or access level

Setting up browser extensions and mobile apps

After installing the extension, adjust a few settings:

• Enable auto-lock after inactivity — five minutes is a reasonable default
• Turn on PIN or biometric lock for the mobile app
• Confirm the extension connects to the correct server URL (required for on-premise deployments)
• Disable auto-fill on public or shared devices

A password saved on your laptop appears on your phone within seconds through cross-platform sync. All data travels encrypted, so even an intercepted sync payload is useless without the master password.

Setting up two-factor authentication for your password manager

MFA adds a second lock to your vault through an additional security verification step. Even if someone learns your master password, access still requires that second factor.

Authenticator apps (Google Authenticator, Authy) generate six-digit TOTP codes that refresh every 30 seconds. During setup, scan the QR code, verify the first code, and save the backup recovery codes in a physically secure location. Without those codes, losing your phone could mean losing vault access.

Importing and organizing your existing passwords

Migration from browsers, spreadsheets, or another password manager into your password storage vault usually starts with a CSV (Comma-Separated Values) export. Most managers accept this format and map fields (URL, username, password) automatically.

Before importing, audit what you have. Old accounts, duplicate entries, and credentials reused across services all need attention. The import stage is the ideal time to replace weak passwords with generated ones. 

Our admin tools let you configure vault structures that mirror your team's organization. With role-based access, the finance team sees only finance credentials, while IT administrators maintain oversight of everything. This combination with a cost-efficient approach gives you enterprise-grade control without paying for features you do not need.

For teams implementing password management for the first time, setting up the right structure early prevents future access issues. Book a consultation to define your access model, deployment approach, and rollout plan.

Prioritizing your most critical accounts

Not all accounts carry the same risk. Start migration with the credentials that would cause the most damage if compromised:

1. Primary email accounts (often the recovery method for everything else)
2. Financial services and payment platforms
3. Cloud infrastructure and admin panels
4. Business communication tools (Slack, Teams, email servers)
5. Social media and public-facing accounts

According to IBM's 2025 Cost of a Data Breach Report, the global average breach cost reached $4.44 million, and the average time to identify and contain an incident was 241 days. Early migration of high-value accounts reduces that exposure window.

Using password health and data breach tools

Once credentials are in the vault, run a password vault health report — a routine computer security check. Built-in data breach monitoring scans your entries against known breach databases, while compromised password detection flags reused or weak credentials. Address critical findings first, especially any accounts where the same password protects multiple services.

Generating and managing strong passwords

For every new account or password replacement, use the built-in password generator. A strong configuration for high-security accounts: 20+ characters, mixed case, numbers, and symbols. Where services impose character limits, adjust — but never go below 15 characters.

A generated password like "g7#Kp!2xVmNqR9bW" has no predictable structure, which makes brute-force attacks impractical. The password manager remembers it, so complexity costs nothing in usability.

Using autofill features securely

Auto-fill speeds up form filling, but it requires awareness. Before letting the extension complete a login, verify these indicators:

• The URL in the address bar matches the expected domain exactly
• The connection uses HTTPS (look for the padlock icon)
• The password manager recognizes the site; if it doesn't offer auto-fill, the domain may be spoofed
• No unexpected redirects occurred before the login page loaded

A phishing page at g00gle.com looks convincing, yet the password manager matches exact domains and will not auto-fill on a fake site. On personal and work devices, keep the extension locked when not in active use.

Sharing passwords securely with others

For joint accounts, admin panels, and third-party services, teams need to share credentials. Sending passwords over email, Slack, or text messages is the wrong approach. Through built-in sharing features, encryption stays intact — credentials remain protected in transit.

We designed our role-based access controls to manage department-specific credentials and temporary contractor access. With on-premise deployment, shared secrets never transit through external servers. Learn more about our approach to business password management.

Managing family and team access

Shared password vaults work like shared folders: each vault has its own access permissions. An IT administrator might have full access, while a marketing team member sees only the social media credentials vault. Under GDPR, organizations must both protect personal data from unauthorized access and prove that protection is in place. Granular access controls and audit logs address both requirements at once.

Advanced features worth using

Beyond storing passwords, most enterprise password managers include features that teams often overlook. Secure notes let you store Wi-Fi credentials, server details, software license keys, or recovery codes — all protected by AES-256 encryption.

Through SSO (Single Sign-On) integration, the password manager connects with your identity provider, reducing friction for users who already authenticate through AD or LDAP. Audit logs track every action: who accessed which credential, when, and from which device — this simplifies GDPR and PCI-DSS (Payment Card Industry Data Security Standard) reporting.

Secure notes and document storage

Secure Shell keys (SSH), API tokens, recovery phrases, or internal procedures — all of these belong in secure notes rather than scattered across email threads or shared drives. Encryption protects them identically to passwords, and access controls determine who sees what.

Device syncing and access management

When a team member updates a password on their laptop, every authorized device reflects that change within seconds. Encrypted in transit, the data travels to the server (or your on-premise instance) and arrives at other devices still protected. Decryption happens only locally.

Proper device management requires MFA verification before any new device gains vault access. Without this step, an attacker who clones a session token could silently reach stored credentials.

Troubleshooting common password manager issues

Maintaining your password security long-term

Security is not a one-time setup. Quarterly reviews keep your vault in good shape:

1. Run the vault's security audit to identify weak, reused, or old passwords
2. Replace any flagged credentials using the built-in password generator
3. Review shared vault access — remove former employees or contractors
4. Verify MFA is still active and backup codes are accessible
5. Check for any accounts in known breach databases and rotate those passwords immediately

What to do if your password manager is compromised

If you suspect your master password has been exposed, immediate damage control is critical for your computer security:

1. Change the master password immediately from a trusted device
2. Enable or re-verify MFA on the vault account
3. Rotate passwords for your highest-priority accounts (email, financial, infrastructure)
4. Review the vault's audit log for unauthorized access
5. Notify your security team and begin an incident response according to your organization's protocol

Conclusion: your next steps to password security

A password manager replaces guesswork with structure, a direct upgrade to your organization's digital protection. Instead of hoping employees choose strong passwords, you give them a tool that does it automatically and keeps every credential encrypted, auditable, and under control.

The first step is the simplest: choose a solution, create a strong master password, and start migrating your most critical accounts today.

Frequently Asked Questions

Passwork: Secrets management and automation for DevOps

Introduction In corporate environment, the number of passwords, keys, and digital certificates is rapidly increasing, and secrets management is becoming one of the critical tasks for IT teams. Secrets management addresses the complete lifecycle of sensitive data: from secure generation and encrypted storage to automated rotation and audit trails. As

Passwork BlogEirik Salmi

What is password management?

Learn what password management is, why it matters, and how it protects your accounts with encryption, secure storage, and access control.

Passwork BlogEirik Salmi

Passwork 7.1: Vault types

Vault types Passwork 7.1 introduces a robust vault types architecture, providing enterprise-grade access control for enhanced security and management. Vault types address a key challenge for administrators: controlling data access and delegating vault management across large organizations. Previously, the choice was limited to two types. Now, you can create

Passwork BlogEirik Salmi

Passwork ist jetzt als vollwertige Desktop-App für Windows, macOS und Linux verfügbar. Die Desktop-App bietet den kompletten Funktionsumfang für die Passwortverwaltung: Zugangsdaten verwalten, auf Tresore zugreifen und mit Ihrem Team zusammenarbeiten — alles mit der nativen Leistung und dem Komfort einer Desktop-Umgebung.

Unterstützte Betriebssysteme

Die Desktop-Anwendung unterstützt Windows 10/11 (64-Bit), macOS 12 (Monterey) und neuer sowie Linux-Distributionen einschließlich Ubuntu 20.04+, Fedora 34+, Debian 11+ und andere (64-Bit).

So laden Sie die App herunter

Sie können die Desktop-App direkt über die Passwork-Oberfläche herunterladen.

Öffnen Sie Passwork → Einstellungen und Benutzer → Desktop-App und laden Sie das Installationsprogramm für Ihr Betriebssystem herunter.

Installation

Die App authentifiziert sich über Ihren Browser. Sie benötigen den Hostnamen Ihrer Passwork-Instanz.

1. Laden Sie das Installationsprogramm herunter.
2. Installieren Sie die App für Ihr Betriebssystem und starten Sie sie.
3. Geben Sie Ihren Passwork-Hostnamen ein und klicken Sie auf Mit Browser anmelden.
4. Authentifizieren Sie sich im Browser: Geben Sie Ihre Zugangsdaten ein oder melden Sie sich über SSO oder Passkey an.
5. Erlauben Sie der App, sich mit Ihrer Browser-Sitzung zu verbinden.
6. Wenn die clientseitige Verschlüsselung in Passwork aktiviert ist, geben Sie Ihr Masterpasswort in der App ein.

Hinweis: Wenn Sie eine aktive Sitzung in der Web-Version haben, werden Sie von Passwork gefragt, ob Sie mit dem aktuellen Benutzer fortfahren oder das Konto wechseln möchten.

So aktualisieren Sie die App

Neue Versionen der Desktop-App werden zusammen mit Passwork-Updates veröffentlicht. Wenn eine neue Version verfügbar ist, werden Sie von der App zur Aktualisierung aufgefordert. Der Vorgang ist automatisch — das Installationsprogramm wird aus dem Repository heruntergeladen und ohne manuellen Eingriff installiert.

Was kommt als Nächstes

Kommende Versionen werden exklusive Desktop-Funktionen einführen, einschließlich eines Offline-Modus. Greifen Sie auf Ihre Passwörter ohne Serververbindung zu und gewährleisten Sie Kontinuität auch bei nicht verfügbarem Netzwerkzugang.

Passwork 7.5 und 7.5.1 Releases

Die neuen Releases führen die Unterstützung der Passwork Desktop-App ein und fügen mehrere Verbesserungen und Fehlerbehebungen zu den Authentifizierungseinstellungen hinzu.

Passwork BlogEirik Salmi

Passwork gewinnt Best Customer Support 2026 von Software Advice

Wir freuen uns, mitteilen zu können, dass der Kundensupport von Passwork als der beste in der Kategorie Passwort-Manager von Software Advice ausgezeichnet wurde.

Passwork BlogMike Shikun

Passwork: Secrets Management und Automatisierung für DevOps

Einführung In Unternehmensumgebungen steigt die Anzahl von Passwörtern, Schlüsseln und digitalen Zertifikaten rapide an, und Secrets Management wird zu einer der kritischen Aufgaben für IT-Teams. Secrets Management umfasst den gesamten Lebenszyklus sensibler Daten: von der sicheren Generierung und verschlüsselten Speicherung bis hin zur automatisierten Rotation und Audit-Trails. Da

Passwork BlogEirik Salmi

Passwork ya está disponible como una aplicación de escritorio completa para Windows, macOS y Linux. La aplicación de escritorio ofrece funcionalidad completa de gestión de contraseñas: gestione credenciales, acceda a bóvedas, colabore con su equipo, todo con el rendimiento nativo y la comodidad de un entorno de escritorio.

Sistemas operativos compatibles

La aplicación de escritorio es compatible con Windows 10/11 (64 bits), macOS 12 (Monterey) y versiones posteriores, y distribuciones de Linux incluyendo Ubuntu 20.04+, Fedora 34+, Debian 11+ y otras (64 bits).

Cómo descargar

Puede descargar la aplicación de escritorio directamente desde la interfaz de Passwork.

Abra Passwork → Configuración y usuarios → Aplicación de escritorio y descargue el instalador para su sistema operativo.

Instalación

La aplicación se autentica a través de su navegador. Necesitará el nombre de host de su instancia de Passwork.

1. Descargue el instalador.
2. Instale la aplicación para su sistema operativo e iníciela.
3. Introduzca el nombre de host de Passwork y haga clic en Iniciar sesión con navegador.
4. Autentíquese en el navegador: introduzca sus credenciales o inicie sesión mediante SSO o passkey.
5. Permita que la aplicación se conecte a su sesión del navegador.
6. Si el cifrado del lado del cliente está habilitado en Passwork, introduzca su contraseña maestra en la aplicación.

Nota: Si tiene una sesión activa en la versión web, Passwork le preguntará si desea continuar con el usuario actual o cambiar de cuenta.

Cómo actualizar

Las nuevas versiones de la aplicación de escritorio se publican junto con las actualizaciones de Passwork. Cuando una nueva versión está disponible, la aplicación le solicita que actualice. El proceso es automático — el instalador se descarga del repositorio y se instala sin intervención manual.

Próximas novedades

Las próximas versiones introducirán funciones exclusivas para escritorio, incluyendo el modo sin conexión. Acceda a sus contraseñas sin conexión al servidor, garantizando la continuidad incluso cuando el acceso a la red no esté disponible.

Versiones Passwork 7.5 y 7.5.1

Las nuevas versiones introducen compatibilidad con la aplicación de escritorio de Passwork y añaden varias mejoras y correcciones de errores en la configuración de autenticación.

Passwork BlogEirik Salmi

Passwork gana el premio Mejor Soporte al Cliente 2026 de Software Advice

Nos complace compartir que el soporte al cliente de Passwork ha sido reconocido como el mejor en la categoría de Gestores de Contraseñas por Software Advice.

Passwork BlogMike Shikun

Passwork: Gestión de secretos y automatización para DevOps

Introducción En el entorno corporativo, el número de contraseñas, claves y certificados digitales está aumentando rápidamente, y la gestión de secretos se está convirtiendo en una de las tareas críticas para los equipos de TI. La gestión de secretos aborda el ciclo de vida completo de los datos sensibles: desde la generación segura y el almacenamiento cifrado hasta la rotación automatizada y los registros de auditoría. A medida que

Passwork BlogEirik Salmi

Passwork is now available as a full-featured desktop app for Windows, macOS, and Linux. The desktop app delivers complete password management functionality: manage credentials, access vaults, collaborate with your team, all with the native performance and convenience of a desktop environment.

Supported operating systems

The desktop application supports Windows 10/11 (64-bit), macOS 12 (Monterey) and later, and Linux distros including Ubuntu 20.04+, Fedora 34+, Debian 11+, and others (64-bit).

How to download

You can download the desktop app directly from the Passwork interface.

Open Passwork → Settings and users → Desktop app and download the installer for your operating system.

Installation

The app authenticates through your browser. You'll need your Passwork instance hostname.

1. Download the installer
2. Install the app for your OS and launch it
3. Enter your Passwork hostname and click Sign in with browser
4. Authenticate in the browser: enter your credentials or sign in via SSO or passkey
5. Allow the app to connect to your browser session
6. If client-side encryption is enabled in Passwork, enter your master password in the app

Note: If you have an active session in the web version, Passwork will prompt you to continue with the current user or switch accounts.

How to update

New desktop app versions are released alongside Passwork updates. When a new version becomes available, the app prompts you to update. The process is automatic — the installer downloads from the repository and installs without manual intervention.

What's next

Upcoming releases will introduce desktop-exclusive features, including offline mode. Access your passwords without a server connection, ensuring continuity even when network access is unavailable.

Passwork wins Best Customer Support 2026 by Software Advice

We’re excited to share that Passwork’s customer support has been recognized as the best in the Password Managers category by Software Advice.

Passwork BlogMike Shikun