Password complexity is a policy rule that requires a password to mix character types (uppercase, lowercase, digits, and symbols) on the assumption that more character variety produces higher entropy and stronger resistance to guessing.

P@ssw0rd123! probably meets every complexity rule your Group Policy enforces. It also takes a modern GPU rig about 2 seconds to crack, because the pattern behind it is one of the first things any cracking dictionary tries.

That's the core failure. Complexity rules were built to increase entropy, but users converged on predictable substitutions instead, wrote passwords down, and reused the same credential across a dozen services. In 2024, NIST formally abandoned complexity mandates in SP 800-63B-4. Here is why, and what replaces it.

What are password complexity rules

Password complexity rules are policy requirements that force a password to mix character types, typically at least one uppercase letter, one lowercase letter, one digit, and one symbol, on the assumption that more character variety produces higher entropy and stronger resistance to guessing attacks.

These rules became standard in enterprise IT during the 2000s and 2010s, usually paired with a minimum length of 8 characters and mandatory rotation every 60 to 90 days. Active Directory's default password policy still ships with composition requirements enabled, and most compliance checklists from that era assumed complexity and rotation were the baseline for account security.

The assumption behind the rule was sound in theory: a larger character set per position means more possible combinations, which means a longer brute-force search. In practice, the rule interacts with human behavior in a way that undermines its own goal, which is the subject of the next section.

What NIST changed — and why it matters

NIST SP 800-63B-4 drops mandatory character-composition rules and periodic password resets, citing evidence that both practices degrade real-world security rather than improve it. The update replaces prescriptive complexity with length-based requirements and breach screening.

The rationale sits in Appendix A of the publication: composition rules push users toward predictable, formulaic passwords, while forced rotation drives people to make trivial changes (Summer2025! becomes Summer2026!) or reuse old passwords with a digit appended. Neither behavior increases resistance to guessing or cracking.

"Research has shown that users respond in very predictable ways to the requirements imposed by composition rules (policies). For example, a user who might have chosen “password” as their password would be relatively likely to choose “Password1” if required to include an uppercase letter and a number or “Password1!” if a symbol is also required." — NIST SP 800-63B-4

Here is the shift in practice:

• Character composition: 
  • Old — require uppercase, lowercase, digit, and special character.
  • New — no composition rules. Accept any printable character, including spaces.
• Rotation: 
  • Old — expire passwords every 60-90 days.
  • New — no forced rotation. Change only on evidence of compromise.
• Minimum length: 
  • Old — 8 characters was often treated as sufficient on its own.
  • New — 8 characters is the absolute minimum for passwords used in multi-factor authentication. If a password is your only security, systems must require a minimum of 15 characters. 12+ characters recommended as the practical enterprise floor.
• Password hints: 
  • Old — knowledge-based hints were permitted.
  • New — no hints, since they leak information an attacker can use directly.
• Breach checking: 
  • Old — largely absent from policy.
  • New — screen every password against known breach corpuses at creation and at every change.

If your Active Directory GPO still enforces the 2010-era checklist, it is now working against the guidance it was built to satisfy.

The behavioral failure of complexity rules

Complexity rules fail because they force predictable behavior. Under a composition requirement, users converge on the same handful of substitution patterns: @ for a, 1 for i or l, a capital letter at the start, a digit or symbol at the end. Cracking tools test these patterns first, which is exactly backwards from what the policy intended.

It's the default outcome of asking humans to generate entropy on demand. People under cognitive load reach for the path of least resistance: a memorable word, a predictable transformation, a pattern they've used before. Password1! and Summer2026! are the result of complexity policy applied to actual humans.

Password entropy measures how unpredictable a password is, in bits. Each added bit doubles the guesses an attacker needs for a brute-force crack. It depends on character set size and length, with length carrying more weight — and it assumes fully random selection, which human-chosen passwords rarely achieve.

The consequence compounds. Once a user settles on a formula that satisfies the policy, they apply the same formula everywhere: the same base word, the same substitutions, tweaked slightly per site. That's password reuse with extra steps, and it's precisely why credential stuffing works at scale. Verizon's 2025 Data Breach Investigations Report found that stolen or reused credentials remain the top initial access vector across breaches, involved in a large majority of web application incidents.

Password fatigue makes the problem worse. Employees juggling policy requirements across dozens of systems don't get more careful with each new rule. They get tired, and tired users write passwords on sticky notes or store them in a spreadsheet nobody encrypts.

Length and randomness beat complexity — the math

An 8-character password drawn truly at random from a 95-character set has roughly 52 bits of entropy. A human-chosen "complex" password rarely gets close. Studies on user-generated passwords under composition rules put real-world entropy closer to 20-30 bits, because the character choices aren't random. They follow the substitution patterns described above.

The gap between the first two rows is the entire problem with complexity rules: the theoretical ceiling and the real-world outcome are two different numbers, and policy only controls the ceiling.

A passphrase closes that gap. Four words chosen at random from a 7,776-word list (the standard EFF/Diceware wordlist size) produce about 52 bits of entropy — matching the theoretical maximum of that 8-character complex password, while being dramatically easier to remember. correct horse battery staple is the canonical example, and it holds up because the randomness comes from word selection, not character substitution a human has to invent on the spot.

The practical takeaway: a 12-character all-lowercase password drawn randomly from 26 characters has more real entropy than an 8-character "complex" password a human actually chooses, because humans are predictable and mathematics is not.

Length scales entropy exponentially with each additional character. Composition rules add a small, easily-guessed search space on top of a short string. Against modern GPU hash rates, that difference determines whether a brute force attack takes hours or centuries.

How to move away from complexity rules

Moving off legacy complexity rules doesn't require a multi-quarter project. Most of the work is policy and configuration, not new infrastructure, and it maps closely to what NIST SP 800-63B-4 and the OWASP Authentication Cheat Sheet both recommend: update the password policy document, adjust the identity provider's settings, and give users a grace period to update existing passwords at next login.

The 5-step complexity rule migration checklist:

1. Update the written policy first. Replace character-composition requirements with a minimum length of 15 characters, generated at random rather than composed by hand. Drop mandatory digit, symbol, and uppercase rules, along with periodic forced resets, both add friction without a corresponding security gain once minimum length is enforced.
2. Reconfigure the identity provider. Most AD/LDAP and SSO systems let you disable complexity enforcement and set a minimum length independently. Test the change on a pilot group before rolling out organization-wide.
3. Add breach-database screening. Check new passwords against known-breached password lists at creation time. This does more to stop credential stuffing than forcing a digit and a symbol, because it blocks the exact passwords attackers are already trying, not just weak patterns.
4. Deploy phishing-resistant MFA. A long, unbreached password is still a single point of failure if it gets phished. Prioritize FIDO2/WebAuthn security keys or passkeys for production access. TOTP works as a fallback, but security keys and passkeys should be the goal.
5. Give a grace period, not a forced reset. Force everyone to change passwords on the same day and you get a flood of Winter2026!-style patterns. Let passwords rotate naturally at next login or expiration instead.

Teams that make this switch tend to see a secondary benefit nobody puts in the policy document: helpdesk ticket volume for password resets drops, because there's no forced rotation cycle generating "I forgot my new password" tickets every quarter.

For service accounts and secrets that can't rely on human memory at all, the calculus is different: generated 32+ character secrets stored in a password manager rather than something anyone types from memory.

Why MFA and passkeys are the real endgame

Even a well-designed password policy is a transitional measure. The direction security is heading is passwordless authentication built on FIDO2 and WebAuthn, where there's no shared secret to steal in the first place.

Passkeys are phishing-resistant by design: the private key never leaves the device, and the relying party stores only a public key that has no value to an attacker without the matching hardware. Apple, Google, and Microsoft support passkeys natively across their platforms, per the W3C WebAuthn specification, and consumer adoption has moved faster than most predicted.

Enterprise adoption runs on a slower timeline. Three factors keep most organizations years away from retiring passwords entirely:

• Legacy applications that authenticate against on-prem directories or predate WebAuthn support and can't be rewritten overnight
• Federated identity setups where SSO, SAML, and LDAP integrations need to accommodate passkeys alongside existing protocols, not replace them outright
• Workforce-scale rollout logistics: device enrollment, account recovery when a hardware key is lost, and help desk capacity to support the transition

In that window, the password policy described above (length, breach screening, MFA) enforced through tooling rather than a PDF is what keeps an organization secure while the transition plays out.

What a password manager enforces that Group Policy cannot

A Group Policy Object defines password composition rules, but has no way to check whether a password has already leaked, and no mechanism for tracking who accessed a shared credential afterward. A password manager closes that gap: it screens credentials against breach databases, enforces length organization-wide, and logs every access event. That's the enforcement layer GPO structurally lacks.

Passwork, a self-hosted corporate password manager, applies this at the vault level: it enforces minimum length organization-wide without reintroducing character-mix rules, and organizes team credentials into shared vaults with role-based access control that scopes permissions by group instead of by individual account.

Passwork's built-in generator produces cryptographically random, high-entropy passwords, the kind a person cannot reliably invent by hand, and stores them directly in the vault. Autofill then handles login, so no one ever has to memorize or retype what the generator created. That removes the last point where a human could still weaken the password: the moment someone tries to make a long, random string memorable and quietly makes it predictable instead.

Unlike tools that handle only human logins, Passwork combines password management and secrets management in one vault: API keys, access tokens, database credentials, and TLS certificates sit alongside user passwords under the same access controls and audit log.

Making the switch

Complexity rules are a holdover from an era when attackers relied on brute-force guessing rather than automated tooling. Once credential-stuffing attacks can test thousands of password variants per second, asking users to invent entropy manually stops making sense. Length and MFA do the job composition rules were supposed to do, without relying on anyone's memory.

The NIST update is a formal acknowledgment of something security practitioners have watched happen for over a decade: humans are the weakest link in any policy that asks them to generate randomness on demand.

Start with the audit. Pull your current GPO password settings, check whether they still mandate composition and rotation, and map that against SP 800-63B-4.

Frequently asked questions

Brute force attacks in 2026: Types, examples & how to prevent them

GPU clusters, AI-assisted wordlists, botnets of 2.8M devices. Brute force has scaled. This guide covers six attack variants, real-world cases from 2025, and a layered defense strategy your team can implement today.

Passwork BlogAlex Muntyan

Is your data safe? High-profile data leaks 2025-2026 guide

16 billion leaked credentials. A €2.2–2.5 billion shutdown at JLR. One stale service account exposed data across four major firms. Here’s what the biggest data breaches of 2025–2026 reveal about credential risk, and the six controls that would have stopped most of them.

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.

Passwork BlogAlex Muntyan

A cifragem de conhecimento zero é uma arquitetura em que a cifragem e a decifragem ocorrem exclusivamente no dispositivo do utilizador. O servidor armazena apenas texto cifrado e chaves cifradas. Mesmo que o fornecedor sofra uma violação, seja intimado judicialmente, ou tenha um colaborador desonesto com acesso à base de dados, o texto simples permanece fora de alcance.

O que o conhecimento zero realmente significa

A arquitetura de conhecimento zero significa que o fornecedor não tem forma de ler os dados em texto simples, e não que simplesmente opte por não o fazer. A distinção que importa: as chaves são geradas e utilizadas inteiramente no cliente, e o servidor armazena apenas blobs cifrados que não consegue decifrar por si só, mesmo sob coação legal.

Compare isto com o «armazenamento cifrado» comum. Um fornecedor pode cifrar os seus dados em repouso, mas, se também detiver a chave de decifragem, pode tecnicamente ler esses dados sempre que quiser. A cifragem em repouso protege contra o roubo físico de discos rígidos. Não protege contra o próprio fornecedor, nem contra quem comprometa a infraestrutura do fornecedor.

Três propriedades distinguem o conhecimento zero real da retórica de marketing:

1. As chaves são geradas no lado do cliente, com recurso a um gerador de números pseudoaleatórios criptograficamente seguro (CSPRNG), e não num servidor
2. A chave privada nunca sai do dispositivo em texto simples e nunca é transmitida ao servidor sem cifragem
3. O servidor armazena apenas blobs cifrados, incluindo cópias cifradas das próprias chaves

Como funciona a cadeia de cifragem: Um exemplo real

A cifragem de conhecimento zero assenta numa cadeia de etapas de derivação de chaves e de cifragem, cada uma a desbloquear a seguinte. No modelo criptográfico do Passwork, uma palavra-passe mestra transforma-se numa chave mestra através do PBKDF2. Essa chave mestra decifra uma chave RSA privada, que decifra as chaves de cofre, que, por sua vez, decifram as chaves de registo que protegem as palavras-passe e os segredos propriamente ditos.

Eis a cadeia do lado do cliente, passo a passo:

1. Palavra-passe mestra → chave mestra. O utilizador introduz a sua palavra-passe mestra. O PBKDF2 (HMAC-SHA-256, 300 000 iterações) deriva uma chave mestra de 512 bits, e a derivação do lado do servidor é executada com 600 000 iterações, como camada adicional. A elevada contagem de iterações existe por um único motivo: torna a quebra da palavra-passe por força bruta computacionalmente dispendiosa.
2. Chave mestra → chave RSA privada. A chave mestra decifra a chave RSA-2048 privada do utilizador (RSA-OAEP, SHA-256) com AES-256. Essa chave privada permanece cifrada no servidor. Sem a palavra-passe mestra, trata-se de dados inertes.
3. Chave privada → chave de cofre. A chave RSA privada decifra uma chave de cofre simétrica (256 bits, com cerca de 596 bits de entropia). Um cofre contém um conjunto de registos partilhados entre os membros da equipa, e cada cofre tem a sua própria chave exclusiva.
4. Chave de cofre → chave de registo → dados do registo. A chave de cofre decifra as chaves de registo individuais, que, por sua vez, decifram as palavras-passe, os segredos e os ficheiros anexados propriamente ditos, tudo através de AES-256.
5. Uma segunda camada independente. Em paralelo com a cadeia do lado do cliente, uma chave de servidor (256 bits, gerada pelo OpenSSL) cifra a base de dados com AES-256. Duas chaves independentes, duas camadas independentes. Comprometer uma não compromete a outra.

O que o servidor realmente armazena. Não a palavra-passe mestra. Não o texto simples de nada. Armazena: o hash cifrado da chave mestra para verificação de identidade, a chave privada cifrada, as chaves de cofre e de registo cifradas, os dados de registo cifrados, e um hash de verificação utilizado para confirmar uma tentativa de início de sessão sem nunca ver a própria palavra-passe.

Como o servidor nunca possui a chave de decifragem do lado do cliente, uma violação da base de dados só produz texto cifrado. É esta a recompensa de toda a cadeia: quem roubar a base de dados, as cópias de segurança ou a chave do lado do servidor não obtém nada utilizável.

Essa proteção tem, no entanto, um limite. Defende contra o comprometimento da infraestrutura, não contra um atacante que obtenha uma palavra-passe mestra válida e inicie sessão como o utilizador. O relatório da IBM, 2025 Cost of a Data Breach Report, refere que os atacantes recorrem cada vez mais a credenciais roubadas em vez de explorarem diretamente a infraestrutura, um caminho que a arquitetura de conhecimento zero não cobre. É um motivo para associar a arquitetura à MFA.

O que o conhecimento zero protege, e o que não protege

O conhecimento zero é poderoso, mas não é magia. Defende a camada de armazenamento, não o endpoint, e compreender essa fronteira é o que distingue um comprador informado de alguém que se limita a repetir o slogan de um fornecedor.

Protege contra:

• Violações do servidor. Um atacante que extraia a base de dados obtém blobs cifrados, nada mais.
• Acesso interno. Administradores de bases de dados, operadores de cópias de segurança e equipa de suporte não conseguem ler o texto simples, porque nenhum deles possui as chaves do lado do cliente. É isto que impõe a separação de funções: quem mantém o servidor não passa automaticamente a poder ler as palavras-passe nele armazenadas.
• Intimações e ordens judiciais. Quem opera a infraestrutura não tem nada de legível para entregar, uma vez que as chaves de decifragem nunca saem do cliente.
• Fugas de bases de dados ou cópias de segurança roubadas. Os registos expostos são texto cifrado, inúteis sem as chaves do lado do cliente.

Não protege contra:

• Phishing. Se entregar a sua palavra-passe mestra a um atacante, a arquitetura não o consegue impedir.
• Partilha pública de dados decifrados. Depois de decifrar algo e de o colar num local inseguro, a cifragem deixa de ser o controlo relevante.
• Fuga de metadados. O servidor sabe, normalmente, quando acedeu a um cofre, mesmo que não saiba a que acedeu.

A segurança dos dados é normalmente descrita em três estados: em repouso, em trânsito e em utilização. A arquitetura de conhecimento zero diz essencialmente respeito ao estado em repouso: o servidor armazena texto cifrado que não consegue decifrar, independentemente da forma como é acedido.

Em trânsito, a proteção vem do TLS, um controlo separado. O que o conhecimento zero acrescenta aqui é um efeito colateral, não um substituto: os dados saem do cliente já cifrados, pelo que mesmo uma falha do TLS não exporia texto simples.

Em utilização, quando o cofre é desbloqueado e um registo é decifrado, essa decifragem ocorre apenas dentro do próprio cliente do utilizador autenticado, exclusivamente para esse utilizador. O servidor nunca recebe nem observa o texto simples em nenhum momento desse processo.

O que significa o conhecimento zero num ambiente self-hosted

O self-hosting e o conhecimento zero são propriedades independentes. O self-hosting controla onde reside a infraestrutura. O conhecimento zero controla se quem opera essa infraestrutura consegue ler os dados.

Numa implementação self-hosted, toda a cadeia, servidor, base de dados e chaves cifradas, reside no hardware da própria empresa, sem ligação de saída. O que muda quando esta configuração se combina com o conhecimento zero:

• Nenhuma parte externa envolvida. Não existe infraestrutura do fornecedor, nem pessoal do fornecedor, nem tráfego de saída a transportar dados ou chaves para fora das instalações. Tudo o que a cadeia de cifragem envolve permanece dentro da rede da empresa.
• Residência e cifragem tornam-se respostas separadas. O self-hosting define onde os dados residem fisicamente. O conhecimento zero define quem os consegue ler mesmo aí. Em conjunto, reduzem o perímetro de confiança ao dispositivo cliente, dentro de uma infraestrutura que a empresa já controla de ponta a ponta.
• O custo desloca-se, não desaparece. A aplicação de patches, as cópias de segurança e o tempo de atividade passam do fornecedor para a equipa de TI interna. Trata-se de um compromisso operacional, não de segurança, e tem lugar na conversa sobre o TCO.

Para setores regulados, esta distinção reflete-se diretamente nas questões de conformidade relacionadas com a residência dos dados.

Reforçar o conhecimento zero na prática

A cifragem de conhecimento zero protege os dados, mas não cobre os hábitos de autenticação nem a exposição da rede. Associá-la à MFA, à higiene da palavra-passe mestra, a controlos organizacionais e a uma implementação com air gap fecha as lacunas restantes.

Base de segurança:

• Autenticação multifator (MFA). Um atacante que obtenha a palavra-passe mestra por phishing continua a precisar do segundo fator para desbloquear o cofre.
• Higiene da palavra-passe mestra. A contagem de iterações do PBKDF2 retarda a força bruta, mas não corrige uma palavra-passe fraca ou reutilizada. O comprimento e a exclusividade continuam a importar mais do que a KDF que os rodeia.
• Controlos organizacionais. O acesso baseado em funções, as permissões de grupo sincronizadas a partir do AD/LDAP e um registo de auditoria completo limitam os danos que uma única conta comprometida pode causar.

Implementação com air gap: executar um gestor de palavras-passe self-hosted sem ligação de saída elimina por completo a exploração remota, o comprometimento da cadeia de fornecimento na cloud e a interceção de rede como vetores de ataque.

Como verificar uma alegação de conhecimento zero

Verificar uma alegação de conhecimento zero sem ler o código-fonte resume-se a confirmar cinco aspetos que um fornecedor legítimo documenta sem hesitar: um whitepaper técnico, prova da geração de chaves do lado do cliente, auditorias independentes, um processo de recuperação transparente e criptografia aberta. Páginas de marketing vagas que omitem estes detalhes são um sinal, não uma prova, de um problema.

Lista de verificação do conhecimento zero (5 pontos):

1. Confirmar a cifragem do lado do cliente. Verifique se a cifragem ocorre antes de os dados saírem do navegador ou da aplicação. Se as chaves forem geradas no servidor, não se trata de conhecimento zero, independentemente do que o marketing afirme.
2. Procurar validação independente. Testes de intrusão de terceiros e certificações como a ISO/IEC 27001 ou a SOC 2 Type II fornecem provas externas, e não alegações autodeclaradas.
3. Examinar o processo de recuperação. O verdadeiro conhecimento zero significa que não existe uma «reposição de palavra-passe» no sentido tradicional. Se o suporte conseguir repor o seu acesso, é porque detém uma chave algures. A recuperação legítima assenta numa chave de recuperação pré-gerada que só o utilizador guarda.
4. Privilegiar criptografia auditável. Não é necessário ler cada linha, mas algoritmos e parâmetros documentados publicamente são um sinal de confiança significativo.

