Biometric authentication verifies a person through a characteristic such as a fingerprint or facial scan. In a passkey sign-in flow, that biometric, or a local PIN, unlocks a cryptographic key stored on the device rather than sending a password anywhere. NIST SP 800-63B Revision 4 treats biometrics as part of multi-factor authentication paired with a physical authenticator, not as a standalone remote authenticator.

For enterprise password vaults, the security benefit comes from the credential architecture, endpoint integrity, and authorization policy, not from the biometric gesture alone. The operational decision for IT leaders is whether the organization can support managed endpoints, a tested non-biometric fallback, and vault governance solid enough to matter once sign-in friction disappears.

What is biometric authentication

Biometric authentication verifies a person's identity using a physical trait, such as a fingerprint, face, or iris pattern, instead of a memorized secret. On modern devices, the check happens locally: the sensor compares the live scan against a template stored on the device and, if it matches, unlocks a cryptographic key or grants access to the system.

It's a verification method, not an access-control system. A fingerprint or face scan confirms who is sitting at the device. It says nothing about which files, systems, or vaults that person should be allowed to reach, that's a separate layer, handled by roles, permissions, and policy.

Common implementations include:

• Fingerprint recognition, read by a capacitive sensor built into a laptop, phone, or standalone key fob.
• Facial recognition, such as Face ID or Windows Hello, using a camera and, on most devices, an infrared depth sensor to resist photo spoofing.
• Iris and retina scanning, used mainly in high-security facilities rather than everyday corporate sign-in.
• Voice recognition, less common for device sign-in, more common in call-center identity checks.

In an enterprise context, biometrics almost always appear as the local unlock step in a larger authentication flow, most commonly a WebAuthn passkey, rather than as a standalone way to reach corporate systems. NIST SP 800-63B Revision 4 formalizes that role: biometrics function as part of multi-factor authentication, paired with a physical authenticator, not as a remote credential on their own.

What biometric authentication does (and does not) secure

Biometrics verify the person locally, on the device or authenticator. They don't, on their own, secure anything server-side. That job belongs to the WebAuthn cryptographic assertion and the password manager's role and vault policy, which decide what the verified person can actually reach.

Passwords are replayable secrets that an employee types into a login field, which makes them phishable and reusable across systems. A local biometric gesture instead authorizes use of a private key that stays under the control of an authenticator, so there's no shared secret to intercept in transit. 

The W3C WebAuthn Level 3 specification defines two credential types here. A single-device credential can't be exported. A backup-eligible multi-device credential, commonly called a synced passkey, can be available across a user's devices within the same platform ecosystem. Both keep the private key out of the relying party's hands. Only the first is accurately described as bound to one device.

Advantages of biometric authentication

Biometric sign-in removes the step where an employee types a secret that can be phished, guessed, or reused. Paired with a passkey, it replaces a replayable password with a private key that never leaves the device, and industry data shows measurable gains in sign-in speed and fewer help-desk tickets tied to lost credentials.

The advantage is structural, not cosmetic. A password sitting in a login field can be captured by a fake site, a keylogger, or a reused-credential list. A biometric-unlocked passkey has nothing equivalent to steal in transit, because the private key never crosses the network.

The speed gain is documented. FIDO Alliance's Passkey Index reports a 93% success rate for passkey sign-ins against 63% for other methods, a 73% decrease in login time, and up to an 81% reduction in login-related help-desk incidents. These are association-reported, industry-wide figures from participating organizations, not a guarantee for any specific deployment.

None of this makes biometrics a complete answer on its own. The gain shows up when a biometric authorizes a well-governed credential. Used as a bare standalone factor, it swaps a revocable secret for a permanent one, which is exactly the trade-off the next section covers.

Risks of biometric authentication

Biometric authentication ties access to a fingerprint, face scan, or iris pattern that can't be changed if compromised. Unlike a password, you can't rotate a fingerprint after a breach, and centralized biometric databases become high-value targets for attackers. These risks make biometrics a poor standalone replacement for credential management.

• Irrevocability is the core problem. NIST SP 800-63B classifies biometrics as an identifier, not a secret, since they can't be reset like a password (NIST SP 800-63B, Section 5.2.3). Once a template leaks, that factor is compromised for good.
• Centralized data is a single point of failure. Storing biometric templates in one database creates one high-value target: a breach there exposes fingerprint or facial data for every enrolled user at once. A password breach forces a reset. A biometric breach has no equivalent fix. This is a different object from the "central governance" discussed later in this article, which centralizes who can reach a secret, not the biometric template itself.
• Spoofing. Photos and deepfake video have defeated consumer-grade sensors in independent tests, and accuracy varies widely with sensor quality and lighting.
• Regulatory exposure. GDPR Article 9 treats biometric identifiers as special category data, requiring explicit consent and stricter safeguards than standard credentials.

None of this makes biometrics a complete answer on its own. The gain shows up when a biometric authorizes a well-governed credential. Used as a bare standalone factor, it swaps a revocable secret for a permanent one, which is exactly the trade-off the next section covers.

Biometrics, passkeys, and WebAuthn: The control boundary

The control boundary is the line between what a biometric authorizes locally and what WebAuthn proves to a server. A fingerprint or face scan unlocks a device-bound key; the cryptographic assertion that key produces, scoped to a Relying Party ID, is what the server actually checks.

Fingerprint and facial authentication both work for employee sign-in on supported managed devices, but the right choice depends on sensor quality, device management maturity, accessibility needs, and acceptable risk level. Neither method is a universal answer. Both trade differently on speed, reliability, and governance overhead.

Local verification versus central biometric matching

Local verification checks a biometric against a template stored on the device itself. Central verification checks it against a reference database held elsewhere. NIST recommends local verification because it removes, or sharply reduces, the need for a centrally held biometric store that becomes a single point of failure if breached.

The distinction is easiest to see through two familiar examples:

• Local verification: Windows Hello or Touch ID checks a fingerprint against a template stored in a secure hardware enclave on the device. The template never leaves the chip.
• Central verification: airport border-control gates match a traveler's face against a passport database held on a server, not on the gate itself.

Organizations should confirm the template-handling model for each device platform and product integration rather than assume it's identical everywhere. Local verification and centralized secret governance are not in tension. The goal is to keep biometric templates local while still centralizing control over who can reach a given credential, two different things being centralized (or not) for two different reasons.

NIST SP 800-63B Revision 4 sets three specific benchmarks for applicable deployments:

• False match rate (FMR): the probability the wrong person gets accepted. NIST requires 1 in 10,000 or better.
• False non-match rate (FNMR): the probability the legitimate user gets rejected. NIST recommends below 5%.
• Presentation-attack detection (PAD): required for facial recognition, recommended for fingerprint and iris modalities.

Treat these figures as procurement benchmarks for vendor evaluation, not as guaranteed real-world performance. Actual sensor accuracy varies by manufacturer.

Fingerprint versus facial recognition on managed devices

Fingerprint and facial recognition fail differently, and both need a tested fallback rather than a default assumption that the sensor will always work.

A facial recognition rollout without PAD in scope is incomplete under NIST's guidance. Independent research has shown facial sensors can be bypassed with a modified image rather than a live face, which is exactly the attack PAD is meant to catch.

What actually counts as a factor in multi-factor biometric authentication

A biometric never functions as a standalone factor under NIST's guidance. Multi-factor biometric authentication combines a local "something you are" check with a physical, cryptographic authenticator representing "something you have." The biometric activates that authenticator. It doesn't serve as proof of identity by itself, and enrolling a fingerprint and a face on the same device doesn't create two factors, only two ways to unlock the same one.

Two authenticator types sit behind these prompts, and they survive device loss differently. A platform authenticator is built into the employee's device and is lost along with it. A hardware security key moves between devices, adding a physical possession factor that survives a lost or wiped laptop.

WebAuthn credentials add a second layer of protection on top of the factor itself: each credential is scoped to a Relying Party ID, the identifier of the specific site or service it's registered to. A credential registered for one relying party can't be used on an unrelated lookalike domain. That scoping, not the biometric, is what gives WebAuthn its phishing resistance.

None of this replaces separate policy controls. MFA settings, device trust posture, session timeout, and conditional access for high-risk actions still sit on top of the sign-in method itself.

The five controls for enterprise rollout

Biometric convenience stays at the employee's device. Secret governance stays with centrally managed identity and password-vault controls. Splitting the two removes the need to build a company-held biometric database while keeping full organizational control over who reaches which secret.

The three factors that opened this article, managed endpoints, a working fallback, and vault governance, break down into five specific controls once you're ready to operationalize them. This is the Local Biometric Unlock / Central Secret Governance model, a practical framework rather than a formal standard.

Managed endpoints and user verification

• Managed endpoint and supported authenticator. Define which devices, OS versions, and sensors are eligible before anyone enrolls.
• Local user verification. A biometric or PIN unlocks the authenticator. An alternate non-biometric method stays available for anyone who needs it.

Identity policy and central secret governance

• Identity and step-up policy. SSO, MFA, session duration, and additional verification for high-risk administrative actions.
• Central secret governance. Roles, least privilege, vault segmentation, activity review, and secure sharing govern the actual corporate credentials.

Recovery and revocation

• Recovery and revocation. A documented process covers lost-device response, passkey reset or removal, break-glass access, and audit review.

Biometric data able to uniquely identify a person is classified as special category data under UK GDPR, according to the ICO's guidance on biometric recognition. Consent alone isn't the deciding factor: applicable law may require a lawful basis, a special-category condition, transparency, and data minimization on top of it, and the specifics vary by jurisdiction. That assessment belongs with the organization's legal and privacy teams. This model doesn't resolve it; it reduces how much biometric data needs to exist centrally in the first place.

Using Passwork passkeys with vault governance

Passwork supports passkey sign-in built on the WebAuthn standard, letting users authenticate with a device-bound key instead of a password. Supported platform authenticators include Face ID, Touch ID, Windows Hello, and compatible hardware security keys. An administrator enables it for specific roles, and every member of that role can then choose to enroll a passkey.

The 4-step passkey sign-in workflow

Passkey adoption in Passwork follows a fixed sequence that keeps authentication changes inside the existing role and audit model, instead of running alongside it as a separate system.

1. Enable the role setting. An administrator decides which roles may use the "Use passkey instead of password" sign-in option.
2. Enroll the passkey. An employee registers a platform passkey or a WebAuthn security key on the Authentication page of their account.
3. Sign in with local verification. The employee approves a device-local biometric or PIN prompt. The passkey proves key ownership without ever transmitting the local or domain password.
4. Handle offboarding or loss. If a device is lost, replaced, or an employee leaves, the administrator removes or resets the passkey and follows the organization's recovery and access-review procedure.

Pilot metrics and rollout checklist

A biometric rollout is ready to expand past a pilot group once each of the five controls above has an owner, evidence of readiness, and a defined failure response. This pilot-readiness checklist turns the model into a go/no-go gate rather than a rollout that scales on assumptions.

Track enrollment completion rate, authentication success rate, false-reject and fallback frequency, help-desk volume, time to remove a lost device, and time to revoke access after offboarding. Compare your numbers against the FIDO Alliance benchmarks cited earlier: a completion or success rate far below 93%, or a fallback rate far above what your pilot group predicted, is worth investigating before scaling past the first team.

Conclusion

Biometric authentication and password-manager governance solve different problems. Mixing them up is where most rollouts go wrong. Biometrics unlock the device; vault governance decides who reaches which secret. Keep those jobs separate, and the payoff is faster sign-in without a biometric database nobody meant to build, or a single weak point standing in for real access control.

Pick one team already handling shared admin, SaaS, or infrastructure credentials, and pilot the split before it becomes company-wide practice.

Frequently asked questions

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

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

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

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

Ein Datenleck kostet jetzt 1.100 Dollar für jede Stunde, die es unbehoben bleibt. Im Jahr 2026 dauerte die Eindämmung von Datenlecks durchschnittlich 247 Tage — was sich auf einen Rekordwert von 4,99 Millionen Dollar pro Vorfall summiert. Laut dem Cost of a Data Breach Report 2026 von IBM, erstellt mit dem Ponemon Institute auf Basis von 602 betroffenen Organisationen in 16 Ländern, zeigen die diesjährigen Daten ein zentrales Thema: KI ist zum entscheidenden Faktor in der Ökonomie von Datenlecks geworden.

