Cybersecurity

The two-year period from 2025 to 2026 produced the largest credential exposure in recorded history. A single support portal account with no MFA gave an attacker access to records on 60 million students and 10 million educators across 18,000 school districts. The most expensive cyberattack in British corporate history shut down factory production for weeks and cost an estimated £1.9–2.1 billion (around 2,2–2,5 billion €).

Large incidents get investigated thoroughly: root causes published, attack chains reconstructed, regulatory findings released. That makes them the clearest window into how attackers actually operate.

This article breaks down what made 2025–2026 different: the five structural shifts in attacker behavior, the specific breaches that defined the period, and a six-step framework for closing the credential gaps that made most of them possible.

Key takeaways

• Credential reuse is a structural risk, not a user behavior problem. 16 billion credentials in one searchable corpus means any reused password is effectively public. Unique credentials per service, enforced at the vault level, is the only reliable fix.
• Third-party access is your access surface. 48% of 2026 breaches traced to a vendor or SaaS integration. Your security posture is only as strong as the weakest OAuth grant you've forgotten about.
• Privileged accounts outside governance are the highest-risk accounts you have. SSA and PowerSchool both failed on the same point: accounts with unrestricted access that existed outside normal IAM controls.
• Unpatched ERP software is now a confirmed, financially quantified attack vector. CVE-2025-31324 cost JLR an estimated £1.9–2.1 billion. Patch windows for internet-facing enterprise software are measured in hours, not weeks.
• Data you don't delete is data you're responsible for. The University of Hawaiʻi was liable for records from 1993. Data minimization is a security control, not a compliance checkbox.
• Social engineering bypasses technical controls entirely. M&S lost £300 million not to zero-day but to a phone call to a helpdesk agent. No firewall stops that.

The shift in cyber threats: 2025-2026 trends 

The 2025–2026 period marked a structural shift in how attackers operate — away from encrypting systems and toward stealing data and threatening to publish it. 

Five trends defined the period.

1. Data-theft extortion replaced ransomware as the dominant model. Cybercriminal groups like ShinyHunters industrialized the approach: exfiltrate data, set a deadline, publish if unpaid. Attackers no longer need to manage decryption keys or negotiate recovery — exfiltration and a leak site are sufficient.

2. Third-party supply chain attacks became the primary entry vector. The Verizon 2025 DBIR found third-party involvement in 30% of confirmed incidents. By 2026, that share reached 48% — meaning nearly half of all breaches now trace back to a vendor, SaaS provider, or OAuth integration rather than a direct attack on the organization itself (Verizon 2026 DBIR).

3. Education and healthcare became high-value targets. Student information systems and patient records now hold SSNs, medical histories, and insurance data — and both sectors consistently lag on basic controls like MFA and privileged access monitoring. 

4. Vulnerability exploitation overtook credential theft as the top initial access vector — 31% versus 13% in 2026, the first time in the DBIR's history. AI compressed the window between disclosure and active exploitation from months to hours. Compromised credentials still appear in 39% of all breaches when the full attack chain is considered.

5. Privileged access became an attack surface in its own right. A single account with unrestricted access and no monitoring can expose more data than a sophisticated external intrusion — no privilege escalation required.

The breaches below show how each of these patterns played out in practice.

The 16-billion credential mega-leak (June 2025)

The June 2025 credential mega-leak is the largest password exposure in recorded history: 16 billion login credentials across 30 separate databases, discovered by Cybernews researchers. The data was an aggregation of infostealer malware logs and prior breach compilations, assembled into a searchable corpus available on darknet markets for $10.

Infostealers harvest saved credentials from browsers and session cookies after the user has already authenticated. Credential reuse turns a single infection into an enterprise problem: according to Heimdal Security's analysis of Verizon DBIR 2025 data, 94% of passwords appear in multiple accounts. An employee whose personal account credentials were harvested may be using the same password on a corporate VPN or cloud console.

A centralized password vault that generates unique credentials per service, combined with phishing-resistant MFA, eliminates credential reuse as an attack surface.

Passwork's self-hosted vault generates and stores unique credentials for every service, making credential reuse structurally impossible. Audit logs show exactly who accessed what, and when. See how it works — https://passwork.pro/

SaaS supply chain under attack: Klue, Salesforce Experience Cloud, and Volvo/Miljödata

Third-party SaaS risk operates at three distinct levels simultaneously: credential theft, misconfiguration, and vendor concentration. 

The Klue breach (June 2026)

The Klue breach illustrates the credential theft vector. A legacy service account credential — the kind that gets created during an integration project and never rotated — was used to harvest OAuth tokens across dozens of connected platforms. The affected companies included HackerOne, Recorded Future, Jamf, and Tanium. Their CRM data in Salesforce, HubSpot, and Gong was exposed not because those platforms were breached, but because a single stale credential in a connected service gave an attacker the OAuth token needed to read data across all of them. OAuth token abuse at this scale is a direct consequence of ungoverned third-party integrations — shadow IT that security teams often cannot see until after the fact.

The Salesforce Experience Cloud misconfiguration (2025–2026) 

ShinyHunters exploited a Salesforce Experience Cloud misconfiguration to expose data across telecom, finance, and government organizations. Administrators had granted guest users broader read permissions than intended. The platforms were not breached — they were misconfigured. ShinyHunters claimed to have stolen data from around 100 high-profile companies, but Salesforce did not confirm that figure. 

The Miljödata ransomware attack (August 2025)

The DataCarry group attacked Miljödata, a Swedish HR software provider serving Volvo Group, approximately 25 other private companies, 200 Swedish municipalities, and multiple educational institutions. One vendor breach became hundreds of victims. According to Have I Been Pwned, 870,000 accounts were exposed, including government-issued identity numbers. Volvo Group North America began notifying employees on September 29, 2025, confirming that names and Social Security numbers had been exposed — data that originated in Volvo's HR processes but was stored in a third-party system Volvo did not control.

Together, these three cases show that third-party risk management cannot be reduced to a vendor questionnaire. It requires continuous monitoring of OAuth grants, SaaS permission audits, and an honest assessment of how many critical processes depend on a single external provider.

Healthcare under fire: NYC Health + Hospitals, Conduent, and Navia

Healthcare is the most expensive sector to breach. According to the IBM 2025 Cost of a Data Breach Report, the average cost of a healthcare breach reached $7.42 million — nearly double the global average of $4.44 million. The 2025-2026 period produced three incidents that show why.

The NYC Health + Hospitals data breach (2025)

1.8 million patients' records were exposed via a third-party vendor compromise.The NYC Health + Hospitals data breach included biometric templates — fingerprints and palm prints. Unlike passwords, biometric identifiers cannot be changed. An employee whose password is stolen can reset it. An employee whose fingerprint template is stolen has no equivalent recovery option. The permanent nature of biometric exposure makes IAM controls around biometric data storage categorically more critical than those around password storage.

Navia breach (2025)

Health benefits administrator Navia exposed 2.7 million records through an unauthenticated public API endpoint reachable from the open internet — a misconfiguration that mirrors the database exposure pattern above, applied to the application layer.

The Conduent Business Services breach (2025)

Attackers from the SafePay group were inside Conduent's network for 84 days before detection. Conduent processes payments, documents, and medical records for insurers and government agencies across North America. 

By the time the full scope was confirmed in June 2026, the breach had affected 62.2 million individuals, making it the third-largest healthcare data breach in recorded history. Among the confirmed victims: Premera Blue Cross, Humana, and multiple Blue Cross Blue Shield branches. The attackers never touched the insurers directly. They went through the vendor.

Healthcare's combination of high-value data, legacy infrastructure, and complex vendor ecosystems makes it the sector most consistently hit by both credential-based and extortion-based attacks.

When privilege becomes a weapon: SSA and PowerSchool

The DOGE/SSA incident illustrates that the most dangerous credential threat is not always external. A single privileged account with unchecked access can expose more data than any external breach.

The Social Security Administration data export (2025) 

The SSA case is the clearest argument for why privileged access management (PAM) and the principle of least privilege matter even inside organizations. DOGE operators with privileged access to SSA systems allegedly exported a full live database dump of SSN records — covering more than 300 million Americans — to an unsecured external server. No external attacker was involved. 

The PowerSchool breach (2025) 

A single support portal account, lacking MFA, session monitoring, and anomaly detection, exposed records of 60 million students and 10 million educators across the US, Canada, and the UK. 83% of affected students had their Social Security numbers exposed, along with medical records. The support account already had unrestricted access — no privilege escalation or lateral movement was needed.

Both incidents point to the same gap in IAM architecture: privileged accounts that exist outside the normal credential governance process. Support portals, vendor accounts, and administrative backdoors are frequently excluded from password rotation policies, MFA enforcement, and audit logging — the exact controls that would have prevented both breaches.

Europe under attack: Marks & Spencer, Jaguar, and the cost of social engineering

Three European incidents from 2025–2026 produced the most financially documented losses of the period.

The Marks & Spencer breach (2025) 

The breach exposed personal data across M&S's customer base — names, addresses, phone numbers, dates of birth, and order history. M&S did not disclose the exact number of affected customers. Scattered Spider, a cybercriminal group known for stealing sensitive data from Fortune 500 companies, gained initial access through a third-party managed IT services provider by impersonating an employee to a helpdesk agent via SIM-swapping. From there, they moved through Active Directory. Online sales were suspended for 46 days. M&S confirmed a £300 million (around €353 million) profit impact in its annual results.

The Jaguar Land Rover breach (2025) 

It’s the most expensive security breach in British corporate history, estimated at £1.9–2.1 billion (around €2.4 billion) by the Cyber Monitoring Centre. An unpatched SAP NetWeaver vulnerability (CVE-2025-31324, patched April 2025) halted production at factories globally. Wholesale deliveries fell 24.2% year-on-year in JLR's fiscal second quarter and 43% in the third. The Bank of England's manufacturing PMI for September 2025 fell to 46.2, with JLR's shutdown cited as a contributing factor.

The France Titres / ANTS breach (2026) 

Attackers exfiltrated 11.7 million accounts from France's national passport and ID portal. Government identity portals hold verified, legally binding identity data — which makes them high-value targets precisely because the data cannot be disputed or replaced.

The M&S and JLR cases confirm two attack vectors that are now financially quantified: social engineering against third-party contractors, and exploitation of unpatched enterprise ERP software.

The shadow data problem: University of Hawaiʻi and the legacy archive risk

The University of Hawaiʻi breach (2025) exposed records from 1993 to 2007 — data that had never been deleted, encrypted, or audited, demonstrating that data minimization is a direct security control.

A ransomware attack exposed 1.2 million records, including research archives created before modern encryption standards existed. Data from 1993 to 2007 was never subject to current access controls, yet it remained on live infrastructure — queryable, exfiltrable, and legally the university's liability.

Shadow IT and shadow data are two sides of the same governance failure. Shadow IT is the unauthorized application running on your network. Shadow data is the dataset that was created for a project in 2001, never deleted, and never included in any data inventory. Both are invisible to security controls because they were never registered in the first place.

The control is data minimization: retain only what is operationally necessary, and audit legacy datasets on a defined schedule. Organizations that cannot answer "what data do we hold, where is it, and who can access it?" cannot defend it.

How to protect your enterprise from the next mega-leak

The Enterprise Credential Defense Framework maps each control directly to a breach pattern from this article.

Step 1. Deploy a centralized enterprise password vault.

Eliminates credential reuse and provides a single audit trail for all credential access. A centralized password vault with role-based access control means that when a credential is compromised, the blast radius is contained to what that credential was authorized to access — not everything the employee happened to know.

Step 2. Enforce minimum 15-character passwords and phishing-resistant MFA.

Legacy password policies — 90-day mandatory rotation, complexity rules requiring symbols and mixed case — are counterproductive. NIST SP 800-63B Rev. 4 removes both requirements. The reasoning is empirical: forced rotation produces predictable incremental changes (Password1! → Password2!), and complexity rules generate passwords that are hard for humans to remember but easy for automated tools to crack.

For MFA specifically: SMS-based OTP is not recommended at AAL2. Hardware keys and passkeys meet the phishing-resistant threshold. The Verizon 2025 DBIR notes that MFA bypass techniques are growing — token theft accounts for 31% of bypass methods, MFA fatigue for 22% — but having MFA enabled still eliminates the vast majority of credential-based attacks.

Step 3. Audit and revoke ungoverned third-party SaaS integrations and OAuth grants.

Run a quarterly audit of all OAuth grants in your identity provider. Revoke any grant that cannot be attributed to an active, documented integration. Legacy service accounts should be rotated on a defined schedule and decommissioned when the integration is retired.

Step 4. Apply PAM controls and the principle of least privilege.

No account — internal or external — should have access beyond what its documented function requires. Privileged accounts should be time-limited, session-recorded, and subject to the same MFA requirements as any other account.

Step 5. Enforce data minimization and audit legacy datasets.

Establish a data retention schedule. Run an annual audit of datasets older than five years. Data that has no current operational purpose should be deleted, not archived on a live server.

Step 6. Eliminate arbitrary password expiration; adopt compromise-driven rotation.

Rotate credentials when a compromise is detected or suspected — not on a calendar. Integrate your password vault with breach intelligence feeds so that rotation is triggered by evidence, not by a 90-day clock that trains users to make predictable changes.

Conclusion

Three root causes appear in breach after breach across this article: credentials that were unmanaged or reused, access that was unchecked or over-permissioned, and data retained long past any operational purpose. Every incident covered here, from the 16-billion credential dump to the £1.9 billion JLR shutdown, maps to at least one of those three failures.

Every control in the Enterprise Credential Defense Framework maps to a documented failure in a named breach above. The question for your organization: which of those failures are you replicating right now?

Start with a credential audit: every privileged account, every OAuth grant, every service account in your environment. If you cannot answer those questions in under an hour, you have a visibility problem before you have a security problem.

Passwork is a self-hosted password and secrets manager built for exactly that audit: centralized vaults, role-based access, and zero-knowledge encryption, so you always know who has access to what. Explore deployment options — passwork.pro

Frequently asked questions

Passwork vs 1Password: Best Password Manager for EU

GDPR, NIS2, ANSSI 2027 — the regulatory pressure keeps building. We compare Passwork and 1Password on the criteria that matter to European businesses: data sovereignty, audit readiness, deployment model, and real total cost of ownership.

Passwork BlogPasswork Team

Team password management: The complete guide for 2026

Learn how teams share credentials securely in 2026 — RBAC, audit logs, offboarding checklists, NIST SP 800-63B Rev. 4 requirements, and self-hosted vs. cloud deployment.

PassworkAlex Muntyan

11 password reuse risks and how to avoid them

Reusing a password feels harmless. It isn’t. Here’s why one leaked credential can unravel your entire organization’s security — and how to stop it from happening.

Passwork BlogAlex Muntyan

El shadow IT en 2026 no se parece en nada al de hace cinco años. El problema ahora son los agentes de IA con tokens OAuth persistentes, las sesiones de LLM que procesan código fuente propietario en silencio y las cuentas SaaS huérfanas que nadie recuerda haber aprovisionado. Cada uno de estos elementos extiende la superficie de ataque corporativa mucho más allá de lo que cualquier perímetro de red tradicional fue diseñado para manejar.

Según el informe State of Shadow AI de UpGuard, más del 80% de los empleados utilizan herramientas de IA no aprobadas. Una encuesta de Gartner a 302 líderes de ciberseguridad (marzo-mayo de 2025) reveló que el 69% de las organizaciones sospechaban o habían confirmado que sus empleados utilizaban herramientas públicas de GenAI prohibidas. Gartner predice que para 2030, más del 40% de las empresas experimentará un incidente de seguridad o cumplimiento relacionado con shadow AI no autorizado.

El informe Cost of Insider Risks 2026 de DTEX/Ponemon cifra el coste anual de la negligencia interna impulsada principalmente por el shadow AI en 10,3 millones de dólares por organización. Esa cifra cubre incidentes donde no hubo intención maliciosa: solo empleados usando herramientas que TI nunca aprobó, y presupuestos financiando silenciosamente infraestructura que nadie puede ver ni proteger.

Puntos clave

• El shadow IT en 2026 es tanto un problema de IA como de SaaS. Los agentes de IA con tokens OAuth persistentes, las sesiones de LLM que procesan código fuente propietario y las cuentas SaaS huérfanas que sobreviven a sus propietarios son ahora los riesgos de mayor gravedad.
• El shadow AI es categóricamente diferente del shadow IT tradicional. Las herramientas SaaS no autorizadas almacenan datos en el lugar equivocado. Las herramientas de IA no autorizadas los procesan, analizan y actúan sobre ellos.
• La exposición financiera está cuantificada. El informe Cost of a Data Breach 2025 de IBM encontró que la participación del shadow AI añade 670.000 dólares al coste promedio de una brecha de 4,44 millones de dólares. El informe Cost of Insider Risks 2026 de DTEX/Ponemon cifra el coste anual de la negligencia interna impulsada por IA en 10,3 millones de dólares por organización.
• La detección requiere al menos cinco fuentes de datos trabajando en paralelo. CASB, análisis de logs DNS, EDR, revisión de datos de gastos y escaneo de integraciones de correo electrónico cubren cada uno una porción diferente del entorno. Ningún método único ve simultáneamente los dispositivos personales, las cuentas de nivel gratuito y los endpoints gestionados.
• Las organizaciones europeas enfrentan una exposición regulatoria por capas. Las herramientas SaaS no autorizadas violan el Artículo 28 del GDPR en el momento en que procesan datos personales sin un DPA firmado. El Artículo 21 de NIS2 trata las herramientas de terceros no verificadas como riesgo de la cadena de suministro. El Artículo 28 de DORA exige a las entidades financieras registrar cada proveedor de TIC — sea shadow o no.
• Bloquear sin habilitar alternativas falla consistentemente. Casi la mitad de los empleados continúan usando cuentas personales de IA después de una prohibición organizacional. La respuesta efectiva es hacer que el camino aprobado sea más rápido que el atajo: un flujo de aprobación ligero, gestión centralizada de credenciales y un programa de concienciación de seguridad que haga tangible el riesgo.
• El Marco de Gobernanza de Shadow IT de 6 pasos — descubrir y clasificar, centralizar credenciales, establecer políticas, agilizar aprobaciones, automatizar el offboarding, construir concienciación de seguridad — aborda tanto el lado técnico como el conductual del problema. Las herramientas manejan la detección. El marco cambia la estructura de incentivos que impulsa la adopción del shadow IT en primer lugar.

¿Qué es el shadow IT?

Shadow IT es cualquier tecnología (software, servicio en la nube, herramienta de IA o hardware) que los empleados utilizan para trabajar sin el conocimiento o la aprobación formal de TI. Abarca desde una carpeta personal de Dropbox usada para compartir archivos de proyectos, hasta un asistente de codificación de IA con acceso OAuth a repositorios de producción. El hilo común: sin revisión de seguridad, sin registro de adquisición, sin pista de auditoría.

El shadow IT no es un problema marginal. Gartner sitúa la proporción del gasto de TI consumido por herramientas no autorizadas entre el 30-40% en grandes empresas. El análisis de Harmonic Security de 22,4 millones de prompts empresariales de IA identificó 665 herramientas distintas de IA generativa ejecutándose en entornos empresariales — sin embargo, solo el 40% de esas organizaciones había adquirido una suscripción oficial de IA. El tráfico de GenAI aumentó más del 890% solo en 2024.

Shadow IT vs. shadow AI: Cómo se comparan los riesgos

¿Qué impulsa a los empleados a usar shadow IT?

Los empleados recurren a herramientas no autorizadas cuando las alternativas aprobadas son demasiado lentas, demasiado limitadas o simplemente aún no existen. La fricción es la causa: un desarrollador que espera tres semanas por un asistente de IA con licencia encontrará uno gratuito antes de que termine el día.

Tres patrones se repiten en organizaciones de todos los tamaños:

• Velocidad sobre proceso. Los empleados recurren a lo que sea que haga el trabajo más rápido. Cuando las herramientas aprobadas no igualan lo que está disponible gratuitamente fuera de la empresa, la elección es obvia: usar lo que funciona.
• Retraso en adquisiciones. Los ciclos de software empresarial funcionan por trimestres. Las herramientas de IA se lanzan por semanas. Para cuando TI evalúa y aprueba una herramienta, los empleados ya han construido flujos de trabajo alrededor de su equivalente de nivel gratuito.
• Brechas funcionales. Las herramientas aprobadas a menudo no cubren casos de uso específicos. Un analista de datos que necesita un entorno Python rápido, o un diseñador que necesita un generador de imágenes específico, recurrirá a lo que funcione, no a lo que esté en la lista aprobada.
• Sin ciclo de retroalimentación. Los empleados rara vez reportan las herramientas que están usando porque no hay un canal fácil para hacerlo. TI no sabe qué gobernar. Seguridad no sabe qué auditar. La brecha entre el uso real de herramientas y el inventario aprobado se amplía silenciosamente.
• Las prohibiciones no se sostienen. Casi la mitad de los empleados continúan usando cuentas personales de IA después de una prohibición organizacional. La prohibición no elimina el shadow IT. Solo lo empuja fuera de la vista, haciendo la detección más difícil y la respuesta más lenta.

Estos patrones son una respuesta predecible a estructuras de gobernanza que no han seguido el ritmo de la velocidad con que evoluciona el ecosistema de herramientas. Esa brecha es exactamente lo que convierte al shadow IT en un riesgo sistémico en lugar de un problema de disciplina.

La evolución del shadow IT en 2026

El shadow IT en 2026 ha ido mucho más allá del almacenamiento en la nube no gestionado. Ahora abarca herramientas de IA, agentes autónomos y ecosistemas SaaS completos que TI nunca aprobó, nunca inventarió y no puede monitorear. La empresa promedio ejecuta 305 aplicaciones SaaS, gasta 55,7 millones de dólares en SaaS anualmente, y ha visto el gasto en aplicaciones nativas de IA aumentar un 108% interanual — la mayor parte de ese crecimiento ocurriendo más rápido de lo que los equipos de gobernanza pueden rastrear.

De la proliferación de SaaS al shadow AI

La cifra de 305 aplicaciones proviene del Zylo 2026 SaaS Management Index, que se basa en datos de gasto reales de miles de organizaciones. Una proporción significativa de esas aplicaciones nunca fueron aprobadas formalmente. Los empleados adoptan herramientas de forma independiente y TI se entera meses después, si es que se entera.

El shadow AI acelera esta dinámica. Asistentes de IA gratuitos, generadores de código y agentes autónomos se volvieron ampliamente disponibles más rápido de lo que los ciclos de adquisición podían responder. El informe Check Point 2026 Cloud Security Report encontró que el 78-80% de los trabajadores usan herramientas de IA personales en el trabajo. La mayoría de esas sesiones ocurren a través de cuentas personales, fuera de SSO, fuera de DLP, y sin pista de auditoría.

La distinción vale la pena precisarla: 

• El shadow IT tradicional crea residencia de datos no gestionada: archivos almacenados en un servicio no autorizado. 
• El shadow AI crea procesamiento de datos no gestionado: información propietaria siendo analizada, resumida y utilizada por sistemas que su equipo de seguridad nunca ha revisado.

Por qué la superficie de ataque sigue expandiéndose

Tres fuerzas estructurales impulsan esto:

• El trabajo remoto e híbrido eliminó el perímetro de red como punto de control natural. Los empleados que trabajan desde casa adoptan herramientas sin canalizar las solicitudes a través de TI.
• Los niveles gratuitos están en todas partes. La mayoría de las herramientas SaaS ofrecen un punto de entrada sin coste. Sin orden de compra, sin ticket de aprobación, sin visibilidad.
• La proliferación de agentes de IA cambió las apuestas. Los agentes operan a través de permisos OAuth delegados — leyendo datos, activando flujos de trabajo y modificando registros de forma autónoma. Un desarrollador que conecta un asistente de codificación de IA a su cuenta de GitHub puede haber otorgado a ese agente acceso de lectura/escritura a los repositorios. Cuando el desarrollador se va, el permiso OAuth permanece.

Gartner proyecta que para 2027, el 75% de los empleados adquirirá, modificará o creará tecnología fuera de la visibilidad de TI — frente al 41% en 2022. La dirección es inequívoca.

Los riesgos ocultos del shadow IT (la realidad de 2026)

El shadow IT en 2026 no es solo un problema de fuga de datos. Las herramientas no gestionadas crean acceso no autorizado persistente, exponen credenciales, desencadenan violaciones regulatorias, y cada vez más alimentan datos empresariales en modelos de IA que ningún equipo de seguridad ha aprobado o puede monitorear.

El multiplicador de riesgo del shadow AI: Procesamiento de datos vs. almacenamiento de datos