A própria documentação do Passwork é um exemplo prático do que esta lista de verificação deve revelar: uma certificação ISO/IEC 27001, um programa HackerOne para testes de segurança independentes, e uma especificação criptográfica documentada publicamente que enumera todos os algoritmos e parâmetros utilizados, além de código-fonte auditável que os clientes podem analisar diretamente para confirmar que a implementação corresponde à documentação.

Em resumo

A cifragem de conhecimento zero resume-se a uma única decisão de arquitetura: o servidor armazena apenas aquilo que estruturalmente não consegue ler. Tudo o resto, as iterações do PBKDF2, a troca de chaves RSA, a cifragem em dois níveis, existe para impor essa única garantia em cada etapa da cadeia.

Para uma equipa empresarial, trata-se de reduzir o raio de impacto de uma violação. Uma base de dados roubada, uma cópia de segurança comprometida, um agente de suporte com acesso excessivo: nada disso importa se o que é exposto for texto cifrado que ninguém consegue utilizar.

FAQ

Partilha segura de palavras-passe em equipas: Um guia para gestores de TI

Saiba como implementar a partilha segura de palavras-passe em equipas. Descubra as best practices de RBAC, a conformidade com o NIS2 e a integração com o AD para proteger as credenciais partilhadas.

Passwork BlogAlex Muntyan

Shadow IT em 2026: Riscos, deteção e como geri-lo

O Shadow IT em 2026 abrange agentes de IA, contas SaaS órfãs e sessões de LLM não monitorizadas: riscos que a maioria das organizações não consegue ver. Saiba o que mudou, quanto custa e como uma estrutura de governação em 6 etapas fecha esta lacuna.

Passwork BlogAlex Muntyan

Gestão de palavras-passe para equipas: A solução de que toda a PME precisa

Armazenar palavras-passe no Slack e em navegadores expõe a sua empresa a violações. Descubra porque é que as ferramentas pessoais falham para as equipas, como assegurar, com um único clique, a saída segura de colaboradores que deixam a empresa, e porque é que as diretrizes mais recentes do NIST desaconselham a rotação forçada de palavras-passe.

Passwork BlogAlex Muntyan

Zero-Knowledge-Verschlüsselung ist eine Architektur, bei der Ver- und Entschlüsselung ausschließlich auf dem Gerät des Benutzers stattfinden. Der Server speichert nur Geheimtext und verschlüsselte Schlüssel. Selbst wenn der Anbieter kompromittiert wird, einer gerichtlichen Anordnung unterliegt oder ein böswilliger Mitarbeiter Datenbankzugriff hat, bleibt der Klartext unerreichbar.

Was Zero-Knowledge tatsächlich bedeutet

Zero-Knowledge-Architektur bedeutet, dass der Anbieter keine Möglichkeit hat, Ihre Klartextdaten zu lesen — nicht, dass er sich einfach entscheidet, nicht hinzuschauen. Der entscheidende Unterschied: Schlüssel werden vollständig auf dem Client generiert und verwendet, und der Server hält immer nur verschlüsselte Blobs, die er selbst nicht entschlüsseln kann, auch nicht unter rechtlichem Zwang.

Vergleichen Sie das mit gewöhnlichem „verschlüsseltem Speicher". Ein Anbieter mag Ihre Daten im Ruhezustand verschlüsseln, aber wenn er auch den Entschlüsselungsschlüssel besitzt, kann er diese Daten technisch jederzeit lesen. Verschlüsselung im Ruhezustand schützt vor physischem Diebstahl von Festplatten. Sie schützt nicht vor dem Anbieter selbst oder vor jedem, der die Infrastruktur des Anbieters kompromittiert.

Drei Eigenschaften unterscheiden echtes Zero-Knowledge von Marketing-Texten:

1. Schlüssel werden clientseitig generiert, unter Verwendung eines kryptographisch sicheren Pseudozufallszahlengenerators (CSPRNG), nicht auf einem Server.
2. Der private Schlüssel verlässt das Gerät niemals im Klartext und wird niemals unverschlüsselt an den Server übertragen.
3. Der Server speichert nur verschlüsselte Blobs, einschließlich verschlüsselter Kopien der Schlüssel selbst.

Wie die Verschlüsselungskette funktioniert: Ein praktisches Beispiel

Zero-Knowledge-Verschlüsselung basiert auf einer Kette von Schlüsselableitungs- und Verschlüsselungsschritten, wobei jeder den nächsten entsperrt. In Passworks Kryptographiemodell wird ein Masterpasswort durch PBKDF2 zu einem Masterschlüssel. Dieser Masterschlüssel entschlüsselt einen privaten RSA-Schlüssel, der Tresorschlüssel entschlüsselt, die wiederum die Datensatzschlüssel entschlüsseln, welche die eigentlichen Passwörter und Geheimnisse schützen.

Hier ist die clientseitige Kette Schritt für Schritt:

1. Masterpasswort → Masterschlüssel. Der Benutzer gibt sein Masterpasswort ein. PBKDF2 (HMAC-SHA-256, 300.000 Iterationen) leitet einen 512-Bit-Masterschlüssel ab, und die serverseitige Ableitung läuft mit 600.000 Iterationen für eine zusätzliche Schicht. Die hohe Iterationszahl existiert aus einem Grund: Sie macht das Brute-Forcing des Passworts rechenintensiv.
2. Masterschlüssel → privater RSA-Schlüssel. Der Masterschlüssel entschlüsselt den privaten RSA-2048-Schlüssel des Benutzers (RSA-OAEP, SHA-256) mit AES-256. Dieser private Schlüssel liegt verschlüsselt auf dem Server. Ohne das Masterpasswort sind es nur inerte Daten.
3. Privater Schlüssel → Tresorschlüssel. Der private RSA-Schlüssel entschlüsselt einen symmetrischen Tresorschlüssel (256-Bit, etwa 596 Bit Entropie). Ein Tresor enthält eine Sammlung von Datensätzen, die von Teammitgliedern geteilt werden, und jeder Tresor trägt seinen eigenen eindeutigen Schlüssel.
4. Tresorschlüssel → Datensatzschlüssel → Datensatzdaten. Der Tresorschlüssel entschlüsselt einzelne Datensatzschlüssel, die wiederum die eigentlichen Passwörter, Geheimnisse und angehängten Dateien entschlüsseln — alles durch AES-256.
5. Eine zweite, unabhängige Schicht. Getrennt von der clientseitigen Kette verschlüsselt ein Serverschlüssel (256-Bit, OpenSSL-generiert) die Datenbank mit AES-256. Zwei unabhängige Schlüssel, zwei unabhängige Schichten. Die Kompromittierung eines davon kompromittiert nicht den anderen.

Was der Server tatsächlich speichert. Nicht das Masterpasswort. Nicht den Klartext von irgendetwas. Er speichert: den verschlüsselten Masterschlüssel-Hash zur Identitätsverifizierung, den verschlüsselten privaten Schlüssel, verschlüsselte Tresor- und Datensatzschlüssel, verschlüsselte Datensatzdaten und einen Verifizierungs-Hash, der verwendet wird, um einen Anmeldeversuch zu bestätigen, ohne jemals das Passwort selbst zu sehen.

Da der Server niemals den clientseitigen Entschlüsselungsschlüssel besitzt, liefert ein Datenbankeinbruch nur Geheimtext. Das ist der Nutzen der gesamten Kette: Wer die Datenbank, Backups oder den serverseitigen Schlüssel stiehlt, erhält nichts Verwertbares.

Dieser Schutz hat jedoch eine Grenze. Er verteidigt gegen Infrastrukturkompromittierung, nicht gegen einen Angreifer, der ein gültiges Masterpasswort erlangt und sich als Benutzer anmeldet. Der Cost of a Data Breach Report 2025 von IBM stellt fest, dass Angreifer zunehmend auf gestohlene Anmeldedaten setzen, anstatt die Infrastruktur direkt auszunutzen — ein Weg, den Zero-Knowledge-Architektur nicht abdeckt. Das ist ein Grund, die Architektur mit MFA zu kombinieren.

Was Zero-Knowledge schützt — und was nicht

Zero-Knowledge ist leistungsstark, aber keine Magie. Es verteidigt die Speicherschicht, nicht den Endpunkt, und das Verständnis dieser Grenze unterscheidet einen informierten Käufer von jemandem, der die Slogans eines Anbieters wiederholt.

Schützt vor:

• Server-Einbrüche. Ein Angreifer, der die Datenbank exportiert, erhält verschlüsselte Blobs, nichts weiter.
• Insider-Zugriff. Datenbankadministratoren, Backup-Operatoren und Support-Mitarbeiter können keinen Klartext lesen, weil keiner von ihnen die clientseitigen Schlüssel besitzt. Dies erzwingt die Trennung von Aufgaben: Die Person, die den Server wartet, erhält nicht automatisch Zugriff auf die darin gespeicherten Passwörter.
• Vorladungen und gerichtliche Anordnungen. Wer auch immer die Infrastruktur betreibt, hat nichts Lesbares zu übergeben, da die Entschlüsselungsschlüssel niemals den Client verlassen.
• Datenbanklecks oder gestohlene Backups. Exponierte Datensätze sind Geheimtext, ohne die clientseitigen Schlüssel nutzlos.

Schützt nicht vor:

• Phishing. Wenn Sie Ihr Masterpasswort einem Angreifer übergeben, kann die Architektur ihn nicht aufhalten.
• Öffentlichem Teilen entschlüsselter Daten. Sobald Sie etwas entschlüsselt und irgendwo unsicher eingefügt haben, ist Verschlüsselung nicht mehr die relevante Kontrolle.
• Metadaten-Lecks. Der Server weiß typischerweise, wann Sie auf einen Tresor zugegriffen haben, auch wenn er nicht weiß, worauf Sie zugegriffen haben.

Datensicherheit wird üblicherweise über drei Zustände beschrieben: im Ruhezustand, bei der Übertragung und bei der Nutzung. Zero-Knowledge-Architektur bezieht sich grundlegend auf den Ruhezustand: Der Server speichert Geheimtext, den er nicht entschlüsseln kann, unabhängig davon, wie darauf zugegriffen wird.

Bei der Übertragung kommt der Schutz von TLS, einer separaten Kontrolle. Was Zero-Knowledge hier hinzufügt, ist ein Nebeneffekt, kein Ersatz: Daten verlassen den Client bereits verschlüsselt, sodass selbst ein TLS-Fehler keinen Klartext offenlegen würde.

Bei der Nutzung, wenn der Tresor entsperrt und ein Datensatz entschlüsselt wird, geschieht diese Entschlüsselung nur innerhalb des authentifizierten Clients des Benutzers selbst, für diesen einen Benutzer. Der Server empfängt oder beobachtet den Klartext zu keinem Zeitpunkt in diesem Prozess.

Was Zero-Knowledge in einer Self-Hosted-Umgebung bedeutet

Self-Hosting und Zero-Knowledge sind unabhängige Eigenschaften. Self-Hosting kontrolliert, wo die Infrastruktur sich befindet. Zero-Knowledge kontrolliert, ob derjenige, der diese Infrastruktur betreibt, die Daten lesen kann.

In einer Self-Hosted-Bereitstellung befindet sich die gesamte Kette — Server, Datenbank und verschlüsselte Schlüssel — auf der eigenen Hardware des Unternehmens, ohne ausgehende Verbindung. Was sich ändert, wenn dieses Setup mit Zero-Knowledge kombiniert wird:

• Keine externe Partei im Spiel. Es gibt keine Anbieterinfrastruktur, kein Anbieterpersonal und keinen ausgehenden Datenverkehr, der Daten oder Schlüssel aus dem Unternehmen trägt. Alles, was die Verschlüsselungskette berührt, bleibt innerhalb des Unternehmensnetzwerks.
• Datenresidenz und Verschlüsselung werden zu separaten Antworten. Self-Hosting klärt, wo die Daten physisch liegen. Zero-Knowledge klärt, wer sie selbst dort lesen kann. Zusammen verengen sie die Vertrauensgrenze auf das Client-Gerät, innerhalb einer Infrastruktur, die das Unternehmen bereits Ende-zu-Ende kontrolliert.
• Die Kosten verschieben sich, sie verschwinden nicht. Patching, Backups und Verfügbarkeit wandern vom Anbieter zur internen IT. Das ist ein betrieblicher Kompromiss, kein sicherheitstechnischer, und gehört in die TCO-Betrachtung.

Für regulierte Branchen lässt sich diese Unterscheidung direkt auf Compliance-Fragen zur Datenresidenz abbilden.

Zero-Knowledge in der Praxis verstärken

Zero-Knowledge-Verschlüsselung schützt Daten, deckt aber keine Authentifizierungsgewohnheiten oder Netzwerkexposition ab. Die Kombination mit MFA, Masterpasswort-Hygiene, organisatorischen Kontrollen und Air-Gap-Bereitstellung schließt die verbleibenden Lücken.

Sicherheitsgrundlage:

• Multi-Faktor-Authentifizierung (MFA). Ein Angreifer, der das Masterpasswort phisht, benötigt immer noch den zweiten Faktor, um den Tresor zu entsperren.
• Masterpasswort-Hygiene. Die Iterationszahl von PBKDF2 verlangsamt Brute-Forcing, kann aber ein schwaches oder wiederverwendetes Passwort nicht reparieren. Länge und Einzigartigkeit zählen immer noch mehr als die KDF, die sie umgibt.
• Organisatorische Kontrollen. Rollenbasierter Zugriff, mit AD/LDAP synchronisierte Gruppenberechtigungen und ein vollständiges Audit-Log begrenzen, wie viel Schaden ein kompromittiertes Konto anrichten kann.

Air-Gap-Bereitstellung: Ein Self-Hosted-Passwortmanager ohne ausgehende Verbindung eliminiert Remote-Exploitation, Cloud-Supply-Chain-Kompromittierung und Netzwerk-Interception als Angriffsvektoren vollständig.

Wie man eine Zero-Knowledge-Behauptung überprüft

Die Überprüfung einer Zero-Knowledge-Behauptung ohne Quellcode-Lektüre läuft auf fünf Punkte hinaus, die ein seriöser Anbieter bereitwillig dokumentieren wird: ein technisches Whitepaper, Nachweis clientseitiger Schlüsselgenerierung, unabhängige Audits, ein ehrlicher Wiederherstellungsprozess und offene Kryptographie. Vage Marketing-Seiten, die diese Details überspringen, sind ein Signal, kein Beweis, für ein Problem.

Zero-Knowledge-Verifizierungs-Checkliste (5 Punkte):

1. Bestätigen Sie clientseitige Verschlüsselung. Prüfen Sie, ob die Verschlüsselung erfolgt, bevor Daten den Browser oder die App verlassen. Wenn Schlüssel auf dem Server generiert werden, ist es kein Zero-Knowledge, unabhängig davon, was das Marketing sagt.
2. Suchen Sie nach unabhängiger Validierung. Penetrationstests durch Dritte und Zertifizierungen wie ISO/IEC 27001 oder SOC 2 Type II liefern externe Nachweise, keine selbstberichteten Behauptungen.
3. Untersuchen Sie den Wiederherstellungsprozess. Echtes Zero-Knowledge bedeutet kein „Passwort zurücksetzen" im traditionellen Sinne. Wenn der Support Ihren Zugang zurücksetzen kann, hält er irgendwo einen Schlüssel. Legitime Wiederherstellung basiert auf einem vorgenerierten Wiederherstellungsschlüssel, den nur der Benutzer aufbewahrt.
4. Bevorzugen Sie überprüfbare Kryptographie. Sie müssen nicht jede Zeile lesen, aber öffentlich dokumentierte Algorithmen und Parameter sind ein bedeutsames Vertrauenssignal.

Die Dokumentation von Passwork ist ein funktionierendes Beispiel dafür, was diese Checkliste zutage fördern sollte: eine ISO/IEC 27001-Zertifizierung, ein HackerOne-Programm für unabhängige Sicherheitstests und eine öffentlich dokumentierte kryptographische Spezifikation, die jeden verwendeten Algorithmus und Parameter auflistet, sowie überprüfbaren Quellcode, den Kunden direkt einsehen können, um zu verifizieren, dass die Implementierung der Dokumentation entspricht.

Das Fazit

Zero-Knowledge-Verschlüsselung läuft auf eine Designentscheidung hinaus: Der Server speichert nur das, was er strukturell nicht lesen kann. Alles andere — die PBKDF2-Iterationen, der RSA-Schlüsselaustausch, die zweistufige Verschlüsselung — existiert, um diese eine Garantie in jedem Schritt der Kette durchzusetzen.

Für ein Unternehmensteam geht es darum, den Explosionsradius eines Einbruchs zu verkleinern. Eine gestohlene Datenbank, ein kompromittiertes Backup, ein Support-Mitarbeiter mit zu viel Zugriff: Nichts davon ist relevant, wenn das, was geleakt wird, Geheimtext ist, den niemand verwenden kann.

FAQ

Sichere Passwortfreigabe in Teams: Ein Leitfaden für IT-Manager

Erfahren Sie, wie Sie sichere Passwortfreigabe in Teams implementieren. Entdecken Sie Best Practices für RBAC, NIS2-Compliance und AD-Integration zum Schutz gemeinsam genutzter Zugangsdaten.

Passwork BlogAlex Muntyan

Schatten-IT in 2026: Risiken, Erkennung und Management

Schatten-IT in 2026 umfasst KI-Agenten, verwaiste SaaS-Konten und nicht überwachte LLM-Sitzungen — Risiken, die die meisten Organisationen nicht sehen können. Erfahren Sie, was sich geändert hat, was es kostet und wie ein 6-Schritte-Governance-Framework die Lücke schließt.

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

El cifrado de conocimiento cero es una arquitectura donde el cifrado y descifrado ocurren exclusivamente en el dispositivo del usuario. El servidor almacena únicamente texto cifrado y claves cifradas. Incluso si el proveedor sufre una brecha, recibe una citación judicial o tiene un empleado malintencionado con acceso a la base de datos, el texto plano permanece fuera de alcance.

Qué significa realmente conocimiento cero

La arquitectura de conocimiento cero significa que el proveedor no tiene forma de leer sus datos en texto plano, no que simplemente elige no mirar. La distinción que importa: las claves se generan y utilizan completamente en el cliente, y el servidor solo almacena blobs cifrados que no puede descifrar por sí mismo, incluso bajo orden judicial.

Compare esto con el «almacenamiento cifrado» ordinario. Un proveedor podría cifrar sus datos en reposo, pero si también posee la clave de descifrado, técnicamente puede leer esos datos cuando quiera. El cifrado en reposo protege contra el robo físico de discos duros. No protege contra el propio proveedor, ni contra cualquiera que comprometa la infraestructura del proveedor.

Tres propiedades separan el verdadero conocimiento cero del texto de marketing:

1. Las claves se generan en el lado del cliente, utilizando un generador de números pseudoaleatorios criptográficamente seguro (CSPRNG), no en un servidor.
2. La clave privada nunca abandona el dispositivo en texto plano y nunca se transmite al servidor sin cifrar.
3. El servidor almacena solo blobs cifrados, incluyendo copias cifradas de las propias claves.

Cómo funciona la cadena de cifrado: un ejemplo real

El cifrado de conocimiento cero funciona mediante una cadena de pasos de derivación y cifrado de claves, donde cada uno desbloquea el siguiente. En el modelo criptográfico de Passwork, una contraseña maestra se convierte en una clave maestra a través de PBKDF2. Esa clave maestra descifra una clave privada RSA, que descifra las claves de bóveda, que a su vez descifran las claves de registro que protegen las contraseñas y secretos reales.

Aquí está la cadena del lado del cliente, paso a paso:

1. Contraseña maestra → clave maestra. El usuario introduce su contraseña maestra. PBKDF2 (HMAC-SHA-256, 300.000 iteraciones) deriva una clave maestra de 512 bits, y la derivación del lado del servidor ejecuta 600.000 iteraciones para una capa adicional. El alto número de iteraciones existe por una razón: hace que el ataque de fuerza bruta a la contraseña sea computacionalmente costoso.
2. Clave maestra → clave privada RSA. La clave maestra descifra la clave privada RSA-2048 del usuario (RSA-OAEP, SHA-256) con AES-256. Esa clave privada permanece cifrada en el servidor. Sin la contraseña maestra, son datos inertes.
3. Clave privada → clave de bóveda. La clave privada RSA descifra una clave simétrica de bóveda (256 bits, aproximadamente 596 bits de entropía). Una bóveda contiene una colección de registros compartidos entre miembros del equipo, y cada bóveda tiene su propia clave única.
4. Clave de bóveda → clave de registro → datos del registro. La clave de bóveda descifra las claves de registro individuales, que a su vez descifran las contraseñas reales, secretos y archivos adjuntos, todo mediante AES-256.
5. Una segunda capa independiente. Independientemente de la cadena del lado del cliente, una clave de servidor (256 bits, generada con OpenSSL) cifra la base de datos con AES-256. Dos claves independientes, dos capas independientes. Comprometer una no compromete la otra.

