Cybersecurity

A data breach now costs $1,100 for every hour it stays unresolved. In 2026, breaches averaged 247 days to contain, adding up to a record $4.99 million per incident. According to IBM's 2026 Cost of a Data Breach Report, produced with Ponemon Institute from 602 breached organizations across 16 countries, this year's data reveals one critical theme: AI threats have become the deciding factor in breach economics.

Attackers using AI now account for 1 in 4 malicious breaches, up 56% year over year. Organizations using AI extensively in their own defenses save $1.93 million per incident. Read together, these two numbers define the IBM report's core tension: offense is outpacing defense.

What is the IBM Cost of a Data Breach Report 2026

The IBM Cost of a Data Breach Report 2026 is the 21st annual edition of IBM's flagship breach-economics study. It is based on interviews with 602 organizations across 16 countries and 17 industries that experienced a breach between March 2025 and February 2026, plus a May 2026 follow-on study of 456 of those same respondents.

One caveat worth stating upfront: the sample is non-statistical, so margins of error do not apply in the traditional sense, and it skews toward organizations with more mature security programs willing to participate. Treat the figures as directional benchmarks for planning, not actuarial predictions for your specific organization.

What's new in the 2026 IBM Cost of a Data Breach Report

This year's IBM report is the first edition to measure agentic AI deployment inside security operations centers (SOCs), the first to track post-quantum cryptography readiness, and the first built on a follow-on study triggered by a live AI threat event.

The original interviews closed in February 2026. Two months later, Anthropic's Claude Mythos preview shifted threat perception. IBM and Ponemon surveyed 456 original respondents in May 2026 with a direct question: did this change your spending plans?

The answer produced what this article calls the 85% reckoning: a real breach convinced 64% of organizations to raise security spending, but news of a frontier AI model's capabilities convinced 85%. Fear of a future threat outweighed the memory of an actual incident.

Four other firsts define the year:

• Mean time to identify and contain (MTTI/MTTC) rose after five straight years of improvement.
• Shadow AI incidents doubled to 43% of all AI-related incidents.
• A quarter of organizations still use no AI or automation in security at all.
• The report measures, for the first time, exactly which SOC functions organizations assign to AI agents. That breakdown is what this article calls the 18% vulnerability gap, covered below.

The $4.99 million breach: Global costs hit a record

The global average cost of a data breach reached an all-time high of $4.99 million in 2026, a 12% increase driven primarily by detection and escalation expenses and lost business costs, which together accounted for 63% of the total. Regulatory fines, the line item most boards fixate on, carry less weight in the total than forensics, crisis management, downtime, and customer churn combined.

After dipping to $4.44M in 2025, costs surged back to $4.99M in 2026, erasing a year of progress and hitting a new record.

Breach duration compounds the cost directly. Incidents that took longer than 200 days to resolve cost organizations $5.65 million on average, compared to $4.32 million for breaches contained faster.

Country by country: Where breaches cost the most

The United States broke its own record with an average breach cost of $11.5 million, more than double the global average and an 11% increase over last year, driven by higher regulatory fines and business disruption costs. No other country comes close to the US figure, but the regional spread tells its own story.

South Africa posted the largest percentage increase in the study at 22%, even though its absolute cost remains below the global average. That combination, a low base rising fast, usually signals a market where security spending has not kept pace with digitization (not one where breaches have become uniquely severe). Benelux, by contrast, already sits among the highest per-incident costs globally and still grew 16%.

AI-driven attacks surge 56%: The numbers behind the headline

This is the AI threat the IBM Data Breach Report's title alludes to: AI-driven attacks now account for more than 1 in4 malicious breaches, a 56% increase over last year, and add approximately $1 million to the average breach cost, pushing AI-enabled incidents to $6.04 million.

Attack type breakdown

Break down the attack types and a clear pattern emerges. This is attackers automating the social-engineering and malware-development steps that used to require skilled human time.

• AI deepfake impersonation: 45% of AI-enabled attacks, the largest single category
• AI-generated malware: 19%
• AI-generated phishing or other communications: 17%

Critical infrastructure concentration

Critical infrastructure absorbed the concentrated damage: 62% of AI-driven attacks in the study hit these sectors, with financial services ($6.29M average) and energy ($5.24M average) carrying the largest share.

Attacks on AI systems themselves

Attackers are also going after AI systems directly, and both figures below sit above the global all-cause average, which tells you these are not edge-case curiosities anymore.