Angreifer, die KI einsetzen, sind mittlerweile für 1 von 4 böswilligen Datenlecks verantwortlich (+56 % im Jahresvergleich). Verteidiger, die KI umfassend nutzen, sparen 1,93 Millionen Dollar pro Vorfall. Beide Aussagen treffen gleichzeitig zu, und die Lücke zwischen ihnen ist die eigentliche Geschichte. Dieser Artikel übersetzt die Kernzahlen des Berichts in Entscheidungen, die ein CISO in eine Budgetbesprechung mitbringen kann — nicht nur eine Zusammenfassung der Ergebnisse.

Was ist der IBM Cost of a Data Breach Report 2026

Der IBM Cost of a Data Breach Report 2026 ist die 21. jährliche Ausgabe der Flaggschiff-Studie von IBM zur Ökonomie von Datenlecks. Er basiert auf Interviews mit 602 Organisationen in 16 Ländern und 17 Branchen, die zwischen März 2025 und Februar 2026 ein Datenleck erlitten haben, sowie einer Folgestudie vom Mai 2026 mit 456 derselben Befragten.

Ein wichtiger Vorbehalt vorab: Die Stichprobe ist nicht statistisch, daher gelten Fehlermargen nicht im traditionellen Sinne, und sie tendiert zu Organisationen mit ausgereifteren Sicherheitsprogrammen, die bereit sind, teilzunehmen. Die Zahlen sollten als richtungsweisende Benchmarks für die Planung betrachtet werden, nicht als versicherungsmathematische Vorhersagen für Ihre spezifische Organisation.

Was ist neu im IBM Cost of a Data Breach Report 2026

Die diesjährige Ausgabe ist die erste, die den Einsatz von agentischer KI innerhalb von Security Operations Centers (SOCs) misst, die erste, die die Bereitschaft für Post-Quanten-Kryptografie verfolgt, und die erste, die auf einer Folgestudie basiert, die durch ein Live-KI-Bedrohungsereignis ausgelöst wurde.

Die ursprünglichen Interviews endeten im Februar 2026. Zwei Monate später veränderte Anthropics Claude Mythos-Vorschau die Bedrohungswahrnehmung. IBM und Ponemon befragten im Mai 2026 456 ursprüngliche Teilnehmer mit einer direkten Frage: Hat dies Ihre Ausgabenpläne verändert?

Die Antwort brachte das hervor, was dieser Artikel als die 85 %-Erkenntnis bezeichnet: Ein echtes Datenleck überzeugte 64 % der Organisationen, ihre Sicherheitsausgaben zu erhöhen, aber die Nachricht über die Fähigkeiten eines Frontier-KI-Modells überzeugte 85 %. Die Angst vor einer zukünftigen Bedrohung überwog die Erinnerung an einen tatsächlichen Vorfall.

Vier weitere Premieren definieren das Jahr:

• Die durchschnittliche Zeit bis zur Identifizierung und Eindämmung (MTTI/MTTC) stieg nach fünf Jahren kontinuierlicher Verbesserung.
• Shadow-KI-Vorfälle verdoppelten sich auf 43 % aller KI-bezogenen Vorfälle.
• Ein Viertel der Organisationen nutzt überhaupt keine KI oder Automatisierung in der Sicherheit.
• Der Bericht misst zum ersten Mal genau, welche SOC-Funktionen Organisationen KI-Agenten zuweisen. Diese Aufschlüsselung ist das, was dieser Artikel als die 18 %-Schwachstellenlücke bezeichnet, die unten behandelt wird.

Das 4,99-Millionen-Dollar-Datenleck: Globale Kosten erreichen Rekordwert

Die globalen durchschnittlichen Kosten eines Datenlecks erreichten 2026 mit 4,99 Millionen Dollar einen Allzeit-Höchststand — ein Anstieg von 12 %, der hauptsächlich durch Aufwendungen für Erkennung und Eskalation sowie Kosten durch Geschäftsverluste getrieben wurde, die zusammen 63 % der Gesamtsumme ausmachten. Regulatorische Strafen, der Posten, auf den sich die meisten Vorstände fixieren, haben in der Gesamtsumme weniger Gewicht als Forensik, Krisenmanagement, Ausfallzeiten und Kundenabwanderung zusammen.

Nach einem Rückgang auf 4,44 Mio. $ im Jahr 2025 stiegen die Kosten 2026 wieder auf 4,99 Mio. $ an, machten ein Jahr des Fortschritts zunichte und erreichten einen neuen Rekord.

Die Dauer eines Datenlecks erhöht die Kosten direkt. Vorfälle, deren Behebung länger als 200 Tage dauerte, kosteten Organisationen durchschnittlich 5,65 Millionen Dollar, verglichen mit 4,32 Millionen Dollar für Datenlecks, die schneller eingedämmt wurden.

Land für Land: Wo Datenlecks am meisten kosten

Die Vereinigten Staaten brachen ihren eigenen Rekord mit durchschnittlichen Kosten für ein Datenleck von 11,5 Millionen Dollar — mehr als das Doppelte des globalen Durchschnitts und ein Anstieg von 11 % gegenüber dem Vorjahr, getrieben durch höhere regulatorische Strafen und Kosten durch Geschäftsunterbrechungen. Kein anderes Land kommt der US-Zahl nahe, aber die regionale Verteilung erzählt ihre eigene Geschichte.

Südafrika verzeichnete mit 22 % den größten prozentualen Anstieg in der Studie, obwohl die absoluten Kosten unter dem globalen Durchschnitt liegen. Diese Kombination — eine niedrige Basis, die schnell steigt — signalisiert in der Regel einen Markt, in dem die Sicherheitsausgaben nicht mit der Digitalisierung Schritt gehalten haben (nicht einen, in dem Datenlecks besonders schwerwiegend geworden sind). Benelux hingegen gehört bereits zu den Ländern mit den höchsten Kosten pro Vorfall weltweit und wuchs dennoch um 16 %.

KI-gesteuerte Angriffe steigen um 56 %: Die Zahlen hinter der Schlagzeile

KI-gesteuerte Angriffe machen jetzt mehr als 1 von 4 böswilligen Datenlecks aus — ein Anstieg von 56 % gegenüber dem Vorjahr — und erhöhen die durchschnittlichen Kosten eines Datenlecks um etwa 1 Million Dollar, wodurch KI-gestützte Vorfälle auf 6,04 Millionen Dollar steigen.

Aufschlüsselung der Angriffstypen

Bei der Aufschlüsselung der Angriffstypen zeigt sich ein klares Muster. Angreifer automatisieren die Social-Engineering- und Malware-Entwicklungsschritte, die früher qualifizierte menschliche Arbeitszeit erforderten.

• KI-Deepfake-Imitation: 45 % der KI-gestützten Angriffe, die größte Einzelkategorie
• KI-generierte Malware: 19 %
• KI-generiertes Phishing oder andere Kommunikation: 17 %

Konzentration auf kritische Infrastruktur

Kritische Infrastruktur absorbierte den konzentrierten Schaden: 62 % der KI-gesteuerten Angriffe in der Studie trafen diese Sektoren, wobei Finanzdienstleistungen (durchschnittlich 6,29 Mio. $) und Energie (durchschnittlich 5,24 Mio. $) den größten Anteil trugen.

Angriffe auf KI-Systeme selbst

Angreifer gehen auch direkt gegen KI-Systeme vor, und beide unten genannten Zahlen liegen über dem globalen Durchschnitt aller Ursachen, was zeigt, dass es sich dabei nicht mehr um Randerscheinungen handelt.

• KI-Modellinversionsangriffe (ein Angreifer rekonstruiert sensible Trainingsdaten aus einem eingesetzten Modell): durchschnittlich 6,07 Mio. $
• Prompt-Injection-Angriffe (bösartige Eingaben manipulieren das Verhalten eines Modells): durchschnittlich 5,89 Mio. $

Die 18 %-Lücke: Wo Verteidiger das KI-Wettrüsten verlieren

Die Hälfte der betroffenen Organisationen setzte KI-Agenten in ihren SOCs ein, aber nur 18 % richteten sie auf das Schwachstellenmanagement aus. Dies ist die 18 %-Schwachstellenlücke: Verteidiger setzen KI überall ein, außer dort, wo Angreifer eindringen.

Wohin SOC-Agenten tatsächlich gehen

Die meisten SOC-Agenten-Einsätze konzentrierten sich auf Erkennung und Reaktion, nicht auf die Eingangstür, die Angreifer nutzen:

• Threat Hunting: 56 %
• Reaktion und Eindämmung: 54 %
• Schwachstellen-Scanning und -Management: 18 %

Das Schwachstellenmanagement — die unspektakuläre Arbeit, Lücken zu finden und zu schließen, durch die Angreifer eindringen — erhielt die geringste Aufmerksamkeit, obwohl genau hier Frontier-KI-Modelle die Mathematik am schnellsten zu verändern drohen.

Warum die Lücke jetzt gefährlich ist

Im April 2026 stellte Anthropic Claude Mythos vor, ein Frontier-Modell, das während der Tests Tausende von Schwachstellen mit hohem Schweregrad in wichtigen Betriebssystemen und Browsern identifizierte. Die Forschung des Frontier Red Teams von Anthropic bezifferte die Kosten für die Entwicklung eines funktionierenden Exploits aus einer entdeckten Schwachstelle auf unter 1.000 bis 2.000 Dollar, erreichbar in weniger als einem Tag.

Die Branche reagiert bereits

Die Befragten von IBM selbst erkannten die Diskrepanz im Nachhinein, nach der Mythos-Ankündigung:

• 74 % der Organisationen gaben an, ihre KI-Agenten-Einsatzstrategie im SOC überdacht zu haben
• Der geplante Einsatz von Agenten für das Schwachstellenmanagement stieg von 18 % auf 37 % in der erklärten Absicht

Die Branchenaufschlüsselung: Gesundheitswesen, Finanzwesen und die größten Veränderungen

Das Gesundheitswesen blieb im 13. Jahr in Folge die teuerste Branche für Datenlecks mit 6,64 Millionen Dollar, obwohl es der einzige Sektor war, in dem die Kosten sanken — um 10,5 % von 7,42 Millionen Dollar im Jahr 2025.

Kommunikation verzeichnete mit 20 % den steilsten Anstieg in der gesamten Studie, gefolgt von Unterhaltung mit 18 %. Finanzdienstleistungen stiegen um 13 % auf 6,29 Millionen Dollar und setzten einen mehrjährigen Aufwärtstrend fort, der den Abstand zum Gesundheitswesen größtenteils geschlossen hat. Kunden-PII tauchten in 52 % der Datenlecks auf, mit durchschnittlich 192 Dollar pro Datensatz. Der Diebstahl von geistigem Eigentum war seltener, in 32 % der Datenlecks, aber mit 196 Dollar pro Datensatz der teuerste Datentyp.

Wie Angreifer eindringen: Phishing, Lieferketten und Social Engineering

Phishing, einschließlich sprach- und SMS-basierter Varianten, blieb im vierten Jahr in Folge der führende anfängliche Angriffsvektor — beteiligt an 17 % der Datenlecks und mit durchschnittlichen Kosten von 5,29 Millionen Dollar, den höchsten unter allen Vektoren.

Woher Datenlecks stammen

Böswillige und kriminelle Angriffe machten 55 % aller Datenlecks aus — ein Anstieg um 8 Prozentpunkte im Jahresvergleich — vor zwei anderen Ursachen:

• Menschliches Versagen: 23 %
• IT-Ausfälle: 22 %

Warum Lieferkettenangriffe so lange unentdeckt bleiben

Lieferkettenkompromittierungen und Wechselmedien benötigten durchschnittlich 258 Tage zur Identifizierung und Eindämmung — deutlich über dem Gesamtdurchschnitt von 247 Tagen. Beide tauchen weder zuverlässig in Malware-Scans noch im eingehenden Netzwerkverkehr auf, was die Erkennungszeit über die Norm für jeden anderen Vektor hinaus verlängert.

Warum Sprach- und SMS-Phishing mehr kosten

Phishing und Social Engineering konvergieren auf dasselbe Ziel: Zugang zu Anmeldedaten. Sprach- und SMS-Phishing kosten mehr, gerade weil ein erfolgreicher Anruf oder eine erfolgreiche SMS Angreifern oft direkten Zugang zu höherwertigen Systemen verschafft und den Malware-Bereitstellungsschritt vollständig überspringt.

Der Lebenszyklus eines Datenlecks: 247 Tage und warum sich die Uhr umkehrte

Die durchschnittliche Zeit bis zur Identifizierung und Eindämmung eines Datenlecks stieg auf 247 Tage — ein Anstieg von 2,5 %, der fünf Jahre stetiger Verbesserung umkehrte. Interne Sicherheitsteams übertreffen weiterhin den Durchschnitt und beheben Datenlecks 15 % schneller — in 209 Tagen.