Qué almacena realmente el servidor. No la contraseña maestra. No el texto plano de nada. Almacena: el hash cifrado de la clave maestra para verificación de identidad, la clave privada cifrada, las claves de bóveda y registro cifradas, los datos de registro cifrados, y un hash de verificación utilizado para confirmar un intento de inicio de sesión sin ver nunca la contraseña en sí.

Debido a que el servidor nunca posee la clave de descifrado del lado del cliente, una brecha de base de datos solo produce texto cifrado. Ese es el beneficio de toda la cadena: cualquiera que robe la base de datos, copias de seguridad o la clave del lado del servidor no obtiene nada utilizable.

Sin embargo, esa protección tiene un límite. Defiende contra el compromiso de infraestructura, no contra un atacante que obtiene una contraseña maestra válida e inicia sesión como el usuario. El informe de IBM Cost of a Data Breach 2025 señala que los atacantes dependen cada vez más de credenciales robadas en lugar de explotar directamente la infraestructura, un camino que la arquitectura de conocimiento cero no cubre. Es una razón para combinar la arquitectura con MFA.

Qué protege el conocimiento cero y qué no

El conocimiento cero es poderoso, pero no es magia. Defiende la capa de almacenamiento, no el endpoint, y entender ese límite es lo que separa a un comprador informado de alguien que repite el eslogan de un proveedor.

Protege contra:

• Brechas de servidor. Un atacante que extrae la base de datos obtiene blobs cifrados, nada más.
• Acceso interno. Los administradores de bases de datos, operadores de copias de seguridad y personal de soporte no pueden leer texto plano, porque ninguno de ellos posee las claves del lado del cliente. Esto es lo que impone la separación de funciones: la persona que mantiene el servidor no obtiene automáticamente acceso a leer las contraseñas almacenadas en él.
• Citaciones y órdenes judiciales. Quien opera la infraestructura no tiene nada legible que entregar, ya que las claves de descifrado nunca abandonan el cliente.
• Filtraciones de bases de datos o copias de seguridad robadas. Los registros expuestos son texto cifrado, inútiles sin las claves del lado del cliente.

No protege contra:

• Phishing. Si entrega su contraseña maestra a un atacante, la arquitectura no puede detenerlo.
• Compartir públicamente datos descifrados. Una vez que ha descifrado algo y lo ha pegado en algún lugar inseguro, el cifrado ya no es el control relevante.
• Filtración de metadatos. El servidor típicamente sabe cuándo accedió a una bóveda, aunque no sepa a qué accedió.

La seguridad de datos generalmente se describe en tres estados: en reposo, en tránsito y en uso. La arquitectura de conocimiento cero trata fundamentalmente sobre en reposo: el servidor almacena texto cifrado que no puede descifrar, independientemente de cómo se acceda.

En tránsito, la protección proviene de TLS, un control separado. Lo que el conocimiento cero añade aquí es un efecto secundario, no un sustituto: los datos salen del cliente ya cifrados, por lo que incluso un fallo de TLS no expondría texto plano.

En uso, cuando la bóveda está desbloqueada y un registro se descifra, ese descifrado ocurre solo dentro del propio cliente del usuario autenticado, para ese único usuario. El servidor nunca recibe ni observa el texto plano en ningún punto de ese proceso.

Qué significa el conocimiento cero en un entorno autoalojado

El autoalojamiento y el conocimiento cero son propiedades independientes. El autoalojamiento controla dónde reside la infraestructura. El conocimiento cero controla si quien opera esa infraestructura puede leer los datos.

En un despliegue autoalojado, toda la cadena — servidor, base de datos y claves cifradas — reside en el propio hardware de la empresa, sin conexión saliente. Qué cambia cuando esa configuración se combina con conocimiento cero:

• Ninguna parte externa en el proceso. No hay infraestructura del proveedor, no hay personal del proveedor, y no hay tráfico saliente transportando datos o claves fuera de las instalaciones. Todo lo que toca la cadena de cifrado permanece dentro de la red de la empresa.
• Residencia y cifrado se convierten en respuestas separadas. El autoalojamiento establece dónde residen físicamente los datos. El conocimiento cero establece quién puede leerlos incluso allí. Juntos, reducen el perímetro de confianza hasta el dispositivo cliente, dentro de una infraestructura que la empresa ya controla de extremo a extremo.
• El coste se desplaza, no desaparece. Parches, copias de seguridad y tiempo de actividad pasan del proveedor al departamento de TI interno. Eso es un compromiso operativo, no de seguridad, y pertenece a la conversación sobre TCO.

Para industrias reguladas, esta distinción se corresponde directamente con las preguntas de cumplimiento sobre residencia de datos.

Reforzar el conocimiento cero en la práctica

El cifrado de conocimiento cero protege los datos, pero no cubre los hábitos de autenticación ni la exposición de red. Combinarlo con MFA, buenas prácticas de contraseña maestra, controles organizacionales y despliegue sin conexión cierra las brechas restantes.

Base de seguridad:

• Autenticación multifactor (MFA). Un atacante que obtiene la contraseña maestra mediante phishing aún necesita el segundo factor para desbloquear la bóveda.
• Buenas prácticas de contraseña maestra. El número de iteraciones de PBKDF2 ralentiza el ataque de fuerza bruta, pero no puede arreglar una contraseña débil o reutilizada. La longitud y la unicidad siguen importando más que el KDF que las rodea.
• Controles organizacionales. El control de acceso basado en roles, los permisos de grupo sincronizados desde AD/LDAP, y un registro de auditoría completo limitan cuánto daño puede causar una cuenta comprometida.

Despliegue sin conexión: Ejecutar un gestor de contraseñas autoalojado sin conexión saliente elimina por completo la explotación remota, el compromiso de la cadena de suministro en la nube y la interceptación de red como vectores de ataque.

Cómo verificar una afirmación de conocimiento cero

Verificar una afirmación de conocimiento cero sin leer el código fuente se reduce a comprobar cinco cosas que un proveedor legítimo documentará fácilmente: un whitepaper técnico, prueba de generación de claves en el cliente, auditorías independientes, un flujo de recuperación honesto y criptografía abierta. Las páginas de marketing vagas que omiten estos detalles son una señal, no una prueba, de un problema.

Lista de verificación de conocimiento cero (5 puntos):

1. Confirme el cifrado del lado del cliente. Verifique si el cifrado ocurre antes de que los datos salgan del navegador o la aplicación. Si las claves se generan en el servidor, no es conocimiento cero, independientemente de lo que diga el marketing.
2. Busque validación independiente. Las pruebas de penetración de terceros y certificaciones como ISO/IEC 27001 o SOC 2 Type II proporcionan evidencia externa, no afirmaciones autoinformadas.
3. Examine el flujo de recuperación. El verdadero conocimiento cero significa que no hay «restablecimiento de contraseña» en el sentido tradicional. Si el soporte puede restablecer su acceso, tienen una clave en algún lugar. La recuperación legítima depende de una clave de recuperación pregenerada que solo el usuario almacena.
4. Favorezca la criptografía auditable. No necesita leer cada línea, pero los algoritmos y parámetros documentados públicamente son una señal de confianza significativa.

La propia documentación de Passwork es un ejemplo funcional de lo que esta lista de verificación debería revelar: una certificación ISO/IEC 27001, un programa de HackerOne para pruebas de seguridad independientes, y una especificación criptográfica documentada públicamente que lista cada algoritmo y parámetro utilizado, además de código fuente auditable que los clientes pueden revisar directamente para verificar que la implementación coincide con la documentación.

Conclusión

El cifrado de conocimiento cero se reduce a una decisión de diseño: el servidor almacena solo lo que estructuralmente no puede leer. Todo lo demás — las iteraciones de PBKDF2, el intercambio de claves RSA, el cifrado de dos niveles — existe para hacer cumplir esa única garantía en cada paso de la cadena.

Para un equipo empresarial, se trata de reducir el radio de impacto de una brecha. Una base de datos robada, una copia de seguridad comprometida, un agente de soporte con demasiado acceso: nada de eso importa si lo que se filtra es texto cifrado que nadie puede usar.

Preguntas frecuentes

Compartir contraseñas de forma segura en equipos: Una guía para responsables de TI

Aprenda a implementar el intercambio seguro de contraseñas en equipos. Descubra las mejores prácticas para RBAC, cumplimiento de NIS2 e integración con AD para proteger credenciales compartidas.

Passwork BlogAlex Muntyan

Shadow IT en 2026: Riesgos, detección y cómo gestionarlo

El shadow IT en 2026 abarca agentes de IA, cuentas SaaS huérfanas y sesiones LLM no monitoreadas — riesgos que la mayoría de las organizaciones no pueden ver. Aprenda qué ha cambiado, cuánto cuesta y cómo un marco de gobernanza de 6 pasos cierra la brecha.

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

Zero-knowledge encryption is an architecture where encryption and decryption happen exclusively on the user's device. The server stores only ciphertext and encrypted keys. Even if the provider is breached, subpoenaed, or has a rogue employee with database access, the plaintext stays out of reach.

What zero knowledge actually means

Zero-knowledge architecture means the provider has no way to read your plaintext data, not that it simply chooses not to look. The distinction that matters: keys are generated and used entirely on the client, and the server only ever holds encrypted blobs it cannot decrypt on its own, even under legal compulsion.

Compare that with ordinary "encrypted storage." A provider might encrypt your data at rest, but if it also holds the decryption key, it can technically read that data whenever it wants. Encryption at rest protects against physical theft of hard drives. It doesn't protect against the provider itself, or against anyone who compromises the provider's infrastructure.

Three properties separate real zero knowledge from marketing copy:

1. Keys are generated client-side, using a cryptographically secure pseudo-random number generator (CSPRNG), not on a server.
2. The private key never leaves the device in plaintext and is never transmitted to the server unencrypted.
3. The server stores only encrypted blobs, including encrypted copies of the keys themselves.

How the encryption chain works: a real example

Zero-knowledge encryption runs on a chain of key derivation and encryption steps, each one unlocking the next. In Passwork's cryptography model, a master password becomes a master key through PBKDF2. That master key decrypts a private RSA key, which decrypts vault keys, which decrypt the record keys protecting the actual passwords and secrets.

Here's the client-side chain, step by step:

1. Master password → master key. The user enters their master password. PBKDF2 (HMAC-SHA-256, 300,000 iterations) derives a 512-bit master key, and the server-side derivation runs at 600,000 iterations for an added layer. The high iteration count exists for one reason: it makes brute-forcing the password computationally expensive.
2. Master key → private RSA key. The master key decrypts the user's private RSA-2048 key (RSA-OAEP, SHA-256) with AES-256. That private key sits encrypted on the server. Without the master password, it's inert data.
3. Private key → vault key. The private RSA key decrypts a symmetric vault key (256-bit, roughly 596 bits of entropy). A vault holds a collection of records shared among team members, and each vault carries its own unique key.
4. Vault key → record key → record data. The vault key decrypts individual record keys, which in turn decrypt the actual passwords, secrets, and attached files, all through AES-256.
5. A second, independent layer. Separately from the client-side chain, a server key (256-bit, OpenSSL-generated) encrypts the database with AES-256. Two independent keys, two independent layers. Compromising one doesn't compromise the other.

What the server actually stores. Not the master password. Not the plaintext of anything. It stores: the encrypted master key hash for identity verification, the encrypted private key, encrypted vault and record keys, encrypted record data, and a verification hash used to confirm a login attempt without ever seeing the password itself.

Because the server never holds the client-side decryption key, a database breach yields only ciphertext. That's the payoff of the whole chain: anyone who steals the database, backups, or server-side key gets nothing usable.

That protection has a limit, though. It defends against infrastructure compromise, not against an attacker who obtains a valid master password and logs in as the user. IBM's 2025 Cost of a Data Breach Report notes that attackers increasingly rely on stolen credentials rather than exploiting infrastructure directly, a path zero-knowledge architecture doesn't cover. It's a reason to pair the architecture with MFA.

What zero-knowledge protects, and what it doesn't

Zero-knowledge is powerful, but it isn't magic. It defends the storage layer, not the endpoint, and understanding that boundary is what separates an informed buyer from someone repeating a vendor's tagline.

Protects against:

• Server breaches. An attacker who dumps the database gets encrypted blobs, nothing more.
• Insider access. Database administrators, backup operators, and support staff can't read plaintext, because none of them hold the client-side keys. This is what enforces separation of duties: the person who maintains the server doesn't automatically get to read the passwords stored inside it.
• Subpoenas and legal orders. Whoever operates the infrastructure has nothing readable to hand over, since the decryption keys never leave the client.
• Database leaks or stolen backups. Exposed records are ciphertext, useless without the client-side keys.

Does not protect against:

• Phishing. If you hand your master password to an attacker, the architecture can't stop them.
• Public sharing of decrypted data. Once you've decrypted something and pasted it somewhere insecure, encryption is no longer the relevant control.
• Metadata leakage. The server typically knows when you accessed a vault, even if it doesn't know what you accessed.

Data security is usually described across three states: at rest, in transit, and in use. Zero-knowledge architecture is fundamentally about at rest: the server stores ciphertext it cannot decrypt, regardless of how it's accessed.

In transit, protection comes from TLS, a separate control. What zero-knowledge adds here is a side effect, not a substitute: data leaves the client already encrypted, so even a TLS failure wouldn't expose plaintext.

In use, when the vault is unlocked and a record gets decrypted, that decryption happens only inside the authenticated user's own client, for that one user. The server never receives or observes the plaintext at any point in that process.

What zero-knowledge means in a self-hosted environment

Self-hosting and zero-knowledge are independent properties. Self-hosting controls where the infrastructure lives. Zero-knowledge controls whether whoever operates that infrastructure can read the data.

In a self-hosted deployment, the entire chain, server, database, and encrypted keys, sits on the company's own hardware, with no outbound connection. What changes when that setup combines with zero-knowledge:

• No external party in the loop. There's no vendor infrastructure, no vendor staff, and no outbound traffic carrying data or keys off-premises. Everything the encryption chain touches stays inside the company's network.
• Residency and encryption become separate answers. Self-hosting settles where the data physically sits. Zero-knowledge settles who can read it even there. Together, they narrow the trust boundary down to the client device, inside infrastructure the company already controls end to end.
• The cost shifts, it doesn't disappear. Patching, backups, and uptime move from vendor to internal IT. That's an operational trade-off, not a security one, and it belongs in the TCO conversation.

For regulated industries, this distinction maps directly onto compliance questions around data residency.

Reinforcing zero-knowledge in practice

Zero-knowledge encryption protects data, but it doesn't cover authentication habits or network exposure. Pairing it with MFA, master password hygiene, organizational controls, and air-gapped deployment closes the remaining gaps.

Security foundation:

• Multi-factor authentication (MFA). An attacker who phishes the master password still needs the second factor to unlock the vault.
• Master password hygiene. PBKDF2's iteration count slows brute-forcing, but it can't fix a weak or reused password. Length and uniqueness still matter more than the KDF around them.
• Organizational controls. Role-based access, group permissions synced from AD/LDAP, and a full audit log limit how much damage one compromised account can do.

Air-gapped deployment: Running a self-hosted password manager with no outbound connection removes remote exploitation, cloud supply-chain compromise, and network interception as attack vectors entirely.

How to verify a zero-knowledge claim

Verifying a zero-knowledge claim without reading source code comes down to checking five things a legitimate vendor will readily document: a technical whitepaper, proof of client-side key generation, independent audits, an honest recovery flow, and open cryptography. Vague marketing pages that skip these details are a signal, not proof, of a problem.

Zero-knowledge verification checklist (5 points):

1. Confirm client-side encryption. Check whether encryption happens before data leaves the browser or app. If keys are generated on the server, it isn't zero-knowledge, regardless of what the marketing says.
2. Look for independent validation. Third-party penetration tests and certifications such as ISO/IEC 27001 or SOC 2 Type II provide external evidence, not self-reported claims.
3. Examine the recovery flow. True zero-knowledge means no "password reset" in the traditional sense. If support can reset your access, they hold a key somewhere. Legitimate recovery relies on a pre-generated recovery key that only the user stores.
4. Favor auditable cryptography. You don't need to read every line, but publicly documented algorithms and parameters is a meaningful trust signal.

Passwork's own documentation is a working example of what this checklist should turn up: an ISO/IEC 27001 certification, a HackerOne program for independent security testing, and a publicly documented cryptographic specification listing every algorithm and parameter used, and auditable source code that customers can review directly to verify the implementation matches the documentation.

The bottom line

Zero-knowledge encryption comes down to one design decision: the server stores only what it structurally cannot read. Everything else, the PBKDF2 iterations, the RSA key exchange, the two-level encryption, exists to enforce that one guarantee at every step of the chain.

For an enterprise team, this is about shrinking the blast radius of a breach. A stolen database, a compromised backup, a support agent with too much access: none of it matters if what leaks is ciphertext nobody can use.

FAQ

Secure password sharing in teams: A guide for IT managers

Learn how to implement secure password sharing in teams. Discover best practices for RBAC, NIS2 compliance, and AD integration to protect shared credentials.

Passwork BlogAlex Muntyan

Shadow IT in 2026: Risks, detection, and how to manage it

Shadow IT in 2026 spans AI agents, orphaned SaaS accounts, and unmonitored LLM sessions — risks most organizations can’t see. Learn what’s changed, what it costs, and how a 6-step governance framework closes the gap.

Passwork BlogAlex Muntyan

Password management for teams: The fix every SMB needs

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

Passwork BlogAlex Muntyan

Pelo segundo trimestre consecutivo, o Passwork recebeu da SourceForge o selo Top Performer, desta vez relativo ao verão de 2026. A SourceForge ajuda os responsáveis por compras de TI a comparar software empresarial com base em opiniões verificadas de clientes, e esta distinção reflete as experiências genuínas das equipas que utilizam o Passwork em produção.

O Passwork reuniu ainda outros reconhecimentos independentes, incluindo o prémio Best Customer Support da Software Advice e o prémio Best Ease of Use da Capterra, todos determinados por opiniões reais de clientes.

O que dizem os clientes sobre o Passwork

As permissões flexíveis, baseadas em funções, continuam a ser uma prioridade para os administradores de TI que gerem os acessos entre equipas.

«Uma das maiores vantagens é a estrutura flexível de permissões. Ao atribuir funções a cada utilizador, foi possível criar um modelo de acesso claro e transparente, que garante que os colaboradores veem apenas as palavras-passe relevantes para as suas responsabilidades.» — Administrador de TI

Uma migração simples a partir de ferramentas legadas é importante para as equipas que abandonam folhas de cálculo ou outros gestores de palavras-passe.

«A nossa pequena empresa queria migrar do KeePass para uma solução com extensão nativa para o navegador e gestão centralizada. Avaliei versões de teste do Bitwarden autoalojado, do KeePass Hub e do Passwork. O Passwork ofereceu a melhor experiência global e o melhor preço.» — Administrador de sistemas

Uma governação de nível empresarial, incluindo a integração com o Active Directory, é decisiva para as organizações que expandem a gestão de acessos.

«A opção autoalojada dá tranquilidade quanto à soberania dos dados, e os controlos de acesso granulares permitem-nos gerir as permissões com precisão. A integração com o Active Directory é fluida e poupa muito tempo de administração.» — CEO

Sobre o prémio

SourceForge é o maior diretório de avaliação e comparação de software B2B do mundo, com quase 20 milhões de utilizadores mensais que avaliam software empresarial. Atribui o selo Top Performer quatro vezes por ano (primavera, verão, outono e inverno) aos produtos classificados entre os 10 % melhores de mais de 100 000 soluções listadas na plataforma. As classificações dependem exclusivamente do volume, da atualidade e da pontuação das avaliações verificadas, sem qualquer intervenção editorial.

«O reconhecimento consecutivo da SourceForge reflete um nível sustentado de confiança por parte dos profissionais que dependem do Passwork nas suas operações diárias. As opiniões verificadas de clientes são a medida mais credível do valor de um produto na prática, e levamo-las a sério.» — Alex Muntyan, CEO do Passwork