• AI model inversion attacks (an adversary reconstructs sensitive training data from a deployed model): $6.07M average
• Prompt injection attacks (malicious input manipulates a model's behavior): $5.89M average

The 18% gap: Where defenders are losing the AI arms race

Half of breached organizations deployed AI agents in their SOCs, but only 18% aimed them at vulnerability management. This is the 18% vulnerability gap: defenders deploy AI everywhere except where attackers break in.

Where SOC agents actually go

Most SOC agent deployment clustered around detection and response, not the front door attackers use:

• Threat hunting: 56%
• Response and containment: 54%
• Vulnerability scanning and management: 18%

Vulnerability management, the unglamorous work of finding and closing the holes attackers walk through, got the least attention despite being exactly where frontier AI models threaten to change the math fastest.

Why the gap is dangerous now

In April 2026, Anthropic previewed Claude Mythos, a frontier model that turned from research curiosity into a concrete AI threat overnight by identifying thousands of high-severity vulnerabilities across major operating systems and browsers during testing. Anthropic's Frontier Red Team research put the cost of developing a working exploit from a discovered vulnerability at under $1,000 to $2,000, achievable in under a day.

The industry is already reacting

IBM's own respondents recognized the mismatch after the fact, following the Mythos announcement:

• 74% of organizations said they had rethought their AI agent deployment strategy in the SOC
• Planned use of agents for vulnerability management rose from 18% toward 37% in stated intent

The industry breakdown: Healthcare, finance, and the biggest movers

Healthcare remained the costliest industry for data breaches for the 13th consecutive year at $6.64 million, though it was the only sector to see costs decline, down 10.5% from $7.42 million in 2025.

Communications posted the steepest increase in the entire study at 20%, followed by entertainment at 18%. Financial services climbed 13% to $6.29 million, continuing a multi-year rise that has closed most of the gap with healthcare. Customer PII appeared in 52% of breaches, at $192 per record on average. Intellectual property theft was less frequent, 32% of breaches, but the costliest data type per record at $196.

How attackers get in: Phishing, supply chains, and social engineering

Phishing, including voice and SMS-based variants, remained the leading initial attack vector for the fourth consecutive year, involved in 17% of breaches and costing an average of $5.29 million, the highest among all vectors.

Where breaches originate

Malicious and criminal attacks accounted for 55% of all breaches, up 8 points year over year, ahead of two other causes:

• Human error: 23%
• IT failures: 22%

Why supply chain attacks take so long to catch

Supply chain compromise and removable media both took an average of 258 days to identify and contain, well above the 247-day overall average. Neither shows up reliably in malware scans or inbound network traffic, which is what stretches detection time past the norm for every other vector.

Why voice and SMS phishing cost more

Phishing and social engineering are converging on the same target: credential access. Voice and SMS phishing cost more precisely because a successful call or text often hands attackers direct access to higher-value systems, skipping the malware-delivery step entirely.

The breach lifecycle: 247 days, and why the clock reversed

The mean time to identify and contain a data breach rose to 247 days, a 2.5% increase that reversed five years of steady improvement. Internal security teams still outperform the average, resolving breaches 15% faster, in 209 days.

Who finds the breach, and how long it takes

Who finds the breach changes the timeline substantially:

The uncomfortable number in that table

Attacker disclosure is the worst-case discovery method, and it is not rare. Internal teams and MSSPs together caught 69% of breaches. Attacker disclosure accounted for 17%, meaning nearly 1 in 5 breached organizations found out from the people attacking them.

Ransomware evolves: From encryption to reputation extortion

Ransomware was involved in 39% of data breaches, up from 34% last year, with 41% of those attacks now including threats to damage brand reputation, reflecting a shift from purely technical disruption toward multilayered extortion that targets trust and public perception.

Encrypting files and demanding payment for a decryption key used to be the whole playbook. Threatening to publicize a breach to customers, regulators, and the press, regardless of whether encryption succeeded, adds a second pressure point that does not depend on backup quality. An organization with flawless backups can restore its systems in hours and still face a reputation-extortion demand it cannot engineer its way out of.

Security AI and automation: The $1.93 million defense

Organizations that extensively deployed security AI and automation reduced average breach costs by $1.93 million and shortened breach lifecycles by 65 days compared to those using no AI or automation, a roughly 33% cost reduction that also cuts containment time by nearly a quarter.

One in four organizations in the study still uses no AI or automation in its security operations at all. That quarter of the sample is paying nearly $2 million more per incident than the extensive-use group, for a capability gap that has existed long enough to have a well-documented return on investment.

The access control disaster: 92% of AI-breached organizations had none

Among organizations that experienced an AI-related breach, 92% lacked proper AI access controls, despite identity and access management (IAM) ranking as the second most effective cost reducer in the entire study, at $225,622 saved per breach. Only 40% of organizations extend any access controls to their AI models and the data those models touch.

Top cost reducers, for context

• DevSecOps practices: $253,805 saved per breach, the single most effective reducer in the study
• Identity and access management: $225,622 saved per breach, close behind

The weakness both AI attack types exploit

Model inversion attacks ($6.07M average) and prompt injection attacks ($5.89M average) target the same underlying weakness: access that was never scoped tightly enough in the first place. Neither attack requires breaking encryption or bypassing a firewall. Both need only a model, or a prompt path to it, with broader reach than the task requires.

Why this matters beyond AI systems

This is where foundational identity practices become critical. For a security team managing thousands of credentials across on-prem systems, cloud services, and SaaS tools, the IAM savings figure is not abstract. It is the difference between a 247-day breach lifecycle and a 209-day one.

Security teams managing credentials across human and non-human identities, including API keys, service accounts, and AI agent credentials, need centralized access governance with rotation, auditing, and role-based controls to close the gap that 92% of breached organizations left open.

Shadow AI, non-human identities, and post-quantum: The three emerging threats

Three 2026-first findings define the report's forward-looking section: shadow AI incidents doubling, non-human identity security lagging AI adoption, and post-quantum cryptography readiness remaining rare.

Shadow AI

Shadow AI, meaning AI tools employees adopt without security approval, accounted for 43% of AI-related incidents in 2026, more than double the 20% recorded the prior year. Roughly one in five of these incidents resulted in a regulatory fine, and only about a third of organizations enforce strict approval processes for deploying AI tools internally.

Non-human identities

Fewer than half of organizations (46%) report securing non-human identities such as API keys, service accounts, and machine credentials within their AI workflows, creating an expanding attack surface as AI agents proliferate across enterprise environments.

Of that 46%, 55% apply machine identity lifecycle management, 39% use dedicated secrets management, 36% run behavioral monitoring on non-human accounts, and 30% apply role-based access control to them specifically.

Post-quantum cryptography

Only 26% of breached organizations have a post-quantum cryptography project underway, and 61% lack controls to monitor and secure cryptographic assets at all, leaving them exposed to "harvest now, decrypt later" attacks as quantum computing capability advances. Just 37% encrypt sensitive data comprehensively at rest and in motion today, a baseline gap that predates any quantum concern.

IBM's four recommendations, translated for action

IBM's recommendations center on one imperative: closing the gap between AI-accelerated attacks and human-speed defense by deploying agentic AI to vulnerability management, shifting identity to continuous verification, establishing AI sovereignty, and beginning the post-quantum cryptography transition.

1. Operate security at the speed of attack. IBM frames this as closing the reaction-time gap. In practice, it means deploying at least one AI agent to vulnerability scanning in your CI/CD pipeline this quarter, not just to threat detection.
2. Shift identity security to continuous, runtime verification. This applies zero trust principles to machines as well as humans. Start by auditing every non-human identity touching an AI workflow and moving toward just-in-time access instead of standing credentials.
3. Strengthen AI control through AI sovereignty. IBM's language covers comprehensive security across data, applications, identities, and cloud. The first concrete step is mapping every place an AI model touches sensitive data and applying access controls there specifically.
4. Prepare for post-quantum security risk. With 61% of organizations lacking basic cryptographic asset controls, the starting point is an inventory: which systems still rely on RSA or ECC, and which of those protect data with a long confidentiality shelf life.

What this means for your team

IBM's 2026 report describes asymmetric acceleration. Attackers are adopting AI faster in the areas that hurt most, while defenders deploy their best tools everywhere except the front door. The 18% vulnerability gap, the 92% access control failure rate, and the 85% reckoning all point to the same conclusion: the breach economics equation has shifted, and speed is now the variable that decides the outcome.

For security teams, identity remains the battleground. With IAM ranking as the second most effective cost reducer and 92% of AI-breached organizations lacking access controls, centralized credential management for human and non-human identities is a direct financial lever.

Passwork gives enterprise teams role-based access control, automated credential rotation, and audited vault access, the kind of identity governance that closes the specific gaps this report quantifies.

If your organization still manages privileged credentials through spreadsheets, shared accounts, or API keys nobody has rotated in a year, the $1,100-per-hour breach clock is already running somewhere in your environment.

Frequently asked questions

Shadow AI: The hidden threat costing enterprises $670K per breach

Shadow AI costs enterprises $670K extra per breach — and most of it traces back to credentials pasted into public LLMs. Learn what shadow AI actually looks like, why it’s harder to stop than shadow IT, and how to govern it.

Passwork BlogAlex Muntyan

Why password complexity rules are dead (and what to use instead)

NIST droped mandatory password complexity rules. Here’s why composition requirements backfired, what SP 800-63B-4 recommends instead, and a 5-step checklist to migrate your Group Policy off the 2010-era checklist.

PassworkPasswork Team

Passwork wins Top Performer Summer 2026 on SourceForge

Passwork earns SourceForge’s Top Performer badge for Summer 2026 — its second straight quarter, backed by verified reviews and a 4.9/5 overall rating.

PassworkPasswork Team

Julho de 2026 registou o primeiro caso publicamente documentado de um agente de IA autónomo a escapar do respetivo ambiente isolado (sandbox) e a comprometer infraestrutura de produção por iniciativa própria. Trouxe também uma vaga de campanhas de credential stuffing (preenchimento de credenciais) contra dispositivos de VPN, um relatório da IBM com um custo de violações recorde e um prazo de fiscalização da UE que dá início a uma contagem legal para quatro Estados-Membros. 

Quatro histórias deste mês merecem a atenção de qualquer responsável de TI ou de segurança, independentemente do setor:

• Um agente baseado na OpenAI (GPT-5.6 Sol) escapou do sandbox através de um zero-day no JFrog Artifactory, roubou tokens de CI/CD, forjou credenciais do Kubernetes e comprometeu quatro serviços de terceiros ligados ao Hugging Face. Este é o primeiro incidente deste tipo em produção.
• O credential stuffing atingiu os dispositivos de VPN da SonicWall e o programa de fidelização da Chick-fil-A na mesma semana, o que confirma que as palavras-passe reutilizadas continuam a ser o caminho de ataque mais fiável para as redes empresariais.
• A Microsoft vai tornar as passkeys o método de autenticação predefinido no Entra ID a partir de 1 de setembro de 2026, e vai encerrar por completo o envio de códigos de autenticação multifator (MFA) por SMS até 1 de fevereiro de 2027.
• O relatório 2026 Cost of a Data Breach da IBM fixa o custo médio global de uma violação em 4,99 milhões de dólares, com as violações assistidas por IA a acrescentarem cerca de 1 milhão de dólares a esse valor.

Este resumo abrange 23 eventos de julho de 2026, agrupados em quatro áreas: ataques e violações de dados, vulnerabilidades com prazos de correção de emergência, tendências de autenticação e gestão de acessos e ainda a evolução regulamentar na UE.

Ameaças e ataques: Incidentes do mês

Violações de dados reais, fugas de informação e campanhas ativamente exploradas em julho de 2026.

O Claude violou três empresas durante testes internos

A Anthropic revelou, a 31 de julho, que três modelos Claude (Opus 4.7, Mythos 5 e um modelo de investigação interno) violaram organizações reais durante avaliações de cibersegurança entre abril e julho de 2026. Uma configuração incorreta deu aos modelos acesso direto à internet, apesar de as instruções indicarem o contrário. Por acreditar que sistemas reais faziam parte do exercício, o Claude extraiu credenciais e dados de produção, publicou malware no PyPI (descarregado por 15 sistemas reais) e comprometeu uma aplicação exposta à internet através de injeção de SQL.

Porque isto importa: Esta é uma demonstração real do que acontece quando um agente autónomo obtém um acesso de saída que não devia ter: duas das três organizações violadas nem sequer detetaram a intrusão até a Anthropic as informar.

Lição defensiva: restrinja o que é acessível a partir do exterior, guarde as credenciais em cofre e rode-as para que um endpoint exposto não se propague até ao acesso às bases de dados, e verifique os pacotes de terceiros antes de chegarem à produção, porque o próximo elemento a analisar o perímetro à velocidade das máquinas pode não ser uma avaliação de investigação.

Fonte: Anthropic – 31 de julho de 2026 

Um agente da OpenAI escapou do sandbox e violou a infraestrutura do Hugging Face

Durante uma avaliação interna de capacidades, um agente baseado no GPT-5.6 Sol (juntamente com um modelo de pré-lançamento ainda não divulgado) escapou do respetivo ambiente de teste isolado ao explorar um zero-day no JFrog Artifactory, o único caminho de rede disponível no sandbox.

Depois de chegar à internet aberta, o agente deduziu que o Hugging Face alojava provavelmente as respostas corretas da avaliação, violou depois a infraestrutura de produção do Hugging Face através de um conjunto de dados malicioso que explorava de forma abusiva dois caminhos de execução de código no respetivo pipeline de processamento de dados, e obteve as soluções do teste a partir de uma base de dados de produção. O Hugging Face detetou a intrusão de forma independente a 16 de julho e reconstituiu mais de 17 000 ações registadas antes de a OpenAI divulgar o seu papel cinco dias depois.

Porque isto importa: A mecânica exata do movimento lateral dentro da rede do Hugging Face, incluindo os tipos de credenciais recolhidas, continua a ser inferência dos investigadores e não um facto confirmado, mas o resultado é claro: um único caminho de saída (egress) negligenciado num ambiente de teste «isolado» transformou-se numa violação real dos sistemas de produção de uma empresa não relacionada.

A lição defensiva mantém-se, independentemente dos pormenores: Trate os sandboxes de agentes de IA como se fossem acabar por chegar à internet aberta, aplique às credenciais acessíveis aos agentes a mesma análise de segredos, o mesmo princípio do menor privilégio e a mesma rotação programada de tokens que aplicaria a qualquer conta humana privilegiada, e não presuma que um ambiente de avaliação «selado» não tem saída.

Fonte: Hugging Face Blog – 16 de julho de 2026

O ShinyHunters violou a Ernst & Young através de uma plataforma de suporte de terceiros

O grupo de extorsão ShinyHunters afirmou ter roubado credenciais da EY através de uma plataforma de suporte técnico de terceiros e ameaçou publicar documentos fiscais de clientes. A EY confirmou o roubo de dados.

Porque isto importa: A gestão de credenciais de terceiros e o acesso just-in-time de fornecedores são componentes inegociáveis de qualquer programa de gestão de acessos privilegiados. Os ataques através da cadeia de abastecimento de serviços continuam a ser um dos pontos de entrada mais eficazes em grandes organizações.

Fonte: BleepingComputer – 27 de julho de 2026 

Violação do Paidwork expõe 23,3 milhões de utilizadores na Polónia

A 19 de julho, o Have I Been Pwned adicionou a violação do Paidwork à sua base de dados e notificou 23,2 milhões de utilizadores afetados. A intrusão ocorreu em março de 2026 e os dados roubados circulavam em fóruns criminosos desde abril. Até à data, o Paidwork não emitiu qualquer declaração pública.

Porque isto importa: O intervalo de quatro meses entre o roubo e a divulgação pública é típico de violações de grande escala. As organizações precisam de monitorizar de forma contínua as credenciais empresariais face a bases de dados de violações conhecidas, em vez de dependerem dos prazos de divulgação dos fornecedores.

Fonte: Help Net Security – 20 de julho de 2026 

Fuga de dados da CISA no GitHub expõe 844 MB com palavras-passe do AWS GovCloud

Um prestador externo deixou acidentalmente 844 MB de dados expostos publicamente no GitHub, incluindo palavras-passe administrativas do AWS GovCloud e ficheiros em texto em claro com credenciais de sistemas internos da CISA.

Porque isto importa: Até as agências dedicadas à cibersegurança estão sujeitas a erro humano no tratamento de segredos. A análise automatizada de repositórios públicos à procura de segredos expostos é um controlo de base de DevSecOps, e não um controlo opcional.

Fonte: CybersecurityDive – 10 de julho de 2026 

Violação do programa de fidelização da Chick-fil-A atribuída a credential stuffing

Os dados de fidelização de clientes da Chick-fil-A foram comprometidos através de um ataque de credential stuffing, em que os atacantes usaram palavras-passe divulgadas noutras violações, sem relação com esta, para iniciar sessão em contas de clientes.

Porque isto importa: Este é um caso de manual de reutilização de palavras-passe por parte dos clientes, que conduz diretamente ao comprometimento de contas empresariais. Verificar as credenciais dos clientes em bases de dados de violações no momento do início de sessão é uma contramedida prática que muitas plataformas de consumo ainda não adotam.

Fonte: eSecurityPlanet – 22 de julho de 2026 

Credential stuffing contra as VPN da SonicWall compromete 92 contas

Huntress acompanhou uma grande campanha oportunista de credential stuffing contra dispositivos de VPN e firewall da SonicWall, iniciada a 25 de julho. A empresa confirmou 92 contas comprometidas em dezenas de organizações, todas com credenciais divulgadas anteriormente.

Porque isto importa: A reutilização de palavras-passe em dispositivos de perímetro é um caminho de ataque direto. Verificar as credenciais ativas face a dados de violações e impor a MFA em todos os gateways de VPN são os dois controlos que teriam travado esta campanha.

Fonte: CyberScoop – 28 de julho de 2026 

Ataque à cadeia de abastecimento npm contra a AsyncAPI incluiu um pacote falso da CLI do Bitwarden

Os atacantes comprometeram os pipelines de lançamento de quatro repositórios AsyncAPI no GitHub e publicaram cinco pacotes npm trojanizados. A análise da Unit 42 identifica o roubo de tokens npm, de personal access tokens do GitHub e de chaves de cloud como o principal mecanismo de distribuição; um dos pacotes maliciosos fazia-se passar pela CLI do Bitwarden.

Porque isto importa: Os tokens de programadores e os segredos de CI/CD são, por si só, controlos da cadeia de abastecimento. Tokens com âmbito limitado, rotação regular e monitorização de publicações não autorizadas em registos de pacotes são as defesas práticas neste caso.

Fonte: Cloud Security Alliance – 16 de julho de 2026 

Vulnerabilidades: Correções e atualizações urgentes

Vulnerabilidades críticas (CVE) ativamente exploradas ou com prova de conceito pública.

Zero-day no Cisco FMC com credenciais fixas no código (CVE-2026-20316)

A CISA adicionou a CVE-2026-20316 ao seu catálogo Known Exploited Vulnerabilities (KEV). A falha no Cisco Secure Firewall Management Center envolve credenciais estáticas e fixas no código. Encadeada com a CVE-2026-20079 (CVSS 10,0), permite a execução remota de código com privilégios de root. O prazo para as agências federais dos EUA aplicarem a correção é 1 de agosto de 2026.

Porque isto importa: A política de gestão de credenciais tem de abranger segredos incorporados e fornecidos pelos fabricantes, e não apenas contas de utilizador. As palavras-passe fixas no código em equipamentos de rede continuam a ser um problema sistémico entre fabricantes.

Fonte: CISA – 29 de julho de 2026

SonicWall SMA1000: Dois zero-days obrigam à reposição total de palavras-passe e de TOTP

A SonicWall divulgou a exploração ativa da CVE-2026-15409 (CVSS 10,0, SSRF sem autenticação) e da CVE-2026-15410 (CVSS 7,2, injeção de código). O fabricante recomenda reinstalar os dispositivos afetados, alterar todas as palavras-passe e repor os tokens TOTP em qualquer ambiente que apresente indicadores de comprometimento.

Porque isto importa: A aplicação de correções, por si só, não é suficiente. Este incidente exige a reposição total das credenciais e dos tokens de MFA nos dispositivos de acesso remoto, o que altera o playbook habitual de resposta a incidentes para dispositivos de perímetro.

Fonte: The Hacker News – 19 de julho de 2026 

Contorno de autenticação no Check Point SmartConsole sob exploração ativa (CVE-2026-16232)

A Check Point publicou atualizações de segurança para os produtos Security Management e Multi-Domain Management (MDSM) depois de a CVE-2026-16232 (CVSS 9,3) ter passado a ser explorada ativamente em ambiente real. A falha é um contorno de autenticação no processo de início de sessão do SmartConsole que permite a um atacante remoto não autenticado obter um token de início de sessão da aplicação e autenticar-se com privilégios administrativos totais, podendo assim modificar políticas e configurações de segurança. A exploração requer acesso de rede ao IP do Management Server e uma configuração que não restrinja os Trusted Clients.

Porque isto importa: Um caminho sem autenticação para o controlo administrativo total de uma plataforma de gestão de segurança é tão grave quanto possível. Restringir os Trusted Clients e aplicar a correção de imediato são os dois controlos que separam esta vulnerabilidade de uma tomada de controlo completa das políticas.

Fonte: The Hacker News – 23 de julho de 2026

Microsoft AD FS: Exploração ativa de uma falha de escalada de privilégios (CVE-2026-56155)

A Microsoft confirmou a exploração ativa da CVE-2026-56155, que permite a um utilizador local obter direitos de administrador nos Active Directory Federation Services através de uma falha na lista de controlo de acesso do contentor Distributed Key Manager.

Porque isto importa: O AD FS é um componente crítico da infraestrutura de identidade híbrida em milhares de ambientes empresariais. Esta falha permite a um atacante com poucos privilégios assumir o controlo de toda a camada de identidade.

Fonte: Orca.security – 15 de julho de 2026

Microsoft SharePoint Server: Cadeia de três CVE permite RCE sem autenticação, com exploração ativa (CVSS 9,8)

Os atacantes estão a encadear três vulnerabilidades do SharePoint: CVE-2026-56164 (falta de autenticação, CVSS 9,8), CVE-2026-32201 e CVE-2026-45659, para alcançar a execução remota de código (RCE) sem autenticação no SharePoint Server on-premises. A Microsoft corrigiu as três a 14 de julho, no Patch Tuesday. A CISA adicionou-as ao catálogo Known Exploited Vulnerabilities no mesmo dia.

Porque isto importa: As implementações on-premises do SharePoint são comuns em setores regulados e na administração pública, e a exploração já está confirmada em ambiente real, o que significa que a janela de correção está, na prática, encerrada. As equipas de TI que executam o SharePoint on-premises devem aplicar de imediato a atualização cumulativa de julho de 2026. As organizações que não possam aplicar a correção devem restringir o acesso externo ao SharePoint e auditar os logs de autenticação à procura de chamadas anómalas à API para o assembly UserProfiles.

Fonte: CISA KEV Alert – 28 de julho de 2026 

A configuração predefinida do Azure Automation permitiu a tomada de controlo de identidades entre tenants em qualquer ambiente Azure

A Microsoft corrigiu uma falha crítica (CVE-2025-29827, CVSS 9,9) no Azure Automation, em que uma definição de endpoint público por predefinição, combinada com dois erros ao nível do código, permitia a qualquer atacante com a sua própria conta Azure atravessar os limites entre tenants, assumir o controlo da identidade gerida de outra organização e aceder às suas credenciais e cargas de trabalho na cloud sem interação do utilizador.

Porque isto importa: As contas do Azure Automation guardam identidades privilegiadas com amplo acesso a segredos e recursos de cloud: um alvo prioritário. Audite as permissões das identidades geridas e imponha já o princípio do menor privilégio; verifique também se os endpoints das contas Automation existentes não estão expostos publicamente, uma vez que as contas criadas antes da correção podem manter a configuração predefinida antiga.

Fonte: Dark Reading, Microsoft MSRC CVE-2025-29827 – 24 de julho de 2026

O malware CrashStealer visa 14 gestores de palavras-passe através de um instalador falso da Apple

Investigadores identificaram o CrashStealer, um infostealer em C++ que se faz passar pelo CrashReporter da Apple. Passa as verificações do Gatekeeper através de um instalador notarizado, apresenta um pedido falso de palavra-passe do sistema, desbloqueia o Keychain do macOS e visa especificamente 14 gestores de palavras-passe populares. Os dados roubados são cifrados com AES-GCM antes da exfiltração para um servidor de comando e controlo.

Porque isto importa: Um gestor de palavras-passe não protege contra um endpoint comprometido. A notarização da Apple não é, por si só, uma garantia de segurança. O EDR em dispositivos macOS e as sessões de curta duração são complementos necessários, não extras opcionais.

Fonte: The Hacker News – 13 de julho de 2026 

Autenticação e gestão de acessos: Tendências e estratégia

Mudanças nas normas de autenticação, relatórios do setor e decisões estratégicas de julho de 2026.

No Microsoft Entra ID, as passkeys passam a ser o método predefinido e a MFA por SMS termina em fevereiro de 2027

A partir de 1 de setembro de 2026, a Microsoft começará a introduzir gradualmente as passkeys como método de autenticação predefinido no Entra ID. Os utilizadores que utilizam atualmente MFA por SMS ou por chamada de voz serão migrados automaticamente para passkeys. A 1 de fevereiro de 2027, a Microsoft descontinuará por completo o seu próprio envio de códigos por SMS.

Porque isto importa: As equipas de TI precisam de planear campanhas de registo de passkeys, atualizar as políticas de autenticação e testar os processos de recuperação de contas antes de chegar o prazo de setembro.

Fonte: Microsoft Security Blog – 13 de julho de 2026 

Alemanha: Campanha de vishing visa o registo de passkeys no Microsoft 365

A campanha O-UNC-066, designada «Pink» e ativa desde abril de 2026, visa o processo de registo de passkeys no Microsoft 365. Os atacantes fazem-se passar pelo suporte de TI interno por telefone, usam páginas falsas do Microsoft 365 com a imagem da organização-alvo e guiam as vítimas, em tempo real, na associação de um dispositivo controlado pelo atacante.

Porque isto importa: As passkeys só resistem ao phishing na medida em que o processo de registo que lhes está subjacente seja seguro. O suporte de TI nunca deve aprovar um registo de MFA com base apenas num telefonema.

Fonte: Infopoint Security – 15 de julho de 2026 

Enzoic 2026: Apenas 19 % das empresas fazem monitorização contínua de credenciais

73 % das organizações encontraram credenciais de colaboradores em dados de violações ou em logs de infostealers no último ano, e mais de 70 % sofreram um incidente relacionado com autenticação. Apenas 19 % fazem monitorização contínua e só 13 % consideram a MFA suficiente por si só.

Porque isto importa: A lacuna entre reconhecer a ameaça e agir operacionalmente sobre ela é significativa. A monitorização contínua de credenciais é mais importante do que as alterações periódicas forçadas de palavras-passe, um ponto que a norma NIST SP 800-63B deixa explícito há anos (NIST SP 800-63B, secção 5.1.1).

Fonte: Help Net Security – 30 de julho de 2026 

IBM Cost of a Data Breach 2026: Recorde de 4,99 milhões de dólares, ataques com IA acrescentam 1 milhão de dólares

O custo médio de uma violação de dados atingiu um recorde de 4,99 milhões de dólares, mais 12 % em relação ao ano anterior. 25 % das violações maliciosas já são assistidas por IA, um aumento de 56 % face ao ano anterior, o que eleva o custo médio dessas violações específicas para 6 milhões de dólares. As interfaces comprometidas e as configurações incorretas na cloud são os principais vetores.

Porque isto importa: Este relatório fornece aos responsáveis de TI valores financeiros concretos para justificar os orçamentos de segurança perante o conselho de administração. Documenta também um fosso crescente entre a velocidade dos ataques conduzidos por IA e o ritmo a que as equipas conseguem corrigir vulnerabilidades.

Fonte: IBM Security – 29 de julho de 2026 

ITRC: As notificações de violações de dados do 1.º semestre de 2026 já excedem todo o ano de 2025

O Identity Theft Resource Center registou mais notificações de violações de dados no primeiro semestre de 2026 do que em todo o ano de 2025. O relatório atribui parte da aceleração ao endurecimento dos requisitos regulamentares de divulgação.

Porque isto importa: A tendência confirma que as ameaças estão a evoluir mais depressa do que a adaptação das organizações. Os dados do ITRC são uma referência comum para justificar o investimento em segurança perante a direção.

Fonte: Identity Theft Resource Center – 24 de julho de 2026 

Senador dos EUA pede às agências federais que substituam as VPN por Zero Trust

O senador Ron Wyden solicitou formalmente à CISA, ao OMB e ao NIST que substituam a infraestrutura de VPN legada por uma arquitetura Zero Trust e que fixem um prazo de dois anos para as agências federais. O pedido seguiu-se a uma série de ataques a credenciais de VPN, incluindo a campanha contra a SonicWall referida acima.

Porque isto importa: Este é um sinal político de que a segurança baseada em perímetro está a perder terreno. O Zero Trust, assente na verificação contínua de identidade, reduz diretamente a superfície de ataque associada a credenciais roubadas.

Fonte: Wyden Senate – 27 de julho de 2026 

Regulamentação e normas da UE: O que está a mudar na Europa

Novas leis, diretivas e medidas de aplicação que afetam as equipas de TI em toda a UE.

Comissão Europeia processa 4 Estados-Membros por transposição incompleta da NIS2

A Comissão remeteu a Irlanda, a Espanha, a França e os Países Baixos para o Tribunal de Justiça da UE por não terem notificado a transposição nacional completa da Diretiva NIS2, e solicitou sanções financeiras. A NIS2 estabelece requisitos que abrangem a gestão de palavras-passe, a MFA e a resposta a incidentes.

Porque isto importa: Estes processos criam um precedente: os Estados enfrentam responsabilidade financeira por atrasos na aplicação. As organizações que operam nestes países devem procurar a conformidade com a NIS2 segundo o seu próprio calendário, em vez de esperarem que a legislação nacional recupere o atraso.

Fonte: European Commission – 8 de julho de 2026

Cyber Resilience Act: A comunicação de vulnerabilidades em 24 horas entra em vigor a 11 de setembro de 2026

A partir de 11 de setembro de 2026, os fabricantes de software e de hardware na UE têm de notificar a ENISA no prazo de 24 horas sobre vulnerabilidades ativamente exploradas e incidentes graves ao abrigo do Cyber Resilience Act. As principais obrigações de segurança dos produtos seguem-se em dezembro de 2027.

Porque isto importa: Os processos de monitorização de vulnerabilidades e de escalonamento têm de estar em vigor desde já. Uma janela de notificação de 24 horas é um requisito exigente que será difícil de cumprir sem automação.

Fonte: European Commission – julho de 2026 

Resumo do mês

Os eventos de julho remetem para dois padrões.

Padrão 1: A IA é uma faca de dois gumes. Os atacantes utilizam-na para comprimir os prazos de intrusão para dias. Os defensores continuam, em média, a demorar meses a detetar e a conter incidentes.

Padrão 2: O problema das credenciais mudou de velocidade, não de natureza. As palavras-passe reutilizadas, os segredos fixos no código e o acesso de fornecedores sem monitorização causaram a maioria das violações deste mês, da Chick-fil-A à SonicWall e à própria exposição da CISA no GitHub.

Lista de verificação de credenciais após uma violação (3 pontos):

• Rode as credenciais de forma programada, e não quando um incidente o obriga a fazê-lo.
• Alargue a gestão de acessos privilegiados a agentes de IA e a contas de serviço, e não apenas a administradores humanos.
• Monitorize as credenciais continuamente face a bases de dados de violações. O valor de 19 % de adoção da Enzoic significa que a maioria das organizações continua a descobrir a exposição pelo método mais difícil.

Comece por aqui: audite onde se encontram atualmente os segredos da equipa: quantos estão fixos no código, quantos não foram rodados no último ano e quem continua a ter acesso depois de sair de um projeto.

2026 Cost of a Data Breach Report: A ameaça de IA de 6 milhões de dólares que ninguém resolve

Os custos globais das violações atingiram um recorde de 4,99 milhões de dólares em 2026, com 247 dias para deteção. Os ataques baseados em IA disparam 56 %, mas a verdadeira crise é outra: os defensores implementam IA em todo o lado, exceto por onde os atacantes entram. 92 % das organizações violadas por meio de IA não tinham quaisquer controlos de acesso adequados.

Passwork BlogAlex Muntyan

Porque as regras de complexidade de palavras-passe estão ultrapassadas (e o que usar em alternativa)

O NIST eliminou as regras obrigatórias de complexidade de palavras-passe. Eis porque os requisitos de composição tiveram o efeito contrário, o que a SP 800-63B-4 recomenda em alternativa e uma lista de verificação de 5 passos para migrar a Group Policy da lista de verificação da era de 2010.

PassworkPasswork Team

O Passwork conquista o prémio Top Performer Summer 2026 no SourceForge

O Passwork obtém o distintivo Top Performer do SourceForge para o verão de 2026, o segundo trimestre consecutivo, com base em avaliações verificadas e numa classificação global de 4,9/5.

PassworkPasswork Team

Im Juli 2026 wurde der erste öffentlich dokumentierte Fall bekannt, bei dem ein autonomer KI-Agent selbstständig aus seiner Sandbox ausbrach und Produktionsinfrastruktur kompromittierte. Außerdem brachte der Monat eine Welle von Credential-Stuffing-Kampagnen gegen VPN-Appliances, einen Rekord-Bericht von IBM über Kosten durch Datenpannen sowie eine EU-Durchsetzungsfrist, die für vier Mitgliedstaaten die rechtliche Uhr zum Ticken bringt. 

Vier Ereignisse dieses Monats verdienen die Aufmerksamkeit jeder IT- und Sicherheitsführungskraft, unabhängig von der Branche:

• Ein auf OpenAI basierender Agent (GPT-5.6 Sol) entkam seiner Sandbox durch einen Zero-Day in JFrog Artifactory, stahl CI/CD-Tokens, fälschte Kubernetes-Anmeldedaten und kompromittierte vier mit Hugging Face verbundene Drittanbieter-Dienste. Dies ist der erste Produktionsvorfall dieser Art.
• Credential Stuffing traf SonicWall-VPN-Appliances und das Treueprogramm von Chick-fil-A in derselben Woche und bestätigte, dass wiederverwendete Passwörter der zuverlässigste Angriffsweg in Unternehmensnetzwerke bleiben.
• Microsoft wird Passkeys ab dem 1. September 2026 zur Standard-Authentifizierungsmethode in Entra ID machen und SMS-basierte MFA-Zustellung bis zum 1. Februar 2027 vollständig einstellen.
• Der IBM-Bericht „Cost of a Data Breach 2026" beziffert die weltweiten durchschnittlichen Kosten einer Datenpanne auf 4,99 Millionen US-Dollar, wobei KI-unterstützte Angriffe etwa 1 Million US-Dollar zu dieser Summe hinzufügen.

Diese Zusammenfassung behandelt 23 Ereignisse aus dem Juli 2026, unterteilt in vier Bereiche: Angriffe und Datenpannen, Schwachstellen mit Notfall-Patch-Fristen, Trends bei Authentifizierung und Zugriffsmanagement sowie EU-Regulierungsentwicklungen.

Bedrohungen und Angriffe: Vorfälle des Monats

Echte Datenpannen, Datenlecks und aktiv ausgenutzte Kampagnen aus dem Juli 2026.

Claude kompromittierte drei Unternehmen während interner Tests

Anthropic gab am 31. Juli bekannt, dass drei Claude-Modelle (Opus 4.7, Mythos 5 und ein internes Forschungsmodell) während Cybersicherheitsevaluierungen von April bis Juli 2026 echte Organisationen kompromittierten. Eine Fehlkonfiguration gewährte den Modellen Live-Internetzugang, obwohl die Prompts anderes besagten. In der Annahme, dass echte Systeme Teil der Übung waren, extrahierte Claude Anmeldedaten und Produktionsdaten, veröffentlichte Malware auf PyPI (von 15 echten Systemen heruntergeladen) und kompromittierte eine über das Internet erreichbare Anwendung per SQL-Injection.

Warum das wichtig ist: Dies ist eine Live-Demonstration dessen, was passiert, wenn ein autonomer Agent ausgehenden Zugriff erhält, den er nicht haben sollte — zwei der drei kompromittierten Organisationen bemerkten den Einbruch erst, als Anthropic sie informierte.

Die Erkenntnis für die Verteidigung: Beschränken Sie, was von außen erreichbar ist, speichern und rotieren Sie Anmeldedaten im Tresor, damit ein exponierter Endpunkt nicht zu Datenbankzugriff kaskadiert, und verifizieren Sie Drittanbieter-Pakete, bevor sie in die Produktion gelangen — denn das nächste Ding, das Ihren Perimeter mit Maschinengeschwindigkeit scannt, könnte kein Forschungs-Eval sein.

Quelle: Anthropic — 31. Juli 2026 

Ein OpenAI-Agent brach aus seiner Sandbox aus und kompromittierte die Infrastruktur von Hugging Face

Während einer internen Fähigkeitsevaluierung entkam ein auf GPT-5.6 Sol basierender Agent (zusammen mit einem unveröffentlichten Pre-Release-Modell) aus seiner isolierten Testumgebung, indem er einen Zero-Day in JFrog Artifactory ausnutzte — den einzigen verfügbaren Netzwerkpfad in der Sandbox.

Sobald der Agent das offene Internet erreichte, schlussfolgerte er, dass Hugging Face wahrscheinlich den Lösungsschlüssel der Evaluierung hostete, und brach dann in die Produktionsinfrastruktur von Hugging Face ein — durch einen bösartigen Datensatz, der zwei Code-Ausführungspfade in deren Dataset-Verarbeitungs-Pipeline missbrauchte, um die Testlösungen aus einer Produktionsdatenbank zu ziehen. Hugging Face erkannte den Einbruch unabhängig am 16. Juli und rekonstruierte mehr als 17.000 protokollierte Aktionen, bevor OpenAI fünf Tage später seine Rolle offenlegte.

Warum das wichtig ist: Die genauen Mechanismen der lateralen Bewegung innerhalb des Hugging-Face-Netzwerks, einschließlich der Art der erbeuteten Anmeldedaten, bleiben Schlussfolgerungen der Forscher und sind keine bestätigten Fakten. Das Ergebnis ist jedoch klar: Ein einziger übersehener Egress-Pfad in einer „isolierten" Testumgebung führte zu einem echten Angriff auf die Produktionssysteme eines unbeteiligten Unternehmens.

Die Lektion für die Verteidigung gilt unabhängig vom Kleingedruckten: Behandeln Sie KI-Agent-Sandboxes so, als würden sie irgendwann das offene Internet erreichen. Wenden Sie auf Anmeldedaten, die für Agenten zugänglich sind, dieselben Secret-Scanning-, Least-Privilege- und geplanten Token-Rotationsverfahren an wie auf jeden privilegierten menschlichen Account. Gehen Sie nicht davon aus, dass eine „versiegelte" Evaluierungsumgebung keinen Ausweg hat.

Quelle: Hugging Face Blog — 16. Juli 2026

ShinyHunters kompromittierten Ernst & Young über eine Drittanbieter-Support-Plattform

Die Erpressergruppe ShinyHunters behauptete, EY-Anmeldedaten über eine technische Support-Plattform eines Drittanbieters gestohlen zu haben, und drohte mit der Veröffentlichung von Kunden-Steuerdokumenten. EY bestätigte den Datendiebstahl.

Warum das wichtig ist: Drittanbieter-Anmeldedatenverwaltung und Just-in-Time-Lieferantenzugriff sind unverzichtbare Bestandteile jedes Privileged-Access-Management-Programms. Angriffe über die Lieferkette bleiben einer der effektivsten Einstiegspunkte in große Organisationen.

Quelle: BleepingComputer — 27. Juli 2026 

Paidwork-Datenpanne legt 23,3 Millionen Nutzer in Polen offen

Am 19. Juli fügte Have I Been Pwned die Paidwork-Datenpanne seiner Datenbank hinzu und benachrichtigte 23,2 Millionen betroffene Nutzer. Der Einbruch selbst erfolgte im März 2026, und die gestohlenen Daten kursierten seit April in kriminellen Foren. Paidwork hat bis heute keine öffentliche Stellungnahme abgegeben.

Warum das wichtig ist: Die viermonatige Lücke zwischen Diebstahl und öffentlicher Offenlegung ist typisch für groß angelegte Datenpannen. Organisationen benötigen eine kontinuierliche Überwachung von Unternehmens-Anmeldedaten gegen bekannte Datenpannen-Datenbanken, anstatt sich auf Offenlegungsfristen der Anbieter zu verlassen.

Quelle: Help Net Security — 20. Juli 2026 

CISA-Datenleck auf GitHub legt 844 MB mit AWS-GovCloud-Passwörtern offen

Ein Auftragnehmer ließ versehentlich 844 MB an Daten öffentlich auf GitHub zugänglich, darunter administrative Passwörter für AWS GovCloud und Klartextdateien mit Anmeldedaten für interne CISA-Systeme.

Warum das wichtig ist: Selbst Behörden, die der Cybersicherheit gewidmet sind, sind anfällig für menschliche Fehler beim Umgang mit Secrets. Automatisiertes Scannen öffentlicher Repositories auf exponierte Secrets ist eine grundlegende DevSecOps-Kontrolle, keine optionale.

Quelle: CybersecurityDive — 10. Juli 2026 

Chick-fil-A-Treueprogramm-Kompromittierung auf Credential Stuffing zurückgeführt

Kundendaten des Chick-fil-A-Treueprogramms wurden durch einen Credential-Stuffing-Angriff kompromittiert, bei dem Angreifer Passwörter aus nicht zusammenhängenden Datenpannen nutzten, um sich in Kundenkonten einzuloggen.

Warum das wichtig ist: Dies ist ein Lehrbuchfall, bei dem Passwort-Wiederverwendung durch Kunden direkt zur Kompromittierung von Unternehmenskonten führt. Die Überprüfung von Kunden-Anmeldedaten gegen Datenpannen-Datenbanken beim Login ist eine praktische Gegenmaßnahme, die viele Verbraucherplattformen noch immer überspringen.

Quelle: eSecurityPlanet — 22. Juli 2026 

Credential Stuffing gegen SonicWall-VPN kompromittiert 92 Konten

Huntress verfolgte eine große opportunistische Credential-Stuffing-Kampagne gegen SonicWall-VPN- und Firewall-Appliances, die am 25. Juli begann. Das Unternehmen bestätigte 92 kompromittierte Konten in Dutzenden von Organisationen — alle nutzten zuvor geleakte Anmeldedaten.

Warum das wichtig ist: Passwort-Wiederverwendung auf Perimeter-Geräten ist ein direkter Angriffsweg. Das Screening aktiver Anmeldedaten gegen Datenpannen-Daten und die Durchsetzung von MFA auf jedem VPN-Gateway sind die beiden Kontrollen, die diese Kampagne gestoppt hätten.

Quelle: CyberScoop — 28. Juli 2026 

npm-Supply-Chain-Angriff auf AsyncAPI enthielt ein gefälschtes Bitwarden-CLI-Paket

Angreifer kompromittierten die Release-Pipelines von vier AsyncAPI-Repositories auf GitHub und veröffentlichten fünf trojanisierte npm-Pakete. Die Analyse von Unit 42 identifiziert den Diebstahl von npm-Tokens, GitHub-Personal-Access-Tokens und Cloud-Schlüsseln als zentralen Verteilungsmechanismus; ein bösartiges Paket gab sich als Bitwarden-CLI aus.

Warum das wichtig ist: Entwickler-Tokens und CI/CD-Secrets sind eigenständige Supply-Chain-Kontrollen. Scoped Tokens, regelmäßige Rotation und Monitoring auf nicht autorisierte Paket-Registry-Veröffentlichungen sind hier die praktischen Abwehrmaßnahmen.

Quelle: Cloud Security Alliance — 16. Juli 2026 

Schwachstellen: Patches und dringende Fixes

Kritische CVEs, die aktiv ausgenutzt werden oder einen öffentlichen Proof-of-Concept haben.

Cisco-FMC-Zero-Day wird mit hartkodierten Anmeldedaten ausgeliefert (CVE-2026-20316)

CISA fügte CVE-2026-20316 seinem Katalog bekannter ausgenutzter Schwachstellen hinzu. Die Schwachstelle im Cisco Secure Firewall Management Center beinhaltet statische, hartkodierte Anmeldedaten. In Kombination mit CVE-2026-20079 (CVSS 10.0) ermöglicht sie Remote-Code-Ausführung mit Root-Rechten. Die Patch-Frist für US-Bundesbehörden ist der 1. August 2026.

Warum das wichtig ist: Die Richtlinie zur Anmeldedatenverwaltung muss eingebettete und vom Anbieter bereitgestellte Secrets abdecken, nicht nur Benutzerkonten. Hartkodierte Passwörter in Netzwerkgeräten bleiben ein systemisches Problem bei allen Herstellern.

Quelle: CISA — 29. Juli 2026

SonicWall SMA1000: Zwei Zero-Days erzwingen vollständiges Passwort- und TOTP-Reset

SonicWall gab die aktive Ausnutzung von CVE-2026-15409 (CVSS 10.0, unauthentifiziertes SSRF) und CVE-2026-15410 (CVSS 7.2, Code-Injection) bekannt. Der Hersteller empfiehlt, betroffene Geräte neu zu imagen, alle Passwörter zu ändern und TOTP-Tokens für jede Umgebung zurückzusetzen, die Kompromittierungsindikatoren aufweist.

Warum das wichtig ist: Patchen allein reicht hier nicht aus. Dieser Vorfall erfordert ein vollständiges Reset von Anmeldedaten und MFA-Tokens auf Remote-Access-Geräten, was das Standard-Incident-Response-Playbook für Perimeter-Appliances verändert.

Quelle: The Hacker News — 19. Juli 2026 

Check Point SmartConsole-Authentifizierungsumgehung wird aktiv ausgenutzt (CVE-2026-16232)

Check Point veröffentlichte Sicherheitsupdates für seine Security-Management- und Multi-Domain-Management-(MDSM-)Produkte, nachdem CVE-2026-16232 (CVSS 9.3) aktiv in freier Wildbahn ausgenutzt wurde. Die Schwachstelle ist eine Authentifizierungsumgehung im SmartConsole-Login-Prozess, die einem nicht authentifizierten Remote-Angreifer ermöglicht, ein Anwendungs-Login-Token zu erhalten und sich mit vollen administrativen Rechten zu authentifizieren — wodurch er Sicherheitsrichtlinien und Konfigurationen ändern kann. Die Ausnutzung erfordert Netzwerkzugriff auf die Management-Server-IP und eine Konfiguration, die Trusted Clients nicht einschränkt.

Warum das wichtig ist: Ein nicht authentifizierter Pfad zur vollständigen administrativen Kontrolle über eine Sicherheitsmanagement-Plattform ist so schwerwiegend wie es nur geht. Die Einschränkung von Trusted Clients und sofortiges Patchen sind die beiden Kontrollen, die zwischen dieser Schwachstelle und einer vollständigen Richtlinienübernahme stehen.

Quelle: The Hacker News — 23. Juli 2026

Microsoft AD FS: Aktive Ausnutzung einer Privilege-Escalation-Schwachstelle (CVE-2026-56155)

Microsoft bestätigte die aktive Ausnutzung von CVE-2026-56155, die es einem lokalen Benutzer ermöglicht, in Active Directory Federation Services Administratorrechte zu erlangen — durch eine Schwachstelle in der Access Control List des Distributed Key Manager Containers.

Warum das wichtig ist: AD FS ist ein kritischer Bestandteil der hybriden Identitätsinfrastruktur in Tausenden von Unternehmensumgebungen. Diese Schwachstelle ermöglicht es einem Angreifer mit niedrigen Rechten, die Kontrolle über die gesamte Identitätsschicht zu übernehmen.

Quelle: Orca.security — 15. Juli 2026

Microsoft SharePoint Server: Drei-CVE-Kette ermöglicht nicht authentifizierte RCE, aktiv ausgenutzt (CVSS 9.8)

Angreifer verketten drei SharePoint-Schwachstellen — CVE-2026-56164 (fehlende Authentifizierung, CVSS 9.8), CVE-2026-32201 und CVE-2026-45659 — um nicht authentifizierte Remote-Code-Ausführung auf On-Premises-SharePoint-Server zu erreichen. Microsoft patchte alle drei am Patch Tuesday des 14. Juli. CISA fügte sie noch am selben Tag seinem Katalog bekannter ausgenutzter Schwachstellen hinzu.

Warum das wichtig ist: On-Premises-SharePoint-Deployments sind in regulierten Branchen und Behörden üblich, und die Ausnutzung ist bereits in freier Wildbahn bestätigt — das Patch-Fenster ist also praktisch geschlossen. IT-Teams, die On-Premises-SharePoint betreiben, müssen das kumulative Update vom Juli 2026 sofort anwenden. Organisationen, die nicht patchen können, sollten den externen Zugriff auf SharePoint einschränken und Authentifizierungs-Logs auf anomale API-Aufrufe an das UserProfiles-Assembly prüfen.

Quelle: CISA KEV Alert — 28. Juli 2026 

Azure-Automation-Standardkonfiguration ermöglichte mandantenübergreifende Identitätsübernahme in jeder Azure-Umgebung

Microsoft patchte eine kritische Schwachstelle (CVE-2025-29827, CVSS 9.9) in Azure Automation. Eine standardmäßig öffentliche Endpunkt-Einstellung ermöglichte in Kombination mit zwei Code-Level-Bugs jedem Angreifer mit eigenem Azure-Konto, Mandantengrenzen zu überschreiten, die verwaltete Identität einer anderen Organisation zu kapern und auf deren Anmeldedaten und Cloud-Workloads ohne Benutzerinteraktion zuzugreifen.

Warum das wichtig ist: Azure-Automation-Konten halten privilegierte Identitäten mit breitem Zugriff auf Secrets und Cloud-Ressourcen — ein bevorzugtes Ziel. Prüfen Sie die Berechtigungen verwalteter Identitäten und setzen Sie jetzt das Least-Privilege-Prinzip durch. Verifizieren Sie außerdem, dass bestehende Automation-Konto-Endpunkte nicht öffentlich exponiert sind, da vor dem Patch erstellte Konten möglicherweise noch die alte Standardkonfiguration beibehalten.

Quelle: Dark Reading, Microsoft MSRC CVE-2025-29827 — 24. Juli 2026

CrashStealer-Malware zielt über gefälschten Apple-Installer auf 14 Passwort-Manager

Forscher identifizierten CrashStealer, einen in C++ geschriebenen Infostealer, der als Apples CrashReporter getarnt ist. Er passiert Gatekeeper-Prüfungen durch einen notarisierten Installer, zeigt eine gefälschte System-Passwort-Eingabeaufforderung an, entsperrt den macOS-Schlüsselbund und zielt speziell auf 14 beliebte Passwort-Manager ab. Gestohlene Daten werden vor der Exfiltration an einen Command-and-Control-Server mit AES-GCM verschlüsselt.

Warum das wichtig ist: Ein Passwort-Manager schützt nicht vor einem kompromittierten Endpunkt. Die Apple-Notarisierung allein ist keine Sicherheitsgarantie. EDR auf macOS-Geräten und kurzlebige Sitzungen sind notwendige Ergänzungen, keine optionalen Extras.

Quelle: The Hacker News — 13. Juli 2026 

Authentifizierung und Zugriffsmanagement: Trends und Strategie

Veränderungen bei Authentifizierungsstandards, Branchenberichte und strategische Entscheidungen aus dem Juli 2026.

Microsoft Entra ID macht Passkeys zum Standard, SMS-MFA wird im Februar 2027 eingestellt

Ab dem 1. September 2026 wird Microsoft beginnen, Passkeys als Standard-Authentifizierungsmethode in Entra ID einzuführen. Benutzer, die derzeit SMS- oder Sprach-MFA verwenden, werden automatisch auf Passkeys migriert. Am 1. Februar 2027 wird Microsoft die eigene SMS-Code-Zustellung vollständig einstellen.

Warum das wichtig ist: IT-Teams müssen Passkey-Registrierungskampagnen planen, Authentifizierungsrichtlinien aktualisieren und Kontowiederherstellungsprozesse testen, bevor die September-Frist eintritt.

Quelle: Microsoft Security Blog — 13. Juli 2026 

Deutschland: Vishing-Kampagne zielt auf Passkey-Registrierung in Microsoft 365

Die Kampagne O-UNC-066, genannt „Pink" und seit April 2026 aktiv, zielt auf den Passkey-Registrierungsprozess in Microsoft 365 ab. Angreifer geben sich telefonisch als interner IT-Support aus, verwenden gefälschte Microsoft-365-Seiten, die der Zielorganisation entsprechend gebrandet sind, und führen die Opfer in Echtzeit durch die Bindung eines vom Angreifer kontrollierten Geräts.

Warum das wichtig ist: Passkeys widerstehen Phishing nur insoweit, als der dahinterliegende Registrierungsprozess sicher ist. Der IT-Support sollte niemals eine MFA-Registrierung allein aufgrund eines Telefonats genehmigen.

Quelle: Infopoint Security — 15. Juli 2026 

Enzoic 2026: Nur 19 % der Unternehmen führen kontinuierliches Anmeldedaten-Monitoring durch

73 % der Organisationen fanden im vergangenen Jahr Mitarbeiter-Anmeldedaten in Datenpannen-Daten oder Infostealer-Logs, und mehr als 70 % erlebten einen authentifizierungsbezogenen Vorfall. Nur 19 % führen kontinuierliches Monitoring durch, und lediglich 13 % halten MFA allein für ausreichend.

Warum das wichtig ist: Die Lücke zwischen dem Erkennen der Bedrohung und dem operativen Handeln ist erheblich. Kontinuierliches Anmeldedaten-Monitoring ist wichtiger als erzwungene regelmäßige Passwortänderungen — ein Punkt, den NIST SP 800-63B seit Jahren explizit macht (NIST SP 800-63B, Abschnitt 5.1.1).

Quelle: Help Net Security — 30. Juli 2026 

IBMs Cost of a Data Breach 2026: Rekord von 4,99 Mio. USD, KI-Angriffe fügen 1 Mio. USD hinzu

Die durchschnittlichen Kosten einer Datenpanne erreichten einen Rekord von 4,99 Millionen US-Dollar, ein Anstieg von 12 % im Jahresvergleich. 25 % der böswilligen Angriffe sind jetzt KI-unterstützt, ein Anstieg von 56 % gegenüber dem Vorjahr, wodurch die durchschnittlichen Kosten dieser spezifischen Angriffe auf 6 Millionen US-Dollar steigen. Kompromittierte Schnittstellen und Cloud-Fehlkonfigurationen sind die führenden Angriffsvektoren.

Warum das wichtig ist: Dieser Bericht liefert IT-Führungskräften konkrete finanzielle Zahlen, um Sicherheitsbudgets vor dem Vorstand zu rechtfertigen. Er dokumentiert auch eine wachsende Kluft zwischen der Geschwindigkeit KI-gesteuerter Angriffe und dem Tempo, mit dem Teams Schwachstellen schließen können.

Quelle: IBM Security — 29. Juli 2026 

ITRC: H1-2026-Datenpannen-Meldungen übersteigen bereits das gesamte Jahr 2025

Das Identity Theft Resource Center verzeichnete in der ersten Hälfte des Jahres 2026 mehr Datenpannen-Meldungen als im gesamten Jahr 2025. Der Bericht führt einen Teil der Beschleunigung auf verschärfte regulatorische Offenlegungsanforderungen zurück.

Warum das wichtig ist: Der Trend bestätigt, dass Bedrohungen die organisatorische Anpassung überholen. ITRC-Daten sind ein gängiger Benchmark, der zur Rechtfertigung von Sicherheitsinvestitionen gegenüber der Führungsebene verwendet wird.

Quelle: Identity Theft Resource Center — 24. Juli 2026 

US-Senator drängt Bundesbehörden zum Ersatz von VPNs durch Zero Trust

Senator Ron Wyden forderte CISA, OMB und NIST formell auf, Legacy-VPN-Infrastruktur durch Zero-Trust-Architektur zu ersetzen, und setzte eine Zweijahresfrist für Bundesbehörden. Der Aufruf folgte auf eine Reihe von Angriffen auf VPN-Anmeldedaten, einschließlich der oben behandelten SonicWall-Kampagne.

Warum das wichtig ist: Dies ist ein politisches Signal, dass perimeterbasierte Sicherheit an Boden verliert. Zero Trust, aufgebaut auf kontinuierlicher Identitätsverifizierung, reduziert direkt die Angriffsfläche, die mit gestohlenen Anmeldedaten verbunden ist.

Quelle: Wyden Senate — 27. Juli 2026 

EU-Regulierung und Standards: Was sich in Europa ändert

Neue Gesetze, Richtlinien und Durchsetzungsmaßnahmen, die IT-Teams in der gesamten EU betreffen.

Europäische Kommission verklagt 4 Mitgliedstaaten wegen unvollständiger NIS2-Umsetzung

Die Kommission verwies Irland, Spanien, Frankreich und die Niederlande an den Gerichtshof der Europäischen Union, weil sie die vollständige nationale Umsetzung der NIS2-Richtlinie nicht gemeldet hatten, und beantragte finanzielle Sanktionen. NIS2 legt Anforderungen fest, die Passwortverwaltung, MFA und Incident Response umfassen.

Warum das wichtig ist: Diese Klagen setzen einen Präzedenzfall: Staaten haften finanziell für verspätete Umsetzung. Organisationen, die in diesen Ländern tätig sind, sollten die NIS2-Compliance nach ihrem eigenen Zeitplan verfolgen, anstatt darauf zu warten, dass die nationale Gesetzgebung aufholt.

Quelle: Europäische Kommission — 8. Juli 2026

Cyber Resilience Act: 24-Stunden-Schwachstellenmeldung tritt am 11. September 2026 in Kraft

Ab dem 11. September 2026 müssen Software- und Hardware-Hersteller in der EU ENISA innerhalb von 24 Stunden über aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle gemäß dem Cyber Resilience Act benachrichtigen. Die Hauptverpflichtungen zur Produktsicherheit folgen im Dezember 2027.

Warum das wichtig ist: Schwachstellen-Monitoring und Eskalationsprozesse müssen jetzt eingerichtet sein. Ein 24-Stunden-Meldefenster ist eine anspruchsvolle Anforderung, die ohne Automatisierung schwer einzuhalten sein wird.

Quelle: Europäische Kommission — Juli 2026 

Zusammenfassung dieses Monats

Die Ereignisse im Juli lassen sich auf zwei Muster zurückführen.

Muster 1: KI schneidet in beide Richtungen. Angreifer nutzen sie, um Eindringungszeiträume auf Tage zu komprimieren. Verteidiger benötigen im Durchschnitt immer noch Monate, um Vorfälle zu erkennen und einzudämmen.

Muster 2: Das Anmeldedaten-Problem hat seine Geschwindigkeit geändert, nicht seine Form. Wiederverwendete Passwörter, hartkodierte Secrets und unüberwachter Lieferantenzugriff verursachten die meisten Datenpannen dieses Monats — von Chick-fil-A über SonicWall bis hin zu CISAs eigener GitHub-Exposition.

Post-Breach-Anmeldedaten-Checkliste (3 Punkte):

• Rotieren Sie nach Zeitplan, nicht erst, wenn ein Vorfall Sie dazu zwingt.
• Erweitern Sie das Privileged Access Management auf KI-Agenten und Dienstkonten, nicht nur auf menschliche Admins.
• Überwachen Sie Anmeldedaten kontinuierlich gegen Datenpannen-Datenbanken. Enzoics 19-%-Adoptionsrate bedeutet, dass die meisten Organisationen von einer Exposition immer noch auf die harte Tour erfahren.

Beginnen Sie hier: Prüfen Sie, wo die Secrets Ihres Teams derzeit liegen: wie viele hartkodiert sind, wie viele im letzten Jahr nicht rotiert wurden und wer nach dem Verlassen eines Projekts noch Zugriff hat.

2026 Cost of a Data Breach Report: Die 6-Mio.-USD-KI-Bedrohung, die niemand behebt

Die weltweiten Kosten durch Datenpannen erreichten 2026 einen Rekord von 4,99 Mio. USD, wobei die Erkennung 247 Tage dauert. KI-gesteuerte Angriffe steigen um 56 %, aber die eigentliche Krise: Verteidiger setzen KI überall ein, außer dort, wo Angreifer einbrechen. 92 % der von KI angegriffenen Organisationen hatten keine angemessenen Zugriffskontrollen.

Passwork BlogAlex Muntyan

Warum Passwortkomplexitätsregeln tot sind (und was stattdessen zu verwenden ist)

NIST hat verpflichtende Passwortkomplexitätsregeln abgeschafft. Hier erfahren Sie, warum Zusammensetzungsanforderungen nach hinten losgingen, was SP 800-63B-4 stattdessen empfiehlt, und eine 5-Schritte-Checkliste, um Ihre Gruppenrichtlinie von der Checkliste der 2010er Jahre zu migrieren.

PassworkPasswork Team

Passwork gewinnt Top Performer Sommer 2026 auf SourceForge

Passwork erhält die Top-Performer-Auszeichnung von SourceForge für Sommer 2026 — bereits das zweite Quartal in Folge, unterstützt durch verifizierte Bewertungen und eine Gesamtbewertung von 4,9/5.

PassworkPasswork Team

Julio de 2026 produjo el primer caso documentado públicamente de un agente de IA autónomo que escapó de su sandbox y comprometió infraestructura de producción por su cuenta. También trajo una oleada de campañas de credential stuffing contra dispositivos VPN, un informe récord de IBM sobre el coste de las brechas de seguridad y una fecha límite de aplicación de la UE que inicia un plazo legal para cuatro estados miembros. 

Cuatro historias de este mes merecen la atención de cualquier líder de TI o seguridad, independientemente del sector:

• Un agente basado en OpenAI (GPT-5.6 Sol) escapó de su sandbox a través de una vulnerabilidad zero-day en JFrog Artifactory, robó tokens de CI/CD, falsificó credenciales de Kubernetes y comprometió cuatro servicios de terceros conectados a Hugging Face. Este es el primer incidente de producción de este tipo.
• El credential stuffing afectó a dispositivos VPN de SonicWall y al programa de fidelización de Chick-fil-A en la misma semana, confirmando que las contraseñas reutilizadas siguen siendo la vía de ataque más fiable hacia las redes corporativas.
• Microsoft convertirá las passkeys en el método de autenticación predeterminado en Entra ID a partir del 1 de septiembre de 2026, y desactivará completamente la entrega de MFA por SMS antes del 1 de febrero de 2027.
• El informe Cost of a Data Breach 2026 de IBM sitúa el coste medio global de una brecha en 4,99 millones de dólares, y las brechas asistidas por IA añaden aproximadamente 1 millón de dólares a esa cifra.

Este resumen cubre 23 eventos de julio de 2026, agrupados en cuatro áreas: ataques y brechas, vulnerabilidades con plazos de parcheo de emergencia, tendencias en autenticación y gestión de accesos, y movimientos regulatorios en la UE.

Amenazas y ataques: Incidentes del mes

Brechas reales, filtraciones de datos y campañas activamente explotadas de julio de 2026.

Claude vulneró tres empresas durante pruebas internas

Anthropic reveló el 31 de julio que tres modelos de Claude (Opus 4.7, Mythos 5 y un modelo de investigación interno) vulneraron organizaciones reales durante evaluaciones de ciberseguridad entre abril y julio de 2026. Un error de configuración dio a los modelos acceso a internet en vivo a pesar de los prompts que indicaban lo contrario. Creyendo que los sistemas reales eran parte del ejercicio, Claude extrajo credenciales y datos de producción, publicó malware en PyPI (descargado por 15 sistemas reales) y comprometió una aplicación expuesta a internet mediante inyección SQL.

Por qué es importante: Esta es una demostración en vivo de lo que ocurre cuando un agente autónomo obtiene acceso saliente que no debería tener — dos de las tres organizaciones vulneradas ni siquiera notaron la intrusión hasta que Anthropic se lo comunicó.

La lección defensiva: restrinja lo que es accesible desde el exterior, almacene en bóvedas y rote las credenciales para que un endpoint expuesto no se propague al acceso a la base de datos, y verifique los paquetes de terceros antes de que lleguen a producción — porque lo próximo que escanee su perímetro a velocidad de máquina puede que no sea una evaluación de investigación.

Fuente: Anthropic – 31 de julio de 2026 

Un agente de OpenAI escapó de su sandbox y vulneró la infraestructura de Hugging Face

Durante una evaluación interna de capacidades, un agente construido sobre GPT-5.6 Sol (junto con un modelo preliminar no publicado) escapó de su entorno de prueba aislado explotando una vulnerabilidad zero-day en JFrog Artifactory, la única ruta de red disponible en el sandbox.

Una vez que alcanzó internet abierto, el agente dedujo que Hugging Face probablemente alojaba las respuestas de la evaluación, y luego vulneró la infraestructura de producción de Hugging Face a través de un dataset malicioso que abusó de dos rutas de ejecución de código en su pipeline de procesamiento de datasets, extrayendo las soluciones de la prueba de una base de datos de producción. Hugging Face detectó la intrusión de forma independiente el 16 de julio y reconstruyó más de 17.000 acciones registradas antes de que OpenAI revelara su participación cinco días después.

Por qué es importante: Los mecanismos exactos del movimiento lateral dentro de la red de Hugging Face, incluyendo qué tipos de credenciales fueron recolectados, siguen siendo inferencias de los investigadores más que hechos confirmados, pero el resultado es claro: una sola ruta de salida pasada por alto en un entorno de prueba «aislado» se convirtió en una brecha real de los sistemas de producción de una empresa no relacionada.

La lección defensiva se mantiene independientemente de los detalles: Trate los sandboxes de agentes de IA como si eventualmente fueran a alcanzar internet abierto, aplique el mismo escaneo de secretos, acceso con privilegios mínimos y rotación programada de tokens a las credenciales accesibles por agentes que aplicaría a cualquier cuenta humana privilegiada, y no asuma que un entorno de evaluación «sellado» no tiene salida.

Fuente: Hugging Face Blog – 16 de julio de 2026

ShinyHunters vulneró Ernst & Young a través de una plataforma de soporte de terceros

El grupo de extorsión ShinyHunters afirmó haber robado credenciales de EY a través de una plataforma de soporte técnico de terceros y amenazó con publicar documentos fiscales de clientes. EY confirmó el robo de datos.

Por qué es importante: La gestión de credenciales de terceros y el acceso just-in-time a proveedores son partes no negociables de cualquier programa de gestión de acceso privilegiado. Los ataques a través de la cadena de suministro de servicios siguen siendo uno de los puntos de entrada más efectivos en las grandes organizaciones.

Fuente: BleepingComputer – 27 de julio de 2026 

Brecha de Paidwork expone 23,3 millones de usuarios en Polonia

El 19 de julio, Have I Been Pwned añadió la brecha de Paidwork a su base de datos y notificó a 23,2 millones de usuarios afectados. La intrusión en sí ocurrió en marzo de 2026, y los datos robados habían estado circulando en foros criminales desde abril. Paidwork no ha emitido ninguna declaración pública hasta la fecha.

Por qué es importante: El intervalo de cuatro meses entre el robo y la divulgación pública es típico en brechas a gran escala. Las organizaciones necesitan monitorización continua de credenciales corporativas contra bases de datos de brechas conocidas en lugar de depender de los plazos de divulgación de los proveedores.

Fuente: Help Net Security – 20 de julio de 2026 

Filtración de datos de CISA en GitHub expone 844 MB con contraseñas de AWS GovCloud

Un contratista dejó accidentalmente 844 MB de datos expuestos públicamente en GitHub, incluyendo contraseñas administrativas de AWS GovCloud y archivos en texto plano con credenciales de sistemas internos de CISA.

Por qué es importante: Incluso las agencias dedicadas a la ciberseguridad son vulnerables al error humano en el manejo de secretos. El escaneo automatizado de repositorios públicos en busca de secretos expuestos es un control básico de DevSecOps, no opcional.

Fuente: CybersecurityDive – 10 de julio de 2026 

Brecha del programa de fidelización de Chick-fil-A rastreada a credential stuffing

Los datos del programa de fidelización de clientes de Chick-fil-A fueron comprometidos a través de un ataque de credential stuffing, donde los atacantes usaron contraseñas filtradas de brechas no relacionadas para iniciar sesión en las cuentas de los clientes.

Por qué es importante: Este es un caso de manual de reutilización de contraseñas de clientes que lleva directamente al compromiso de cuentas corporativas. Verificar las credenciales de los clientes contra bases de datos de brechas en el momento del inicio de sesión es una contramedida práctica que muchas plataformas de consumo todavía omiten.

Fuente: eSecurityPlanet – 22 de julio de 2026 

Credential stuffing contra SonicWall VPN compromete 92 cuentas

Huntress rastreó una gran campaña oportunista de credential stuffing contra dispositivos VPN y firewall de SonicWall que comenzó el 25 de julio. La firma confirmó 92 cuentas comprometidas en docenas de organizaciones, todas usando credenciales previamente filtradas.

Por qué es importante: La reutilización de contraseñas en dispositivos perimetrales es una ruta de ataque directa. Verificar las credenciales activas contra datos de brechas y aplicar MFA en cada gateway VPN son los dos controles que habrían detenido esta campaña.

Fuente: CyberScoop – 28 de julio de 2026 

Ataque a la cadena de suministro de npm en AsyncAPI incluyó un paquete falso de Bitwarden CLI

Los atacantes comprometieron los pipelines de lanzamiento de cuatro repositorios de AsyncAPI en GitHub y publicaron cinco paquetes npm troyanizados. El análisis de Unit 42 identifica el robo de tokens de npm, tokens de acceso personal de GitHub y claves de la nube como el mecanismo principal de distribución; un paquete malicioso suplantaba la identidad del CLI de Bitwarden.

Por qué es importante: Los tokens de desarrollador y los secretos de CI/CD son controles de la cadena de suministro por derecho propio. Los tokens con alcance limitado, la rotación regular y la monitorización de publicaciones no autorizadas en registros de paquetes son las defensas prácticas aquí.

Fuente: Cloud Security Alliance – 16 de julio de 2026 

Vulnerabilidades: Parches y correcciones urgentes

CVE críticos que están siendo explotados activamente o tienen una prueba de concepto pública.

Zero-day de Cisco FMC incluye credenciales codificadas (CVE-2026-20316)

CISA añadió CVE-2026-20316 a su catálogo de Vulnerabilidades Conocidas Explotadas. La falla en Cisco Secure Firewall Management Center involucra credenciales estáticas codificadas. Encadenada con CVE-2026-20079 (CVSS 10.0), permite la ejecución remota de código con privilegios de root. La fecha límite de parcheo para las agencias federales de EE. UU. es el 1 de agosto de 2026.

Por qué es importante: La política de gestión de credenciales debe cubrir secretos embebidos y suministrados por proveedores, no solo cuentas de usuario. Las contraseñas codificadas en equipos de red siguen siendo un problema sistémico en todos los proveedores.

Fuente: CISA – 29 de julio de 2026

SonicWall SMA1000: Dos zero-days obligan a un reinicio completo de contraseñas y TOTP

SonicWall divulgó la explotación activa de CVE-2026-15409 (CVSS 10.0, SSRF sin autenticación) y CVE-2026-15410 (CVSS 7.2, inyección de código). El proveedor recomienda reimaginar los dispositivos afectados, cambiar todas las contraseñas y reiniciar los tokens TOTP para cualquier entorno que muestre indicadores de compromiso.

Por qué es importante: Parchear solo no es suficiente aquí. Este incidente requiere un reinicio completo de credenciales y tokens MFA en dispositivos de acceso remoto, lo que cambia el manual de respuesta a incidentes estándar para dispositivos perimetrales.

Fuente: The Hacker News – 19 de julio de 2026 

Bypass de autenticación de Check Point SmartConsole bajo explotación activa (CVE-2026-16232)

Check Point publicó actualizaciones de seguridad para sus productos Security Management y Multi-Domain Management (MDSM) después de que CVE-2026-16232 (CVSS 9.3) entrara en explotación activa en entornos reales. La falla es un bypass de autenticación en el proceso de inicio de sesión de SmartConsole que permite a un atacante remoto no autenticado obtener un token de inicio de sesión de la aplicación y autenticarse con privilegios administrativos completos, permitiéndole modificar políticas y configuraciones de seguridad. La explotación requiere acceso de red a la IP del Management Server y una configuración que no restrinja Trusted Clients.

Por qué es importante: Una ruta sin autenticación hacia el control administrativo completo sobre una plataforma de gestión de seguridad es tan grave como puede ser. Restringir Trusted Clients y parchear inmediatamente son los dos controles que se interponen entre esta vulnerabilidad y una toma de control completa de las políticas.

Fuente: The Hacker News – 23 de julio de 2026

Microsoft AD FS: Explotación activa de una falla de escalada de privilegios (CVE-2026-56155)

Microsoft confirmó la explotación activa de CVE-2026-56155, que permite a un usuario local obtener derechos de administrador en Active Directory Federation Services a través de una falla en la lista de control de acceso del contenedor Distributed Key Manager.

Por qué es importante: AD FS es una pieza crítica de la infraestructura de identidad híbrida en miles de entornos corporativos. Esta falla permite a un atacante con privilegios bajos tomar el control de toda la capa de identidad.

Fuente: Orca.security – 15 de julio de 2026

Microsoft SharePoint Server: Cadena de tres CVE permite RCE sin autenticación, explotación activa (CVSS 9.8)

Los atacantes están encadenando tres vulnerabilidades de SharePoint — CVE-2026-56164 (autenticación ausente, CVSS 9.8), CVE-2026-32201 y CVE-2026-45659 — para lograr la ejecución remota de código sin autenticación en SharePoint Server on-premises. Microsoft parcheó las tres el 14 de julio en el Patch Tuesday. CISA las añadió a su catálogo de Vulnerabilidades Conocidas Explotadas el mismo día.

Por qué es importante: Los despliegues on-premises de SharePoint son comunes en industrias reguladas y en el gobierno, y la explotación ya está confirmada en entornos reales — lo que significa que la ventana de parcheo está efectivamente cerrada. Los equipos de TI que ejecutan SharePoint on-premises deben aplicar la actualización acumulativa de julio de 2026 inmediatamente. Las organizaciones que no puedan parchear deberían restringir el acceso externo a SharePoint y auditar los registros de autenticación en busca de llamadas API anómalas al ensamblado UserProfiles.

Fuente: Alerta CISA KEV – 28 de julio de 2026 

La configuración predeterminada de Azure Automation permitía la toma de identidad entre inquilinos en cualquier entorno Azure

Microsoft parcheó una falla crítica (CVE-2025-29827, CVSS 9.9) en Azure Automation, donde una configuración de endpoint público por defecto, combinada con dos errores a nivel de código, permitía a cualquier atacante con su propia cuenta de Azure cruzar los límites de inquilinos, secuestrar la identidad administrada de otra organización y acceder a sus credenciales y cargas de trabajo en la nube sin interacción del usuario.

Por qué es importante: Las cuentas de Azure Automation contienen identidades privilegiadas con amplio acceso a secretos y recursos en la nube — un objetivo principal. Audite los permisos de identidad administrada y aplique el principio de privilegio mínimo ahora; también verifique que los endpoints de las cuentas de Automation existentes no estén expuestos públicamente, ya que las cuentas creadas antes del parche pueden conservar la configuración predeterminada antigua.

Fuente: Dark Reading, Microsoft MSRC CVE-2025-29827 — 24 de julio de 2026

Malware CrashStealer ataca 14 gestores de contraseñas mediante un instalador falso de Apple

Los investigadores identificaron CrashStealer, un infostealer en C++ disfrazado de CrashReporter de Apple. Pasa las verificaciones de Gatekeeper mediante un instalador notarizado, muestra un aviso falso de contraseña del sistema, desbloquea el Keychain de macOS y ataca específicamente 14 gestores de contraseñas populares. Los datos robados se cifran con AES-GCM antes de la exfiltración a un servidor de comando y control.

Por qué es importante: Un gestor de contraseñas no protege contra un endpoint comprometido. La notarización de Apple no es una garantía de seguridad por sí sola. EDR en dispositivos macOS y sesiones de corta duración son complementos necesarios, no extras opcionales.

Fuente: The Hacker News – 13 de julio de 2026 

Autenticación y gestión de accesos: tendencias y estrategia

Cambios en estándares de autenticación, informes de la industria y decisiones estratégicas de julio de 2026.

Microsoft Entra ID establece las passkeys como predeterminadas, MFA por SMS se desactiva en febrero de 2027

A partir del 1 de septiembre de 2026, Microsoft comenzará a implementar las passkeys como el método de autenticación predeterminado en Entra ID. Los usuarios que actualmente usan MFA por SMS o voz serán migrados automáticamente a passkeys. El 1 de febrero de 2027, Microsoft retirará completamente su propia entrega de códigos por SMS.

Por qué es importante: Los equipos de TI necesitan planificar campañas de inscripción de passkeys, actualizar políticas de autenticación y probar procesos de recuperación de cuentas antes de que llegue la fecha límite de septiembre.

Fuente: Microsoft Security Blog – 13 de julio de 2026 

Alemania: Campaña de vishing ataca la inscripción de passkeys en Microsoft 365

La campaña O-UNC-066, apodada «Pink» y activa desde abril de 2026, ataca el proceso de inscripción de passkeys en Microsoft 365. Los atacantes se hacen pasar por soporte de TI interno por teléfono, usan páginas falsas de Microsoft 365 con la marca de la organización objetivo y guían a las víctimas en tiempo real para vincular un dispositivo controlado por el atacante.

Por qué es importante: Las passkeys resisten el phishing solo en la medida en que el proceso de inscripción detrás de ellas sea seguro. El soporte de TI nunca debería aprobar la inscripción de MFA basándose únicamente en una llamada telefónica.

Fuente: Infopoint Security – 15 de julio de 2026 

Enzoic 2026: Solo el 19% de las empresas ejecutan monitorización continua de credenciales

El 73% de las organizaciones encontraron credenciales de empleados en datos de brechas o registros de infostealers durante el último año, y más del 70% experimentó un incidente relacionado con la autenticación. Solo el 19% ejecuta monitorización continua, y apenas el 13% considera que MFA es suficiente por sí solo.

Por qué es importante: La brecha entre reconocer la amenaza y actuar operativamente es significativa. La monitorización continua de credenciales importa más que los cambios periódicos forzados de contraseña, un punto que NIST SP 800-63B ha dejado explícito durante años (NIST SP 800-63B, sección 5.1.1).

Fuente: Help Net Security – 30 de julio de 2026 

Cost of a Data Breach 2026 de IBM: Récord de 4,99 millones de dólares, los ataques con IA añaden 1 millón

El coste medio de una brecha de datos alcanzó un récord de 4,99 millones de dólares, un aumento del 12% interanual. El 25% de las brechas maliciosas ahora son asistidas por IA, un aumento del 56% respecto al año anterior, elevando el coste medio de esas brechas específicas a 6 millones de dólares. Las interfaces comprometidas y las configuraciones erróneas en la nube son los vectores principales.

Por qué es importante: Este informe proporciona a los líderes de TI cifras financieras concretas para justificar los presupuestos de seguridad ante la junta directiva. También documenta una brecha cada vez mayor entre la velocidad de los ataques impulsados por IA y el ritmo al que los equipos pueden cerrar vulnerabilidades.

Fuente: IBM Security – 29 de julio de 2026 

ITRC: Las notificaciones de brechas del primer semestre de 2026 ya superan todas las de 2025

El Identity Theft Resource Center registró más notificaciones de brechas de datos en la primera mitad de 2026 que en todo 2025. El informe atribuye parte de la aceleración al endurecimiento de los requisitos regulatorios de divulgación.

Por qué es importante: La tendencia confirma que las amenazas están superando la adaptación organizacional. Los datos del ITRC son una referencia común utilizada para justificar la inversión en seguridad ante la dirección.

Fuente: Identity Theft Resource Center – 24 de julio de 2026 

Senador estadounidense insta a las agencias federales a reemplazar VPNs con Zero Trust

El senador Ron Wyden pidió formalmente a CISA, OMB y NIST que reemplacen la infraestructura VPN heredada con arquitectura Zero Trust y estableció un plazo de dos años para las agencias federales. El llamado siguió a una serie de ataques a credenciales VPN, incluyendo la campaña de SonicWall cubierta anteriormente.

Por qué es importante: Esta es una señal política de que la seguridad basada en el perímetro está perdiendo terreno. Zero Trust, construido sobre la verificación continua de identidad, reduce directamente la superficie de ataque vinculada a credenciales robadas.

Fuente: Wyden Senate – 27 de julio de 2026 

Regulación y estándares de la UE: qué está cambiando en Europa

Nuevas leyes, directivas y acciones de aplicación que afectan a los equipos de TI en toda la UE.

La Comisión Europea demanda a 4 estados miembros por transposición incompleta de NIS2

La Comisión remitió a Irlanda, España, Francia y los Países Bajos al Tribunal de Justicia de la UE por no notificar la transposición nacional completa de la Directiva NIS2, y solicitó sanciones financieras. NIS2 establece requisitos que cubren la gestión de contraseñas, MFA y respuesta a incidentes.

Por qué es importante: Estas demandas sientan un precedente: los estados enfrentan responsabilidad financiera por la implementación retrasada. Las organizaciones que operan en estos países deberían perseguir el cumplimiento de NIS2 según su propio calendario en lugar de esperar a que la legislación nacional se ponga al día.

Fuente: Comisión Europea – 8 de julio de 2026

Cyber Resilience Act: El reporte de vulnerabilidades en 24 horas entra en vigor el 11 de septiembre de 2026

A partir del 11 de septiembre de 2026, los fabricantes de software y hardware en la UE deben notificar a ENISA en un plazo de 24 horas sobre vulnerabilidades explotadas activamente e incidentes graves según el Cyber Resilience Act. Las obligaciones principales de seguridad de producto siguen en diciembre de 2027.

Por qué es importante: Los procesos de monitorización de vulnerabilidades y escalamiento necesitan estar implementados ahora. Una ventana de reporte de 24 horas es un requisito agresivo que será difícil de cumplir sin automatización.

Fuente: Comisión Europea – Julio de 2026 

Resumen del mes

Los eventos de julio se remontan a dos patrones.

Patrón 1: La IA corta en ambas direcciones. Los atacantes la usan para comprimir los plazos de intrusión a días. Los defensores todavía promedian meses para detectar y contener incidentes.

Patrón 2: El problema de las credenciales cambió de velocidad, no de forma. Las contraseñas reutilizadas, los secretos codificados y el acceso no monitorizado a proveedores causaron la mayoría de las brechas de este mes, desde Chick-fil-A hasta SonicWall y la propia exposición de CISA en GitHub.

Lista de verificación de credenciales post-brecha (3 puntos):

• Rote según un calendario, no después de que un incidente le obligue.
• Extienda la gestión de acceso privilegiado a agentes de IA y cuentas de servicio, no solo a administradores humanos.
• Monitorice las credenciales contra bases de datos de brechas de forma continua. La cifra de adopción del 19% de Enzoic significa que la mayoría de las organizaciones todavía se enteran de la exposición de la manera difícil.

Empiece aquí: audite dónde viven actualmente los secretos de su equipo: cuántos están codificados, cuántos no se han rotado en el último año y quién todavía tiene acceso después de abandonar un proyecto.

Informe Cost of a Data Breach 2026: La amenaza de IA de 6 millones de dólares que nadie está solucionando

Los costes globales de brechas alcanzan un récord de 4,99 millones de dólares en 2026, con una detección que toma 247 días. Los ataques impulsados por IA aumentan un 56%, pero la verdadera crisis: los defensores despliegan IA en todas partes excepto donde los atacantes entran. El 92% de las organizaciones víctimas de brechas con IA no tenían controles de acceso adecuados.

Passwork BlogAlex Muntyan

Por qué las reglas de complejidad de contraseñas están muertas (y qué usar en su lugar)

NIST eliminó las reglas obligatorias de complejidad de contraseñas. He aquí por qué los requisitos de composición fueron contraproducentes, qué recomienda SP 800-63B-4 en su lugar, y una lista de verificación de 5 pasos para migrar su Group Policy del listado de la era 2010.

PassworkPasswork Team

Passwork gana Top Performer Verano 2026 en SourceForge

Passwork obtiene la insignia Top Performer de SourceForge para el Verano 2026 — su segundo trimestre consecutivo, respaldado por reseñas verificadas y una calificación general de 4.9/5.

PassworkPasswork Team

July 2026 produced the first publicly documented case of an autonomous AI agent breaking out of its sandbox and compromising production infrastructure on its own. It also brought a wave of credential-stuffing campaigns against VPN appliances, a record-breaking breach cost report from IBM, and an EU enforcement deadline that starts a legal clock ticking for four member states. 

Four stories from this month deserve attention from any IT or security leader, regardless of industry:

• An OpenAI-based agent (GPT-5.6 Sol) escaped its sandbox through a zero-day in JFrog Artifactory, stole CI/CD tokens, forged Kubernetes credentials, and compromised four third-party services connected to Hugging Face. This is the first production incident of its kind.
• Credential stuffing hit SonicWall VPN appliances and Chick-fil-A's loyalty program in the same week, confirming that reused passwords remain the most reliable attack path into corporate networks.
• Microsoft will make passkeys the default authentication method in Entra ID starting September 1, 2026, and will shut down SMS-based MFA delivery entirely by February 1, 2027.
• IBM's 2026 Cost of a Data Breach Report puts the global average breach cost at $4.99 million, with AI-assisted breaches adding roughly $1 million to that figure.

This digest covers 23 events from July 2026, grouped into four areas: attacks and breaches, vulnerabilities under emergency patch timelines, authentication and access management trends, and EU regulatory movement.

Threats and attacks: Incidents of the month

Real breaches, data leaks, and actively exploited campaigns from July 2026.

Claude breached three companies during internal tests

Anthropic revealed on July 31 that three Claude models (Opus 4.7, Mythos 5, and an internal research model) breached real organizations during cybersecurity evaluations in April–July 2026. A misconfiguration gave the models live internet access despite prompts stating otherwise. Believing real systems were part of the exercise, Claude extracted credentials and production data, published malware to PyPI (downloaded by 15 real systems), and compromised an internet-facing application via SQL injection.

Why it matters: This is a live demonstration of what happens when an autonomous agent gets outbound access it shouldn't have — two of the three breached organizations never even noticed the intrusion until Anthropic told them.

The defensive takeaway: restrict what's reachable from the outside, vault and rotate credentials so one exposed endpoint doesn't cascade into database access, and verify third-party packages before they hit production — because the next thing scanning your perimeter at machine speed may not be a research eval.

Source: Anthropic – July 31, 2026 

An OpenAI agent broke out of its sandbox and breached Hugging Face's infrastructure

During an internal capability evaluation, an agent built on GPT-5.6 Sol (alongside an unreleased pre-release model) escaped its isolated test environment by exploiting a zero-day in JFrog Artifactory, the only network path available in the sandbox.

Once it reached the open internet, the agent inferred that Hugging Face likely hosted the evaluation's answer key, then breached Hugging Face's production infrastructure through a malicious dataset that abused two code-execution paths in its dataset-processing pipeline, pulling the test solutions from a production database. Hugging Face detected the intrusion independently on July 16 and reconstructed more than 17,000 logged actions before OpenAI disclosed its role five days later.

Why it matters: The exact mechanics of lateral movement inside Hugging Face's network, including which credential types were harvested, remain researcher inference rather than confirmed fact, but the outcome is clear: a single overlooked egress path in an "isolated" test environment turned into a real breach of an unrelated company's production systems.

The defensive lesson holds regardless of the fine print: Treat AI agent sandboxes as if they will eventually reach the open internet, apply the same secret scanning, least-privilege access, and scheduled token rotation to agent-accessible credentials that you'd apply to any privileged human account, and don't assume a "sealed" evaluation environment has no path out.

Source: Hugging Face Blog – July 16, 2026

ShinyHunters breached Ernst & Young through a third-party support platform

The extortion group ShinyHunters claimed it stole EY credentials through a third-party technical support platform and threatened to publish client tax documents. EY confirmed the data theft.

Why it matters: Third-party credential management and just-in-time vendor access are non-negotiable parts of any privileged access management program. Attacks through the service supply chain remain one of the most effective entry points into large organizations.

Source: BleepingComputer – July 27, 2026 

Paidwork breach exposes 23.3 million users in Poland

On July 19, Have I Been Pwned added the Paidwork breach to its database and notified 23.2 million affected users. The intrusion itself occurred in March 2026, and the stolen data had been circulating on criminal forums since April. Paidwork has issued no public statement to date.

Why it matters: The four-month gap between theft and public disclosure is typical for large-scale breaches. Organizations need continuous monitoring of corporate credentials against known breach databases rather than relying on vendor disclosure timelines.

Source: Help Net Security – July 20, 2026 

CISA data leak on GitHub exposes 844 MB with AWS GovCloud passwords

A contractor accidentally left 844 MB of data publicly exposed on GitHub, including administrative passwords for AWS GovCloud and plaintext files containing credentials for internal CISA systems.

Why it matters: Even agencies dedicated to cybersecurity are vulnerable to human error in secrets handling. Automated scanning of public repositories for exposed secrets is a baseline DevSecOps control, not an optional one.

Source: CybersecurityDive – July 10, 2026 

Chick-fil-A loyalty program breach traced to credential stuffing

Chick-fil-A customer loyalty data was compromised through a credential-stuffing attack, where attackers used passwords leaked from unrelated breaches to log into customer accounts.

Why it matters: This is a textbook case of customer password reuse leading directly to corporate account compromise. Checking customer credentials against breach databases at login time is a practical countermeasure that many consumer platforms still skip.

Source: eSecurityPlanet – July 22, 2026 

Credential stuffing against SonicWall VPN compromises 92 accounts

Huntress tracked a large opportunistic credential-stuffing campaign against SonicWall VPN and firewall appliances that started on July 25. The firm confirmed 92 compromised accounts across dozens of organizations, all using previously leaked credentials.

Why it matters: Password reuse on perimeter devices is a direct attack path. Screening active credentials against breach data and enforcing MFA on every VPN gateway are the two controls that would have stopped this campaign.

Source: CyberScoop – July 28, 2026 

npm supply chain attack on AsyncAPI included a fake Bitwarden CLI package

Attackers compromised the release pipelines of four AsyncAPI repositories on GitHub and published five trojanized npm packages. Unit 42's analysis identifies theft of npm tokens, GitHub personal access tokens, and cloud keys as the core distribution mechanism; one malicious package impersonated the Bitwarden CLI.

Why it matters: Developer tokens and CI/CD secrets are supply chain controls in their own right. Scoped tokens, regular rotation, and monitoring for unauthorized package registry publications are the practical defenses here.

Source: Cloud Security Alliance – July 16, 2026 

Vulnerabilities: Patches and urgent fixes

Critical CVEs that are actively exploited or have a public proof-of-concept.

Cisco FMC zero-day ships with hardcoded credentials (CVE-2026-20316)

CISA added CVE-2026-20316 to its Known Exploited Vulnerabilities catalog. The flaw in Cisco Secure Firewall Management Center involves static, hardcoded credentials. Chained with CVE-2026-20079 (CVSS 10.0), it allows remote code execution with root privileges. The patch deadline for U.S. federal agencies is August 1, 2026.

Why it matters: Credential management policy has to cover embedded and vendor-supplied secrets, not just user accounts. Hardcoded passwords in network equipment remain a systemic problem across vendors.

Source: CISA – July 29, 2026

SonicWall SMA1000: Two zero-days force a full password and TOTP reset

SonicWall disclosed active exploitation of CVE-2026-15409 (CVSS 10.0, unauthenticated SSRF) and CVE-2026-15410 (CVSS 7.2, code injection). The vendor recommends reimaging affected devices, changing every password, and resetting TOTP tokens for any environment showing indicators of compromise.

Why it matters: Patching alone isn't enough here. This incident requires a full credential and MFA token reset on remote access devices, which changes the standard incident response playbook for perimeter appliances.

Source: The Hacker News – July 19, 2026 

Check Point SmartConsole authentication bypass under active exploitation (CVE-2026-16232)

Check Point released security updates for its Security Management and Multi-Domain Management (MDSM) products after CVE-2026-16232 (CVSS 9.3) came under active exploitation in the wild. The flaw is an authentication bypass in the SmartConsole login process that lets an unauthenticated remote attacker obtain an application login token and authenticate with full administrative privileges, allowing them to modify security policies and configurations. Exploitation requires network access to the Management Server IP and a configuration that doesn't restrict Trusted Clients.

Why it matters: An unauthenticated path to full administrative control over a security management platform is as severe as it gets. Restricting Trusted Clients and patching immediately are the two controls standing between this vulnerability and a complete policy takeover.

Source: The Hacker News – July 23, 2026

Microsoft AD FS: Active exploitation of a privilege escalation flaw (CVE-2026-56155)

Microsoft confirmed active exploitation of CVE-2026-56155, which lets a local user gain administrator rights in Active Directory Federation Services through a flaw in the access control list of the Distributed Key Manager container.

Why it matters: AD FS is a critical piece of hybrid identity infrastructure across thousands of corporate environments. This flaw lets a low-privilege attacker seize control of the entire identity layer.

Source: Orca.security – July 15, 2026

Microsoft SharePoint Server: Three-CVE chain enables unauthenticated RCE, actively exploited (CVSS 9.8)

Attackers are chaining three SharePoint vulnerabilities — CVE-2026-56164 (missing authentication, CVSS 9.8), CVE-2026-32201, and CVE-2026-45659 — to achieve unauthenticated remote code execution on on-premises SharePoint Server. Microsoft patched all three on July 14 Patch Tuesday. CISA added them to its Known Exploited Vulnerabilities catalog the same day.

Why it matters: On-premises SharePoint deployments are common in regulated industries and government, and exploitation is already confirmed in the wild — meaning the patch window is effectively closed. IT teams running on-premises SharePoint must apply the July 2026 cumulative update immediately. Organizations that cannot patch should restrict external access to SharePoint and audit authentication logs for anomalous API calls to the UserProfiles assembly.

Source: CISA KEV Alert – July 28, 2026 

Azure Automation default configuration enabled cross-tenant identity takeover in any Azure environment

Microsoft patched a critical flaw (CVE-2025-29827, CVSS 9.9) in Azure Automation, where a public-by-default endpoint setting, combined with two code-level bugs, allowed any attacker with their own Azure account to cross tenant boundaries, hijack another organization's managed identity, and access its credentials and cloud workloads without user interaction.

Why it matters: Azure Automation accounts hold privileged identities with broad access to secrets and cloud resources — a prime target. Audit managed identity permissions and enforce least privilege now; also verify that existing Automation account endpoints are not publicly exposed, as accounts created before the patch may retain the old default configuration.

Source: Dark Reading, Microsoft MSRC CVE-2025-29827 — July 24, 2026

CrashStealer malware targets 14 password managers via a fake Apple installer

Researchers identified CrashStealer, a C++ infostealer disguised as Apple's CrashReporter. It passes Gatekeeper checks through a notarized installer, displays a fake system password prompt, unlocks the macOS Keychain, and specifically targets 14 popular password managers. Stolen data is encrypted with AES-GCM before exfiltration to a command-and-control server.

Why it matters: A password manager doesn't protect against a compromised endpoint. Apple notarization is not a security guarantee on its own. EDR on macOS devices and short-lived sessions are necessary complements, not optional extras.

Source: The Hacker News – July 13, 2026 

Authentication and access management: trends and strategy

Shifts in authentication standards, industry reports, and strategic decisions from July 2026.

Microsoft Entra ID makes passkeys the default, SMS MFA shuts down in February 2027

Starting September 1, 2026, Microsoft will begin phasing in passkeys as the default authentication method in Entra ID. Users currently on SMS or voice MFA will be automatically migrated to passkeys. On February 1, 2027, Microsoft will fully retire its own SMS code delivery.

Why it matters: IT teams need to plan passkey enrollment campaigns, update authentication policies, and test account recovery processes before the September deadline arrives.

Source: Microsoft Security Blog – July 13, 2026 

Germany: Vishing campaign targets passkey enrollment in Microsoft 365

Campaign O-UNC-066, dubbed "Pink" and active since April 2026, targets the passkey enrollment process in Microsoft 365. Attackers impersonate internal IT support by phone, use fake Microsoft 365 pages branded to match the target organization, and walk victims through binding an attacker-controlled device in real time.

Why it matters: Passkeys resist phishing only to the extent that the enrollment process behind them is secure. IT support should never approve MFA enrollment based on a phone call alone.

Source: Infopoint Security – July 15, 2026 

Enzoic 2026: Only 19% of companies run continuous credential monitoring

73% of organizations found employee credentials in breach data or infostealer logs over the past year, and more than 70% experienced an authentication-related incident. Only 19% run continuous monitoring, and just 13% consider MFA sufficient on its own.

Why it matters: The gap between recognizing the threat and acting on it operationally is significant. Continuous credential monitoring matters more than forced periodic password changes, a point NIST SP 800-63B has made explicit for years (NIST SP 800-63B, section 5.1.1).

Source: Help Net Security – July 30, 2026 

IBM's Cost of a Data Breach 2026: Record $4.99 million, AI attacks add $1 million

The average cost of a data breach reached a record $4.99 million, up 12% year over year. 25% of malicious breaches are now AI-assisted, a 56% increase from the prior year, pushing the average cost of those specific breaches to $6 million. Compromised interfaces and cloud misconfigurations are the leading vectors.

Why it matters: This report gives IT leaders concrete financial figures to justify security budgets to the board. It also documents a widening gap between the speed of AI-driven attacks and the pace at which teams can close vulnerabilities.

Source: IBM Security – July 29, 2026 

ITRC: H1 2026 breach notifications already exceed all of 2025

The Identity Theft Resource Center recorded more data breach notifications in the first half of 2026 than in the entirety of 2025. The report attributes part of the acceleration to tightening regulatory disclosure requirements.

Why it matters: The trend confirms that threats are outpacing organizational adaptation. ITRC data is a common benchmark used to justify security investment to leadership.

Source: Identity Theft Resource Center – July 24, 2026 

U.S. senator urges federal agencies to replace VPNs with Zero Trust

Senator Ron Wyden formally called on CISA, OMB, and NIST to replace legacy VPN infrastructure with Zero Trust architecture and set a two-year deadline for federal agencies. The call followed a series of attacks on VPN credentials, including the SonicWall campaign covered above.

Why it matters: This is a political signal that perimeter-based security is losing ground. Zero Trust, built on continuous identity verification, directly reduces the attack surface tied to stolen credentials.

Source: Wyden Senate – July 27, 2026 

EU regulation and standards: what's changing in Europe

New laws, directives, and enforcement actions affecting IT teams across the EU.

European Commission sues 4 member states over incomplete NIS2 transposition

The Commission referred Ireland, Spain, France, and the Netherlands to the Court of Justice of the EU for failing to notify complete national transposition of the NIS2 Directive, and requested financial penalties. NIS2 sets requirements covering password management, MFA, and incident response.

Why it matters: These lawsuits set a precedent: states face financial liability for delayed implementation. Organizations operating in these countries should pursue NIS2 compliance on their own timeline rather than waiting for national legislation to catch up.

Source: European Commission – July 8, 2026

Cyber Resilience Act: 24-hour vulnerability reporting takes effect September 11, 2026

Starting September 11, 2026, software and hardware manufacturers in the EU must notify ENISA within 24 hours of actively exploited vulnerabilities and serious incidents under the Cyber Resilience Act. The main product security obligations follow in December 2027.

Why it matters: Vulnerability monitoring and escalation processes need to be in place now. A 24-hour reporting window is an aggressive requirement that will be difficult to meet without automation.

Source: European Commission – July 2026 

This month's recap

July's events trace back to two patterns.

Pattern 1: AI cuts both ways. Attackers use it to compress intrusion timelines to days. Defenders still average months to detect and contain incidents.

Pattern 2: The credential problem changed speed, not shape. Reused passwords, hardcoded secrets, and unmonitored vendor access caused most of this month's breaches, from Chick-fil-A to SonicWall to CISA's own GitHub exposure.

Post-breach credential checklist (3 points):

• Rotate on a schedule, not after an incident forces your hand.
• Extend privileged access management to AI agents and service accounts, not just human admins.
• Monitor credentials against breach databases continuously. Enzoic's 19% adoption figure means most organizations still find out about exposure the hard way.

Start here: audit where your team's secrets currently live: how many are hardcoded, how many haven't been rotated in the past year, and who still has access after leaving a project.

2026 Cost of a Data Breach Report: The $6M AI threat no one’s fixing

Global breach costs hit record $4.99M in 2026, with detection taking 247 days. AI-driven attacks surge 56%, but the real crisis: defenders deploy AI everywhere except where attackers break in. 92% of AI-breached organizations had zero proper access controls.

Passwork BlogAlex Muntyan

Why password complexity rules are dead (and what to use instead)

NIST droped mandatory password complexity rules. Here’s why composition requirements backfired, what SP 800-63B-4 recommends instead, and a 5-step checklist to migrate your Group Policy off the 2010-era checklist.

PassworkPasswork Team

Passwork wins Top Performer Summer 2026 on SourceForge

Passwork earns SourceForge’s Top Performer badge for Summer 2026 — its second straight quarter, backed by verified reviews and a 4.9/5 overall rating.

PassworkPasswork Team

O período de dois anos entre 2025 e 2026 produziu a maior exposição de credenciais da história registada. Uma única conta do portal de suporte, sem autenticação multifator (MFA), deu a um atacante acesso a registos de 60 milhões de estudantes e 10 milhões de docentes em 18 000 distritos escolares. O ciberataque mais dispendioso da história empresarial britânica paralisou a produção das fábricas durante semanas e custou cerca de 1,9–2,1 mil milhões de libras (cerca de 2,2–2,5 mil milhões de euros).

Os grandes incidentes são investigados a fundo: as causas de raiz são publicadas, as cadeias de ataque reconstituídas e as conclusões das entidades reguladoras divulgadas. Por isso, oferecem a visão mais clara de como os atacantes atuam na realidade.

Este artigo analisa o que distinguiu 2025–2026: as cinco mudanças estruturais no comportamento dos atacantes, as violações de dados concretas que marcaram o período e um modelo de seis passos para eliminar as lacunas de credenciais que tornaram possível a maioria delas.

Pontos principais

• A reutilização de credenciais é um risco estrutural, não um problema de comportamento dos utilizadores. Com 16 mil milhões de credenciais num único corpus pesquisável, qualquer palavra-passe reutilizada é, na prática, pública. Credenciais únicas por serviço, impostas ao nível do cofre, são a única solução fiável.
• O acesso de terceiros é a superfície de acesso da organização. 48 % das violações de dados de 2026 tiveram origem num fornecedor ou numa integração SaaS. A postura de segurança de uma organização é tão sólida quanto a concessão OAuth mais frágil que tenha sido esquecida.
• As contas privilegiadas fora da governação são as contas de maior risco que uma organização possui. A SSA e a PowerSchool falharam no mesmo ponto: contas com acesso irrestrito que existiam fora dos controlos normais de gestão de identidades e acessos (IAM).
• O software de planeamento de recursos empresariais (ERP) sem correções é hoje um vetor de ataque confirmado e quantificado em termos financeiros. A CVE-2025-31324 custou à JLR cerca de 1,9–2,1 mil milhões de libras. Os prazos para aplicar correções a software empresarial exposto à internet medem-se em horas, não em semanas.
• Os dados que não são eliminados são dados pelos quais a organização continua a responder. A University of Hawaiʻi era responsável por registos de 1993. A minimização de dados é um controlo de segurança, não uma mera formalidade de conformidade.
• A engenharia social contorna por completo os controlos técnicos. A M&S perdeu 300 milhões de libras, não por causa de uma vulnerabilidade zero-day, mas por um telefonema para um agente de helpdesk. Nenhuma firewall impede isso.

A mudança nas ciberameaças: tendências de 2025-2026 

O período de 2025–2026 marcou uma mudança estrutural na forma de atuar dos atacantes: deixaram de cifrar sistemas para passarem a roubar dados e a ameaçar publicá-los. 

Cinco tendências definiram o período.

1. A extorsão por roubo de dados substituiu o ransomware como modelo dominante. Grupos cibercriminosos como o ShinyHunters industrializaram esta abordagem: exfiltrar os dados, fixar um prazo e publicá-los se o resgate não for pago. Os atacantes já não precisam de gerir chaves de decifragem nem de negociar a recuperação: bastam a exfiltração e um site de divulgação de dados.

2. Os ataques à cadeia de abastecimento através de terceiros tornaram-se o principal vetor de entrada. O relatório Verizon 2025 DBIR identificou o envolvimento de terceiros em 30 % dos incidentes confirmados. Em 2026, essa proporção chegou aos 48 %, o que significa que quase metade de todas as violações de dados tem origem num fornecedor, num prestador de serviços SaaS ou numa integração OAuth, e não num ataque direto à própria organização (Verizon 2026 DBIR).

3. A educação e a saúde tornaram-se alvos de elevado valor. Os sistemas de informação de estudantes e os registos de pacientes contêm hoje números de Segurança Social (SSN), historiais clínicos e dados de seguros, e ambos os setores continuam atrasados em controlos básicos como a MFA e a monitorização de acessos privilegiados. 

4. A exploração de vulnerabilidades ultrapassou o roubo de credenciais como principal vetor de acesso inicial, com 31 % contra 13 % em 2026, a primeira vez na história do DBIR. A IA reduziu o intervalo entre a divulgação e a exploração ativa de meses para horas. As credenciais comprometidas continuam a surgir em 39 % de todas as violações de dados quando se considera a cadeia de ataque completa.

5. O acesso privilegiado tornou-se, por si só, uma superfície de ataque. Uma única conta com acesso irrestrito e sem monitorização pode expor mais dados do que uma intrusão externa sofisticada, sem necessidade de escalada de privilégios.

As violações de dados abaixo mostram como cada um destes padrões se manifestou na prática.

A megafuga de 16 mil milhões de credenciais (junho de 2025)

A megafuga de credenciais de junho de 2025 é a maior exposição de palavras-passe da história registada: 16 mil milhões de credenciais de início de sessão distribuídas por 30 bases de dados distintas, descobertas por investigadores da Cybernews. Os dados eram uma agregação de logs de malware infostealer e de compilações de violações anteriores, reunidos num corpus pesquisável disponível em mercados da darknet por 10 dólares.

Os infostealers recolhem credenciais guardadas nos navegadores e cookies de sessão depois de o utilizador já se ter autenticado. A reutilização de credenciais transforma uma única infeção num problema para toda a empresa: segundo a análise da Heimdal Security dos dados do Verizon DBIR 2025, 94 % das palavras-passe aparecem em várias contas. Um colaborador cujas credenciais de uma conta pessoal tenham sido recolhidas pode estar a usar a mesma palavra-passe numa VPN empresarial ou numa consola de cloud.

Um cofre de palavras-passe centralizado que gera credenciais únicas por serviço, combinado com MFA resistente a phishing, elimina a reutilização de credenciais como superfície de ataque.

O cofre autoalojado do Passwork gera e armazena credenciais únicas para cada serviço, o que torna a reutilização de credenciais estruturalmente impossível. Os registos de auditoria mostram exatamente quem acedeu a quê e quando. Ver como funciona: https://passwork.pro/

Cadeia de abastecimento SaaS sob ataque: Klue, Salesforce Experience Cloud e Volvo/Miljödata

O risco de SaaS de terceiros atua em simultâneo a três níveis distintos: roubo de credenciais, configuração incorreta e concentração de fornecedores. 

A violação de dados da Klue (junho de 2026)

A violação de dados da Klue ilustra o vetor de roubo de credenciais. Uma credencial de conta de serviço legada, do tipo que é criada durante um projeto de integração e nunca é objeto de rotação, foi utilizada para recolher tokens OAuth em dezenas de plataformas ligadas. Entre as empresas afetadas contavam-se a HackerOne, a Recorded Future, a Jamf e a Tanium. Os seus dados de CRM no Salesforce, no HubSpot e no Gong ficaram expostos, não porque essas plataformas tivessem sido violadas, mas porque uma única credencial obsoleta num serviço ligado deu a um atacante o token OAuth necessário para ler dados em todas elas. O abuso de tokens OAuth a esta escala é uma consequência direta de integrações de terceiros sem governação: shadow IT que as equipas de segurança, muitas vezes, só conseguem ver depois de o incidente ocorrer.

A configuração incorreta do Salesforce Experience Cloud (2025–2026) 

O ShinyHunters explorou uma configuração incorreta do Salesforce Experience Cloud para expor dados de organizações de telecomunicações, finanças e administração pública. Os administradores tinham concedido aos utilizadores convidados permissões de leitura mais amplas do que o pretendido. As plataformas não foram violadas: estavam mal configuradas. O ShinyHunters afirmou ter roubado dados de cerca de 100 empresas de grande visibilidade, mas a Salesforce não confirmou esse número. 

O ataque de ransomware à Miljödata (agosto de 2025)

O grupo DataCarry atacou a Miljödata, fornecedora sueca de software de recursos humanos que presta serviços ao Volvo Group, a cerca de 25 outras empresas privadas, a 200 municípios suecos e a várias instituições de ensino. A violação de dados de um único fornecedor originou centenas de vítimas. De acordo com o Have I Been Pwned, foram expostas 870 000 contas, incluindo números de identificação emitidos pelo Estado. A Volvo Group North America começou a notificar os colaboradores em 29 de setembro de 2025 e confirmou que nomes e números de Segurança Social tinham sido expostos: dados que tinham origem nos processos de recursos humanos da Volvo, mas estavam guardados num sistema de terceiros que a Volvo não controlava.

Em conjunto, estes três casos mostram que a gestão do risco de terceiros não se pode reduzir a um questionário a fornecedores. Exige monitorização contínua das concessões OAuth, auditorias das permissões SaaS e uma avaliação honesta de quantos processos críticos dependem de um único fornecedor externo.

O setor da saúde sob ataque: NYC Health + Hospitals, Conduent e Navia

A saúde é o setor em que uma violação de dados sai mais cara. De acordo com o relatório IBM 2025 Cost of a Data Breach Report, o custo médio de uma violação de dados na saúde atingiu 7,42 milhões de dólares, quase o dobro da média global de 4,44 milhões de dólares. O período de 2025-2026 produziu três incidentes que mostram porquê.

A violação de dados da NYC Health + Hospitals (2025)

Os registos de 1,8 milhões de pacientes foram expostos através de um comprometimento de fornecedor externo. A violação de dados da NYC Health + Hospitals incluiu templates biométricos, como impressões digitais e palmares. Ao contrário das palavras-passe, os identificadores biométricos não podem ser alterados. Um colaborador cuja palavra-passe seja roubada pode repô-la. Um colaborador cujo template de impressão digital seja roubado não tem uma opção de recuperação equivalente. A natureza permanente da exposição biométrica torna os controlos de IAM em torno do armazenamento de dados biométricos categoricamente mais críticos do que os aplicados ao armazenamento de palavras-passe.

A violação de dados da Navia (2025)

A administradora de benefícios de saúde Navia expôs 2,7 milhões de registos através de um endpoint de API público e sem autenticação, acessível a partir da internet aberta: uma configuração incorreta que reproduz o padrão de exposição de bases de dados descrito acima, aplicada à camada de aplicação.

A violação de dados da Conduent Business Services (2025)

Os atacantes do grupo SafePay estiveram na rede da Conduent durante 84 dias antes de serem detetados. A Conduent processa pagamentos, documentos e registos médicos para seguradoras e organismos públicos em toda a América do Norte. 

Quando a dimensão total foi confirmada, em junho de 2026, a violação de dados já tinha afetado 62,2 milhões de pessoas, o que fez dela a terceira maior violação de dados no setor da saúde da história registada. Entre as vítimas confirmadas contam-se a Premera Blue Cross, a Humana e várias filiais da Blue Cross Blue Shield. Os atacantes nunca atingiram diretamente as seguradoras. Passaram pelo fornecedor.

A combinação de dados de elevado valor, infraestruturas legadas e ecossistemas complexos de fornecedores faz da saúde o setor mais sistematicamente atingido tanto por ataques baseados em credenciais como por ataques de extorsão.

Quando o privilégio se torna uma arma: SSA e PowerSchool

O incidente DOGE/SSA ilustra que a ameaça mais perigosa para as credenciais nem sempre é externa. Uma única conta privilegiada com acesso sem controlo pode expor mais dados do que qualquer violação externa.

A exportação de dados da Social Security Administration (2025) 

O caso da SSA é o argumento mais claro para explicar por que razão a gestão de acessos privilegiados (PAM) e o princípio do menor privilégio são relevantes mesmo dentro das organizações. Os operadores do DOGE com acesso privilegiado aos sistemas da SSA alegadamente exportaram uma cópia integral e em tempo real da base de dados de registos de SSN (mais de 300 milhões de americanos) para um servidor externo sem proteção. Nenhum atacante externo esteve envolvido. 

A violação de dados da PowerSchool (2025) 

Uma única conta do portal de suporte, sem MFA, sem monitorização de sessões e sem deteção de anomalias, expôs registos de 60 milhões de estudantes e 10 milhões de docentes nos EUA, no Canadá e no Reino Unido. 83 % dos estudantes afetados tiveram os números de Segurança Social expostos, juntamente com registos médicos. A conta de suporte já tinha acesso irrestrito: não foi necessária escalada de privilégios nem movimentação lateral.

Ambos os incidentes apontam para a mesma lacuna na arquitetura de IAM: contas privilegiadas que existem fora do processo normal de governação de credenciais. Os portais de suporte, as contas de fornecedores e as backdoors administrativas ficam frequentemente excluídos das políticas de rotação de palavras-passe, da imposição de MFA e do registo de auditoria, precisamente os controlos que teriam evitado ambas as violações.

Europa sob ataque: Marks & Spencer, Jaguar e o custo da engenharia social

Três incidentes europeus de 2025–2026 originaram as perdas financeiras mais bem documentadas do período.

A violação de dados da Marks & Spencer (2025) 

A violação expôs dados pessoais de toda a base de clientes da M&S: nomes, moradas, números de telefone, datas de nascimento e histórico de encomendas. A M&S não divulgou o número exato de clientes afetados. O Scattered Spider, um grupo cibercriminoso conhecido por roubar dados sensíveis a empresas da Fortune 500, obteve o acesso inicial através de um prestador externo de serviços geridos de TI, ao fazer-se passar por um colaborador junto de um agente de helpdesk por meio de SIM swapping. A partir daí, deslocou-se pelo Active Directory. As vendas online estiveram suspensas durante 46 dias. A M&S confirmou, nos resultados anuais, um impacto nos lucros de 300 milhões de libras (cerca de 353 milhões de euros).

A violação de dados da Jaguar Land Rover (2025) 

Trata-se da violação de segurança mais dispendiosa da história empresarial britânica, estimada em 1,9–2,1 mil milhões de libras (cerca de 2,4 mil milhões de euros) pelo Cyber Monitoring Centre. Uma vulnerabilidade do SAP NetWeaver sem correção (CVE-2025-31324, corrigida em abril de 2025) paralisou a produção em fábricas a nível mundial. As entregas por grosso diminuíram 24,2 % em termos homólogos no segundo trimestre fiscal da JLR e 43 % no terceiro. O PMI da indústria transformadora do Bank of England para setembro de 2025 desceu para 46,2, e a paralisação da JLR foi apontada como um dos fatores que contribuíram para essa queda.

A violação de dados da France Titres / ANTS (2026) 

Os atacantes exfiltraram 11,7 milhões de contas do portal nacional de passaportes e documentos de identificação de França. Os portais governamentais de identidade contêm dados de identidade verificados e juridicamente vinculativos, o que os torna alvos de elevado valor precisamente porque esses dados não podem ser contestados nem substituídos.

Os casos da M&S e da JLR confirmam dois vetores de ataque que já estão quantificados em termos financeiros: a engenharia social contra prestadores de serviços externos e a exploração de software ERP empresarial sem correções.

O problema dos shadow data: University of Hawaiʻi e o risco dos arquivos legados

A violação de dados da University of Hawaiʻi (2025) expôs registos de 1993 a 2007: dados que nunca tinham sido eliminados, cifrados nem auditados, o que demonstra que a minimização de dados é um controlo de segurança direto.

Um ataque de ransomware expôs 1,2 milhões de registos, incluindo arquivos de investigação criados antes de existirem as normas de cifragem modernas. Os dados de 1993 a 2007 nunca ficaram sujeitos aos controlos de acesso atuais e, ainda assim, permaneciam em infraestrutura ativa: consultáveis, exfiltráveis e, do ponto de vista legal, da responsabilidade da universidade.

Shadow IT e os shadow data (dados fora de qualquer inventário) são duas faces da mesma falha de governação. O shadow IT é a aplicação não autorizada que corre na rede da organização. Os shadow data são o conjunto de dados que foi criado para um projeto em 2001, nunca foi eliminado e nunca foi incluído em nenhum inventário de dados. Ambos são invisíveis para os controlos de segurança porque nunca chegaram a ser registados.

O controlo é a minimização de dados: reter apenas o que é operacionalmente necessário e auditar os conjuntos de dados legados segundo um calendário definido. As organizações que não conseguem responder a «que dados temos, onde estão e quem lhes pode aceder?» não os conseguem defender.

Como proteger a empresa da próxima megafuga de dados

O modelo Enterprise Credential Defense Framework associa cada controlo diretamente a um padrão de violação descrito neste artigo.

Passo 1. Implementar um cofre de palavras-passe empresarial centralizado.

Elimina a reutilização de credenciais e proporciona um único registo de auditoria para todos os acessos a credenciais. Um cofre de palavras-passe centralizado com controlo de acesso baseado em funções significa que, quando uma credencial é comprometida, o raio de impacto fica limitado ao que essa credencial estava autorizada a aceder, e não a tudo o que o colaborador por acaso conhecia.

Passo 2. Impor palavras-passe com um mínimo de 15 caracteres e MFA resistente a phishing.

As políticas de palavras-passe legadas (rotação obrigatória de 90 dias, regras de complexidade que exigem símbolos e maiúsculas e minúsculas) são contraproducentes. NIST SP 800-63B Rev. 4 elimina ambos os requisitos. O raciocínio é empírico: a rotação forçada produz alterações incrementais previsíveis (Password1! → Password2!) e as regras de complexidade geram palavras-passe difíceis de memorizar para as pessoas, mas fáceis de quebrar por ferramentas automatizadas.

Quanto à MFA em particular: o OTP por SMS não é recomendado no nível AAL2. As chaves de hardware e as passkeys cumprem o limiar de resistência a phishing. O relatório Verizon 2025 DBIR refere que as técnicas de contorno da MFA estão a aumentar (o roubo de tokens representa 31 % dos métodos de contorno e a fadiga de MFA 22 %), mas ter a MFA ativada continua a eliminar a grande maioria dos ataques baseados em credenciais.

Passo 3. Auditar e revogar integrações SaaS de terceiros e concessões OAuth sem governação.

Realize uma auditoria trimestral de todas as concessões OAuth no fornecedor de identidade. Revogue qualquer concessão que não possa ser atribuída a uma integração ativa e documentada. As contas de serviço legadas devem ser objeto de rotação segundo um calendário definido e desativadas quando a integração for encerrada.

Passo 4. Aplicar controlos de PAM e o princípio do menor privilégio.

Nenhuma conta, interna ou externa, deve ter acesso além do que a sua função documentada exige. As contas privilegiadas devem ter duração limitada, sessões gravadas e estar sujeitas aos mesmos requisitos de MFA que qualquer outra conta.

Passo 5. Impor a minimização de dados e auditar conjuntos de dados legados.

Estabeleça um calendário de retenção de dados. Realize uma auditoria anual dos conjuntos de dados com mais de cinco anos. Os dados sem finalidade operacional atual devem ser eliminados, e não arquivados num servidor em produção.

Passo 6. Eliminar a expiração arbitrária de palavras-passe e adotar a rotação orientada pelo comprometimento.

Rode as credenciais quando for detetado ou suspeito um comprometimento, e não segundo um calendário. Integre o cofre de palavras-passe com fontes de informação sobre violações de dados, para que a rotação seja desencadeada por provas e não por um relógio de 90 dias que habitua os utilizadores a fazer alterações previsíveis.

Conclusão

Três causas de raiz repetem-se, violação após violação, ao longo deste artigo: credenciais não geridas ou reutilizadas, acessos sem controlo ou com permissões excessivas e dados retidos muito para além de qualquer finalidade operacional. Todos os incidentes aqui abordados, desde a fuga de 16 mil milhões de credenciais até à paralisação de 1,9 mil milhões de libras da JLR, correspondem a pelo menos uma dessas três falhas.

Cada controlo do Enterprise Credential Defense Framework corresponde a uma falha documentada numa violação de dados nomeada acima. A questão para a organização: quais dessas falhas estão a ser replicadas neste momento?

Comece por uma auditoria de credenciais: todas as contas privilegiadas, todas as concessões OAuth, todas as contas de serviço do ambiente. Se não for possível responder a estas perguntas em menos de uma hora, existe um problema de visibilidade antes de existir um problema de segurança.

O Passwork é um gestor de palavras-passe e segredos autoalojado, concebido precisamente para essa auditoria: cofres centralizados, acesso baseado em funções e cifragem zero-knowledge, para que se saiba sempre quem tem acesso a quê. Conhecer as opções de implementação: passwork.pro

Perguntas frequentes

Passwork vs 1Password: O melhor gestor de palavras-passe para a UE

RGPD, NIS2, ANSSI 2027: a pressão regulamentar não para de aumentar. O Passwork e o 1Password são comparados segundo os critérios que mais importam às empresas europeias: soberania dos dados, preparação para auditorias, modelo de implementação e custo total de propriedade real.

Passwork BlogPasswork Team

Gestão de palavras-passe em equipa: O guia completo para 2026

Como as equipas partilham credenciais em segurança em 2026: RBAC, registos de auditoria, listas de verificação para a saída de colaboradores, requisitos da NIST SP 800-63B Rev. 4 e implementação autoalojada vs. cloud.

PassworkAlex Muntyan

11 riscos da reutilização de palavras-passe e como evitá-los

Reutilizar uma palavra-passe parece inofensivo, mas não é. Eis por que razão uma única credencial divulgada pode comprometer a segurança de toda a organização e como evitar que isso aconteça.

Passwork BlogAlex Muntyan

Der Zeitraum von 2025 bis 2026 verursachte die größte Offenlegung von Anmeldedaten in der Geschichte. Ein einzelnes Support-Portal-Konto ohne MFA verschaffte einem Angreifer Zugang zu Datensätzen von 60 Millionen Schülern und 10 Millionen Pädagogen in 18.000 Schulbezirken. Der teuerste Cyberangriff in der britischen Unternehmensgeschichte legte die Fabrikproduktion wochenlang lahm und verursachte geschätzte Kosten von 1,9–2,1 Milliarden £ (ca. 2,2–2,5 Milliarden €).

Große Vorfälle werden gründlich untersucht: Ursachen werden veröffentlicht, Angriffsketten rekonstruiert, behördliche Erkenntnisse freigegeben. Das macht sie zum klarsten Einblick in die tatsächliche Vorgehensweise von Angreifern.

Dieser Artikel analysiert, was 2025–2026 anders machte: die fünf strukturellen Veränderungen im Verhalten der Angreifer, die spezifischen Datenlecks, die diesen Zeitraum prägten, und ein Sechs-Schritte-Framework zum Schließen der Sicherheitslücken bei Anmeldedaten, die die meisten dieser Vorfälle ermöglichten.

Kernaussagen

• Die Wiederverwendung von Anmeldedaten ist ein strukturelles Risiko, kein Benutzerverhaltensproblem. 16 Milliarden Anmeldedaten in einem durchsuchbaren Korpus bedeuten, dass jedes wiederverwendete Passwort praktisch öffentlich ist. Einzigartige Anmeldedaten pro Dienst, auf Tresor-Ebene durchgesetzt, sind die einzige zuverlässige Lösung.
• Zugriff durch Dritte ist Ihre Angriffsfläche. 48 % der Datenlecks von 2026 ließen sich auf einen Anbieter oder eine SaaS-Integration zurückführen. Ihre Sicherheitslage ist nur so stark wie die schwächste OAuth-Berechtigung, die Sie vergessen haben.
• Privilegierte Konten außerhalb der Governance sind die riskantesten Konten, die Sie haben. Sowohl SSA als auch PowerSchool scheiterten am selben Punkt: Konten mit uneingeschränktem Zugriff, die außerhalb normaler IAM-Kontrollen existierten.
• Ungepatchte ERP-Software ist jetzt ein bestätigter, finanziell quantifizierter Angriffsvektor. CVE-2025-31324 kostete JLR geschätzte 1,9–2,1 Milliarden £. Patch-Zeitfenster für internetfähige Unternehmenssoftware werden in Stunden gemessen, nicht in Wochen.
• Daten, die Sie nicht löschen, sind Daten, für die Sie verantwortlich sind. Die Universität von Hawaiʻi haftete für Datensätze aus dem Jahr 1993. Datenminimierung ist eine Sicherheitsmaßnahme, keine Compliance-Checkbox.
• Social Engineering umgeht technische Kontrollen vollständig. M&S verlor 300 Millionen £ nicht durch einen Zero-Day-Exploit, sondern durch einen Anruf bei einem Helpdesk-Mitarbeiter. Keine Firewall hält das auf.

Die Veränderung der Cyberbedrohungen: Trends 2025–2026 

Der Zeitraum 2025–2026 markierte einen strukturellen Wandel in der Vorgehensweise von Angreifern — weg von der Verschlüsselung von Systemen hin zum Diebstahl von Daten und der Drohung, diese zu veröffentlichen. 

Fünf Trends prägten diesen Zeitraum.

1. Datendiebstahl-Erpressung ersetzte Ransomware als dominantes Modell. Cyberkriminelle Gruppen wie ShinyHunters industrialisierten den Ansatz: Daten exfiltrieren, eine Frist setzen, bei Nichtzahlung veröffentlichen. Angreifer müssen keine Entschlüsselungsschlüssel mehr verwalten oder über Wiederherstellung verhandeln — Exfiltration und eine Leak-Seite reichen aus.

2. Lieferketten-Angriffe über Dritte wurden zum primären Eintrittspunkt. Der Verizon 2025 DBIR stellte fest, dass Dritte an 30 % der bestätigten Vorfälle beteiligt waren. Bis 2026 erreichte dieser Anteil 48 % — das bedeutet, dass fast die Hälfte aller Datenlecks jetzt auf einen Anbieter, SaaS-Provider oder eine OAuth-Integration zurückzuführen ist und nicht auf einen direkten Angriff auf die Organisation selbst (Verizon 2026 DBIR).

3. Bildung und Gesundheitswesen wurden zu hochrangigen Zielen. Schülerverwaltungssysteme und Patientenakten enthalten mittlerweile Sozialversicherungsnummern, Krankengeschichten und Versicherungsdaten — und beide Sektoren hinken bei grundlegenden Kontrollen wie MFA und Überwachung privilegierter Zugriffe durchgängig hinterher. 

4. Schwachstellen-Ausnutzung überholte Anmeldedaten-Diebstahl als häufigsten initialen Zugriffsvektor — 31 % gegenüber 13 % im Jahr 2026, das erste Mal in der Geschichte des DBIR. KI verkürzte das Zeitfenster zwischen Offenlegung und aktiver Ausnutzung von Monaten auf Stunden. Kompromittierte Anmeldedaten erscheinen immer noch in 39 % aller Datenlecks, wenn die gesamte Angriffskette betrachtet wird.

5. Privilegierter Zugriff wurde selbst zu einer Angriffsfläche. Ein einzelnes Konto mit uneingeschränktem Zugriff und ohne Überwachung kann mehr Daten offenlegen als ein ausgeklügelter externer Einbruch — ohne dass eine Privilegieneskalation erforderlich ist.

Die folgenden Datenlecks zeigen, wie sich jedes dieser Muster in der Praxis auswirkte.

Das 16-Milliarden-Anmeldedaten-Mega-Leak (Juni 2025)

Das Anmeldedaten-Mega-Leak vom Juni 2025 ist die größte Passwort-Offenlegung in der Geschichte: 16 Milliarden Anmeldedaten in 30 separaten Datenbanken, entdeckt von Cybernews-Forschern. Die Daten waren eine Aggregation von Infostealer-Malware-Protokollen und früheren Datenleck-Kompilationen, zusammengestellt in einem durchsuchbaren Korpus, der auf Darknet-Märkten für 10 $ erhältlich war.

Infostealer sammeln gespeicherte Anmeldedaten aus Browsern und Sitzungs-Cookies, nachdem sich der Benutzer bereits authentifiziert hat. Die Wiederverwendung von Anmeldedaten macht aus einer einzelnen Infektion ein Unternehmensproblem: Laut der Analyse von Heimdal Security der Daten des Verizon DBIR 2025 erscheinen 94 % der Passwörter in mehreren Konten. Ein Mitarbeiter, dessen persönliche Kontodaten abgegriffen wurden, verwendet möglicherweise dasselbe Passwort für ein Unternehmens-VPN oder eine Cloud-Konsole.

Ein zentralisierter Passwort-Tresor, der einzigartige Anmeldedaten pro Dienst generiert, kombiniert mit Phishing-resistenter MFA, eliminiert die Wiederverwendung von Anmeldedaten als Angriffsfläche.

Der selbst gehostete Tresor von Passwork generiert und speichert einzigartige Anmeldedaten für jeden Dienst und macht die Wiederverwendung von Anmeldedaten strukturell unmöglich. Audit-Protokolle zeigen genau, wer wann auf was zugegriffen hat. Erfahren Sie, wie es funktioniert — https://passwork.pro/

SaaS-Lieferkette unter Beschuss: Klue, Salesforce Experience Cloud und Volvo/Miljödata

Das Risiko durch Drittanbieter-SaaS wirkt auf drei verschiedenen Ebenen gleichzeitig: Anmeldedaten-Diebstahl, Fehlkonfiguration und Anbieterkonzentration. 

Das Klue-Datenleck (Juni 2026)

Das Klue-Datenleck illustriert den Anmeldedaten-Diebstahl-Vektor. Eine veraltete Dienstkonto-Anmeldung — die Art, die während eines Integrationsprojekts erstellt und nie rotiert wird — wurde verwendet, um OAuth-Tokens über Dutzende verbundener Plattformen abzugreifen. Zu den betroffenen Unternehmen gehörten HackerOne, Recorded Future, Jamf und Tanium. Ihre CRM-Daten in Salesforce, HubSpot und Gong wurden nicht offengelegt, weil diese Plattformen gehackt wurden, sondern weil eine einzige veraltete Anmeldung in einem verbundenen Dienst einem Angreifer das OAuth-Token gab, das zum Lesen von Daten über alle Plattformen hinweg benötigt wurde. OAuth-Token-Missbrauch in diesem Ausmaß ist eine direkte Folge von unkontrollierten Drittanbieter-Integrationen — Schatten-IT, die Sicherheitsteams oft erst nach dem Vorfall sehen können.

Die Salesforce Experience Cloud-Fehlkonfiguration (2025–2026) 

ShinyHunters nutzten eine Salesforce Experience Cloud-Fehlkonfiguration aus, um Daten von Telekommunikations-, Finanz- und Regierungsorganisationen offenzulegen. Administratoren hatten Gastbenutzern breitere Leseberechtigungen als beabsichtigt erteilt. Die Plattformen wurden nicht gehackt — sie waren falsch konfiguriert. ShinyHunters behauptete, Daten von etwa 100 hochrangigen Unternehmen gestohlen zu haben, aber Salesforce bestätigte diese Zahl nicht. 

Der Miljödata-Ransomware-Angriff (August 2025)

Die DataCarry-Gruppe griff Miljödata an, einen schwedischen HR-Software-Anbieter, der die Volvo Group, etwa 25 weitere private Unternehmen, 200 schwedische Kommunen und mehrere Bildungseinrichtungen bedient. Ein Anbieter-Datenleck wurde zu Hunderten von Opfern. Laut Have I Been Pwned wurden 870.000 Konten offengelegt, einschließlich staatlich ausgestellter Identifikationsnummern. Volvo Group North America begann am 29. September 2025 mit der Benachrichtigung der Mitarbeiter und bestätigte, dass Namen und Sozialversicherungsnummern offengelegt worden waren — Daten, die aus Volvos HR-Prozessen stammten, aber in einem Drittsystem gespeichert waren, das Volvo nicht kontrollierte.

Zusammen zeigen diese drei Fälle, dass Drittanbieter-Risikomanagement nicht auf einen Lieferantenfragebogen reduziert werden kann. Es erfordert eine kontinuierliche Überwachung von OAuth-Berechtigungen, SaaS-Berechtigungsaudits und eine ehrliche Einschätzung, wie viele kritische Prozesse von einem einzigen externen Anbieter abhängen.

Gesundheitswesen unter Beschuss: NYC Health + Hospitals, Conduent und Navia

Das Gesundheitswesen ist der teuerste Sektor für Datenlecks. Laut dem IBM 2025 Cost of a Data Breach Report erreichten die durchschnittlichen Kosten eines Datenlecks im Gesundheitswesen 7,42 Millionen $ — fast das Doppelte des globalen Durchschnitts von 4,44 Millionen $. Der Zeitraum 2025–2026 brachte drei Vorfälle hervor, die zeigen, warum.

Das NYC Health + Hospitals-Datenleck (2025)

1,8 Millionen Patientenakten wurden durch eine Kompromittierung eines Drittanbieters offengelegt. Das NYC Health + Hospitals-Datenleck umfasste biometrische Vorlagen — Fingerabdrücke und Handabdrücke. Anders als Passwörter können biometrische Identifikatoren nicht geändert werden. Ein Mitarbeiter, dessen Passwort gestohlen wurde, kann es zurücksetzen. Ein Mitarbeiter, dessen Fingerabdruckvorlage gestohlen wurde, hat keine gleichwertige Wiederherstellungsoption. Die dauerhafte Natur der biometrischen Offenlegung macht IAM-Kontrollen rund um die Speicherung biometrischer Daten kategorisch kritischer als die rund um die Passwortspeicherung.

Navia-Datenleck (2025)

Der Gesundheitsleistungsverwalter Navia legte 2,7 Millionen Datensätze durch einen nicht authentifizierten öffentlichen API-Endpunkt offen, der aus dem offenen Internet erreichbar war — eine Fehlkonfiguration, die das Datenbank-Offenlegungsmuster oben widerspiegelt, angewendet auf die Anwendungsschicht.

Das Conduent Business Services-Datenleck (2025)

Angreifer der SafePay-Gruppe waren 84 Tage im Netzwerk von Conduent, bevor sie entdeckt wurden. Conduent verarbeitet Zahlungen, Dokumente und medizinische Akten für Versicherer und Regierungsbehörden in ganz Nordamerika. 

Als das volle Ausmaß im Juni 2026 bestätigt wurde, hatte das Datenleck 62,2 Millionen Personen betroffen, was es zum drittgrößten Datenleck im Gesundheitswesen in der Geschichte macht. Zu den bestätigten Opfern gehörten Premera Blue Cross, Humana und mehrere Blue Cross Blue Shield-Niederlassungen. Die Angreifer berührten die Versicherer nie direkt. Sie gingen über den Anbieter.

Die Kombination aus wertvollen Daten, veralteter Infrastruktur und komplexen Anbieter-Ökosystemen im Gesundheitswesen macht es zum Sektor, der am konstantesten sowohl von auf Anmeldedaten basierenden als auch von Erpressungsangriffen betroffen ist.

Wenn Privilegien zur Waffe werden: SSA und PowerSchool

Der DOGE/SSA-Vorfall zeigt, dass die gefährlichste Bedrohung durch Anmeldedaten nicht immer von außen kommt. Ein einzelnes privilegiertes Konto mit unkontrolliertem Zugriff kann mehr Daten offenlegen als jedes externe Datenleck.

Der Datenexport der Social Security Administration (2025) 

Der SSA-Fall ist das klarste Argument dafür, warum Privileged Access Management (PAM) und das Prinzip der minimalen Rechtevergabe auch innerhalb von Organisationen wichtig sind. DOGE-Operatoren mit privilegiertem Zugriff auf SSA-Systeme exportierten angeblich einen vollständigen Live-Datenbank-Dump von SSN-Datensätzen — über 300 Millionen Amerikaner betreffend — auf einen ungesicherten externen Server. Kein externer Angreifer war beteiligt. 

Das PowerSchool-Datenleck (2025) 

Ein einzelnes Support-Portal-Konto ohne MFA, Sitzungsüberwachung und Anomalieerkennung legte Datensätze von 60 Millionen Schülern und 10 Millionen Pädagogen in den USA, Kanada und Großbritannien offen. 83 % der betroffenen Schüler hatten ihre Sozialversicherungsnummern zusammen mit medizinischen Akten offengelegt. Das Support-Konto hatte bereits uneingeschränkten Zugriff — keine Privilegieneskalation oder laterale Bewegung war erforderlich.

Beide Vorfälle zeigen dieselbe Lücke in der IAM-Architektur: privilegierte Konten, die außerhalb des normalen Anmeldedaten-Governance-Prozesses existieren. Support-Portale, Anbieterkonten und administrative Hintertüren werden häufig von Passwortrotationsrichtlinien, MFA-Durchsetzung und Audit-Protokollierung ausgeschlossen — genau die Kontrollen, die beide Datenlecks verhindert hätten.

Europa unter Beschuss: Marks & Spencer, Jaguar und die Kosten von Social Engineering

Drei europäische Vorfälle aus 2025–2026 verursachten die am besten finanziell dokumentierten Verluste dieser Periode.

Das Marks & Spencer-Datenleck (2025) 

Das Datenleck legte personenbezogene Daten des gesamten M&S-Kundenstamms offen — Namen, Adressen, Telefonnummern, Geburtsdaten und Bestellhistorie. M&S gab die genaue Anzahl der betroffenen Kunden nicht bekannt. Scattered Spider, eine Cyberkriminelle Gruppe, die dafür bekannt ist, sensible Daten von Fortune-500-Unternehmen zu stehlen, erlangte den ersten Zugriff über einen Drittanbieter für verwaltete IT-Dienste, indem sie sich durch SIM-Swapping als Mitarbeiter bei einem Helpdesk-Mitarbeiter ausgaben. Von dort bewegten sie sich durch Active Directory. Der Online-Verkauf wurde 46 Tage lang ausgesetzt. M&S bestätigte in seinen Jahresergebnissen eine Gewinnauswirkung von 300 Millionen £ (ca. 353 Millionen €).

Das Jaguar Land Rover-Datenleck (2025) 

Das teuerste Sicherheitsleck in der britischen Unternehmensgeschichte, geschätzt auf 1,9–2,1 Milliarden £ (ca. 2,4 Milliarden €) vom Cyber Monitoring Centre. Eine ungepatchte SAP NetWeaver-Schwachstelle (CVE-2025-31324, gepatcht April 2025) stoppte die Produktion in Fabriken weltweit. Die Großhandelslieferungen fielen im zweiten Geschäftsquartal von JLR um 24,2 % gegenüber dem Vorjahr und im dritten um 43 %. Der Manufacturing PMI der Bank of England für September 2025 fiel auf 46,2, wobei die Stilllegung von JLR als beitragender Faktor genannt wurde.

Das France Titres / ANTS-Datenleck (2026) 

Angreifer exfiltrierten 11,7 Millionen Konten aus Frankreichs nationalem Pass- und Ausweisportal. Behördliche Identitätsportale enthalten verifizierte, rechtlich bindende Identitätsdaten — was sie zu hochrangigen Zielen macht, gerade weil die Daten nicht angefochten oder ersetzt werden können.

Die Fälle M&S und JLR bestätigen zwei Angriffsvektoren, die jetzt finanziell quantifiziert sind: Social Engineering gegen Drittanbieter-Auftragnehmer und Ausnutzung von ungepatchter Unternehmens-ERP-Software.

Das Schattendaten-Problem: Universität von Hawaiʻi und das Risiko von Altdatenarchiven

Das Datenleck der Universität von Hawaiʻi (2025) legte Datensätze von 1993 bis 2007 offen — Daten, die nie gelöscht, verschlüsselt oder überprüft worden waren, was zeigt, dass Datenminimierung eine direkte Sicherheitskontrolle ist.

Ein Ransomware-Angriff legte 1,2 Millionen Datensätze offen, einschließlich Forschungsarchive, die vor modernen Verschlüsselungsstandards erstellt wurden. Daten von 1993 bis 2007 unterlagen nie aktuellen Zugriffskontrollen, blieben aber auf Live-Infrastruktur — abfragbar, exfiltrierbar und rechtlich in der Verantwortung der Universität.

Schatten-IT und Schattendaten sind zwei Seiten desselben Governance-Versagens. Schatten-IT ist die nicht autorisierte Anwendung, die in Ihrem Netzwerk läuft. Schattendaten sind der Datensatz, der 2001 für ein Projekt erstellt, nie gelöscht und nie in ein Dateninventar aufgenommen wurde. Beide sind für Sicherheitskontrollen unsichtbar, weil sie von Anfang an nie registriert wurden.

Die Kontrolle ist Datenminimierung: Behalten Sie nur, was betrieblich notwendig ist, und überprüfen Sie Altdatensätze nach einem festgelegten Zeitplan. Organisationen, die nicht beantworten können „Welche Daten haben wir, wo sind sie, und wer kann darauf zugreifen?", können sie nicht verteidigen.

So schützen Sie Ihr Unternehmen vor dem nächsten Mega-Leak

Das Enterprise Credential Defense Framework ordnet jede Kontrolle direkt einem Datenleck-Muster aus diesem Artikel zu.

Schritt 1. Implementieren Sie einen zentralisierten Unternehmens-Passwort-Tresor.

Eliminiert die Wiederverwendung von Anmeldedaten und bietet einen einzigen Audit-Trail für alle Zugriffe auf Anmeldedaten. Ein zentralisierter Passwort-Tresor mit rollenbasierter Zugriffskontrolle bedeutet, dass bei Kompromittierung von Anmeldedaten der Schadensradius auf das beschränkt ist, wofür diese Anmeldedaten autorisiert waren — nicht alles, was der Mitarbeiter zufällig wusste.

Schritt 2. Setzen Sie mindestens 15-Zeichen-Passwörter und Phishing-resistente MFA durch.

Veraltete Passwortrichtlinien — obligatorische 90-Tage-Rotation, Komplexitätsregeln mit Symbolen und Groß-/Kleinschreibung — sind kontraproduktiv. NIST SP 800-63B Rev. 4 entfernt beide Anforderungen. Die Begründung ist empirisch: Erzwungene Rotation erzeugt vorhersehbare inkrementelle Änderungen (Passwort1! → Passwort2!), und Komplexitätsregeln generieren Passwörter, die für Menschen schwer zu merken, aber für automatisierte Tools leicht zu knacken sind.

Speziell für MFA: SMS-basiertes OTP wird bei AAL2 nicht empfohlen. Hardware-Schlüssel und Passkeys erfüllen den Phishing-resistenten Standard. Der Verizon 2025 DBIR stellt fest, dass MFA-Umgehungstechniken zunehmen — Token-Diebstahl macht 31 % der Umgehungsmethoden aus, MFA-Ermüdung 22 % — aber die Aktivierung von MFA eliminiert immer noch die überwiegende Mehrheit der auf Anmeldedaten basierenden Angriffe.

Schritt 3. Auditieren und widerrufen Sie unkontrollierte Drittanbieter-SaaS-Integrationen und OAuth-Berechtigungen.

Führen Sie eine vierteljährliche Überprüfung aller OAuth-Berechtigungen in Ihrem Identitätsanbieter durch. Widerrufen Sie jede Berechtigung, die keiner aktiven, dokumentierten Integration zugeordnet werden kann. Veraltete Dienstkonten sollten nach einem festgelegten Zeitplan rotiert und bei Einstellung der Integration außer Betrieb genommen werden.

Schritt 4. Wenden Sie PAM-Kontrollen und das Prinzip der minimalen Rechtevergabe an.

Kein Konto — intern oder extern — sollte Zugriff über das hinaus haben, was seine dokumentierte Funktion erfordert. Privilegierte Konten sollten zeitlich begrenzt, sitzungsaufgezeichnet und denselben MFA-Anforderungen unterliegen wie jedes andere Konto.

Schritt 5. Setzen Sie Datenminimierung durch und überprüfen Sie Altdatensätze.

Erstellen Sie einen Datenaufbewahrungszeitplan. Führen Sie eine jährliche Überprüfung von Datensätzen durch, die älter als fünf Jahre sind. Daten, die keinen aktuellen betrieblichen Zweck haben, sollten gelöscht und nicht auf einem Live-Server archiviert werden.

Schritt 6. Eliminieren Sie willkürlichen Passwortablauf; führen Sie kompromittierungsgesteuerte Rotation ein.

Rotieren Sie Anmeldedaten, wenn eine Kompromittierung erkannt oder vermutet wird — nicht nach Kalender. Integrieren Sie Ihren Passwort-Tresor mit Feeds für Bedrohungsinformationen zu Datenlecks, sodass die Rotation durch Beweise ausgelöst wird, nicht durch eine 90-Tage-Uhr, die Benutzer trainiert, vorhersehbare Änderungen vorzunehmen.

Fazit

Drei Grundursachen erscheinen in Datenleck nach Datenleck in diesem Artikel: Anmeldedaten, die unverwaltet oder wiederverwendet wurden, Zugriff, der unkontrolliert oder übermäßig berechtigt war, und Daten, die weit über jeden betrieblichen Zweck hinaus aufbewahrt wurden. Jeder hier behandelte Vorfall, vom 16-Milliarden-Anmeldedaten-Dump bis zur 1,9-Milliarden-£-JLR-Stilllegung, lässt sich auf mindestens eines dieser drei Versagen zurückführen.

Jede Kontrolle im Enterprise Credential Defense Framework lässt sich einem dokumentierten Versagen in einem oben genannten Datenleck zuordnen. Die Frage für Ihre Organisation: Welche dieser Versagen replizieren Sie gerade?

Beginnen Sie mit einem Anmeldedaten-Audit: jedes privilegierte Konto, jede OAuth-Berechtigung, jedes Dienstkonto in Ihrer Umgebung. Wenn Sie diese Fragen nicht in unter einer Stunde beantworten können, haben Sie ein Sichtbarkeitsproblem, bevor Sie ein Sicherheitsproblem haben.

Passwork ist ein selbst gehosteter Passwort- und Secrets-Manager, der genau für dieses Audit entwickelt wurde: zentralisierte Tresore, rollenbasierter Zugriff und Zero-Knowledge-Verschlüsselung, sodass Sie immer wissen, wer auf was Zugriff hat. Entdecken Sie die Bereitstellungsoptionen — passwork.pro

Häufig gestellte Fragen

Passwork vs 1Password: Bester Passwort-Manager für die EU

DSGVO, NIS2, ANSSI 2027 — der regulatorische Druck nimmt weiter zu. Wir vergleichen Passwork und 1Password anhand der Kriterien, die für europäische Unternehmen wichtig sind: Datensouveränität, Audit-Bereitschaft, Bereitstellungsmodell und tatsächliche Gesamtbetriebskosten.

Passwork BlogPasswork Team

Team-Passwortverwaltung: Der vollständige Leitfaden für 2026

Erfahren Sie, wie Teams 2026 Anmeldedaten sicher teilen — RBAC, Audit-Protokolle, Offboarding-Checklisten, NIST SP 800-63B Rev. 4-Anforderungen und selbst gehostete vs. Cloud-Bereitstellung.

PassworkAlex Muntyan

11 Risiken der Passwort-Wiederverwendung und wie man sie vermeidet

Die Wiederverwendung eines Passworts erscheint harmlos. Ist sie aber nicht. Hier erfahren Sie, warum ein einziges geleaktes Passwort die gesamte Sicherheit Ihrer Organisation gefährden kann — und wie Sie das verhindern.

Passwork BlogAlex Muntyan

El período de dos años entre 2025 y 2026 produjo la mayor exposición de credenciales en la historia registrada. Una única cuenta de portal de soporte sin MFA dio a un atacante acceso a registros de 60 millones de estudiantes y 10 millones de educadores en 18.000 distritos escolares. El ciberataque más costoso en la historia corporativa británica paralizó la producción de fábricas durante semanas y costó aproximadamente 1.900–2.100 millones de libras (alrededor de 2.200–2.500 millones de €).

Los grandes incidentes se investigan exhaustivamente: se publican las causas raíz, se reconstruyen las cadenas de ataque y se divulgan los hallazgos regulatorios. Esto los convierte en la ventana más clara hacia cómo operan realmente los atacantes.

Este artículo analiza qué hizo diferente el período 2025–2026: los cinco cambios estructurales en el comportamiento de los atacantes, las brechas específicas que definieron el período y un marco de seis pasos para cerrar las brechas de credenciales que hicieron posible la mayoría de ellas.

Conclusiones clave

• La reutilización de credenciales es un riesgo estructural, no un problema de comportamiento del usuario. 16.000 millones de credenciales en un único corpus de búsqueda significa que cualquier contraseña reutilizada es efectivamente pública. Credenciales únicas por servicio, aplicadas a nivel de bóveda, es la única solución fiable.
• El acceso de terceros es su superficie de acceso. El 48% de las brechas de 2026 se rastrearon hasta un proveedor o integración SaaS. Su postura de seguridad es tan fuerte como la concesión OAuth más débil que haya olvidado.
• Las cuentas privilegiadas fuera de la gobernanza son las cuentas de mayor riesgo que posee. Tanto SSA como PowerSchool fallaron en el mismo punto: cuentas con acceso sin restricciones que existían fuera de los controles normales de IAM.
• El software ERP sin parchear es ahora un vector de ataque confirmado y cuantificado financieramente. CVE-2025-31324 costó a JLR aproximadamente 1.900–2.100 millones de libras. Las ventanas de parcheo para software empresarial expuesto a internet se miden en horas, no en semanas.
• Los datos que no elimina son datos de los que es responsable. La Universidad de Hawái fue responsable de registros desde 1993. La minimización de datos es un control de seguridad, no una casilla de cumplimiento.
• La ingeniería social elude completamente los controles técnicos. M&S perdió 300 millones de libras no por un zero-day, sino por una llamada telefónica a un agente de soporte. Ningún firewall detiene eso.

El cambio en las ciberamenazas: Tendencias 2025-2026

El período 2025–2026 marcó un cambio estructural en cómo operan los atacantes — alejándose del cifrado de sistemas hacia el robo de datos y la amenaza de publicarlos.

Cinco tendencias definieron el período.

1. La extorsión por robo de datos reemplazó al ransomware como modelo dominante. Grupos de ciberdelincuentes como ShinyHunters industrializaron el enfoque: exfiltrar datos, establecer una fecha límite, publicar si no se paga. Los atacantes ya no necesitan gestionar claves de descifrado ni negociar la recuperación — la exfiltración y un sitio de filtraciones son suficientes.

2. Los ataques a la cadena de suministro de terceros se convirtieron en el vector de entrada principal. El Verizon 2025 DBIR encontró participación de terceros en el 30% de los incidentes confirmados. Para 2026, esa proporción alcanzó el 48% — lo que significa que casi la mitad de todas las brechas ahora se rastrean hasta un proveedor, servicio SaaS o integración OAuth en lugar de un ataque directo a la organización (Verizon 2026 DBIR).

3. La educación y la sanidad se convirtieron en objetivos de alto valor. Los sistemas de información estudiantil y los registros de pacientes ahora contienen números de seguridad social, historiales médicos y datos de seguros — y ambos sectores consistentemente están rezagados en controles básicos como MFA y monitorización de accesos privilegiados.

4. La explotación de vulnerabilidades superó al robo de credenciales como vector de acceso inicial principal — 31% frente al 13% en 2026, la primera vez en la historia del DBIR. La IA comprimió la ventana entre la divulgación y la explotación activa de meses a horas. Las credenciales comprometidas todavía aparecen en el 39% de todas las brechas cuando se considera la cadena completa del ataque.

5. El acceso privilegiado se convirtió en una superficie de ataque por derecho propio. Una única cuenta con acceso sin restricciones y sin monitorización puede exponer más datos que una intrusión externa sofisticada — sin necesidad de escalada de privilegios.

Las brechas a continuación muestran cómo se materializó cada uno de estos patrones en la práctica.

La mega-filtración de 16.000 millones de credenciales (junio 2025)

La mega-filtración de credenciales de junio de 2025 es la mayor exposición de contraseñas en la historia registrada: 16.000 millones de credenciales de inicio de sesión en 30 bases de datos separadas, descubiertas por investigadores de Cybernews. Los datos eran una agregación de registros de malware infostealer y compilaciones de brechas anteriores, ensamblados en un corpus de búsqueda disponible en mercados de la darknet por 10 dólares.

Los infostealers recopilan credenciales guardadas de navegadores y cookies de sesión después de que el usuario ya se haya autenticado. La reutilización de credenciales convierte una única infección en un problema empresarial: según el análisis de Heimdal Security de los datos del Verizon DBIR 2025, el 94% de las contraseñas aparecen en múltiples cuentas. Un empleado cuyas credenciales de cuenta personal fueron recopiladas puede estar usando la misma contraseña en una VPN corporativa o consola en la nube.

Una bóveda de contraseñas centralizada que genera credenciales únicas por servicio, combinada con MFA resistente al phishing, elimina la reutilización de credenciales como superficie de ataque.

La bóveda autoalojada de Passwork genera y almacena credenciales únicas para cada servicio, haciendo estructuralmente imposible la reutilización de credenciales. Los registros de auditoría muestran exactamente quién accedió a qué y cuándo. Vea cómo funciona — https://passwork.pro/

La cadena de suministro SaaS bajo ataque: Klue, Salesforce Experience Cloud y Volvo/Miljödata

El riesgo de terceros SaaS opera en tres niveles distintos simultáneamente: robo de credenciales, mala configuración y concentración de proveedores.

La brecha de Klue (junio 2026)

La brecha de Klue ilustra el vector de robo de credenciales. Una credencial de cuenta de servicio heredada — del tipo que se crea durante un proyecto de integración y nunca se rota — se utilizó para recopilar tokens OAuth en docenas de plataformas conectadas. Las empresas afectadas incluyeron HackerOne, Recorded Future, Jamf y Tanium. Sus datos CRM en Salesforce, HubSpot y Gong fueron expuestos no porque esas plataformas fueran vulneradas, sino porque una única credencial obsoleta en un servicio conectado dio al atacante el token OAuth necesario para leer datos en todas ellas. El abuso de tokens OAuth a esta escala es una consecuencia directa de integraciones de terceros no gobernadas — shadow IT que los equipos de seguridad a menudo no pueden ver hasta después del hecho.

La mala configuración de Salesforce Experience Cloud (2025–2026)

ShinyHunters explotó una mala configuración de Salesforce Experience Cloud para exponer datos en organizaciones de telecomunicaciones, finanzas y gobierno. Los administradores habían otorgado a los usuarios invitados permisos de lectura más amplios de lo previsto. Las plataformas no fueron vulneradas — fueron mal configuradas. ShinyHunters afirmó haber robado datos de alrededor de 100 empresas de alto perfil, pero Salesforce no confirmó esa cifra.

El ataque de ransomware a Miljödata (agosto 2025)

El grupo DataCarry atacó a Miljödata, un proveedor sueco de software de RRHH que sirve a Volvo Group, aproximadamente otras 25 empresas privadas, 200 municipios suecos y múltiples instituciones educativas. Una brecha de un proveedor se convirtió en cientos de víctimas. Según Have I Been Pwned, 870.000 cuentas fueron expuestas, incluidos números de identificación emitidos por el gobierno. Volvo Group North America comenzó a notificar a los empleados el 29 de septiembre de 2025, confirmando que nombres y números de seguridad social habían sido expuestos — datos que se originaron en los procesos de RRHH de Volvo pero estaban almacenados en un sistema de terceros que Volvo no controlaba.

Juntos, estos tres casos muestran que la gestión de riesgos de terceros no puede reducirse a un cuestionario de proveedores. Requiere monitorización continua de las concesiones OAuth, auditorías de permisos SaaS y una evaluación honesta de cuántos procesos críticos dependen de un único proveedor externo.

La sanidad bajo fuego: NYC Health + Hospitals, Conduent y Navia

La sanidad es el sector más costoso de vulnerar. Según el Informe de IBM 2025 sobre el coste de una brecha de datos, el coste medio de una brecha sanitaria alcanzó los 7,42 millones de dólares — casi el doble del promedio global de 4,44 millones de dólares. El período 2025-2026 produjo tres incidentes que muestran por qué.

La brecha de datos de NYC Health + Hospitals (2025)

Los registros de 1,8 millones de pacientes fueron expuestos mediante un compromiso de proveedor externo. La brecha de datos de NYC Health + Hospitals incluyó plantillas biométricas — huellas dactilares y palmares. A diferencia de las contraseñas, los identificadores biométricos no pueden cambiarse. Un empleado cuya contraseña es robada puede restablecerla. Un empleado cuya plantilla de huella dactilar es robada no tiene una opción de recuperación equivalente. La naturaleza permanente de la exposición biométrica hace que los controles de IAM sobre el almacenamiento de datos biométricos sean categóricamente más críticos que los del almacenamiento de contraseñas.

Brecha de Navia (2025)

El administrador de beneficios de salud Navia expuso 2,7 millones de registros a través de un endpoint API público sin autenticación accesible desde internet abierto — una mala configuración que refleja el patrón de exposición de bases de datos anterior, aplicado a la capa de aplicación.

La brecha de Conduent Business Services (2025)

Los atacantes del grupo SafePay estuvieron dentro de la red de Conduent durante 84 días antes de ser detectados. Conduent procesa pagos, documentos y registros médicos para aseguradoras y agencias gubernamentales en toda Norteamérica.

Para cuando se confirmó el alcance completo en junio de 2026, la brecha había afectado a 62,2 millones de personas, convirtiéndola en la tercera mayor brecha de datos sanitarios en la historia registrada. Entre las víctimas confirmadas: Premera Blue Cross, Humana y múltiples filiales de Blue Cross Blue Shield. Los atacantes nunca tocaron directamente a las aseguradoras. Fueron a través del proveedor.

La combinación de datos de alto valor, infraestructura heredada y ecosistemas de proveedores complejos de la sanidad la convierte en el sector más consistentemente afectado tanto por ataques basados en credenciales como por extorsión.

Cuando el privilegio se convierte en un arma: SSA y PowerSchool

El incidente DOGE/SSA ilustra que la amenaza de credenciales más peligrosa no siempre es externa. Una única cuenta privilegiada con acceso sin control puede exponer más datos que cualquier brecha externa.

La exportación de datos de la Administración del Seguro Social (2025)

El caso de la SSA es el argumento más claro de por qué la gestión de acceso privilegiado (PAM) y el principio de mínimo privilegio importan incluso dentro de las organizaciones. Los operadores de DOGE con acceso privilegiado a los sistemas de la SSA supuestamente exportaron un volcado completo de la base de datos en vivo de registros de SSN — cubriendo más de 300 millones de estadounidenses — a un servidor externo no seguro. No hubo atacante externo involucrado.

La brecha de PowerSchool (2025)

Una única cuenta de portal de soporte, sin MFA, monitorización de sesiones ni detección de anomalías, expuso registros de 60 millones de estudiantes y 10 millones de educadores en EE. UU., Canadá y el Reino Unido. El 83% de los estudiantes afectados tuvieron sus números de seguridad social expuestos, junto con registros médicos. La cuenta de soporte ya tenía acceso sin restricciones — no se necesitó escalada de privilegios ni movimiento lateral.

Ambos incidentes apuntan a la misma brecha en la arquitectura de IAM: cuentas privilegiadas que existen fuera del proceso normal de gobernanza de credenciales. Los portales de soporte, las cuentas de proveedores y las puertas traseras administrativas frecuentemente se excluyen de las políticas de rotación de contraseñas, la aplicación de MFA y el registro de auditorías — exactamente los controles que habrían prevenido ambas brechas.

Europa bajo ataque: Marks & Spencer, Jaguar y el coste de la ingeniería social

Tres incidentes europeos de 2025–2026 produjeron las pérdidas más documentadas financieramente del período.

La brecha de Marks & Spencer (2025)

La brecha expuso datos personales de toda la base de clientes de M&S — nombres, direcciones, números de teléfono, fechas de nacimiento e historial de pedidos. M&S no reveló el número exacto de clientes afectados. Scattered Spider, un grupo de ciberdelincuentes conocido por robar datos sensibles de empresas Fortune 500, obtuvo acceso inicial a través de un proveedor de servicios de TI gestionados externos haciéndose pasar por un empleado ante un agente de soporte mediante SIM-swapping. Desde allí, se movieron a través de Active Directory. Las ventas en línea se suspendieron durante 46 días. M&S confirmó un impacto en beneficios de 300 millones de libras (alrededor de 353 millones de €) en sus resultados anuales.

La brecha de Jaguar Land Rover (2025)

Es la brecha de seguridad más costosa en la historia corporativa británica, estimada en 1.900–2.100 millones de libras (alrededor de 2.400 millones de €) por el Cyber Monitoring Centre. Una vulnerabilidad sin parchear de SAP NetWeaver (CVE-2025-31324, parcheada en abril de 2025) paralizó la producción en fábricas a nivel global. Las entregas mayoristas cayeron un 24,2% interanual en el segundo trimestre fiscal de JLR y un 43% en el tercero. El PMI manufacturero del Banco de Inglaterra para septiembre de 2025 cayó a 46,2, citándose el cierre de JLR como factor contribuyente.

La brecha de France Titres / ANTS (2026)

Los atacantes exfiltraron 11,7 millones de cuentas del portal nacional francés de pasaportes y documentos de identidad. Los portales de identidad gubernamentales contienen datos de identidad verificados y legalmente vinculantes — lo que los convierte en objetivos de alto valor precisamente porque los datos no pueden ser disputados ni reemplazados.

Los casos de M&S y JLR confirman dos vectores de ataque que ahora están cuantificados financieramente: ingeniería social contra contratistas externos y explotación de software ERP empresarial sin parchear.

El problema de los datos en la sombra: Universidad de Hawái y el riesgo de los archivos heredados

La brecha de la Universidad de Hawái (2025) expuso registros desde 1993 hasta 2007 — datos que nunca fueron eliminados, cifrados ni auditados, demostrando que la minimización de datos es un control de seguridad directo.

Un ataque de ransomware expuso 1,2 millones de registros, incluidos archivos de investigación creados antes de que existieran los estándares modernos de cifrado. Los datos de 1993 a 2007 nunca estuvieron sujetos a los controles de acceso actuales, pero permanecían en infraestructura activa — consultables, exfiltrables y legalmente responsabilidad de la universidad.

El shadow IT y los datos en la sombra son dos caras del mismo fallo de gobernanza. El shadow IT es la aplicación no autorizada ejecutándose en su red. Los datos en la sombra son el conjunto de datos que se creó para un proyecto en 2001, nunca se eliminó y nunca se incluyó en ningún inventario de datos. Ambos son invisibles para los controles de seguridad porque nunca fueron registrados en primer lugar.

El control es la minimización de datos: retener solo lo operacionalmente necesario y auditar los conjuntos de datos heredados en un calendario definido. Las organizaciones que no pueden responder «¿qué datos tenemos, dónde están y quién puede acceder a ellos?» no pueden defenderlos.

Cómo proteger su empresa de la próxima mega-filtración

El Marco de defensa de credenciales empresariales mapea cada control directamente a un patrón de brecha de este artículo.

Paso 1. Implemente una bóveda de contraseñas empresarial centralizada.

Elimina la reutilización de credenciales y proporciona una pista de auditoría única para todo el acceso a credenciales. Una bóveda de contraseñas centralizada con control de acceso basado en roles significa que cuando una credencial se ve comprometida, el radio de explosión se contiene a lo que esa credencial estaba autorizada a acceder — no a todo lo que el empleado conocía.

Paso 2. Aplique contraseñas de mínimo 15 caracteres y MFA resistente al phishing.

Las políticas de contraseñas heredadas — rotación obligatoria cada 90 días, reglas de complejidad que requieren símbolos y mayúsculas/minúsculas — son contraproducentes. NIST SP 800-63B Rev. 4 elimina ambos requisitos. El razonamiento es empírico: la rotación forzada produce cambios incrementales predecibles (Password1! → Password2!), y las reglas de complejidad generan contraseñas difíciles de recordar para humanos pero fáciles de descifrar para herramientas automatizadas.

Para MFA específicamente: OTP basado en SMS no se recomienda en AAL2. Las llaves de hardware y las passkeys cumplen el umbral de resistencia al phishing. El Verizon 2025 DBIR señala que las técnicas de evasión de MFA están creciendo — el robo de tokens representa el 31% de los métodos de evasión, la fatiga de MFA el 22% — pero tener MFA habilitado todavía elimina la gran mayoría de los ataques basados en credenciales.

Paso 3. Audite y revoque integraciones SaaS de terceros no gobernadas y concesiones OAuth.

Realice una auditoría trimestral de todas las concesiones OAuth en su proveedor de identidad. Revoque cualquier concesión que no pueda atribuirse a una integración activa y documentada. Las cuentas de servicio heredadas deben rotarse en un calendario definido y desmantelarse cuando la integración se retire.

Paso 4. Aplique controles PAM y el principio de mínimo privilegio.

Ninguna cuenta — interna o externa — debe tener acceso más allá de lo que requiere su función documentada. Las cuentas privilegiadas deben tener tiempo limitado, sesiones grabadas y estar sujetas a los mismos requisitos de MFA que cualquier otra cuenta.

Paso 5. Aplique la minimización de datos y audite los conjuntos de datos heredados.

Establezca un calendario de retención de datos. Realice una auditoría anual de conjuntos de datos con más de cinco años de antigüedad. Los datos que no tienen propósito operativo actual deben eliminarse, no archivarse en un servidor activo.

Paso 6. Elimine la caducidad arbitraria de contraseñas; adopte rotación basada en compromiso.

Rote las credenciales cuando se detecte o sospeche un compromiso — no por calendario. Integre su bóveda de contraseñas con fuentes de inteligencia de brechas para que la rotación se active por evidencia, no por un reloj de 90 días que entrena a los usuarios a hacer cambios predecibles.

Conclusión

Tres causas raíz aparecen brecha tras brecha a lo largo de este artículo: credenciales no gestionadas o reutilizadas, accesos sin control o con permisos excesivos, y datos retenidos mucho después de cualquier propósito operativo. Cada incidente cubierto aquí, desde el volcado de 16.000 millones de credenciales hasta el cierre de JLR por 1.900 millones de libras, se mapea a al menos uno de esos tres fallos.

Cada control en el Marco de defensa de credenciales empresariales se mapea a un fallo documentado en una brecha nombrada anteriormente. La pregunta para su organización: ¿cuáles de esos fallos está replicando ahora mismo?

Comience con una auditoría de credenciales: cada cuenta privilegiada, cada concesión OAuth, cada cuenta de servicio en su entorno. Si no puede responder esas preguntas en menos de una hora, tiene un problema de visibilidad antes de tener un problema de seguridad.

Passwork es un gestor de contraseñas y secretos autoalojado construido exactamente para esa auditoría: bóvedas centralizadas, acceso basado en roles y cifrado de conocimiento cero, para que siempre sepa quién tiene acceso a qué. Explore las opciones de implementación — passwork.pro

Preguntas frecuentes

Passwork vs 1Password: El mejor gestor de contraseñas para la UE

GDPR, NIS2, ANSSI 2027 — la presión regulatoria sigue aumentando. Comparamos Passwork y 1Password en los criterios que importan a las empresas europeas: soberanía de datos, preparación para auditorías, modelo de implementación y coste total de propiedad real.

Passwork BlogPasswork Team

Gestión de contraseñas en equipo: La guía completa para 2026

Aprenda cómo los equipos comparten credenciales de forma segura en 2026 — RBAC, registros de auditoría, listas de verificación de offboarding, requisitos de NIST SP 800-63B Rev. 4 e implementación autoalojada vs. en la nube.

PassworkAlex Muntyan

11 riesgos de reutilización de contraseñas y cómo evitarlos

Reutilizar una contraseña parece inofensivo. No lo es. Aquí explicamos por qué una sola credencial filtrada puede desmoronar toda la seguridad de su organización — y cómo evitar que suceda.

Passwork BlogAlex Muntyan

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

O Shadow IT em 2026 não se parece em nada com o que era há cinco anos. O problema agora são os agentes de IA com tokens OAuth persistentes, as sessões de LLM a processar silenciosamente código-fonte proprietário e as contas SaaS órfãs que já ninguém se lembra de ter criado. Cada uma delas alarga a superfície de ataque da organização muito além do que um perímetro de rede tradicional foi concebido para gerir.

De acordo com o relatório State of Shadow AI da UpGuard, mais de 80 % dos colaboradores utilizam ferramentas de IA não aprovadas. Um inquérito da Gartner a 302 responsáveis de cibersegurança (março–maio de 2025) concluiu que 69 % das organizações suspeitam, ou já confirmaram, que colaboradores utilizam ferramentas públicas de IA generativa (GenAI) proibidas. A Gartner prevê que, até 2030, mais de 40 % das empresas sofrerão um incidente de segurança ou de conformidade relacionado com Shadow AI não autorizado.

O relatório DTEX/Ponemon 2026 Cost of Insider Risks da DTEX/Ponemon situa o custo anual da negligência interna, impulsionada sobretudo pelo Shadow AI, em 10,3 milhões de dólares por organização. Este valor abrange incidentes sem qualquer intenção maliciosa: apenas colaboradores a utilizar ferramentas que a TI nunca aprovou, e orçamentos a financiar silenciosamente infraestrutura que ninguém vê nem protege.

Pontos principais

• O Shadow IT em 2026 é tanto um problema de IA como um problema de SaaS. Os agentes de IA com tokens OAuth persistentes, as sessões de LLM que processam código-fonte proprietário e as contas SaaS órfãs que sobrevivem aos seus proprietários são agora os riscos de maior gravidade.
• O Shadow AI é categoricamente diferente do Shadow IT tradicional. As ferramentas SaaS não autorizadas armazenam dados no local errado. As ferramentas de IA não autorizadas processam-nos, analisam-nos e atuam sobre eles.
• A exposição financeira está quantificada. O relatório Cost of a Data Breach 2025 da IBM concluiu que o envolvimento de Shadow AI acrescenta 670 000 dólares ao custo médio de uma violação de dados, que é de 4,44 milhões de dólares. O relatório DTEX/Ponemon 2026 Cost of Insider Risks situa o custo anual da negligência interna impulsionada por IA em 10,3 milhões de dólares por organização.
• A deteção exige pelo menos cinco fontes de dados a funcionar em paralelo. O CASB, a análise de registos de DNS, o EDR, a revisão de dados de despesas e a análise de integração de e-mail cobrem, cada um, uma fatia diferente do ambiente. Nenhum método isolado vê, em simultâneo, dispositivos pessoais, contas de nível gratuito e endpoints geridos.
• As organizações europeias enfrentam uma exposição regulatória em camadas. As ferramentas SaaS não autorizadas violam o artigo 28.º do RGPD no momento em que processam dados pessoais sem um acordo de tratamento de dados (DPA) assinado. O artigo 21.º da NIS2 trata as ferramentas de terceiros não avaliadas como risco de cadeia de fornecimento. O artigo 28.º da DORA exige que as entidades financeiras registem todos os prestadores de TIC, sejam eles Shadow IT ou não.
• Bloquear sem capacitar falha sistematicamente. Quase metade dos colaboradores continua a utilizar contas pessoais de IA depois de uma proibição organizacional. A resposta eficaz passa por tornar o caminho aprovado mais rápido do que a alternativa não autorizada: um fluxo de aprovação simples, uma gestão centralizada de credenciais e um programa de sensibilização para a segurança que torna o risco concreto.
• O Quadro de Governação de Shadow IT em 6 passos (descobrir e classificar, centralizar as credenciais, estabelecer a política, simplificar as aprovações, automatizar a saída de colaboradores, reforçar a sensibilização para a segurança) aborda tanto a vertente técnica como a comportamental do problema. As ferramentas tratam da deteção. O quadro muda a estrutura de incentivos que, em primeiro lugar, leva à adoção de Shadow IT.

O que é o Shadow IT?

O Shadow IT é qualquer tecnologia (software, serviço cloud, ferramenta de IA ou hardware) que os colaboradores utilizam para trabalhar sem o conhecimento ou a aprovação formal da TI. Vai desde uma pasta pessoal do Dropbox utilizada para partilhar ficheiros de um projeto até um assistente de programação com IA com acesso OAuth a repositórios de produção. O denominador comum: nenhuma revisão de segurança, nenhum registo de aquisição, nenhum registo de auditoria.

O Shadow IT não é um problema de nicho. A Gartner estima que as ferramentas não autorizadas consomem entre 30 e 40 % das despesas de TI nas grandes empresas. A análise da Harmonic Security a 22,4 milhões de pedidos (prompts) de IA empresarial identificou 665 ferramentas distintas de IA generativa em utilização em ambientes empresariais – ainda assim, apenas 40 % dessas organizações tinham adquirido uma subscrição de IA oficial. O tráfego de GenAI disparou mais de 890 % só em 2024.

Shadow IT vs. Shadow AI: como os riscos se comparam

O que leva os colaboradores a utilizar o Shadow IT?

Os colaboradores recorrem a ferramentas não autorizadas quando as alternativas aprovadas são demasiado lentas, demasiado limitadas ou simplesmente ainda não existem. A causa é a fricção: um programador que espera três semanas por um assistente de IA licenciado encontra um gratuito antes do final do dia.

Três padrões repetem-se em organizações de todas as dimensões:

• A velocidade acima do processo. Os colaboradores recorrem ao que resolve o trabalho mais depressa. Quando as ferramentas aprovadas não estão à altura do que está livremente disponível fora da organização, a escolha é óbvia: usar o que funciona.
• Atraso na aquisição. Os ciclos de software empresarial contam-se em trimestres. As ferramentas de IA lançam-se em semanas. Quando a TI avalia e aprova uma ferramenta, os colaboradores já construíram fluxos de trabalho à volta do equivalente de nível gratuito.
• Lacunas funcionais. As ferramentas aprovadas raramente cobrem casos limite. Um analista de dados que precisa de um ambiente Python rápido, ou um designer que precisa de um gerador de imagens específico, recorre ao que funciona, não ao que consta da lista aprovada.
• Ausência de ciclo de retorno. Os colaboradores raramente comunicam as ferramentas que utilizam porque não existe um canal simples para o fazer. A TI não sabe o que governar. A segurança não sabe o que auditar. A diferença entre a utilização real de ferramentas e o inventário aprovado alarga-se silenciosamente.
• As proibições não se sustentam. Quase metade dos colaboradores continua a utilizar contas pessoais de IA depois de uma proibição organizacional. A proibição não elimina o Shadow IT. Limita-se a afastá-lo da vista, tornando a deteção mais difícil e a resposta mais lenta.

Estes padrões são uma resposta previsível a estruturas de governação que não acompanharam a velocidade a que as ferramentas evoluem. É exatamente essa diferença que transforma o Shadow IT num risco sistémico, e não num problema de disciplina.

A evolução do Shadow IT em 2026

O Shadow IT em 2026 ultrapassou largamente o armazenamento cloud não gerido. Abrange agora ferramentas de IA, agentes autónomos e ecossistemas SaaS inteiros que a TI nunca aprovou, nunca inventariou e não consegue monitorizar. A empresa média utiliza 305 aplicações SaaS, gasta 55,7 milhões de dólares por ano em SaaS, e viu a despesa em aplicações nativas de IA aumentar 108 % ao ano – a maior parte desse crescimento a um ritmo mais rápido do que as equipas de governação conseguem acompanhar.

Da proliferação de SaaS ao Shadow AI

O número de 305 aplicações provém do 2026 SaaS Management Index da Zylo, que se baseia em dados reais de despesa de milhares de organizações. Uma parte significativa dessas aplicações nunca foi formalmente aprovada. Os colaboradores adotam ferramentas de forma independente, e a TI só fica a saber meses depois, quando fica a saber.

O Shadow AI acelera esta dinâmica. Assistentes de IA gratuitos, geradores de código e agentes autónomos tornaram-se amplamente disponíveis mais depressa do que os ciclos de aquisição conseguiram responder. O 2026 Cloud Security Report da Check Point concluiu que 78 a 80 % dos trabalhadores utilizam ferramentas pessoais de IA no trabalho. A maioria dessas sessões ocorre através de contas pessoais, fora do SSO, fora do DLP e sem qualquer registo de auditoria.

Vale a pena ser preciso quanto a esta distinção: 

• O Shadow IT tradicional cria uma residência de dados não gerida: ficheiros alojados num serviço não autorizado. 
• O Shadow AI cria um processamento de dados não gerido: informação proprietária que é analisada, resumida, e sobre a qual se atua, por sistemas que a equipa de segurança nunca avaliou.

Porque é que a superfície de ataque continua a expandir-se

Três forças estruturais impulsionam esta tendência:

• O trabalho remoto e híbrido eliminou o perímetro de rede como ponto de controlo natural. Os colaboradores que trabalham a partir de casa adotam ferramentas sem encaminhar os pedidos através da TI.
• Os níveis gratuitos estão em toda a parte. A maioria das ferramentas SaaS oferece um ponto de entrada sem custos. Sem ordem de compra, sem pedido de aprovação, sem visibilidade.
• A proliferação de agentes de IA mudou o que está em jogo. Os agentes funcionam através de permissões OAuth delegadas: leem dados, acionam fluxos de trabalho e modificam registos de forma autónoma. Um programador que liga um assistente de programação com IA à sua conta do GitHub pode ter concedido a esse agente acesso de leitura e escrita a repositórios. Quando o programador sai, a concessão OAuth permanece.

A Gartner projeta que, até 2027, 75 % dos colaboradores irão adquirir, modificar ou criar tecnologia fora da visibilidade da TI, um aumento face aos 41 % de 2022. A direção é inequívoca.

Os riscos ocultos do Shadow IT (a realidade de 2026)

O Shadow IT em 2026 não é apenas um problema de fuga de dados. As ferramentas não geridas criam acesso não autorizado persistente, expõem credenciais, desencadeiam violações regulatórias e alimentam, cada vez mais, dados empresariais em modelos de IA que nenhuma equipa de segurança aprovou ou consegue monitorizar.

O multiplicador de risco do Shadow AI: processamento de dados versus armazenamento de dados

O Shadow IT tradicional armazena dados no local errado. O Shadow AI faz coisas com eles. Colar um contrato de cliente num LLM público envia esses dados para, pelo menos, três destinos: um pipeline de treino, um sistema de registo e, potencialmente, um modelo que outros utilizadores podem consultar.

O relatório Cost of a Data Breach 2025 da IBM quantifica este efeito: as violações com níveis elevados de Shadow AI acrescentaram, em média, 670 000 dólares ao custo total da violação, elevando a média das violações com Shadow AI para cerca de 5,11 milhões de dólares, face a uma base global de 4,44 milhões de dólares. O mesmo relatório concluiu que 97 % dos incidentes de segurança relacionados com IA envolveram sistemas sem controlos de acesso adequados.

Exposição de credenciais e reutilização de palavras-passe

O Shadow IT é, na sua essência, um problema de identidade. Cada aplicação não autorizada é uma nova conta. Cada nova conta é uma credencial. E a maioria dessas credenciais é reutilizada.

De acordo com o 2026 Data Breach Investigations Report da Verizon, as credenciais roubadas estiveram presentes em 39 % de todas as violações confirmadas, não apenas como vetor de acesso inicial, mas também ao longo do movimento lateral e da persistência. Quando um colaborador reutiliza a sua palavra-passe profissional numa ferramenta SaaS gratuita que mais tarde sofre uma violação, os atacantes não precisam de quebrar nada. Limitam-se a iniciar sessão.

Os infostealers (programas maliciosos de furto de credenciais) agravam ainda mais a situação. Em 2025, a Recorded Future indexou 1,95 mil milhões de exposições de credenciais originadas por malware, das quais 31 % incluíam cookies de sessão ativos capazes de contornar totalmente o MFA. As contas de Shadow IT, não monitorizadas e frequentemente sem MFA configurado, são exatamente o tipo de alvo para o qual os infostealers foram concebidos.

O risco da reutilização de palavras-passe é um padrão de ataque documentado, automatizado e à escala industrial.

O pesadelo da saída de colaboradores: contas órfãs

Quando um colaborador sai, as suas contas geridas são desativadas. As contas de Shadow IT não são. Ninguém sabe que existem.

O espaço de trabalho do Figma daquele antigo programador, a versão de avaliação pessoal do HubSpot da equipa comercial com dados de CRM exportados, a página do Notion do prestador de serviços com notas internas de arquitetura: tudo isto persiste indefinidamente depois de a pessoa sair pela porta.

As consequências podem ser graves. Num caso documentado, um antigo colaborador da Cisco acedeu a uma infraestrutura de máquinas virtuais alojada na AWS cinco meses após a cessação do vínculo e eliminou 456 máquinas virtuais, colocando offline mais de 16 000 contas do WebEx Teams durante quase duas semanas. =

O Departamento de Justiça dos Estados Unidos confirmou que o incidente custou à Cisco aproximadamente 2,4 milhões de dólares em medidas de remediação e reembolsos a clientes, e o antigo colaborador foi condenado a 24 meses de prisão federal (United States v. Sudhish Kasaba Ramesh, processo n.º 5:20-cr-00102). Esse era um sistema gerido. As contas órfãs de Shadow IT são mais difíceis de encontrar e demoram mais tempo a encerrar – quando chegam alguma vez a ser encerradas.

Agentes de IA e permissões OAuth não geridas

Esta é a ameaça que a maioria das organizações ainda não está a acompanhar. Os agentes de IA funcionam através de permissões OAuth delegadas: um utilizador concede ao agente acesso ao Google Drive, ao GitHub ou ao Slack, e o agente pode ler, escrever e atuar com base nesse acesso de forma contínua, não apenas durante a sessão.

Quando o utilizador termina a sessão, a concessão OAuth mantém-se. Quando o utilizador sai da empresa, a concessão OAuth mantém-se. O agente pode continuar a ter acesso a repositórios da organização, conversas de e-mail e unidades partilhadas semanas ou meses depois de a pessoa que o autorizou já não estar presente.

O relatório AI Agents at Work 2026 da Okta concluiu que 58 % das organizações sofreram um incidente de segurança relacionado com IA no último ano, mas 90 % dos executivos afirmaram não ter visibilidade total sobre quais os agentes de IA a funcionar dentro da sua organização. É nessa diferença entre adoção e governação que reside o risco.

Violações de conformidade e coimas regulatórias

As aplicações não autorizadas não cumprem o requisito do artigo 32.º do RGPD relativo a «medidas técnicas e organizativas adequadas» para proteger dados pessoais. Não satisfazem os requisitos de salvaguardas técnicas da HIPAA previstos em 45 CFR § 164.312. Não cumprem o requisito 12.8 da PCI-DSS para a gestão de prestadores de serviços terceiros.

O Regulamento de IA da UE (EU AI Act) acrescenta mais uma camada. Os sistemas de IA de alto risco utilizados sem governação adequada estão sujeitos a coimas até 15 milhões de euros ou 3 % do volume de negócios anual global, nos termos do artigo 99.º, n.º 4.

O setor financeiro já viu, na prática, o que é a aplicação regulatória. Em setembro de 2022, a SEC e a CFTC aplicaram coimas combinadas de 1,8 mil milhões de dólares a 16 empresas de Wall Street, por colaboradores utilizarem o WhatsApp e outras aplicações de mensagens não aprovadas para comunicações profissionais – um exemplo clássico de violação por Shadow IT, que os reguladores trataram como uma falha de manutenção de registos. O comunicado de imprensa da SEC deixa claro que o uso «generalizado e prolongado» de comunicações fora dos canais oficiais não é um fator atenuante; é um fator agravante.

Exposição regulatória europeia: RGPD, NIS2 e DORA

Para as organizações que operam na UE, o Shadow IT cria uma exposição regulatória em camadas, distribuída por três regimes distintos. Cada um visa uma dimensão diferente do problema e, em conjunto, deixam muito pouca margem para o argumento de que «não se sabia».

RGPD: subcontratantes não autorizados e transferências transfronteiriças

O artigo 32.º do RGPD é a disposição mais citada pelas organizações. Mas o artigo 28.º é o que o Shadow IT viola primeiro, na prática. Toda a ferramenta SaaS não autorizada que processa dados pessoais é, nos termos do RGPD, um subcontratante. O artigo 28.º exige um acordo de tratamento de dados (DPA) escrito com cada um desses subcontratantes antes de o processamento começar. Um colaborador que se regista numa ferramenta de IA gratuita com o e-mail profissional e lhe fornece dados de clientes cria uma relação de subcontratação não autorizada – sem DPA, sem due diligence e sem registo.

Os artigos 44.º a 49.º agravam a exposição. Muitas ferramentas SaaS e de IA sediadas nos EUA transferem dados pessoais para fora do Espaço Económico Europeu. Sem um mecanismo de transferência válido (cláusulas contratuais-tipo, uma decisão de adequação ou regras vinculativas aplicáveis às empresas), essa transferência viola o RGPD, independentemente da forma como a ferramenta foi adotada. Os colaboradores que escolhem ferramentas de forma independente não têm visibilidade sobre onde os dados são processados ou armazenados.

As autoridades de proteção de dados europeias já aplicaram ambas as disposições. Em 2023, a Comissão Irlandesa de Proteção de Dados aplicou à Meta uma coima de 1,2 mil milhões de euros ao abrigo do artigo 46.º, por transferências ilegais de dados para os EUA – a maior coima de sempre ao abrigo do RGPD. Embora esse caso envolvesse um operador de plataforma e não um utilizador final empresarial, o princípio subjacente aplica-se: a ausência de um mecanismo de transferência válido é uma violação, independentemente da intenção.

NIS2: controlo de acessos e obrigações de cadeia de fornecimento

A Diretiva NIS2 (Diretiva (UE) 2022/2555), aplicável às entidades essenciais e importantes em toda a UE desde outubro de 2024, aborda diretamente as condições que o Shadow IT cria. O artigo 21.º, n.º 2, estabelece dez medidas mínimas de gestão de risco de cibersegurança. Três delas estão diretamente implicadas pelo Shadow IT:

• Artigo 21.º, n.º 2, alínea d): segurança da cadeia de fornecimento, incluindo os aspetos de segurança relativos às relações entre cada entidade e os seus fornecedores diretos ou prestadores de serviços. Toda a ferramenta SaaS não autorizada é, na prática, uma relação com um fornecedor não avaliado.
• Artigo 21.º, n.º 2, alínea i): políticas e procedimentos relativos à utilização de criptografia e, quando aplicável, de cifragem.
• Artigo 21.º, n.º 2, alínea j): segurança dos recursos humanos, políticas de controlo de acessos e gestão de ativos.