El shadow IT tradicional almacena datos en el lugar equivocado. El shadow AI hace cosas con ellos. Pegar un contrato de cliente en un LLM público envía esos datos a al menos tres lugares: un pipeline de entrenamiento, un sistema de logging, y potencialmente un modelo que otros usuarios pueden consultar.

El informe Cost of a Data Breach 2025 de IBM pone un número a esto: las brechas que involucraban altos niveles de shadow AI añadieron un promedio de 670.000 dólares al coste total de la brecha, llevando el promedio de brechas relacionadas con shadow AI a aproximadamente 5,11 millones de dólares contra una línea base global de 4,44 millones. El mismo informe encontró que el 97% de los incidentes de seguridad relacionados con IA involucraban sistemas sin controles de acceso adecuados.

Exposición de credenciales y reutilización de contraseñas

El shadow IT es, en su raíz, un problema de identidad. Cada aplicación no autorizada es una nueva cuenta. Cada nueva cuenta es una credencial. Y la mayoría de esas credenciales se reutilizan.

Según el informe Data Breach Investigations Report 2026 de Verizon, las credenciales robadas aparecieron en el 39% de todas las brechas confirmadas, no solo como el vector de acceso inicial, sino a lo largo del movimiento lateral y la persistencia. Cuando un empleado reutiliza su contraseña corporativa en una herramienta SaaS gratuita que posteriormente sufre una brecha, los atacantes no necesitan romper nada. Simplemente inician sesión.

Los infostealers empeoran esto. En 2025, Recorded Future indexó 1.950 millones de exposiciones de credenciales procedentes de malware, de las cuales el 31% incluía cookies de sesión activas que evitan completamente el MFA. Las cuentas de shadow IT, no monitoreadas, a menudo sin MFA configurado, son exactamente el tipo de objetivo para el que están diseñados los infostealers.

El riesgo de reutilización de contraseñas es un patrón de ataque documentado, automatizado y a escala industrial.

La pesadilla del offboarding: Cuentas huérfanas

Cuando un empleado se va, sus cuentas gestionadas se desaprovisionan. Sus cuentas de shadow IT no. Nadie sabe que existen.

El espacio de trabajo de Figma de ese antiguo desarrollador, la prueba personal de HubSpot del representante de ventas con datos exportados del CRM, la página de Notion del contratista con notas de arquitectura interna: todo esto persiste indefinidamente después de que la persona sale por la puerta.

Las consecuencias pueden ser graves. En un caso documentado, un antiguo empleado de Cisco accedió a una infraestructura de máquinas virtuales alojada en AWS cinco meses después de su despido y eliminó 456 máquinas virtuales, dejando fuera de servicio más de 16.000 cuentas de WebEx Teams durante casi dos semanas.

El Departamento de Justicia de EE. UU. confirmó que el incidente le costó a Cisco aproximadamente 2,4 millones de dólares en remediación y reembolsos a clientes, y el antiguo empleado fue sentenciado a 24 meses en una prisión federal (United States v. Sudhish Kasaba Ramesh, Caso N.º 5:20-cr-00102). Ese era un sistema gestionado. Las cuentas de shadow IT huérfanas son más difíciles de encontrar y tardan más en cerrarse — si es que se cierran alguna vez.

Agentes de IA y permisos OAuth no gestionados

Esta es la amenaza que la mayoría de las organizaciones aún no están rastreando. Los agentes de IA operan a través de permisos OAuth delegados: un usuario otorga al agente acceso a Google Drive, GitHub o Slack, y el agente puede leer, escribir y actuar sobre ese acceso de forma continua — no solo durante la sesión.

Cuando el usuario cierra sesión, el permiso OAuth permanece. Cuando el usuario deja la empresa, el permiso OAuth permanece. El agente puede seguir teniendo acceso a repositorios corporativos, hilos de correo electrónico y unidades compartidas semanas o meses después de que la persona que lo autorizó se haya ido.

El informe AI Agents at Work 2026 de Okta encontró que el 58% de las organizaciones sufrieron un incidente de seguridad relacionado con IA en el último año, sin embargo, el 90% de los ejecutivos reportaron carecer de visibilidad completa sobre qué agentes de IA están operando dentro de su organización. La brecha entre adopción y gobernanza es donde reside el riesgo.

Violaciones de cumplimiento y multas regulatorias

Las aplicaciones no autorizadas no cumplen con el requisito del Artículo 32 del GDPR de «medidas técnicas y organizativas apropiadas» para proteger los datos personales. No satisfacen los requisitos de salvaguardas técnicas de HIPAA bajo 45 CFR § 164.312. No cumplen con el Requisito 12.8 de PCI-DSS para la gestión de proveedores de servicios externos.

La Ley de IA de la UE añade otra capa. Los sistemas de IA de alto riesgo utilizados sin una gobernanza adecuada conllevan penalizaciones de hasta 15 millones de euros o el 3% de la facturación anual global según el Artículo 99(4).

El sector de servicios financieros ya ha visto cómo es la aplicación regulatoria en la práctica. En septiembre de 2022, la SEC y la CFTC multaron a 16 firmas de Wall Street con un total combinado de 1.800 millones de dólares por empleados que usaban WhatsApp y otras aplicaciones de mensajería no aprobadas para comunicaciones comerciales — una violación típica de shadow IT que los reguladores trataron como un fallo de mantenimiento de registros. El comunicado de prensa de la SEC deja claro que el uso «generalizado y prolongado» de comunicaciones fuera del canal oficial no es un factor atenuante; es uno agravante.

Exposición regulatoria europea: GDPR, NIS2 y DORA

Para las organizaciones que operan en la UE, el shadow IT crea una exposición regulatoria por capas a través de tres marcos distintos. Cada uno apunta a una dimensión diferente del problema, y juntos dejan muy poco espacio para «no lo sabíamos».

GDPR: Procesadores no autorizados y transferencias transfronterizas

El Artículo 32 del GDPR es la disposición que más citan las organizaciones. Pero el Artículo 28 es el que el shadow IT viola primero. Toda herramienta SaaS no autorizada que procese datos personales es, en términos del GDPR, un encargado del tratamiento. El Artículo 28 requiere un acuerdo de procesamiento de datos (DPA) por escrito con cada encargado antes de que comience el procesamiento. Un empleado que se registra en una herramienta de IA gratuita usando su correo corporativo y le introduce datos de clientes ha creado una relación de encargado no autorizada — sin DPA, sin diligencia debida y sin registro.

Los Artículos 44 a 49 agravan la exposición. Muchas herramientas SaaS y de IA con sede en EE. UU. transfieren datos personales fuera del Espacio Económico Europeo. Sin un mecanismo de transferencia válido (Cláusulas Contractuales Tipo, una decisión de adecuación o Normas Corporativas Vinculantes), esa transferencia viola el GDPR independientemente de cómo se haya adoptado la herramienta. Los empleados que eligen herramientas de forma independiente no tienen visibilidad sobre dónde se procesan o almacenan los datos.

Las autoridades europeas de protección de datos han aplicado ambas disposiciones. En 2023, la Comisión de Protección de Datos de Irlanda multó a Meta con 1.200 millones de euros bajo el Artículo 46 por transferencias ilegales de datos a EE. UU. — la mayor multa del GDPR hasta la fecha. Aunque ese caso involucraba a un operador de plataforma y no a un usuario empresarial final, el principio subyacente se aplica: la ausencia de un mecanismo de transferencia válido es una violación, independientemente de la intención.

NIS2: Control de acceso y obligaciones de la cadena de suministro

La Directiva NIS2 (Directiva UE 2022/2555), aplicable a entidades esenciales e importantes en toda la UE desde octubre de 2024, aborda directamente las condiciones que crea el shadow IT. El Artículo 21(2) establece diez medidas mínimas de gestión de riesgos de ciberseguridad. Tres están directamente implicadas por el shadow IT:

• Artículo 21(2)(d): Seguridad de la cadena de suministro, incluyendo aspectos de seguridad relativos a las relaciones entre cada entidad y sus proveedores directos o prestadores de servicios. Toda herramienta SaaS no autorizada es, en efecto, una relación de proveedor no verificada.
• Artículo 21(2)(i): Políticas y procedimientos relativos al uso de criptografía y, cuando proceda, cifrado.
• Artículo 21(2)(j): Seguridad de recursos humanos, políticas de control de acceso y gestión de activos.

Las penalizaciones de NIS2 alcanzan los 10 millones de euros o el 2% de la facturación anual global para entidades esenciales, y 7 millones de euros o el 1,4% para otras. La transposición por parte de los Estados miembros varía, pero el marco ya está activo en toda la UE.

La página de cumplimiento NIS2 de Passwork cubre en detalle cómo la gestión centralizada de credenciales se alinea con los requisitos del Artículo 21 de NIS2.

DORA: Riesgo de terceros TIC para entidades financieras

El Reglamento de Resiliencia Operativa Digital (DORA, Reglamento UE 2022/2554) está en vigor desde enero de 2025 para las entidades financieras que operan en la UE: bancos, aseguradoras, empresas de inversión, procesadores de pagos y sus proveedores críticos de TIC. El Artículo 28 requiere que las entidades financieras mantengan un registro de todos los proveedores de servicios TIC de terceros y realicen la diligencia debida precontractual antes de incorporar a cualquier nuevo proveedor.

El shadow SaaS está directamente dentro del ámbito de aplicación. Un empleado de un banco que adopta una herramienta de gestión de proyectos o un asistente de IA no autorizado ha creado una relación con un tercero TIC no registrada. Bajo DORA, eso no es un problema de gobernanza de TI; es una infracción regulatoria. Las Autoridades Europeas de Supervisión (EBA, ESMA, EIOPA) tienen autoridad supervisora para investigar y sancionar. En las jurisdicciones donde la transposición nacional lo prevé, también puede aplicarse responsabilidad penal a nivel directivo.

Para los equipos de TI y cumplimiento del sector financiero, el descubrimiento de shadow IT ya no es una buena práctica. Bajo DORA, es una obligación legal.

El impacto financiero: Cuantificando el coste del shadow IT

El shadow IT conlleva dos costes financieros distintos: exposición a brechas y gasto desperdiciado. El informe Cost of a Data Breach 2025 de IBM encontró que la participación del shadow AI añade 670.000 dólares al coste promedio de una brecha de 4,44 millones de dólares. En el lado del gasto, el SaaS Management Index 2026 de Zylo cifra el gasto promedio desperdiciado en licencias en 21 millones de dólares por año — impulsado por herramientas redundantes, puestos sin usar y compras de las que TI nunca tuvo conocimiento.

Datos de IBM 2025: La penalización de 670.000 $ del shadow AI

El informe Cost of a Data Breach de IBM de 2025 es el punto de referencia más autorizado disponible para entender las consecuencias financieras de la IA no gestionada. Los números principales:

• Coste promedio global de una brecha: 4,44 millones de dólares
• La participación del shadow AI añade 670.000 dólares a ese promedio, llevando la cifra con shadow AI involucrado a aproximadamente 5,11 millones de dólares
• El 97% de los incidentes relacionados con IA involucraban sistemas sin controles de acceso adecuados
• El 20% de las organizaciones reportaron un incidente de seguridad directamente vinculado al shadow AI en 2025

El incremento de 670.000 dólares es el coste adicional de investigación, contención, notificación y remediación cuando están involucrados sistemas de IA que los equipos de seguridad desconocían.

Gasto de TI desperdiciado y licencias redundantes

Las organizaciones pagan por herramientas aprobadas mientras los empleados adoptan silenciosamente alternativas gratuitas o más baratas. El resultado: funcionalidad duplicada, licencias abandonadas y gasto que nadie gestiona.

Según el SaaS Management Index 2026 de Zylo, la organización promedio desperdicia 21 millones de dólares al año solo en licencias SaaS sin usar — y la tasa de utilización promedio en las carteras SaaS empresariales se sitúa en apenas el 47%. Para empresas medianas con 500 o menos empleados, esa cifra aún alcanza los 4,2 millones de dólares anuales en gasto desperdiciado en licencias.

El patrón es predecible: las compras descentralizadas significan que los equipos se registran en herramientas de forma independiente, a menudo sin saber que ya existe un contrato empresarial para la misma categoría. Cuando ocurre un incidente de seguridad además de eso, los costes de remediación agravan el desperdicio base en una exposición financiera material.

Cómo detectar el shadow IT y el shadow AI

Detectar el shadow IT en 2026 requiere combinar al menos cinco fuentes de datos: despliegue de CASB (Cloud Access Security Broker), análisis de logs DNS, EDR (Endpoint Detection and Response), revisión de datos de gastos y escaneo de integraciones de correo electrónico. Cada método cubre una porción diferente del entorno. Ninguno lo cubre todo. Los puntos ciegos son estructurales, no incidentales — ninguna herramienta única ve simultáneamente los dispositivos personales, las cuentas de nivel gratuito y los endpoints gestionados.

Monitoreo de endpoints y extensiones de navegador

Las herramientas EDR y las auditorías de extensiones de navegador pueden revelar el uso de SaaS no autorizado directamente en el dispositivo. El análisis del historial del navegador, los inventarios de extensiones y el monitoreo basado en agentes detectan actividad que nunca toca la red corporativa.

La limitación: los entornos BYOD (Bring Your Own Device) y los dispositivos personales usados para trabajar son en gran medida invisibles para las herramientas de endpoint a menos que la organización haya desplegado MDM (Mobile Device Management) con el alcance apropiado.

Análisis de red: Logs DNS y de proxy

Los logs de consultas DNS y los datos de proxy web revelan a qué dominios están accediendo los empleados. Los picos de tráfico a dominios SaaS desconocidos, servicios de IA o plataformas de intercambio de archivos aparecen claramente en los logs DNS incluso cuando el contenido está cifrado.

Este método funciona bien para el tráfico de red corporativa. No detecta nada de lo que ocurre sobre conexiones móviles, redes domésticas o VPNs que enrutan fuera del proxy corporativo. DNS-over-HTTPS (DoH) y DNS-over-TLS (DoT) cifran las consultas de extremo a extremo, evitando por completo la inspección DNS tradicional sin una política de firewall adicional para bloquearlos.

CASB: Fortalezas y limitaciones

Un CASB (Cloud Access Security Broker) se sitúa entre los usuarios y los servicios en la nube, proporcionando visibilidad, aplicación de políticas y prevención de pérdida de datos para aplicaciones autorizadas y no autorizadas. Los CASB son la herramienta más específicamente diseñada para la detección de shadow IT y pueden identificar miles de servicios en la nube en uso en una organización.

La limitación práctica es la cobertura. Los CASB funcionan mejor cuando el tráfico se enruta a través de ellos — son más efectivos para dispositivos gestionados en redes corporativas. Los empleados que usan cuentas personales en dispositivos personales, o herramientas de IA accedidas a través del navegador sin SSO, pueden no ser visibles. Las funciones de shadow AI integradas dentro de herramientas SaaS ya autorizadas tampoco se detectan normalmente, ya que el dominio padre ya está aprobado.

Un marco de 6 pasos para gestionar el shadow IT

El Marco de Gobernanza de Shadow IT es un proceso de seis pasos: descubrir y clasificar, centralizar credenciales, establecer políticas, agilizar aprobaciones, automatizar el offboarding y construir un programa de concienciación de seguridad. Aborda tanto las dimensiones técnicas como las conductuales del problema. Bloquear herramientas no autorizadas sin habilitar alternativas aprobadas más rápidas falla consistentemente.

Paso 1. Descubrir y clasificar

No se puede gobernar lo que no se puede ver. Comience con un barrido de descubrimiento completo utilizando una combinación de análisis de logs DNS, despliegue de CASB, monitoreo de endpoints y revisión de datos de gastos. El resultado debe ser un inventario clasificado: autorizado, tolerado (conocido pero no aprobado formalmente) y no autorizado.

Clasifique cada aplicación por sensibilidad de datos. Un corrector gramatical gratuito que accede a borradores de correo electrónico tiene un perfil de riesgo diferente a un asistente de codificación de IA con acceso a repositorios.

Paso 2. Implementar una gestión segura de credenciales

Cada cuenta de shadow IT es una credencial no gestionada. La solución no es prohibir las cuentas; es poner las credenciales bajo control centralizado.

Una bóveda centralizada con control de acceso basado en roles (RBAC) proporciona a los empleados un lugar seguro y conveniente para almacenar y compartir credenciales tanto para herramientas aprobadas como para las recién aprobadas. Cuando el acceso está centralizado, el offboarding se vuelve determinístico: revoque el acceso a la bóveda, y el empleado pierde el acceso a todas las credenciales almacenadas allí.

Passwork está disponible como un despliegue autoalojado o en la nube, dando a los equipos la flexibilidad de elegir dónde residen los datos de credenciales. El modelo autoalojado mantiene todo dentro de su propia infraestructura sin dependencia de servicios en la nube de terceros; la opción en la nube le permite comenzar a funcionar sin gestionar su propia infraestructura de servidores. En cualquier caso, los administradores obtienen visibilidad completa de quién tiene acceso a qué y un registro de auditoría completo de cada operación con credenciales. Consulte las guías técnicas para obtener detalles sobre despliegue e integración.

Paso 3. Establecer políticas claras de IA y SaaS

Una prohibición general será ignorada incluso por las personas que la aplican. Una política que defina cómo obtener herramientas aprobadas, qué clasificaciones de datos están permitidas en las herramientas de IA, y qué sucede con los permisos OAuth cuando un empleado se va, es aplicable.

La política debe abordar específicamente:

• Clasificaciones de datos prohibidas para la entrada en herramientas de IA (PII, código fuente, datos financieros, credenciales)
• Ciclos de aprobación y revisión de permisos OAuth
• Tiempo máximo de aprobación para nuevas solicitudes de SaaS (los procesos de aprobación lentos son la razón principal por la que los empleados evitan TI)
• Consecuencias por violaciones de la política

Paso 4. Agilizar el proceso de aprobación

El shadow IT existe porque el camino aprobado es demasiado lento. Si un empleado necesita una herramienta hoy y el proceso de aprobación tarda tres semanas, usará la herramienta sin aprobación y pedirá perdón después, si es que lo pide.

Construya un flujo de aprobación ligero: un formulario de solicitud breve, un SLA de 48 horas para herramientas de bajo riesgo, y un marco de decisión claro basado en la sensibilidad de los datos y la postura de seguridad del proveedor. El objetivo es hacer que «pasar por TI» sea más rápido que «resolverlo por cuenta propia».

Paso 5. Automatizar los flujos de trabajo de offboarding

El offboarding manual es donde nacen las cuentas huérfanas. Cuando un empleado se va, TI normalmente desaprovisiona las cuentas que conoce. Las cuentas de shadow IT, por definición, no están en esa lista.

Los flujos de trabajo de offboarding automatizados, activados por eventos de baja en el HRIS, deben:

• Revocar el acceso a SSO e IdP inmediatamente
• Rotar o invalidar todas las credenciales almacenadas en la bóveda centralizada para ese usuario
• Auditar y revocar los permisos OAuth asociados con la identidad corporativa del usuario
• Transferir la propiedad de los recursos compartidos antes de que se corte el acceso

Las guías de usuario de Passwork cubren en detalle los flujos de trabajo de offboarding de la bóveda de credenciales, incluyendo cómo manejar contraseñas compartidas y credenciales de cuentas de servicio que necesitan rotarse, no solo revocarse.

Paso 6. Construir un programa de concienciación de seguridad

Las políticas y herramientas por sí solas no cambian el comportamiento. Los empleados adoptan shadow IT porque no entienden el riesgo, no saben que existe la alternativa aprobada, o encuentran el camino aprobado demasiado lento. Un programa de concienciación de seguridad aborda directamente los dos primeros.

• Haga el riesgo tangible: mostrar a los empleados un ejemplo real de cómo funciona un ataque de reutilización de credenciales tiene más impacto que una diapositiva sobre «protección de datos». Publicite el conjunto de herramientas aprobadas; los empleados que conocen una alternativa rápida y autorizada tienen menos probabilidades de recurrir a una no aprobada. 
• Cree una cultura de reporte: los empleados deben sentirse cómodos señalando las herramientas que ya están usando sin temor a un castigo inmediato. El descubrimiento a través del autorreporte es más rápido y más barato que el descubrimiento a través de una brecha.
• La formación anual no es suficiente. Las sesiones de microformación trimestrales (10-15 minutos, basadas en escenarios) superan consistentemente a los módulos de cumplimiento anuales en estudios de retención. Las simulaciones de phishing que incluyen falsos formularios de registro de SaaS — no solo señuelos por correo electrónico — prueban exactamente el comportamiento que la gobernanza del shadow IT está tratando de cambiar.

Mida el efecto del programa en las tasas de descubrimiento de shadow IT, no solo en los porcentajes de finalización de la formación. La finalización es una métrica de entrada. La reducción en la adopción de herramientas no autorizadas es el resultado que importa.

Conclusión: Haga que el camino aprobado sea más rápido que el atajo

Las organizaciones que gestionan eficazmente el shadow IT son las que hicieron que el camino aprobado fuera más rápido que el atajo. No las que tienen las políticas de bloqueo más estrictas.

Eso significa un programa de descubrimiento que funcione continuamente. Una bóveda de credenciales que los empleados realmente quieran usar porque les ahorra tiempo. Un flujo de trabajo de offboarding que se active automáticamente en el momento en que se desencadena un evento de baja en el HRIS. Una política de IA que diga a los empleados lo que pueden hacer con las herramientas de IA, no solo lo que no pueden. Y un programa de concienciación de seguridad que haga el riesgo real en lugar de abstracto.

Para las organizaciones europeas, las apuestas son aún más altas. El Artículo 28 del GDPR, el Artículo 21 de NIS2 y el Artículo 28 de DORA no tratan el shadow IT como un inconveniente de gobernanza; lo tratan como un fallo de cumplimiento con penalizaciones cuantificadas asociadas. El incremento de coste de 670.000 dólares por shadow AI del informe de IBM de 2025 no es una abstracción. Es lo que sucede cuando la gobernanza va por detrás de la adopción. Cierre esa brecha antes de que la próxima brecha argumente el caso por usted.

Preguntas frecuentes

¿Qué es el shadow IT en 2026?

El shadow IT en 2026 se refiere a cualquier tecnología (software, aplicaciones SaaS, herramientas de IA o agentes autónomos) utilizada por los empleados sin el conocimiento o la aprobación de TI. Incluye aplicaciones no autorizadas tradicionales como intercambio de archivos y mensajería, y riesgos más nuevos como asistentes de IA que procesan datos sensibles y agentes de IA con acceso OAuth persistente a sistemas corporativos.

¿Cuál es la diferencia entre shadow IT y shadow AI?

El shadow IT es tecnología no gestionada que crea residencia de datos no controlada. El shadow AI es uso de IA no gestionado que crea procesamiento de datos no controlado: modelos que analizan información propietaria, generan outputs y toman acciones a través de permisos delegados. El shadow AI conlleva un mayor riesgo porque los datos no solo se almacenan en algún lugar no autorizado; están siendo procesados y utilizados activamente por sistemas fuera de su perímetro de gobernanza.

¿Cuánto cuesta el shadow IT a las organizaciones?

El informe Cost of a Data Breach 2025 de IBM encontró que la participación del shadow AI añade 670.000 dólares al coste promedio de una brecha de 4,44 millones de dólares, llevando las brechas con shadow AI involucrado a aproximadamente 5,11 millones de dólares. Por separado, la investigación de DataFence de 2026 estima que el incidente promedio de ciberataque por shadow IT cuesta 4,2 millones de dólares. Más allá de los costes de brechas, el shadow IT representa un estimado del 30-40% del gasto total de TI en grandes empresas a través de licencias redundantes y gasto desperdiciado.

¿Cómo se detecta el shadow IT?

La detección efectiva del shadow IT combina múltiples métodos: despliegue de CASB para visibilidad de servicios en la nube, análisis de logs DNS y de proxy para descubrimiento a nivel de red, monitoreo de endpoints para actividad a nivel de dispositivo, y revisión de datos de gastos para suscripciones de pago. Ningún método único proporciona cobertura completa. Las herramientas de integración de correo electrónico también pueden revelar cuentas SaaS creadas con direcciones de correo corporativas, incluyendo herramientas de nivel gratuito que no aparecen en los datos de gastos.

¿Cuál es el mayor riesgo de shadow IT en 2026?

El riesgo de mayor gravedad es la exposición de credenciales a través de cuentas huérfanas y reutilización de contraseñas. Cada aplicación no autorizada es una credencial no gestionada, a menudo protegida por una contraseña reutilizada y sin MFA. Cuando esas credenciales se comprometen (a través de una brecha en el proveedor SaaS, un infostealer o credential stuffing) los atacantes obtienen acceso a cuentas que los equipos de seguridad desconocen y no pueden monitorear.