O Passwork tem uma classificação global de 4,9 em 5 estrelas, com pontuações individuais de 4,7 em facilidade de utilização, 4,4 em funcionalidades, 4,7 em design e 5,0 em suporte.

Zum zweiten Mal in Folge hat Passwork das Top Performer Badge von SourceForge erhalten — diesmal für den Sommer 2026. SourceForge unterstützt IT-Einkäufer beim Vergleich von Business-Software auf Basis verifizierter Kundenbewertungen. Diese Auszeichnung spiegelt die ehrlichen Erfahrungen von Teams wider, die Passwork im produktiven Einsatz nutzen.

Passwork hat eine breite Palette unabhängiger Anerkennungen erhalten, darunter Best Customer Support von Software Advice und Best Ease of Use von Capterra — alle basierend auf echtem Kundenfeedback.

Was Kunden über Passwork sagen

Flexible, rollenbasierte Berechtigungen bleiben eine zentrale Priorität für IT-Administratoren, die den Zugriff über mehrere Teams hinweg verwalten.

„Einer der größten Vorteile ist die flexible Berechtigungsstruktur. Durch die Zuweisung von Rollen an einzelne Benutzer konnten wir ein übersichtliches und transparentes Zugriffsmodell aufbauen. So ist sichergestellt, dass Mitarbeiter nur die Passwörter sehen, die für ihre Aufgaben relevant sind." — IT-Admin

Reibungslose Migration von Legacy-Tools ist wichtig für Teams, die von Tabellenkalkulationen oder anderen Passwort-Managern wechseln.

„Unser kleines Unternehmen wollte von KeePass zu einer Lösung mit nativer Browser-Erweiterung und zentraler Verwaltung migrieren. Ich habe Testversionen von selbst gehostetem Bitwarden, KeePass Hub und Passwork evaluiert. Passwork bot das beste Gesamterlebnis und das beste Preis-Leistungs-Verhältnis." — Systemadministrator

Enterprise-taugliche Governance, einschließlich Active Directory-Integration, ist entscheidend für Organisationen, die ihr Zugriffsmanagement skalieren.

„Die Self-Hosted-Option bietet Sicherheit hinsichtlich der Datensouveränität, und die granularen Zugriffskontrollen ermöglichen eine präzise Verwaltung der Berechtigungen. Die Integration mit Active Directory ist nahtlos und spart viel Administrationszeit." — CEO

Über die Auszeichnung

SourceForge ist das weltweit größte Verzeichnis für B2B-Software-Bewertungen und -Vergleiche mit fast 20 Millionen monatlichen Nutzern, die Business-Software evaluieren. Das Top Performer Badge wird viermal jährlich (Frühling, Sommer, Herbst und Winter) an Produkte vergeben, die zu den besten 10 % von mehr als 100.000 gelisteten Lösungen auf der Plattform gehören. Die Rankings basieren ausschließlich auf Anzahl, Aktualität und Bewertung verifizierter Rezensionen — ohne redaktionellen Einfluss.

„Die aufeinanderfolgende Anerkennung von SourceForge spiegelt ein nachhaltiges Vertrauen der Fachleute wider, die sich in ihrem täglichen Betrieb auf Passwork verlassen. Verifiziertes Kundenfeedback ist das glaubwürdigste Maß für den realen Wert eines Produkts, und wir nehmen es ernst." — Alex Muntyan, CEO von Passwork

Passwork hält eine Gesamtbewertung von 4,9 von 5 Sternen mit Einzelwertungen von 4,7 für Benutzerfreundlichkeit, 4,4 für Funktionen, 4,7 für Design und 5,0 für Support.

Por segundo trimestre consecutivo, Passwork ha obtenido la insignia Top Performer de SourceForge — esta vez para el verano de 2026. SourceForge ayuda a los compradores de TI a comparar software empresarial basándose en opiniones verificadas de clientes, y este premio refleja las experiencias reales de equipos que utilizan Passwork en producción.

Passwork ha acumulado un amplio reconocimiento independiente, incluyendo Mejor Soporte al Cliente de Software Advice y Mejor Facilidad de Uso de Capterra — todos determinados por opiniones reales de clientes.

Lo que dicen los clientes sobre Passwork

Los permisos flexibles basados en roles siguen siendo una prioridad clave para los administradores de TI que gestionan el acceso entre equipos.

«Una de las mayores ventajas es su estructura flexible de permisos. Al asignar roles a usuarios individuales, pudimos construir un modelo de acceso limpio y transparente, asegurando que los empleados solo vean las contraseñas relevantes para sus responsabilidades.» — Administrador de TI

La migración fluida desde herramientas heredadas es importante para los equipos que cambian desde hojas de cálculo u otros gestores de contraseñas.

«Nuestra pequeña empresa quería migrar de KeePass a algo con una extensión nativa para navegador y gestión centralizada. Evalué versiones de prueba de Bitwarden autoalojado, KeePass Hub y Passwork. Passwork tuvo la mejor experiencia general y el mejor precio.» — Administrador de Sistemas

La gobernanza de nivel empresarial, incluyendo la integración con Active Directory, es decisiva para las organizaciones que escalan la gestión de accesos.

«La opción autoalojada proporciona tranquilidad en cuanto a la soberanía de los datos, y los controles de acceso granulares nos permiten gestionar los permisos con precisión. La integración con Active Directory es perfecta y ahorra mucho tiempo administrativo.» — CEO

Acerca del premio

SourceForge es el directorio de reseñas y comparación de software B2B más grande del mundo, con casi 20 millones de usuarios mensuales evaluando software empresarial. Otorga la insignia Top Performer cuatro veces al año (primavera, verano, otoño e invierno) a los productos que se sitúan en el 10% superior de más de 100.000 soluciones listadas en la plataforma. Las clasificaciones se basan exclusivamente en el volumen, la actualidad y la puntuación de las reseñas verificadas, sin intervención editorial.

«El reconocimiento consecutivo de SourceForge refleja un nivel sostenido de confianza por parte de los profesionales que confían en Passwork en sus operaciones diarias. Las opiniones verificadas de clientes son la medida más creíble del valor real de un producto, y nos lo tomamos en serio.» — Alex Muntyan, CEO de Passwork

Passwork tiene una puntuación general de 4,9 sobre 5 estrellas, con puntuaciones individuales de 4,7 en facilidad de uso, 4,4 en funcionalidades, 4,7 en diseño y 5,0 en soporte.

For the second consecutive quarter, Passwork has earned SourceForge's Top Performer badge — this time for Summer 2026. SourceForge helps IT buyers compare business software based on verified customer feedback, and this award reflects the honest experiences of teams using Passwork in production.

Passwork has built a broader run of independent recognition, including Best Customer Support from Software Advice and Best Ease of Use from Capterra — all determined by real customer feedback.

What customers say about Passwork

Flexible, role-based permissions remain a key priority for IT administrators managing access across teams.

"One of the biggest advantages is its flexible permission structure. By assigning roles to individual users, we were able to build a clean and transparent access model, ensuring that employees only see the passwords relevant to their responsibilities." — IT Admin

Smooth migration from legacy tools matters for teams switching from spreadsheets or other password managers.

"Our small business wanted to migrate from KeePass to something with a native browser extension and was centrally managed. I evaluated trials of self-hosted Bitwarden, KeePass Hub, and Passwork. Passwork had the best overall experience and the best pricing." — Systems Administrator

Enterprise-grade governance, including Active Directory integration, is decisive for organizations scaling access management.

"The self-hosted option provides peace of mind regarding data sovereignty, and the granular access controls allow us to manage permissions with precision. The integration with Active Directory is seamless and saves a lot of administrative time." — CEO

About the award

SourceForge is the largest B2B software review and comparison directory in the world, with nearly 20 million monthly users evaluating business software. It issues the Top Performer badge four times a year (spring, summer, fall, and winter) to products ranking in the top 10% out of more than 100,000 solutions listed on the platform. Rankings are driven purely by the volume, recency, and rating of verified reviews, with no editorial input.

"Consecutive recognition from SourceForge reflects a sustained level of trust from the professionals who rely on Passwork in their daily operations. Verified customer feedback is the most credible measure of a product's real-world value, and we take it seriously." — Alex Muntyan, CEO of Passwork

Passwork holds a 4.9 out of 5 stars overall rating, with individual scores of 4.7 for ease of use, 4.4 for features, 4.7 for design, and 5.0 for support.

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

A partilha segura de palavras-passe é a prática de conceder acesso a credenciais partilhadas através de um cofre cifrado, em que os utilizadores se autenticam no cofre em vez de receberem a palavra-passe em claro. Preserva a responsabilização individual e proporciona um registo de acesso revogável e auditável — as duas propriedades que os métodos de partilha informais não conseguem oferecer, por razões estruturais.

A maioria das organizações está longe deste padrão. As credenciais circulam na empresa de formas que ninguém concebeu e ninguém monitoriza: uma palavra-passe de base de dados enviada pelo Slack, uma conta de administrador enviada por e-mail a um prestador externo, um início de sessão da folha de pagamentos numa folha de cálculo que três pessoas do departamento financeiro conseguem abrir. O acesso é real. O registo de auditoria não é.

Pontos principais

• As violações de credenciais demoram, em média, 241 dias a ser detetadas. O relatório IBM Cost of a Data Breach Report de 2025 situa o custo médio global de uma violação em 4,44 milhões de dólares. Sem uma governação centralizada das credenciais, não existe forma fiável de saber que uma credencial foi comprometida até que o dano já esteja feito.
• As credenciais partilhadas através do Slack, de e-mail ou de folhas de cálculo não deixam registo de auditoria. Quando um membro da equipa sai, não existe forma fiável de identificar todos os sistemas a que teria acesso. A lacuna de responsabilização é estrutural: a credencial foi partilhada, mas a responsabilidade por ela nunca foi transferida.
• Um gestor de palavras-passe com integração AD/LDAP automatiza o aprovisionamento logo no primeiro dia e revoga todo o acesso ao cofre no momento em que uma conta do AD é desativada. Sem isso, a saída de colaboradores continua a ser manual e os ex-colaboradores mantêm o acesso durante mais tempo do que o previsto.
• A NIST SP 800-63B Rev. 4 eleva o comprimento mínimo da palavra-passe para 15 carateres e proíbe a rotação periódica obrigatória. Se a política da organização ainda exigir uma rotação de 90 em 90 dias, está desatualizada: a rotação forçada leva a alterações incrementais previsíveis, não a credenciais mais fortes.
• Os registos de auditoria transformam um incidente de segurança, que seria um jogo de adivinhas, numa investigação estruturada. Um registo com indicação temporal de quem acedeu a que credencial, quando e a partir de onde indica exatamente o que foi exposto — e quem tinha acesso nessa altura.
• Os inícios de sessão de administrador partilhados tornam impossível a atribuição individual. Quando cinco pessoas utilizam a mesma credencial, não há forma de saber quem alterou uma definição, quem se autenticou durante um incidente ou a quem é preciso revogar o acesso. A partilha mediada pelo cofre atribui o acesso a uma pessoa, não a uma palavra-passe.
• As ligações seguras de utilização única e o acesso com tempo limitado eliminam o problema da revogação manual. A ligação expira após ser utilizada e a permissão expira numa data definida. Sem necessidade de qualquer pedido de saída.

Porque é que a partilha segura de palavras-passe em equipas é fundamental?

Os números financeiros são concretos. Segundo a IBM, no relatório Cost of a Data Breach Report de 2025, o custo médio global de uma violação de dados foi de 4,44 milhões de dólares, e as violações que envolvem credenciais comprometidas demoram, em média, 241 dias a ser identificadas e contidas. Isto equivale a quase oito meses de exposição não detetada — tempo suficiente para um atacante mapear a infraestrutura, exfiltrar dados e estabelecer persistência antes de ser detetado.

O valor de 241 dias não é um cenário extremo. É a mediana. As organizações sem governação centralizada das credenciais não dispõem de um mecanismo fiável para detetar que uma credencial foi comprometida até que o dano já esteja feito. Uma gestão estruturada das credenciais reduz a janela de deteção que torna as violações dispendiosas.

Partilha insegura de palavras-passe: riscos e soluções

O problema da partilha insegura de palavras-passe: mensageiros, folhas de cálculo e e-mail

Segundo o relatório Data Breach Investigations Report da Verizon, de 2026, as credenciais comprometidas são o vetor de acesso inicial em 13 % das violações, mas surgem nalgum ponto da cadeia de ataque em 39 % de todos os incidentes — uma proporção significativa entre mais de 22 000 violações confirmadas analisadas no relatório.

No caso mediano, apenas 49 % das palavras-passe de um utilizador em diferentes serviços são únicas, o que significa que uma única credencial exposta abre, com frequência, o acesso a vários sistemas através de credential stuffing — uma conclusão do próprio estudo suplementar sobre credenciais do DBIR 2025 da Verizon, que continua atual.

O problema de base é estrutural. Quando as credenciais são partilhadas através do Slack, de e-mail ou de uma folha de cálculo, não existe registo de auditoria. Quando um membro da equipa sai, não há forma fiável de identificar todos os sistemas a que teria acesso. A credencial existe algures fora do cofre (numa caixa de entrada, num histórico de conversas, numa captura de ecrã) e não há mecanismo de revogação que não passe por alterar a palavra-passe manualmente, em todos os sistemas afetados.

Esta é a lacuna de responsabilização. A credencial foi partilhada, mas a responsabilidade por ela não foi transferida. Ninguém sabe quem a tem, onde está guardada ou se já foi reencaminhada. Um modelo de acesso mediado pelo cofre fecha essa lacuna por conceção: o acesso é concedido a uma pessoa, não a uma palavra-passe, e pode ser revogado numa única ação.

Um guia para a gestão segura de palavras-passe partilhadas

A arquitetura de uma partilha segura de credenciais assenta em três decisões: que ferramenta utilizar, como estruturar o acesso e que modelo de permissões aplicar. Acertando nestes três pontos, o resto da implementação decorre naturalmente.

Passo 1: escolher um gestor de palavras-passe empresarial com arquitetura zero-knowledge

O fornecedor do cofre nunca deve ter acesso às credenciais armazenadas. Numa arquitetura zero-knowledge, a cifragem e a decifragem ocorrem do lado do cliente. O servidor guarda apenas texto cifrado.

Este é o requisito fundamental para a soberania dos dados ao abrigo do RGPD: se o fornecedor não consegue ler as credenciais, uma violação do lado do fornecedor não as pode expor. Para organizações da UE, uma implementação on-premise ou em cloud alojada na UE (com residência de dados em jurisdição da UE) elimina por completo a exposição ao Cloud Act dos EUA.

Passo 2: estruturar os cofres por equipa e nível de sensibilidade 

Organize as credenciais partilhadas por departamento, projeto ou sistema — Desenvolvimento, Operações, Financeiro, Marketing. Esta estrutura limita o raio de impacto de uma conta comprometida.

Se o acesso ao cofre de um membro da equipa de Marketing for comprometido, o atacante chega apenas às credenciais de Marketing, não às cadeias de ligação da base de dados de produção. Isto também torna as revisões de acesso viáveis: está a analisar um conjunto limitado de permissões, e não uma lista indiferenciada de todas as credenciais da organização.

Passo 3: implementar um modelo de acesso em três níveis baseado em funções

O modelo de três níveis é a estrutura de governação mínima viável para a partilha segura de credenciais em equipas:

• Leitura: O utilizador pode ver e copiar a palavra-passe em claro dentro do cofre, mas não pode alterá-la nem eliminá-la. Adequado para membros da equipa que precisam de se autenticar diretamente num sistema, mas que não devem poder alterar ou eliminar a credencial.
• Edição: O utilizador pode atualizar e gerir as credenciais dentro do grupo que lhe foi atribuído. Adequado para líderes de equipa e responsáveis de sistemas encarregados de manter as credenciais atualizadas.
• Administração: O utilizador gere a composição dos grupos, as permissões e as políticas de acesso. Reservado a administradores de TI e responsáveis de segurança.

Este modelo garante que as permissões estão alinhadas com a responsabilidade de cada um: os membros da equipa autenticam-se e leem, os líderes gerem, os administradores governam. Alterar a função de alguém resume-se à atualização de uma única permissão.

Boas práticas de partilha de palavras-passe para uma partilha segura de credenciais

Para além da estrutura básica do cofre, cinco práticas operacionais distinguem um sistema realmente conforme de um que apenas parece conforme no papel.

Ligações seguras de utilização única para prestadores externos 

Quando um fornecedor ou um profissional independente precisa de aceder a uma credencial específica, uma ligação de utilização única gera um URL que expira após uma única utilização ou ao fim de um período definido. O destinatário acede à credencial sem ser adicionado ao cofre como utilizador permanente. Assim que a ligação expira, o acesso termina automaticamente. Não há passo de revogação manual, nem ticket de saída esquecido, nem acesso residual.

Imagine a alternativa: um prestador termina um contrato de seis semanas. Alguém na equipa de TI deveria remover o seu acesso ao cofre. Esse pedido fica numa fila durante duas semanas. O prestador, já a trabalhar para outro cliente, continua com acesso ao ambiente de staging. As ligações de utilização única tornam este cenário estruturalmente impossível.

Acesso com tempo limitado para projetos temporários 

A maioria dos gestores de palavras-passe empresariais permite conceder acesso com uma data de expiração definida. Basta defini-la ao aprovisionar o prestador — se o contrato durar seis semanas, o acesso expira na sexta semana. Sem necessidade de pedido de saída, sem acompanhamento manual, sem acesso que sobreviva silenciosamente ao projeto. Isto elimina a causa mais comum da proliferação de credenciais: antigos utilizadores que nunca chegaram a ser removidos corretamente.

MFA resistente a phishing no próprio cofre 

Segundo o Okta Secure Sign-In Trends Report de 2025, da Okta, a adoção de MFA nas organizações atingiu os 70 % — o que significa que quase 30 % dos utilizadores continuam sem qualquer MFA. Para o acesso ao cofre, a MFA resistente a phishing (chaves de hardware FIDO2 ou passkeys vinculadas ao dispositivo) é o padrão exigido ao abrigo da NIS2. 

As OTP por SMS não são recomendadas: são vulneráveis a SIM-swapping e a proxies de phishing em tempo real, e os auditores da NIS2 estão cada vez mais atentos a esta distinção.

Comprimento da palavra-passe alinhado com a NIST Rev. 4 

A atualização de 2025 à NIST SP 800-63B Rev. 4 eleva o comprimento mínimo da palavra-passe para 15 carateres quando esta é utilizada como único fator de autenticação, e elimina explicitamente a rotação periódica obrigatória, substituindo-a por alterações de credenciais desencadeadas por indícios de comprometimento.

Esta é a revisão mais significativa das diretrizes federais de palavras-passe dos EUA em quase uma década. Se a política da organização ainda exigir rotação a cada 90 dias, já está desatualizada e é efetivamente contraproducente: a rotação forçada leva os utilizadores a alterações incrementais previsíveis (Palavra-passe1! → Palavra-passe2!) em vez de credenciais genuinamente mais fortes.

Auditoria de acesso abrangente 

Os registos de auditoria têm de captar quem acedeu a que credencial, quando e a partir de onde. Para a conformidade com o RGPD e a NIS2, esta é a principal evidência solicitada pelos auditores — antes dos documentos de política, antes dos diagramas de arquitetura, antes de qualquer outra coisa. Um registo com indicação temporal que mostre exatamente quem acedeu à credencial da base de dados de produção às 2:14 AM de uma terça-feira pesa mais numa auditoria do que uma centena de páginas de política de controlo de acesso.

Boas práticas operacionais para uma partilha segura de credenciais

Requisitos regulamentares: RGPD, NIS2, SOC 2 e ISO 27001

As credenciais não geridas criam simultaneamente uma exposição de segurança e uma falha de conformidade — muitas vezes, as duas coisas ao mesmo tempo. O artigo 32.º do RGPD exige «medidas técnicas e organizativas adequadas» para proteger os dados pessoais. As credenciais partilhadas sem registo de auditoria falham diretamente esse critério: demonstrar controlos de acesso adequados exige provas de quem teve acesso a quê e quando.

A aplicação da NIS2 já está em vigor. As coimas podem atingir 10 milhões de euros ou 2 % do volume de negócios anual global. As conclusões de pré-auditorias do quarto trimestre de 2025, na Alemanha, nos Países Baixos e na Áustria, assinalaram sistematicamente a ausência de MFA, contas com privilégios excessivos e credenciais de serviço não geridas como as principais falhas.

O padrão é consistente em todas as auditorias falhadas: as organizações tinham controlos implementados, mas não conseguiam apresentar registos, registos de revisão de acessos nem relatórios de higiene de credenciais. Os auditores tratam os controlos não documentados da mesma forma que os controlos inexistentes.