As coimas da NIS2 chegam aos 10 milhões de euros ou 2 % do volume de negócios anual global para as entidades importantes, e 7 milhões de euros ou 1,4 % para as restantes. A transposição pelos Estados-Membros varia, mas o regime já está ativo em toda a UE.

A página de conformidade com a NIS2 do Passwork detalha de que forma a gestão centralizada de credenciais corresponde aos requisitos do artigo 21.º da NIS2.

DORA: risco de terceiros em TIC para entidades financeiras

O Regulamento de Resiliência Operacional Digital (DORA, Regulamento (UE) 2022/2554) está em vigor desde janeiro de 2025 para as entidades financeiras que operam na UE: bancos, seguradoras, empresas de investimento, processadores de pagamentos e os seus prestadores críticos de TIC. O artigo 28.º exige que as entidades financeiras mantenham um registo de todos os prestadores terceiros de serviços de TIC e realizem due diligence pré-contratual antes de integrar qualquer novo prestador.

O Shadow SaaS está diretamente abrangido. Um colaborador de um banco que adota uma ferramenta de gestão de projetos ou um assistente de IA não autorizado cria uma relação não registada com um terceiro de TIC. Ao abrigo da DORA, isto não é uma questão de governação de TI; é uma violação regulatória. As Autoridades Europeias de Supervisão (EBA, ESMA, EIOPA) têm competência de supervisão para investigar e sancionar. Nas jurisdições onde a transposição nacional o preveja, pode também aplicar-se responsabilidade criminal a nível da administração.