Wer das Datenleck findet und wie lange es dauert

Wer das Datenleck findet, verändert den Zeitrahmen erheblich:

Die unangenehme Zahl in dieser Tabelle

Die Offenlegung durch Angreifer ist die schlechteste Entdeckungsmethode, und sie ist nicht selten. Interne Teams und MSSPs zusammen entdeckten 69 % der Datenlecks. Die Offenlegung durch Angreifer machte 17 % aus, was bedeutet, dass fast 1 von 5 betroffenen Organisationen von den Personen erfuhr, die sie angriffen.

Ransomware entwickelt sich: Von Verschlüsselung zu Reputationserpressung

Ransomware war an 39 % der Datenlecks beteiligt — ein Anstieg von 34 % im Vorjahr — wobei 41 % dieser Angriffe jetzt Drohungen zur Schädigung der Markenreputation beinhalten. Dies spiegelt eine Verschiebung von rein technischer Störung hin zu mehrschichtiger Erpressung wider, die auf Vertrauen und öffentliche Wahrnehmung abzielt.

Dateien zu verschlüsseln und eine Zahlung für einen Entschlüsselungsschlüssel zu fordern, war früher das gesamte Spielbuch. Die Drohung, ein Datenleck gegenüber Kunden, Regulierungsbehörden und der Presse öffentlich zu machen — unabhängig davon, ob die Verschlüsselung erfolgreich war — fügt einen zweiten Druckpunkt hinzu, der nicht von der Backup-Qualität abhängt. Eine Organisation mit einwandfreien Backups kann ihre Systeme in Stunden wiederherstellen und dennoch mit einer Reputationserpressungsforderung konfrontiert werden, der sie technisch nicht entkommen kann.

Sicherheits-KI und Automatisierung: Die 1,93-Millionen-Dollar-Verteidigung

Organisationen, die Sicherheits-KI und Automatisierung umfassend einsetzten, reduzierten die durchschnittlichen Kosten eines Datenlecks um 1,93 Millionen Dollar und verkürzten die Lebenszyklen von Datenlecks um 65 Tage im Vergleich zu denen ohne KI oder Automatisierung — eine Kostenreduzierung von etwa 33 %, die auch die Eindämmungszeit um fast ein Viertel verkürzt.

Eine von vier Organisationen in der Studie nutzt überhaupt keine KI oder Automatisierung in ihren Sicherheitsoperationen. Dieses Viertel der Stichprobe zahlt fast 2 Millionen Dollar mehr pro Vorfall als die Gruppe mit umfassender Nutzung — für eine Fähigkeitslücke, die lange genug existiert, um einen gut dokumentierten Return on Investment zu haben.

Das Zugriffskontroll-Desaster: 92 % der von KI betroffenen Organisationen hatten keine

Unter den Organisationen, die ein KI-bezogenes Datenleck erlebten, fehlten 92 % ordnungsgemäße KI-Zugriffskontrollen — obwohl Identity and Access Management (IAM) als zweiteffektivster Kostenreduzierer in der gesamten Studie rangiert, mit 225.622 Dollar Einsparungen pro Datenleck. Nur 40 % der Organisationen erweitern irgendwelche Zugriffskontrollen auf ihre KI-Modelle und die Daten, die diese Modelle berühren.

Top-Kostenreduzierer im Kontext

• DevSecOps-Praktiken: 253.805 Dollar Einsparung pro Datenleck, der effektivste Reduzierer in der Studie
• Identity and Access Management: 225.622 Dollar Einsparung pro Datenleck, knapp dahinter

Die Schwäche, die beide KI-Angriffstypen ausnutzen

Modellinversionsangriffe (durchschnittlich 6,07 Mio. $) und Prompt-Injection-Angriffe (durchschnittlich 5,89 Mio. $) zielen auf dieselbe zugrunde liegende Schwäche ab: Zugriff, der von Anfang an nie eng genug eingeschränkt war. Keiner der beiden Angriffe erfordert das Brechen von Verschlüsselung oder das Umgehen einer Firewall. Beide benötigen nur ein Modell — oder einen Prompt-Pfad dorthin — mit größerer Reichweite als die Aufgabe erfordert.

Warum dies über KI-Systeme hinaus wichtig ist

Hier werden grundlegende Identity-Praktiken kritisch. Für ein Sicherheitsteam, das Tausende von Anmeldedaten über On-Prem-Systeme, Cloud-Dienste und SaaS-Tools verwaltet, ist die IAM-Einsparungszahl nicht abstrakt. Es ist der Unterschied zwischen einem 247-Tage-Lebenszyklus eines Datenlecks und einem 209-Tage-Lebenszyklus.

Sicherheitsteams, die Anmeldedaten über menschliche und nicht-menschliche Identitäten verwalten — einschließlich API-Schlüssel, Service-Konten und KI-Agenten-Anmeldedaten — benötigen zentralisierte Zugriffsgovernance mit Rotation, Auditing und rollenbasierten Kontrollen, um die Lücke zu schließen, die 92 % der betroffenen Organisationen offen gelassen haben.

Shadow-KI, nicht-menschliche Identitäten und Post-Quanten: Die drei aufkommenden Bedrohungen

Drei erstmalige Erkenntnisse aus 2026 definieren den vorausschauenden Abschnitt des Berichts: Shadow-KI-Vorfälle verdoppeln sich, die Sicherheit nicht-menschlicher Identitäten hinkt der KI-Adoption hinterher, und die Post-Quanten-Kryptografie-Bereitschaft ist weiterhin selten.

Shadow-KI

Shadow-KI — also KI-Tools, die Mitarbeiter ohne Sicherheitsgenehmigung einsetzen — machte 2026 43 % der KI-bezogenen Vorfälle aus, mehr als das Doppelte der im Vorjahr verzeichneten 20 %. Etwa einer von fünf dieser Vorfälle führte zu einer regulatorischen Strafe, und nur etwa ein Drittel der Organisationen setzt strenge Genehmigungsprozesse für die interne Bereitstellung von KI-Tools durch.

Nicht-menschliche Identitäten

Weniger als die Hälfte der Organisationen (46 %) gibt an, nicht-menschliche Identitäten wie API-Schlüssel, Service-Konten und Maschinenanmeldedaten innerhalb ihrer KI-Workflows zu sichern, was eine wachsende Angriffsfläche schafft, während KI-Agenten sich in Unternehmensumgebungen ausbreiten.

Von diesen 46 % wenden 55 % Maschinenidentitäts-Lifecycle-Management an, 39 % nutzen dediziertes Secrets Management, 36 % führen Verhaltensüberwachung für nicht-menschliche Konten durch, und 30 % wenden speziell für diese rollenbasierte Zugriffskontrolle an.

Post-Quanten-Kryptografie

Nur 26 % der betroffenen Organisationen haben ein Post-Quanten-Kryptografie-Projekt laufen, und 61 % fehlen Kontrollen zur Überwachung und Sicherung kryptografischer Assets insgesamt, was sie „Harvest Now, Decrypt Later"-Angriffen aussetzt, während die Quantencomputing-Fähigkeiten voranschreiten. Heute verschlüsseln nur 37 % sensible Daten umfassend im Ruhezustand und bei der Übertragung — eine grundlegende Lücke, die jeder Quantenbedenken vorausgeht.

IBMs vier Empfehlungen — übersetzt in Maßnahmen

IBMs Empfehlungen konzentrieren sich auf einen Imperativ: Die Lücke zwischen KI-beschleunigten Angriffen und Verteidigung in menschlicher Geschwindigkeit zu schließen — durch den Einsatz agentischer KI für das Schwachstellenmanagement, die Verlagerung von Identity auf kontinuierliche Verifizierung, die Etablierung von KI-Souveränität und den Beginn des Übergangs zur Post-Quanten-Kryptografie.

1. Sicherheit mit der Geschwindigkeit von Angriffen betreiben. IBM formuliert dies als Schließung der Reaktionszeitlücke. In der Praxis bedeutet dies, in diesem Quartal mindestens einen KI-Agenten für Schwachstellen-Scanning in Ihrer CI/CD-Pipeline einzusetzen, nicht nur für die Bedrohungserkennung.
2. Identity Security auf kontinuierliche, Laufzeit-Verifizierung umstellen. Dies wendet Zero-Trust-Prinzipien auf Maschinen ebenso wie auf Menschen an. Beginnen Sie damit, jede nicht-menschliche Identität zu auditieren, die einen KI-Workflow berührt, und bewegen Sie sich in Richtung Just-in-Time-Zugriff anstelle von dauerhaften Anmeldedaten.
3. KI-Kontrolle durch KI-Souveränität stärken. IBMs Sprache umfasst umfassende Sicherheit über Daten, Anwendungen, Identitäten und Cloud hinweg. Der erste konkrete Schritt ist, jeden Ort zu kartieren, an dem ein KI-Modell sensible Daten berührt, und dort speziell Zugriffskontrollen anzuwenden.
4. Auf Post-Quanten-Sicherheitsrisiken vorbereiten. Da 61 % der Organisationen grundlegende kryptografische Asset-Kontrollen fehlen, ist der Ausgangspunkt eine Inventur: Welche Systeme verlassen sich noch auf RSA oder ECC, und welche davon schützen Daten mit langer Vertraulichkeitsdauer.

Was das für Ihr Team bedeutet

Der Bericht von IBM aus dem Jahr 2026 beschreibt asymmetrische Beschleunigung. Angreifer übernehmen KI schneller in den Bereichen, die am meisten schaden, während Verteidiger ihre besten Tools überall einsetzen — außer an der Eingangstür. Die 18 %-Schwachstellenlücke, die 92 %-Zugriffskontroll-Ausfallrate und die 85 %-Erkenntnis weisen alle auf dieselbe Schlussfolgerung hin: Die Gleichung der Datenleck-Ökonomie hat sich verschoben, und Geschwindigkeit ist jetzt die Variable, die das Ergebnis entscheidet.

Für Sicherheitsteams bleibt Identity das Schlachtfeld. Da IAM als zweiteffektivster Kostenreduzierer rangiert und 92 % der von KI betroffenen Organisationen Zugriffskontrollen fehlten, ist zentralisiertes Credential Management für menschliche und nicht-menschliche Identitäten ein direkter finanzieller Hebel.

Passwork bietet Enterprise-Teams rollenbasierte Zugriffskontrolle, automatisierte Credential-Rotation und auditierte Tresor-Zugriffe — die Art von Identity Governance, die genau die Lücken schließt, die dieser Bericht quantifiziert.

Wenn Ihre Organisation privilegierte Anmeldedaten immer noch über Tabellenkalkulationen, gemeinsam genutzte Konten oder API-Schlüssel verwaltet, die seit einem Jahr niemand rotiert hat, läuft die 1.100-Dollar-pro-Stunde-Datenleck-Uhr bereits irgendwo in Ihrer Umgebung.

Häufig gestellte Fragen

Shadow-KI: Die versteckte Bedrohung, die Unternehmen 670.000 $ pro Datenleck kostet

Shadow-KI kostet Unternehmen 670.000 $ extra pro Datenleck — und das meiste davon geht auf Anmeldedaten zurück, die in öffentliche LLMs eingefügt wurden. Erfahren Sie, wie Shadow-KI tatsächlich aussieht, warum sie schwerer zu stoppen ist als Shadow-IT, und wie man sie regelt.

Passwork BlogAlex Muntyan

Warum Passwortkomplexitätsregeln tot sind (und was stattdessen verwendet werden sollte)

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

PassworkPasswork Team

Passwork gewinnt Top Performer Sommer 2026 auf SourceForge

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

PassworkPasswork Team

Una filtración de datos ahora cuesta $1,100 por cada hora que permanece sin resolver. En 2026, las filtraciones tardaron un promedio de 247 días en contenerse — sumando un récord de $4.99 millones por incidente. Según el Informe del costo de una filtración de datos 2026 de IBM, producido con el Ponemon Institute a partir de 602 organizaciones afectadas en 16 países, los datos de este año revelan un tema crítico: la IA se ha convertido en el factor decisivo en la economía de las filtraciones.

Los atacantes que usan IA ahora representan 1 de cada 4 filtraciones maliciosas (+56% interanual). Los defensores que usan IA extensivamente ahorran $1.93 millones por incidente. Ambas afirmaciones son ciertas simultáneamente, y la brecha entre ellas es la verdadera historia. Este artículo traduce las cifras principales del informe en decisiones que un CISO puede llevar a una reunión de presupuesto, no solo un resumen de los hallazgos.