A escassez de competências agrava o problema. Segundo o ENISA relatório NIS Investments 2025 da ENISA (publicado em dezembro de 2025), 76 % das organizações da UE relatam dificuldades em recrutar perfis qualificados em cibersegurança, e 45 % apontam a falta de competências necessárias como o principal obstáculo.

Para equipas com falta de pessoal, as ferramentas automatizadas colmatam a lacuna que o número de colaboradores não consegue cobrir: o controlo de acesso baseado no cofre, a integração com o AD e as revisões de acesso agendadas funcionam continuamente, sem exigir uma equipa de IAM dedicada para as operar manualmente.

Consulte o nosso guia de conformidade com a NIS2 para um mapeamento detalhado dos requisitos de conformidade em controlos técnicos específicos.

Passos práticos de implementação: o modelo de governação de palavras-passe em 4 passos

O modelo de governação de palavras-passe em 4 passos dá aos gestores de TI uma sequência de implementação concreta, que revela problemas numa fase inicial e constrói adesão organizacional antes de um lançamento alargado a toda a empresa.

Passo 1: realizar um piloto com o departamento de TI

Comece pela equipa que vai administrar o sistema. Um piloto de duas semanas revela problemas de integração, atritos na experiência de utilização e lacunas nas políticas antes de afetarem o resto da organização. Também dá à equipa de TI experiência direta com a ferramenta antes de se esperar que lhe dê suporte.

O Passwork implementa-se on-premise ou na cloud da UE, pelo que o ambiente do piloto reproduz exatamente a configuração de produção — sem necessidade de infraestrutura separada. A equipa de TI pode validar a estrutura do cofre, testar a sincronização com o AD e confirmar os registos de auditoria antes de alargar a implementação ao resto da organização.

Passo 2: integrar com o Active Directory ou o LDAP

A integração com o Active Directory ou o LDAP é o passo técnico mais importante de todos. A integração AD/LDAP automatiza o aprovisionamento de utilizadores: os novos colaboradores surgem no cofre logo no primeiro dia, com o acesso determinado pela sua associação a grupos do AD. Quando uma conta do AD é desativada (na saída do colaborador), todo o acesso ao cofre associado é revogado de imediato. Sem ticket de saída manual. Sem fila de espera de duas semanas. Sem ex-colaboradores com acesso ativo ao ambiente de staging.

Isto é importante porque a alternativa é um processo manual que não escala. Com 200 colaboradores e 40 grupos de credenciais partilhadas, acompanhar quem tem acesso a quê sem sincronização automática transforma-se num jogo de adivinhas, em vez de num processo de governação.

A integração do Passwork com o AD e o LDAP trata disto de forma nativa. A associação a grupos no AD mapeia diretamente para as permissões do cofre — quando alguém passa da equipa de Desenvolvimento para a de Operações, o seu acesso ao cofre atualiza-se automaticamente na sincronização seguinte.

Passo 3: formar a equipa no novo fluxo de trabalho 

O caminho seguro tem de ser mais rápido do que a alternativa insegura. Se partilhar uma credencial através de um gestor de palavras-passe demora 5 minutos e partilhá-la pelo Slack demora 5 segundos, as pessoas vão usar o Slack. A formação deve concentrar-se nos três cenários mais comuns: 

1. Partilhar uma credencial com um novo membro da equipa. 
2. Conceder acesso temporário a um prestador através de uma ligação de utilização única e revogar o acesso quando um projeto termina. 
3. Manter o foco nas tarefas, em vez de na política.

Mantenha o foco nas tarefas, em vez de na política. No Passwork, os três cenários demoram menos de um minuto a partir da interface do cofre — gerar uma ligação de utilização única para um prestador exige apenas dois cliques e produz um URL que expira automaticamente após a primeira utilização ou ao fim de um período definido. É essa rapidez que torna a adoção duradoura.

Passo 4: estabelecer monitorização contínua e revisões trimestrais de acesso 

Agende revisões trimestrais para identificar permissões obsoletas, credenciais não utilizadas e contas que nunca tiveram a saída devidamente processada. Os registos de auditoria tornam isto viável: a revisão transforma-se numa consulta estruturada, em vez de numa investigação manual.

Procura-se identificar contas às quais não se acede há 90 dias, credenciais que não são alteradas desde uma janela de comprometimento conhecida e contas de prestadores que já deveriam ter expirado. As ferramentas de auditoria de segurança do Passwork identificam estes casos automaticamente — palavras-passe fracas, contas inativas e utilizadores com privilégios excessivos surgem num único relatório, sem necessidade de uma verificação manual em todos os cofres.

Conclusão

A partilha segura de palavras-passe é um problema de governação de acessos. Mover as credenciais para um cofre é apenas o primeiro passo. O RBAC (controlo de acesso baseado em funções), os registos de auditoria, a MFA resistente a phishing e a integração com o AD são o que distingue um sistema conforme e auditável de uma versão apenas um pouco mais organizada do mesmo risco.

O modelo de governação de palavras-passe em 4 passos oferece uma sequência exequível: piloto com a equipa de TI, ligação ao AD, formação no fluxo de trabalho real e revisão trimestral. Sem a integração com o AD, a saída de colaboradores continua manual. Sem formação, as pessoas continuam a usar o Slack.

Se a política de palavras-passe da organização for anterior a agosto de 2025, precisa de ser revista. Se a organização estiver abrangida pela NIS2 e não conseguir apresentar registos de acesso quando solicitado, a lacuna é real, mensurável e corrigível. As ferramentas para a fechar já existem — a questão é saber se se adequam à infraestrutura e aos requisitos de conformidade da organização.

O Passwork foi concebido exatamente para este contexto: organizações que precisam de governação total das credenciais sem terem de entregar os seus dados a uma cloud de terceiros. Implementa-se on-premise ou na cloud da UE, integra-se nativamente com o AD e o LDAP e produz, por predefinição, os registos de auditoria que os auditores da NIS2 exigem. Se o modelo em 4 passos descrito neste artigo é o destino pretendido, o Passwork é a infraestrutura que torna cada passo operacional.

Perguntas frequentes

Partilha insegura de palavras-passe: riscos de 2026 e soluções seguras

Sempre que uma credencial passa pelo Slack ou por e-mail, perde-se, num único passo, a responsabilização, o registo de auditoria e a postura de conformidade. Este guia aborda os riscos reais da partilha insegura de palavras-passe em 2026, as razões pelas quais os colaboradores a praticam mesmo assim e como migrar para o acesso mediado pelo cofre sem perturbar a equipa.

Passwork BlogAlex Muntyan

O caos das palavras-passe: porque é um problema de negócio e como resolvê-lo

Uma palavra-passe esquecida custa 70 dólares. Uma violação custa 4,44 milhões de dólares. Ambas começam da mesma forma — credenciais partilhadas pelo Slack, guardadas em folhas de cálculo, nunca alteradas. Eis o que o caos das palavras-passe custa realmente e como eliminá-lo.

Passwork BlogAlex Muntyan

Gestão de palavras-passe para equipas: a solução de que toda a PME precisa

Guardar palavras-passe no Slack e em navegadores expõe o negócio a violações. Descubra porque é que as ferramentas pessoais falham para as equipas, como processar com segurança, num único clique, a saída de colaboradores, e porque é que as diretrizes mais recentes da NIST desaconselham a rotação forçada de palavras-passe.

Passwork BlogAlex Muntyan

Sicheres Teilen von Passwörtern bezeichnet die Praxis, Zugang zu gemeinsam genutzten Anmeldedaten über einen verschlüsselten Tresor zu gewähren. Dabei authentifizieren sich Benutzer am Tresor, anstatt das Rohpasswort zu erhalten. Diese Methode bewahrt die individuelle Verantwortlichkeit und bietet einen widerrufbaren, auditierbaren Zugriffsnachweis — zwei Eigenschaften, die informelle Weitergabemethoden strukturell nicht bieten können.

Die meisten Organisationen sind von diesem Standard weit entfernt. Anmeldedaten bewegen sich auf Wegen durch das Unternehmen, die niemand geplant hat und niemand verfolgt: ein Datenbankpasswort per Slack gesendet, ein Admin-Konto per E-Mail an einen Auftragnehmer, ein Lohnbuchhaltungs-Login in einer Tabelle, auf die drei Personen in der Finanzabteilung zugreifen können. Der Zugang ist real. Der Audit-Trail ist es nicht.

Kernpunkte

• Die Erkennung von Credential-Breaches dauert durchschnittlich 241 Tage. Der IBM Cost of a Data Breach Report 2025 beziffert die durchschnittlichen globalen Kosten eines Datenlecks auf 4,44 Millionen US-Dollar. Ohne zentrale Credential-Governance gibt es keinen zuverlässigen Weg zu wissen, dass Anmeldedaten kompromittiert wurden, bis der Schaden entstanden ist.
• Über Slack, E-Mail oder Tabellen geteilte Anmeldedaten hinterlassen keinen Audit-Trail. Wenn ein Teammitglied das Unternehmen verlässt, gibt es keinen zuverlässigen Weg, jeden Systemzugang zu identifizieren, den die Person hatte. Die Verantwortlichkeitslücke ist architektonisch bedingt: Die Anmeldedaten wurden geteilt, aber die Eigentümerschaft wurde nie übertragen.
• Ein Passwort-Manager mit AD/LDAP-Integration automatisiert die Bereitstellung ab dem ersten Tag und entzieht sämtlichen Tresorzugang in dem Moment, wenn ein AD-Konto deaktiviert wird. Ohne diese Integration bleibt das Offboarding manuell, und ehemalige Mitarbeiter behalten länger Zugang, als beabsichtigt.
• NIST SP 800-63B Rev. 4 erhöht die Mindestpasswortlänge auf 15 Zeichen und verbietet die obligatorische periodische Rotation. Wenn Ihre Richtlinie noch eine 90-Tage-Rotation vorschreibt, ist sie veraltet: Erzwungene Rotation führt zu vorhersehbaren inkrementellen Änderungen, nicht zu stärkeren Anmeldedaten.
• Audit-Logs verwandeln einen Sicherheitsvorfall von einem Ratespiel in eine strukturierte Untersuchung. Ein mit Zeitstempel versehener Nachweis, wer wann und von wo auf welche Anmeldedaten zugegriffen hat, zeigt genau, was exponiert wurde — und wer zu diesem Zeitpunkt Zugang hatte.
• Gemeinsam genutzte Admin-Logins machen individuelle Zuordnung unmöglich. Wenn fünf Personen dieselben Anmeldedaten verwenden, gibt es keine Möglichkeit zu wissen, wer eine Einstellung geändert hat, wer sich während eines Vorfalls authentifiziert hat oder wessen Zugang widerrufen werden muss. Tresor-vermittelte Freigabe weist den Zugang einer Person zu, nicht einem Passwort.
• Einmal-Links und zeitlich begrenzter Zugang eliminieren das Problem der manuellen Widerrufung. Der Link läuft nach Verwendung ab, die Berechtigung läuft an einem festgelegten Datum ab. Kein Offboarding-Ticket erforderlich.

Warum ist sicheres Teilen von Passwörtern in Teams so wichtig?

Die finanziellen Risiken sind konkret. Laut dem IBM Cost of a Data Breach Report 2025 betrugen die durchschnittlichen globalen Kosten eines Datenlecks 4,44 Millionen US-Dollar, und Breaches mit kompromittierten Anmeldedaten benötigen durchschnittlich 241 Tage zur Identifizierung und Eindämmung. Das sind fast acht Monate unentdeckter Exposition — lang genug für einen Angreifer, Ihre Infrastruktur zu kartieren, Daten zu exfiltrieren und Persistenz aufzubauen, bevor jemand etwas bemerkt.

Die 241-Tage-Zahl ist kein Worst-Case-Szenario. Sie ist der Median. Organisationen ohne zentrale Credential-Governance haben keinen zuverlässigen Mechanismus, um zu erkennen, dass Anmeldedaten kompromittiert wurden, bis der Schaden bereits entstanden ist. Strukturiertes Credential-Management reduziert die Erkennungslücke, die Breaches teuer macht.

Unsicheres Teilen von Passwörtern: Risiken und Lösungen

Das Problem mit unsicherem Teilen von Passwörtern: Messenger, Tabellen und E-Mail

Laut dem Verizon Data Breach Investigations Report 2026 sind kompromittierte Anmeldedaten der initiale Zugriffsvektor bei 13% der Breaches, erscheinen aber irgendwo in der Angriffskette bei 39% aller Vorfälle — ein erheblicher Anteil bei mehr als 22.000 bestätigten Breaches, die im Bericht analysiert wurden.

Im Median sind nur 49% der Passwörter eines Benutzers über verschiedene Dienste hinweg einzigartig. Das bedeutet, dass ein einzelnes geleaktes Credential routinemäßig Zugang zu mehreren Systemen durch Credential Stuffing eröffnet — ein Ergebnis aus Verizons eigener ergänzender DBIR-Credential-Forschung von 2025, das weiterhin aktuell ist.

Das Grundproblem ist architektonisch. Wenn Anmeldedaten über Slack, E-Mail oder eine Tabelle geteilt werden, gibt es keinen Audit-Trail. Wenn ein Teammitglied das Unternehmen verlässt, gibt es keinen zuverlässigen Weg, jedes System zu identifizieren, auf das es zugreifen konnte. Die Anmeldedaten existieren irgendwo außerhalb des Tresors (in einem Posteingang, einem Chat-Verlauf, einem Screenshot) und es gibt keinen Widerrufsmechanismus außer der manuellen Rotation des Passworts über alle betroffenen Systeme hinweg.

Das ist die Verantwortlichkeitslücke. Die Anmeldedaten wurden geteilt, aber die Eigentümerschaft wurde nicht übertragen. Niemand weiß, wer sie hat, wo sie gespeichert sind oder ob sie bereits weitergeleitet wurden. Ein Tresor-vermitteltes Zugriffsmodell schließt diese Lücke konstruktionsbedingt: Der Zugang wird einer Person gewährt, nicht einem Passwort, und kann mit einer einzigen Aktion widerrufen werden.

Ein Leitfaden für sicheres gemeinsames Passwort-Management

Die Architektur des sicheren Teilens von Anmeldedaten basiert auf drei Entscheidungen: welches Tool Sie verwenden, wie Sie den Zugang strukturieren und welches Berechtigungsmodell Sie anwenden. Wenn Sie diese richtig treffen, folgt der Rest der Implementierung.

Schritt 1: Wählen Sie einen Enterprise-Passwort-Manager mit Zero-Knowledge-Architektur

Der Tresor-Anbieter darf niemals Zugang zu gespeicherten Anmeldedaten haben. Zero-Knowledge-Architektur bedeutet, dass Ver- und Entschlüsselung auf der Client-Seite erfolgen. Der Server speichert nur verschlüsselten Text.

Dies ist die grundlegende Anforderung für DSGVO-Datensouveränität: Wenn der Anbieter Ihre Anmeldedaten nicht lesen kann, kann ein anbieterseitiger Breach sie nicht exponieren. Für EU-Organisationen eliminiert On-Premise-Deployment oder EU-gehostete Cloud (mit Datenresidenz in EU-Gerichtsbarkeit) die Exposition durch den US Cloud Act vollständig.

Schritt 2: Strukturieren Sie Tresore nach Team und Sensibilitätsstufe 

Organisieren Sie gemeinsam genutzte Anmeldedaten nach Abteilung, Projekt oder System — Entwicklung, Betrieb, Finanzen, Marketing. Diese Struktur begrenzt den Schadensradius eines kompromittierten Kontos.

Wenn der Tresorzugang eines Marketing-Teammitglieds kompromittiert wird, erreicht der Angreifer Marketing-Anmeldedaten, nicht Produktions-Datenbankstrings. Es macht auch Zugriffsüberprüfungen handhabbar: Sie überprüfen einen begrenzten Satz von Berechtigungen, nicht eine undifferenzierte Liste aller Anmeldedaten in der Organisation.

Schritt 3: Implementieren Sie ein dreistufiges rollenbasiertes Zugriffsmodell

Das dreistufige Modell ist die minimale praktikable Governance-Struktur für sicheres Teilen von Anmeldedaten in Teams:

• Lesen: Der Benutzer kann das Rohpasswort innerhalb des Tresors anzeigen und kopieren, aber nicht ändern oder löschen. Geeignet für Teammitglieder, die sich direkt bei einem System authentifizieren müssen, aber keine Möglichkeit haben sollten, die Anmeldedaten zu ändern oder zu löschen.
• Bearbeiten: Der Benutzer kann Anmeldedaten innerhalb seiner zugewiesenen Gruppe aktualisieren und verwalten. Geeignet für Teamleiter und Systemverantwortliche, die für die Aktualität der Anmeldedaten verantwortlich sind.
• Administration: Der Benutzer verwaltet Gruppenmitgliedschaften, Berechtigungen und Zugriffsrichtlinien. Beschränkt auf IT-Administratoren und Sicherheitsverantwortliche.

Dieses Modell stellt sicher, dass Berechtigungen auf die Verantwortung abgestimmt sind: Teammitglieder authentifizieren sich und lesen, Leiter verwalten, Administratoren regieren. Das Ändern der Rolle einer Person ist eine einzige Berechtigungsaktualisierung.

Best Practices für sicheres Teilen von Anmeldedaten

Über die grundlegende Tresorstruktur hinaus trennen fünf operative Praktiken ein konformes System von einem, das nur auf dem Papier konform aussieht.

Einmal-Links für externe Auftragnehmer 

Wenn ein Anbieter oder Freiberufler Zugang zu bestimmten Anmeldedaten benötigt, generiert ein Einmal-Link eine URL, die nach einmaliger Verwendung oder nach einem definierten Zeitfenster abläuft. Der Empfänger greift auf die Anmeldedaten zu, ohne dem Tresor als permanenter Benutzer hinzugefügt zu werden. Sobald der Link abläuft, endet der Zugang automatisch. Es gibt keinen manuellen Widerrufsschritt, kein vergessenes Offboarding-Ticket, keinen Restzugang.

Stellen Sie sich die Alternative vor: Ein Auftragnehmer beendet einen sechswöchigen Einsatz. Jemand im IT-Team soll seinen Tresorzugang entfernen. Dieses Ticket liegt zwei Wochen in einer Warteschlange. Der Auftragnehmer, der jetzt für einen anderen Kunden arbeitet, hat immer noch Zugang zu Ihrer Staging-Umgebung. Einmal-Links machen dieses Szenario strukturell unmöglich.

Zeitlich begrenzter Zugang für temporäre Projekte 

Die meisten Enterprise-Passwort-Manager unterstützen Zugriffsgewährungen mit einem definierten Ablaufdatum. Legen Sie es bei der Bereitstellung für den Auftragnehmer fest — wenn der Einsatz sechs Wochen dauert, läuft der Zugang in Woche sechs ab. Kein Offboarding-Ticket erforderlich, keine manuelle Nachverfolgung, kein Zugang, der stillschweigend das Projekt überdauert. Dies eliminiert die häufigste Quelle von Credential Sprawl: ehemalige Benutzer, die nie ordnungsgemäß entfernt wurden.

Phishing-resistente MFA auf dem Tresor selbst 

Laut Oktas Secure Sign-In Trends Report 2025 erreichte die MFA-Adoption bei Arbeitskräften 70% — das bedeutet, dass fast 30% der Benutzer sie noch gar nicht haben. Für Tresorzugang ist Phishing-resistente MFA (FIDO2-Hardware-Keys oder gerätegebundene Passkeys) der operative Standard unter NIS2.

SMS-basierte OTPs werden nicht empfohlen: Sie sind anfällig für SIM-Swapping und Echtzeit-Phishing-Proxys, und NIS2-Prüfer sind sich dieser Unterscheidung zunehmend bewusst.

Passwortlänge gemäß NIST Rev. 4 

Die Aktualisierung 2025 von NIST SP 800-63B Rev. 4 erhöht die Mindestpasswortlänge auf 15 Zeichen, wenn ein Passwort als einziger Authentifikator verwendet wird, und missbilligt explizit die obligatorische periodische Rotation, die durch kompromittierungsbedingte Credential-Änderungen ersetzt wird.

Dies ist die bedeutendste Überarbeitung der bundesstaatlichen Passwort-Richtlinien seit fast einem Jahrzehnt. Wenn Ihre Richtlinie noch eine 90-Tage-Rotation vorschreibt, ist sie bereits veraltet und aktiv kontraproduktiv: Erzwungene Rotation treibt Benutzer zu vorhersehbaren inkrementellen Änderungen (Password1! → Password2!) anstatt zu wirklich stärkeren Anmeldedaten.

Umfassende Zugriffsprotokollierung 