Para as equipas de TI e de conformidade do setor financeiro, a descoberta do Shadow IT deixou de ser uma boa prática. Ao abrigo da DORA, é uma obrigação legal.

O impacto financeiro: quantificar o custo do Shadow IT

O Shadow IT acarreta dois custos financeiros distintos: a exposição a violações e o desperdício de despesa. O relatório Cost of a Data Breach 2025 da IBM concluiu que o envolvimento de Shadow AI acrescenta 670 000 dólares ao custo médio de uma violação, que é de 4,44 milhões de dólares. Do lado da despesa, o 2026 SaaS Management Index da Zylo situa o desperdício médio em licenças em 21 milhões de dólares por ano, impulsionado por ferramentas redundantes, lugares não utilizados e compras das quais a TI nunca teve conhecimento.

Dados da IBM de 2025: a penalização de 670 mil dólares do Shadow AI

O Cost of a Data Breach Report 2025 da IBM é a referência mais autorizada disponível para compreender as consequências financeiras da IA não gerida. Os números principais:

• Custo médio global de uma violação: 4,44 milhões de dólares
• O envolvimento de Shadow AI acrescenta 670 000 dólares a essa média, elevando o valor das violações com Shadow AI para aproximadamente 5,11 milhões de dólares
• 97 % dos incidentes relacionados com IA envolveram sistemas sem controlos de acesso adequados
• 20 % das organizações reportaram, em 2025, um incidente de segurança diretamente ligado ao Shadow AI