¿Qué es el Informe del costo de una filtración de datos 2026 de IBM?

El Informe del costo de una filtración de datos 2026 de IBM es la 21ª edición anual del estudio insignia de economía de filtraciones de IBM. Se basa en entrevistas con 602 organizaciones en 16 países y 17 industrias que experimentaron una filtración entre marzo de 2025 y febrero de 2026, más un estudio de seguimiento en mayo de 2026 con 456 de esos mismos encuestados.

Una advertencia que vale la pena mencionar desde el principio: la muestra no es estadística, por lo que los márgenes de error no se aplican en el sentido tradicional, y tiende hacia organizaciones con programas de seguridad más maduros dispuestas a participar. Trate las cifras como referencias direccionales para la planificación, no como predicciones actuariales para su organización específica.

¿Qué hay de nuevo en el Informe del costo de una filtración de datos 2026 de IBM?

La edición de este año es la primera en medir el despliegue de IA agéntica dentro de los centros de operaciones de seguridad (SOC), la primera en rastrear la preparación para criptografía poscuántica, y la primera construida sobre un estudio de seguimiento desencadenado por un evento de amenaza de IA en vivo.

Las entrevistas originales se cerraron en febrero de 2026. Dos meses después, la vista previa de Claude Mythos de Anthropic cambió la percepción de amenazas. IBM y Ponemon encuestaron a 456 encuestados originales en mayo de 2026 con una pregunta directa: ¿esto cambió sus planes de gasto?

La respuesta produjo lo que este artículo llama el ajuste de cuentas del 85%: una filtración real convenció al 64% de las organizaciones de aumentar el gasto en seguridad, pero la noticia de las capacidades de un modelo de IA de frontera convenció al 85%. El miedo a una amenaza futura superó el recuerdo de un incidente real.

Cuatro otras primicias definen el año:

• El tiempo medio para identificar y contener (MTTI/MTTC) aumentó después de cinco años consecutivos de mejora.
• Los incidentes de Shadow AI se duplicaron al 43% de todos los incidentes relacionados con IA.
• Una cuarta parte de las organizaciones todavía no usa ninguna IA o automatización en seguridad.
• El informe mide, por primera vez, exactamente qué funciones del SOC asignan las organizaciones a los agentes de IA. Ese desglose es lo que este artículo llama la brecha del 18% en vulnerabilidades, cubierta más adelante.

La filtración de $4.99 millones: Los costos globales alcanzan un récord

El costo promedio global de una filtración de datos alcanzó un máximo histórico de $4.99 millones en 2026, un aumento del 12% impulsado principalmente por los gastos de detección y escalamiento y los costos de pérdida de negocio, que juntos representaron el 63% del total. Las multas regulatorias, la partida en la que más se fijan los consejos de administración, tienen menos peso en el total que la informática forense, la gestión de crisis, el tiempo de inactividad y la pérdida de clientes combinados.

Después de bajar a $4.44M en 2025, los costos se dispararon a $4.99M en 2026, borrando un año de progreso y alcanzando un nuevo récord.

La duración de la filtración aumenta el costo directamente. Los incidentes que tardaron más de 200 días en resolverse costaron a las organizaciones $5.65 millones en promedio, en comparación con $4.32 millones para las filtraciones contenidas más rápido.

País por país: Dónde cuestan más las filtraciones

Estados Unidos rompió su propio récord con un costo promedio de filtración de $11.5 millones, más del doble del promedio global y un aumento del 11% respecto al año pasado, impulsado por mayores multas regulatorias y costos de interrupción del negocio. Ningún otro país se acerca a la cifra de EE. UU., pero la distribución regional cuenta su propia historia.

Sudáfrica registró el mayor aumento porcentual en el estudio con un 22%, aunque su costo absoluto permanece por debajo del promedio global. Esa combinación — una base baja que crece rápidamente — generalmente indica un mercado donde el gasto en seguridad no ha seguido el ritmo de la digitalización (no uno donde las filtraciones se hayan vuelto particularmente graves). Benelux, por el contrario, ya se encuentra entre los costos por incidente más altos a nivel mundial y aún creció un 16%.

Los ataques impulsados por IA aumentan un 56%: Los números detrás del titular

Los ataques impulsados por IA ahora representan más de 1 de cada 4 filtraciones maliciosas, un aumento del 56% respecto al año pasado, y añaden aproximadamente $1 millón al costo promedio de una filtración, llevando los incidentes habilitados por IA a $6.04 millones.

Desglose por tipo de ataque

Desglose los tipos de ataque y emerge un patrón claro. Los atacantes están automatizando los pasos de ingeniería social y desarrollo de malware que antes requerían tiempo humano calificado.

• Suplantación de identidad con deepfake de IA: 45% de los ataques habilitados por IA, la categoría individual más grande
• Malware generado por IA: 19%
• Phishing u otras comunicaciones generadas por IA: 17%

Concentración en infraestructura crítica

La infraestructura crítica absorbió el daño concentrado: el 62% de los ataques impulsados por IA en el estudio afectaron a estos sectores, con los servicios financieros ($6.29M en promedio) y energía ($5.24M en promedio) llevando la mayor parte.

Ataques a los propios sistemas de IA

Los atacantes también están atacando directamente los sistemas de IA, y ambas cifras a continuación están por encima del promedio global de todas las causas, lo que indica que ya no son curiosidades marginales.

• Ataques de inversión de modelos de IA (un adversario reconstruye datos de entrenamiento sensibles a partir de un modelo desplegado): $6.07M en promedio
• Ataques de inyección de prompts (una entrada maliciosa manipula el comportamiento de un modelo): $5.89M en promedio

La brecha del 18%: Dónde los defensores están perdiendo la carrera armamentista de IA

La mitad de las organizaciones afectadas desplegaron agentes de IA en sus SOC, pero solo el 18% los dirigió a la gestión de vulnerabilidades. Esta es la brecha del 18% en vulnerabilidades: los defensores despliegan IA en todas partes excepto donde los atacantes entran.

Dónde van realmente los agentes del SOC

La mayor parte del despliegue de agentes del SOC se agrupó en torno a la detección y respuesta, no en la puerta principal que usan los atacantes:

• Caza de amenazas: 56%
• Respuesta y contención: 54%
• Escaneo y gestión de vulnerabilidades: 18%

La gestión de vulnerabilidades, el trabajo poco glamoroso de encontrar y cerrar los agujeros por los que entran los atacantes, recibió la menor atención a pesar de ser exactamente donde los modelos de IA de frontera amenazan con cambiar la ecuación más rápidamente.

Por qué la brecha es peligrosa ahora

En abril de 2026, Anthropic presentó Claude Mythos, un modelo de frontera que identificó miles de vulnerabilidades de alta gravedad en los principales sistemas operativos y navegadores durante las pruebas. La investigación del Frontier Red Team de Anthropic estimó el costo de desarrollar un exploit funcional a partir de una vulnerabilidad descubierta en menos de $1,000 a $2,000, lograble en menos de un día.

La industria ya está reaccionando

Los propios encuestados de IBM reconocieron el desajuste después del hecho, tras el anuncio de Mythos:

• El 74% de las organizaciones dijeron que habían reconsiderado su estrategia de despliegue de agentes de IA en el SOC
• El uso planificado de agentes para gestión de vulnerabilidades aumentó del 18% hacia el 37% en intención declarada

Desglose por industria: Sanidad, finanzas y los mayores cambios

Sanidad siguió siendo la industria más costosa para las filtraciones de datos por decimotercer año consecutivo con $6.64 millones, aunque fue el único sector que vio disminuir los costos, bajando un 10.5% desde $7.42 millones en 2025.

Comunicaciones registró el aumento más pronunciado de todo el estudio con un 20%, seguido de entretenimiento con un 18%. Los servicios financieros subieron un 13% hasta $6.29 millones, continuando un aumento de varios años que ha cerrado la mayor parte de la brecha con sanidad. La información personal de clientes apareció en el 52% de las filtraciones, con un promedio de $192 por registro. El robo de propiedad intelectual fue menos frecuente, 32% de las filtraciones, pero fue el tipo de datos más costoso por registro con $196.

Cómo entran los atacantes: Phishing, cadenas de suministro e ingeniería social

El phishing, incluyendo variantes basadas en voz y SMS, siguió siendo el principal vector de ataque inicial por cuarto año consecutivo, involucrado en el 17% de las filtraciones y costando un promedio de $5.29 millones, el más alto entre todos los vectores.

Dónde se originan las filtraciones

Los ataques maliciosos y criminales representaron el 55% de todas las filtraciones, un aumento de 8 puntos interanual, por delante de otras dos causas:

• Error humano: 23%
• Fallos de TI: 22%

Por qué los ataques a la cadena de suministro tardan tanto en detectarse

El compromiso de la cadena de suministro y los medios extraíbles tardaron un promedio de 258 días en identificarse y contenerse, muy por encima del promedio general de 247 días. Ninguno de los dos aparece de forma fiable en los escaneos de malware o el tráfico de red entrante, lo que prolonga el tiempo de detección más allá de la norma para cualquier otro vector.

Por qué el phishing por voz y SMS cuesta más

El phishing y la ingeniería social están convergiendo en el mismo objetivo: el acceso a credenciales. El phishing por voz y SMS cuesta más precisamente porque una llamada o mensaje de texto exitoso a menudo otorga a los atacantes acceso directo a sistemas de mayor valor, saltándose completamente el paso de entrega de malware.

El ciclo de vida de la filtración: 247 días, y por qué el reloj se invirtió

El tiempo medio para identificar y contener una filtración de datos aumentó a 247 días, un incremento del 2.5% que revirtió cinco años de mejora constante. Los equipos de seguridad internos aún superan el promedio, resolviendo las filtraciones un 15% más rápido, en 209 días.

Quién encuentra la filtración y cuánto tarda

Quién encuentra la filtración cambia sustancialmente el cronograma:

El número incómodo en esa tabla

La divulgación por el atacante es el peor método de descubrimiento, y no es raro. Los equipos internos y los MSSP juntos detectaron el 69% de las filtraciones. La divulgación por el atacante representó el 17%, lo que significa que casi 1 de cada 5 organizaciones afectadas se enteraron por las personas que las estaban atacando.

El ransomware evoluciona: Del cifrado a la extorsión reputacional

El ransomware estuvo involucrado en el 39% de las filtraciones de datos, frente al 34% del año pasado, con el 41% de esos ataques incluyendo ahora amenazas de dañar la reputación de la marca, reflejando un cambio de la interrupción puramente técnica hacia una extorsión multicapa que ataca la confianza y la percepción pública.

Cifrar archivos y exigir un pago por una clave de descifrado solía ser todo el manual de juego. Amenazar con publicar una filtración a clientes, reguladores y la prensa, independientemente de si el cifrado tuvo éxito, añade un segundo punto de presión que no depende de la calidad de las copias de seguridad. Una organización con copias de seguridad impecables puede restaurar sus sistemas en horas y aún enfrentarse a una demanda de extorsión reputacional de la que no puede escapar mediante ingeniería.

IA y automatización de seguridad: La defensa de $1.93 millones

Las organizaciones que desplegaron extensivamente IA y automatización de seguridad redujeron los costos promedio de filtración en $1.93 millones y acortaron los ciclos de vida de las filtraciones en 65 días en comparación con aquellas que no usan IA o automatización, una reducción de costos de aproximadamente el 33% que también recorta el tiempo de contención en casi una cuarta parte.

Una de cada cuatro organizaciones en el estudio todavía no usa ninguna IA o automatización en sus operaciones de seguridad. Esa cuarta parte de la muestra está pagando casi $2 millones más por incidente que el grupo de uso extensivo, por una brecha de capacidad que ha existido el tiempo suficiente para tener un retorno de inversión bien documentado.

El desastre del control de acceso: El 92% de las organizaciones afectadas por IA no tenía ninguno

Entre las organizaciones que experimentaron una filtración relacionada con IA, el 92% carecía de controles de acceso de IA adecuados, a pesar de que la gestión de identidades y accesos (IAM) ocupa el segundo lugar como reductor de costos más efectivo en todo el estudio, con $225,622 ahorrados por filtración. Solo el 40% de las organizaciones extienden algún control de acceso a sus modelos de IA y los datos que tocan esos modelos.

Principales reductores de costos, para contexto

• Prácticas de DevSecOps: $253,805 ahorrados por filtración, el reductor más efectivo en el estudio
• Gestión de identidades y accesos: $225,622 ahorrados por filtración, muy cerca