Audit-Logs müssen erfassen, wer wann und von wo auf welche Anmeldedaten zugegriffen hat. Für DSGVO- und NIS2-Compliance sind dies die primären Nachweise, die Prüfer anfordern — noch vor Richtliniendokumenten, vor Architekturdiagrammen, vor allem anderen. Ein mit Zeitstempel versehenes Log, das genau zeigt, wer um 2:14 Uhr morgens an einem Dienstag auf die Produktions-Datenbank-Anmeldedaten zugegriffen hat, hat in einem Audit mehr Gewicht als hundert Seiten Zugriffskontrollrichtlinie.

Operative Best Practices für sicheres Teilen von Anmeldedaten

Regulatorische Anforderungen: DSGVO, NIS2, SOC 2 und ISO 27001

Unverwaltete Anmeldedaten verursachen sowohl ein Sicherheitsrisiko als auch ein Compliance-Versagen — oft gleichzeitig. DSGVO Artikel 32 erfordert „geeignete technische und organisatorische Maßnahmen" zum Schutz personenbezogener Daten. Gemeinsam genutzte Anmeldedaten ohne Audit-Trail verstoßen direkt gegen diesen Standard: Der Nachweis angemessener Zugriffskontrollen erfordert Belege, wer wann auf was Zugang hatte.

Die NIS2-Durchsetzung ist aktiv. Bußgelder erreichen 10 Millionen Euro oder 2% des globalen Jahresumsatzes. Pre-Audit-Ergebnisse aus Q4 2025 in Deutschland, den Niederlanden und Österreich monierten durchgängig fehlende MFA, überprivilegierte Konten und unverwaltete Service-Anmeldedaten als primäre Mängel.

Das Muster bei gescheiterten Audits ist konsistent: Organisationen hatten Kontrollen implementiert, konnten aber keine Logs, keine Zugriffsüberprüfungsprotokolle, keine Credential-Hygiene-Berichte vorlegen. Prüfer behandeln undokumentierte Kontrollen genauso wie fehlende.

Der Fachkräftemangel verschärft das Problem. Laut dem ENISA NIS Investments 2025 Report (veröffentlicht im Dezember 2025) berichten 76% der EU-Organisationen von Schwierigkeiten bei der Rekrutierung qualifizierter Cybersicherheitsprofile, und 45% nennen einen Mangel an erforderlichen Fähigkeiten als Haupthindernis.

Für unterbesetzte Teams überbrückt automatisiertes Tooling die Lücke, die Personal nicht füllen kann: Tresor-basierte Zugriffskontrolle, AD-Integration und geplante Zugriffsüberprüfungen laufen kontinuierlich, ohne dass ein dediziertes IAM-Team sie manuell betreiben muss.

Lesen Sie unseren NIS2-Compliance-Leitfaden für eine detaillierte Zuordnung von Compliance-Anforderungen zu spezifischen technischen Kontrollen.

Praktische Implementierungsschritte: Das 4-Schritte-Passwort-Governance-Modell

Das 4-Schritte-Passwort-Governance-Modell gibt IT-Managern eine konkrete Deployment-Sequenz, die Probleme frühzeitig aufdeckt und die organisatorische Akzeptanz vor einem unternehmensweiten Rollout aufbaut.

Schritt 1: Führen Sie einen Piloten mit der IT-Abteilung durch

Beginnen Sie mit dem Team, das das System administrieren wird. Ein zweiwöchiger Pilot deckt Integrationsprobleme, Reibungspunkte bei der Benutzererfahrung und Richtlinienlücken auf, bevor sie die breitere Organisation betreffen. Er gibt Ihrem IT-Team auch direkte Erfahrung mit dem Tool, bevor es erwartet wird, es zu unterstützen.

Passwork wird On-Premise oder in der EU-Cloud deployed, sodass die Pilotumgebung genau Ihrem Produktions-Setup entspricht — keine separate Infrastruktur erforderlich. Ihr IT-Team kann die Tresorstruktur validieren, die AD-Synchronisation testen und die Audit-Log-Ausgabe bestätigen, bevor es an den Rest der Organisation ausgerollt wird.

Schritt 2: Integrieren Sie mit Active Directory oder LDAP

Die Integration mit Active Directory oder LDAP ist der wichtigste technische Schritt. AD/LDAP-Integration automatisiert die Benutzerbereitstellung: Neue Mitarbeiter erscheinen am ersten Tag im Tresor, wobei der Zugang durch ihre AD-Gruppenmitgliedschaft bestimmt wird. Wenn ein AD-Konto (beim Offboarding) deaktiviert wird, wird sämtlicher zugehöriger Tresorzugang sofort entzogen. Kein manuelles Offboarding-Ticket. Keine zweiwöchige Warteschlange. Kein ehemaliger Mitarbeiter mit aktivem Zugang zu Ihrer Staging-Umgebung.

Das ist wichtig, weil die Alternative ein manueller Prozess ist, der nicht skaliert. Wenn Sie 200 Mitarbeiter und 40 gemeinsam genutzte Credential-Gruppen haben, wird die Nachverfolgung, wer auf was Zugang hat, ohne automatisierte Synchronisation zum Ratespiel statt zu einem Governance-Prozess.

Passworks AD- und LDAP-Integration bewältigt dies nativ. Gruppenmitgliedschaft in AD wird direkt auf Tresorberechtigungen abgebildet — wenn jemand vom Entwicklungsteam zum Betrieb wechselt, wird sein Tresorzugang automatisch bei der nächsten Synchronisation aktualisiert.

Schritt 3: Schulen Sie das Team im neuen Workflow 

Der sichere Weg muss schneller sein als der unsichere Workaround. Wenn das Teilen eines Credentials über einen Passwort-Manager 5 Minuten dauert, während das Teilen über Slack 5 Sekunden dauert, werden die Leute Slack verwenden. Die Schulung sollte sich auf die drei häufigsten Szenarien konzentrieren:

1. Teilen eines Credentials mit einem neuen Teammitglied.
2. Gewähren eines temporären Zugangs für einen Auftragnehmer über einen Einmal-Link und Widerrufen des Zugangs, wenn ein Projekt endet.
3. Aufgabenorientiert statt richtlinienorientiert bleiben.

Halten Sie es aufgabenorientiert statt richtlinienorientiert. In Passwork dauern alle drei Szenarien weniger als eine Minute über die Tresor-Oberfläche — das Generieren eines Einmal-Links für einen Auftragnehmer erfordert zwei Klicks und erzeugt eine URL, die automatisch nach dem ersten Gebrauch oder nach einem definierten Zeitfenster abläuft. Diese Geschwindigkeit ist es, die die Akzeptanz festigt.

Schritt 4: Etablieren Sie fortlaufende Überwachung und vierteljährliche Zugriffsüberprüfungen 

Planen Sie vierteljährliche Überprüfungen, um veraltete Berechtigungen, ungenutzte Anmeldedaten und Konten zu identifizieren, die nie ordnungsgemäß offgeboardet wurden. Audit-Logs machen dies handhabbar: Die Überprüfung wird zu einer strukturierten Abfrage statt einer manuellen Untersuchung.

Sie suchen nach Konten, auf die seit 90 Tagen nicht zugegriffen wurde, Anmeldedaten, die seit einem bekannten Kompromittierungsfenster nicht rotiert wurden, und Auftragnehmerkonten, die abgelaufen sein sollten. Passworks Sicherheitsaudit-Tools zeigen diese automatisch an — schwache Passwörter, inaktive Konten und überprivilegierte Benutzer erscheinen in einem einzigen Bericht, anstatt dass ein manueller Durchgang durch jeden Tresor erforderlich ist.

Fazit

Sicheres Teilen von Passwörtern ist ein Zugangs-Governance-Problem. Das Verschieben von Anmeldedaten in einen Tresor ist der erste Schritt. RBAC, Audit-Logs, Phishing-resistente MFA und AD-Integration sind das, was ein konformes, auditierbares System von einer etwas besser organisierten Version desselben Risikos unterscheidet.

Das 4-Schritte-Passwort-Governance-Modell gibt Ihnen eine praktikable Sequenz: Pilotieren Sie mit der IT, verbinden Sie mit AD, schulen Sie am tatsächlichen Workflow, überprüfen Sie vierteljährlich. Überspringen Sie die AD-Integration, und das Offboarding bleibt manuell. Überspringen Sie die Schulung, und die Leute verwenden weiterhin Slack.

Wenn Ihre Passwortrichtlinie vor August 2025 erstellt wurde, ist eine Überprüfung erforderlich. Wenn Ihre Organisation im Geltungsbereich von NIS2 liegt und keine Zugriffs-Logs auf Anfrage vorlegen kann, ist die Lücke real, messbar und behebbar. Das Tooling, um sie zu schließen, existiert — die Frage ist, ob es zu Ihrer Infrastruktur und Ihren Compliance-Anforderungen passt.

Passwork ist genau für diesen Kontext gebaut: Organisationen, die vollständige Credential-Governance benötigen, ohne Daten an eine Drittanbieter-Cloud zu übergeben. Es wird On-Premise oder in der EU-Cloud deployed, integriert sich nativ mit AD und LDAP und erstellt standardmäßig die Audit-Trails, die NIS2-Prüfer anfordern. Wenn das in diesem Artikel beschriebene 4-Schritte-Modell Ihr Ziel ist, ist Passwork die Infrastruktur, die jeden Schritt operativ macht.

Häufig gestellte Fragen

Unsicheres Teilen von Passwörtern: Risiken und sichere Lösungen 2026

Jedes Mal, wenn Anmeldedaten über Slack oder E-Mail übertragen werden, verlieren Sie Verantwortlichkeit, Audit-Trail und Compliance-Status in einem Schritt. Dieser Leitfaden behandelt die tatsächlichen Risiken des unsicheren Teilens von Passwörtern im Jahr 2026, warum Mitarbeiter es trotzdem tun und wie Sie auf Tresor-vermittelten Zugang migrieren, ohne Ihr Team zu stören.

Passwork BlogAlex Muntyan

Passwort-Chaos: Warum es ein Geschäftsproblem ist und wie man es behebt

Ein vergessenes Passwort kostet 70 $. Ein Breach kostet 4,44 Millionen $. Beides beginnt auf die gleiche Weise — Anmeldedaten, die über Slack geteilt, in Tabellen gespeichert und nie rotiert werden. Hier erfahren Sie, was Passwort-Chaos tatsächlich kostet und wie Sie es eliminieren.

Passwork BlogAlex Muntyan

Passwort-Management für Teams: Die Lösung, die jedes KMU braucht

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

Passwork BlogAlex Muntyan

El uso compartido seguro de contraseñas es la práctica de otorgar acceso a credenciales compartidas a través de una bóveda cifrada, donde los usuarios se autentican en la bóveda en lugar de recibir la contraseña en texto plano. Preserva la responsabilidad individual y proporciona un registro de acceso revocable y auditable — las dos propiedades que los métodos informales de compartición no pueden proporcionar estructuralmente.

La mayoría de las organizaciones están lejos de ese estándar. Las credenciales se mueven por la empresa de formas que nadie diseñó y nadie rastrea: una contraseña de base de datos enviada por Slack, una cuenta de administrador enviada por correo electrónico a un contratista, un inicio de sesión de nóminas en una hoja de cálculo que tres personas de Finanzas pueden abrir. El acceso es real. El registro de auditoría no lo es.

Puntos clave

• Las brechas de credenciales tardan 241 días de media en detectarse. El informe Cost of a Data Breach Report 2025 de IBM sitúa el coste medio global de una brecha en 4,44 millones de dólares. Sin una gobernanza centralizada de credenciales, no existe una forma fiable de saber que una credencial ha sido comprometida hasta que el daño ya está hecho.
• Las credenciales compartidas a través de Slack, correo electrónico u hojas de cálculo no dejan registro de auditoría. Cuando un miembro del equipo se va, no hay forma fiable de identificar cada sistema al que podía acceder. La brecha de responsabilidad es arquitectónica: la credencial ha sido compartida, pero la propiedad nunca ha sido transferida.
• Un gestor de contraseñas con integración AD/LDAP automatiza el aprovisionamiento desde el primer día y revoca todo el acceso a la bóveda en el momento en que se desactiva una cuenta AD. Sin él, la baja de empleados sigue siendo manual y los exempleados mantienen el acceso más tiempo del previsto.
• NIST SP 800-63B Rev. 4 eleva la longitud mínima de contraseña a 15 caracteres y prohíbe la rotación periódica obligatoria. Si su política aún exige rotación cada 90 días, está desactualizada: la rotación forzada genera cambios incrementales predecibles, no credenciales más fuertes.
• Los registros de auditoría convierten un incidente de seguridad de un juego de adivinanzas en una investigación estructurada. Un registro con marca de tiempo de quién accedió a qué credencial, cuándo y desde dónde le indica exactamente qué fue expuesto — y quién tenía acceso en ese momento.
• Los inicios de sesión de administrador compartidos hacen imposible la atribución individual. Cuando cinco personas usan la misma credencial, no hay forma de saber quién cambió una configuración, quién se autenticó durante un incidente o a quién se le debe revocar el acceso. El uso compartido mediado por bóveda asigna el acceso a una persona, no a una contraseña.
• Los enlaces seguros de un solo uso y el acceso con tiempo limitado eliminan el problema de la revocación manual. El enlace caduca después de su uso, el permiso caduca en una fecha establecida. No se requiere ticket de baja.

¿Por qué es crítico el uso compartido seguro de contraseñas en equipos?

Las implicaciones financieras son concretas. Según el informe Cost of a Data Breach Report 2025 de IBM, el coste medio global de una brecha de datos fue de 4,44 millones de dólares, y las brechas que involucran credenciales comprometidas tardan una media de 241 días en identificarse y contenerse. Eso es casi ocho meses de exposición no detectada — tiempo suficiente para que un atacante mapee su infraestructura, exfiltre datos y establezca persistencia antes de que alguien lo note.

La cifra de 241 días no es un escenario del peor caso. Es la mediana. Las organizaciones que carecen de gobernanza centralizada de credenciales no tienen un mecanismo fiable para detectar que una credencial ha sido comprometida hasta que el daño ya está hecho. La gestión estructurada de credenciales reduce la brecha de detección que hace que las brechas sean costosas.

Uso compartido inseguro de contraseñas: Riesgos y soluciones

El problema del uso compartido inseguro de contraseñas: Mensajería, hojas de cálculo y correo electrónico

Según el informe Data Breach Investigations Report 2026 de Verizon, las credenciales comprometidas son el vector de acceso inicial en el 13% de las brechas, pero aparecen en algún punto de la cadena de ataque en el 39% de todos los incidentes — una proporción significativa entre más de 22.000 brechas confirmadas analizadas en el informe.

En el caso mediano, solo el 49% de las contraseñas de un usuario en diferentes servicios son únicas, lo que significa que una credencial filtrada rutinariamente abre acceso a múltiples sistemas a través de credential stuffing — un hallazgo de la investigación complementaria de credenciales DBIR 2025 de Verizon que sigue siendo actual.

El problema raíz es arquitectónico. Cuando las credenciales se comparten a través de Slack, correo electrónico o una hoja de cálculo, no hay registro de auditoría. Cuando un miembro del equipo se va, no hay forma fiable de identificar cada sistema al que podía acceder. La credencial existe en algún lugar fuera de la bóveda (en una bandeja de entrada, un historial de chat, una captura de pantalla) y no hay mecanismo de revocación más que rotar la contraseña en cada sistema afectado manualmente.

Esta es la brecha de responsabilidad. La credencial ha sido compartida, pero la propiedad no ha sido transferida. Nadie sabe quién la tiene, dónde está almacenada o si ya ha sido reenviada. Un modelo de acceso mediado por bóveda cierra esa brecha por diseño: el acceso se otorga a una persona, no a una contraseña, y puede revocarse en una sola acción.

Una guía para la gestión segura de contraseñas compartidas

La arquitectura del uso compartido seguro de credenciales se basa en tres decisiones: qué herramienta utiliza, cómo estructura el acceso y qué modelo de permisos aplica. Si acierta en estas, el resto de la implementación sigue naturalmente.

Paso 1: Elija un gestor de contraseñas empresarial con arquitectura de conocimiento cero

El proveedor de la bóveda nunca debe tener acceso a las credenciales almacenadas. La arquitectura de conocimiento cero significa que el cifrado y descifrado ocurren en el lado del cliente. El servidor solo almacena texto cifrado.

Este es el requisito fundamental para la soberanía de datos del GDPR: si el proveedor no puede leer sus credenciales, una brecha del lado del proveedor no puede exponerlas. Para las organizaciones de la UE, el despliegue local o la nube alojada en la UE (con residencia de datos en jurisdicción de la UE) elimina completamente la exposición a la US Cloud Act.

Paso 2: Estructure las bóvedas por equipo y nivel de sensibilidad 

Organice las credenciales compartidas por departamento, proyecto o sistema — Desarrollo, Operaciones, Finanzas, Marketing. Esta estructura limita el radio de impacto de una cuenta comprometida.

Si el acceso a la bóveda de un miembro del equipo de Marketing se ve comprometido, el atacante alcanza las credenciales de marketing, no las cadenas de conexión a la base de datos de producción. También hace que las revisiones de acceso sean manejables: está revisando un conjunto limitado de permisos, no una lista indiferenciada de cada credencial en la organización.

Paso 3: Implemente un modelo de acceso basado en roles de tres niveles

El modelo de tres niveles es la estructura de gobernanza mínima viable para el uso compartido seguro de credenciales en equipos:

• Lectura: El usuario puede ver y copiar la contraseña en texto plano dentro de la bóveda, pero no puede modificarla ni eliminarla. Apropiado para miembros del equipo que necesitan autenticarse directamente en un sistema, pero no deben tener capacidad de cambiar o eliminar la credencial.
• Edición: El usuario puede actualizar y gestionar credenciales dentro de su grupo asignado. Apropiado para líderes de equipo y propietarios de sistemas que son responsables de mantener las credenciales actualizadas.
• Administración: El usuario gestiona la membresía del grupo, permisos y políticas de acceso. Restringido a administradores de TI y responsables de seguridad.

Este modelo asegura que los permisos estén alineados con la responsabilidad: los miembros del equipo se autentican y leen, los líderes gestionan, los administradores gobiernan. Cambiar el rol de alguien es una única actualización de permisos.

Mejores prácticas de uso compartido de contraseñas para credenciales seguras

Más allá de la estructura básica de la bóveda, cinco prácticas operativas separan un sistema conforme de uno que solo parece conforme en el papel.

Enlaces seguros de un solo uso para contratistas externos 

Cuando un proveedor o freelance necesita acceso a una credencial específica, un enlace de un solo uso genera una URL que caduca después de un único uso o después de una ventana de tiempo definida. El destinatario accede a la credencial sin ser añadido a la bóveda como usuario permanente. Una vez que el enlace caduca, el acceso termina automáticamente. No hay paso de revocación manual, no hay ticket de baja olvidado, no hay acceso residual.

Imagine la alternativa: un contratista termina un proyecto de seis semanas. Se supone que alguien del equipo de TI debe eliminar su acceso a la bóveda. Ese ticket permanece en una cola durante dos semanas. El contratista, ahora trabajando para otro cliente, todavía tiene acceso a su entorno de staging. Los enlaces de un solo uso hacen ese escenario estructuralmente imposible.

Acceso con tiempo limitado para proyectos temporales 

La mayoría de los gestores de contraseñas empresariales admiten concesiones de acceso con una fecha de caducidad definida. Establézcala cuando aprovisione al contratista — si el proyecto dura seis semanas, el acceso caduca en la semana seis. No se requiere ticket de baja, no hay seguimiento manual, no hay acceso que sobreviva silenciosamente al proyecto. Esto elimina la fuente más común de proliferación de credenciales: antiguos usuarios que nunca fueron eliminados correctamente.

MFA resistente al phishing en la propia bóveda 

Según el informe Secure Sign-In Trends Report 2025 de Okta, la adopción de MFA en el ámbito laboral alcanzó el 70% — lo que significa que casi el 30% de los usuarios aún carecen de él por completo. Para el acceso a la bóveda, el MFA resistente al phishing (llaves de hardware FIDO2 o passkeys vinculadas al dispositivo) es el estándar operativo bajo NIS2.

Los OTP basados en SMS no se recomiendan: son vulnerables al SIM-swapping y a los proxies de phishing en tiempo real, y los auditores de NIS2 son cada vez más conscientes de la distinción.

Longitud de contraseña alineada con NIST Rev. 4 

La actualización de 2025 de NIST SP 800-63B Rev. 4 eleva la longitud mínima de contraseña a 15 caracteres cuando una contraseña se usa como único autenticador, y deprecia explícitamente la rotación periódica obligatoria, reemplazándola con cambios de credenciales activados por compromiso.