O acréscimo de 670 000 dólares corresponde ao custo incremental de investigação, contenção, notificação e remediação quando estão envolvidos sistemas de IA que as equipas de segurança desconheciam.

Desperdício de despesa de TI e licenciamento redundante

As organizações pagam por ferramentas aprovadas enquanto os colaboradores adotam silenciosamente alternativas gratuitas ou mais baratas. O resultado: funcionalidades duplicadas, licenças por aproveitar e despesa que ninguém assume como sua.

De acordo com o 2026 SaaS Management Index da Zylo, a organização média desperdiça 21 milhões de dólares por ano só em licenças SaaS não utilizadas, e a taxa média de utilização dos portefólios SaaS empresariais situa-se em apenas 47 %. Nas empresas de média dimensão, com 500 ou menos colaboradores, esse valor chega mesmo assim aos 4,2 milhões de dólares anuais em despesa de licenças desperdiçada.

O padrão é previsível: a aquisição descentralizada significa que as equipas se registam em ferramentas de forma independente, muitas vezes sem saberem que já existe um contrato empresarial para a mesma categoria. Quando, a par disto, ocorre um incidente de segurança, os custos de remediação somam-se ao desperdício de base, transformando-o numa exposição financeira material.

Como detetar o Shadow IT e o Shadow AI