¿Cómo crea el shadow IT exposición al GDPR?

Toda herramienta SaaS no autorizada que procese datos personales es un encargado del tratamiento no autorizado bajo el Artículo 28 del GDPR, que requiere un acuerdo de procesamiento de datos por escrito antes de que comience el procesamiento. Si esa herramienta tiene sede en EE. UU. y transfiere datos personales fuera del EEE sin Cláusulas Contractuales Tipo u otro mecanismo de transferencia válido, los Artículos 44-49 también se violan. Ambas exposiciones surgen en el momento en que un empleado se registra, independientemente de si TI lo sabe.

¿Cómo se relaciona el shadow AI con la Ley de IA de la UE?

La Ley de IA de la UE impone penalizaciones a las organizaciones que utilizan sistemas de IA de alto riesgo sin una gobernanza adecuada — hasta 15 millones de euros o el 3% de la facturación anual global según el Artículo 99(4). Los empleados que utilizan herramientas de IA no aprobadas que procesan datos personales o influyen en decisiones importantes pueden estar operando sistemas de IA de alto riesgo fuera del marco de cumplimiento de la organización, creando una exposición regulatoria directa sin que haya tenido lugar ninguna evaluación formal de riesgos.

¿Por qué falla bloquear el shadow IT?

La prohibición sin habilitación empuja al shadow IT a la clandestinidad en lugar de eliminarlo. Cuando los empleados no pueden obtener lo que necesitan a través de canales oficiales con suficiente rapidez, encuentran alternativas. La respuesta efectiva es la habilitación estructurada: procesos de aprobación rápidos, alternativas aprobadas y seguras, gestión centralizada de credenciales, y un programa de concienciación de seguridad que haga del camino conforme el camino conveniente.

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

10 fallos de seguridad en el trabajo remoto — y el principio único 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

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 luce el riesgo y qué debe abordar la gobernanza.

Passwork BlogAlex Muntyan

Guía de seguridad de la cadena de suministro: Riesgos de proveedores, regulaciones, control de acceso en 2026

El 48% de las brechas ahora involucran a un tercero. Esta guía cubre los patrones de ataque detrás de SolarWinds, MOVEit y XZ Utils — y los controles de acceso, prácticas de gestión de credenciales y requisitos regulatorios que realmente los detienen.

Passwork BlogAlex Muntyan

Schatten-IT im Jahr 2026 sieht völlig anders aus als noch vor fünf Jahren. Das Problem sind jetzt KI-Agenten mit persistenten OAuth-Tokens, LLM-Sitzungen, die stillschweigend proprietären Quellcode verarbeiten, und verwaiste SaaS-Accounts, an deren Einrichtung sich niemand erinnert. Jedes einzelne Element erweitert die Angriffsfläche des Unternehmens weit über das hinaus, wofür ein traditioneller Netzwerkperimeter konzipiert war.

Laut dem State of Shadow AI-Bericht von UpGuard nutzen über 80 % der Mitarbeiter nicht genehmigte KI-Tools. Eine Gartner-Umfrage unter 302 Cybersicherheitsverantwortlichen (März–Mai 2025) ergab, dass 69 % der Organisationen entweder vermuten oder bestätigt haben, dass Mitarbeiter verbotene öffentliche GenAI-Tools nutzen. Gartner prognostiziert, dass bis 2030 mehr als 40 % der Unternehmen einen Sicherheits- oder Compliance-Vorfall im Zusammenhang mit nicht autorisierter Schatten-KI erleben werden.

Der DTEX/Ponemon-Bericht 2026 zu den Kosten von Insider-Risiken beziffert die jährlichen Kosten durch Insider-Fahrlässigkeit — hauptsächlich verursacht durch Schatten-KI — auf 10,3 Millionen US-Dollar pro Organisation. Diese Summe umfasst Vorfälle ohne böswillige Absicht: lediglich Mitarbeiter, die Tools nutzen, die die IT nie genehmigt hat, und Budgets, die stillschweigend Infrastruktur finanzieren, die niemand sehen oder absichern kann.

Wichtigste Erkenntnisse

• Schatten-IT im Jahr 2026 ist ebenso ein KI-Problem wie ein SaaS-Problem. KI-Agenten mit persistenten OAuth-Tokens, LLM-Sitzungen, die proprietären Quellcode verarbeiten, und verwaiste SaaS-Accounts, die ihre Besitzer überdauern, stellen jetzt die Risiken mit der höchsten Schwere dar.
• Schatten-KI unterscheidet sich grundlegend von traditioneller Schatten-IT. Nicht genehmigte SaaS-Tools speichern Daten am falschen Ort. Nicht genehmigte KI-Tools verarbeiten, analysieren und handeln auf deren Basis.
• Das finanzielle Risiko ist quantifiziert. IBMs Cost of a Data Breach Report 2025 ergab, dass die Beteiligung von Schatten-KI 670.000 US-Dollar zu den durchschnittlichen Kosten eines Datenlecks von 4,44 Millionen US-Dollar hinzufügt. Der DTEX/Ponemon-Bericht 2026 zu den Kosten von Insider-Risiken beziffert die jährlichen Kosten durch KI-bedingte Insider-Fahrlässigkeit auf 10,3 Millionen US-Dollar pro Organisation.
• Die Erkennung erfordert mindestens fünf parallel arbeitende Datenquellen. CASB, DNS-Protokollanalyse, EDR, Ausgabendatenprüfung und E-Mail-Integrations-Scans decken jeweils einen anderen Teil der Umgebung ab. Keine einzelne Methode erfasst gleichzeitig persönliche Geräte, Free-Tier-Accounts und verwaltete Endpunkte.
• Europäische Organisationen sind mehrschichtigen regulatorischen Risiken ausgesetzt. Nicht genehmigte SaaS-Tools verstoßen gegen DSGVO-Artikel 28, sobald sie personenbezogene Daten ohne unterzeichneten Auftragsverarbeitungsvertrag verarbeiten. NIS2-Artikel 21 behandelt ungeprüfte Drittanbieter-Tools als Lieferkettenrisiko. DORA-Artikel 28 verlangt von Finanzunternehmen, jeden IKT-Anbieter zu registrieren — ob Schatten oder nicht.
• Sperren ohne Ermöglichen scheitert durchgehend. Fast die Hälfte der Mitarbeiter nutzt persönliche KI-Accounts weiter, nachdem eine organisatorische Sperre verhängt wurde. Die wirksame Antwort besteht darin, den genehmigten Weg schneller als den Workaround zu gestalten: ein schlanker Genehmigungsworkflow, zentralisiertes Credential-Management und ein Security-Awareness-Programm, das das Risiko greifbar macht.
• Das 6-Schritte-Framework zur Schatten-IT-Governance — Entdecken und Klassifizieren, Credentials zentralisieren, Richtlinien etablieren, Genehmigungen optimieren, Offboarding automatisieren, Security-Awareness aufbauen — adressiert sowohl die technischen als auch die verhaltensbezogenen Aspekte des Problems. Tooling übernimmt die Erkennung. Das Framework verändert die Anreizstruktur, die die Schatten-IT-Nutzung überhaupt erst antreibt.

Was ist Schatten-IT?

Schatten-IT ist jede Technologie (Software, Cloud-Service, KI-Tool oder Hardware), die Mitarbeiter für die Arbeit ohne Wissen oder formale Genehmigung der IT nutzen. Sie reicht von einem persönlichen Dropbox-Ordner zum Teilen von Projektdateien bis hin zu einem KI-Coding-Assistenten mit OAuth-Zugriff auf Produktions-Repositories. Der gemeinsame Nenner: keine Sicherheitsüberprüfung, kein Beschaffungsnachweis, kein Audit-Trail.

Schatten-IT ist kein Nischenproblem. Gartner beziffert den Anteil der IT-Ausgaben für nicht genehmigte Tools in Großunternehmen auf 30-40 %. Die Analyse von Harmonic Security von 22,4 Millionen Unternehmens-KI-Prompts identifizierte 665 verschiedene generative KI-Tools, die in Unternehmensumgebungen laufen — doch nur 40 % dieser Organisationen hatten ein offizielles KI-Abonnement erworben. Der GenAI-Traffic stieg allein im Jahr 2024 um mehr als 890 %.

Schatten-IT vs. Schatten-KI: Wie sich die Risiken vergleichen

Was treibt Mitarbeiter zur Nutzung von Schatten-IT?

Mitarbeiter greifen zu nicht genehmigten Tools, wenn genehmigte Alternativen zu langsam, zu eingeschränkt oder schlicht noch nicht vorhanden sind. Die Reibung ist die Ursache: Ein Entwickler, der drei Wochen auf einen lizenzierten KI-Assistenten wartet, wird bis zum Ende des Tages einen kostenlosen gefunden haben.

Drei Muster wiederholen sich in Organisationen jeder Größe:

• Geschwindigkeit vor Prozess. Mitarbeiter greifen zu dem, was die Arbeit am schnellsten erledigt. Wenn genehmigte Tools nicht mit dem mithalten, was außerhalb des Unternehmens frei verfügbar ist, ist die Wahl offensichtlich: Das nutzen, was funktioniert.
• Beschaffungsverzögerung. Unternehmens-Softwarezyklen laufen in Quartalen. KI-Tooling wird in Wochen ausgeliefert. Bis die IT ein Tool evaluiert und genehmigt hat, haben Mitarbeiter bereits Workflows um dessen Free-Tier-Äquivalent aufgebaut.
• Funktionale Lücken. Genehmigte Tools decken oft keine Randfälle ab. Ein Datenanalyst, der eine schnelle Python-Umgebung benötigt, oder ein Designer, der einen bestimmten Bildgenerator braucht, wird zu dem greifen, was funktioniert, nicht zu dem, was auf der genehmigten Liste steht.
• Keine Feedback-Schleife. Mitarbeiter melden selten die Tools, die sie nutzen, weil es keinen einfachen Kanal dafür gibt. Die IT weiß nicht, was zu steuern ist. Die Sicherheitsabteilung weiß nicht, was zu prüfen ist. Die Kluft zwischen tatsächlicher Tool-Nutzung und genehmigtem Inventar wächst stillschweigend.
• Verbote halten nicht. Fast die Hälfte der Mitarbeiter nutzt persönliche KI-Accounts weiter, nachdem eine organisatorische Sperre verhängt wurde. Verbote eliminieren Schatten-IT nicht. Sie drängen sie nur aus dem Blickfeld, was die Erkennung erschwert und die Reaktion verlangsamt.

Diese Muster sind eine vorhersehbare Reaktion auf Governance-Strukturen, die nicht mit der Geschwindigkeit mitgehalten haben, mit der sich Tooling entwickelt. Diese Lücke macht Schatten-IT zu einem systemischen Risiko statt zu einem Disziplinproblem.

Die Entwicklung der Schatten-IT im Jahr 2026

Schatten-IT im Jahr 2026 geht weit über unverwalteten Cloud-Speicher hinaus. Sie umfasst jetzt KI-Tools, autonome Agenten und ganze SaaS-Ökosysteme, die die IT nie genehmigt, nie inventarisiert hat und nicht überwachen kann. Das durchschnittliche Unternehmen betreibt 305 SaaS-Anwendungen, gibt jährlich 55,7 Millionen US-Dollar für SaaS aus und hat ein Wachstum der Ausgaben für KI-native Apps von 108 % im Jahresvergleich erlebt — wobei der Großteil dieses Wachstums schneller stattfindet, als Governance-Teams es verfolgen können.

Von SaaS-Wildwuchs zu Schatten-KI

Die Zahl von 305 Anwendungen stammt aus dem Zylo SaaS Management Index 2026, der auf realen Ausgabendaten aus Tausenden von Organisationen basiert. Ein erheblicher Anteil dieser Anwendungen wurde nie formal genehmigt. Mitarbeiter adoptieren Tools eigenständig, und die IT erfährt Monate später davon, wenn überhaupt.

Schatten-KI beschleunigt diese Dynamik. Kostenlose KI-Assistenten, Code-Generatoren und autonome Agenten wurden schneller allgemein verfügbar, als Beschaffungszyklen reagieren konnten. Der Check Point Cloud Security Report 2026 ergab, dass 78-80 % der Arbeitnehmer persönliche KI-Tools bei der Arbeit nutzen. Die meisten dieser Sitzungen finden über persönliche Accounts statt, außerhalb von SSO, außerhalb von DLP und ohne Audit-Trail.

Der Unterschied sollte präzise benannt werden: 

• Traditionelle Schatten-IT erzeugt unverwaltete Datenresidenz: Dateien, die in einem nicht genehmigten Service liegen. 
• Schatten-KI erzeugt unverwaltete Datenverarbeitung: proprietäre Informationen, die von Systemen analysiert, zusammengefasst und verarbeitet werden, die Ihr Sicherheitsteam nie überprüft hat.

Warum die Angriffsfläche weiter wächst

Drei strukturelle Kräfte treiben dies an:

• Remote- und Hybridarbeit hat den Netzwerkperimeter als natürlichen Kontrollpunkt entfernt. Mitarbeiter, die von zu Hause aus arbeiten, adoptieren Tools, ohne Anfragen über die IT zu leiten.
• Free-Tiers sind überall. Die meisten SaaS-Tools bieten einen kostenlosen Einstieg. Keine Bestellung, kein Genehmigungsticket, keine Sichtbarkeit.
• Die Verbreitung von KI-Agenten hat die Einsätze verändert. Agenten arbeiten über delegierte OAuth-Berechtigungen — sie lesen Daten, lösen Workflows aus und ändern Datensätze autonom. Ein Entwickler, der einen KI-Coding-Assistenten mit seinem GitHub-Account verbindet, hat diesem Agenten möglicherweise Lese-/Schreibzugriff auf Repositories gewährt. Wenn der Entwickler das Unternehmen verlässt, bleibt die OAuth-Berechtigung bestehen.

Gartner prognostiziert, dass bis 2027 75 % der Mitarbeiter Technologie außerhalb der Sichtbarkeit der IT erwerben, modifizieren oder erstellen werden — ein Anstieg von 41 % im Jahr 2022. Die Richtung ist eindeutig.

Die verborgenen Risiken der Schatten-IT (die Realität 2026)

Schatten-IT im Jahr 2026 ist nicht nur ein Datenleck-Problem. Unverwaltete Tools schaffen persistenten unbefugten Zugriff, exponieren Credentials, lösen Regulierungsverstöße aus und speisen zunehmend Unternehmensdaten in KI-Modelle ein, die kein Sicherheitsteam genehmigt hat oder überwachen kann.

Der Schatten-KI-Risikomultiplikator: Datenverarbeitung vs. Datenspeicherung

Traditionelle Schatten-IT speichert Daten am falschen Ort. Schatten-KI macht etwas damit. Das Einfügen eines Kundenvertrags in ein öffentliches LLM sendet diese Daten an mindestens drei Orte: eine Trainingspipeline, ein Logging-System und potenziell ein Modell, das andere Benutzer abfragen können.

IBMs Cost of a Data Breach Report 2025 beziffert dies: Datenlecks mit hohem Schatten-KI-Anteil fügten durchschnittlich 670.000 US-Dollar zu den Gesamtkosten des Datenlecks hinzu, wodurch der Durchschnitt bei Schatten-KI-Beteiligung auf etwa 5,11 Millionen US-Dollar stieg — gegenüber einem globalen Basiswert von 4,44 Millionen US-Dollar. Derselbe Bericht ergab, dass 97 % der KI-bezogenen Sicherheitsvorfälle Systeme ohne angemessene Zugriffskontrollen betrafen.

Credential-Exposition und Passwort-Wiederverwendung

Schatten-IT ist im Kern ein Identitätsproblem. Jede nicht genehmigte App ist ein neuer Account. Jeder neue Account ist ein Credential. Und die meisten dieser Credentials werden wiederverwendet.

Laut dem Data Breach Investigations Report 2026 von Verizon tauchten gestohlene Credentials bei 39 % aller bestätigten Datenlecks auf, nicht nur als initialer Zugriffsvektor, sondern durchgehend bei Lateral Movement und Persistenz. Wenn ein Mitarbeiter sein Unternehmenspasswort bei einem kostenlosen SaaS-Tool wiederverwendet, das später ein Datenleck erleidet, müssen Angreifer nichts knacken. Sie melden sich einfach an.

Infostealer verschärfen dies. Im Jahr 2025 indexierte Recorded Future 1,95 Milliarden malware-basierte Credential-Expositionen, von denen 31 % aktive Session-Cookies enthielten, die MFA vollständig umgehen. Schatten-IT-Accounts, unüberwacht, oft ohne konfiguriertes MFA, sind genau die Art von Ziel, für die Infostealer gebaut sind.

Das Passwort-Wiederverwendungsrisiko ist ein dokumentiertes, automatisiertes Angriffsmuster im industriellen Maßstab.

Der Offboarding-Albtraum: Verwaiste Accounts

Wenn ein Mitarbeiter das Unternehmen verlässt, werden seine verwalteten Accounts deprovisioniert. Seine Schatten-IT-Accounts nicht. Niemand weiß, dass sie existieren.

Der Figma-Workspace des ehemaligen Entwicklers, die persönliche HubSpot-Testversion des Vertriebsmitarbeiters mit exportierten CRM-Daten, die Notion-Seite des Auftragnehmers mit internen Architekturnotizen: All dies bleibt unbegrenzt bestehen, nachdem die Person das Unternehmen verlassen hat.

Die Konsequenzen können schwerwiegend sein. In einem dokumentierten Fall griff ein ehemaliger Cisco-Mitarbeiter fünf Monate nach seiner Kündigung auf eine in AWS gehostete virtuelle Maschinen-Infrastruktur zu und löschte 456 virtuelle Maschinen, wodurch mehr als 16.000 WebEx-Teams-Accounts fast zwei Wochen lang offline waren.

Das US-Justizministerium bestätigte, dass der Vorfall Cisco etwa 2,4 Millionen US-Dollar an Behebungskosten und Kundenerstattungen kostete, und der ehemalige Mitarbeiter wurde zu 24 Monaten Bundesgefängnis verurteilt (United States v. Sudhish Kasaba Ramesh, Case No. 5:20-cr-00102). Das war ein verwaltetes System. Verwaiste Schatten-IT-Accounts sind schwieriger zu finden und brauchen länger zum Schließen — falls sie überhaupt geschlossen werden.

KI-Agenten und unverwaltete OAuth-Berechtigungen

Dies ist die Bedrohung, die die meisten Organisationen noch nicht verfolgen. KI-Agenten arbeiten über delegierte OAuth-Berechtigungen: Ein Benutzer gewährt dem Agenten Zugriff auf Google Drive, GitHub oder Slack, und der Agent kann kontinuierlich auf diesem Zugriff lesen, schreiben und handeln — nicht nur während der Sitzung.

Wenn sich der Benutzer abmeldet, bleibt die OAuth-Berechtigung bestehen. Wenn der Benutzer das Unternehmen verlässt, bleibt die OAuth-Berechtigung bestehen. Der Agent hat möglicherweise noch Wochen oder Monate nach dem Ausscheiden der Person, die ihn autorisiert hat, Zugriff auf Unternehmens-Repositories, E-Mail-Threads und freigegebene Laufwerke.

Der Okta-Bericht AI Agents at Work 2026 ergab, dass 58 % der Organisationen im vergangenen Jahr einen KI-bezogenen Sicherheitsvorfall erlitten haben, doch 90 % der Führungskräfte gaben an, keinen vollständigen Überblick darüber zu haben, welche KI-Agenten in ihrer Organisation arbeiten. Die Lücke zwischen Adoption und Governance ist der Ort, an dem das Risiko lebt.

Compliance-Verstöße und regulatorische Bußgelder

Nicht genehmigte Apps erfüllen nicht die Anforderung von DSGVO-Artikel 32 nach „geeigneten technischen und organisatorischen Maßnahmen" zum Schutz personenbezogener Daten. Sie erfüllen nicht die technischen Schutzanforderungen von HIPAA unter 45 CFR § 164.312. Sie erfüllen nicht PCI-DSS-Anforderung 12.8 für die Verwaltung von Drittanbieter-Dienstleistern.

Der EU AI Act fügt eine weitere Ebene hinzu. Hochrisiko-KI-Systeme, die ohne ordnungsgemäße Governance eingesetzt werden, können mit Strafen von bis zu 15 Millionen Euro oder 3 % des weltweiten Jahresumsatzes gemäß Artikel 99(4) belegt werden.

Der Finanzdienstleistungssektor hat bereits erfahren, wie regulatorische Durchsetzung in der Praxis aussieht. Im September 2022 verhängten die SEC und CFTC gegen 16 Wall-Street-Firmen zusammen 1,8 Milliarden US-Dollar Bußgelder, weil Mitarbeiter WhatsApp und andere nicht genehmigte Messaging-Apps für geschäftliche Kommunikation nutzten — ein klassischer Schatten-IT-Verstoß, den die Aufsichtsbehörden als Verstoß gegen die Aufzeichnungspflicht behandelten. Die Pressemitteilung der SEC macht deutlich, dass die „weit verbreitete und langjährige" Nutzung von Off-Channel-Kommunikation kein mildernder Faktor ist; es ist ein erschwerender.

Europäische regulatorische Exposition: DSGVO, NIS2 und DORA

Für Organisationen, die in der EU tätig sind, erzeugt Schatten-IT mehrschichtige regulatorische Exposition über drei verschiedene Rahmenwerke hinweg. Jedes zielt auf eine andere Dimension des Problems ab, und zusammen lassen sie sehr wenig Raum für „wir wussten es nicht".

DSGVO: Nicht autorisierte Auftragsverarbeiter und grenzüberschreitende Übermittlungen

DSGVO-Artikel 32 ist die Vorschrift, die die meisten Organisationen zitieren. Aber Artikel 28 ist derjenige, gegen den Schatten-IT zuerst verstößt. Jedes nicht genehmigte SaaS-Tool, das personenbezogene Daten verarbeitet, ist nach DSGVO-Terminologie ein Auftragsverarbeiter. Artikel 28 verlangt vor Beginn der Verarbeitung einen schriftlichen Auftragsverarbeitungsvertrag (AV-Vertrag) mit jedem solchen Auftragsverarbeiter. Ein Mitarbeiter, der sich mit seiner geschäftlichen E-Mail für ein kostenloses KI-Tool anmeldet und es mit Kundendaten füttert, hat eine nicht autorisierte Auftragsverarbeiterbeziehung geschaffen — ohne AV-Vertrag, ohne Due Diligence und ohne Nachweis.

Die Artikel 44 bis 49 verstärken die Exposition. Viele US-basierte SaaS- und KI-Tools übermitteln personenbezogene Daten außerhalb des Europäischen Wirtschaftsraums. Ohne einen gültigen Übermittlungsmechanismus (Standardvertragsklauseln, Angemessenheitsbeschluss oder verbindliche interne Datenschutzvorschriften) verstößt diese Übermittlung gegen die DSGVO, unabhängig davon, wie das Tool eingeführt wurde. Mitarbeiter, die Tools eigenständig auswählen, haben keine Sichtbarkeit darüber, wo Daten verarbeitet oder gespeichert werden.

Europäische Datenschutzbehörden haben beide Vorschriften durchgesetzt. Im Jahr 2023 verhängte die Irish Data Protection Commission gegen Meta ein Bußgeld von 1,2 Milliarden Euro gemäß Artikel 46 für rechtswidrige Datenübermittlungen in die USA — das höchste DSGVO-Bußgeld bisher. Obwohl dieser Fall einen Plattformbetreiber und keinen Unternehmensendnutzer betraf, gilt das zugrunde liegende Prinzip: Das Fehlen eines gültigen Übermittlungsmechanismus ist ein Verstoß, unabhängig von der Absicht.

NIS2: Zugriffskontrolle und Lieferkettenpflichten

Die NIS2-Richtlinie (Richtlinie EU 2022/2555), die seit Oktober 2024 für wesentliche und wichtige Einrichtungen in der EU gilt, adressiert direkt die Bedingungen, die Schatten-IT schafft. Artikel 21(2) legt zehn Mindestmaßnahmen für das Cybersicherheits-Risikomanagement fest. Drei sind direkt von Schatten-IT betroffen:

• Artikel 21(2)(d): Sicherheit der Lieferkette, einschließlich Sicherheitsaspekte hinsichtlich der Beziehungen zwischen jeder Einrichtung und ihren direkten Lieferanten oder Dienstleistern. Jedes nicht genehmigte SaaS-Tool ist faktisch eine ungeprüfte Lieferantenbeziehung.
• Artikel 21(2)(i): Richtlinien und Verfahren bezüglich der Nutzung von Kryptographie und, wo angemessen, Verschlüsselung.
• Artikel 21(2)(j): Personalsicherheit, Zugriffskontrollrichtlinien und Asset-Management.

NIS2-Strafen erreichen 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes für wesentliche Einrichtungen und 7 Millionen Euro oder 1,4 % für andere. Die Umsetzung in den Mitgliedstaaten variiert, aber das Rahmenwerk ist jetzt in der gesamten EU aktiv.

Die NIS2-Compliance-Seite von Passwork erläutert detailliert, wie zentralisiertes Credential-Management auf die Anforderungen von NIS2-Artikel 21 abgestimmt ist.

DORA: IKT-Drittparteirisiko für Finanzunternehmen

Der Digital Operational Resilience Act (DORA, Verordnung EU 2022/2554) gilt seit Januar 2025 für Finanzunternehmen, die in der EU tätig sind: Banken, Versicherer, Wertpapierfirmen, Zahlungsdienstleister und ihre kritischen IKT-Anbieter. Artikel 28 verlangt von Finanzunternehmen, ein Register aller IKT-Drittanbieter zu führen und vor der Einbindung eines neuen Anbieters eine vorvertragliche Due Diligence durchzuführen.

Schatten-SaaS fällt direkt in den Anwendungsbereich. Ein Mitarbeiter bei einer Bank, der ein nicht genehmigtes Projektmanagement-Tool oder einen KI-Assistenten einführt, hat eine nicht registrierte IKT-Drittparteibeziehung geschaffen. Nach DORA ist das kein IT-Governance-Problem; es ist ein regulatorischer Verstoß. Die Europäischen Aufsichtsbehörden (EBA, ESMA, EIOPA) haben die Befugnis zur Untersuchung und Sanktionierung. In Jurisdiktionen, in denen die nationale Umsetzung dies vorsieht, kann auch eine strafrechtliche Haftung auf Managementebene gelten.

Für IT- und Compliance-Teams im Finanzsektor ist die Erkennung von Schatten-IT nicht mehr nur Best Practice. Nach DORA ist es eine gesetzliche Pflicht.

Die finanziellen Auswirkungen: Quantifizierung der Kosten von Schatten-IT

Schatten-IT verursacht zwei unterschiedliche Kostenarten: Datenleck-Exposition und verschwendete Ausgaben. IBMs Cost of a Data Breach Report 2025 ergab, dass die Beteiligung von Schatten-KI 670.000 US-Dollar zu den durchschnittlichen Kosten eines Datenlecks von 4,44 Millionen US-Dollar hinzufügt. Auf der Ausgabenseite beziffert der Zylo SaaS Management Index 2026 die durchschnittlich verschwendeten Lizenzausgaben auf 21 Millionen US-Dollar pro Jahr — verursacht durch redundante Tools, ungenutzte Plätze und Käufe, von denen die IT nie wusste.

IBM-Daten 2025: Die 670.000-Dollar-Schatten-KI-Strafe

IBMs Cost of a Data Breach Report 2025 ist der maßgeblichste verfügbare Benchmark zum Verständnis der finanziellen Konsequenzen unverwalteter KI. Die Hauptzahlen:

• Globale durchschnittliche Kosten eines Datenlecks: 4,44 Millionen US-Dollar
• Die Beteiligung von Schatten-KI fügt diesem Durchschnitt 670.000 US-Dollar hinzu, wodurch die Zahl bei Schatten-KI-Beteiligung auf etwa 5,11 Millionen US-Dollar steigt
• 97 % der KI-bezogenen Vorfälle betrafen Systeme ohne angemessene Zugriffskontrollen
• 20 % der Organisationen meldeten 2025 einen Sicherheitsvorfall, der direkt mit Schatten-KI verbunden war

Der Aufschlag von 670.000 US-Dollar ist der inkrementelle Aufwand für Untersuchung, Eindämmung, Benachrichtigung und Behebung, wenn KI-Systeme beteiligt sind, von denen Sicherheitsteams nichts wussten.

Verschwendete IT-Ausgaben und redundante Lizenzierung

Organisationen zahlen für genehmigte Tools, während Mitarbeiter stillschweigend kostenlose oder günstigere Alternativen einführen. Das Ergebnis: doppelte Funktionalität, verwaiste Lizenzen und Ausgaben, für die niemand verantwortlich ist.

Laut dem Zylo SaaS Management Index 2026 verschwendet die durchschnittliche Organisation jährlich 21 Millionen US-Dollar allein für ungenutzte SaaS-Lizenzen — und die durchschnittliche Nutzungsrate über Unternehmens-SaaS-Portfolios hinweg liegt bei nur 47 %. Für mittelständische Unternehmen mit 500 oder weniger Mitarbeitern erreicht diese Zahl immer noch 4,2 Millionen US-Dollar jährlich an verschwendeten Lizenzausgaben.

Das Muster ist vorhersehbar: Dezentralisierte Beschaffung bedeutet, dass Teams Tools eigenständig anmelden, oft ohne zu wissen, dass bereits ein Unternehmensvertrag für dieselbe Kategorie existiert. Wenn dann noch ein Sicherheitsvorfall hinzukommt, summieren sich die Behebungskosten zusätzlich zur grundlegenden Verschwendung zu einer erheblichen finanziellen Exposition.

Wie man Schatten-IT und Schatten-KI erkennt

Die Erkennung von Schatten-IT im Jahr 2026 erfordert die Kombination von mindestens fünf Datenquellen: CASB-Deployment (Cloud Access Security Broker), DNS-Protokollanalyse, EDR (Endpoint Detection and Response), Ausgabendatenprüfung und E-Mail-Integrations-Scanning. Jede Methode deckt einen anderen Teil der Umgebung ab. Keine deckt alles ab. Blinde Flecken sind strukturell, nicht zufällig — kein einzelnes Tool sieht gleichzeitig persönliche Geräte, Free-Tier-Accounts und verwaltete Endpunkte.

Endpunkt-Monitoring und Browser-Erweiterungen

EDR-Tools und Browser-Erweiterungs-Audits können nicht autorisierte SaaS-Nutzung direkt auf dem Gerät aufdecken. Browser-Verlaufsanalyse, Erweiterungsinventare und agentenbasiertes Monitoring erfassen Aktivitäten, die nie das Unternehmensnetzwerk berühren.

Die Einschränkung: BYOD-Umgebungen (Bring Your Own Device) und persönliche Geräte, die für die Arbeit genutzt werden, sind für Endpunkt-Tools weitgehend unsichtbar, es sei denn, die Organisation hat MDM (Mobile Device Management) mit entsprechendem Umfang bereitgestellt.

Netzwerkanalyse: DNS- und Proxy-Protokolle

DNS-Abfrageprotokolle und Web-Proxy-Daten zeigen, auf welche Domains Mitarbeiter zugreifen. Spitzen im Traffic zu unbekannten SaaS-Domains, KI-Services oder File-Sharing-Plattformen erscheinen deutlich in DNS-Protokollen, selbst wenn der Inhalt verschlüsselt ist.

Diese Methode funktioniert gut für Unternehmensnetzwerk-Traffic. Sie verfehlt alles, was über Mobilfunkverbindungen, Heimnetzwerke oder VPNs geschieht, die außerhalb des Unternehmens-Proxys routen. DNS-over-HTTPS (DoH) und DNS-over-TLS (DoT) verschlüsseln Abfragen Ende-zu-Ende und umgehen traditionelle DNS-Inspektion vollständig, ohne zusätzliche Firewall-Richtlinien zur Blockierung.

CASB: Stärken und Einschränkungen

Ein CASB (Cloud Access Security Broker) sitzt zwischen Benutzern und Cloud-Services und bietet Sichtbarkeit, Richtliniendurchsetzung und Data-Loss-Prevention für genehmigte und nicht genehmigte Apps. CASBs sind das am besten geeignete Tool zur Erkennung von Schatten-IT und können Tausende von Cloud-Services identifizieren, die in einer Organisation genutzt werden.

Die praktische Einschränkung ist die Abdeckung. CASBs funktionieren am besten, wenn Traffic durch sie geleitet wird — am effektivsten für verwaltete Geräte in Unternehmensnetzwerken. Mitarbeiter, die persönliche Accounts auf persönlichen Geräten nutzen, oder KI-Tools, auf die über den Browser ohne SSO zugegriffen wird, sind möglicherweise nicht sichtbar. Schatten-KI-Funktionen, die in bereits genehmigten SaaS-Tools eingebettet sind, werden typischerweise ebenfalls nicht erkannt, da die übergeordnete Domain bereits genehmigt ist.

Ein 6-Schritte-Framework zur Verwaltung von Schatten-IT

Das Schatten-IT-Governance-Framework ist ein sechsstufiger Prozess: Entdecken und Klassifizieren, Credentials zentralisieren, Richtlinien etablieren, Genehmigungen optimieren, Offboarding automatisieren und ein Security-Awareness-Programm aufbauen. Es adressiert sowohl die technischen als auch die verhaltensbezogenen Dimensionen des Problems. Das Blockieren nicht genehmigter Tools ohne schnellere genehmigte Alternativen scheitert durchgehend.

Schritt 1. Entdecken und klassifizieren

Was nicht sichtbar ist, kann nicht gesteuert werden. Beginnen Sie mit einer umfassenden Entdeckungsanalyse unter Verwendung einer Kombination aus DNS-Protokollanalyse, CASB-Deployment, Endpunkt-Monitoring und Ausgabendatenprüfung. Das Ergebnis sollte ein klassifiziertes Inventar sein: genehmigt, toleriert (bekannt, aber nicht formal genehmigt) und nicht genehmigt.

Klassifizieren Sie jede Anwendung nach Datensensibilität. Ein kostenloser Grammatik-Checker, der auf E-Mail-Entwürfe zugreift, hat ein anderes Risikoprofil als ein KI-Coding-Assistent mit Repository-Zugriff.

Schritt 2. Sicheres Credential-Management implementieren

Jeder Schatten-IT-Account ist ein unverwaltetes Credential. Die Lösung besteht nicht darin, Accounts zu verbieten; es geht darum, Credentials unter zentralisierte Kontrolle zu bringen.

Ein zentralisierter Tresor mit rollenbasierter Zugriffskontrolle (RBAC) gibt Mitarbeitern einen sicheren, bequemen Ort zum Speichern und Teilen von Credentials für genehmigte und neu genehmigte Tools. Wenn der Zugriff zentralisiert ist, wird Offboarding deterministisch: Entziehen Sie den Tresor-Zugriff, und der Mitarbeiter verliert den Zugriff auf jedes dort gespeicherte Credential.

Passwork ist als Self-Hosted-Deployment oder in der Cloud verfügbar und gibt Teams die Flexibilität zu wählen, wo Credential-Daten gespeichert werden. Das Self-Hosted-Modell hält alles in Ihrer eigenen Infrastruktur ohne Abhängigkeit von Cloud-Services Dritter; die Cloud-Option ermöglicht den schnellen Start ohne Verwaltung eines eigenen Server-Stacks. In beiden Fällen erhalten Administratoren vollständige Sichtbarkeit darüber, wer Zugriff auf was hat, sowie ein vollständiges Audit-Protokoll jeder Credential-Operation. Weitere Informationen zu Deployment und Integration finden Sie in den technischen Anleitungen.

Schritt 3. Klare KI- und SaaS-Richtlinien etablieren

Ein pauschales Verbot wird selbst von den Personen ignoriert, die es durchsetzen. Eine Richtlinie, die definiert, wie Tools genehmigt werden, welche Datenklassifizierungen in KI-Tools zulässig sind und was mit OAuth-Berechtigungen geschieht, wenn ein Mitarbeiter das Unternehmen verlässt, ist umsetzbar.

Die Richtlinie sollte speziell adressieren:

• Verbotene Datenklassifizierungen für KI-Tool-Eingaben (personenbezogene Daten, Quellcode, Finanzdaten, Credentials)
• OAuth-Berechtigungsgenehmigung und Überprüfungszyklen
• Maximale Zeit bis zur Genehmigung für neue SaaS-Anfragen (langsame Genehmigungsprozesse sind der Hauptgrund, warum Mitarbeiter die IT umgehen)
• Konsequenzen bei Richtlinienverstößen

Schritt 4. Den Genehmigungsprozess optimieren

Schatten-IT existiert, weil der genehmigte Weg zu langsam ist. Wenn ein Mitarbeiter heute ein Tool benötigt und der Genehmigungsprozess drei Wochen dauert, wird er das Tool ohne Genehmigung nutzen und später um Verzeihung bitten, falls überhaupt.

Bauen Sie einen schlanken Genehmigungsworkflow auf: ein kurzes Antragsformular, ein 48-Stunden-SLA für risikoarme Tools und ein klares Entscheidungsframework basierend auf Datensensibilität und Anbieter-Sicherheitsstatus. Das Ziel ist, „über die IT gehen" schneller zu machen als „selbst herausfinden".

Schritt 5. Offboarding-Workflows automatisieren

Manuelles Offboarding ist der Ort, an dem verwaiste Accounts entstehen. Wenn ein Mitarbeiter das Unternehmen verlässt, deprovisioniert die IT typischerweise die ihr bekannten Accounts. Schatten-IT-Accounts stehen per Definition nicht auf dieser Liste.

Automatisierte Offboarding-Workflows, ausgelöst durch HRIS-Kündigungsereignisse, sollten:

• SSO- und IdP-Zugriff sofort widerrufen
• Alle im zentralisierten Tresor für diesen Benutzer gespeicherten Credentials rotieren oder ungültig machen
• OAuth-Berechtigungen, die mit der Unternehmensidentität des Benutzers verbunden sind, prüfen und widerrufen
• Eigentümerschaft freigegebener Ressourcen übertragen, bevor der Zugriff entzogen wird

Die Passwork-Benutzeranleitungen behandeln Credential-Tresor-Offboarding-Workflows im Detail, einschließlich des Umgangs mit geteilten Passwörtern und Service-Account-Credentials, die rotiert werden müssen, nicht nur widerrufen.

Schritt 6. Ein Security-Awareness-Programm aufbauen

Richtlinien und Tooling allein ändern kein Verhalten. Mitarbeiter nutzen Schatten-IT, weil sie das Risiko nicht verstehen, die genehmigte Alternative nicht kennen oder den genehmigten Weg als zu langsam empfinden. Ein Security-Awareness-Programm adressiert die ersten beiden direkt.

• Das Risiko greifbar machen: Mitarbeitern ein reales Beispiel zu zeigen, wie ein Credential-Wiederverwendungsangriff funktioniert, wirkt stärker als eine Folie über „Datenschutz". Machen Sie das genehmigte Toolkit bekannt; Mitarbeiter, die wissen, dass eine schnelle, genehmigte Alternative existiert, greifen seltener zu einer nicht genehmigten. 
• Eine Meldekultur schaffen: Mitarbeiter sollten sich wohl dabei fühlen, Tools zu melden, die sie bereits nutzen, ohne sofortige Bestrafung befürchten zu müssen. Entdeckung durch Selbstmeldung ist schneller und günstiger als Entdeckung durch ein Datenleck.
• Jährliche Schulungen reichen nicht aus. Vierteljährliche Mikro-Schulungen (10-15 Minuten, szenariobasiert) übertreffen in Retentionsstudien durchgehend jährliche Compliance-Module. Phishing-Simulationen, die gefälschte SaaS-Anmeldeaufforderungen enthalten — nicht nur E-Mail-Köder — testen genau das Verhalten, das Schatten-IT-Governance ändern soll.

Verfolgen Sie die Auswirkungen des Programms auf die Schatten-IT-Erkennungsraten, nicht nur auf Schulungsabschlussquoten. Abschluss ist eine Input-Metrik. Die Reduzierung der Nutzung nicht genehmigter Tools ist der Output, der zählt.

Fazit: Den genehmigten Weg schneller machen als den Workaround

Die Organisationen, die Schatten-IT effektiv verwalten, sind diejenigen, die den genehmigten Weg schneller als den Workaround gemacht haben. Nicht diejenigen mit den strengsten Blockierungsrichtlinien.

Das bedeutet ein Entdeckungsprogramm, das kontinuierlich läuft. Einen Credential-Tresor, den Mitarbeiter tatsächlich nutzen wollen, weil er ihnen Zeit spart. Einen Offboarding-Workflow, der automatisch ausgelöst wird, sobald ein HRIS-Kündigungsereignis eintritt. Eine KI-Richtlinie, die Mitarbeitern sagt, was sie mit KI-Tools tun können, nicht nur, was sie nicht dürfen. Und ein Security-Awareness-Programm, das das Risiko real macht statt abstrakt.

Für europäische Organisationen sind die Einsätze noch höher. DSGVO-Artikel 28, NIS2-Artikel 21 und DORA-Artikel 28 behandeln Schatten-IT nicht als Governance-Unannehmlichkeit; sie behandeln sie als Compliance-Verstoß mit quantifizierten Strafen. Der Aufschlag von 670.000 US-Dollar für Schatten-KI aus IBMs Bericht 2025 ist keine Abstraktion. Es ist das, was passiert, wenn Governance der Adoption hinterherhinkt. Schließen Sie diese Lücke, bevor das nächste Datenleck das Argument für Sie liefert.

Häufig gestellte Fragen

10 Remote-Work-Sicherheitsfehler (und wie Sie sie beheben)

10 Remote-Work-Sicherheitsfehler — und das eine Prinzip hinter allen: Sicherheit bricht dort, 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

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

Mitarbeiter nutzen KI-Tools, die Sie nicht genehmigt haben, auf Accounts, 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

Leitfaden zur Lieferkettensicherheit: Lieferantenrisiken, Vorschriften, Zugriffskontrolle im Jahr 2026

48 % der Datenlecks betreffen jetzt eine Drittpartei. Dieser Leitfaden behandelt die Angriffsmuster hinter SolarWinds, MOVEit und XZ Utils — sowie die Zugriffskontrollen, Credential-Management-Praktiken und regulatorischen Anforderungen, die sie tatsächlich stoppen.

Passwork BlogAlex Muntyan

Shadow IT in 2026 looks nothing like it did five years ago. The problem now is AI agents with persistent OAuth tokens, LLM sessions quietly processing proprietary source code, and orphaned SaaS accounts no one remembers provisioning. Each one extends the corporate attack surface well past anything a traditional network perimeter was designed to handle.

According to UpGuard's State of Shadow AI report, over 80% of employees use unapproved AI tools. A Gartner survey of 302 cybersecurity leaders (March–May 2025) found that 69% of organizations either suspect or have confirmed employees using prohibited public GenAI tools. Gartner predicts that by 2030, more than 40% of enterprises will experience a security or compliance incident tied to unauthorized shadow AI.

The DTEX/Ponemon 2026 Cost of Insider Risks report puts the annual cost of insider negligence driven primarily by shadow AI at $10.3 million per organization. That figure covers incidents where no malicious intent was involved: just employees using tools IT never approved, and budgets quietly funding infrastructure no one can see or secure.

Key takeaways

• Shadow IT in 2026 is an AI problem as much as a SaaS problem. AI agents with persistent OAuth tokens, LLM sessions processing proprietary source code, and orphaned SaaS accounts that outlive their owners are now the highest-severity risks.
• Shadow AI is categorically different from traditional shadow IT. Unsanctioned SaaS tools store data in the wrong place. Unsanctioned AI tools process, analyze, and act on it.
• The financial exposure is quantified. IBM's 2025 Cost of a Data Breach Report found that shadow AI involvement adds $670,000 to the average breach cost of $4.44 million. The DTEX/Ponemon 2026 Cost of Insider Risks report puts the annual cost of AI-driven insider negligence at $10.3 million per organization.
• Detection requires at least five data sources working in parallel. CASB, DNS log analysis, EDR, expense data review, and email integration scanning each cover a different slice of the environment. No single method sees personal devices, free-tier accounts, and managed endpoints simultaneously.
• European organizations face layered regulatory exposure. Unsanctioned SaaS tools violate GDPR Article 28 the moment they process personal data without a signed DPA. NIS2 Article 21 treats unvetted third-party tools as supply chain risk. DORA Article 28 requires financial entities to register every ICT provider — shadow or otherwise.
• Blocking without enabling consistently fails. Nearly half of employees continue using personal AI accounts after an organizational ban. The effective response is making the approved path faster than the workaround: a lightweight approval workflow, centralized credential management, and a security awareness program that makes the risk concrete.
• The 6-step Shadow IT Governance Framework — discover and classify, centralize credentials, establish policy, streamline approvals, automate offboarding, build security awareness — addresses both the technical and behavioral sides of the problem. Tooling handles detection. The framework changes the incentive structure that drives shadow IT adoption in the first place.

What is shadow IT?

Shadow IT is any technology (software, cloud service, AI tool, or hardware) that employees use for work without IT's knowledge or formal approval. It ranges from a personal Dropbox folder used to share project files, to an AI coding assistant with OAuth access to production repositories. The common thread: no security review, no procurement record, no audit trail.

Shadow IT is not a niche problem. Gartner puts the share of IT spending consumed by unsanctioned tools at 30-40% in large enterprises. Harmonic Security's analysis of 22.4 million enterprise AI prompts identified 665 distinct generative AI tools running across enterprise environments — yet only 40% of those organizations had purchased an official AI subscription. GenAI traffic surged more than 890% in 2024 alone.

Shadow IT vs. Shadow AI: How the risks compare

What drives employees to use shadow IT?

Employees turn to unsanctioned tools when approved alternatives are too slow, too limited, or simply don't exist yet. The friction is the cause: a developer waiting three weeks for a licensed AI assistant will find a free one by end of day.

Three patterns repeat across organizations of every size:

• Speed over process. Employees reach for whatever gets the job done fastest. When approved tools don't match what's freely available outside the enterprise, the choice is obvious: use what works.
• Procurement lag. Enterprise software cycles run on quarters. AI tooling ships on weeks. By the time IT evaluates and approves a tool, employees have already built workflows around its free-tier equivalent.
• Functional gaps. Approved tools often don't cover edge cases. A data analyst who needs a quick Python environment, or a designer who needs a specific image generator, will reach for whatever works, not whatever's on the approved list.
• No feedback loop. Employees rarely report the tools they're using because there's no easy channel to do so. IT doesn't know what to govern. Security doesn't know what to audit. The gap between actual tool usage and approved inventory widens silently.
• Bans don't hold. Nearly half of employees continue using personal AI accounts after an organizational ban. Prohibition doesn't eliminate shadow IT. It just pushes it out of sight, making detection harder and response slower.

These patterns are a predictable response to governance structures that haven't kept pace with how fast tooling moves. That gap is exactly what makes shadow IT a systemic risk rather than a discipline problem.

The evolution of shadow IT in 2026

Shadow IT in 2026 has moved well beyond unmanaged cloud storage. It now spans AI tools, autonomous agents, and entire SaaS ecosystems that IT never approved, never inventoried, and cannot monitor. The average enterprise runs 305 SaaS applications, spends $55.7 million on SaaS annually, and has seen AI-native app spend jump 108% year over year — most of that growth happening faster than governance teams can track it.

From SaaS sprawl to shadow AI

The 305-application figure comes from Zylo's 2026 SaaS Management Index, which draws on real-world spend data across thousands of organizations. A significant share of those applications were never formally approved. Employees adopt tools independently and IT finds out months later, if at all.

Shadow AI accelerates this dynamic. Free AI assistants, code generators, and autonomous agents became widely available faster than procurement cycles could respond. Check Point's 2026 Cloud Security Report found that 78-80% of workers use personal AI tools at work. Most of those sessions happen through personal accounts, outside SSO, outside DLP, and with no audit trail.

The distinction is worth being precise about: 

• Traditional shadow IT creates unmanaged data residency: files sitting in an unsanctioned service. 
• Shadow AI creates unmanaged data processing: proprietary information being analyzed, summarized, and acted upon by systems your security team has never reviewed.

Why the attack surface keeps expanding

Three structural forces drive this:

• Remote and hybrid work removed the network perimeter as a natural control point. Employees working from home adopt tools without routing requests through IT.
• Free tiers are everywhere. Most SaaS tools offer a no-cost entry point. No purchase order, no approval ticket, no visibility.
• AI agent proliferation changed the stakes. Agents operate through delegated OAuth permissions — reading data, triggering workflows, and modifying records autonomously. A developer who connects an AI coding assistant to their GitHub account may have granted that agent read/write access to repositories. When the developer leaves, the OAuth grant stays.

Gartner projects that by 2027, 75% of employees will acquire, modify, or create technology outside IT's visibility — up from 41% in 2022. The direction is unambiguous.