La debilidad que explotan ambos tipos de ataques de IA

Los ataques de inversión de modelos ($6.07M en promedio) y los ataques de inyección de prompts ($5.89M en promedio) apuntan a la misma debilidad subyacente: acceso que nunca se delimitó lo suficientemente estricto en primer lugar. Ningún ataque requiere romper el cifrado o eludir un firewall. Ambos solo necesitan un modelo, o una ruta de prompt hacia él, con mayor alcance del que requiere la tarea.

Por qué esto importa más allá de los sistemas de IA

Aquí es donde las prácticas fundamentales de identidad se vuelven críticas. Para un equipo de seguridad que gestiona miles de credenciales en sistemas locales, servicios en la nube y herramientas SaaS, la cifra de ahorro de IAM no es abstracta. Es la diferencia entre un ciclo de vida de filtración de 247 días y uno de 209 días.

Los equipos de seguridad que gestionan credenciales tanto de identidades humanas como no humanas, incluyendo claves API, cuentas de servicio y credenciales de agentes de IA, necesitan gobernanza de acceso centralizada con rotación, auditoría y controles basados en roles para cerrar la brecha que el 92% de las organizaciones afectadas dejaron abierta.

Shadow AI, identidades no humanas y poscuántica: Las tres amenazas emergentes

Tres hallazgos que son primicia en 2026 definen la sección prospectiva del informe: los incidentes de Shadow AI duplicándose, la seguridad de identidades no humanas rezagada respecto a la adopción de IA, y la preparación para criptografía poscuántica siendo todavía rara.

Shadow AI

Shadow AI, es decir, herramientas de IA que los empleados adoptan sin aprobación de seguridad, representó el 43% de los incidentes relacionados con IA en 2026, más del doble del 20% registrado el año anterior. Aproximadamente uno de cada cinco de estos incidentes resultó en una multa regulatoria, y solo alrededor de un tercio de las organizaciones aplican procesos de aprobación estrictos para desplegar herramientas de IA internamente.

Identidades no humanas

Menos de la mitad de las organizaciones (46%) informan que aseguran identidades no humanas como claves API, cuentas de servicio y credenciales de máquinas dentro de sus flujos de trabajo de IA, creando una superficie de ataque en expansión a medida que los agentes de IA proliferan en los entornos empresariales.

De ese 46%, el 55% aplica gestión del ciclo de vida de identidades de máquinas, el 39% usa gestión de secretos dedicada, el 36% ejecuta monitorización de comportamiento en cuentas no humanas, y el 30% aplica control de acceso basado en roles específicamente a ellas.

Criptografía poscuántica

Solo el 26% de las organizaciones afectadas tiene un proyecto de criptografía poscuántica en marcha, y el 61% carece de controles para monitorizar y asegurar activos criptográficos en absoluto, dejándolas expuestas a ataques de «recoger ahora, descifrar después» a medida que avanza la capacidad de computación cuántica. Solo el 37% cifra de manera integral los datos sensibles en reposo y en tránsito hoy, una brecha de línea base que precede a cualquier preocupación cuántica.

Las cuatro recomendaciones de IBM, traducidas para la acción

Las recomendaciones de IBM se centran en un imperativo: cerrar la brecha entre los ataques acelerados por IA y la defensa a velocidad humana desplegando IA agéntica en la gestión de vulnerabilidades, cambiando la identidad a verificación continua, estableciendo soberanía de IA, y comenzando la transición a criptografía poscuántica.

1. Operar la seguridad a la velocidad del ataque. IBM enmarca esto como cerrar la brecha de tiempo de reacción. En la práctica, significa desplegar al menos un agente de IA para escaneo de vulnerabilidades en su pipeline CI/CD este trimestre, no solo para detección de amenazas.
2. Cambiar la seguridad de identidad a verificación continua en tiempo de ejecución. Esto aplica los principios de confianza cero tanto a máquinas como a humanos. Comience auditando cada identidad no humana que toca un flujo de trabajo de IA y avance hacia el acceso justo a tiempo en lugar de credenciales permanentes.
3. Fortalecer el control de IA a través de la soberanía de IA. El lenguaje de IBM cubre seguridad integral en datos, aplicaciones, identidades y nube. El primer paso concreto es mapear cada lugar donde un modelo de IA toca datos sensibles y aplicar controles de acceso específicamente allí.
4. Prepararse para el riesgo de seguridad poscuántica. Con el 61% de las organizaciones sin controles básicos de activos criptográficos, el punto de partida es un inventario: qué sistemas todavía dependen de RSA o ECC, y cuáles de ellos protegen datos con una vida útil de confidencialidad prolongada.

Qué significa esto para su equipo

El informe 2026 de IBM describe una aceleración asimétrica. Los atacantes están adoptando la IA más rápido en las áreas que más duelen, mientras los defensores despliegan sus mejores herramientas en todas partes excepto en la puerta principal. La brecha del 18% en vulnerabilidades, la tasa de fallo del 92% en control de acceso, y el ajuste de cuentas del 85% apuntan todos a la misma conclusión: la ecuación económica de las filtraciones ha cambiado, y la velocidad es ahora la variable que decide el resultado.

Para los equipos de seguridad, la identidad sigue siendo el campo de batalla. Con IAM ocupando el segundo lugar como reductor de costos más efectivo y el 92% de las organizaciones afectadas por IA sin controles de acceso, la gestión centralizada de credenciales para identidades humanas y no humanas es una palanca financiera directa.

Passwork proporciona a los equipos empresariales control de acceso basado en roles, rotación automatizada de credenciales y acceso auditado a bóvedas — el tipo de gobernanza de identidad que cierra las brechas específicas que este informe cuantifica.

Si su organización todavía gestiona credenciales privilegiadas a través de hojas de cálculo, cuentas compartidas o claves API que nadie ha rotado en un año, el reloj de filtración de $1,100 por hora ya está corriendo en algún lugar de su entorno.

Preguntas frecuentes

Shadow AI: La amenaza oculta que cuesta a las empresas $670K por filtración

Shadow AI cuesta a las empresas $670K extra por filtración — y la mayor parte se remonta a credenciales pegadas en LLM públicos. Descubra cómo es realmente Shadow AI, por qué es más difícil de detener que Shadow IT, y cómo gobernarlo.

Passwork BlogAlex Muntyan

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

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

PassworkPasswork Team

Passwork gana Top Performer Verano 2026 en SourceForge

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

PassworkPasswork Team

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

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

What is the IBM Cost of a Data Breach Report 2026

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

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

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

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

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

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

Four other firsts define the year:

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

The $4.99 million breach: Global costs hit a record

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

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

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

Country by country: Where breaches cost the most

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

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

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

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

Attack type breakdown

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

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

Critical infrastructure concentration

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

Attacks on AI systems themselves

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

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

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

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

Where SOC agents actually go

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

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

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

Why the gap is dangerous now

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

The industry is already reacting

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

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

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

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

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

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

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

Where breaches originate

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

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

Why supply chain attacks take so long to catch

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

Why voice and SMS phishing cost more

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

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

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

Who finds the breach, and how long it takes

Who finds the breach changes the timeline substantially:

The uncomfortable number in that table

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

Ransomware evolves: From encryption to reputation extortion

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

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

Security AI and automation: The $1.93 million defense

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

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

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

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

Top cost reducers, for context

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

The weakness both AI attack types exploit

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

Why this matters beyond AI systems

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

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

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

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

Shadow AI

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

Non-human identities

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

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

Post-quantum cryptography

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

IBM's four recommendations, translated for action

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

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

What this means for your team

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

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

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

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

Frequently asked questions

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

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

Passwork BlogAlex Muntyan

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

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

PassworkPasswork Team

Passwork wins Top Performer Summer 2026 on SourceForge

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

PassworkPasswork Team

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

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

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

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

Bedrohungen und Angriffe: Vorfälle des Monats

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

Claude kompromittierte drei Unternehmen während interner Tests

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

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

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

Quelle: Anthropic — 31. Juli 2026 

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

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

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

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

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

Quelle: Hugging Face Blog — 16. Juli 2026

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

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

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

Quelle: BleepingComputer — 27. Juli 2026 

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

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

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

Quelle: Help Net Security — 20. Juli 2026 

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

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

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

Quelle: CybersecurityDive — 10. Juli 2026 

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

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

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

Quelle: eSecurityPlanet — 22. Juli 2026 

Credential Stuffing gegen SonicWall-VPN kompromittiert 92 Konten

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

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

Quelle: CyberScoop — 28. Juli 2026 

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

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

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

Quelle: Cloud Security Alliance — 16. Juli 2026 

Schwachstellen: Patches und dringende Fixes

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

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

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

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

Quelle: CISA — 29. Juli 2026

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

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

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

Quelle: The Hacker News — 19. Juli 2026 

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

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

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

Quelle: The Hacker News — 23. Juli 2026

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

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

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

Quelle: Orca.security — 15. Juli 2026

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

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

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

Quelle: CISA KEV Alert — 28. Juli 2026 

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

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

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

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

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

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

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

Quelle: The Hacker News — 13. Juli 2026 

Authentifizierung und Zugriffsmanagement: Trends und Strategie

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

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

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

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

Quelle: Microsoft Security Blog — 13. Juli 2026 

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

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

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

Quelle: Infopoint Security — 15. Juli 2026 

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

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

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

Quelle: Help Net Security — 30. Juli 2026 

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

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

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

Quelle: IBM Security — 29. Juli 2026 

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

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

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

Quelle: Identity Theft Resource Center — 24. Juli 2026 

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

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

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

Quelle: Wyden Senate — 27. Juli 2026 

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

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

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

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

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

Quelle: Europäische Kommission — 8. Juli 2026

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

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

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

Quelle: Europäische Kommission — Juli 2026 

Zusammenfassung dieses Monats

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

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

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

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

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

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

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

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

Passwork BlogAlex Muntyan

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

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

PassworkPasswork Team

Passwork gewinnt Top Performer Sommer 2026 auf SourceForge

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

PassworkPasswork Team

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

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

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

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

Amenazas y ataques: Incidentes del mes

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

Claude vulneró tres empresas durante pruebas internas

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

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

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

Fuente: Anthropic – 31 de julio de 2026 

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

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

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

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

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

Fuente: Hugging Face Blog – 16 de julio de 2026

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

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

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

Fuente: BleepingComputer – 27 de julio de 2026 

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

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

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

Fuente: Help Net Security – 20 de julio de 2026 

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

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

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

Fuente: CybersecurityDive – 10 de julio de 2026 

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

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

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

Fuente: eSecurityPlanet – 22 de julio de 2026 

Credential stuffing contra SonicWall VPN compromete 92 cuentas

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

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

Fuente: CyberScoop – 28 de julio de 2026 

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

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

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

Fuente: Cloud Security Alliance – 16 de julio de 2026 

Vulnerabilidades: Parches y correcciones urgentes

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

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

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

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

Fuente: CISA – 29 de julio de 2026

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

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

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

Fuente: The Hacker News – 19 de julio de 2026 

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

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

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

Fuente: The Hacker News – 23 de julio de 2026

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

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

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

Fuente: Orca.security – 15 de julio de 2026

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

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

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

Fuente: Alerta CISA KEV – 28 de julio de 2026 

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

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

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

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

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

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

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

Fuente: The Hacker News – 13 de julio de 2026 

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

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

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

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

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

Fuente: Microsoft Security Blog – 13 de julio de 2026 

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

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

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

Fuente: Infopoint Security – 15 de julio de 2026 

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

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

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

Fuente: Help Net Security – 30 de julio de 2026 

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

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

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

Fuente: IBM Security – 29 de julio de 2026 

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

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

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

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

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

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

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

Fuente: Wyden Senate – 27 de julio de 2026 

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

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

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

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

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

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

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

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

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

Fuente: Comisión Europea – Julio de 2026 

Resumen del mes

Los eventos de julio se remontan a dos patrones.

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

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

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

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

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

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

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

Passwork BlogAlex Muntyan

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

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

PassworkPasswork Team

Passwork gana Top Performer Verano 2026 en SourceForge

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

PassworkPasswork Team

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

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

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

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

Threats and attacks: Incidents of the month

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

Claude breached three companies during internal tests

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

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

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

Source: Anthropic – July 31, 2026 

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

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

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

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

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

Source: Hugging Face Blog – July 16, 2026

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

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

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

Source: BleepingComputer – July 27, 2026 

Paidwork breach exposes 23.3 million users in Poland

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

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

Source: Help Net Security – July 20, 2026 

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

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

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