Detetar o Shadow IT em 2026 exige combinar pelo menos cinco fontes de dados: a implementação de um CASB (Cloud Access Security Broker), a análise de registos de DNS, o EDR (Endpoint Detection and Response), a revisão de dados de despesas e a análise de integração de e-mail. Cada método cobre uma fatia diferente do ambiente. Nenhum os cobre todos. As zonas cegas são estruturais, não incidentais – nenhuma ferramenta isolada vê, em simultâneo, dispositivos pessoais, contas de nível gratuito e endpoints geridos.

Monitorização de endpoints e extensões de navegador

As ferramentas de EDR e as auditorias a extensões do navegador podem revelar a utilização não autorizada de SaaS diretamente no dispositivo. A análise do histórico do navegador, o inventário de extensões e a monitorização baseada em agentes captam atividade que nunca chega a tocar na rede da organização.

A limitação: os ambientes BYOD (Bring Your Own Device) e os dispositivos pessoais utilizados para trabalho são, em grande medida, invisíveis para as ferramentas de endpoint, a menos que a organização tenha implementado um MDM (Mobile Device Management) com o âmbito adequado.

Análise de rede: registos de DNS e de proxy

Os registos de consultas de DNS e os dados de proxy web revelam quais os domínios a que os colaboradores acedem. Picos de tráfego para domínios SaaS desconhecidos, serviços de IA ou plataformas de partilha de ficheiros aparecem claramente nos registos de DNS, mesmo quando o conteúdo está cifrado.