The hidden risks of shadow IT (the 2026 reality)

Shadow IT in 2026 is not just a data leakage problem. Unmanaged tools create persistent unauthorized access, expose credentials, trigger regulatory violations, and increasingly feed enterprise data into AI models that no security team has approved or can monitor.

The shadow AI risk multiplier: Data processing vs. data storage

Traditional shadow IT stores data in the wrong place. Shadow AI does things with it. Pasting a customer contract into a public LLM sends that data into at least three places: a training pipeline, a logging system, and potentially a model that other users can query.

IBM's 2025 Cost of a Data Breach Report puts a number on this: breaches involving high levels of shadow AI added an average of $670,000 to the total breach cost, bringing the shadow-AI-involved average to approximately $5.11 million against a global baseline of $4.44 million. The same report found that 97% of AI-related security incidents involved systems lacking proper access controls.

Credential exposure and password reuse

Shadow IT is, at its root, an identity problem. Every unsanctioned app is a new account. Every new account is a credential. And most of those credentials are reused.

According to Verizon's 2026 Data Breach Investigations Report, stolen credentials appeared in 39% of all confirmed breaches, not just as the initial access vector, but throughout lateral movement and persistence. When an employee reuses their corporate password on a free SaaS tool that later suffers a breach, attackers don't need to break anything. They just log in.

Infostealers make this worse. In 2025, Recorded Future indexed 1.95 billion malware-sourced credential exposures, 31% of which included active session cookies that bypass MFA entirely. Shadow IT accounts, unmonitored, often without MFA configured, are exactly the kind of target infostealers are built for.

The password reuse risk is a documented, automated, industrial-scale attack pattern.

The offboarding nightmare: Orphaned accounts

When an employee leaves, their managed accounts get deprovisioned. Their shadow IT accounts don't. Nobody knows they exist.

That former developer's Figma workspace, the sales rep's personal HubSpot trial with exported CRM data, the contractor's Notion page with internal architecture notes: all of these persist indefinitely after the person walks out the door.

The consequences can be severe. In one documented case, a former Cisco employee accessed an AWS-hosted virtual machine infrastructure five months after termination and deleted 456 virtual machines, taking down more than 16,000 WebEx Teams accounts for nearly two weeks. =

The US Department of Justice confirmed the incident cost Cisco approximately $2.4 million in remediation and customer refunds, and the former employee was sentenced to 24 months in federal prison (United States v. Sudhish Kasaba Ramesh, Case No. 5:20-cr-00102). That was a managed system. Orphaned shadow IT accounts are harder to find and take longer to close — if they're ever closed at all.

AI agents and unmanaged OAuth permissions

This is the threat most organizations aren't tracking yet. AI agents operate through delegated OAuth permissions: a user grants the agent access to Google Drive, GitHub, or Slack, and the agent can read, write, and act on that access continuously — not just during the session.

When the user logs out, the OAuth grant remains. When the user leaves the company, the OAuth grant remains. The agent may still have access to corporate repositories, email threads, and shared drives weeks or months after the person who authorized it is gone.

Okta's AI Agents at Work 2026 report found that 58% of organizations suffered an AI-related security incident in the past year, yet 90% of executives reported lacking full visibility into which AI agents are operating within their organization. The gap between adoption and governance is where the risk lives.

Compliance violations and regulatory fines

Unsanctioned apps don't comply with GDPR Article 32's requirement for "appropriate technical and organisational measures" to protect personal data. They don't satisfy HIPAA's technical safeguard requirements under 45 CFR § 164.312. They don't meet PCI-DSS Requirement 12.8 for managing third-party service providers.

The EU AI Act adds another layer. High-risk AI systems used without proper governance carry penalties of up to €15 million or 3% of global annual turnover under Article 99(4).

The financial services sector has already seen what regulatory enforcement looks like in practice. In September 2022, the SEC and CFTC fined 16 Wall Street firms a combined $1.8 billion for employees using WhatsApp and other unapproved messaging apps for business communications — a textbook shadow IT violation that regulators treated as a recordkeeping failure. The SEC's press release makes clear that "widespread and longstanding" use of off-channel communications is not a mitigating factor; it's an aggravating one.

European regulatory exposure: GDPR, NIS2, and DORA

For organizations operating in the EU, shadow IT creates layered regulatory exposure across three distinct frameworks. Each targets a different dimension of the problem, and together they leave very little room for "we didn't know."

GDPR: Unauthorized processors and cross-border transfers

GDPR Article 32 is the provision most organizations cite. But Article 28 is the one shadow IT actually violates first. Every unsanctioned SaaS tool that processes personal data is, in GDPR terms, a data processor. Article 28 requires a written data processing agreement (DPA) with every such processor before processing begins. An employee who signs up for a free AI tool using their corporate email and feeds it customer data has created an unauthorized processor relationship — with no DPA, no due diligence, and no record.

Articles 44 through 49 compound the exposure. Many US-based SaaS and AI tools transfer personal data outside the European Economic Area. Without a valid transfer mechanism (Standard Contractual Clauses, an adequacy decision, or Binding Corporate Rules), that transfer violates GDPR regardless of how the tool was adopted. Employees choosing tools independently have no visibility into where data is processed or stored.

European DPAs have enforced both provisions. In 2023, the Irish Data Protection Commission fined Meta €1.2 billion under Article 46 for unlawful data transfers to the US — the largest GDPR fine to date. While that case involved a platform operator rather than an enterprise end user, the underlying principle applies: the absence of a valid transfer mechanism is a violation, regardless of intent.

NIS2: Access control and supply chain obligations

The NIS2 Directive (Directive EU 2022/2555), applicable to essential and important entities across the EU since October 2024, directly addresses the conditions that shadow IT creates. Article 21(2) sets out ten minimum cybersecurity risk-management measures. Three are directly implicated by shadow IT:

• Article 21(2)(d): Supply chain security, including security aspects concerning the relationships between each entity and its direct suppliers or service providers. Every unsanctioned SaaS tool is, in effect, an unvetted supplier relationship.
• Article 21(2)(i): Policies and procedures regarding the use of cryptography and, where appropriate, encryption.
• Article 21(2)(j): Human resources security, access control policies, and asset management.

NIS2 penalties reach €10 million or 2% of global annual turnover for important entities, and €7 million or 1.4% for others. Member state transposition varies, but the framework is now active across the EU.

Passwork's NIS2 compliance page covers how centralized credential management maps to NIS2 Article 21 requirements in detail.

DORA: ICT third-party risk for financial entities

The Digital Operational Resilience Act (DORA, Regulation EU 2022/2554) has been in force since January 2025 for financial entities operating in the EU: banks, insurers, investment firms, payment processors, and their critical ICT providers. Article 28 requires financial entities to maintain a register of all ICT third-party service providers and conduct pre-contractual due diligence before onboarding any new provider.

Shadow SaaS is directly in scope. An employee at a bank who adopts an unsanctioned project management tool or AI assistant has created an unregistered ICT third-party relationship. Under DORA, that's not an IT governance issue; it's a regulatory breach. The European Supervisory Authorities (EBA, ESMA, EIOPA) have supervisory authority to investigate and sanction. In jurisdictions where national transposition provides for it, management-level criminal liability may also apply.

For financial sector IT and compliance teams, shadow IT discovery is no longer a best practice. Under DORA, it's a legal obligation.

The financial impact: Quantifying the cost of shadow IT

Shadow IT carries two distinct financial costs: breach exposure and wasted spend. IBM's 2025 Cost of a Data Breach Report found that shadow AI involvement adds $670,000 to the average breach cost of $4.44 million. On the spend side, Zylo's 2026 SaaS Management Index puts average wasted license spend at $21 million per year — driven by redundant tools, unused seats, and purchases IT never knew about.

IBM 2025 data: the $670K shadow AI penalty

IBM's 2025 Cost of a Data Breach Report is the most authoritative benchmark available for understanding the financial consequences of unmanaged AI. The headline numbers:

• Global average breach cost: $4.44 million
• Shadow AI involvement adds $670,000 to that average, bringing the shadow-AI-involved figure to approximately $5.11 million
• 97% of AI-related incidents involved systems without proper access controls
• 20% of organizations reported a security incident directly linked to shadow AI in 2025

The $670,000 adder is the incremental cost of investigation, containment, notification, and remediation when AI systems are involved that security teams didn't know about.

Wasted IT spend and redundant licensing

Organizations pay for approved tools while employees quietly adopt free or cheaper alternatives. The result: duplicate functionality, stranded licenses, and spend that nobody owns.

According to Zylo's 2026 SaaS Management Index, the average organization wastes $21 million a year on unused SaaS licenses alone — and the average utilization rate across enterprise SaaS portfolios sits at just 47%. For mid-market firms running 500 or fewer employees, that figure still reaches $4.2 million annually in wasted license spend.

The pattern is predictable: decentralized purchasing means teams sign up for tools independently, often unaware that an enterprise contract for the same category already exists. When a security incident occurs on top of that, remediation costs compound the baseline waste into a material financial exposure.

How to detect shadow IT and shadow AI

Detecting shadow IT in 2026 requires combining at least five data sources: CASB (Cloud Access Security Broker) deployment, DNS log analysis, EDR (Endpoint Detection and Response), expense data review, and email integration scanning. Each method covers a different slice of the environment. None covers all of it. Blind spots are structural, not incidental — no single tool sees personal devices, free-tier accounts, and managed endpoints simultaneously.

Endpoint monitoring and browser extensions

EDR tools and browser extension audits can surface unauthorized SaaS usage directly on the device. Browser history analysis, extension inventories, and agent-based monitoring catch activity that never touches the corporate network.

The limitation: BYOD (Bring Your Own Device) environments and personal devices used for work are largely invisible to endpoint tools unless the organization has deployed MDM (Mobile Device Management) with appropriate scope.

Network analysis: DNS and proxy logs

DNS query logs and web proxy data reveal which domains employees are accessing. Spikes in traffic to unknown SaaS domains, AI services, or file-sharing platforms show up clearly in DNS logs even when the content is encrypted.

This method works well for corporate network traffic. It misses everything that happens over cellular connections, home networks, or VPNs that route outside the corporate proxy. DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) encrypt queries end-to-end, bypassing traditional DNS inspection entirely without additional firewall policy to block them.

CASB: strengths and limitations

A CASB (Cloud Access Security Broker) sits between users and cloud services, providing visibility, policy enforcement, and data loss prevention for sanctioned and unsanctioned apps. CASBs are the most purpose-built tool for shadow IT detection and can identify thousands of cloud services in use across an organization.

The practical limitation is coverage. CASBs work best when traffic routes through them — most effective for managed devices on corporate networks. Employees using personal accounts on personal devices, or AI tools accessed via browser without SSO, may not be visible. Shadow AI features embedded inside already-sanctioned SaaS tools are also typically undetected, since the parent domain is already approved.

A 6-step framework to manage shadow IT

The Shadow IT Governance Framework is a six-step process: discover and classify, centralize credentials, establish policy, streamline approvals, automate offboarding, and build a security awareness program. It addresses both the technical and behavioral dimensions of the problem. Blocking unsanctioned tools without enabling faster approved alternatives consistently fails.

Step 1. Discover and classify

You cannot govern what you cannot see. Start with a comprehensive discovery sweep using a combination of DNS log analysis, CASB deployment, endpoint monitoring, and expense data review. The output should be a classified inventory: sanctioned, tolerated (known but not formally approved), and unsanctioned.

Classify each application by data sensitivity. A free grammar checker accessing email drafts is a different risk profile than an AI coding assistant with repository access.

Step 2. Implement secure credential management

Every shadow IT account is an unmanaged credential. The fix is not to prohibit accounts; it's to bring credentials under centralized control.

A centralized vault with role-based access control (RBAC) gives employees a secure, convenient place to store and share credentials for both approved and newly-approved tools. When access is centralized, offboarding becomes deterministic: revoke vault access, and the employee loses access to every credential stored there.

Passwork is available as a self-hosted deployment or in the cloud, giving teams the flexibility to choose where credential data lives. The self-hosted model keeps everything within your own infrastructure with no dependency on third-party cloud services; the cloud option gets you up and running without managing your own server stack. Either way, administrators get full visibility into who has access to what and a complete audit log of every credential operation. See the technical guides for deployment and integration details.

Step 3. Establish clear AI and SaaS policies

A blanket prohibition will be ignored even by the people enforcing it. A policy that defines how to get tools approved, what data classifications are permissible in AI tools, and what happens to OAuth grants when an employee leaves is actionable.

The policy should specifically address:

• Prohibited data classifications for AI tool input (PII, source code, financial data, credentials)
• OAuth grant approval and review cycles
• Maximum time-to-approval for new SaaS requests (slow approval processes are the primary reason employees go around IT)
• Consequences for policy violations

Step 4. Streamline the approval process

Shadow IT exists because the approved path is too slow. If an employee needs a tool today and the approval process takes three weeks, they'll use the tool without approval and ask for forgiveness later, if they ask at all.

Build a lightweight approval workflow: a short intake form, a 48-hour SLA for low-risk tools, and a clear decision framework based on data sensitivity and vendor security posture. The goal is to make "go through IT" faster than "figure it out yourself."

Step 5. Automate offboarding workflows

Manual offboarding is where orphaned accounts are born. When an employee leaves, IT typically deprovisions the accounts it knows about. Shadow IT accounts, by definition, aren't on that list.

Automated offboarding workflows, triggered by HRIS termination events, should:

• Revoke SSO and IdP access immediately
• Rotate or invalidate all credentials stored in the centralized vault for that user
• Audit and revoke OAuth grants associated with the user's corporate identity
• Transfer ownership of shared resources before access is cut

The Passwork user guides cover credential vault offboarding workflows in detail, including how to handle shared passwords and service account credentials that need to be rotated, not just revoked.

Step 6. Build a security awareness program

Policy and tooling alone don't change behavior. Employees adopt shadow IT because they don't understand the risk, don't know the approved alternative exists, or find the approved path too slow. A security awareness program addresses the first two directly.

• Make the risk concrete: showing employees a real example of how a credential reuse attack works lands harder than a slide about "data protection." Publicize the approved toolkit; employees who know a fast, sanctioned alternative exists are less likely to reach for an unapproved one. 
• Create a reporting culture: employees should feel comfortable flagging tools they're already using without fear of immediate punishment. Discovery through self-reporting is faster and cheaper than discovery through a breach.
• Annual training is not enough. Quarterly micro-training sessions (10-15 minutes, scenario-based) consistently outperform annual compliance modules in retention studies. Phishing simulations that include fake SaaS sign-up prompts — not just email lures — test exactly the behavior shadow IT governance is trying to change.

Track the program's effect on shadow IT discovery rates, not just training completion percentages. Completion is an input metric. Reduction in unsanctioned tool adoption is the output that matters.

Conclusion: Make the approved path faster than the workaround

The organizations that manage shadow IT effectively are the ones that made the approved path faster than the workaround. Not the ones with the strictest blocking policies.

That means a discovery program that runs continuously. A credential vault that employees actually want to use because it saves them time. An offboarding workflow that fires automatically the moment an HRIS termination event triggers. An AI policy that tells employees what they can do with AI tools, not just what they can't. And a security awareness program that makes the risk real rather than abstract.

For European organizations, the stakes are higher still. GDPR Article 28, NIS2 Article 21, and DORA Article 28 don't treat shadow IT as a governance inconvenience; they treat it as a compliance failure with quantified penalties attached. The $670,000 shadow AI cost adder from IBM's 2025 report isn't an abstraction. It's what happens when governance lags adoption. Close that gap /before the next breach makes the case for you.

Frequently asked questions

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

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

Supply chain security guide: Vendor risks, regulations, access control in 2026

48% of breaches now involve a third party. This guide covers the attack patterns behind SolarWinds, MOVEit, and XZ Utils — and the access controls, credential management practices, and regulatory requirements that actually stop them.

Passwork BlogAlex Muntyan

Noch vor wenigen Jahren war der Standardrat einfach: Prüfen Sie Ihre Anbieter, unterzeichnen Sie eine Geheimhaltungsvereinbarung, führen Sie einen jährlichen Fragebogen durch. Dann kam SolarWinds, dann MOVEit, dann XZ Utils — eine Hintertür, die über zwei Jahre legitimer Open-Source-Beiträge eingeschleust und von einem Ingenieur entdeckt wurde, dem auffiel, dass ein Prozess 500 ms langsamer lief als erwartet. Jeder dieser Angriffe erfolgte über eine vertrauenswürdige Beziehung.

Das Muster ist bei jedem größeren Vorfall gleich. Die Beteiligung von Drittanbietern macht laut Verizons 2026 DBIR mittlerweile 48 % aller Datenschutzverletzungen aus (gegenüber 30 % im Vorjahr), und die durchschnittliche Kompromittierung der Lieferkette kostet 4,91 Millionen US-Dollar und benötigt 267 Tage zur Eindämmung, laut IBMs Cost of a Data Breach Report 2025. 

Die meisten Organisationen reagieren weiterhin mit Fragebögen und jährlichen Audits. Diese haben ihren Platz. Aber ein Fragebogen verhindert keine Sicherheitsverletzung. Das Widerrufen der permanenten Berechtigungen eines Anbieters schon. Dieser Leitfaden behandelt Lieferkettensicherheit als das, was sie tatsächlich ist: ein IAM- und Credential-Control-Problem mit einer Compliance-Ebene darüber.

Wichtige Erkenntnisse

• Die Beteiligung von Drittanbietern macht mittlerweile 48 % aller Datenschutzverletzungen aus — gegenüber 30 % im Vorjahr, laut Verizons 2026 DBIR. Lieferkettenangriffe sind der dominierende Angriffsvektor.
• Die durchschnittliche Kompromittierung der Lieferkette kostet 4,91 Millionen US-Dollar und benötigt 267 Tage zur Eindämmung. Diese Verweildauer macht permanente Anbieterberechtigungen so gefährlich — Angreifer müssen sich nicht beeilen, wenn die Anmeldedaten nie ablaufen.
• Jeder größere Lieferkettenvorfall erfolgte über eine vertrauenswürdige Beziehung. SolarWinds, MOVEit, XZ Utils — in jedem Fall nutzte der Angreifer Zugriff, der bereits bereitgestellt und bereits als vertrauenswürdig eingestuft war.
• Fragebögen und jährliche Audits verhindern keine Sicherheitsverletzungen. Das Widerrufen permanenter Anbieterberechtigungen schon. Die entscheidenden Kontrollen sind technischer Natur: Credential-Vaulting, JIT-Zugriff, RBAC mit Beschränkung auf den Auftrag und Phishing-resistente MFA.
• NIS2, DORA und der EU Cyber Resilience Act machen Lieferkettensicherheit zur gesetzlichen Pflicht. NIS2 Artikel 21, DORA Artikel 28–30 und CRA-Anforderungen gelten mit gestaffelten Fristen bis 2027.
• 70 % der Top-50-Anbieter, die von Global-2000-Unternehmen gemeinsam genutzt werden, weisen mindestens eine ungepatchte KEV-Schwachstelle auf, laut Black Kites Third-Party Breach Report 2026.

Was ist Cyber Supply Chain Risk Management (C-SCRM)?

Cyber Supply Chain Risk Management (C-SCRM) ist die Disziplin der Identifizierung, Bewertung und Minderung von Cybersicherheitsrisiken, die aus dem erweiterten Netzwerk von Lieferanten, Anbietern, Dienstleistern und Software-Abhängigkeiten einer Organisation stammen. Es umfasst alles von den SaaS-Tools, die Ihre Entwickler nutzen, bis hin zum Managed Service Provider (MSP) mit Admin-Zugriff auf Ihre Produktionsumgebung.

C-SCRM liegt an der Schnittstelle von Beschaffung, IT-Sicherheit und Compliance. NIST SP 800-161 Rev. 1 bietet das detaillierteste föderale Framework dafür und definiert C-SCRM als strukturierten Prozess zur Steuerung der Exposition gegenüber Cybersicherheitsrisiken während des gesamten Lieferketten-Lebenszyklus — von der ersten Anbieterauswahl bis zur Vertragsbeendigung und Zugriffsentzug.

Der Umfang ist größer, als den meisten Teams bewusst ist. Ihre Lieferkette umfasst:

• Softwareanbieter und Open-Source-Abhängigkeiten
• Cloud-Infrastruktur und SaaS-Anbieter
• Managed-Service- und IT-Support-Anbieter
• Hardwarehersteller und Firmware-Lieferanten
• Beratungsunternehmen mit Netzwerk- oder Datenzugriff

Jeder dieser Bereiche ist ein potenzieller Eintrittspunkt. Die Vorfälle SolarWinds, MOVEit und XZ Utils nutzten diesen Eintrittspunkt auf unterschiedliche Weise aus.

Der Stand der Lieferkettenangriffe 2025–2026

Lieferkettenangriffe erreichten 2025–2026 Rekordniveaus. Verizons 2026 DBIR verzeichnete eine Drittanbieterbeteiligung bei 48 % aller analysierten Sicherheitsverletzungen — der höchste Wert in der Geschichte des Berichts und ein Anstieg um 60 % gegenüber den 30 % des Vorjahres. IBMs Cost of a Data Breach Report 2025 beziffert die durchschnittliche Kompromittierung der Lieferkette auf 4,91 Millionen US-Dollar mit einem durchschnittlichen Lebenszyklus von 267 Tagen von der Erkennung bis zur Eindämmung.

Bedrohungsakteure haben gelernt, dass die Kompromittierung eines vertrauenswürdigen Anbieters gleichzeitig Zugang zu Dutzenden oder Hunderten von nachgelagerten Organisationen ermöglicht. Die Wirtschaftlichkeit begünstigt den Angreifer: ein erfolgreicher Einbruch, multipliziert über die gesamte Kundenbasis eines Anbieters.

Laut Black Kites Third-Party Breach Report 2026 weisen 70 % der Top-50-Anbieter, die von Global-2000-Unternehmen gemeinsam genutzt werden, mindestens eine ungepatchte Schwachstelle aus dem CISA Known Exploited Vulnerabilities (KEV) Katalog auf. Dies sind keine theoretischen Risiken — CISA kennzeichnet KEV-Einträge speziell deshalb, weil sie aktiv in freier Wildbahn ausgenutzt werden.

Lehren aus SolarWinds, MOVEit und XZ Utils

Alle drei Vorfälle haben einen gemeinsamen Nenner: Der initiale Zugriffsvektor war vertrauenswürdig. Vertrauenswürdige Software, vertrauenswürdiger Anbieter, vertrauenswürdiger Mitwirkender. Einmal drinnen, bewegte sich der Angreifer lateral mit Anmeldedaten und Zugriff, die bereits bereitgestellt waren.

SolarWinds (2020)

Angreifer kompromittierten die Build-Pipeline direkt und fügten eine Hintertür in ein signiertes Software-Update ein, das als routinemäßiger Patch an Kunden verteilt wurde. Etwa 18.000 Organisationen installierten es. Die rechtlichen Folgen zogen sich über Jahre hin: Die SEC reichte im Oktober 2023 eine zivilrechtliche Klage gegen SolarWinds und seinen CISO ein, wobei der Fall schließlich 2025 vollständig abgewiesen wurde.

Die Lehre: Kontrollen der Software-Integrität und SBOM-Transparenz (Software Bill of Materials) sind genauso wichtig wie Netzwerkperimeterkontrollen — und die Haftungsexposition durch eine Build-Pipeline-Kompromittierung reicht weit über die ursprüngliche Sicherheitsverletzung hinaus.

MOVEit (2023)

Eine Zero-Day-SQL-Injection-Schwachstelle (CVE-2023-34362) in einem Managed-File-Transfer-Produkt gab der Cl0p-Ransomware-Gruppe Zugang zu Daten von über 2.700 Organisationen — von denen viele keine direkte Beziehung zu MOVEit hatten, aber durch die Nutzung bei ihren Anbietern betroffen waren. Die endgültige Opferzahl erreichte etwa 95 Millionen Personen. 

Die Lehre: Ihre Angriffsfläche umfasst Software, die Ihre Anbieter betreiben, nicht nur Software, die Sie selbst betreiben.

XZ Utils (2024)

Eine mehrjährige Social-Engineering-Kampagne fügte eine Hintertür in eine weit verbreitete Open-Source-Kompressionsbibliothek ein. Der Angreifer trug zwei Jahre lang legitimen Code bei, bevor er die schädliche Payload einführte — und die Hintertür wurde nicht durch einen formalen Sicherheitsprozess entdeckt, sondern von einem Microsoft-Ingenieur, dem eine 500-ms-Verzögerung bei SSH-Logins auffiel. 