Source: CybersecurityDive – July 10, 2026 

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

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

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

Source: eSecurityPlanet – July 22, 2026 

Credential stuffing against SonicWall VPN compromises 92 accounts

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

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

Source: CyberScoop – July 28, 2026 

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

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

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

Source: Cloud Security Alliance – July 16, 2026 

Vulnerabilities: Patches and urgent fixes

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

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

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

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

Source: CISA – July 29, 2026

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

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

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

Source: The Hacker News – July 19, 2026 

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

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

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

Source: The Hacker News – July 23, 2026

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

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

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

Source: Orca.security – July 15, 2026

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

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

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

Source: CISA KEV Alert – July 28, 2026 

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

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

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

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

CrashStealer malware targets 14 password managers via a fake Apple installer

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

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

Source: The Hacker News – July 13, 2026 

Authentication and access management: trends and strategy

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

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

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

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

Source: Microsoft Security Blog – July 13, 2026 

Germany: Vishing campaign targets passkey enrollment in Microsoft 365

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

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

Source: Infopoint Security – July 15, 2026 

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

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

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

Source: Help Net Security – July 30, 2026 

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

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

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

Source: IBM Security – July 29, 2026 

ITRC: H1 2026 breach notifications already exceed all of 2025

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

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

Source: Identity Theft Resource Center – July 24, 2026 

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

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

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

Source: Wyden Senate – July 27, 2026 

EU regulation and standards: what's changing in Europe

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

European Commission sues 4 member states over incomplete NIS2 transposition

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

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

Source: European Commission – July 8, 2026

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

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

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

Source: European Commission – July 2026 

This month's recap

July's events trace back to two patterns.

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

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

Post-breach credential checklist (3 points):

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

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

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

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

Passwork BlogAlex Muntyan

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

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

PassworkPasswork Team

Passwork wins Top Performer Summer 2026 on SourceForge

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

PassworkPasswork Team

Passwortkomplexität ist eine Richtlinienregel, die verlangt, dass ein Passwort verschiedene Zeichentypen (Großbuchstaben, Kleinbuchstaben, Ziffern und Symbole) kombiniert — in der Annahme, dass mehr Zeichenvielfalt höhere Entropie und stärkeren Schutz gegen das Erraten von Passwörtern erzeugt.

P@ssw0rd123! erfüllt wahrscheinlich jede Komplexitätsregel, die Ihre Gruppenrichtlinie vorschreibt. Trotzdem benötigt ein modernes GPU-System nur etwa 2 Sekunden, um es zu knacken, da das dahinterliegende Muster zu den ersten gehört, die jedes Cracking-Wörterbuch ausprobiert.

Das ist das Kernproblem. Komplexitätsregeln wurden entwickelt, um die Entropie zu erhöhen, aber Benutzer sind stattdessen auf vorhersehbare Ersetzungen ausgewichen, haben Passwörter aufgeschrieben und dieselben Anmeldedaten über ein Dutzend Dienste hinweg wiederverwendet. Im Jahr 2024 hat NIST die Komplexitätsvorgaben in SP 800-63B-4 offiziell aufgegeben. Hier erfahren Sie, warum — und was sie ersetzt.

Was sind Passwortkomplexitätsregeln

Passwortkomplexitätsregeln sind Richtlinienanforderungen, die ein Passwort dazu zwingen, verschiedene Zeichentypen zu kombinieren — typischerweise mindestens einen Großbuchstaben, einen Kleinbuchstaben, eine Ziffer und ein Symbol — in der Annahme, dass mehr Zeichenvielfalt höhere Entropie und stärkeren Schutz gegen Rateangriffe erzeugt.

Diese Regeln wurden in den 2000er und 2010er Jahren zum Standard in der Unternehmens-IT, meist in Kombination mit einer Mindestlänge von 8 Zeichen und einer obligatorischen Rotation alle 60 bis 90 Tage. Die Standard-Passwortrichtlinie von Active Directory wird immer noch mit aktivierten Zusammensetzungsanforderungen ausgeliefert, und die meisten Compliance-Checklisten aus dieser Ära gingen davon aus, dass Komplexität und Rotation die Basis für Kontosicherheit bilden.

Die Annahme hinter der Regel war theoretisch fundiert: Ein größerer Zeichensatz pro Position bedeutet mehr mögliche Kombinationen, was eine längere Brute-Force-Suche bedeutet. In der Praxis interagiert die Regel mit dem menschlichen Verhalten auf eine Weise, die ihr eigenes Ziel untergräbt — das Thema des nächsten Abschnitts.

Was NIST geändert hat — und warum es wichtig ist

NIST SP 800-63B-4 streicht die obligatorischen Zeichenzusammensetzungsregeln und periodischen Passwort-Resets und begründet dies damit, dass beide Praktiken die reale Sicherheit eher verschlechtern als verbessern. Das Update ersetzt vorschreibende Komplexität durch längenbasierte Anforderungen und Breach-Screening.

Die Begründung findet sich in Anhang A der Publikation: Zusammensetzungsregeln treiben Benutzer zu vorhersehbaren, formelhaften Passwörtern, während erzwungene Rotation dazu führt, dass Personen triviale Änderungen vornehmen (Summer2025! wird zu Summer2026!) oder alte Passwörter mit einer angehängten Ziffer wiederverwenden. Keines dieser Verhaltensweisen erhöht den Schutz gegen Erraten oder Knacken.

„Forschungen haben gezeigt, dass Benutzer auf sehr vorhersehbare Weise auf die Anforderungen reagieren, die durch Zusammensetzungsregeln (Richtlinien) auferlegt werden. Beispielsweise würde ein Benutzer, der vielleicht „password" als Passwort gewählt hätte, relativ wahrscheinlich „Password1" wählen, wenn ein Großbuchstabe und eine Zahl erforderlich sind, oder „Password1!", wenn zusätzlich ein Symbol verlangt wird." — NIST SP 800-63B-4

Hier die Änderung in der Praxis:

• Zeichenzusammensetzung: 
  • Alt — Großbuchstaben, Kleinbuchstaben, Ziffer und Sonderzeichen vorschreiben.
  • Neu — keine Zusammensetzungsregeln. Alle druckbaren Zeichen akzeptieren, einschließlich Leerzeichen.
• Rotation: 
  • Alt — Passwörter alle 60-90 Tage ablaufen lassen.
  • Neu — keine erzwungene Rotation. Änderung nur bei Hinweisen auf Kompromittierung.
• Mindestlänge: 
  • Alt — 8 Zeichen wurden oft als allein ausreichend behandelt.
  • Neu — 8 Zeichen sind das absolute Minimum für Passwörter, die mit Multi-Faktor-Authentifizierung verwendet werden. Wenn ein Passwort die einzige Sicherheitsmaßnahme ist, müssen Systeme mindestens 15 Zeichen verlangen. 12+ Zeichen werden als praktischer Unternehmensstandard empfohlen.
• Passworthinweise: 
  • Alt — wissensbasierte Hinweise waren erlaubt.
  • Neu — keine Hinweise, da sie Informationen preisgeben, die ein Angreifer direkt nutzen kann.
• Breach-Prüfung: 
  • Alt — in Richtlinien weitgehend fehlend.
  • Neu — jedes Passwort bei der Erstellung und bei jeder Änderung gegen bekannte Breach-Datenbanken prüfen.

Wenn Ihr Active Directory GPO noch die Checkliste aus den 2010er Jahren durchsetzt, arbeitet es jetzt gegen die Richtlinien, für deren Erfüllung es entwickelt wurde.

Das Verhaltensversagen von Komplexitätsregeln

Komplexitätsregeln scheitern, weil sie vorhersehbares Verhalten erzwingen. Unter einer Zusammensetzungsanforderung konvergieren Benutzer auf dieselben wenigen Ersetzungsmuster: @ für a, 1 für i oder l, ein Großbuchstabe am Anfang, eine Ziffer oder ein Symbol am Ende. Cracking-Tools testen diese Muster zuerst — genau das Gegenteil dessen, was die Richtlinie beabsichtigte.

Es ist das Standardergebnis, wenn Menschen aufgefordert werden, spontan Entropie zu erzeugen. Personen unter kognitiver Belastung greifen zum Weg des geringsten Widerstands: ein einprägsames Wort, eine vorhersehbare Transformation, ein Muster, das sie schon einmal verwendet haben. Password1! und Summer2026! sind das Ergebnis von Komplexitätsrichtlinien, die auf echte Menschen angewendet werden.

Passwortentropie misst, wie unvorhersehbar ein Passwort ist, in Bits. Jedes zusätzliche Bit verdoppelt die Versuche, die ein Angreifer für einen Brute-Force-Angriff benötigt. Sie hängt von der Zeichensatzgröße und der Länge ab, wobei die Länge mehr Gewicht hat — und sie setzt eine vollständig zufällige Auswahl voraus, die von Menschen gewählte Passwörter selten erreichen.

Die Konsequenz verstärkt sich. Sobald ein Benutzer eine Formel gefunden hat, die die Richtlinie erfüllt, wendet er dieselbe Formel überall an: dasselbe Basiswort, dieselben Ersetzungen, leicht pro Website angepasst. Das ist Passwortwiederverwendung mit zusätzlichen Schritten, und genau deshalb funktioniert Credential Stuffing im großen Maßstab. Der 2025 Data Breach Investigations Report von Verizon stellte fest, dass gestohlene oder wiederverwendete Anmeldedaten der häufigste Initialzugriffsvektor bei Sicherheitsverletzungen bleiben und bei der großen Mehrheit der Webanwendungsvorfälle beteiligt sind.

Passwortmüdigkeit verschärft das Problem. Mitarbeiter, die Richtlinienanforderungen über Dutzende von Systemen hinweg jonglieren, werden mit jeder neuen Regel nicht vorsichtiger. Sie werden müde, und müde Benutzer schreiben Passwörter auf Haftnotizen oder speichern sie in einer Tabelle, die niemand verschlüsselt.

Länge und Zufälligkeit schlagen Komplexität — die Mathematik

Ein 8-Zeichen-Passwort, das wirklich zufällig aus einem 95-Zeichen-Satz gezogen wird, hat etwa 52 Bits Entropie. Ein von Menschen gewähltes „komplexes" Passwort kommt selten auch nur annähernd daran heran. Studien zu benutzergenerierten Passwörtern unter Zusammensetzungsregeln beziffern die reale Entropie auf etwa 20-30 Bits, weil die Zeichenauswahl nicht zufällig ist. Sie folgt den oben beschriebenen Ersetzungsmustern.

Die Lücke zwischen den ersten beiden Zeilen ist das gesamte Problem mit Komplexitätsregeln: Die theoretische Obergrenze und das reale Ergebnis sind zwei verschiedene Zahlen, und die Richtlinie kontrolliert nur die Obergrenze.

Eine Passphrase schließt diese Lücke. Vier Wörter, die zufällig aus einer 7.776-Wort-Liste ausgewählt werden (die Standard-EFF/Diceware-Wortlistengröße), erzeugen etwa 52 Bits Entropie — entsprechend dem theoretischen Maximum des 8-Zeichen-komplexen Passworts, sind dabei aber dramatisch leichter zu merken. correct horse battery staple ist das kanonische Beispiel, und es funktioniert, weil die Zufälligkeit aus der Wortauswahl kommt, nicht aus Zeichenersetzungen, die ein Mensch spontan erfinden muss.

Die praktische Erkenntnis: Ein 12-Zeichen-Passwort, das nur aus Kleinbuchstaben besteht und zufällig aus 26 Zeichen gezogen wird, hat mehr reale Entropie als ein 8-Zeichen-„komplexes" Passwort, das ein Mensch tatsächlich wählt, weil Menschen vorhersehbar sind und die Mathematik nicht.

Länge skaliert die Entropie exponentiell mit jedem zusätzlichen Zeichen. Zusammensetzungsregeln fügen einen kleinen, leicht zu erratenden Suchraum auf eine kurze Zeichenkette. Gegen moderne GPU-Hash-Raten bestimmt dieser Unterschied, ob ein Brute-Force-Angriff Stunden oder Jahrhunderte dauert.

Wie Sie sich von Komplexitätsregeln verabschieden

Die Abkehr von veralteten Komplexitätsregeln erfordert kein mehrmonatiges Projekt. Der Großteil der Arbeit besteht aus Richtlinien und Konfiguration, nicht aus neuer Infrastruktur, und entspricht eng dem, was sowohl NIST SP 800-63B-4 als auch das OWASP Authentication Cheat Sheet empfehlen: das Passwortrichtliniendokument aktualisieren, die Einstellungen des Identity Providers anpassen und den Benutzern eine Übergangsfrist geben, um bestehende Passwörter bei der nächsten Anmeldung zu aktualisieren.

