Cybersecurity

Einleitung

Um 3:14 Uhr nachts beobachtet niemand die Authentifizierungs-Logs. Ein Skript, das auf einer gemieteten Cloud-Instanz läuft, sendet seinen zehntausendsten Anmeldeversuch an ein VPN-Portal. Um 3:17 Uhr erhält es eine Antwort, die sich von den anderen unterscheidet. Zugriff gewährt. Keine Malware, kein Social Engineering, keine Insider-Bedrohung. Nur ein schwaches Passwort, automatisierte Geduld und eine Lücke im Monitoring.

Einer von drei erfolgreichen Angriffen auf Webanwendungen beginnt heute auf die gleiche Weise: Ein automatisiertes Skript durchläuft Anmeldedaten, bis etwas funktioniert. Laut dem Verizon Data Breach Investigations Report 2025 haben sich Brute-Force-Angriffe auf einfache Webanwendungen im letzten Jahr fast verdreifacht — von etwa 20 % auf 60 %. Dies signalisiert, dass automatisierte Credential-Angriffe zur primären Waffe geworden sind, nicht zum Ausweichplan.

Die zugrundeliegende Mechanik hat sich nicht geändert: Kombinationen ausprobieren, bis eine funktioniert. Was sich geändert hat, ist die Geschwindigkeit, Skalierung und Intelligenz hinter diesen Versuchen. Moderne GPU-Cluster, KI-gestützte Wordlist-Generierung und Botnets mit Millionen kompromittierter Geräte haben das, was einst ein langsamer, auffälliger Angriff war, in etwas Schnelles, Verteiltes und schwer Erkennbares verwandelt.

Dieser Artikel behandelt, was Brute-Force-Angriffe sind, wie sie sich 2026 entwickelt haben, die sechs Hauptvarianten, Praxisbeispiele aus 2025–2026 und eine mehrschichtige Verteidigungsstrategie, die Ihr Team heute implementieren kann.

Wichtigste Erkenntnisse

• Brute-Force-Angriffe sind automatisierte Credential-Angriffe — Skripte durchlaufen systematisch Benutzernamen- und Passwortkombinationen, bis eine funktioniert, und nutzen schwache, wiederverwendete oder vorhersagbare Passwörter aus — nicht Software-Schwachstellen.
• Sechs verschiedene Varianten zielen auf unterschiedliche Schwachstellen ab: Einfache Brute-Force, Dictionary-Angriffe, Credential Stuffing, Password Spraying, Reverse Brute Force und Hybrid-Angriffe — jede darauf ausgelegt, einen bestimmten Satz von Abwehrmaßnahmen zu umgehen.
• Moderne Hardware hat schwache Passwörter unhaltbar gemacht: Ein GPU-Cluster kann ein 8-Zeichen-MD5-gehashtes Passwort in Minuten knacken. Passwortlänge und sicheres Hashing bestimmen den realen Widerstand.
• Mehrschichtige Abwehrmaßnahmen funktionieren, aber nur bei konsequenter Durchsetzung. MFA, starke Passwortrichtlinien, Breach-Datenbank-Prüfung, Kontosperren, Rate Limiting und ein Passwort-Manager machen Brute-Force-Angriffe gemeinsam unpraktikabel. Jede einzelne Lücke reicht einem Angreifer zur Ausnutzung.
• Erkennung ist eine präventive Kontrolle, nicht nur eine reaktive. Das Erkennen von Angriffssignaturen — Spitzen bei fehlgeschlagenen Anmeldungen, langsame Spraying-Muster, unmögliche Reisen — gibt Ihrem Team Zeit, die Quelle zu blockieren, bevor Anmeldedaten validiert werden.
• Ein Passwort-Manager ist die strukturelle Lösung für Credential-Wiederverwendung — die Hauptursache hinter Credential Stuffing. Für Teams erzwingt er auch Rotation, markiert kompromittierte Anmeldedaten und schließt die Offboarding-Lücke, die veraltete Anmeldedaten jahrelang gültig lässt.

Was ist ein Brute-Force-Angriff?

Ein Brute-Force-Angriff verschafft unbefugten Zugriff auf ein System durch systematisches Ausprobieren jeder möglichen Kombination von Anmeldedaten (Benutzernamen, Passwörter oder Verschlüsselungsschlüssel), bis die richtige gefunden ist. Er nutzt menschliches Verhalten aus: schwache, wiederverwendete oder vorhersagbare Passwörter.

Stellen Sie es sich vor wie das Ausprobieren jedes Schlüssels an einem Schlüsselbund. Mit genügend Zeit und Rechenleistung wird irgendwann einer passen. Das Ziel des Angreifers ist es, diese Zeit auf etwas Praktikables zu reduzieren — und 2026 macht moderne Hardware das zunehmend erreichbar.

Brute-Force-Angriffe zielen auf Authentifizierungs-Endpunkte: Anmeldeseiten, SSH- und RDP-Dienste, VPN-Portale, API-Gateways und Admin-Panels. Jedes System, das einen Benutzernamen und ein Passwort akzeptiert, ist ein potenzielles Ziel.

Wie Brute-Force-Angriffe 2026 funktionieren

Im Kern ist ein Brute-Force-Angriff Automatisierung im großen Maßstab. Ein Angreifer setzt ein Skript oder Tool ein, das Credential-Kombinationen in schneller Folge an den Authentifizierungs-Endpunkt eines Zielsystems sendet. Das Skript protokolliert erfolgreiche Treffer und macht weiter.

Was 2026 von vor einem Jahrzehnt unterscheidet, ist die Infrastruktur hinter diesen Skripten.

Der KI- und Hardware-Faktor

Moderne Grafikkarten (ursprünglich für Gaming und maschinelles Lernen entwickelt) sind außergewöhnlich effizient bei paralleler Berechnung — genau das, was Password Cracking erfordert. Ein Cluster aus 12 NVIDIA RTX 5090 GPUs kann Hunderte Milliarden MD5-Hash-Kombinationen pro Sekunde testen (Hive Systems).

Bei schwach gehashten Anmeldedaten fällt ein 8-Zeichen-Passwort in Minuten — oder weniger. Gegen bcrypt mit modernen Kosteneinstellungen kann dieselbe Hardware Jahre benötigen. Der Unterschied liegt nicht an der Hardware des Angreifers. Es geht darum, ob das Zielsystem Passwörter sicher speichert.

Machine-Learning-Modelle, die auf geleakten Passwort-Datensätzen trainiert wurden (Tools wie PassGAN, basierend auf Generative Adversarial Networks), lernen reale Passwortverteilungen ohne menschengeschriebene Regeln. Sie sagen wahrscheinliche Muster voraus: An Namen angehängte Geburtstage, gängige Zeichensubstitutionen, kulturspezifische Phrasen.

In Tests gegen den RockYou-Breach-Datensatz traf PassGAN 47 % der echten Passwörter. In Kombination mit konventionellen Cracking-Tools wurden 24 % mehr Treffer erzielt als mit beiden Ansätzen allein. Der Suchraum schrumpft nicht durch Brute Force — er schrumpft durch Vorhersage.

Die Quantenbedrohung

Quantencomputing nutzt quantenmechanische Phänomene zur Informationsverarbeitung auf eine Weise, die klassische Computer nicht können. Während ein klassischer Prozessor Möglichkeiten sequenziell durcharbeitet, wertet ein Quantensystem viele Zustände gleichzeitig aus. Angewendet auf Kryptografie wird diese Parallelität zur direkten Bedrohung für die mathematischen Probleme, die der aktuellen Verschlüsselung zugrunde liegen.

Quantencomputing führt ein längerfristiges Risiko ein. IBMs Quanten-Roadmap prognostiziert, dass kryptografisch relevante Quantencomputer aktuelle asymmetrische Verschlüsselungsstandards noch in diesem Jahrzehnt untergraben könnten.

Quantenangriffe auf gehashte Passwörter bleiben theoretisch, aber Organisationen, die langlebige Geheimnisse und Verschlüsselungsschlüssel verwalten, sollten mit der Evaluierung von Post-Quanten-Kryptografiestandards beginnen — NIST hat seine ersten Post-Quanten-Standards 2024 finalisiert.

Botnets und verteilte Angriffe

Ein Botnet ist ein Netzwerk kompromittierter Geräte (Server, Router, IoT-Endpunkte, PCs), die ohne Wissen ihrer Besitzer von einem Angreifer ferngesteuert werden. Jedes Gerät fungiert als unabhängiger Knoten, der Anfragen senden, Systeme sondieren oder Anmeldeversuche übermitteln kann. Die Skalierung kann Millionen koordiniert arbeitender Maschinen erreichen.

Angreifer operieren selten von einer einzelnen IP aus. Moderne Brute-Force-Kampagnen nutzen Botnets, um Anmeldeversuche über verschiedene Quelladressen zu verteilen und so IP-basiertes Rate Limiting und geografische Sperren zu umgehen.

Anfang 2025 verfolgte die Shadowserver Foundation eine Kampagne, die täglich 2,8 Millionen IP-Adressen nutzte, um VPN-Anmeldeportale von Palo Alto Networks, Ivanti und SonicWall anzugreifen (BleepingComputer).

Die angreifenden Knoten waren überwiegend kompromittierte MikroTik-, Huawei- und Cisco-Router — gekaperte Geräte verteilt über Dutzende Länder, wobei der größte Cluster aus Brasilien stammte. Der Traffic wurde über Residential-Proxy-Netzwerke geleitet, sodass jeder Versuch wie normaler Heimanwender-Traffic aussah statt wie ein Bot. Standard-IP-basierte Abwehrmaßnahmen sahen etwas, das wie normaler Traffic aussah.

Arten von Brute-Force-Angriffen

Brute-Force-Angriffe teilen ein Prinzip: Zugang durch systematisches Testen von Anmeldedaten erlangen, bis etwas funktioniert. Die Methoden unterscheiden sich darin, was sie testen, woher sie ihre Daten beziehen und welche Abwehrmaßnahmen sie umgehen sollen.

1. Einfacher Brute-Force-Angriff

Die direkteste Variante: Jede mögliche Zeichenkombination wird der Reihe nach ausprobiert — aaa, aab, aac — bis ein Treffer gefunden wird. Keine Vorkenntnisse über das Ziel sind erforderlich. Der Angriff verlässt sich vollständig auf Rechenleistung.

Er ist nur gegen kurze oder einfache Passwörter effektiv. Bei einem 8-Zeichen-Passwort mit gemischten Zeichen können moderne GPU-Cluster die Suche in Stunden abschließen. Ab 12 Zeichen wird derselbe Ansatz rechnerisch unpraktikabel — der Suchraum wächst exponentiell mit jedem hinzugefügten Zeichen.

2. Dictionary-Angriff

Ein Dictionary-Angriff ersetzt die erschöpfende Aufzählung durch eine kuratierte Liste wahrscheinlicher Passwörter (Wörter, Phrasen und bekannte Anmeldedaten) und verengt so den Suchraum dramatisch. Der Angreifer setzt auf menschliche Vorhersagbarkeit statt auf rohe Rechenleistung.

Diese Listen reichen von einfachen Zusammenstellungen der 10.000 häufigsten Passwörter bis zu Multi-Gigabyte-Datensätzen aus geleakten Anmeldedaten, regionalen Slang und branchenspezifischer Terminologie. Jedes Passwort, das natürlicher Sprache ähnelt, ist anfällig. Zufälligkeit ist die einzige zuverlässige Verteidigung.

3. Credential Stuffing

Credential Stuffing ist die automatisierte Wiederverwendung von Benutzernamen-Passwort-Paaren, die bei früheren Datenschutzverletzungen gestohlen wurden. Angreifer nehmen Benutzernamen-Passwort-Paare und testen sie gegen andere Dienste und nutzen die Tatsache aus, dass viele Benutzer dieselben Anmeldedaten über mehrere Konten hinweg wiederverwenden.

Im Juli 2024 wurde eine Zusammenstellung von fast 10 Milliarden einzigartigen Passwörtern — genannt RockYou2024 — in einem kriminellen Forum veröffentlicht und bot Angreifern einen beispiellosen Pool an Anmeldedaten (Cybernews, 2024).

Das Verständnis der Gefahren der Passwortwiederverwendung ist hier wesentlicher Kontext — ein einziges kompromittiertes Konto auf einer Plattform kann sich kaskadenartig auf den gesamten digitalen Fußabdruck auswirken.

4. Password Spraying

Password Spraying kehrt den typischen Ansatz um. Anstatt viele Passwörter gegen ein Konto zu probieren (was Sperren auslöst), probiert der Angreifer ein oder zwei gängige Passwörter — Password1!, Welcome2026 — über Tausende von Konten.

Es bleibt unter Sperrschwellen und ist besonders effektiv gegen große Organisationen mit schwachen Passwortrichtlinien. Über 97 % der Identitätsangriffe beinhalten Password Spray oder Brute Force, laut dem Microsoft Digital Defence Report 2025.

5. Reverse-Brute-Force-Angriff

Ein Reverse-Brute-Force-Angriff beginnt mit einem bekannten Passwort (typischerweise aus einem Breach oder einem bekannten Standard stammend) und testet es systematisch gegen eine Liste von Benutzernamen. Die Anmeldedaten sind fix; die Identität ist die Unbekannte.

Diese Methode ist am effektivsten, wenn das Zielpasswort weit verbreitet ist: Ein Standard-Firmenpasswort, das beim Onboarding verteilt wurde, ein gängiges durch eine schwache Richtlinie vorgeschriebenes Muster oder ein Credential, das in einem früheren Leak auftauchte. Während ein Standardangriff ein Konto tief sondiert, sondiert ein Reverse-Angriff viele Konten mit chirurgischer Präzision.

6. Hybrid-Brute-Force-Angriff

Ein Hybrid-Brute-Force-Angriff kombiniert Wörterbuch-Wörter mit programmatischen Mutationen — Anhängen von Zahlen, Jahren oder Sonderzeichen (Summer2026!, admin@123), Ersetzen von Buchstaben durch Symbole oder Verschieben der Groß-/Kleinschreibung. Er ist darauf ausgelegt, Passwörter zu knacken, die komplex erscheinen, aber vorhersagbaren Konstruktionsmustern folgen.

Diese Angriffe zielen auf die Lücke zwischen Passwortrichtlinie und menschlichem Verhalten. Wenn Benutzer aufgefordert werden, ein Passwort zu „verkomplizieren", führen sie selten echte Zufälligkeit ein — sie hängen 1! an ein bekanntes Wort an oder schreiben den ersten Buchstaben groß. Hybrid-Angriffe sind genau darauf ausgelegt, diesen Instinkt auszunutzen, was regelbasierte Komplexitätsanforderungen zu einer schwächeren Verteidigung als Länge allein macht.

Vergleichstabelle für Brute-Force-Angriffe

Die Verwaltung von Anmeldedaten in einem großen Team schafft genau die Angriffsfläche, die Brute-Force-Kampagnen ausnutzen. Erfahren Sie, wie Passwork Team-Tresore mit rollenbasiertem Zugriff und durchgesetzten Passwortrichtlinien strukturiert

Praxisbeispiele für Brute-Force-Angriffe (2025)

Brute-Force- und Credential-Stuffing-Angriffe stellen weiterhin eine erhebliche Bedrohung dar und entwickeln sich in Raffinesse und Umfang weiter. Die folgenden Fälle aus 2025 und 2026 verdeutlichen die anhaltenden Risiken und die kritische Bedeutung robuster Authentifizierung und Sicherheitspraktiken.

Australische Superannuation-Fonds — März 2025

Angriffstyp: Credential Stuffing (koordiniert, Multi-Target).

Am Wochenende vom 29.–30. März 2025 wurden fünf große australische Pensionsfonds (AustralianSuper, REST Super, Hostplus, Australian Retirement Trust und Insignia Financial) gleichzeitig mit Combo-Listen aus unabhängigen früheren Breaches angegriffen. Über 20.000 Konten wurden kompromittiert.

Vier AustralianSuper-Mitglieder verloren zusammen 500.000 AUD. REST schaltete sein MemberAccess-Portal vollständig ab, nachdem bei ca. 8.000 Mitgliedern persönliche Daten offengelegt worden waren.

23andMe — 2023 → regulatorische Konsequenzen 2025

Angriffstyp: Credential Stuffing

Zwischen April und September 2023 testeten Angreifer Anmeldedaten aus unabhängigen Breaches gegen 23andMe-Konten. Durch die DNA-Relatives-Funktion kaskadierten anfängliche Kompromittierungen in die Offenlegung genetischer und Abstammungsdaten von etwa 6,9 Millionen Nutzern — von denen die meisten nie direkt angegriffen worden waren.

„Mega Leak" — 16 Milliarden Anmeldedaten offengelegt — Juni 2025

Angriffstyp: Credential Stuffing (Quelldaten)

Im Juni 2025 entdeckten Cybernews-Forscher ca. 30 Datensätze mit über 16 Milliarden Anmeldedatensätzen — URLs, Benutzernamen und Klartext-Passwörter. Die Daten wurden hauptsächlich durch Infostealer-Malware gesammelt, die auf Verbrauchergeräte abzielte. Betroffene Plattformen waren unter anderem Google, Apple und Facebook. Bemerkenswert: BleepingComputer bestätigte, dass die Datensätze einen erheblichen Anteil recycelter Anmeldedaten aus älteren Breaches enthalten — nicht alle Datensätze stellen also frische Offenlegungen dar.

Jaguar Land Rover — März 2025 + September 2025

Angriffstyp: Credential Stuffing / gestohlene Anmeldedaten (Infostealer-Herkunft)

Im März 2025 durchbrach die HELLCAT-Ransomware-Gruppe JLR mit gestohlenen Jira-Anmeldedaten, die durch Infostealer-Malware gesammelt wurden. Bedrohungsakteur „Rey" leakte am 10. März ca. 700 interne Dokumente. Tage später nutzte ein zweiter Akteur „APTS" Anmeldedaten aus dem Jahr 2021 — die einem Drittanbieter-Auftragnehmer gehörten — um auf denselben Jira-Server zuzugreifen und weitere ca. 350 GB Daten zu leaken, darunter Quellcode, Entwicklungsprotokolle und Mitarbeiterdaten.

Im September 2025 legte ein separater Angriff, der einer Gruppe namens „Scattered Spider Lapsus$ Hunters" zugeschrieben wurde, globale IT-Systeme lahm und stoppte die Produktion im Halewood-Werk, wobei Mitarbeiter nach Hause geschickt wurden.

Zusammenfassungstabelle

Wie erkennt man einen Brute-Force-Angriff?

Prävention ist das Ziel, aber Erkennung ist das Sicherheitsnetz. Brute-Force-Angriffe hinterlassen konsistente Signaturen in Authentifizierungs-Logs — wenn Sie wissen, worauf Sie achten müssen.

• Spitzen bei fehlgeschlagenen Anmeldeversuchen — Ein plötzlicher Anstieg von Authentifizierungsfehlern gegen ein einzelnes Konto oder verteilt über viele ist der direkteste Indikator. Legen Sie eine Baseline für Ihre Umgebung fest und alarmieren Sie bei Abweichungen.
• Mehrere Sperren von derselben Quell-IP — Selbst verteilte Angriffe hinterlassen teilweise Muster. Wiederholte Sperren, die vom selben IP-Bereich oder ASN (Autonomous System Number) stammen, deuten auf automatisierte Aktivität hin.
• Unmögliche Reisen — Ein Benutzer, der sich von London und dann innerhalb von 30 Minuten von Singapur authentifiziert, löst in modernen SIEM- und Identity-Plattformen automatisch eine Markierung aus. Das Signal allein ist nicht schlüssig: VPN-Exit-Nodes, Split-Tunneling-Konfigurationen und Cloud-Proxy-Dienste produzieren routinemäßig False Positives. Der Wert liegt in der Untersuchung, die es auslöst — nicht in der Annahme, die es bestätigt.
• Hohes Anfragevolumen an Authentifizierungs-Endpunkte — Hunderte von POST-Anfragen pro Minute an /login oder /api/auth von einer einzelnen Quelle sind kein organischer Traffic. Überwachen Sie Ihre Login-Endpunkte auf Anfrageraten, die die menschliche Tippgeschwindigkeit überschreiten.
• Verteilte Low-and-Slow-Muster — Password Spraying vermeidet gezielt das Auslösen von Sperren pro Konto. Achten Sie auf ein Muster, bei dem viele verschiedene Konten jeweils genau einen oder zwei fehlgeschlagene Versuche innerhalb eines kurzen Zeitfensters erhalten — dies ist die Spraying-Signatur.
• Ungewöhnliche User-Agent-Strings oder fehlende Header — Automatisierte Tools senden oft Anfragen mit generischen oder fehlenden User-Agent-Strings, fehlenden Standard-Browser-Headern oder mit ungewöhnlichen TLS-Fingerprints.

Wie verhindert man Brute-Force-Angriffe?

Die Verteidigung gegen Brute Force ist ein Stack. Jede Schicht kompensiert die Schwächen der anderen.

Starke Passwortrichtlinien durchsetzen

Länge ist wichtiger als Komplexität. Eine 16-Zeichen-Passphrase ist exponentiell schwerer zu knacken als ein 8-Zeichen-String mit gemischten Zeichen. Bewegen Sie Ihre Organisation weg von Mindestlängen-Richtlinien, die technisch P@ssw0rd erlauben, hin zu Mindest-Entropie-Richtlinien, die echte Unvorhersehbarkeit erfordern. Lesen Sie Best Practices für Enterprise Password Management für ein strukturiertes Framework.

Schlüsselanforderungen gemäß NIST SP 800-63B:

• Mindestens 15 Zeichen für Konten ohne MFA; mindestens 8 mit durchgesetztem MFA
• Keine willkürlichen Komplexitätsregeln, die vorhersagbare Muster erzeugen
• Maximale Länge von mindestens 64 Zeichen zur Unterstützung von Passphrasen
• Blockieren von Passwörtern, die in Breach-Datenbanken erscheinen — neue Anmeldedaten bei der Erstellung gegen Dienste wie Have I Been Pwned prüfen, nicht erst danach

Anmeldedaten gegen Breach-Datenbanken prüfen

Bevor ein Passwort akzeptiert wird, überprüfen Sie, ob es nicht bereits in einem bekannten Datenleck aufgetaucht ist. NIST SP 800-63B und OWASP verlangen dies als separate Kontrolle — getrennt von Passwortlänge- oder Komplexitätsregeln. Ein Angreifer, der einen Dictionary-Angriff gegen Ihre Systeme ausführt, arbeitet mit denselben geleakten Datensätzen. Das Blockieren dieser Passwörter bei der Registrierung entfernt sie vollständig von der Angriffsfläche.

Multi-Faktor-Authentifizierung implementieren

MFA ist die wirksamste Einzelkontrolle gegen Credential-basierte Angriffe — ein kompromittiertes Passwort allein reicht nicht für den Zugang. Allerdings ist MFA nicht unfehlbar. MFA-Fatigue-Angriffe — bei denen Angreifer wiederholte Push-Benachrichtigungen senden, bis ein Benutzer aus Frustration eine genehmigt — haben MFA bei großen Organisationen umgangen. Phishing-resistente MFA-Methoden wie FIDO2 und Passkeys eliminieren diesen Vektor vollständig.

Kontosperren und progressive Verzögerungen konfigurieren

Konfigurieren Sie Authentifizierungssysteme so, dass Konten nach einer definierten Anzahl fehlgeschlagener Versuche (typischerweise 5–10) gesperrt werden, oder implementieren Sie progressive Verzögerungen, die mit jedem Fehlversuch exponentiell zunehmen. Progressive Verzögerungen sind oft vorzuziehen gegenüber harten Sperren, die selbst für Denial-of-Service gegen legitime Benutzer missbraucht werden können.

Rate Limiting auf IP- und ASN-Ebene anwenden

Kontosperren schützen einzelne Konten. Rate Limiting schützt den Authentifizierungs-Endpunkt selbst. Dies sind unterschiedliche Kontrollen mit unterschiedlichen Zielen. Begrenzen Sie die Anzahl der Anmeldeanfragen pro IP-Adresse pro Zeitfenster. Eskalieren Sie zu ASN-Level-Blockierung, wenn verteilte Muster auftreten.

CAPTCHA und Bot-Management einsetzen

CAPTCHA-Challenges unterscheiden menschliche Benutzer von automatisierten Skripten auf der Authentifizierungsebene. Moderne Bot-Management-Plattformen gehen weiter und analysieren Verhaltenssignale — Mausbewegung, Tipprhythmus, TLS-Fingerprints — um nicht-menschlichen Traffic zu identifizieren, bevor er das Anmeldeformular erreicht.

Zero-Trust-Architektur implementieren

Zero Trust basiert auf dem Prinzip, dass kein Benutzer, Gerät oder Netzwerksegment von Natur aus vertrauenswürdig ist. Selbst nach erfolgreicher Authentifizierung wird der Zugriff kontinuierlich basierend auf Kontext verifiziert: Gerätezustand, Standort, Verhalten und Least-Privilege-Zugriffsregeln. Wenn ein Brute-Force-Angriff ein Konto kompromittiert, begrenzt Zero Trust den Explosionsradius, indem laterale Bewegung zu anderen Systemen und Ressourcen verhindert wird.

Authentifizierungs-Logs überwachen und bei Anomalien alarmieren

Erkennung ist eine präventive Kontrolle, nicht nur eine reaktive. Das Erkennen eines laufenden Angriffs gibt Ihrem Team Zeit, die Quelle zu blockieren, Sitzungen ungültig zu machen und den Schaden einzudämmen. Konfigurieren Sie SIEM-Alarme für: Spitzen bei fehlgeschlagenen Authentifizierungsversuchen, Unmögliche-Reisen-Ereignisse, hohes Anfragevolumen an Login-Endpunkte und das Low-and-Slow-Spraying-Muster, bei dem viele Konten jeweils genau einen oder zwei Fehlversuche innerhalb eines kurzen Zeitfensters erhalten.

Einen Passwort-Manager verwenden

Passwortwiederverwendung ist der Treibstoff, der Credential Stuffing im großen Maßstab praktikabel macht. Wenn ein Breach Anmeldedaten offenlegt, wird jeder andere Dienst, bei dem dieses Passwort wiederverwendet wird, automatisch verwundbar — ohne zusätzlichen Aufwand des Angreifers. Ein Passwort-Manager eliminiert dies, indem er ein einzigartiges Passwort mit hoher Entropie für jedes Konto generiert und speichert, wodurch Wiederverwendung strukturell unmöglich wird.

Für einzelne Benutzer erreicht jeder seriöse Passwort-Manager dies. Für Teams und Organisationen sind die Anforderungen anders und die Einsätze höher.

Passwork wurde speziell für diese Umgebung entwickelt. Es bietet IT-Teams einen zentralisierten, strukturierten Tresor, in dem Anmeldedaten mit granularer, rollenbasierter Zugriffskontrolle organisiert sind: Jeder Benutzer sieht nur das, was seine Rolle erlaubt, nicht mehr. Geteilte Anmeldedaten werden in geteilten Tresoren mit definierten Berechtigungen gespeichert.

Mehrere Funktionen von Passwork adressieren direkt die in diesem Artikel behandelten Angriffsvektoren:

• Anpassbarer Passwort-Generator — erzwingt Längen- und Komplexitätsanforderungen bei der Erstellung, sodass die Richtlinien-Compliance nicht dem individuellen Urteil überlassen wird.
• Passwortsicherheits-Dashboard — verfolgt kontinuierlich den Status aller gespeicherten Anmeldedaten und markiert schwache, wiederverwendete, veraltete und potenziell kompromittierte Passwörter im gesamten Tresor. Wenn ein Mitarbeiter das Unternehmen verlässt, markiert Passwork automatisch jede Anmeldedaten, auf die diese Person Zugriff hatte, als potenziell kompromittiert und fordert zur Rotation auf.
• Zero-Knowledge-Client-seitige Verschlüsselung — Anmeldedaten werden auf der Client-Seite verschlüsselt, bevor sie den Server erreichen. Selbst mit vollem Zugriff auf die Datenbank oder die zugrundeliegende Infrastruktur erhält ein Angreifer nichts Lesbares. Der Verschlüsselungsschlüssel verlässt nie das Gerät des Benutzers.
• Vollständiges Audit-Log — jede Aktion im Tresor wird protokolliert: Wer hat auf was zugegriffen, wann und von wo. Dies ist die Sichtbarkeitsebene, die Post-Incident-Untersuchungen ermöglicht und die Compliance mit DSGVO, NIS2 und ähnlichen Frameworks unterstützt.
• Zwei-Faktor-Authentifizierung, Passkeys und Hardware-Sicherheitsschlüssel — Passwork unterstützt 2FA über Authenticator-Apps und WebAuthn-basierte Authentifizierung einschließlich Biometrie und FIDO2-Hardware-Schlüssel und fügt eine zweite Schicht über das Tresor-Passwort selbst hinaus hinzu.
• Konfigurierbare Kontosperre — Administratoren legen den Schwellenwert für fehlgeschlagene Anmeldeversuche fest, nach dem ein Konto gesperrt wird. Dies wendet Brute-Force- und Credential-Stuffing-Schutz auf Tresor-Ebene an — nicht nur am Netzwerkperimeter.
• Self-Hosted-Deployment — Passwork läuft vollständig innerhalb Ihrer eigenen Infrastruktur. Anmeldedaten verlassen nie Ihre Umgebung, werden auf Server- und Client-Seite mit AES-256 verschlüsselt (Zero-Knowledge-Architektur) und werden ausschließlich von Ihrem Team verwaltet.

Der JLR-Breach illustrierte, was ohne diese Struktur passiert: Anmeldedaten aus 2021, die einem Drittanbieter-Auftragnehmer gehörten, waren vier Jahre später noch gültig, ohne Rotation und ohne MFA auf der Jira-Instanz. Ein zentralisierter Tresor mit durchgesetzten Rotationsrichtlinien und einem Offboarding-Workflow hätte dieses Fenster geschlossen, bevor es ausgenutzt wurde.

Fazit

Brute-Force-Angriffe sind in der Praxis skalierbarer geworden. Günstige GPU-Rechenleistung, KI-gestützte Wordlist-Generierung und massive Botnets bedeuten, dass das, was einst erhebliche Ressourcen erforderte, jetzt fast keine mehr benötigt. Der 37-%-Anteil von Webanwendungsangriffen, die im Verizon DBIR 2025 Brute Force zugeschrieben werden, ist das Ergebnis dieser Zugänglichkeit.

Die gute Nachricht: Die Abwehrmaßnahmen funktionieren. MFA, starke und einzigartige Passwörter, Kontosperr-Richtlinien und Verhaltensüberwachung machen Brute-Force-Angriffe gemeinsam unpraktikabel gegen ein gehärtetes Ziel. Angreifer bewegen sich in Richtung des geringsten Widerstands — was bedeutet, dass Organisationen, die mehrschichtige Authentifizierungssicherheit effektiv implementieren, sich selbst aus dem Pool leichter Ziele entfernen.

Das eigentliche Risiko besteht darin, dass sie inkonsistent angewendet werden — ein Team nutzt MFA, ein anderes nicht. Geteilte Anmeldedaten in Tabellenkalkulationen gespeichert; Passwortrichtlinien, die auf dem Papier existieren, aber technisch nicht durchgesetzt werden. Das Schließen dieser Lücken ist, wo die eigentliche Arbeit liegt.

Passwork bietet IT-Teams einen strukturierten, prüffähigen Credential-Tresor mit rollenbasiertem Zugriff — entwickelt für Umgebungen, in denen Inkonsistenz Risiken schafft. Vollständiges Self-Hosted-Deployment und Zero-Knowledge-Verschlüsselung — auf Ihrer Infrastruktur vom ersten Tag an. Kostenlose Testversion erhalten

Häufig gestellte Fragen

Was ist der Unterschied zwischen einem Brute-Force-Angriff und einem Dictionary-Angriff?

Ein einfacher Brute-Force-Angriff probiert systematisch jede mögliche Zeichenkombination ohne Vorkenntnisse. Ein Dictionary-Angriff verwendet eine kuratierte Liste wahrscheinlicher Passwörter — gängige Wörter, bekannte Phrasen, geleakte Anmeldedaten — um den Suchraum zu reduzieren. Dictionary-Angriffe sind schneller und gezielter; einfache Brute Force ist erschöpfend, aber langsamer. Beide werden durch lange, zufällige Passwörter besiegt, die nicht natürlicher Sprache ähneln.

Können Brute-Force-Angriffe MFA umgehen?

Standard-Brute-Force kann MFA nicht direkt umgehen — ein korrektes Passwort allein reicht nicht für den Zugang. Allerdings nutzen Angreifer benachbarte Techniken: MFA-Fatigue (wiederholtes Senden von Push-Benachrichtigungen, bis der Benutzer eine genehmigt), Echtzeit-Phishing (Abfangen und Wiederverwenden von MFA-Token) und Session-Hijacking (Stehlen authentifizierter Sitzungscookies nach dem Login). Phishing-resistente MFA-Methoden wie FIDO2-Hardware-Schlüssel und Passkeys eliminieren die Phishing- und Fatigue-Vektoren vollständig.

Sind Brute-Force-Angriffe illegal?

Ja. Unbefugte Brute-Force-Angriffe gegen Systeme, die Sie nicht besitzen oder für die Sie keine ausdrückliche Genehmigung zum Testen haben, sind nach der Computerbetruggesetzgebung in den meisten Rechtsordnungen illegal — einschließlich des Computer Fraud and Abuse Act (CFAA) in den Vereinigten Staaten, des Computer Misuse Act im Vereinigten Königreich und der EU-Richtlinie über Angriffe auf Informationssysteme (2013/40/EU). Die Strafen umfassen erhebliche Geldstrafen und Freiheitsstrafen. Autorisierte Penetrationstests erfordern eine schriftliche Genehmigung des Systemeigentümers.

Wie lange dauert es, ein Passwort mit Brute Force zu knacken?

Das hängt von der Passwortlänge, dem Zeichensatz und der Art der Hash-Speicherung ab. Ein 8-Zeichen-MD5-gehashtes Passwort fällt in unter einer Stunde gegen einen modernen GPU-Cluster. Dasselbe Passwort, mit bcrypt bei hohem Kostenfaktor gehasht, kann auf derselben Hardware Jahre dauern. Länge ist die zuverlässigste Variable unter Ihrer Kontrolle: Jedes zusätzliche Zeichen multipliziert den Suchraum exponentiell. Eine 16-Zeichen-Passphrase gegen bcrypt ist mit aktueller Hardware rechnerisch unpraktikabel zu knacken.

Was ist Credential Stuffing und wie unterscheidet es sich von Brute Force?

Credential Stuffing verwendet verifizierte Benutzernamen/Passwort-Paare aus früheren Datenschutzverletzungen und testet sie gegen andere Dienste. Es rät nicht — es verwendet wieder. Brute Force generiert oder durchläuft Kombinationen ohne Vorkenntnisse über gültige Anmeldedaten. Credential Stuffing ist schneller und gezielter, weil es mit echten Anmeldedaten arbeitet, und es hat speziell wegen der Passwortwiederverwendung über Dienste hinweg Erfolg.

Welche Systeme werden am häufigsten von Brute-Force-Angriffen angegriffen?

Authentifizierungs-Endpunkte mit öffentlicher Exposition tragen das höchste Risiko: SSH- und RDP-Dienste, VPN-Portale, Webanwendungs-Anmeldeseiten, Admin-Panels (WordPress /wp-admin, cPanel) und API-Authentifizierungs-Endpunkte. Die Kampagne 2025, die 2,8 Millionen IPs nutzte, konzentrierte sich speziell auf VPN-Gateways und Firewalls — Perimeter-Geräte, die bei Kompromittierung direkten Zugang zu internen Netzwerken bieten.

Introducción

A las 3:14 AM, nadie está vigilando los registros de autenticación. Un script ejecutándose en una instancia en la nube alquilada envía su intento de inicio de sesión número diez mil a un portal VPN. A las 3:17 AM, recibe una respuesta diferente a las demás. Acceso concedido. No hay malware, ni ingeniería social, ni amenaza interna. Solo una contraseña débil, paciencia automatizada y una brecha en la supervisión.

Uno de cada tres ataques exitosos contra aplicaciones web ahora comienza de la misma manera: un script automatizado probando credenciales hasta que algo funciona. Según el Informe de Investigaciones de Filtraciones de Datos 2025 de Verizon, los ataques de fuerza bruta contra aplicaciones web básicas casi se triplicaron durante el último año — saltando de aproximadamente 20% a 60%. Es una señal de que los ataques automatizados de credenciales se han convertido en un arma principal, no en un recurso de respaldo.

La mecánica subyacente no ha cambiado: probar combinaciones hasta que una funcione. Lo que ha cambiado es la velocidad, escala e inteligencia detrás de esos intentos. Los clústeres de GPU modernos, la generación de listas de palabras asistida por IA y las botnets que abarcan millones de dispositivos comprometidos han transformado lo que alguna vez fue un ataque lento y ruidoso en algo rápido, distribuido y difícil de detectar.

Este artículo cubre qué son los ataques de fuerza bruta, cómo han evolucionado en 2026, las seis variantes principales, ejemplos del mundo real de 2025–2026 y una estrategia de defensa por capas que su equipo puede implementar hoy.

Puntos clave

• Los ataques de fuerza bruta son ataques automatizados de credenciales — los scripts prueban sistemáticamente combinaciones de nombre de usuario y contraseña hasta que una funciona, explotando contraseñas débiles, reutilizadas o predecibles en lugar de vulnerabilidades de software.
• Seis variantes distintas atacan diferentes debilidades: fuerza bruta simple, ataques de diccionario, credential stuffing, password spraying, fuerza bruta inversa y ataques híbridos — cada uno diseñado para evadir un conjunto específico de defensas.
• El hardware moderno ha hecho indefendibles las contraseñas débiles: un clúster de GPU puede descifrar una contraseña de 8 caracteres con hash MD5 en minutos. La longitud de la contraseña y el hash seguro son lo que determina la resistencia en el mundo real.
• Las defensas por capas funcionan, pero solo cuando se aplican consistentemente. MFA, políticas de contraseñas robustas, verificación contra bases de datos de filtraciones, bloqueo de cuentas, limitación de velocidad y un gestor de contraseñas hacen colectivamente que los ataques de fuerza bruta sean imprácticos. Cualquier brecha individual es suficiente para que un atacante la explote.
• La detección es un control preventivo, no solo reactivo. Reconocer las firmas de ataque — picos de inicios de sesión fallidos, patrones de spraying lentos y graduales, viajes imposibles — le da a su equipo tiempo para bloquear la fuente antes de que las credenciales sean validadas.
• Un gestor de contraseñas es la solución estructural para la reutilización de credenciales — la causa raíz detrás del credential stuffing. Para equipos, también impone la rotación, marca credenciales comprometidas y cierra la brecha de desvinculación que deja credenciales obsoletas válidas durante años.

¿Qué es un ataque de fuerza bruta?

Un ataque de fuerza bruta obtiene acceso no autorizado a un sistema probando sistemáticamente todas las combinaciones posibles de credenciales (nombres de usuario, contraseñas o claves de cifrado) hasta encontrar la correcta. Explota el comportamiento humano: contraseñas débiles, reutilizadas o predecibles.

Piénselo como probar cada llave de un llavero. Dado suficiente tiempo y potencia de cómputo, una eventualmente encajará. El objetivo del atacante es reducir ese tiempo a algo práctico y, en 2026, el hardware moderno lo hace cada vez más alcanzable.

Los ataques de fuerza bruta apuntan a endpoints de autenticación: páginas de inicio de sesión, servicios SSH y RDP, portales VPN, puertas de enlace API y paneles de administración. Cualquier sistema que acepte un nombre de usuario y contraseña es un objetivo potencial.

Cómo funcionan los ataques de fuerza bruta en 2026

En esencia, un ataque de fuerza bruta es automatización a escala. Un atacante despliega un script o herramienta que envía combinaciones de credenciales al endpoint de autenticación de un sistema objetivo en rápida sucesión. El script registra las coincidencias exitosas y continúa.

Lo que separa 2026 de hace una década es la infraestructura detrás de esos scripts.

El factor de la IA y el hardware

Las tarjetas gráficas modernas (originalmente diseñadas para juegos y aprendizaje automático) son excepcionalmente eficientes en computación paralela, que es exactamente lo que requiere el descifrado de contraseñas. Un clúster de 12 GPU NVIDIA RTX 5090 puede probar cientos de miles de millones de combinaciones de hash MD5 por segundo (Hive Systems).

Contra credenciales con hash débil, una contraseña de 8 caracteres cae en minutos — o menos. Contra bcrypt con configuraciones de costo modernas, el mismo hardware puede tardar años. La diferencia no está en el hardware del atacante. Está en si el sistema objetivo almacena las contraseñas de forma segura.

Los modelos de aprendizaje automático entrenados con conjuntos de datos de contraseñas filtradas (herramientas como PassGAN, construidas sobre redes generativas adversarias) aprenden distribuciones de contraseñas del mundo real sin reglas escritas por humanos. Predicen patrones probables: fechas de nacimiento añadidas a nombres, sustituciones comunes de caracteres, frases culturalmente específicas.

En pruebas contra el conjunto de datos de la filtración RockYou, PassGAN coincidió con el 47% de las contraseñas reales. Combinado con herramientas de descifrado convencionales, descubrió un 24% más de coincidencias que cualquiera de los enfoques por separado. El espacio de búsqueda no se reduce por fuerza bruta — se reduce por predicción.

La amenaza cuántica

La computación cuántica utiliza fenómenos mecánico-cuánticos para procesar información de maneras que las computadoras clásicas no pueden. Mientras un procesador clásico trabaja a través de posibilidades secuencialmente, un sistema cuántico evalúa muchos estados simultáneamente. Aplicado a la criptografía, ese paralelismo se convierte en una amenaza directa a los problemas matemáticos que sustentan el cifrado actual.

La computación cuántica introduce un riesgo a más largo plazo. La hoja de ruta cuántica de IBM proyecta que las computadoras cuánticas criptográficamente relevantes podrían socavar los estándares actuales de cifrado asimétrico dentro de esta década.

Los ataques cuánticos a contraseñas hasheadas siguen siendo teóricos, pero las organizaciones que gestionan secretos de larga duración y claves de cifrado deberían comenzar a evaluar los estándares de criptografía post-cuántica — NIST finalizó sus primeros estándares post-cuánticos en 2024.

Botnets y ataques distribuidos

Una botnet es una red de dispositivos comprometidos (servidores, routers, endpoints IoT, computadoras personales) controlados remotamente por un atacante sin el conocimiento de sus propietarios. Cada dispositivo actúa como un nodo independiente, capaz de enviar solicitudes, sondear sistemas o enviar intentos de inicio de sesión. La escala puede alcanzar millones de máquinas operando de forma coordinada.

Los atacantes rara vez operan desde una sola IP. Las campañas modernas de fuerza bruta usan botnets para distribuir intentos de inicio de sesión a través de diferentes direcciones de origen, evadiendo la limitación de velocidad basada en IP y el bloqueo geográfico.

A principios de 2025, la Shadowserver Foundation rastreó una campaña que utilizaba 2,8 millones de direcciones IP diariamente para atacar portales de inicio de sesión VPN de Palo Alto Networks, Ivanti y SonicWall (BleepingComputer).

Los nodos atacantes eran predominantemente routers MikroTik, Huawei y Cisco comprometidos — dispositivos secuestrados distribuidos en docenas de países, con el clúster más grande originándose en Brasil. El tráfico se enrutaba a través de redes de proxy residenciales, haciendo que cada intento pareciera provenir de un usuario doméstico normal en lugar de un bot. Las defensas estándar basadas en IP veían lo que parecía tráfico normal.

Tipos de ataques de fuerza bruta

Los ataques de fuerza bruta comparten un principio: obtener acceso probando sistemáticamente credenciales hasta que algo funcione. Los métodos difieren en qué prueban, cómo obtienen sus datos y qué defensas están diseñados para evadir.

1. Ataque de fuerza bruta simple

La variante más directa: cada combinación de caracteres posible se prueba en secuencia — aaa, aab, aac — hasta encontrar una coincidencia. No se requiere conocimiento previo del objetivo. El ataque depende enteramente de la potencia computacional.

Es efectivo solo contra contraseñas cortas o simples. Contra una contraseña de 8 caracteres usando caracteres mixtos, los clústeres de GPU modernos pueden completar la búsqueda en horas. Más allá de 12 caracteres, el mismo enfoque se vuelve computacionalmente impráctico — el espacio de búsqueda crece exponencialmente con cada carácter añadido.

2. Ataque de diccionario

Un ataque de diccionario reemplaza la enumeración exhaustiva con una lista curada de contraseñas probables (palabras, frases y credenciales conocidas), reduciendo drásticamente el espacio de búsqueda. El atacante apuesta por la previsibilidad humana en lugar de la computación bruta.

Estas listas van desde compilaciones básicas de las 10.000 contraseñas más comunes hasta conjuntos de datos de varios gigabytes construidos a partir de credenciales filtradas, jerga regional y terminología específica de la industria. Cualquier contraseña que se parezca al lenguaje natural es vulnerable. La aleatoriedad es la única defensa confiable.

3. Credential stuffing

El credential stuffing es la reutilización automatizada de pares de nombre de usuario y contraseña robados de filtraciones de datos anteriores. Los atacantes toman pares de nombre de usuario y contraseña y los prueban contra otros servicios, explotando el hecho de que muchos usuarios reutilizan las mismas credenciales en múltiples cuentas.

En julio de 2024, una compilación de casi 10 mil millones de contraseñas únicas — denominada RockYou2024 — fue publicada en un foro criminal, proporcionando a los atacantes un conjunto de credenciales sin precedentes del cual trabajar (Cybernews, 2024).

Comprender los peligros de la reutilización de contraseñas es un contexto esencial aquí — una sola cuenta comprometida en una plataforma puede propagarse en acceso a través de toda una huella digital.

4. Password spraying

El password spraying invierte el enfoque típico. En lugar de probar muchas contraseñas contra una cuenta (lo que activa bloqueos), el atacante prueba una o dos contraseñas comunes — Password1!, Welcome2026 — en miles de cuentas.

Se mantiene por debajo de los umbrales de bloqueo y es particularmente efectivo contra grandes organizaciones con políticas de contraseñas débiles. Más del 97% de los ataques de identidad involucran password spraying o fuerza bruta, según el Informe de Defensa Digital de Microsoft 2025.

5. Ataque de fuerza bruta inversa

Un ataque de fuerza bruta inversa comienza con una contraseña conocida (típicamente obtenida de una filtración o un valor predeterminado conocido) y la prueba sistemáticamente contra una lista de nombres de usuario. La credencial está fija; la identidad es la incógnita.

Este método es más efectivo cuando la contraseña objetivo es ampliamente compartida: una contraseña corporativa predeterminada distribuida durante la incorporación, un patrón común exigido por una política débil, o una credencial que apareció en una filtración anterior. Donde un ataque estándar sondea una cuenta en profundidad, un ataque inverso sondea muchas cuentas con precisión quirúrgica.

6. Ataque híbrido de fuerza bruta

Un ataque híbrido de fuerza bruta combina palabras de diccionario con mutaciones programáticas — añadiendo números, años o caracteres especiales (Summer2026!, admin@123), sustituyendo letras con símbolos o cambiando mayúsculas. Está diseñado para descifrar contraseñas que parecen complejas pero siguen patrones de construcción predecibles.

Estos ataques apuntan a la brecha entre la política de contraseñas y el comportamiento humano. Cuando se requiere que los usuarios «compliquen» una contraseña, rara vez introducen verdadera aleatoriedad — añaden 1! a una palabra familiar o ponen en mayúscula la primera letra. Los ataques híbridos están construidos para explotar exactamente ese instinto, haciendo que los requisitos de complejidad basados en reglas sean una defensa más débil que la longitud sola.

Tabla comparativa de ataques de fuerza bruta

Gestionar credenciales en un equipo grande crea exactamente la superficie de ataque que explotan las campañas de fuerza bruta. Vea cómo Passwork estructura bóvedas de equipo con acceso basado en roles y políticas de contraseñas aplicadas

Ejemplos reales de ataques de fuerza bruta (2025)

Los ataques de fuerza bruta y credential stuffing continúan siendo una amenaza significativa, evolucionando en sofisticación y escala. Los siguientes casos de 2025 y 2026 destacan los riesgos persistentes y la importancia crítica de prácticas robustas de autenticación y seguridad.

Fondos de jubilación australianos — marzo 2025

Tipo de ataque: Credential stuffing (coordinado, multi-objetivo).

Durante el fin de semana del 29–30 de marzo de 2025, cinco importantes fondos de pensiones australianos (AustralianSuper, REST Super, Hostplus, Australian Retirement Trust e Insignia Financial) fueron atacados simultáneamente usando listas combinadas de filtraciones anteriores no relacionadas. Más de 20.000 cuentas fueron comprometidas.

Cuatro miembros de AustralianSuper perdieron colectivamente 500.000 AUD. REST cerró su portal MemberAccess por completo después de que ~8.000 miembros tuvieran datos personales expuestos.

23andMe — 2023 → consecuencias regulatorias en 2025

Tipo de ataque: Credential stuffing

Entre abril y septiembre de 2023, los atacantes probaron credenciales de filtraciones no relacionadas contra cuentas de 23andMe. A través de la función DNA Relatives, los compromisos iniciales se propagaron en exposición de datos genéticos y de ascendencia pertenecientes a aproximadamente 6,9 millones de usuarios — la mayoría de los cuales nunca habían sido atacados directamente.

«Mega filtración» — 16 mil millones de credenciales expuestas — junio 2025

Tipo de ataque: Credential stuffing (datos fuente)

En junio de 2025, investigadores de Cybernews descubrieron ~30 conjuntos de datos que contenían más de 16 mil millones de registros de inicio de sesión — URL, nombres de usuario y contraseñas en texto plano. Los datos fueron recolectados principalmente por malware infostealer dirigido a dispositivos de consumidores. Las plataformas afectadas incluyeron Google, Apple, Facebook y otras. Notablemente, BleepingComputer confirmó que los conjuntos de datos incluyen una proporción significativa de credenciales recicladas de filtraciones anteriores, lo que significa que no todos los registros representan exposiciones nuevas.

Jaguar Land Rover — marzo 2025 + septiembre 2025

Tipo de ataque: Credential stuffing / credenciales robadas (fuente infostealer)

En marzo de 2025, el grupo de ransomware HELLCAT vulneró JLR usando credenciales de Jira robadas recolectadas mediante malware infostealer. El actor de amenazas «Rey» filtró ~700 documentos internos el 10 de marzo. Días después, un segundo actor «APTS» usó credenciales que databan de 2021 — pertenecientes a un contratista externo — para acceder al mismo servidor Jira y filtrar ~350 GB adicionales de datos incluyendo código fuente, registros de desarrollo y expedientes de empleados.

En septiembre de 2025, un ataque separado atribuido a un grupo que se autodenominaba «Scattered Spider Lapsus$ Hunters» paralizó los sistemas de TI globales y detuvo la fabricación en la planta de Halewood, enviando a los empleados a casa.

Tabla resumen

Cómo detectar un ataque de fuerza bruta

La prevención es el objetivo, pero la detección es la red de seguridad. Los ataques de fuerza bruta dejan firmas consistentes en los registros de autenticación — si sabe qué buscar.

• Picos en intentos de inicio de sesión fallidos — Un aumento repentino en fallos de autenticación contra una sola cuenta, o distribuidos en muchas, es el indicador más directo. Establezca una línea base para su entorno y alerte sobre desviaciones.
• Múltiples bloqueos desde la misma IP de origen — Incluso los ataques distribuidos dejan patrones parciales. Bloqueos repetidos originados desde el mismo rango de IP o ASN (Número de Sistema Autónomo) sugieren actividad automatizada.
• Viaje imposible — Un usuario autenticándose desde Londres y luego desde Singapur en 30 minutos activa una alerta automática en plataformas SIEM y de identidad modernas. La señal por sí sola no es concluyente: los nodos de salida VPN, las configuraciones de túnel dividido y los servicios de proxy en la nube producen rutinariamente falsos positivos. El valor está en la investigación que provoca — no en la suposición que confirma.
• Alto volumen de solicitudes a endpoints de autenticación — Cientos de solicitudes POST por minuto a /login o /api/auth desde una sola fuente no es tráfico orgánico. Supervise sus endpoints de inicio de sesión para tasas de solicitud que excedan la velocidad de escritura humana.
• Patrones distribuidos lentos y graduales — El password spraying específicamente evita activar bloqueos por cuenta. Busque un patrón donde muchas cuentas diferentes reciben exactamente uno o dos intentos fallidos dentro de una ventana corta — esta es la firma del spraying.
• Cadenas de user-agent inusuales o encabezados faltantes — Las herramientas automatizadas a menudo envían solicitudes con cadenas de user-agent genéricas o ausentes, encabezados de navegador estándar faltantes o con huellas TLS inusuales.

Cómo prevenir ataques de fuerza bruta

La defensa contra la fuerza bruta es una pila. Cada capa compensa las debilidades de las otras.

Aplicar políticas de contraseñas robustas

La longitud importa más que la complejidad. Una frase de contraseña de 16 caracteres es exponencialmente más difícil de descifrar que una cadena de 8 caracteres de caracteres mixtos. Aleje a su organización de políticas de longitud mínima que técnicamente permiten P@ssw0rd y muévase hacia políticas de entropía mínima que requieran verdadera imprevisibilidad. Revise las mejores prácticas de gestión de contraseñas empresariales para un marco estructurado.

Requisitos clave según NIST SP 800-63B:

• Mínimo 15 caracteres para cuentas sin MFA; mínimo 8 con MFA aplicado
• Sin reglas de complejidad arbitrarias que produzcan patrones predecibles
• Longitud máxima de al menos 64 caracteres para soportar frases de contraseña
• Bloquear contraseñas que aparezcan en bases de datos de filtraciones — verificar nuevas credenciales contra servicios como Have I Been Pwned en el momento de creación, no después

Verificar credenciales contra bases de datos de filtraciones

Antes de aceptar una contraseña, verifique que no haya aparecido ya en una filtración de datos conocida. NIST SP 800-63B y OWASP requieren esto como un control distinto — separado de las reglas de longitud o complejidad de contraseña. Un atacante ejecutando un ataque de diccionario contra sus sistemas está trabajando con los mismos conjuntos de datos filtrados. Bloquear esas contraseñas en el registro las elimina de la superficie de ataque por completo.

Implementar autenticación multifactor

MFA es el control individual más efectivo contra ataques basados en credenciales — una contraseña comprometida por sí sola no es suficiente para el acceso. Dicho esto, MFA no es infalible. Los ataques de fatiga MFA — donde los atacantes envían notificaciones push repetidas hasta que un usuario aprueba una por frustración — han evadido MFA en organizaciones importantes. Los métodos MFA resistentes al phishing como FIDO2 y passkeys eliminan este vector por completo.

Configurar bloqueos de cuenta y retrasos progresivos

Configure los sistemas de autenticación para bloquear cuentas después de un número definido de intentos fallidos (típicamente 5–10), o implemente retrasos progresivos que aumenten exponencialmente con cada fallo. Los retrasos progresivos son a menudo preferibles a los bloqueos duros, que pueden ser utilizados como arma para denegación de servicio contra usuarios legítimos.

Aplicar limitación de velocidad a nivel de IP y ASN

El bloqueo de cuenta protege cuentas individuales. La limitación de velocidad protege el endpoint de autenticación en sí. Estos son controles diferentes con objetivos diferentes. Restrinja el número de solicitudes de inicio de sesión por dirección IP por ventana de tiempo. Escale al bloqueo a nivel de ASN cuando surjan patrones distribuidos.

Desplegar CAPTCHA y gestión de bots

Los desafíos CAPTCHA diferencian usuarios humanos de scripts automatizados en la capa de autenticación. Las plataformas modernas de gestión de bots van más allá, analizando señales de comportamiento — movimiento del ratón, cadencia de escritura, huellas TLS — para identificar tráfico no humano antes de que llegue al formulario de inicio de sesión.

Implementar arquitectura de confianza cero

La confianza cero opera bajo el principio de que ningún usuario, dispositivo o segmento de red es inherentemente confiable. Incluso después de una autenticación exitosa, el acceso se verifica continuamente según el contexto: salud del dispositivo, ubicación, comportamiento y reglas de acceso de mínimo privilegio. Si un ataque de fuerza bruta compromete una cuenta, la confianza cero limita el radio de explosión previniendo el movimiento lateral a otros sistemas y recursos.

Supervisar registros de autenticación y alertar sobre anomalías

La detección es un control preventivo, no solo reactivo. Detectar un ataque en progreso le da a su equipo tiempo para bloquear la fuente, invalidar sesiones y contener el daño. Configure alertas SIEM para: picos en intentos de autenticación fallidos, eventos de viaje imposible, alto volumen de solicitudes a endpoints de inicio de sesión y el patrón de spraying lento y gradual donde muchas cuentas reciben exactamente uno o dos fallos dentro de una ventana corta.

Usar un gestor de contraseñas

La reutilización de contraseñas es el combustible que hace viable el credential stuffing a escala. Cuando una filtración expone una credencial, cada otro servicio donde esa contraseña se reutiliza se vuelve vulnerable — automáticamente, sin ningún esfuerzo adicional del atacante. Un gestor de contraseñas elimina esto generando y almacenando una contraseña única de alta entropía para cada cuenta, haciendo la reutilización estructuralmente imposible.

Para usuarios individuales, cualquier gestor de contraseñas de buena reputación logra esto. Para equipos y organizaciones, los requisitos son diferentes y los riesgos son mayores.

Passwork está construido específicamente para este entorno. Proporciona a los equipos de TI una bóveda centralizada y estructurada donde las credenciales se organizan con control de acceso granular basado en roles: cada usuario ve solo lo que su rol permite, nada más. Las credenciales compartidas se almacenan en bóvedas compartidas con permisos definidos.

Varias características de Passwork abordan directamente los vectores de ataque cubiertos en este artículo:

• Generador de contraseñas personalizable — aplica requisitos de longitud y complejidad en el momento de creación, para que el cumplimiento de políticas no quede al juicio individual.
• Panel de seguridad de contraseñas — rastrea continuamente el estado de todas las credenciales almacenadas, marcando contraseñas débiles, reutilizadas, obsoletas y potencialmente comprometidas en toda la bóveda. Cuando un empleado se va, Passwork marca automáticamente cada credencial a la que tenía acceso como potencialmente comprometida y solicita la rotación.
• Cifrado de conocimiento cero del lado del cliente — las credenciales se cifran en el lado del cliente antes de llegar al servidor. Incluso con acceso completo a la base de datos o la infraestructura subyacente, un atacante no recupera nada legible. La clave de cifrado nunca sale del dispositivo del usuario.
• Registro de auditoría completo — cada acción en la bóveda se registra: quién accedió a qué, cuándo y desde dónde. Esta es la capa de visibilidad que hace posible la investigación post-incidente y apoya el cumplimiento con GDPR, NIS2 y marcos similares.
• Autenticación de dos factores, passkeys y llaves de seguridad de hardware — Passwork soporta 2FA mediante aplicaciones de autenticación y autenticación basada en WebAuthn incluyendo biometría y llaves de hardware FIDO2, añadiendo una segunda capa más allá de la contraseña de la bóveda en sí.
• Bloqueo de cuenta configurable — los administradores establecen el umbral de intentos de inicio de sesión fallidos después del cual una cuenta se bloquea. Esto aplica protección contra fuerza bruta y credential stuffing a nivel de la bóveda misma — no solo en el perímetro de red.
• Despliegue autoalojado — Passwork se ejecuta completamente dentro de su propia infraestructura. Los datos de credenciales nunca salen de su entorno, se cifran con AES-256 tanto en el lado del servidor como del cliente (arquitectura de conocimiento cero), y son gestionados exclusivamente por su equipo.

La filtración de JLR ilustró lo que sucede sin esta estructura: las credenciales de 2021 pertenecientes a un contratista externo seguían siendo válidas cuatro años después, sin rotación y sin MFA en la instancia de Jira. Una bóveda centralizada con políticas de rotación aplicadas y un flujo de trabajo de desvinculación habría cerrado esa ventana antes de que fuera explotada.

Conclusión

Los ataques de fuerza bruta se han vuelto más escalables en la práctica. La computación GPU barata, la generación de listas de palabras asistida por IA y las botnets masivas significan que lo que antes requería recursos significativos ahora no requiere casi ninguno. El 37% de los ataques a aplicaciones web atribuidos a fuerza bruta en el DBIR 2025 de Verizon es el resultado de esa accesibilidad.

La buena noticia: las defensas funcionan. MFA, contraseñas robustas y únicas, políticas de bloqueo de cuenta y supervisión del comportamiento hacen colectivamente que los ataques de fuerza bruta sean imprácticos contra un objetivo endurecido. Los atacantes se mueven hacia la menor resistencia — lo que significa que las organizaciones que implementan seguridad de autenticación por capas efectivamente se eliminan del grupo de objetivos fáciles.

El riesgo real es que se aplican inconsistentemente — un equipo usando MFA, otro no. Credenciales compartidas almacenadas en hojas de cálculo; políticas de contraseñas que existen en papel pero no se aplican técnicamente. Cerrar esas brechas es donde está el verdadero trabajo.

Passwork proporciona a los equipos de TI una bóveda de credenciales estructurada y auditable con acceso basado en roles — construida para los entornos donde la inconsistencia crea riesgo. Despliegue autoalojado completo y cifrado de conocimiento cero — en su infraestructura desde el primer día. Obtener prueba gratuita

Preguntas frecuentes

¿Cuál es la diferencia entre un ataque de fuerza bruta y un ataque de diccionario?

Un ataque de fuerza bruta simple prueba cada combinación de caracteres posible sistemáticamente, sin conocimiento previo. Un ataque de diccionario usa una lista curada de contraseñas probables — palabras comunes, frases conocidas, credenciales filtradas — para reducir el espacio de búsqueda. Los ataques de diccionario son más rápidos y dirigidos; la fuerza bruta simple es exhaustiva pero más lenta. Ambos son derrotados por contraseñas largas y aleatorias que no se parezcan al lenguaje natural.

¿Pueden los ataques de fuerza bruta evadir MFA?

La fuerza bruta estándar no puede evadir MFA directamente — una contraseña correcta por sí sola no es suficiente para el acceso. Sin embargo, los atacantes usan técnicas adyacentes: fatiga MFA (enviar notificaciones push repetidas hasta que el usuario apruebe una), phishing en tiempo real (capturar y reproducir tokens MFA), y secuestro de sesión (robar cookies de sesión autenticadas después del inicio de sesión). Los métodos MFA resistentes al phishing como las llaves de hardware FIDO2 y passkeys eliminan los vectores de phishing y fatiga por completo.

¿Son ilegales los ataques de fuerza bruta?

Sí. Los ataques de fuerza bruta no autorizados contra sistemas que usted no posee o no tiene permiso explícito para probar son ilegales bajo la legislación de fraude informático en la mayoría de las jurisdicciones — incluyendo la Ley de Fraude y Abuso Informático (CFAA) en Estados Unidos, la Ley de Uso Indebido de Computadoras en el Reino Unido, y la Directiva de la UE sobre Ataques contra Sistemas de Información (2013/40/UE). Las sanciones incluyen multas significativas y prisión. Las pruebas de penetración autorizadas requieren permiso escrito del propietario del sistema.

¿Cuánto tiempo lleva descifrar una contraseña con fuerza bruta?

Depende de la longitud de la contraseña, el conjunto de caracteres y cómo se almacena el hash. Una contraseña de 8 caracteres con hash MD5 cae en menos de una hora contra un clúster de GPU moderno. La misma contraseña hasheada con bcrypt a un factor de costo alto puede tardar años en el mismo hardware. La longitud es la variable más confiable bajo su control: cada carácter adicional multiplica el espacio de búsqueda exponencialmente. Una frase de contraseña de 16 caracteres contra bcrypt es computacionalmente impráctico de descifrar con el hardware actual.

¿Qué es el credential stuffing y en qué se diferencia de la fuerza bruta?

El credential stuffing usa pares verificados de nombre de usuario/contraseña de filtraciones de datos anteriores y los prueba contra otros servicios. No adivina — reutiliza. La fuerza bruta genera o cicla a través de combinaciones sin conocimiento previo de credenciales válidas. El credential stuffing es más rápido y dirigido porque trabaja con credenciales reales, y tiene éxito específicamente debido a la reutilización de contraseñas entre servicios.

¿Qué sistemas son más comúnmente atacados por ataques de fuerza bruta?

Los endpoints de autenticación con exposición pública conllevan el mayor riesgo: servicios SSH y RDP, portales VPN, páginas de inicio de sesión de aplicaciones web, paneles de administración (WordPress /wp-admin, cPanel) y endpoints de autenticación API. La campaña de 2025 que utilizó 2,8 millones de IP se centró específicamente en puertas de enlace VPN y firewalls — dispositivos perimetrales que, si se comprometen, proporcionan acceso directo a las redes internas.

Introduction

At 3:14 AM, no one is watching the authentication logs. A script running on a rented cloud instance sends its ten-thousandth login attempt to a VPN portal. At 3:17 AM, it gets a response that's different from the others. Access granted. There is no malware, no social engineering, no insider threat. Just a weak password, automated patience, and a gap in monitoring.

One in three successful attacks against web applications now begins the same way: an automated script cycling through credentials until something works. According to the 2025 Verizon Data Breach Investigations Report, brute force attacks against basic web applications nearly tripled over the last year — jumping from roughly 20% to 60%. It's a signal that automated credential attacks have become a primary weapon, not a fallback.

The underlying mechanics haven't changed: try combinations until one works. What has changed is the speed, scale, and intelligence behind those attempts. Modern GPU clusters, AI-assisted wordlist generation, and botnets spanning millions of compromised devices have transformed  what was once a slow, noisy attack into something fast, distributed, and difficult to detect.

This article covers what brute force attacks are, how they’ve evolved in 2026, the six main variants, real-world examples from 2025–2026, and a layered defense strategy your team can implement today.

Key takeaways

• Brute force attacks are automated credential attacks — scripts systematically cycle through username and password combinations until one works, exploiting weak, reused, or predictable passwords rather than software vulnerabilities.
• Six distinct variants target different weaknesses: simple brute force, dictionary attacks, credential stuffing, password spraying, reverse brute force, and hybrid attacks — each designed to bypass a specific set of defenses.
• Modern hardware has made weak passwords indefensible: a GPU cluster can crack an 8-character MD5-hashed password in minutes. Password length and secure hashing are what determine real-world resistance.
• Layered defenses work but only when consistently enforced. MFA, strong password policies, breach database screening, account lockouts, rate limiting, and a password manager collectively make brute force attacks impractical. Any single gap is enough for an attacker to exploit.
• Detection is a preventive control, not just a reactive one. Recognizing attack signatures — failed login spikes, low-and-slow spraying patterns, impossible travel — gives your team time to block the source before credentials are validated.
• A password manager is the structural fix for credential reuse — the root cause behind credential stuffing. For teams, it also enforces rotation, flags compromised credentials, and closes the offboarding gap that leaves stale credentials valid for years.

What is a brute force attack?

A brute force attack gains unauthorized access to a system by systematically trying every possible combination of credentials (usernames, passwords, or encryption keys) until the correct one is found. It exploits  human behavior: weak, reused, or predictable passwords.

Think of it as trying every key on a keyring. Given enough time and computing power, one will eventually fit. The attacker's goal is to reduce that time to something practical and in 2026, modern hardware makes that increasingly achievable.

Brute force attacks target authentication endpoints: login pages, SSH and RDP services, VPN portals, API gateways, and admin panels. Any system that accepts a username and password is a potential target.

How brute force attacks work in 2026

At its core, a brute force attack is automation at scale. An attacker deploys a script or tool that sends credential combinations to a target system's authentication endpoint in rapid succession. The script logs successful matches and moves on.

What separates 2026 from a decade ago is the infrastructure behind those scripts.

The AI and hardware factor

Modern graphics cards (originally designed for gaming and machine learning) are exceptionally efficient at parallel computation, which is exactly what password cracking requires. A cluster of 12 NVIDIA RTX 5090 GPUs can test hundreds of billions of MD5 hash combinations per second (Hive Systems).

Against weakly hashed credentials, an 8-character password falls in minutes — or less. Against bcrypt with modern cost settings, the same hardware may take years. The difference isn't the attacker's hardware. It's whether the target system stores passwords securely.

Machine learning models trained on leaked password datasets (tools like PassGAN, built on generative adversarial networks) learn real-world password distributions without human-written rules. They predict likely patterns: birthdays appended to names, common character substitutions, culturally specific phrases.

In testing against the RockYou breach dataset, PassGAN matched 47% of real passwords. Сombined with conventional cracking tools, it uncovered 24% more matches than either approach alone. The search space doesn't shrink by brute force — it shrinks by prediction.

The quantum threat

Quantum computing uses quantum-mechanical phenomena to process information in ways classical computers cannot. Where a classical processor works through possibilities sequentially, a quantum system evaluates many states simultaneously. Applied to cryptography, that parallelism becomes a direct threat to the mathematical problems that underpin current encryption.

Quantum computing introduces a longer-term risk. IBM's quantum roadmap projects that cryptographically relevant quantum computers could undermine current asymmetric encryption standards within this decade.

Quantum  attacks on hashed passwords remain theoretical, but organizations managing long-lived secrets and encryption keys should begin evaluating post-quantum cryptography standards — NIST finalized its first post-quantum standards in 2024.

Botnets and distributed attacks

A botnet is a network of compromised devices (servers, routers, IoT endpoints, personal computers) controlled remotely by an attacker without their owners' knowledge. Each device acts as an independent node, capable of sending requests, probing systems, or submitting login attempts. The scale can reach millions of machines operating in coordination.

Attackers rarely operate from a single IP. Modern brute force campaigns use botnets to distribute login attempts across different source addresses, bypassing IP-based rate limiting and geographic blocking.

In early 2025, the Shadowserver Foundation tracked a campaign using 2.8 million IP addresses daily to target  VPN login portals from Palo Alto Networks, Ivanti, and SonicWall (BleepingComputer).

The attacking nodes were predominantly compromised MikroTik, Huawei, and Cisco routers — hijacked devices spread across dozens of countries, with the largest cluster originating from Brazil. The traffic was routed through residential proxy networks, making each attempt appear to come from a regular home user rather than a bot. Standard IP-based defenses saw what looked like normal traffic.

Types of brute force attacks

Brute force attacks share one principle: gain access by systematically testing credentials until something works. The methods differ in what they test, how they source their data, and which defenses they're designed to bypass.

1. Simple brute force attack

The most straightforward variant: every possible character combination is tried in sequence — aaa, aab, aac — until a match is found. No prior knowledge of the target is required. The attack relies entirely on computational power.

It is effective only against short or simple passwords. Against an 8-character password using mixed characters, modern GPU clusters can complete the search in hours. Beyond 12 characters, the same approach becomes computationally impractical — the search space grows exponentially with each added character.

2. Dictionary attack

A dictionary attack replaces exhaustive enumeration with a curated list of likely passwords (words, phrases, and known credentials) dramatically narrowing the search space. The attacker bets on human predictability rather than raw computation.

These lists range from basic compilations of the 10,000 most common passwords to multi-gigabyte datasets built from leaked credentials, regional slang, and industry-specific terminology. Any password that resembles natural language is vulnerable. Randomness is the only reliable defense.

3. Credential stuffing

Credential stuffing is the automated reuse of username and password pairs stolen from previous data breaches. Attackers take username and password pairs and test them against other services, exploiting the fact that many users reuse the same credentials across multiple accounts.

In July 2024, a compilation of nearly 10 billion unique passwords — dubbed RockYou2024 — was posted on a criminal forum, providing attackers with an unprecedented pool of credentials to work from (Cybernews, 2024).

Understanding the dangers of password reuse is essential context here — a single compromised account on one platform can cascade into access across an entire digital footprint.

4. Password spraying

Password spraying inverts the typical approach. Rather than trying many passwords against one account (which triggers lockouts), the attacker tries one or two common passwords — Password1!, Welcome2026 — across thousands of accounts.

It stays below lockout thresholds and is particularly effective against large organizations with weak password policies. Over 97% of identity attacks involve password spray or brute force, according to Microsoft Digital Defence Report 2025.

5. Reverse brute force attack

A reverse brute force attack starts with a known password (typically sourced from a breach or a known default) and tests it systematically against a list of usernames. The credential is fixed; the identity is the unknown.

This method is most effective when the target password is widely shared: a default corporate password distributed during onboarding, a common pattern mandated by a weak policy, or a credential that appeared in a previous leak. Where a standard attack probes one account deeply, a reverse attack probes many accounts with surgical precision.

6. Hybrid brute force attack

A hybrid brute force attack combines dictionary words with programmatic mutations — appending numbers, years, or special characters (Summer2026!, admin@123), substituting letters with symbols, or shifting capitalization. It is designed to crack passwords that appear complex but follow predictable construction patterns.

These attacks target the gap between password policy and human behavior. When users are required to "complicate" a password, they rarely introduce true randomness — they append 1! to a familiar word or capitalize the first letter. Hybrid attacks are built to exploit exactly that instinct, making rule-based complexity requirements a weaker defense than length alone.

Brute force attack comparison table

Managing credentials across a large team creates exactly the attack surface brute force campaigns exploit. See how Passwork structures team vaults with role-based access and enforced password policies

Real-world brute force attack examples (2025)

Brute force and credential stuffing attacks continue to be a significant threat, evolving in sophistication and scale. The following cases from 2025 and 2026 highlight the persistent risks and the critical importance of robust authentication and security practices.

Australian superannuation funds — March 2025

Attack type: Credential stuffing (coordinated, multi-target).

Over the weekend of 29–30 March 2025, five major Australian pension funds (AustralianSuper, REST Super, Hostplus, Australian Retirement Trust, and Insignia Financial) were simultaneously targeted using combo lists from unrelated prior breaches. Over 20,000 accounts were compromised.

Four AustralianSuper members collectively lost AUD 500,000. REST shut down its MemberAccess portal entirely after ~8,000 members had personal data exposed.

23andMe — 2023 → regulatory consequences in 2025

Attack type: Credential stuffing

Between April and September 2023, attackers tested credentials from unrelated breaches against 23andMe accounts. Through the DNA Relatives feature, initial compromises cascaded into exposure of genetic and ancestry data belonging to approximately 6.9 million users — most of whom had never been directly targeted.

"Mega Leak" — 16 billion credentials exposed — June 2025

Attack type: Credential stuffing (source data)

In June 2025, Cybernews researchers discovered ~30 datasets containing over 16 billion login records — URLs, usernames, and plaintext passwords. The data was harvested primarily by infostealer malware targeting consumer devices. Platforms affected included Google, Apple, Facebook, and others. Notably, BleepingComputer confirmed the datasets include a significant proportion of recycled credentials from older breaches, meaning not all records represent fresh exposures.

Jaguar Land Rover — March 2025 + September 2025

Attack type: Credential stuffing / stolen credentials (infostealer-sourced)

In March 2025, the HELLCAT ransomware group breached JLR using stolen Jira credentials harvested via infostealer malware. Threat actor "Rey" leaked ~700 internal documents on 10 March. Days later, a second actor "APTS" used credentials dating back to 2021 — belonging to a third-party contractor — to access the same Jira server and leak an additional ~350 GB of data including source code, development logs, and employee records.

In September 2025, a separate attack attributed to a group calling itself "Scattered Spider Lapsus$ Hunters" shut down global IT systems and halted manufacturing at the Halewood plant, with employees sent home.

Summary table

How to detect a brute force attack

Prevention is the goal, but detection is the safety net. Brute force attacks leave consistent signatures in authentication logs — if you know what to look for.

• Spikes in failed login attempts — A sudden increase in authentication failures against a single account, or spread across many, is the most direct indicator. Establish a baseline for your environment and alert on deviations.
• Multiple lockouts from the same source IP — Even distributed attacks leave partial patterns. Repeated lockouts originating from the same IP range or ASN (Autonomous System Number) suggest automated activity.
• Impossible travel — A user authenticating from London and then from Singapore within 30 minutes triggers an automatic flag in modern SIEM and identity platforms. The signal alone is not conclusive: VPN exit nodes, split-tunneling configurations, and cloud proxy services routinely produce false positives. The value is in the investigation it prompts — not the assumption it confirms.
• High request volume to authentication endpoints — Hundreds of POST requests per minute to /login or /api/auth from a single source is not organic traffic. Monitor your login endpoints for request rates that exceed human typing speed.
• Distributed low-and-slow patterns — Password spraying specifically avoids triggering per-account lockouts. Look for a pattern where many different accounts each receive exactly one or two failed attempts within a short window — this is the spraying signature.
• Unusual user-agent strings or missing headers — Automated tools often send requests with generic or absent user-agent strings, missing standard browser headers, or with unusual TLS fingerprints.

How to prevent brute force attacks

Defense against brute force is a stack. Each layer compensates for the weaknesses of the others.

Enforce strong password policies

Length matters more than complexity. A 16-character passphrase is exponentially harder to crack than an 8-character string of mixed characters. Move your organization away from minimum-length policies that technically permit P@ssw0rd and toward minimum-entropy policies that require genuine unpredictability. Review enterprise password management best practices for a structured framework.

Key requirements per NIST SP 800-63B:

• Minimum 15 characters for accounts without MFA; minimum 8 with MFA enforced
• No arbitrary complexity rules that produce predictable patterns
• Maximum length of at least 64 characters to support passphrases
• Block passwords that appear in breach databases — check new credentials against services like Have I Been Pwned at the point of creation, not after the fact

Screen credentials against breach databases

Before a password is accepted, verify it hasn't already appeared in a known data breach. NIST SP 800-63B and OWASP both require this as a distinct control — separate from password length or complexity rules. An attacker running a dictionary attack against your systems is working from the same leaked datasets. Blocking those passwords at registration removes them from the attack surface entirely.

Implement multi-factor authentication

MFA is the single most effective control against credential-based attacks — a compromised password alone is not enough  for access. That said , MFA is not infallible. MFA fatigue attacks — where attackers send repeated push notifications until a user approves one out of frustration — have bypassed MFA at major organizations. Phishing-resistant MFA methods such as FIDO2 and passkeys  eliminate this vector entirely. 

Configure account lockouts and progressive delays

Configure authentication systems to lock accounts after a defined number of failed attempts (typically 5–10), or implement progressive delays that increase exponentially with each failure. Progressive delays are often preferable to hard lockouts, which can themselves be weaponized for denial-of-service against legitimate users.

Apply rate limiting at the IP and ASN level

Account lockout protects individual accounts. Rate limiting protects the authentication endpoint itself. These are different controls with different targets. Restrict the number of login requests per IP address per time window. Escalate to ASN-level blocking when distributed patterns emerge.

Deploy CAPTCHA and bot management

CAPTCHA challenges differentiate human users from automated scripts at the authentication layer. Modern bot management platforms go further, analyzing behavioral signals — mouse movement, typing cadence, TLS fingerprints — to identify non-human traffic before it reaches the login form.

Implement zero trust architecture

Zero trust operates on the principle that no user, device, or network segment is inherently trusted. Even after successful authentication, access is continuously verified based on context: device health, location, behavior, and least-privilege access rules. If a brute force attack does compromise  one account, zero trust limits the blast radius by preventing lateral movement to other systems and resources.

Monitor authentication logs and alert on anomalies

Detection is a preventive control, not just a reactive one. Catching an attack in progress gives your team time to block the source, invalidate sessions, and contain the damage. Configure SIEM alerts for: spikes in failed authentication attempts, impossible travel events, high request volume to login endpoints, and the low-and-slow spraying pattern where many accounts each receive exactly one or two failures within a short window.

Use a password manager

Password reuse is the fuel that makes credential stuffing viable at scale. When one breach exposes a credential, every other service where that password is reused becomes vulnerable — automatically, without any additional effort from the attacker. A password manager eliminates this by generating and storing a unique, high-entropy password for every account, making reuse structurally impossible.

For individual users, any reputable password manager achieves this. For teams and organizations, the requirements are different and the stakes are higher.

Passwork is built specifically for this environment. It gives IT teams a centralized, structured vault where credentials are organized with granular, role-based access control: each user sees only what their role permits, nothing more. Shared credentials are stored in shared vaults with defined permissions.

Several of Passwork's features directly address the attack vectors covered in this article:

• Customizable password generator — enforces length and complexity requirements at the point of creation, so policy compliance isn't left to individual judgment.
• Password security dashboard — continuously tracks the status of all stored credentials, flagging weak, reused, outdated, and potentially compromised passwords across the entire vault. When an employee leaves, Passwork automatically marks every credential they had access to as potentially compromised and prompts rotation.
• Zero-knowledge client-side encryption — credentials are encrypted on the client side before they ever reach the server. Even with full access to the database or underlying infrastructure, an attacker retrieves nothing readable. The encryption key never leaves the user's device.
• Full audit log — every action in the vault is logged: who accessed what, when, and from where. This is the visibility layer that makes post-incident investigation possible and supports compliance with GDPR, NIS2, and similar frameworks.
• Two-factor authentication, passkeys, and hardware security keys — Passwork supports 2FA via authenticator apps and WebAuthn-based authentication including biometrics and FIDO2 hardware keys, adding a second layer beyond the vault password itself.
• Configurable account lockout — administrators set the threshold of failed login attempts after which an account is locked. This applies brute-force and credential stuffing protection at the vault level itself — not just at the network perimeter.
• Self-hosted deployment — Passwork runs entirely within your own infrastructure. Credential data never leaves your environment, is encrypted with AES-256 on both server and client sides (zero-knowledge architecture), and is managed exclusively by your team.

The JLR breach illustrated what happens without this structure: credentials from 2021 belonging to a third-party contractor were still valid four years later, with no rotation and no MFA on the Jira instance. A centralized vault with enforced rotation policies and an offboarding workflow would have closed that window before it was exploited.

Conclusion

Brute force attacks have become more scalable in practice. Cheap GPU compute, AI-assisted wordlist generation, and massive botnets mean that what once required significant resources now requires almost none. The 37% share of web application attacks attributed to brute force in the 2025 Verizon DBIR is the result of that accessibility.

The good news: the defenses work. MFA, strong and unique passwords, account lockout policies, and behavioral monitoring collectively make brute force attacks impractical against a hardened target. Attackers move toward lowest resistance  — which means organizations that implement layered authentication security effectively remove themselves from the easy-target pool.

The real risk is that they're inconsistently applied — one team using MFA, another not. Shared credentials stored in spreadsheets; password policies that exist on paper but aren't enforced technically. Closing those gaps is where the real work lies.

Passwork gives IT teams a structured, auditable credential vault with role-based access — built for the environments where inconsistency creates risk. Full self-hosted deployment and zero-knowledge encryption — on your infrastructure from day one. Get free trial

Frequently asked questions

What is the difference between a brute force attack and a dictionary attack?

A simple brute force attack tries every possible character combination systematically, with no prior knowledge. A dictionary attack uses a curated list of likely passwords — common words, known phrases, leaked credentials — to reduce the search space. Dictionary attacks are faster and more targeted; simple brute force is exhaustive but slower. Both are defeated by long, random passwords that don't resemble natural language.

Can brute force attacks bypass MFA?

Standard brute force cannot bypass MFA directly — a correct password alone isn't enough  for access. However, attackers use adjacent techniques: MFA fatigue (sending repeated push notifications until the user approves), real-time phishing (capturing and replaying MFA tokens), and session hijacking (stealing authenticated session cookies after login). Phishing-resistant MFA methods such as FIDO2 hardware keys and passkeys eliminate the phishing and fatigue vectors entirely.

Are brute force attacks illegal?

Yes. Unauthorized brute force attacks against systems you do not own or have explicit permission to test are illegal under computer fraud legislation in most jurisdictions — including the Computer Fraud and Abuse Act (CFAA) in the United States, the Computer Misuse Act in the United Kingdom, and the EU Directive on Attacks Against Information Systems (2013/40/EU). Penalties include significant fines and imprisonment. Authorized penetration testing requires written permission from the system owner.

How long does it take to crack a password with brute force?

It depends on password length, character set, and how the hash is stored. A 8-character MD5-hashed password falls in under an hour against a modern GPU cluster. The same password hashed with bcrypt at a high cost factor may take years on the same hardware. Length is the most reliable variable under your control: every additional character multiplies the search space exponentially. A 16-character passphrase against bcrypt is computationally impractical to crack with current hardware.

What is credential stuffing and how does it differ from brute force?

Credential stuffing uses verified username/password pairs from previous data breaches and tests them against other services. It doesn't guess — it reuses. Brute force generates or cycles through combinations without prior knowledge of valid credentials. Credential stuffing is faster and more targeted because it works with real credentials, and it succeeds specifically because of password reuse across services.

What systems are most commonly targeted by brute force attacks?

Authentication endpoints with public exposure carry the highest risk: SSH and RDP services, VPN portals, web application login pages, admin panels (WordPress /wp-admin, cPanel), and API authentication endpoints. The 2025 campaign utilizing  2.8 million IPs focused specifically on VPN gateways and firewalls — perimeter devices that, if compromised, provide direct access to internal networks.

Einleitung

Datenresidenz und Datensouveränität klingen fast wie dasselbe. Sind sie aber nicht.

Viele europäische Unternehmen wählen einen US-basierten Anbieter, entscheiden sich für die EU-Rechenzentrum-Option und betrachten die Frage der Datenresidenz als gelöst. Rechtlich ist sie das nicht. Der US CLOUD Act gibt amerikanischen Bundesbehörden die Befugnis, jedes in den USA eingetragene Unternehmen zur Herausgabe von Daten zu zwingen, die überall auf der Welt gespeichert sind. Die Daten befinden sich in Europa. Die rechtliche Verpflichtung nicht.

Dies ist die Spannung, auf die europäische Unternehmen stoßen, wenn sie entscheiden, wie sie einen Passwort-Manager hosten. DSGVO, NIS2, DORA und der CLOUD Act schaffen sich überschneidende Anforderungen, die sich nicht durch die Wahl des nächstgelegenen Rechenzentrums lösen lassen. Das Hosting-Modell (wem die Infrastruktur gehört, unter welcher Rechtsordnung, mit welchem Maß an organisatorischer Kontrolle) ist es, was das Compliance-Bild tatsächlich bestimmt.

Dieser Leitfaden zeigt die Hosting-Modelle auf, die europäischen Unternehmen zur Verfügung stehen, den regulatorischen Rahmen, der jedes einzelne prägt, und die Kriterien, die die Entscheidung bestimmen sollten.

Kernaussagen

• Die Wahl eines EU-Rechenzentrums löst die Datensouveränität nicht. Wenn der Anbieter in den USA eingetragen ist, zwingt der CLOUD Act ihn, Daten an amerikanische Behörden herauszugeben — unabhängig davon, wo sich die Server physisch befinden.
• Vier regulatorische Rahmenwerke prägen die Hosting-Entscheidung. DSGVO, NIS2, DORA und der US CLOUD Act schaffen sich überschneidende Verpflichtungen, die keine Rechenzentrumsauswahl allein erfüllen kann. Das Hosting-Modell bestimmt die rechtliche Verteidigungsfähigkeit.
• On-Premises ist das einzige Modell, das den Zugriff Dritter konstruktionsbedingt ausschließt. Es eliminiert die CLOUD-Act-Exposition vollständig und gibt der Organisation die volle Infrastrukturkontrolle, erfordert jedoch interne IT-Kapazitäten für Betrieb und Wartung.
• Souveräne EU-Cloud ist ein glaubwürdiger Mittelweg. Die europäischen Ausgaben für souveräne Cloud-IaaS sollen 2026 voraussichtlich 12,6 Milliarden US-Dollar erreichen — ein Anstieg von 83 % im Jahresvergleich (Gartner, 2026). Das Modell liefert verwaltete Infrastruktur ohne Risiko ausländischer Rechtsordnung.
• Das richtige Modell hängt von vier Variablen ab. Branchenklassifizierung, regulatorische Exposition, interne IT-Kapazität und Gesamtbetriebskosten bestimmen, ob On-Premises, souveräne EU-Cloud oder hybride Architektur die vertretbare Wahl ist.

Das europäische Hosting-Spektrum

Europäischen Unternehmen stehen fünf unterschiedliche Hosting-Konfigurationen für einen Passwort-Manager zur Verfügung. Zwei fallen für die meisten EU-Unternehmen außerhalb realistischer Compliance-Überlegungen. Drei sind einer eingehenden Bewertung wert.

US-Cloud mit US-Rechenzentrum liegt außerhalb des Umfangs dieses Leitfadens und für die meisten europäischen Unternehmen außerhalb des Bereichs realistischer Überlegungen. Wenn sich Server in den Vereinigten Staaten befinden und die Muttergesellschaft in den USA eingetragen ist, befinden sich die Daten physisch außerhalb der EU. Diese Kombination löst DSGVO-Übertragungspflichten gemäß Artikeln 44–49 aus und schafft gleichzeitig volle CLOUD-Act-Exposition.

US-Cloud mit EU-Rechenzentrum ist einen Schritt näher an der Compliance — aber keine saubere Lösung. Der Passwort-Manager-Anbieter betreibt Server in einer EU-Region (z. B. Frankfurt, Dublin), sodass sich die Daten physisch in Europa befinden. Das erfüllt die DSGVO-Anforderungen zur Datenresidenz auf dem Papier. Wenn die Muttergesellschaft jedoch in den USA eingetragen ist, gilt der US CLOUD Act unabhängig davon, wo sich die Server befinden. Amerikanische Behörden können legal Zugang zu diesen Daten verlangen, ohne EU-Rechtskanäle zu nutzen. Das Risiko ist geringer als beim vorherigen Modell, aber Souveränität ist nicht garantiert.

Die drei Modelle, die einer Bewertung wert sind:

• Souveräne EU-Cloud. Der Dienst läuft auf Infrastruktur, die von EU-basierten Anbietern betrieben wird, außerhalb der US- oder anderer ausländischer Rechtsordnung. Dieses Modell erfüllt die DSGVO-Anforderungen zur Datenresidenz und eliminiert die CLOUD-Act-Exposition.
• On-Premises-Bereitstellung. Der Passwort-Manager läuft vollständig innerhalb der eigenen Infrastruktur der Organisation (physische Server, Private Cloud oder Air-Gap-Umgebungen). Kein Drittanbieter hat Zugriff auf die Anmeldedaten. Dies ist das einzige Modell, das vollständige Infrastrukturkontrolle bietet.
• Hybride Architektur. Eine Kombination aus On-Premises-Tresoren für sensible Anmeldedaten und cloudbasiertem Zugriff für verteilte Teams. Erfordert sorgfältige Richtliniengestaltung, um Compliance-Lücken zwischen den beiden Umgebungen zu vermeiden.

Die Wahl zwischen diesen Modellen ist eine Frage der Regulierung und des Risikomanagements.

Wie EU-Vorschriften das Passwort-Manager-Hosting bestimmen

DSGVO, NIS2, DORA und der US CLOUD Act erlegen jeweils spezifische Verpflichtungen auf, die direkt einschränken, welches Hosting-Modell eine europäische Organisation vertretbar wählen kann. Das Verständnis der Wechselwirkung zwischen diesen Rahmenwerken ist der Ausgangspunkt für jede Bereitstellungsentscheidung.

DSGVO und Datenresidenz

Die Datenschutz-Grundverordnung ist das primäre Rechtsrahmenwerk der EU für die Erhebung, Speicherung und Übertragung personenbezogener Daten. Sie gilt für jede Organisation, die personenbezogene Daten von EU-Bürgern verarbeitet, unabhängig davon, wo diese Organisation ihren Sitz hat.

Die DSGVO verlangt nicht ausdrücklich, dass Daten innerhalb der EU gespeichert werden. Sie verlangt, dass personenbezogene Daten, die außerhalb der EU übertragen werden, nach einem gleichwertigen Standard geschützt werden — durch Standardvertragsklauseln (SCCs), Angemessenheitsbeschlüsse oder andere Übertragungsmechanismen gemäß Artikeln 44–49. Für einen Passwort-Manager, der Mitarbeiter-Anmeldedaten und zugehörige Metadaten (Benutzernamen, URLs, E-Mail-Adressen) speichert, gilt die DSGVO direkt.

„Jegliche Übermittlung personenbezogener Daten, die bereits verarbeitet werden oder nach ihrer Übermittlung an ein Drittland oder eine internationale Organisation zur Verarbeitung bestimmt sind, ist nur zulässig, wenn der Verantwortliche und der Auftragsverarbeiter die in diesem Kapitel niedergelegten Bedingungen einhalten und auch die sonstigen Bestimmungen dieser Verordnung eingehalten werden." — DSGVO, Artikel 44 (Allgemeine Grundsätze der Datenübermittlung)

Das Risiko ist nicht theoretisch. Im August 2024 verhängte die niederländische Datenschutzbehörde eine Geldstrafe von 290 Millionen Euro gegen Uber wegen der Übertragung personenbezogener Daten europäischer Taxifahrer auf US-Server ohne Anwendung der nach DSGVO Kapitel V erforderlichen Schutzmaßnahmen. Keine Standardvertragsklauseln, kein Angemessenheitsbeschluss, kein alternativer Übertragungsmechanismus. Der Verstoß erstreckte sich über mehr als zwei Jahre. Der Fall veranschaulicht direkt, wie die Durchsetzung von Artikel 44 in der Praxis aussieht: Mitarbeiterdaten, grenzüberschreitende Infrastruktur und eine neunstellige Strafe.

NIS2 und kritische Infrastruktur

Die NIS2-Richtlinie (Netz- und Informationssicherheitsrichtlinie 2) ist die primäre Cybersicherheitsgesetzgebung der EU und ersetzt die ursprüngliche NIS-Richtlinie von 2016. Sie legt verbindliche Sicherheitsanforderungen für Organisationen fest, die in kritischen Sektoren in den EU-Mitgliedstaaten tätig sind, mit Schwerpunkt auf Risikomanagement, Vorfallmeldung und Lieferkettensicherheit.

NIS2 erweitert den Kreis der als „wesentliche" oder „wichtige" Einrichtungen eingestuften Organisationen erheblich. Sektoren wie Energie, Verkehr, Bankwesen, Gesundheitswesen, digitale Infrastruktur und öffentliche Verwaltung müssen ihre Technologieanbieter nun als Teil ihres Sicherheitsperimeters behandeln, nicht nur ihre interne Infrastruktur.

Ein Passwort-Manager, der Anmeldedaten in einer Drittanbieter-Cloud-Umgebung speichert, fällt unter diesen Perimeter. Er ist ein direkter Lieferant eines sicherheitskritischen Dienstes. NIS2 Artikel 21(2) verlangt von den betroffenen Einrichtungen die Umsetzung von Maßnahmen, die mindestens Folgendes umfassen:

„Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen den einzelnen Einrichtungen und ihren unmittelbaren Anbietern oder Diensteanbietern." — NIS2-Richtlinie, Artikel 21(2), Richtlinie (EU) 2022/2555

Die Wahl eines US-basierten Cloud-Anbieters für die Speicherung von Anmeldedaten ohne dokumentierte Risikobewertung schafft eine konkrete Compliance-Lücke. Nach NIS2 können nationale Aufsichtsbehörden verbindliche Anweisungen erteilen und Bußgelder verhängen. Für wesentliche Einrichtungen begründet Artikel 20 auch die persönliche Haftung der Mitglieder des Leitungsorgans.

DORA und Besonderheiten des Finanzsektors

Der Digital Operational Resilience Act (DORA) ist das regulatorische Rahmenwerk der EU für digitale operationelle Resilienz im Finanzsektor. Er legt Anforderungen fest, wie Finanzunternehmen IKT-Risiken (Informations- und Kommunikationstechnologie) managen, und deckt Drittanbieterabhängigkeiten, Vorfallmeldung und Resilienztests ab, um die Stabilität von Finanzdienstleistungen in der EU zu gewährleisten.

Ein cloudbasierter Passwort-Manager qualifiziert sich als IKT-Drittanbieter-Dienst nach DORA. Diese Einstufung löst spezifische vertragliche Verpflichtungen aus — einschließlich der Anforderung zu dokumentieren, wo Daten gespeichert und verarbeitet werden. Artikel 30(2)(b) der Verordnung (EU) 2022/2554 lautet:

„Die Standorte, d. h. die Regionen oder Länder, in denen die vertraglich vereinbarten oder ausgelagerten Funktionen und IKT-Dienste erbracht werden sollen und in denen Daten verarbeitet werden sollen, einschließlich des Speicherorts, sowie die Anforderung an den IKT-Drittanbieter, das Finanzunternehmen vorab zu benachrichtigen, wenn er beabsichtigt, solche Standorte zu ändern." — DORA, Artikel 30(2)(b), Verordnung (EU) 2022/2554

Wenn der Passwort-Manager-Anbieter in den USA ansässig ist, muss das Finanzinstitut dokumentieren, wie es die CLOUD-Act-Exposition handhabt, und sicherstellen, dass der Vertrag die DORA-Anforderungen für Datenzugang, Portabilität und Kündigung erfüllt.

Der US CLOUD Act

Der Clarifying Lawful Overseas Use of Data Act (CLOUD Act, 2018) ist ein US-Bundesgesetz, das Strafverfolgungsbehörden ermöglicht, in den USA eingetragene Unternehmen zur Herausgabe von Daten zu zwingen, die überall auf der Welt gespeichert sind, einschließlich Servern in EU-Rechenzentren. Die Verpflichtung gilt unabhängig davon, wo sich die Daten physisch befinden. Der entscheidende Faktor ist die Unternehmensgerichtsbarkeit des Anbieters.

Das Gesetz ist in diesem Punkt eindeutig:

„Ein Anbieter von elektronischen Kommunikationsdiensten oder Remote-Computing-Diensten muss den Verpflichtungen dieses Kapitels nachkommen, Inhalte einer leitungsgebundenen oder elektronischen Kommunikation sowie Aufzeichnungen oder andere Informationen in Bezug auf einen Kunden oder Abonnenten, die sich im Besitz, Gewahrsam oder unter der Kontrolle des Anbieters befinden, zu sichern, zu sichern oder offenzulegen, unabhängig davon, ob sich diese Kommunikation, Aufzeichnung oder andere Information innerhalb oder außerhalb der Vereinigten Staaten befindet." — 18 U.S.C. § 2713, Pub. L. 115–141, div. V, §103(a)(1), 23. März 2018

Das Unternehmen kann die Anordnung anfechten, aber die rechtliche Verpflichtung besteht unabhängig davon, wo sich die Server befinden.

Für europäische Organisationen, die mit sensiblen Anmeldedaten umgehen (privilegierter Zugang, Passwörter für Finanzsysteme, Infrastrukturschlüssel), schafft dies ein strukturelles Risiko, das EU-Regionen-Rechenzentren allein nicht lösen. Souveräne Cloud oder On-Premises-Bereitstellung sind die einzigen Modelle, die diese Exposition vollständig eliminieren.

Passwork ist ein europäischer Passwort-Manager, der genau für dieses regulatorische Umfeld entwickelt wurde — mit On-Premises- und Cloud-Optionen, die auf DSGVO- und NIS2-Compliance sowie Datensouveränität ausgelegt sind. So funktioniert es

Cloud-Passwort-Manager in Europa: Komfort vs. Kontrolle

Cloud-Hosting bedeutet, dass die Server des Anbieters Ihre Daten speichern und verarbeiten — die Organisation greift über das Internet auf den Dienst zu, ohne die zugrunde liegende Infrastruktur zu verwalten. Bei Passwort-Managern bedeutet dies, dass Anmeldedaten, Metadaten und Zugriffsprotokolle auf Servern liegen, die einem Dritten gehören und von diesem betrieben werden, in Rechenzentren, die die Organisation nicht kontrolliert.

Cloudbasierte Passwort-Manager bieten schnelle Bereitstellung, automatische Updates und keinen Infrastruktur-Overhead. Für viele europäische Organisationen sind sie die Standardwahl — 53 % der EU-Unternehmen nutzten 2025 kostenpflichtige Cloud-Computing-Dienste, ein Anstieg um 7,4 Prozentpunkte gegenüber 2023 (Eurostat, 2026).

Der Reiz ist offensichtlich: keine Server zu warten, der Anbieter übernimmt das Patching, und der Zugriff funktioniert von jedem Gerät aus. Für KMU ohne dedizierte Sicherheitsteams senkt dies die Hürde für die Einführung eines ordnungsgemäßen Anmeldedaten-Managements.

Wo Cloud für EU-Organisationen zu kurz greift

Das Modell der geteilten Verantwortung ist das zentrale Thema. Bei einer Cloud-Bereitstellung kontrolliert der Anbieter die Infrastruktur, die Architektur des Verschlüsselungsschlüssel-Managements und die Backup-Systeme. Die Organisation kontrolliert den Benutzerzugang und die Richtlinien, aber nicht die zugrunde liegende Datenumgebung.

Zero-Knowledge-Architektur adressiert dies teilweise: Wenn der Anbieter niemals die Entschlüsselungsschlüssel besitzt, kann ein serverseitiger Sicherheitsvorfall keine Klartext-Anmeldedaten offenlegen. Die ICO-Strafe gegen LastPass veranschaulicht die Grenzen — der Vorfall legte Metadaten (Namen, E-Mails, URLs) offen, obwohl verschlüsselte Tresorinhalte geschützt waren. Metadaten sind personenbezogene Daten nach der DSGVO.

AES-256-Verschlüsselung im Ruhezustand ist eine Grundanforderung, kein Unterscheidungsmerkmal. Entscheidend ist, wo Schlüssel generiert und gespeichert werden, wer darauf zugreifen kann und ob die Architektur des Anbieters diese Schlüssel außerhalb seiner eigenen Reichweite hält.

On-Premises-Passwort-Manager: Maximale Souveränität

On-Premises-Bereitstellung bedeutet, dass der Passwort-Manager auf Servern läuft, die der Organisation gehören und von ihr betrieben werden — kein Anbieter hat Netzwerkzugriff auf den Anmeldedatenspeicher. Alle Anmeldedaten, Metadaten und Zugriffsprotokolle verbleiben innerhalb des eigenen Infrastrukturperimeters der Organisation.

Dies ist das einzige Hosting-Modell, das die Anforderungen an die Datensouveränität vollständig erfüllt und die Drittanbieter-Exposition konstruktionsbedingt eliminiert.

Für Organisationen in regulierten Sektoren (Finanzinstitute, Gesundheitsdienstleister, Betreiber kritischer Infrastrukturen unter NIS2) entfernt die On-Premises-Bereitstellung eine ganze Kategorie von Drittanbieter-Risiken aus der Compliance-Gleichung.

Wo On-Premises die einzige praktikable Option ist

Air-Gap-Umgebungen stellen die sicherste Variante dar: Der Passwort-Manager wird in einem Netzwerk ohne Internetverbindung betrieben. Dies ist relevant für industrielle Steuerungssysteme, klassifizierte Umgebungen oder jeden Kontext, in dem der Anmeldedatenspeicher physisch von externen Netzwerken isoliert sein muss.

Wie oben dargelegt, ist die On-Premises-Bereitstellung mit einem Nicht-US-Anbieter das einzige Modell, das die CLOUD-Act-Exposition vollständig eliminiert, indem es die US-Unternehmensgerichtsbarkeit entfernt, die die Verpflichtung überhaupt erst auslöst.

On-Premises-Bereitstellung: Vor- und Nachteile

Die TCO-Kalkulation verlagert Kosten von wiederkehrenden SaaS-Gebühren zu internen IT-Arbeitskosten und Infrastruktur. Für Organisationen, die bereits eigene Server betreiben und ein Sicherheitsteam haben, sind die Grenzkosten für das Hinzufügen eines selbst gehosteten Passwort-Managers oft niedriger als es erscheint.

Die tatsächlichen Kosten von On-Premises liegen in der operativen Disziplin, die für die Wartung erforderlich ist. Unternehmen ohne dediziertes Sicherheitsteam oder ausgereiften Patch-Management-Prozess werden feststellen, dass die Einschränkungsspalte schwieriger zu handhaben ist, als die Vorteilsspalte vermuten lässt.

Passwork ist als vollständig selbst gehostete Lösung verfügbar: auf den eigenen Servern der Organisation bereitgestellt, ohne ausgehende Verbindungen. Der Quellcode steht zur Prüfung zur Verfügung, und die Plattform unterstützt Air-Gap-Umgebungen. Für Teams, die Prüfern oder Regulierungsbehörden gegenüber vollständige Datensouveränität nachweisen müssen, ist dies das Bereitstellungsmodell, das die Diskussion beendet.

Passwork On-Premises gibt Ihrem Team volle Infrastrukturkontrolle — kein Drittanbieter-Zugriff, ohne Ausnahmen. On-Premises-Bereitstellung erkunden

Der souveräne Cloud-Mittelweg

Souveräne EU-Cloud-Anbieter bieten einen dritten Weg: verwaltete Infrastruktur mit Cloud-typischem Komfort, die vollständig innerhalb der EU-Rechtsordnung betrieben wird und außerhalb der Reichweite ausländischer Rechtsrahmen liegt. Die europäischen Ausgaben für souveräne Cloud-IaaS sollen 2026 voraussichtlich 12,6 Milliarden US-Dollar erreichen, ein Anstieg von 83 % gegenüber 2025 (Gartner, 2026).

Das Wachstum wird durch geopolitischen Druck angetrieben. Der US CLOUD Act, kombiniert mit aufsehenerregenden Vorfällen im Zusammenhang mit Hyperscaler-Abhängigkeit, hat europäische Organisationen dazu gebracht, ihre Cloud-Anbieterwahl zu überdenken.

Für einen Passwort-Manager, der auf souveräner Cloud-Infrastruktur bereitgestellt wird, liefert die Hosting-Umgebung dokumentierte Nachweise, dass die Daten innerhalb der EU-Rechtsordnung verbleiben — direkt relevant für die NIS2-Compliance-Dokumentation und DORA-Drittanbieter-Risikobewertungen.

Souveräne Cloud adressiert Rechtsordnung und Infrastrukturkontrolle. Sie ersetzt nicht die Notwendigkeit, die Passwort-Manager-Anwendung selbst zu bewerten. Die Hosting-Schicht und die Anwendungsschicht sind separate Sicherheitsfragen.

Hybride Architektur

Eine hybride Architektur kombiniert On-Premises-Tresore für sensible Anmeldedaten mit cloudbasiertem Zugriff für verteilte Teams. Es ist eine Richtlinien- und Engineering-Entscheidung, die explizite Grenzen zwischen dem erfordert, was lokal bleibt und was durch externe Infrastruktur läuft.

Der Reiz ist praktischer Natur. Organisationen mit Remote- oder international verteilten Teams können nicht immer jede Authentifizierungsanfrage durch ein On-Premises-System leiten, ohne Latenz- oder Verfügbarkeitsrisiken einzuführen. Ein hybrides Setup ermöglicht es Sicherheitsteams, die sensibelsten Anmeldedatenklassen (privilegierte Konten, Infrastruktur-Secrets, Compliance-sensible Anmeldedaten) in einem lokal kontrollierten Tresor zu halten und gleichzeitig den Zugriff auf weniger sensible Ressourcen über eine Cloud-Schicht zu erweitern.

Die Compliance-Komplexität skaliert jedoch mit der Architektur. Jede Grenze zwischen den On-Premises- und Cloud-Komponenten ist eine potenzielle Lücke: in der Audit-Abdeckung, in der Durchsetzung von Zugriffsrichtlinien, im Umfang der Incident Response. Wenn die Cloud-Schicht unter eine ausländische Rechtsordnung fällt, erstrecken sich die Souveränitätsschutzmaßnahmen der On-Premises-Komponente nicht automatisch darauf.

Hybride Architektur ist das flexibelste Modell in diesem Spektrum — und das anspruchsvollste im korrekten Betrieb. Für Organisationen mit der Engineering-Kapazität, es zu verwalten, bietet es eine praktikable Balance zwischen Kontrolle und Zugänglichkeit. Für diejenigen ohne diese Kapazität ist On-Premises oder souveräne EU-Cloud die vertretbarere Wahl.

Passwork für europäische Unternehmen: Von Anfang an für Souveränität gebaut

Passwork ist ein europäischer Passwort-Manager — als europäisches Unternehmen eingetragen und betrieben, mit rechtlichem Sitz in Spanien unter EU-Recht. Er wurde zuerst On-Premises entwickelt, für Organisationen, die volle Infrastrukturkontrolle benötigen, und bietet seitdem eine Cloud-Option, die vollständig innerhalb der EU gehostet wird.

Dies ist für europäische Unternehmen wichtig, weil die Rechtsordnung des Anbieters selbst Teil des Compliance-Bildes ist. Ein europäisches Unternehmen, das unter EU-Recht operiert, unterliegt keiner US-CLOUD-Act-Exposition. Die Architektur und Bereitstellungsoptionen von Passwork wurden mit diesem regulatorischen Kontext im Sinn entwickelt.

On-Premises-Bereitstellung

Passwork On-Premises läuft vollständig innerhalb der eigenen Infrastruktur der Organisation. Der Anbieter hat keinen Zugriff auf den Anmeldedatenspeicher — keinen Fernzugriff, keine Telemetrie und keine Hintertür. Alle Daten, Verschlüsselungsschlüssel und Backups verbleiben innerhalb der Systeme der Organisation.

Schlüsselfähigkeiten für regulierte Umgebungen:

• Volle Infrastrukturkontrolle — Bereitstellung auf eigenen Servern, Private Cloud oder Air-Gap-Netzwerken. Unterstützt Umgebungen ohne Internetverbindung.
• Zero-Knowledge-Architektur — Anmeldedaten werden auf der Client-Seite ver- und entschlüsselt. Der Server speichert nur Chiffretext und verarbeitet niemals Klartext-Passwörter, was bedeutet, dass ein kompromittierter Server nichts Lesbares offenlegt.
• Rollenbasierte Zugriffskontrolle — Granulare Berechtigungen auf Tresor-, Ordner- und Anmeldedaten-Ebene. Integration mit Active Directory, Azure AD, LDAP und SAML SSO für automatisierte Benutzerbereitstellung und Lifecycle-Management.
• Audit-Protokolle — Vollständige Aktivitätshistorie für jeden Anmeldedaten-Zugriff, jede Änderung und jedes Freigabeereignis. Unterstützt direkt die DSGVO-Rechenschaftspflicht und NIS2-Vorfallsdokumentation.
• AES-256-Verschlüsselung — Anmeldedaten im Ruhezustand und bei der Übertragung verschlüsselt. Schlüssel verbleiben innerhalb der Infrastruktur der Organisation.
• Compliance-Berichte — Integriertes Reporting für Sicherheitsaudits, Zugriffsüberprüfungen und regulatorische Dokumentation.
• Skaliert von 10 bis über 30.000 Benutzer — Dieselbe Architektur funktioniert für ein mittelständisches IT-Team und ein Großunternehmen mit komplexen Berechtigungsstrukturen.

Die Mehrheit der Passwork-Kunden wählt laut unternehmensinternen Daten die On-Premises-Bereitstellung. Dies gilt insbesondere für Großunternehmen, Regierungsstellen und Organisationen in stark regulierten Branchen.

Passwork Cloud: EU-gehostet, Zero-Knowledge

Passwork Cloud wird in Deutschland gehostet. Alle Daten bleiben innerhalb der EU-Rechtsordnung, verarbeitet und gespeichert unter EU-Recht.

Die Architektur verwendet clientseitige Verschlüsselung mit Zero-Knowledge-Design: Der Server sieht niemals Klartext-Anmeldedaten. Ver- und Entschlüsselung erfolgen auf der Client-Seite, sodass auch im Falle eines serverseitigen Vorfalls die Anmeldedaten geschützt bleiben.

Passwork Cloud enthält den vollständigen Enterprise-Funktionsumfang:

• Benutzerverwaltung, Active Directory / LDAP-Integration, SSO
• Audit-Protokolle und Compliance-Berichte
• Erweiterte MFA und Sicherheitsrichtlinien
• Browser-Erweiterungen, mobile Apps und REST API
• DevOps-Secrets-Management — CLI, Python-Bibliothek, Kubernetes-Integration, CI/CD-Pipeline-Unterstützung

Die Preise beginnen bei 3 € pro Benutzer pro Monat (Standardlizenz) und 4,50 € pro Benutzer pro Monat (Erweiterte Lizenz). Die langfristigen Betriebskosten liegen etwa 30 % unter dem Branchendurchschnitt.

Sicherheitsstatus

Passwork besitzt eine ISO 27001-Zertifizierung für Entwicklung, Infrastruktur und Betrieb. Das Unternehmen führt jährliche Penetrationstests durch Dritte durch, einschließlich über HackerOne, und wendet einen DevSecOps-Ansatz mit statischer und dynamischer Analyse an, die in jeden Build integriert ist.

Dieser Sicherheitsstatus ist direkt relevant für Organisationen, die die Sicherheitspraktiken ihres Passwort-Manager-Anbieters dokumentieren müssen — eine Anforderung sowohl nach NIS2 Artikel 21 als auch nach dem DORA-Rahmenwerk für Drittanbieter-Risikomanagement.

Entscheidungsrahmen: Das richtige Modell für Ihre Organisation wählen

Das richtige Hosting-Modell hängt von vier Variablen ab: regulatorische Exposition, Branchenklassifizierung, interne IT-Kapazität und Gesamtbetriebskosten. Die folgende Tabelle ordnet gängige Organisationsprofile empfohlenen Bereitstellungsmodellen zu.

TCO-Überlegungen

Die Gesamtbetriebskosten für jedes Modell umfassen mehr als Lizenz- oder Infrastrukturkosten. Compliance-Overhead ist ein realer Kostenfaktor: Die Zeit für Anbieter-Risikobewertungen, Audit-Dokumentation und Incident-Response-Planung variiert erheblich je nach Modell.

On-Premises-Bereitstellung konzentriert die Compliance-Arbeit intern — die Organisation kontrolliert die Umgebung und kann Audit-Nachweise direkt erbringen. Cloud-Bereitstellungen verlagern einen Teil der Compliance-Arbeit auf das Anbietermanagement: Überprüfung von Sicherheitszertifizierungen, Aushandeln von DPA-Bedingungen, Pflege eines DORA-Drittanbieterregister-Eintrags.

Für NIS2-regulierte Einrichtungen kann der Compliance-Overhead einer schlecht dokumentierten Cloud-Bereitstellung die Infrastrukturkosten einer On-Premises-Bereitstellung übersteigen. Diese Kalkulation lohnt sich, bevor man zur reibungsärmsten Option greift.

Fazit

Das Hosting-Modell für einen Passwort-Manager ist eine architektonische Entscheidung mit langfristigen Compliance-Auswirkungen. DSGVO, NIS2, DORA und der US CLOUD Act schaffen ein regulatorisches Umfeld, in dem die falsche Wahl dokumentierte Haftung erzeugt.

Das Modellspektrum gibt europäischen Organisationen echte Optionen. Die richtige Wahl hängt von der Branchenklassifizierung, der regulatorischen Exposition, der internen IT-Kapazität und einer ehrlichen TCO-Kalkulation ab, die den Compliance-Overhead einschließt.

Für Organisationen, die maximale Kontrolle benötigen, eliminiert die On-Premises-Bereitstellung die Drittanbieter-Exposition vollständig. Für diejenigen, die verwaltete Infrastruktur ohne Risiko ausländischer Rechtsordnung benötigen, ist souveräne EU-Cloud ein glaubwürdiger Weg. Hybride Architekturen funktionieren, wenn keines der Extreme zur operativen Realität passt.

Passwork ist ein europäischer Passwort-Manager, der das gesamte Spektrum abdeckt: On-Premises-Bereitstellung für Organisationen, die vollständige Infrastrukturkontrolle benötigen, und EU-gehostete Cloud für Teams, die verwaltetes Hosting ohne Verzicht auf Datensouveränität wünschen. Beide Optionen basieren auf derselben Zero-Knowledge-Verschlüsselungsarchitektur und beinhalten die Audit-, Zugriffskontroll- und Compliance-Reporting-Funktionen, die regulierte europäische Unternehmen benötigen.

Bereit für den ersten Schritt? Starten Sie Ihre kostenlose Passwork-Testversion, um vollständige Kontrolle, automatisiertes Anmeldedaten-Management und unternehmensweiten Datenschutz zu erhalten.

Häufig gestellte Fragen

Ist ein Cloud-Passwort-Manager DSGVO-konform?

Ein Cloud-Passwort-Manager kann DSGVO-konform sein, wenn der Anbieter personenbezogene Daten auf einer gültigen Rechtsgrundlage verarbeitet, einen Auftragsverarbeitungsvertrag (AVV) bereitstellt, der die Anforderungen von Artikel 28 erfüllt, und angemessene Schutzmaßnahmen für Datenübertragungen außerhalb der EU anwendet. Die Compliance hängt von der Architektur und den Vertragsbedingungen des Anbieters ab — nicht allein vom Cloud-Hosting.

Verlangt die DSGVO, dass Daten in Europa gespeichert werden?

Die DSGVO schreibt keine EU-Datenspeicherung vor. Sie verlangt, dass personenbezogene Daten, die außerhalb der EU übertragen werden, nach einem gleichwertigen Standard geschützt werden — durch Angemessenheitsbeschlüsse, Standardvertragsklauseln oder andere Mechanismen gemäß Artikeln 44–49. Die Speicherung von Daten in der EU vereinfacht die Compliance, ist aber keine rechtliche Anforderung der Verordnung selbst.

Was ist der US CLOUD Act und warum ist er für EU-Unternehmen relevant?

Der US CLOUD Act (2018) erlaubt US-Bundesbehörden, in den USA eingetragene Unternehmen zur Herausgabe von Daten zu zwingen, die überall auf der Welt gespeichert sind, einschließlich EU-Rechenzentren. Für europäische Organisationen, die US-basierte Passwort-Manager-Anbieter nutzen, bedeutet dies, dass Anmeldedaten dem Zugriff der US-Regierung unterliegen könnten, unabhängig davon, wo sich die Server physisch befinden.

Wann gilt NIS2 für Hosting-Entscheidungen bei Passwort-Managern?

NIS2 gilt, wenn die Organisation als „wesentliche" oder „wichtige" Einrichtung eingestuft ist — darunter Energie, Verkehr, Bankwesen, Gesundheitswesen, digitale Infrastruktur und öffentliche Verwaltung. Für diese Organisationen ist ein Passwort-Manager Teil der IKT-Lieferkette, und Artikel 21 verlangt dokumentierte Sicherheitsmaßnahmen für alle Lieferkettenkomponenten.

Was verlangt DORA für cloudbasierte Passwort-Manager in Finanzdienstleistungen?

DORA verlangt von Finanzunternehmen, ein Register der IKT-Drittanbieter zu führen, Risikobewertungen kritischer Anbieter durchzuführen und sicherzustellen, dass Verträge Audit-, Datenzugangs- und Austrittsrechte enthalten. Ein cloudbasierter Passwort-Manager, der von einem Finanzinstitut genutzt wird, ist ein IKT-Drittanbieter-Dienst nach DORA — das Institut muss diese Abhängigkeit formell dokumentieren und managen.

Was ist der Unterschied zwischen einer souveränen EU-Cloud und einem regulären EU-Rechenzentrum?

Ein reguläres EU-Rechenzentrum, das von einem US-Unternehmen betrieben wird, unterliegt weiterhin der US-Rechtsordnung durch den CLOUD Act. Ein souveräner Cloud-Anbieter ist vollständig innerhalb der EU eingetragen und wird dort betrieben, ohne rechtliche Verpflichtung, ausländischen Regierungsanfragen nach Daten nachzukommen. Die Unterscheidung ist relevant für DSGVO-Transfer-Risikobewertungen und NIS2-Lieferkettendokumentation.

Wie unterstützt Passwork die Compliance für europäische Organisationen?

Passwork ist ein europäisches Unternehmen unter EU-Recht, ISO 27001-zertifiziert, mit On-Premises- und EU-gehosteten Cloud-Bereitstellungsoptionen. Die On-Premises-Bereitstellung eliminiert den Drittanbieter-Zugriff vollständig. Die Cloud-Version wird in Deutschland unter EU-Rechtsordnung mit Zero-Knowledge-Verschlüsselung gehostet. Beide Optionen umfassen Audit-Protokolle, Compliance-Berichte und rollenbasierte Zugriffskontrolle zur Unterstützung der DSGVO-, NIS2- und DORA-Anforderungen.

Prävention von Datenschutzverletzungen für Unternehmen: Über einfachen Virenschutz hinaus

82 % der Angriffe im Jahr 2026 sind malware-frei — Virenschutz wird sie nicht erkennen. Dieser Leitfaden behandelt eine 7-Schichten-Verteidigungsstrategie, die für Anmeldedatendiebstahl, laterale Bewegung und Lieferkettenangriffe konzipiert ist.

Passwork BlogAlex Muntyan

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

Die Wahl, wo Sie Ihren Passwort-Manager betreiben, ist genauso wichtig wie die Wahl, welchen Sie verwenden. Dieser Leitfaden erklärt Cloud-, Self-Hosted- und Hybrid-Bereitstellung — mit einer Compliance-Matrix für DSGVO, HIPAA und NIS2 und einem klaren Blick auf die Kompromisse jedes Modells.

Passwork BlogAlex Muntyan

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

Das Frühjahr 2026 brachte den bedeutendsten institutionellen Sicherheitsvorfall der EU, ihre ersten Cybersanktionen des Jahres und vier wichtige Cybersicherheitsvorschriften, die gleichzeitig in Kraft treten. NIS2, DORA, CRA und CSA2 setzen nun harte Fristen — und echte Strafen. Hier erfahren Sie, was sich geändert hat, wer betroffen ist und was zu tun ist.

Passwork BlogAlex Muntyan

Introducción

Residencia de datos y soberanía de datos suenan casi como lo mismo. Pero no lo son.

Muchas organizaciones europeas eligen un proveedor estadounidense, seleccionan la opción de centro de datos en la UE y consideran resuelta la cuestión de la residencia de datos. Legalmente, no lo está. La ley CLOUD Act de EE. UU. otorga a las autoridades federales estadounidenses el poder de obligar a cualquier empresa constituida en EE. UU. a entregar datos almacenados en cualquier parte del mundo. Los datos están en Europa. La obligación legal no.

Esta es la tensión que enfrentan las empresas europeas al elegir cómo alojar un gestor de contraseñas. GDPR, NIS2, DORA y la CLOUD Act crean requisitos superpuestos que no se resuelven eligiendo el centro de datos más cercano. El modelo de alojamiento (quién posee la infraestructura, bajo qué jurisdicción, con qué nivel de control organizativo) es lo que realmente determina el panorama de cumplimiento.

Esta guía mapea los modelos de alojamiento disponibles para las organizaciones europeas, el marco regulatorio que configura cada uno y los criterios que deben guiar la decisión.

Puntos clave

• Elegir un centro de datos en la UE no resuelve la soberanía de datos. Si el proveedor está constituido en EE. UU., la CLOUD Act le obliga a entregar datos a las autoridades estadounidenses — independientemente de dónde se encuentren físicamente los servidores.
• Cuatro marcos regulatorios configuran la decisión de alojamiento. GDPR, NIS2, DORA y la CLOUD Act de EE. UU. crean obligaciones superpuestas que ninguna selección de centro de datos por sí sola puede satisfacer. El modelo de alojamiento es lo que determina la defensibilidad legal.
• El despliegue local es el único modelo que elimina el acceso de terceros por diseño. Elimina completamente la exposición a la CLOUD Act y otorga a la organización control total de la infraestructura, pero requiere capacidad interna de TI para operar y mantener.
• La nube soberana de la UE es un punto intermedio creíble. Se proyecta que el gasto europeo en IaaS de nube soberana alcanzará los 12.600 millones de dólares en 2026 — un aumento del 83% interanual (Gartner, 2026). El modelo ofrece infraestructura gestionada sin riesgo de jurisdicción extranjera.
• El modelo adecuado depende de cuatro variables. La clasificación del sector, la exposición regulatoria, la capacidad interna de TI y el coste total de propiedad determinan si el despliegue local, la nube soberana de la UE o la arquitectura híbrida es la opción defendible.

El espectro de alojamiento europeo

Las organizaciones europeas tienen cinco configuraciones de alojamiento distintas disponibles para un gestor de contraseñas. Dos quedan fuera de la consideración realista de cumplimiento para la mayoría de las empresas de la UE. Tres merecen una evaluación en profundidad.

Nube estadounidense con centro de datos en EE. UU. queda fuera del alcance de esta guía y, para la mayoría de las organizaciones europeas, fuera del alcance de la consideración realista. Cuando los servidores están ubicados en Estados Unidos y la empresa matriz está constituida en EE. UU., los datos residen físicamente fuera de la UE. Esa combinación activa las obligaciones de transferencia del GDPR según los Artículos 44–49 y crea exposición total a la CLOUD Act simultáneamente.

Nube estadounidense con centro de datos en la UE es un paso más cerca del cumplimiento — pero no una solución limpia. El proveedor del gestor de contraseñas opera servidores en una región de la UE (por ejemplo, Fráncfort, Dublín), por lo que los datos residen físicamente en Europa. Eso satisface los requisitos de residencia de datos del GDPR sobre el papel. Sin embargo, cuando la empresa matriz está constituida en EE. UU., la CLOUD Act de EE. UU. se aplica independientemente de dónde estén los servidores. Las autoridades estadounidenses pueden obligar legalmente al acceso a esos datos sin invocar los canales legales de la UE. El riesgo es menor que en el modelo anterior, pero la soberanía no está garantizada.

Los tres modelos que vale la pena evaluar:

• Nube soberana de la UE. El servicio se ejecuta en infraestructura propiedad de proveedores con sede en la UE y operada por ellos, fuera de la jurisdicción estadounidense u otra extranjera. Este modelo aborda los requisitos de residencia de datos del GDPR y elimina la exposición a la CLOUD Act.
• Despliegue local. El gestor de contraseñas se ejecuta completamente dentro de la propia infraestructura de la organización (servidores físicos, nube privada o entornos aislados). Ningún proveedor externo tiene acceso a los datos de credenciales. Este es el único modelo que proporciona control completo de la infraestructura.
• Arquitectura híbrida. Una combinación de bóvedas locales para credenciales sensibles y acceso basado en la nube para equipos distribuidos. Requiere un diseño cuidadoso de políticas para evitar crear brechas de cumplimiento entre los dos entornos.

La elección entre estos modelos es una cuestión de regulación y gestión de riesgos.

Cómo las regulaciones de la UE dictan el alojamiento de gestores de contraseñas

GDPR, NIS2, DORA y la CLOUD Act de EE. UU. imponen cada una obligaciones específicas que restringen directamente qué modelo de alojamiento puede elegir defensiblemente una organización europea. Comprender la interacción entre estos marcos es el punto de partida para cualquier decisión de despliegue.

GDPR y residencia de datos

El Reglamento General de Protección de Datos es el principal marco legal de la UE que rige la recopilación, almacenamiento y transferencia de datos personales. Se aplica a cualquier organización que procese datos personales de residentes de la UE, independientemente de dónde esté ubicada esa organización.

El GDPR no exige explícitamente que los datos se almacenen dentro de la UE. Lo que exige es que los datos personales transferidos fuera de la UE estén protegidos con un estándar equivalente — a través de Cláusulas Contractuales Tipo (CCT), decisiones de adecuación u otros mecanismos de transferencia según los Artículos 44–49. Para un gestor de contraseñas que almacena credenciales de empleados y metadatos asociados (nombres de usuario, URL, direcciones de correo electrónico), el GDPR se aplica directamente.

«Cualquier transferencia de datos personales que estén siendo objeto de tratamiento o que vayan a ser objeto de tratamiento después de la transferencia a un tercer país o a una organización internacional solo se efectuará si, a reserva de las demás disposiciones del presente Reglamento, el responsable y el encargado del tratamiento cumplen las condiciones establecidas en el presente capítulo.» — GDPR, Artículo 44 (Principio general de las transferencias)

El riesgo no es teórico. En agosto de 2024, la Autoridad de Protección de Datos de los Países Bajos multó a Uber con 290 millones de euros por transferir los datos personales de conductores de taxi europeos a servidores de EE. UU. sin aplicar ninguna de las salvaguardas requeridas según el Capítulo V del GDPR. Sin Cláusulas Contractuales Tipo, sin decisión de adecuación, sin mecanismo alternativo de transferencia. La violación abarcó más de dos años. El caso ilustra directamente cómo es la aplicación del Artículo 44 en la práctica: datos de empleados, infraestructura transfronteriza y una multa de nueve cifras.

NIS2 e infraestructura crítica

La Directiva NIS2 (Directiva de Seguridad de las Redes y de la Información 2) es la principal legislación de ciberseguridad de la UE, que sustituye a la Directiva NIS original de 2016. Establece requisitos de seguridad vinculantes para las organizaciones que operan en sectores críticos en los Estados miembros de la UE, con un enfoque en la gestión de riesgos, la notificación de incidentes y la seguridad de la cadena de suministro.

NIS2 amplía significativamente el alcance de las organizaciones clasificadas como entidades «esenciales» o «importantes». Sectores que incluyen energía, transporte, banca, sanidad, infraestructura digital y administración pública ahora deben tratar a sus proveedores de tecnología como parte de su perímetro de seguridad, no solo su infraestructura interna.

Un gestor de contraseñas que almacena credenciales en un entorno de nube de terceros entra dentro de ese perímetro. Es un proveedor directo de un servicio crítico para la seguridad. El Artículo 21(2) de NIS2 requiere que las entidades cubiertas implementen medidas que incluyan al menos:

«Seguridad de la cadena de suministro, incluidos los aspectos relacionados con la seguridad relativos a las relaciones entre cada entidad y sus proveedores o prestadores de servicios directos.» — Directiva NIS2, Artículo 21(2), Directiva (UE) 2022/2555

Elegir un proveedor de nube con sede en EE. UU. para el almacenamiento de credenciales sin una evaluación de riesgos documentada crea una brecha de cumplimiento concreta. Según NIS2, las autoridades de supervisión nacionales pueden emitir instrucciones vinculantes e imponer multas. Para las entidades esenciales, el Artículo 20 también establece responsabilidad personal para los miembros del órgano de dirección.

DORA y especificidades del sector financiero

El Reglamento de Resiliencia Operativa Digital (DORA) es el marco regulatorio de la UE para la resiliencia operativa digital en el sector financiero. Establece requisitos sobre cómo las entidades financieras gestionan los riesgos de tecnologías de la información y la comunicación (TIC), cubriendo dependencias de terceros, notificación de incidentes y pruebas de resiliencia, para garantizar la estabilidad de los servicios financieros en toda la UE.

Un gestor de contraseñas alojado en la nube califica como un servicio TIC de terceros según DORA. Esa clasificación activa obligaciones contractuales específicas — incluyendo el requisito de documentar dónde se almacenan y procesan los datos. El Artículo 30(2)(b) del Reglamento (UE) 2022/2554 establece:

«Las ubicaciones, es decir, las regiones o países, donde se prestarán las funciones contratadas o subcontratadas y los servicios de TIC y donde se procesarán los datos, incluida la ubicación de almacenamiento, y el requisito de que el proveedor tercero de servicios de TIC notifique a la entidad financiera con antelación si prevé modificar dichas ubicaciones.» — DORA, Artículo 30(2)(b), Reglamento (UE) 2022/2554

Si el proveedor del gestor de contraseñas tiene sede en EE. UU., la institución financiera debe documentar cómo gestiona la exposición a la CLOUD Act y garantizar que el contrato cumpla con los requisitos de DORA sobre acceso a datos, portabilidad y terminación.

La CLOUD Act de EE. UU.

La Ley de Clarificación del Uso Legal de Datos en el Extranjero (CLOUD Act, 2018) es una ley federal de EE. UU. que permite a las agencias de aplicación de la ley obligar a las empresas constituidas en EE. UU. a entregar datos almacenados en cualquier parte del mundo, incluidos servidores ubicados en centros de datos de la UE. La obligación se aplica independientemente de dónde residan físicamente los datos. El factor determinante es la jurisdicción corporativa del proveedor.

El estatuto es inequívoco en este punto:

«Un proveedor de servicio de comunicación electrónica o servicio de computación remota deberá cumplir con las obligaciones de este capítulo de preservar, respaldar o divulgar el contenido de una comunicación electrónica o por cable y cualquier registro u otra información perteneciente a un cliente o suscriptor dentro de la posesión, custodia o control de dicho proveedor, independientemente de si dicha comunicación, registro o información se encuentra dentro o fuera de los Estados Unidos.» — 18 U.S.C. § 2713, Pub. L. 115–141, div. V, §103(a)(1), 23 de marzo de 2018

La empresa puede impugnar la orden, pero la obligación legal existe independientemente de dónde estén ubicados los servidores.

Para las organizaciones europeas que manejan credenciales sensibles (acceso privilegiado, contraseñas de sistemas financieros, claves de infraestructura) esto crea un riesgo estructural que los centros de datos en la región de la UE por sí solos no resuelven. La nube soberana o el despliegue local son los únicos modelos que eliminan esta exposición por completo.

Passwork es un gestor de contraseñas europeo creado exactamente para este entorno regulatorio, con opciones tanto locales como en la nube diseñadas en torno al cumplimiento de GDPR y NIS2 y la soberanía de datos. Vea cómo funciona

Gestores de contraseñas en la nube en Europa: Conveniencia vs control

Alojamiento en la nube significa que los servidores del proveedor almacenan y procesan sus datos — la organización accede al servicio a través de internet sin gestionar ninguna infraestructura subyacente. Para los gestores de contraseñas, esto significa que las credenciales, los metadatos y los registros de acceso residen en servidores propiedad de un tercero y operados por él, en centros de datos que la organización no controla.

Los gestores de contraseñas alojados en la nube ofrecen despliegue rápido, actualizaciones automáticas y sin sobrecarga de infraestructura. Para muchas organizaciones europeas, son la opción predeterminada — el 53% de las empresas de la UE utilizaron servicios de computación en la nube de pago en 2025, 7,4 puntos porcentuales más que en 2023 (Eurostat, 2026).

El atractivo es sencillo: no hay servidores que mantener, el proveedor se encarga de los parches y el acceso funciona desde cualquier dispositivo. Para las PYMES sin equipos de seguridad dedicados, esto reduce la barrera para implementar una gestión adecuada de credenciales.

Dónde la nube se queda corta para las organizaciones de la UE

El modelo de responsabilidad compartida es el problema central. En un despliegue en la nube, el proveedor controla la infraestructura, la arquitectura de gestión de claves de cifrado y los sistemas de respaldo. La organización controla el acceso de usuarios y las políticas, pero no el entorno de datos subyacente.

La arquitectura de conocimiento cero aborda parcialmente esto: si el proveedor nunca posee las claves de descifrado, una brecha del lado del servidor no puede exponer credenciales en texto plano. La multa del ICO contra LastPass ilustra los límites — la brecha expuso metadatos (nombres, correos electrónicos, URL) aunque el contenido cifrado de las bóvedas estaba protegido. Los metadatos son datos personales según el GDPR.

El cifrado AES-256 en reposo es un requisito básico, no un diferenciador. Lo que importa es dónde se generan y almacenan las claves, quién puede acceder a ellas y si la arquitectura del proveedor mantiene esas claves fuera de su propio alcance.

Gestores de contraseñas locales: Máxima soberanía

El despliegue local significa que el gestor de contraseñas se ejecuta en servidores que la organización posee y opera — ningún proveedor tiene acceso de red al almacén de credenciales. Todas las credenciales, metadatos y registros de acceso permanecen dentro del propio perímetro de infraestructura de la organización.

Este es el único modelo de alojamiento que satisface completamente los requisitos de soberanía de datos y elimina la exposición a terceros por diseño.

Para organizaciones en sectores regulados (instituciones financieras, proveedores de atención sanitaria, operadores de infraestructura crítica según NIS2) el despliegue local elimina toda una categoría de riesgo de terceros de la ecuación de cumplimiento.

Dónde el despliegue local es la única opción viable

Los entornos aislados representan la variante más segura: el gestor de contraseñas opera en una red sin conectividad a internet. Esto es relevante para sistemas de control industrial, entornos clasificados o cualquier contexto donde el almacén de credenciales deba estar físicamente aislado de redes externas.

Como se cubrió anteriormente, el despliegue local con un proveedor no estadounidense es el único modelo que elimina completamente la exposición a la CLOUD Act al eliminar la jurisdicción corporativa estadounidense que activa la obligación en primer lugar.

Despliegue local: Ventajas y desventajas

El cálculo del TCO desplaza los costes de las tarifas SaaS recurrentes al trabajo de TI interno y la infraestructura. Para organizaciones que ya operan sus propios servidores y tienen un equipo de seguridad en su lugar, el coste marginal de añadir un gestor de contraseñas autoalojado es a menudo menor de lo que parece.

El coste real del despliegue local es la disciplina operativa necesaria para mantenerlo. Las empresas que carecen de un equipo de seguridad dedicado o un proceso maduro de gestión de parches encontrarán la columna de limitaciones más difícil de gestionar de lo que sugiere la columna de ventajas.

Passwork está disponible como una solución completamente autoalojada: desplegada en los propios servidores de la organización, sin conexiones salientes. El código fuente está disponible para auditoría, y la plataforma soporta entornos aislados. Para equipos que necesitan demostrar soberanía total de datos a auditores o reguladores, este es el modelo de despliegue que cierra el argumento.

Passwork local otorga a su equipo control total de la infraestructura — sin acceso de terceros, sin excepciones. Explore el despliegue local

El punto intermedio de la nube soberana

Los proveedores de nube soberana de la UE ofrecen una tercera vía: infraestructura gestionada con la comodidad del estilo de la nube, operada completamente dentro de la jurisdicción de la UE y fuera del alcance de los marcos legales extranjeros. Se proyecta que el gasto europeo en IaaS de nube soberana alcanzará los 12.600 millones de dólares en 2026, un aumento del 83% respecto a 2025 (Gartner, 2026).

El crecimiento está impulsado por la presión geopolítica. La CLOUD Act de EE. UU., combinada con incidentes de alto perfil que involucran dependencia de hiperescaladores, ha llevado a las organizaciones europeas a reconsiderar sus elecciones de proveedores de nube.

Para un gestor de contraseñas desplegado en infraestructura de nube soberana, el entorno de alojamiento proporciona evidencia documentada de que los datos permanecen dentro de la jurisdicción de la UE — directamente relevante para la documentación de cumplimiento de NIS2 y las evaluaciones de riesgo de terceros de DORA.

La nube soberana aborda la jurisdicción y el control de la infraestructura. No reemplaza la necesidad de evaluar la propia aplicación del gestor de contraseñas. La capa de alojamiento y la capa de aplicación son cuestiones de seguridad separadas.

Arquitectura híbrida

Una arquitectura híbrida combina bóvedas locales para credenciales sensibles con acceso basado en la nube para equipos distribuidos. Es una decisión de política e ingeniería que requiere límites explícitos entre lo que permanece local y lo que pasa por infraestructura externa.

El atractivo es práctico. Las organizaciones con equipos remotos o distribuidos internacionalmente no siempre pueden enrutar cada solicitud de autenticación a través de un sistema local sin introducir latencia o riesgos de disponibilidad. Una configuración híbrida permite a los equipos de seguridad mantener las clases de credenciales más sensibles (cuentas privilegiadas, secretos de infraestructura, credenciales sensibles para el cumplimiento) en una bóveda controlada localmente, mientras extienden el acceso a recursos menos sensibles a través de una capa en la nube.

La complejidad del cumplimiento, sin embargo, escala con la arquitectura. Cada límite entre los componentes locales y en la nube es una brecha potencial: en cobertura de auditoría, en aplicación de políticas de acceso, en alcance de respuesta a incidentes. Si la capa en la nube cae bajo una jurisdicción extranjera, las protecciones de soberanía del componente local no se extienden automáticamente a ella.

La arquitectura híbrida es el modelo más flexible en este espectro — y el más exigente de operar correctamente. Para organizaciones con la capacidad de ingeniería para gestionarlo, ofrece un equilibrio viable entre control y accesibilidad. Para aquellas sin ella, el despliegue local o la nube soberana de la UE es la opción más defendible.

Passwork para empresas europeas: Construido para la soberanía desde el principio

Passwork es un gestor de contraseñas europeo — constituido y operado como empresa europea, con su base legal en España bajo la legislación de la UE. Fue construido primero para despliegue local, para organizaciones que necesitan control total de la infraestructura, y desde entonces ha añadido una opción en la nube alojada completamente dentro de la UE.

Esto importa para las empresas europeas porque la propia jurisdicción del proveedor es parte del panorama de cumplimiento. Una empresa europea que opera bajo la legislación de la UE no tiene exposición a la CLOUD Act de EE. UU. La arquitectura y las opciones de despliegue de Passwork fueron diseñadas teniendo en cuenta este contexto regulatorio.

Despliegue local

Passwork local se ejecuta completamente dentro de la propia infraestructura de la organización. El proveedor no tiene acceso al almacén de credenciales — sin acceso remoto, sin telemetría y sin puerta trasera. Todos los datos, claves de cifrado y copias de seguridad permanecen dentro de los sistemas de la organización.

Capacidades clave para entornos regulados:

• Control total de la infraestructura — despliegue en sus propios servidores, nube privada o redes aisladas. Soporta entornos sin conectividad a internet.
• Arquitectura de conocimiento cero — las credenciales se cifran y descifran en el lado del cliente. El servidor almacena solo texto cifrado y nunca procesa contraseñas en texto plano, lo que significa que un servidor comprometido no expone nada legible.
• Control de acceso basado en roles — permisos granulares a nivel de bóveda, carpeta y credencial. Se integra con Active Directory, Azure AD, LDAP y SSO SAML para el aprovisionamiento automatizado de usuarios y la gestión del ciclo de vida.
• Registros de auditoría — historial completo de actividad para cada acceso, modificación y evento de compartición de credenciales. Soporta directamente los requisitos de responsabilidad del GDPR y la documentación de incidentes de NIS2.
• Cifrado AES-256 — credenciales cifradas en reposo y en tránsito. Las claves permanecen dentro de la infraestructura de la organización.
• Informes de cumplimiento — informes integrados para auditorías de seguridad, revisiones de acceso y documentación regulatoria.
• Escala de 10 a más de 30.000 usuarios — la misma arquitectura funciona para un equipo de TI de mercado medio y una gran empresa con estructuras de permisos complejas.

La mayoría de los clientes de Passwork eligen el despliegue local, según los datos internos de la empresa. Esto es especialmente cierto para grandes empresas, organismos gubernamentales y organizaciones en industrias altamente reguladas.

Passwork Cloud: Alojado en la UE, conocimiento cero

Passwork Cloud está alojado en Alemania. Todos los datos permanecen dentro de la jurisdicción de la UE, procesados y almacenados bajo la legislación de la UE.

La arquitectura utiliza cifrado del lado del cliente con diseño de conocimiento cero: el servidor nunca ve credenciales en texto plano. El cifrado y descifrado ocurren en el lado del cliente, por lo que incluso en caso de un incidente del lado del servidor, los datos de credenciales permanecen protegidos.

Passwork Cloud incluye el conjunto completo de funciones empresariales:

• Gestión de usuarios, integración con Active Directory / LDAP, SSO
• Registros de auditoría e informes de cumplimiento
• MFA avanzado y políticas de seguridad
• Extensiones de navegador, aplicaciones móviles y REST API
• Gestión de secretos DevOps — CLI, biblioteca Python, integración con Kubernetes, soporte de pipelines CI/CD

Los precios comienzan en 3 € por usuario al mes (licencia estándar) y 4,50 € por usuario al mes (licencia avanzada). Los costes de propiedad a largo plazo son aproximadamente un 30% inferiores al promedio de la industria.

Postura de seguridad

Passwork posee certificación ISO 27001 en desarrollo, infraestructura y operaciones. La empresa realiza pruebas de penetración anuales por terceros, incluso a través de HackerOne, y aplica un enfoque DevSecOps con análisis estático y dinámico integrado en cada compilación.

Esta postura de seguridad es directamente relevante para las organizaciones que necesitan documentar las prácticas de seguridad de su proveedor de gestor de contraseñas — un requisito tanto del Artículo 21 de NIS2 como del marco de gestión de riesgos de terceros de DORA.

Marco de decisión: Eligiendo el modelo adecuado para su organización

El modelo de alojamiento adecuado depende de cuatro variables: exposición regulatoria, clasificación del sector, capacidad interna de TI y coste total de propiedad. La tabla siguiente mapea perfiles organizativos comunes a modelos de despliegue recomendados.

Consideraciones de TCO

El coste total de propiedad para cada modelo incluye más que costes de licencia o infraestructura. La sobrecarga de cumplimiento es una partida real: el tiempo dedicado a evaluaciones de riesgo de proveedores, documentación de auditoría y planificación de respuesta a incidentes varía significativamente según el modelo.

El despliegue local concentra el trabajo de cumplimiento internamente — la organización controla el entorno y puede producir evidencia de auditoría directamente. Los despliegues en la nube desplazan parte del trabajo de cumplimiento a la gestión de proveedores: revisar certificaciones de seguridad, negociar términos de DPA, mantener una entrada en el registro de terceros de DORA.

Para las entidades reguladas por NIS2, la sobrecarga de cumplimiento de un despliegue en la nube mal documentado puede superar el coste de infraestructura del despliegue local. Vale la pena hacer ese cálculo antes de optar por defecto por la opción de menor fricción.

Conclusión

El modelo de alojamiento para un gestor de contraseñas es una decisión arquitectónica con implicaciones de cumplimiento a largo plazo. GDPR, NIS2, DORA y la CLOUD Act de EE. UU. crean un entorno regulatorio donde la elección incorrecta genera responsabilidad documentada.

El espectro de modelos ofrece a las organizaciones europeas opciones reales. La elección correcta depende de la clasificación del sector, la exposición regulatoria, la capacidad interna de TI y un cálculo honesto del TCO que incluya la sobrecarga de cumplimiento.

Para organizaciones que necesitan máximo control, el despliegue local elimina completamente la exposición a terceros. Para aquellas que necesitan infraestructura gestionada sin riesgo de jurisdicción extranjera, la nube soberana de la UE es un camino creíble. Las arquitecturas híbridas funcionan cuando ningún extremo se ajusta a la realidad operativa.

Passwork es un gestor de contraseñas europeo que cubre todo el espectro: despliegue local para organizaciones que requieren control completo de la infraestructura, y nube alojada en la UE para equipos que desean alojamiento gestionado sin sacrificar la soberanía de datos. Ambas opciones están construidas sobre la misma arquitectura de cifrado de conocimiento cero e incluyen las funciones de auditoría, control de acceso e informes de cumplimiento que necesitan las empresas europeas reguladas.

¿Listo para dar el primer paso? Inicie su prueba gratuita de Passwork para obtener control completo, gestión automatizada de credenciales y protección de datos de nivel empresarial.

Preguntas frecuentes

¿Es un gestor de contraseñas en la nube compatible con el GDPR?

Un gestor de contraseñas en la nube puede ser compatible con el GDPR si el proveedor procesa datos personales bajo una base legal válida, proporciona un Acuerdo de Procesamiento de Datos (DPA) que cumpla con los requisitos del Artículo 28, y aplica salvaguardas apropiadas para cualquier transferencia de datos fuera de la UE. El cumplimiento depende de la arquitectura y los términos contractuales del proveedor — no solo del alojamiento en la nube.

¿Exige el GDPR que los datos se almacenen en Europa?

El GDPR no obliga al almacenamiento de datos en la UE. Exige que los datos personales transferidos fuera de la UE estén protegidos con un estándar equivalente — a través de decisiones de adecuación, Cláusulas Contractuales Tipo u otros mecanismos según los Artículos 44–49. Almacenar datos en la UE simplifica el cumplimiento pero no es un requisito legal según el propio reglamento.

¿Qué es la CLOUD Act de EE. UU. y por qué importa a las empresas de la UE?

La CLOUD Act de EE. UU. (2018) permite a las autoridades federales estadounidenses obligar a las empresas constituidas en EE. UU. a entregar datos almacenados en cualquier parte del mundo, incluidos centros de datos de la UE. Para las organizaciones europeas que utilizan proveedores de gestores de contraseñas con sede en EE. UU., esto significa que los datos de credenciales podrían estar sujetos al acceso del gobierno estadounidense independientemente de dónde estén ubicados físicamente los servidores.

¿Cuándo se aplica NIS2 a las decisiones de alojamiento de gestores de contraseñas?

NIS2 se aplica cuando la organización está clasificada como entidad «esencial» o «importante» — cubriendo energía, transporte, banca, sanidad, infraestructura digital y administración pública, entre otros. Para estas organizaciones, un gestor de contraseñas es parte de la cadena de suministro TIC, y el Artículo 21 requiere medidas de seguridad documentadas para todos los componentes de la cadena de suministro.

¿Qué exige DORA para los gestores de contraseñas alojados en la nube en servicios financieros?

DORA exige que las entidades financieras mantengan un registro de proveedores de servicios TIC de terceros, realicen evaluaciones de riesgo de proveedores críticos y garanticen que los contratos incluyan derechos de auditoría, acceso a datos y salida. Un gestor de contraseñas alojado en la nube utilizado por una institución financiera es un servicio TIC de terceros según DORA — la institución debe documentar y gestionar esta dependencia formalmente.

¿Cuál es la diferencia entre una nube soberana de la UE y un centro de datos regular de la UE?

Un centro de datos regular de la UE operado por una empresa estadounidense sigue estando sujeto a la jurisdicción de EE. UU. a través de la CLOUD Act. Un proveedor de nube soberana está constituido y opera completamente dentro de la UE, sin obligación legal de cumplir con solicitudes de datos de gobiernos extranjeros. La distinción importa para las evaluaciones de riesgo de transferencia del GDPR y la documentación de la cadena de suministro de NIS2.

¿Cómo apoya Passwork el cumplimiento para las organizaciones europeas?

Passwork es una empresa europea bajo la legislación de la UE, con certificación ISO 27001, y opciones de despliegue local y en la nube alojada en la UE. El despliegue local elimina completamente el acceso de terceros. La versión en la nube está alojada en Alemania bajo jurisdicción de la UE con cifrado de conocimiento cero. Ambas opciones incluyen registros de auditoría, informes de cumplimiento y control de acceso basado en roles para apoyar los requisitos de GDPR, NIS2 y DORA.

Prevención de brechas de datos para empresas: Más allá del antivirus básico

El 82% de los ataques en 2026 no usan malware — el antivirus no los detectará. Esta guía cubre una estrategia de defensa de 7 capas diseñada para el robo de credenciales, el movimiento lateral y el compromiso de la cadena de suministro.

Passwork BlogAlex Muntyan

Modelos de despliegue de gestores de contraseñas: Nube, autoalojado e híbrido

Elegir dónde ejecutar su gestor de contraseñas importa tanto como elegir cuál. Esta guía desglosa el despliegue en la nube, autoalojado e híbrido — con una matriz de cumplimiento para GDPR, HIPAA y NIS2, y una visión clara de las compensaciones que conlleva cada modelo.

Passwork BlogAlex Muntyan

Actualización de ciberseguridad de la UE primavera 2026: Qué cambió

La primavera de 2026 trajo la brecha institucional más significativa de la UE, sus primeras sanciones cibernéticas del año y cuatro importantes regulaciones de ciberseguridad aplicándose simultáneamente. NIS2, DORA, CRA y CSA2 ahora establecen plazos firmes — y sanciones reales. Esto es lo que cambió, quién está afectado y qué hacer.

Passwork BlogAlex Muntyan

Introduction

Data residency and data sovereignty sound almost like the same thing. But they aren't.

Many European organizations choose a US-based vendor, select the EU data center option, and consider the data residency question resolved. Legally, it isn't. The US CLOUD Act gives American federal authorities the power to compel any US-incorporated company to produce data stored anywhere in the world. The data is in Europe. The legal obligation is not.

This is the tension European businesses run into when choosing how to host a password manager. GDPR, NIS2, DORA, and the CLOUD Act create overlapping requirements that don't resolve by picking the nearest data center. The hosting model (who owns the infrastructure, under which jurisdiction, with what level of organizational control) is what actually determines the compliance picture.

This guide maps the hosting models available to European organizations, the regulatory framework that shapes each one, and the criteria that should drive the decision.

Key takeaways

• Choosing an EU data center does not resolve data sovereignty. If the vendor is US-incorporated, the CLOUD Act compels them to produce data for American authorities — regardless of where the servers physically sit.
• Four regulatory frameworks shape the hosting decision. GDPR, NIS2, DORA, and the US CLOUD Act create overlapping obligations that no data center selection alone can satisfy. The hosting model is what determines legal defensibility.
• On-premises is the only model that eliminates third-party access by design. It removes CLOUD Act exposure entirely and gives the organization full infrastructure control, but requires internal IT capacity to operate and maintain.
• Sovereign EU cloud is a credible middle ground. European spending on sovereign cloud IaaS is projected to reach $12.6 billion in 2026 — an 83% increase year-over-year (Gartner, 2026). The model delivers managed infrastructure without foreign jurisdiction risk.
• The right model depends on four variables. Sector classification, regulatory exposure, internal IT capacity, and total cost of ownership determine whether on-premises, sovereign EU cloud, or hybrid architecture is the defensible choice.

The European hosting spectrum

European organizations have five distinct hosting configurations available for a password manager. Two fall outside realistic compliance consideration for most EU businesses. Three are worth evaluating in depth.

US cloud with US data center sits outside the scope of this guide and, for most European organizations, outside the scope of realistic consideration. When servers are located in the United States and the parent company is US-incorporated, data physically resides outside the EU. That combination triggers GDPR transfer obligations under Articles 44–49 and creates full CLOUD Act exposure simultaneously.

US cloud with EU data center is a step closer to compliance — but not a clean solution. The password manager vendor operates servers in an EU region (e.g., Frankfurt, Dublin), so data physically resides in Europe. That satisfies GDPR data residency requirements on paper. However, when the parent company is US-incorporated, the US CLOUD Act applies regardless of where the servers sit. American authorities can legally compel access to that data without invoking EU legal channels. The risk is lower than the previous model, but sovereignty is not guaranteed

The three models worth evaluating:

• Sovereign EU cloud. The service runs on infrastructure owned and operated by EU-based providers, outside US or other foreign jurisdiction. This model addresses GDPR data residency requirements and eliminates CLOUD Act exposure.
• On-premises deployment. The password manager runs entirely within the organization's own infrastructure (physical servers, private cloud, or air-gapped environments). No third-party vendor has access to credential data. This is the only model that gives complete infrastructure control.
• Hybrid architecture. A combination of on-premises vaults for sensitive credentials and cloud-based access for distributed teams. Requires careful policy design to avoid creating compliance gaps between the two environments.

The choice between these models is a regulatory and risk management question.

How EU regulations dictate password manager hosting

GDPR, NIS2, DORA, and the US CLOUD Act each impose specific obligations that directly constrain which hosting model a European organization can defensibly choose. Understanding the interaction between these frameworks is the starting point for any deployment decision.

GDPR and data residency

The General Data Protection Regulation is the EU's primary legal framework governing the collection, storage, and transfer of personal data. It applies to any organization processing the personal data of EU residents, regardless of where that organization is based.

GDPR does not explicitly require data to be stored within the EU. What it requires is that personal data transferred outside the EU is protected to an equivalent standard — through Standard Contractual Clauses (SCCs), adequacy decisions, or other transfer mechanisms under Articles 44–49. For a password manager storing employee credentials and associated metadata (usernames, URLs, email addresses), GDPR applies directly.

"Any transfer of personal data which are undergoing processing or are intended for processing after transfer to a third country or to an international organisation shall take place only if, subject to the other provisions of this Regulation, the conditions laid down in this Chapter are complied with by the controller and processor." — GDPR, Article 44 (General principle for transfers)

The risk is not theoretical. In August 2024, the Dutch Data Protection Authority fined Uber €290 million for transferring the personal data of European taxi drivers to US servers without applying any of the safeguards required under GDPR Chapter V. No Standard Contractual Clauses, no adequacy decision, no alternative transfer mechanism. The violation spanned more than two years. The case directly illustrates what Article 44 enforcement looks like in practice: employee data, cross-border infrastructure, and a nine-figure penalty.

NIS2 and critical infrastructure

The NIS2 Directive (Network and Information Security Directive 2) is the EU's primary cybersecurity legislation, replacing the original NIS Directive from 2016. It establishes binding security requirements for organizations operating in critical sectors across EU member states, with a focus on risk management, incident reporting, and supply chain security.

NIS2 significantly expands the scope of organizations classified as "essential" or "important" entities. Sectors including energy, transport, banking, healthcare, digital infrastructure, and public administration must now treat their technology vendors as part of their security perimeter, not just their internal infrastructure.

A password manager storing credentials in a third-party cloud environment falls within that perimeter. It is a direct supplier of a security-critical service. NIS2 Article 21(2) requires covered entities to implement measures that include at least:

"Supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." — NIS2 Directive, Article 21(2), Directive (EU) 2022/2555

Choosing a US-based cloud provider for credential storage without a documented risk assessment creates a concrete compliance gap. Under NIS2, national supervisory authorities can issue binding instructions and impose fines. For essential entities, Article 20 also establishes personal liability for members of the management body.

DORA and financial sector specifics

The Digital Operational Resilience Act (DORA) is the EU's regulatory framework for digital operational resilience in the financial sector. It sets requirements for how financial entities manage information and communication technology (ICT) risks, covering third-party dependencies, incident reporting, and resilience testing, to ensure the stability of financial services across the EU.

A cloud-hosted password manager qualifies as an ICT third-party service under DORA. That classification triggers specific contractual obligations — including a requirement to document where data is stored and processed. Article 30(2)(b) of Regulation (EU) 2022/2554 states:

"The locations, namely the regions or countries, where the contracted or subcontracted functions and ICT services are to be provided and where data is to be processed, including the storage location, and the requirement for the ICT third-party service provider to notify the financial entity in advance if it envisages changing such locations" — DORA, Article 30(2)(b), Regulation (EU) 2022/2554

If the password manager provider is US-based, the financial institution must document how it manages CLOUD Act exposure and ensure the contract meets DORA's requirements for data access, portability, and termination.

The US CLOUD Act

The Clarifying Lawful Overseas Use of Data Act (CLOUD Act, 2018) is a US federal law that allows law enforcement agencies to compel US-incorporated companies to produce data stored anywhere in the world, including servers located in EU data centers. The obligation applies regardless of where the data physically resides. The determining factor is the corporate jurisdiction of the provider.

The statute is unambiguous on this point:

"A provider of electronic communication service or remote computing service shall comply with the obligations of this chapter to preserve, backup, or disclose the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber within such provider's possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States." — 18 U.S.C. § 2713, Pub. L. 115–141, div. V, §103(a)(1), March 23, 2018

The company can challenge the order, but the legal obligation exists regardless of where the servers are located.

For European organizations handling sensitive credentials (privileged access, financial system passwords, infrastructure keys) this creates a structural risk that EU-region data centers alone do not resolve. Sovereign cloud or on-premises deployment are the only models that eliminate this exposure entirely.

Passwork is a European password manager built for exactly this regulatory environment with both on-premises and cloud options designed around GDPR and NIS2 compliance and data sovereignty. See how it works

Cloud password managers in Europe: Convenience vs control

Cloud hosting means the vendor's servers store and process your data — the organization accesses the service over the internet without managing any underlying infrastructure. For password managers, this means credentials, metadata, and access logs reside on servers owned and operated by a third party, in data centers the organization does not control.

Cloud-hosted password managers offer fast deployment, automatic updates, and no infrastructure overhead. For many European organizations, they are the default choice — 53% of EU enterprises used paid cloud computing services in 2025, up 7.4 percentage points from 2023 (Eurostat, 2026).

The appeal is straightforward: no servers to maintain, the vendor handles patching, and access works from any device. For SMBs without dedicated security teams, this lowers the barrier to deploying proper credential management.

Where cloud falls short for EU organizations

The shared responsibility model is the central issue. In a cloud deployment, the vendor controls the infrastructure, the encryption key management architecture, and the backup systems. The organization controls user access and policies but not the underlying data environment.

Zero-knowledge architecture partially addresses this: if the vendor never holds the decryption keys, a server-side breach cannot expose plaintext credentials. The ICO fine against LastPass illustrates the limits — the breach exposed metadata (names, emails, URLs) even though encrypted vault contents were protected. Metadata is personal data under GDPR.

AES-256 encryption at rest is a baseline requirement, not a differentiator. What matters is where keys are generated, stored, and who can access them and whether the vendor's architecture keeps those keys outside their own reach.

On-premises password managers: Maximum sovereignty

On-premises deployment means the password manager runs on servers the organization owns and operates — no vendor has network access to the credential store. All credentials, metadata, and access logs remain within the organization's own infrastructure perimeter.

This is the only hosting model that fully satisfies data sovereignty requirements and eliminates third-party exposure by design.

For organizations in regulated sectors (financial institutions, healthcare providers, critical infrastructure operators under NIS2) on-premises deployment removes an entire category of third-party risk from the compliance equation.

Where on-premises is the only viable option

Air-gapped environments represent the most secure variant: the password manager operates on a network with no internet connectivity. This is relevant for industrial control systems, classified environments, or any context where the credential store must be physically isolated from external networks.

As covered above, on-premises deployment with a non-US vendor is the only model that eliminates CLOUD Act exposure entirely by removing the US corporate jurisdiction that triggers the obligation in the first place.

On-premises deployment: Pros and cons

The TCO calculation shifts costs from recurring SaaS fees to internal IT labor and infrastructure. For organizations that already operate their own servers and have a security team in place, the marginal cost of adding a self-hosted password manager is often lower than it appears.

The real cost of on-premises is the operational discipline required to maintain it. Businesses that lack a dedicated security team or a mature patch management process will find the limitations column harder to manage than the advantages column suggests.

Passwork is available as a fully self-hosted solution: deployed on the organization's own servers, with no outbound connections. The source code is available for audit, and the platform supports air-gapped environments. For teams that need to demonstrate full data sovereignty to auditors or regulators, this is the deployment model that closes the argument.

Passwork on-premises gives your team full infrastructure control — no third-party access, no exceptions. Explore on-premises deployment

The sovereign cloud middle ground

Sovereign EU cloud providers offer a third path: managed infrastructure with cloud-style convenience, operated entirely within EU jurisdiction and outside the reach of foreign legal frameworks. European spending on sovereign cloud IaaS is projected to reach $12.6 billion in 2026, an 83% increase from 2025 (Gartner, 2026).

The growth is driven by geopolitical pressure. The US CLOUD Act, combined with high-profile incidents involving hyperscaler dependency, has pushed European organizations to reconsider their cloud vendor choices.

For a password manager deployed on sovereign cloud infrastructure, the hosting environment provides documented evidence that data stays within EU jurisdiction — directly relevant for NIS2 compliance documentation and DORA third-party risk assessments.

Sovereign cloud addresses jurisdiction and infrastructure control. It does not replace the need to evaluate the password manager application itself. The hosting layer and the application layer are separate security questions.

Hybrid architecture

A hybrid architecture combines on-premises vaults for sensitive credentials with cloud-based access for distributed teams. It is a policy and engineering decision that requires explicit boundaries between what stays local and what moves through external infrastructure.

The appeal is practical. Organizations with remote or internationally distributed teams cannot always route every authentication request through an on-premises system without introducing latency or availability risks. A hybrid setup lets security teams keep the most sensitive credential classes (privileged accounts, infrastructure secrets, compliance-sensitive credentials) in a locally controlled vault, while extending access to less sensitive resources through a cloud layer.

The compliance complexity, however, scales with the architecture. Every boundary between the on-premises and cloud components is a potential gap: in audit coverage, in access policy enforcement, in incident response scope. If the cloud layer falls under a foreign jurisdiction, the sovereignty protections of the on-premises component do not automatically extend to it.

Hybrid architecture is the most flexible model in this spectrum — and the most demanding to operate correctly. For organizations with the engineering capacity to manage it, it offers a workable balance between control and accessibility. For those without, on-premises or sovereign EU cloud is the more defensible choice.

Passwork for European businesses: Built for sovereignty from the start

Passwork is a European password manager — incorporated and operated as a European company, with its legal base in Spain under EU law. It was built on-premises first, for organizations that need full infrastructure control, and has since added a cloud option hosted entirely within the EU.

This matters for European businesses because the vendor's own jurisdiction is part of the compliance picture. A European company operating under EU law does not carry US CLOUD Act exposure. Passwork's architecture and deployment options were designed with this regulatory context in mind.

On-premises deployment

Passwork on-premises runs entirely within the organization's own infrastructure. The vendor has no access to the credential store — no remote access, no telemetry, and no backdoor. All data, encryption keys, and backups remain inside the organization's systems.

Key capabilities for regulated environments:

• Full infrastructure control — deploy on your own servers, private cloud, or air-gapped networks. Supports environments with no internet connectivity.
• Zero-knowledge architecture — credentials are encrypted and decrypted on the client side. The server stores only ciphertext and never processes plaintext passwords, which means a compromised server exposes nothing readable.
• Role-based access control — granular permissions at vault, folder, and credential level. Integrates with Active Directory, Azure AD, LDAP, and SAML SSO for automated user provisioning and lifecycle management.
• Audit logs — complete activity history for every credential access, modification, and sharing event. Directly supports GDPR accountability requirements and NIS2 incident documentation.
• AES-256 encryption — credentials encrypted at rest and in transit. Keys stay within the organization's infrastructure.
• Compliance reports — built-in reporting for security audits, access reviews, and regulatory documentation.
• Scales from 10 to 30,000+ users — the same architecture works for a mid-market IT team and a large enterprise with complex permission structures.

The majority of Passwork's customers choose on-premises deployment, according to the company's internal data. This is especially true for large enterprises, government bodies, and organizations in highly regulated industries.

Passwork Cloud: EU-hosted, zero-knowledge

Passwork Cloud is hosted in Germany. All data stays within EU jurisdiction, processed and stored under EU law.

The architecture uses client-side encryption with zero-knowledge design: the server never sees plaintext credentials. Encryption and decryption happen on the client side, so even in the event of a server-side incident, credential data remains protected.

Passwork Cloud includes the full enterprise feature set:

• User management, Active Directory / LDAP integration, SSO
• Audit logs and compliance reports
• Advanced MFA and security policies
• Browser extensions, mobile apps, and REST API
• DevOps secrets management — CLI, Python library, Kubernetes integration, CI/CD pipeline support

Pricing starts at €3 per user per month (Standard) and €4.50 per user per month (Advanced). Long-term ownership costs run approximately 30% below the industry average.

Security posture

Passwork holds ISO 27001 certification across development, infrastructure, and operations. The company runs annual third-party penetration tests, including through HackerOne, and applies a DevSecOps approach with static and dynamic analysis integrated into every build.

This security posture is directly relevant for organizations that need to document their password manager vendor's security practices — a requirement under both NIS2 Article 21 and DORA's third-party risk management framework.

Decision framework: Choosing the right model for your organization

The right hosting model depends on four variables: regulatory exposure, sector classification, internal IT capacity, and total cost of ownership. The table below maps common organizational profiles to recommended deployment models.

TCO considerations

Total cost of ownership for each model includes more than licensing or infrastructure costs. Compliance overhead is a real line item: the time spent on vendor risk assessments, audit documentation, and incident response planning varies significantly by model.

On-premises deployment concentrates compliance work internally — the organization controls the environment and can produce audit evidence directly. Cloud deployments shift some compliance work to vendor management: reviewing security certifications, negotiating DPA terms, maintaining a DORA third-party register entry.

For NIS2-regulated entities, the compliance overhead of a poorly documented cloud deployment can exceed the infrastructure cost of on-premises deployment. That calculation is worth running before defaulting to the lowest-friction option.

Conclusion

The hosting model for a password manager is an architectural decision with long-term compliance implications. GDPR, NIS2, DORA, and the US CLOUD Act create a regulatory environment where the wrong choice generates documented liability.

The model spectrum gives European organizations real options. The right choice depends on sector classification, regulatory exposure, internal IT capacity, and an honest TCO calculation that includes compliance overhead.

For organizations that need maximum control, on-premises deployment eliminates third-party exposure entirely. For those that need managed infrastructure without foreign jurisdiction risk, sovereign EU cloud is a credible path. Hybrid architectures work when neither extreme fits the operational reality.

Passwork is a European password manager that covers the full spectrum: on-premises deployment for organizations that require complete infrastructure control, and EU-hosted cloud for teams that want managed hosting without sacrificing data sovereignty. Both options are built on the same zero-knowledge encryption architecture and include the audit, access control, and compliance reporting features that regulated European businesses need.

Ready to take te frist step? Start your free Passwork trial to get complete control, automated credential management, and enterprise-grade data protection.

Frequently asked questions

Is a cloud password manager GDPR compliant?

A cloud password manager can be GDPR compliant if the vendor processes personal data under a valid legal basis, provides a Data Processing Agreement (DPA) meeting Article 28 requirements, and applies appropriate safeguards for any data transfers outside the EU. Compliance depends on the vendor's architecture and contractual terms — not cloud hosting alone.

Does GDPR require data to be stored in Europe?

GDPR does not mandate EU data storage. It requires that personal data transferred outside the EU is protected to an equivalent standard — through adequacy decisions, Standard Contractual Clauses, or other mechanisms under Articles 44–49. Storing data in the EU simplifies compliance but is not a legal requirement under the regulation itself.

What is the US CLOUD Act and why does it matter for EU businesses?

The US CLOUD Act (2018) allows US federal authorities to compel US-incorporated companies to produce data stored anywhere in the world, including EU data centers. For European organizations using US-based password manager vendors, this means credential data could be subject to US government access regardless of where the servers are physically located.

When does NIS2 apply to password manager hosting decisions?

NIS2 applies when the organization is classified as an "essential" or "important" entity — covering energy, transport, banking, healthcare, digital infrastructure, and public administration, among others. For these organizations, a password manager is part of the ICT supply chain, and Article 21 requires documented security measures for all supply chain components.

What does DORA require for cloud-hosted password managers in financial services?

DORA requires financial entities to maintain a register of ICT third-party service providers, conduct risk assessments of critical providers, and ensure contracts include rights to audit, data access, and exit. A cloud-hosted password manager used by a financial institution is an ICT third-party service under DORA — the institution must document and manage this dependency formally.

What is the difference between a sovereign EU cloud and a regular EU data center?

A regular EU data center operated by a US company is still subject to US jurisdiction through the CLOUD Act. A sovereign cloud provider is incorporated and operated entirely within the EU, with no legal obligation to comply with foreign government data requests. The distinction matters for GDPR transfer risk assessments and NIS2 supply chain documentation.

How does Passwork support compliance for European organizations?

Passwork is a European company under EU law, ISO 27001 certified, with on-premises and EU-hosted cloud deployment options. On-premises deployment eliminates third-party access entirely. The cloud version is hosted in Germany under EU jurisdiction with zero-knowledge encryption. Both options include audit logs, compliance reports, and role-based access control to support GDPR, NIS2, and DORA requirements.

Data breach prevention for business: Beyond basic antivirus

82% of attacks in 2026 are malware-free — antivirus won’t catch them. This guide covers a 7-layer defense strategy built for credential theft, lateral movement, and supply chain compromise.

Passwork BlogAlex Muntyan

Password Manager Deployment Models: Cloud, Self-Hosted & Hybrid

Choosing where to run your password manager matters as much as choosing which one. This guide breaks down cloud, self-hosted, and hybrid deployment — with a compliance matrix for GDPR, HIPAA, and NIS2, and a clear look at the trade-offs each model carries.

Passwork BlogAlex Muntyan

Spring 2026 EU cybersecurity update: What changed

Spring 2026 brought the EU’s most significant institutional breach, its first cyber sanctions of the year, and four major cybersecurity regulations enforcing simultaneously. NIS2, DORA, CRA, and CSA2 now set hard deadlines — and real penalties. Here’s what changed, who’s affected, and what to do.

Passwork BlogAlex Muntyan

Einleitung

Ihr Sicherheitsteam hat gerade die Antivirenlizenz verlängert. Patches sind aktuell. Die Firewall-Regeln wurden seit zwei Jahren nicht geändert — weil nichts schiefgegangen ist. Warum landen Organisationen mit all diesen Maßnahmen trotzdem auf der Liste der Datenschutzverletzungen?

Weil die Tools, die 2010 funktionierten, für eine Bedrohung entwickelt wurden, die nicht mehr existiert.

Moderne Angreifer liefern keine Malware an Ihre Endpunkte. Sie beschaffen sich gültige Anmeldedaten — durch Phishing, eine geleakte Datenbank oder einen kompromittierten Anbieter — und authentifizieren sich wie jeder andere Benutzer. Von dort aus bewegen sie sich leise, eskalieren Berechtigungen und exfiltrieren Daten über Wochen. Bis jemand es bemerkt, ist der Schaden bereits angerichtet.

Antivirensoftware hat keine Signatur für einen legitimen Login.

Dieser Artikel erläutert, wie eine mehrschichtige, identitätszentrierte Verteidigung tatsächlich aussieht — und welche Kontrollen priorisiert werden sollten, wenn Sie 2026 einen Security-Stack aufbauen oder auditieren.

Wichtigste Erkenntnisse

• Signaturbasierte Antivirensoftware übersieht die Mehrheit moderner Angriffe. CrowdStrikes Global Threat Report 2026 stellte fest, dass 82 % der Erkennungen im Jahr 2025 malwarefrei waren — Angreifer nutzten Anmeldedatenmissbrauch und dateilose Techniken, die keinen binären Fußabdruck zum Scannen hinterlassen.
• Gestohlene Anmeldedaten sind der führende Erstzugriffsvektor. Verizons DBIR 2025 ergab, dass kompromittierte Anmeldedaten bei etwa 30 % der Datenschutzverletzungen beteiligt waren. Angreifer authentifizieren sich als legitime Benutzer und umgehen dabei jede Kontrolle, die zur Erkennung von Malware entwickelt wurde.
• Enterprise-Passwortmanagement und PAM sind grundlegende Kontrollen. Zentralisierte Anmeldedatenspeicherung, Durchsetzung des Least-Privilege-Prinzips und Just-In-Time-Zugriffsbereitstellung adressieren direkt die Angriffsvektoren, die für die meisten Datenschutzverletzungen verantwortlich sind.
• Zero-Trust-Architektur ist die strukturelle Antwort auf laterale Bewegung. Kontinuierliche Verifizierung von Identität, Gerätezustand und Verhaltenskontext — kombiniert mit Mikrosegmentierung — begrenzt einen Angreifer selbst nach der ersten Kompromittierung.
• Compliance-Frameworks definieren das Minimum, nicht den angemessenen Standard. DSGVO, NIS2, SOC 2 und ISO 27001 schreiben alle Zugriffskontrollen und Incident-Response-Verfahren vor, aber keines definiert die genaue Implementierung. Die Lücke zwischen dem Abhaken und effektiver Sicherheit ist dort, wo die meisten Datenschutzverletzungen auftreten.

Was ist eine Datenschutzverletzung? (Die moderne Definition)

Eine Datenschutzverletzung ist jeder bestätigte Vorfall, bei dem sensible, geschützte oder vertrauliche Informationen ohne Autorisierung zugegriffen, offengelegt oder exfiltriert werden. Dies umfasst personenbezogene Daten (PII), Finanzdaten, geistiges Eigentum und geschützte Gesundheitsinformationen (PHI).

Der Unterschied zwischen einem Sicherheitsvorfall und einer bestätigten Datenschutzverletzung ist operativ wichtig.

• Sicherheitsvorfall — jedes Ereignis, das Vertraulichkeit, Integrität oder Verfügbarkeit bedroht. Bewusst breit gefasst; die meisten eskalieren nicht weiter.
• Bestätigte Datenschutzverletzung — unberechtigter Zugriff auf Daten ist als Tatsache festgestellt. Dies löst obligatorische Meldepflichten gemäß DSGVO Artikel 33, NIS2 Artikel 23 und ähnlichen Rahmenwerken aus.

Diese Grenze bestimmt Ihre rechtliche Exposition, Ihre Meldefrist und ob Aufsichtsbehörden Sie als Opfer oder als fahrlässige Partei behandeln.

Warum Antivirensoftware nicht mehr ausreicht, um Datenschutzverletzungen zu verhindern

Antivirensoftware scannt Dateien und Prozesse gegen eine Datenbank bekannter Malware-Signaturen und blockiert dann alles, was übereinstimmt. Es war das richtige Tool für eine Bedrohungslandschaft, die auf ausführbaren Dateien und bekannten Virenstämmen basierte.

Ältere Antivirensoftware basiert auf signaturbasierter Erkennung: Wenn die Bedrohung nicht in der Datenbank ist, wird sie nicht erkannt. Dieses Modell versagt bei Bedrohungen, die überhaupt nicht wie Malware aussehen.

Laut CrowdStrikes Global Threat Report 2026 waren 82 % der Erkennungen im Jahr 2025 malwarefrei — das bedeutet, Angreifer nutzten Anmeldedatenmissbrauch, Living-off-the-Land-Techniken und dateilose Ausführung, die keinen binären Fußabdruck zum Scannen hinterlassen. Googles Threat Intelligence Team verfolgte 90 Zero-Day-Schwachstellen, die 2025 in freier Wildbahn ausgenutzt wurden, wobei jede ein Angriffsfenster darstellt, für das noch keine Signatur existiert.

Die 7-Schichten-Strategie zur Verhinderung von Datenschutzverletzungen für 2026

Ein mehrschichtiges Verteidigungsmodell adressiert die gesamte Angriffskette — vom Erstzugriff über laterale Bewegung bis zur Exfiltration. Jede Schicht unten ist nach Auswirkung und Implementierungspriorität geordnet.

1. Phishing-resistente MFA und Enterprise-Passwortmanagement durchsetzen

Microsoft-Forschung bestätigt, dass MFA mehr als 99,2 % der Account-Kompromittierungsangriffe blockiert. Diese einzelne Kontrolle eliminiert die überwiegende Mehrheit der anmeldedatenbasierten Eindringversuche — aber nur, wenn sie korrekt implementiert wird.

SMS-basierte MFA ist anfällig für SIM-Swapping und Prompt-Bombing. Phishing-resistente Alternativen — FIDO2-Hardware-Keys, Passkeys und zertifikatsbasierte Authentifizierung — entfernen den menschlichen Abfangvektor vollständig. Diese sollten der Standard für jeden Account mit Zugriff auf sensible Systeme sein.

MFA allein löst jedoch nicht das zugrundeliegende Problem der Anmeldedatenhygiene. Mitarbeiter verwenden Passwörter auf persönlichen und Unternehmenskonten wieder, teilen Anmeldedaten über Chat und speichern sie in Tabellen. Verizons DBIR 2025 stellte fest, dass gestohlene Anmeldedaten bei etwa 30 % der Datenschutzverletzungen der Erstzugriffsvektor waren. Ein Enterprise-Passwortmanager schließt diese Lücke durch Zentralisierung der Anmeldedatenspeicherung, Durchsetzung starker Passwortrichtlinien und Eliminierung von Ad-hoc-Freigaben.

Passwork ist speziell für diesen Anwendungsfall entwickelt. Es wird vollständig auf Ihrer eigenen Infrastruktur bereitgestellt — keine Anmeldedaten verlassen jemals Ihre Umgebung. Alle Geheimnisse werden mit AES-256 sowohl auf Server- als auch auf Client-Seite unter einer Zero-Knowledge-Architektur verschlüsselt.

Die Integration mit Active Directory und LDAP automatisiert die Benutzerbereitstellung und -deprovisionierung, sodass der Zugriff in dem Moment entzogen wird, in dem ein Mitarbeiter das Unternehmen verlässt. Jeder Anmeldedatenzugriff, jede Änderung und jedes Freigabeereignis wird in einem manipulationssicheren Audit-Trail protokolliert — was direkt die Anforderungen an Insider-Bedrohungen und Compliance-Audits adressiert. Passwork ist ISO/IEC 27001-zertifiziert, was bestätigt, dass das Informationssicherheitsmanagement internationalen Standards entspricht.

Die Verwaltung gemeinsam genutzter Anmeldedaten über Teams hinweg ohne einen strukturierten Tresor ist einer der schnellsten Wege zu einer Datenschutzverletzung. Erfahren Sie, wie Passwork Enterprise-Passwortmanagement handhabt → passwork.pro

2. Privileged Access Management (PAM) implementieren

Privileged Access Management (PAM) ist ein Sicherheitsframework, das den Zugriff auf Konten mit erhöhten Systemberechtigungen kontrolliert, überwacht und auditiert — die Anmeldedaten, die einem Angreifer bei Kompromittierung administrative Kontrolle über Ihre Infrastruktur geben.

PAM regelt den Zugriff auf hochwertige Ziele: Domain-Controller, Cloud-Konsolen, Datenbankserver und Netzwerkinfrastruktur. Über die Zugriffskontrolle hinaus erzwingt es zusätzliche Sicherheit auf Sitzungsebene: Aufzeichnung von Aktivitäten, Auditierung von Befehlen und Bereitstellung von Zugriff durch Just-In-Time (JIT)-Mechanismen. JIT bedeutet, dass Admin-Rechte für ein definiertes Zeitfenster gewährt und automatisch entzogen werden — was dauerhafte Berechtigungen eliminiert, die Angreifer nach der ersten Kompromittierung ausnutzen können.

Das Prinzip der minimalen Rechtevergabe ist die operative Grundlage: Jeder Benutzer, jedes Dienstkonto und jede Anwendung erhält nur den minimalen Zugriff, der für ihre Funktion erforderlich ist, und nicht mehr.

Die Durchsetzung minimaler Rechte beginnt auf der Anmeldedatenebene. Das rollenbasierte Zugriffsmodell von Passwork ermöglicht Administratoren die Zuweisung granularer Berechtigungen pro Benutzer oder Gruppe — mit genauer Kontrolle darüber, wer bestimmte Anmeldedaten ansehen, kopieren oder ändern kann.

Jede Rolle ist vollständig konfigurierbar: Anstatt zwischen vollem Administratorzugriff und keinem zu wählen, können Berechtigungen auf spezifische Funktionen beschränkt werden — Benutzerverwaltung, LDAP-Konfiguration, Audit-Logs oder Tresoreinstellungen — unabhängig voneinander.

3. Eine Zero-Trust-Architektur einführen

Zero Trust ist ein Sicherheitsmodell, das auf der Annahme basiert, dass keinem Benutzer, Gerät oder Netzwerksegment standardmäßig vertraut werden sollte — unabhängig davon, ob die Anfrage innerhalb oder außerhalb des Unternehmensperimeters erfolgt. Der Zugriff wird erst nach kontinuierlicher Verifizierung von Identität, Gerätezustand und Verhaltenskontext gewährt.

Das Modell basiert auf drei Kernprinzipien:

• Explizit verifizieren — jede Zugriffsanfrage wird basierend auf allen verfügbaren Datenpunkten authentifiziert und autorisiert: Identität, Gerätezustand, Standort und Verhaltenskontext.
• Least-Privilege-Zugriff verwenden — Benutzer und Systeme erhalten nur die Berechtigungen, die für ihre aktuelle Aufgabe erforderlich sind, was den Explosionsradius einer Kompromittierung begrenzt.
• Von einer Kompromittierung ausgehen — die Architektur ist so konzipiert, als ob ein Angreifer bereits drin ist. Mikrosegmentierung, verschlüsselte Traffic-Inspektion und kontinuierliche Überwachung begrenzen laterale Bewegung, bevor sie eskaliert.

Diese Architektur adressiert direkt laterale Bewegung. Wenn ein Angreifer einen Endpunkt oder ein Konto kompromittiert, verhindern Zero-Trust-Mikrosegmentierung und kontinuierliche Authentifizierungsprüfungen, dass sie auf benachbarte Systeme übergreifen.

Zero Trust ist eine Designphilosophie, die durch Identitätsanbieter, Netzwerksegmentierung und Richtliniendurchsetzungspunkte implementiert wird — kein einzelnes Produkt oder keine einzelne Anbieterlösung. NIST SP 800-207 bietet das maßgebliche Framework für die Implementierung.

4. Auf Endpoint Detection and Response (EDR) upgraden

Endpoint Detection and Response (EDR) ist eine Sicherheitstechnologie, die Endpunktaktivitäten kontinuierlich überwacht — Prozesse, Netzwerkverbindungen, Dateisystemänderungen und Benutzerverhalten — und automatisierte Reaktionen auslöst, wenn anomale Muster erkannt werden.

EDR ersetzt das statische Signaturmodell durch Verhaltensüberwachung. Anstatt zu fragen „stimmt diese Datei mit einer bekannten Bedrohung überein?", fragt EDR „verhält sich dieser Prozess wie ein Angriff?"

Diese Unterscheidung erkennt dateilose Malware, Credential-Dumping-Tools und Ransomware-Staging-Aktivitäten, bevor die Ausführung abgeschlossen ist. EDR-Lösungen führen ein kontinuierliches Telemetrie-Protokoll der Endpunktaktivitäten und ermöglichen eine forensische Rekonstruktion nach einem Vorfall — entscheidend sowohl für die Eindämmung als auch für die Compliance-Berichterstattung.

Ransomware war bei 44 % der Datenschutzverletzungen im Jahr 2025 vorhanden, gegenüber 32 % im Vorjahr. EDR mit automatisierten Reaktionsfähigkeiten — Isolierung eines Endpunkts in dem Moment, in dem anomales Verhalten erkannt wird — ist heute eine Basiskontrolle für jede Organisation, die sensible Daten verarbeitet.

EDR-Lösungen in der Praxis

• CrowdStrike Falcon — cloudnativer Agent mit Echtzeit-Verhaltenserkennung, automatisierter Eindämmung und Threat-Intelligence-Integration
• SentinelOne Singularity Endpoint — autonome Reaktion ohne Cloud-Abhängigkeit; enthält Rollback-Fähigkeit für Ransomware-betroffene Dateien
• Microsoft Defender for Endpoint — tief in das Microsoft-Ökosystem integriert; deckt Windows, macOS, Linux, iOS und Android ab
• Palo Alto Networks Cortex XDR — erweitert Endpunkt-Telemetrie auf Netzwerk- und Cloud-Daten; einheitliche Erkennung über die gesamte Angriffsoberfläche
• Trend Micro Vision One — kombiniert EDR mit XDR über E-Mail, Endpunkte, Server und Cloud-Workloads
• Sophos Intercept X — enthält Anti-Exploit- und Anti-Ransomware-Module neben Verhaltenserkennung; als Managed Service verfügbar
• Cisco Secure Endpoint — integriert sich in Ciscos breiteren Security-Stack; stark bei Threat Hunting und retrospektiver Analyse

5. Data Loss Prevention (DLP) und Verschlüsselung einsetzen

Data Loss Prevention (DLP) ist eine Reihe von Technologien und Richtlinien, die die Bewegung sensibler Daten über Endpunkte, Netzwerke und Cloud-Umgebungen erkennen, überwachen und einschränken — um unbefugten Zugriff, Übertragung oder Exfiltration zu verhindern, bevor eine Datenschutzverletzung bestätigt wird.

DLP-Tools überwachen und kontrollieren die Bewegung sensibler Daten: PII, Finanzdaten, Quellcode und regulierte Informationen. Sie setzen Richtlinien durch, die unbefugte Uploads in Cloud-Speicher blockieren, Exfiltration per E-Mail verhindern und anomale Massen-Datenübertragungen kennzeichnen.

DLP-Tools in der Praxis

Der Markt bietet Lösungen in drei Bereitstellungsmodellen — Endpunkt, Netzwerk und Cloud — die oft in einer einzigen Plattform kombiniert werden:

Endpunkt-DLP

• Microsoft Purview DLP — native Integration mit Microsoft 365 und Windows-Endpunkten; deckt E-Mail, Teams, SharePoint und lokale Dateiaktivitäten ab
• Forcepoint DLP — verhaltensbasierte Erkennung mit tiefgehender Inhaltsprüfung über Endpunkte und Webkanäle
• Digital Guardian (Fortra) — granularer Endpunkt-Agent mit forensischem Logging; starke Abdeckung für geistiges Eigentum

Netzwerk- und Cloud-DLP

• Netskope DLP — cloudnativ; konzipiert für SaaS, IaaS und Web-Traffic-Inspektion
• Symantec DLP (Broadcom) — deckt Netzwerk, Endpunkt und Cloud-Speicher mit Datenerkennung und -klassifizierung ab
• Palo Alto Networks Enterprise DLP — in den NGFW- und Prisma-SASE-Stack integriert; kein separater Agent erforderlich
• Varonis — kartiert sensible Daten über Dateifreigaben, Cloud-Speicher und E-Mail; enthält Anomalieerkennung für Benutzerverhalten

Verschlüsselung ist die ergänzende Kontrolle. Daten, die im Ruhezustand und bei der Übertragung verschlüsselt sind, bleiben selbst bei Exfiltration unlesbar. Vollständige Festplattenverschlüsselung auf Endpunkten, TLS 1.3 für Daten bei der Übertragung und offline gespeicherte verschlüsselte Backups bilden die Baseline. Für regulierte Branchen ist Verschlüsselung nicht optional — NIS2 Artikel 21 und DSGVO Artikel 32 verweisen beide darauf als angemessene technische Schutzmaßnahme.

6. Drittanbieter- und Lieferkettenrisiken managen

Drittanbieterrisiko ist die Exposition, die durch Anbieter, Auftragnehmer und Software-Abhängigkeiten in Ihre Umgebung gelangt — Entitäten außerhalb Ihrer direkten Kontrolle, die dennoch Zugriff auf Ihre Systeme, Daten oder Codebasis haben. Die Beteiligung von Drittanbietern an Datenschutzverletzungen verdoppelte sich laut Verizons DBIR 2025 im Jahresvergleich.

Anbieterrisikomanagement erfordert mehr als jährliche Fragebögen. Wirksame Kontrollen umfassen:

• Beschränkung des Drittanbieterzugriffs auf nur die Systeme, die sie benötigen
• MFA-Anforderung für alle externen Konten
• Überwachung der Drittanbieter-Sitzungsaktivitäten
• Einbeziehung von Sicherheitsanforderungen in vertragliche Vereinbarungen

Lieferkettenangriffe sind ein eigenständiger und schwerer zu erkennender Vektor: Bösartiger Code wird in Software eingeschleust, bevor sie Sie erreicht — durch eine kompromittierte Build-Pipeline, ein manipuliertes Paket-Repository oder ein gekapertes Anbieter-Update. Wenn die Nutzlast ankommt, sieht sie bereits legitim aus. Zwei Vorfälle von Anfang 2026 illustrieren das Ausmaß der Exposition:

• Trivy (März 2026). Der Schwachstellenscanner von Aqua Security wurde über seine Docker-Images kompromittiert und lieferte eine Information-Stealer-Nutzlast an Teams, die jeden Grund hatten, dem Tool zu vertrauen.
• Axios (März 2026). Angreifer, die mit dem nordkoreanischen Bedrohungsakteur UNC1069 in Verbindung stehen, betteten einen Remote-Access-Trojaner in das weit verbreitete Axios-npm-Paket ein und verteilten ihn still über die Abhängigkeitskette.

In beiden Fällen kam bösartiger Code über einen vertrauenswürdigen Kanal — bevor eine interne Kontrolle die Chance hatte, ihn abzufangen. Effektive Verteidigung erfordert Software-Composition-Analyse und Integritätsverifizierung für alle Drittanbieterkomponenten.

7. Kontinuierliche Security-Awareness-Schulungen durchführen

Der menschliche Faktor war bei 60 % der Datenschutzverletzungen im Jahr 2025 beteiligt. Jährliche Compliance-Schulungen ändern das Verhalten nicht — sie produzieren abgehakte Checkboxen, kein Sicherheitsbewusstsein.

Effektive Programme führen kontinuierliche, simulierte Phishing-Kampagnen durch, die auf aktuelle Angriffstechniken kalibriert sind. Wenn ein Mitarbeiter auf einen simulierten Phishing-Link klickt, erhält er sofort kontextbezogenes Feedback — nicht eine vierteljährliche Erinnerung.

Gamifizierte Plattformen, die individuelle Verbesserungen im Laufe der Zeit verfolgen, erzielen messbare Reduzierungen der Klickraten. Sicherheitskultur wird durch Wiederholung und Relevanz aufgebaut, nicht durch jährliche Vorträge.

Wie Compliance-Frameworks die Verhinderung von Datenschutzverletzungen beeinflussen

Compliance-Frameworks (DSGVO, NIS2, DORA, SOC 2) schreiben spezifische technische Kontrollen vor: Zugriffsprotokollierung, Verschlüsselung, Incident-Response-Verfahren und Anbietermanagement. Die Erfüllung dieser Anforderungen etabliert eine Sicherheits-Baseline.

Compliance definiert den minimal akzeptablen Standard — nicht den angemessenen. Ein SOC 2 Type II-Audit bestätigt, dass Kontrollen während des Auditzeitraums existierten und effektiv funktionierten; es macht keine Aussage darüber, was am Tag nach dem Verlassen des Auditors passiert, oder ob diese Kontrollen gegen Ihre tatsächliche Bedrohungslandschaft ausreichen. Organisationen, die Compliance mit Sicherheitsstrategie gleichsetzen, erfahren den Unterschied in der Regel im ungünstigsten Moment.

Nutzen Sie Frameworks als strukturierten Ausgangspunkt. Bauen Sie basierend auf Ihrem tatsächlichen Bedrohungsmodell darüber hinaus.

Was jedes Framework tatsächlich erfordert

Die Tabelle zeigt ein Muster: Jedes Framework deckt Zugriffskontrolle und Incident Response in irgendeiner Form ab, aber keines schreibt genau vor, wie. Diese Implementierungslücke ist dort, wo die meisten Datenschutzverletzungen auftreten — nicht weil das Framework falsch war, sondern weil die Organisation bei der Checkbox aufgehört hat.

Passworks Audit-Logs, rollenbasierte Zugriffskontrollen und ISO 27001-Zertifizierung unterstützen direkt die Compliance mit DSGVO-, NIS2- und SOC 2-Anforderungen. Entdecken Sie Passworks Compliance-relevante Funktionen → passwork.pro

Entwicklung eines Incident-Response-Plans (von einer Kompromittierung ausgehen)

Prävention ist niemals absolut. Der IBM Cost of a Data Breach Report 2025 stellte fest, dass die durchschnittliche Zeit zur Identifizierung und Eindämmung einer Datenschutzverletzung 241 Tage beträgt. Organisationen mit einem getesteten Incident-Response-Plan dämmen Datenschutzverletzungen deutlich schneller ein — und schnellere Eindämmung reduziert direkt die Kosten.

Ein wirksamer IR-Plan definiert: wer einen Vorfall deklariert, wie der Eskalationspfad aussieht, wie Systeme isoliert werden, wann Aufsichtsbehörden und betroffene Parteien benachrichtigt werden müssen und wie Beweise für die forensische Analyse gesichert werden. DSGVO Artikel 33 erfordert die Meldung an Aufsichtsbehörden innerhalb von 72 Stunden nach Kenntnis einer Datenschutzverletzung — eine Frist, die ohne einen vordefinierten Prozess nicht einzuhalten ist.

Testen Sie den Plan. Eine Tabletop-Übung, die einmal im Jahr durchgeführt wird, offenbart Lücken, die keine Dokumentation aufdecken kann.

Fazit

Die Bedrohungslandschaft hat sich entscheidend von malwarebasierten Angriffen hin zu Identitätsausnutzung, dateilosen Techniken und Lieferkettenkompromittierungen verlagert. Ein signaturbasiertes Antivirenprodukt adressiert keinen dieser Vektoren effektiv.

Das oben beschriebene 7-Schichten-Modell — verankert durch phishing-resistente MFA, Enterprise-Passwortmanagement und Zero-Trust-Architektur — spiegelt wider, wie moderne Angriffe tatsächlich funktionieren und wo Kontrollen die größte Wirkung haben. Jede Schicht adressiert eine spezifische Phase der Angriffskette. Zusammen schaffen sie eine Defense-in-Depth, die ältere Perimetersicherheit nicht replizieren kann.

Auditieren Sie Ihren aktuellen Stack gegen diese sieben Schichten. Identifizieren Sie, welche Kontrollen fehlen, welche teilweise implementiert sind und welche falsch konfiguriert sind. Die Lücken, die Sie finden, sind die Lücken, die ein Angreifer zuerst finden wird.

Passwork ist als Self-hosted- und Cloud-Lösung verfügbar mit AES-256-Verschlüsselung, AD/LDAP-Integration, vollständiger Audit-Protokollierung und ISO 27001-Zertifizierung. Testen Sie Passwork in Ihrer Umgebung → passwork.pro

Häufig gestellte Fragen

Worauf sollten Unternehmen bei einem Enterprise-Passwortmanager achten?

Priorisieren Sie On-Premise- oder Self-hosted-Bereitstellung, damit Anmeldedaten innerhalb Ihrer Infrastruktur bleiben. Wesentliche Fähigkeiten umfassen Zero-Knowledge-AES-256-Verschlüsselung, Active Directory- und LDAP-Integration für automatisierte Benutzerbereitstellung, manipulationssichere Audit-Logs und ISO 27001-Zertifizierung. Passwork erfüllt alle diese Anforderungen und wird vollständig in Ihrer eigenen Umgebung bereitgestellt.

Was ist die häufigste Ursache für eine Datenschutzverletzung im Jahr 2026?

Gestohlene Anmeldedaten bleiben der führende Erstzugriffsvektor. Verizons DBIR 2025 ergab, dass kompromittierte Anmeldedaten bei etwa 30 % der Datenschutzverletzungen beteiligt waren. Angreifer beschaffen sie durch Phishing, geleakte Datenbanken oder kompromittierte Anbieter — und authentifizieren sich dann als legitime Benutzer, wobei sie signaturbasierte Abwehrmechanismen vollständig umgehen.

Warum reicht Antivirensoftware nicht mehr aus, um Datenschutzverletzungen zu verhindern?

Antivirensoftware basiert auf signaturbasierter Erkennung: Sie identifiziert Bedrohungen durch Abgleich von Dateien mit einer Datenbank bekannter Malware. Laut CrowdStrikes Global Threat Report 2026 waren 82 % der Erkennungen im Jahr 2025 malwarefrei — das bedeutet, Angreifer nutzten Anmeldedatenmissbrauch und dateilose Techniken, die keinen binären Fußabdruck zum Scannen hinterlassen.

Was ist der Unterschied zwischen einem Sicherheitsvorfall und einer Datenschutzverletzung?

Ein Sicherheitsvorfall ist jedes Ereignis, das Vertraulichkeit, Integrität oder Verfügbarkeit bedroht — die meisten eskalieren nicht weiter. Eine bestätigte Datenschutzverletzung bedeutet, dass unberechtigter Zugriff auf Daten als Tatsache festgestellt ist. Diese Unterscheidung bestimmt Ihre rechtliche Exposition: DSGVO Artikel 33 und NIS2 Artikel 23 erfordern die Meldung an Aufsichtsbehörden innerhalb von 72 Stunden nach Bestätigung einer Datenschutzverletzung.

Was bedeutet Zero-Trust-Architektur in der Praxis tatsächlich?

Zero Trust bedeutet, dass keinem Benutzer, Gerät oder Netzwerksegment standardmäßig vertraut wird — unabhängig davon, ob die Anfrage innerhalb oder außerhalb des Unternehmensperimeters erfolgt. Jede Zugriffsanfrage wird gegen Identität, Gerätezustand und Verhaltenskontext verifiziert. Mikrosegmentierung begrenzt laterale Bewegung, wenn ein Konto oder Endpunkt kompromittiert wird. NIST SP 800-207 bietet das maßgebliche Implementierungsframework.

Was ist ein Lieferkettenangriff und wie unterscheidet er sich von einer Standard-Anbieterverletzung?

Ein Lieferkettenangriff schleust bösartigen Code in Software ein, bevor sie den Endbenutzer erreicht — durch eine kompromittierte Build-Pipeline, ein manipuliertes Paket-Repository oder ein gekapertes Update. Anders als bei einer Anbieterverletzung, bei der der Angreiferzugriff die Bedrohung ist, macht ein Lieferkettenangriff die Software selbst zur Waffe. Wenn die Nutzlast ankommt, erscheint sie bereits legitim.

Was ist die durchschnittliche Zeit zur Erkennung und Eindämmung einer Datenschutzverletzung?

Laut IBMs Cost of a Data Breach Report 2025 beträgt die durchschnittliche Zeit zur Identifizierung und Eindämmung einer Datenschutzverletzung 241 Tage. Organisationen mit einem getesteten Incident-Response-Plan dämmen Datenschutzverletzungen deutlich schneller ein. Dieser Geschwindigkeitsunterschied reduziert direkt die finanzielle und regulatorische Exposition — einschließlich des 72-Stunden-Meldefensters, das gemäß DSGVO Artikel 33 erforderlich ist.

Was sollte ein Enterprise-Passwortmanager enthalten, um Compliance zu unterstützen?

On-Premise-Bereitstellung, damit Anmeldedaten innerhalb Ihrer Infrastruktur bleiben, AES-256-Zero-Knowledge-Verschlüsselung, Active Directory- und LDAP-Integration für automatisierte Bereitstellung und Deprovisionierung, manipulationssichere Audit-Logs und ISO 27001-Zertifizierung. Diese Fähigkeiten adressieren direkt die Zugriffskontroll- und Audit-Anforderungen gemäß DSGVO, NIS2 und SOC 2. Passwork erfüllt alle diese Anforderungen und wird vollständig in Ihrer eigenen Umgebung bereitgestellt.

Wie reduziert Privileged Access Management das Risiko von Datenschutzverletzungen?

PAM kontrolliert den Zugriff auf hochwertige Konten — Domain-Controller, Cloud-Konsolen, Datenbankserver — und erzwingt Just-In-Time-Bereitstellung: Admin-Rechte werden für ein definiertes Zeitfenster gewährt und automatisch entzogen. Dies eliminiert dauerhafte Berechtigungen, die Angreifer nach der ersten Kompromittierung ausnutzen. Das Prinzip der minimalen Rechtevergabe begrenzt den Explosionsradius eines einzelnen kompromittierten Kontos.

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

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

Passwork BlogAlex Muntyan

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

Lücken bei Anmeldedaten sind der führende NIS2-Audit-Fehlergrund im Jahr 2026. Dieser Leitfaden behandelt die Passwortanforderungen gemäß Artikel 21, die Ausrichtung an NIST SP 800-63B, AD-Härtungsschritte und die Auditnachweise, nach denen Aufsichtsbehörden zuerst fragen.

Passwork BlogAlex Muntyan

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

Die Wahl, wo Sie Ihren Passwortmanager betreiben, ist genauso wichtig wie die Wahl, welchen Sie verwenden. Dieser Leitfaden erläutert Cloud-, Self-hosted- und Hybrid-Bereitstellung — mit einer Compliance-Matrix für DSGVO, HIPAA und NIS2 und einem klaren Blick auf die Kompromisse, die jedes Modell mit sich bringt.

Passwork BlogAlex Muntyan

Introducción

Su equipo de seguridad acaba de renovar la licencia del antivirus. Los parches están actualizados. Las reglas del firewall no han cambiado en dos años — porque nada salió mal. Entonces, ¿por qué las organizaciones que tienen todo esto implementado siguen apareciendo en la lista de divulgación de filtraciones?

Porque las herramientas que funcionaban en 2010 fueron diseñadas para una amenaza que ya no existe.

Los atacantes modernos no entregan malware a sus endpoints. Adquieren un conjunto válido de credenciales — mediante phishing, una base de datos filtrada o un proveedor comprometido — y se autentican como cualquier otro usuario. A partir de ahí, se mueven silenciosamente, escalan privilegios y exfiltran datos durante semanas. Para cuando alguien lo nota, el daño ya está hecho.

El antivirus no tiene una firma para un inicio de sesión legítimo.

Este artículo desglosa cómo es realmente una defensa en capas centrada en la identidad — y qué controles priorizar si está construyendo o auditando una pila de seguridad en 2026.

Puntos clave

• El antivirus basado en firmas no detecta la mayoría de los ataques modernos. El Informe Global de Amenazas 2026 de CrowdStrike encontró que el 82% de las detecciones en 2025 no contenían malware — los atacantes utilizaron abuso de credenciales y técnicas sin archivos que no dejan huella binaria para escanear.
• Las credenciales robadas son el principal vector de acceso inicial. El DBIR 2025 de Verizon encontró que las credenciales comprometidas estuvieron involucradas en aproximadamente el 30% de las filtraciones. Los atacantes se autentican como usuarios legítimos, evadiendo todos los controles diseñados para detectar malware.
• La gestión de contraseñas empresariales y PAM son controles fundamentales. El almacenamiento centralizado de credenciales, la aplicación del principio de mínimo privilegio y el aprovisionamiento de acceso Just-In-Time abordan directamente los vectores de ataque responsables de la mayoría de las filtraciones.
• La arquitectura Zero Trust es la respuesta estructural al movimiento lateral. La verificación continua de identidad, estado del dispositivo y contexto de comportamiento — combinada con microsegmentación — contiene a un atacante incluso después del compromiso inicial.
• Los marcos de cumplimiento definen el mínimo, no el estándar apropiado. GDPR, NIS2, SOC 2 e ISO 27001 exigen controles de acceso y respuesta a incidentes, pero ninguno prescribe la implementación exacta. La brecha entre la casilla de verificación y la seguridad efectiva es donde ocurren la mayoría de las filtraciones.

¿Qué es una filtración de datos? (La definición moderna)

Una filtración de datos es cualquier incidente confirmado en el que información sensible, protegida o confidencial es accedida, divulgada o exfiltrada sin autorización. Esto incluye información de identificación personal (PII), registros financieros, propiedad intelectual e información de salud protegida (PHI).

La distinción entre un incidente de seguridad y una filtración de datos confirmada es importante operativamente.

• Incidente de seguridad — cualquier evento que amenaza la confidencialidad, integridad o disponibilidad. Amplio por diseño, la mayoría nunca escala más allá.
• Filtración de datos confirmada — el acceso no autorizado a datos se establece como un hecho. Esto activa obligaciones de notificación obligatorias bajo el Artículo 33 del GDPR, el Artículo 23 de NIS2 y marcos similares.

Ese límite determina su exposición legal, su plazo de notificación y si los reguladores lo tratan como víctima o como parte negligente.

Por qué el antivirus ya no es suficiente para la prevención de filtraciones de datos

El software antivirus escanea archivos y procesos contra una base de datos de firmas de malware conocidas, y luego bloquea cualquier cosa que coincida. Era la herramienta correcta para un panorama de amenazas construido alrededor de archivos ejecutables y cepas de virus conocidas.

El antivirus tradicional depende de la detección basada en firmas: si la amenaza no está en la base de datos, no se detecta. Ese modelo falla contra amenazas que no parecen malware en absoluto.

Según el Informe Global de Amenazas 2026 de CrowdStrike, el 82% de las detecciones en 2025 no contenían malware — lo que significa que los atacantes utilizaron abuso de credenciales, técnicas living-off-the-land y ejecución sin archivos que no dejan huella binaria para que el antivirus la escanee. El Equipo de Inteligencia de Amenazas de Google rastreó 90 vulnerabilidades de día cero explotadas en la naturaleza en 2025, cada una representando una ventana de ataque donde aún no existe ninguna firma.

La estrategia de prevención de filtraciones de datos de 7 capas para 2026

Un modelo de defensa en capas aborda toda la cadena de ataque — desde el acceso inicial hasta el movimiento lateral y la exfiltración. Cada capa a continuación está ordenada por impacto y prioridad de implementación.

1. Implemente MFA resistente al phishing y gestión de contraseñas empresariales

La investigación de Microsoft confirma que MFA bloquea más del 99,2% de los ataques de compromiso de cuentas. Ese único control elimina la gran mayoría de las intrusiones basadas en credenciales, pero solo si se implementa correctamente.

El MFA basado en SMS es vulnerable al SIM-swapping y al bombardeo de solicitudes. Las alternativas resistentes al phishing — llaves de hardware FIDO2, passkeys y autenticación basada en certificados — eliminan por completo el vector de interceptación humana. Estas deberían ser el estándar para cualquier cuenta con acceso a sistemas sensibles.

Sin embargo, el MFA por sí solo no resuelve el problema subyacente de higiene de credenciales. Los empleados reutilizan contraseñas entre cuentas personales y corporativas, comparten credenciales por chat y las almacenan en hojas de cálculo. El DBIR 2025 de Verizon encontró que las credenciales robadas fueron el vector de acceso inicial en aproximadamente el 30% de las filtraciones. Un gestor de contraseñas empresarial cierra esa brecha centralizando el almacenamiento de credenciales, aplicando políticas de contraseñas fuertes y eliminando el uso compartido ad-hoc.

Passwork está diseñado específicamente para este caso de uso. Se implementa completamente en su propia infraestructura — ningún dato de credenciales sale de su entorno. Todos los secretos están cifrados con AES-256 tanto en el lado del servidor como del cliente bajo una arquitectura de conocimiento cero.

La integración con Active Directory y LDAP automatiza el aprovisionamiento y desaprovisionamiento de usuarios, de modo que el acceso se revoca en el momento en que un empleado se va. Cada acceso, modificación y evento de uso compartido de credenciales se registra en un registro de auditoría a prueba de manipulaciones — abordando directamente los requisitos de amenazas internas y auditorías de cumplimiento. Passwork posee la certificación ISO/IEC 27001, lo que confirma que su gestión de seguridad de la información cumple con los estándares internacionales.

Gestionar credenciales compartidas entre equipos sin una bóveda estructurada es uno de los caminos más rápidos hacia una filtración. Vea cómo Passwork gestiona las contraseñas empresariales → passwork.pro

2. Implemente la gestión de acceso privilegiado (PAM)

La gestión de acceso privilegiado (PAM) es un marco de seguridad que controla, monitorea y audita el acceso a cuentas con permisos elevados del sistema — las credenciales que, si se comprometen, dan a un atacante control administrativo sobre su infraestructura.

PAM gobierna el acceso a objetivos de alto valor: controladores de dominio, consolas en la nube, servidores de bases de datos e infraestructura de red. Más allá del control de acceso, aplica seguridad adicional a nivel de sesión: grabación de actividad, auditoría de comandos y aprovisionamiento de acceso mediante mecanismos Just-In-Time (JIT). JIT significa que los derechos de administrador se otorgan por una ventana definida y se revocan automáticamente — eliminando los privilegios permanentes que los atacantes pueden explotar después del compromiso inicial.

El principio de mínimo privilegio es la base operativa: cada usuario, cuenta de servicio y aplicación recibe el acceso mínimo requerido para su función, y nada más.

La aplicación del mínimo privilegio comienza a nivel de credenciales. El modelo de acceso basado en roles de Passwork permite a los administradores asignar permisos granulares por usuario o grupo — controlando exactamente quién puede ver, copiar o modificar credenciales específicas.

Cada rol es completamente configurable: en lugar de elegir entre acceso de administrador completo y ninguno, puede delimitar permisos a funciones específicas — gestión de usuarios, configuración de LDAP, registros de auditoría o configuraciones de bóvedas — independientemente unas de otras.

3. Adopte una arquitectura Zero Trust

Zero Trust es un modelo de seguridad basado en la suposición de que ningún usuario, dispositivo o segmento de red debe ser confiable por defecto — independientemente de si la solicitud se origina dentro o fuera del perímetro corporativo. El acceso se otorga solo después de la verificación continua de identidad, estado del dispositivo y contexto de comportamiento.

El modelo se basa en tres principios fundamentales:

• Verificar explícitamente — cada solicitud de acceso se autentica y autoriza basándose en todos los puntos de datos disponibles: identidad, estado del dispositivo, ubicación y contexto de comportamiento.
• Usar acceso de mínimo privilegio — los usuarios y sistemas reciben solo los permisos requeridos para su tarea actual, limitando el radio de impacto de cualquier compromiso.
• Asumir la brecha — la arquitectura está diseñada como si un atacante ya estuviera dentro. La microsegmentación, la inspección de tráfico cifrado y el monitoreo continuo contienen el movimiento lateral antes de que escale.

Esta arquitectura aborda directamente el movimiento lateral. Cuando un atacante compromete un endpoint o cuenta, la microsegmentación de Zero Trust y las verificaciones continuas de autenticación evitan que pivoten hacia sistemas adyacentes.

Zero Trust es una filosofía de diseño implementada a través de proveedores de identidad, segmentación de red y puntos de aplicación de políticas — no es un producto único o solución de un proveedor. NIST SP 800-207 proporciona el marco autorizado para la implementación.

4. Actualice a detección y respuesta de endpoints (EDR)

La detección y respuesta de endpoints (EDR) es una tecnología de seguridad que monitorea continuamente la actividad de los endpoints — procesos, conexiones de red, cambios en el sistema de archivos y comportamiento del usuario — y activa respuestas automatizadas cuando se detectan patrones anómalos.

EDR reemplaza el modelo de firma estática con monitoreo de comportamiento. En lugar de preguntar «¿coincide este archivo con una amenaza conocida?», EDR pregunta «¿se comporta este proceso como un ataque?»

Esa distinción detecta malware sin archivos, herramientas de volcado de credenciales y actividad de preparación de ransomware antes de que se complete la ejecución. Las soluciones EDR mantienen un registro continuo de telemetría de la actividad de los endpoints, permitiendo la reconstrucción forense después de un incidente — crítico tanto para la contención como para los informes de cumplimiento.

El ransomware estuvo presente en el 44% de las filtraciones en 2025, frente al 32% del año anterior. EDR con capacidades de respuesta automatizada — aislando un endpoint en el momento en que se detecta un comportamiento anómalo — es ahora un control básico para cualquier organización que maneje datos sensibles.

Soluciones EDR en la práctica

• CrowdStrike Falcon — agente nativo en la nube con detección de comportamiento en tiempo real, contención automatizada e integración de inteligencia de amenazas
• SentinelOne Singularity Endpoint — respuesta autónoma sin dependencia de la nube; incluye capacidad de reversión para archivos afectados por ransomware
• Microsoft Defender for Endpoint — profundamente integrado con el ecosistema de Microsoft; cubre Windows, macOS, Linux, iOS y Android
• Palo Alto Networks Cortex XDR — extiende la telemetría de endpoints a datos de red y nube; detección unificada en toda la superficie de ataque
• Trend Micro Vision One — combina EDR con XDR a través de correo electrónico, endpoints, servidores y cargas de trabajo en la nube
• Sophos Intercept X — incluye módulos anti-exploit y anti-ransomware junto con detección de comportamiento; disponible como servicio gestionado
• Cisco Secure Endpoint — se integra con la pila de seguridad más amplia de Cisco; fuerte en búsqueda de amenazas y análisis retrospectivo

5. Implemente prevención de pérdida de datos (DLP) y cifrado

La prevención de pérdida de datos (DLP) es un conjunto de tecnologías y políticas que detectan, monitorean y restringen el movimiento de datos sensibles a través de endpoints, redes y entornos en la nube — previniendo el acceso, transferencia o exfiltración no autorizados antes de que se confirme una filtración.

Las herramientas DLP monitorean y controlan el movimiento de datos sensibles: PII, registros financieros, código fuente e información regulada. Aplican políticas que bloquean cargas no autorizadas al almacenamiento en la nube, previenen la exfiltración por correo electrónico y señalan transferencias masivas de datos anómalas.

Herramientas DLP en la práctica

El mercado ofrece soluciones en tres modelos de implementación — endpoint, red y nube — a menudo combinados dentro de una sola plataforma:

DLP de endpoint

• Microsoft Purview DLP — integración nativa con Microsoft 365 y endpoints de Windows; cubre correo electrónico, Teams, SharePoint y actividad de archivos locales
• Forcepoint DLP — detección basada en comportamiento con inspección profunda de contenido a través de endpoints y canales web
• Digital Guardian (Fortra) — agente de endpoint granular con registro a nivel forense; fuerte cobertura para propiedad intelectual

DLP de red y nube

• Netskope DLP — nativo en la nube; diseñado para inspección de tráfico SaaS, IaaS y web
• Symantec DLP (Broadcom) — cubre red, endpoint y almacenamiento en la nube con descubrimiento y clasificación de datos
• Palo Alto Networks Enterprise DLP — integrado en el NGFW y la pila Prisma SASE; no requiere agente separado
• Varonis — mapea datos sensibles a través de recursos compartidos de archivos, almacenamiento en la nube y correo electrónico; incluye detección de anomalías en el comportamiento del usuario

El cifrado es el control complementario. Los datos cifrados en reposo y en tránsito permanecen ilegibles incluso si se exfiltran. El cifrado de disco completo en endpoints, TLS 1.3 para datos en tránsito y copias de seguridad cifradas almacenadas fuera de línea forman la línea base. Para industrias reguladas, el cifrado no es opcional — el Artículo 21 de NIS2 y el Artículo 32 del GDPR lo mencionan como una medida técnica apropiada.

6. Gestione el riesgo de terceros y cadena de suministro

El riesgo de terceros es la exposición que entra en su entorno a través de proveedores, contratistas y dependencias de software — entidades fuera de su control directo que, sin embargo, tienen acceso a sus sistemas, datos o código fuente. La participación de terceros en las filtraciones se duplicó año tras año, según el DBIR 2025 de Verizon.

La gestión de riesgo de proveedores requiere más que cuestionarios anuales. Los controles efectivos incluyen:

• Limitar el acceso de terceros solo a los sistemas que necesitan
• Requerir MFA para todas las cuentas externas
• Monitorear la actividad de sesión de terceros
• Incluir requisitos de seguridad en los acuerdos contractuales

Los ataques a la cadena de suministro son un vector distinto y más difícil de detectar: el código malicioso se inyecta en el software antes de que llegue a usted — a través de un pipeline de compilación comprometido, un repositorio de paquetes manipulado o una actualización de proveedor secuestrada. Para cuando la carga útil llega, ya parece legítima. Dos incidentes de principios de 2026 ilustran el rango de exposición:

• Trivy (marzo 2026). El escáner de vulnerabilidades de Aqua Security fue comprometido a través de sus imágenes Docker, entregando una carga útil de robo de información a equipos que tenían toda la razón para confiar en la herramienta.
• Axios (marzo 2026). Atacantes vinculados al actor de amenazas norcoreano UNC1069 incrustaron un troyano de acceso remoto dentro del paquete npm Axios, ampliamente utilizado, y lo distribuyeron silenciosamente a través de la cadena de dependencias.

En ambos casos, el código malicioso llegó a través de un canal de confianza — antes de que cualquier control interno tuviera la oportunidad de interceptarlo. Una defensa efectiva requiere análisis de composición de software y verificación de integridad para todos los componentes de terceros.

7. Realice formación continua de concienciación en seguridad

El elemento humano estuvo involucrado en el 60% de las filtraciones en 2025. La formación de cumplimiento anual no cambia el comportamiento — produce finalización de casillas de verificación, no concienciación en seguridad.

Los programas efectivos ejecutan campañas de phishing simuladas continuas, calibradas según las técnicas de ataque actuales. Cuando un empleado hace clic en un enlace de phishing simulado, recibe retroalimentación inmediata y contextual — no un recordatorio trimestral.

Las plataformas gamificadas que rastrean la mejora individual a lo largo del tiempo producen reducciones medibles en las tasas de clics. La cultura de seguridad se construye a través de la repetición y la relevancia, no de conferencias anuales.

Cómo los marcos de cumplimiento impactan en la prevención de filtraciones de datos

Los marcos de cumplimiento (GDPR, NIS2, DORA, SOC 2) exigen controles técnicos específicos: registro de acceso, cifrado, procedimientos de respuesta a incidentes y gestión de proveedores. Cumplir con estos requisitos establece una línea base de seguridad.

El cumplimiento define el estándar mínimo aceptable — no el apropiado. Una auditoría SOC 2 Tipo II confirma que los controles existieron y operaron efectivamente durante el período de auditoría; no hace ninguna declaración sobre lo que sucede el día después de que el auditor se va, o si esos controles son suficientes contra su panorama de amenazas real. Las organizaciones que sustituyen el cumplimiento por la estrategia de seguridad tienden a descubrir la diferencia en el peor momento posible.

Use los marcos como un punto de partida estructurado. Construya más allá de ellos basándose en su modelo de amenazas real.

Qué requiere realmente cada marco

La tabla revela un patrón: cada marco cubre el control de acceso y la respuesta a incidentes de alguna forma, pero ninguno prescribe exactamente cómo. Esa brecha de implementación es donde ocurren la mayoría de las filtraciones — no porque el marco estuviera equivocado, sino porque la organización se detuvo en la casilla de verificación.

Los registros de auditoría, controles de acceso basados en roles y certificación ISO 27001 de Passwork apoyan directamente el cumplimiento de los requisitos de GDPR, NIS2 y SOC 2. Explore las características de Passwork relevantes para el cumplimiento → passwork.pro

Desarrollo de un plan de respuesta a incidentes (asumir la brecha)

La prevención nunca es absoluta. El Informe de Costo de una Filtración de Datos 2025 de IBM encontró que el tiempo medio para identificar y contener una filtración es de 241 días. Las organizaciones con un plan de respuesta a incidentes probado contienen las filtraciones significativamente más rápido — y una contención más rápida reduce directamente el costo.

Un plan de RI efectivo define: quién declara un incidente, cómo es la ruta de escalación, cómo se aíslan los sistemas, cuándo se debe notificar a los reguladores y las partes afectadas, y cómo se preserva la evidencia para el análisis forense. El Artículo 33 del GDPR requiere notificación a las autoridades de supervisión dentro de las 72 horas posteriores a tener conocimiento de una filtración — un plazo que es imposible de cumplir sin un proceso predefinido.

Pruebe el plan. Un ejercicio de simulación ejecutado una vez al año revela brechas que ninguna cantidad de documentación puede exponer.

Conclusión

El panorama de amenazas se ha alejado decisivamente de los ataques basados en malware hacia la explotación de identidad, técnicas sin archivos y compromiso de la cadena de suministro. Un producto antivirus basado en firmas no aborda ninguno de estos vectores de manera efectiva.

El modelo de 7 capas anterior — anclado por MFA resistente al phishing, gestión de contraseñas empresariales y arquitectura Zero Trust — refleja cómo funcionan realmente los ataques modernos y dónde los controles tienen el mayor impacto. Cada capa aborda una etapa específica de la cadena de ataque. Juntas, crean una defensa en profundidad que la seguridad perimetral tradicional no puede replicar.

Audite su pila actual contra estas siete capas. Identifique qué controles están ausentes, cuáles están parcialmente implementados y cuáles están mal configurados. Las brechas que encuentre son las brechas que un atacante encontrará primero.

Passwork está disponible como solución autoalojada y en la nube con cifrado AES-256, integración AD/LDAP, registro de auditoría completo y certificación ISO 27001. Pruebe Passwork en su entorno → passwork.pro

Preguntas frecuentes

¿Qué deben buscar las empresas en un gestor de contraseñas empresarial?

Priorice la implementación local o autoalojada para que los datos de credenciales permanezcan dentro de su infraestructura. Las capacidades esenciales incluyen cifrado AES-256 de conocimiento cero, integración con Active Directory y LDAP para aprovisionamiento automatizado de usuarios, registros de auditoría a prueba de manipulaciones y certificación ISO 27001. Passwork cumple con todos estos requisitos y se implementa completamente dentro de su propio entorno.

¿Cuál es la causa más común de una filtración de datos en 2026?

Las credenciales robadas siguen siendo el principal vector de acceso inicial. El DBIR 2025 de Verizon encontró que las credenciales comprometidas estuvieron involucradas en aproximadamente el 30% de las filtraciones. Los atacantes las obtienen mediante phishing, bases de datos filtradas o proveedores comprometidos — luego se autentican como usuarios legítimos, evadiendo todas las defensas basadas en firmas.

¿Por qué el antivirus ya no es suficiente para la prevención de filtraciones de datos?

El antivirus depende de la detección basada en firmas: identifica amenazas comparando archivos con una base de datos de malware conocido. Según el Informe Global de Amenazas 2026 de CrowdStrike, el 82% de las detecciones en 2025 no contenían malware — lo que significa que los atacantes utilizaron abuso de credenciales y técnicas sin archivos que no dejan huella binaria para que el antivirus la escanee.

¿Cuál es la diferencia entre un incidente de seguridad y una filtración de datos?

Un incidente de seguridad es cualquier evento que amenaza la confidencialidad, integridad o disponibilidad — la mayoría nunca escala más allá. Una filtración de datos confirmada significa que el acceso no autorizado a datos se establece como un hecho. Esa distinción determina su exposición legal: el Artículo 33 del GDPR y el Artículo 23 de NIS2 requieren notificación a las autoridades de supervisión dentro de las 72 horas posteriores a confirmar una filtración.

¿Qué significa realmente la arquitectura Zero Trust en la práctica?

Zero Trust significa que ningún usuario, dispositivo o segmento de red es confiable por defecto — independientemente de si la solicitud se origina dentro o fuera del perímetro corporativo. Cada solicitud de acceso se verifica contra identidad, estado del dispositivo y contexto de comportamiento. La microsegmentación limita el movimiento lateral si una cuenta o endpoint se ve comprometido. NIST SP 800-207 proporciona el marco de implementación autorizado.

¿Qué es un ataque a la cadena de suministro y cómo difiere de una filtración de proveedor estándar?

Un ataque a la cadena de suministro inyecta código malicioso en el software antes de que llegue al usuario final — a través de un pipeline de compilación comprometido, un repositorio de paquetes manipulado o una actualización secuestrada. A diferencia de una filtración de proveedor, donde el acceso del atacante es la amenaza, un ataque a la cadena de suministro convierte el software en un arma. Para cuando la carga útil llega, ya parece legítima.

¿Cuál es el tiempo medio para detectar y contener una filtración de datos?

Según el Informe de Costo de una Filtración de Datos 2025 de IBM, el tiempo medio para identificar y contener una filtración es de 241 días. Las organizaciones con un plan de respuesta a incidentes probado contienen las filtraciones significativamente más rápido. Esa diferencia de velocidad reduce directamente la exposición financiera y regulatoria — incluyendo la ventana de notificación de 72 horas requerida bajo el Artículo 33 del GDPR.

¿Qué debe incluir un gestor de contraseñas empresarial para apoyar el cumplimiento?

Implementación local para que los datos de credenciales permanezcan dentro de su infraestructura, cifrado AES-256 de conocimiento cero, integración con Active Directory y LDAP para aprovisionamiento y desaprovisionamiento automatizados, registros de auditoría a prueba de manipulaciones y certificación ISO 27001. Estas capacidades abordan directamente los requisitos de control de acceso y auditoría bajo GDPR, NIS2 y SOC 2. Passwork cumple con todos estos requisitos y se implementa completamente dentro de su propio entorno.

¿Cómo reduce la gestión de acceso privilegiado el riesgo de filtración?

PAM controla el acceso a cuentas de alto valor — controladores de dominio, consolas en la nube, servidores de bases de datos — y aplica aprovisionamiento Just-In-Time: los derechos de administrador se otorgan por una ventana definida y se revocan automáticamente. Esto elimina los privilegios permanentes que los atacantes explotan después del compromiso inicial. El principio de mínimo privilegio limita el radio de impacto de cualquier cuenta comprometida individual.

Actualización de ciberseguridad de la UE primavera 2026: Qué cambió

La primavera de 2026 trajo la filtración institucional más significativa de la UE, sus primeras sanciones cibernéticas del año y cuatro regulaciones importantes de ciberseguridad aplicándose simultáneamente. NIS2, DORA, CRA y CSA2 ahora establecen plazos firmes — y sanciones reales. Esto es lo que cambió, quién se ve afectado y qué hacer.

Passwork BlogAlex Muntyan

Requisitos de contraseñas de NIS2: Qué deben hacer las empresas europeas en 2026

Las brechas de credenciales son el principal punto de fallo en las auditorías NIS2 en 2026. Esta guía cubre los requisitos de contraseñas del Artículo 21, la alineación con NIST SP 800-63B, los pasos de fortalecimiento de AD y la evidencia de auditoría que los reguladores solicitan primero.

Passwork BlogAlex Muntyan

Modelos de implementación de gestores de contraseñas: Nube, autoalojado e híbrido

Elegir dónde ejecutar su gestor de contraseñas importa tanto como elegir cuál. Esta guía desglosa la implementación en la nube, autoalojada e híbrida — con una matriz de cumplimiento para GDPR, HIPAA y NIS2, y una visión clara de las compensaciones que conlleva cada modelo.

Passwork BlogAlex Muntyan

Introduction

Your security team just renewed the antivirus license. Patches are current. The firewall rules haven't changed in two years — because nothing went wrong. So why do organizations with all of this in place still end up on the breach disclosure list?

Because the tools that worked in 2010 were built for a threat that no longer exists.

Modern attackers don't deliver malware to your endpoints. They acquire a valid set of credentials — through phishing, a leaked database, or a compromised vendor — and authenticate like any other user. From there, they move quietly, escalate privileges, and exfiltrate data over weeks. By the time anyone notices, the damage is done.

Antivirus has no signature for a legitimate login.

This article breaks down what a layered, identity-centric defense actually looks like — and which controls to prioritize if you're building or auditing a security stack in 2026.

Key takeaways

• Signature-based antivirus misses the majority of modern attacks. CrowdStrike's 2026 Global Threat Report found that 82% of detections in 2025 were malware-free — attackers used credential abuse and fileless techniques that leave no binary footprint to scan.
• Stolen credentials are the leading initial access vector. Verizon's 2025 DBIR found compromised credentials involved in roughly 30% of breaches. Attackers authenticate as legitimate users bypassing every control built to detect malware.
• Enterprise password management and PAM are foundational controls. Centralized credential storage, least-privilege enforcement, and Just-In-Time access provisioning directly address the attack vectors responsible for most breaches.
• Zero Trust architecture is the structural answer to lateral movement. Continuous verification of identity, device health, and behavioral context — combined with micro-segmentation — contains an attacker even after initial compromise.
• Compliance frameworks define the minimum, not the appropriate standard. GDPR, NIS2, SOC 2, and ISO 27001 all mandate access controls and incident response but none prescribes exact implementation. The gap between the checkbox and effective security is where most breaches occur.

What is a data breach? (The modern definition)

A data breach is any confirmed incident in which sensitive, protected, or confidential information is accessed, disclosed, or exfiltrated without authorization. This includes personally identifiable information (PII), financial records, intellectual property, and protected health information (PHI).

The distinction between a security incident and a confirmed data breach matters operationally.

• Security incident — any event that threatens confidentiality, integrity, or availability. Broad by design, most never escalate further.
• Confirmed data breach — unauthorized access to data is established as fact. This triggers mandatory notification obligations under GDPR Article 33, NIS2 Article 23, and similar frameworks.

That boundary determines your legal exposure, your notification timeline, and whether regulators treat you as a victim or a negligent party.

Why antivirus is no longer enough for data breach prevention

Antivirus software scans files and processes against a database of known malware signatures, then blocks anything that matches. It was the right tool for a threat landscape built around executable files and known virus strains.

Legacy antivirus relies on signature-based detection: if the threat isn't in the database, it isn't detected. That model fails against threats that don't look like malware at all.

According to CrowdStrike's 2026 Global Threat Report, 82% of detections in 2025 were malware-free — meaning attackers used credential abuse, living-off-the-land techniques, and fileless execution that leave no binary footprint for antivirus to scan. Google's Threat Intelligence Team tracked 90 zero-day vulnerabilities exploited in the wild in 2025, each representing an attack window where no signature yet exists.

The 7-layer data breach prevention strategy for 2026

A layered defense model addresses the full attack chain — from initial access through lateral movement to exfiltration. Each layer below is ordered by impact and implementation priority.

1. Enforce phishing-resistant MFA and enterprise password management

Microsoft research confirms that MFA blocks more than 99.2% of account compromise attacks. That single control eliminates the vast majority of credential-based intrusions but only if it's implemented correctly.

SMS-based MFA is vulnerable to SIM-swapping and prompt bombing. Phishing-resistant alternatives — FIDO2 hardware keys, passkeys, and certificate-based authentication — remove the human-intercept vector entirely. These should be the standard for any account with access to sensitive systems.

MFA alone, however, doesn't solve the underlying credential hygiene problem. Employees reuse passwords across personal and corporate accounts, share credentials over chat, and store them in spreadsheets. Verizon's 2025 DBIR found that stolen credentials were the initial access vector in roughly 30% of breaches. An enterprise password manager closes that gap by centralizing credential storage, enforcing strong password policies, and eliminating ad-hoc sharing.

Passwork is purpose-built for this use case. It deploys entirely on your own infrastructure — no credential data ever leaves your environment. All secrets are encrypted with AES-256 on both the server and client sides under a zero-knowledge architecture.

Integration with Active Directory and LDAP automates user provisioning and deprovisioning, so access is revoked the moment an employee leaves. Every credential access, modification, and sharing event is logged in a tamper-evident audit trail — directly addressing insider threat and compliance audit requirements. Passwork holds ISO/IEC 27001 certification, confirming its information security management meets international standards.

Managing shared credentials across teams without a structured vault is one of the fastest paths to a breach. See how Passwork handles enterprise password management → passwork.pro

2. Implement Privileged Access Management (PAM)

Privileged Access Management (PAM) is a security framework that controls, monitors, and audits access to accounts with elevated system permissions — the credentials that, if compromised, give an attacker administrative control over your infrastructure.

PAM governs access to high-value targets: domain controllers, cloud consoles, database servers, and network infrastructure. Beyond access control, it enforces additional session-level security: recording activity, auditing commands, and provisioning access through Just-In-Time (JIT) mechanisms. JIT means admin rights are granted for a defined window and automatically revoked — eliminating standing privileges that attackers can exploit after initial compromise.

The principle of least privilege is the operational foundation: every user, service account, and application receives the minimum access required for its function, and nothing more.

Enforcing least privilege starts at the credential level. Passwork's role-based access model lets administrators assign granular permissions per user or group — controlling exactly who can view, copy, or modify specific credentials.

Each role is fully configurable: rather than choosing between full administrator access and none, you can scope permissions to specific functions — user management, LDAP configuration, audit logs, or vault settings — independently of each other.

3. Adopt a Zero Trust architecture

Zero Trust is a security model built on the assumption that no user, device, or network segment should be trusted by default — regardless of whether the request originates inside or outside the corporate perimeter. Access is granted only after continuous verification of identity, device health, and behavioral context.

The model rests on three core principles:

• Verify explicitly — every access request is authenticated and authorized based on all available data points: identity, device health, location, and behavioral context.
• Use least privilege access — users and systems receive only the permissions required for their current task, limiting the blast radius of any compromise.
• Assume breach — the architecture is designed as if an attacker is already inside. Micro-segmentation, encrypted traffic inspection, and continuous monitoring contain lateral movement before it escalates.

This architecture directly addresses lateral movement. When an attacker compromises one endpoint or account, Zero Trust micro-segmentation and continuous authentication checks prevent them from pivoting to adjacent systems.

Zero Trust is a design philosophy implemented through identity providers, network segmentation, and policy enforcement points — not a single product or vendor solution. NIST SP 800-207 provides the authoritative framework for implementation.

4. Upgrade to Endpoint Detection and Response (EDR)

Endpoint Detection and Response (EDR) is a security technology that continuously monitors endpoint activity — processes, network connections, file system changes, and user behavior — and triggers automated responses when anomalous patterns are detected.

EDR replaces the static signature model with behavioral monitoring. Instead of asking "does this file match a known threat?", EDR asks "does this process behave like an attack?"

That distinction catches fileless malware, credential dumping tools, and ransomware staging activity before execution completes. EDR solutions maintain a continuous telemetry record of endpoint activity, enabling forensic reconstruction after an incident — critical for both containment and compliance reporting.

Ransomware was present in 44% of breaches in 2025, up from 32% the prior year. EDR with automated response capabilities — isolating an endpoint the moment anomalous behavior is detected — is now a baseline control for any organization handling sensitive data.

EDR solutions in practice

• CrowdStrike Falcon — cloud-native agent with real-time behavioral detection, automated containment, and threat intelligence integration
• SentinelOne Singularity Endpoint — autonomous response without cloud dependency; includes rollback capability for ransomware-affected files
• Microsoft Defender for Endpoint — deeply integrated with the Microsoft ecosystem; covers Windows, macOS, Linux, iOS, and Android
• Palo Alto Networks Cortex XDR — extends endpoint telemetry to network and cloud data; unified detection across the full attack surface
• Trend Micro Vision One — combines EDR with XDR across email, endpoints, servers, and cloud workloads
• Sophos Intercept X — includes anti-exploit and anti-ransomware modules alongside behavioral detection; available as a managed service
• Cisco Secure Endpoint — integrates with Cisco's broader security stack; strong on threat hunting and retrospective analysis

5. Deploy Data Loss Prevention (DLP) and encryption

Data Loss Prevention (DLP) is a set of technologies and policies that detect, monitor, and restrict the movement of sensitive data across endpoints, networks, and cloud environments — preventing unauthorized access, transfer, or exfiltration before a breach is confirmed.

DLP tools monitor and control the movement of sensitive data: PII, financial records, source code, and regulated information. They enforce policies that block unauthorized uploads to cloud storage, prevent exfiltration via email, and flag anomalous bulk data transfers.

DLP tools in practice

The market offers solutions across three deployment models — endpoint, network, and cloud — often combined within a single platform:

Endpoint DLP

• Microsoft Purview DLP — native integration with Microsoft 365 and Windows endpoints; covers email, Teams, SharePoint, and local file activity
• Forcepoint DLP — behavior-based detection with deep content inspection across endpoints and web channels
• Digital Guardian (Fortra) — granular endpoint agent with forensic-level logging; strong coverage for intellectual property

Network and cloud DLP

• Netskope DLP — cloud-native; designed for SaaS, IaaS, and web traffic inspection
• Symantec DLP (Broadcom) — covers network, endpoint, and cloud storage with data discovery and classification
• Palo Alto Networks Enterprise DLP — integrated into the NGFW and Prisma SASE stack; no separate agent required
• Varonis — maps sensitive data across file shares, cloud storage, and email; includes anomaly detection on user behavior

Encryption is the complementary control. Data encrypted at rest and in transit remains unreadable even if exfiltrated. Full-disk encryption on endpoints, TLS 1.3 for data in transit, and encrypted backups stored offline form the baseline. For regulated industries, encryption is not optional — NIS2 Article 21 and GDPR Article 32 both reference it as an appropriate technical safeguard.

6. Manage third-party and supply chain risk

Third-party risk is the exposure that enters your environment through vendors, contractors, and software dependencies — entities outside your direct control that nonetheless have access to your systems, data, or codebase. Third-party involvement in breaches doubled year-over-year, according to Verizon's 2025 DBIR.

Vendor risk management requires more than annual questionnaires. Effective controls include:

• Limiting third-party access to only the systems they need
• Requiring MFA for all external accounts
• Monitoring third-party session activity
• Including security requirements in contractual agreements

Supply chain attacks are a distinct and harder-to-detect vector: malicious code is injected into software before it reaches you — through a compromised build pipeline, a tampered package repository, or a hijacked vendor update. By the time the payload arrives, it already looks legitimate. Two incidents from early 2026 illustrate the range of exposure:

• Trivy (March 2026). Aqua Security's vulnerability scanner was compromised through its Docker images, delivering an information-stealing payload to teams that had every reason to trust the tool.
• Axios (March 2026). Attackers linked to North Korean threat actor UNC1069 embedded a remote access trojan inside the widely used Axios npm package and distributed it silently through the dependency chain.

In both cases, malicious code arrived through a trusted channel — before any internal control had a chance to intercept it. Effective defense requires software composition analysis and integrity verification for all third-party components.

7. Conduct continuous security awareness training

The human element was involved in 60% of breaches in 2025. Annual compliance training doesn't change behavior — it produces checkbox completion, not security awareness.

Effective programs run continuous, simulated phishing campaigns calibrated to current attack techniques. When an employee clicks a simulated phishing link, they receive immediate, contextual feedback — not a quarterly reminder.

Gamified platforms that track individual improvement over time produce measurable reductions in click rates. Security culture is built through repetition and relevance, not annual lectures.

How compliance frameworks impact data breach prevention

Compliance frameworks (GDPR, NIS2, DORA, SOC 2) mandate specific technical controls: access logging, encryption, incident response procedures, and vendor management. Meeting these requirements establishes a security baseline.

Compliance defines the minimum acceptable standard — not the appropriate one. A SOC 2 Type II audit confirms that controls existed and operated effectively during the audit period; it makes no statement about what happens the day after the auditor leaves, or whether those controls are sufficient against your actual threat landscape. Organizations that substitute compliance for security strategy tend to find out the difference at the worst possible moment.

Use frameworks as a structured starting point. Build beyond them based on your actual threat model.

What each framework actually requires

The table reveals a pattern: every framework covers access control and incident response in some form, but none prescribes exactly how. That implementation gap is where most breaches occur — not because the framework was wrong, but because the organization stopped at the checkbox.

Passwork's audit logs, role-based access controls, and ISO 27001 certification directly support compliance with GDPR, NIS2, and SOC 2 requirements. Explore Passwork's compliance-relevant features → passwork.pro

Developing an incident response plan (assume breach)

Prevention is never absolute. The IBM Cost of a Data Breach Report 2025 found that the mean time to identify and contain a breach is 241 days. Organizations with a tested incident response plan contain breaches significantly faster — and faster containment directly reduces cost.

An effective IR plan defines: who declares an incident, what the escalation path looks like, how systems are isolated, when regulators and affected parties must be notified, and how evidence is preserved for forensic analysis. GDPR Article 33 requires notification to supervisory authorities within 72 hours of becoming aware of a breach — a timeline that's impossible to meet without a pre-defined process.

Test the plan. A tabletop exercise run once a year reveals gaps that no amount of documentation can expose.

Conclusion

The threat landscape has moved decisively away from malware-based attacks toward identity exploitation, fileless techniques, and supply chain compromise. A signature-based antivirus product addresses none of these vectors effectively.

The 7-layer model above — anchored by phishing-resistant MFA, enterprise password management, and Zero Trust architecture — reflects how modern attacks actually work and where controls have the highest impact. Each layer addresses a specific stage of the attack chain. Together, they create defense in depth that legacy perimeter security cannot replicate.

Audit your current stack against these seven layers. Identify which controls are absent, which are partially implemented, and which are misconfigured. The gaps you find are the gaps an attacker will find first.

Passwork is available as a self-hosted and cloud solution with AES-256 encryption, AD/LDAP integration, full audit logging, and ISO 27001 certification. Try Passwork in your environment → passwork.pro

Frequently asked questions

What should businesses look for in an enterprise password manager?

Prioritize on-premise or self-hosted deployment so credential data stays within your infrastructure. Essential capabilities include zero-knowledge AES-256 encryption, Active Directory and LDAP integration for automated user provisioning, tamper-evident audit logs, and ISO 27001 certification. Passwork meets all of these requirements and deploys entirely within your own environment.

What is the most common cause of a data breach in 2026?

Stolen credentials remain the leading initial access vector. Verizon's 2025 DBIR found that compromised credentials were involved in roughly 30% of breaches. Attackers obtain them through phishing, leaked databases, or compromised vendors — then authenticate as legitimate users, bypassing signature-based defenses entirely.

Why is antivirus no longer sufficient for data breach prevention?

Antivirus relies on signature-based detection: it identifies threats by matching files against a database of known malware. According to CrowdStrike's 2026 Global Threat Report, 82% of detections in 2025 were malware-free — meaning attackers used credential abuse and fileless techniques that leave no binary footprint for antivirus to scan.

What is the difference between a security incident and a data breach?

A security incident is any event that threatens confidentiality, integrity, or availability — most never escalate further. A confirmed data breach means unauthorized access to data is established as fact. That distinction determines your legal exposure: GDPR Article 33 and NIS2 Article 23 require notification to supervisory authorities within 72 hours of confirming a breach.

What does Zero Trust architecture actually mean in practice?

Zero Trust means no user, device, or network segment is trusted by default — regardless of whether the request originates inside or outside the corporate perimeter. Every access request is verified against identity, device health, and behavioral context. Micro-segmentation limits lateral movement if one account or endpoint is compromised. NIST SP 800-207 provides the authoritative implementation framework.

What is a supply chain attack and how does it differ from a standard vendor breach?

A supply chain attack injects malicious code into software before it reaches the end user — through a compromised build pipeline, a tampered package repository, or a hijacked update. Unlike a vendor breach, where attacker access is the threat, a supply chain attack weaponizes the software itself. By the time the payload arrives, it already appears legitimate.

What is the mean time to detect and contain a data breach?

According to IBM's Cost of a Data Breach Report 2025, the mean time to identify and contain a breach is 241 days. Organizations with a tested incident response plan contain breaches significantly faster. That speed difference directly reduces financial and regulatory exposure — including the 72-hour notification window required under GDPR Article 33.

What should an enterprise password manager include to support compliance?

On-premise deployment so credential data stays within your infrastructure, AES-256 zero-knowledge encryption, Active Directory and LDAP integration for automated provisioning and deprovisioning, tamper-evident audit logs, and ISO 27001 certification. These capabilities directly address access control and audit requirements under GDPR, NIS2, and SOC 2. Passwork meets all of these requirements and deploys entirely within your own environment.

How does Privileged Access Management reduce breach risk?

PAM controls access to high-value accounts — domain controllers, cloud consoles, database servers — and enforces Just-In-Time provisioning: admin rights are granted for a defined window and automatically revoked. This eliminates standing privileges that attackers exploit after initial compromise. The principle of least privilege limits the blast radius of any single compromised account.

Spring 2026 EU cybersecurity update: What changed

Spring 2026 brought the EU’s most significant institutional breach, its first cyber sanctions of the year, and four major cybersecurity regulations enforcing simultaneously. NIS2, DORA, CRA, and CSA2 now set hard deadlines — and real penalties. Here’s what changed, who’s affected, and what to do.

Passwork BlogAlex Muntyan

NIS2 password requirements: What European companies must do in 2026

Credential gaps are the leading NIS2 audit failure point in 2026. This guide covers Article 21 password requirements, NIST SP 800-63B alignment, AD hardening steps, and the audit evidence regulators ask for first.

Passwork BlogAlex Muntyan

Password Manager Deployment Models: Cloud, Self-Hosted & Hybrid

Choosing where to run your password manager matters as much as choosing which one. This guide breaks down cloud, self-hosted, and hybrid deployment — with a compliance matrix for GDPR, HIPAA, and NIS2, and a clear look at the trade-offs each model carries.

Passwork BlogAlex Muntyan

Einleitung

Am 24. März 2026 verschafften sich Angreifer Zugang zu den AWS-Cloud-Konten der Europäischen Kommission und entwendeten über 350 GB an Daten, bevor sie blockiert wurden.

Die Erpressergruppe ShinyHunters übernahm die Verantwortung. Die Kommission bestätigte den Vorfall am 30. März — damit handelt es sich um die gravierendste Kompromittierung einer EU-Institution in diesem Jahr und ein präzises Beispiel für die Bedrohungslage, in der vier bedeutende EU-Cybersicherheitsverordnungen nun gleichzeitig durchgesetzt werden.

Das Frühjahr 2026 markiert eine Konvergenz: Die NIS2-Änderungen und der CSA2-Vorschlag vom 20. Januar, die aktive DORA-Durchsetzung durch nationale Aufsichtsbehörden und die sich schnell nähernde CRA-Meldepflicht am 11. September.

Die EU verhängte am 16. März auch ihre ersten Cyber-Sanktionen des Jahres gegen chinesische und iranische Bedrohungsakteure. Dies sind keine Hintergrundereignisse — sie bilden den Durchsetzungskontext, den jede IT-Führungskraft und jeder Compliance-Beauftragte jetzt verstehen muss.

Wichtigste Erkenntnisse

• Datenpanne bei der Europäischen Kommission bestätigt: Am 30. März 2026 stahl ShinyHunters über 350 GB aus ihren AWS-Cloud-Konten, darunter Datenbanken, Verträge und E-Mail-Server-Dumps.
• Erste EU-Cyber-Sanktionen 2026: Am 16. März verhängte der EU-Rat restriktive Maßnahmen gegen drei Unternehmen — Integrity Technology Group, Anxun Information Technology (China) und Emennet Pasargad (Iran) — sowie zwei Einzelpersonen.
• NIS2- und CSA2-Änderungen vorgeschlagen: Am 20. Januar 2026 legte die Europäische Kommission Änderungen vor, die Zuständigkeit, Anwendungsbereich und Zertifizierungspflichten in beiden Rahmenwerken präzisieren.
• CRA-Meldepflicht rückt näher: Die obligatorischen Meldepflichten für Schwachstellen und Vorfälle gemäß dem Cyber Resilience Act beginnen am 11. September 2026.
• DORA-Durchsetzung ist aktiv: Vollständig anwendbar seit dem 17. Januar 2025, wobei die BaFin und andere nationale Aufsichtsbehörden im gesamten Jahr 2026 Prüfungen durchführen.

Der Bedrohungskontext, der diese Änderungen erforderlich machte

Die regulatorische Beschleunigung der EU im Frühjahr 2026 ist eine direkte Reaktion auf einen dokumentierten Anstieg von Angriffen auf europäische Institutionen und kritische Infrastrukturen. Die Datenpanne bei der Europäischen Kommission, die ersten EU-Cyber-Sanktionen des Jahres 2026 und das statistische Bild von ENISA und unabhängigen Incident-Respondern weisen alle in dieselbe Richtung: Die Bedrohung ist real, gezielt und andauernd.

Die Datenpanne bei der Europäischen Kommission (März 2026)

Der Angriff vom 24. März auf die AWS-gehostete Europa.eu-Plattform der Kommission ist das deutlichste aktuelle Beispiel für Cloud-Supply-Chain-Risiken. ShinyHunters — dieselbe Erpressergruppe hinter mehreren hochkarätigen Datendiebstahl-Kampagnen — behauptete, über 350 GB an Daten entwendet zu haben: E-Mail-Server-Dumps, Datenbanken, vertrauliche Dokumente und Verträge.

Ein 90-GB-Archiv erschien auf ihrer Darkweb-Leak-Seite. Die internen Systeme der Kommission waren nicht betroffen, aber der Vorfall legte eine strukturelle Schwachstelle offen: öffentlich zugängliche Cloud-Infrastruktur, die ohne die Zugangskontrollen und Credential-Hygiene betrieben wurde, die NIS2 und DORA vorschreiben sollen.

„Erste Erkenntnisse unserer laufenden Untersuchung deuten darauf hin, dass Daten von diesen Websites entwendet wurden. Die internen Systeme der Kommission waren von dem Cyberangriff nicht betroffen." — Pressemitteilung der Europäischen Kommission, 27. März 2026

Dies war die zweite Datenpanne der Kommission im Jahr 2026. Ein Vorfall im Februar hatte bereits die Mobile-Device-Management-Plattform kompromittiert, die zur Verwaltung der Mitarbeitergeräte verwendet wird. Zwei bedeutende Datenpannen in zwei Monaten bei einer einzigen Institution sind kein Zufall — sie spiegeln eine anhaltende, gezielte Angriffskampagne wider.

EU-Cyber-Sanktionen — 16. März 2026

Am 16. März 2026 verhängte der EU-Rat restriktive Maßnahmen gegen drei Unternehmen und zwei Einzelpersonen im Rahmen des EU-Cyber-Diplomatie-Instrumentariums — die ersten EU-Cyber-Sanktionen des Jahres.

Die sanktionierten Parteien:

• Integrity Technology Group (China): Lieferte Produkte, die zur Kompromittierung von über 65.000 Geräten in sechs EU-Mitgliedstaaten zwischen 2022 und 2023 verwendet wurden.
• Anxun Information Technology (China): Erbrachte Hacking-Dienstleistungen gegen kritische EU-Infrastrukturen. Zwei Mitgründer wurden individuell sanktioniert.
• Emennet Pasargad (Iran): Kompromittierte eine französische Abonnentendatenbank, manipulierte Werbetafeln während der Olympischen Spiele 2024 in Paris zur Verbreitung von Desinformation und kompromittierte einen schwedischen SMS-Dienst.

Alle gelisteten Unternehmen unterliegen Vermögenssperren. Die beiden Einzelpersonen unterliegen zusätzlich Reiseverboten. Das EU-Cyber-Sanktionsregime umfasst nun insgesamt 19 Einzelpersonen und 7 Unternehmen.

Der statistische Hintergrund

Laut dem Bericht ENISA Threat Landscape 2025 machten DDoS-Angriffe 77 % aller erfassten EU-Cybervorfälle aus, hauptsächlich getrieben von Hacktivistengruppen. Ransomware bleibt die operativ schädlichste Bedrohung: 81,1 % der Cybercrime-Vorfälle gegen EU-Organisationen betrafen Ransomware.

Die öffentliche Verwaltung war der am häufigsten angegriffene Sektor und repräsentierte 38 % aller Vorfälle. Staatlich unterstützte Gruppen intensivierten langfristige Spionagekampagnen gegen Telekommunikation, Logistik und Fertigung.

Das Bild der Incident-Responder vor Ort ist ebenso eindeutig. Der Eye Security Incident Report 2026 — basierend auf 630 Untersuchungen in den Benelux-Ländern und Deutschland — ergab, dass 70 % aller Fälle Business Email Compromise (BEC) waren. Noch aufschlussreicher: 62 % der klassifizierten Fälle seit Januar 2025 beinhalteten MFA-Umgehung. Angreifer brechen keine Verschlüsselung — sie stehlen oder umgehen Anmeldedaten. Das ist genau der Angriffsvektor, den NIS2, DORA und die DSGVO-Durchsetzung schließen sollen.

Die Datenpanne bei der Europäischen Kommission folgte einem gut dokumentierten Muster: kompromittierte Cloud-Anmeldedaten, kein Audit-Trail, keine Zugriffsgrenzen. Passwork bietet IT-Teams einen strukturierten Tresor mit rollenbasierter Zugriffskontrolle, granularen Berechtigungen und einem vollständigen Aktivitätsprotokoll — genau die Kontrollen, die NIS2 und DORA ausdrücklich fordern. Passwork kostenlos testen

NIS2-Änderungen: Was sich am 20. Januar 2026 geändert hat

Am 20. Januar 2026 schlug die Europäische Kommission Änderungen zu NIS2 vor, die sich auf Rechtssicherheit, vereinfachte Compliance und präzisierte Zuständigkeitsregeln konzentrieren. Der Vorschlag enthielt auch einen überarbeiteten Cybersecurity Act (CSA2), der das Mandat der ENISA erweitert und auf eine verpflichtende Cybersicherheitszertifizierung für Produkte und Dienste hinarbeitet, die in kritischen Sektoren eingesetzt werden.

Die drei praktischen Änderungen in NIS2

Die Änderungen adressieren drei Problemfelder, die im ersten Jahr der Umsetzung in den Mitgliedstaaten aufgetreten sind:

1. Klarheit bei der Zuständigkeit. Die Änderungen legen fest, welcher Mitgliedstaat die Aufsichtsbefugnis über grenzüberschreitend tätige Unternehmen hat — eine wesentliche Quelle der Compliance-Unsicherheit für multinationale Organisationen, die gleichzeitig in mehreren EU-Rechtsordnungen operieren.
2. Ransomware-Datenerfassung. Der Vorschlag standardisiert die Erfassung von Ransomware-bezogenen Vorfallsdaten in allen Mitgliedstaaten und ermöglicht so einen konsistenteren Austausch von Bedrohungsinformationen auf EU-Ebene.
3. Präzisierung des Anwendungsbereichs. Eine neue Kategorie „kleine mittelständische Unternehmen" passt die Schwellenwerte an, die bestimmen, ob Organisationen unter die Klassifizierung als wesentliche oder wichtige Einrichtung gemäß NIS2 fallen.

CSA2: Die bedeutendere strukturelle Veränderung

Die CSA2-Revision erweitert sowohl den sachlichen als auch den persönlichen Anwendungsbereich des EU-Cybersicherheitsrahmens. Die entscheidende Änderung: Die Zertifizierung für IKT-Produkte und -Dienste, die in kritischen Sektoren eingesetzt werden, wird von freiwillig auf verpflichtend umgestellt. Organisationen, die sich auf die aktuellen freiwilligen ENISA-Zertifizierungssysteme verlassen haben, müssen ihre Produktportfolios und Lieferantenverträge neu bewerten, sobald CSA2 verabschiedet wird — erwartet Ende 2026 oder 2027.

Deutschland: NIS2-Umsetzung ist bereits in Kraft

Das deutsche NIS2-Umsetzungsgesetz (NIS2UmsuCG) trat am 6. Dezember 2025 in Kraft. Die BSI-Registrierungsfrist war der 6. März 2026. Ungefähr 30.000 Unternehmen in Deutschland fallen unter NIS2. Eine Umfrage von nis2-check.de ergab, dass 80 % der betroffenen Unternehmen ihre Pflichten nicht kannten (ADVISORI, Februar 2026). Das Gesetz führt mit §38 NIS2UmsuCG eine persönliche Haftung der Geschäftsleitung ein — ein Novum im deutschen Cybersicherheitsrecht.

NIS2-Meldepflichten bei Vorfällen

DORA: Durchsetzung beginnt 2026

DORA (Verordnung EU 2022/2554) ist seit dem 17. Januar 2025 unmittelbar anwendbar. Es ist kein nationales Umsetzungsgesetz erforderlich und keine Verschiebung möglich. Im Jahr 2026 führen nationale Aufsichtsbehörden, darunter die deutsche BaFin, aktive Prüfungen bei Finanzinstituten und deren IKT-Drittanbietern durch.

Für wen DORA gilt

DORA gilt für den gesamten Finanzsektor: Kreditinstitute, Versicherungsunternehmen, Wertpapierfirmen, Zahlungsdienstleister, Krypto-Asset-Dienstleister und — entscheidend — die IKT-Drittanbieter, die kritische Dienstleistungen für diese Unternehmen erbringen.

Ein Cloud-Anbieter, der Kernbanksysteme hostet, fällt ebenso unter DORA wie die Bank selbst. Die Reichweite der Verordnung erstreckt sich weit über traditionelle Finanzdienstleistungen hinaus.

Die fünf Compliance-Säulen

DORA organisiert seine Anforderungen in fünf Bereichen: IKT-Risikomanagement, Vorfallsmeldung, Tests der digitalen operationalen Resilienz, Drittanbieter-Risikomanagement und Informationsaustausch.

Die anspruchsvollste Anforderung ist das Threat-Led Penetration Testing (TLPT) — verpflichtend für systemrelevante Institute. TLPT erfordert spezialisierte Red Teams, die reale Angriffsszenarien auf Basis aktueller Bedrohungsinformationen simulieren, nicht generische Penetrationstest-Methoden.

Compliance-Lücken bleiben erheblich

Obwohl DORA seit über einem Jahr in Kraft ist, bleibt die Bereitschaft im Sektor unvollständig. Eine Veeam-Umfrage ergab, dass 96 % der EMEA-Finanzorganisationen glauben, ihre Resilienz verbessern zu müssen, um die DORA-Anforderungen zu erfüllen.

Eine Computerwoche-Umfrage ergab, dass 44 % der betroffenen Unternehmen erhebliche Umsetzungsprobleme melden. Spezifische Lücken: 24 % haben keinen DORA-Umsetzungsverantwortlichen benannt, und 23 % haben keine Tests der digitalen operationalen Resilienz durchgeführt.

Diese Zahlen bedeuten, dass BaFin-Prüfer auf Organisationen treffen, die grundlegende Bereitschaftsschritte nicht abgeschlossen haben — mit Durchsetzungskonsequenzen, die den Lizenzentzug einschließen, nicht nur Bußgelder.

Cyber Resilience Act: Die Frist im September 2026

Der Cyber Resilience Act trat am 10. Dezember 2024 in Kraft. Ab dem 11. September 2026 müssen Hersteller und Importeure digitaler Produkte aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle innerhalb von 24 Stunden an ENISA melden. Die vollständigen CRA-Anforderungen — einschließlich der Security-by-Design-Pflichten — gelten ab dem 11. Dezember 2027.

Was der Meilenstein September 2026 umfasst

Am 11. September treten zwei spezifische Pflichten in Kraft:

• Schwachstellenmeldung: Hersteller müssen aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden nach Kenntnisnahme an ENISA melden.
• Vorfallsmeldung: Schwerwiegende Vorfälle mit Auswirkungen auf die Sicherheit digitaler Produkte müssen ebenfalls innerhalb von 24 Stunden an ENISA gemeldet werden.

Die vollständigen CRA-Anforderungen — Security by Design, Software Bill of Materials (SBOM), kontinuierliches Schwachstellenmanagement und CE-Kennzeichnung für digitale Produkte — gelten ab Dezember 2027. Organisationen, die bis Mitte 2026 nicht mit der Vorbereitung begonnen haben, werden Schwierigkeiten haben, diese Frist einzuhalten. Die maximale CRA-Geldstrafe beträgt 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.

NIS2 vs. DORA vs. CRA vs. CSA2: Welche Verordnung gilt für Sie?

Das Lex-specialis-Prinzip bedeutet, dass sektorspezifische Verordnungen Vorrang vor allgemeinen haben. Finanzunternehmen, die DORA unterliegen, sind von bestimmten NIS2-Pflichten befreit, wenn DORA gleichwertige oder strengere Anforderungen stellt. Alle vier Verordnungen können sich bei großen Organisationen überschneiden, die sektorübergreifend tätig sind — ein Cloud-Anbieter, der Finanzinstitute bedient und gleichzeitig IoT-Hardware herstellt, kann Pflichten aus allen vier Verordnungen gleichzeitig unterliegen.

Verordnungsvergleich

Entscheidungsmatrix: Gilt diese Verordnung für Sie?

DORA verlangt dokumentierte Zugangskontrollen und Audit-Trails für alle privilegierten IKT-Konten. Passworks sichere Freigabe von Anmeldedaten und Aktivitätsprotokollierung bieten Compliance-Teams die Nachweisspur, nach der Prüfer fragen.

Praktische Compliance-Checkliste für Frühjahr/Sommer 2026

Da 62 % der EU-Cybervorfälle im Jahr 2025 MFA-Umgehung beinhalteten und 70 % als Business Email Compromise klassifiziert wurden, sind die dringendsten technischen Maßnahmen identitätsbezogen: MFA überall durchsetzen, privilegierten Zugang prüfen und die Exposition von Drittanbieter-Anmeldedaten bewerten. Regulatorische Compliance und operative Sicherheit weisen auf dieselben Kontrollen hin.

Sofortmaßnahmen (April – Juni 2026)

1. BSI-Registrierung abschließen (Deutschland), falls noch nicht erfolgt. Kontaktieren Sie das BSI umgehend und dokumentieren Sie den Versuch — auch wenn die Frist vom 6. März verstrichen ist, ist der Nachweis eines gutgläubigen Bemühens in Durchsetzungsverfahren relevant.
2. Eine NIS2-Auswirkungsanalyse durchführen. Ermitteln Sie, ob Ihre Organisation und ihre Tochtergesellschaften, Joint Ventures und kritischen Lieferanten unter die NIS2-Klassifizierung als wesentliche oder wichtige Einrichtung fallen.
3. Einen 24/72-Stunden-Vorfallsmeldeprozess etablieren. Weisen Sie klare Verantwortlichkeiten zu, erstellen Sie Meldevorlagen und testen Sie den Eskalationspfad vollständig, bevor ein Vorfall Sie zwingt, ihn zu nutzen.
4. MFA für alle Fernzugriffe und privilegierten Konten durchsetzen. Angesichts der Tatsache, dass 62 % der klassifizierten EU-Vorfälle MFA-Umgehung beinhalteten (Eye Security, 2026), ist dies die einzelne Maßnahme mit dem höchsten Return on Investment.
5. IKT-Drittanbieter prüfen. DORA verlangt vertragliche Sicherheitsverpflichtungen für alle kritischen IKT-Lieferanten. NIS2 verlangt Sicherheitsbewertungen der Lieferkette. Beide Verordnungen fordern dokumentierte Nachweise der Drittanbieter-Überwachung.
6. Eine Richtlinie für sicheres Credential-Management implementieren. Zentralisieren Sie das Passwort-Management für privilegierte Konten, um den Credential-Diebstahl-Vektor zu verhindern, der bei der ShinyHunters-Datenpanne genutzt wurde. Unverwaltete geteilte Anmeldedaten bleiben der häufigste Einstiegspunkt bei BEC- und Cloud-Konto-Kompromittierungsfällen.

Mittelfristige Maßnahmen (Juli – September 2026)

1. Auf die CRA-Meldepflichten vorbereiten (ab 11. September 2026). Etablieren Sie einen Prozess zur Schwachstellenoffenlegung, benennen Sie einen Ansprechpartner für ENISA-Meldungen und bestätigen Sie, dass Ihr Produktinventar genau widerspiegelt, welche Artikel als „digitale Produkte mit digitalen Elementen" qualifizieren.
2. Einen DORA-Resilienztest durchführen. Führen Sie mindestens eine Tabletop-Übung durch. Systemrelevante Institute müssen ein vollständiges TLPT mit einem qualifizierten Red Team planen, das auf Basis aktueller Bedrohungsinformationen arbeitet.
3. Mit der CSA2-Zertifizierungsbewertung beginnen. Identifizieren Sie, welche Produkte oder Dienstleistungen eine verpflichtende EU-Cybersicherheitszertifizierung gemäß CSA2 erfordern werden, und beauftragen Sie frühzeitig eine notifizierte Stelle — Zertifizierungszeiträume sind lang.
4. DSGVO-Compliance überprüfen. Der französische Conseil d'État bestätigte am 4. März 2026 eine DSGVO-Geldstrafe von 40 Millionen Euro gegen Criteo. Die Gesamtsumme der DSGVO-Bußgelder seit 2018 übersteigt nun 7,1 Milliarden Euro, wobei allein 2025 1,2 Milliarden Euro verhängt wurden (Kiteworks, März 2026). Die Datenschutzdurchsetzung befindet sich auf Höchstniveau — behandeln Sie sie als parallele Spur, nicht als separates Programm.

Fazit

Bedrohungs- und Regulierungskontext konvergieren. Das EU-Cybersicherheitsumfeld im Frühjahr 2026 ist durch gleichzeitige Verschärfung der Regulierung und Eskalation von Angriffen gekennzeichnet. Die Datenpanne bei der Europäischen Kommission und die ersten EU-Cyber-Sanktionen des Jahres sind keine isolierten Ereignisse — sie sind der Durchsetzungskontext für NIS2, DORA, CRA und CSA2.

Identitätssicherheit hat unmittelbare Priorität. Der Diebstahl von Anmeldedaten durch Cloud-Konto-Kompromittierung ist genau das, was die NIS2-Anforderung „angemessener technischer Maßnahmen" verhindern soll. Da 62 % der EU-Vorfälle im Jahr 2025 MFA-Umgehung beinhalteten, sind die Durchsetzung von MFA, die Prüfung privilegierter Zugriffe und die Zentralisierung des Credential-Managements grundlegende Kontrollen — solche, die gleichzeitig das Risiko einer Datenpanne reduzieren und die Anforderungen von NIS2, DORA und DSGVO erfüllen.

Die Fristen sind festgelegt. Die CRA-Meldepflicht am 11. September 2026 liegt sechs Monate entfernt. DORA-Prüfungen laufen. Die NIS2-Registrierung in Deutschland endete am 6. März. Organisationen, die Compliance als Dokumentationsübung statt als Sicherheitsverbesserungsprogramm behandeln, sind sowohl regulatorischen Strafen als auch operativen Risiken ausgesetzt.

Die gemeinsame Annahme in allen vier Rahmenwerken: Organisationen führen dokumentierte, prüfbare Kontrollen darüber, wer auf welche Anmeldedaten zugreift, wann und warum. Das ist der Ausgangspunkt für jedes ernsthafte Compliance-Programm — und die Baseline, an der Regulierungsbehörden prüfen werden.

Passwork ist ein selbst gehosteter Unternehmens-Passwort-Manager mit rollenbasierter Zugriffskontrolle, detaillierten Aktivitätsprotokollen und Zero-Knowledge-Verschlüsselung — vollständig innerhalb Ihrer eigenen Infrastruktur bereitgestellt. Er adressiert die Credential-Management-Kontrollen, die NIS2, DORA und DSGVO verlangen, in einem einzigen, prüfbaren System. Passwork kostenlos in Ihrer Infrastruktur testen

FAQ: EU-Cybersicherheitsverordnungen im Frühjahr 2026

Was hat sich im EU-Cybersicherheitsrecht im Frühjahr 2026 geändert?

Die Europäische Kommission schlug am 20. Januar 2026 Änderungen zu NIS2 und einen neuen Cybersecurity Act (CSA2) vor. Die CRA-Meldepflichten beginnen am 11. September 2026. DORA wird seit Januar 2025 aktiv durchgesetzt. Die EU verhängte am 16. März auch ihre ersten Cyber-Sanktionen des Jahres 2026 gegen chinesische und iranische Bedrohungsakteure.

Was ist der Unterschied zwischen NIS2 und DORA?

NIS2 ist eine breit angelegte Richtlinie, die 18 Sektoren abdeckt und sich auf Cybersicherheits-Risikomanagement und Vorfallsmeldung konzentriert. DORA ist eine speziell für den Finanzsektor geltende Verordnung mit tiefergehenden Anforderungen an IKT-Risikomanagement, Resilienztests und Drittanbieter-Überwachung. Das Lex-specialis-Prinzip bedeutet, dass DORA für Finanzunternehmen Vorrang hat, wenn seine Anforderungen strenger sind als die entsprechenden NIS2-Pflichten.

Welche Strafen drohen bei NIS2-Nichteinhaltung im Jahr 2026?

Wesentlichen Einrichtungen drohen Bußgelder von bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Wichtigen Einrichtungen drohen Bußgelder von bis zu 7 Millionen Euro oder 1,4 % des weltweiten Umsatzes. Das deutsche NIS2-Umsetzungsgesetz (§38 NIS2UmsuCG) führt zudem eine persönliche Haftung der Geschäftsleitung ein — ein Novum im deutschen Cybersicherheitsrecht.

Wann tritt der Cyber Resilience Act in Kraft?

Der CRA trat am 10. Dezember 2024 in Kraft. Die verpflichtenden Meldepflichten für Schwachstellen und Vorfälle beginnen am 11. September 2026. Die vollständigen Security-by-Design-Anforderungen und CE-Kennzeichnungspflichten gelten ab dem 11. Dezember 2027. Organisationen, die die Vorbereitung bis Ende 2026 verschieben, werden einen komprimierten Zeitrahmen für die Frist 2027 haben.

Wer wurde im März 2026 unter den EU-Cyber-Sanktionen sanktioniert?

Am 16. März 2026 sanktionierte der EU-Rat Integrity Technology Group und Anxun Information Technology (beide mit Sitz in China) sowie Emennet Pasargad (mit Sitz im Iran) zusammen mit zwei chinesischen Einzelpersonen. Die Sanktionen umfassen Vermögenssperren; die beiden Einzelpersonen unterliegen zusätzlich Reiseverboten. Das EU-Cyber-Sanktionsregime umfasst nun insgesamt 19 Einzelpersonen und 7 Unternehmen.

Was ist der EU Cybersecurity Act 2 (CSA2)?

CSA2 ist die vorgeschlagene Überarbeitung des EU Cybersecurity Act, angekündigt am 20. Januar 2026. Er erweitert das Mandat der ENISA und führt eine verpflichtende Cybersicherheitszertifizierung für IKT-Produkte und -Dienstleistungen ein, die in kritischen Sektoren eingesetzt werden — und ersetzt damit das aktuelle freiwillige Zertifizierungsrahmenwerk für diese Kategorien. Erwartete Verabschiedung: Ende 2026 oder 2027.

Gilt NIS2 oder DORA für Cloud-Anbieter?

Ein Cloud-Anbieter, der kritische Dienstleistungen für Finanzinstitute erbringt, fällt als IKT-Drittanbieter unter DORA. Wenn derselbe Anbieter auch in einem der 18 NIS2-Sektoren mit den entsprechenden Größenschwellenwerten tätig ist, gilt NIS2 unabhängig davon. Die beiden Verordnungen können — und tun dies häufig — gleichzeitig für dieselbe Organisation gelten.

Was geschah bei der Datenpanne der Europäischen Kommission 2026?

Am 24. März 2026 verschafften sich Angreifer Zugang zu den AWS-Cloud-Konten der Europäischen Kommission, die die Europa.eu-Plattform hosten. Die Erpressergruppe ShinyHunters übernahm die Verantwortung und behauptete, über 350 GB an Daten entwendet zu haben, darunter Datenbanken, Verträge und vertrauliche Dokumente. Die Kommission bestätigte die Datenpanne am 30. März 2026.

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

Credential-Lücken sind 2026 der häufigste Grund für NIS2-Audit-Mängel. Dieser Leitfaden behandelt die Passwortanforderungen gemäß Artikel 21, die Ausrichtung an NIST SP 800-63B, AD-Härtungsschritte und die Audit-Nachweise, nach denen Regulierungsbehörden zuerst fragen.

Passwork BlogAlex Muntyan

Passwort-Manager-Bereitstellungsmodelle: Cloud, Self-Hosted & Hybrid

Die Wahl, wo Sie Ihren Passwort-Manager betreiben, ist ebenso wichtig wie die Wahl, welchen Sie verwenden. Dieser Leitfaden schlüsselt Cloud-, Self-Hosted- und Hybrid-Bereitstellung auf — mit einer Compliance-Matrix für DSGVO, HIPAA und NIS2 sowie einem klaren Blick auf die Kompromisse jedes Modells.

Passwork BlogAlex Muntyan

Was ist ein Passkey? Leitfaden zur passwortlosen Authentifizierung

Ein Passkey ist ein phishing-resistentes Credential, das auf Ihrem Gerät gespeichert wird. Melden Sie sich mit einem biometrischen Tippen an — kein Passwort zum Merken oder Stehlen. Dieser Leitfaden behandelt die technischen Mechanismen, die Plattformeinrichtung, reale Leistungsdaten und was der Übergang für Unternehmensteams bedeutet.

Passwork BlogAlex Muntyan

Introducción

El 24 de marzo de 2026, atacantes accedieron a las cuentas de AWS en la nube de la Comisión Europea y exfiltraron más de 350 GB de datos antes de ser bloqueados.

El grupo de extorsión ShinyHunters se atribuyó la responsabilidad. La Comisión confirmó la brecha el 30 de marzo, convirtiéndola en el compromiso institucional de la UE más significativo del año y una ilustración precisa del entorno de amenazas en el que cuatro importantes regulaciones de ciberseguridad de la UE se están aplicando simultáneamente.

La primavera de 2026 marca una convergencia: las enmiendas a NIS2 y la propuesta CSA2 del 20 de enero, la aplicación activa de DORA por parte de los reguladores nacionales, y la fecha límite de notificación del CRA del 11 de septiembre que se aproxima rápidamente.

La UE también impuso sus primeras sanciones cibernéticas del año el 16 de marzo, dirigidas contra actores de amenazas chinos e iraníes. Estos no son eventos de trasfondo — son el contexto de aplicación que todo líder de TI y responsable de cumplimiento necesita comprender ahora.

Puntos clave

• Confirmada la brecha de datos de la Comisión Europea: El 30 de marzo de 2026, ShinyHunters robó más de 350 GB de sus cuentas de AWS en la nube, incluyendo bases de datos, contratos y volcados de servidores de correo.
• Primeras sanciones cibernéticas de la UE en 2026: El 16 de marzo, el Consejo de la UE impuso medidas restrictivas contra tres entidades — Integrity Technology Group, Anxun Information Technology (China) y Emennet Pasargad (Irán) — y dos individuos.
• Enmiendas propuestas a NIS2 y CSA2: El 20 de enero de 2026, la Comisión Europea introdujo cambios que aclaran la jurisdicción, el alcance y las obligaciones de certificación en ambos marcos.
• Fecha límite de notificación del CRA próxima: Las obligaciones de notificación de vulnerabilidades e incidentes bajo la Ley de Ciberresiliencia comienzan el 11 de septiembre de 2026.
• La aplicación de DORA está activa: Totalmente aplicable desde el 17 de enero de 2025, con BaFin y otros reguladores nacionales realizando auditorías durante 2026.

El contexto de amenazas que hizo necesarios estos cambios

La aceleración regulatoria de la UE en primavera de 2026 es una respuesta directa a un aumento documentado de ataques contra instituciones europeas e infraestructura crítica. La brecha de la Comisión Europea, las primeras sanciones cibernéticas de la UE en 2026, y el panorama estadístico de ENISA e investigadores de incidentes independientes apuntan en la misma dirección: la amenaza es real, dirigida y continua.

La brecha de la Comisión Europea (marzo 2026)

El ataque del 24 de marzo a la plataforma Europa.eu de la Comisión, alojada en AWS, es el ejemplo reciente más claro de riesgo en la cadena de suministro en la nube. ShinyHunters — el mismo grupo de extorsión detrás de múltiples campañas de robo de datos de alto perfil — afirmó haber obtenido más de 350 GB de datos: volcados de servidores de correo, bases de datos, documentos confidenciales y contratos.

Un archivo de 90 GB apareció en su sitio de filtraciones en la dark web. Los sistemas internos de la Comisión no se vieron afectados, pero el incidente expuso una vulnerabilidad estructural: infraestructura en la nube de cara al público operada sin los controles de acceso y la higiene de credenciales que NIS2 y DORA están diseñados para exigir.

«Los hallazgos iniciales de nuestra investigación en curso sugieren que se han extraído datos de esos sitios web. Los sistemas internos de la Comisión no se vieron afectados por el ciberataque.» — Comunicado de prensa de la Comisión Europea, 27 de marzo de 2026

Esta fue la segunda brecha de la Comisión en 2026. Un incidente en febrero ya había comprometido la plataforma de gestión de dispositivos móviles utilizada para administrar los dispositivos del personal. Dos brechas significativas en dos meses en una sola institución no es una coincidencia — refleja una campaña de ataques sostenida.

Sanciones cibernéticas de la UE — 16 de marzo de 2026

El 16 de marzo de 2026, el Consejo de la UE impuso medidas restrictivas contra tres entidades y dos individuos bajo el conjunto de herramientas de ciberdiplomacia de la UE — las primeras sanciones cibernéticas de la UE del año.

Las partes sancionadas:

• Integrity Technology Group (China): Proporcionó productos utilizados para comprometer más de 65.000 dispositivos en seis estados miembros de la UE entre 2022 y 2023.
• Anxun Information Technology (China): Proporcionó servicios de hacking dirigidos a infraestructura crítica de la UE. Dos cofundadores fueron sancionados individualmente.
• Emennet Pasargad (Irán): Vulneró una base de datos de suscriptores francesa, comprometió vallas publicitarias durante los Juegos Olímpicos de París 2024 para difundir desinformación, y comprometió un servicio de SMS sueco.

Todas las entidades listadas enfrentan congelación de activos. Los dos individuos también enfrentan prohibiciones de viaje. El régimen de sanciones cibernéticas de la UE ahora cubre 19 individuos y 7 entidades.

El contexto estadístico

Según el informe ENISA Threat Landscape 2025, los ataques DDoS representaron el 77% de todos los incidentes cibernéticos registrados en la UE, impulsados principalmente por grupos hacktivistas. El ransomware sigue siendo la amenaza más dañina operativamente: el 81,1% de los incidentes de ciberdelincuencia dirigidos a organizaciones de la UE involucraron ransomware.

La administración pública fue el sector más atacado, representando el 38% de todos los incidentes. Los grupos alineados con estados intensificaron las campañas de espionaje a largo plazo contra telecomunicaciones, logística y manufactura.

El panorama de los investigadores de incidentes sobre el terreno es igualmente directo. El informe de incidentes 2026 de Eye Security — basado en 630 investigaciones en Benelux y Alemania — encontró que el 70% de todos los casos fueron Compromiso de Correo Electrónico Empresarial (BEC). Más revelador: el 62% de los casos clasificados desde enero de 2025 involucraron elusión de MFA. Los atacantes no están rompiendo el cifrado — están robando o eludiendo credenciales. Ese es el vector que NIS2, DORA y la aplicación del RGPD están diseñados para cerrar.

La brecha de la Comisión Europea siguió un patrón bien documentado: credenciales en la nube comprometidas, sin registro de auditoría, sin límites de acceso. Passwork proporciona a los equipos de TI una bóveda estructurada con acceso basado en roles, permisos granulares y un registro completo de actividad — los controles que NIS2 y DORA exigen explícitamente. Pruebe Passwork gratis

Enmiendas a NIS2: Qué cambió el 20 de enero de 2026

El 20 de enero de 2026, la Comisión Europea propuso enmiendas a NIS2 centradas en la certeza jurídica, el cumplimiento simplificado y las reglas jurisdiccionales clarificadas. La propuesta también introdujo una Ley de Ciberseguridad (CSA2) revisada que amplía el mandato de ENISA y avanza hacia la certificación obligatoria de ciberseguridad para productos y servicios utilizados en sectores críticos.

Los tres cambios prácticos en NIS2

Las enmiendas abordan tres puntos problemáticos que surgieron durante el primer año de implementación en los estados miembros:

1. Claridad jurisdiccional. Las enmiendas especifican qué estado miembro tiene autoridad de supervisión sobre entidades transfronterizas — una fuente importante de incertidumbre de cumplimiento para organizaciones multinacionales que operan en múltiples jurisdicciones de la UE simultáneamente.
2. Recopilación de datos de ransomware. La propuesta estandariza la recopilación de datos de incidentes relacionados con ransomware en los estados miembros, permitiendo un intercambio de inteligencia de amenazas más consistente a nivel de la UE.
3. Refinamiento del alcance. Una nueva categoría de «pequeña mediana empresa» ajusta los umbrales que determinan si las organizaciones se clasifican como entidades esenciales o importantes bajo NIS2.

CSA2: El cambio estructural más significativo

La revisión de CSA2 amplía tanto el alcance material como subjetivo del marco de ciberseguridad de la UE. El cambio crítico: la certificación para productos y servicios de TIC utilizados en sectores críticos pasa de voluntaria a obligatoria. Las organizaciones que han confiado en los esquemas de certificación voluntaria actuales de ENISA necesitarán reevaluar sus carteras de productos y contratos con proveedores una vez que se adopte CSA2 — esperado a finales de 2026 o 2027.

Alemania: La implementación de NIS2 ya está en vigor

La ley de implementación de NIS2 de Alemania (NIS2UmsuCG) entró en vigor el 6 de diciembre de 2025. La fecha límite de registro en BSI fue el 6 de marzo de 2026. Aproximadamente 30.000 empresas en Alemania están bajo el ámbito de NIS2. Una encuesta de nis2-check.de encontró que el 80% de las empresas afectadas desconocían sus obligaciones (ADVISORI, febrero 2026). La ley introduce responsabilidad personal para la dirección bajo el §38 NIS2UmsuCG — una primicia en la legislación alemana de ciberseguridad.

Requisitos de notificación de incidentes de NIS2

DORA: La aplicación comienza en 2026

DORA (Reglamento UE 2022/2554) es directamente aplicable desde el 17 de enero de 2025. No se requiere ley de implementación nacional y no es posible ningún aplazamiento. En 2026, los reguladores nacionales, incluido BaFin de Alemania, están realizando auditorías activas de instituciones financieras y sus proveedores de TIC terceros.

A quién cubre DORA

DORA se aplica a todo el sector financiero: entidades de crédito, compañías de seguros, empresas de inversión, proveedores de servicios de pago, proveedores de servicios de criptoactivos y — de manera crítica — los proveedores de TIC terceros que suministran servicios críticos a estas entidades.

Un proveedor de nube que aloja sistemas bancarios centrales está bajo DORA como proveedor de TIC tercero, al igual que el propio banco. El alcance del reglamento se extiende mucho más allá de los servicios financieros tradicionales.

Los cinco pilares de cumplimiento

DORA organiza sus requisitos en torno a cinco áreas: gestión de riesgos de TIC, notificación de incidentes, pruebas de resiliencia operativa digital, gestión de riesgos de terceros e intercambio de información.

El requisito más exigente es la Prueba de Penetración Guiada por Amenazas (TLPT) — obligatoria para instituciones sistémicamente importantes. TLPT requiere equipos rojos especializados para simular escenarios de ataque reales basados en inteligencia de amenazas actual, no metodologías de pruebas de penetración genéricas.

Las brechas de cumplimiento siguen siendo significativas

A pesar de que DORA lleva en vigor más de un año, la preparación en el sector es incompleta. Una encuesta de Veeam encontró que el 96% de las organizaciones financieras de EMEA creen que necesitan mejorar su resiliencia para cumplir con los requisitos de DORA.

Una encuesta de Computerwoche encontró que el 44% de las empresas afectadas reportan problemas significativos de implementación. Brechas específicas: el 24% no ha identificado un líder de implementación de DORA, y el 23% no ha realizado pruebas de resiliencia operativa digital.

Estos números significan que los auditores de BaFin están entrando en organizaciones que no han completado los pasos básicos de preparación — con consecuencias de aplicación que incluyen la revocación de licencias, no solo multas.

Ley de Ciberresiliencia: La fecha límite de septiembre 2026

La Ley de Ciberresiliencia entró en vigor el 10 de diciembre de 2024. A partir del 11 de septiembre de 2026, los fabricantes e importadores de productos digitales deben notificar a ENISA las vulnerabilidades explotadas activamente y los incidentes graves dentro de las 24 horas. Los requisitos completos del CRA — incluyendo las obligaciones de seguridad desde el diseño — se aplican a partir del 11 de diciembre de 2027.

Qué cubre el hito de septiembre 2026

Dos obligaciones específicas se activan el 11 de septiembre:

• Notificación de vulnerabilidades: Los fabricantes deben notificar a ENISA las vulnerabilidades explotadas activamente dentro de las 24 horas siguientes a tener conocimiento de ellas.
• Notificación de incidentes: Los incidentes graves con impacto en la seguridad de los productos digitales también deben notificarse a ENISA dentro de las 24 horas.

Los requisitos completos del CRA — seguridad desde el diseño, lista de materiales de software (SBOM), gestión continua de vulnerabilidades y marcado CE para productos digitales — se aplican a partir de diciembre de 2027. Las organizaciones que no hayan comenzado la preparación a mediados de 2026 tendrán dificultades para cumplir esa fecha límite. La multa máxima del CRA es de 15 millones de euros o el 2,5% de la facturación anual global, lo que sea mayor.

NIS2 vs. DORA vs. CRA vs. CSA2: ¿Qué regulación le aplica?

El principio de lex specialis significa que las regulaciones sectoriales específicas tienen precedencia sobre las generales. Las entidades financieras sujetas a DORA están exentas de ciertas obligaciones de NIS2 donde DORA proporciona requisitos equivalentes o más estrictos. Las cuatro regulaciones pueden superponerse para grandes organizaciones que operan en múltiples sectores — un proveedor de nube que sirve a instituciones financieras mientras también fabrica hardware IoT puede enfrentar obligaciones bajo las cuatro simultáneamente.

Comparación de regulaciones

Matriz de decisión: ¿Le aplica esta regulación?

DORA requiere controles de acceso documentados y registros de auditoría para todas las cuentas de TIC privilegiadas. El intercambio seguro de credenciales y el registro de actividad de Passwork proporcionan a los equipos de cumplimiento la evidencia que solicitan los auditores.

Lista de verificación práctica de cumplimiento para primavera/verano 2026

Con el 62% de los incidentes cibernéticos de la UE en 2025 involucrando elusión de MFA y el 70% clasificados como Compromiso de Correo Electrónico Empresarial, las medidas técnicas más inmediatas están centradas en la identidad: imponer MFA en todas partes, auditar el acceso privilegiado y evaluar la exposición de credenciales de terceros. El cumplimiento regulatorio y la seguridad operativa apuntan a los mismos controles.

Acciones inmediatas (abril – junio 2026)

1. Complete el registro en BSI (Alemania) si aún no lo ha hecho. Contacte con BSI inmediatamente y documente el intento — incluso si ha pasado la fecha límite del 6 de marzo, el registro del esfuerzo de buena fe importa en los procedimientos de aplicación.
2. Realice un análisis de impacto de NIS2. Determine si su organización y sus subsidiarias, empresas conjuntas y proveedores críticos están bajo la clasificación de entidad esencial o importante de NIS2.
3. Establezca un proceso de notificación de incidentes de 24/72 horas. Asigne responsabilidad clara, cree plantillas de notificación y pruebe la ruta de escalamiento de extremo a extremo antes de que un incidente le obligue a usarla.
4. Imponga MFA en todos los accesos remotos y cuentas privilegiadas. Dado que el 62% de los incidentes clasificados de la UE involucraron elusión de MFA (Eye Security, 2026), este es el control de mayor retorno de inversión disponible.
5. Audite los proveedores de TIC terceros. DORA requiere obligaciones de seguridad contractuales para todos los proveedores de TIC críticos. NIS2 requiere evaluaciones de seguridad de la cadena de suministro. Ambas regulaciones exigen evidencia documentada de supervisión de terceros.
6. Implemente una política de gestión segura de credenciales. Centralice la gestión de contraseñas para cuentas privilegiadas para prevenir el vector de robo de credenciales utilizado en la brecha de ShinyHunters. Las credenciales compartidas no gestionadas siguen siendo el punto de entrada más común en casos de BEC y compromiso de cuentas en la nube.

Acciones a medio plazo (julio – septiembre 2026)

1. Prepárese para las obligaciones de notificación del CRA (efectivas el 11 de septiembre de 2026). Establezca un proceso de divulgación de vulnerabilidades, designe un punto de contacto para la notificación a ENISA y confirme que su inventario de productos refleja con precisión qué elementos califican como «productos digitales con elementos digitales».
2. Realice una prueba de resiliencia DORA. Como mínimo, ejecute un ejercicio de simulación. Las instituciones sistémicamente importantes deben planificar un TLPT completo con un equipo rojo cualificado operando contra inteligencia de amenazas actual.
3. Comience la evaluación de certificación CSA2. Identifique qué productos o servicios requerirán certificación obligatoria de ciberseguridad de la UE bajo CSA2 e involucre a un organismo notificado temprano — los plazos de certificación son largos.
4. Revise el cumplimiento del RGPD. El Conseil d'État francés confirmó una multa de 40 millones de euros del RGPD contra Criteo el 4 de marzo de 2026. Las multas totales del RGPD desde 2018 ahora superan los 7.100 millones de euros, con 1.200 millones de euros emitidos solo en 2025 (Kiteworks, marzo 2026). La aplicación de la protección de datos está en su máxima intensidad — trátelo como una vía paralela, no como un programa separado.

Conclusión

El contexto de amenazas y regulatorio están convergiendo. El entorno de ciberseguridad de la UE en primavera de 2026 está definido por el endurecimiento simultáneo de la regulación y la escalada de ataques. La brecha de la Comisión Europea y las primeras sanciones cibernéticas de la UE del año no son eventos aislados — son el contexto de aplicación para NIS2, DORA, CRA y CSA2.

La seguridad de identidad es la prioridad inmediata. El robo de credenciales mediante compromiso de cuentas en la nube es precisamente lo que el requisito de «medidas técnicas apropiadas» de NIS2 está diseñado para prevenir. Con el 62% de los incidentes de la UE en 2025 involucrando elusión de MFA, imponer MFA, auditar el acceso privilegiado y centralizar la gestión de credenciales son controles fundamentales — que simultáneamente reducen el riesgo de brechas y satisfacen los requisitos de NIS2, DORA y RGPD.

Las fechas límite son fijas. La fecha límite de notificación del CRA del 11 de septiembre de 2026 está a seis meses. Las auditorías de DORA están en curso. El registro de NIS2 en Alemania cerró el 6 de marzo. Las organizaciones que tratan el cumplimiento como un ejercicio de documentación en lugar de un programa de mejora de seguridad enfrentan tanto sanciones regulatorias como exposición operativa.

La suposición común en los cuatro marcos: las organizaciones mantienen control documentado y auditable sobre quién accede a qué credenciales, cuándo y por qué. Ese es el punto de partida para cualquier programa serio de cumplimiento — y la línea base contra la que los reguladores evaluarán.

Passwork es un gestor de contraseñas corporativo autoalojado con control de acceso basado en roles, registros de actividad detallados y cifrado de conocimiento cero — desplegado completamente dentro de su propia infraestructura. Aborda los controles de gestión de credenciales requeridos bajo NIS2, DORA y RGPD en un único sistema auditable. Pruebe Passwork gratis en su infraestructura

Preguntas frecuentes: Regulaciones de ciberseguridad de la UE en primavera 2026

¿Qué cambió en la legislación de ciberseguridad de la UE en primavera 2026?

La Comisión Europea propuso enmiendas a NIS2 y una nueva Ley de Ciberseguridad (CSA2) el 20 de enero de 2026. Las obligaciones de notificación del CRA comienzan el 11 de septiembre de 2026. DORA ha estado en aplicación activa desde enero de 2025. La UE también impuso sus primeras sanciones cibernéticas de 2026 el 16 de marzo, dirigidas contra actores de amenazas chinos e iraníes.

¿Cuál es la diferencia entre NIS2 y DORA?

NIS2 es una directiva amplia que cubre 18 sectores y se centra en la gestión de riesgos de ciberseguridad y la notificación de incidentes. DORA es un reglamento específico para el sector financiero, con requisitos más profundos para la gestión de riesgos de TIC, pruebas de resiliencia y supervisión de terceros. El principio de lex specialis significa que DORA tiene precedencia para entidades financieras donde sus requisitos son más estrictos que las obligaciones equivalentes de NIS2.

¿Cuáles son las sanciones por incumplimiento de NIS2 en 2026?

Las entidades esenciales enfrentan multas de hasta 10 millones de euros o el 2% de la facturación anual global, lo que sea mayor. Las entidades importantes enfrentan multas de hasta 7 millones de euros o el 1,4% de los ingresos globales. La ley de implementación de NIS2 de Alemania (§38 NIS2UmsuCG) también introduce responsabilidad personal para la dirección — una primicia en la legislación alemana de ciberseguridad.

¿Cuándo entra en vigor la Ley de Ciberresiliencia?

El CRA entró en vigor el 10 de diciembre de 2024. Las obligaciones de notificación de vulnerabilidades e incidentes comienzan el 11 de septiembre de 2026. Los requisitos completos de seguridad desde el diseño y las obligaciones de marcado CE se aplican a partir del 11 de diciembre de 2027. Las organizaciones que retrasen la preparación hasta finales de 2026 enfrentarán un plazo comprimido para la fecha límite de 2027.

¿Quién fue sancionado bajo las sanciones cibernéticas de la UE en marzo 2026?

El 16 de marzo de 2026, el Consejo de la UE sancionó a Integrity Technology Group y Anxun Information Technology (ambas con sede en China) y Emennet Pasargad (con sede en Irán), junto con dos individuos chinos. Las sanciones incluyen congelación de activos; los dos individuos también enfrentan prohibiciones de viaje. El régimen de sanciones cibernéticas de la UE ahora cubre un total de 19 individuos y 7 entidades.

¿Qué es la Ley de Ciberseguridad de la UE 2 (CSA2)?

CSA2 es la revisión propuesta de la Ley de Ciberseguridad de la UE, anunciada el 20 de enero de 2026. Amplía el mandato de ENISA e introduce la certificación obligatoria de ciberseguridad para productos y servicios de TIC utilizados en sectores críticos — reemplazando el marco de certificación voluntaria actual para esas categorías. Adopción esperada: finales de 2026 o 2027.

¿Se aplica NIS2 o DORA a los proveedores de nube?

Un proveedor de nube que suministra servicios críticos a instituciones financieras está bajo DORA como proveedor de TIC tercero. Si el mismo proveedor también opera en uno de los 18 sectores de NIS2 con los umbrales de tamaño relevantes, NIS2 se aplica de forma independiente. Las dos regulaciones pueden — y frecuentemente lo hacen — aplicarse simultáneamente a la misma organización.

¿Qué ocurrió en la brecha de datos de la Comisión Europea de 2026?

El 24 de marzo de 2026, atacantes accedieron a las cuentas de AWS en la nube de la Comisión Europea que alojaban la plataforma Europa.eu. El grupo de extorsión ShinyHunters se atribuyó la responsabilidad y alegó el robo de más de 350 GB de datos, incluyendo bases de datos, contratos y documentos confidenciales. La Comisión confirmó la brecha el 30 de marzo de 2026.

Requisitos de contraseñas de NIS2: Qué deben hacer las empresas europeas en 2026

Las brechas de credenciales son el principal punto de fallo en las auditorías de NIS2 en 2026. Esta guía cubre los requisitos de contraseñas del Artículo 21, la alineación con NIST SP 800-63B, los pasos de fortalecimiento de AD y la evidencia de auditoría que los reguladores solicitan primero.

Passwork BlogAlex Muntyan

Modelos de despliegue de gestores de contraseñas: Nube, autoalojado e híbrido

Elegir dónde ejecutar su gestor de contraseñas importa tanto como elegir cuál. Esta guía desglosa el despliegue en nube, autoalojado e híbrido — con una matriz de cumplimiento para RGPD, HIPAA y NIS2, y una visión clara de las compensaciones que conlleva cada modelo.

Passwork BlogAlex Muntyan

¿Qué es una passkey? Guía de autenticación sin contraseñas

Una passkey es una credencial resistente al phishing almacenada en su dispositivo. Inicie sesión con un toque biométrico — sin contraseña que recordar o robar. Esta guía cubre la mecánica técnica, la configuración de plataforma, los datos de rendimiento del mundo real y lo que significa la transición para los equipos empresariales.

Passwork BlogAlex Muntyan

Introduction

On March 24, 2026, attackers accessed the European Commission's AWS cloud accounts and exfiltrated over 350GB of data before being blocked.

The ShinyHunters extortion group claimed responsibility. The Commission confirmed the breach on March 30, making it the most significant EU institutional compromise of the year and a precise illustration of the threat environment in which four major EU cybersecurity regulations are now being enforced simultaneously.

Spring 2026 marks a convergence: the January 20 NIS2 amendments and CSA2 proposal, active DORA enforcement by national regulators, and the September 11 CRA reporting deadline approaching fast.

The EU also imposed its first cyber sanctions of the year on March 16, targeting Chinese and Iranian threat actors. These are not background events — they are the enforcement context every IT leader and compliance officer needs to understand now.

Key takeaways

• European Commission data breach confirmed: On March 30, 2026, ShinyHunters stole over 350GB from its AWS cloud accounts, including databases, contracts, and mail server dumps.
• First EU cyber sanctions of 2026: On March 16, the EU Council imposed restrictive measures against three entities — Integrity Technology Group, Anxun Information Technology (China), and Emennet Pasargad (Iran) — and two individuals.
• NIS2 and CSA2 amendments proposed: On January 20, 2026, the European Commission introduced changes clarifying jurisdiction, scope, and certification obligations across both frameworks.
• CRA reporting deadline approaching: Mandatory vulnerability and incident reporting obligations under the Cyber Resilience Act begin September 11, 2026.
• DORA enforcement is active: Fully applicable since January 17, 2025, with BaFin and other national regulators conducting audits throughout 2026.

The threat context that made these changes necessary

The Spring 2026 EU regulatory acceleration is a direct response to a documented surge in attacks on European institutions and critical infrastructure. The European Commission breach, the EU's first cyber sanctions of 2026, and the statistical picture from ENISA and independent incident responders all point in the same direction: the threat is real, targeted, and ongoing.

The European Commission breach (March 2026)

The March 24 attack on the Commission's AWS-hosted Europa.eu platform is the clearest recent example of cloud supply chain risk. ShinyHunters — the same extortion group behind multiple high-profile data theft campaigns — claimed to have taken over 350GB of data: mail server dumps, databases, confidential documents, and contracts.

A 90GB archive appeared on their dark web leak site. The Commission's internal systems were not affected, but the incident exposed a structural vulnerability: public-facing cloud infrastructure operated without the access controls and credential hygiene that NIS2 and DORA are designed to mandate.

"Early findings of our ongoing investigation suggest that data have been taken from those websites. The Commission's internal systems were not affected by the cyber-attack." — European Commission Press Release, March 27, 2026

This was the Commission's second breach in 2026. A February incident had already compromised the mobile device management platform used to manage staff devices. Two significant breaches in two months at a single institution is not a coincidence — it reflects a sustained targeting campaign.

EU cyber sanctions — March 16, 2026

On March 16, 2026, the EU Council imposed restrictive measures against three entities and two individuals under the EU's cyber diplomacy toolbox — the first EU cyber sanctions of the year.

The sanctioned parties:

• Integrity Technology Group (China): Provided products used to compromise over 65,000 devices across six EU member states between 2022 and 2023.
• Anxun Information Technology (China): Provided hacking services targeting EU critical infrastructure. Two co-founders were individually sanctioned.
• Emennet Pasargad (Iran): Breached a French subscriber database, compromised advertising billboards during the 2024 Paris Olympics to spread disinformation, and compromised a Swedish SMS service.

All listed entities face asset freezes. The two individuals also face travel bans. The EU cyber sanctions regime now covers 19 individuals and 7 entities.

The statistical backdrop

According to the ENISA Threat Landscape 2025 report, DDoS attacks accounted for 77% of all recorded EU cyber incidents, driven primarily by hacktivist groups. Ransomware remains the most operationally damaging threat: 81.1% of cybercrime incidents targeting EU organizations involved ransomware.

Public administration was the most targeted sector, representing 38% of all incidents. State-aligned groups intensified long-term espionage campaigns against telecommunications, logistics, and manufacturing.

The picture from incident responders on the ground is equally direct. Eye Security's 2026 incident report — based on 630 investigations across Benelux and Germany — found that 70% of all cases were Business Email Compromise (BEC). More telling: 62% of classified cases since January 2025 involved MFA bypass. Attackers are not breaking encryption — they are stealing or bypassing credentials. That is the vector NIS2, DORA, and GDPR enforcement are all designed to close.

The European Commission breach followed a well-documented pattern: compromised cloud credentials, no audit trail, no access boundaries. Passwork gives IT teams a structured vault with role-based access, granular permissions, and a full activity log — the controls NIS2 and DORA explicitly require. Try Passwork free

NIS2 amendments: What changed on January 20, 2026

On January 20, 2026, the European Commission proposed amendments to NIS2 focused on legal certainty, streamlined compliance, and clarified jurisdictional rules. The proposal also introduced a revised Cybersecurity Act (CSA2) that expands ENISA's mandate and moves toward mandatory cybersecurity certification for products and services used in critical sectors.

The three practical changes in NIS2

The amendments address three pain points that emerged during the first year of implementation across member states:

1. Jurisdictional clarity. The amendments specify which member state holds supervisory authority over cross-border entities — a major source of compliance uncertainty for multinational organizations operating in multiple EU jurisdictions simultaneously.
2. Ransomware data collection. The proposal standardizes the collection of ransomware-related incident data across member states, enabling more consistent threat intelligence sharing at the EU level.
3. Scope refinement. A new "small mid-cap" category adjusts the thresholds determining whether organizations fall under NIS2's essential or important entity classification.

CSA2: The more significant structural shift

The CSA2 revision expands both the material and subjective scope of the EU cybersecurity framework. The critical change: certification for ICT products and services used in critical sectors moves from voluntary to mandatory. Organizations that have relied on the current voluntary ENISA certification schemes will need to reassess their product portfolios and supplier contracts once CSA2 is adopted — expected late 2026 or 2027.

Germany: NIS2 implementation is already in force

Germany's NIS2 implementation law (NIS2UmsuCG) entered into force on December 6, 2025. The BSI registration deadline was March 6, 2026. Approximately 30,000 companies in Germany fall under NIS2. A survey by nis2-check.de found that 80% of affected companies were unaware of their obligations (ADVISORI, February 2026). The law introduces personal liability for management under §38 NIS2UmsuCG — a first in German cybersecurity law.

NIS2 incident reporting requirements

DORA: Enforcement begins in 2026

DORA (Regulation EU 2022/2554) has been directly applicable since January 17, 2025. There is no national implementation law required and no postponement possible. In 2026, national regulators including Germany's BaFin are conducting active audits of financial institutions and their ICT third-party providers.

Who DORA covers

DORA applies to the entire financial sector: credit institutions, insurance companies, investment firms, payment service providers, crypto-asset service providers, and — critically — the ICT third-party providers supplying critical services to these entities.

A cloud provider hosting core banking systems falls under DORA as an ICT third-party provider, as does the bank itself. The regulation's reach extends well beyond traditional financial services.

The five compliance pillars

DORA organizes its requirements around five areas: ICT risk management, incident reporting, digital operational resilience testing, third-party risk management, and information sharing.

The most demanding requirement is Threat-Led Penetration Testing (TLPT) — mandatory for systemically important institutions. TLPT requires specialized red teams to simulate real attack scenarios based on current threat intelligence, not generic penetration testing methodologies.

Compliance gaps remain significant

Despite DORA being in force for over a year, readiness across the sector is incomplete. A Veeam survey found that 96% of EMEA financial organizations believe they need to improve their resilience to meet DORA requirements.

A Computerwoche survey found that 44% of affected companies report significant implementation problems. Specific gaps: 24% have not identified a DORA implementation lead, and 23% have not conducted digital operational resilience testing.

These numbers mean BaFin auditors are walking into organizations that have not completed basic readiness steps — with enforcement consequences that include license revocation, not just fines.

Cyber Resilience Act: The September 2026 deadline

The Cyber Resilience Act entered into force on December 10, 2024. From September 11, 2026, manufacturers and importers of digital products must report actively exploited vulnerabilities and severe incidents to ENISA within 24 hours. Full CRA requirements — including security-by-design obligations — apply from December 11, 2027.

What the September 2026 milestone covers

Two specific obligations activate on September 11:

• Vulnerability reporting: Manufacturers must report actively exploited vulnerabilities to ENISA within 24 hours of becoming aware of them.
• Incident reporting: Severe incidents with an impact on the security of digital products must also be reported to ENISA within 24 hours.

The full CRA requirements — security by design, software bill of materials (SBOM), ongoing vulnerability management, and CE marking for digital products — apply from December 2027. Organizations that have not started preparation by mid-2026 will struggle to meet that deadline. The maximum CRA fine is €15 million or 2.5% of global annual turnover, whichever is higher.

NIS2 vs. DORA vs. CRA vs. CSA2: Which regulation applies to you?

The lex specialis principle means that sector-specific regulations take precedence over general ones. Financial entities subject to DORA are exempt from certain NIS2 obligations where DORA provides equivalent or stricter requirements. All four regulations can overlap for large organizations operating across sectors — a cloud provider serving financial institutions while also manufacturing IoT hardware may face obligations under all four simultaneously.

Regulation comparison

Decision matrix: Does this regulation apply to you?

DORA requires documented access controls and audit trails for all privileged ICT accounts. Passwork's secure credential sharing and activity logging give compliance teams the evidence trail auditors ask for.

Practical compliance checklist for Spring/Summer 2026

With 62% of EU cyber incidents in 2025 involving MFA bypass and 70% classified as Business Email Compromise, the most immediate technical measures are identity-focused: enforce MFA everywhere, audit privileged access, and assess third-party credential exposure. Regulatory compliance and operational security point to the same controls.

Immediate actions (April – June 2026)

1. Complete BSI registration (Germany) if not yet done. Contact BSI immediately and document the attempt — even if the March 6 deadline has passed, the record of good-faith effort matters in enforcement proceedings.
2. Conduct a NIS2 impact analysis. Determine whether your organization and its subsidiaries, joint ventures, and critical suppliers fall under NIS2's essential or important entity classification.
3. Establish a 24/72-hour incident reporting process. Assign clear ownership, create notification templates, and test the escalation path end-to-end before an incident forces you to use it.
4. Enforce MFA across all remote access and privileged accounts. Given that 62% of classified EU incidents involved MFA bypass (Eye Security, 2026), this is the single highest-ROI control available.
5. Audit third-party ICT providers. DORA requires contractual security obligations for all critical ICT suppliers. NIS2 requires supply chain security assessments. Both regulations demand documented evidence of third-party oversight.
6. Implement a secure credential management policy. Centralize password management for privileged accounts to prevent the credential theft vector used in the ShinyHunters breach. Unmanaged shared credentials remain the most common entry point in BEC and cloud account compromise cases.

Mid-term actions (July – September 2026)

1. Prepare for CRA reporting obligations (effective September 11, 2026). Establish a vulnerability disclosure process, designate a contact point for ENISA reporting, and confirm that your product inventory accurately reflects which items qualify as "digital products with digital elements."
2. Conduct a DORA resilience test. At minimum, run a tabletop exercise. Systemically important institutions must plan for full TLPT with a qualified red team operating against current threat intelligence.
3. Begin CSA2 certification assessment. Identify which products or services will require mandatory EU cybersecurity certification under CSA2 and engage a notified body early — certification timelines are long.
4. Review GDPR compliance. The French Conseil d'État upheld a €40 million GDPR fine against Criteo on March 4, 2026. Total GDPR fines since 2018 now exceed €7.1 billion, with €1.2 billion issued in 2025 alone (Kiteworks, March 2026). Data protection enforcement is at peak intensity — treat it as a parallel track, not a separate program.

Conclusion

The threat and regulatory context are converging. The Spring 2026 EU cybersecurity environment is defined by simultaneous tightening of regulation and escalation of attacks. The European Commission breach and the EU's first cyber sanctions of the year are not isolated events — they are the enforcement context for NIS2, DORA, CRA, and CSA2.

Identity security is the immediate priority. Credential theft via cloud account compromise is precisely what NIS2's "appropriate technical measures" requirement is designed to prevent. With 62% of EU incidents in 2025 involving MFA bypass, enforcing MFA, auditing privileged access, and centralizing credential management are foundational controls — ones that simultaneously reduce breach risk and satisfy requirements across NIS2, DORA, and GDPR.

The deadlines are fixed. The September 11, 2026 CRA reporting deadline is six months away. DORA audits are underway. NIS2 registration in Germany closed on March 6. Organizations that treat compliance as a documentation exercise rather than a security improvement program face both regulatory penalties and operational exposure.

The common assumption across all four frameworks: organizations maintain documented, auditable control over who accesses what credentials, when, and why. That is the starting point for any serious compliance program — and the baseline regulators will test against.

Passwork is a self-hosted corporate password manager with role-based access control, detailed activity logs, and zero-knowledge encryption — deployed entirely within your own infrastructure. It addresses the credential management controls required under NIS2, DORA, and GDPR in a single, auditable system. Try Passwork free in your infrastructure

FAQ: EU cybersecurity regulations in Spring 2026

What changed in EU cybersecurity law in Spring 2026?

The European Commission proposed amendments to NIS2 and a new Cybersecurity Act (CSA2) on January 20, 2026. The CRA's reporting obligations begin September 11, 2026. DORA has been in active enforcement since January 2025. The EU also imposed its first cyber sanctions of 2026 on March 16, targeting Chinese and Iranian threat actors.

What is the difference between NIS2 and DORA?

NIS2 is a broad directive covering 18 sectors and focusing on cybersecurity risk management and incident reporting. DORA is a regulation specific to the financial sector, with deeper requirements for ICT risk management, resilience testing, and third-party oversight. The lex specialis principle means DORA takes precedence for financial entities where its requirements are stricter than NIS2's equivalent obligations.

What are the penalties for NIS2 non-compliance in 2026?

Essential entities face fines of up to €10 million or 2% of global annual turnover, whichever is higher. Important entities face fines of up to €7 million or 1.4% of global revenue. Germany's NIS2 implementation law (§38 NIS2UmsuCG) also introduces personal liability for management — a first in German cybersecurity law.

When does the Cyber Resilience Act take effect?

The CRA entered into force on December 10, 2024. Mandatory vulnerability and incident reporting obligations begin September 11, 2026. Full security-by-design requirements and CE marking obligations apply from December 11, 2027. Organizations that delay preparation until late 2026 will face a compressed timeline for the 2027 deadline.

Who was sanctioned under EU cyber sanctions in March 2026?

On March 16, 2026, the EU Council sanctioned Integrity Technology Group and Anxun Information Technology (both China-based) and Emennet Pasargad (Iran-based), along with two Chinese individuals. Sanctions include asset freezes; the two individuals also face travel bans. The EU cyber sanctions regime now covers 19 individuals and 7 entities total.

What is the EU Cybersecurity Act 2 (CSA2)?

CSA2 is the proposed revision to the EU Cybersecurity Act, announced January 20, 2026. It expands ENISA's mandate and introduces mandatory cybersecurity certification for ICT products and services used in critical sectors — replacing the current voluntary certification framework for those categories. Expected adoption: late 2026 or 2027.

Does NIS2 or DORA apply to cloud providers?

A cloud provider supplying critical services to financial institutions falls under DORA as an ICT third-party provider. If the same provider also operates in one of NIS2's 18 sectors with the relevant size thresholds, NIS2 applies independently. The two regulations can — and frequently do — apply simultaneously to the same organization.

What happened in the European Commission data breach of 2026?

On March 24, 2026, attackers accessed the European Commission's AWS cloud accounts hosting the Europa.eu platform. The ShinyHunters extortion group claimed responsibility and alleged theft of over 350GB of data, including databases, contracts, and confidential documents. The Commission confirmed the breach on March 30, 2026.

NIS2 password requirements: What European companies must do in 2026

Credential gaps are the leading NIS2 audit failure point in 2026. This guide covers Article 21 password requirements, NIST SP 800-63B alignment, AD hardening steps, and the audit evidence regulators ask for first.

Passwork BlogAlex Muntyan

Password Manager Deployment Models: Cloud, Self-Hosted & Hybrid

Choosing where to run your password manager matters as much as choosing which one. This guide breaks down cloud, self-hosted, and hybrid deployment — with a compliance matrix for GDPR, HIPAA, and NIS2, and a clear look at the trade-offs each model carries.

Passwork BlogAlex Muntyan

What is a passkey? Guide to passwordless authentication

A passkey is a phishing-resistant credential stored on your device. Sign in with a biometric tap — no password to remember or steal. This guide covers the technical mechanics, platform setup, real-world performance data, and what the transition means for enterprise teams.

Passwork BlogAlex Muntyan

Introduction

If you had to explain the difference between XDR and MDR in a vendor meeting right now, without checking your notes — what would you say?

Cybercrime is projected to cost the global economy $10.5 trillion annually by 2026. A significant share of that damage traces back to misconfigured tools, misapplied policies, and decisions made without full context. The terminology is where the gaps begin.

This cybersecurity glossary for 2026 covers the terms that matter — Zero Trust, PAM, XDR, CTEM, DSPM, PQC — organized by business function, not alphabetically. Every definition includes the business context that vendor datasheets leave out.

Key takeaways

• IAM vs. PAM: IAM governs all user access; PAM specifically secures privileged (admin-level) accounts — the higher-value target.
• EDR vs. XDR vs. MDR: EDR covers endpoints; XDR extends visibility across the full environment; MDR is a managed service where a vendor's team runs either.
• SIEM vs. SOAR: SIEM aggregates and correlates logs to surface alerts; SOAR automates the response workflows those alerts trigger.
• CTEM and DSPM are the two 2026 terms appearing most frequently in board-level security conversations — both are covered in full below.
• Shadow AI and PQC are no longer future concerns. Both require policy decisions now.

Identity and access management

Identity is the new perimeter. With the average cost of a data breach reaching $4.44 million in 2025, the majority of incidents involve compromised credentials — making this category the foundation of any security program.

• IAM (Identity and Access Management) — the overarching framework for managing who can access which resources, under what conditions. IAM covers authentication, authorization, and the lifecycle of user accounts across the organization. Every other term in this section is a subset or extension of IAM.
• PAM (Privileged Access Management) — a specialized discipline within IAM focused on accounts with elevated permissions: domain admins, root users, service accounts. A single compromised admin credential gives an attacker full control over infrastructure. PAM tools enforce session recording, just-in-time access, and credential vaulting for these accounts. For a detailed breakdown, see the Passwork guide on privileged access management.
• Zero Trust — an architecture principle, not a product. The core rule: every access request is verified regardless of origin, including requests from inside the corporate network. Zero Trust requires MFA, least-privilege access, and continuous session monitoring. Vendors sell "Zero Trust solutions" — what they mean is tools that help implement the principle.
• MFA (Multi-Factor Authentication) and passkeys — MFA requires a second verification factor beyond a password. Passkeys go further: they replace passwords entirely with cryptographic key pairs stored on the user's device, making phishing structurally impossible. The shift toward passkeys is accelerating as FIDO2/WebAuthn adoption grows across enterprise platforms.
• SSO (Single Sign-On) — a mechanism that lets users authenticate once — typically against a central identity provider (IdP) such as Okta, Azure AD, or Google Workspace — and access multiple applications without re-entering credentials. When combined with MFA, it reduces the number of authentication entry points an attacker can target — instead of dozens of app-level logins, there is one.
• RBAC (Role-Based Access Control) — assigns permissions based on job role rather than individual identity. A finance analyst gets access to finance systems; a developer gets access to code repositories. RBAC is the standard model for enforcing least privilege at scale.
• ABAC (Attribute-Based Access Control) — a access control model that grants permissions based on attributes — properties of the user (role, department, clearance level), the resource (classification, owner, type), and the environment (time of day, location, device state). Unlike RBAC, which assigns permissions to roles, ABAC evaluates a combination of attributes against a policy at the moment of each access request.

Threat detection and incident response

EDR, XDR, and MDR are the three most-searched confusing acronyms in cybersecurity. Here is the direct answer: EDR monitors endpoints, XDR extends that visibility across network, cloud, and email, MDR is a managed service where a third-party team operates EDR or XDR on your behalf. The distinction matters when you're evaluating vendors.

• EDR (Endpoint Detection and Response) — monitors laptops, servers, and workstations for malicious behavior in real time. EDR tools detect threats that signature-based antivirus misses — fileless attacks, lateral movement, living-off-the-land techniques. The internal security team manages it.
• XDR (Extended Detection and Response) — extends EDR's visibility across the full environment: network traffic, cloud workloads, email, and identity systems. XDR correlates signals from multiple sources to surface multi-stage attacks that would appear as isolated anomalies in siloed tools.
• MDR (Managed Detection and Response) — EDR or XDR delivered as a managed service. The vendor's analysts handle detection, triage, and initial response. MDR is the answer for organizations that lack the internal headcount to staff a 24/7 SOC — a real constraint given the 4.8 million professional shortage in the global cybersecurity workforce.
• SIEM (Security Information and Event Management) — aggregates and correlates logs from every system in the environment: firewalls, endpoints, identity providers, cloud platforms. SIEM surfaces anomalies and generates alerts. It does not act on them.
• SOAR (Security Orchestration, Automation, and Response) — automates the response workflows that SIEM alerts trigger. When SIEM flags a suspicious login, SOAR can automatically disable the account, notify the analyst, and open a ticket — without human intervention. SIEM detects; SOAR acts.
• SOC (Security Operations Center) — the team, internal or outsourced, that monitors SIEM alerts, investigates incidents, and coordinates response. A SOC without SOAR automation is a team drowning in alerts.
• DevSecOps — a development practice that integrates security controls directly into the CI/CD pipeline rather than treating them as a separate phase after deployment. Static code analysis, dependency scanning, secrets detection, and container image checks run automatically at each stage of the build. The goal is to catch vulnerabilities at the point where they are cheapest to fix — in the code, before it reaches production.
• TTP (Tactics, Techniques, and Procedures) — the behavioral fingerprint of a threat actor. TTPs describe how attackers operate, mapped to frameworks like MITRE ATT&CK. Sharing TTP intelligence between organizations is the foundation of threat intelligence programs.

Cloud security and data posture

Cloud environments dissolve the traditional network boundary. The terms in this section address how organizations protect data that lives outside their own data centers — and increasingly, data they didn't know they had.

• CNAPP (Cloud-Native Application Protection Platform) — unifies cloud workload protection, container security, infrastructure-as-code scanning, and API security into a single platform. CNAPP replaces the previous generation of point tools (CSPM + CWPP) with an integrated view of cloud risk.
• DSPM (Data Security Posture Management) — one of the defining security priorities of 2025–2026. DSPM discovers, classifies, and assesses risk for data across cloud and hybrid environments — including shadow data that organizations didn't know existed. Where CSPM asks "is the infrastructure configured securely?", DSPM asks "where is sensitive data, and who can reach it?"
• CASB (Cloud Access Security Broker) — the security checkpoint between users and cloud services like Microsoft 365, Google Workspace, or Salesforce. CASB enforces data policies, detects anomalous access, and provides visibility into shadow IT application usage.
• DLP (Data Loss Prevention) — monitors and blocks sensitive data from leaving the organization through email, file uploads, USB transfers, or cloud sync. DLP is the enforcement layer; DSPM is the discovery and classification layer.
• CIEM (Cloud Infrastructure Entitlement Management) — manages and right-sizes permissions in cloud environments, where over-provisioned IAM roles are one of the most common misconfigurations. CIEM identifies which identities have access to what cloud resources — and flags permissions that exceed what's actually needed.

Emerging threats and AI security — the 2026 additions

87% of security leaders identify AI-related vulnerabilities as the fastest-growing cyber threat in 2026, according to the WEF Global Cybersecurity Outlook. The terms below are already appearing in board-level conversations and vendor pitches. Understanding them now prevents expensive course corrections later.

• CTEM (Continuous Threat Exposure Management) — a five-stage framework coined by Gartner in 2022 for continuously discovering, prioritizing, and remediating exposure across the attack surface. CTEM replaces point-in-time penetration tests — which leave organizations exposed between assessments — with an ongoing process of scoping, discovery, prioritization, validation, and mobilization. Gartner projects that organizations with CTEM programs will suffer two-thirds fewer breaches by 2026.
• Shadow AI — the unsanctioned use of generative AI tools (ChatGPT, Microsoft Copilot, Google Gemini) by employees without IT approval or governance. Sensitive data entered into consumer AI tools may be used for model training, retained by the vendor, or exposed in data leaks. 97% of organizations that reported an AI-related security incident lacked proper AI access controls or governance policies, per IBM's 2025 Cost of a Data Breach Report. Shadow AI is the 2026 equivalent of shadow IT — and requires the same policy response.
• LLM Security — the discipline of securing large language model deployments against prompt injection attacks, training data leakage, and model poisoning. As organizations deploy AI-powered tools internally, LLM security becomes an operational concern, not a research topic.
• MCP (Model Context Protocol) — an open standard developed by Anthropic for how AI agents interact with external systems, tools, and data sources. Organizations deploying AI-powered security tools or autonomous agents need to understand MCP as the emerging integration layer — and the new attack surface it introduces.
• PQC (Post-Quantum Cryptography) — cryptographic algorithms designed to resist attacks from quantum computers, which would break current RSA and ECC encryption. NIST finalized the first PQC standards in 2024 (FIPS 203, 204, 205). Organizations don't need to panic — but they do need to begin a cryptographic inventory: identifying which systems rely on vulnerable algorithms and planning migration timelines.
• QKD (Quantum Key Distribution) — a method of distributing encryption keys using quantum mechanical properties, making interception detectable. QKD is a complementary approach to PQC, currently deployed in high-security government and financial contexts.

Compliance and governance

Security frameworks and regulations drive purchasing decisions, audit requirements, and board-level reporting. Knowing the acronyms prevents compliance theater — checkbox activity that satisfies auditors without reducing actual risk.

• GRC (Governance, Risk, and Compliance) — the integrated framework for aligning security programs with business objectives and regulatory obligations. GRC platforms aggregate risk data, track control effectiveness, and generate audit evidence across multiple frameworks simultaneously.
• NIST CSF (NIST Cybersecurity Framework) — the U.S. government's voluntary framework for managing cybersecurity risk, organized around six functions: Identify, Protect, Detect, Respond, Recover, and Govern.
• ISO 27001 — the international standard for information security management systems (ISMS). Certification requires documented policies, risk assessments, and evidence of control implementation. ISO 27001 is the baseline credential for enterprise security programs operating across multiple jurisdictions.
• SOC 2 — an audit standard for service organizations demonstrating that security, availability, and confidentiality controls meet AICPA Trust Service Criteria. SOC 2 Type II reports cover a period of time (typically 6–12 months), not a point-in-time snapshot. Relevant for any SaaS vendor or cloud provider handling customer data.
• NIS2 — the EU's updated Network and Information Security Directive, effective October 2024. NIS2 expands compliance obligations to 18 sectors (up from 7 under NIS1), introduces direct liability for C-level executives, and mandates 24-hour incident reporting to national authorities. Organizations operating in the EU that haven't assessed their NIS2 obligations are already behind.
• GDPR / HIPAA — the two most-referenced data protection regulations. GDPR (General Data Protection Regulation) governs personal data handling for EU residents globally. HIPAA (Health Insurance Portability and Accountability Act) governs protected health information in the U.S. Both carry significant financial penalties and require documented access controls, breach notification procedures, and data minimization practices.

Conclusion

Knowing the terminology is the foundation — but the real work is implementation. The terms in this cybersecurity glossary for 2026 map directly to decisions: which tools to buy, which frameworks to adopt, which risks to prioritize in the next budget cycle.

The credential layer sits at the intersection of IAM, PAM, and Zero Trust — and it's where most breaches begin. Passwork addresses this layer directly: a self-hosted password manager with role-based access control, full audit logs, and zero-knowledge encryption, deployed entirely within your own infrastructure. For organizations with strict data sovereignty requirements, the self-hosted deployment model keeps all credential data under your control, with no dependency on third-party cloud services.

Frequently asked questions

What is the difference between EDR, MDR, and XDR?

EDR monitors endpoints for threats and is managed by the internal security team. XDR extends that visibility across network, cloud, email, and identity systems, correlating signals into a unified view. MDR is a managed service where a third-party vendor's analysts operate EDR or XDR on your behalf, handling detection and initial response.

Why is PAM considered more critical than standard IAM?

PAM secures privileged accounts — admin credentials that grant full control over infrastructure. A single compromised admin account can enable complete network takeover, ransomware deployment, or data exfiltration at scale. Standard IAM governs all users; PAM governs the accounts where a breach causes maximum damage.

What does Zero Trust mean in practice?

Zero Trust means every access request is verified regardless of where it originates — including requests from inside the corporate network. In practice, implementation requires MFA on all accounts, least-privilege access policies, network microsegmentation, and continuous monitoring of active sessions for anomalous behavior.

What is CTEM and why is Gartner pushing it?

CTEM (Continuous Threat Exposure Management) is a five-stage framework for continuously assessing and reducing an organization's attack surface. Gartner recommends it because annual penetration tests leave organizations exposed for months between assessments. CTEM turns exposure management into an ongoing operational process rather than a periodic event.

What is Shadow AI and why is it a security risk?

Shadow AI refers to employees using generative AI tools — ChatGPT, Copilot, Gemini — without IT approval or data governance controls. Sensitive business data entered into consumer AI platforms may be retained, used for training, or exposed in breaches. IBM's 2025 data shows 97% of organizations with AI-related incidents lacked proper AI access controls.

What is the difference between SIEM and SOAR?

SIEM aggregates logs from all systems and correlates them to surface security alerts. SOAR automates the response actions those alerts require — disabling accounts, blocking IPs, creating tickets, notifying analysts. SIEM is the detection layer; SOAR is the response layer. Most modern security programs need both.

Is PQC something organizations need to worry about now?

Yes — not to deploy immediately, but to plan. NIST finalized the first post-quantum cryptography standards in 2024. Organizations should conduct a cryptographic inventory now: identify systems relying on RSA or ECC encryption and assess migration complexity. Quantum computers capable of breaking current encryption are not imminent, but migration timelines are long.

Password Manager Deployment Models: Cloud, Self-Hosted & Hybrid

Choosing where to run your password manager matters as much as choosing which one. This guide breaks down cloud, self-hosted, and hybrid deployment — with a compliance matrix for GDPR, HIPAA, and NIS2, and a clear look at the trade-offs each model carries.

Passwork BlogAlex Muntyan

What is a passkey? Guide to passwordless authentication

A passkey is a phishing-resistant credential stored on your device. Sign in with a biometric tap — no password to remember or steal. This guide covers the technical mechanics, platform setup, real-world performance data, and what the transition means for enterprise teams.

Passwork BlogAlex Muntyan

Five ways to make users love password security

Users don’t resist security — they resist friction. Five evidence-based strategies to update your password policy, drive password manager adoption, and build a security culture employees actually follow.

Passwork BlogAlex Muntyan

Einleitung

Die meisten Organisationen verbringen Wochen damit, zu evaluieren, welchen Passwort-Manager sie kaufen sollen — und einen Nachmittag damit, zu entscheiden, wo sie ihn betreiben. Das ist das falsche Verhältnis.

Das Bereitstellungsmodell bestimmt, ob Ihre Anmeldedaten einem Sicherheitsvorfall beim Anbieter unterliegen, ob Ihre Infrastruktur die DSGVO ohne zusätzliche rechtliche Mechanismen erfüllt und ob Ihr Team das, was es aufgebaut hat, realistisch warten kann. Zwei Organisationen können identische Software betreiben und völlig unterschiedliche Sicherheitslagen haben — weil die eine Cloud und die andere Self-hosted gewählt hat.

Das Ausmaß des Problems verdeutlicht die Tragweite. Sechzehn Milliarden Passwörter wurden in einem einzigen Datenkompilierungsvorfall im Juni 2025 offengelegt — eine Zahl, die Anmeldedatensicherheit als Infrastrukturproblem neu definiert, nicht als Problem des Benutzerverhaltens. Laut globalen Cybersicherheitsbewertungen im Jahr 2025 beinhalten 74 % der Sicherheitsvorfälle gestohlene, schwache oder geleakte Anmeldedaten.

Ein Passwort-Manager ist die naheliegende Antwort. Aber das Bereitstellungsmodell, das Sie wählen — Cloud, Self-hosted oder Hybrid — prägt alles, was folgt: wo Ihre Daten liegen, wer sie kontrolliert, welche Compliance-Frameworks Sie erfüllen können und was Ihr Team für die Wartung aufwenden wird.

Dieser Leitfaden bietet ein konkretes Framework für diese architektonische Entscheidung.

Wichtigste Erkenntnisse

• Das Bereitstellungsmodell ist eine architektonische Entscheidung. Cloud, Self-hosted und Hybrid optimieren jeweils für unterschiedliche Prioritäten. Die falsche Wahl erzeugt Compliance-Lücken, die teuer zu beheben sind.
• Zero-Knowledge-Verschlüsselung ist eine Grundvoraussetzung, kein Differenzierungsmerkmal. Die Bereitstellungsentscheidung bestimmt, wer den Server kontrolliert, der den Chiffretext speichert — und wer verantwortlich ist, wenn er kompromittiert wird.
• Cloud tauscht Kontrolle gegen Komfort. Vom Anbieter verwaltete Infrastruktur bedeutet, dass ein Sicherheitsvorfall auf Anbieterebene alle Kunden gleichzeitig betrifft.
• Self-hosted tauscht Komfort gegen Kontrolle. Anmeldedaten verlassen niemals Ihre Infrastruktur. Die operative Last — Patching, Hochverfügbarkeit, Backups — liegt vollständig bei Ihrem Team.
• Hybrid umfasst vier verschiedene Muster, nicht eines. Aufteilung nach Sensibilität, dezentrale Synchronisation, geteilte Steuerungsebene und Failover-Architektur haben jeweils unterschiedliche Sicherheitsimplikationen.
• Vorschriften schreiben Kontrollen vor, keine Bereitstellungsmodelle. DSGVO und NIS2 können jeweils durch mehr als eine Architektur erfüllt werden — aber einige Modelle machen die Compliance-Nachweise deutlich einfacher.
• Rotieren Sie alle Anmeldedaten nach der Migration. Das ist der Schritt, den die meisten Organisationen überspringen — und der wichtigste, wenn Sie von einem Cloud-Tresor migrieren.

Passwort-Manager-Architekturen verstehen

Das Kernkonzept der Zero-Knowledge-Verschlüsselung

Zero-Knowledge-Verschlüsselung ist eine Sicherheitsarchitektur, bei der alle Ver- und Entschlüsselungsvorgänge ausschließlich auf dem Gerät des Benutzers stattfinden — was bedeutet, dass der Server nur Chiffretext empfängt, speichert und überträgt und keine kryptografische Möglichkeit hat, die zugrunde liegenden Daten zu lesen.

Bevor Bereitstellungsmodelle verglichen werden, lohnt es sich festzustellen, was sie gemeinsam haben. Unternehmenstaugliche Passwort-Manager — unabhängig davon, wo der Tresor liegt — setzen auf Zero-Knowledge-Architektur. Ver- und Entschlüsselung erfolgen auf Geräteebene, unter Verwendung von Algorithmen wie AES-256. Der Server, ob er sich im Rechenzentrum eines Anbieters oder in Ihrem eigenen Rack befindet, speichert nur Chiffretext. Selbst der Anbieter kann Ihre Anmeldedaten nicht lesen.

Dies ist für die Bereitstellungsentscheidung wichtig, weil die Zero-Knowledge-Architektur die Sicherheitsfrage von „Ist der Server vertrauenswürdig?" hin zu „Wer kontrolliert den Server, und was passiert, wenn er kompromittiert wird?" verschiebt. Die Antwort auf diese Frage unterscheidet sich erheblich zwischen den drei Modellen.

Die drei primären Bereitstellungsmodelle

Cloud-Bereitstellung bedeutet, dass der Anbieter den verschlüsselten Passwort-Tresor auf seiner Infrastruktur hostet und verwaltet. Self-hosted-Bereitstellung bedeutet, dass die Organisation den Tresor auf ihren eigenen Servern oder in einer privaten Cloud betreibt. Hybrid-Bereitstellung kombiniert Elemente von beiden — typischerweise werden Datenspeicherung, Synchronisation oder administrative Kontrolle auf Cloud- und On-Premise-Komponenten aufgeteilt.

Die Wahl beeinflusst die Datenresidenz (wo Anmeldedaten physisch liegen), die organisatorische Kontrolle (wer Zugriff und Patching verwaltet) und die Wartungsverantwortung (wer reagiert, wenn etwas ausfällt). Jedes Modell optimiert für unterschiedliche Prioritäten.

Cloud-basierte Passwort-Manager-Bereitstellung

Architektur und Mechanik

Cloud-basierte Bereitstellung ist ein Modell, bei dem der Anbieter die gesamte Server-Infrastruktur besitzt und betreibt — er hostet den verschlüsselten Passwort-Tresor, verwaltet die Verfügbarkeit und übernimmt die gesamte Backend-Wartung im Auftrag der Organisation.

In der Praxis verwaltet der Anbieter den gesamten Stack: Server, Load Balancer, Backups und Verfügbarkeitszonen. Die Organisation installiert Client-Anwendungen — Browser-Erweiterungen, Desktop-Apps, mobile Clients — die sich mit der API des Anbieters verbinden. Anmeldedaten werden lokal verschlüsselt, bevor sie übertragen werden, und als Chiffretext in der Umgebung des Anbieters gespeichert.

Aus IT-Perspektive ist der operative Aufwand minimal. Es gibt keine Server zu provisionieren, keine Datenbank-Cluster zu warten und keine Backup-Zeitpläne zu konfigurieren. Der Anbieter übernimmt all das.

Strategische Vorteile

Der primäre Vorteil ist Geschwindigkeit. Ein Cloud-Passwort-Manager kann organisationsweit in Stunden bis Tagen bereitgestellt werden, ohne Infrastrukturvoraussetzungen. Automatisches Patching bedeutet, dass die Organisation immer die neueste Version verwendet, ohne Wartungsfenster planen zu müssen. Hochverfügbarkeit (HA) wird vom Anbieter verwaltet, typischerweise durch SLAs abgesichert, die die meisten internen IT-Teams selbstständig nur schwer erreichen würden.

Risiken und Einschränkungen

Das Modell der geteilten Sicherheitsverantwortung ist das zentrale Risiko. Wenn die Infrastruktur eines Anbieters kompromittiert wird, sind alle Kunden gleichzeitig betroffen. Der LastPass-Sicherheitsvorfall von 2022 ist das deutlichste aktuelle Beispiel: Ein Angreifer erlangte Zugang zu einer Backup-Datenbank über einen Drittanbieter-Cloud-Speicherdienst und betraf letztendlich etwa 1,6 Millionen britische Benutzer. Im Dezember 2025 verhängte das britische Information Commissioner's Office eine Geldstrafe von etwa 1,6 Millionen US-Dollar gegen LastPass für die Sicherheitsmängel, die den Vorfall ermöglichten. Der Vorfall zeigte, dass vom Anbieter verwaltete Compliance-Zertifizierungen das Anbieterrisiko nicht eliminieren.

Über das Risiko von Sicherheitsvorfällen hinaus führt Cloud-Bereitstellung zu Datenresidenz-Einschränkungen. Wenn die Rechenzentren eines Anbieters außerhalb der EU liegen, kann die Speicherung von Anmeldedaten dort zusätzliche rechtliche Mechanismen erfordern, um die Anforderungen der DSGVO an grenzüberschreitende Übertragungen zu erfüllen. Kontinuierliche Internetverbindung ist ebenfalls eine harte Abhängigkeit — ein Ausfall beim Anbieter oder auf dem Netzwerkpfad macht es Benutzern unmöglich, auf Anmeldedaten zuzugreifen. Und Abonnementkosten akkumulieren unbegrenzt; es gibt keinen Punkt, an dem die Organisation die Infrastruktur „besitzt".

Self-hosted (On-Premise) Passwort-Manager-Bereitstellung

Architektur und Mechanik

Self-hosted-Bereitstellung ist ein Modell, bei dem die Organisation den Passwort-Manager auf ihrer eigenen Infrastruktur betreibt — mit vollständigem Eigentum am Tresor-Server, der Datenbank und jeder Netzwerkschicht, die sie umgibt.

Dies kann physische Server in einem Unternehmensrechenzentrum bedeuten, virtuelle Maschinen in einer privaten Cloud oder Container in einem Kubernetes-Cluster. Die Organisation installiert und konfiguriert die Passwort-Manager-Server-Software, verwaltet die Datenbank und übernimmt alle Netzwerkzugriffskontrollen.

Das Client-Erlebnis ist identisch mit der Cloud: Benutzer greifen über Browser-Erweiterungen und Desktop- oder Mobile-Apps auf Anmeldedaten zu. Der Unterschied liegt vollständig auf der Serverseite — die Organisation kontrolliert jede Schicht des Stacks.

Strategische Vorteile

Self-Hosting bietet vollständige Datensouveränität. Anmeldedaten verlassen niemals die Infrastruktur der Organisation, was strenge Datenresidenzanforderungen direkt erfüllt. Für Organisationen, die der DSGVO unterliegen, eliminiert dies die Notwendigkeit von Standardvertragsklauseln oder anderen Mechanismen für grenzüberschreitende Übertragungen. Für regulierte Branchen — Rüstungsunternehmen, Finanzinstitute, Gesundheitsorganisationen — ist dieses Maß an Kontrolle oft eine nicht verhandelbare Anforderung.

Self-hosted-Bereitstellungen unterstützen auch Air-Gapped-Umgebungen. Ein Tresor-Server ohne externe Netzwerkverbindung ist physisch von internetbasierten Angriffen isoliert, was ihn für klassifizierte Systeme oder kritische Infrastrukturen geeignet macht, in denen selbst verschlüsselte ausgehende Verbindungen verboten sind. Und da kein Drittanbieter in der Kette ist, beschränkt sich die Angriffsfläche auf die eigene Infrastruktur der Organisation — die die Organisation bereits verteidigt.

Risiken und Einschränkungen

Die operative Last ist real und sollte nicht unterschätzt werden. Self-Hosting erfordert dedizierte Infrastruktur (Server, Load Balancer für HA, Backup-Systeme), Expertise zur Konfiguration und Wartung sowie einen disziplinierten Patching-Prozess. Sicherheitspatches für die Passwort-Manager-Software müssen zeitnah eingespielt werden; ein verpasstes Update auf einem Self-hosted-Tresor ist das Problem der Organisation, nicht des Anbieters.

Hochverfügbarkeit in einer Self-hosted-Umgebung bedeutet, sie selbst aufzubauen: redundante Datenbankknoten, Failover-Konfigurationen und getestete Wiederherstellungsverfahren. Organisationen, denen diese Fähigkeit fehlt — oder das IT-Personal, um sie zu warten — stehen vor dem echten Risiko, dass eine Self-hosted-Bereitstellung weniger verfügbar und weniger sicher wird als die Cloud-Alternative, die sie ersetzt hat.

Fehlkonfigurationen in Netzwerkzugriffskontrollen oder Datenbankberechtigungen können den Tresor internen Bedrohungen aussetzen, die eine vom Anbieter verwaltete Umgebung standardmäßig handhaben würde.

Hybrid-Passwort-Manager-Bereitstellung

Definition der Hybrid-Architektur

Hybrid-Bereitstellung ist ein Modell, bei dem die Organisation die Passwort-Manager-Funktionalität auf Cloud- und On-Premise-Komponenten aufteilt — wobei jeder Teil des Stacks der Umgebung zugewiesen wird, die am besten zu seinen Sicherheits-, Compliance- oder operativen Anforderungen passt.

„Hybrid" wird im Anbieter-Marketing häufig ungenau verwendet und bedeutet oft nicht mehr als „wir haben sowohl eine Cloud- als auch eine On-Premise-Option". In der Praxis nehmen Unternehmens-Hybrid-Bereitstellungen vier verschiedene architektonische Formen an, jede mit unterschiedlichen Sicherheits- und operativen Implikationen.

• Aufteilung nach Sensibilität behält routinemäßige Anmeldedaten — SaaS-Anwendungslogins, gemeinsame Team-Accounts — in einem Cloud-Tresor, während hochsensible Anmeldedaten (privilegierte Accounts, Infrastruktur-Secrets, kryptografische Schlüssel) in einem On-Premise-Tresor gespeichert werden. Dieses Muster reduziert den On-Premise-Footprint und schützt gleichzeitig die wertvollsten Assets.
• Dezentrale Speicherung mit Cloud-Synchronisation speichert den Passwort-Tresor lokal auf jedem Gerät oder On-Premise-Server und nutzt Cloud-Infrastruktur nur zur Synchronisation zwischen Endpunkten. Die Cloud-Komponente hält niemals die primäre Kopie der Anmeldedaten — sie überträgt verschlüsselte Deltas zwischen lokalen Speichern.
• Geteilte Steuerungsebene trennt Tresorspeicherung von Administration: Anmeldedaten werden On-Premise gespeichert, aber die Management-Konsole, Audit-Logging und Policy-Durchsetzung laufen in der Cloud. Dieses Muster eignet sich für Organisationen, die Datenlokalität wollen, ohne den Overhead der internen Verwaltung einer administrativen Oberfläche.
• Failover-Architektur betreibt den primären Tresor On-Premise mit einem Cloud-gehosteten Replikat, das automatisch aktiviert wird, wenn die On-Premise-Umgebung nicht verfügbar ist. Dies ist ein Disaster-Recovery-Muster statt eines alltäglichen Hybrids — die Cloud-Komponente existiert, um Kontinuität zu garantieren, nicht um routinemäßigen Zugriff zu handhaben.

Strategische Vorteile

Hybrid-Bereitstellungen adressieren die zentrale Spannung zwischen Kontrolle und Komfort. Eine Organisation, die der DSGVO für EU-Mitarbeiter-Anmeldedaten unterliegt, aber auch US-basierte SaaS-Accounts verwaltet, kann jeden Anmeldedatentyp zur entsprechenden Speicherumgebung routen.

Gemischte regulatorische Umgebungen — bei multinationalen Unternehmen üblich — werden handhabbar, wenn das Bereitstellungsmodell nach Datenklassifizierung, Geografie oder Sensibilitätsstufe segmentiert werden kann.

Das Failover-Muster eliminiert speziell den Single Point of Failure, den sowohl reine Cloud- (Anbieterausfall) als auch reine Self-hosted-Bereitstellungen (On-Premise-Infrastrukturausfall) mit sich bringen. Für Organisationen mit hohen Verfügbarkeitsanforderungen und der IT-Reife, Komplexität zu verwalten, kann Hybrid-Architektur bessere Resilienz bieten als jedes Modell allein.

Risiken und Einschränkungen

Hybrid-Bereitstellungen sind die architektonisch komplexeste Option. Jede Grenze zwischen Cloud- und On-Premise-Komponenten ist eine potenzielle Sicherheitslücke: Synchronisationskanäle müssen verschlüsselt und authentifiziert sein, Zugriffsrichtlinien müssen über beide Umgebungen hinweg konsistent sein, und Audit-Logs müssen aus mehreren Quellen aggregiert werden, um ein kohärentes Bild des Anmeldedatenzugriffs zu liefern.

Inkonsistente Richtliniendurchsetzung an der Grenze — zum Beispiel MFA erforderlich On-Premise, aber nicht für Cloud-synchronisierte Anmeldedaten erzwungen — kann ausnutzbare Lücken schaffen, die keine der beiden Umgebungen isoliert hätte.

Der operative Overhead ist ebenfalls additiv. Das Team muss sowohl die On-Premise-Infrastruktur als auch die Cloud-Integration warten, und Vorfälle können sich über beide Umgebungen erstrecken, was Diagnose und Reaktion erschwert.

Compliance- und Datenresidenzanforderungen

Regulatorische Rahmenwerke schreiben keine Bereitstellungsmodelle vor — sie schreiben Kontrollen vor. Aber bestimmte Kontrollen sind mit spezifischen Bereitstellungsarchitekturen deutlich einfacher nachzuweisen.

DSGVO

Die DSGVO (Verordnung (EU) 2016/679) behandelt Anmeldedaten als personenbezogene Daten und erfordert, dass grenzüberschreitende Übertragungen in Drittländer Angemessenheitsstandards erfüllen oder genehmigte Übertragungsmechanismen wie Standardvertragsklauseln verwenden.

Die Speicherung von Anmeldedaten in einer EU-Region-Cloud oder On-Premise innerhalb der EU eliminiert die Übertragungsfrage vollständig. Organisationen, die US-basierte Cloud-Anbieter nutzen, müssen überprüfen, ob der Datenverarbeitungsvertrag des Anbieters die Anmeldedatenspeicherung abdeckt und dass die relevante Rechenzentrumsregion vertraglich garantiert ist.

NIS2

NIS2 (Richtlinie (EU) 2022/2555) gilt für wesentliche und wichtige Einrichtungen in kritischen Infrastruktursektoren. Sie verpflichtet Organisationen, Zugangskontrollmaßnahmen und sichere Authentifizierungspraktiken als Teil ihrer Cybersicherheits-Risikomanagement-Verpflichtungen zu implementieren.

Self-hosted- oder Hybrid-Bereitstellungen geben Organisationen direkte Kontrolle über diese Kontrollen und die Nachweise, die benötigt werden, um sie gegenüber nationalen zuständigen Behörden zu demonstrieren.

Passwort-Manager mit eingebauten Audit-Logs und rollenbasierter Zugriffskontrolle — wie Passwork — vereinfachen den Prozess der Bereitstellung dieser Nachweise während Bewertungen.

Migration und Vendor-Lock-in-Überlegungen

Die Migration zwischen Bereitstellungsmodellen ist im Prinzip operativ unkompliziert und in der Praxis wirklich komplex. Die meisten Passwort-Manager unterstützen Tresor-Export im CSV- oder JSON-Format. Der Prozess umfasst den Export des bestehenden Tresors, den Import in das neue System, die Überprüfung der Integrität der Anmeldedaten und die Stilllegung der alten Umgebung.

Der kritische Sicherheitsschritt — einer, der häufig übersprungen wird — ist die Rotation aller Anmeldedaten nach der Migration. Alle Anmeldedaten, die in der alten Umgebung existierten, sollten als potenziell exponiert während des Migrationsfensters behandelt werden, insbesondere wenn die alte Bereitstellung Cloud-basiert war und die Organisation aus Sicherheitsgründen zu Self-hosted wechselt. Die Passwortrotation für privilegierte Accounts und gemeinsam genutzte Anmeldedaten sollte erfolgen, bevor der alte Tresor stillgelegt wird.

Das Vendor-Lock-in-Risiko variiert erheblich je nach Exportformat. Anbieter, die proprietäre Formate verwenden — oder den Export auf bestimmte Tarife beschränken — erzeugen echte Migrationsreibung. Vor der Festlegung auf eine Plattform sollten Sie überprüfen, dass das Exportformat offen ist (CSV oder JSON), dass der Export alle Anmeldedatenfelder enthält (einschließlich TOTP-Secrets und benutzerdefinierter Felder) und dass der Prozess ohne Anbieterunterstützung abgeschlossen werden kann. Dies ist ein vertraglicher und technischer Due-Diligence-Punkt, keine Nebensache.

Fazit

Die Entscheidung über das Passwort-Manager-Bereitstellungsmodell hat dasselbe Gewicht wie die Softwareauswahl selbst.

• Cloud-Bereitstellung liefert Geschwindigkeit, operative Einfachheit und vom Anbieter verwaltete Compliance-Zertifizierungen — auf Kosten von Datenkontrolle und gemeinsamer Exposition bei Sicherheitsvorfällen.
• Self-hosted-Bereitstellung bietet vollständige Datensouveränität und Air-Gap-Fähigkeit — auf Kosten erheblichen IT-Overheads und voller Verantwortung für Sicherheitswartung.
• Hybrid-Bereitstellung bietet ein konfigurierbares Gleichgewicht zwischen beiden, auf Kosten architektonischer Komplexität.

Die richtige Wahl hängt von drei Faktoren ab: Ihren Compliance-Verpflichtungen (welche Vorschriften gelten und welche Datenresidenzanforderungen stellen sie), Ihren IT-Ressourcen (haben Sie die Infrastruktur und Expertise, um eine Self-hosted-Umgebung zuverlässig zu betreiben) und Ihrer Risikobereitschaft (wie gewichten Sie das Risiko eines Anbieter-Sicherheitsvorfalls gegen das Fehlkonfigurationsrisiko).

Passwork unterstützt alle drei Bereitstellungsmodelle — Cloud, On-Premise und Hybrid — sodass die Architekturentscheidung Ihre Softwarewahl nicht einschränkt.

• Die On-Premise-Version liefert vollständige Datensouveränität, LDAP/AD-Integration und rollenbasierte Zugriffskontrolle für regulierte Umgebungen.
• Die Cloud-Version bietet denselben Funktionsumfang mit vom Anbieter verwalteter Infrastruktur für Teams, die Bereitstellungsgeschwindigkeit priorisieren.
• Hybrid-Konfigurationen sind verfügbar für Organisationen, die Anmeldedatenspeicherung über Umgebungen hinweg segmentieren müssen.

Häufig gestellte Fragen

Fünf Wege, damit Benutzer Passwortsicherheit lieben

Benutzer wehren sich nicht gegen Sicherheit — sie wehren sich gegen Reibung. Fünf evidenzbasierte Strategien, um Ihre Passwortrichtlinie zu aktualisieren, die Einführung von Passwort-Managern voranzutreiben und eine Sicherheitskultur aufzubauen, der Mitarbeiter tatsächlich folgen.

Passwork BlogAlex Muntyan

Was ist ein Passkey? Leitfaden zur passwortlosen Authentifizierung

Ein Passkey ist eine Phishing-resistente Anmeldedaten, die auf Ihrem Gerät gespeichert wird. Melden Sie sich mit einem biometrischen Tippen an — kein Passwort zum Merken oder Stehlen. Dieser Leitfaden behandelt die technischen Mechanismen, Plattformeinrichtung, reale Leistungsdaten und was der Übergang für Unternehmensteams bedeutet.

Passwork BlogAlex Muntyan

Enterprise-Passwort-Management: Der B2B-Leitfaden zu Bereitstellung, Sicherheit & Implementierung (2026)

Ein umfassender Leitfaden für B2B-Führungskräfte zum Enterprise-Passwort-Management. Erkunden Sie Bereitstellungsoptionen (Cloud, On-Premise, Hybrid), Sicherheitsarchitektur und Best Practices für die Implementierung.

Passwork BlogAlex Muntyan

Introducción

La mayoría de las organizaciones dedican semanas a evaluar qué gestor de contraseñas comprar — y una tarde a decidir dónde ejecutarlo. Esa proporción está equivocada.

El modelo de implementación determina si sus credenciales están sujetas a una brecha del proveedor, si su infraestructura satisface el GDPR sin mecanismos legales adicionales y si su equipo puede mantener de manera realista lo que ha construido. Dos organizaciones pueden ejecutar software idéntico y enfrentar posturas de seguridad completamente diferentes — porque una eligió la nube y la otra eligió autoalojamiento.

La escala del problema deja claras las implicaciones. Dieciséis mil millones de contraseñas quedaron expuestas en un único incidente de compilación de datos en junio de 2025 — una cifra que redefine la seguridad de credenciales como un problema de infraestructura, no como un problema de comportamiento del usuario. Según las evaluaciones globales de ciberseguridad de 2025, el 74% de las brechas involucran credenciales robadas, débiles o filtradas.

Un gestor de contraseñas es la respuesta obvia. Pero el modelo de implementación que elija — nube, autoalojado o híbrido — determina todo lo que sigue: dónde residen sus datos, quién los controla, qué marcos de cumplimiento puede satisfacer y cuánto gastará su equipo en mantenimiento.

Esta guía proporciona un marco concreto para tomar esa decisión arquitectónica.

Puntos clave

• El modelo de implementación es una decisión arquitectónica. Nube, autoalojado e híbrido optimizan cada uno para un conjunto diferente de prioridades. La elección incorrecta crea brechas de cumplimiento que son costosas de corregir.
• El cifrado de conocimiento cero es una base, no un diferenciador. La decisión de implementación determina quién controla el servidor que almacena el texto cifrado — y quién es responsable cuando se ve comprometido.
• La nube intercambia control por conveniencia. La infraestructura gestionada por el proveedor significa que una brecha a nivel del proveedor afecta a todos los clientes simultáneamente.
• El autoalojamiento intercambia conveniencia por control. Las credenciales nunca abandonan su infraestructura. La carga operativa — parches, alta disponibilidad, copias de seguridad — recae completamente en su equipo.
• Híbrido son cuatro patrones distintos, no uno. División por sensibilidad, sincronización descentralizada, plano de control dividido y arquitectura de conmutación por error tienen cada uno diferentes implicaciones de seguridad.
• Las regulaciones prescriben controles, no modelos de implementación. GDPR y NIS2 pueden satisfacerse cada uno con más de una arquitectura — pero algunos modelos facilitan significativamente la producción de evidencia de cumplimiento.
• Rote todas las credenciales después de la migración. Es el paso que la mayoría de las organizaciones omiten — y el que más importa al migrar desde una bóveda en la nube.

Comprender las arquitecturas de gestores de contraseñas

El concepto central del cifrado de conocimiento cero

El cifrado de conocimiento cero es una arquitectura de seguridad en la que todas las operaciones de cifrado y descifrado ocurren exclusivamente en el dispositivo del usuario — lo que significa que el servidor recibe, almacena y transmite solo texto cifrado y no tiene capacidad criptográfica para leer los datos subyacentes.

Antes de comparar los modelos de implementación, vale la pena establecer lo que comparten. Los gestores de contraseñas de nivel empresarial — independientemente de dónde resida la bóveda — se basan en una arquitectura de conocimiento cero. El cifrado y descifrado ocurren a nivel del dispositivo, utilizando algoritmos como AES-256. El servidor, ya sea que esté en el centro de datos de un proveedor o en su propio rack, almacena solo texto cifrado. Ni siquiera el proveedor puede leer sus credenciales.

Esto importa para la decisión de implementación porque la arquitectura de conocimiento cero desplaza la pregunta de seguridad de «¿es confiable el servidor?» hacia «¿quién controla el servidor y qué sucede si se ve comprometido?» La respuesta a esa pregunta difiere significativamente entre los tres modelos.

Los tres modelos principales de implementación

La implementación en la nube significa que el proveedor aloja y gestiona la bóveda de contraseñas cifrada en su infraestructura. La implementación autoalojada significa que la organización ejecuta la bóveda en sus propios servidores o nube privada. La implementación híbrida combina elementos de ambas — típicamente dividiendo el almacenamiento de datos, la sincronización o el control administrativo entre componentes en la nube y locales.

La elección afecta la residencia de datos (dónde residen físicamente las credenciales), el control organizacional (quién gestiona el acceso y los parches) y la responsabilidad de mantenimiento (quién responde cuando algo falla). Cada modelo optimiza para un conjunto diferente de prioridades.

Implementación de gestor de contraseñas en la nube

Arquitectura y mecanismos

La implementación en la nube es un modelo en el que el proveedor posee y opera toda la infraestructura del servidor — alojando la bóveda de contraseñas cifrada, gestionando la disponibilidad y manejando todo el mantenimiento del backend en nombre de la organización.

En la práctica, el proveedor gestiona toda la pila: servidores, balanceadores de carga, copias de seguridad y zonas de disponibilidad. La organización instala aplicaciones cliente — extensiones de navegador, aplicaciones de escritorio, clientes móviles — que se conectan a la API del proveedor. Las credenciales se cifran localmente antes de la transmisión y se almacenan como texto cifrado en el entorno del proveedor.

Desde la perspectiva de TI, la huella operativa es mínima. No hay servidores que aprovisionar, ni clústeres de bases de datos que mantener, ni programas de copias de seguridad que configurar. El proveedor maneja todo eso.

Ventajas estratégicas

La ventaja principal es la velocidad. Un gestor de contraseñas en la nube puede implementarse en toda la organización en horas o días, sin requisitos previos de infraestructura. La aplicación automática de parches significa que la organización siempre ejecuta la última versión sin programar ventanas de mantenimiento. La alta disponibilidad (HA) es gestionada por el proveedor, típicamente respaldada por SLAs que la mayoría de los equipos internos de TI tendrían dificultades para igualar de forma independiente.

Riesgos y limitaciones

El modelo de responsabilidad compartida de seguridad es el riesgo central. Cuando la infraestructura de un proveedor se ve comprometida, todos los clientes se ven afectados simultáneamente. La brecha de LastPass de 2022 es el ejemplo reciente más claro: un atacante accedió a una base de datos de respaldo a través de un servicio de almacenamiento en la nube de terceros, afectando finalmente a aproximadamente 1,6 millones de usuarios del Reino Unido. En diciembre de 2025, la Oficina del Comisionado de Información del Reino Unido multó a LastPass con aproximadamente 1,6 millones de dólares por las fallas de seguridad que hicieron posible la brecha. El incidente demostró que las certificaciones de cumplimiento gestionadas por el proveedor no eliminan el riesgo del lado del proveedor.

Más allá del riesgo de brechas, la implementación en la nube introduce restricciones de residencia de datos. Si los centros de datos de un proveedor están ubicados fuera de la UE, almacenar credenciales allí puede requerir mecanismos legales adicionales para satisfacer los requisitos de transferencia transfronteriza del GDPR. La conectividad continua a internet también es una dependencia estricta — una interrupción en el proveedor o en la ruta de red deja a los usuarios sin poder acceder a las credenciales. Y los costos de suscripción se acumulan indefinidamente; no hay un punto en el que la organización «posea» la infraestructura.

Implementación de gestor de contraseñas autoalojado (local)

Arquitectura y mecanismos

La implementación autoalojada es un modelo en el que la organización ejecuta el gestor de contraseñas en su propia infraestructura — reteniendo la propiedad total del servidor de la bóveda, la base de datos y cada capa de red que los rodea.

Esto puede significar servidores físicos en un centro de datos corporativo, máquinas virtuales en una nube privada o contenedores en un clúster de Kubernetes. La organización instala y configura el software del servidor del gestor de contraseñas, gestiona la base de datos y maneja todos los controles de acceso a la red.

La experiencia del cliente es idéntica a la nube: los usuarios acceden a las credenciales a través de extensiones de navegador y aplicaciones de escritorio o móviles. La diferencia está completamente en el lado del servidor — la organización controla cada capa de la pila.

Ventajas estratégicas

El autoalojamiento proporciona soberanía completa de los datos. Las credenciales nunca abandonan la infraestructura de la organización, lo que satisface directamente los requisitos estrictos de residencia de datos. Para organizaciones sujetas al GDPR, esto elimina la necesidad de Cláusulas Contractuales Tipo u otros mecanismos de transferencia transfronteriza. Para industrias reguladas — contratistas de defensa, instituciones financieras, organizaciones de salud — este nivel de control es a menudo un requisito no negociable.

Las implementaciones autoalojadas también admiten entornos aislados. Un servidor de bóveda sin conectividad de red externa está físicamente aislado de los ataques basados en internet, lo que lo hace apropiado para sistemas clasificados o infraestructura crítica donde incluso las conexiones salientes cifradas están prohibidas. Y debido a que no hay un proveedor tercero en la cadena, la superficie de ataque se limita a la propia infraestructura de la organización — que la organización ya defiende.

Riesgos y limitaciones

La carga operativa es real y no debe subestimarse. El autoalojamiento requiere infraestructura dedicada (servidores, balanceadores de carga para HA, sistemas de respaldo), experiencia para configurarla y mantenerla, y un proceso disciplinado de aplicación de parches. Los parches de seguridad para el software del gestor de contraseñas deben aplicarse rápidamente; una actualización omitida en una bóveda autoalojada es problema de la organización, no del proveedor.

La alta disponibilidad en un entorno autoalojado significa construirla usted mismo: nodos de base de datos redundantes, configuraciones de conmutación por error y procedimientos de recuperación probados. Las organizaciones que carecen de esta capacidad — o del personal de TI para mantenerla — enfrentan un riesgo genuino de que una implementación autoalojada se vuelva menos disponible y menos segura que la alternativa en la nube que reemplazó.

Las configuraciones incorrectas en los controles de acceso a la red o los permisos de la base de datos pueden exponer la bóveda a amenazas internas que un entorno gestionado por el proveedor manejaría por defecto.

Implementación híbrida de gestor de contraseñas

Definición de la arquitectura híbrida

La implementación híbrida es un modelo en el que la organización divide la funcionalidad del gestor de contraseñas entre componentes en la nube y locales — asignando cada parte de la pila al entorno que mejor se adapta a sus requisitos de seguridad, cumplimiento u operativos.

«Híbrido» se usa de manera imprecisa en el marketing de proveedores, a menudo significando poco más que «tenemos tanto una opción en la nube como una local». En la práctica, las implementaciones híbridas empresariales adoptan cuatro formas arquitectónicas distintas, cada una con diferentes implicaciones de seguridad y operativas.

• División por sensibilidad mantiene las credenciales rutinarias — inicios de sesión de aplicaciones SaaS, cuentas de equipo compartidas — en una bóveda en la nube, mientras que las credenciales altamente sensibles (cuentas privilegiadas, secretos de infraestructura, claves criptográficas) se almacenan en una bóveda local. Este patrón reduce la huella local mientras protege los activos de mayor valor.
• Almacenamiento descentralizado con sincronización en la nube almacena la bóveda de contraseñas localmente en cada dispositivo o servidor local, usando la infraestructura en la nube solo para la sincronización entre puntos finales. El componente en la nube nunca contiene la copia principal de las credenciales — transmite deltas cifrados entre almacenes locales.
• Plano de control dividido separa el almacenamiento de la bóveda de la administración: las credenciales se almacenan localmente, pero la consola de gestión, el registro de auditoría y la aplicación de políticas se ejecutan en la nube. Este patrón es adecuado para organizaciones que desean localidad de datos sin la sobrecarga de gestionar una interfaz administrativa internamente.
• Arquitectura de conmutación por error ejecuta la bóveda principal localmente, con una réplica alojada en la nube que se activa automáticamente si el entorno local deja de estar disponible. Este es un patrón de recuperación ante desastres más que un híbrido del día a día — el componente en la nube existe para garantizar la continuidad, no para manejar el acceso rutinario.

Ventajas estratégicas

Las implementaciones híbridas abordan la tensión central entre control y conveniencia. Una organización sujeta al GDPR para las credenciales de empleados de la UE pero que también gestiona cuentas SaaS con sede en EE. UU. puede dirigir cada tipo de credencial al entorno de almacenamiento apropiado.

Los entornos regulatorios mixtos — comunes en empresas multinacionales — se vuelven manejables cuando el modelo de implementación puede segmentarse por clasificación de datos, geografía o nivel de sensibilidad.

El patrón de conmutación por error específicamente elimina el punto único de fallo que llevan tanto las implementaciones puramente en la nube (interrupción del proveedor) como las puramente autoalojadas (fallo de infraestructura local). Para organizaciones con requisitos de alta disponibilidad y la madurez de TI para gestionar la complejidad, la arquitectura híbrida puede ofrecer mejor resiliencia que cualquiera de los modelos por separado.

Riesgos y limitaciones

Las implementaciones híbridas son la opción arquitectónicamente más compleja. Cada límite entre componentes en la nube y locales es una brecha de seguridad potencial: los canales de sincronización deben estar cifrados y autenticados, las políticas de acceso deben ser consistentes en ambos entornos y los registros de auditoría deben agregarse de múltiples fuentes para proporcionar una imagen coherente del acceso a credenciales.

La aplicación inconsistente de políticas en el límite — por ejemplo, MFA requerido localmente pero no aplicado para credenciales sincronizadas en la nube — puede crear brechas explotables que ninguno de los entornos tendría de forma aislada.

La sobrecarga operativa también es aditiva. El equipo debe mantener tanto la infraestructura local como la integración en la nube, y los incidentes pueden abarcar ambos entornos, complicando el diagnóstico y la respuesta.

Requisitos de cumplimiento y residencia de datos

Los marcos regulatorios no prescriben modelos de implementación — prescriben controles. Pero ciertos controles son significativamente más fáciles de demostrar con arquitecturas de implementación específicas.

GDPR

El GDPR (Reglamento (UE) 2016/679) trata las credenciales como datos personales y requiere que las transferencias transfronterizas a terceros países cumplan con estándares de adecuación o utilicen mecanismos de transferencia aprobados como las Cláusulas Contractuales Tipo.

Almacenar credenciales en una nube de región de la UE o localmente dentro de la UE elimina la cuestión de la transferencia por completo. Las organizaciones que utilizan proveedores de nube con sede en EE. UU. deben verificar que el acuerdo de procesamiento de datos del proveedor cubra el almacenamiento de credenciales y que la región del centro de datos relevante esté garantizada contractualmente.

NIS2

La NIS2 (Directiva (UE) 2022/2555) se aplica a entidades esenciales e importantes en sectores de infraestructura crítica. Requiere que las organizaciones implementen medidas de control de acceso y prácticas de autenticación segura como parte de sus obligaciones de gestión de riesgos de ciberseguridad.

Las implementaciones autoalojadas o híbridas dan a las organizaciones control directo sobre estos controles y la evidencia necesaria para demostrarlos ante las autoridades nacionales competentes.

Los gestores de contraseñas con registros de auditoría integrados y control de acceso basado en roles — como Passwork — simplifican el proceso de producir esa evidencia durante las evaluaciones.

Consideraciones sobre migración y dependencia del proveedor

Migrar entre modelos de implementación es operativamente sencillo en principio y genuinamente complejo en la práctica. La mayoría de los gestores de contraseñas admiten la exportación de la bóveda en formato CSV o JSON. El proceso implica exportar la bóveda existente, importarla al nuevo sistema, verificar la integridad de las credenciales y desmantelar el entorno antiguo.

El paso crítico de seguridad — uno que se omite con frecuencia — es rotar todas las credenciales después de la migración. Cualquier credencial que existiera en el entorno anterior debe tratarse como potencialmente expuesta durante la ventana de migración, particularmente si la implementación anterior era en la nube y la organización está migrando a autoalojado por razones de seguridad. La rotación de contraseñas para cuentas privilegiadas y credenciales compartidas debe realizarse antes de que se desmantele la bóveda antigua.

El riesgo de dependencia del proveedor varía significativamente según el formato de exportación. Los proveedores que utilizan formatos propietarios — o que limitan la exportación a niveles específicos — crean una fricción real de migración. Antes de comprometerse con una plataforma, verifique que el formato de exportación sea abierto (CSV o JSON), que la exportación incluya todos los campos de credenciales (incluidos secretos TOTP y campos personalizados), y que el proceso pueda completarse sin asistencia del proveedor. Este es un elemento de debida diligencia contractual y técnica, no una ocurrencia tardía.

Conclusión

La decisión del modelo de implementación del gestor de contraseñas tiene el mismo peso que la selección del software en sí.

• La implementación en la nube ofrece velocidad, simplicidad operativa y certificaciones de cumplimiento gestionadas por el proveedor — a costa del control de datos y la exposición compartida a brechas.
• La implementación autoalojada proporciona soberanía completa de los datos y capacidad de aislamiento — a costa de una sobrecarga significativa de TI y responsabilidad total del mantenimiento de seguridad.
• La implementación híbrida ofrece un equilibrio configurable entre las dos, a costa de la complejidad arquitectónica.

La elección correcta depende de tres factores: sus obligaciones de cumplimiento (qué regulaciones aplican y qué requisitos de residencia de datos imponen), sus recursos de TI (¿tiene la infraestructura y la experiencia para ejecutar un entorno autoalojado de manera confiable?) y su tolerancia al riesgo (¿cómo pondera el riesgo de brecha del proveedor frente al riesgo de configuración incorrecta?).

Passwork admite los tres modelos de implementación — nube, local e híbrido — para que la decisión arquitectónica no limite su elección de software.

• La versión local ofrece soberanía completa de los datos, integración LDAP/AD y control de acceso basado en roles para entornos regulados.
• La versión en la nube proporciona el mismo conjunto de características con infraestructura gestionada por el proveedor para equipos que priorizan la velocidad de implementación.
• Las configuraciones híbridas están disponibles para organizaciones que necesitan segmentar el almacenamiento de credenciales entre entornos.

Preguntas frecuentes

Cinco formas de hacer que los usuarios amen la seguridad de contraseñas

Los usuarios no se resisten a la seguridad — se resisten a la fricción. Cinco estrategias basadas en evidencia para actualizar su política de contraseñas, impulsar la adopción del gestor de contraseñas y construir una cultura de seguridad que los empleados realmente sigan.

Passwork BlogAlex Muntyan

¿Qué es una passkey? Guía de autenticación sin contraseña

Una passkey es una credencial resistente al phishing almacenada en su dispositivo. Inicie sesión con un toque biométrico — sin contraseña que recordar o robar. Esta guía cubre los mecanismos técnicos, la configuración de plataformas, datos de rendimiento del mundo real y lo que significa la transición para los equipos empresariales.

Passwork BlogAlex Muntyan

Gestión de contraseñas empresariales: la guía B2B de implementación, seguridad e integración (2026)

Una guía completa para líderes B2B sobre gestión de contraseñas empresariales. Explore las opciones de implementación (nube, local, híbrido), arquitectura de seguridad y mejores prácticas de implementación.

Passwork BlogAlex Muntyan

Introduction

Most organizations spend weeks evaluating which password manager to buy — and an afternoon deciding where to run it. That's the wrong ratio.

The deployment model determines whether your credentials are subject to a vendor's breach, whether your infrastructure satisfies GDPR without additional legal mechanisms, and whether your team can realistically maintain what they've built. Two organizations can run identical software and face completely different security postures — because one chose cloud and the other chose self-hosted.

The scale of the problem makes the stakes clear. Sixteen billion passwords were exposed in a single data compilation incident in June 2025 — a number that reframes credential security as an infrastructure problem, not a user behavior problem. According to global cybersecurity assessments in 2025, 74% of breaches involve stolen, weak, or leaked credentials.

A password manager is the obvious response. But the deployment model you choose — cloud, self-hosted, or hybrid — shapes everything that follows: where your data lives, who controls it, what compliance frameworks you can satisfy, and what your team will spend maintaining it.

This guide gives a concrete framework for making that architectural decision.

Key takeways

• Deployment model is an architectural decision. Cloud, self-hosted, and hybrid each optimize for a different set of priorities. The wrong choice creates compliance gaps that are expensive to unwind.
• Zero-knowledge encryption is a baseline, not a differentiator. The deployment decision determines who controls the server storing the ciphertext — and who is responsible when it's compromised.
• Cloud trades control for convenience. Vendor-managed infrastructure means a breach at the vendor level affects every customer simultaneously.
• Self-hosted trades convenience for control. Credentials never leave your infrastructure. The operational burden — patching, HA, backups — falls entirely on your team.
• Hybrid is four distinct patterns, not one. Split-by-sensitivity, decentralized sync, split control plane, and failover architecture each carry different security implications.
• Regulations prescribe controls, not deployment models. GDPR and NIS2 can each be satisfied by more than one architecture — but some models make compliance evidence significantly easier to produce.
• Rotate all credentials after migration. It's the step most organizations skip — and the one that matters most when moving away from a cloud vault.

Understanding password manager architectures

The core concept of zero-knowledge encryption

Zero-knowledge encryption is a security architecture in which all encryption and decryption operations occur exclusively on the user's device — meaning the server receives, stores, and transmits only ciphertext and has no cryptographic ability to read the underlying data.

Before comparing deployment models, it's worth establishing what they share. Enterprise-grade password managers — regardless of where the vault lives — rely on zero-knowledge architecture. Encryption and decryption happen at the device level, using algorithms such as AES-256. The server, whether it sits in a vendor's data center or your own rack, stores only ciphertext. Even the vendor cannot read your credentials.

This matters for the deployment decision because zero-knowledge architecture shifts the security question away from "is the server trustworthy?" toward "who controls the server, and what happens if it's compromised?" The answer to that question differs significantly across the three models.

The three primary deployment models

Cloud deployment means the vendor hosts and manages the encrypted password vault on their infrastructure. Self-hosted deployment means the organization runs the vault on its own servers or private cloud. Hybrid deployment combines elements of both — typically splitting data storage, synchronization, or administrative control across cloud and on-premise components.

The choice affects data residency (where credentials physically reside), organizational control (who manages access and patching), and maintenance responsibility (who responds when something breaks). Each model optimizes for a different set of priorities.

Cloud-based password manager deployment

Architecture and mechanics

Cloud-based deployment is a model in which the vendor owns and operates the entire server infrastructure — hosting the encrypted password vault, managing availability, and handling all backend maintenance on the organization's behalf.

In practice, the vendor manages the full stack: servers, load balancers, backups, and availability zones. The organization installs client applications — browser extensions, desktop apps, mobile clients — that connect to the vendor's API. Credentials are encrypted locally before transmission and stored as ciphertext in the vendor's environment.

From an IT perspective, the operational footprint is minimal. There are no servers to provision, no database clusters to maintain, and no backup schedules to configure. The vendor handles all of that.

Strategic advantages

The primary advantage is speed. A cloud password manager can be deployed organization-wide in hours to days, with no infrastructure prerequisites. Automatic patching means the organization is always running the latest version without scheduling maintenance windows. High availability (HA) is vendor-managed, typically backed by SLAs that most internal IT teams would struggle to match independently.

Risks and limitations

The shared security responsibility model is the central risk. When a vendor's infrastructure is compromised, every customer is affected simultaneously. The 2022 LastPass breach is the clearest recent example: an attacker accessed a backup database through a third-party cloud storage service, ultimately affecting approximately 1.6 million UK users. In December 2025, the UK Information Commissioner's Office fined LastPass approximately $1.6 million for the security failures that made the breach possible. The incident demonstrated that vendor-managed compliance certifications do not eliminate vendor-side risk.

Beyond breach risk, cloud deployment introduces data residency constraints. If a vendor's data centers are located outside the EU, storing credentials there may require additional legal mechanisms to satisfy GDPR's cross-border transfer requirements. Continuous internet connectivity is also a hard dependency — an outage at the vendor or on the network path leaves users unable to access credentials. And subscription costs accumulate indefinitely; there is no point at which the organization "owns" the infrastructure.

Self-hosted (on-premise) password manager deployment

Architecture and mechanics

Self-hosted deployment is a model in which the organization runs the password manager on its own infrastructure — retaining full ownership of the vault server, the database, and every network layer that surrounds them.

This can mean physical servers in a corporate data center, virtual machines in a private cloud, or containers in a Kubernetes cluster. The organization installs and configures the password manager server software, manages the database, and handles all network access controls.

The client experience is identical to cloud: users access credentials through browser extensions and desktop or mobile apps. The difference is entirely on the server side — the organization controls every layer of the stack.

Strategic advantages

Self-hosting provides complete data sovereignty. Credentials never leave the organization's infrastructure, which directly satisfies strict data residency requirements. For organizations subject to GDPR, this eliminates the need for Standard Contractual Clauses or other cross-border transfer mechanisms. For regulated industries — defense contractors, financial institutions, healthcare organizations — this level of control is often a non-negotiable requirement.

Self-hosted deployments also support air-gapped environments. A vault server with no external network connectivity is physically isolated from internet-based attacks, making it appropriate for classified systems or critical infrastructure where even encrypted outbound connections are prohibited. And because there is no third-party vendor in the chain, the attack surface is limited to the organization's own infrastructure — which the organization already defends.

Risks and limitations

The operational burden is real and should not be underestimated. Self-hosting requires dedicated infrastructure (servers, load balancers for HA, backup systems), expertise to configure and maintain it, and a disciplined patching process. Security patches for the password manager software must be applied promptly; a missed update on a self-hosted vault is the organization's problem, not the vendor's.

High availability in a self-hosted environment means building it yourself: redundant database nodes, failover configurations, and tested recovery procedures. Organizations that lack this capability — or the IT staff to maintain it — face a genuine risk that a self-hosted deployment becomes less available and less secure than the cloud alternative it replaced.

Misconfigurations in network access controls or database permissions can expose the vault to internal threats that a vendor-managed environment would handle by default.

Passwork on-premise
Passwork is built specifically for on-premise deployment. It ships with detailed installation documentation covering Linux, Windows, and Docker environments, and the support team is available to assist with configuration at every stage.
Try Passwork free

Hybrid password manager deployment

Defining the hybrid architecture

Hybrid deployment is a model in which the organization splits password manager functionality across cloud and on-premise components — assigning each part of the stack to the environment that best fits its security, compliance, or operational requirements.

"Hybrid" is used loosely in vendor marketing, often meaning little more than "we have both a cloud and an on-premise option." In practice, enterprise hybrid deployments take four distinct architectural forms, each with different security and operational implications.

• Split-by-sensitivity keeps routine credentials — SaaS application logins, shared team accounts — in a cloud vault, while highly sensitive credentials (privileged accounts, infrastructure secrets, cryptographic keys) are stored in an on-premise vault. This pattern reduces the on-premise footprint while protecting the highest-value assets.
• Decentralized storage with cloud sync stores the password vault locally on each device or on-premise server, using cloud infrastructure only for synchronization between endpoints. The cloud component never holds the primary copy of credentials — it transmits encrypted deltas between local stores.
• Split control plane separates vault storage from administration: credentials are stored on-premise, but the management console, audit logging, and policy enforcement run in the cloud. This pattern suits organizations that want data locality without the overhead of managing an administrative interface internally.
• Failover architecture runs the primary vault on-premise, with a cloud-hosted replica that activates automatically if the on-premise environment becomes unavailable. This is a disaster recovery pattern rather than a day-to-day hybrid — the cloud component exists to guarantee continuity, not to handle routine access.

Strategic advantages

Hybrid deployments address the core tension between control and convenience. An organization subject to GDPR for EU employee credentials but also managing US-based SaaS accounts can route each credential type to the appropriate storage environment.

Mixed regulatory environments — common in multinational enterprises — become manageable when the deployment model can be segmented by data classification, geography, or sensitivity level.

The failover pattern specifically eliminates the single point of failure that both pure cloud (vendor outage) and pure self-hosted (on-premise infrastructure failure) deployments carry. For organizations with high availability requirements and the IT maturity to manage complexity, hybrid architecture can deliver better resilience than either model alone.

Risks and limitations

Hybrid deployments are the most architecturally complex option. Every boundary between cloud and on-premise components is a potential security gap: synchronization channels must be encrypted and authenticated, access policies must be consistent across both environments, and audit logs must be aggregated from multiple sources to provide a coherent picture of credential access.

Inconsistent policy enforcement at the boundary — for example, MFA required on-premise but not enforced for cloud-synced credentials — can create exploitable gaps that neither environment would have in isolation.

The operational overhead is also additive. The team must maintain both the on-premise infrastructure and the cloud integration, and incidents may span both environments, complicating diagnosis and response.

Compliance and data residency requirements

Regulatory frameworks don't prescribe deployment models — they prescribe controls. But certain controls are significantly easier to demonstrate with specific deployment architectures.

GDPR

GDPR (Regulation (EU) 2016/679) treats credentials as personal data and requires that cross-border transfers to third countries meet adequacy standards or use approved transfer mechanisms such as Standard Contractual Clauses.

Storing credentials in an EU-region cloud or on-premise within the EU eliminates the transfer question entirely. Organizations using US-based cloud vendors must verify that the vendor's data processing agreement covers credential storage and that the relevant data center region is contractually guaranteed.

NIS2

NIS2 (Directive (EU) 2022/2555) applies to essential and important entities across critical infrastructure sectors. It requires organizations to implement access control measures and secure authentication practices as part of their cybersecurity risk management obligations.

Self-hosted or hybrid deployments give organizations direct control over these controls and the evidence needed to demonstrate them to national competent authorities.

Password managers with built-in audit logs and role-based access control — such as Passwork — simplify the process of producing that evidence during assessments.

See how Passwork handles access control and audit logging — try Passwork free

Migration and vendor lock-in considerations

Migrating between deployment models is operationally straightforward in principle and genuinely complex in practice. Most password managers support vault export in CSV or JSON format. The process involves exporting the existing vault, importing it into the new system, verifying credential integrity, and decommissioning the old environment.

The critical security step — one that is frequently skipped — is rotating all credentials after migration. Any credential that existed in the old environment should be treated as potentially exposed during the migration window, particularly if the old deployment was cloud-based and the organization is moving to self-hosted for security reasons. Password rotation for privileged accounts and shared credentials should happen before the old vault is decommissioned.

Vendor lock-in risk varies significantly by export format. Vendors that use proprietary formats — or that limit export to specific tiers — create real migration friction. Before committing to a platform, verify that the export format is open (CSV or JSON), that the export includes all credential fields (including TOTP secrets and custom fields), and that the process can be completed without vendor assistance. This is a contractual and technical due diligence item, not an afterthought.

Conclusion

The password manager deployment model decision carries the same weight as the software selection itself.

• Cloud deployment delivers speed, operational simplicity, and vendor-managed compliance certifications — at the cost of data control and shared breach exposure.
• Self-hosted deployment provides complete data sovereignty and air-gap capability — at the cost of significant IT overhead and full responsibility for security maintenance.
• Hybrid deployment offers a configurable balance between the two, at the cost of architectural complexity.

The right choice depends on three factors: your compliance obligations (which regulations apply, and what data residency requirements do they impose), your IT resources (do you have the infrastructure and expertise to run a self-hosted environment reliably), and your risk tolerance (how do you weigh vendor breach risk against misconfiguration risk).

Passwork supports all three deployment models — cloud, on-premise, and hybrid — so the architecture decision doesn't constrain your software choice.

• The on-premise version delivers full data sovereignty, LDAP/AD integration, and role-based access control for regulated environments.
• The cloud version provides the same feature set with vendor-managed infrastructure for teams that prioritize deployment speed.
• Hybrid configurations are available for organizations that need to segment credential storage across environments.

Ready to take the first step? Start with your compliance requirements, map them to the deployment model that satisfies them with the least operational risk, and try Passwork free to see how it fits your environment.

Frequently asked questions

Five ways to make users love password security

Users don’t resist security — they resist friction. Five evidence-based strategies to update your password policy, drive password manager adoption, and build a security culture employees actually follow.

Passwork BlogAlex Muntyan

What is a passkey? Guide to passwordless authentication

A passkey is a phishing-resistant credential stored on your device. Sign in with a biometric tap — no password to remember or steal. This guide covers the technical mechanics, platform setup, real-world performance data, and what the transition means for enterprise teams.

Passwork BlogAlex Muntyan

Enterprise password management: The B2B Guide to Deployment, Security & Implementation (2026)

A comprehensive guide for B2B leaders on enterprise password management. Explore deployment options (cloud, on-premise, hybrid), security architecture, and implementation best practices.

Passwork BlogAlex Muntyan

Ein Passkey ist ein phishing-resistentes, passwortloses Authentifizierungs-Credential, das auf Public-Key-Kryptographie basiert. Bei der Erstellung eines Passkeys generiert Ihr Gerät ein einzigartiges kryptographisches Schlüsselpaar: einen öffentlichen Schlüssel, der auf dem Server der Website gespeichert wird, und einen privaten Schlüssel, der Ihr Gerät niemals verlässt. Sie melden sich an, indem Sie Ihre Identität mit Biometrie oder einer PIN verifizieren.

Dieser Ansatz, standardisiert von der FIDO Alliance und zentral für die passwortlose Authentifizierung, verhindert Phishing und Credential-Diebstahl, da der private Schlüssel Ihr Gerät niemals verlässt. Das Modell entspricht den Richtlinien von NIST SP 800-63B-4 und den DSGVO-Datenschutzanforderungen.

In der Praxis betreiben die meisten Organisationen gemischte Umgebungen — einige Dienste unterstützen bereits Passkeys, andere werden dies erst in Jahren tun. Ein strukturierter Ansatz für das Credential-Management deckt beides ab.

Dieser Leitfaden behandelt alles: wie Passkeys technisch funktionieren, den Unterschied zwischen synchronisierten und gerätegebundenen Passkeys, wie sie auf iPhone, Android und Windows eingerichtet werden, und was die neuesten Daten von 2025–2026 über die reale Leistung aussagen.

Wichtigste Erkenntnisse

• Passkeys nutzen Public-Key-Kryptographie: der private Schlüssel bleibt auf Ihrem Gerät; der Server speichert nur den öffentlichen Schlüssel.
• Passkeys sind konstruktionsbedingt phishing-resistent — eine gefälschte Website kann keine Passkey-Signatur anfordern.
• Passkey-Anmeldungen erreichen eine Erfolgsquote von 93 %, verglichen mit 63 % bei anderen Authentifizierungsmethoden (FIDO Alliance Passkey Index, Oktober 2025).
• Bei Verlust Ihres Geräts sind synchronisierte Passkeys über iCloud Keychain oder die Google-Kontowiederherstellung wiederherstellbar.
• Ende 2024 unterstützen über 15 Milliarden Konten Passkeys, und die Akzeptanz hat sich im Laufe des Jahres verdoppelt (FIDO Alliance, Dezember 2024).

Was ist ein Passkey?

Ein Passkey ist ein kryptographisches Schlüsselpaar, das auf Ihrem Gerät gespeichert ist. Die FIDO Alliance — das Branchenkonsortium hinter dem Standard — definiert Passkeys als Credentials, die „Passwörter durch kryptographische Schlüsselpaare für phishing-resistente Anmeldesicherheit und eine verbesserte Benutzererfahrung ersetzen".

Passkeys implementieren den FIDO2-Standard, wobei WebAuthn die Browser-Gerät-Kommunikation handhabt. Wenn Sie einen Passkey erstellen, generiert Ihr Gerät zwei mathematisch verknüpfte Schlüssel: einer bleibt auf Ihrem Gerät (privat), einer geht an die Website (öffentlich).

Zum Anmelden beweisen Sie, dass Sie den privaten Schlüssel besitzen, indem Sie eine kryptographische Challenge lösen — mit Ihrem Gesicht, Fingerabdruck oder einer PIN. Die Website verifiziert Ihre Antwort mit dem öffentlichen Schlüssel, den sie bereits hat.

Der private Schlüssel verlässt niemals Ihr Gerät. Der Server sieht ihn nie. Es gibt nichts auf der Serverseite, das es zu stehlen lohnt.

Passkeys einfach erklärt

Ein Passkey ist etwas, das Sie haben (Ihr Gerät) plus etwas, das Sie sind (Ihr Fingerabdruck oder Gesicht). Ihr Telefon generiert den Passkey, und Sie entsperren ihn mit Biometrie. 

Der Dienst sieht niemals Ihren Fingerabdruck oder Ihr Gesicht, nur dass Sie den Schlüssel entsperrt haben. Stellen Sie es sich wie eine Hotelschlüsselkarte vor: Sie haben die Karte, und die Tür öffnet sich, wenn Sie sie antippen. Kein Code zum Merken, nichts zum Eintippen, nichts, das aus der Ferne gestohlen werden kann.

Das Problem mit traditionellen Passwörtern

Passwörter haben einen fundamentalen Fehler: Sie sind Geheimnisse, die geteilt werden müssen. Jedes Mal, wenn Sie eines eingeben, wird es über Netzwerke übertragen und auf Servern gespeichert. Der 2025 Verizon DBIR stellte fest, dass über 53 % der Datenschutzverletzungen gestohlene oder per Brute-Force erratene Anmeldedaten beinhalten.

Benutzer verschärfen das Problem. Die Wiederverwendung von Passwörtern ist weit verbreitet, eine Verletzung bei einem Dienst führt zu kompromittierten Konten überall. Phishing nutzt dies weiter aus: gefälschte Anmeldeseiten bringen Benutzer dazu, Anmeldedaten einzugeben und geben Angreifern direkten Zugriff. Hinzu kommt Passwort-Müdigkeit, und Sie erhalten Haftnotizen oder „Firma2024"-Varianten.

Häufige Passwortprobleme:

• Wiederverwendung — eine Verletzung entsperrt mehrere Konten.
• Schwache Passwörter — „123456" dominiert immer noch.
• Phishing-Anfälligkeit — gefälschte Seiten erfassen eingetippte Anmeldedaten.
• Serverseitige Exposition — geleakte Datenbanken werden geknackt.
• Gedächtnisbelastung — Benutzer setzen zurück, schreiben auf oder vereinfachen.

Mit Passkeys gibt es kein Passwort zum Merken, kein Passwort zum Stehlen und keine Serverdatenbank, die verletzt werden kann.

Wie Passkeys tatsächlich funktionieren

Passkeys verwenden Public-Key-Kryptographie anstelle von geteilten Geheimnissen. Stellen Sie es sich wie einen physischen Briefkasten vor: der öffentliche Schlüssel ist der Schlitz, durch den jeder eine Nachricht einwerfen kann, und der private Schlüssel ist der Schlüssel, der den Kasten öffnet. Nur die Person mit dem privaten Schlüssel kann lesen, was drin ist.

Wenn Sie sich mit einem Passkey anmelden, sendet der Dienst oder die Website eine Challenge — eine einzigartige, zufällige Datenzeichenfolge. Ihr Gerät verwendet den privaten Schlüssel, um diese Challenge mathematisch zu signieren. Die Website überprüft dann die Signatur gegen den öffentlichen Schlüssel, den sie während der Registrierung gespeichert hat. Wenn die Signatur gültig ist, sind Sie drin.

Die FIDO Alliance standardisiert dies durch FIDO2. WebAuthn handhabt die Browser-Gerät-Kommunikation. NIST erkennt dieses Modell als phishing-resistent an.

Schritt für Schritt:

1. Gerät erstellt Schlüsselpaar
2. Privater Schlüssel bleibt auf dem Gerät
3. Öffentlicher Schlüssel wird an den Dienst gesendet
4. Dienst sendet Challenge
5. Sie genehmigen mit Biometrie
6. Gerät signiert Challenge
7. Dienst validiert Signatur
8. Sie sind angemeldet

Schritt 1: Der Registrierungsprozess

Der Prozess der Erstellung eines Passkeys wird in der WebAuthn-Spezifikation als Registrierungszeremonie bezeichnet — die W3C-Web-API, die FIDO2 in Browsern implementiert.

Folgendes passiert:

1. Sie besuchen eine Website und wählen, einen Passkey zu erstellen.
2. Die Website sendet eine Registrierungsanfrage über die WebAuthn-API an Ihren Browser.
3. Ihr Browser fordert Sie auf, Ihre Identität zu verifizieren — Face ID, Fingerabdruck oder PIN.
4. Ihr Gerät generiert ein einzigartiges öffentliches/privates Schlüsselpaar speziell für diese Website.
5. Der öffentliche Schlüssel wird an den Server der Website gesendet und gespeichert. Der private Schlüssel wird in der sicheren Hardware Ihres Geräts gespeichert — dem Secure Enclave auf Apple-Geräten oder dem TPM (Trusted Platform Module)-Chip unter Windows.

Apple, Google und Microsoft implementieren dies jeweils über plattformspezifische APIs (iCloud Keychain, Google Password Manager, Windows Hello), aber alle folgen den FIDO2- und WebAuthn-Standards. Ihre biometrischen Daten verlassen niemals Ihr Gerät, nur der kryptographische Nachweis, dass Sie die Schlüsselerstellung autorisiert haben.

Schritt 2: Der Authentifizierungsprozess

Die Anmeldung mit einem Passkey — die Authentifizierungszeremonie — ist ebenso unkompliziert:

1. Sie besuchen die Website und klicken auf „Mit Passkey anmelden".
2. Die Website sendet eine einzigartige, zufällige Challenge an Ihren Browser.
3. Ihr Browser fordert Sie auf, Ihre Identität zu verifizieren (Biometrie oder PIN).
4. Ihr Gerät verwendet den privaten Schlüssel, um die Challenge kryptographisch zu signieren.
5. Die signierte Challenge geht zurück an den Server. Der Server verifiziert die Signatur mit dem gespeicherten öffentlichen Schlüssel. Bei Übereinstimmung wird der Zugriff gewährt.

WebAuthn standardisiert diesen Ablauf über Browser und Plattformen hinweg. Der private Schlüssel verlässt niemals Ihr Gerät, und der Challenge-Response-Mechanismus verhindert Replay-Angriffe.

Die Challenge ist jedes Mal einzigartig. Selbst wenn ein Angreifer die signierte Antwort abfängt, kann er sie nicht wiederverwenden — sie ist mathematisch an diese einzelne Sitzung gebunden.

Geräteübergreifende Authentifizierung: QR-Codes und Bluetooth

Hier ist ein Szenario, das viele Benutzer verwirrt: Sie sind an einem Windows-Laptop, aber Ihr Passkey ist auf Ihrem iPhone gespeichert. Was passiert?

Der Browser zeigt einen QR-Code an. Sie scannen ihn mit Ihrem Telefon. Das Telefon und der Laptop stellen dann eine Bluetooth-Nahbereichsverbindung her, um die physische Nähe zu verifizieren — dies ist der Hybrid-Transport-Mechanismus, der im FIDO2 CTAP2-Protokoll definiert ist.

Die Bluetooth-Näheprüfung ist der kritische Sicherheitsschritt. Sie verhindert, dass ein entfernter Angreifer den QR-Code von einem anderen Standort aus verwendet. Ihr Telefon führt die biometrische Verifizierung lokal durch und sendet dann die signierte Challenge über den sicheren Bluetooth-Kanal zurück an den Laptop.

Bluetooth überträgt nicht Ihren Passkey. Es bestätigt, dass Ihr Telefon sich physisch neben dem Computer befindet — was die geräteübergreifende Authentifizierung auch bei Verwendung eines zweiten Geräts phishing-resistent macht.

Passkeys vs. Passwörter: Wichtige Unterschiede

Ein Passwort ist eine geheime Zeichenfolge, die Sie erstellen und an einen Server senden, um Ihre Identität zu verifizieren. Passwörter haben einen fundamentalen strukturellen Fehler: Sie sind geteilte Geheimnisse. Die Website speichert Ihr Passwort (oder einen Hash davon), was bedeutet, dass eine Serververletzung es offenlegt. Passkeys sind kryptographische Nachweise. Ihr Gerät hält den privaten Schlüssel; Dienste halten nur nutzlose öffentliche Schlüssel.

Cloudflares Daten vom März 2025 ergaben, dass ungefähr 41 % der erfolgreichen menschlichen Authentifizierungsversuche geleakte Anmeldedaten beinhalten. Diese Zahl spiegelt Jahre der Passwort-Wiederverwendung über verletzte Datenbanken wider.

Arten von Passkeys: Synchronisiert vs. gerätegebunden

Nicht alle Passkeys sind gleich. Die Unterscheidung zwischen synchronisierten und gerätegebundenen Passkeys ist sowohl für die Sicherheit als auch für die Compliance wichtig — und die meisten Leitfäden überspringen sie vollständig.

Synchronisierte Passkeys (Multi-Device FIDO Credentials)

Synchronisierte Passkeys werden in einem cloudbasierten Credential-Manager gespeichert und automatisch über alle Geräte in Ihrem Ökosystem synchronisiert. Erstellen Sie einen Passkey auf Ihrem iPhone, und er ist sofort auf Ihrem iPad und Mac verfügbar.

Diese Passkeys sind Ende-zu-Ende-verschlüsselt. Der Cloud-Anbieter kann sie nicht lesen. Gemäß NIST SP 800-63B-4 (veröffentlicht 2025) qualifizieren sich synchronisierte Passkeys als AAL2 (Authentication Assurance Level 2)-Authentifikatoren — geeignet für die meisten Verbraucher- und Unternehmensanwendungen.

Am besten für: Allgemeine Verbraucher, die meisten Unternehmensanwendungen, Dienste, bei denen geräteübergreifende Bequemlichkeit wichtig ist.

Gerätegebundene Passkeys

Gerätegebundene Passkeys werden auf einer bestimmten Hardware gespeichert — einem Hardware-Sicherheitsschlüssel wie einem YubiKey oder dem TPM-Chip in einem Windows-Gerät — und können nicht kopiert oder synchronisiert werden. Sie existieren nur auf diesem einen Gerät.

Gemäß NIST SP 800-63B-4 qualifizieren sich gerätegebundene Passkeys als AAL3 — das höchste Authentifizierungssicherheitsniveau, erforderlich für Regierungssysteme, Finanzinstitute und hochsichere Unternehmensumgebungen.

Am besten für: Privileged Access Management, regulierte Branchen, Regierungssysteme.

Sind Passkeys sicher?

Ja. Passkeys sind deutlich sicherer als Passwörter. Passkeys eliminieren konstruktionsbedingt ganze Kategorien von Angriffen. Sie sind konstruktionsbedingt phishing-resistent und immun gegen Credential Stuffing. Der private Schlüssel verlässt niemals das Gerät des Benutzers.

Diese Architektur, basierend auf Public-Key-Kryptographie, neutralisiert auch Serververletzungen. Dienste speichern nur öffentliche Schlüssel, die für Angreifer nutzlos sind. Selbst wenn eine Datenbank geleakt wird, bleiben die Anmeldedaten sicher.

Der 2025 Verizon DBIR zeigt, dass Credential-Diebstahl 88 % der Webanwendungsverletzungen antreibt. Passkeys machen diesen Vektor irrelevant. NIST SP 800-63B klassifiziert dieses Modell als phishing-resistent, das höchste Authentifizierungssicherheitsniveau.

Sicherheitsvorteile:

• Phishing unmöglich — kryptographisch an bestimmte Websites gebunden
• Kein Credential-Diebstahl — private Schlüssel verlassen niemals die Geräte
• Serververletzungen neutralisiert — nur öffentliche Schlüssel, nutzlos für Angreifer
• Keine Replay-Angriffe — Challenge-Response verhindert Wiederverwendung
• Biometrische Bindung — lokale Verifizierung, Biometrie wird niemals übertragen

Konstruktionsbedingt sicher

Passkeys bauen Sicherheit in die Architektur ein, nicht in das Benutzerverhalten. Mit Public-Key-Kryptographie verlässt der private Schlüssel niemals Ihr Gerät. Er bleibt in sicherer Hardware (TPM, Secure Enclave), die selbst dann unzugänglich ist, wenn Ihr Gerät kompromittiert wird. Der Dienst speichert nur den öffentlichen Schlüssel, der für Angreifer nutzlos ist.

Diese strukturelle Trennung ändert alles. Wenn Server verletzt werden, finden Angreifer nichts Nützliches.

WebAuthn fügt eine weitere Schicht hinzu: Website-Bindung. Während der Registrierung bindet sich der Passkey kryptographisch an die Domain. Wenn eine Phishing-Seite versucht, den Passkey zu verwenden, schlägt die Authentifizierung fehl; die kryptographische Signatur stimmt nicht mit der falschen Domain überein. NIST SP 800-63B erkennt dies als Verifier-Impersonation-Resistenz an, das höchste Sicherheitsniveau.

Sicherheit wird automatisch. Sie können nicht dazu gebracht werden, Anmeldedaten einzutippen, die nicht existieren. Sie können Passwörter nicht über Websites hinweg wiederverwenden. Sie können nicht auf gefälschte Anmeldeseiten hereinfallen. Die Kryptographie kooperiert einfach nicht.

Warum Passkeys phishing-resistent sind

Passkeys sind kryptographisch an die spezifische Domain gebunden, auf der sie erstellt wurden — zum Beispiel google.com. Wenn Ihr Browser die Challenge des Servers signiert, enthält er den Domainnamen in den signierten Daten. Wenn Sie auf einer gefälschten Seite landen (g00gle.com), funktioniert der Passkey für google.com einfach nicht — die Domain stimmt nicht überein. Es gibt kein Passwort, das Sie auf einer gefälschten Seite eintippen könnten.

Dies ist eine Eigenschaft, die SMS-basierte 2FA und sogar TOTP-Codes nicht bieten können. Diese können bei Echtzeit-Phishing-Angriffen abgefangen werden. Ein Passkey kann das nicht.

Können Passkeys gestohlen oder gehackt werden?

Der private Schlüssel befindet sich im Secure Enclave (Apple) oder TPM (Windows) des Geräts — hardware-isolierten Chips, die manipulationssicher konzipiert sind. Selbst wenn Malware das Gerät infiziert, kann sie den privaten Schlüssel nicht aus dem Secure Enclave extrahieren. Ein Angreifer müsste auch die biometrische Verifizierung bestehen, um den Passkey zu verwenden.

Konstruktionsbedingt privat

Passkeys schützen die Privatsphäre so grundlegend wie die Sicherheit. Ihr Fingerabdruck- oder Gesichtsscan verlässt niemals Ihr Gerät. Die biometrische Authentifizierung findet lokal statt. Der Dienst sieht niemals Ihre biometrischen Daten, nur dass Sie den Schlüssel entsperrt haben.

Public-Key-Kryptographie verhindert auch Tracking. Jeder Dienst erhält einen anderen öffentlichen Schlüssel. Anders als Passwörter (gleiche Anmeldedaten überall) oder Cookies können Passkeys Ihre Aktivitäten nicht über Websites hinweg verknüpfen. Google kann nicht sehen, was Sie bei Microsoft tun.

Dies entspricht den DSGVO-Prinzipien: minimale Datenerfassung, lokale Verarbeitung, Benutzerkontrolle. NIST-Richtlinien betonen ebenfalls datenschutzbewahrende Authentifizierung. Mit Passkeys beweisen Sie, wer Sie sind, ohne zu offenbaren, wer Sie sind.

Was passiert, wenn Sie Ihr Gerät verlieren?

Dies ist die Frage, die die meisten Menschen vom Wechsel abhält. Hier ist das vollständige Bild:

• Synchronisierte Passkeys — iCloud Keychain: Ihre Passkeys werden in iCloud Keychain gesichert, das Ende-zu-Ende-verschlüsselt ist. Apple bestätigt, dass Apple selbst Ihre Passkeys nicht lesen kann. Richten Sie ein neues iPhone ein, melden Sie sich mit Ihrer Apple ID an, und Ihre Passkeys werden automatisch wiederhergestellt. Apples iCloud Keychain Escrow-System erzwingt eine 10-Versuche-Grenze — nach 10 fehlgeschlagenen Wiederherstellungsversuchen wird der Datensatz dauerhaft zerstört. Zwei-Faktor-Authentifizierung ist für die Apple ID erforderlich.
• Synchronisierte Passkeys — Google Password Manager: Melden Sie sich mit Ihrem Google-Konto auf einem neuen Android-Gerät an, und Ihre Passkeys werden automatisch wiederhergestellt.
• Gerätegebundene Passkeys: Wenn Sie einen Hardware-Sicherheitsschlüssel verlieren, benötigen Sie ein Backup. Best Practice ist, zwei Hardware-Schlüssel für jedes Konto zu registrieren — halten Sie einen als Backup an einem sicheren Ort bereit.
• Kontowiederherstellungskontakte: Apple, Google und Microsoft unterstützen alle Wiederherstellungskontakte und Wiederherstellungscodes. Richten Sie diese ein, bevor Sie sie benötigen.

Die realen Vorteile von Passkeys: Daten 2025–2026

Der FIDO Alliance Passkey Index (Oktober 2025) aggregiert Leistungsdaten von Amazon, Google, Microsoft, PayPal, TikTok und fünf anderen großen Plattformen. Die Zahlen sind beeindruckend.

Passkey-Anmeldungen erreichen eine Erfolgsquote von 93 %, verglichen mit nur 63 % bei anderen Authentifizierungsmethoden — ein Unterschied von 30 Prozentpunkten. In Bezug auf Geschwindigkeit benötigen Passkeys durchschnittlich 8,5 Sekunden pro Anmeldung, verglichen mit 31,2 Sekunden für traditionelle MFA — eine Reduktion der Anmeldezeit um 73 %. Organisationen berichten von einer Reduktion der anmeldebezogenen Helpdesk-Vorfälle um bis zu 81 %, hauptsächlich Passwortzurücksetzungsanfragen.

Praxisbeispiele von der Authenticate 2025-Konferenz bestätigen diese Zahlen. Roblox erreichte eine 15%ige Reduktion von Kontoübernahmen nach der Implementierung von Passkeys in seinem Anmeldeablauf (Corbado, 2025). TikTok berichtete von einer 97%igen Passkey-Authentifizierungs-Erfolgsquote. VicRoads in Australien rollte Passkeys an 5 Millionen Benutzer mit einem schrittweisen, datengesteuerten Ansatz aus.

Die Akzeptanz durch Verbraucher beschleunigt sich ebenfalls. Die FIDO Alliance World Passkey Day Verbraucherumfrage (April 2025) ergab, dass 69 % der Verbraucher Passkeys auf mindestens einem Konto aktiviert haben und 74 % Passkeys kennen. Dieselbe Umfrage ergab, dass 47 % der Verbraucher einen Kauf abbrechen, wenn sie ihr Passwort vergessen — ein Konversionsproblem, das Passkeys eliminieren.

Einschränkungen und Nachteile von Passkeys

Passkeys lösen grundlegende Sicherheitsprobleme, sind aber noch nicht reibungslos. Die geräteübergreifende Synchronisation ist der größte Reibungspunkt. Apple synchronisiert über iCloud Keychain, Google über Password Manager, Microsoft über Windows Hello, und diese Ökosysteme kommunizieren nicht miteinander. iPhone-zu-Windows erfordert umständliche QR-Codes.

Die Kontowiederherstellung wird schwieriger. Verlieren Sie Ihr Telefon ohne Backups, und Sie könnten sich aussperren. Plattformanbieter bieten Wiederherstellungsoptionen an, aber Benutzer müssen diese proaktiv aktivieren.

Die Unterstützung von Legacy-Systemen bleibt unvollständig. Viele interne Apps, VPNs und ältere Websites akzeptieren keine Passkeys. Passwörter verschwinden nicht über Nacht.

Aktuelle Einschränkungen

• Das Schwachstellen-Problem. Die meisten Websites, die Passkeys unterstützen, erlauben immer noch Passwort-Login als Fallback. Das bedeutet, dass die Sicherheit des Kontos nur so stark ist wie die schwächste verfügbare Authentifizierungsmethode. Ein Angreifer, der den „Passwort vergessen"-Ablauf auslösen kann, kann den Passkey immer noch komplett umgehen. Bis Dienste den Passwort-Fallback entfernen, fügen Passkeys eine stärkere Option hinzu — sie eliminieren nicht die Passwort-Angriffsfläche.
• Ökosystemübergreifende Reibung. In iCloud Keychain gespeicherte Passkeys sind nicht automatisch auf Android verfügbar und umgekehrt. Ein Benutzer, der von iPhone zu Android wechselt, muss Passkeys auf der neuen Plattform neu registrieren. Passwort-Manager lösen dies, indem sie Passkeys in einem plattformunabhängigen Tresor speichern, was sie zur besseren Wahl für Benutzer macht, die über mehrere Ökosysteme hinweg arbeiten.
• Das Bootstrapping-Paradoxon. Um einen Passkey zu verwenden, benötigen Sie ein passkey-fähiges Gerät. Die Einrichtung eines neuen Geräts von Grund auf erfordert immer noch eine andere Möglichkeit zur Authentifizierung zuerst — typischerweise ein Passwort oder einen Wiederherstellungscode. Für Unternehmens-IT-Teams, die groß angelegte Rollouts verwalten, entsteht ein Henne-Ei-Problem: Passwörter können nicht vollständig eliminiert werden, bis jeder Benutzer einen Passkey registriert hat, aber die Registrierung erfordert die alten Anmeldedaten.
• Begrenzte Akzeptanz. Stand Anfang 2026 unterstützen 48 % der Top-100-Websites Passkeys. Die Mehrheit des Internets erfordert immer noch Passwörter. Passkeys und Passwörter werden jahrelang koexistieren — was bedeutet, dass Passwort-Management während der Übergangszeit ein echter operativer Bedarf bleibt.

Plattform-Credential-Manager — iCloud Keychain, Google Password Manager, Windows Hello — sind für einzelne Benutzer konzipiert, nicht für Organisationen. Sie bieten keine geteilten Tresore, rollenbasierten Zugriffskontrollen oder Audit-Logs. Wenn ein Mitarbeiter das Unternehmen verlässt, gibt es keine zentrale Möglichkeit, seine Passkeys zu widerrufen oder geteilte Anmeldedaten zu rotieren.

Für IT-Teams, die Dutzende von Systemen verwalten, ist das eine operative Lücke, keine geringfügige Unannehmlichkeit. Diese Koexistenz zu verwalten — Passkeys, wo unterstützt, starke Passwörter, wo nicht — ist genau das, wofür Passwork entwickelt wurde. Strukturierte Tresore, granulare Zugriffskontrollen und vollständige Audit-Trails halten Legacy-Anmeldedaten sicher, während Ihr Team Passkeys in seinem eigenen Tempo ausrollt.

Warum Organisationen immer noch einen Passwort-Manager benötigen

Passkeys lösen das Authentifizierungsproblem für unterstützte Dienste. Sie lösen nicht das Credential-Management-Problem für alles andere.

Betrachten Sie, was eine typische Unternehmensumgebung tatsächlich enthält: Dutzende von internen Tools, die Passkeys erst in Jahren unterstützen werden, geteilte Dienstkonten, die nicht an ein einzelnes Gerät gebunden werden können, API-Schlüssel und SSH-Anmeldedaten, die kein Passkey-Äquivalent haben, und Legacy-Systeme, bei denen das Authentifizierungsmodell festgelegt ist. Nichts davon verschwindet, wenn Sie Passkeys für Microsoft 365 und Google Workspace ausrollen.

Ein Unternehmens-Passwort-Manager handhabt, was Passkeys nicht können:

• Geteilte Anmeldedaten — Dienstkonten, Admin-Logins und Team-Passwörter benötigen kontrollierten Zugriff mit klarer Eigentümerschaft. Plattform-Keychains sind konstruktionsbedingt persönlich; sie haben kein Konzept für geteilte Tresore oder rollenbasierte Berechtigungen.
• Nicht-menschliche Identitäten — API-Schlüssel, SSH-Schlüssel, Datenbank-Anmeldedaten und CI/CD-Secrets lassen sich nicht auf die Biometrie eines Benutzers abbilden. Sie benötigen einen sicheren Ort mit Zugriffskontrollen und Rotationsrichtlinien.
• Legacy-Systeme — interne Tools, On-Premise-Anwendungen und ältere SaaS-Produkte werden jahrelang Passwörter erfordern. Diese Anmeldedaten benötigen dieselbe Sicherheitsdisziplin wie alles andere.
• Offboarding — wenn ein Mitarbeiter das Unternehmen verlässt, muss die IT den Zugriff widerrufen und geteilte Anmeldedaten sofort rotieren. Es gibt keine zentrale Möglichkeit, dies über iCloud Keychains oder Google-Konten hinweg zu tun.
• Audit-Trails — SOC 2, ISO 27001 und ähnliche Frameworks erfordern Nachweise darüber, wer wann auf was zugegriffen hat. Plattform-Credential-Manager erstellen dieses Protokoll nicht.
• Plattformübergreifende Umgebungen — Organisationen, die gleichzeitig Windows, macOS, Android und Linux betreiben, können sich nicht auf die native Synchronisation einer einzelnen Plattform verlassen. Ein herstellerneutraler Tresor deckt den gesamten Stack ab.

Die beiden Tools adressieren unterschiedliche Schichten desselben Problems. Passkeys handhaben die Benutzerauthentifizierung, wo der Standard unterstützt wird. Ein Passwort-Manager deckt den Rest ab — und hält die gesamte Credential-Oberfläche auditierbar.

Welche Dienste und Plattformen unterstützen derzeit Passkeys?

Alle großen Plattformen unterstützen jetzt Passkeys, obwohl die Implementierungsdetails variieren.

Apple speichert Passkeys in iCloud Keychain und synchronisiert sie Ende-zu-Ende-verschlüsselt über iPhones, iPads und Macs. Benutzer können sich mit Face ID oder Touch ID anmelden und ihr iPhone als Authentifikator für Nicht-Apple-Geräte über QR-Code verwenden.

Google integriert Passkeys über Google Password Manager auf Android und Chrome. Passkeys werden über Geräte synchronisiert, die im selben Google-Konto angemeldet sind, geschützt durch eine dedizierte PIN oder biometrische Entsperrung.

Microsoft unterstützt Passkeys über Windows Hello, Microsoft Authenticator und Entra ID. Windows 10/11-Geräte verwenden Biometrie oder PIN; die Authenticator-App speichert gerätegebundene Passkeys für Unternehmenskonten mit optionaler Cloud-Synchronisation für persönliche Konten.

Die FIDO Alliance zertifiziert Implementierungen und gewährleistet plattformübergreifende Interoperabilität. Die meisten modernen Browser (Chrome, Safari, Edge, Firefox) unterstützen WebAuthn, was Passkeys über Betriebssysteme hinweg nutzbar macht.

Geräte und Browser, die Passkeys unterstützen

Passkeys funktionieren auf modernen Plattformen, aber Versionsanforderungen sind wichtig. Hier ist die aktuelle Kompatibilitätslandschaft basierend auf unseren Tests über Gerätekombinationen hinweg.

Wichtige Erkenntnisse aus den Tests:

• Apples Ökosystem synchronisiert nahtlos über Apple-Geräte hinweg, benötigt aber QR-Codes für Nicht-Apple-Hardware.
• Android-Passkeys werden über Google-Konten synchronisiert, benötigen aber Geräte-Entsperrung für den Zugriff.
• Windows Hello bietet gerätegebundene Passkeys; Cloud-Synchronisation wird noch für persönliche Konten ausgerollt.
• Plattformübergreifende Abläufe funktionieren, fühlen sich aber weniger ausgereift an als die Synchronisation innerhalb eines Ökosystems.

WebAuthn ermöglicht diese plattformübergreifende Kompatibilität. Browser implementieren den Standard, sodass Passkeys trotz unterschiedlicher Synchronisations-Backends über Betriebssysteme hinweg funktionieren.

So beginnen Sie heute mit der Nutzung von Passkeys

Der Einstieg mit Passkeys dauert fünf Minuten. Hier ist der praktische Ablauf basierend auf der Einrichtung über Geräte hinweg.

Apple-Ökosystem (iPhone, iPad, Mac)

Passkeys auf Apple-Geräten werden in iCloud Keychain gespeichert und automatisch über alle Apple-Geräte synchronisiert, die mit derselben Apple ID angemeldet sind. Die Zwei-Faktor-Authentifizierung muss für die Apple ID aktiviert sein.

1. Besuchen Sie eine unterstützte Website und gehen Sie zu den Kontoeinstellungen oder der Registrierungsseite.
2. Suchen Sie nach der Option „Passkey erstellen" oder „Passkey hinzufügen".
3. Tippen Sie auf die Option. Der Browser fordert Sie auf, Face ID, Touch ID oder Ihren Geräte-Passcode zu verwenden.
4. Authentifizieren Sie sich mit Ihrer Biometrie. Der Passkey wird automatisch in iCloud Keychain gespeichert.
5. Bei zukünftigen Anmeldungen tippen Sie auf „Mit Passkey anmelden" und authentifizieren sich mit Face ID oder Touch ID.

Android (Google Password Manager)

Passkeys auf Android werden im Google Password Manager gespeichert und über Android-Geräte synchronisiert, die mit demselben Google-Konto angemeldet sind. Wenn eine Website anbietet, einen Passkey zu erstellen, fordert Android Sie auf, ihn im Google Password Manager zu speichern. Authentifizieren Sie sich mit Fingerabdruck, Gesichtserkennung oder Ihrer Bildschirmsperre-PIN.

Windows (Windows Hello / Microsoft Authenticator)

Unter Windows 11 können Passkeys in Windows Hello gespeichert werden — unter Verwendung des TPM-Chips des Geräts — oder in der Microsoft Authenticator-App. Windows Hello-Passkeys sind standardmäßig gerätegebunden, was bedeutet, dass sie gemäß NIST SP 800-63B-4 als AAL3 qualifiziert sind.

Wenn eine Website anbietet, einen Passkey zu erstellen, fordert Windows Sie auf, ihn mit Windows Hello zu speichern. Authentifizieren Sie sich mit Ihrer Windows Hello-PIN, Fingerabdruck oder Gesichtserkennung.

Passwort-Manager

Für Organisationen, die Anmeldedaten in großem Maßstab verwalten, bietet ein Unternehmens-Passwort-Manager wie Passwork die Infrastruktur, um sowohl Legacy-Passwörter als auch den Übergang zu Passkeys zu handhaben — und hält Anmeldedaten während der gesamten Migration sicher und auditierbar.

Tipps aus den Tests:

• Beginnen Sie mit Diensten, die Sie täglich nutzen, aber nicht geschäftskritisch sind.
• Behalten Sie ein Gerät als Backup, bevor Sie Passwörter entfernen.
• Testen Sie die Wiederherstellung, bevor Sie sie benötigen.
• Unternehmensbenutzer sollten die Kompatibilität mit bestehendem SSO überprüfen.

Welche Websites und Apps unterstützen Passkeys?

Stand Anfang 2026 unterstützen die wichtigsten Plattformen Passkeys, darunter: Google, Apple ID, Microsoft, Amazon, PayPal, GitHub, Shopify, Adobe, Uber, TikTok, eBay, Roblox, Coinbase, Best Buy und viele andere.

Das von der Community gepflegte Verzeichnis unter passkeys.directory bietet eine aktuelle, durchsuchbare Liste aller Websites und Apps, die Passkeys unterstützen.

Fazit

Passwörter verschwinden dieses Jahr nicht. Aber die Richtung ist klar: Über 15 Milliarden Konten unterstützen bereits Passkeys, 87 % der Unternehmen setzen sie ein, und die Lücke bei der Authentifizierungserfolgsquote — 93 % vs. 63 % — macht den Fall besser als jede Marketing-Behauptung es könnte.

Passkeys sind jetzt verfügbar, auf Geräten, die Menschen bereits besitzen, für Dienste, die sie bereits nutzen. Die Technologie ist ausgereift. Die Standards sind festgelegt. Die verbleibende Reibung ist Akzeptanz, nicht Fähigkeit.

Der Übergang von Passwörtern zu Passkeys wird Jahre dauern, nicht Monate. Während dieser Zeit werden die meisten Organisationen hybride Umgebungen betreiben: Passkeys für einige Dienste, Passwörter für andere, Dienstkonten, die in keines der beiden Modelle passen. Die Sicherheitslage des Ganzen hängt davon ab, wie gut Sie die Teile verwalten, die sich noch nicht bewegt haben.

Passwork ist für diese Zeit entwickelt — strukturierte Tresore, Zugriffskontrollen und Audit-Trails, die Legacy-Anmeldedaten unter Kontrolle halten, während die Passkey-Registrierung in Ihrem Team skaliert.

Der Wechsel von Passwörtern zu Passkeys ist ein Prozess, kein Schalter. Die Organisationen, die ihn bewusst verwalten, werden zu einer bedeutend stärkeren Sicherheitslage gelangen — mit weniger Reibung für Benutzer und weniger Vorfällen für IT-Teams.

Häufig gestellte Fragen

Social Engineering vs. Phishing-Angriffe: Wichtige Unterschiede & Verteidigungsstrategien | Expertenleitfaden

Phishing ist Social Engineering — aber Social Engineering ist viel mehr als Phishing. Erfahren Sie den Unterschied, sehen Sie, wie KI beide Bedrohungen verändert, und bauen Sie Abwehrmaßnahmen auf, die die gesamte Angriffsfläche abdecken.

Passwork BlogAlex Muntyan

Was ist Privileged Access Management? Ein vollständiger Leitfaden

Privilegierte Konten sind die wertvollsten Ziele für Angreifer. Ein kompromittiertes Admin-Credential gibt volle Kontrolle über Infrastruktur, Daten und Anwendungen. PAM adressiert dies durch Credential-Vaulting, Sitzungsüberwachung und Durchsetzung des Prinzips der geringsten Privilegien. So funktioniert es in der Praxis.

Passwork BlogAlex Muntyan

Enterprise Passwort-Management Best Practices: Der Sicherheitsleitfaden 2026

Wenn Ihre Passwortrichtlinie immer noch 90-Tage-Rotationen und acht Zeichen Minimum vorschreibt, ist sie veraltet. Dieser Leitfaden behandelt Enterprise Passwort-Management Best Practices für 2026: Richtlinien, privilegierte Konten, nicht-menschliche Identitäten, MFA und Compliance.

Passwork BlogAlex Muntyan

Una passkey es una credencial de autenticación sin contraseñas y resistente al phishing, basada en criptografía de clave pública. Cuando crea una passkey, su dispositivo genera un par de claves criptográficas único: una clave pública almacenada en el servidor del sitio web y una clave privada que nunca abandona su dispositivo. Inicia sesión verificando su identidad con biometría o un PIN.

Este enfoque, estandarizado por la FIDO Alliance y fundamental para la autenticación sin contraseñas, previene el phishing y el robo de credenciales porque la clave privada nunca abandona su dispositivo. El modelo se alinea con las directrices NIST SP 800-63B-4 y los requisitos de privacidad del GDPR.

En la práctica, la mayoría de las organizaciones operan en entornos mixtos — algunos servicios ya admiten passkeys, otros no lo harán durante años. Un enfoque estructurado de gestión de credenciales abarca ambos casos.

Esta guía cubre todo: cómo funcionan las passkeys técnicamente, la diferencia entre passkeys sincronizadas y vinculadas al dispositivo, cómo configurarlas en iPhone, Android y Windows, y qué dicen los datos más recientes de 2025–2026 sobre el rendimiento en el mundo real.

Puntos clave

• Las passkeys utilizan criptografía de clave pública: la clave privada permanece en su dispositivo; el servidor solo almacena la clave pública.
• Las passkeys son resistentes al phishing por diseño — un sitio web falso no puede solicitar la firma de su passkey.
• Los inicios de sesión con passkey logran una tasa de éxito del 93%, comparado con el 63% de otros métodos de autenticación (FIDO Alliance Passkey Index, octubre de 2025).
• Si pierde su dispositivo, las passkeys sincronizadas son recuperables a través de iCloud Keychain o la recuperación de cuenta de Google.
• A finales de 2024, más de 15 mil millones de cuentas admiten passkeys, y la adopción se duplicó durante ese año (FIDO Alliance, diciembre de 2024).

¿Qué es una passkey?

Una passkey es un par de claves criptográficas almacenado en su dispositivo. La FIDO Alliance — el consorcio de la industria detrás del estándar — define las passkeys como credenciales que «reemplazan las contraseñas con pares de claves criptográficas para seguridad de inicio de sesión resistente al phishing y una experiencia de usuario mejorada».

Las passkeys implementan el estándar FIDO2, con WebAuthn gestionando la comunicación entre el navegador y el dispositivo. Cuando crea una passkey, su dispositivo genera dos claves matemáticamente vinculadas: una permanece en su dispositivo (privada), otra va al sitio web (pública).

Para iniciar sesión, demuestra que posee la clave privada resolviendo un desafío criptográfico — utilizando su rostro, huella dactilar o PIN. El sitio web verifica su respuesta utilizando la clave pública que ya tiene.

La clave privada nunca abandona su dispositivo. El servidor nunca la ve. No hay nada en el lado del servidor que valga la pena robar.

Las passkeys en términos simples

Una passkey es algo que tiene (su dispositivo) más algo que es (su huella dactilar o rostro). Su teléfono genera la passkey, y usted la desbloquea con biometría. 

El servicio nunca ve su huella dactilar o rostro, solo que usted desbloqueó la clave. Piense en ello como una tarjeta de hotel: tiene la tarjeta, y la puerta se abre cuando la toca. No hay código que recordar, nada que escribir, nada que robar de forma remota.

El problema con las contraseñas tradicionales

Las contraseñas tienen un defecto fundamental: son secretos que deben compartirse. Cada vez que escribe una, viaja a través de redes y se almacena en servidores. El 2025 Verizon DBIR encontró que más del 53% de las filtraciones de datos involucran credenciales robadas o descifradas por fuerza bruta.

Los usuarios agravan el problema. La reutilización de contraseñas es desenfrenada — una filtración en un servicio se propaga a cuentas comprometidas en todas partes. El phishing explota esto aún más: páginas de inicio de sesión falsas engañan a los usuarios para que escriban credenciales, dando a los atacantes acceso directo. Añada la fatiga de contraseñas, y obtendrá notas adhesivas o variantes de «Company2024».

Problemas comunes con las contraseñas:

• Reutilización — una filtración desbloquea múltiples cuentas.
• Contraseñas débiles — «123456» todavía domina.
• Vulnerabilidad al phishing — sitios falsos capturan credenciales escritas.
• Exposición del lado del servidor — las bases de datos filtradas se descifran.
• Carga de memoria — los usuarios restablecen, anotan o simplifican.

Con las passkeys, no hay contraseña que recordar, no hay contraseña que robar y no hay base de datos del servidor que vulnerar.

Cómo funcionan realmente las passkeys

Las passkeys utilizan criptografía de clave pública en lugar de secretos compartidos. Piense en ello como un buzón físico: la clave pública es la ranura por donde cualquiera puede dejar un mensaje, y la clave privada es la llave que abre el buzón. Solo la persona con la clave privada puede leer lo que hay dentro.

Cuando inicia sesión con una passkey, el servicio o sitio web envía un desafío — una cadena de datos única y aleatoria. Su dispositivo utiliza la clave privada para firmar ese desafío matemáticamente. El sitio web luego verifica la firma contra la clave pública que almacenó durante el registro. Si la firma es válida, tiene acceso.

La FIDO Alliance estandariza esto a través de FIDO2. WebAuthn gestiona la comunicación entre el navegador y el dispositivo. NIST reconoce este modelo como resistente al phishing.

Paso a paso:

1. El dispositivo crea el par de claves
2. La clave privada permanece en el dispositivo
3. La clave pública se envía al servicio
4. El servicio envía un desafío
5. Usted aprueba con biometría
6. El dispositivo firma el desafío
7. El servicio valida la firma
8. Tiene acceso

Paso 1. El proceso de registro

El proceso de crear una passkey se denomina ceremonia de registro en la especificación WebAuthn — la API web del W3C que implementa FIDO2 en navegadores.

Esto es lo que sucede:

1. Visita un sitio web y elige crear una passkey.
2. El sitio web envía una solicitud de registro a su navegador a través de la API WebAuthn.
3. Su navegador le solicita que verifique su identidad — Face ID, huella dactilar o PIN.
4. Su dispositivo genera un par de claves pública/privada único específicamente para este sitio web.
5. La clave pública se envía al servidor del sitio web y se almacena. La clave privada se guarda en el hardware seguro de su dispositivo — el Secure Enclave en dispositivos Apple, o el chip TPM (Trusted Platform Module) en Windows.

Apple, Google y Microsoft implementan esto a través de APIs específicas de la plataforma (iCloud Keychain, Google Password Manager, Windows Hello), pero todos siguen los estándares FIDO2 y WebAuthn. Sus datos biométricos nunca abandonan su dispositivo, solo la prueba criptográfica de que autorizó la creación de la clave.

Paso 2. El proceso de autenticación

Iniciar sesión con una passkey — la ceremonia de autenticación — es igualmente sencillo:

1. Visita el sitio web y hace clic en «Iniciar sesión con passkey».
2. El sitio web envía un desafío único y aleatorio a su navegador.
3. Su navegador le solicita que verifique su identidad (biometría o PIN).
4. Su dispositivo utiliza la clave privada para firmar criptográficamente el desafío.
5. El desafío firmado vuelve al servidor. El servidor verifica la firma utilizando la clave pública almacenada. Si coincide, se concede el acceso.

WebAuthn estandariza este flujo en navegadores y plataformas. La clave privada nunca abandona su dispositivo, y el mecanismo de desafío-respuesta previene ataques de repetición.

El desafío es único cada vez. Incluso si un atacante intercepta la respuesta firmada, no puede reutilizarla — está matemáticamente vinculada a esa única sesión.

Autenticación entre dispositivos: códigos QR y Bluetooth

Aquí hay un escenario que confunde a muchos usuarios: está en un portátil Windows, pero su passkey está almacenada en su iPhone. ¿Qué sucede?

El navegador muestra un código QR. Lo escanea con su teléfono. El teléfono y el portátil luego establecen una conexión Bluetooth de corto alcance para verificar la proximidad física — este es el mecanismo de transporte híbrido definido en el protocolo FIDO2 CTAP2.

La verificación de proximidad por Bluetooth es el paso de seguridad crítico. Evita que un atacante remoto utilice el código QR desde una ubicación diferente. Su teléfono realiza la verificación biométrica localmente, luego envía el desafío firmado de vuelta al portátil a través del canal Bluetooth seguro.

Bluetooth no está transmitiendo su passkey. Está confirmando que su teléfono está físicamente junto a la computadora — lo que hace que la autenticación entre dispositivos sea resistente al phishing incluso cuando se utiliza un segundo dispositivo.

Passkeys vs. contraseñas: diferencias clave

Una contraseña es una cadena secreta de caracteres que usted crea y envía a un servidor para verificar su identidad. Las contraseñas tienen un defecto estructural fundamental: son secretos compartidos. El sitio web almacena su contraseña (o un hash de ella), lo que significa que una filtración del servidor la expone. Las passkeys son pruebas criptográficas — su dispositivo guarda la clave privada; los servicios solo guardan claves públicas inútiles.

Los datos de Cloudflare de marzo de 2025 encontraron que aproximadamente el 41% de los intentos exitosos de autenticación humana involucran credenciales filtradas. Ese número refleja años de reutilización de contraseñas en bases de datos vulneradas.

Tipos de passkeys: sincronizadas vs. vinculadas al dispositivo

No todas las passkeys son iguales. La distinción entre passkeys sincronizadas y vinculadas al dispositivo importa tanto para la seguridad como para el cumplimiento — y la mayoría de las guías la omiten por completo.

Passkeys sincronizadas (credenciales FIDO multidispositivo)

Las passkeys sincronizadas se almacenan en un gestor de credenciales basado en la nube y se sincronizan automáticamente en todos los dispositivos de su ecosistema. Cree una passkey en su iPhone, y estará inmediatamente disponible en su iPad y Mac.

Estas passkeys están cifradas de extremo a extremo. El proveedor de la nube no puede leerlas. A partir de NIST SP 800-63B-4 (publicado en 2025), las passkeys sincronizadas califican como autenticadores AAL2 (Nivel de Garantía de Autenticación 2) — apropiadas para la mayoría de los casos de uso de consumidores y empresas.

Ideal para: Consumidores en general, la mayoría de las aplicaciones empresariales, servicios donde la comodidad entre dispositivos importa.

Passkeys vinculadas al dispositivo

Las passkeys vinculadas al dispositivo se almacenan en una pieza específica de hardware — una llave de seguridad de hardware como un YubiKey, o el chip TPM en un dispositivo Windows — y no pueden copiarse ni sincronizarse. Existen solo en ese único dispositivo.

Según NIST SP 800-63B-4, las passkeys vinculadas al dispositivo califican como AAL3 — el nivel más alto de garantía de autenticación, requerido para sistemas gubernamentales, instituciones financieras y entornos empresariales de alta seguridad.

Ideal para: Gestión de acceso privilegiado, industrias reguladas, sistemas gubernamentales.

¿Son seguras las passkeys?

Sí. Las passkeys son significativamente más seguras que las contraseñas. Las passkeys eliminan categorías enteras de ataques por diseño. Son resistentes al phishing por diseño e inmunes al credential stuffing. La clave privada nunca abandona el dispositivo del usuario.

Esta arquitectura, construida sobre criptografía de clave pública, también neutraliza las filtraciones de servidores. Los servicios almacenan solo claves públicas, inútiles para los atacantes. Incluso si una base de datos se filtra, las credenciales permanecen seguras.

El 2025 Verizon DBIR muestra que el robo de credenciales impulsa el 88% de las filtraciones de aplicaciones web. Las passkeys hacen que ese vector sea irrelevante. NIST SP 800-63B clasifica este modelo como resistente al phishing, el nivel más alto de garantía de autenticación.

Beneficios de seguridad:

• Phishing imposible — vinculadas criptográficamente a sitios específicos
• Sin robo de credenciales — las claves privadas nunca abandonan los dispositivos
• Filtraciones de servidores neutralizadas — solo claves públicas, inútiles para los atacantes
• Sin ataques de repetición — el desafío-respuesta previene la reutilización
• Vinculación biométrica — verificación local, la biometría nunca se transmite

Segura por diseño

Las passkeys incorporan la seguridad en la arquitectura, no en el comportamiento del usuario. Con criptografía de clave pública, la clave privada nunca abandona su dispositivo. Permanece en hardware seguro (TPM, Secure Enclave) inaccesible incluso si su dispositivo está comprometido. El servicio almacena solo la clave pública, inútil para los atacantes.

Esta separación estructural lo cambia todo. Cuando los servidores son vulnerados, los atacantes no encuentran nada útil.

WebAuthn añade otra capa: vinculación al sitio. Durante el registro, la passkey se vincula criptográficamente al dominio. Si un sitio de phishing intenta usar la passkey, la autenticación falla; la firma criptográfica no coincidirá con el dominio incorrecto. NIST SP 800-63B reconoce esto como resistencia a la suplantación del verificador, el nivel más alto de garantía.

La seguridad se vuelve automática. No se le puede engañar para que escriba credenciales que no existen. No puede reutilizar contraseñas entre sitios. No puede caer en páginas de inicio de sesión falsas. La criptografía simplemente no cooperará.

Por qué las passkeys son resistentes al phishing

Las passkeys están vinculadas criptográficamente al dominio específico donde fueron creadas — por ejemplo, google.com. Cuando su navegador firma el desafío del servidor, incluye el nombre del dominio en los datos firmados. Si llega a un sitio falso (g00gle.com), la passkey para google.com simplemente no funcionará — el dominio no coincide. No hay contraseña para engañarle y que la escriba en una página falsa.

Esta es una propiedad que 2FA basado en SMS e incluso códigos TOTP no pueden ofrecer. Estos pueden ser interceptados en ataques de phishing en tiempo real. Una passkey no puede serlo.

¿Pueden las passkeys ser robadas o hackeadas?

La clave privada reside en el Secure Enclave del dispositivo (Apple) o TPM (Windows) — chips aislados por hardware diseñados para ser resistentes a manipulaciones. Incluso si un malware infecta el dispositivo, no puede extraer la clave privada del Secure Enclave. Un atacante también necesitaría pasar la verificación biométrica para usar la passkey.

Privada por diseño

Las passkeys protegen la privacidad tan fundamentalmente como la seguridad. Su escaneo de huella dactilar o rostro nunca abandona su dispositivo. La autenticación biométrica ocurre localmente. El servicio nunca ve sus datos biométricos, solo que usted desbloqueó la clave.

La criptografía de clave pública también previene el rastreo. Cada servicio obtiene una clave pública diferente. A diferencia de las contraseñas (la misma credencial en todas partes) o las cookies, las passkeys no pueden vincular su actividad entre sitios. Google no puede ver lo que hace en Microsoft.

Esto se alinea con los principios del GDPR: recopilación mínima de datos, procesamiento local, control del usuario. Las directrices de NIST igualmente enfatizan la autenticación que preserva la privacidad. Con las passkeys, demuestra quién es sin revelar quién es.

¿Qué sucede si pierde su dispositivo?

Esta es la pregunta que detiene a la mayoría de las personas de cambiar. Aquí está el panorama completo:

• Passkeys sincronizadas — iCloud Keychain: Sus passkeys están respaldadas en iCloud Keychain, que está cifrado de extremo a extremo. Apple confirma que Apple misma no puede leer sus passkeys. Configure un nuevo iPhone, inicie sesión en su Apple ID, y sus passkeys se restauran automáticamente. El sistema de custodia de iCloud Keychain de Apple aplica un límite de 10 intentos — después de 10 intentos de recuperación fallidos, el registro se destruye permanentemente. Se requiere autenticación de dos factores en el Apple ID.
• Passkeys sincronizadas — Google Password Manager: Inicie sesión en su cuenta de Google en un nuevo dispositivo Android y sus passkeys se restauran automáticamente.
• Passkeys vinculadas al dispositivo: Si pierde una llave de seguridad de hardware, necesita una copia de seguridad. La mejor práctica es registrar dos llaves de hardware para cada cuenta — mantenga una como copia de seguridad en una ubicación segura.
• Contactos de recuperación de cuenta: Apple, Google y Microsoft admiten contactos de recuperación y códigos de recuperación. Configúrelos antes de necesitarlos.

Los beneficios reales de las passkeys: datos 2025–2026

El FIDO Alliance Passkey Index (octubre de 2025) agrega datos de rendimiento de Amazon, Google, Microsoft, PayPal, TikTok y otras cinco plataformas principales. Los números son sorprendentes.

Los inicios de sesión con passkey logran una tasa de éxito del 93%, comparado con solo el 63% para otros métodos de autenticación — una diferencia de 30 puntos porcentuales. En términos de velocidad, las passkeys toman un promedio de 8,5 segundos por inicio de sesión, comparado con 31,2 segundos para MFA tradicional — una reducción del 73% en el tiempo de inicio de sesión. Las organizaciones reportan hasta un 81% de reducción en incidentes de soporte técnico relacionados con el inicio de sesión, principalmente solicitudes de restablecimiento de contraseña.

Los casos de estudio del mundo real de la conferencia Authenticate 2025 refuerzan estas cifras. Roblox logró una reducción del 15% en la apropiación de cuentas después de implementar passkeys en su flujo de registro (Corbado, 2025). TikTok reportó una tasa de éxito de autenticación con passkey del 97%. VicRoads en Australia implementó passkeys para 5 millones de usuarios utilizando un enfoque gradual basado en datos.

La adopción por parte de los consumidores también se está acelerando. La Encuesta de Consumidores del Día Mundial de la Passkey de FIDO Alliance (abril de 2025) encontró que el 69% de los consumidores han habilitado passkeys en al menos una cuenta, y el 74% conocen las passkeys. La misma encuesta encontró que el 47% de los consumidores abandonarán una compra si olvidan su contraseña — un problema de conversión que las passkeys eliminan.

Limitaciones y desventajas de las passkeys

Las passkeys resuelven problemas de seguridad fundamentales pero aún no son completamente fluidas. La sincronización entre dispositivos es el mayor punto de fricción. Apple sincroniza a través de iCloud Keychain, Google a través de Password Manager, Microsoft a través de Windows Hello, y estos ecosistemas no se comunican. iPhone a Windows necesita códigos QR poco prácticos.

La recuperación de cuentas se vuelve más complicada. Pierda su teléfono sin copias de seguridad, y podría quedarse bloqueado. Los proveedores de plataformas ofrecen opciones de recuperación, pero los usuarios deben habilitarlas proactivamente.

El soporte para sistemas heredados sigue siendo incompleto. Muchas aplicaciones internas, VPNs y sitios más antiguos no aceptan passkeys. Las contraseñas no van a desaparecer de la noche a la mañana.

Limitaciones actuales

• El problema del eslabón más débil. La mayoría de los sitios web que admiten passkeys todavía permiten el inicio de sesión con contraseña como respaldo. Esto significa que la seguridad de la cuenta es solo tan fuerte como el método de autenticación más débil disponible. Un atacante que pueda activar el flujo «olvidé mi contraseña» todavía puede eludir la passkey por completo. Hasta que los servicios eliminen el respaldo de contraseña, las passkeys añaden una opción más fuerte — no eliminan la superficie de ataque de contraseñas.
• Fricción entre ecosistemas. Las passkeys almacenadas en iCloud Keychain no están automáticamente disponibles en Android, y viceversa. Un usuario que cambia de iPhone a Android debe volver a registrar las passkeys en la nueva plataforma. Los gestores de contraseñas resuelven esto almacenando passkeys en una bóveda agnóstica de plataforma, haciéndolos la mejor opción para usuarios que trabajan en múltiples ecosistemas.
• La paradoja del arranque. Para usar una passkey, necesita un dispositivo compatible con passkeys. Configurar un nuevo dispositivo desde cero todavía requiere otra forma de autenticarse primero — típicamente una contraseña o un código de recuperación. Para equipos de TI empresarial que gestionan implementaciones a gran escala, esto crea un problema del huevo y la gallina: no se pueden eliminar completamente las contraseñas hasta que cada usuario haya registrado una passkey, pero el registro requiere las credenciales antiguas.
• Adopción limitada. A principios de 2026, el 48% de los 100 principales sitios web admiten passkeys. La mayoría de internet todavía requiere contraseñas. Las passkeys y las contraseñas coexistirán durante años — lo que significa que la gestión de contraseñas sigue siendo una necesidad operativa real durante la transición.

Los gestores de credenciales de plataforma — iCloud Keychain, Google Password Manager, Windows Hello — están diseñados para usuarios individuales, no para organizaciones. No ofrecen bóvedas compartidas, controles de acceso basados en roles ni registros de auditoría. Cuando un empleado se va, no hay forma centralizada de revocar sus passkeys o rotar credenciales compartidas.

Para equipos de TI que gestionan docenas de sistemas, esa es una brecha operativa, no un inconveniente menor. Gestionar esa coexistencia — passkeys donde estén soportadas, contraseñas fuertes donde no — es exactamente para lo que Passwork está diseñado. Bóvedas estructuradas, controles de acceso granulares y registros de auditoría completos mantienen las credenciales heredadas seguras mientras su equipo implementa passkeys a su propio ritmo.

Por qué las organizaciones todavía necesitan un gestor de contraseñas

Las passkeys resuelven el problema de autenticación para los servicios soportados. No resuelven el problema de gestión de credenciales para todo lo demás.

Considere lo que un entorno empresarial típico realmente contiene: docenas de herramientas internas que no soportarán passkeys durante años, cuentas de servicio compartidas que no pueden vincularse a un solo dispositivo, claves API y credenciales SSH que no tienen equivalente en passkey, y sistemas heredados donde el modelo de autenticación es fijo. Nada de eso desaparece cuando implementa passkeys para Microsoft 365 y Google Workspace.

Un gestor de contraseñas corporativo maneja lo que las passkeys no pueden:

• Credenciales compartidas — las cuentas de servicio, inicios de sesión de administrador y contraseñas de equipo necesitan acceso controlado con propiedad clara. Los llaveros de plataforma son personales por diseño; no tienen concepto de bóvedas compartidas o permisos basados en roles.
• Identidades no humanas — las claves API, claves SSH, credenciales de bases de datos y secretos de CI/CD no se mapean a la biometría de un usuario. Necesitan un hogar seguro con controles de acceso y políticas de rotación.
• Sistemas heredados — las herramientas internas, aplicaciones on-premise y productos SaaS más antiguos seguirán requiriendo contraseñas durante años. Esas credenciales necesitan la misma disciplina de seguridad que todo lo demás.
• Desvinculación — cuando un empleado se va, TI necesita revocar el acceso y rotar las credenciales compartidas inmediatamente. No hay forma centralizada de hacer eso a través de iCloud Keychains o cuentas de Google.
• Registros de auditoría — SOC 2, ISO 27001 y marcos similares requieren evidencia de quién accedió a qué y cuándo. Los gestores de credenciales de plataforma no producen ese registro.
• Entornos multiplataforma — las organizaciones que ejecutan Windows, macOS, Android y Linux simultáneamente no pueden depender de la sincronización nativa de ninguna plataforma individual. Una bóveda agnóstica de proveedor cubre toda la pila.

Las dos herramientas abordan diferentes capas del mismo problema. Las passkeys manejan la autenticación de usuario donde el estándar es soportado. Un gestor de contraseñas cubre el resto — y mantiene toda la superficie de credenciales auditable.

¿Qué servicios y plataformas admiten actualmente passkeys?

Todas las principales plataformas ahora admiten passkeys, aunque los detalles de implementación varían.

Apple almacena las passkeys en iCloud Keychain, sincronizando cifrado de extremo a extremo a través de iPhones, iPads y Macs. Los usuarios pueden iniciar sesión con Face ID o Touch ID, y usar su iPhone como autenticador para dispositivos que no son Apple mediante código QR.

Google integra las passkeys a través de Google Password Manager en Android y Chrome. Las passkeys se sincronizan entre dispositivos conectados a la misma cuenta de Google, protegidas por un PIN dedicado o desbloqueo biométrico.

Microsoft admite passkeys a través de Windows Hello, Microsoft Authenticator y Entra ID. Los dispositivos Windows 10/11 usan biometría o PIN; la aplicación Authenticator almacena passkeys vinculadas al dispositivo para cuentas empresariales, con sincronización en la nube opcional para cuentas personales.

La FIDO Alliance certifica las implementaciones, asegurando la interoperabilidad entre plataformas. La mayoría de los navegadores modernos (Chrome, Safari, Edge, Firefox) admiten WebAuthn, haciendo que las passkeys sean utilizables en todos los sistemas operativos.

Dispositivos y navegadores que admiten passkeys

Las passkeys funcionan en plataformas modernas, pero los requisitos de versión importan. Aquí está el panorama actual de compatibilidad basado en nuestras pruebas en combinaciones de dispositivos.

Hallazgos clave de las pruebas:

• El ecosistema de Apple sincroniza sin problemas entre dispositivos Apple pero necesita códigos QR para hardware que no es Apple.
• Las passkeys de Android se sincronizan a través de cuentas de Google pero necesitan desbloqueo del dispositivo para acceder.
• Windows Hello ofrece passkeys vinculadas al dispositivo; la sincronización en la nube todavía se está implementando para cuentas personales.
• Los flujos entre plataformas funcionan pero se sienten menos pulidos que la sincronización dentro del ecosistema.

WebAuthn habilita esta compatibilidad entre plataformas — los navegadores implementan el estándar, así que las passkeys funcionan en todos los sistemas operativos a pesar de los diferentes backends de sincronización.

Cómo empezar a usar passkeys hoy

Comenzar con passkeys toma cinco minutos. Aquí está el flujo práctico basado en configurarlas en diferentes dispositivos.

Ecosistema Apple (iPhone, iPad, Mac)

Las passkeys en dispositivos Apple se almacenan en iCloud Keychain y se sincronizan automáticamente en todos los dispositivos Apple conectados al mismo Apple ID. La autenticación de dos factores debe estar habilitada en el Apple ID.

1. Visite un sitio web compatible y vaya a la configuración de la cuenta o la página de registro.
2. Busque una opción «Crear una passkey» o «Añadir una passkey».
3. Toque la opción. El navegador le solicita usar Face ID, Touch ID o el código de su dispositivo.
4. Autentíquese con su biometría. La passkey se guarda en iCloud Keychain automáticamente.
5. En futuros inicios de sesión, toque «Iniciar sesión con passkey» y autentíquese con Face ID o Touch ID.

Android (Google Password Manager)

Las passkeys en Android se almacenan en Google Password Manager y se sincronizan entre dispositivos Android conectados a la misma cuenta de Google. Cuando un sitio web ofrece crear una passkey, Android le solicita guardarla en Google Password Manager. Autentíquese con huella dactilar, reconocimiento facial o el PIN de bloqueo de pantalla.

Windows (Windows Hello / Microsoft Authenticator)

En Windows 11, las passkeys pueden almacenarse en Windows Hello — usando el chip TPM del dispositivo — o en la aplicación Microsoft Authenticator. Las passkeys de Windows Hello están vinculadas al dispositivo por defecto, lo que significa que califican como AAL3 bajo NIST SP 800-63B-4.

Cuando un sitio web ofrece crear una passkey, Windows le solicita guardarla con Windows Hello. Autentíquese con su PIN de Windows Hello, huella dactilar o reconocimiento facial.

Gestor de contraseñas

Para organizaciones que gestionan credenciales a escala, un gestor de contraseñas corporativo como Passwork proporciona la infraestructura para manejar tanto contraseñas heredadas como la transición a passkeys — manteniendo las credenciales seguras y auditables durante toda la migración.

Consejos de las pruebas:

• Comience con servicios que usa diariamente pero que no son críticos para el negocio.
• Mantenga un dispositivo como copia de seguridad antes de eliminar contraseñas.
• Pruebe la recuperación antes de necesitarla.
• Los usuarios empresariales deben verificar la compatibilidad con el SSO existente.

¿Qué sitios web y aplicaciones admiten passkeys?

A principios de 2026, las principales plataformas que admiten passkeys incluyen: Google, Apple ID, Microsoft, Amazon, PayPal, GitHub, Shopify, Adobe, Uber, TikTok, eBay, Roblox, Coinbase, Best Buy y muchos otros.

El directorio mantenido por la comunidad en passkeys.directory proporciona una lista actual y consultable de cada sitio web y aplicación que admite passkeys.

Conclusión

Las contraseñas no van a desaparecer este año. Pero la dirección es clara: más de 15 mil millones de cuentas ya admiten passkeys, el 87% de las empresas las están implementando, y la diferencia en la tasa de éxito de autenticación — 93% vs. 63% — hace el caso mejor de lo que cualquier afirmación de marketing podría.

Las passkeys están disponibles ahora, en dispositivos que las personas ya poseen, para servicios que ya usan. La tecnología está madura. Los estándares están establecidos. La fricción restante es la adopción, no la capacidad.

La transición de contraseñas a passkeys tomará años, no meses. Durante ese período, la mayoría de las organizaciones operarán entornos híbridos: passkeys para algunos servicios, contraseñas para otros, cuentas de servicio que no encajan en ningún modelo. La postura de seguridad del conjunto depende de qué tan bien gestione las partes que aún no se han movido.

Passwork está diseñado para este período — bóvedas estructuradas, controles de acceso y registros de auditoría que mantienen las credenciales heredadas bajo control mientras la inscripción de passkeys escala en su equipo.

El cambio de contraseñas a passkeys es un proceso, no un interruptor. Las organizaciones que lo gestionen deliberadamente llegarán a una postura de seguridad significativamente más fuerte — con menos fricción para los usuarios y menos incidentes para los equipos de TI.

Preguntas frecuentes

Ingeniería social vs. ataques de phishing: diferencias clave y estrategias de defensa | guía experta

El phishing es ingeniería social — pero la ingeniería social es mucho más que phishing. Conozca la diferencia, vea cómo la IA está transformando ambas amenazas y construya defensas que cubran toda la superficie de ataque.

Passwork BlogAlex Muntyan

¿Qué es la gestión de acceso privilegiado? Una guía completa

Las cuentas privilegiadas son los objetivos de mayor valor para los atacantes. Una credencial de administrador comprometida da control total sobre infraestructura, datos y aplicaciones. PAM aborda esto mediante bóveda de credenciales, monitoreo de sesiones y aplicación del principio de mínimo privilegio. Así es como funciona en la práctica.

Passwork BlogAlex Muntyan

Mejores prácticas de gestión de contraseñas empresariales: la guía de seguridad 2026

Si su política de contraseñas todavía exige rotaciones de 90 días y mínimos de ocho caracteres, está desactualizada. Esta guía cubre las mejores prácticas de gestión de contraseñas empresariales para 2026: política, cuentas privilegiadas, identidades no humanas, MFA y cumplimiento.

Passwork BlogAlex Muntyan