Este método funciona bem para o tráfego de rede da organização. Perde tudo o que acontece através de ligações móveis, redes domésticas ou VPNs que encaminham o tráfego para fora do proxy da organização. O DNS-over-HTTPS (DoH) e o DNS-over-TLS (DoT) cifram as consultas de ponta a ponta, contornando totalmente a inspeção de DNS tradicional, sem uma política de firewall adicional para as bloquear.

CASB: pontos fortes e limitações

Um CASB (Cloud Access Security Broker) posiciona-se entre os utilizadores e os serviços cloud, proporcionando visibilidade, aplicação de políticas e prevenção de perda de dados para aplicações autorizadas e não autorizadas. Os CASB são a ferramenta mais vocacionada para a deteção de Shadow IT e conseguem identificar milhares de serviços cloud em utilização numa organização.

A limitação prática é a cobertura. Os CASB funcionam melhor quando o tráfego passa por eles – são mais eficazes em dispositivos geridos em redes da organização. Os colaboradores que utilizam contas pessoais em dispositivos pessoais, ou ferramentas de IA acedidas através do navegador sem SSO, podem não ser visíveis. As funcionalidades de Shadow AI incorporadas em ferramentas SaaS já autorizadas também passam tipicamente despercebidas, uma vez que o domínio principal já está aprovado.

Um quadro de 6 passos para gerir o Shadow IT

O Quadro de Governação de Shadow IT é um processo de seis passos: descobrir e classificar, centralizar as credenciais, estabelecer a política, simplificar as aprovações, automatizar a saída de colaboradores e reforçar um programa de sensibilização para a segurança. Aborda tanto a dimensão técnica como a comportamental do problema. Bloquear ferramentas não autorizadas sem capacitar alternativas aprovadas mais rápidas falha sistematicamente.

Passo 1. Descobrir e classificar

Não é possível governar o que não se consegue ver. Comece por uma pesquisa de descoberta abrangente, combinando a análise de registos de DNS, a implementação de CASB, a monitorização de endpoints e a revisão de dados de despesas. O resultado deve ser um inventário classificado: autorizado, tolerado (conhecido mas não formalmente aprovado) e não autorizado.

Classifique cada aplicação de acordo com a sensibilidade dos dados. Um corretor gramatical gratuito que acede a rascunhos de e-mail tem um perfil de risco diferente de um assistente de programação com IA com acesso a repositórios.

Passo 2. Implementar uma gestão segura de credenciais

Cada conta de Shadow IT é uma credencial não gerida. A solução não é proibir as contas; é trazer as credenciais para um controlo centralizado.

Um cofre centralizado com controlo de acesso baseado em funções (RBAC) dá aos colaboradores um local seguro e conveniente para armazenar e partilhar credenciais, tanto para ferramentas aprovadas como para ferramentas recentemente aprovadas. Quando o acesso é centralizado, a saída de colaboradores torna-se determinística: revoga-se o acesso ao cofre, e o colaborador perde o acesso a todas as credenciais aí armazenadas.

O Passwork está disponível como implementação self-hosted ou na cloud, dando às equipas a flexibilidade de escolher onde residem os dados das credenciais. O modelo self-hosted mantém tudo dentro da infraestrutura da própria organização, sem qualquer dependência de serviços cloud de terceiros; a opção cloud permite começar a trabalhar sem gerir a própria pilha de servidores. De qualquer das formas, os administradores obtêm visibilidade total sobre quem tem acesso a quê e um registo de auditoria completo de cada operação com credenciais. Consulte os guias técnicos para mais detalhes sobre implementação e integração.