Die 5-Schritte-Checkliste für die Migration von Komplexitätsregeln:

1. Aktualisieren Sie zuerst die schriftliche Richtlinie. Ersetzen Sie Zeichenzusammensetzungsanforderungen durch eine Mindestlänge von 15 Zeichen, die zufällig generiert statt manuell zusammengestellt werden. Streichen Sie die obligatorischen Ziffern-, Symbol- und Großbuchstabenregeln zusammen mit periodisch erzwungenen Resets — beides erhöht den Aufwand ohne entsprechenden Sicherheitsgewinn, sobald die Mindestlänge durchgesetzt wird.
2. Konfigurieren Sie den Identity Provider neu. Die meisten AD/LDAP- und SSO-Systeme ermöglichen es, die Komplexitätsdurchsetzung zu deaktivieren und eine Mindestlänge unabhängig festzulegen. Testen Sie die Änderung an einer Pilotgruppe, bevor Sie sie organisationsweit ausrollen.
3. Fügen Sie Breach-Datenbank-Screening hinzu. Prüfen Sie neue Passwörter bei der Erstellung gegen bekannte geleakte Passwortlisten. Dies leistet mehr gegen Credential Stuffing als eine erzwungene Ziffer und ein Symbol, weil es genau die Passwörter blockiert, die Angreifer bereits ausprobieren — nicht nur schwache Muster.
4. Implementieren Sie phishing-resistente MFA. Ein langes, nicht geleaktes Passwort ist immer noch ein Single Point of Failure, wenn es gephisht wird. Priorisieren Sie FIDO2/WebAuthn-Sicherheitsschlüssel oder Passkeys für den Produktivzugriff. TOTP funktioniert als Fallback, aber Sicherheitsschlüssel und Passkeys sollten das Ziel sein.
5. Gewähren Sie eine Übergangsfrist, keinen erzwungenen Reset. Wenn Sie alle zwingen, ihre Passwörter am selben Tag zu ändern, erhalten Sie eine Flut von Winter2026!-ähnlichen Mustern. Lassen Sie Passwörter stattdessen natürlich bei der nächsten Anmeldung oder beim Ablauf rotieren.

Teams, die diese Umstellung vornehmen, erleben tendenziell einen Nebeneffekt, den niemand im Richtliniendokument erwähnt: Das Helpdesk-Ticketvolumen für Passwort-Resets sinkt, weil es keinen erzwungenen Rotationszyklus mehr gibt, der vierteljährlich „Ich habe mein neues Passwort vergessen"-Tickets generiert.

Für Dienstkonten und Secrets, die sich überhaupt nicht auf das menschliche Gedächtnis verlassen können, ist die Kalkulation anders: generierte 32+-Zeichen-Secrets, die in einem Passwort-Manager gespeichert werden, anstatt etwas, das jemand aus dem Gedächtnis eingibt.

Warum MFA und Passkeys das eigentliche Ziel sind

Selbst eine gut konzipierte Passwortrichtlinie ist eine Übergangsmaßnahme. Die Richtung, in die sich die Sicherheit entwickelt, ist passwortlose Authentifizierung auf Basis von FIDO2 und WebAuthn, bei der es überhaupt kein geteiltes Geheimnis mehr gibt, das gestohlen werden könnte.

Passkeys sind von Grund auf phishing-resistent: Der private Schlüssel verlässt niemals das Gerät, und die Relying Party speichert nur einen öffentlichen Schlüssel, der für einen Angreifer ohne die passende Hardware wertlos ist. Apple, Google und Microsoft unterstützen Passkeys nativ auf ihren Plattformen gemäß der W3C WebAuthn-Spezifikation, und die Verbraucherakzeptanz hat sich schneller entwickelt als die meisten vorhergesagt hatten.

Die Unternehmenseinführung läuft langsamer. Drei Faktoren halten die meisten Organisationen noch Jahre davon ab, Passwörter vollständig abzuschaffen:

• Legacy-Anwendungen, die sich gegen On-Premise-Verzeichnisse authentifizieren oder vor der WebAuthn-Unterstützung entwickelt wurden und nicht über Nacht umgeschrieben werden können
• Föderierte Identitäts-Setups, bei denen SSO, SAML und LDAP-Integrationen Passkeys neben bestehenden Protokollen unterstützen müssen, nicht diese vollständig ersetzen
• Rollout-Logistik im Unternehmensmaßstab: Geräteregistrierung, Kontowiederherstellung bei Verlust eines Hardware-Schlüssels und Helpdesk-Kapazität zur Unterstützung des Übergangs

In diesem Zeitfenster ist die oben beschriebene Passwortrichtlinie (Länge, Breach-Screening, MFA) — durchgesetzt durch Tools statt durch ein PDF — das, was eine Organisation sicher hält, während der Übergang voranschreitet.

Was ein Passwort-Manager durchsetzt, was Gruppenrichtlinien nicht können

Ein Gruppenrichtlinienobjekt definiert Passwortzusammensetzungsregeln, hat aber keine Möglichkeit zu prüfen, ob ein Passwort bereits geleakt wurde, und keinen Mechanismus zur Nachverfolgung, wer danach auf ein geteiltes Passwort zugegriffen hat. Ein Passwort-Manager schließt diese Lücke: Er prüft Anmeldedaten gegen Breach-Datenbanken, setzt die Länge organisationsweit durch und protokolliert jedes Zugriffsereignis. Das ist die Durchsetzungsebene, die GPO strukturell fehlt.

Passwork, ein selbst gehosteter Unternehmens-Passwort-Manager, wendet dies auf Tresor-Ebene an: Er setzt die Mindestlänge organisationsweit durch, ohne Zeichenmix-Regeln wieder einzuführen, und organisiert Team-Anmeldedaten in geteilten Tresoren mit rollenbasierter Zugriffskontrolle, die Berechtigungen nach Gruppe statt nach individuellem Konto festlegt.

Der integrierte Generator von Passwork erzeugt kryptografisch zufällige Passwörter mit hoher Entropie — die Art, die eine Person nicht zuverlässig von Hand erfinden kann — und speichert sie direkt im Tresor. Autofill übernimmt dann die Anmeldung, sodass niemand jemals das vom Generator Erstellte auswendig lernen oder erneut eingeben muss. Das eliminiert den letzten Punkt, an dem ein Mensch das Passwort noch schwächen könnte: den Moment, in dem jemand versucht, eine lange, zufällige Zeichenkette merkbar zu machen und sie dabei stillschweigend vorhersehbar macht.

Im Gegensatz zu Tools, die nur menschliche Logins verwalten, kombiniert Passwork Passwortverwaltung und Secrets Management in einem Tresor: API-Schlüssel, Zugriffstoken, Datenbank-Anmeldedaten und TLS-Zertifikate befinden sich neben Benutzerpasswörtern unter denselben Zugriffskontrollen und im selben Audit-Log.

Die Umstellung vollziehen

Komplexitätsregeln sind ein Überbleibsel aus einer Ära, als Angreifer sich auf Brute-Force-Raten statt auf automatisierte Tools verließen. Sobald Credential-Stuffing-Angriffe Tausende von Passwortvarianten pro Sekunde testen können, macht es keinen Sinn mehr, Benutzer zu bitten, manuell Entropie zu erzeugen. Länge und MFA erledigen die Aufgabe, die Zusammensetzungsregeln erfüllen sollten, ohne sich auf das Gedächtnis von irgendjemandem zu verlassen.

Das NIST-Update ist eine formelle Anerkennung dessen, was Sicherheitsexperten seit über einem Jahrzehnt beobachten: Menschen sind das schwächste Glied in jeder Richtlinie, die sie auffordert, auf Abruf Zufälligkeit zu erzeugen.

Beginnen Sie mit dem Audit. Rufen Sie Ihre aktuellen GPO-Passworteinstellungen ab, prüfen Sie, ob sie noch Zusammensetzung und Rotation vorschreiben, und vergleichen Sie das mit SP 800-63B-4.

Häufig gestellte Fragen

Brute-Force-Angriffe 2026: Typen, Beispiele und wie man sie verhindert

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

Passwork BlogAlex Muntyan

Sind Ihre Daten sicher? Aufsehenerregende Datenlecks 2025-2026 Leitfaden

16 Milliarden geleakte Anmeldedaten. Eine Betriebsunterbrechung von 2,2–2,5 Milliarden Euro bei JLR. Ein veraltetes Dienstkonto legte Daten von vier großen Unternehmen offen. Hier erfahren Sie, was die größten Datenschutzverletzungen 2025–2026 über Anmeldedatenrisiken verraten, und die sechs Kontrollen, die die meisten davon verhindert hätten.

Passwork BlogPasswork Team

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

Erfahren Sie, wie Teams 2026 Anmeldedaten sicher teilen — RBAC, Audit-Logs, Offboarding-Checklisten, NIST SP 800-63B Rev. 4-Anforderungen und Self-hosted vs. Cloud-Deployment.

Passwork BlogAlex Muntyan

La complejidad de contraseñas es una regla de política que exige que una contraseña combine tipos de caracteres (mayúsculas, minúsculas, dígitos y símbolos) bajo la suposición de que una mayor variedad de caracteres produce mayor entropía y mayor resistencia a los intentos de adivinación.

P@ssw0rd123! probablemente cumple con todas las reglas de complejidad que aplica su Política de Grupo. También le toma a un equipo GPU moderno aproximadamente 2 segundos descifrarlo, porque el patrón detrás de él es una de las primeras cosas que cualquier diccionario de cracking intenta.

Ese es el fallo principal. Las reglas de complejidad fueron diseñadas para aumentar la entropía, pero los usuarios convergieron en sustituciones predecibles, anotaron las contraseñas y reutilizaron la misma credencial en una docena de servicios. En 2024, NIST abandonó formalmente los requisitos de complejidad en SP 800-63B-4. Aquí explicamos por qué y qué lo reemplaza.

Qué son las reglas de complejidad de contraseñas

Las reglas de complejidad de contraseñas son requisitos de política que obligan a que una contraseña combine tipos de caracteres, típicamente al menos una letra mayúscula, una letra minúscula, un dígito y un símbolo, bajo la suposición de que una mayor variedad de caracteres produce mayor entropía y mayor resistencia a los ataques de adivinación.

Estas reglas se convirtieron en estándar en la TI empresarial durante las décadas de 2000 y 2010, generalmente combinadas con una longitud mínima de 8 caracteres y rotación obligatoria cada 60 a 90 días. La política de contraseñas predeterminada de Active Directory todavía viene con los requisitos de composición habilitados, y la mayoría de las listas de verificación de cumplimiento de esa época asumían que la complejidad y la rotación eran la base para la seguridad de las cuentas.

La suposición detrás de la regla era sólida en teoría: un conjunto de caracteres más grande por posición significa más combinaciones posibles, lo que significa una búsqueda de fuerza bruta más larga. En la práctica, la regla interactúa con el comportamiento humano de una manera que socava su propio objetivo, tema de la siguiente sección.

Qué cambió NIST — y por qué importa

NIST SP 800-63B-4 elimina las reglas obligatorias de composición de caracteres y los restablecimientos periódicos de contraseñas, citando evidencia de que ambas prácticas degradan la seguridad en el mundo real en lugar de mejorarla. La actualización reemplaza la complejidad prescriptiva con requisitos basados en longitud y verificación de brechas.

La justificación se encuentra en el Apéndice A de la publicación: las reglas de composición empujan a los usuarios hacia contraseñas predecibles y formulaicas, mientras que la rotación forzada lleva a las personas a hacer cambios triviales (Summer2025! se convierte en Summer2026!) o reutilizar contraseñas antiguas con un dígito añadido. Ninguno de estos comportamientos aumenta la resistencia a la adivinación o el cracking.

«La investigación ha demostrado que los usuarios responden de maneras muy predecibles a los requisitos impuestos por las reglas de composición (políticas). Por ejemplo, un usuario que podría haber elegido "password" como su contraseña probablemente elegiría "Password1" si se le exige incluir una letra mayúscula y un número, o "Password1!" si también se requiere un símbolo.» — NIST SP 800-63B-4

Este es el cambio en la práctica:

• Composición de caracteres: 
  • Antes — exigir mayúsculas, minúsculas, dígitos y caracteres especiales.
  • Ahora — sin reglas de composición. Aceptar cualquier carácter imprimible, incluyendo espacios.