Esta es la revisión más significativa de las directrices federales de contraseñas en casi una década. Si su política aún exige rotación cada 90 días, ya está desactualizada y es activamente contraproducente: la rotación forzada lleva a los usuarios hacia cambios incrementales predecibles (Password1! → Password2!) en lugar de credenciales genuinamente más fuertes.

Auditoría de acceso integral 

Los registros de auditoría deben capturar quién accedió a qué credencial, cuándo y desde dónde. Para el cumplimiento de GDPR y NIS2, esta es la evidencia principal que solicitan los auditores — antes que los documentos de políticas, antes que los diagramas de arquitectura, antes que cualquier otra cosa. Un registro con marca de tiempo que muestra exactamente quién accedió a la credencial de la base de datos de producción a las 2:14 AM un martes tiene más peso en una auditoría que cien páginas de política de control de acceso.

Mejores prácticas operativas para el uso compartido seguro de credenciales

Requisitos regulatorios: GDPR, NIS2, SOC 2 e ISO 27001

Las credenciales no gestionadas crean tanto una exposición de seguridad como un fallo de cumplimiento — a menudo simultáneamente. El Artículo 32 del GDPR requiere «medidas técnicas y organizativas apropiadas» para proteger los datos personales. Las credenciales compartidas sin registro de auditoría no cumplen ese estándar directamente: demostrar controles de acceso apropiados requiere evidencia de quién tuvo acceso a qué, y cuándo.

La aplicación de NIS2 está activa. Las multas alcanzan los 10 millones de euros o el 2% de la facturación anual global. Los hallazgos previos a auditorías del cuarto trimestre de 2025 en Alemania, Países Bajos y Austria señalaron consistentemente la falta de MFA, cuentas con privilegios excesivos y credenciales de servicio no gestionadas como fallos principales.

El patrón en las auditorías fallidas es consistente: las organizaciones tenían controles implementados pero no podían producir registros, ni registros de revisión de acceso, ni informes de higiene de credenciales. Los auditores tratan los controles no documentados igual que los ausentes.

La brecha de habilidades agrava el problema. Según el informe NIS Investments 2025 de ENISA (publicado en diciembre de 2025), el 76% de las organizaciones de la UE reportan dificultades para contratar perfiles cualificados en ciberseguridad, y el 45% cita la falta de habilidades requeridas como su principal barrera.

Para equipos con poco personal, las herramientas automatizadas cubren la brecha que la plantilla no puede: el control de acceso basado en bóveda, la integración con AD y las revisiones de acceso programadas funcionan continuamente sin requerir un equipo dedicado de IAM para operarlas manualmente.

Lea nuestra guía de cumplimiento NIS2 para un mapeo detallado de los requisitos de cumplimiento con controles técnicos específicos.

Pasos prácticos de implementación: El modelo de gobernanza de contraseñas en 4 pasos

El modelo de gobernanza de contraseñas en 4 pasos proporciona a los responsables de TI una secuencia de despliegue concreta que detecta problemas temprano y construye la adopción organizativa antes de un despliegue a toda la empresa.

Paso 1: Realice un piloto con el departamento de TI

Comience con el equipo que administrará el sistema. Un piloto de dos semanas detecta problemas de integración, fricciones en la experiencia de usuario y brechas en las políticas antes de que afecten a la organización más amplia. También da a su equipo de TI experiencia directa con la herramienta antes de que se espere que la soporten.

Passwork se despliega en local o en la nube de la UE, por lo que el entorno piloto refleja exactamente su configuración de producción — no se requiere infraestructura separada. Su equipo de TI puede validar la estructura de la bóveda, probar la sincronización con AD y confirmar la salida de los registros de auditoría antes de desplegar al resto de la organización.

Paso 2: Integre con Active Directory o LDAP

Integrar con Active Directory o LDAP es el paso técnico más importante. La integración AD/LDAP automatiza el aprovisionamiento de usuarios: los nuevos empleados aparecen en la bóveda en su primer día, con acceso determinado por su pertenencia a grupos de AD. Cuando se desactiva una cuenta AD (en la baja) todo el acceso a la bóveda asociado se revoca inmediatamente. Sin ticket de baja manual. Sin cola de dos semanas. Sin exempleado con acceso activo a su entorno de staging.

Esto importa porque la alternativa es un proceso manual que no escala. Cuando tiene 200 empleados y 40 grupos de credenciales compartidas, rastrear quién tiene acceso a qué sin sincronización automatizada se convierte en un juego de adivinanzas en lugar de un proceso de gobernanza.

La integración de Passwork con AD y LDAP maneja esto de forma nativa. La pertenencia a grupos en AD se mapea directamente a los permisos de la bóveda — cuando alguien pasa del equipo de Desarrollo a Operaciones, su acceso a la bóveda se actualiza automáticamente en la siguiente sincronización.

Paso 3: Capacite al equipo en el nuevo flujo de trabajo 

El camino seguro debe ser más rápido que el atajo inseguro. Si compartir una credencial a través de un gestor de contraseñas toma 5 minutos mientras compartirla por Slack toma 5 segundos, la gente usará Slack. La capacitación debe centrarse en los tres escenarios más comunes:

1. Compartir una credencial con un nuevo miembro del equipo.
2. Otorgar acceso temporal a un contratista a través de un enlace de un solo uso, y revocar el acceso cuando termina un proyecto.
3. Mantenerlo orientado a tareas en lugar de orientado a políticas.

Manténgalo orientado a tareas en lugar de orientado a políticas. En Passwork, los tres escenarios toman menos de un minuto desde la interfaz de la bóveda — generar un enlace de un solo uso para un contratista requiere dos clics y produce una URL que caduca automáticamente después del primer uso o después de una ventana de tiempo definida. Esa velocidad es lo que hace que la adopción perdure.

Paso 4: Establezca monitorización continua y revisiones trimestrales de acceso 

Programe revisiones trimestrales para identificar permisos obsoletos, credenciales no utilizadas y cuentas que nunca fueron dadas de baja correctamente. Los registros de auditoría hacen esto manejable: la revisión se convierte en una consulta estructurada en lugar de una investigación manual.

Está buscando cuentas a las que no se ha accedido en 90 días, credenciales que no se han rotado desde una ventana de compromiso conocida, y cuentas de contratistas que deberían haber caducado. Las herramientas de auditoría de seguridad de Passwork detectan esto automáticamente — contraseñas débiles, cuentas inactivas y usuarios con privilegios excesivos aparecen en un único informe en lugar de requerir un barrido manual por cada bóveda.

Conclusión

El uso compartido seguro de contraseñas es un problema de gobernanza de acceso. Mover las credenciales a una bóveda es el primer paso. RBAC, registros de auditoría, MFA resistente al phishing e integración con AD son lo que separa un sistema conforme y auditable de una versión ligeramente más organizada del mismo riesgo.

El modelo de gobernanza de contraseñas en 4 pasos le proporciona una secuencia viable: piloto con TI, conexión a AD, capacitación en el flujo de trabajo real, revisión trimestral. Si omite la integración con AD, la baja sigue siendo manual. Si omite la capacitación, la gente sigue usando Slack.

Si su política de contraseñas es anterior a agosto de 2025, necesita una revisión. Si su organización está dentro del alcance de NIS2 y no puede producir registros de acceso bajo demanda, la brecha es real, medible y solucionable. Las herramientas para cerrarla existen — la pregunta es si se ajustan a su infraestructura y requisitos de cumplimiento.

Passwork está diseñado exactamente para ese contexto: organizaciones que necesitan gobernanza completa de credenciales sin ceder datos a una nube de terceros. Se despliega en local o en la nube de la UE, se integra de forma nativa con AD y LDAP, y produce los registros de auditoría que los auditores de NIS2 solicitan por defecto. Si el modelo de 4 pasos descrito en este artículo es donde quiere llegar, Passwork es la infraestructura que hace operativo cada paso.

Preguntas frecuentes

Uso compartido inseguro de contraseñas: Riesgos en 2026 y soluciones seguras

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

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

Secure password sharing is the practice of granting access to shared credentials through an encrypted vault, where users authenticate to the vault rather than receiving the raw password. It preserves individual accountability and provides a revocable, auditable access trail — the two properties that informal sharing methods structurally cannot provide.

Most organizations are nowhere near that standard. Credentials move through the business in ways nobody designed and nobody tracks: a database password sent over Slack, an admin account emailed to a contractor, a payroll login in a spreadsheet that three people in Finance can open. The access is real. The audit trail is not.

Key takeaways

• Credential breaches take 241 days to detect on average. IBM's 2025 Cost of a Data Breach Report puts the global average breach cost at $4.44 million. Without centralized credential governance, there is no reliable way to know a credential is compromised until the damage is done.
• Credentials shared via Slack, email, or spreadsheets leave no audit trail. When a team member leaves, there is no reliable way to identify every system they could access. The accountability gap is architectural: the credential has been shared, but ownership has never been transferred.
• A password manager with AD/LDAP integration automates provisioning on day one and revokes all vault access the moment an AD account is disabled. Without it, offboarding stays manual and former employees keep access longer than anyone intends.
• NIST SP 800-63B Rev. 4 raises the minimum password length to 15 characters and prohibits mandatory periodic rotation. If your policy still mandates 90-day rotation, it is out of date: forced rotation drives predictable incremental changes, not stronger credentials.
• Audit logs turn a security incident from a guessing game into a structured investigation. A timestamped record of who accessed which credential, when, and from where tells you exactly what was exposed — and who had access at the time.
• Shared admin logins make individual attribution impossible. When five people use the same credential, there is no way to know who changed a setting, who authenticated during an incident, or whose access needs to be revoked. Vault-mediated sharing assigns access to a person, not a password.
• One-time secure links and time-limited access eliminate the manual revocation problem. The link expires after use, the permission expires on a set date. No offboarding ticket required.

Why is secure password sharing in teams critical?

The financial stakes are concrete. According to IBM's 2025 Cost of a Data Breach Report, the global average cost of a data breach was $4.44 million, and breaches involving compromised credentials take an average of 241 days to identify and contain. That is nearly eight months of undetected exposure — long enough for an attacker to map your infrastructure, exfiltrate data, and establish persistence before anyone notices.

The 241-day figure is not a worst-case scenario. It is the median. Organizations that lack centralized credential governance have no reliable mechanism to detect that a credential has been compromised until the damage is already done. Structured credential management reduces the detection gap that makes breaches expensive.

Insecure password sharing: risks and solutions

The problem with insecure password sharing: Messengers, spreadsheets, and email

According to the 2026 Verizon Data Breach Investigations Report, сompromised credentials are the initial access vector in 13% of breaches, but appear somewhere in the attack chain in 39% of all incidents — a significant share across more than 22,000 confirmed breaches analyzed in the report.

In the median case, only 49% of a user's passwords across different services are unique, meaning one leaked credential routinely opens access to multiple systems through credential stuffing — a finding from Verizon's own supplemental 2025 DBIR credential research that remains current.

The root problem is architectural. When credentials are shared via Slack, email, or a spreadsheet, there is no audit trail. When a team member leaves, there is no reliable way to identify every system they could access. The credential exists somewhere outside the vault (in an inbox, a chat history, a screenshot) and there is no revocation mechanism short of rotating the password across every affected system manually.

This is the accountability gap. The credential has been shared, but ownership has not been transferred. Nobody knows who has it, where it is stored, or whether it has already been forwarded. A vault-mediated access model closes that gap by design: access is granted to a person, not a password, and it can be revoked in a single action.

A guide to secure shared password management

The architecture of secure credential sharing rests on three decisions: which tool you use, how you structure access, and what permissions model you apply. Get these right and the rest of the implementation follows.

Step 1: Choose an enterprise password manager with zero-knowledge architecture

The vault provider must never have access to stored credentials. Zero-knowledge architecture means encryption and decryption happen on the client side. The server holds only ciphertext.

This is the foundational requirement for GDPR data sovereignty: if the vendor cannot read your credentials, a vendor-side breach cannot expose them. For EU organizations, on-premise deployment or EU-hosted cloud (with data residency in EU jurisdiction) eliminates US Cloud Act exposure entirely.

Step 2: Structure vaults by team and sensitivity level 

Organize shared credentials by department, project, or system — Development, Operations, Finance, Marketing. This structure limits the blast radius of a compromised account.

If a Marketing team member's vault access is compromised, the attacker reaches marketing credentials, not production database strings. It also makes access reviews tractable: you are reviewing a bounded set of permissions, not an undifferentiated list of every credential in the organization.

Step 3: Implement a three-tier role-based access model

The three-tier model is the minimum viable governance structure for secure credential sharing in teams:

• Read: The user can view and copy the raw password within the vault but cannot modify or delete it. Appropriate for team members who need to authenticate to a system directly, but should have no ability to change or delete the credential.
• Edit: The user can update and manage credentials within their assigned group. Appropriate for team leads and system owners who are responsible for keeping credentials current.
• Administration: The user manages group membership, permissions, and access policies. Restricted to IT administrators and security leads.

This model ensures that permissions are scoped to responsibility: team members authenticate and read, leads manage, administrators govern. Changing someone's role is a single permission update.

Password sharing best practices for secure credential sharing

Beyond the basic vault structure, five operational practices separate a compliant system from one that merely looks compliant on paper.

One-time secure links for external contractors 

When a vendor or freelancer needs access to a specific credential, a one-time link generates a URL that expires after a single use or after a defined time window. The recipient accesses the credential without being added to the vault as a permanent user. Once the link expires, access ends automatically. There is no manual revocation step, no forgotten offboarding ticket, no residual access.

Picture the alternative: a contractor finishes a six-week engagement. Someone on the IT team is supposed to remove their vault access. That ticket sits in a queue for two weeks. The contractor, now working for a different client, still has access to your staging environment. One-time links make that scenario structurally impossible.

Time-limited access for temporary projects 

Most enterprise password managers support access grants with a defined expiration date. Set it when you provision the contractor — if the engagement runs six weeks, access expires on week six. No offboarding ticket required, no manual follow-up, no access that quietly outlasts the project. This eliminates the most common source of credential sprawl: former users who were never properly removed.

Phishing-resistant MFA on the vault itself 

According to Okta's 2025 Secure Sign-In Trends Report, workforce MFA adoption reached 70% — meaning nearly 30% of users still lack it entirely. For vault access, phishing-resistant MFA (FIDO2 hardware keys or device-bound passkeys) is the operative standard under NIS2. 

SMS-based OTPs are not recommended: they are vulnerable to SIM-swapping and real-time phishing proxies, and NIS2 auditors are increasingly aware of the distinction.

Password length aligned with NIST Rev. 4 

The 2025 update to NIST SP 800-63B Rev. 4 raises the minimum password length to 15 characters when a password is used as the sole authenticator, and explicitly deprecates mandatory periodic rotation, replacing it with compromise-triggered credential changes.

This is the most significant revision to federal password guidance in nearly a decade. If your policy still mandates 90-day rotation, it is already out of date and actively counterproductive: forced rotation drives users toward predictable incremental changes (Password1! → Password2!) rather than genuinely stronger credentials.

Comprehensive access auditing 

Audit logs must capture who accessed which credential, when, and from where. For GDPR and NIS2 compliance, this is the primary evidence auditors request — ahead of policy documents, ahead of architecture diagrams, ahead of anything else. A timestamped log showing exactly who accessed the production database credential at 2:14 AM on a Tuesday carries more weight in an audit than a hundred pages of access control policy.

Operational best practices for secure credential sharing

Regulatory requirements: GDPR, NIS2, SOC 2, and ISO 27001

Unmanaged credentials create both a security exposure and a compliance failure — often simultaneously. GDPR Article 32 requires "appropriate technical and organisational measures" to protect personal data. Shared credentials with no audit trail fail that standard directly: demonstrating appropriate access controls requires evidence of who had access to what, and when.

NIS2 enforcement is active. Fines reach €10 million or 2% of global annual turnover. Pre-audit findings from Q4 2025 across Germany, the Netherlands, and Austria consistently flagged missing MFA, over-privileged accounts, and unmanaged service credentials as primary failures.

The pattern across failed audits is consistent: organizations had controls in place but could produce no logs, no access review records, no credential hygiene reports. Auditors treat undocumented controls the same as absent ones.

The skills gap compounds the problem. According to ENISA's NIS Investments 2025 report (published December 2025), 76% of EU organizations report difficulties recruiting qualified cybersecurity profiles, and 45% cite a lack of required skills as their main barrier.

For understaffed teams, automated tooling covers the gap that headcount cannot: vault-based access control, AD integration, and scheduled access reviews run continuously without requiring a dedicated IAM team to operate them manually.

Read our NIS2 compliance guide for a detailed mapping of compliance requirements to specific technical controls.

Practical implementation steps: The 4-step password governance model

The 4-step password governance model gives IT managers a concrete deployment sequence that surfaces problems early and builds organizational adoption before a company-wide rollout.

Step 1: Run a pilot with the IT department

Start with the team that will administer the system. A two-week pilot surfaces integration issues, user experience friction, and policy gaps before they affect the broader organization. It also gives your IT team direct experience with the tool before they are expected to support it.

Passwork deploys on-premise or in the EU cloud, so the pilot environment mirrors your production setup exactly — no separate infrastructure required. Your IT team can validate the vault structure, test AD sync, and confirm audit log output before rolling out to the rest of the organization.

Step 2: Integrate with Active Directory or LDAP

Integrating with Active Directory or LDAP is the single most important technical step. AD/LDAP integration automates user provisioning: new employees appear in the vault on their first day, with access determined by their AD group membership. When an AD account is disabled (at offboarding) all associated vault access is revoked immediately. No manual offboarding ticket. No two-week queue. No former employee with active access to your staging environment.

This matters because the alternative is a manual process that doesn't scale. When you have 200 employees and 40 shared credential groups, tracking who has access to what without automated sync becomes a guessing game rather than a governance process.

Passwork's AD and LDAP integration handles this natively. Group membership in AD maps directly to vault permissions — when someone moves from the Development team to Operations, their vault access updates automatically on the next sync.

Step 3: Train the team on the new workflow 

The secure path must be faster than the insecure workaround. If sharing a credential through a password manager takes 5 minutes while sharing it via Slack takes 5 seconds, people will use Slack. Training should focus on the three most common scenarios: 

1. Sharing a credential with a new team member. 
2. Granting temporary access to a contractor through a one-time link, and revoking access when a project ends. 
3. Keeping it task-oriented rather than policy-oriented.

Keep it task-oriented rather than policy-oriented. In Passwork, all three scenarios take under a minute from the vault interface — generating a one-time link for a contractor requires two clicks and produces a URL that expires automatically after first use or after a defined time window. That speed is what makes adoption stick.

Step 4: Establish ongoing monitoring and quarterly access reviews 

Schedule quarterly reviews to identify stale permissions, unused credentials, and accounts that were never properly offboarded. Audit logs make this tractable: the review becomes a structured query rather than a manual investigation.

You are looking for accounts that haven't been accessed in 90 days, credentials that haven't been rotated since a known compromise window, and contractor accounts that should have expired. Passwork's security audit tools surface these automatically — weak passwords, inactive accounts, and over-privileged users appear in a single report rather than requiring a manual sweep across every vault.

Conclusion

Secure password sharing is an access governance problem. Moving credentials into a vault is the first step. RBAC, audit logs, phishing-resistant MFA, and AD integration are what separate a compliant, auditable system from a slightly more organized version of the same risk.

The 4-step password governance model gives you a workable sequence: pilot with IT, connect to AD, train on the actual workflow, review quarterly. Skip AD integration and offboarding stays manual. Skip training and people keep using Slack.

If your password policy predates August 2025, it needs a review. If your organization is in scope for NIS2 and cannot produce access logs on demand, the gap is real, measurable, and fixable. The tooling to close it exists — the question is whether it fits your infrastructure and compliance requirements.

Passwork is built for exactly that context: organizations that need full credential governance without surrendering data to a third-party cloud. It deploys on-premise or in the EU cloud, integrates natively with AD and LDAP, and produces the audit trails NIS2 auditors ask for by default. If the 4-step model described in this article is where you want to land, Passwork is the infrastructure that makes each step operational.

Frequently Asked Questions

Insecure password sharing: 2026 risks and secure solutions

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

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

Password management for teams: The fix every SMB needs

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

Passwork BlogAlex Muntyan

A máquina de infrações da UE passou dos avisos às remessas para o Tribunal em julho de 2026. A Irlanda, a Espanha, a França e os Países Baixos enfrentam agora sanções financeiras por não terem cumprido o prazo de transposição da NIS2 de outubro de 2024, com sanções pecuniárias diárias que se acumulam até cada país notificar a Comissão da transposição completa.

Em simultâneo, as estruturas de aplicação vão ganhando forma. O BSI da Alemanha está a auditar ativamente as entidades registadas. Os Países Baixos aprovaram a lei nacional um dia antes de a remessa ser apresentada. O Grupo de Cooperação NIS publicou o documento de mapeamento do artigo 21.º mais detalhado até à data. E a Comissão associou pela primeira vez, de forma explícita, a NIS2 à deteção de ameaças assistida por IA.