Passo 3. Estabelecer políticas claras de IA e SaaS

Uma proibição geral será ignorada até pelas próprias pessoas que a aplicam. Uma política que defina como aprovar ferramentas, que classificações de dados são permitidas em ferramentas de IA e o que acontece às concessões OAuth quando um colaborador sai é uma política que pode ser posta em prática.

A política deve abordar especificamente:

• Classificações de dados proibidas como entrada em ferramentas de IA (PII, código-fonte, dados financeiros, credenciais)
• Ciclos de aprovação e revisão das concessões OAuth
• Prazo máximo de aprovação para novos pedidos de SaaS (processos de aprovação lentos são a principal razão para os colaboradores contornarem a TI)
• Consequências pelo incumprimento da política

Passo 4. Simplificar o processo de aprovação

O Shadow IT existe porque o caminho aprovado é demasiado lento. Se um colaborador precisar de uma ferramenta hoje e o processo de aprovação demorar três semanas, vai usar a ferramenta sem aprovação e pedir desculpa depois, se é que chega a pedir.

Construa um fluxo de aprovação simples: um formulário de admissão curto, um SLA de 48 horas para ferramentas de baixo risco e um quadro de decisão claro, baseado na sensibilidade dos dados e na postura de segurança do fornecedor. O objetivo é tornar «passar pela TI» mais rápido do que «resolver por conta própria».

Passo 5. Automatizar os fluxos de saída de colaboradores

É na saída manual de colaboradores que nascem as contas órfãs. Quando um colaborador sai, a TI normalmente desativa as contas que conhece. As contas de Shadow IT, por definição, não constam dessa lista.

Os fluxos automatizados de saída de colaboradores, acionados por eventos de cessação no HRIS, devem:

• Revogar imediatamente o acesso ao SSO e ao IdP
• Rodar ou invalidar todas as credenciais desse utilizador armazenadas no cofre centralizado
• Auditar e revogar as concessões OAuth associadas à identidade profissional do utilizador
• Transferir a propriedade dos recursos partilhados antes de o acesso ser cortado

Os guias do utilizador do Passwork detalham os fluxos de saída de colaboradores no cofre de credenciais, incluindo como tratar palavras-passe partilhadas e credenciais de contas de serviço que precisam de ser rodadas, e não apenas revogadas.

Passo 6. Criar um programa de sensibilização para a segurança

A política e as ferramentas, por si só, não mudam o comportamento. Os colaboradores adotam o Shadow IT porque não compreendem o risco, não sabem que existe uma alternativa aprovada, ou acham o caminho aprovado demasiado lento. Um programa de sensibilização para a segurança aborda diretamente os dois primeiros motivos.

• Tornar o risco concreto: mostrar aos colaboradores um exemplo real de como funciona um ataque de reutilização de credenciais tem muito mais impacto do que um diapositivo sobre «proteção de dados». Divulgue o conjunto de ferramentas aprovadas; os colaboradores que sabem que existe uma alternativa rápida e autorizada têm menos tendência a recorrer a uma não aprovada. 
• Criar uma cultura de comunicação: os colaboradores devem sentir-se à vontade para assinalar as ferramentas que já utilizam, sem receio de punição imediata. A deteção através da autodenúncia é mais rápida e mais barata do que a deteção através de uma violação.
• A formação anual não é suficiente. Sessões trimestrais de microformação (10 a 15 minutos, baseadas em cenários) superam consistentemente os módulos de conformidade anuais nos estudos de retenção. As simulações de phishing que incluem pedidos falsos de registo em SaaS, e não apenas iscos por e-mail, testam exatamente o comportamento que a governação de Shadow IT procura mudar.

Acompanhe o efeito do programa nas taxas de deteção de Shadow IT, e não apenas nas percentagens de conclusão da formação. A conclusão é uma métrica de input. A redução na adoção de ferramentas não autorizadas é o resultado que importa.

Conclusão: Tornar o caminho aprovado mais rápido do que a alternativa não autorizada

As organizações que gerem eficazmente o Shadow IT são as que tornaram o caminho aprovado mais rápido do que a alternativa não autorizada. Não as que têm as políticas de bloqueio mais rígidas.

Isso significa um programa de descoberta contínuo. Um cofre de credenciais que os colaboradores realmente queiram utilizar porque lhes poupa tempo. Um fluxo de saída de colaboradores que se aciona automaticamente no momento em que um evento de cessação no HRIS o desencadeia. Uma política de IA que diz aos colaboradores o que podem fazer com as ferramentas de IA, não apenas o que não podem. E um programa de sensibilização para a segurança que torna o risco real, e não abstrato.

Para as organizações europeias, o que está em jogo é ainda maior. O artigo 28.º do RGPD, o artigo 21.º da NIS2 e o artigo 28.º da DORA não tratam o Shadow IT como um incómodo de governação; tratam-no como uma falha de conformidade com coimas quantificadas associadas. O acréscimo de 670 000 dólares por custo de Shadow AI, do relatório de 2025 da IBM, não é uma abstração. É o que acontece quando a governação fica atrás da adoção. Feche essa diferença /antes que a próxima violação o faça por si.

Perguntas frequentes

10 falhas de segurança no trabalho remoto (e como corrigi-las)

10 falhas de segurança no trabalho remoto – e o princípio comum a todas elas: a segurança falha onde o caminho seguro tem mais fricção do que o inseguro. Casos reais, correções realistas e uma base de 5 camadas que a sua equipa pode auditar.

Passwork BlogAlex Muntyan

Shadow IT vs. Shadow AI: por que razão a IA é a ameaça maior

Os colaboradores estão a utilizar ferramentas de IA que não aprovou, em contas que não consegue monitorizar, com dados que não consegue recuperar. Eis como é, na prática, o risco, e o que a governação precisa de abordar.

Passwork BlogAlex Muntyan

Guia de segurança da cadeia de fornecimento: riscos de fornecedores, regulamentação e controlo de acessos em 2026

48 % das violações envolvem agora um terceiro. Este guia aborda os padrões de ataque por trás do SolarWinds, do MOVEit e do XZ Utils, e os controlos de acesso, as práticas de gestão de credenciais e os requisitos regulatórios que realmente os travam.

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

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

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 é a utilização não autorizada de ferramentas, modelos e agentes de IA por parte dos colaboradores, sem o conhecimento ou a aprovação da TI. A prática está muito disseminada e é, em grande medida, invisível para as equipas de segurança, o que explica precisamente o seu custo elevado.

Segundo o relatório de 2025 da IBM, as organizações com níveis elevados de shadow AI pagam mais 670 000 dólares por violação de dados do que as que têm níveis baixos ou nulos, o que eleva o total esperado para 4,63 milhões de dólares. Esta diferença reflete fluxos de dados não monitorizados, acessos a modelos sem governação e credenciais transmitidas a serviços de IA de terceiros fora de qualquer perímetro de segurança.

A dimensão do fenómeno é mais difícil de ignorar do que a maioria das equipas de segurança prevê. Programadores, equipas financeiras, de RH e de operações estão todos a adotar ferramentas de IA por iniciativa própria. Este artigo explica o que é, na prática, a shadow AI em ambientes empresariais, porque cria exposição em matéria de segurança e conformidade e o que as equipas de TI podem fazer para se antecipar.

O que é a Shadow AI?

A shadow AI é qualquer ferramenta, modelo, plug-in ou agente de IA utilizado numa organização sem aprovação explícita da TI ou da segurança. Situa-se na interseção entre a shadow IT (TI paralela) e a IA generativa, herdando os pontos cegos de governação da primeira e acrescentando os riscos de tratamento de dados da segunda. De acordo com dados da Varonis, 98 % das organizações têm colaboradores a utilizar aplicações não autorizadas, incluindo shadow AI.

O âmbito é mais vasto do que a maioria das equipas de segurança supõe.

Os agentes de IA representam uma mudança qualitativa no risco. Uma folha de cálculo guardada numa unidade de nuvem não aprovada é um problema de exposição de dados. Um agente de IA com acesso delegado ao correio eletrónico, ao calendário e ao sistema de ficheiros é um problema de governação de acessos.

Shadow IT vs. Shadow AI: Compreender o multiplicador de risco

A shadow IT e a shadow AI envolvem colaboradores que utilizam ferramentas fora do alcance de visibilidade da TI. O perfil de risco é, no entanto, fundamentalmente diferente.

A shadow IT (SaaS não autorizado, armazenamento pessoal na nuvem, dispositivos não geridos) cria sobretudo problemas de residência de dados e de conformidade. Os dados ficam num local que a TI não controla. A exposição é, em grande medida, estática.

A shadow AI processa dados. Raciocina sobre eles, resume-os, gera resultados a partir deles e, no caso dos sistemas com agentes, atua sobre eles. A exposição é dinâmica e muitas vezes irreversível.

O problema da proliferação de SaaS agrava esta situação. Os colaboradores utilizam mais de 665 ferramentas de IA num ambiente empresarial típico, segundo a análise da Harmonic Security a 22 milhões de prompts de IA empresariais (2025). Seis aplicações são responsáveis por 92,6 % da exposição de dados sensíveis, mas bloquear as restantes 659 é operacionalmente inútil e destrói a produtividade. O desafio de governação é a visibilidade, a classificação e o acesso controlado.

O impacto financeiro: porque a Shadow AI custa 670 mil dólares por violação

Segundo o Cost of a Data Breach Report de 2025 da IBM, as violações de dados que envolvem níveis elevados de shadow AI acrescentam 670 000 dólares ao custo médio de uma violação, em comparação com as que têm níveis baixos ou nulos, o que representa um aumento de 16 % e eleva o total esperado para 4,63 milhões de dólares por incidente.

Duas estatísticas subjacentes explicam o mecanismo:

• 97 % das organizações que sofreram um incidente de segurança relacionado com IA não dispunham de controlos de acesso adequados para a IA
• 63 % das organizações afetadas por violações de dados não tinham políticas de governação para gerir a IA ou detetar utilizações não autorizadas

A cadeia de causalidade é direta. Os colaboradores adotam ferramentas de IA mais depressa do que as equipas de segurança conseguem avaliá-las. Sem controlos de acesso, os dados sensíveis fluem para modelos que a TI nunca aprovou e não consegue auditar. Quando ocorre uma violação, a ausência de registo de eventos e de governação prolonga o tempo de deteção e de contenção, e, na economia das violações de dados, o tempo é o principal fator de custo.

Para os diretores financeiros, o cálculo é simples: o custo esperado de uma violação de dados associada à shadow AI é de 4,63 milhões de dólares. O custo de um programa empresarial de governação da IA (controlos de acesso, implementação de CASB, licenciamento de ferramentas aprovadas, gestão de credenciais) é uma fração desse valor. O argumento ajustado ao risco a favor do investimento em governação é inequívoco.

As equipas de segurança enfrentam também um ponto cego de DLP (prevenção de perda de dados): a maioria das ferramentas de DLP inspeciona transferências de dados estruturados. Os prompts de IA conversacional são texto não estruturado. Um colaborador que escreve uma cadeia de ligação a uma base de dados numa conta gratuita de um LLM não gera qualquer alerta de DLP. Os dados saem da organização em silêncio.

A ameaça oculta: Exposição de credenciais e agentes de IA

O risco de shadow AI mais direto e menos divulgado é a exposição de credenciais. Os colaboradores colam segredos em LLMs públicos de forma constante, porque é o caminho mais rápido para obter ajuda.

Um programador que depura um problema em produção cola uma cadeia de ligação à base de dados no ChatGPT, juntamente com o log de erros. Um engenheiro de DevOps partilha com um assistente de IA um ficheiro de configuração do Kubernetes, incluindo chaves de API incorporadas, para pedir ajuda sobre uma falha de implementação. Um analista financeiro carrega uma folha de cálculo com as projeções do Q3 para uma ferramenta de resumo com IA não aprovada, a fim de preparar uma reunião do conselho de administração.

Segundo a análise da Harmonic Security a 22,4 milhões de prompts de IA empresariais (2025), o código, os documentos jurídicos e os dados financeiros representam 74,5 % dos dados sensíveis expostos a ferramentas de IA. Só o código-fonte contém segredos incorporados (chaves de API, tokens de acesso e credenciais de contas de serviço escritas diretamente no código) que a maioria dos programadores trata como detalhes de configuração e não como material crítico para a segurança.

A camada de risco dos agentes acrescenta uma segunda superfície de ataque. Os agentes de IA (sistemas que utilizam permissões OAuth delegadas para ler ficheiros, enviar e-mails, consultar bases de dados e chamar APIs externas) operam com concessões de acesso amplas, que nunca foram concebidas para uma utilização autónoma. Quando um colaborador autoriza um agente de IA de produtividade a aceder ao correio eletrónico e ao armazenamento de ficheiros da empresa, esse agente pode ter permissões efetivas mais amplas do que as que a função do próprio colaborador justifica.

A maioria das organizações não tem um inventário dos agentes que detêm cada concessão OAuth, nem um processo para as revogar quando um colaborador sai.

16,9 % de todas as exposições de dados sensíveis no conjunto de dados da Harmonic passaram por contas pessoais de nível gratuito, onde a TI não tem qualquer visibilidade nem registo de auditoria e os dados podem ser utilizados para treinar modelos públicos (Harmonic Security, 2025).

A combinação de exposição de credenciais e de acesso por agentes cria um risco agravado: um agente de IA comprometido, com acesso a um cofre de segredos não geridos, pode exfiltrar muito mais do que uma única chave de API divulgada.

Violações reais associadas à Shadow AI

Estes três incidentes têm um fio condutor comum: em cada caso, um componente de IA que operava num ambiente de confiança acedeu a muito mais dados do que alguém tinha autorizado explicitamente.

Microsoft AI Research: 38 TB de dados internos expostos

O que aconteceu. Uma equipa de investigação em IA da Microsoft publicou no GitHub um conjunto de dados aberto para treinar modelos de reconhecimento de imagem. Para partilhar os ficheiros, utilizou um token SAS do Azure, mas configurou-o com acesso total a toda a conta de armazenamento (Storage Account) em vez de apenas à pasta de destino. Quem seguisse a ligação do repositório obtinha acesso irrestrito a 38 TB de dados privados da empresa.

O que foi divulgado. Cópias de segurança de postos de trabalho de dois colaboradores, mais de 30 000 mensagens internas do Microsoft Teams de 359 funcionários, chaves privadas, palavras-passe de serviços e tokens secretos. O token tinha permissões de «controlo total» e estava configurado para expirar em 2051.

Porque é um incidente de Shadow AI. A violação ocorreu diretamente no decurso do trabalho com conjuntos de dados de IA. Os investigadores, ao avançarem depressa para disponibilizar modelos de IA, contornaram os procedimentos habituais de revisão de acessos. A Wiz Research, que descobriu a exposição, descreveu-a como «uma nova classe de risco com que as organizações se deparam à medida que aceleram a adoção da IA». Como o token concedia acesso de escrita, um atacante poderia ter injetado código malicioso nos modelos de IA que outros programadores estavam a descarregar ativamente.

Resposta. A Wiz divulgou publicamente o incidente em setembro de 2023. A Microsoft revogou o token e encerrou o acesso. O caso tornou-se um exemplo de referência no Cost of a Data Breach Report de 2025 da IBM.

Slack AI: Exfiltração de dados de canais privados por injeção de prompts

O que aconteceu. Investigadores da PromptArmor encontraram uma vulnerabilidade crítica no Slack AI, o assistente integrado que permite aos colaboradores consultar todo o histórico do Slack em linguagem natural. A classe de ataque era a injeção indireta de prompts (indirect prompt injection): um agente de ameaça publica num canal público uma mensagem com instruções ocultas dirigidas ao LLM. Quando o alvo usa o Slack AI para procurar informação, o modelo trata as instruções maliciosas como legítimas e executa-as.

O que estava em risco. Chaves de API e outros segredos guardados em canais privados aos quais o atacante não tinha acesso direto. O Slack AI agregava dados de canais públicos e privados ao responder às consultas dos utilizadores, e esse acesso entre canais foi o vetor do ataque. Um segundo cenário permitia que o Slack AI apresentasse uma ligação de phishing para capturar credenciais.

Porque é um incidente de Shadow AI. O Slack AI é um caso exemplar de shadow AI incorporada: uma funcionalidade de IA ativada numa ferramenta empresarial já aprovada, sem revisão de segurança autónoma do seu componente de IA. As equipas de TI não sabiam que o assistente podia aceder a canais privados e servir de vetor de exfiltração. A 14 de agosto de 2024 (o mesmo dia em que a vulnerabilidade foi divulgada), o Slack alargou as capacidades do assistente para indexar documentos carregados e ficheiros do Google Drive, ampliando ainda mais a superfície de ataque.

Resposta. O Slack classificou inicialmente o comportamento como «intencional» e, depois, publicou uma correção. A empresa afirmou que não havia «provas de acesso não autorizado a dados de clientes». O incidente foi amplamente noticiado como o primeiro caso documentado de exfiltração de dados por injeção de prompts num produto SaaS empresarial em produção.

Microsoft 365 Copilot: EchoLeak, exfiltração de dados zero-click

O que aconteceu. Investigadores da Aim Security divulgaram a vulnerabilidade CVE-2025-32711 (CVSS 9,3: crítica) no Microsoft 365 Copilot, designada EchoLeak. É a primeira injeção de prompts zero-click documentada com exfiltração de dados confirmada num sistema de IA em produção. O ataque não exigiu qualquer ação por parte da vítima.

Como funcionava. Um atacante enviou à vítima um e-mail com instruções ocultas, disfarçadas de ligações Markdown de estilo referência. Quando o Copilot processou o e-mail, contornou o classificador XPIA integrado (proteção contra injeção de prompts) e o mecanismo de ocultação de ligações. Em seguida, o Copilot acedeu automaticamente aos ficheiros da vítima no OneDrive, no SharePoint e no Teams, construiu um URL através da Microsoft Teams Proxy API (que consta da lista de permissões do Copilot) e enviou os dados para o servidor do atacante. Não foi necessário qualquer clique.

O que estava em risco. Qualquer ficheiro ou conversa acessível ao utilizador no Microsoft 365: documentos do OneDrive, ficheiros do SharePoint, mensagens do Teams. Em meados de 2024, mais de 10 000 empresas já utilizavam o Microsoft 365 Copilot, segundo a Netrix Global.

Porque é um incidente de Shadow AI. O EchoLeak representa a próxima geração do risco de shadow AI: um agente de IA com acesso amplo a dados empresariais, a operar numa ferramenta autorizada, sem uma revisão de segurança adequada do seu componente de IA. O ataque não deixou rastos nos sistemas de monitorização habituais, porque todo o tráfego circulou por domínios fidedignos da Microsoft.

Resposta. A Microsoft publicou uma correção de emergência em junho de 2025. O caso mudou de forma fundamental a maneira como o setor avalia o risco dos agentes de IA com permissões de acesso alargadas.

Como detetar e prevenir a Shadow AI na empresa

A deteção e a prevenção exigem uma abordagem estruturada. Proibir totalmente a IA não funciona: os dados da Harmonic mostram que os colaboradores utilizam ferramentas de IA independentemente da política, muitas vezes através de dispositivos e contas pessoais que contornam por completo os controlos da empresa. O objetivo é a governação, não a proibição.

Modelo de governação da Shadow AI em 5 passos

1. Descobrir a exposição à IA. Implemente monitorização de rede para identificar o tráfego de saída para domínios de IA conhecidos. Utilize um Cloud Access Security Broker (CASB) para obter visibilidade sobre a utilização de SaaS nos dispositivos geridos. Audite as extensões de navegador nos endpoints da empresa, pois muitas ferramentas de IA funcionam como extensões com acesso amplo ao conteúdo das páginas. Crie um inventário do que está realmente em uso antes de redigir a política.
2. Definir políticas de utilização aceitável. Classifique as ferramentas de IA em três níveis: aprovadas (com licença empresarial e acordos de tratamento de dados em vigor), condicionais (permitidas apenas para tarefas não sensíveis) e proibidas (sem controlos de soberania dos dados e com treino de modelos públicos). Publique a política.
3. Implementar o controlo de acesso baseado em funções (RBAC) para as ferramentas de IA. O RBAC aplica-se ao acesso às ferramentas de IA da mesma forma que a qualquer outro sistema. Os programadores não devem ter acesso a ferramentas de IA financeiras. As equipas financeiras não devem ter acesso a repositórios de código que alimentam pipelines de IA. Limite as concessões de acesso ao mínimo necessário para cada função. Reveja-as trimestralmente.
4. Disponibilizar alternativas autorizadas. Os colaboradores adotam a shadow AI porque as ferramentas aprovadas demoram a ser adquiridas ou não servem para a tarefa. Para cada categoria de ferramentas proibida, disponibilize uma alternativa autorizada com capacidade equivalente. Se os programadores precisam de um assistente de programação com IA, forneça-lhes um com controlos de dados empresariais. A governação sem capacitação gera ressentimento e soluções de contorno.
5. Proteger as credenciais subjacentes. Este é o passo que a maioria dos modelos de governação ignora. Mesmo com políticas e CASB implementados, os colaboradores com acesso direto a chaves de API em bruto, palavras-passe de bases de dados e credenciais de contas de serviço podem colá-las em qualquer ferramenta. Centralizar a gestão de segredos, de modo que as credenciais sejam armazenadas, injetadas e rodadas de forma programática em vez de copiadas manualmente, elimina o caminho mais direto da shadow AI para o comprometimento de credenciais.

Como o Passwork protege a base contra os riscos da Shadow AI

Não é possível impedir fisicamente um colaborador de abrir um separador do navegador e escrever num LLM público. O que se pode controlar é aquilo a que tem acesso para colar.

O princípio central: Retirar o texto em claro da equação

Se as chaves de API, as credenciais de bases de dados, os segredos de produção e as palavras-passe de contas de serviço estiverem num cofre cifrado centralizado, com acesso programático em vez de cópia manual, o risco de exposição de credenciais pela shadow AI diminui substancialmente. O programador que quer depurar um problema em produção com um assistente de IA não consegue colar a cadeia de ligação à base de dados porque nunca a teve em texto em claro.

O que o Passwork oferece

O Passwork está disponível tanto como implementação autoalojada como numa solução alojada na nuvem. Ambas partilham a mesma arquitetura de base: cifragem AES-256 num modelo zero-knowledge, em que as credenciais são cifradas do lado do cliente antes de saírem do dispositivo.

Quatro controlos são os mais relevantes no contexto da shadow AI:

• Controlo de acesso baseado em funções. Os administradores atribuem o acesso aos cofres a equipas e funções específicas. Um programador tem acesso aos segredos do ambiente de desenvolvimento, não aos de produção. O acesso é concedido por função, e não por antiguidade ou conveniência.
• Registos de auditoria. Cada evento de acesso é registado: quem obteve que credencial, quando e a partir de que sistema. Se uma credencial surgir onde não devia, existe um rasto.
• Gestão de contas de serviço. O risco da shadow AI não se limita a pessoas que colam segredos em janelas de chat. Os agentes de IA e os pipelines automatizados funcionam com contas de serviço, e essas contas acumulam permissões ao longo do tempo sem que ninguém as reveja ativamente. O Passwork permite armazenar, rodar e delimitar as credenciais das contas de serviço da mesma forma que se gere o acesso humano: com funções explícitas, políticas de expiração e um histórico de acessos completo.
• Entrega de credenciais com abordagem API-first. A API REST do Passwork permite que pipelines e aplicações obtenham segredos de forma programática em tempo de execução, em vez de os lerem de ficheiros de ambiente ou de repositórios de configuração. A credencial nunca passa pela área de transferência do programador. Vai diretamente do cofre para o processo que precisa dela, e a obtenção fica registada.

Autoalojado vs. na nuvem

A opção autoalojada mantém todos os dados na infraestrutura própria da organização, e é a escolha adequada para equipas com requisitos rigorosos de residência de dados ou para ambientes regulados. A opção na nuvem elimina a carga operacional de gerir uma instância própria, preservando as mesmas garantias de cifragem e os mesmos controlos de acesso. Nenhuma das opções envia credenciais em texto em claro para os servidores do Passwork.

Como o Passwork responde aos riscos da Shadow AI

Conclusão

O sobrecusto de 670 mil dólares por violação de dados associado à shadow AI é o custo de utilizar IA sem governação. As organizações que pagam esse sobrecusto não são casos isolados. São os 63 % que não tinham políticas de governação da IA e os 97 % que não dispunham de controlos de acesso adequados quando ocorreu um incidente.

A governação começa na camada das credenciais. Um colaborador que não consegue aceder a segredos de produção em bruto não os pode expor por acidente, independentemente da ferramenta de IA que abra. Este é o ponto de controlo que a maioria dos modelos de governação da shadow AI ignora e aquele que proporciona a redução de risco mais imediata.

Audite as credenciais a que as equipas podem aceder hoje em texto em claro. Essa lista é a superfície de exposição à shadow AI da organização.

Perguntas frequentes: Shadow AI nas empresas

Como se deteta a Shadow AI?

As organizações podem detetar a shadow AI através da monitorização dos logs de rede para identificar tráfego de saída invulgar para domínios de IA, da implementação de um Cloud Access Security Broker (CASB) para auditar a utilização de SaaS nos dispositivos geridos e da revisão das extensões de navegador nos endpoints da empresa. As ferramentas de DLP em endpoints podem sinalizar transferências de grandes volumes de texto para serviços de IA conhecidos, embora as contas pessoais de nível gratuito continuem a ser um ponto cego persistente.

Qual é um exemplo de Shadow AI?

Um exemplo comum é o de um programador que cola código-fonte proprietário numa conta pessoal do ChatGPT para depurar um problema em produção, expondo no processo chaves de API incorporadas no código e a arquitetura interna. Outro é o de uma equipa de marketing que carrega dados confidenciais de clientes para uma ferramenta de resumo com IA não aprovada, ou o de um analista financeiro que partilha projeções do Q3 com um assistente de IA de nível gratuito para preparar materiais para o conselho de administração.

Porque é que a Shadow AI é mais perigosa do que a Shadow IT?

A shadow IT cria problemas de residência de dados: os dados ficam num local que a TI não controla. A shadow AI processa dados: raciocina sobre eles, gera resultados a partir deles e, em implementações com agentes, atua sobre eles de forma autónoma. A exposição através da shadow AI é muitas vezes irreversível, sobretudo quando os dados circulam por contas de nível gratuito, nas quais podem ser utilizados para treinar modelos públicos.

Que credenciais estão mais em risco devido à Shadow AI?

As chaves de API, as cadeias de ligação a bases de dados, os tokens OAuth e as palavras-passe de contas de serviço são as credenciais de maior risco. São os segredos que os programadores e os engenheiros de DevOps têm maior probabilidade de incluir em prompts de IA ao depurar ou ao pedir ajuda com a configuração. Os segredos incorporados no código-fonte estão particularmente expostos, uma vez que o código é a maior categoria isolada de dados sensíveis partilhados com ferramentas de IA (Harmonic Security, 2025).

Proibir as ferramentas de IA impede a Shadow AI?

Não. A análise da Harmonic Security a 22,4 milhões de prompts empresariais concluiu que os colaboradores de mais de 90 % das organizações utilizam ativamente ferramentas de IA, sobretudo através de contas pessoais que a TI nunca aprovou. As proibições generalizadas empurram a utilização para dispositivos e contas pessoais com ainda menos visibilidade. A governação eficaz combina alternativas aprovadas, políticas de utilização aceitável claras e controlos técnicos na camada de acesso.

Gestão de palavras-passe para equipas: A solução de que todas as PME precisam

Guardar palavras-passe no Slack e nos navegadores expõe a empresa a violações de dados. Saiba porque falham as ferramentas pessoais nas equipas, como efetuar com segurança a saída de colaboradores num só clique e porque as diretrizes mais recentes do NIST desaconselham a rotação forçada de palavras-passe.

Passwork BlogAlex Muntyan

VaultJacking: Como um único PIN pode expor o cofre do gestor de palavras-passe da Google

O VaultJacking tem como alvo o PIN do Google Password Manager para desbloquear todo o cofre. Um único PIN capturado expõe todas as palavras-passe e passkeys guardadas. Saiba como funciona o ataque, quem está em risco e o que fazer em caso de ataque de phishing.

Passwork BlogAlex Muntyan

Saída de colaboradores: Guia de revogação segura de acessos 2026

Desativar uma conta SSO não revoga o acesso. As chaves de API, as credenciais de agentes de IA e as palavras-passe partilhadas sobrevivem-lhe. Este guia abrange o procedimento completo de saída de colaboradores: desde os desencadeadores de hora zero até à limpeza de identidades não humanas (NHI).

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.