Die Lehre: Das Risiko von Open-Source-Abhängigkeiten ist real, SBOMs sind der einzige systematische Weg, es zu verfolgen, und Ihre Erkennungskontrollen müssen Verhalten abdecken, nicht nur Signaturen.

Die größten Anbieterrisiken in der modernen Lieferkette

Die fünf häufigsten Kategorien von Lieferkettenrisiken sind:

• Geteilte Anmeldedaten und mangelhafte Zugangskontrolle
• Schwachstellen in Software-Abhängigkeiten
• Hardware- und Komponenten-Manipulation
• Shadow AI und Datenexposition durch Dritte
• Anbieter-Konzentrationsrisiko

Jede erfordert eine eigene Kontrollmaßnahme. Fehler bei geteilten Anmeldedaten sind ein Prozessproblem. Hardware-Manipulation erfordert physische Herkunftsverifizierung.

Geteilte Anmeldedaten und mangelhafte Zugangskontrolle

Das häufigste und am leichtesten vermeidbare Lieferkettenrisiko ist auch das am wenigsten spektakuläre: gemeinsam genutzte Konten. Ein Anbieter-Support-Team erhält einen einzigen Satz Anmeldedaten für den Zugriff auf Ihre Umgebung. Diese Anmeldedaten werden unter den Mitarbeitern des Anbieters geteilt, in einer Tabelle oder E-Mail-Kette gespeichert und nach Ende des Auftrags nie rotiert.

Wenn dieser Anbieter kompromittiert wird oder ein verärgerter Mitarbeiter das Unternehmen verlässt, haben Sie keine Möglichkeit zu wissen, wer diese Anmeldedaten wann verwendet hat oder worauf zugegriffen wurde. Sie haben keinen Audit-Trail. Sie haben keine Möglichkeit, den Zugriff für eine einzelne Person zu widerrufen, ohne die Anmeldedaten für alle zu ändern.

Verizons 2026 DBIR identifiziert Authentifizierungsfehler (fehlende oder umgangene MFA, gestohlene Anmeldedaten) als den primären Mechanismus bei Drittanbieter-Sicherheitsverletzungen. Dies ist ein Prozessfehler.

Schwachstellen in der Software-Lieferkette und die Notwendigkeit von SBOMs

Eine Software Bill of Materials (SBOM) ist ein maschinenlesbares Inventar aller Komponenten eines Softwareprodukts: Bibliotheken, Abhängigkeiten, Versionen und ihre bekannten Schwachstellen. Die U.S. Executive Order 14028 (2021) schrieb SBOMs für Software vor, die an Bundesbehörden verkauft wird. Der EU Cyber Resilience Act (CRA) erweitert ähnliche Anforderungen auf Produkte, die auf dem europäischen Markt verkauft werden, wobei Schwachstellen-Meldepflichten ab September 2026 und vollständige Produktanforderungen ab Dezember 2027 gelten.

Ohne eine SBOM können Sie die Frage „Nutzen wir die verwundbare Version von Log4j?" nicht innerhalb von 24 Stunden beantworten. Mit einer schon. Dieser Geschwindigkeitsunterschied ist die Lücke zwischen einem eingedämmten Vorfall und einer Sicherheitsverletzung, deren Behebung 267 Tage dauert.

Hardware- und Komponenten-Manipulation

Das Hardware-Lieferkettenrisiko unterscheidet sich vom Softwarerisiko und wird oft unterschätzt. Gefälschte oder manipulierte Komponenten — Netzwerkausrüstung, Server-Hardware, Firmware — können persistente Hintertüren einführen, die eine Betriebssystem-Neuinstallation überleben und für Software-Layer-Sicherheitskontrollen unsichtbar sind.

Der EU Cyber Resilience Act adressiert explizit Hardwareprodukte mit digitalen Elementen und verlangt von Herstellern, die Lieferkettensicherheit für physische Komponenten zu bewerten und zu dokumentieren. Für Organisationen, die Netzwerkinfrastruktur oder industrielle Steuerungssysteme beschaffen, bedeutet dies die Verifizierung der Komponentenherkunft, das Anfordern von Firmware-Integritätsnachweisen von Lieferanten und die Führung eines Inventars von Hardware-Versionen, das einer Software-SBOM entspricht.

Shadow AI und Datenexposition durch Dritte

Verizons 2026 DBIR identifiziert Shadow AI als eines der drei größten Insider-Verhaltensweisen — Mitarbeiter, die nicht autorisierte KI-Tools nutzen, die Organisationsdaten außerhalb genehmigter Kanäle verarbeiten. Der Lieferkettenaspekt: Viele dieser Tools sind Drittanbieter-SaaS-Produkte mit eigenen Datenaufbewahrungsrichtlinien, Unterauftragnehmervereinbarungen und Sicherheitslagen, die Ihre Organisation nie überprüft hat.

Wenn ein Entwickler Datenbank-Anmeldedaten in einen KI-Assistenten einfügt, um eine Abfrage zu debuggen, können diese Anmeldedaten aufbewahrt, protokolliert oder für das Modelltraining verwendet werden. Das Anbieterrisiko ist nicht nur der KI-Anbieter — es ist jeder Unterauftragnehmer in deren Kette.

Verfügbarkeitsunterbrechungen und Anbieter-Konzentrationsrisiko

Ein Sicherheitsversagen in der Lieferkette bedeutet nicht immer eine Datenschutzverletzung. Anbieterausfälle, Ransomware-Angriffe auf kritische Lieferanten und Single Points of Failure in gemeinsam genutzter Infrastruktur können den Betrieb vollständig unterbrechen. DORAs Mandat zur operativen Resilienz existiert genau deshalb, weil der EU-Finanzsektor erkannt hat, dass Verfügbarkeitsrisiken durch ICT-Drittanbieter ebenso wesentlich sind wie Vertraulichkeitsrisiken.

Konzentrationsrisiko verstärkt dies: Wenn 70 % der Forbes Global 2000-Unternehmen dieselben Top-50-Anbieter nutzen, verbreitet sich eine einzelne Kompromittierung in großem Maßstab. Die Kartierung Ihrer kritischen Anbieterabhängigkeiten und die Pflege dokumentierter Kontinuitätspläne für Tier-1-Lieferantenausfälle ist eine Anforderung von DORA Artikel 28 für Finanzunternehmen.

Europäische und internationale regulatorische Anforderungen für Lieferkettensicherheit

NIS2, DORA und der EU Cyber Resilience Act bilden zusammen den verbindlichen regulatorischen Rahmen für Lieferkettensicherheit auf dem europäischen Markt. NIST CSF 2.0 und SP 800-161 sind US-Frameworks — keine EU-Rechtsverpflichtungen — werden aber von multinationalen Organisationen weitgehend referenziert und bieten operatives Detail, das die EU-Anforderungen ergänzt.

NIS2-Richtlinie (Artikel 21)

NIS2 Artikel 21 verlangt von den betroffenen Einrichtungen die Implementierung von „Sicherheit der Lieferkette, einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen jeder Einrichtung und ihren direkten Lieferanten oder Dienstleistern." Dies ist eine rechtliche Verpflichtung für wesentliche und wichtige Einrichtungen in 18 Sektoren, deren Durchsetzung die EU-Mitgliedstaaten Ende 2024 begonnen haben.

In der Praxis bedeutet Artikel 21, dass Sie die Sicherheitslage Ihrer direkten Anbieter bewerten, Sicherheitsanforderungen in Verträge aufnehmen und einen dokumentierten Prozess für das Management von anbieterbezogenen Vorfällen pflegen müssen. Für das Credential-Management bedeutet dies konkret: keine gemeinsam genutzten Konten, dokumentierte Verfahren für Zugriffsbereitstellung und -entzug sowie Audit-Protokolle, die bei einer Aufsichtsprüfung vorgelegt werden können.

Eine detaillierte Aufschlüsselung, wie NIS2 auf Zugangskontrollanforderungen abbildet, finden Sie im NIS2-Compliance-Leitfaden von Passwork.

DORA (Digital Operational Resilience Act)

DORA gilt für Finanzunternehmen und ihre ICT-Drittanbieter, die in der EU tätig sind. Die Artikel 28 bis 30 etablieren ein detailliertes ICT-Drittanbieter-Risikomanagement-Framework, einschließlich der Anforderungen, ein Register aller ICT-Anbieter zu führen, Risikobewertungen vor dem Onboarding durchzuführen und sicherzustellen, dass Verträge Bestimmungen für Auditrechte und Vorfallsmeldungen enthalten.

DORA führt auch das Konzept der „kritischen ICT-Drittanbieter" (CTPPs) ein, die von den europäischen Aufsichtsbehörden für direkte Überwachung designiert werden können. Wenn Ihre Organisation ein CTPP ist — oder von einem abhängt — ist die Prüfung Ihrer Lieferketten-Sicherheitskontrollen erheblich strenger. Das oben beschriebene Verfügbarkeitsunterbrechungsrisiko ist ebenso ein DORA-Anliegen wie ein Sicherheitsanliegen: Artikel 28 verlangt ausdrücklich dokumentierte Kontinuitätspläne für kritische Drittanbieterabhängigkeiten.

EU Cyber Resilience Act (CRA)

Der CRA wurde 2024 verabschiedet und gilt mit gestaffeltem Zeitplan. Schwachstellen- und Vorfallsmeldepflichten treten ab dem 11. September 2026 in Kraft. Vollständige Produktanforderungen — einschließlich SBOM-Mandate und Konformitätsbewertungen für Produkte mit digitalen Elementen — gelten ab dem 11. Dezember 2027. Organisationen, die vernetzte Hardware oder Software auf dem EU-Markt verkaufen, müssen jetzt mit der Compliance-Arbeit beginnen; die Frist 2027 kommt schneller, als die meisten Produktentwicklungszyklen zulassen.

NIST CSF 2.0 und NIST SP 800-161

NIST CSF 2.0, veröffentlicht im Februar 2024, fügte „Govern" als sechste Kernfunktion hinzu. Die GV.SC-Unterkategorie adressiert explizit das Lieferketten-Risikomanagement und verlangt von Organisationen, C-SCRM in die unternehmensweite Risiko-Governance zu integrieren — es nicht als separates IT-Projekt zu behandeln. Für EU-Organisationen ist CSF 2.0 keine rechtliche Anforderung, bietet aber eine nützliche operationelle Struktur, die gut auf NIS2- und DORA-Verpflichtungen abbildet.

NIST SP 800-161 Rev. 1 liefert das operationelle Detail: wie Lieferantenbewertungen durchzuführen sind, welche Kontrollen in Verträgen verlangt werden sollen und wie ein C-SCRM-Programm über den gesamten Beschaffungslebenszyklus strukturiert werden kann. Für US-Bundesauftragnehmer wird die Ausrichtung an SP 800-161 zunehmend zur Beschaffungsanforderung.

So sichern Sie den Anbieterzugriff: Der technische Bauplan

Die vier wirkungsvollsten Kontrollen für die Sicherheit des Anbieterzugriffs sind RBAC mit Beschränkung auf den Auftrag, Just-in-Time-Zugriff auf privilegierte Ressourcen, zentralisiertes Credential-Vaulting und Phishing-resistente MFA. In dieser Reihenfolge angewendet, adressieren sie die häufigsten Fehlermodi — permanente Berechtigungen, gemeinsam genutzte Konten und Authentifizierungslücken — ohne in den meisten Umgebungen neue Infrastruktur zu erfordern.

Strikte rollenbasierte Zugriffskontrolle (RBAC) durchsetzen

Rollenbasierte Zugriffskontrolle (RBAC) weist Berechtigungen Rollen zu, nicht Einzelpersonen. Ein Support-Ingenieur des Anbieters erhält die Rolle „Nur-Lese-Produktionsüberwachung", nicht ein persönliches Admin-Konto. Wenn der Auftrag endet, entfernen Sie die Rollenzuweisung. Wenn der Anbieter sein Personal wechselt, müssen Sie keine einzelnen Konten verfolgen — die Rolle definiert, worauf zugegriffen werden kann.

Für den Anbieterzugriff sollte RBAC auf das Minimum beschränkt sein, das für den Auftrag erforderlich ist. Ein Datenbankanbieter, der ein Performance-Audit durchführt, benötigt keinen Schreibzugriff auf die Anwendungskonfiguration. Definieren Sie die Rolle vor der Zugriffsbereitstellung, nicht danach.

Just-in-Time (JIT) privilegierten Zugriff implementieren

Just-in-Time (JIT) Zugriff bedeutet, dass privilegierte Anmeldedaten für ein definiertes Zeitfenster ausgestellt und automatisch widerrufen werden, wenn dieses Fenster geschlossen wird. Ein Anbieter-Ingenieur fordert Zugriff für ein zweistündiges Wartungsfenster an; das System gewährt ihn, protokolliert die Sitzung und widerruft ihn nach zwei Stunden, unabhängig davon, ob der Ingenieur daran denkt, sich abzumelden.

JIT-Zugriff eliminiert permanente Berechtigungen: den persistenten, immer aktiven Zugriff, den Angreifer während der durchschnittlich 267 Tage dauernden Verweildauer einer Lieferketten-Sicherheitsverletzung ausnutzen. Es gibt nichts zu stehlen, wenn die Anmeldedaten ablaufen, bevor der Angreifer sie nutzen kann. JIT ist besonders wirksam für Break-Glass-Szenarien: Notfall-Anbieterzugriff während eines Vorfalls, bei dem Geschwindigkeit wichtig ist, aber auch Verantwortlichkeit.

Sicheres Anbieter-Credential-Vaulting

Gemeinsam genutzte Anbieterkonten sind eine Haftung. Die Alternative ist ein Credential-Vault: ein zentralisierter, verschlüsselter Speicher, in dem Anbieter-Anmeldedaten von Ihrer Organisation gehalten werden, nicht vom Anbieter. Der Anbieter authentifiziert sich am Vault, checkt Anmeldedaten für seine Sitzung aus, und der Vault protokolliert jedes Zugriffsereignis.

Dieser Ansatz gibt Ihnen einen vollständigen Audit-Trail darüber, wer wann auf was zugegriffen hat, die Möglichkeit, Anmeldedaten ohne Abstimmung mit dem Anbieter zu rotieren, automatischen Widerruf bei Ende der Anbieterbeziehung und Compliance-Nachweise für die Auditrechtsanforderungen von NIS2 Artikel 21 und DORA Artikel 30.

Passworks Enterprise-Passwort- und Secrets-Manager unterstützt zeitlich begrenztes Credential-Sharing, Sitzungsprotokollierung und Integration mit AD/LDAP- und SSO-Infrastruktur — mit AES-256-Client-seitiger Verschlüsselung und einer vollständigen REST API für die Integration in bestehende Bereitstellungs-Workflows.

Phishing-resistente MFA für Dritte vorschreiben

MFA ist die einzelne Kontrolle mit dem höchsten ROI für den Drittanbieterzugriff. Verizons 2026 DBIR ordnet die Mehrheit der Drittanbieter-Sicherheitsverletzungsszenarien Authentifizierungsfehlern zu — und die meisten dieser Fehler sind fehlende MFA, nicht umgangene MFA.

Für privilegierten Anbieterzugriff auf Produktionssysteme sollte der Standard Phishing-resistente MFA sein: FIDO2/WebAuthn-Hardwareschlüssel oder Passkeys, nicht SMS OTP. SMS-basierte MFA ist anfällig für SIM-Swapping und Echtzeit-Phishing-Proxies. Fordern Sie Phishing-resistente MFA von Anbietern vertraglich als Zugangsbedingung. Nehmen Sie es in Ihren Anbieter-Sicherheitsanhang auf, nicht nur in Ihre interne Richtlinie.

Die meisten der in diesem Leitfaden beschriebenen Zugangskontrollfehler haben dieselbe Ursache: Anbieter-Anmeldedaten, die nie richtig in einem Vault gespeichert, begrenzt oder widerrufen wurden. Passwork adressiert das direkt — zentralisiertes Credential-Vaulting, rollenbasierter Zugriff, zeitlich begrenztes Teilen und ein vollständiger Audit-Trail, der an benannte Identitäten gebunden ist. Verfügbar als Self-hosted oder als Cloud-Bereitstellung, integriert es sich mit AD/LDAP und SAML SSO und ist ISO 27001 zertifiziert.

Aufbau eines Anbieter-Risikobewertungs-Frameworks

Ein Anbieter-Risikobewertungs-Framework klassifiziert Dritte nach Zugangslevel und wendet verhältnismäßige Sicherheitsanforderungen auf jede Stufe an. Das 5-Stufen-Modell unten skaliert von Tier-1-Anbietern mit privilegiertem Produktionszugriff, die vollständige Sicherheitsbewertungen und jährliche Reviews erfordern — bis hin zu Tier-5-Anbietern ohne Daten- oder Systemzugriff, bei denen Standard-Beschaffungs-Due-Diligence ausreicht.

Das 5-Stufen-Anbieter-Risikoklassifizierungsmodell:

Die Klassifizierung bestimmt den verhältnismäßigen Aufwand. Sie benötigen keinen vollständigen Penetrationstestbericht von Ihrem Bürobedarfslieferanten. Von dem MSP mit Admin-Zugriff auf Ihr Active Directory schon.

Checkliste für Anbieterzugangskontrolle

Die folgende Pre-Audit-Checkliste für Anbieterzugriff bildet direkt auf die Anforderungen von NIS2 Artikel 21, DORA Artikel 28 und NIST SP 800-161 ab. Verwenden Sie sie beim Anbieter-Onboarding und bei jeder jährlichen Überprüfung.

Vor der Zugriffsbereitstellung:

•  Anbieter nach Stufe basierend auf Zugangslevel klassifiziert
•  Minimaler notwendiger Zugriffsumfang schriftlich definiert
•  Benannte Personen identifiziert (keine gemeinsam genutzten/generischen Konten)
•  MFA-Anforderung bestätigt und getestet
•  Zugriff über Credential-Vault bereitgestellt, nicht durch direkte Weitergabe von Anmeldedaten
•  Sitzungsprotokollierung aktiviert

Während des Auftrags:

•  Zugriffsumfang überprüft, wenn sich der Auftragsumfang ändert
•  Ungewöhnliche Zugriffsmuster zur Überprüfung gekennzeichnet
•  Anbieter-Vorfallsbenachrichtigungsklausel im Vertrag aktiv

Zugriffsentzug:

•  Offboarding-Auslöser definiert (Vertragsende, Personalwechsel, Vorfall)
•  Anmeldedaten sofort beim Offboarding rotiert
•  Vault-Zugriff widerrufen und Audit-Protokoll exportiert
•  Zugriffsüberprüfung für Compliance-Unterlagen dokumentiert

Fazit: Lieferkettensicherheit operationalisieren

Organisationen, die dies gut handhaben, haben nicht weniger Anbieter; sie haben strengere Kontrollen darüber, wie sich diese Anbieter authentifizieren, worauf sie zugreifen können und für wie lange.

Der technische Bauplan ist klar: Anbieter nach Zugriffsstufe klassifizieren, gemeinsam genutzte Konten eliminieren, Anmeldedaten zentral in einem Vault speichern, JIT-Zugriff für privilegierte Sitzungen durchsetzen und Phishing-resistente MFA verlangen. NIS2, DORA und der CRA bieten die Governance-Struktur und die vertragliche Hebelwirkung, um Anbieter am selben Standard zu messen.

Beginnen Sie mit Ihren Tier-1-Anbietern — denen mit privilegiertem Zugriff auf Produktionssysteme. Prüfen Sie deren aktuellen Zugriffsumfang, bestätigen Sie die Zuweisung einzelner Konten und verifizieren Sie, dass MFA aktiv ist. Dieser einzelne Durchgang wird mehr handlungsfähiges Risiko aufdecken als ein Jahr voller Fragebögen.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Lieferkettensicherheit und Anbieter-Risikomanagement?

Anbieter-Risikomanagement (Vendor Risk Management, VRM) ist die breitere Disziplin, die finanzielle, operative, reputationsbezogene und Cyber-Risiken von Dritten abdeckt. Lieferkettensicherheit ist die cybersicherheitsspezifische Untermenge: der Schutz von Systemen, Daten und Software-Integrität vor Bedrohungen, die über Lieferantenbeziehungen eintreten. VRM informiert Beschaffungsentscheidungen; Lieferkettensicherheit regelt technische Zugriffskontrollen und Software-Integrität.

Welche Vorschriften erfordern Lieferketten-Sicherheitskontrollen in 2025–2026?

NIS2-Richtlinie Artikel 21 verlangt von wesentlichen und wichtigen EU-Einrichtungen, Lieferantensicherheitsrisiken zu bewerten und zu managen. DORA Artikel 28–30 erlegt EU-Finanzunternehmen ICT-Drittanbieter-Risikomanagement-Verpflichtungen auf. Der EU Cyber Resilience Act verlangt Schwachstellenmeldungen ab September 2026 und vollständige SBOM- und Konformitätsanforderungen ab Dezember 2027. In den USA setzen NIST SP 800-161 und Executive Order 14028 C-SCRM-Erwartungen für Bundesauftragnehmer.

Was ist Just-in-Time (JIT) Zugriff und warum ist er für Anbietersicherheit wichtig?

JIT-Zugriff stellt privilegierte Anmeldedaten für ein definiertes Zeitfenster aus und widerruft sie automatisch, wenn dieses Fenster geschlossen wird. Er eliminiert permanente Berechtigungen — persistenten Zugriff, den Angreifer während der für Lieferketten-Sicherheitsverletzungen typischen verlängerten Verweildauer ausnutzen. IBMs Daten von 2025 zeigen, dass Lieferkettenkompromittierungen durchschnittlich 267 Tage benötigen, um identifiziert und eingedämmt zu werden; JIT-Zugriff reduziert das ausnutzbare Fenster auf Stunden, nicht Monate.

Wie reduzieren SBOMs das Lieferkettenrisiko?

Eine Software Bill of Materials (SBOM) ist ein maschinenlesbares Inventar aller Softwarekomponenten und ihrer Versionen. Wenn eine neue Schwachstelle offengelegt wird — wie Log4Shell 2021 — ermöglicht Ihnen eine SBOM, innerhalb von Minuten festzustellen, ob eines Ihrer Systeme oder eine vom Anbieter bereitgestellte Software die betroffene Komponente enthält. Ohne SBOM kann dieselbe Feststellung Tage oder Wochen dauern, während derer die Schwachstelle ungepatcht und ausnutzbar bleibt.

Was sollte ein Anbieter-Sicherheitsvertragsanhang enthalten?

Mindestens: eine Anforderung für benannte einzelne Konten (keine gemeinsam genutzten Anmeldedaten), Phishing-resistente MFA für privilegierten Zugriff, Benachrichtigungspflichten innerhalb von 24–72 Stunden nach einem Sicherheitsvorfall, Auditrechte, die Ihrer Organisation die Überprüfung von Zugriffsprotokollen ermöglichen, und ein definierter Offboarding-Prozess einschließlich Credential-Rotation. NIS2 Artikel 21 und DORA Artikel 30 verlangen beide vertragliche Sicherheitsbestimmungen — der Anhang ist Ihr Compliance-Nachweis.

Wie sollten Organisationen Anbieter für Risikobewertungszwecke klassifizieren?

Klassifizieren Sie nach Zugangslevel, nicht nach Vertragswert oder Anbietergröße. Ein kleines Beratungsunternehmen mit Admin-Zugriff auf Ihre Produktionsumgebung ist risikoreicher als ein großer Softwareanbieter ohne direkten Systemzugriff. Das oben dargestellte 5-Stufen-Anbieter-Risikoklassifizierungsmodell bietet eine praktische Struktur: Tier 1 (privilegierter Produktionszugriff) bis Tier 5 (kein Daten- oder Systemzugriff), mit entsprechend skalierten Bewertungsanforderungen und Überprüfungshäufigkeiten.

Was ist der häufigste Zugangskontrollfehler bei Drittanbieter-Sicherheitsverletzungen?

Gemeinsam genutzte Anmeldedaten ohne individuelle Verantwortlichkeit. Ein einzelner Satz Anmeldedaten, der einem Anbieterteam ausgestellt, außerhalb eines Vaults gespeichert, nie rotiert und nie widerrufen wird, wenn der Auftrag endet. Verizons 2026 DBIR identifiziert Authentifizierungsfehler als den primären Mechanismus bei Drittanbieter-Sicherheitsverletzungsszenarien. Die Lösung sind einzelne benannte Konten, Credential-Vaulting und ein dokumentierter Offboarding-Prozess — nicht komplexere Technologie.

Was ist Hardware-Lieferkettenrisiko und wie unterscheidet es sich vom Software-Lieferkettenrisiko?