• Rotación: 
  • Antes — caducar contraseñas cada 60-90 días.
  • Ahora — sin rotación forzada. Cambiar solo ante evidencia de compromiso.
• Longitud mínima: 
  • Antes — 8 caracteres a menudo se trataban como suficientes por sí solos.
  • Ahora — 8 caracteres es el mínimo absoluto para contraseñas utilizadas con autenticación multifactor. Si una contraseña es su única seguridad, los sistemas deben exigir un mínimo de 15 caracteres. Se recomiendan 12+ caracteres como el piso práctico empresarial.
• Pistas de contraseña: 
  • Antes — se permitían pistas basadas en conocimiento.
  • Ahora — sin pistas, ya que filtran información que un atacante puede usar directamente.
• Verificación de brechas: 
  • Antes — en gran parte ausente de la política.
  • Ahora — verificar cada contraseña contra corpus de brechas conocidas al momento de la creación y en cada cambio.

Si su GPO de Active Directory todavía aplica la lista de verificación de la era 2010, ahora está trabajando en contra de las directrices que fue diseñado para satisfacer.

El fallo conductual de las reglas de complejidad

Las reglas de complejidad fallan porque fuerzan un comportamiento predecible. Bajo un requisito de composición, los usuarios convergen en el mismo puñado de patrones de sustitución: @ por a, 1 por i o l, una letra mayúscula al principio, un dígito o símbolo al final. Las herramientas de cracking prueban estos patrones primero, lo cual es exactamente lo contrario de lo que la política pretendía.

Es el resultado predeterminado de pedir a los humanos que generen entropía bajo demanda. Las personas bajo carga cognitiva recurren al camino de menor resistencia: una palabra memorable, una transformación predecible, un patrón que han usado antes. Password1! y Summer2026! son el resultado de la política de complejidad aplicada a humanos reales.

La entropía de contraseña mide cuán impredecible es una contraseña, en bits. Cada bit añadido duplica las conjeturas que un atacante necesita para un crackeo por fuerza bruta. Depende del tamaño del conjunto de caracteres y la longitud, siendo la longitud más importante — y asume una selección completamente aleatoria, algo que las contraseñas elegidas por humanos rara vez logran.

La consecuencia se multiplica. Una vez que un usuario establece una fórmula que satisface la política, aplica la misma fórmula en todas partes: la misma palabra base, las mismas sustituciones, ligeramente modificadas por sitio. Eso es reutilización de contraseñas con pasos adicionales, y es precisamente por qué el credential stuffing funciona a escala. El Informe de Investigaciones de Brechas de Datos 2025 de Verizon encontró que las credenciales robadas o reutilizadas siguen siendo el principal vector de acceso inicial en las brechas, involucradas en la gran mayoría de los incidentes de aplicaciones web.

La fatiga de contraseñas empeora el problema. Los empleados que manejan requisitos de políticas en docenas de sistemas no se vuelven más cuidadosos con cada nueva regla. Se cansan, y los usuarios cansados escriben contraseñas en notas adhesivas o las almacenan en una hoja de cálculo que nadie cifra.

La longitud y la aleatoriedad superan a la complejidad — las matemáticas

Una contraseña de 8 caracteres elegida verdaderamente al azar de un conjunto de 95 caracteres tiene aproximadamente 52 bits de entropía. Una contraseña «compleja» elegida por un humano rara vez se acerca. Estudios sobre contraseñas generadas por usuarios bajo reglas de composición sitúan la entropía real más cerca de 20-30 bits, porque las elecciones de caracteres no son aleatorias. Siguen los patrones de sustitución descritos anteriormente.

La brecha entre las dos primeras filas es todo el problema con las reglas de complejidad: el techo teórico y el resultado del mundo real son dos números diferentes, y la política solo controla el techo.

Una frase de contraseña cierra esa brecha. Cuatro palabras elegidas al azar de una lista de 7.776 palabras (el tamaño estándar de la lista de palabras EFF/Diceware) producen aproximadamente 52 bits de entropía — igualando el máximo teórico de esa contraseña compleja de 8 caracteres, mientras son dramáticamente más fáciles de recordar. correct horse battery staple es el ejemplo canónico, y se mantiene porque la aleatoriedad proviene de la selección de palabras, no de la sustitución de caracteres que un humano tiene que inventar en el momento.

La conclusión práctica: una contraseña de 12 caracteres completamente en minúsculas elegida aleatoriamente de 26 caracteres tiene más entropía real que una contraseña «compleja» de 8 caracteres que un humano realmente elige, porque los humanos son predecibles y las matemáticas no lo son.

La longitud escala la entropía exponencialmente con cada carácter adicional. Las reglas de composición añaden un pequeño espacio de búsqueda fácilmente adivinable sobre una cadena corta. Contra las tasas de hash de GPU modernas, esa diferencia determina si un ataque de fuerza bruta toma horas o siglos.

Cómo abandonar las reglas de complejidad

Abandonar las reglas de complejidad heredadas no requiere un proyecto de varios trimestres. La mayor parte del trabajo es política y configuración, no nueva infraestructura, y se alinea estrechamente con lo que NIST SP 800-63B-4 y la Hoja de trucos de autenticación de OWASP recomiendan: actualizar el documento de política de contraseñas, ajustar la configuración del proveedor de identidad y dar a los usuarios un período de gracia para actualizar las contraseñas existentes en el próximo inicio de sesión.

La lista de verificación de migración de reglas de complejidad en 5 pasos:

1. Actualice primero la política escrita. Reemplace los requisitos de composición de caracteres con una longitud mínima de 15 caracteres, generados aleatoriamente en lugar de compuestos a mano. Elimine las reglas obligatorias de dígitos, símbolos y mayúsculas, junto con los restablecimientos forzados periódicos; ambos añaden fricción sin una ganancia de seguridad correspondiente una vez que se aplica la longitud mínima.
2. Reconfigure el proveedor de identidad. La mayoría de los sistemas AD/LDAP y SSO permiten deshabilitar la aplicación de complejidad y establecer una longitud mínima de forma independiente. Pruebe el cambio en un grupo piloto antes de implementarlo en toda la organización.
3. Agregue verificación contra bases de datos de brechas. Verifique las nuevas contraseñas contra listas de contraseñas comprometidas conocidas al momento de la creación. Esto hace más para detener el credential stuffing que forzar un dígito y un símbolo, porque bloquea exactamente las contraseñas que los atacantes ya están probando, no solo patrones débiles.
4. Implemente MFA resistente al phishing. Una contraseña larga y no comprometida sigue siendo un único punto de fallo si es objeto de phishing. Priorice las llaves de seguridad FIDO2/WebAuthn o los passkeys para el acceso de producción. TOTP funciona como alternativa, pero las llaves de seguridad y los passkeys deberían ser el objetivo.
5. Otorgue un período de gracia, no un restablecimiento forzado. Obligue a todos a cambiar contraseñas el mismo día y obtendrá una avalancha de patrones estilo Winter2026!. En su lugar, permita que las contraseñas roten naturalmente en el próximo inicio de sesión o vencimiento.

Los equipos que hacen este cambio tienden a ver un beneficio secundario que nadie pone en el documento de política: el volumen de tickets de soporte técnico para restablecimientos de contraseña disminuye, porque no hay un ciclo de rotación forzada que genere tickets de «olvidé mi nueva contraseña» cada trimestre.

Para cuentas de servicio y secretos que no pueden depender de la memoria humana en absoluto, el cálculo es diferente: secretos generados de 32+ caracteres almacenados en un gestor de contraseñas en lugar de algo que alguien escriba de memoria.

Por qué MFA y los passkeys son el objetivo final real

Incluso una política de contraseñas bien diseñada es una medida de transición. La dirección hacia la que se dirige la seguridad es la autenticación sin contraseña basada en FIDO2 y WebAuthn, donde no hay secreto compartido que robar en primer lugar.

Los passkeys son resistentes al phishing por diseño: la clave privada nunca abandona el dispositivo, y la parte que confía almacena solo una clave pública que no tiene valor para un atacante sin el hardware correspondiente. Apple, Google y Microsoft admiten passkeys de forma nativa en sus plataformas, según la especificación W3C WebAuthn, y la adopción del consumidor ha avanzado más rápido de lo que la mayoría predijo.

La adopción empresarial sigue una línea de tiempo más lenta. Tres factores mantienen a la mayoría de las organizaciones a años de retirar las contraseñas por completo:

• Aplicaciones heredadas que se autentican contra directorios on-premise o son anteriores al soporte de WebAuthn y no se pueden reescribir de la noche a la mañana
• Configuraciones de identidad federada donde SSO, SAML e integraciones LDAP necesitan acomodar passkeys junto con los protocolos existentes, no reemplazarlos por completo
• Logística de implementación a escala de la fuerza laboral: inscripción de dispositivos, recuperación de cuentas cuando se pierde una llave de hardware y capacidad del servicio de asistencia para apoyar la transición

En esa ventana, la política de contraseñas descrita anteriormente (longitud, verificación de brechas, MFA) aplicada a través de herramientas en lugar de un PDF es lo que mantiene segura a una organización mientras la transición se desarrolla.

Lo que un gestor de contraseñas aplica y la Política de Grupo no puede

Un Objeto de Política de Grupo define reglas de composición de contraseñas, pero no tiene forma de verificar si una contraseña ya se ha filtrado, y ningún mecanismo para rastrear quién accedió a una credencial compartida posteriormente. Un gestor de contraseñas cierra esa brecha: verifica las credenciales contra bases de datos de brechas, aplica la longitud en toda la organización y registra cada evento de acceso. Esa es la capa de aplicación que GPO estructuralmente carece.

Passwork, un gestor de contraseñas corporativo autoalojado, aplica esto a nivel de bóveda: aplica la longitud mínima en toda la organización sin reintroducir reglas de combinación de caracteres, y organiza las credenciales del equipo en bóvedas compartidas con control de acceso basado en roles que delimita los permisos por grupo en lugar de por cuenta individual.

El generador integrado de Passwork produce contraseñas criptográficamente aleatorias y de alta entropía, del tipo que una persona no puede inventar de forma fiable a mano, y las almacena directamente en la bóveda. El autocompletado luego maneja el inicio de sesión, por lo que nadie tiene que memorizar ni volver a escribir lo que el generador creó. Esto elimina el último punto donde un humano aún podría debilitar la contraseña: el momento en que alguien intenta hacer memorable una cadena larga y aleatoria y silenciosamente la hace predecible en su lugar.

A diferencia de las herramientas que solo manejan inicios de sesión humanos, Passwork combina la gestión de contraseñas y la gestión de secretos en una sola bóveda: claves API, tokens de acceso, credenciales de bases de datos y certificados TLS se encuentran junto a las contraseñas de usuario bajo los mismos controles de acceso y registro de auditoría.

Realizando el cambio

Las reglas de complejidad son un remanente de una era en la que los atacantes dependían de la adivinación por fuerza bruta en lugar de herramientas automatizadas. Una vez que los ataques de credential stuffing pueden probar miles de variantes de contraseñas por segundo, pedir a los usuarios que inventen entropía manualmente deja de tener sentido. La longitud y MFA hacen el trabajo que se suponía que debían hacer las reglas de composición, sin depender de la memoria de nadie.

La actualización de NIST es un reconocimiento formal de algo que los profesionales de seguridad han observado durante más de una década: los humanos son el eslabón más débil en cualquier política que les pida generar aleatoriedad bajo demanda.

Comience con la auditoría. Extraiga la configuración actual de contraseñas de su GPO, verifique si todavía exige composición y rotación, y compare con SP 800-63B-4.

Preguntas frecuentes

Ataques de fuerza bruta en 2026: tipos, ejemplos y cómo prevenirlos

Clústeres de GPU, listas de palabras asistidas por IA, botnets de 2,8 millones de dispositivos. La fuerza bruta ha escalado. Esta guía cubre seis variantes de ataque, casos reales de 2025 y una estrategia de defensa en capas que su equipo puede implementar hoy.

Passwork BlogAlex Muntyan

¿Están seguros sus datos? Guía de filtraciones de datos de alto perfil 2025-2026

16 mil millones de credenciales filtradas. Un cierre de €2,2-2,5 mil millones en JLR. Una cuenta de servicio obsoleta expuso datos en cuatro grandes empresas. Esto es lo que revelan las mayores brechas de datos de 2025-2026 sobre el riesgo de credenciales, y los seis controles que habrían detenido la mayoría de ellas.

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 y despliegue autoalojado vs. en la nube.

Passwork BlogAlex Muntyan

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

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

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.

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