Este artigo aborda todos os desenvolvimentos relevantes da NIS2: o que mudou, que prazos estão em vigor e em que a equipa tem de agir já. Para os desenvolvimentos do mês anterior, consulte Últimas novidades NIS2: maio de 2026.

Pontos principais

• Remessas para o Tribunal contra quatro Estados-Membros. A 8 de julho de 2026, a Comissão Europeia 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 transposto integralmente a NIS2. São solicitadas sanções financeiras para cada país.
• A Cyberbeveiligingswet dos Países Baixos entra em vigor a 15 de agosto de 2026. O Senado neerlandês aprovou a lei a 7 de julho. Mais de 8000 organizações têm de registar-se junto do NCSC, implementar medidas de segurança baseadas no risco e assegurar a supervisão ao nível do conselho de administração até essa data.
• O BSI alemão está agora a auditar, e não apenas a registar. A fase de supervisão ativa teve início a 6 de março de 2026. O BSI pode solicitar provas das medidas de segurança sem esperar por um incidente. Aplica-se um segundo prazo de registo, a 31 de julho, a uma parte significativa das 29 000 entidades abrangidas que falharam o prazo de março.
• O Grupo de Cooperação NIS publicou o seu documento de mapeamento do artigo 21.º. Publicado em junho de 2026, associa as obrigações da NIS2 e o Regulamento de Execução 2024/2690 às normas ISO 27001, NIST CSF 2.0 e IEC 62443 e aos quadros nacionais. É a orientação de conformidade mais concreta publicada até à data a nível da UE.
• O NCSC da Irlanda publicou orientações de governação cibernética para os conselhos de administração. Publicado a 7 de julho de 2026, o documento destina-se a CEOs, CIOs e CISOs de organizações reguladas pela NIS2 e assenta no quadro CyFun, baseado no NIST.
• A ENISA elevou o setor espacial para criticidade alta. O relatório NIS360 2026 coloca o setor espacial a par do setor bancário, da eletricidade e da aviação. Sete setores permanecem na zona de risco, onde a maturidade fica abaixo do que a criticidade exige.
• O Plano de Ação da UE para a Cibersegurança e a IA foi publicado a 7 de julho de 2026. É o primeiro documento a nível da UE a associar formalmente a conformidade com a NIS2 à deteção de ameaças assistida por IA como prática operacional esperada.
• O projeto de lei Cyber Security and Resilience Bill do Reino Unido foi aprovado na Câmara dos Comuns a 16 de junho. Deu entrada na Câmara dos Lordes a 17 de junho e a segunda leitura está agendada para 14 de julho. Os prestadores de serviços geridos e os operadores de centros de dados ficam abrangidos pela primeira vez.

Comissão Europeia leva Irlanda, Espanha, França e Países Baixos a tribunal por atrasos na NIS2

A 8 de julho de 2026, a Comissão Europeia 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 integral da Diretiva NIS2. As remessas incluem um pedido de sanções financeiras: uma quantia fixa e sanções pecuniárias diárias que se acumulam até cada país notificar a transposição completa.

O prazo de transposição era 17 de outubro de 2024. A Comissão enviou cartas de notificação aos Estados-Membros incumpridores em novembro de 2024 e pareceres fundamentados em maio de 2025. A remessa para o Tribunal é a terceira e última fase do processo por infração da UE.

O momento é digno de nota no caso dos Países Baixos. O Senado neerlandês aprovou a Cyberbeveiligingswet a 7 de julho, um dia antes de a remessa ser apresentada (mais pormenores adiante). A lei entra em vigor a 15 de agosto de 2026, mas a notificação formal da transposição à Comissão ainda não tinha sido apresentada à data da remessa. As sanções pecuniárias diárias deixarão de acumular-se quando a notificação estiver concluída.

Relativamente a Espanha, França e Irlanda, ainda não foi aprovada nenhuma lei nacional equivalente. A transposição em Espanha deverá ocorrer no final de 2026. A França e a Irlanda não anunciaram prazos firmes.

Os processos por infração têm números de processo individuais:

• Irlanda (INFR(2024)0279)
• Espanha (INFR(2024)0270)
• França (INFR(2024)0274)
• Países Baixos (INFR(2024)0288)

As remessas reforçam um ponto que as equipas de conformidade destes países já devem conhecer: os requisitos da Diretiva NIS2 são vinculativos independentemente do estado da transposição nacional. Os processos judiciais não suspendem as obrigações subjacentes, mas exercem pressão financeira sobre os governos para colmatarem a lacuna mais depressa.

Fonte: Comissão Europeia, 2026

Países Baixos: Cyberbeveiligingswet aprovada, entra em vigor a 15 de agosto

A 7 de julho de 2026, o Senado neerlandês aprovou a Cyberbeveiligingswet (a transposição neerlandesa da NIS2) e a Lei de Resiliência das Entidades Críticas (Wwke), que implementa a Diretiva relativa à Resiliência das Entidades Críticas (CER) da UE. Ambas as leis entram em vigor a 15 de agosto de 2026.

Mais de 8000 organizações são abrangidas: ministérios, municípios, autoridades da água, províncias, organismos administrativos independentes e parcerias intermunicipais. A partir de 15 de agosto, têm de:

1. Registar-se no Centro Nacional de Cibersegurança (NCSC) através do Registo de Entidades
2. Implementar medidas técnicas, operacionais e organizativas adequadas, com base numa avaliação de risco, incluindo as dependências da cadeia de abastecimento
3. Comunicar os incidentes de cibersegurança graves ao CSIRT pertinente e à autoridade de supervisão competente, dentro dos prazos legais
4. Assegurar a supervisão ao nível do conselho de administração: os membros do órgão de administração têm de ter conhecimentos suficientes de cibersegurança e concluir formação adequada

A aplicação cabe às autoridades de supervisão designadas, incluindo a Autoridade neerlandesa para as Infraestruturas Digitais. A Cyberbeveiligingswet introduz a responsabilidade dos administradores: as autoridades de supervisão podem emitir instruções vinculativas, realizar inspeções e suspender administradores sempre que necessário.

Para as organizações do setor público, o cumprimento da norma Baseline Information Security Government (BIO) 2 contribui para satisfazer os requisitos de segurança da Cbw.

A data de entrada em vigor, 15 de agosto, é um prazo improrrogável. O registo junto do NCSC deve começar antes dessa data: o próprio NCSC recomenda a preparação antecipada para evitar estrangulamentos no processo de registo.

Fonte: NL Digital Government, 2026

A nível da UE: Publicado novo documento de referência sobre medidas de segurança

Publicado em junho de 2026, o documento de referência sobre medidas de segurança do Grupo de Cooperação NIS oferece às organizações a orientação a nível da UE mais concreta até à data sobre a conformidade com o artigo 21.º da NIS2. O documento estabelece um quadro europeu comum de objetivos de cibersegurança e inclui uma tabela de mapeamento que associa as obrigações da NIS2 e o Regulamento de Execução europeu 2024/2690 a:

• ISO/IEC 27001
• IEC 62443
• NIST Cybersecurity Framework 2.0
• quadros nacionais de cibersegurança
• o CyberFundamentals Framework, CyFun®

O documento não é vinculativo. Não substitui a legislação nacional relativa à NIS2 nem as orientações setoriais. Mas, para as equipas de conformidade que já trabalham com base na ISO 27001 ou no NIST CSF 2.0, responde a uma pergunta em aberto desde a aprovação da diretiva: de que forma correspondem, exatamente, os controlos já existentes aos requisitos da NIS2?

O mapeamento é particularmente útil para organizações que operam em vários Estados-Membros. Em vez de manterem análises de lacunas separadas por jurisdição, as equipas podem utilizar o documento de referência como base comum e acrescentar depois os desvios nacionais.

O controlo de acessos, a autenticação e a gestão de acessos privilegiados surgem explicitamente nos objetivos mapeados, áreas em que as orientações do documento de referência se alinham diretamente com o artigo 21.º, n.º 2, alínea j), da NIS2, relativo à utilização de autenticação multifator e de sistemas de comunicação seguros.

Fontes: Center for Cybersecurity Belgium, 2026; Comissão Europeia, 2026

Irlanda: O NCSC publica orientações de governação cibernética para os conselhos de administração de entidades NIS2

A 7 de julho de 2026, o Centro Nacional de Cibersegurança da Irlanda publicou orientações sobre governação cibernética destinadas aos membros dos conselhos de administração de organizações reguladas pela NIS2. O documento dirige-se a CEOs, diretores-gerais, CIOs e CISOs, os dirigentes que têm responsabilidade pessoal pela gestão do risco de cibersegurança ao abrigo da NIS2.

As orientações centram-se no Cyber Fundamentals Framework (CyFun), o quadro nacional preferencial da Irlanda para a conformidade com a NIS2. O CyFun baseia-se no NIST Cybersecurity Framework e oferece aos conselhos de administração uma abordagem estruturada e baseada no risco para cumprirem as suas obrigações legais, sem exigir conhecimentos técnicos aprofundados.

O documento abrange três áreas práticas: compreender que perguntas os conselhos de administração devem colocar sobre o risco cibernético, identificar e gerir os riscos da cadeia de abastecimento e criar uma cultura organizacional em que a cibersegurança seja tratada como uma questão de governação, e não como um problema do departamento de TI.

O momento é deliberado. A Irlanda está atualmente sujeita a um processo por infração da UE por não ter transposto integralmente a NIS2 para o direito nacional: a Comissão remeteu o país para o Tribunal de Justiça a 8 de julho de 2026. A publicação de orientações ao nível do conselho de administração antes da transposição formal indica que o NCSC está a encaminhar as organizações para a conformidade, independentemente do ponto em que se encontre o processo legislativo.

Fonte: Portal oficial do Governo da Irlanda, 2026

ENISA NIS360 2026: Setor espacial sobe para criticidade alta

O relatório ENISA NIS360 2026 é a terceira avaliação anual da maturidade e da criticidade da cibersegurança em todos os setores do anexo I da Diretiva NIS2. A principal conclusão: o setor espacial juntou-se ao setor bancário, à eletricidade, à aviação e aos serviços digitais por defeito na faixa de criticidade mais alta.

A elevação reflete o papel crescente da infraestrutura espacial como camada de dependência para outros setores: a navegação, as comunicações, a liquidação financeira e a logística militar assentam todas em sistemas de satélite. Maior dependência significa maior impacto em caso de perturbação e maior criticidade temporal na recuperação.

Sete setores situam-se na zona de risco do NIS360 2026, em que a maturidade da cibersegurança fica abaixo do nível exigido pela respetiva criticidade:

1. Saúde
2. Transporte ferroviário
3. Transporte marítimo
4. Gestão de serviços de TIC
5. Espaço
6. Administração pública
7. Água potável e águas residuais

Três setores atingiram a faixa de maturidade alta: serviços de confiança, aviação e infraestruturas do mercado financeiro. O setor do gás começou a sair da zona de risco, graças à melhoria da partilha de informações e a uma implementação mais sólida das medidas de gestão de riscos.

A composição da zona de risco tem relevância operacional. As autoridades de supervisão utilizam os dados do NIS360 para definir as prioridades dos calendários de auditoria. Se a organização atua nos setores da saúde, ferroviário ou da administração pública, deve esperar uma maior atenção das autoridades de supervisão no segundo semestre de 2026.

A ENISA concluiu, no estudo NIS Investments 2025, que 70 % das organizações inquiridas apontaram o cumprimento da NIS2, do DORA e do CRA como o principal fator de investimento em cibersegurança, um valor que deverá aumentar à medida que as autoridades de supervisão passam do registo para a análise ativa.

Fonte: ENISA, 2026

Alemanha: O BSI entra na fase de supervisão ativa

O BSI da Alemanha entrou na fase de supervisão ativa a 6 de março de 2026, data em que expirou o prazo de registo ao abrigo da NIS2-Umsetzungsgesetz (NIS2UmsuCG). A lei foi promulgada a 6 de dezembro de 2025. Em junho de 2026, estava em vigor há seis meses.

A análise de 16 de junho do SecurityToday.de sobre a mudança na supervisão observou que a questão se alterou: já não se trata de saber se uma entidade está registada, mas se as medidas comunicadas resistem a um exame rigoroso.

O portal de registo do BSI abriu a 6 de janeiro de 2026. Uma parte significativa das cerca de 29 000 entidades abrangidas falhou o prazo de março. O BSI fixou um segundo prazo de registo, a 31 de julho de 2026. O registo tardio continua a ser possível, mas não constitui porto seguro: as obrigações de conformidade aplicam-se desde dezembro de 2025, independentemente do estado do registo.

O que significa supervisão ativa na prática:

• O BSI pode solicitar proativamente provas das medidas de segurança, sem esperar por um incidente
• As auditorias no local e remotas estão agora abrangidas
• As coimas para entidades essenciais podem ir até 10 milhões de euros ou 2 % do volume de negócios anual mundial, consoante o que for mais elevado
• Os membros dos órgãos de gestão enfrentam responsabilidade pessoal, incluindo a possível proibição temporária de exercer funções de gestão

A implementação alemã vai além do mínimo da UE em matéria de responsabilização dos dirigentes. A NIS2UmsuCG exige expressamente que os órgãos de gestão aprovem as medidas de cibersegurança, supervisionem a sua implementação e demonstrem competência pessoal. As autoridades de supervisão podem responsabilizar pessoalmente cada dirigente por falhas sistémicas.

O nível de exigência mais elevado da Alemanha tem uma vantagem prática. As organizações que cumprem os requisitos da NIS2UmsuCG satisfazem com folga o mínimo da UE. Para as empresas que operam em vários Estados-Membros, uma postura de segurança que satisfaça o escrutínio do BSI deverá, em geral, ser igualmente aceite pelas autoridades de supervisão vizinhas.

Para quem se registou tarde, a ordem de prioridades é clara: registar primeiro e só depois reunir provas documentadas das medidas. Se ocorrer um incidente de notificação obrigatória antes de as medidas estarem comprovadamente implementadas, um registo em falta ou tardio é um fator agravante.

Fonte: SecurityToday.de, 2026

Publicado o Plano de Ação da UE para a Cibersegurança e a IA

A 7 de julho de 2026, a Comissão Europeia publicou o Plano de Ação da UE para a Cibersegurança e a Inteligência Artificial (EU Action Plan on Cybersecurity and Artificial Intelligence). O documento define uma abordagem coordenada da UE à cibersegurança baseada em IA em todos os Estados-Membros, autoridades públicas e empresas.

O plano assenta em três objetivos: promover a utilização segura e responsável da IA avançada, reforçar a cibersegurança e a resiliência da UE e ampliar as capacidades de IA da Europa para fins de cibersegurança.

No que respeita à NIS2, o Plano de Ação refere expressamente a Diretiva NIS2 como parte do quadro jurídico existente em que se baseia e incentiva as organizações abrangidas pela NIS2 a utilizar IA (incluindo modelos de código aberto) para detetar e corrigir vulnerabilidades mais depressa. É o primeiro documento a nível da UE a associar formalmente a conformidade com a NIS2 à deteção de ameaças assistida por IA como prática operacional esperada.

As medidas concretas incluem:

• Um plano de referência europeu (blueprint) para o acesso seguro a sistemas de IA avançados para fins de cibersegurança, a desenvolver com a ENISA
• Uma plataforma de testes segura para organizações de setores críticos (energia, transportes, saúde, finanças e administração pública), destinada a testar e implementar soluções de IA em segurança
• Um Grande Desafio da UE sobre IA para a cibersegurança (EU Grand Challenge), que reúne a indústria, investigadores e comunidades de código aberto

O Plano de Ação coexiste com o Regulamento da IA, o Regulamento Ciberresiliência, o DORA e o Regulamento Cibersolidariedade. Não cria, por si só, novas obrigações vinculativas, mas indica onde a Comissão espera que se concentrem a ênfase na aplicação e o investimento no próximo ciclo legislativo.

Fonte: Comissão Europeia, 2026

Reino Unido: O Cyber Security and Resilience Bill passa na Câmara dos Comuns e segue para a Câmara dos Lordes

A 16 de junho de 2026, o projeto de lei Cyber Security and Resilience (Network and Information Systems) Bill concluiu a terceira leitura e a fase de relatório na Câmara dos Comuns. Teve a primeira leitura na Câmara dos Lordes a 17 de junho e tem a segunda leitura agendada para 14 de julho de 2026.

O projeto de lei foi apresentado ao Parlamento a 12 de novembro de 2025 e atualiza as Network and Information Systems Regulations 2018 (NIS1) em vigor. Não transpõe a NIS2 (o Reino Unido já não está vinculado pelo direito da UE), mas aproxima significativamente os requisitos do Reino Unido da norma NIS2 em termos de âmbito e de aplicação.

O que o projeto de lei acrescenta:

• Prestadores de serviços geridos ficam abrangidos pela primeira vez. Os prestadores de serviços geridos relevantes (RMSPs) têm de registar-se junto do ICO, implementar medidas de gestão de riscos e nomear um representante no Reino Unido caso não estejam estabelecidos neste país.
• Operadores de centros de dados também passam a ficar abrangidos.
• Os prazos de notificação de incidentes tornam-se mais rigorosos: notificação inicial em 24 horas e notificação completa em 72 horas, em linha com a estrutura do artigo 23.º da NIS2.
• Designação de fornecedores críticos: O ICO passa a ter poder para designar fornecedores cujo comprometimento afetaria serviços essenciais ou RMSPs.
• As sanções aumentam para até 17 milhões de libras ou 4 % do volume de negócios anual mundial em caso de infrações graves e até 10 milhões de libras ou 2 % nas menos graves.

A definição de incidente também é alargada: o projeto de lei abrange os incidentes «suscetíveis de ter um efeito adverso» nos serviços regulados, e não apenas os que tiveram um efeito real comprovado. Trata-se de uma alteração relevante para as organizações que estão a calibrar os respetivos limiares de notificação.

Foram propostas 63 alterações durante a tramitação do projeto de lei. Duas alterações apresentadas em junho, incluindo uma para acrescentar a cadeia de abastecimento alimentar como serviço essencial regulado, não obtiveram decisão na fase de relatório.

O Governo prevê realizar uma consulta em 2026 sobre a legislação secundária relativa a medidas específicas de gestão de riscos e a requisitos de notificação. Algumas disposições produzirão efeitos no primeiro dia ou no segundo mês após o assentimento real; outras seguirão por via de legislação secundária.

Fontes: Parlamento do Reino Unido, 2026; Parallel Parliament, 2026

Resumo

O período de junho a início de julho de 2026 marca o momento em que a aplicação da NIS2 passou da pressão política para a ação jurídica e de supervisão efetiva. As remessas para o Tribunal foram apresentadas. As leis nacionais estão a entrar em vigor. As autoridades de supervisão estão a solicitar provas das medidas de segurança, e não apenas confirmações de registo.

Para as organizações na Irlanda, em Espanha, em França e nos Países Baixos, os processos por infração não alteram em nada as obrigações subjacentes. Os requisitos da NIS2 são vinculativos desde outubro de 2024, independentemente do estado da transposição nacional. Os processos acrescentam consequências financeiras para os governos, mas não criam um período de tolerância para as entidades reguladas.

Para as organizações na Alemanha e nos Países Baixos, o calendário de conformidade está agora definido. O BSI está a auditar. A Cyberbeveiligingswet entra em vigor a 15 de agosto. O documento de mapeamento do artigo 21.º publicado pelo Grupo de Cooperação NIS em junho de 2026 é o resultado mais aplicável na prática deste período: se a equipa já trabalha com base na ISO 27001 ou no NIST CSF 2.0, oferece um caminho direto para concluir a análise de lacunas da NIS2 antes que uma autoridade de supervisão a faça por conta da organização.

Controlos de acesso NIS2 para a segurança da cadeia de abastecimento

48 % das violações envolvem agora terceiros. O artigo 21.º da NIS2 torna a governação do acesso de fornecedores uma obrigação legal. Eis como mapear o acesso dos fornecedores, impor a MFA e o princípio do menor privilégio e manter as provas de auditoria que demonstram que os controlos funcionam.

Passwork BlogAlex Muntyan

Shadow IT vs Shadow AI: Porque a IA é a maior ameaça

Os colaboradores estão a utilizar ferramentas de IA que não foram aprovadas, em contas que não é possível monitorizar, com dados que não é possível recuperar. Eis como é realmente o risco e o que a governação tem de abordar.

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 à desativação. Este guia abrange o procedimento completo de saída de colaboradores, desde os gatilhos de hora zero até à limpeza de NHI.

Passwork BlogAlex Muntyan