Hardware-Lieferkettenrisiko umfasst gefälschte oder manipulierte physische Komponenten — Netzwerkausrüstung, Server-Hardware, Firmware — die persistente Hintertüren einführen können, die für Software-Layer-Sicherheitskontrollen unsichtbar sind. Im Gegensatz zu Software-Schwachstellen überlebt Hardware-Manipulation eine Betriebssystem-Neuinstallation. Der EU Cyber Resilience Act adressiert dies direkt und verlangt von Herstellern, die Lieferkettensicherheit für Hardwareprodukte mit digitalen Elementen zu dokumentieren.

Einblick in reale Lieferkettenangriffe: Bitwarden CLI, Axios und Vercel

Warum Ihr Netzwerk kompromittieren, wenn Angreifer eine vertrauenswürdige Abhängigkeit mit Millionen von Downloads kompromittieren und sich lautlos in Tausende von Organisationen gleichzeitig einschleichen können? Drei Kampagnen aus 2026 beweisen, dass Lieferkettenangriffe keine Einzelfälle mehr sind.

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. Hier erfahren Sie, wie das Risiko tatsächlich aussieht und was die Governance adressieren muss.

Passwork BlogAlex Muntyan

NIS2-Zugriffskontrollen für Lieferkettensicherheit

48 % der Sicherheitsverletzungen betreffen jetzt Dritte. NIS2 Artikel 21 macht die Lieferanten-Zugriffs-Governance zur gesetzlichen Pflicht. Hier erfahren Sie, wie Sie den Anbieterzugriff kartieren, MFA und Least Privilege durchsetzen und die Audit-Nachweise aufbewahren, die beweisen, dass Ihre Kontrollen funktionieren.

Passwork BlogAlex Muntyan

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

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

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

Puntos clave

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

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

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

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

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

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

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

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

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

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

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

Lecciones de SolarWinds, MOVEit y XZ Utils

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

SolarWinds (2020)

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

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

MOVEit (2023)

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

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

XZ Utils (2024)

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

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

Principales riesgos de proveedores en la cadena de suministro moderna

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

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

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

Credenciales compartidas y control de acceso deficiente

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

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

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

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

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

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

Manipulación de hardware y componentes

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

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

Shadow AI y exposición de datos de terceros

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

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

Interrupciones de disponibilidad y riesgo de concentración de proveedores

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

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

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

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

Directiva NIS2 (Artículo 21)

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

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

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

DORA (Ley de Resiliencia Operativa Digital)

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

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

Ley de Ciberresiliencia de la UE (CRA)

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

NIST CSF 2.0 y NIST SP 800-161

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

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

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

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

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

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

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

Implemente acceso privilegiado justo a tiempo (JIT)

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

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

Almacenamiento seguro de credenciales de proveedores en bóveda

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

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

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

Exija MFA resistente al phishing para terceros

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

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

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

Construyendo un marco de evaluación de riesgos de proveedores

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

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

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

Lista de verificación de control de acceso de proveedores

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

Antes del aprovisionamiento de acceso:

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

Durante el compromiso:

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

Revocación de acceso:

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

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

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

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

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

Preguntas frecuentes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

Controles de acceso NIS2 para seguridad de la cadena de suministro

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

Passwork BlogAlex Muntyan

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

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

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

Key takeaways

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

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

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

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

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

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

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

The state of supply chain attacks in 2025–2026

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

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

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

Lessons from SolarWinds, MOVEit, and XZ Utils

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

SolarWinds (2020)

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

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

MOVEit (2023)

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

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

XZ Utils (2024)

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

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

Top vendor risks in the modern supply chain

The five most common supply chain risk categories are:

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

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

Shared credentials and poor access control

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

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

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

Software supply chain vulnerabilities and the need for SBOMs

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

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

Hardware and component tampering

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

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

Shadow AI and third-party data exposure

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

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

Availability disruptions and vendor concentration risk

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

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

European and international regulatory requirements for supply chain security

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

NIS2 Directive (Article 21)

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

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

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

DORA (Digital Operational Resilience Act)

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

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

EU Cyber Resilience Act (CRA)

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

NIST CSF 2.0 and NIST SP 800-161

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

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

How to secure vendor access: The technical blueprint

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

Enforce strict role-based access control (RBAC)

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

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

Implement just-in-time (JIT) privileged access

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

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

Secure vendor credential vaulting

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

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

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

Mandate phishing-resistant MFA for third parties

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

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

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

Building a vendor risk assessment framework

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

The 5-tier vendor risk classification model:

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

Vendor access control checklist

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

Pre-access provisioning:

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

During the engagement:

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

Access revocation:

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

Conclusion: Making supply chain security operational

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

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

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

Frequently asked questions

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

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

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

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

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

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

How do SBOMs reduce supply chain risk?

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

What should a vendor security contract addendum include?

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

How should organizations classify vendors for risk assessment purposes?

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

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

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

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

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

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

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

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

NIS2 access controls for supply chain security

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

Passwork BlogAlex Muntyan

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

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

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

Was ist Shadow AI?

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

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

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

Shadow IT vs. Shadow AI: Den Risikomultiplikator verstehen

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

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

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

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

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

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

Zwei zugrunde liegende Statistiken erklären den Mechanismus:

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

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

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

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

Die versteckte Bedrohung: Credential-Exposition und KI-Agenten

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

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

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

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

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

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

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

Reale Datenpannen im Zusammenhang mit Shadow AI

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

Microsoft AI Research: 38 TB interner Daten exponiert

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

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

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

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

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

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

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

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

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

Microsoft 365 Copilot: EchoLeak, Zero-Click-Datenexfiltration

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

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

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

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

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

Shadow AI im Unternehmen erkennen und verhindern

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

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

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

Wie Passwork die Grundlage gegen Shadow-AI-Risiken sichert

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

Das Kernprinzip: Klartext aus der Gleichung entfernen

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

Was Passwork bietet

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

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

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

Self-Hosted vs. Cloud

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

Wie Passwork Shadow-AI-Risiken adressiert

Fazit

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

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

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

FAQ: Shadow AI im Unternehmen

Wie erkennt man Shadow AI?

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

Was ist ein Beispiel für Shadow AI?

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

Warum ist Shadow AI gefährlicher als Shadow IT?

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

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

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

Verhindert das Verbot von KI-Tools Shadow AI?

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

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

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

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

Mitarbeiter-Offboarding: Leitfaden zur sicheren Zugriffsentziehung 2026

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

Passwork BlogAlex Muntyan

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

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

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

¿Qué es Shadow AI?

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

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

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

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

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

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

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

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

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

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

Dos estadísticas subyacentes explican el mecanismo:

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

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

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

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

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

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

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

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

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

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

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

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

Brechas reales vinculadas a Shadow AI

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

Microsoft AI Research: 38 TB de datos internos expuestos

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cómo detectar y prevenir Shadow AI en la empresa

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

El marco de gobernanza de Shadow AI en 5 pasos

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

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

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

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

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

Qué ofrece Passwork

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

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

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

Autoalojado vs. nube

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

Cómo Passwork aborda los riesgos de Shadow AI

Conclusión

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

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

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

Preguntas frecuentes: Shadow AI en la empresa

¿Cómo se detecta Shadow AI?

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

¿Cuál es un ejemplo de Shadow AI?

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

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

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

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

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

¿Prohibir las herramientas de IA previene Shadow AI?

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

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

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

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

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

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

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

What is Shadow AI?

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

The scope is wider than most security teams assume.

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

Shadow IT vs. Shadow AI: Understanding the risk multiplier

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

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

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

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

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

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

Two underlying statistics explain the mechanism:

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

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

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

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

The hidden threat: Credential exposure and AI agents

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

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

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

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

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

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

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

Real breaches tied to Shadow AI

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

Microsoft AI Research: 38 TB of internal data exposed

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

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

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

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

Slack AI: Data exfiltration from private channels via prompt injection

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

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

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

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

Microsoft 365 Copilot: EchoLeak, zero-click data exfiltration

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

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

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

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

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

How to detect and prevent Shadow AI in the enterprise

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

The 5-step Shadow AI governance framework

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

How Passwork secures the foundation against Shadow AI risks

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

The core principle: remove plaintext from the equation

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

What Passwork provides

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

Four controls matter most in the shadow AI context:

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

Self-hosted vs. cloud

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

How Passwork addresses Shadow AI risks

Conclusion

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

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

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

FAQ: Shadow AI in the enterprise

How do you detect Shadow AI?

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

What is an example of Shadow AI?

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

Why is Shadow AI more dangerous than Shadow IT?

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

What credentials are most at risk from Shadow AI?

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

Does banning AI tools prevent Shadow AI?

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

Password management for teams: The fix every SMB needs

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

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

Employee offboarding: Secure access revocation guide 2026

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

Passwork BlogAlex Muntyan

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

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

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

Fehler 1: Der ungesicherte Heimrouter (Standard-Zugangsdaten)

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

Warum das passiert

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

Die Lösung

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

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

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

Warum das passiert

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

Die Lösung

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

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

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

Warum das passiert

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

Die Lösung

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

Fehler 4: Bildschirmfreigabe und Benachrichtigungslecks

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

Warum das passiert

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

Die Lösung

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

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

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

Warum das passiert

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

Die Lösung

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

Fehler 6: Verbindung mit öffentlichem WLAN ohne VPN

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

Warum das passiert

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

Die Lösung

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

Fehler 7: Ignorieren von Software-Updates und Patching

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

Warum das passiert

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

Die Lösung

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

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

Fehler 8: Auf Phishing und Social Engineering hereinfallen

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

Warum das passiert

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

Die Lösung

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

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

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

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

Warum das passiert

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

Die Lösung

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

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

Fehler 10: Unverschlüsselter lokaler Speicher und Backups

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

Warum das passiert

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

Die Lösung

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

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

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

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

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

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

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

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

Fazit

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

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

Häufig gestellte Fragen zur Remote-Arbeit-Sicherheit

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

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

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

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

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

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

Verhindert MFA tatsächlich Sicherheitsverletzungen in Remote-Arbeitsumgebungen?

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

Wie sollten Remote-Teams Passwörter sicher teilen?

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

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

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

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

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

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

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

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

Unsichere Passwortweitergabe: Risiken 2026 und sichere Lösungen

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

Passwork BlogAlex Muntyan

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

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

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

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

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

Por qué ocurre

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

La solución

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

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

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

Por qué ocurre

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

La solución

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

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

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

Por qué ocurre

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

La solución

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

Error 4: Fugas por compartir pantalla y notificaciones

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

Por qué ocurre

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

La solución

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

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

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

Por qué ocurre

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

La solución

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

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

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

Por qué ocurre

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

La solución

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

Error 7: Ignorar las actualizaciones de software y el parcheo

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

Por qué ocurre

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

La solución

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

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

Error 8: Caer en phishing e ingeniería social

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

Por qué ocurre

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

La solución

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

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

Error 9: Shadow IT y herramientas cloud no autorizadas

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

Por qué ocurre

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

La solución

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

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

Error 10: Almacenamiento local y copias de seguridad sin cifrar

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

Por qué ocurre

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

La solución

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

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

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

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

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

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

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

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

Conclusión

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

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

Preguntas frecuentes sobre seguridad en el trabajo remoto

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

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

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

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

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

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

¿MFA realmente previene brechas en entornos de trabajo remoto?

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

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

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

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

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

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

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

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

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

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

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

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

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

Fail 1: The unsecured home router (default credentials)

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

Why it happens

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

The fix

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

Fail 2: Insecure password sharing via chat and email

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

Why it happens

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

The fix

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

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

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

Why it happens

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

The fix

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

Fail 4: Screen sharing and notification leaks

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

Why it happens

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

The fix

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

Fail 5: Neglecting multi-factor authentication (MFA)

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

Why it happens

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

The fix

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

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

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

Why it happens

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

The fix

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

Fail 7: Ignoring software updates and patching

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

Why it happens

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

The fix

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

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

Fail 8: Falling for phishing and social engineering

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

Why it happens

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

The fix

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

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

Fail 9: Shadow IT and unsanctioned cloud tools

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

Why it happens

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

The fix

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

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

Fail 10: Unencrypted local storage and backups

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

Why it happens

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

The fix

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

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

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

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

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

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

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

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

Conclusion

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

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

Frequently asked questions about remote work security

What are the most common remote work security fails?

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

How do I secure my home network for remote work?

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

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

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

Does MFA actually prevent breaches in remote work environments?

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

How should remote teams handle password sharing securely?

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

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

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

What does "frictionless security" mean for remote teams?

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

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

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

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

Insecure password sharing: 2026 risks and secure solutions

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

Passwork BlogAlex Muntyan

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

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

Die wichtigsten Erkenntnisse

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

Die verborgenen Risiken verzögerter Zugriffsentziehung

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

Compliance-Fristen werden strenger

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

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

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

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

Datenexfiltration und Insider-Bedrohungen

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

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

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

Offboarding-Blindspots 2026: KI-Agenten und NHIs

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

Das Problem mit KI-Agenten-Zugriff

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

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

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

Verwaiste Non-Human Identities (NHIs)

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

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

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

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

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

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

Wie man geteilte Passwörter beim Offboarding behandelt

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

Die Gefahr geteilter Anmeldedaten

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

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

Enterprise-Passwortmanagement für geteilte Tresor-Kontrolle

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

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

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

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

Die Checkliste für sichere Zugriffsentziehung 2026

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

Phase 1: Discovery vor dem Austritt

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

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

Phase 2: Trigger zum Zeitpunkt null (sofortige Aktionen)

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

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

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

Phase 3: Tiefenreinigung (innerhalb von 24 Stunden)

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

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

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

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

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

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

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

Prioritätsmatrix für Zugriffsentziehung

Automatisierung des Offboarding-Workflows

HRIS-zu-IAM-Integration

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

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

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

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

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

Fazit

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

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

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

Häufig gestellte Fragen zu Mitarbeiter-Offboarding und Zugriffsentziehung

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

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

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

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

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

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

Was ist das Problem mit KI-Agenten beim Offboarding?

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

Entzieht das Deaktivieren eines SSO-Kontos allen Anwendungszugriff?

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

Was sollte eine IT-Offboarding-Checkliste 2026 enthalten?

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

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

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

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

Passwork gewinnt Top Performer Frühjahr 2026 auf SourceForge

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

Passwork BlogAlex Muntyan

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

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

Puntos clave

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

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

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

Los plazos de cumplimiento se están ajustando

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

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

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

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

Exfiltración de datos y amenazas internas

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

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

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

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

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

El problema del acceso de agentes de IA

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

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

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

Identidades no humanas (NHIs) huérfanas

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

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

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

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

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

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

Cómo manejar contraseñas compartidas durante el offboarding

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

El peligro de las credenciales compartidas

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

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

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

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

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

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

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

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

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

Fase 1: Descubrimiento previo a la salida

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

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

Fase 2: Activador de hora cero (acciones inmediatas)

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

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

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

Fase 3: Limpieza profunda (dentro de 24 horas)

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

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

Fase 4: Recuperación y borrado del dispositivo

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

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

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

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

Matriz de prioridad de revocación de acceso

Automatización del flujo de trabajo de offboarding

Integración de HRIS a IAM

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

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

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

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

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

Conclusión

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

Passwork gana Top Performer Primavera 2026 en SourceForge

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

Passwork BlogAlex Muntyan

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

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

Key takeaways

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

The hidden risks of delayed access revocation

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

Compliance timelines are tightening

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

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

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

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

Data exfiltration and insider threats

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

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

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

2026 offboarding blind spots: AI agents and NHIs

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

The AI agent access problem

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

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

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

Orphaned non-human identities (NHIs)

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

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

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

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

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

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

How to handle shared passwords during offboarding

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

The danger of shared credentials

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

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

Enterprise password management for shared vault control

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

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

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

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

The 2026 secure access revocation checklist

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

Phase 1: Pre-departure discovery

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

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

Phase 2: Zero-hour trigger (immediate actions)

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

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

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

Phase 3: Deep clean (within 24 hours)

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

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

Phase 4: Device retrieval and wipe

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

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

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

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

Access revocation priority matrix

Automating the offboarding workflow

HRIS to IAM integration

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

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

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

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

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

Conclusion

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

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

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

Frequently asked questions about employee offboarding and access revocation

What is the biggest security risk when offboarding an employee?

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

How quickly should access be revoked when an employee leaves?

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

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

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

What is the AI agent offboarding problem?

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

Does disabling an SSO account revoke all application access?

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

What should an IT offboarding checklist include in 2026?

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

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

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

Passwork BlogAlex Muntyan

Insecure password sharing: 2026 risks and secure solutions

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

Passwork BlogAlex Muntyan

Passwork wins Top Performer Spring 2026 on SourceForge

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

Passwork BlogAlex Muntyan

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

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

Puntos clave

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

La implementación práctica requiere cuatro cosas:

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

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

Abordando sistemas heredados y shadow IT

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

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

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

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

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

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

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

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

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

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

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

Puntos clave para CISOs y líderes de TI

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

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

Conclusión

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

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

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

Preguntas frecuentes

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

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

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

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

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

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

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

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

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

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

¿Cuánto tiempo suele tardar en detectarse una brecha basada en credenciales?

Según el Informe sobre el Costo de una Brecha de Datos 2025 de IBM, las brechas que involucran credenciales comprometidas tardan un promedio de 246 días en identificarse y contenerse. Las cuentas compartidas lo empeoran: sin líneas base de comportamiento individual, la actividad anómala se mezcla con el tráfico normal de múltiples usuarios y rara vez activa alertas.

Shadow IT vs Shadow AI: Por qué la IA es la mayor amenaza

Los empleados están usando herramientas de IA que usted no aprobó, en cuentas que no puede monitorear, con datos que no puede recuperar. Así es como realmente se ve el riesgo y qué necesita abordar la gobernanza.

Passwork BlogAlex Muntyan

Ataques de fuerza bruta en 2026: Tipos, ejemplos y cómo prevenirlos

Clústeres de GPU, listas de palabras asistidas por IA, botnets de 2.8M de dispositivos. La fuerza bruta ha escalado. Esta guía cubre seis variantes de ataque, casos reales de 2025 y una estrategia de defensa en capas que su equipo puede implementar hoy.

Passwork BlogAlex Muntyan

Passwork gana Top Performer Primavera 2026 en SourceForge

Passwork ha sido nombrado Top Performer Primavera 2026 por SourceForge, ubicándose en el 10% superior de más de 100,000 soluciones. La insignia se basa completamente en reseñas verificadas — 4.8 estrellas en general, con un perfecto 5.0 en soporte.

Passwork BlogAlex Muntyan

Anmeldedaten werden täglich zwischen Personen weitergegeben. Ein Entwickler erhält eine Datenbank-Zugangsberechtigung über Slack. Ein Auftragnehmer bekommt ein Admin-Konto per E-Mail. Die Finanzabteilung speichert das Login für das Gehaltsabrechnungssystem in einer gemeinsamen Tabelle. Jede Weitergabe ist ein Sicherheitsvorfall, der nur darauf wartet, zu passieren. Im Jahr 2026 hat dieses Warten einen messbaren Wert — oft in Minuten gezählt.

Dieser Artikel zeigt genau, was 2026 auf dem Spiel steht, warum Mitarbeiter es trotzdem weiter tun, und wie das Problem gelöst werden kann, ohne dass sich Sicherheit wie eine Strafe anfühlt.

Wichtige Erkenntnisse

• Geteilte Anmeldedaten sind ein Problem der Zugriffsverwaltung, kein Problem des Benutzerverhaltens. Richtlinien, die darauf setzen, dass Mitarbeiter das Richtige tun, scheitern im großen Maßstab. Eine Architektur, die das Richtige zum Einfachsten macht, scheitert nicht.
• Tresor-vermittelter Zugriff eliminiert die direkte Weitergabe von Anmeldedaten. Benutzer greifen über den Tresor auf Systeme zu. Sie sehen das Passwort nie. Jede Aktion wird protokolliert und einer individuellen Identität zugeordnet.
• RBAC auf Gruppenebene ist das einzige Modell, das skaliert. Die Verwaltung von Berechtigungen pro Person bricht bei mehr als einem Dutzend Personen zusammen. Gruppenbasierte Vererbung bedeutet, dass eine Änderung alle im Team abdeckt.
• MFA bei privilegierten Konten begrenzt den Schadensradius bei kompromittierten Anmeldedaten. Die Kompromittierung von Anmeldedaten ist keine Frage des Ob, sondern des Wann. Ein zweiter Faktor bedeutet, dass ein gestohlenes Passwort allein nicht ausreicht.
• Audit-Trails müssen vor dem Vorfall existieren, nicht danach. Incident Response ohne Protokolle ist Rekonstruktion aus dem Gedächtnis. Der Trail muss jetzt aufgebaut werden.
• Legacy-Systeme sind eine Einschränkung, keine Ausrede. Ein Service-Konto, das in einem Tresor mit vermitteltem Zugriff gespeichert ist, ist nicht perfekt, aber es ist dokumentiert, überprüfbar und widerrufbar.
• Shadow IT ist ein Friktionssignal. Wenn Mitarbeiter persönliche Tools für Arbeits-Anmeldedaten verwenden, ist der Unternehmens-Tresor schwieriger zu nutzen, als er sein sollte. Das Onboarding muss verbessert werden, nicht die Richtlinie.
• Offboarding auf Verzeichnisebene automatisieren. Jeder Tag, an dem ein ehemaliger Mitarbeiter Zugriff behält, ist eine offene Haftung. AD/LDAP-Integration schließt sie ohne manuelle Eingriffe.

Die Gefahren unsicherer Passwortweitergabe im Jahr 2026

Unsichere Passwortweitergabe setzt Organisationen Credential Stuffing, Account Takeover (ATO) und Insider-Bedrohungen aus — all dies ist mit der Reifung KI-gestützter Angriffswerkzeuge deutlich einfacher geworden. Das Kernproblem ist, dass geteilte Anmeldedaten die individuelle Verantwortlichkeit zerstören: Wenn fünf Personen dasselbe Login verwenden, zeigt kein Audit-Trail, welche Person den Sicherheitsvorfall verursacht hat.

Die Bedrohungslandschaft hat sich mit dem Fortschritt von GPU-Hardware und Cracking-Tools wesentlich verändert. Die Passwort-Tabelle von Hive Systems für 2025 zeigt, dass kurze Passwörter unabhängig von ihrer Komplexität gefährlich exponiert bleiben. NIST SP 800-63B (aktualisiert im August 2025) spiegelt dieselbe Realität wider: Die Richtlinien setzen nun eine Mindestgrenze von 15 Zeichen fest und verzichten ausdrücklich auf obligatorische Komplexitätsregeln zugunsten der Länge. Dies erkennt an, dass Brute-Force-Resistenz exponentiell mit der Länge skaliert, nicht mit Zeichenersetzungen.

Zeit, die ein Hacker benötigt, um Ihr Passwort 2025 per Brute-Force zu knacken

Credential Stuffing hat mit diesen Werkzeugen skaliert. Angreifer speisen geleakte Anmeldedaten-Datenbanken — Milliarden von Benutzername/Passwort-Paaren sind auf Dark-Web-Märkten verfügbar — in automatisierte Tools ein, die sie gleichzeitig bei Hunderten von Diensten testen. Geteilte Passwörter verstärken den Schadensradius: Ein geleaktes Anmeldedatum kann jedes System kompromittieren, bei dem dieses Passwort wiederverwendet wurde.

Brute-Force-Angriffe haben ebenfalls von KI profitiert. Moderne Cracking-Algorithmen nutzen neuronale Netzwerke, um menschliche Ersetzungsmuster zu modellieren. Das Ersetzen von a durch @ oder das Anhängen von ! an ein Wörterbuchwort bietet keinen nennenswerten Widerstand mehr. Das Modell des Angreifers berücksichtigt dies bereits.

Insider-Bedrohungen sind das weniger diskutierte Risiko. Wenn Anmeldedaten informell geteilt werden (über Chat, E-Mail oder mündlich), gibt es keine Aufzeichnung darüber, wer sie zu einem bestimmten Zeitpunkt besitzt. Ein verärgerter Mitarbeiter, ein Auftragnehmer, dessen Engagement beendet wurde, oder ein ehemaliger Kollege, dessen Offboarding nie ordnungsgemäß durchgeführt wurde, kann auf unbestimmte Zeit Zugriff behalten. Ohne individuelle Konten und Audit-Trails kann der Zugriff weder erkannt noch zugeordnet werden.

Wie unsichere Weitergabe auf spezifische Angriffsvektoren abbildet

Jenseits der Bequemlichkeit: Warum Mitarbeiter immer noch Passwörter teilen (und die tatsächlichen Kosten)

Mitarbeiter teilen Arbeitspasswörter aus denselben banalen Gründen wie immer: Notfälle, gemeinsam genutzte Team-Konten, delegierte Aufgaben. Das Teilen ist die rationale Reaktion, wenn der sichere Weg langsamer ist als die Aufgabe selbst. Wenn der formale Zugriffsanfrageprozess länger dauert, überspringen ihn die Leute.

Diese Friktion hat einen Namen. Eine 2025 peer-reviewed veröffentlichte Studie „Digital detox: Exploring the impact of cybersecurity fatigue on employee productivity and mental health", publiziert in Discover Mental Health (PMC/PubMed), befragte 351 Mitarbeiter aus IT, Finanzen, Gesundheitswesen und Bildung und stellte fest, dass Cybersicherheits-Müdigkeit (definiert als mentale und emotionale Erschöpfung durch wiederholte Sicherheitsanforderungen) direkt zu Desengagement, reduzierter Compliance und Burnout beiträgt.

Cybersicherheits-Müdigkeit — ein Zustand mentaler und emotionaler Erschöpfung durch wiederholte Exposition gegenüber Sicherheitsanforderungen — manifestiert sich durch kognitive Überlastung, Stress und Desengagement und beeinflusst erheblich die Mitarbeiterproduktivität und organisatorische Resilienz.

Wenn sich obligatorische Rotationszyklen, Authentifizierungsaufforderungen und Zugriffsanfrage-Warteschlangen häufen, fühlt sich Sicherheit nicht mehr wie Schutz an und beginnt sich wie Friktion anzufühlen. Der Workaround wird offensichtlich: die Anmeldedaten direkt teilen und die Arbeit erledigen.

Dies ist ein Designfehler, kein Disziplinproblem. Die Forschung von Proofpoint zu menschenzentrierten Bedrohungen zeigt durchgängig, dass Mitarbeiter Kontrollen umgehen, weil der sichere Weg länger dauert als der unsichere. Die Anmeldedaten werden geteilt, die Aufgabe wird erledigt, und niemand denkt viel darüber nach.

Bis etwas schiefgeht. Der DBIR 2025 von Verizon stellte fest, dass Anmeldedaten branchenübergreifend einer der am häufigsten ausgenutzten Einstiegspunkte bleiben. Der Cost of a Data Breach Report 2025 von IBM beziffert, was das in der Praxis bedeutet: Sicherheitsvorfälle mit kompromittierten Anmeldedaten benötigen durchschnittlich 246 Tage zur Identifizierung und Eindämmung — über acht Monate unentdeckter Exposition — und verursachen durchschnittliche Gesamtkosten von 4,57 Mio. USD.

Die Verantwortlichkeitslücke ist das, was die Wiederherstellung so schwierig macht. Sobald Anmeldedaten geteilt werden, verliert man die Möglichkeit, Aktionen Einzelpersonen zuzuordnen. Das ist wichtig für Incident Response, für Compliance-Audits und für die grundlegende Frage „Wer hat diese Konfiguration am Samstag um 2 Uhr morgens geändert?" Geteilte Anmeldedaten schaffen nicht nur Risiken — sie zerstören den Audit-Trail, der benötigt wird, um im Nachhinein zu verstehen, was passiert ist.

Der Dominoeffekt: Geschäftliche Auswirkungen unsicherer Anmeldedaten-Weitergabe

Unsichere Anmeldedaten-Weitergabe schafft finanzielle, rechtliche und reputationsbezogene Risiken, die weit über den ursprünglichen Sicherheitsvorfall hinausgehen. Die Kompromittierung von Anmeldedaten ist branchenübergreifend der dominierende Angriffsvektor. Der Sicherheitsvorfall selbst ist selten der teuerste Teil. Incident Response, regulatorische Prüfungen und die Audit-Trail-Lücken, die von geteilten Konten hinterlassen werden, verstärken den Schaden lange nach dem ursprünglichen Eindringen.

Die Compliance-Dimension ist spezifisch und folgenreich. DSGVO Artikel 32 verlangt „geeignete technische und organisatorische Maßnahmen" zum Schutz personenbezogener Daten — und geteilte Anmeldedaten ohne Audit-Trail erfüllen diesen Standard direkt nicht. SOC 2 Trust Services Criteria CC6.1 erfordert logische Zugriffskontrollen, die an individuelle Identitäten gebunden sind. Die Technical Safeguard-Anforderungen von HIPAA gemäß 45 CFR §164.312(a)(2)(i) verlangen eine eindeutige Benutzeridentifikation. Das Teilen eines einzelnen Logins im Team verstößt gleichzeitig gegen alle drei Frameworks.

Reputationsschäden folgen einem anderen Zeitplan als finanzielle Schäden. Die Kosten des Sicherheitsvorfalls sind unmittelbar. Die Reputationskosten kumulieren sich. Kunden, Partner und Regulierungsbehörden berücksichtigen alle die Historie von Sicherheitsvorfällen in ihren Risikobewertungen. Ein anmeldedatenbasierter Sicherheitsvorfall, der mit grundlegender Zugriffsverwaltung hätte verhindert werden können, ist besonders schwer gegenüber einem Vorstand oder einer Regulierungsbehörde zu erklären.

Das Offboarding-Szenario veranschaulicht das Risiko konkret. Ein Mitarbeiter verlässt das Unternehmen mit Zugriff auf fünf geteilte Konten. Da Anmeldedaten nie formell zugewiesen wurden, weiß niemand, welche Systeme er erreichen konnte. Das Widerrufen des Zugriffs bedeutet:

1. Identifizieren jedes geteilten Passworts, das der Mitarbeiter kannte
2. Finden jedes Systems, bei dem dieses Passwort verwendet wurde
3. Benachrichtigen jedes Teams, das von diesen Anmeldedaten abhängt
4. Rotieren aller Anmeldedaten, ohne etwas in der Produktion zu beschädigen

In der Praxis überspringen viele Organisationen dies vollständig. So behalten ehemalige Mitarbeiter monatelang aktiven Zugriff.

Implementierung reibungsloser Governance: Lösungen für sichere Passwortweitergabe

Reibungslose Governance ist ein Anmeldedaten-Management-Modell, das unsichere Weitergabe eliminiert, indem sicherer Zugriff schneller als der Workaround gemacht wird. Es basiert auf drei Komponenten: individuelle Verantwortlichkeit (jeder Benutzer hat seine eigene Identität), RBAC (Berechtigungen werden Rollen zugewiesen, nicht Einzelpersonen) und Audit-Logging (jedes Zugriffsereignis wird aufgezeichnet und ist zuordenbar).

Die praktische Implementierung erfordert vier Dinge:

1. Einen Passwort-Tresor mit rollenbasierter Zugriffskontrolle. Benutzer greifen über den Tresor auf Anmeldedaten zu, nicht durch direkten Erhalt des Passworts. RBAC (rollenbasierte Zugriffskontrolle) bedeutet, dass Berechtigungen von der Gruppenmitgliedschaft geerbt werden — fügen Sie jemanden zur DevOps-Gruppe hinzu, erhält er DevOps-Tresor-Zugriff. Entfernen Sie ihn, wird der Zugriff sofort widerrufen.
2. Ende-zu-Ende-Verschlüsselung mit einer Zero-Knowledge-Architektur. Anmeldedaten werden clientseitig verschlüsselt, bevor sie das Gerät des Benutzers verlassen. Der Server speichert Chiffretext. Selbst ein kompromittierter Server exponiert nichts Verwertbares. AES-256 ist hierfür der aktuelle Standard.
3. MFA auf jedem Konto. Multi-Faktor-Authentifizierung (MFA) verhindert nicht die Weitergabe von Anmeldedaten, begrenzt aber den Schaden, wenn ein geteiltes Anmeldedatum kompromittiert wird. Ein Angreifer mit einem gestohlenen Passwort benötigt immer noch den zweiten Faktor. Für privilegierte Konten sind Hardware-Token oder FIDO2-Schlüssel vorzuziehen.
4. Passphrasen statt komplexer kurzer Passwörter. Eine 16-Zeichen-Passphrase — vier zufällige Wörter — ist sowohl resistenter gegen Brute-Force-Angriffe als auch einfacher für Benutzer zu merken als P@ssw0rd!2. Länge bietet exponentiellen Widerstand; Komplexität bietet linearen Widerstand.

Identity and Access Management (IAM)-Integration erweitert dieses Modell auf Verzeichnisebene. Wenn Passwork mit AD/LDAP verbunden ist, erfolgen Benutzerbereitstellung und -deaktivierung automatisch. Ein in Active Directory deaktivierter Benutzer verliert den Tresor-Zugriff ohne manuelle Eingriffe. Das ist das Offboarding-Problem, gelöst auf Infrastrukturebene.

Umgang mit Legacy-Systemen und Shadow IT

Legacy-Systeme sind der häufigste Grund, warum Teams geteilte Anmeldedaten rechtfertigen. Ein 2008 entwickeltes System hat möglicherweise kein Konzept für individuelle Benutzerkonten — es hat ein Admin-Login, und jeder, der Zugriff benötigt, nutzt es. Dies ist eine echte Einschränkung, kein Richtlinienversagen.

Die praktische Lösung ist ein Service-Account-Muster mit Tresor-vermitteltem Zugriff. Das geteilte Anmeldedatum befindet sich im Tresor, verschlüsselt. Benutzer greifen über das Session-Management des Tresors auf das System zu — sie sehen nie das rohe Passwort. Der Zugriff wird auf Tresor-Ebene protokolliert, auch wenn das Zielsystem keine native Audit-Fähigkeit hat. Wenn jemand das Unternehmen verlässt, wird das Anmeldedatum im Tresor rotiert. Das System selbst muss sich nicht ändern.

Einmal-Secrets und sichere Links adressieren das angrenzende Problem: Gelegentlich müssen Anmeldedaten wirklich an jemanden außerhalb Ihres Tresors übermittelt werden. Ein Einmal-Secret-Link läuft nach einer einzelnen Ansicht oder nach einem definierten Zeitfenster ab. Es ist keine dauerhafte Lösung, aber kategorisch sicherer als eine Slack-Nachricht, die auf unbestimmte Zeit im Chat-Verlauf verbleibt.

Shadow IT — Mitarbeiter, die persönliche Passwort-Manager für Arbeitspasswörter verwenden — ist schwieriger zu erkennen und birgt eigene Risiken. Ein persönlicher Tresor hat keinen organisatorischen Audit-Trail, keinen Offboarding-Hook und keine Garantie für Verschlüsselungsstandards. Die Lösung ist organisatorisch: Den Unternehmens-Tresor einfacher nutzbar machen als den persönlichen. Wenn das Onboarding fünf Minuten dauert und die Browser-Erweiterung Anmeldedaten automatisch ausfüllt, werden die meisten Mitarbeiter ihn nutzen. Friktion ist der Feind der Akzeptanz.

Wie Passwork sichere Weitergabe zum Standard macht

Die oben beschriebenen Probleme (geteilte Anmeldedaten, fehlerhaftes Offboarding, fehlende Audit-Trails, Legacy-System-Einschränkungen) sind genau das, wofür Passwork entwickelt wurde. Hier ist, wie jedes Problem einer spezifischen Fähigkeit zugeordnet wird.

• Geteilte Anmeldedaten ohne Verantwortlichkeit. Passwork ersetzt die direkte Passwortweitergabe durch Tresor-vermittelten Zugriff. Benutzer interagieren mit Systemen über den Tresor. Sie erhalten nie das rohe Anmeldedatum. Jedes Zugriffsereignis wird protokolliert, mit Zeitstempel versehen und einer individuellen Identität zugeordnet.
• Fehlerhaftes Offboarding. Passwork integriert sich mit AD/LDAP. Wenn ein Benutzer in Active Directory deaktiviert wird, wird der Tresor-Zugriff automatisch widerrufen. Keine manuelle Rotation, kein Rätselraten darüber, welche Konten er erreichen konnte.
• Kein Audit-Trail. Jede Aktion in Passwork wird aufgezeichnet. Wenn ein Vorfall auftritt, haben Sie ein vollständiges, zuordenbares Protokoll. Nicht „jemand im DevOps-Team", sondern ein spezifischer Benutzer zu einem bestimmten Zeitpunkt.
• Legacy-Systeme mit geteilten Logins. Passwork unterstützt ein Service-Account-Muster: Das Anmeldedatum befindet sich im Tresor, verschlüsselt. Benutzer greifen über Tresor-vermittelte Sitzungen auf das System zu und sehen nie das Passwort. Das Zielsystem muss sich nicht ändern.
• Gelegentliche externe Weitergabe. Für Anmeldedaten, die wirklich den Tresor verlassen müssen — ein Auftragnehmer, eine einmalige Übergabe — generiert Passwork Einmal-Secret-Links, die nach einer einzelnen Ansicht oder einem definierten Zeitfenster ablaufen. Sicherer als eine Slack-Nachricht — by Design.
• Compliance-Lücken. Rollenbasierte Zugriffskontrolle, individuelle Identitätsbindung und ein vollständiges Audit-Log unterstützen direkt die Anforderungen von DSGVO Artikel 32, SOC 2 CC6.1 und HIPAA §164.312. Der Audit-Trail, den Sie für eine Regulierungsbehörde benötigen, ist derselbe, den Sie für Incident Response benötigen.

Von unsicherer zu sicherer Weitergabe: Eine praktische 6-Schritte-Migration

Die meisten Teams scheitern, weil der Übergang von informeller Weitergabe zu strukturiertem Zugriff wie ein Projekt wirkt, für das niemand Zeit hat. Dieser Leitfaden unterteilt ihn in sechs Schritte, die inkrementell ausgeführt werden können und die Exposition in jeder Phase reduzieren, ohne den Betrieb zu stören.

1. Auditieren, was tatsächlich geteilt wird. Bevor das Problem behoben werden kann, muss sein Umfang bekannt sein. Befragen Sie Ihre Teams und dokumentieren Sie jedes geteilte Anmeldedatum: auf welches System es zugreift, wer es besitzt und wie es verteilt wurde. Tabellen, Slack-Verlauf und E-Mail-Threads sind die häufigsten Quellen. Überspringen Sie diesen Schritt nicht. Zugriff, der nicht bekannt ist, kann nicht widerrufen werden.
2. Nach Risiko klassifizieren. Nicht alle geteilten Anmeldedaten bergen das gleiche Risiko. Priorisieren Sie nach Schadensradius: Produktionsdatenbank-Anmeldedaten und Admin-Konten zuerst, interne Tooling-Anmeldedaten als zweites, wenig sensitive geteilte Konten zuletzt. Dies ergibt eine Migrationssequenz, die die Exposition schnell reduziert, ohne alles auf einmal verschieben zu müssen.
3. Den Tresor bereitstellen und Ihr Team onboarden. Richten Sie Passwork ein und verbinden Sie es mit Ihrem Verzeichnisdienst (AD/LDAP). Erstellen Sie rollenbasierte Gruppen, die Ihre bestehende Teamstruktur widerspiegeln. Das Onboarding funktioniert am besten, wenn der Tresor bereits befüllt ist, bevor Sie die Leute bitten, ihn zu nutzen. Importieren Sie bestehende Anmeldedaten in die entsprechenden Tresore vor dem Rollout-Meeting.
4. Anmeldedaten in Prioritätsreihenfolge migrieren. Verschieben Sie zuerst Hochrisiko-Anmeldedaten in den Tresor. Für jedes: In Passwork speichern, Zugriff der relevanten Rollengruppe zuweisen und sofort aufhören, das rohe Passwort zu verteilen. Für Legacy-Systeme, die keine individuellen Konten unterstützen können, implementieren Sie das Service-Account-Muster — Anmeldedaten im Tresor, Zugriff vermittelt durch Passwork.
5. Den neuen Prozess durchsetzen und den alten abschaffen. Blockieren Sie die informellen Kanäle. Das bedeutet eine klare Richtlinie: keine Anmeldedaten in Slack, E-Mail oder geteilten Dokumenten. Für externe Weitergabe nutzen Sie die Einmal-Secret-Links von Passwork anstelle von Direktnachrichten. Die Richtlinie funktioniert nur, wenn der Tresor bereits einfacher zu nutzen ist als der Workaround — weshalb die Schritte 3 und 4 zuerst kommen.
6. Auditieren, rotieren und pflegen. Sobald Anmeldedaten im Tresor sind, nutzen Sie die Sicherheits-Audit-Tools von Passwork, um schwache Passwörter zu identifizieren, Anmeldedaten zu kennzeichnen, die nicht rotiert wurden, und Zugriffsprotokolle auf Anomalien zu überprüfen. Legen Sie einen Rotationsplan für privilegierte Konten fest. Überprüfen Sie Rollengruppen-Mitgliedschaften vierteljährlich — oder lösen Sie eine Überprüfung automatisch bei jeder organisatorischen Änderung aus.

Die vollständige Migration für ein 50-Personen-Team dauert in dieser Reihenfolge typischerweise ein bis zwei Wochen. Das Audit in Schritt 1 dauert normalerweise am längsten.

Wichtige Erkenntnisse für CISOs und IT-Führungskräfte

Die erforderliche Kernverschiebung besteht darin, die Weitergabe von Anmeldedaten als Zugriffsverwaltungsproblem zu behandeln, nicht als Problem des Benutzerverhaltens. Richtlinien, die darauf setzen, dass Mitarbeiter „das Richtige tun", werden im großen Maßstab scheitern. Eine Architektur, die das Richtige zum Einfachen macht, wird nicht scheitern.

• Geteilte Anmeldedaten durch Tresor-vermittelten Zugriff ersetzen. Benutzer erhalten Zugriff auf Systeme über den Tresor, nicht über das Passwort selbst.
• RBAC auf Gruppenebene implementieren. Individuelle Berechtigungsverwaltung skaliert nicht; gruppenbasierte Vererbung schon.
• MFA auf allen privilegierten Konten erzwingen. Die Kompromittierung von Anmeldedaten ist eine Frage des Wann, nicht des Ob — MFA begrenzt den Schaden.
• Audit-Trails etablieren, bevor sie benötigt werden. Incident Response ohne Protokolle ist Raterei.
• Legacy-Systeme explizit adressieren. Ein Service-Account in einem Tresor ist keine perfekte Lösung, aber eine dokumentierte und überprüfbare.
• Shadow IT als Design-Signal behandeln. Wenn Mitarbeiter persönliche Tools für Arbeits-Anmeldedaten verwenden, hat das Unternehmens-Tooling ein Friktionsproblem.
• Offboarding automatisieren. Jeder Tag, an dem ein ehemaliger Mitarbeiter Zugriff behält, ist eine Haftung. Verzeichnisintegration eliminiert den manuellen Schritt.

Fazit

Geteilte Anmeldedaten waren schon immer eine Haftung. Im Jahr 2026, mit KI-gestützten Cracking-Tools und durchschnittlichen Kosten von 4,57 Millionen USD pro Sicherheitsvorfall, sind sie nicht mehr vertretbar.

Die Lösung erfordert nicht, Mitarbeiter zu mehr Disziplin aufzufordern. Sie erfordert den Aufbau von Systemen, in denen der sichere Weg auch der schnellere ist. Wenn der Tresor-Zugriff weniger Zeit kostet als eine Slack-Nachricht, nutzen die Leute den Tresor. Wenn das Offboarding automatische Widerrufung auslöst, behalten ehemalige Mitarbeiter keinen monatelangen Zugriff. Wenn jede Aktion protokolliert wird, hört Incident Response auf, Raterei zu sein.

Beginnen Sie mit Ihren Anmeldedaten mit dem höchsten Risiko: Admin-Konten, Produktionsdatenbank-Zugriff, alles, was regulierte Daten berührt. Verschieben Sie diese zuerst in einen Tresor mit rollenbasierter Zugriffskontrolle. Arbeiten Sie dann in Prioritätsreihenfolge nach außen, unter Verwendung der obigen 6-Schritte-Migration.

Häufig gestellte Fragen

Warum ist unsichere Passwortweitergabe 2026 ein erhebliches Sicherheitsrisiko?

KI-gestützte Cracking-Tools können ein 8-Zeichen-Passwort in unter 12 Minuten auf Consumer-Hardware knacken (Hive Systems, 2025), und Credential-Stuffing-Angriffe laufen im industriellen Maßstab mit Milliarden geleakter Paare. Geteilte Passwörter eliminieren individuelle Verantwortlichkeit — wenn ein Sicherheitsvorfall auftritt, gibt es keinen Audit-Trail, um zu identifizieren, wer Zugriff hatte oder wann.

Wie können Organisationen Passwörter für Legacy-Systeme sicher verwalten, die nur ein einzelnes geteiltes Login unterstützen?

Verwenden Sie ein Service-Account-Muster: Speichern Sie das geteilte Anmeldedatum in einem verschlüsselten Tresor und gewähren Sie Benutzern Tresor-vermittelten Zugriff anstelle des rohen Passworts. Der Zugriff wird auf Tresor-Ebene protokolliert, auch wenn das Zielsystem keine native Audit-Fähigkeit hat. Bei Personaländerungen rotieren Sie das Anmeldedatum im Tresor — das System selbst muss sich nicht ändern.

Was ist reibungslose Governance im Kontext des Anmeldedaten-Managements?

Reibungslose Governance ist ein Anmeldedaten-Management-Modell, das sicheren Zugriff schneller als den Workaround macht. Es kombiniert individuelle Benutzeridentitäten, RBAC für gruppenbasierte Berechtigungsvererbung und vollständiges Audit-Logging — sodass Mitarbeiter nie ein rohes Passwort teilen müssen, um ihre Arbeit zu erledigen.

Wie schafft Shadow IT Sicherheitsrisiken bei Anmeldedaten?

Wenn Mitarbeiter Arbeitspasswörter in persönlichen Passwort-Managern speichern, verliert die Organisation Audit-Trails, Offboarding-Hooks und die Kontrolle über Verschlüsselungsstandards. Der persönliche Tresor eines ausscheidenden Mitarbeiters behält jedes dort gespeicherte Anmeldedatum. Die Lösung besteht darin, den Unternehmens-Tresor einfacher nutzbar zu machen als die persönliche Alternative — schnelleres Onboarding, Browser-Autofill, mobiler Zugriff.

Gegen welche Compliance-Frameworks verstoßen geteilte Anmeldedaten?

Geteilte Anmeldedaten ohne individuelle Zuordnung verstoßen gegen DSGVO Artikel 32 (geeignete technische Maßnahmen zum Datenschutz), SOC 2 Trust Services Criteria CC6.1 (logische Zugriffskontrollen, die an individuelle Identitäten gebunden sind) und HIPAA 45 CFR §164.312(a)(2)(i) (eindeutige Benutzeridentifikation). Alle drei erfordern die Fähigkeit, Zugriffsereignisse einer bestimmten Person zuzuordnen.

Wie lange dauert es typischerweise, einen anmeldedatenbasierten Sicherheitsvorfall zu erkennen?

Laut dem Cost of a Data Breach Report 2025 von IBM benötigen Sicherheitsvorfälle mit kompromittierten Anmeldedaten durchschnittlich 246 Tage zur Identifizierung und Eindämmung. Geteilte Konten verschlimmern dies: Ohne individuelle Verhaltens-Baselines vermischt sich anomale Aktivität mit normalem Multi-User-Traffic und löst selten Alarme aus.

Shadow IT vs Shadow AI: Warum KI die größere Bedrohung ist

Mitarbeiter nutzen KI-Tools, die Sie nicht genehmigt haben, auf Konten, die Sie nicht überwachen können, mit Daten, die Sie nicht wiederherstellen können. So sieht das Risiko tatsächlich aus und was Governance adressieren muss.

Passwork BlogAlex Muntyan

Brute-Force-Angriffe 2026: Typen, Beispiele und wie man sie verhindert

GPU-Cluster, KI-gestützte Wortlisten, Botnets mit 2,8 Mio. Geräten. Brute-Force hat skaliert. Dieser Leitfaden behandelt sechs Angriffsvarianten, reale Fälle aus 2025 und eine mehrschichtige Verteidigungsstrategie, die Ihr Team heute implementieren kann.

Passwork BlogAlex Muntyan

Passwork gewinnt Top Performer Frühjahr 2026 auf SourceForge

Passwork wurde von SourceForge als Top Performer Frühjahr 2026 ausgezeichnet und gehört zu den besten 10 % von über 100.000 Lösungen. Das Badge basiert ausschließlich auf verifizierten Bewertungen — 4,8 Sterne insgesamt, mit perfekten 5,0 für Support.

Passwork BlogAlex Muntyan