Die Cybersecurity-News im September 2026 wurden von gefälschten Tokens, wiederverwendeten Sitzungen und geleakten API-Schlüsseln dominiert, die auch nach einer Passwortänderung weiterfunktionierten oder nie ein Passwort benötigt hatten. Zwei Schwachstellen stehen bereits im Known Exploited Vulnerabilities-Katalog der CISA, und ein geleakter Schlüssel eines Anbieters gefährdete über 100.000 Websites.

• Cisco ISE: CVE-2026-76460, eine Authentifizierungsumgehung mit bestätigter aktiver Ausnutzung (Cisco).
• EvilTokens: Microsoft hat einen Device-Code-Phishing-Dienst zerschlagen, der mit mehr als 12.000 kompromittierten Postfächern in über 10.000 Organisationen in Verbindung steht (Microsoft).
• Brevo und Cloudflare: Ein kompromittierter API-Schlüssel setzte mehr als 100.000 Websites einem potenziellen Risiko aus (Sansec).
• JFrog Artifactory: Eine Schwachstelle, die in Honeypots ausgenutzt wurde, um Administrator-Tokens auszustellen (SecurityWeek).
• Cleo Harmony: Ein öffentlicher Exploit für eine Schwachstelle im JWT-Refresh-Token (SecurityWeek).
• CyberArk: 10 Sicherheitsbulletins an vier Terminen, darunter ein kritisches (CyberArk).
• GitHub-App-Schlüssel: GitGuardian stellte fest, dass 474 von 4.802 geleakten privaten Schlüsseln noch gültig waren und sich als 440 Apps authentifizierten (GitGuardian).
• NIST IR 8587: Finale Leitlinie zum Schutz von Tokens und Assertions, veröffentlicht am 15. September (NIST).

Jeder der folgenden Fälle zeigt eine andere Art, wie Zugangsdaten weiter funktionieren, obwohl sie es nicht mehr sollten: gefälscht, wiederverwendet, geleakt oder auf Abruf ausgestellt. Details, betroffene Versionen und Fixes folgen, mit einer kurzen Liste von Maßnahmen für Teams am Ende.

Aktive Ausnutzung einer Authentifizierungsumgehung in Cisco Identity Services Engine (CVE-2026-76460)

Cisco veröffentlichte am 16. September 2026 einen Sicherheitshinweis zu CVE-2026-76460, einer kritischen, nicht authentifizierten Schwachstelle zur Authentifizierungsumgehung in einer Identity Services Engine (ISE)-API. Cisco bewertet sie mit CVSS 3.1 Base 10.0 (kritisch) und bestätigte eine aktive Ausnutzung. Die CISA fügte die CVE am selben Tag ihrem Known Exploited Vulnerabilities-Katalog hinzu.

Was geschah: Eine speziell gestaltete Anfrage an den betroffenen API-Endpunkt ermöglicht es einem Angreifer, die webbasierte Verwaltungsoberfläche von ISE zu umgehen und ohne gültige Zugangsdaten unbefugten Zugriff auf ein betroffenes ISE- oder ISE-PIC-Gerät zu erlangen. Ciscos PSIRT bestätigte, dass Angriffe in freier Wildbahn bekannt waren. Das genaue Datum, an dem die Ausnutzung begann, wurde nicht offengelegt.

Warum das wichtig ist: ISE ist eine Plattform für Richtlinien zum Netzwerkzugriff. Unbefugter Zugriff könnte je nach Implementierung ein erhebliches Risiko für Verwaltungs- und Richtlinienvorgänge darstellen, aber die verfügbaren Quellen belegen nicht, dass bei jedem Kunden nachgelagerte RBAC- oder MFA-Entscheidungen verändert wurden. Die Auswirkung hängt davon ab, wie eine bestimmte Organisation ISE einsetzt.

Handlungsempfehlung: Laut Cisco behebt kein Workaround die Schwachstelle. Ein Upgrade auf eine fehlerbereinigte Version ist die vollständige Lösung. Als vorübergehende Abhilfemaßnahme empfiehlt Cisco Infrastructure-ACLs (iACLs), die am betroffenen Gerät nur den erforderlichen Management- und Control-Plane-Verkehr zulassen. Prüfen Sie die access.log jedes Knotens auf verdächtige Benutzernamen, und gleichen Sie Netzwerk- und Firewall-Protokolle außerhalb der Appliance selbst ab. Das sind Schritte zur Erkennung und Reaktion, kein Ersatz für das Patchen.

Quellen: Cisco; CISA KEV

Microsoft zerschlägt EvilTokens, einen OAuth-Device-Code-Phishing-Dienst

Am 22. September 2026 zerschlug die Digital Crimes Unit von Microsoft gemeinsam mit Partnern die Infrastruktur hinter EvilTokens, einer Phishing-as-a-Service-Plattform, die mit mehr als 12.000 kompromittierten Postfächern in über 10.000 Organisationen weltweit in Verbindung steht.

Was geschah: EvilTokens missbrauchte OAuth-2.0-Device-Authorization-Flows, den Mechanismus für Geräte ohne Browser, etwa Smart-TVs oder CLI-Tools, um Nutzer dazu zu bringen, eine Anmeldung im Namen des Angreifers zu genehmigen. Microsoft legte separat Social-Engineering-Aktivitäten mit Passkey-Bezug offen, die seit Mai 2026 beobachtet wurden. In einer untersuchten Abfolge führte ein Passkey-Köder zu Device-Code-Phishing. Bei anderen untersuchten Mustern nutzten Angreifer Helpdesk-Vorwände oder registrierten vom Angreifer kontrollierte Authentifizierungsmethoden. Die Berichterstattung von Microsoft belegt nicht, dass jede Abfolge alle diese Schritte zu einer einzigen Angriffskette kombinierte.

Warum das wichtig ist: Device-Code-Phishing umgeht genau die Teile der Authentifizierung, auf die sich die Abwehr am stärksten konzentriert. Es gibt keine gefälschte Login-Seite, die auffällt, und kein Passwort, das auf der Seite eines Angreifers eingegeben wird. Das Opfer genehmigt die Anmeldung über die echte, legitime Seite von Microsoft und hält den Vorgang für Routine. Allerdings kann einem Opfer ohne aktive Microsoft-Sitzung weiterhin ein echtes Passwort und eine MFA-Abfrage angezeigt werden, sodass diese Technik nicht grundsätzlich jeden Authentifizierungsschritt aushebelt.

Handlungsempfehlung: Deaktivieren Sie Device-Code-Authentifizierungsflows für Nutzer, die sie operativ nicht benötigen, und überwachen Sie ein ungewöhnlich hohes Volumen an Device-Code-Anmeldungen als Erkennungssignal. Wo der Flow wirklich erforderlich ist, sichern Sie ihn über eine Richtlinie für bedingten Zugriff ab.

Quellen: Microsoft; Microsoft (Aktivitäten mit Passkey-Bezug)

Ein einzelner überprivilegierter Cloudflare-API-Schlüssel gefährdete über 100.000 Websites

Am 14. September 2026 nutzten Angreifer einen kompromittierten, breit berechtigten Cloudflare-API-Schlüssel der E-Mail- und Marketingplattform Brevo, um einen bösartigen Cloudflare Worker einzusetzen, der von Brevo eingebettete Assets auf Kundenseiten veränderte.

Was geschah: Die Telemetrie von Sansec zeichnete auf, dass der bösartige Worker am 14. September von 16:05 bis 20:13 UTC Inhalte auslieferte, rund vier Stunden lang. Der Incident-Bericht von Brevo beschreibt den Worker als etwa fünfeinhalb Stunden aktiv, ein längeres Zeitfenster, als Sansec direkt beobachtet hat. Sansec schätzte, dass in diesem Zeitraum mehr als 100.000 Websites, die betroffene Brevo-Komponenten einsetzen, bösartigen Inhalten ausgesetzt gewesen sein könnten.

Warum das wichtig ist: Ein einzelner, langlebiger Cloudflare-API-Schlüssel mit vollen Berechtigungen, der an einen Anbieter für Marketing-Automatisierung gebunden war, wurde zum Verteilungskanal für bösartigen Code auf einer großen Zahl von Drittanbieter-Websites. Cloud-API-Schlüssel mit weit gefassten Berechtigungen und ohne Ablaufdatum sind genau der Zugangsdatentyp, den eine klassische Passwortrichtlinie nicht abdeckt.

Handlungsempfehlung: Beschränken Sie API-Schlüssel auf den minimalen Berechtigungsumfang, den eine Integration tatsächlich benötigt, legen Sie auch für Schlüssel auf Servicelevel ein Ablaufdatum fest, und führen Sie kontinuierliches Secret-Scanning nicht nur in Passwort-Tresoren der Mitarbeiter, sondern auch über Repositories und Deployment-Pipelines hinweg durch. Eine Überwachung auf unerwartete Worker-Deployments oder Routing-Änderungen hätte dies wahrscheinlich schneller aufgedeckt als eine manuelle Prüfung.

Quellen: Sansec; Brevo

JFrog-Artifactory-Schwachstelle zur Ausstellung von Admin-Tokens genutzt (CVE-2026-82329)

JFrog veröffentlichte am 28. August 2026 einen Fix für CVE-2026-82329. Am 1. September meldete WatchTowr Honeypot-Aktivitäten, die darauf hindeuten, dass Angreifer die Schwachstelle ausnutzten, um Administrator-Tokens zu generieren.

Was geschah: Die Honeypots von WatchTowr erfassten Ausnutzungsversuche von einer kleinen Zahl von Quell-IPs, von denen einige offenbar nur zur Verifizierung dienten statt zu vollständigen Angriffen zu führen. Das belegt, dass die Schwachstelle ausnutzbar ist und getestet wird. Es belegt kein breites Scannen im gesamten Internet oder eine bestätigte Massenausnutzung von Kundeninstanzen.

Warum das wichtig ist: Artifact-Repositories stehen nahe am Zentrum der Software-Lieferkette. Sie unterhalten Federation-Vertrauensbeziehungen zu anderen Repositories und enthalten häufig eingebettete Zugangsdaten für nachgelagerte Systeme. Ein Angreifer, der einen Admin-Token generieren kann, muss keinen stehlen – er erzeugt gültigen Zugriff auf Abruf.

Handlungsempfehlung: Aktualisieren Sie selbst gehostete Artifactory-Instanzen auf die fehlerbereinigte Version Ihres Branches: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 oder 7.161.20. Laut JFrog waren betroffene Cloud-Umgebungen bereits abgesichert. Wenn Protokolle eine Ausnutzung oder verdächtige Token-Ausstellungen zeigen, widerrufen Sie potenziell offengelegte Admin-Tokens, stellen Sie sie neu aus, und prüfen Sie die Federation-Konfigurationen. Die verfügbaren Berichte stützen eine in Honeypots beobachtete Ausnutzung, nicht eine bestätigte Kompromittierung von Kundeninstanzen.

Quellen: JFrog; SecurityWeek

Öffentlicher Exploit für eine Schwachstelle im JWT-Refresh-Token von Cleo Harmony (CVE-2026-84115)

Ein öffentlicher Exploit für CVE-2026-84115 wurde am 2. September 2026 gemeldet, kurz nachdem der CVE-Eintrag am 1. September veröffentlicht worden war.

Was geschah: Die Schwachstelle betrifft Cleo-Harmony-Versionen bis 5.8.1.10 und ist in Harmony 5.8.1.11 behoben. Der CVE-Eintrag beschreibt ein remote ausnutzbares Problem im JWT-Refresh-Token-Handler unter /api/connections: Die Manipulation des Bearer-Arguments führt zu fehlerhafter Rechteverwaltung. SecurityWeek beschreibt dasselbe Problem als Ermöglichung von Authentifizierungsumgehung und Rechteausweitung. Die verfügbaren Berichte belegen öffentliche Ausnutzbarkeit und eine Reproduktion durch Forscher. Sie belegen keine bestätigte Ausnutzung bei Kundensystemen und auch nicht, dass ein manipulierter Token über den Ablauf der ursprünglichen Sitzung hinaus bestehen bleibt.

Warum das wichtig ist: Refresh-Tokens sollen eine Sitzung unauffällig verlängern, ohne eine erneute Anmeldung zu erzwingen. Eine Schwachstelle in der Validierung macht aus dieser Komfortfunktion ein potenzielles Persistenzrisiko – Grund genug zu patchen, auch ohne bestätigte Ausnutzung.

Handlungsempfehlung: Aktualisieren Sie zügig auf Harmony 5.8.1.11. Bei Verdacht auf eine Gefährdung folgen Sie der aktuellen Anleitung von Cleo, prüfen Sie Authentifizierungs- und Rechteänderungen aus dem relevanten Zeitraum, und widerrufen Sie ausstehende Refresh-Tokens, wo die Implementierung das unterstützt. Die Existenz eines öffentlichen Exploits allein bestätigt weder eine Kompromittierung noch einen fortbestehenden Zugriff.

Quellen: NVD; SecurityWeek

CyberArk veröffentlicht zehn Sicherheitsbulletins für seine PAM-Produktlinie

CyberArk veröffentlichte im September 2026 zehn Sicherheitsbulletins in vier datierten Chargen.

Was geschah: CyberArk veröffentlichte im September 2026 in vier Chargen zehn Sicherheitsbulletins. Sie adressieren Probleme mit hohem Schweregrad in Agenten für Endpoint Privilege Management, selbst gehosteten Gateway- und Vault-Komponenten, Analytik für privilegierten Zugriff und der Verwaltung von Datenbank-Zugangsdaten, sowie ein kritisches Problem – CA26-44 –, das bestimmte selbst gehostete Versionen von Password Vault Web Access (PVWA) betrifft.

Warum das wichtig ist: PAM-Systeme verwalten häufig privilegierte Zugangsdaten und sensible Infrastruktur oder stellen den Zugriff darauf bereit. Eine konzentrierte Reihe von Sicherheitsupdates ist eine Erinnerung daran, dass diese Umgebungen kontinuierliches Patch-Management, klare Zugriffs-Governance und verlässliche Nachvollziehbarkeit erfordern. Die Advisories deuten für sich genommen nicht auf eine aktive Ausnutzung hin.

Handlungsempfehlung: Organisationen, die betroffene Produkte einsetzen, sollten die Advisories prüfen und die Behebung nach Schweregrad, Gefährdung und möglichen Auswirkungen auf zugangsdatenbezogene Systeme priorisieren. Allgemeiner sollten Sicherheitsteams stets im Blick behalten, wer auf sensible Zugangsdaten zugreifen kann, und diesen Zugriff bei Bedarf überprüfen können.

Quelle: CyberArk; CyberIAM-Bulletin-Board

Geleakte private Schlüssel von GitHub Apps funktionieren noch lange nach ihrer Offenlegung

GitGuardian testete 4.802 geleakte private Schlüssel von GitHub Apps, die in öffentlichen Quellen gefunden wurden, und stellte fest, dass sich 474 davon weiterhin als 440 verschiedene aktive Apps authentifizieren ließen.

Was geschah: Ein privater Schlüssel einer GitHub App hat kein automatisches Ablaufdatum und kann so lange nutzbar bleiben, bis er manuell widerrufen oder gelöscht wird. Von den 474 noch gültigen Schlüsseln, die GitGuardian testete, verfügten 207 über Schreibrechte für Repository-Inhalte, 40 konnten selbst gehostete Runner verwalten, 98 konnten Workflows steuern, und 44 besaßen Rechte zur Organisationsverwaltung. Ein Schlüssel, der vor Jahren committet wurde, kann sich weiterhin authentifizieren, wenn er nicht widerrufen oder gelöscht wurde.

Ein verwandtes Muster zeigte sich bei einer Schwachstelle im API-Management von WSO2, CVE-2026-5430. Der Advisory datiert auf Mai 2026, die CVE wurde im August veröffentlicht. Die Nachricht im September war eine Meldung über Ausnutzung, keine neue Offenlegung. Ein Angreifer kann ein JSON Web Token (JWT) mit einem nicht unterstützten Signaturalgorithmus erstellen und die fehlerhafte Validierung von WSO2 ausnutzen, um die Authentifizierung zu umgehen. Der Dienst muss dafür nicht selbst einen Token ausstellen. Der Honeypot von WatchTowr erfasste am 13. September gefälschte JWTs mit Administratorrechten gegen das System, und die CISA fügte die CVE am 24. September ihrem Known Exploited Vulnerabilities-Katalog hinzu. Backend-Zugangsdaten, Consumer-Keys oder Secrets wurden als potenziell erreichbar gemeldet, nicht als bestätigt gestohlen.

Warum das wichtig ist: Ein öffentliches Leak schafft potenziell dauerhaften Zugriff, bis der Schlüssel widerrufen oder gelöscht wird. Es belegt für sich genommen nicht, dass der Schlüssel tatsächlich genutzt oder auf Daten zugegriffen wurde. Der WSO2-Fall zeigt ein verwandtes Muster eine Ebene tiefer im Stack: Ein Angreifer braucht gar keinen geleakten Schlüssel, wenn sich die Validierungslogik selbst dazu verleiten lässt, einen gefälschten Schlüssel zu akzeptieren.

Handlungsempfehlung: Legen Sie für jeden GitHub-App-Schlüssel einen Verantwortlichen und einen dokumentierten Rotations- bzw. Widerrufsprozess fest. Bei Verdacht auf oder Bestätigung einer Gefährdung erzeugen Sie umgehend einen Ersatz und widerrufen oder löschen den alten Schlüssel; eine regelmäßige Rotation verkürzt die Gefährdungsdauer, auch wenn GitHub keinen einheitlichen Rhythmus vorschreibt. Für WSO2-Implementierungen spielen Sie den Fix des Herstellers ein, prüfen Sie die Protokolle für das Ausnutzungsfenster im September, und rotieren Sie die Zugangsdaten, auf die die API-Management-Schicht Zugriff hatte.

Quellen: GitGuardian; GitHub-Dokumentation; WSO2-Advisory; The Hacker News

NIST und CISA finalisieren Leitlinie zum Schutz von Identitäts- und Zugriffstokens

NIST und CISA finalisierten IR 8587 am 15. September 2026, nach einem ersten öffentlichen Entwurf vom 22. Dezember 2025.

Was geschah: Die Implementierungsleitlinie richtet sich vor allem an Bundesbehörden und die von ihnen genutzten Cloud-Dienstanbieter und behandelt Identitätstokens, Zugriffstokens und Assertions in SSO-, Federation- und API-Zugriffsszenarien. Ihre Empfehlungen fassen Praktiken für Schlüsselverwaltung, Token-Verifizierung, Lebenszyklus (einschließlich Gültigkeitsdauer und Widerruf) und kontinuierliche Überwachung zusammen, wobei die Verantwortlichkeiten zwischen Anbietern, nutzenden Behörden und Cloud-Konsumenten aufgeteilt sind.

Warum das wichtig ist: Mehrere der oben beschriebenen Vorfälle – gefälschte JWTs, über Validierungsschwachstellen generierte Admin-Tokens, nie ablaufende API-Schlüssel – fallen in genau die Kategorien, die dieser Bericht behandelt: Lücken bei der Verifizierung, fehlende Lebenszykluskontrollen und unklare Verantwortung zwischen Anbieter und Kunde für den Widerruf. Diese Überschneidung ist auch für Organisationen außerhalb des Bundesbereichs nützlich.

Handlungsempfehlung: Nutzen Sie NIST IR 8587 als praktische Checkliste für die aktuellen Praktiken: Stellen Sie sicher, dass Token-Gültigkeitsdauern begrenzt sind, dass Widerrufswege getestet und nicht nur dokumentiert sind, und dass die Sitzungsprotokollierung genug Details erfasst, um einen tokenbasierten Vorfall nachträglich rekonstruieren zu können.

Quellen: NIST; CISA

CloudSEK beschreibt BigBear 2.0, einen Adversary-in-the-Middle-Dienst, der Microsoft-365-Sitzungen nach der MFA wiederverwendet

CloudSEK veröffentlichte seine Untersuchung zu BigBear 2.0 am 7. September 2026. Das TRIAD-Team entdeckte die Operation im Juni, was nicht belegt, wann die gesamte Kampagnenaktivität begann.

Was geschah: Der auf Evilginx2 basierende Adversary-in-the-Middle-Dienst leitete Microsoft-365-Anmeldungen um. Er erfasste Zugangsdaten und das von Microsoft ausgestellte Sitzungscookie, nachdem Opfer die MFA abgeschlossen hatten, und ließ Angreifer anschließend die authentifizierten Sitzungen wiederverwenden. Das Panel von CloudSEK enthielt 4.148 Sitzungscookie-Datensätze und 474 abgeschlossene, MFA-umgangene Authentifizierungen. BleepingComputer berichtete, dass 258 verschiedene Organisationen mindestens eine solche abgeschlossene Kompromittierung erlitten, während 461 Organisationen im breiteren Zieldatensatz auftauchten. Die Zahl 4.148 ist eine Zählung von Cookie-Datensätzen, keine bestätigte Zahl eindeutiger Opfer. (CloudSEK; BleepingComputer)

Warum das wichtig ist: Eine MFA, die das Opfer auf einer proxybasierten Seite abschließt, schützt nicht mehr, sobald das Sitzungscookie gestohlen ist. Der Angreifer übernimmt eine bereits authentifizierte Sitzung. Codes und Push-Genehmigungen stoppen dieses Muster nicht.

Handlungsempfehlung: Priorisieren Sie phishingresistente Methoden wie Passkeys und FIDO2-Sicherheitsschlüssel für Administratoren und Nutzer mit hohem Risiko. Überprüfen Sie Richtlinien für bedingten Zugriff, die Sitzungen an konforme Geräte binden. Lösen Sie einen Alarm aus, wenn sich IP-Adresse oder Gerät einer Sitzung kurz nach der MFA ändern.

Quellen: CloudSEK; BleepingComputer

Okta analysiert Infostealer-Dump mit 44.791 eindeutigen JWTs, 1.843 Tokens zum Zeitpunkt der Veröffentlichung noch gültig

Okta veröffentlichte am 9. September 2026 eine Untersuchung zu einem 7-GB-Infostealer-Dump, der am 2. August auf Telegram veröffentlicht wurde.

Was geschah: Der Dump enthielt Daten von 5.871 infizierten Rechnern. Okta identifizierte 44.791 eindeutige JWTs, darunter 555, die wahrscheinlich mit der Authentifizierung von KI-Diensten zusammenhängen, sowie 2.937 authentifizierungsbezogene JWEs. Zum Zeitpunkt der Veröffentlichung des Dumps waren 1.843 JWTs und JWEs noch nicht abgelaufen. Laut Okta könnten nicht abgelaufene Sitzungs-Secrets potenziell wiederverwendet werden, um die zugangsdatenbasierte Authentifizierung zu umgehen. Die Untersuchung meldete keine erfolgreiche Wiederverwendung oder eine bestätigte Account-Übernahme. Ob eine Wiederverwendung funktioniert, hängt vom jeweiligen Dienst und von Kontrollen wie Token-Bindung oder IP-Allowlisting ab. (Okta)

Warum das wichtig ist: Infostealer nehmen alles mit, was auf dem Endgerät liegt, und Tokens sind ein Teil dieser Beute. Die Gültigkeitsdauer eines Tokens bestimmt, wie lange ein gestohlenes Secret nützlich bleibt. Die KI-Dienst-Tokens in diesem Datensatz zeigen, dass die Gefährdung inzwischen auch neuere Tools erreicht, die Teams häufig außerhalb des zentralen Identitätsmanagements einführen.

Handlungsempfehlung: Verkürzen Sie Token-Gültigkeitsdauern, wo der Dienst das zulässt, und binden Sie Tokens an ein Gerät oder Netzwerk, wo das unterstützt wird. Widerrufen Sie nach einer Infostealer-Infektion Sitzungen und rotieren Sie Secrets – nicht nur das Passwort zurücksetzen. Nehmen Sie Konten für KI-Dienste in Ihr Inventar von Tokens und API-Schlüsseln auf.

Quelle: Okta

JeetBot-Twitch-Erweiterung leitete OAuth-Tokens über vom Betreiber kontrollierte Proxys weiter

Die bösartige Twitch-Browser-Erweiterung JeetBot verzeichnete über Chrome und Firefox hinweg rund 30.500 Installationen aus dem Store (eine Installationsschätzung, keine bestätigte Zahl kompromittierter Nutzer).

Was geschah: Socket fand heraus, dass die Erweiterung kontobezogene Twitch-OAuth-Tokens erfasste und sie über vom Betreiber kontrollierte Proxys in einem &auth=-Query-Parameter weiterleitete. Die Berichterstattung belegt nicht, dass die Tokens für unbefugte Aktivitäten genutzt wurden. Firefox-Version 85.8.7 (16. September) und Chrome-Version 85.8.9 (gemeldet am 25. September) beendeten die Weiterleitung. Der Betreiber widersprach der Einstufung der Erweiterung als bösartig, räumte aber Sicherheits- und Offenlegungsprobleme ein. (Socket)

Handlungsempfehlung: Prüfen Sie installierte Browser-Erweiterungen, und behandeln Sie jeden Token, der in einer URL aufgetaucht ist, als offengelegt. Nutzer von JeetBot sollten der App den Zugriff auf ihr Twitch-Konto entziehen.

Quelle: Socket

Microsoft Entra aktiviert Passkeys automatisch vor der Abschaltung von SMS- und Sprach-MFA

Microsoft Entra begann am 1. September 2026 damit, Passkeys automatisch für Public-Cloud-Nutzer zu aktivieren, für die SMS- oder Sprach-MFA bereits in der Entra-Richtlinie für Authentifizierungsmethoden oder in den Legacy-Einstellungen aktiviert war.

Was geschah: Wenn diese Nutzer sich das nächste Mal anmelden und die MFA abschließen, werden sie aufgefordert, einen Passkey zu registrieren. Diese Aufforderung lässt sich in der Regel vertagen, und bis zum 1. Februar 2027 steht ein vorübergehendes Opt-out für den Tenant zur Verfügung. Die von Microsoft bereitgestellte SMS- und Sprachzustellung wird für die meisten Nutzer am 1. Februar 2027 und für globale Administratoren und externe Nutzer am 1. Juli 2027 abgeschaltet. Organisationen mit einem berechtigten Bedarf können SMS oder Sprache über einen unterstützten Telefonieanbieter fortführen. Diese Konfigurationsoption ist für den 30. Oktober 2026 geplant.

Warum das wichtig ist: Die Änderung verschiebt den Standard weg von telefonbasierten Faktoren – genau der Art, die laut der oben beschriebenen BigBear-2.0-Kampagne weitergeleitet werden kann. Tenants, die nichts unternehmen, sehen schon jetzt Registrierungsaufforderungen und verlieren 2027 die von Microsoft bereitgestellte SMS- und Sprachzustellung.

Handlungsempfehlung: Erfassen Sie, welche Nutzer und Serviceprozesse noch auf SMS oder Sprache angewiesen sind. Beginnen Sie die Passkey-Registrierung mit Administratoren und externen Nutzern, für die die Frist am frühesten endet. Entscheiden Sie vor dem 1. Februar 2027, ob Sie einen Telefonieanbieter benötigen oder diese Methoden ganz abschalten können.

Quelle: Microsoft Learn

Was das für Ihr Team bedeutet

Die meisten Fälle dieses Monats laufen darauf hinaus, dass Zugangsdaten weiter funktionierten, obwohl sie es nicht mehr sollten. Sechs Schritte, mit denen Ihr Team ähnliche Probleme vermeiden kann:

1. Nicht-menschliche Zugangsdaten inventarisieren. Erfassen Sie API-Schlüssel, Service-Account-Tokens, private Schlüssel von GitHub Apps und CI/CD-Secrets genauso wie Benutzerkonten. Geben Sie jedem einen namentlich benannten Verantwortlichen und einen dokumentierten Plan für Ablauf oder Rotation. In den Fällen Brevo und GitHub App ging es jeweils um Schlüssel, die niemand verfolgt hat.
2. Berechtigungen einschränken und Ablaufdaten setzen. Vergeben Sie für jeden Schlüssel nur die Berechtigungen, die die Integration tatsächlich benötigt, und setzen Sie überall dort ein Ablaufdatum, wo der Anbieter das unterstützt. Wo das nicht möglich ist, planen Sie eine manuelle Rotation.
3. Widerruf testen, bevor Sie ihn brauchen. Prüfen Sie für jeden Anbieter, was der Widerruf einer Sitzung, eines JWT, einer OAuth-Berechtigung oder eines Refresh-Tokens tatsächlich bewirkt. Durchlaufen Sie nach einem Vorfall den gesamten Widerrufsweg, statt sich auf die Dokumentation zu verlassen. Widerrufen Sie Sitzungen und rotieren Sie Secrets – nicht nur das Passwort zurücksetzen.
4. OAuth- und Sitzungslücken schließen. Deaktivieren Sie Device-Code-Flows für Nutzer, die sie nicht benötigen, und wechseln Sie Administratoren vor der Abschaltung von Microsofts SMS- und Sprach-MFA 2027 zu Passkeys oder FIDO2-Schlüsseln. Binden Sie Sitzungen an Geräte, wo das unterstützt wird.
5. Exponierte Identitätsinfrastruktur zuerst patchen. Cisco ISE, JFrog Artifactory, Cleo Harmony und WSO2 stellen Zugriff für alles aus, was dahinter liegt, oder validieren ihn. Behandeln Sie deren Updates vorrangig vor dem routinemäßigen Patchen.
6. So protokollieren, dass sich ein Vorfall rekonstruieren lässt. Halten Sie Sitzungs- und Token-Protokolle detailliert genug, um zu zeigen, wer sich wo mit welchem Token authentifiziert hat. NIST IR 8587 ist dafür und für die obigen Punkte eine brauchbare Checkliste.

Weiterführende Informationen finden Sie in unseren Leitfäden zum Lebenszyklus der Secrets-Rotation und zu hartcodierten Secrets.

Monatlicher Cybersecurity-Rückblick: Authentifizierung unter Beschuss

Die Vorfälle im August 2026 umgingen die Authentifizierung vollständig: bestätigte Exploits in N-able N-central und SharePoint, über 9.300 offengelegte AWS-Schlüssel und Mirage2FA, das Sitzungen nach der MFA übernahm. Hier ist, was IT- und Sicherheitsteams zuerst patchen und prüfen müssen.

PassworkPasswork Team

Post-Quanten-Passwortsicherheit: Was sich ändert und was zu tun ist

Grovers Algorithmus setzt einem korrekt gehashten Passwort kaum etwas entgegen. Shors Algorithmus zerlegt dagegen den RSA-Schlüsselaustausch direkt daneben. Hier ist das dreistufige Audit, das zeigt, welches der beiden Probleme bei Ihnen wirklich relevant ist.

PassworkPasswork Team

2026 IBM Cost of a Data Breach Report: Die KI-Bedrohung über 6 Mio. US-Dollar, die niemand behebt

Die globalen Kosten von Datenschutzverletzungen erreichten 2026 mit 4,99 Mio. US-Dollar einen neuen Höchststand, bei einer Erkennungszeit von 247 Tagen. KI-gestützte Angriffe steigen um 56 %, doch die eigentliche Krise ist: Verteidiger setzen KI überall ein – außer genau dort, wo Angreifer eindringen. 92 % der von KI-Angriffen betroffenen Organisationen hatten keine angemessenen Zugriffskontrollen.

PassworkAlex Muntyan

Las noticias de ciberseguridad de septiembre de 2026 estuvieron dominadas por tokens falsificados, sesiones reproducidas y claves de API filtradas que seguían funcionando después de cambiar la contraseña o que nunca la necesitaron. Dos vulnerabilidades ya figuran en el catálogo Known Exploited Vulnerabilities de CISA, y una clave de proveedor filtrada puso en riesgo a más de 100 000 sitios.

• Cisco ISE: CVE-2026-76460, una omisión de autenticación con explotación activa confirmada (Cisco).
• EvilTokens: Microsoft desmanteló un servicio de phishing por código de dispositivo vinculado a más de 12 000 bandejas de entrada comprometidas en más de 10 000 organizaciones (Microsoft).
• Brevo y Cloudflare: una clave de API comprometida puso en riesgo potencial a más de 100 000 sitios (Sansec).
• JFrog Artifactory: un fallo explotado en honeypots para generar tokens de administrador (SecurityWeek).
• Cleo Harmony: un exploit público para un fallo en el token de actualización JWT (SecurityWeek).
• CyberArk: 10 boletines de seguridad en cuatro fechas, incluido uno crítico (CyberArk).
• Claves de aplicaciones de GitHub: GitGuardian determinó que 474 de 4802 claves privadas filtradas seguían siendo válidas, autenticando como 440 aplicaciones (GitGuardian).
• NIST IR 8587: guía final sobre la protección de tokens y aserciones, publicada el 15 de septiembre (NIST).

Cada caso a continuación muestra una forma distinta en que una credencial sigue funcionando después de que debería haberse detenido: falsificada, reproducida, filtrada o generada a demanda. A continuación se detallan las versiones afectadas y las soluciones, con una breve lista de acciones a nivel de equipo al final.

Explotación activa de una omisión de autenticación en Cisco Identity Services Engine (CVE-2026-76460)

Cisco publicó un aviso el 16 de septiembre de 2026 sobre el CVE-2026-76460, una vulnerabilidad crítica de omisión de autenticación no autenticada en una API de Identity Services Engine (ISE). Cisco la califica con CVSS 3.1 Base 10.0 (Crítico) y confirmó la explotación activa. CISA añadió el CVE a su catálogo Known Exploited Vulnerabilities el mismo día.

Qué ocurrió: una solicitud manipulada al endpoint de API afectado permite a un atacante omitir la interfaz de administración web de ISE y obtener acceso no autorizado a un dispositivo ISE o ISE-PIC afectado, sin credenciales válidas. El PSIRT de Cisco confirmó que tenía conocimiento de ataques en entornos reales. No se ha revelado la fecha exacta en que comenzó la explotación.

Por qué importa: ISE es una plataforma de políticas de acceso a la red. El acceso no autorizado podría crear un riesgo grave específico de cada implementación para las operaciones de administración y de políticas, pero las fuentes disponibles no establecen que se hayan alterado las decisiones de RBAC o MFA posteriores de todos los clientes. El impacto depende de cómo tenga implementado ISE cada organización.

La conclusión defensiva: Cisco afirma que no existe ninguna solución alternativa para el fallo. Actualizar a una versión corregida es la solución completa. Como mitigación temporal, Cisco recomienda ACL de infraestructura (iACL) que permitan únicamente el tráfico de administración y de plano de control necesario hacia el dispositivo afectado. Revise el access.log de cada nodo en busca de nombres de usuario sospechosos y coteje los registros de red y de firewall fuera del propio dispositivo. Son pasos de detección y respuesta, no un sustituto de la aplicación de parches.

Fuentes: Cisco; CISA KEV

Microsoft desmantela EvilTokens, un servicio de phishing por código de dispositivo OAuth

El 22 de septiembre de 2026, la Unidad de Delitos Digitales de Microsoft, en colaboración con socios, desmanteló la infraestructura que sustentaba a EvilTokens, una plataforma de phishing como servicio vinculada a más de 12 000 bandejas de entrada comprometidas en más de 10 000 organizaciones de todo el mundo.

Qué ocurrió: EvilTokens abusaba de los flujos de autorización por código de dispositivo de OAuth 2.0, el mecanismo diseñado para dispositivos sin navegador, como televisores inteligentes o herramientas de línea de comandos, para engañar a los usuarios y hacerles aprobar un inicio de sesión en nombre del atacante. Microsoft reveló por separado actividad de ingeniería social con temática de passkeys observada desde mayo de 2026. En una de las secuencias investigadas, un anzuelo de passkey condujo a un phishing por código de dispositivo. En otros patrones investigados, los atacantes usaron pretextos de mesa de ayuda o registraron métodos de autenticación controlados por el atacante. Los informes de Microsoft no establecen que todas las secuencias combinaran estos pasos en una sola cadena de ataque.

Por qué importa: el phishing por código de dispositivo evita las partes de la autenticación que reciben más atención defensiva. No hay una página de inicio de sesión falsa que detectar ni una contraseña escrita en el sitio del atacante. La víctima aprueba el inicio de sesión a través de la página legítima de Microsoft, creyendo que es un trámite rutinario. Aun así, una víctima sin una sesión activa de Microsoft puede recibir igualmente una solicitud de contraseña real y un desafío de MFA, por lo que esta técnica no elimina universalmente todos los pasos de autenticación.

La conclusión defensiva: deshabilite los flujos de autenticación por código de dispositivo para los usuarios que no los necesiten operativamente, y supervise los volúmenes anómalos de inicio de sesión por código de dispositivo como señal de detección. Donde el flujo sea realmente necesario, protéjalo con una política de acceso condicional.

Fuentes: Microsoft; Microsoft (actividad con temática de passkeys)

Una sola clave de API de Cloudflare con permisos excesivos puso en riesgo a más de 100 000 sitios

El 14 de septiembre de 2026, los atacantes usaron una clave de API de Cloudflare comprometida y con permisos amplios, perteneciente a la plataforma de correo electrónico y marketing Brevo, para desplegar un Cloudflare Worker malicioso que alteró los recursos de Brevo incrustados en los sitios de los clientes.

Qué ocurrió: la telemetría de Sansec registró que el Worker malicioso sirvió contenido desde las 16:05 hasta las 20:13 UTC del 14 de septiembre, aproximadamente cuatro horas. El informe del incidente de Brevo describe el Worker como activo durante unas cinco horas y media, una ventana más larga que la observada directamente por Sansec. Sansec estimó que más de 100 000 sitios que utilizaban componentes afectados de Brevo pudieron haber estado expuestos a contenido malicioso durante ese periodo.

Por qué importa: una sola clave de API de Cloudflare de larga duración y con permisos totales, vinculada a un proveedor de automatización de marketing, se convirtió en un canal de distribución de código malicioso en un gran número de sitios de terceros. Las claves de API en la nube con alcances amplios y sin caducidad son exactamente el tipo de credencial que la política de contraseñas tradicional no cubre.

La conclusión defensiva: limite las claves de API al conjunto mínimo de permisos que realmente necesita una integración, establezca caducidades incluso en las claves a nivel de servicio, y ejecute un escaneo continuo de secretos en repositorios y canalizaciones de despliegue, no solo en las bóvedas de contraseñas de los empleados. Supervisar los despliegues inesperados de Workers o los cambios de enrutamiento probablemente habría detectado esto más rápido que una auditoría manual.

Fuentes: Sansec; Brevo

Un fallo de JFrog Artifactory se usa para generar tokens de administrador (CVE-2026-82329)

JFrog publicó una corrección para el CVE-2026-82329 el 28 de agosto de 2026. El 1 de septiembre, WatchTowr informó de actividad en honeypots compatible con atacantes que explotaban el fallo para generar tokens de administrador.

Qué ocurrió: los honeypots de WatchTowr capturaron intentos de explotación contra un pequeño número de IP de origen, algunos de los cuales parecían ser actividad de mera verificación y no ataques completos. Es una prueba de que la vulnerabilidad es explotable y está siendo sondeada. No establece un escaneo amplio en internet ni una explotación masiva confirmada de instancias de clientes.

Por qué importa: los repositorios de artefactos se sitúan cerca del centro de la cadena de suministro de software. Mantienen relaciones de confianza federada con otros repositorios y a menudo contienen credenciales incrustadas para sistemas posteriores. Un atacante que puede generar un token de administrador no necesita robar uno: crea acceso válido a demanda.

La conclusión defensiva: para instalaciones autogestionadas de Artifactory, actualice a la versión corregida de su rama: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 o 7.161.20. JFrog afirma que los entornos en la nube afectados ya estaban reforzados. Si los registros muestran explotación o emisión sospechosa de tokens, revoque y reemita los tokens de administrador potencialmente expuestos y audite las configuraciones de federación. Los informes disponibles respaldan una explotación observada en honeypots, no una vulneración confirmada de instancias de clientes.

Fuentes: JFrog; SecurityWeek

Exploit público para un fallo en el token de actualización JWT de Cleo Harmony (CVE-2026-84115)

Se informó de un exploit público para el CVE-2026-84115 el 2 de septiembre de 2026, poco después de que se publicara el registro del CVE el 1 de septiembre.

Qué ocurrió: el fallo afecta a las versiones de Cleo Harmony hasta la 5.8.1.10 y está corregido en Harmony 5.8.1.11. El registro del CVE describe un problema explotable de forma remota en el gestor de tokens de actualización JWT de /api/connections: manipular el argumento Bearer provoca una gestión incorrecta de privilegios. SecurityWeek describe el mismo problema como causante de una omisión de autenticación y una elevación de privilegios. Los informes disponibles establecen la explotabilidad pública y la reproducción por parte de investigadores. No establecen una explotación confirmada de sistemas de clientes, ni que un token manipulado persista más allá de la caducidad de la sesión original.

Por qué importa: los tokens de actualización están pensados para prolongar una sesión de forma discreta, sin forzar un nuevo inicio de sesión. Un fallo en la forma en que se valida uno convierte esta función de comodidad en un riesgo potencial de persistencia, motivo suficiente para aplicar el parche incluso sin explotación confirmada.

La conclusión defensiva: actualice a Harmony 5.8.1.11 cuanto antes. Si se sospecha exposición, siga las indicaciones actuales de Cleo, revise los cambios de autenticación y de privilegios de la ventana correspondiente, y revoque los tokens de actualización pendientes donde la implementación admita ese control. La existencia de un exploit público no confirma por sí sola una vulneración ni un acceso persistente.

Fuentes: NVD; SecurityWeek

CyberArk publica diez boletines de seguridad en toda su línea de productos PAM

CyberArk publicó 10 boletines de seguridad en septiembre de 2026, en cuatro lotes con distintas fechas.

Qué ocurrió: CyberArk publicó 10 boletines de seguridad en cuatro lotes durante septiembre de 2026, que abordan problemas de gravedad alta en agentes de gestión de privilegios de endpoints, componentes de puerta de enlace y bóveda autogestionados, analítica de acceso privilegiado y gestión de credenciales de bases de datos, además de un problema crítico —CA26-44— que afecta a determinadas versiones autogestionadas de Password Vault Web Access (PVWA).

Por qué importa: los sistemas PAM a menudo gestionan o dan acceso a credenciales privilegiadas e infraestructura sensible. Un conjunto concentrado de actualizaciones de seguridad es un recordatorio de que estos entornos requieren gestión continua de parches, una gobernanza de accesos clara y una capacidad de auditoría fiable. Los avisos no indican, por sí mismos, explotación activa.

La conclusión defensiva: las organizaciones que usan los productos afectados deben revisar los avisos y priorizar la corrección según la gravedad, la exposición y el impacto potencial en los sistemas relacionados con credenciales. De forma más general, los equipos de seguridad deben mantener visibilidad sobre quién puede acceder a las credenciales sensibles y poder revisar ese acceso cuando sea necesario.

Fuente: CyberArk; CyberIAM bulletin board

Las claves privadas filtradas de aplicaciones de GitHub siguen funcionando mucho después de su exposición

GitGuardian probó 4802 claves privadas filtradas de aplicaciones de GitHub encontradas en fuentes públicas y descubrió que 474 seguían autenticándose como 440 aplicaciones activas distintas.

Qué ocurrió: una clave privada de una aplicación de GitHub no tiene caducidad automática y puede permanecer utilizable hasta que se revoque o elimine manualmente. De las 474 claves aún válidas que probó GitGuardian, 207 tenían permiso de escritura de contenido en repositorios, 40 podían administrar ejecutores autogestionados, 98 podían controlar flujos de trabajo y 44 tenían privilegios de administración de la organización. Una clave confirmada hace años aún puede autenticarse si no se ha revocado o eliminado.

Un patrón relacionado surgió en un fallo de gestión de API de WSO2, el CVE-2026-5430. El aviso data de mayo de 2026 y el CVE se publicó en agosto. La noticia de septiembre fue un informe de explotación, no una nueva divulgación. Un atacante puede crear un JWT con un algoritmo de firma no admitido y aprovechar la validación defectuosa de WSO2 para omitir la autenticación. El servicio no necesita generar un token por sí mismo. El honeypot de WatchTowr capturó JWT falsificados con privilegios de administrador contra el servicio el 13 de septiembre, y CISA añadió el CVE a su catálogo Known Exploited Vulnerabilities el 24 de septiembre. Se informó de que las credenciales de backend, las claves de consumidor o los secretos eran potencialmente accesibles, no que se hubieran robado de forma confirmada.

Por qué importa: una filtración pública crea un acceso potencialmente persistente hasta que se revoca o elimina la clave. No prueba por sí sola que la clave se usara o que se accediera a los datos. El caso de WSO2 muestra un patrón relacionado una capa más abajo en la pila: un atacante ni siquiera necesita una clave filtrada si la propia lógica de validación puede ser engañada para aceptar una falsificada.

La conclusión defensiva: mantenga un responsable y un proceso documentado de rotación/revocación para cada clave de aplicación de GitHub. Si se sospecha o se confirma la exposición, genere un reemplazo y revoque o elimine la clave antigua cuanto antes; la rotación periódica reduce el tiempo de exposición, aunque GitHub no prescribe un calendario universal. Para las implementaciones de WSO2, aplique la corrección del proveedor, revise los registros de la ventana de explotación de septiembre y rote las credenciales a las que tenía acceso la capa de gestión de API.

Fuentes: GitGuardian; GitHub docs; WSO2 advisory; The Hacker News

NIST y CISA finalizan la guía sobre la protección de tokens de identidad y de acceso

NIST y CISA finalizaron el IR 8587 el 15 de septiembre de 2026, tras un borrador público inicial fechado el 22 de diciembre de 2025.

Qué ocurrió: la guía de implementación está escrita principalmente para agencias federales y los proveedores de servicios en la nube que utilizan, y abarca tokens de identidad, tokens de acceso y aserciones en escenarios de SSO, federación y acceso a API. Sus recomendaciones resumen prácticas de gestión de claves, verificación de tokens, ciclo de vida (incluida la vigencia y la revocación) y supervisión continua, con responsabilidades divididas entre proveedores, agencias consumidoras y clientes en la nube.

Por qué importa: varios de los fallos descritos anteriormente —JWT falsificados, tokens de administrador generados mediante fallos de validación, claves de API sin caducidad— entran dentro de las categorías que aborda este informe: brechas de verificación, controles de ciclo de vida inexistentes y responsabilidad poco clara entre proveedor y cliente respecto a la revocación. Esa coincidencia es útil incluso para organizaciones fuera del ámbito federal.

La conclusión defensiva: use el NIST IR 8587 como lista de verificación práctica frente a las prácticas actuales: confirme que la vigencia de los tokens está limitada, que las rutas de revocación se prueban y no solo se documentan, y que el registro de sesiones capture suficiente detalle para reconstruir un incidente basado en tokens después de que ocurra.

Fuentes: NIST; CISA

CloudSEK detalla BigBear 2.0, un servicio de adversario en el medio que reproduce sesiones de Microsoft 365 después de la MFA

CloudSEK publicó su investigación sobre BigBear 2.0 el 7 de septiembre de 2026. Su equipo TRIAD descubrió la operación en junio, lo que no establece cuándo comenzó toda la actividad de la campaña.

Qué ocurrió: el servicio de adversario en el medio, basado en Evilginx2, interceptaba los inicios de sesión de Microsoft 365. Capturaba las credenciales y la cookie de sesión emitida por Microsoft después de que las víctimas completaran la MFA, y luego permitía a los atacantes reproducir las sesiones autenticadas. El panel de CloudSEK contenía 4148 registros de cookies de sesión y 474 autenticaciones completadas con omisión de MFA. BleepingComputer informó de que 258 organizaciones distintas tuvieron al menos una vulneración completada de este tipo, mientras que 461 organizaciones aparecían en el conjunto de datos de objetivos más amplio. La cifra de 4148 es un recuento de registros de cookies, no un recuento confirmado de víctimas únicas. (CloudSEK; BleepingComputer)

Por qué importa: la MFA que la víctima completa en una página proxificada no protege nada una vez que se roba la cookie de sesión. El atacante hereda una sesión ya autenticada. Los códigos y las aprobaciones push no detienen este patrón.

La conclusión defensiva: priorice métodos resistentes al phishing, como las passkeys y las llaves de seguridad FIDO2, para administradores y usuarios de alto riesgo. Revise las políticas de acceso condicional que vinculan las sesiones a dispositivos conformes. Genere alertas cuando la dirección IP o el dispositivo de una sesión cambien poco después de la MFA.

Fuentes: CloudSEK; BleepingComputer

Okta analiza un volcado de infostealer con 44 791 JWT únicos; 1843 tokens seguían siendo válidos en el momento de su publicación

Okta publicó una investigación el 9 de septiembre de 2026 sobre un volcado de infostealer de 7 GB publicado en Telegram el 2 de agosto.

Qué ocurrió: el volcado contenía datos de 5871 máquinas infectadas. Okta identificó 44 791 JWT únicos, incluidos 555 probablemente relacionados con la autenticación de servicios de IA, además de 2937 JWE relacionados con la autenticación. En el momento de la publicación del volcado, 1843 JWT y JWE no habían caducado. Okta afirmó que los secretos de sesión no caducados podrían reproducirse potencialmente para omitir la autenticación basada en credenciales. La investigación no informó de una reproducción exitosa ni de una toma de control de cuenta confirmada. Que la reproducción funcione depende del servicio y de controles como la vinculación de tokens o las listas blancas de IP. (Okta)

Por qué importa: los infostealers se llevan todo lo que hay en el endpoint, y los tokens forman parte de ese botín. La vigencia del token determina cuánto tiempo sigue siendo útil un secreto robado. Los tokens de servicios de IA presentes en el conjunto muestran que la exposición alcanza ya a herramientas más recientes que los equipos a menudo adoptan fuera de la gestión central de identidades.

La conclusión defensiva: reduzca la vigencia de los tokens donde el servicio lo permita, y vincule los tokens a un dispositivo o red donde sea posible. Tras una infección de infostealer, revoque las sesiones y rote los secretos, no se limite a restablecer la contraseña. Incluya las cuentas de servicios de IA en su inventario de tokens y claves de API.

Fuente: Okta

La extensión de Twitch JeetBot reenviaba tokens de OAuth a través de proxies controlados por el operador

La extensión de navegador maliciosa para Twitch JeetBot tuvo aproximadamente 30 500 instalaciones desde las tiendas de Chrome y Firefox (una estimación de instalaciones, no un recuento confirmado de vulneraciones).

Qué ocurrió: Socket descubrió que capturaba tokens de OAuth de Twitch con alcance de cuenta y los reenviaba en un parámetro de consulta &auth= a través de proxies controlados por el operador. Los informes no establecen que los tokens se usaran para actividad no autorizada. La versión 85.8.7 de Firefox (16 de septiembre) y la versión 85.8.9 de Chrome (informada el 25 de septiembre) detuvieron el reenvío. El operador rechazó calificar la extensión de maliciosa, pero reconoció problemas de seguridad y de divulgación. (Socket)

La conclusión defensiva: audite las extensiones de navegador instaladas y trate cualquier token que haya aparecido en una URL como expuesto. Los usuarios de JeetBot deben revocar el acceso de la aplicación a su cuenta de Twitch.

Fuente: Socket

Microsoft Entra comienza a habilitar automáticamente las passkeys antes de la retirada de la MFA por SMS y voz

Microsoft Entra comenzó a habilitar automáticamente las passkeys el 1 de septiembre de 2026 para los usuarios de la nube pública ya habilitados para MFA por SMS o voz en la política de métodos de autenticación de Entra o en la configuración heredada.

Qué ocurrió: cuando estos usuarios inician sesión la siguiente vez y completan la MFA, se les invita a registrar una passkey. Por lo general, el aviso puede posponerse, y hay disponible una exclusión temporal a nivel de inquilino hasta el 1 de febrero de 2027. La entrega de SMS y voz proporcionada por Microsoft se retira el 1 de febrero de 2027 para la mayoría de los usuarios, y el 1 de julio de 2027 para los administradores globales y los usuarios externos. Las organizaciones con una necesidad legítima pueden seguir usando SMS o voz a través de un proveedor de telefonía compatible. Esa opción de configuración está prevista para el 30 de octubre de 2026.

Por qué importa: el cambio aleja el valor predeterminado de los factores basados en teléfono, el tipo que la campaña BigBear 2.0 descrita arriba demuestra que puede interceptarse. Los inquilinos que no hagan nada verán ahora avisos de registro y perderán la entrega de SMS y voz proporcionada por Microsoft en 2027.

La conclusión defensiva: inventaríe qué usuarios y procesos de servicio aún dependen de SMS o voz. Comience el registro de passkeys con los administradores y los usuarios externos, cuyo plazo vence antes. Decida antes del 1 de febrero de 2027 si necesita un proveedor de telefonía o puede retirar estos métodos por completo.

Fuente: Microsoft Learn

Qué significa esto para su equipo

La mayoría de los casos de este mes se reducen a credenciales que siguieron funcionando después de que deberían haberse detenido. Seis pasos que su equipo puede tomar para evitar problemas similares:

1. Inventaríe las credenciales no humanas. Liste las claves de API, los tokens de cuentas de servicio, las claves privadas de aplicaciones de GitHub y los secretos de CI/CD de la misma forma en que lista las cuentas de usuario. Asigne a cada una un responsable designado y un plan documentado de caducidad o rotación. Tanto el caso de Brevo como el de las claves de aplicaciones de GitHub implicaron claves que nadie estaba rastreando.
2. Limite el alcance y establezca caducidades. Conceda a cada clave solo los permisos que la integración realmente necesita, y establezca una caducidad siempre que el proveedor lo admita. Donde no lo admita, programe una rotación manual.
3. Pruebe la revocación antes de necesitarla. Para cada proveedor, confirme qué hace realmente revocar una sesión, un JWT, una concesión de OAuth o un token de actualización. Después de un incidente, ejecute la ruta de revocación de principio a fin en lugar de confiar en la documentación. Revoque las sesiones y rote los secretos, no se limite a restablecer la contraseña.
4. Cierre las brechas de OAuth y de sesión. Deshabilite los flujos de código de dispositivo para los usuarios que no los necesiten, y traslade a los administradores a passkeys o llaves FIDO2 antes de la retirada de SMS y voz de Microsoft en 2027. Donde sea posible, vincule las sesiones a los dispositivos.
5. Aplique primero los parches a la infraestructura de identidad expuesta. Cisco ISE, JFrog Artifactory, Cleo Harmony y WSO2 emiten o validan el acceso para todo lo que hay detrás de ellos. Trate sus actualizaciones como una prioridad por encima de los parches rutinarios.
6. Registre lo suficiente para reconstruir un incidente. Mantenga registros de sesiones y tokens con el detalle suficiente para mostrar quién se autenticó, desde dónde y con qué token. El NIST IR 8587 es una lista de verificación práctica para esto y para los puntos anteriores.

Para más información relacionada, consulte nuestras guías sobre el ciclo de vida de la rotación de secretos y los secretos codificados.

Noticias mensuales de ciberseguridad: la autenticación bajo asedio

Los incidentes de agosto de 2026 evitaron la autenticación por completo: exploits confirmados en N-able N-central y SharePoint, más de 9300 claves de AWS expuestas, y Mirage2FA secuestrando sesiones después de la MFA. Esto es lo que los equipos de TI y seguridad deben parchear y auditar primero.

PassworkPasswork Team

Seguridad de contraseñas poscuántica: qué cambia y qué hacer

El algoritmo de Grover apenas hace mella en una contraseña correctamente hasheada. El algoritmo de Shor destroza el intercambio de claves RSA que tiene al lado. Esta es la auditoría de 3 capas que le dice cuál de los dos es realmente su problema.

PassworkPasswork Team

Informe 2026 IBM Cost of a Data Breach: la amenaza de IA de 6 millones de USD que nadie soluciona

Los costos globales de las vulneraciones alcanzaron un récord de 4,99 millones de USD en 2026, con una detección que tarda 247 días. Los ataques impulsados por IA aumentan un 56 %, pero la crisis real es esta: los defensores despliegan IA en todas partes excepto donde entran los atacantes. El 92 % de las organizaciones vulneradas por IA no contaban con controles de acceso adecuados.

PassworkAlex Muntyan

September 2026 cybersecurity news was dominated by forged tokens, replayed sessions, and leaked API keys that kept working after the password was changed or never needed. Two vulnerabilities are already on CISA's Known Exploited Vulnerabilities list, and one leaked vendor key put 100,000+ sites at risk.

• Cisco ISE: CVE-2026-76460, an authentication bypass with confirmed active exploitation (Cisco).
• EvilTokens: Microsoft disrupted a device-code phishing service linked to more than 12,000 compromised inboxes across over 10,000 organizations (Microsoft).
• Brevo and Cloudflare: a compromised API key put more than 100,000 sites at potential risk (Sansec).
• JFrog Artifactory: a flaw exploited in honeypots to mint administrator tokens (SecurityWeek).
• Cleo Harmony: a public exploit for a JWT refresh-token flaw (SecurityWeek).
• CyberArk: 10 security bulletins on four dates, including one Critical (CyberArk).
• GitHub App keys: GitGuardian found 474 of 4,802 leaked private keys still valid, authenticating as 440 apps (GitGuardian).
• NIST IR 8587: final guidance on protecting tokens and assertions, published September 15 (NIST).

Each case below shows a different way a credential keeps working after it should have stopped: forged, replayed, leaked, or minted on demand. Details, affected versions, and fixes follow, with a short list of team-level actions at the end.

Active exploitation of an authentication bypass in Cisco Identity Services Engine (CVE-2026-76460)

Cisco published an advisory on September 16, 2026 for CVE-2026-76460, a critical, unauthenticated authentication-bypass vulnerability in an Identity Services Engine (ISE) API. Cisco rates it CVSS 3.1 Base 10.0 (Critical) and confirmed active exploitation. CISA added the CVE to its Known Exploited Vulnerabilities catalog the same day.

What happened: A crafted request to the affected API endpoint lets an attacker bypass ISE's web-based management interface and gain unauthorized access to an affected ISE or ISE-PIC device, without valid credentials. Cisco's PSIRT confirmed it was aware of in-the-wild attacks. The exact date exploitation began has not been disclosed.

Why it matters: ISE is a network-access policy platform. Unauthorized access could create serious deployment-specific risk to administration and policy operations, but the available sources don't establish that every customer's downstream RBAC or MFA decisions were altered. Impact depends on how a given organization has ISE deployed.

The defensive takeaway: Cisco says no workaround addresses the flaw. Upgrading to a fixed release is the complete remediation. As a temporary mitigation, Cisco recommends infrastructure ACLs (iACLs) that allow only required management- and control-plane traffic to the affected device. Review each node's access.log for suspicious usernames and cross-check network and firewall logs outside the appliance itself. These are detection and response steps, not a substitute for patching.

Sources: Cisco; CISA KEV

Microsoft disrupts EvilTokens, an OAuth device-code phishing service

On September 22, 2026, Microsoft's Digital Crimes Unit, working with partners, disrupted infrastructure behind EvilTokens, a phishing-as-a-service platform linked to more than 12,000 compromised inboxes across over 10,000 organizations worldwide.

What happened: EvilTokens abused OAuth 2.0 device-authorization flows, the mechanism designed for devices without a browser, such as smart TVs or CLI tools, to trick users into approving a sign-in on the attacker's behalf. Microsoft separately disclosed passkey-themed social-engineering activity observed since May 2026. In one investigated sequence, a passkey lure led to device-code phishing. In other investigated patterns, attackers used help-desk pretexts or registered attacker-controlled authentication methods. Microsoft's reporting doesn't establish that every sequence combined all of these steps into one attack chain.

Why it matters: Device-code phishing sidesteps the parts of authentication that get the most defensive attention. There's no fake login page to spot and no password typed into an attacker's site. The victim approves the sign-in through Microsoft's own legitimate page, believing it's routine. That said, a victim without an active Microsoft session can still be prompted for a real password and MFA challenge, so this technique doesn't universally erase every authentication step.

The defensive takeaway: Disable device-code authentication flows for users who don't operationally need them, and monitor for abnormal device-code sign-in volume as a detection signal. Where the flow is genuinely required, gate it behind conditional-access policy.

Sources: Microsoft; Microsoft (passkey-themed activity)

A single overprivileged Cloudflare API key put 100,000+ sites at risk

On September 14, 2026, attackers used a compromised, broadly privileged Cloudflare API key belonging to email and marketing platform Brevo to deploy a malicious Cloudflare Worker that altered Brevo-embedded assets on customer sites.

What happened: Sansec's telemetry recorded the malicious Worker serving content from 16:05 to 20:13 UTC on September 14, roughly four hours. Brevo's incident write-up describes the Worker as active for about five and a half hours, a longer window than Sansec directly observed. Sansec estimated that more than 100,000 sites using affected Brevo components may have been exposed to malicious content during that period.

Why it matters: One long-lived, full-permission Cloudflare API key, tied to a marketing-automation vendor, became a distribution channel for malicious code across a large number of third-party sites. Cloud API keys with broad scopes and no expiration are exactly the credential type that traditional password policy doesn't cover.

The defensive takeaway: Scope API keys to the minimum permission set an integration actually needs, set expirations even on service-level keys, and run continuous secret scanning across repositories and deployment pipelines, not just employee password vaults. Monitoring for unexpected Worker deployments or routing changes would likely have caught this faster than a manual audit.

Sources: Sansec; Brevo

JFrog Artifactory flaw used to mint admin tokens (CVE-2026-82329)

JFrog published a fix for CVE-2026-82329 on August 28, 2026. On September 1, WatchTowr reported honeypot activity consistent with attackers exploiting the flaw to generate administrator tokens.

What happened: WatchTowr's honeypots captured exploitation attempts against a small number of source IPs, some of which appeared to be verification-only activity rather than follow-through attacks. That's evidence the vulnerability is exploitable and being probed. It doesn't establish broad scanning across the internet or confirmed mass exploitation of customer instances.

Why it matters: Artifact repositories sit near the center of the software supply chain. They hold federation trust relationships with other repositories and often carry embedded credentials for downstream systems. An attacker who can generate an admin token doesn't need to steal one, they create valid access on demand.

The defensive takeaway: For self-hosted Artifactory, upgrade to the fixed release for your branch: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, or 7.161.20. JFrog says affected cloud environments were already fortified. If logs show exploitation or suspicious token issuance, revoke and reissue potentially exposed admin tokens and audit federation configurations. The available reporting supports honeypot-observed exploitation, not confirmed compromise of customer instances.

Sources: JFrog; SecurityWeek

Public exploit for a JWT refresh-token flaw in Cleo Harmony (CVE-2026-84115)

A public exploit for CVE-2026-84115 was reported on September 2, 2026, shortly after the CVE record was published on September 1.

What happened: The flaw affects Cleo Harmony versions through 5.8.1.10 and is fixed in Harmony 5.8.1.11. The CVE record describes a remotely exploitable issue in the /api/connections JWT Refresh Token Handler: manipulating the Bearer argument results in improper privilege management. SecurityWeek describes the same issue as allowing authentication bypass and privilege elevation. The available reporting establishes public exploitability and researcher reproduction. It doesn't establish confirmed exploitation of customer systems, nor that a manipulated token persists beyond the original session's expiry.

Why it matters: Refresh tokens are meant to extend a session quietly, without forcing a fresh login. A flaw in how one is validated turns that convenience feature into a potential persistence risk, which is reason enough to patch even without confirmed exploitation.

The defensive takeaway: Upgrade to Harmony 5.8.1.11 promptly. If exposure is suspected, follow Cleo's current guidance, review authentication and privilege changes from the relevant window, and revoke outstanding refresh tokens where the deployment supports that control. A public exploit's existence doesn't by itself confirm compromise or persistent access.

Sources: NVD; SecurityWeek

CyberArk ships ten security bulletins across its PAM product line

CyberArk released 10 security bulletins in September 2026, in four dated batches.

What happened: CyberArk released 10 security bulletins in four batches during September 2026, addressing High-severity issues across endpoint privilege management agents, self-hosted gateway and vault components, privileged-access analytics, and database credential management, as well as a Critical issue—CA26-44—affecting certain self-hosted Password Vault Web Access (PVWA) versions.

Why it matters: PAM systems often manage or provide access to privileged credentials and sensitive infrastructure. A concentrated set of security updates is a reminder that these environments require continuous patch management, clear access governance, and reliable auditability. The advisories do not, by themselves, indicate active exploitation.

The defensive takeaway: Organizations using affected products should review the advisories and prioritize remediation according to severity, exposure, and the potential impact on credential-related systems. More broadly, security teams should maintain visibility into who can access sensitive credentials and be able to review that access when needed.

Source: CyberArk; CyberIAM bulletin board

Leaked GitHub App private keys keep working long after exposure

GitGuardian tested 4,802 leaked GitHub App private keys found in public sources and found 474 still authenticating as 440 distinct live apps.

What happened: A GitHub App private key has no automatic expiry and can remain usable until it's manually revoked or deleted. Among the 474 still-valid keys GitGuardian tested, 207 carried repository content-write permission, 40 could administer self-hosted runners, 98 could control workflows, and 44 held organization-administration privileges. A key committed years ago may still authenticate if it hasn't been revoked or deleted.

A related pattern surfaced in a WSO2 API-management flaw, CVE-2026-5430. The advisory dates to May 2026 and the CVE was published in August. The September news was exploitation reporting, not a new disclosure. An attacker can craft a JWT with an unsupported signing algorithm and exploit WSO2's faulty validation to bypass authentication. The service doesn't need to mint a token itself. WatchTowr's honeypot captured administrator-privilege forged JWTs against it on September 13, and CISA added the CVE to its Known Exploited Vulnerabilities catalog on September 24. Backend credentials, consumer keys, or secrets were reported as potentially reachable, not confirmed stolen.

Why it matters: A public leak creates potentially persistent access until the key is revoked or deleted. It doesn't by itself prove the key was used or that data was accessed. The WSO2 case shows a related pattern one layer down the stack: an attacker doesn't need a leaked key at all if the validation logic itself can be tricked into accepting a forged one.

The defensive takeaway: Maintain an owner and a documented rotation/revocation process for every GitHub App key. If exposure is suspected or confirmed, generate a replacement and revoke or delete the old key promptly; periodic rotation reduces exposure time, though GitHub doesn't prescribe a universal schedule. For WSO2 deployments, apply the vendor's fix, review logs for the September exploitation window, and rotate credentials the API-management layer had access to.

Sources: GitGuardian; GitHub docs; WSO2 advisory; The Hacker News

NIST and CISA finalize guidance on protecting identity and access tokens

NIST and CISA finalized IR 8587 on September 15, 2026, after an initial public draft dated December 22, 2025.

What happened: The implementation guidance is written primarily for federal agencies and the cloud service providers they use, covering identity tokens, access tokens, and assertions in SSO, federation, and API-access scenarios. Its recommendations summarize key-management, token-verification, lifecycle (including lifetime and revocation), and continuous-monitoring practices, with responsibilities divided between providers, consuming agencies, and cloud consumers.

Why it matters: Several of the failures described above, forged JWTs, admin tokens generated through validation flaws, non-expiring API keys, fall inside the categories this report addresses: verification gaps, missing lifecycle controls, and unclear provider-versus-customer responsibility for revocation. That overlap is useful even for organizations outside the federal space.

The defensive takeaway: Use NIST IR 8587 as a working checklist against current practices: confirm token lifetimes are bounded, revocation paths are tested rather than just documented, and session logging captures enough detail to reconstruct a token-based incident after the fact.

Sources: NIST; CISA

CloudSEK details BigBear 2.0, an adversary-in-the-middle service that replays Microsoft 365 sessions after MFA

CloudSEK published its BigBear 2.0 research on September 7, 2026. Its TRIAD team discovered the operation in June, which doesn't establish when all campaign activity began.

What happened: The Evilginx2-based adversary-in-the-middle service relayed Microsoft 365 sign-ins. It captured credentials and the Microsoft-issued session cookie after victims completed MFA, then let attackers replay the authenticated sessions. CloudSEK's panel contained 4,148 session-cookie records and 474 completed MFA-bypassed authentications. BleepingComputer reported that 258 distinct organizations had at least one such completed compromise, while 461 organizations appeared in the broader targeting dataset. The 4,148 figure is a cookie-record count, not a confirmed count of unique victims. (CloudSEK; BleepingComputer)

Why it matters: MFA that the victim completes on a proxied page protects nothing once the session cookie is stolen. The attacker inherits an already authenticated session. Codes and push approvals don't stop this pattern.

The defensive takeaway: Prioritize phishing-resistant methods such as passkeys and FIDO2 security keys for administrators and high-risk users. Review conditional access policies that bind sessions to compliant devices. Alert on sign-ins where the session's IP address or device changes soon after MFA.

Sources: CloudSEK; BleepingComputer

Okta analyzes infostealer dump with 44,791 unique JWTs, 1,843 tokens still valid at release

Okta published research on September 9, 2026 on a 7 GB infostealer dump posted to Telegram on August 2.

What happened: The dump held data from 5,871 infected machines. Okta identified 44,791 unique JWTs, including 555 likely related to AI-service authentication, plus 2,937 authentication-related JWEs. As of the dump's release, 1,843 JWTs and JWEs hadn't expired. Okta said unexpired session secrets could potentially be replayed to bypass credential-based authentication. The research didn't report a successful replay or a confirmed account takeover. Whether replay works depends on the service and on controls such as token binding or IP allowlisting. (Okta)

Why it matters: Infostealers take whatever sits on the endpoint, and tokens are part of that haul. Token lifetime sets how long a stolen secret stays useful. The AI-service tokens in the set show that the exposure now reaches newer tools that teams often adopt outside central identity management.

The defensive takeaway: Shorten token lifetimes where the service allows it, and bind tokens to a device or network where supported. After an infostealer infection, revoke sessions and rotate secrets, not just reset the password. Include AI-service accounts in your inventory of tokens and API keys.

Source: Okta

JeetBot Twitch extension forwarded OAuth tokens through operator-controlled proxies

The malicious Twitch browser extension JeetBot had roughly 30,500 store installations across Chrome and Firefox (an installation estimate, not a confirmed compromise count).

What happened: Socket found it captured account-scoped Twitch OAuth tokens and forwarded them in an &auth= query parameter through operator-controlled proxies. The reporting doesn't establish that the tokens were used for unauthorized activity. Firefox version 85.8.7 (September 16) and Chrome version 85.8.9 (reported September 25) stopped the forwarding. The operator disputed calling the extension malicious but acknowledged security and disclosure problems. (Socket)

The defensive takeaway: Audit installed browser extensions, and treat any token that appeared in a URL as exposed. Users of JeetBot should revoke the app's access to their Twitch account.

Source: Socket

Microsoft Entra begins auto-enabling passkeys ahead of SMS and voice MFA retirement

Microsoft Entra began auto-enabling passkeys on September 1, 2026 for public-cloud users already enabled for SMS or voice MFA in the Entra Authentication Methods Policy or legacy settings.

What happened: When these users next sign in and complete MFA, they are nudged to register a passkey. The nudge can typically be snoozed, and a temporary tenant opt-out is available through February 1, 2027. Microsoft-provided SMS and voice delivery retires on February 1, 2027 for most users, and on July 1, 2027 for Global Administrators and external users. Organizations with a legitimate need can continue SMS or voice through a supported telephony provider. That configuration option is scheduled for October 30, 2026.

Why it matters: The change moves the default away from phone-based factors, the type the BigBear 2.0 campaign above shows can be relayed. Tenants that do nothing will see registration prompts now and lose Microsoft-provided SMS and voice delivery in 2027.

The defensive takeaway: Inventory which users and service processes still rely on SMS or voice. Start passkey registration with administrators and external users, whose deadline is earliest. Decide before February 1, 2027 whether you need a telephony provider or can retire these methods entirely.

Source: Microsoft Learn

What this means for your team

Most of this month's cases come down to credentials that kept working after they should have stopped. Six steps your team can take to avoid similar problems:

1. Inventory non-human credentials. List API keys, service-account tokens, GitHub App private keys, and CI/CD secrets the way you list user accounts. Give each a named owner and a documented expiration or rotation plan. The Brevo and GitHub App cases both involved keys that nobody was tracking.
2. Scope and expire. Grant each key only the permissions the integration needs, and set an expiration wherever the provider supports one. Where it doesn't, schedule manual rotation.
3. Test revocation before you need it. For each provider, confirm what revoking a session, JWT, OAuth grant, or refresh token actually does. After an incident, run the revocation path end to end instead of relying on the documentation. Revoke sessions and rotate secrets, not just reset the password.
4. Close the OAuth and session gaps. Disable device-code flows for users who don't need them, and move administrators to passkeys or FIDO2 keys ahead of Microsoft's 2027 SMS and voice retirement. Where supported, bind sessions to devices.
5. Patch exposed identity infrastructure first. Cisco ISE, JFrog Artifactory, Cleo Harmony, and WSO2 issue or validate access for everything behind them. Treat their updates as a priority over routine patching.
6. Log enough to reconstruct an incident. Keep session and token logs detailed enough to show who authenticated, from where, and with which token. NIST IR 8587 is a usable checklist for this and the points above.

For related reading, see our guides on the secrets rotation lifecycle and hardcoded secrets.

Monthly cybersecurity news: Authentication under siege

August 2026’s incidents bypassed authentication entirely: confirmed exploits in N-able N-central and SharePoint, 9,300+ exposed AWS keys, and Mirage2FA hijacking sessions after MFA. Here’s what IT and security teams need to patch and audit first.

PassworkPasswork Team

Post-quantum password security: What changes and what to do

Grover’s algorithm barely dents a properly hashed password. Shor’s algorithm guts the RSA key exchange sitting next to it. Here’s the 3-layer audit that tells you which one is actually your problem.

PassworkPasswork Team

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

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

PassworkAlex Muntyan

Começa um novo período letivo e a fila do helpdesk enche-se de pedidos de reposição antes de arrancar a primeira aula. Um colaborador não consegue iniciar sessão no sistema de gestão da aprendizagem. Um departamento partilha um único início de sessão numa ferramenta de investigação e ninguém se lembra de quem definiu a palavra-passe nem de quem mais tem uma cópia.

É isto que compromete a segurança das palavras-passe nas instituições de ensino: credenciais dispersas por dezenas de sistemas e partilhadas sem supervisão. Uma escola ou universidade pode manter inícios de sessão separados para registos de estudantes, plataformas de aprendizagem, ferramentas de investigação e bases de dados de finanças, RH e proteção de menores, cada um com os seus próprios hábitos de palavra-passe.

O caos das palavras-passe alastra para além do helpdesk de TI e chega ao resto da organização. Os colaboradores perdem horas a tentar obter acesso em vez de ensinar ou investigar. As credenciais não geridas alargam os caminhos que os atacantes utilizam para entrar. Registos de acesso deficientes transformam uma auditoria de rotina numa constatação de incumprimento. A gestão de acessos é a forma de as instituições fecharem estas três lacunas em simultâneo.

O caos das palavras-passe é um problema de continuidade de acesso

O caos das palavras-passe acumula-se porque nada volta a rever uma decisão de acesso depois de tomada. Um início de sessão é partilhado para um projeto e continua partilhado depois de o projeto terminar. Um colaborador é adicionado a um sistema, muda de função e mantém o acesso antigo porque ninguém tem a tarefa de o verificar. Multiplique-se isto por cada sistema acrescentado ao longo de uma década e ninguém consegue dizer com certeza quem tem acesso a quê.

Esta lacuna manifesta-se de forma mais evidente na saída de colaboradores. Remover o acesso de um colaborador que sai devia ser uma tarefa de TI de rotina. Em vez disso, transforma-se numa busca por dezenas de sistemas desligados entre si, porque o registo de quem tem acesso a quê nunca foi centralizado.

Como o caos das palavras-passe atrasa o trabalho no ensino

O caos das palavras-passe revela-se primeiro como perda de tempo. Reposições, desbloqueios e alterações manuais de contas transformam-se numa fila recorrente que afasta a equipa de TI do apoio ao ensino e do trabalho de segurança.

O acesso fragmentado interrompe fluxos de trabalho críticos

Os sistemas essenciais no ensino incluem plataformas de gestão da aprendizagem, sistemas de informação de estudantes, ambientes de investigação, e-mail, RH, finanças, sistemas de biblioteca e registos de proteção de menores. Perder o acesso a qualquer um deles pode atrasar a atribuição de classificações, bloquear um prazo de investigação ou deixar temporariamente inacessível um registo de proteção de menores. A gravidade depende do impacto do sistema na atividade e da qualidade dos mecanismos de recuperação.

As credenciais partilhadas diluem a responsabilidade

Os inícios de sessão partilhados eliminam a responsabilização. Quando várias pessoas utilizam o mesmo início de sessão numa ferramenta partilhada, a instituição perde a capacidade de dizer quem fez o quê. Isso importa no dia a dia, ao investigar uma alteração inesperada. Importa ainda mais quando uma função muda e alguém precisa de perder o acesso sem inutilizar a conta para todos os que continuam a utilizá-la.

Porque o caos das palavras-passe aumenta o risco de incidentes de segurança

O caos das palavras-passe alarga os caminhos que os atacantes utilizam para entrar. Palavras-passe reutilizadas, contas partilhadas não geridas e uma saída de colaboradores deficiente tornam os ataques baseados em credenciais mais fáceis de concretizar e mais difíceis de conter.

O 2026 Data Breach Investigations Report da Verizon concluiu que a exploração de vulnerabilidades liderou o acesso inicial em 31 % das violações, à frente do abuso de credenciais pela primeira vez. Mas o abuso de credenciais continuou a surgir, em algum ponto da cadeia de ataque, em 39 % das violações analisadas pela Verizon. Uma palavra-passe roubada ou reutilizada não tinha de ser o primeiro passo para ter importância. Bastava estar ali, reutilizável, depois de um atacante entrar por outra porta.

O National Cyber Security Centre do Reino Unido explica porque é que essa reutilização persiste: a sobrecarga de palavras-passe incentiva comportamentos de compensação inseguros, como a reutilização, fórmulas previsíveis e armazenamento inseguro. Pedir aos colaboradores que «escolham uma palavra-passe mais forte» não resolve um sistema em que doze departamentos mantêm, cada um, a sua própria folha de cálculo de inícios de sessão partilhados. O 2025 Threat Landscape da ENISA indica que o phishing continuou a ser o principal método de intrusão inicial e uma técnica eficaz para o roubo de credenciais e o sequestro de sessões, precisamente o tipo de roubo que as credenciais não geridas e reutilizadas facilitam.

Como uma credencial roubada se transforma numa violação de dados

Uma única palavra-passe reutilizada raramente fica confinada a uma só conta. Os atacantes passam do primeiro início de sessão comprometido a um acesso mais amplo numa sequência previsível. Cada passo depende de o anterior passar despercebido.

A cadeia de ataque costuma ter este aspeto:

• Um atacante envia uma mensagem de phishing que imita uma página de início de sessão conhecida ou explora diretamente um sistema sem correções
• Se o phishing resultar, um utilizador entrega credenciais reais sem se aperceber
• O atacante testa essas credenciais noutros sistemas, uma técnica que funciona muito mais vezes quando as palavras-passe são reutilizadas
• Se a conta comprometida tiver acesso amplo, partilhado ou persistente, o atacante pode avançar mais antes de alguém dar por isso

Uma credencial roubada causa mais danos quando concede acesso amplo ou partilhado, porque a instituição perde tanto a contenção como a capacidade de rastrear o que aconteceu. A introdução à gestão de identidades e acessos do NCSC afirma-o de forma direta: controlos de IAM fracos permitem que um atacante que obtenha uma credencial se faça passar por utilizador legítimo em vários sistemas.

Fredrik Blomqvist, diretor de segurança da Uppsala University, defendeu a mesma ideia a partir da própria função de segurança de uma universidade, em março de 2026: o phishing continua a ser o tipo de ataque mais comum que a instituição regista e o fator humano, e não a infraestrutura tecnológica, continua a ser o seu maior risco de cibersegurança.

O acesso de terceiros alarga o risco das credenciais

Os fornecedores externos acrescentam mais uma camada de exposição, porque as instituições de ensino subcontratam com frequência sistemas de informação de estudantes, plataformas de aprendizagem e processamento de pagamentos. O 2026 DBIR da Verizon concluiu que o envolvimento de terceiros atingiu 48 % de todas as violações, um aumento de 60 % face ao ano anterior. Entre essas organizações terceiras, apenas 23 % tinham corrigido por completo a MFA em falta ou incorreta nas respetivas contas cloud. O acesso de terceiros pode estender o risco das credenciais para além dos sistemas da própria instituição, pelo que as ligações de fornecedores exigem o mesmo nível de revisão de identidades e acessos que as contas internas.

O ransomware torna a recuperação e a revogação mais urgentes

Depois de um atacante entrar, a rapidez da contenção determina a dimensão dos danos que uma única credencial roubada pode causar. A Sophos inquiriu 441 instituições de ensino que tinham sofrido um ataque de ransomware no ano anterior e concluiu que 29 % dos inquiridos do ensino básico e secundário e 58 % dos inquiridos do ensino superior declararam um ataque que resultou na cifragem de dados. Este valor descreve o que acontece depois de um atacante entrar, entre instituições já atingidas: é uma medida da rapidez de contenção, não uma afirmação sobre a causa da violação. É um motivo para tratar a revogação rápida de credenciais como uma etapa testada da resposta a incidentes.

Porque a falta de gestão de acessos aumenta o risco de conformidade com o RGPD e a NIS2

As escolas, os colégios e as universidades que tratam dados pessoais ou operam sistemas críticos elegíveis ficam abrangidos pelo RGPD, pela NIS2 ou por ambos. 

• O RGPD aplica um critério de segurança baseado no risco, dentro de limites materiais e territoriais definidos 
• A NIS2 aplica-se a entidades essenciais e importantes que cumpram os critérios da Diretiva quanto ao tipo de entidade, à dimensão ou a vias especiais, conforme a respetiva transposição para o direito nacional 

O RGPD estabelece um critério baseado no risco

RGPD (Regulamento Geral sobre a Proteção de Dados) é a lei central da UE em matéria de proteção de dados. Aplica-se ao tratamento de dados pessoais no seu âmbito material e territorial. Isto inclui o tratamento efetuado no contexto de uma organização estabelecida na UE, bem como determinados tratamentos realizados por organizações fora da UE que oferecem bens ou serviços a pessoas na UE ou monitorizam o seu comportamento nesse território.

O artigo 5.º, n.º 1, alínea f), do RGPD exige proteção contra o tratamento não autorizado ou ilícito e contra a perda ou os danos acidentais. O artigo 32.º vai mais longe: prevê medidas adequadas ao risco, incluindo, consoante o caso, a confidencialidade, a integridade, a disponibilidade, a resiliência, a capacidade de restabelecer o acesso após um incidente e testes regulares.

Numa secretaria académica que guarda os registos dos estudantes, esta formulação baseada no risco traduz-se em controlos práticos: quem pode consultar um registo, como o acesso é registado e com que rapidez o acesso pode ser restabelecido se um sistema falhar.

A abrangência da NIS2 depende do âmbito

NIS2 (a segunda Diretiva da UE relativa à Segurança das Redes e da Informação) cria obrigações de cibersegurança para as organizações classificadas como entidades essenciais e importantes que se enquadrem no âmbito da Diretiva. Essa avaliação começa nas regras da própria Diretiva sobre tipo de entidade, dimensão e vias especiais e depende depois da forma como o Estado-Membro em causa as transpôs e aplicou. O ensino não consta como setor autónomo no Anexo I nem no Anexo II, mas uma escola, um colégio ou uma universidade pode, ainda assim, estar no âmbito da Diretiva por via de um tipo de entidade listado, do estatuto de administração pública ou de outra via aplicável.

Para uma entidade abrangida, o artigo 21.º exige medidas de gestão de riscos adequadas e proporcionadas. O considerando 79 refere que essas medidas devem abordar a segurança dos recursos humanos e incluir políticas de controlo de acesso adequadas.

Para uma entidade que tome conhecimento de um incidente significativo, o artigo 23.º estabelece uma fase de alerta rápido no prazo de 24 horas, uma fase de notificação do incidente no prazo de 72 horas e um relatório final, o mais tardar, um mês após a notificação. Os incidentes em curso seguem um percurso separado de relatórios intercalares.

Cumprir o prazo de 24 horas do artigo 23.º exige saber quem tinha acesso ao sistema comprometido e quando esse acesso foi alterado pela última vez. Quando os departamentos gerem as palavras-passe de forma independente, com uma folha de cálculo num gabinete e uma palavra-passe reencaminhada por chat noutro, essa informação, em regra, não fica registada em lado nenhum. Os auditores que peçam provas de que as decisões de acesso são proporcionadas, documentadas e passíveis de revisão encontrarão a mesma lacuna.

A abrangência do setor da educação depende da implementação nacional.  Nos Países Baixos, por exemplo, as universidades ficam abrangidas pela NIS2 em grande parte devido à propriedade intelectual gerada pela investigação, pois o governo considera esse conhecimento um ativo nacional. Recomenda-se confirmar o estatuto específico da instituição junto de especialistas jurídicos ou de conformidade, em vez de o assumir num sentido ou noutro.

A gestão de acessos fecha as lacunas de produtividade, risco e conformidade

A gestão de acessos é o que elimina os três problemas descritos acima: tempo dos colaboradores desperdiçado, maior exposição a violações e provas de conformidade insuficientes. Funciona ao controlar a identidade, a autenticação e as permissões como um único processo interligado em todos os sistemas que a instituição utiliza, em vez de deixar cada aplicação aplicar as suas próprias regras de palavra-passe.

Um gestor de palavras-passe empresarial é a camada prática que torna isto possível. 

• O armazenamento centralizado de credenciais, com permissões substitui a folha de cálculo partilhada e o post-it 
• A atribuição de responsáveis e o acesso baseado em funções eliminam as dúvidas sobre quem pode aceder a quê 
• A recuperação em autosserviço ou delegada reduz a fila de reposições às contas que realmente precisam da ajuda da equipa de TI 
• Os registos de auditoria e as revisões periódicas de acessos produzem as provas documentadas e passíveis de revisão que tanto o RGPD como a NIS2 exigem

Como os gestores de palavras-passe ajudam o ensino a gerir acessos em grande escala 

As orientações atuais do NIST sobre palavras-passe recomendam a autenticação multifator (MFA), tratam as passkeys como uma alternativa viável às palavras-passe e recomendam os gestores de palavras-passe, cofres seguros de credenciais que geram e armazenam palavras-passe únicas, para as contas que ainda utilizam uma. Isto cobre o nível de base: credenciais únicas, geradas e armazenadas de forma segura, em vez de reutilizadas ou anotadas.

Os gestores de palavras-passe de nível empresarial vão mais longe. As permissões baseadas em funções atribuem a responsabilidade ao nível do cofre, os registos de auditoria e as revisões de acessos produzem o rasto de provas que os auditores pedem, e a integração com diretórios liga o ciclo de vida das contas aos sistemas de RH e de TI em vez de uma lista de verificação manual. O guia do Passwork sobre gestão de palavras-passe em equipa explica como estes elementos funcionam em conjunto na prática.

A recuperação também sai beneficiada. Quando um dispositivo desaparece ou se suspeita de que uma credencial foi comprometida, um administrador pode suspender o acesso dessa pessoa ao cofre e rodar as credenciais afetadas sem perturbar os outros utilizadores que continuam a depender da mesma entrada partilhada. Um sistema gerido reduz o trabalho de busca e recuperação que uma credencial partilhada de outro modo cria e permite que os administradores atuem através de um processo documentado, em vez de seguirem um início de sessão por conversas de chat e documentos de integração.

Duas prioridades específicas do ensino

Os processos de joiner, mover e leaver (entrada, mudança e saída) merecem atenção especial no ensino, porque as mudanças de estudantes, de pessoal temporário, de prestadores de serviços e do período letivo originam alterações frequentes de contas, segundo um calendário previsível. A automatização do aprovisionamento e do desaprovisionamento em torno desses ciclos conhecidos elimina o passo manual em que o acesso mais vezes fica esquecido.

As contas partilhadas devem continuar a ser uma exceção controlada: concedidas deliberadamente, com responsável nomeado e revistas de forma periódica. O guia de partilha segura de palavras-passe do Passwork explica como uma ferramenta departamental partilhada pode manter responsáveis designados e acesso baseado em funções dentro de um cofre seguro com registo de auditoria, em vez de um único início de sessão a circular por mensagem de chat sem registo de quem o tem.

Um plano inicial em cinco passos para responsáveis de TI no ensino

Esta sequência de cinco passos adapta-se ao calendário letivo, pelo que as equipas de TI podem começar já, sem esperar por uma paragem de todo o sistema. Deve ser encarada como ponto de partida, não como um plano de implementação completo.

• Identifique os sistemas em que a perda de acesso ou o acesso não autorizado causaria mais danos. Dê prioridade aos registos de estudantes, aos dados de proteção de menores, aos sistemas de investigação e às finanças, à frente de ferramentas de menor risco.
• Inventarie as contas partilhadas, privilegiadas e sem responsável e atribua um responsável designado a cada uma. Só este passo costuma revelar contas de cuja criação ninguém se recorda.
• Meça a linha de base atual antes de alterar a política. Registe o volume de reposições, os bloqueios e os atrasos na integração ou na saída de colaboradores, para poder avaliar se uma alteração ajudou realmente. É também aqui que uma auditoria de configuração se justifica: o 2026 DBIR da Verizon concluiu que, na sua amostra de dispositivos avaliados, 97 % dos dispositivos falharam a verificação do número de tentativas de início de sessão permitidas antes do bloqueio e 90 % falharam a verificação que exige palavras-passe com pelo menos 15 carateres. Vale a pena testar diretamente esta distância entre a política documentada e a configuração aplicada.
• Dê prioridade, primeiro, à MFA e ao tratamento seguro de credenciais dos utilizadores de risco elevado. Os administradores, a equipa de TI e quem tenha acesso a sistemas financeiros ou de proteção de menores devem avançar antes da população geral de estudantes.
• Realize um piloto num departamento antes de alargar a escala. Execute o novo processo numa única equipa, reveja os controlos, a fricção operacional e os resultados observados e depois alargue-o. As instituições sem pessoal de segurança disponível 24 horas por dia não estão limitadas a resolver isto sozinhas: o setor do ensino superior da Polónia, por exemplo, está a organizar capacidade regional partilhada de monitorização especificamente para as universidades que não conseguem montar internamente uma cobertura 24/7.

A recomendação do NIST de combinar a MFA, ponderar as passkeys onde sejam adequadas e utilizar um gestor de palavras-passe nas contas que ainda precisam de um aplica-se diretamente ao passo quatro. Para os estudantes, o cálculo muda: a idade, as necessidades de acessibilidade e a disponibilidade de dispositivos influenciam que controlos fazem sentido para cada grupo. Um controlo que funciona para os colaboradores das finanças pode ser inadequado para uma criança de doze anos que inicia sessão numa aplicação de leitura.

Do caos das palavras-passe a um sistema gerido

O caos das palavras-passe raramente se anuncia como uma crise. Constrói-se um início de sessão partilhado e uma reposição manual de cada vez, até a instituição já não conseguir dizer com certeza quem tem acesso a quê. Resolvê-lo implica tratar a segurança das palavras-passe nas instituições de ensino como um modelo operacional: atribuir um responsável a cada conta, acompanhá-la e revê-la de forma periódica, como prática contínua.

Para as equipas prontas a centralizar credenciais partilhadas e a ligar o acesso aos sistemas de identidade existentes, o Passwork disponibiliza cofres controlados, permissões baseadas em funções, sincronização de diretórios e registos de auditoria. Estas capacidades podem apoiar partes de um programa mais amplo de governação de acessos. A sua adequação depende dos sistemas da instituição, da configuração, da avaliação de risco e dos restantes controlos de conformidade.

Perguntas frequentes

Caos das palavras-passe: Porque é um problema de negócio e como resolvê-lo

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

Passwork BlogAlex Muntyan

O que é a gestão de palavras-passe?

A gestão de palavras-passe é a prática de criar, armazenar, organizar e controlar o acesso a palavras-passe e a outras credenciais de autenticação de forma segura. Combina processos humanos com ferramentas de software especializadas para garantir que cada conta utiliza uma palavra-passe forte e única, sem exigir que os utilizadores as memorizem todas. Quer se trate de um indivíduo que procura proteger a sua vida online, quer de um administrador de TI que protege os ativos digitais da organização, compreender a gestão de palavras-passe é essencial.

PassworkPasswork Team

Como ensinar as crianças sobre segurança de palavras-passe: Dicas para pais

Um guia para pais sobre como ensinar segurança de palavras-passe às crianças: despertar uma motivação genuína, adaptar as lições à idade, criar frases-passe fortes, adicionar 2FA ou passkeys, detetar tentativas de phishing e recuperar contas com calma através de uma rotina repetível de Criar, Proteger e Recuperar.

PassworkPasswork Team

Ein neues Semester beginnt, und die Helpdesk-Warteschlange füllt sich mit Rücksetzungsanfragen, noch bevor die erste Vorlesung startet. Eine Mitarbeiterin kommt nicht ins Lernmanagementsystem. Eine Abteilung teilt sich einen Login für ein Forschungstool, und niemand erinnert sich mehr, wer das Passwort festgelegt hat oder wer sonst noch eine Kopie davon besitzt.

Genau das untergräbt die Passwortsicherheit in Bildungseinrichtungen: Zugangsdaten, die über Dutzende Systeme verteilt und ohne Kontrolle weitergegeben werden. Eine einzelne Schule oder Universität kann getrennte Logins für Schülerdaten, Lernplattformen, Forschungstools sowie Finanz-, HR- und Kinderschutz-Datenbanken betreiben – jede mit eigenen Passwortgewohnheiten.

Passwortchaos breitet sich vom IT-Helpdesk auf die gesamte Organisation aus. Mitarbeiter verbringen Stunden damit, sich um Zugriffsrechte zu kümmern, statt zu lehren oder zu forschen. Unverwaltete Zugangsdaten vergrößern die Angriffsflächen, über die Angreifer eindringen. Lückenhafte Zugriffsaufzeichnungen machen aus einem Routineaudit einen Compliance-Befund. Zugriffsverwaltung ist, wie Institutionen alle drei Lücken gleichzeitig schließen.

Passwortchaos ist ein Problem der Zugriffskontinuität

Passwortchaos entsteht, weil niemand eine einmal getroffene Zugriffsentscheidung erneut überprüft. Ein Login wird für ein Projekt geteilt und bleibt auch nach dessen Ende geteilt. Ein Mitarbeiter wird einem System hinzugefügt, wechselt die Rolle und behält den alten Zugriff, weil niemand für die Überprüfung zuständig ist. Multipliziert man das mit jedem System, das über ein Jahrzehnt hinzugekommen ist, kann niemand mehr mit Sicherheit sagen, wer worauf Zugriff hat.

Diese Lücke zeigt sich am deutlichsten beim Offboarding. Das Entfernen des Zugriffs eines ausscheidenden Mitarbeiters sollte eine Routineaufgabe der IT sein. Stattdessen wird es zu einer Suche durch Dutzende voneinander getrennte Systeme, weil die Aufzeichnung darüber, wer worauf Zugriff hat, von Anfang an nie zentral erfasst wurde.

Wie Passwortchaos den Bildungsbetrieb ausbremst

Passwortchaos zeigt sich zuerst als verlorene Zeit. Rücksetzungen, Entsperrungen und manuelle Kontoänderungen werden zu einer wiederkehrenden Warteschlange, die IT-Mitarbeiter von der Unterstützung der Lehre und von Sicherheitsaufgaben abzieht.

Fragmentierter Zugriff unterbricht kritische Arbeitsabläufe

Zu den wichtigsten Systemen im Bildungsbereich zählen Lernmanagementplattformen, Schülerinformationssysteme, Forschungsumgebungen, E-Mail, HR, Finanzen, Bibliothekssysteme und Kinderschutzakten. Der Verlust des Zugriffs auf eines dieser Systeme kann die Bewertung verzögern, eine Forschungsfrist blockieren oder eine Kinderschutzakte vorübergehend unerreichbar machen. Wie gravierend das wird, hängt vom Geschäftseinfluss des Systems und der Qualität seiner Wiederherstellungsmaßnahmen ab.

Geteilte Zugangsdaten verschleiern Verantwortlichkeit

Geteilte Logins heben die Verantwortlichkeit auf. Wenn mehrere Personen denselben Login für ein gemeinsames Tool nutzen, verliert die Institution die Möglichkeit zu sagen, wer was getan hat. Das spielt im Alltag eine Rolle, etwa bei der Fehlersuche nach einer unerwarteten Änderung. Es spielt eine noch größere Rolle, wenn sich eine Rolle ändert und jemandem der Zugriff entzogen werden muss, ohne das Konto für alle anderen, die es weiterhin nutzen, unbrauchbar zu machen.

Warum Passwortchaos das Risiko eines Sicherheitsvorfalls erhöht

Passwortchaos vergrößert die Angriffsflächen, über die Angreifer eindringen. Wiederverwendete Passwörter, unverwaltete geteilte Konten und mangelhaftes Offboarding machen auf Zugangsdaten basierende Angriffe leichter durchführbar und schwerer einzudämmen.

Verizons Data Breach Investigations Report 2026 ergab, dass Schwachstellen-Exploits in 31 % der Sicherheitsverletzungen zum initialen Zugriff führten und damit erstmals häufiger vorkamen als Zugangsdatenmissbrauch. Zugangsdatenmissbrauch tauchte jedoch weiterhin irgendwo in der Angriffskette von 39 % der von Verizon analysierten Sicherheitsverletzungen auf. Ein gestohlenes oder wiederverwendetes Passwort musste nicht der erste Schritt sein, um eine Rolle zu spielen. Es musste nur vorhanden und wiederverwendbar sein, sobald ein Angreifer durch eine andere Tür eindrang.

Das britische National Cyber Security Centre (NCSC) erklärt, warum diese Wiederverwendung immer wieder vorkommt: Passwortüberlastung begünstigt unsicheres Ausweichverhalten wie Wiederverwendung, vorhersehbare Muster und unsichere Speicherung. Mitarbeitern zu sagen, sie sollten „ein stärkeres Passwort wählen", behebt kein System, in dem zwölf Abteilungen jeweils ihre eigene Tabelle mit geteilten Logins führen. ENISAs Threat Landscape 2025 berichtet, dass Phishing die wichtigste Methode für den initialen Einbruch sowie eine wirksame Technik für Zugangsdatendiebstahl und Session-Hijacking blieb – genau die Art von Diebstahl, die unverwaltete, wiederverwendete Zugangsdaten erleichtert.

Wie gestohlene Zugangsdaten zu einer Sicherheitsverletzung führen

Ein einzelnes wiederverwendetes Passwort bleibt selten auf ein Konto beschränkt. Angreifer bewegen sich vom ersten kompromittierten Login zu weiterreichendem Zugriff in einer vorhersehbaren Abfolge. Jeder Schritt hängt davon ab, dass der vorherige unentdeckt bleibt.

Die Angriffskette sieht in der Regel so aus:

• Ein Angreifer verschickt eine Phishing-Nachricht, die eine bekannte Login-Seite nachbildet, oder nutzt direkt ein ungepatchtes System aus.
• Funktioniert das Phishing, gibt ein Nutzer echte Zugangsdaten weiter, ohne es zu merken.
• Der Angreifer testet diese Zugangsdaten an anderen Systemen – eine Technik, die deutlich häufiger funktioniert, wenn Passwörter wiederverwendet werden.
• Hat das kompromittierte Konto breiten, geteilten oder dauerhaften Zugriff, kann sich der Angreifer weiter ausbreiten, bevor es jemand bemerkt.

Gestohlene Zugangsdaten verursachen mehr Schaden, wenn sie weiten oder geteilten Zugriff gewähren, weil die Institution dann sowohl die Eindämmung als auch die Möglichkeit verliert, nachzuvollziehen, was passiert ist. NCSCs Einführung in die Identitäts- und Zugriffsverwaltung (IAM) macht diesen Punkt deutlich: Schwache IAM-Kontrollen lassen einen Angreifer, der eine Zugangsdatenkombination erlangt, über mehrere Systeme hinweg als legitimer Nutzer auftreten.

Fredrik Blomqvist, Chief Security Officer der Uppsala University, vertrat im März 2026 aus der eigenen Sicherheitsfunktion einer Universität heraus denselben Standpunkt: Phishing bleibt die häufigste Angriffsart, die die Institution beobachtet, und der Faktor Mensch – nicht der Technologie-Stack – ist weiterhin ihr größtes Cybersicherheitsrisiko.

Zugriff durch Drittanbieter erweitert das Zugangsdatenrisiko

Externe Anbieter schaffen eine zusätzliche Angriffsfläche, da Bildungseinrichtungen Schülerinformationssysteme, Lernplattformen und Zahlungsabwicklung routinemäßig auslagern. Verizons DBIR 2026 fand heraus, dass die Beteiligung Dritter an Sicherheitsverletzungen 48 % aller Sicherheitsverletzungen erreichte, ein Anstieg von 60 % gegenüber dem Vorjahr. Unter diesen Drittanbieter-Organisationen hatten nur 23 % fehlende oder fehlerhafte MFA auf ihren Cloud-Konten vollständig behoben. Zugriff durch Dritte kann das Zugangsdatenrisiko über die eigenen Systeme der Institution hinaus ausweiten, sodass Lieferantenverbindungen dieselbe Prüftiefe bei Identität und Zugriff benötigen wie interne Konten.

Ransomware macht Wiederherstellung und Widerruf dringlicher

Ist ein Angreifer erst einmal im System, bestimmt die Geschwindigkeit der Eindämmung, wie viel Schaden ein einzelnes gestohlenes Zugangsdatenpaar anrichten kann. Sophos befragte 441 Bildungseinrichtungen, die im Vorjahr einen Ransomware-Angriff erlebt hatten, und stellte fest, dass 29 % der Befragten aus dem Primär- und Sekundarbereich und 58 % der Befragten aus dem Hochschulbereich einen Angriff meldeten, der zur Verschlüsselung von Daten führte. Diese Zahl beschreibt, was nach dem Eindringen eines Angreifers bei bereits betroffenen Institutionen passiert – ein Maß für die Eindämmungsgeschwindigkeit, keine Aussage über die Ursache der Sicherheitsverletzung. Das ist ein Grund, einen schnellen Widerruf von Zugangsdaten als geprüften Schritt in der Incident Response zu verankern.

Warum fehlende Zugriffsverwaltung das DSGVO- und NIS2-Compliance-Risiko erhöht

Schulen, Hochschulen und Universitäten, die personenbezogene Daten verarbeiten oder qualifizierende kritische Systeme betreiben, unterliegen der DSGVO, NIS2 oder beiden. 

• Die DSGVO wendet innerhalb festgelegter sachlicher und räumlicher Grenzen einen risikobasierten Sicherheitsstandard an. 
• NIS2 gilt für wesentliche und wichtige Einrichtungen, die die Kriterien der Richtlinie zu Einrichtungsart, Größe oder Sonderregelung erfüllen, so wie sie im nationalen Recht umgesetzt wurden. 

Die DSGVO legt einen risikobasierten Standard fest

Die DSGVO (Datenschutz-Grundverordnung) ist das zentrale Datenschutzgesetz der EU. Sie gilt für die Verarbeitung personenbezogener Daten innerhalb ihres sachlichen und räumlichen Anwendungsbereichs. Dazu zählt die Verarbeitung durch eine in der EU niedergelassene Organisation sowie bestimmte Verarbeitungen durch Organisationen außerhalb der EU, die Personen in der EU Waren oder Dienstleistungen anbieten oder deren Verhalten dort beobachten.

Artikel 5 Abs. 1 lit. f DSGVO verlangt Schutz vor unbefugter oder unrechtmäßiger Verarbeitung sowie vor unbeabsichtigtem Verlust oder unbeabsichtigter Schädigung. Artikel 32 geht weiter: Er fordert risikoangemessene Maßnahmen, gegebenenfalls einschließlich Vertraulichkeit, Integrität, Verfügbarkeit, Belastbarkeit, der Fähigkeit, den Zugriff nach einem Vorfall wiederherzustellen, und regelmäßiger Überprüfung.

Für ein Studierendensekretariat, das Schülerdaten verwaltet, bedeutet diese risikobasierte Formulierung konkrete Kontrollen: wer einen Datensatz einsehen darf, wie der Zugriff protokolliert wird und wie schnell der Zugriff wiederherstellt werden kann, wenn ein System ausfällt.

Die NIS2-Abdeckung hängt vom Anwendungsbereich ab

NIS2 (die zweite EU-Richtlinie zur Netz- und Informationssicherheit) schafft Cybersicherheitspflichten für Organisationen, die als wesentliche und wichtige Einrichtungen im Anwendungsbereich der Richtlinie eingestuft werden. Diese Einschätzung beginnt mit den eigenen Regeln der Richtlinie zu Einrichtungsart, Größe und Sonderregelung und hängt anschließend davon ab, wie der jeweilige Mitgliedstaat sie umgesetzt und angewendet hat. Bildung ist in Anhang I oder Anhang II nicht als eigenständiger Sektor aufgeführt, aber eine Schule, Hochschule oder Universität kann trotzdem über eine aufgeführte Einrichtungsart, den Status als öffentliche Verwaltung oder einen anderen anwendbaren Weg in den Anwendungsbereich fallen.

Für eine im Anwendungsbereich liegende Einrichtung verlangt Artikel 21 angemessene und verhältnismäßige Risikomanagementmaßnahmen. Erwägungsgrund 79 besagt, dass diese Maßnahmen die Sicherheit der Personalressourcen berücksichtigen und angemessene Zugriffskontrollrichtlinien umfassen sollten.

Wird einer Einrichtung ein erheblicher Vorfall bekannt, sieht Artikel 23 eine Frühwarnung innerhalb von 24 Stunden, eine Vorfallsmeldung innerhalb von 72 Stunden und einen Abschlussbericht spätestens einen Monat nach der Meldung vor. Andauernde Vorfälle folgen einem separaten Fortschrittsberichtsweg.

Um die 24-Stunden-Frist aus Artikel 23 einzuhalten, muss bekannt sein, wer Zugriff auf das kompromittierte System hatte und wann sich dieser Zugriff zuletzt geändert hat. Verwalten Abteilungen Passwörter eigenständig – eine Tabelle in einem Büro, ein per Chat weitergeleitetes Passwort in einem anderen –, ist diese Information in der Regel nirgendwo erfasst. Prüfer, die Nachweise dafür verlangen, dass Zugriffsentscheidungen verhältnismäßig, dokumentiert und überprüfbar sind, stoßen auf dieselbe Lücke.

Die Abdeckung des Bildungssektors hängt von der nationalen Umsetzung ab.  In den Niederlanden beispielsweise fallen Universitäten unter NIS2, größtenteils aufgrund des durch Forschung generierten geistigen Eigentums – die Regierung betrachtet dieses Wissen als nationales Gut. Es empfiehlt sich, den konkreten Status Ihrer Institution mit Rechts- oder Compliance-Experten zu klären, anstatt ihn in die eine oder andere Richtung anzunehmen.

Zugriffsverwaltung schließt die Lücken bei Produktivität, Risiko und Compliance

Zugriffsverwaltung beseitigt die drei oben beschriebenen Probleme: verschwendete Mitarbeiterzeit, größere Angriffsfläche und dünne Compliance-Nachweise. Sie funktioniert, indem sie Identität, Authentifizierung und Berechtigungen als einen verbundenen Prozess über alle Systeme einer Institution hinweg steuert, statt jede Anwendung ihre eigenen Passwortregeln durchsetzen zu lassen.

Ein Passwortmanager für Unternehmen ist die praktische Ebene, die das ermöglicht. 

• Zentralisierte, berechtigungsbasierte Speicherung von Zugangsdaten ersetzt die geteilte Tabelle und den Notizzettel. 
• Benannte Verantwortlichkeit und rollenbasierter Zugriff beseitigen das Rätselraten darüber, wer worauf zugreifen kann. 
• Self-Service oder delegierte Wiederherstellung reduziert die Rücksetzungswarteschlange auf die Konten, die wirklich die Hilfe der IT benötigen. 
• Audit-Protokolle und regelmäßige Zugriffsüberprüfungen liefern die dokumentierten, überprüfbaren Nachweise, die sowohl die DSGVO als auch NIS2 verlangen.

Wie Passwortmanager Bildungseinrichtungen beim Zugriffsmanagement in großem Maßstab unterstützen 

NISTs aktuelle Passwort-Richtlinie empfiehlt Multi-Faktor-Authentifizierung (MFA), behandelt Passkeys als brauchbare Alternative zu Passwörtern und empfiehlt für Konten, die weiterhin ein Passwort verwenden, Passwortmanager – sichere Zugangsdaten-Tresore, die eindeutige Passwörter generieren und speichern. Das deckt die Grundlage ab: eindeutige Zugangsdaten, sicher generiert und gespeichert, statt wiederverwendet oder aufgeschrieben.

Passwortmanager auf Enterprise-Niveau gehen weiter. Rollenbasierte Berechtigungen weisen die Verantwortlichkeit auf Tresor-Ebene zu, Audit-Protokolle und Zugriffsüberprüfungen liefern die Nachweiskette, die Prüfer verlangen, und die Verzeichnisintegration verknüpft den Kontolebenszyklus mit HR- und IT-Systemen statt mit einer manuellen Checkliste. Passworks Leitfaden zum Team-Passwortmanagement beschreibt, wie diese Bausteine in der Praxis zusammenwirken.

Auch die Wiederherstellung profitiert. Geht ein Gerät verloren oder wird eine Kompromittierung von Zugangsdaten vermutet, kann ein Administrator den Tresorzugriff dieser Person sperren und die betroffenen Zugangsdaten rotieren, ohne andere Nutzer zu stören, die weiterhin auf denselben geteilten Eintrag angewiesen sind. Ein verwaltetes System reduziert den Such- und Wiederherstellungsaufwand, den ein geteiltes Zugangsdatenpaar sonst verursacht, und lässt Administratoren über einen dokumentierten Prozess handeln, statt einen Login über Chatverläufe und Onboarding-Dokumente zu verfolgen.

Zwei Prioritäten speziell für den Bildungsbereich

Joiner-Mover-Leaver-Prozesse verdienen im Bildungsbereich besondere Aufmerksamkeit, da Veränderungen bei Studierenden, befristetem Personal, externen Dienstleistern und Semesterzeiten zu häufigen, vorhersehbar terminierten Kontoänderungen führen. Die Automatisierung von Provisionierung und Deprovisionierung rund um diese bekannten Zyklen entfernt den manuellen Schritt, bei dem der Zugriff am häufigsten übersehen wird.

Geteilte Konten sollten eine kontrollierte Ausnahme bleiben: bewusst vergeben, namentlich verantwortet und nach einem festen Rhythmus überprüft. Passworks Leitfaden zum sicheren Passwort-Sharing beschreibt, wie ein geteiltes Abteilungstool trotzdem benannte Verantwortliche und rollenbasierten Zugriff innerhalb eines sicheren Tresors mit Audit-Protokollierung haben kann, statt eines Logins, der per Chatnachricht weitergegeben wird, ohne dass erfasst ist, wer ihn besitzt.

Ein Fünf-Schritte-Startplan für IT-Verantwortliche im Bildungsbereich

Diese fünfstufige Abfolge lässt sich an den Semesterkalender anpassen, sodass IT-Teams sofort starten können, ohne auf eine systemweite Pause zu warten. Verstehen Sie sie als Ausgangspunkt, nicht als vollständigen Rollout-Plan.

• Identifizieren Sie die Systeme, bei denen verlorener oder unbefugter Zugriff den größten Schaden anrichten würde. Stufen Sie Schülerdaten, Kinderschutzdaten, Forschungssysteme und Finanzen höher ein als Tools mit geringerem Risiko.
• Erfassen Sie geteilte, privilegierte und nicht zugeordnete Konten und weisen Sie jedem einen namentlich benannten Verantwortlichen zu. Allein dieser Schritt bringt in der Regel Konten zum Vorschein, an deren Einrichtung sich niemand mehr erinnert.
• Messen Sie Ihre aktuelle Ausgangslage, bevor Sie Richtlinien ändern. Verfolgen Sie das Volumen an Rücksetzungen, Sperrungen sowie Verzögerungen beim On- oder Offboarding, damit Sie erkennen können, ob eine Änderung tatsächlich geholfen hat. Genau hier zahlt sich auch ein Konfigurationsaudit aus: Verizons DBIR 2026 fand heraus, dass in der untersuchten Geräte-Stichprobe 97 % der Geräte die Prüfung auf zulässige Anmeldeversuche vor einer Sperrung nicht bestanden und 90 % die Prüfung auf Passwörter mit mindestens 15 Zeichen nicht bestanden. Diese Lücke zwischen dokumentierter Richtlinie und tatsächlich durchgesetzter Konfiguration lohnt sich, direkt zu testen.
• Priorisieren Sie MFA und den sicheren Umgang mit Zugangsdaten zuerst für Nutzer mit hohem Risiko. Administratoren, IT-Mitarbeiter und alle mit Zugriff auf Finanz- oder Kinderschutzsysteme sollten vor der allgemeinen Studierendenschaft umgestellt werden.
• Testen Sie zunächst in einer Abteilung, bevor Sie skalieren. Führen Sie den neuen Prozess in einem einzelnen Team durch, überprüfen Sie die Kontrollen, die betriebliche Reibung und die beobachteten Ergebnisse, und erweitern Sie ihn dann. Institutionen ohne durchgehende Sicherheitsbesetzung müssen das nicht allein lösen: Polens Hochschulsektor beispielsweise organisiert gemeinsame regionale Überwachungskapazitäten speziell für Universitäten, die keine 24/7-Abdeckung intern aufbauen können.

NISTs Empfehlung, MFA zu kombinieren, Passkeys dort zu berücksichtigen, wo sie passen, und für Konten, die weiterhin ein Passwort benötigen, einen Passwortmanager zu verwenden, gilt direkt für Schritt vier. Bei Studierenden und Schülern ändert sich die Rechnung: Alter, Barrierefreiheitsbedarf und Geräteverfügbarkeit beeinflussen, welche Kontrollen für welche Gruppe sinnvoll sind. Eine Kontrolle, die für Finanzmitarbeiter funktioniert, kann für eine Zwölfjährige, die sich in einer Lese-App anmeldet, die falsche Wahl sein.

Vom Passwortchaos zu einem verwalteten System

Passwortchaos kündigt sich selten als Krise an. Es baut sich Login für Login und Rücksetzung für Rücksetzung auf, bis eine Institution nicht mehr mit Sicherheit sagen kann, wer worauf Zugriff hat. Es zu beheben bedeutet, Passwortsicherheit in Bildungseinrichtungen als Betriebsmodell zu behandeln: jedes Konto verantworten, verfolgen und als fortlaufende Praxis nach einem festen Rhythmus überprüfen.

Für Teams, die geteilte Zugangsdaten zentralisieren und den Zugriff mit bestehenden Identitätssystemen verbinden möchten, bietet Passwork kontrollierte Tresore, rollenbasierte Berechtigungen, Verzeichnissynchronisation und Audit-Aufzeichnungen. Diese Funktionen können Teile eines umfassenderen Access-Governance-Programms unterstützen. Ob sie ausreichen, hängt von den Systemen, der Konfiguration, der Risikobewertung und den weiteren Compliance-Kontrollen der Institution ab.

Häufig gestellte Fragen

Passwortchaos: Warum es ein Geschäftsproblem ist und wie man es behebt

Ein vergessenes Passwort kostet 70 US-Dollar. Eine Sicherheitsverletzung kostet 4,44 Millionen US-Dollar. Beide beginnen gleich – Zugangsdaten werden über Slack geteilt, in Tabellen gespeichert und nie rotiert. Was Passwortchaos wirklich kostet und wie man es beseitigt.

Passwork BlogAlex Muntyan

Was ist Passwortmanagement?

Passwortmanagement ist die Praxis, Passwörter und andere Authentifizierungsdaten sicher zu erstellen, zu speichern, zu organisieren und den Zugriff darauf zu kontrollieren. Es verbindet menschliche Prozesse mit spezialisierten Softwaretools, um sicherzustellen, dass jedes Konto ein starkes, eindeutiges Passwort verwendet, ohne dass sich Nutzer alle merken müssen. Ob Sie als Privatperson Ihr Online-Leben schützen oder als IT-Administrator die digitalen Werte Ihrer Organisation absichern möchten – das Verständnis von Passwortmanagement ist unerlässlich.

PassworkPasswork Team

Kindern Passwortsicherheit vermitteln: Tipps für Eltern

Ein Leitfaden für Eltern, um Kindern Passwortsicherheit zu vermitteln: echte Motivation wecken, Lektionen altersgerecht anpassen, starke Passphrasen erstellen, 2FA oder Passkeys einrichten, Phishing-Versuche erkennen und Konten gelassen über eine wiederholbare Routine aus Erstellen, Schützen, Wiederherstellen zurückgewinnen.

PassworkPasswork Team

Comienza un nuevo periodo académico y la cola de la mesa de ayuda se llena de solicitudes de restablecimiento antes de la primera clase. Un miembro del personal no puede iniciar sesión en el sistema de gestión del aprendizaje. Un departamento comparte un mismo inicio de sesión para una herramienta de investigación y nadie recuerda quién estableció la contraseña ni quién más tiene una copia de ella.

Así es como se rompe la seguridad de las contraseñas en las instituciones educativas: credenciales dispersas en docenas de sistemas y compartidas sin ninguna supervisión. Un mismo centro escolar o universidad puede gestionar inicios de sesión independientes para los expedientes del alumnado, las plataformas de aprendizaje, las herramientas de investigación y las bases de datos de finanzas, RR. HH. y protección de menores, cada uno con sus propios hábitos de contraseñas.

El caos de contraseñas se extiende más allá de la mesa de ayuda de TI al resto de la organización. El personal pierde horas tratando de recuperar el acceso en lugar de dedicarse a la enseñanza o la investigación. Las credenciales sin gestionar amplían las vías que los atacantes utilizan para entrar. Unos registros de acceso deficientes convierten una auditoría de rutina en un hallazgo de incumplimiento. La gestión de accesos es la forma en que las instituciones cierran las tres brechas a la vez.

El caos de contraseñas es un problema de continuidad del acceso

El caos de contraseñas se acumula porque nadie vuelve a revisar una decisión de acceso una vez tomada. Un inicio de sesión se comparte para un proyecto y sigue compartido después de que el proyecto termine. Un miembro del personal se añade a un sistema, cambia de puesto y conserva el acceso anterior porque nadie tiene la tarea de comprobarlo. Multiplique esto por cada sistema añadido durante una década y nadie podrá decir con certeza quién tiene acceso a qué.

Esa brecha se nota especialmente en el proceso de baja. Eliminar el acceso de un empleado que se marcha debería ser una tarea rutinaria de TI. En cambio, se convierte en una búsqueda por docenas de sistemas desconectados, porque el registro de quién tiene acceso a qué nunca se centralizó.

Cómo el caos de contraseñas ralentiza el trabajo en el sector educativo

El caos de contraseñas se manifiesta primero como tiempo perdido. Los restablecimientos, los desbloqueos y los cambios manuales de cuentas se convierten en una cola recurrente que aparta al personal de TI del soporte a la docencia y del trabajo de seguridad.

El acceso fragmentado interrumpe flujos de trabajo críticos

Entre los sistemas esenciales del sector educativo se encuentran las plataformas de gestión del aprendizaje, los sistemas de información del alumnado, los entornos de investigación, el correo electrónico, RR. HH., finanzas, los sistemas de biblioteca y los registros de protección de menores. Perder el acceso a cualquiera de ellos puede retrasar la calificación de exámenes, bloquear un plazo de investigación o dejar temporalmente inaccesible un registro de protección de menores. La gravedad depende del impacto del sistema en la actividad de la institución y de la calidad de sus mecanismos de recuperación.

Las credenciales compartidas difuminan la responsabilidad

Los inicios de sesión compartidos eliminan la trazabilidad. Cuando varias personas usan el mismo inicio de sesión para una herramienta compartida, la institución pierde la capacidad de saber quién hizo qué. Esto importa en el día a día, al investigar un cambio inesperado. Importa aún más cuando cambia un puesto y alguien debe perder el acceso sin dejar sin cuenta al resto de quienes todavía la utilizan.

Por qué el caos de contraseñas aumenta el riesgo de un incidente de seguridad

El caos de contraseñas amplía las vías que los atacantes utilizan para entrar. Las contraseñas reutilizadas, las cuentas compartidas sin gestionar y unos procesos de baja deficientes facilitan los ataques basados en credenciales y dificultan su contención.

Verizon informó, en su Data Breach Investigations Report (DBIR) de 2026, que la explotación de vulnerabilidades fue la vía de acceso inicial en el 31 % de las brechas, por delante del uso indebido de credenciales por primera vez. Pero el uso indebido de credenciales siguió apareciendo en algún punto de la cadena de ataque en el 39 % de las brechas que analizó Verizon. Una contraseña robada o reutilizada no tenía que ser el primer paso para ser relevante. Bastaba con que estuviera ahí, reutilizable, en cuanto un atacante entrara por otra puerta.

El Centro Nacional de Ciberseguridad del Reino Unido (NCSC) explica por qué se sigue produciendo esa reutilización: la sobrecarga de contraseñas fomenta comportamientos de afrontamiento inseguros, como la reutilización, las fórmulas predecibles y el almacenamiento inseguro. Decirle al personal que «elija una contraseña más segura» no soluciona un sistema en el que doce departamentos mantienen cada uno su propia hoja de cálculo de inicios de sesión compartidos. ENISA informa, en su Threat Landscape 2025, que el phishing siguió siendo el método principal de intrusión inicial y una técnica eficaz para el robo de credenciales y el secuestro de sesiones, exactamente el tipo de robo que las credenciales sin gestionar y reutilizadas facilitan.

Cómo una credencial robada se convierte en una brecha

Rara vez una sola contraseña reutilizada permanece limitada a una cuenta. Los atacantes avanzan desde el primer inicio de sesión comprometido hacia un acceso más amplio siguiendo una secuencia predecible. Cada paso depende de que el anterior pase inadvertido.

La cadena de ataque suele seguir este patrón:

• Un atacante envía un mensaje de phishing que imita una página de inicio de sesión conocida, o explota directamente un sistema sin parchear.
• Si el phishing funciona, un usuario entrega credenciales reales sin darse cuenta.
• El atacante prueba esas credenciales en otros sistemas, una técnica que funciona con mucha más frecuencia cuando las contraseñas se reutilizan.
• Si la cuenta comprometida tiene un acceso amplio, compartido o persistente, el atacante puede avanzar más antes de que alguien lo note.

Una credencial robada causa más daño cuando concede un acceso amplio o compartido, porque la institución pierde tanto la contención como la capacidad de rastrear lo ocurrido. NCSC lo expone directamente en su introducción a la gestión de identidades y accesos: unos controles de IAM débiles permiten que un atacante que obtiene una sola credencial se presente como un usuario legítimo en varios sistemas.

Fredrik Blomqvist, director de seguridad de la Universidad de Upsala, planteó la misma idea desde dentro de la propia función de seguridad de una universidad en marzo de 2026: el phishing sigue siendo el tipo de ataque más frecuente que observa la institución, y el factor humano, no la pila tecnológica, sigue siendo su mayor riesgo de ciberseguridad.

El acceso de terceros amplía el riesgo de las credenciales

Los proveedores externos añaden otra capa de exposición, porque las instituciones educativas suelen externalizar los sistemas de información del alumnado, las plataformas de aprendizaje y el procesamiento de pagos. Verizon constató, en su DBIR de 2026, que la participación de terceros alcanzó el 48 % de todas las brechas, un 60 % más que el año anterior. Entre esas organizaciones externas, solo el 23 % había corregido por completo la falta o la configuración incorrecta de la MFA en sus cuentas en la nube. El acceso de terceros puede extender el riesgo de las credenciales más allá de los sistemas propios de la institución, por lo que las conexiones con proveedores necesitan el mismo nivel de revisión de identidad y accesos que las cuentas internas.

El ransomware hace más urgentes la recuperación y la revocación

Una vez que un atacante está dentro, la velocidad de contención determina cuánto daño puede causar una sola credencial robada. Sophos encuestó a 441 instituciones educativas que habían sufrido un ataque de ransomware en el año anterior y constató que el 29 % de los encuestados de centros de enseñanza no universitaria y el 58 % de los de educación superior declararon un ataque que provocó el cifrado de datos. Esa cifra describe lo que ocurre después de que un atacante entra, entre instituciones que ya han sido atacadas: es una medida de la velocidad de contención, no una afirmación sobre la causa de la brecha. Es una razón para tratar la revocación rápida de credenciales como un paso probado en la respuesta a incidentes.

Por qué la falta de gestión de accesos aumenta el riesgo de cumplimiento del RGPD y de NIS2

Los centros escolares y las universidades que tratan datos personales o gestionan sistemas críticos que cumplen los requisitos quedan sujetos al RGPD, a NIS2 o a ambos. 

• El RGPD aplica una norma de seguridad basada en el riesgo dentro de unos límites materiales y territoriales definidos. 
• NIS2 se aplica a las entidades esenciales e importantes que cumplen los criterios de tipo de entidad, tamaño o vía especial de la directiva, según se haya transpuesto en el derecho nacional. 

El RGPD establece una norma basada en el riesgo

El RGPD (Reglamento General de Protección de Datos) es la ley fundamental de protección de datos de la UE. Se aplica al tratamiento de datos personales dentro de su ámbito material y territorial. Esto incluye el tratamiento en el contexto de una organización establecida en la UE, así como determinados tratamientos realizados por organizaciones fuera de la UE que ofrecen bienes o servicios a personas en la UE o que supervisan su comportamiento allí.

El artículo 5, apartado 1, letra f), del RGPD exige protección frente al tratamiento no autorizado o ilícito y frente a la pérdida o el daño accidental. El artículo 32 va más allá: exige medidas adecuadas al riesgo, incluyendo, cuando proceda, la confidencialidad, la integridad, la disponibilidad, la resiliencia, la capacidad de restablecer el acceso tras un incidente y la realización de pruebas periódicas.

Para una oficina de registro académico que custodia expedientes de alumnos, ese lenguaje basado en el riesgo se traduce en controles prácticos: quién puede ver un expediente, cómo se registra el acceso y con qué rapidez puede restablecerse el acceso si un sistema falla.

La cobertura de NIS2 depende del ámbito de aplicación

NIS2 (la segunda Directiva de la UE sobre Seguridad de las Redes y de la Información) crea obligaciones de ciberseguridad para las organizaciones clasificadas como entidades esenciales e importantes que entran dentro del ámbito de la directiva. Esa evaluación comienza con las propias normas de la directiva sobre tipo de entidad, tamaño y vías especiales, y después depende de cómo el Estado miembro correspondiente las haya transpuesto y aplicado. La educación no figura como sector independiente en el anexo I ni en el anexo II, pero un centro escolar, una universidad o un instituto superior pueden entrar en el ámbito de aplicación a través de un tipo de entidad incluido en la lista, de su condición de administración pública o de otra vía aplicable.

Para una entidad incluida en el ámbito de aplicación, el artículo 21 exige medidas de gestión de riesgos que sean adecuadas y proporcionadas. El considerando 79 establece que esas medidas deben abordar la seguridad de los recursos humanos e incluir políticas de control de acceso adecuadas.

Para una entidad que tenga conocimiento de un incidente significativo, el artículo 23 establece una fase de alerta temprana dentro de las 24 horas, una fase de notificación del incidente dentro de las 72 horas y un informe final a más tardar un mes después de la notificación. Los incidentes en curso siguen una vía independiente de informes de progreso.

Cumplir el plazo de 24 horas del artículo 23 exige saber quién tenía acceso al sistema comprometido y cuándo cambió ese acceso por última vez. Cuando los departamentos gestionan las contraseñas de forma independiente (una hoja de cálculo en una oficina, una contraseña reenviada por chat en otra), esa información normalmente no queda registrada en ningún sitio. Los auditores que pidan pruebas de que las decisiones de acceso son proporcionadas, están documentadas y pueden revisarse encontrarán la misma carencia.

La cobertura del sector educativo depende de la aplicación nacional.  En los Países Bajos, por ejemplo, las universidades quedan sujetas a NIS2, principalmente por la propiedad intelectual generada a través de la investigación: el gobierno considera que ese conocimiento es un activo nacional. Recomendamos confirmar la situación específica de su institución con especialistas jurídicos o de cumplimiento normativo, en lugar de asumir una cosa u otra.

La gestión de accesos cierra las brechas de productividad, riesgo y cumplimiento

La gestión de accesos es lo que elimina los tres problemas descritos anteriormente: el tiempo de personal desperdiciado, la mayor exposición a brechas y unas evidencias de cumplimiento insuficientes. Funciona controlando la identidad, la autenticación y los permisos como un único proceso conectado en todos los sistemas que utiliza una institución, en lugar de dejar que cada aplicación aplique sus propias normas de contraseñas.

Un gestor de contraseñas empresarial es la capa práctica que hace esto posible. 

• El almacenamiento centralizado y controlado por permisos de las credenciales sustituye a la hoja de cálculo compartida y a la nota adhesiva. 
• La propiedad designada y el acceso basado en roles eliminan las conjeturas sobre quién puede acceder a qué. 
• La recuperación autogestionada o delegada reduce la cola de restablecimientos a las cuentas que realmente necesitan la ayuda de TI. 
• Los registros de auditoría y las revisiones periódicas de accesos generan las evidencias documentadas y revisables que exigen tanto el RGPD como NIS2.

Cómo los gestores de contraseñas ayudan al sector educativo a gestionar el acceso a gran escala 

NIST recomienda, en su guía actual sobre contraseñas, la autenticación multifactor (MFA), considera las passkeys una alternativa viable a las contraseñas y recomienda los gestores de contraseñas, bóvedas seguras de credenciales que generan y almacenan contraseñas únicas, para las cuentas que todavía utilizan una. Esto cubre el nivel básico: credenciales únicas, generadas y almacenadas de forma segura, en lugar de reutilizadas o anotadas.

Los gestores de contraseñas de nivel empresarial van más allá. Los permisos basados en roles asignan la propiedad a nivel de bóveda, los registros de auditoría y las revisiones de accesos generan el rastro de evidencias que piden los auditores, y la integración con el directorio vincula el ciclo de vida de las cuentas a los sistemas de RR. HH. y de TI en lugar de a una lista de verificación manual. La guía de Passwork sobre la gestión de contraseñas en equipo explica cómo funcionan estas piezas juntas en la práctica.

La recuperación también se beneficia. Cuando se pierde un dispositivo o se sospecha que una credencial está comprometida, un administrador puede suspender el acceso a la bóveda de esa persona y rotar las credenciales afectadas sin afectar a otros usuarios que todavía dependen de la misma entrada compartida. Un sistema gestionado reduce el trabajo de búsqueda y recuperación que de otro modo genera una credencial compartida, y permite que los administradores actúen mediante un proceso documentado en lugar de rastrear un inicio de sesión a través de hilos de chat y documentos de incorporación.

Dos prioridades específicas del sector educativo

Los procesos de alta, cambio y baja merecen especial atención en el sector educativo, porque los cambios de alumnado, personal temporal, contratistas y los propios del calendario académico generan cambios de cuenta frecuentes en un calendario predecible. Automatizar el aprovisionamiento y el desaprovisionamiento en torno a esos ciclos conocidos elimina el paso manual en el que el acceso se queda atrás con más frecuencia.

Las cuentas compartidas deben seguir siendo una excepción controlada: concedidas de forma deliberada, con un propietario identificado y revisadas según un calendario. La guía de Passwork sobre el uso compartido seguro de contraseñas explica cómo una herramienta departamental compartida puede tener propietarios identificados y acceso basado en roles dentro de una bóveda segura con registro de auditoría, en lugar de un único inicio de sesión que circula por mensajes de chat sin ningún registro de quién lo tiene.

Un plan inicial de cinco pasos para responsables de TI del sector educativo

Esta secuencia de cinco pasos se adapta al calendario académico, de modo que los equipos de TI pueden empezar ahora sin esperar una pausa generalizada. Trátela como un punto de partida, no como un plan de implementación completo.

• Identifique los sistemas en los que la pérdida de acceso o el acceso no autorizado causarían más daño. Priorice los expedientes del alumnado, los datos de protección de menores, los sistemas de investigación y finanzas por delante de las herramientas de menor riesgo.
• Inventaríe las cuentas compartidas, privilegiadas y sin propietario, y asigne un propietario identificado a cada una. Solo este paso suele revelar cuentas que nadie recuerda haber creado.
• Mida su punto de partida actual antes de cambiar la política. Realice un seguimiento del volumen de restablecimientos, los bloqueos y los retrasos en la incorporación o la baja, para poder comprobar si un cambio realmente ayudó. Aquí es también donde una auditoría de configuración demuestra su valor: Verizon constató, en su DBIR de 2026, que en su muestra de dispositivos evaluados, el 97 % no superó la comprobación del número de intentos de inicio de sesión permitidos antes del bloqueo, y el 90 % no superó la comprobación que exige contraseñas de al menos 15 caracteres. Vale la pena comprobar directamente esa diferencia entre la política documentada y la configuración aplicada.
• Priorice primero la MFA y el manejo seguro de credenciales para los usuarios de mayor riesgo. Los administradores, el personal de TI y cualquier persona con acceso a sistemas financieros o de protección de menores deben pasar a esta fase antes que el conjunto del alumnado.
• Pilote el proceso en un departamento antes de escalarlo. Ejecute el nuevo proceso en un solo equipo, revise los controles, la fricción operativa y los resultados observados, y después amplíelo. Las instituciones sin personal de seguridad permanente no tienen por qué resolver esto solas: el sector de educación superior de Polonia, por ejemplo, está organizando una capacidad de supervisión regional compartida específicamente para las universidades que no pueden crear una cobertura propia las 24 horas del día, los 7 días de la semana.

La recomendación de NIST de combinar la MFA, valorar las passkeys donde resulten adecuadas y usar un gestor de contraseñas para las cuentas que todavía necesiten una se aplica directamente al cuarto paso. En el caso del alumnado, el cálculo cambia: la edad, las necesidades de accesibilidad y la disponibilidad de dispositivos determinan qué controles tienen sentido para cada grupo. Un control que funciona para el personal de finanzas puede no ser adecuado para un niño de doce años que inicia sesión en una aplicación de lectura.

Del caos de contraseñas a un sistema gestionado

El caos de contraseñas rara vez se presenta como una crisis. Se acumula un inicio de sesión compartido y un restablecimiento manual a la vez, hasta que una institución no puede decir con certeza quién tiene acceso a qué. Solucionarlo implica tratar la seguridad de las contraseñas en las instituciones educativas como un modelo operativo: asignar la propiedad de cada cuenta, hacerle seguimiento y revisarla según un calendario, como una práctica continua.

Para los equipos que estén listos para centralizar las credenciales compartidas y conectar el acceso a los sistemas de identidad existentes, Passwork ofrece bóvedas controladas, permisos basados en roles, sincronización con el directorio y registros de auditoría. Estas funciones pueden respaldar partes de un programa más amplio de gobernanza de accesos. Su idoneidad depende de los sistemas, la configuración, la evaluación de riesgos y los controles de cumplimiento más amplios de la institución.

Preguntas frecuentes

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

Una contraseña olvidada cuesta 70 dólares. Una brecha cuesta 4,44 millones de dólares. Ambas empiezan igual: credenciales compartidas por Slack, guardadas en hojas de cálculo, nunca rotadas. Esto es lo que realmente cuesta el caos de contraseñas y cómo eliminarlo.

Passwork BlogAlex Muntyan

¿Qué es la gestión de contraseñas?

La gestión de contraseñas es la práctica de crear, almacenar, organizar y controlar de forma segura el acceso a las contraseñas y otras credenciales de autenticación. Combina procesos humanos con herramientas de software especializadas para garantizar que cada cuenta utilice una contraseña fuerte y única sin exigir a los usuarios que las memoricen todas. Tanto si es una persona que busca proteger su vida en línea como un administrador de TI que protege los activos digitales de su organización, comprender la gestión de contraseñas es esencial.

PassworkPasswork Team

Cómo enseñar a los niños sobre seguridad de contraseñas: Consejos para padres

Una guía para padres sobre cómo enseñar seguridad de contraseñas a los niños: despertar una motivación real, adaptar las lecciones según la edad, crear frases de contraseña seguras, añadir 2FA o passkeys, detectar intentos de phishing y recuperar cuentas con calma mediante una rutina repetible de Crear, Proteger, Recuperar.

PassworkPasswork Team

A new term starts, and the helpdesk queue fills with reset requests before the first lecture begins. A staff member can't log into the learning management system. A department shares one login for a research tool, and nobody remembers who set the password or who else has a copy of it.

That's what breaks password security for educational institutions: credentials scattered across dozens of systems and shared without oversight. A single school or university might run separate logins for student records, learning platforms, research tools, and finance, HR, and safeguarding databases — each with its own password habits.

Password chaos spreads past the IT helpdesk into the rest of the organization. Staff lose hours chasing access instead of teaching or research. Unmanaged credentials widen the paths attackers use to get in. Weak access records turn a routine audit into a compliance finding. Access management is how institutions close all three gaps at once.

Password chaos is an access-continuity problem

Password chaos accumulates because nothing revisits an access decision once it's made. A login gets shared for one project and stays shared after the project ends. A staff member gets added to a system, changes roles, and keeps the old access because no one is assigned to check. Multiply that by every system added over a decade, and no one can say with confidence who has access to what.

That gap surfaces hardest during offboarding. Removing a leaving staff member's access should be a routine IT task. Instead it becomes a search across dozens of disconnected systems, because the record of who has access to what was never centralized in the first place.

How password chaos slows education work

Password chaos shows up first as lost time. Resets, unlocks, and manual account changes turn into a recurring queue that pulls IT staff away from teaching-support and security work.

Fragmented access interrupts critical workflows

Essential systems in education include learning-management platforms, student-information systems, research environments, email, HR, finance, library systems, and safeguarding records. Losing access to any of these can delay grading, block a research deadline, or leave a safeguarding record temporarily unreachable. How severe that becomes depends on the system's business impact and the quality of its recovery arrangements.

Shared credentials obscure responsibility

Shared logins erase accountability. When several people use one login for a shared tool, the institution loses the ability to say who did what. That matters day to day, when troubleshooting an unexpected change. It matters more when a role changes and someone needs to lose access without breaking the account for everyone else still using it.

Why password chaos raises the risk of a security incident

Password chaos widens the paths attackers use to get in. Reused passwords, unmanaged shared accounts, and weak offboarding make credential-based attacks easier to pull off and harder to contain.

Verizon's 2026 Data Breach Investigations Report found vulnerability exploitation leading initial access in 31% of breaches, ahead of credential abuse for the first time. But credential abuse still showed up somewhere in the attack chain of 39% of the breaches Verizon analyzed. A stolen or reused password didn't have to be the opening move to matter. It just had to be sitting there, reusable, once an attacker got in through some other door.

The UK's National Cyber Security Centre explains why that reuse keeps happening: password overload encourages insecure coping behavior such as reuse, predictable formulas, and unsafe storage. Telling staff to "choose a stronger password" doesn't fix a system where twelve departments each keep their own spreadsheet of shared logins. ENISA's 2025 Threat Landscape reports that phishing remained the primary method for initial intrusion and an effective technique for credential theft and session hijacking — exactly the kind of theft that unmanaged, reused credentials make easier to pull off.

How a stolen credential turns into a breach

A single reused password rarely stays contained to one account. Attackers move from the first compromised login to broader access in a predictable sequence. Each step depends on the last one going unnoticed.

The attack chain usually looks like this:

• An attacker sends a phishing message that mimics a familiar login page, or exploits an unpatched system directly.
• If phishing works, a user hands over real credentials without realizing it.
• The attacker tests those credentials against other systems, a technique that works far more often when passwords are reused.
• If the compromised account has broad, shared, or persistent access, the attacker can move further before anyone notices.

A stolen credential does more damage when it grants wide or shared access, because the institution loses both containment and the ability to trace what happened. NCSC's introduction to identity and access management makes this point directly: weak IAM controls let an attacker who obtains one credential appear as a legitimate user across multiple systems.

Fredrik Blomqvist, Uppsala University's Chief Security Officer, made the same point from inside a university's own security function in March 2026: phishing remains the most common attack type the institution sees, and the human factor, not the technology stack, is still its greatest cybersecurity risk.

Third-party access extends credential risk

External vendors add another layer of exposure, because education institutions routinely outsource student-information systems, learning platforms, and payment processing. Verizon's 2026 DBIR found third-party involvement in breaches reached 48% of all breaches, up 60% year over year. Among those third-party organizations, only 23% had fully remediated missing or improper MFA on their cloud accounts. Third-party access can extend credential risk beyond the institution's own systems, so vendor connections need the same level of identity and access review as internal accounts.

Ransomware makes recovery and revocation more urgent

Once an attacker is inside, the speed of containment determines how much damage a single stolen credential can do. Sophos surveyed 441 education institutions that had experienced a ransomware attack in the prior year and found that 29% of lower-education respondents and 58% of higher-education respondents reported an attack that resulted in data encryption. That figure describes what happens after an attacker gets in among institutions already hit, a containment-speed measure rather than a cause-of-breach statement. It's a reason to treat fast credential revocation as a tested step in incident response.

Why the lack of access management raises GDPR and NIS2 compliance risk

Schools, colleges, and universities that handle personal data or operate qualifying critical systems fall under GDPR, NIS2, or both. 

• GDPR applies a risk-based security standard within defined material and territorial limits. 
• NIS2 applies to essential and important entities that meet the Directive's entity-type, size, or special-route criteria, as implemented under national law. 

GDPR sets a risk-based standard

GDPR (General Data Protection Regulation) is the EU's core data-protection law. It applies to processing of personal data within its material and territorial scope. This includes processing in the context of an organization established in the EU, as well as certain processing by organizations outside the EU that offer goods or services to people in the EU or monitor their behavior there.

GDPR's Article 5(1)(f) requires protection against unauthorized or unlawful processing and against accidental loss or damage. Article 32 goes further: it calls for measures appropriate to risk, including, as appropriate, confidentiality, integrity, availability, resilience, the ability to restore access after an incident, and regular testing.

For a registrar's office holding student records, that risk-based language translates into practical controls: who can view a record, how access is logged, and how quickly access can be restored if a system goes down.

NIS2 coverage depends on scope

NIS2 (the EU's second Network and Information Security Directive) creates cybersecurity obligations for organizations classified as essential and important entities that fall within the Directive's scope. That assessment begins with the Directive's own entity-type, size, and special-route rules, then depends on how the relevant member state has transposed and applied them. Education is not listed as a standalone sector in Annex I or Annex II, but a school, college, or university may still be in scope through a listed entity type, public-administration status, or another applicable route.

For an entity in scope, Article 21 requires risk-management measures that are appropriate and proportionate. Recital 79 states that those measures should address human-resources security and include appropriate access-control policies.

For an entity that becomes aware of a significant incident, Article 23 sets an early-warning stage within 24 hours, an incident-notification stage within 72 hours, and a final report no later than one month after notification. Ongoing incidents follow a separate progress-report path.

Meeting Article 23's 24-hour clock requires knowing who had access to the compromised system and when that access last changed. Where departments manage passwords independently — a spreadsheet in one office, a password forwarded over chat in another — that information typically isn't recorded anywhere. Auditors asking for evidence that access decisions are proportionate, documented, and reviewable will find the same gap.

Coverage of the education sector depends on national implementation.  In the Netherlands, for instance, universities fall under NIS2 largely because of the intellectual property generated through research — the government considers that knowledge a national asset. We recommend confirming your institution's specific status with legal or compliance specialists rather than assuming it either way.

Access management closes the productivity, risk, and compliance gaps

Access management is what eliminates the three problems described above: wasted staff time, wider breach exposure, and thin compliance evidence. It works by controlling identity, authentication, and permissions as one connected process across every system an institution runs, instead of leaving each application to enforce its own password rules.

A business password manager is the practical layer that makes this possible. 

• Centralized, permissioned credential storage replaces the shared spreadsheet and the sticky note. 
• Named ownership and role-based access remove the guesswork over who can reach what. 
• Self-service or delegated recovery cuts the reset queue down to the accounts that genuinely need IT's help. 
• Audit logs and periodic access reviews produce the documented, reviewable evidence GDPR and NIS2 both ask for.

How password managers help education manage access at scale 

NIST's current password guidance recommends multi-factor authentication (MFA), treats passkeys as a viable alternative to passwords, and recommends password managers, secure credential vaults that generate and store unique passwords, for accounts that still use one. That covers the baseline: unique credentials, generated and stored securely, instead of reused or written down.

Enterprise-grade password managers extend further. Role-based permissions assign ownership at the vault level, audit logs and access reviews produce the evidence trail auditors ask for, and directory integration ties account lifecycle to HR and IT systems instead of a manual checklist. Passwork's guide to team password management covers how these pieces work together in practice.

Recovery benefits too. When a device goes missing or a credential is suspected compromised, an administrator can suspend that person's vault access and rotate the affected credentials without disrupting other users still relying on the same shared entry. A managed system reduces the search-and-recovery work a shared credential otherwise creates, and lets administrators act through a documented process rather than tracking a login across chat threads and onboarding documents.

Two priorities specific to education

Joiner, mover, and leaver processes deserve particular attention in education, because student, temporary-staff, contractor, and term-time changes create frequent account changes on a predictable calendar. Automating provisioning and deprovisioning around those known cycles removes the manual step where access most often gets left behind.

Shared accounts should stay a controlled exception: granted deliberately, owned by name, and reviewed on a schedule. Passwork's guide to secure password sharing covers how a shared departmental tool can still have named owners and role-based access inside a secure vault with audit logging, rather than one login circulated by chat message with no record of who has it.

A five-step starting plan for education IT leaders

This five-step sequence fits around a term calendar, so IT teams can start now without waiting for a system-wide pause. Treat it as a starting point, not a complete rollout plan.

• Identify the systems where lost or unauthorized access would do the most damage. Rank student records, safeguarding data, research systems, and finance ahead of lower-stakes tools.
• Inventory shared, privileged, and unowned accounts, and assign a named owner to each. This step alone usually surfaces accounts nobody remembers creating.
• Measure your current baseline before changing policy. Track reset volume, lockouts, and onboarding or offboarding delays, so you can tell whether a change actually helped. This is also where a configuration audit earns its keep: Verizon's 2026 DBIR found that in its assessed-device sample, 97% of devices failed the check for allowed login attempts before lockout, and 90% failed the check requiring passwords of at least 15 characters. That gap between documented policy and enforced configuration is worth testing directly.
• Prioritize MFA and secure credential handling for high-risk users first. Administrators, IT staff, and anyone with access to financial or safeguarding systems should move before the general student population.
• Pilot in one department before scaling. Run the new process in a single team, review the controls, operational friction, and outcomes observed, then extend it. Institutions without round-the-clock security staffing aren't limited to solving this alone: Poland's higher-education sector, for example, is organizing shared regional monitoring capacity specifically for universities that can't build 24/7 coverage in-house.

NIST's guidance to combine MFA, consider passkeys where they fit, and use a password manager for accounts that still need one applies directly to step four. For students, the calculus changes: age, accessibility needs, and device availability affect which controls make sense for which group. A control that works for finance staff may be the wrong fit for a twelve-year-old logging into a reading app.

Getting from password chaos to a managed system

Password chaos rarely announces itself as a crisis. It builds up one shared login and one manual reset at a time, until an institution can't say with confidence who has access to what. Fixing it means treating password security for educational institutions as an operating model: own each account, track it, and review it on a schedule as an ongoing practice.

For teams ready to centralize shared credentials and connect access to existing identity systems, Passwork provides controlled vaults, role-based permissions, directory synchronization, and audit records. These capabilities can support parts of a broader access-governance program. Their adequacy depends on the institution's systems, configuration, risk assessment, and wider compliance controls.

Frequently asked questions

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

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

Passwork BlogAlex Muntyan

What is password management?

Password management is the practice of securely creating, storing, organizing, and controlling access to passwords and other authentication credentials. It combines human processes with specialized software tools to ensure that every account uses a strong, unique password without requiring users to memorize them all. Whether you’re an individual trying to secure your online life or an IT administrator protecting your organization’s digital assets, understanding password management is essential.

PassworkPasswork Team

How to teach children about password security: Tips for parents

A parent’s guide to teaching kids password security: spark real motivation, tailor lessons by age, build strong passphrases, add 2FA or passkeys, spot phishing attempts, and recover accounts calmly through a repeatable Create, Protect, Recover routine.

PassworkPasswork Team

O KeePass tem primitivas criptográficas melhores do que muitos gestores de palavras-passe disponíveis no mercado, e é daí que parte esta comparação. O formato KDBX 4 inclui uma função de derivação de chave com utilização intensiva de memória, autentica o texto cifrado antes de decifrar seja o que for e cifra a base de dados inteira, e não apenas os campos de palavra-passe.

O que o KDBX não tem é gestão de chaves para mais de uma pessoa. Existe uma única chave, que pertence a um ficheiro e não a uma pessoa, e que abre tudo. Todas as propriedades multiutilizador de que uma equipa acaba por precisar (revogar o acesso de uma pessoa, saber quem leu uma credencial, limitar o que fica exposto por uma única chave divulgada) têm de ser construídas fora do formato, normalmente à base de permissões do sistema de ficheiros e de boas intenções.

Este é o verdadeiro eixo da questão, e manifesta-se em três momentos: quando duas pessoas guardam em simultâneo a base de dados partilhada, quando alguém sai da empresa e quando um auditor pergunta quem abriu uma credencial no trimestre passado.

O que o KDBX 4 faz na realidade

Um ficheiro KDBX 4 é cifrado com AES-256 em modo CBC com preenchimento PKCS#7 ou com ChaCha20, segundo a especificação do formato. A chave resulta do cálculo de um hash dos componentes da chave mestra, que produz um valor de 256 bits; este passa por uma função de derivação de chave e o resultado é novamente processado por hash com uma semente nova em cada gravação. Três funções de derivação são fornecidas sem plugins: AES-KDF, Argon2d e Argon2id.

A integridade é o ponto em que o KDBX 4 superou o seu antecessor. O ficheiro guarda um hash SHA-256 do cabeçalho, pelo que a corrupção é detetável sem a chave mestra, depois um HMAC-SHA-256 do cabeçalho, e a carga útil é dividida em blocos de 1 MB, cada um com o seu próprio HMAC. A especificação designa este mecanismo como «um esquema Encrypt-then-MAC», o que significa que a autenticidade é verificada antes de qualquer decifragem. O KDBX 3.1 calculava o hash do texto simples, e a nota do autor sobre a alteração merece ser citada pela sua contenção:

Embora o esquema Encrypt-then-MAC (KDBX 4) seja, em geral, considerado mais seguro do que um esquema MAC-then-Encrypt (KDBX 3.1), não acreditamos que os ficheiros KDBX 3.1 fossem inseguros.

Duas ressalvas são relevantes para uma equipa. O KDBX 3.1 continua a ser um formato nativo no KeePassXC, pelo que «KeePass significa Argon2 e HMAC» só se verifica depois de alguém ter efetivamente migrado a base de dados, o que é um passo manual nas definições de cifragem. E o parâmetro de memória do Argon2 é limitado pelo dispositivo mais fraco que abre o ficheiro: o KeePass sugere metade da RAM do dispositivo mais pequeno e avisa que, no iOS, um parâmetro de memória elevado pode prejudicar o AutoFill, pelo que recomenda aí 64 MB ou menos. Uma KDF só é tão forte quanto os parâmetros que o telemóvel suporta.

O âmbito da cifragem é, de facto, superior ao de vários concorrentes alojados na nuvem: «O KeePass cifra toda a base de dados, ou seja, não só as palavras-passe, mas também os nomes de utilizador, os URLs, as notas, etc.» Um ficheiro KDBX roubado não revela nada sobre o seu conteúdo, nem sequer os títulos das entradas.

Há algo que parece uma segunda camada, mas não é. O KDBX aplica também Salsa20 ou ChaCha20 aos campos protegidos dentro do XML, e a especificação desfaz diretamente o equívoco:

Salientamos que o único objetivo da cifragem interna é permitir a proteção da memória do processo. A cifragem interna não tem qualquer efeito na segurança criptográfica do formato de ficheiro KDBX.

A sua chave reside no cabeçalho interno e não depende da chave mestra.

Onde reside a chave e porque é que isso decide tudo o resto

A chave mestra do KeePass é composta: uma palavra-passe mestra, um ficheiro de chave e uma chave associada à conta Windows atual através de DPAPI, em qualquer combinação. Todos os componentes escolhidos são obrigatórios, e a documentação sobre a chave mestra é direta a esse respeito:

Se esquecer/perder qualquer um dos componentes da chave mestra (ou esquecer a composição), todos os dados armazenados na base de dados são perdidos. Não existe nenhuma backdoor nem chave universal capaz de abrir a base de dados.

Note-se o que estes componentes têm em comum. Uma palavra-passe é conhecimento, um ficheiro de chave é posse, uma chave DPAPI é uma conta de máquina. Nenhum deles é uma identidade que a base de dados reconheça e consiga depois distinguir de outra. A chave é uma propriedade do ficheiro.

Passwork parte da pessoa e aplica o mesmo princípio de arquitetura zero-knowledge (o servidor só processa texto cifrado), construído em torno da identidade individual e não de um segredo de ficheiro único. Cada utilizador tem o seu próprio par de chaves RSA gerado no cliente, com a metade privada cifrada por uma chave derivada da sua palavra-passe mestra. Um cofre recebe a sua própria chave AES-256 na criação, e cada utilizador com acesso possui uma cópia separada dessa chave do cofre, encapsulada com a respetiva chave pública (hierarquia de chaves). O servidor só processa texto cifrado (visão geral da criptografia).

A partilha decorre desta estrutura. A concessão de acesso volta a encapsular a chave do cofre para a chave pública do destinatário, em vez de voltar a cifrar os dados (mecanismos de partilha). A revogação elimina a cópia encapsulada dessa pessoa. Todos os restantes continuam com a mesma chave do cofre, e nada é novamente cifrado.

Onde a criptografia do KeePass é mais forte para um único utilizador

A derivação de chave é onde isso se nota. O Argon2 é intensivo em memória (memory-hard), que é precisamente a propriedade que torna dispendiosa a quebra por GPU e ASIC, e o KeePass explica por que razão prefere o Argon2d neste cenário: «uma melhor proteção contra uma ameaça realmente existente (o cracking de palavras-passe com GPUs/ASICs é o estado da arte) é mais importante do que uma proteção contra certos ataques de canal lateral que podem vir ou não a ser um problema em dispositivos cliente no futuro.» O Passwork deriva a chave mestra com PBKDF2 a 300 000 iterações sobre SHA-256, uma configuração defensável e reconhecida pelo NIST, mas sem utilização intensiva de memória, e perante hardware de cracking dedicado essa distinção é relevante.

Isto não altera a conclusão para uma equipa que partilha credenciais entre mais de uma pessoa: tudo se resume à gestão de chaves, e não à força da cifra, e é a questão em que se concentra o resto desta comparação. Para um único utilizador com um só portátil e um só ficheiro, sem partilhar nada com ninguém, essa é a propriedade que mais importa contra tentativas de cracking offline.

O que acontece quando uma equipa partilha o ficheiro

É aqui que se revela o objetivo de conceção. A documentação do KeePass sobre vários utilizadores não deixa margem para dúvidas:

Todos os utilizadores usam a mesma palavra-passe mestra e/ou ficheiro de chave para abrir a base de dados. Não existem listas de controlo de acesso (ACL) por grupo ou por entrada. Para restringir o acesso de escrita ao ficheiro da base de dados (isto é, para que apenas um conjunto selecionado de utilizadores possa alterar os dados armazenados), utilize os direitos de acesso do sistema de ficheiros.

O controlo de acesso existe, mas reside no NTFS ou na partilha SMB, não no produto nem na criptografia. O acesso de leitura é do tipo tudo ou nada por construção, porque a leitura exige a única chave que decifra tudo.

O KeePass 2.x deteta conflitos. Ao guardar, «verifica primeiro se o ficheiro em disco foi modificado desde que foi carregado» e, se for o caso, propõe sincronizar em vez de substituir. A fusão é feita ao nível da entrada, e a versão perdedora de uma entrada em conflito é mantida no histórico dessa entrada, em vez de ser descartada.

Os conflitos são resolvidos por comparação das datas e horas da última modificação, pelo que o árbitro é o relógio do sistema de cada utilizador e não qualquer noção de autoridade. O aviso é acionado apenas ao guardar: «o aviso de sincronização só é acionado pelo comando ‹Guardar›, e não pelo comando ‹Guardar como›. Ao executar o comando ‹Guardar como› e selecionar manualmente um ficheiro, esse ficheiro será sempre substituído.» As entradas do histórico sobrevivem a uma fusão, mas «podem ser eliminadas pela manutenção automática do histórico», que se baseia no tamanho. E o KeePass 1.x não tem qualquer sincronização, pelo que aí uma gravação substitui mesmo o que foi alterado entretanto nos bastidores.

O KeePassXC difere de uma forma que importa se for esse o cliente em uso. Tem uma função de fusão na interface gráfica e como keepassxc-cli merge, que compara as entradas por UUID e data de modificação. Mas não tem sincronização na nuvem integrada, propositadamente, e a FAQ apresenta o raciocínio: colocar a base de dados numa pasta partilhada na nuvem e deixar que o serviço de sincronização trate dela, o que «mantém baixa a complexidade do nosso código». Engenharia defensável, com uma consequência operacional específica. O Dropbox, o Nextcloud e o OneDrive nada sabem sobre o KDBX, pelo que edições simultâneas produzem cópias em conflito do ficheiro, e a reconciliação é uma fusão manual de que alguém tem de se lembrar.

O padrão que o próprio KeePass recomenda para ficheiros partilhados é um trigger (acionador): manter uma cópia local e sincronizar com o ficheiro principal, um esquema que a documentação descreve como forma de evitar «a perda de dados quando os ficheiros de base de dados são substituídos por outras aplicações (por exemplo, software de serviços de armazenamento na nuvem).» Funciona. Significa também que o modelo de acesso passa a depender de um trigger guardado num ficheiro de configuração que, como a página Triggers refere, não está cifrado e «aplica-se a todos os utilizadores desta instalação do KeePass.»

Retirar o acesso

Esta é a primeira pergunta a fazer em qualquer avaliação. Um modelo baseado em ficheiros não tem boa resposta para ela, e a que tem tende a surpreender.

Um colaborador que está de saída tinha a chave mestra. Pode também ter uma cópia do KDBX num portátil, numa cópia de segurança, numa pasta de sincronização ou numa cópia em conflito que ninguém limpou. Alterar a chave mestra volta a cifrar a base de dados daí em diante e nada faz às cópias que já existem. Estas continuam decifráveis com a chave com que foram guardadas, indefinidamente. O histórico das entradas agrava a situação: rodar uma palavra-passe dentro da base de dados mantém o valor anterior no histórico dessa entrada, pelo que uma cópia antiga contém tanto o segredo antigo como o novo.

A única revogação real consiste em efetuar a rotação de todas as credenciais a que essa pessoa tinha acesso, o que, num modelo de ficheiro único, significa todas. O trabalho escala com o tamanho da base de dados e não com o âmbito das funções dessa pessoa.

No Passwork, o mesmo evento fica delimitado. Remover o acesso do utilizador elimina a sua cópia encapsulada da chave do cofre, e os restantes membros continuam com a chave inalterada. A rotação após a saída do colaborador continua a ser o controlo adequado para tudo o que essa pessoa efetivamente leu, e nenhum produto consegue reverter a divulgação de uma credencial que alguém memorizou. A diferença é que o raio de impacto é um cofre e não tudo, e a revogação é uma operação e não um projeto.

Quando a integração LDAP/Active Directory do Passwork estiver configurada, essa operação nem precisa de ser manual: desativar a conta no AD revoga automaticamente o acesso ao Passwork, de acordo com o estado do diretório, pelo que a saída de um colaborador no diretório equivale à saída no cofre. E o painel de segurança não deixa as consequências entregues à memória: sinaliza como risco de comprometimento as credenciais ainda acessíveis a um utilizador cujo acesso foi revogado, o que transforma aquilo a que essa pessoa tinha acesso numa lista de tarefas visível, em vez de algo a reconstituir manualmente.

Quem leu o quê

O KeePass é uma aplicação de desktop sem componente de servidor, um ponto que as suas próprias notas reconhecem ao rejeitar um relatório sobre um ataque de temporização: o KeePass «não dispõe de quaisquer capacidades de servidor (em especial, não é possível acionar externamente nenhuma abertura automática da base de dados).»

Isto tem uma consequência para a auditoria. O KDBX regista datas e horas de modificação e o histórico das entradas, que são um registo de alterações ao ficheiro, não um registo de acessos. Nada regista que alguém abriu a base de dados e leu uma credencial, porque a leitura ocorre inteiramente no cliente. Com uma única chave mestra partilhada, nem sequer um registo de alterações permite saber de forma fiável que pessoa as fez.

O Passwork regista as ações no servidor e pode reencaminhá-las em CEF para o syslog ou para o registo de eventos do Windows, para um SIEM (registo de atividade, lista de eventos). As concessões, alterações e revogações são registadas individualmente e atribuídas a uma conta.

Confiar num ficheiro que todos editam

O argumento mais contundente contra o padrão da base de dados partilhada provém da própria documentação do KeePass.

O KeePass permite usar marcadores de posição nas entradas. {CMD:...} executa uma linha de comandos, e as referências de campo podem obter dados de outras entradas, pelo que um URL manipulado pode exfiltrar uma credencial diferente. A página Security apresenta ela própria o exemplo: https://example.com/?u={REF:U@T:Facebook}&p={REF:P@T:Facebook}. A orientação que se segue é inequívoca:

Ao abrir uma base de dados criada/modificada por outra pessoa, deve verificar cuidadosamente todos os dados que pretende utilizar. Se não confiar plenamente no criador da base de dados, não abra quaisquer ficheiros anexados às entradas.

Leia-se isto no contexto de uma implementação em unidade de rede partilhada. Uma base de dados de equipa é, por definição, criada e modificada por outras pessoas, e qualquer pessoa com acesso de escrita pode adicionar entradas em que as outras irão clicar. O modelo de confiança que o KeePass documenta pressupõe que a base de dados tem um único proprietário que garante o seu conteúdo, o que é precisamente o que um ficheiro de equipa partilhado não é.

Vulnerabilidades documentadas

A CVE-2023-32784 (CVSS 7,5) permitia recuperar a palavra-passe mestra em texto simples a partir de um dump de memória no KeePass 2.x anterior à versão 2.54, inclusive a partir de um ficheiro de swap ou de hibernação e mesmo depois de o processo ter terminado, com apenas o primeiro carácter irrecuperável. A causa era uma caixa de texto personalizada que deixava vestígios de cada carácter na memória do .NET. Foi corrigida na versão 2.54, e o investigador elogiou a rapidez da resposta.

A CVE-2023-24055 (CVSS 5,5) está assinalada como disputada pela MITRE. Um atacante com acesso de escrita ao ficheiro de configuração XML podia adicionar um trigger de exportação e recolher palavras-passe em texto simples. A entrada do NVD regista a posição do fabricante: «a base de dados de palavras-passe não se destina a ser segura contra um atacante com esse nível de acesso ao PC local.» Essa posição é coerente, e a página Security Issues defende-a em termos gerais: quem consegue escrever no ficheiro de configuração pode, em regra, substituir antes o executável.

Para equilíbrio, o KeePassXC foi alvo de uma auditoria externa, concluída em janeiro de 2023, e afirma abertamente que uma auditoria «é válida apenas para um ‹instantâneo› do código».

Tabela comparativa

Migrar e o que vigiar durante o processo

O Passwork importa o XML do KeePass, a par de JSON e CSV. Não lê o binário KDBX cifrado, e a análise é feita no cliente e não no servidor, que é a única disposição coerente com o facto de o servidor nunca ver texto simples.

A consequência merece ser afirmada de forma explícita, e não diluída. Exportar do KeePass para XML produz um ficheiro não cifrado com todas as credenciais, que permanece no disco enquanto durar a migração. Convém fazê-lo numa máquina sob controlo próprio, em armazenamento local e não numa pasta sincronizada, e eliminar o ficheiro com uma ferramenta que sobrescreva os dados em vez de apenas remover a referência. É o único passo de uma migração em que uma tarde descuidada anula de uma só vez a criptografia dos dois produtos.

Quando o KeePass é a resposta certa

Para quem esteja a avaliar especificamente se o KeePass chega para uma pequena equipa, o artigo Gestão de palavras-passe e de acessos para PMEs: O KeePass é suficiente? trata essa questão diretamente. Este artigo mantém-se mais restrito, apenas no eixo da arquitetura de cifragem, para equipas de qualquer dimensão.

Para uma só pessoa, ou para duas pessoas que, de qualquer forma, partilham tudo, o KeePass com uma base de dados KDBX 4 e parâmetros Argon2 sensatos é uma excelente escolha, e é gratuito. A criptografia é sólida, o formato está documentado publicamente e, sem servidor, não existe nenhum serviço a violar.

O modelo deixa de servir quando são necessárias respostas que um ficheiro não consegue dar. Quem tem acesso a isto, em concreto. O que exatamente se perdeu quando aquele portátil desapareceu. O que deixa de funcionar quando esta pessoa sai na sexta-feira. Provar que o prestador externo nunca viu credenciais de produção.

Um teste útil antes de decidir: contar quantas pessoas possuem hoje a chave mestra da base de dados partilhada e perguntar o que seria necessário rodar se qualquer uma delas saísse amanhã. Se a resposta for «tudo», não se trata de um problema de configuração que se resolva com ajustes. É o modelo de ficheiro a funcionar como concebido. A referência da hierarquia de chaves mostra como é o limite alternativo.

Um ficheiro tem uma chave para todos. Um modelo de cofres tem uma chave por cofre, encapsulada por pessoa. Essa diferença não diminui à medida que a equipa cresce; agrava-se. Se o KeePass não for a única alternativa na pré-seleção, a comparação entre as arquiteturas de cifragem de cofres do Passwork e do Bitwarden percorre os mesmos três momentos (gravações simultâneas, saída de colaboradores, auditoria) para um concorrente nativo da nuvem em vez de um formato de ficheiro.

Aplicar o teste da chave mestra à própria equipa e ver depois a alternativa. Iniciar um teste gratuito do Passwork.

Perguntas frequentes

Gestão de palavras-passe e de acessos para PMEs: O KeePass é suficiente?

Todos os administradores de TI que usam o KeePass numa equipa contam a mesma história. Começa com um único ficheiro .kdbx partilhado numa unidade de rede. Depois, alguém não consegue abri-lo porque um colega o tem bloqueado. Depois, um administrador de sistemas júnior guarda por cima de uma alteração que outra pessoa fez uma hora antes. Depois, um colaborador sai e ninguém sabe bem a que palavras-passe tinha acesso. O KeePass é uma ferramenta genuinamente excelente: para uma só pessoa. A partir do momento em que é colocado à frente de uma equipa, já não se está a gerir palavras-passe.

PassworkAlex Muntyan

O que é a cifragem zero-knowledge? Como funciona em 5 minutos

A cifragem zero-knowledge significa que o servidor nunca possui as chaves de decifragem, apenas texto cifrado. Como funciona a cadeia de chaves, contra o que protege, contra o que não protege e como verificar a alegação de um fornecedor.

PassworkPasswork Team

Passwork vs Bitwarden: como difere a arquitetura de cifragem dos cofres

O Passwork cifra cada cofre com a sua própria chave. O Bitwarden cifra uma organização inteira com uma única chave partilhada. Esta comparação analisa o que isso significa em termos de raio de impacto, isolamento entre equipas, recuperação de contas e respostas de auditoria quando uma credencial é divulgada.

PassworkPasswork Team

KeePass hat bessere kryptografische Primitive als viele kommerzielle Passwortmanager, und genau dort beginnt dieser Vergleich. Das Format KDBX 4 unterstützt eine memory-hard Schlüsselableitungsfunktion, authentifiziert seinen Geheimtext, bevor überhaupt etwas entschlüsselt wird, und verschlüsselt die gesamte Datenbank statt nur der Passwortfelder.

Was KDBX nicht hat, ist eine Schlüsselverwaltung für mehr als eine Person. Es gibt einen Schlüssel, er gehört zu einer Datei und nicht zu einem Menschen, und er öffnet alles. Jede Mehrbenutzer-Eigenschaft, die ein Team irgendwann braucht – einer Person den Zugriff entziehen, wissen, wer welche Zugangsdaten gelesen hat, begrenzen, was ein einzelner abgeflossener Schlüssel offenlegt –, muss außerhalb des Formats entstehen, meist aus Dateisystemrechten und guten Absichten.

Das ist die eigentliche Trennlinie, und sie zeigt sich in drei Momenten: wenn zwei Personen die gemeinsame Datenbank gleichzeitig speichern, wenn jemand das Unternehmen verlässt und wenn ein Auditor fragt, wer im letzten Quartal welche Zugangsdaten geöffnet hat.

Was KDBX 4 tatsächlich leistet

Eine KDBX-4-Datei wird mit AES-256 im CBC-Modus mit PKCS#7-Padding oder mit ChaCha20 verschlüsselt, so die Formatspezifikation. Der Schlüssel entsteht, indem die Komponenten des Masterschlüssels zu einem 256-Bit-Wert gehasht werden, dieser Wert durch eine Schlüsselableitungsfunktion läuft und das Ergebnis anschließend mit einem bei jedem Speichern neuen Seed gehasht wird. Drei Ableitungsfunktionen sind ohne Plugins enthalten: AES-KDF, Argon2d und Argon2id.

Bei der Integrität hat KDBX 4 den Vorsprung gegenüber dem Vorgänger gewonnen. Die Datei speichert einen SHA-256-Hash des Headers, sodass Beschädigungen ohne den Masterschlüssel erkennbar sind, anschließend einen HMAC-SHA-256 des Headers, und die Nutzdaten werden in 1-MB-Blöcke aufgeteilt, die jeweils ihren eigenen HMAC tragen. Die Spezifikation nennt das „ein Encrypt-then-MAC-Schema“, das heißt, die Authentizität wird geprüft, bevor überhaupt etwas entschlüsselt wird. KDBX 3.1 hashte stattdessen den Klartext, und die Anmerkung des Autors zu dieser Änderung ist wegen ihrer Zurückhaltung ein Zitat wert:

Obwohl das Encrypt-then-MAC-Schema (KDBX 4) allgemein als sicherer gilt als ein MAC-then-Encrypt-Schema (KDBX 3.1), glauben wir nicht, dass KDBX-3.1-Dateien unsicher waren.

Für ein Team sind zwei Einschränkungen wichtig. KDBX 3.1 ist in KeePassXC weiterhin ein natives Format, deshalb gilt „KeePass bedeutet Argon2 und HMAC“ erst, sobald jemand die Datenbank tatsächlich migriert hat – ein manueller Schritt in den Verschlüsselungseinstellungen. Und der Speicherparameter von Argon2 ist durch das schwächste Gerät begrenzt, das die Datei öffnet: KeePass empfiehlt die Hälfte des Arbeitsspeichers des kleinsten Geräts und warnt, dass ein großer Speicherparameter unter iOS AutoFill beeinträchtigen kann; dort werden 64 MB oder weniger empfohlen. Eine KDF ist nur so stark wie die Parameter, die Ihr Telefon verkraftet.

Der Umfang der Verschlüsselung ist tatsächlich besser als bei mehreren gehosteten Wettbewerbern: „KeePass verschlüsselt die gesamte Datenbank, das heißt nicht nur Ihre Passwörter, sondern auch Ihre Benutzernamen, URLs, Notizen und so weiter.“ Eine gestohlene KDBX-Datei verrät nichts über ihren Inhalt, nicht einmal die Titel der Einträge.

Eine Sache sieht wie eine zweite Schicht aus, ist es aber nicht. KDBX wendet auf geschützte Felder innerhalb des XML zusätzlich Salsa20 oder ChaCha20 an, und die Spezifikation begegnet dem Missverständnis direkt:

Wir betonen, dass der einzige Zweck der inneren Verschlüsselung darin besteht, den Schutz des Prozessspeichers zu unterstützen. Die innere Verschlüsselung hat keinen Einfluss auf die kryptografische Sicherheit des KDBX-Dateiformats.

Ihr Schlüssel liegt im inneren Header und hängt nicht vom Masterschlüssel ab.

Wo der Schlüssel liegt – und warum das alles andere entscheidet

Der Masterschlüssel von KeePass ist zusammengesetzt: ein Masterpasswort, eine Schlüsseldatei und ein über DPAPI an das aktuelle Windows-Konto gebundener Schlüssel, in beliebiger Kombination. Alle gewählten Komponenten sind erforderlich, und die Dokumentation zum Masterschlüssel wird dabei deutlich:

Wenn Sie eine der Komponenten des Masterschlüssels vergessen oder verlieren (oder die Zusammensetzung vergessen), sind alle in der Datenbank gespeicherten Daten verloren. Es gibt keine Backdoor und keinen Universalschlüssel, der Ihre Datenbank öffnen kann.

Beachten Sie, was diese Komponenten gemeinsam haben. Ein Passwort ist Wissen, eine Schlüsseldatei ist Besitz, ein DPAPI-Schlüssel ist ein Maschinenkonto. Keine davon ist eine Identität, die die Datenbank erkennt und später von einer anderen unterscheiden kann. Der Schlüssel ist eine Eigenschaft der Datei.

Passwork setzt bei der Person an und folgt demselben Prinzip der Zero-Knowledge-Architektur (der Server verarbeitet ausschließlich Geheimtext), aufgebaut um die individuelle Identität statt um ein einzelnes Dateigeheimnis. Jeder Benutzer hat ein eigenes RSA-Schlüsselpaar, das clientseitig erzeugt wird; der private Teil wird mit einem Schlüssel verschlüsselt, der aus dem Masterpasswort abgeleitet ist. Ein Tresor erhält bei der Erstellung einen eigenen AES-256-Schlüssel, und jeder Benutzer mit Zugriff hält eine separate Kopie dieses Tresorschlüssels, verschlüsselt mit seinem eigenen öffentlichen Schlüssel (Schlüsselhierarchie). Der Server verarbeitet immer nur Geheimtext (Überblick zur Kryptografie).

Die gemeinsame Nutzung folgt aus dieser Struktur. Eine Zugriffsvergabe verschlüsselt den Tresorschlüssel neu für den öffentlichen Schlüssel des Empfängers, statt die Daten neu zu verschlüsseln (Mechanik der Freigabe). Ein Entzug löscht die verschlüsselte Kopie dieser Person. Alle anderen arbeiten mit demselben Tresorschlüssel weiter, und nichts wird neu verschlüsselt.

Wo die Kryptografie von KeePass für Einzelnutzer stärker ist

Bei der Schlüsselableitung zeigt sich das. Argon2 ist memory-hard, und genau diese Eigenschaft macht das Knacken mit GPUs und ASICs teuer; KeePass erklärt, warum in diesem Zusammenhang Argon2d bevorzugt wird: „ein besserer Schutz gegen eine tatsächlich bestehende Bedrohung (das Knacken von Passwörtern mit GPUs/ASICs ist Stand der Technik) ist wichtiger als ein Schutz gegen bestimmte Seitenkanalangriffe, die auf Client-Geräten in Zukunft zu einem Problem werden können oder auch nicht.“ Passwork leitet den Masterschlüssel mit PBKDF2 über 300.000 Iterationen auf SHA-256 ab – eine vertretbare, von NIST anerkannte Einstellung, aber nicht memory-hard, und gegenüber spezialisierter Cracking-Hardware macht dieser Unterschied etwas aus.

An der Schlussfolgerung für ein Team, das Zugangsdaten über mehr als eine Person hinweg nutzt, ändert das nichts: dort entscheidet die Schlüsselverwaltung, nicht die Stärke des Verschlüsselungsverfahrens, und um diese Frage geht es im weiteren Vergleich. Für einen einzelnen Benutzer mit einem Laptop und einer Datei, der nichts mit anderen teilt, ist das die Eigenschaft, die gegen Offline-Knackversuche am meisten zählt.

Was passiert, wenn ein Team die Datei gemeinsam nutzt

Hier zeigt sich das Entwurfsziel. Die KeePass-Dokumentation zu mehreren Benutzern formuliert es ohne Einschränkung:

Alle Benutzer verwenden dasselbe Masterpasswort und/oder dieselbe Schlüsseldatei, um die Datenbank zu öffnen. Es gibt keine Zugriffskontrolllisten (ACLs) pro Gruppe oder pro Eintrag. Um den Schreibzugriff auf die Datenbankdatei einzuschränken (das heißt, nur eine ausgewählte Gruppe von Benutzern darf die gespeicherten Daten ändern), verwenden Sie Dateisystem-Zugriffsrechte.

Zugriffskontrolle gibt es, aber sie liegt in NTFS oder in Ihrer SMB-Freigabe, nicht im Produkt und nicht in der Kryptografie. Lesezugriff ist konstruktionsbedingt alles oder nichts, denn Lesen setzt den einen Schlüssel voraus, der alles entschlüsselt.

KeePass 2.x erkennt Konflikte. Beim Speichern „prüft es zunächst, ob die Datei auf der Festplatte seit dem Laden geändert wurde“, und bietet dann an, zu synchronisieren statt zu überschreiben. Das Zusammenführen erfolgt auf Eintragsebene, und die unterlegene Version eines konfliktbehafteten Eintrags wird in der Historie dieses Eintrags aufbewahrt, nicht verworfen.

Konflikte werden über den Vergleich der Zeitstempel der letzten Änderung gelöst; entscheidend ist damit die Systemuhr jedes Benutzers und nicht eine Form von Autorität. Die Abfrage erscheint nur beim Speichern: „Die Synchronisierungsabfrage wird nur durch den Befehl ‚Speichern‘ ausgelöst, nicht durch den Befehl ‚Speichern unter‘. Wird der Befehl ‚Speichern unter‘ ausgeführt und eine Datei manuell ausgewählt, wird diese Datei immer überschrieben.“ Historieneinträge überdauern ein Zusammenführen, „können aber von der automatischen Historienpflege gelöscht werden“ – diese richtet sich nach der Größe. Und KeePass 1.x hat überhaupt keine Synchronisierung, sodass ein Speichern dort tatsächlich überschreibt, was sich darunter geändert hat.

KeePassXC unterscheidet sich in einem Punkt, der wichtig ist, wenn es Ihr Client ist. Es hat eine Funktion zum Zusammenführen in der Oberfläche und als keepassxc-cli merge, die Einträge über UUID und Änderungszeit vergleicht. Eine integrierte Cloud-Synchronisierung fehlt aber absichtlich, und die FAQ nennt den Grund: Die Datenbank soll in einem gemeinsamen Cloud-Ordner liegen und der Synchronisierungsdienst soll sich darum kümmern, was „die Komplexität unseres Codes niedrig hält“. Vertretbare Technik mit einer konkreten betrieblichen Folge. Dropbox, Nextcloud und OneDrive wissen nichts über KDBX, deshalb entstehen bei gleichzeitigen Änderungen Konfliktkopien der Datei, und sie wieder zusammenzuführen ist Handarbeit, an die jemand denken muss.

Das von KeePass selbst empfohlene Muster für gemeinsam genutzte Dateien ist ein Trigger: eine lokale Kopie behalten und mit der Hauptdatei synchronisieren – ein Verfahren, das die Dokumentation damit beschreibt, es verhindere „Datenverlust, wenn Datenbankdateien von anderen Anwendungen überschrieben werden (zum Beispiel von Software für Cloud-Speicherdienste)“. Es funktioniert. Es bedeutet aber auch, dass Ihr Zugriffsmodell nun von einem Trigger abhängt, der in einer Konfigurationsdatei liegt, die laut Trigger-Seite unverschlüsselt ist und „für alle Benutzer dieser KeePass-Installation gilt“.

Zugriff zurücknehmen

Fragen Sie das in jeder Evaluierung zuerst. Ein dateibasiertes Modell hat darauf keine gute Antwort, und die Antwort, die es hat, überrascht die meisten.

Ein ausscheidender Mitarbeiter hatte den Masterschlüssel. Möglicherweise hat er außerdem eine Kopie der KDBX-Datei auf einem Laptop, in einem Backup, in einem Synchronisierungsordner oder in einer Konfliktkopie, die niemand aufgeräumt hat. Ein Wechsel des Masterschlüssels verschlüsselt die Datenbank für die Zukunft neu und ändert nichts an bereits bestehenden Kopien. Diese bleiben mit dem Schlüssel entschlüsselbar, unter dem sie gespeichert wurden – unbegrenzt. Die Eintragshistorie verschärft das: Wird ein Passwort in der Datenbank rotiert, bleibt der vorherige Wert in der Historie dieses Eintrags, sodass eine veraltete Kopie sowohl das alte als auch das neue Geheimnis enthält.

Der einzige echte Entzug besteht darin, alle Zugangsdaten zu rotieren, die diese Person erreichen konnte – in einem Einzeldateimodell also alle. Der Aufwand richtet sich nach der Größe Ihrer Datenbank und nicht nach dem Aufgabenbereich dieser Person.

In Passwork ist dasselbe Ereignis begrenzt. Der Entzug des Zugriffs löscht die verschlüsselte Kopie des Tresorschlüssels dieses Benutzers, und die übrigen Mitglieder arbeiten mit dem unveränderten Schlüssel weiter. Eine Rotation nach dem Offboarding bleibt die richtige Maßnahme für alles, was die Person tatsächlich gelesen hat, und kein Produkt kann Zugangsdaten zurückholen, die sich jemand gemerkt hat. Der Unterschied ist, dass der Schaden auf einen Tresor begrenzt bleibt statt auf alles und dass der Entzug eine einzelne Operation ist und kein Projekt.

Wo die LDAP-/Active-Directory-Integration von Passwork konfiguriert ist, muss dieser Vorgang gar nicht manuell erfolgen: Wird das Konto in AD deaktiviert, entzieht Passwork den Zugriff automatisch entsprechend dem Verzeichniszustand, sodass ein Offboarding im Verzeichnis ein Offboarding im Tresor ist. Und das Sicherheits-Dashboard überlässt die Nachbereitung nicht dem Gedächtnis – es markiert Zugangsdaten, die ein Benutzer nach dem Entzug seines Zugriffs weiterhin erreichen könnte, als Kompromittierungsrisiko und macht aus dem, was diese Person erreichen konnte, eine sichtbare Arbeitsliste statt etwas, das von Hand rekonstruiert werden muss.

Wer hat was gelesen

KeePass ist eine Desktop-Anwendung ohne Serverkomponente – ein Punkt, den die eigenen Hinweise machen, während sie einen Bericht über einen Timing-Angriff zurückweisen: KeePass „verfügt über keine Serverfunktionen (insbesondere kann das automatische Öffnen einer Datenbank nicht extern ausgelöst werden)“.

Das hat Folgen für das Audit. KDBX erfasst Änderungszeitstempel und Eintragshistorie, also ein Protokoll der Änderungen an der Datei, nicht ein Protokoll der Zugriffe. Nichts hält fest, dass jemand die Datenbank geöffnet und Zugangsdaten gelesen hat, denn das Lesen findet vollständig im Client statt. Bei einem gemeinsamen Masterschlüssel kann selbst ein Änderungseintrag nicht zuverlässig sagen, welcher Mensch ihn verursacht hat.

Passwork protokolliert Aktionen serverseitig und kann sie im CEF-Format an syslog oder das Windows-Ereignisprotokoll für ein SIEM weiterleiten (Aktivitätsprotokoll, Ereignisliste). Vergaben, Änderungen und Entzüge werden einzeln erfasst und einem Konto zugeordnet.

Einer Datei vertrauen, die alle bearbeiten

Das schärfste Argument gegen das Muster der gemeinsamen Datenbank kommt aus der Dokumentation von KeePass selbst.

KeePass unterstützt Platzhalter in Einträgen. {CMD:...} führt eine Befehlszeile aus, und Feldreferenzen können Daten aus anderen Einträgen holen, sodass eine präparierte URL andere Zugangsdaten abfließen lassen kann. Die Sicherheitsseite nennt das Beispiel selbst: https://example.com/?u={REF:U@T:Facebook}&p={REF:P@T:Facebook}. Der darauf folgende Hinweis ist eindeutig:

Wenn Sie eine Datenbank öffnen, die von jemand anderem erstellt oder geändert wurde, sollten Sie alle Daten, die Sie verwenden möchten, sorgfältig prüfen. Wenn Sie dem Ersteller der Datenbank nicht vollständig vertrauen, öffnen Sie keine an Einträge angehängten Dateien.

Lesen Sie das vor dem Hintergrund einer Bereitstellung auf einem Netzlaufwerk. Eine Team-Datenbank wird per Definition von anderen Personen erstellt und geändert, und jeder mit Schreibzugriff kann Einträge hinzufügen, die die anderen anklicken werden. Das von KeePass dokumentierte Vertrauensmodell setzt voraus, dass eine Datenbank einen Besitzer hat, der für ihren Inhalt bürgt – und genau das ist eine gemeinsam genutzte Team-Datei nicht.

Dokumentierte Schwachstellen

CVE-2023-32784 (CVSS 7,5) erlaubte es, das Masterpasswort im Klartext aus einem Speicherabbild in KeePass 2.x vor 2.54 zu rekonstruieren, auch aus einer Auslagerungs- oder Ruhezustandsdatei und selbst nach dem Beenden des Prozesses; nur das erste Zeichen blieb nicht rekonstruierbar. Ursache war ein eigenes Textfeld, das pro Zeichen Reste im .NET-Speicher hinterließ. Der Fehler wurde in 2.54 behoben, und der Forscher bescheinigte eine schnelle Reaktion.

CVE-2023-24055 (CVSS 5,5) ist von MITRE als umstritten markiert. Ein Angreifer mit Schreibzugriff auf die XML-Konfigurationsdatei konnte einen Export-Trigger hinzufügen und Passwörter im Klartext abgreifen. Der NVD-Eintrag hält die Position des Herstellers fest: „Die Passwortdatenbank soll nicht gegen einen Angreifer sicher sein, der diese Zugriffsebene auf dem lokalen PC hat.“ Diese Position ist konsistent, und die Security-Issues-Seite begründet sie allgemein: Wer Ihre Konfigurationsdatei schreiben kann, kann meist auch die ausführbare Datei ersetzen.

Zur Einordnung: KeePassXC hat ein externes Audit durchlaufen, abgeschlossen im Januar 2023, und sagt offen, dass ein Audit „nur für eine ‚Momentaufnahme‘ des Codes gilt“.

Vergleichstabelle

Migration – und worauf dabei zu achten ist

Passwork importiert KeePass-XML, daneben JSON und CSV. Die verschlüsselte KDBX-Binärdatei wird nicht gelesen, und das Parsen findet im Client statt und nicht auf dem Server – die einzige Anordnung, die dazu passt, dass der Server nie Klartext sieht.

Die Folge sollte ausgesprochen und nicht übergangen werden. Ein Export aus KeePass nach XML erzeugt eine unverschlüsselte Datei mit allen Zugangsdaten, und sie liegt so lange auf der Festplatte, wie die Migration dauert. Führen Sie ihn auf einem Rechner aus, den Sie kontrollieren, auf lokalem Speicher statt in einem synchronisierten Ordner, und löschen Sie die Datei mit einem Werkzeug, das überschreibt und nicht nur den Verweis entfernt. Es ist der eine Schritt einer Migration, in dem ein unachtsamer Nachmittag die Kryptografie beider Produkte gleichzeitig aushebelt.

Wann KeePass die richtige Wahl ist

Wenn Sie konkret abwägen, ob KeePass für ein kleines Team ausreicht, behandelt Passwort- und Zugriffsverwaltung für KMU: Reicht KeePass aus? genau diese Frage. Dieser Artikel bleibt enger gefasst, allein auf der Achse der Verschlüsselungsarchitektur, für Teams jeder Größe.

Wenn Sie eine Person sind oder zwei Personen, die ohnehin alles gemeinsam nutzen, ist KeePass mit einer KDBX-4-Datenbank und vernünftigen Argon2-Parametern eine ausgezeichnete Wahl – und kostenlos. Die Kryptografie ist stark, das Format ist öffentlich dokumentiert, und ohne Server gibt es keinen Dienst, in den eingebrochen werden kann.

Das Modell passt nicht mehr, sobald Sie Antworten brauchen, die eine Datei nicht geben kann. Wer genau hat hierauf Zugriff. Was genau ist verloren gegangen, als dieser Laptop verschwand. Was bricht, wenn diese Person am Freitag geht. Belegen Sie, dass der externe Dienstleister nie Produktions-Zugangsdaten gesehen hat.

Ein nützlicher Test vor der Entscheidung: Zählen Sie, wie viele Personen heute den Masterschlüssel zu Ihrer gemeinsamen Datenbank besitzen, und fragen Sie dann, was Sie rotieren müssten, wenn eine von ihnen morgen ginge. Lautet die Antwort „alles“, ist das kein Konfigurationsproblem, das sich wegstellen lässt. Es ist das Dateimodell, das genau wie vorgesehen funktioniert. Die Referenz zur Schlüsselhierarchie zeigt, wie die alternative Grenze aussieht.

Eine Datei hat einen Schlüssel für alle. Ein Tresor hat einen Schlüssel pro Tresor, verschlüsselt pro Person. Dieser Abstand wird nicht kleiner, wenn ein Team wächst; er wird größer. Wenn KeePass nicht die einzige Alternative auf Ihrer Auswahlliste ist, geht der Vergleich der Tresor-Verschlüsselungsarchitektur von Passwork und Bitwarden dieselben drei Momente (gleichzeitiges Speichern, Offboarding, Audit) für einen cloud-nativen Wettbewerber anstelle eines Dateiformats durch.

Führen Sie den Masterschlüssel-Test in Ihrem eigenen Team durch und sehen Sie sich dann die Alternative an. Kostenlose Passwork-Testversion starten.

Häufig gestellte Fragen

Passwort- und Zugriffsverwaltung für KMU: Reicht KeePass aus?

Jeder IT-Administrator, der KeePass für ein Team betreibt, erzählt dieselbe Geschichte. Es beginnt mit einer gemeinsam genutzten .kdbx-Datei auf einem Netzlaufwerk. Dann kann jemand sie nicht öffnen, weil ein Kollege sie gesperrt hat. Dann überschreibt ein junger Systemadministrator eine Änderung, die jemand anderes eine Stunde zuvor gemacht hat. Dann verlässt ein Mitarbeiter das Unternehmen, und niemand weiß genau, auf welche Passwörter er Zugriff hatte. KeePass ist ein wirklich ausgezeichnetes Werkzeug – für eine Person. Sobald Sie es einem Team vorsetzen, verwalten Sie keine Passwörter mehr. Sie verwalten ein

PassworkAlex Muntyan

Was ist Zero-Knowledge-Verschlüsselung? So funktioniert sie in 5 Minuten

Zero-Knowledge-Verschlüsselung bedeutet, dass der Server nie Ihre Entschlüsselungsschlüssel hält, sondern nur Geheimtext. Erfahren Sie, wie die Schlüsselkette funktioniert, wogegen sie schützt, wogegen nicht und wie sich die Aussage eines Anbieters überprüfen lässt.

PassworkPasswork Team

Passwork vs Bitwarden: Tresor-Verschlüsselungsarchitektur im Vergleich

Passwork verschlüsselt jeden Tresor mit einem eigenen Schlüssel. Bitwarden verschlüsselt eine ganze Organisation mit einem gemeinsamen Schlüssel. Dieser Vergleich zeigt, was das für den Schadensumfang, die Isolation von Teams, die Kontowiederherstellung und die Audit-Antworten bedeutet, wenn Zugangsdaten abfließen.

PassworkPasswork Team

KeePass tiene mejores primitivas criptográficas que muchos gestores de contraseñas de pago, y por ahí empieza esta comparación. El formato KDBX 4 admite una función de derivación de claves de uso intensivo de memoria, autentica su texto cifrado antes de descifrar nada y cifra toda la base de datos, no solo los campos de contraseña.

Lo que KDBX no tiene es gestión de claves para más de una persona. Hay una sola clave, pertenece a un archivo y no a una persona, y lo abre todo. Toda propiedad multiusuario que un equipo acaba necesitando —revocar el acceso de una persona, saber quién leyó una credencial, limitar lo que expone una única clave filtrada— hay que construirla fuera del formato, normalmente a partir de permisos del sistema de archivos y buenas intenciones.

Ese es el verdadero eje de esta comparación, y se manifiesta en tres momentos: cuando dos personas guardan a la vez la base de datos compartida, cuando alguien deja la empresa y cuando un auditor pregunta quién abrió una credencial el trimestre pasado.

Qué hace realmente KDBX 4

Un archivo KDBX 4 se cifra con AES-256 en modo CBC con relleno PKCS#7, o con ChaCha20, según la especificación del formato. La clave se obtiene a partir de un hash de los componentes de la clave maestra en un valor de 256 bits, que después pasa por una función de derivación de claves; al resultado se le aplica un hash con una semilla nueva en cada guardado. Tres funciones de derivación vienen incluidas sin plugins: AES-KDF, Argon2d y Argon2id.

En integridad es donde KDBX 4 se adelantó a su predecesor. El archivo guarda un hash SHA-256 de la cabecera, con lo que la corrupción se detecta sin la clave maestra, después un HMAC-SHA-256 de la cabecera, y la carga útil se divide en bloques de 1 MB que llevan cada uno su propio HMAC. La especificación lo llama «un esquema Encrypt-then-MAC», es decir que la autenticidad se verifica antes de descifrar nada. KDBX 3.1 aplicaba el hash al texto en claro, y la nota del autor sobre el cambio merece citarse por su contención:

Aunque en general se considera que el esquema Encrypt-then-MAC (KDBX 4) es más seguro que un esquema MAC-then-Encrypt (KDBX 3.1), no creemos que los archivos KDBX 3.1 fueran inseguros.

Dos advertencias importan en un equipo. KDBX 3.1 sigue siendo un formato nativo en KeePassXC, así que «KeePass significa Argon2 y HMAC» solo se cumple una vez que alguien ha migrado realmente la base de datos, un paso manual en los ajustes de cifrado. Y el parámetro de memoria de Argon2 está limitado por el dispositivo más débil que abra el archivo: KeePass sugiere la mitad de la RAM del dispositivo más pequeño, y advierte de que en iOS un parámetro de memoria elevado puede romper AutoFill, por lo que recomienda 64 MB o menos. Una KDF no es más fuerte que los parámetros que resista el teléfono.

El alcance del cifrado es realmente mejor que en varios competidores alojados: «KeePass cifra toda la base de datos, es decir, no solo las contraseñas, sino también los nombres de usuario, las URL, las notas, etc.» Un KDBX robado no filtra nada sobre su contenido, ni siquiera los títulos de las entradas.

Algo parece una segunda capa, pero no lo es. KDBX también aplica Salsa20 o ChaCha20 a los campos protegidos dentro del XML, y la especificación se adelanta directamente a esa lectura errónea:

Insistimos en que el único propósito del cifrado interno es dar soporte a la protección de la memoria del proceso. El cifrado interno no influye en la seguridad criptográfica del formato de archivo KDBX.

Su clave reside en la cabecera interna y no depende de la clave maestra.

Dónde reside la clave y por qué eso decide todo lo demás

La clave maestra de KeePass es compuesta: una contraseña maestra, un archivo de clave y una clave vinculada a la cuenta de Windows actual mediante DPAPI, en cualquier combinación. Todos los componentes elegidos son obligatorios, y la documentación de la clave maestra es tajante al respecto:

Si olvida/pierde cualquiera de los componentes de la clave maestra (u olvida la composición), se pierden todos los datos almacenados en la base de datos. No hay puerta trasera ni clave universal que pueda abrir su base de datos.

Observe lo que comparten esos componentes. Una contraseña es conocimiento, un archivo de clave es posesión, una clave DPAPI es una cuenta de máquina. Ninguno es una identidad que la base de datos reconozca y pueda después distinguir de otra. La clave es una propiedad del archivo.

Passwork parte de la persona y aplica el mismo principio de arquitectura de conocimiento cero (el servidor nunca maneja más que texto cifrado), construido en torno a la identidad individual y no a un único secreto de archivo. Cada usuario tiene su propio par de claves RSA generado en el cliente, con la mitad privada cifrada bajo una clave derivada de su contraseña maestra. Una bóveda recibe su propia clave AES-256 al crearse, y cada usuario con acceso conserva una copia independiente de esa clave de bóveda, cifrada con su propia clave pública (jerarquía de claves). El servidor nunca maneja nada más que texto cifrado (introducción a la criptografía).

El uso compartido se deriva de esa estructura. Conceder acceso vuelve a cifrar la clave de la bóveda con la clave pública del destinatario, en lugar de volver a cifrar los datos (mecánica del uso compartido). Revocarlo elimina la copia cifrada de esa persona. El resto continúa con la misma clave de bóveda y no se vuelve a cifrar nada.

Dónde la criptografía de KeePass es más fuerte para un solo usuario

En la derivación de claves es donde se nota. Argon2 es de uso intensivo de memoria, que es precisamente la propiedad que encarece el descifrado con GPU y ASIC, y KeePass explica por qué prefiere Argon2d en este contexto: «una mejor protección frente a una amenaza realmente existente (el descifrado de contraseñas con GPU/ASIC es lo más avanzado hoy) es más importante que una protección frente a ciertos ataques de canal lateral que pueden convertirse o no en un problema en los dispositivos cliente en el futuro». Passwork deriva la clave maestra con PBKDF2 y 300 000 iteraciones sobre SHA-256: un ajuste defendible y reconocido por NIST, pero no de uso intensivo de memoria, y frente a hardware dedicado al descifrado esa distinción importa.

Eso no cambia la conclusión para un equipo que comparte credenciales entre más de una persona: ahí lo decisivo es la gestión de claves, no la fuerza del cifrado, y es la cuestión en la que se centra el resto de esta comparación. Para un solo usuario con un portátil y un archivo, que no comparte nada con nadie, esa es la propiedad que más importa frente a los intentos de descifrado sin conexión.

Qué ocurre cuando un equipo comparte el archivo

Aquí se ve el objetivo de diseño. La documentación de KeePass sobre varios usuarios no se anda con rodeos:

Todos los usuarios utilizan la misma contraseña maestra o el mismo archivo de clave, o ambos, para abrir la base de datos. No hay listas de control de acceso (ACL) por grupo ni por entrada. Para restringir el acceso de escritura al archivo de base de datos (es decir, que solo un conjunto seleccionado de usuarios pueda modificar los datos almacenados), utilice los permisos de acceso del sistema de archivos.

El control de acceso existe, pero reside en NTFS o en el recurso compartido SMB, no en el producto ni en la criptografía. El acceso de lectura es todo o nada por construcción, porque leer requiere la única clave que descifra todo.

KeePass 2.x sí detecta conflictos. Al guardar, «comprueba primero si el archivo en disco se ha modificado desde que se cargó» y, en ese caso, ofrece sincronizar en lugar de sobrescribir. La fusión se produce a nivel de entrada, y la versión perdedora de una entrada en conflicto se conserva en el historial de esa entrada en lugar de descartarse.

Los conflictos se resuelven comparando las marcas de tiempo de última modificación, así que el árbitro es el reloj del sistema de cada usuario y no ninguna noción de autoridad. El aviso aparece solo al guardar: «el aviso de sincronización solo lo activa el comando ‹Save›, no el comando ‹Save As›. Al ejecutar el comando ‹Save As› y seleccionar un archivo manualmente, ese archivo se sobrescribe siempre». Las entradas del historial sobreviven a una fusión, pero «pueden ser eliminadas por el mantenimiento automático del historial», que se basa en el tamaño. Y KeePass 1.x no tiene sincronización alguna, de modo que allí un guardado sí sobrescribe lo que haya cambiado por debajo.

KeePassXC se diferencia de una forma que importa si es su cliente. Tiene una función de fusión en la interfaz gráfica y como keepassxc-cli merge, que compara las entradas por UUID y hora de modificación. Pero no incluye sincronización en la nube de forma deliberada, y las preguntas frecuentes explican el razonamiento: colocar la base de datos en una carpeta compartida en la nube y dejar que el servicio de sincronización se encargue, lo que «mantiene baja la complejidad de nuestro código». Ingeniería defendible, con una consecuencia operativa concreta. Dropbox, Nextcloud y OneDrive no saben nada de KDBX, así que las ediciones simultáneas generan copias en conflicto del archivo, y conciliarlas es una fusión manual que alguien tiene que acordarse de ejecutar.

El patrón que KeePass recomienda para archivos compartidos es un disparador (trigger): mantener una copia local y sincronizarla con el archivo maestro, un esquema que su documentación describe como una forma de evitar la «pérdida de datos cuando otras aplicaciones sobrescriben los archivos de base de datos (por ejemplo, software de servicios de almacenamiento en la nube)». Funciona. También significa que el modelo de acceso depende ahora de un disparador guardado en un archivo de configuración que, como señala la página de disparadores, no está cifrado y «se aplica a todos los usuarios que utilizan esta instalación de KeePass».

Retirar el acceso

Pregunte esto primero en cualquier evaluación. Un modelo basado en archivos no tiene una buena respuesta, y la que tiene suele sorprender.

Un empleado que se marcha tenía la clave maestra. Puede que también tenga una copia del KDBX en un portátil, en una copia de seguridad, en una carpeta sincronizada o en una copia en conflicto que nadie limpió. Cambiar la clave maestra vuelve a cifrar la base de datos a partir de ese momento y no afecta a las copias que ya existen. Esas siguen siendo descifrables indefinidamente con la clave con la que se guardaron. El historial de entradas lo agrava: rotar una contraseña dentro de la base de datos conserva el valor anterior en el historial de esa entrada, de modo que una copia desactualizada contiene tanto el secreto antiguo como el nuevo.

La única revocación real es rotar todas las credenciales a las que esa persona podía llegar, lo que en un modelo de un solo archivo significa todas. El trabajo escala con el tamaño de la base de datos, no con el alcance del puesto de esa persona.

En Passwork ese mismo suceso está acotado. Retirar el acceso del usuario elimina su copia cifrada de la clave de la bóveda, y los miembros restantes continúan con la clave sin cambios. La rotación tras la baja del empleado sigue siendo el control adecuado para todo lo que esa persona haya leído realmente, y ningún producto puede deshacer la filtración de una credencial que alguien memorizó. La diferencia es que el radio de impacto es una bóveda y no todo, y que la revocación es una operación y no un proyecto.

Cuando está configurada la integración con LDAP/Active Directory de Passwork, esa operación no tiene por qué ser manual: desactivar la cuenta en AD revoca el acceso a Passwork de forma automática, en consonancia con el estado del directorio, así que dar de baja en el directorio equivale a dar de baja en la bóveda. Y el panel de seguridad no deja las consecuencias a la memoria: marca como riesgo de compromiso las credenciales que siguen siendo accesibles para un usuario cuyo acceso se ha revocado, con lo que convierte lo que esa persona podía alcanzar en una lista de trabajo visible y no en algo que reconstruir a mano.

Quién leyó qué

KeePass es una aplicación de escritorio sin componente de servidor, algo que señalan sus propias notas al descartar un informe sobre un ataque de temporización: KeePass «no ofrece ninguna capacidad de servidor (en particular, no se puede activar externamente la apertura automática de la base de datos)».

Eso tiene una consecuencia para la auditoría. KDBX registra marcas de tiempo de modificación e historial de entradas, que es un log de cambios en el archivo, no un log de accesos. Nada registra que alguien haya abierto la base de datos y leído una credencial, porque la lectura ocurre por completo en el cliente. Con una única clave maestra compartida, ni siquiera un registro de cambios permite saber de forma fiable qué persona lo hizo.

Passwork registra las acciones en el servidor y puede reenviarlas en CEF a syslog o al registro de eventos de Windows para un SIEM (registro de actividad, lista de eventos). Las concesiones, los cambios y las revocaciones se registran de forma individual y se atribuyen a una cuenta.

Confiar en un archivo que todos editan

El argumento más contundente contra el patrón de base de datos compartida procede de la propia documentación de KeePass.

KeePass admite marcadores de posición dentro de las entradas. {CMD:...} ejecuta una línea de comandos y las referencias a campos pueden extraer datos de otras entradas, así que una URL manipulada puede exfiltrar una credencial distinta. La página de seguridad ofrece el ejemplo: https://example.com/?u={REF:U@T:Facebook}&p={REF:P@T:Facebook}. La recomendación que sigue es inequívoca:

Al abrir una base de datos que ha sido creada/modificada por otra persona, debería comprobar con cuidado todos los datos que quiera utilizar. Si no confía plenamente en el creador de la base de datos, no abra ningún archivo adjunto a las entradas.

Lea eso pensando en un despliegue en una unidad compartida. Una base de datos de equipo está, por definición, creada y modificada por otras personas, y cualquiera con acceso de escritura puede añadir entradas en las que los demás harán clic. El modelo de confianza que KeePass documenta supone que una base de datos tiene un único propietario que responde por su contenido, que es precisamente lo que un archivo de equipo compartido no es.

Vulnerabilidades documentadas

CVE-2023-32784 (CVSS 7,5) permitía recuperar la contraseña maestra en claro a partir de un volcado de memoria en KeePass 2.x anterior a 2.54, incluso desde un archivo de intercambio o de hibernación y aun después de que el proceso hubiera terminado, con solo el primer carácter irrecuperable. La causa era un cuadro de texto personalizado que dejaba restos de cada carácter en la memoria de .NET. Se corrigió en 2.54 y el investigador reconoció una respuesta rápida.

CVE-2023-24055 (CVSS 5,5) está marcado como disputado por MITRE. Un atacante con acceso de escritura al archivo de configuración XML podía añadir un disparador de exportación y recolectar contraseñas en claro. La entrada del NVD recoge la posición del proveedor: «la base de datos de contraseñas no pretende ser segura frente a un atacante que tiene ese nivel de acceso al PC local». Esa posición es coherente, y la página de problemas de seguridad lo argumenta de forma general: quien puede escribir en el archivo de configuración normalmente puede reemplazar el ejecutable.

Para ser justos, KeePassXC ha pasado una auditoría externa, finalizada en enero de 2023, y afirma abiertamente que una auditoría «solo es válida para una ‹instantánea› del código».

Tabla comparativa

Migrar y a qué prestar atención durante la migración

Passwork importa XML de KeePass, además de JSON y CSV. No lee el binario KDBX cifrado, y el análisis se realiza en el cliente y no en el servidor, que es la única disposición coherente con que el servidor nunca vea texto en claro.

Vale la pena enunciar la consecuencia en lugar de pasarla por alto. Exportar de KeePass a XML produce un archivo sin cifrar que contiene todas las credenciales, y ese archivo permanece en disco todo el tiempo que dure la migración. Hágalo en un equipo que controle, en almacenamiento local y no en una carpeta sincronizada, y elimínelo con una herramienta que sobrescriba en lugar de desvincular. Es el único paso de una migración en el que una tarde descuidada deshace a la vez la criptografía de ambos productos.

Cuándo KeePass es la respuesta correcta

Si lo que está valorando concretamente es si KeePass basta para un equipo pequeño, Gestión de contraseñas y accesos para pymes: ¿Basta con KeePass? aborda esa pregunta directamente. Este artículo es más limitado y se centra solo en el eje de la arquitectura de cifrado, para equipos de cualquier tamaño.

Si es una sola persona, o dos que de todos modos comparten realmente todo, KeePass con una base de datos KDBX 4 y parámetros de Argon2 sensatos es una opción excelente, y es gratuita. La criptografía es sólida, el formato está documentado públicamente y, al no haber servidor, no hay ningún servicio que vulnerar.

El modelo deja de encajar cuando se necesitan respuestas que un archivo no puede dar. Quién tiene acceso a esto, exactamente. Qué se perdió exactamente cuando desapareció aquel portátil. Qué se rompe cuando esta persona se marche el viernes. Demuestre que el contratista nunca vio credenciales de producción.

Una prueba útil antes de decidir: cuente cuántas personas tienen hoy la clave maestra de la base de datos compartida y pregúntese qué tendría que rotar si cualquiera de ellas se marchara mañana. Si la respuesta es «todo», no es un problema de configuración que pueda ajustarse. Es el modelo de archivo funcionando como está diseñado. La referencia de la jerarquía de claves muestra cómo es el límite alternativo.

Un archivo tiene una clave para todos. Una bóveda tiene una clave por bóveda, cifrada para cada persona. Esa brecha no se reduce a medida que crece un equipo; se agrava. Si KeePass no es la única alternativa de su lista, la comparación de la arquitectura de cifrado de bóvedas de Passwork y Bitwarden recorre esos mismos tres momentos (guardados simultáneos, baja de empleados, auditoría) para un competidor nativo de la nube en lugar de un formato de archivo.

Haga la prueba de la clave maestra en su propio equipo y vea después la alternativa. Probar Passwork gratis.

Preguntas frecuentes

Gestión de contraseñas y accesos para pymes: ¿Basta con KeePass?

Todo administrador de TI que usa KeePass para un equipo cuenta la misma historia. Empieza con un único archivo .kdbx compartido en una unidad de red. Luego alguien no puede abrirlo porque un compañero lo tiene bloqueado. Luego un administrador de sistemas junior sobrescribe un cambio que otra persona hizo una hora antes. Luego un empleado se marcha y nadie sabe con certeza a qué contraseñas tenía acceso. KeePass es una herramienta realmente excelente, para una sola persona. En el momento en que la pone delante de un equipo, ya no gestiona contraseñas. Gestiona un s

PassworkAlex Muntyan

¿Qué es el cifrado de conocimiento cero? Cómo funciona en 5 minutos

El cifrado de conocimiento cero significa que el servidor nunca guarda las claves de descifrado, solo texto cifrado. Descubra cómo funciona la cadena de claves, de qué protege, de qué no y cómo verificar la afirmación de un proveedor.

PassworkPasswork Team

Passwork vs Bitwarden: Cómo difiere la arquitectura de cifrado de bóvedas

Passwork cifra cada bóveda con su propia clave. Bitwarden cifra toda una organización con una única clave compartida. Esta comparación desglosa qué implica eso para el radio de impacto, el aislamiento de equipos, la recuperación de cuentas y las respuestas de auditoría cuando se filtra una credencial.

PassworkPasswork Team

KeePass has better cryptographic primitives than plenty of password managers you can buy, and that's where this comparison starts. The KDBX 4 format supports a memory-hard key derivation function, authenticates its ciphertext before decrypting anything, and encrypts the whole database rather than just the password fields.

What KDBX does not have is key management for more than one person. There is one key, it belongs to a file rather than to a human, and it opens everything. Every multi-user property a team eventually needs — revoking one person's access, knowing who read a credential, bounding what a single leaked key exposes — has to be built outside the format, usually out of file system permissions and good intentions.

That is the real axis here, and it shows up in three moments: when two people save the shared database at once, when someone leaves the company, and when an auditor asks who opened a credential last quarter.

What KDBX 4 actually does

A KDBX 4 file is encrypted with AES-256 in CBC mode with PKCS#7 padding, or with ChaCha20, per the format specification. The key comes from hashing the master key components into a 256-bit value, running that through a key derivation function, then hashing the result with a fresh per-save seed. Three derivation functions ship without plugins: AES-KDF, Argon2d and Argon2id.

Integrity is where KDBX 4 pulled ahead of its predecessor. The file stores a SHA-256 hash of the header, so corruption is detectable without the master key, then an HMAC-SHA-256 of the header, and the payload is split into 1 MB blocks that each carry their own HMAC. The specification calls this "an Encrypt-then-MAC scheme," meaning authenticity is verified before anything is decrypted. KDBX 3.1 hashed the plaintext instead, and the author's note on the change is worth quoting for its restraint:

Although the Encrypt-then-MAC scheme (KDBX 4) in general is considered to be more secure than a MAC-then-Encrypt scheme (KDBX 3.1), we do not believe that KDBX 3.1 files were insecure.

Two caveats matter for a team. KDBX 3.1 is still a native format in KeePassXC, so "KeePass means Argon2 and HMAC" holds only once someone has actually migrated the database, which is a manual step in the encryption settings. And the Argon2 memory parameter is bounded by the weakest device that opens the file: KeePass suggests half the RAM of your smallest device, and warns that on iOS a large memory parameter can break AutoFill, recommending 64 MB or less there. A KDF is only as strong as the parameters your phone survives.

The scope of encryption is genuinely better than several hosted competitors: "KeePass encrypts the whole database, i.e. not only your passwords, but also your user names, URLs, notes, etc." A stolen KDBX leaks nothing about its contents, not even entry titles.

One thing looks like a second layer but is not. KDBX also applies Salsa20 or ChaCha20 to protected fields inside the XML, and the specification heads off the misreading directly:

We emphasize that the only purpose of the inner encryption is to support the process memory protection. The inner encryption has no effect on the cryptographic security of the KDBX file format.

Its key lives in the inner header and does not depend on the master key.

Where the key lives, and why that decides everything else

The KeePass master key is composite: a master password, a key file, and a key tied to the current Windows account through DPAPI, in any combination. All chosen components are required, and the Master Key documentation is blunt about it:

If you forget/lose any of the master key components (or forget the composition), all data stored in the database is lost. There is no backdoor and no universal key that can open your database.

Notice what those components share. A password is knowledge, a key file is possession, a DPAPI key is a machine account. None is an identity the database recognizes and can later distinguish from another. The key is a property of the file.

Passwork starts from the person, using the same zero-knowledge architecture principle (the server never handles anything but ciphertext) built around individual identity rather than a single file secret. Each user has their own RSA key pair generated client-side, with the private half encrypted under a key derived from their master password. A vault gets its own AES-256 key at creation, and every user with access holds a separate copy of that vault key, wrapped with their own public key (key hierarchy). The server only ever handles ciphertext (cryptography overview).

Sharing follows from that shape. Granting access re-wraps the vault key for the recipient's public key rather than re-encrypting data (sharing mechanics). Revoking it deletes that person's wrapped copy. Everyone else continues on the same vault key, and nothing is re-encrypted.

Where KeePass's cryptography is stronger for a single user

Key derivation is where it shows. Argon2 is memory-hard, which is exactly the property that makes GPU and ASIC cracking expensive, and KeePass explains why it prefers Argon2d in this setting: "a better protection against a really existing threat (password cracking using GPUs/ASICs is state of the art) is more important than a protection against certain side-channel attacks that may or may not become a problem on client devices in the future." Passwork derives the master key with PBKDF2 at 300,000 iterations over SHA-256 — a defensible, NIST-recognized setting, but not memory-hard, and against dedicated cracking hardware that distinction matters.

That doesn't change the conclusion for a team sharing credentials across more than one person: that comes down to key management, not cipher strength, and it's the question the rest of this comparison focuses on. For a single user with one laptop and one file, sharing nothing with anyone, that's the property that matters most against offline cracking attempts.

What happens when a team shares the file

Here the design goal shows. KeePass documentation on multiple users does not hedge:

All users use the same master password and/or key file to open the database. There are no per-group or per-entry access control lists (ACLs). In order to restrict write access to the database file (i.e. only a select set of users may change the stored data), use file system access rights.

Access control exists, but it lives in NTFS or your SMB share, not in the product and not in the cryptography. Read access is all-or-nothing by construction, because reading requires the one key that decrypts everything.

KeePass 2.x does detect conflicts. On Save it "first checks whether the file on disk has been modified since it was loaded," and if so offers to synchronize instead of overwriting. Merging happens at entry level, and the losing version of a conflicting entry is kept in that entry's history rather than discarded.

Conflicts resolve by comparing last modification timestamps, so the arbiter is each user's system clock rather than any notion of authority. The prompt fires only on Save: "the synchronize prompt is only triggered by the 'Save' command, not by the 'Save As' command. When executing the 'Save As' command and manually selecting a file, this file will always be overwritten." History entries survive a merge but "may be deleted by the automatic history maintenance," which is size-based. And KeePass 1.x has no synchronization at all, so a save there really does overwrite what changed underneath you.

KeePassXC differs in a way that matters if it is your client. It has a merge function in the GUI and as keepassxc-cli merge, comparing entries by UUID and modification time. But it has no built-in cloud synchronization on purpose, and the FAQ gives the reasoning: put the database in a shared cloud folder and let the sync service handle it, which "keeps the complexity of our code low." Defensible engineering, with a specific operational consequence. Dropbox, Nextcloud and OneDrive know nothing about KDBX, so simultaneous edits produce conflict copies of the file, and reconciling them is a manual merge somebody has to remember to run.

KeePass's own recommended pattern for shared files is a trigger: keep a local copy and synchronize with the master file, a scheme its documentation describes as preventing "data loss when database files are overwritten by other applications (e.g. cloud storage service software)." It works. It also means your access model now depends on a trigger stored in a configuration file that, as the Triggers page notes, is unencrypted and "applies to all users who use this KeePass installation."

Taking access back

Ask this first in any evaluation. A file-based model has no good answer to it, and the answer it does have tends to surprise people.

A departing employee had the master key. They may also have a copy of the KDBX on a laptop, in a backup, in a sync folder, or in a conflict copy nobody cleaned up. Changing the master key re-encrypts the database going forward and does nothing to copies that already exist. Those stay decryptable with the key they were saved under, indefinitely. Entry history compounds it: rotating a password inside the database keeps the previous value in that entry's history, so a stale copy carries both the old secret and the new one.

The only real revocation is rotating every credential that person could reach, which in a single-file model means all of them. The work scales with the size of your database rather than the scope of that person's job.

In Passwork the same event is bounded. Removing the user's access deletes their wrapped copy of the vault key, and remaining members continue on the unchanged key. Rotation after offboarding is still the right control for anything they actually read, and no product can un-leak a credential someone memorized. What differs is that the blast radius is a vault rather than everything, and revocation is one operation rather than a project.

Where Passwork's LDAP/Active Directory integration is configured, that operation doesn't have to be manual at all: disabling the account in AD revokes Passwork access automatically, in line with directory state, so offboarding in the directory is offboarding in the vault. And the security dashboard doesn't leave the aftermath to memory — it flags credentials still reachable by a user whose access was revoked as a compromise risk, turning what that person could reach into a visible worklist rather than something to reconstruct by hand.

Who read what

KeePass is a desktop application with no server component, a point its own notes make while dismissing a timing attack report: KeePass "does not feature any server capabilities (especially, no automatic database opening can be triggered externally)."

That has an audit consequence. KDBX records modification timestamps and entry history, which is a log of changes to the file, not a log of access. Nothing records that someone opened the database and read a credential, because the read happens entirely on the client. With one shared master key, even a change record cannot reliably tell you which human made it.

Passwork logs actions server-side and can forward them in CEF to syslog or the Windows event log for a SIEM (activity log, event list). Grants, changes and revocations are recorded individually and attributed to an account.

Trusting a file that everyone edits

The sharpest argument against the shared-database pattern comes from KeePass's own documentation.

KeePass supports placeholders inside entries. {CMD:...} runs a command line, and field references can pull data from other entries, so a crafted URL can exfiltrate a different credential. The Security page gives the example itself: https://example.com/?u={REF:U@T:Facebook}&p={REF:P@T:Facebook}. The guidance that follows is unambiguous:

When opening a database that has been created/modified by someone else, you should carefully check all data that you want to use. If you do not fully trust the creator of the database, do not open any files attached to entries.

Read that against a shared-drive deployment. A team database is by definition created and modified by other people, and everyone with write access can add entries the others will click. The trust model KeePass documents assumes a database has one owner who vouches for its contents, which is precisely what a shared team file is not.

Documented vulnerabilities

CVE-2023-32784 (CVSS 7.5) allowed recovering the cleartext master password from a memory dump in KeePass 2.x before 2.54, including from a swap or hibernation file and even after the process exited, with only the first character unrecoverable. The cause was a custom text box leaving per-character remnants in .NET memory. It was fixed in 2.54, and the researcher credited a fast response.

CVE-2023-24055 (CVSS 5.5) is tagged disputed by MITRE. An attacker with write access to the XML configuration file could add an export trigger and harvest cleartext passwords. The NVD entry records the vendor's position: "the password database is not intended to be secure against an attacker who has that level of access to the local PC." That position is consistent, and the Security Issues page argues it generally: someone who can write your configuration file can usually replace the executable instead.

For balance, KeePassXC has had an external audit, completed January 2023, and says openly that an audit "is valid only for a 'snapshot' of the code."

Comparison table

Migrating, and what to watch during it

Passwork imports KeePass XML, alongside JSON and CSV. It does not read the encrypted KDBX binary, and parsing happens in the client rather than on the server, which is the only arrangement consistent with the server never seeing plaintext.

The consequence deserves stating rather than glossing. Exporting from KeePass to XML produces an unencrypted file containing every credential, and it sits on disk for as long as the migration takes. Do it on a machine you control, on local storage rather than a synced folder, and delete it with a tool that overwrites rather than unlinks. It is the one step in a migration where a careless afternoon undoes both products' cryptography at once.

When KeePass is the right answer

If you are specifically weighing whether KeePass is enough for a small team, Password and access management for SMBs: Is KeePass enough? covers that question directly. This article stays narrower, on the encryption-architecture axis alone, for teams of any size.

If you are one person, or two people who genuinely share everything anyway, KeePass with a KDBX 4 database and sensible Argon2 parameters is an excellent choice, and it is free. The cryptography is strong, the format is publicly documented, and with no server there is no service to breach.

The model stops fitting when you need answers a file cannot give. Who has access to this, specifically. What exactly got lost when that laptop went missing. What breaks when this person leaves on Friday. Prove the contractor never saw production credentials.

A useful test before deciding: count how many people hold the master key to your shared database today, then ask what you would have to rotate if any one of them left tomorrow. If the answer is "everything," that is not a configuration problem you can tune away. It is the file model working as designed. The key hierarchy reference shows what the alternative boundary looks like.

A file has one key for everyone. A vault has one key per vault, wrapped per person. That gap does not shrink as a team grows; it compounds. If KeePass is not the only alternative on your shortlist, the comparison of Passwork's and Bitwarden's vault encryption architecture walks through the same three moments (concurrent saves, offboarding, audit) for a cloud-native competitor instead of a file format.

Run the master-key test on your own team, then see the alternative. Start a free trial of Passwork.

Frequently asked questions

Password and access management for SMBs: Is KeePass enough?

Every IT admin who runs KeePass for a team tells the same story. It starts with one shared .kdbx file on a network drive. Then someone can’t open it because a colleague has it locked. Then a junior sysadmin saves over a change someone else made an hour ago. Then an employee leaves, and nobody’s quite sure which passwords they had access to. KeePass is a genuinely excellent tool — for one person. The moment you put it in front of a team, you’re not managing passwords anymore. You’re managing a s

PassworkAlex Muntyan

What is zero-knowledge encryption? How it works in 5 minutes

Zero-knowledge encryption means the server never holds your decryption keys, only ciphertext. Learn how the key chain works, what it protects against, what it doesn’t, and how to verify a vendor’s claim.

PassworkPasswork Team

Passwork vs Bitwarden: How vault encryption architecture differs

Passwork encrypts every vault with its own key. Bitwarden encrypts an entire organization with one shared key. This comparison breaks down what that means for blast radius, team isolation, account recovery, and audit answers when a credential leaks.

PassworkPasswork Team

Nos próximos tempos, os computadores quânticos não conseguirão quebrar por força bruta uma palavra-passe de 16 caracteres devidamente protegida por hash. O algoritmo de Grover apenas reduz para metade o expoente de uma pesquisa de hash, e não o problema inteiro. O que um computador quântico suficientemente potente quebra é a troca de chaves RSA e de curva elíptica que transporta essa palavra-passe até ao servidor, e o NIST já fixou o prazo de 2030 para a sua substituição.

Dois problemas distintos são reduzidos a uma única manchete: «os computadores quânticos vão quebrar as palavras-passe». Este guia mantém-nos separados e propõe depois às equipas de TI e de segurança um fluxo de trabalho para verificar qual dos dois se aplica realmente ao respetivo conjunto de palavras-passe e quais as partes desse conjunto que podem esperar.

Os dois algoritmos quânticos que importam (Shor vs Grover)

Dois algoritmos quânticos são relevantes para a segurança das palavras-passe, e desempenham funções diferentes. O algoritmo de Shor proporciona uma aceleração exponencial contra a matemática subjacente ao RSA e à criptografia de curva elíptica, o que quebra a troca de chaves assim que existir um computador quântico suficientemente potente. O algoritmo de Grover proporciona apenas uma aceleração quadrática contra a pesquisa simétrica, reduzindo a resistência efetiva para metade, e não para zero.

A diferença entre exponencial e quadrático explica tudo. Uma aceleração quadrática contra um hash de 128 bits deixa ainda cerca de 2⁶⁴ operações por tentar, o que é computacionalmente enorme hoje, e uma função com uso intensivo de memória (memory-hard), como o Argon2id, multiplica esse custo ainda mais. Uma aceleração exponencial contra o RSA-2048 não deixa uma margem comparável.

Para uma análise mais aprofundada dos mecanismos dos esquemas pós-quânticos baseados em reticulados e de outros tipos, consulte o artigo explicativo sobre o que é a criptografia quântica; este guia centra-se no que muda especificamente para a infraestrutura de palavras-passe.

Porque é que o hash da palavra-passe não é o verdadeiro alvo

Uma palavra-passe com um hash adequado continua a ser dispendiosa de quebrar mesmo com o algoritmo de Grover, porque o custo da função de hash se aplica a cada tentativa individual que um computador quântico faz. O Argon2id e o bcrypt são memory-hard por conceção, pelo que reduzir o expoente para metade continua a obrigar o atacante a pagar um preço elevado por tentativa.

Considere uma palavra-passe aleatória de 16 caracteres, retirados do conjunto completo de 95 caracteres imprimíveis: cerca de 105 bits de entropia antes de o hash ser aplicado. A aceleração quadrática de Grover reduz esse expoente para cerca de metade, o que deixa o atacante com cerca de 2⁵² operações efetivas. Esse número continua fora do alcance de qualquer computador quântico em discussão séria atualmente, e o custo memory-hard do Argon2id multiplica ainda o preço de cada tentativa.

Nem todas as funções de hash oferecem esta proteção de forma igual. O PBKDF2 é limitado pela CPU e é mais barato de paralelizar em hardware personalizado. O Argon2id e o bcrypt obrigam o atacante a pagar em memória, além de tempo, o que pesa cada vez mais à medida que melhoram as técnicas de quebra com GPU e ASIC, quânticas ou não. O uso de salt continua a ser obrigatório, independentemente do algoritmo: impede ataques com rainbow tables pré-calculadas e obriga a que cada tentativa seja executada individualmente contra um único hash.

O guia sobre hash e salting de palavras-passe explica em maior detalhe o funcionamento de cada função, incluindo a razão pela qual um mínimo de 16 caracteres se tornou o patamar prático.

A camada que realmente quebra: Troca de chaves

O RSA-2048 e a troca de chaves ECDH são aqui o verdadeiro alvo. O algoritmo de Shor torna tratável a decomposição em fatores em que assenta o RSA e o cálculo dos logaritmos discretos em que assenta a ECC, o que quebra handshakes TLS, sessões SSH, túneis VPN e qualquer encapsulamento de chaves privadas baseado nas mesmas primitivas.

A criptografia de chave pública transporta esse risco para a infraestrutura quotidiana em mais locais do que a maioria das equipas contabiliza:

• Handshakes TLS 1.3: troca de chaves RSA ou ECDHE, certificados ECDSA
• Troca de chaves SSH de host e de utilizador
• Negociação de túneis VPN
• Encapsulamento de chaves privadas na hierarquia de chaves de um gestor de palavras-passe
• Certificados de assinatura de código e de documentos

O fundamento matemático deste risco não é hipotético. A Google Quantum AI publicou em maio de 2025 um preprint que demonstra que o RSA de 2048 bits poderia, em teoria, ser decomposto em fatores por um computador quântico com correção de erros suficientemente grande. A máquina ainda não existe. A matemática que o quebraria já existe.

Um gestor de palavras-passe encontra-se nesta mesma lista. Partilhar um cofre com um novo membro da equipa, sincronizar um registo entre dispositivos ou desencapsular uma chave privada no início de sessão dependem, em algum ponto da cadeia, de uma operação assimétrica. A auditoria da pilha criptográfica do gestor de palavras-passe deve constar do mesmo inventário que os endpoints TLS e os concentradores VPN.

Harvest now, decrypt later: A ameaça que já existe hoje

O harvest now, decrypt later (recolher agora, decifrar depois) descreve um atacante que grava hoje tráfego cifrado e o decifra quando existir um computador quântico capaz. Reformula o argumento de que «a computação quântica está a dez anos de distância» como «a recolha já começou», o que é relevante para qualquer dado cuja confidencialidade tenha de se manter durante uma década ou mais.

O 2026 Quantum & AI Threat Report da Thales inquiriu 3120 profissionais de segurança e de TI em 20 países e concluiu que o harvest-now-decrypt-later é a sua principal preocupação quântica, citada por 61 % dos inquiridos, à frente da descontinuação de algoritmos ou dos prazos de conformidade. Os adversários com paciência para esperar anos por um retorno, tipicamente atores estatais, são quem realiza esta recolha atualmente.

A exposição concentra-se nos dados que têm de permanecer confidenciais durante anos: registos médicos, documentos jurídicos, propriedade intelectual, comunicações governamentais. Uma chave de sessão TLS descartada no momento em que a ligação é fechada é um alvo pouco interessante. Um arquivo de 2024 protegido por encapsulamento RSA e ainda guardado numa banda magnética de cópia de segurança em 2034 é exatamente o alvo desta ameaça, tal como uma exportação cifrada de um cofre guardada numa cópia de segurança desativada que ninguém se lembrou de eliminar.

O que o NIST realmente decidiu e os prazos vinculativos

O NIST finalizou as suas três primeiras normas de criptografia pós-quântica em agosto de 2024: a FIPS 203 (ML-KEM) para troca de chaves, e a FIPS 204 (ML-DSA) e a FIPS 205 (SLH-DSA) para assinaturas digitais. O documento NIST IR 8547 definiu depois o calendário de conformidade, descontinuando o RSA, o ECDSA e o EdDSA após 2030 e proibindo-os após 2035.

A criptografia simétrica com segurança de 128 bits ou superior não é afetada por nada disto. O AES-256 não exige qualquer alteração de algoritmo. Os prazos visam especificamente a camada assimétrica: RSA, ECDSA e EdDSA, substituídos por ML-KEM e ML-DSA. A Commercial National Security Algorithm Suite 2.0 reflete este calendário para os sistemas de segurança nacional dos EUA, um sinal da seriedade com que as equipas de aquisição devem encarar o assunto.

O NIST IR 8547 apresenta a migração pós-quântica como um esforço de engenharia plurianual, da ordem de uma década para integrar em produtos e infraestruturas, o que constitui o verdadeiro argumento para iniciar um inventário agora em vez de esperar até 2029. O roteiro quântico público da IBM fixa como objetivo um sistema com mais de 100 000 qubits até 2033. É o objetivo declarado pelo próprio fornecedor, e não uma projeção independente, mas dá uma data aproximada para o momento em que «suficientemente grande» deixa de ser teórico.

Integrar desde já a agilidade criptográfica (crypto agility) nas aquisições, isto é, a capacidade de substituir um algoritmo sem reestruturar um produto, é o que transforma isto numa migração planeada e não numa correria.

A Auditoria de Exposição Quântica em 3 Camadas

A execução desta auditoria demora uma tarde, e não um projeto de consultoria. Classifique o conjunto de palavras-passe em três camadas, e cada uma recebe o seu próprio veredicto: seguro, vigiar ou agir já.

A camada 1 é aquela com que as equipas mais se preocupam e com que menos precisam de se preocupar. Se os hashes das palavras-passe de início de sessão e das palavras-passe mestras do gestor de palavras-passe já utilizarem Argon2id, PBKDF2 ou bcrypt com um fator de trabalho razoável, o algoritmo de Grover não altera o cálculo de risco. A única lacuna real que vale a pena resolver: um sistema legado que ainda use MD5 ou SHA-1 sem salt já estava comprometido antes de a computação quântica entrar na conversa.

A camada 2 é onde um administrador costuma encontrar a lacuna real: um concentrador VPN ainda preso ao RSA-2048, uma infraestrutura de chave pública (PKI) interna que emite certificados ECDSA sem plano de renovação, uma API legada que nunca passou do TLS 1.2. Inventarie todos os pontos em que o RSA, o ECDH ou o ECDSA realizam uma troca de chaves e comece pelo que protege o tráfego de maior longevidade.

A camada 3 diz respeito ao que já foi recolhido, e não ao que será cifrado amanhã. Importa perguntar que dados a organização protege hoje que ainda precisarão de confidencialidade em 2035: retenções por motivos legais, tabelas de capitalização, código-fonte, tudo o que esteja abrangido por um acordo de confidencialidade plurianual. Depois, há que verificar se essa confidencialidade depende de uma troca de chaves assimétrica realizada há anos.

Execute a auditoria uma vez e integre-a depois na cadência que a equipa já utiliza para o inventário criptográfico. Anualmente é razoável. Com maior frequência, se este ano estiver prevista a emissão de uma nova PKI ou a renegociação de um contrato de VPN.

Como ler a documentação criptográfica de um gestor de palavras-passe

A documentação criptográfica de um gestor de palavras-passe deve indicar exatamente o que protege o cofre em cada camada. Uma referência vaga a «cifragem de nível militar» não conta. Procure algoritmos identificados pelo nome, tamanhos de chave declarados, uma função de derivação de chaves identificada e uma posição pública sobre a migração pós-quântica.

O que publica um fornecedor atento à ameaça quântica:

• A cifra simétrica exata e o tamanho de chave que protegem os dados do cofre (AES-128 e AES-256 não oferecem a mesma margem, pelo que «AES» por si só não basta)
• O algoritmo assimétrico exato utilizado para a troca de chaves e o encapsulamento de chaves privadas
• A função de derivação de chaves e o número de iterações que transformam uma palavra-passe mestra numa chave de cifragem
• Se a cifragem ocorre no lado do cliente, no modelo de zero-knowledge, ou apenas em repouso no servidor

A documentação do próprio Passwork é um exemplo razoável do aspeto que essa transparência tem na prática. A sua cifragem do lado do cliente aplica AES-256 aos dados de cofres e de registos, com uma camada AES-256 separada a proteger a base de dados em repouso. A partir de uma palavra-passe mestra, o PBKDF2 (HMAC-SHA-256) deriva uma chave mestra de 512 bits, que desencapsula uma chave privada RSA-2048 que, por sua vez, desencapsula as chaves de cada cofre e de cada registo, uma hierarquia documentada na visão geral da criptografia.

Se esta pilha for submetida à Auditoria de 3 Camadas, a resposta honesta é simples. A camada de dados AES-256 mantém-se resistente a ataques quânticos com os tamanhos de chave atuais; a camada de troca de chaves RSA-2048 é o componente a vigiar à medida que as normas pós-quânticas amadurecem em todo o setor. É a mesma resposta que qualquer fornecedor que encapsule chaves com RSA deve dar hoje: uma camada AES-256 documentada que não precisa de mudar e uma camada assimétrica com um caminho de migração reconhecido, e não a afirmação de que tudo já está à prova de ataques quânticos. O artigo explicativo sobre o AES-256 aborda a razão pela qual a margem do tamanho da chave importa por si só.

Se a equipa estiver a iniciar o seu próprio inventário criptográfico, o Passwork publica exatamente este tipo de pilha AES-256/RSA-2048 documentada, com registos de auditoria exportáveis para alimentar diretamente a revisão da camada 2. Iniciar um teste gratuito

O que fazer hoje (e o que pode esperar)

Comece pelo que protege hoje a troca de chaves TLS, SSH e VPN, uma vez que é a camada com um prazo real, em 2030. A adoção de passkeys, os testes de troca de chaves híbrida e um inventário criptográfico documentado podem decorrer em paralelo. Renovar as chaves de implementações AES-256 ou preocupar-se com a resistência dos hashes de palavras-passe pode esperar.

Fazer agora:

1. Inventariar todos os pontos em que o RSA, o ECDH ou o ECDSA realizam uma troca de chaves: endpoints TLS, hosts SSH, concentradores VPN, PKI interna.
2. Confirmar que o gestor de palavras-passe e o fornecedor de identidade publicam a sua pilha criptográfica real, em vez de uma referência vaga a «cifragem de nível bancário». Se um fornecedor não indicar, a pedido, os seus algoritmos e tamanhos de chave, essa é a resposta.
3. Ativar a autenticação multifator (MFA) em todos os sistemas onde ainda não seja obrigatória. Não toca diretamente na questão quântica, mas reduz a exposição enquanto a migração decorre.

Planear este ano:

4. Incluir a troca de chaves híbrida (clássica mais ML-KEM) nas conversas sobre o roteiro com os fornecedores, sobretudo para tudo o que enfrente um prazo em 2030.
5. Dar prioridade à adoção de passkeys na autenticação dirigida aos utilizadores. A agilidade algorítmica do FIDO2 significa que o caminho de migração já existe, embora as passkeys atuais ainda utilizem ECDSA, e a própria adoção reduz a parte do conjunto de palavras-passe que ainda depende de um hash de palavra-passe.
6. Eliminar os endpoints TLS 1.2 que ainda subsistam. A atualização para TLS 1.3 é um pré-requisito para a troca de chaves pós-quântica, e não um projeto separado.

Vigiar:

7. Os roteiros de hardware quântico da IBM e da Google. Um salto para além dos marcos do calendário do NIST acima indicado anteciparia os prazos, em vez de simplesmente os confirmar.
8. As orientações do NIST sobre modos híbridos e puramente pós-quânticos, à medida que as implementações das FIPS 203, 204 e 205 amadurecem nas bibliotecas TLS e SSH de uso generalizado.

Nada disto exige a substituição de um gestor de palavras-passe existente. Se este já publicar uma pilha AES-256/RSA-2048 como a descrita acima, a plataforma está a fazer a sua parte; o trabalho de inventário acima descrito cabe à organização.

Conclusão

Os computadores quânticos não vêm atrás do hash da palavra-passe. Vêm atrás da troca de chaves RSA e ECC que a transporta, e o NIST já marcou datas no calendário: 2030 para descontinuar, 2035 para proibir. A Auditoria de Exposição Quântica em 3 Camadas transforma esse risco abstrato em três verificações concretas que uma equipa pode executar neste trimestre, uma das quais provavelmente pode ficar concluída ainda esta tarde.

Comece pela camada 2. Reúna a lista de todos os locais onde o RSA, o ECDH ou o ECDSA tratam de um handshake no ambiente e saberá, num dia, que fornecedores exigem uma conversa sobre migração e quais já a iniciaram.

Se a equipa estiver a elaborar esse inventário, o Passwork disponibiliza um cofre AES-256/RSA-2048 documentado, com registos de auditoria exportáveis para alimentar diretamente esse trabalho. Iniciar um teste gratuito

Perguntas frequentes

O que é a cifragem zero-knowledge? Como funciona em 5 minutos

A cifragem zero-knowledge significa que o servidor nunca detém as chaves de decifragem, apenas o texto cifrado. Saiba como funciona a cadeia de chaves, contra o que protege, contra o que não protege e como verificar a afirmação de um fornecedor.

PassworkPasswork Team

Gestão de acessos para PME: A primeira camada de cibersegurança

A gestão de acessos deve estar no topo da lista de verificação de cibersegurança das PME. Saiba como configurar identidade, autenticação, autorização e revogação como um sistema que resiste ao dia a dia.

PassworkPasswork Team

O que é a PKI? Infraestrutura de chave pública explicada para 2026

Até 2029, os certificados passarão a expirar a cada 47 dias. Eis o que é realmente a PKI, como funciona e as credenciais humanas que mantêm a CA em funcionamento, e que a própria PKI não protege.

PassworkPasswork Team

Quantencomputer werden ein korrekt gehashtes 16-stelliges Passwort auf absehbare Zeit nicht per Brute Force knacken. Grovers Algorithmus halbiert lediglich den Exponenten einer Hash-Suche, nicht das ganze Problem. Was ein ausreichend großer Quantencomputer tatsächlich bricht, ist der RSA- und Elliptic-Curve-Schlüsselaustausch, der dieses Passwort zu Ihrem Server transportiert – und für dessen Ersatz hat NIST bereits eine Frist bis 2030 gesetzt.

Zwei getrennte Probleme werden zu einer Schlagzeile verdichtet: „Quantencomputer werden Ihre Passwörter brechen.“ Dieser Leitfaden hält sie auseinander und gibt IT- und Sicherheitsteams anschließend einen Arbeitsablauf an die Hand, mit dem sie prüfen können, welches der beiden tatsächlich auf ihren eigenen Passwortbestand zutrifft und welche Teile dieses Bestands warten können.

Die zwei relevanten Quantenalgorithmen (Shor vs. Grover)

Für die Passwortsicherheit sind zwei Quantenalgorithmen relevant, und sie leisten Unterschiedliches. Shors Algorithmus liefert eine exponentielle Beschleunigung gegen die Mathematik hinter RSA und Elliptic-Curve-Kryptografie und bricht damit den Schlüsselaustausch, sobald ein ausreichend großer Quantencomputer existiert. Grovers Algorithmus liefert lediglich eine quadratische Beschleunigung gegen symmetrische Suche und halbiert die effektive Stärke, statt sie auf null zu senken.

Der Unterschied zwischen exponentiell und quadratisch ist die ganze Geschichte. Eine quadratische Beschleunigung gegen einen 128-Bit-Hash lässt immer noch rund 2⁶⁴ Operationen übrig, was heute rechnerisch enorm ist, und eine Memory-hard-Funktion wie Argon2id vervielfacht diese Kosten weiter. Eine exponentielle Beschleunigung gegen RSA-2048 lässt keinen vergleichbaren Spielraum.

Die tiefere Mechanik gitterbasierter und anderer Post-Quanten-Verfahren erläutert unser Beitrag dazu, was Quantenkryptografie ist; dieser Leitfaden bleibt darauf fokussiert, was sich speziell für die Passwortinfrastruktur ändert.

Warum Ihr Passwort-Hash nicht das eigentliche Ziel ist

Ein korrekt gehashtes Passwort bleibt auch unter Grovers Algorithmus teuer zu knacken, weil die Kosten der Hash-Funktion bei jedem einzelnen Rateversuch eines Quantencomputers anfallen. Argon2id und bcrypt sind konstruktionsbedingt memory-hard, sodass eine Halbierung des Exponenten einem Angreifer immer noch einen hohen Preis pro Versuch abverlangt.

Nehmen Sie ein 16-stelliges Zufallspasswort aus dem vollständigen Zeichensatz von 95 druckbaren Zeichen: rund 105 Bit Entropie, bevor das Hashing greift. Grovers quadratische Beschleunigung halbiert diesen Exponenten in etwa, womit ein Angreifer bei rund 2⁵² effektiven Operationen landet. Diese Zahl bleibt für jeden Quantencomputer, der heute ernsthaft diskutiert wird, unerreichbar, und der Memory-hard-Aufwand von Argon2id vervielfacht den Preis jedes Rateversuchs obendrein.

Nicht jede Hash-Funktion bietet diesen Schutz im gleichen Maß. PBKDF2 ist CPU-gebunden und lässt sich auf spezialisierter Hardware günstiger parallelisieren. Argon2id und bcrypt zwingen einen Angreifer, nicht nur mit Zeit, sondern auch mit Speicher zu bezahlen, was mit besserem GPU- und ASIC-Cracking immer stärker ins Gewicht fällt, quantenbasiert oder nicht. Salting bleibt unabhängig vom Algorithmus verpflichtend: Es verhindert vorberechnete Rainbow-Table-Angriffe und zwingt jeden Rateversuch, einzeln gegen einen einzelnen Hash zu laufen.

Unser Leitfaden zu Passwort-Hashing und Salting behandelt die Mechanik jeder Funktion ausführlicher, einschließlich der Frage, warum ein Minimum von 16 Zeichen zur praktischen Untergrenze geworden ist.

Die Schicht, die wirklich bricht: Schlüsselaustausch

RSA-2048 und der ECDH-Schlüsselaustausch sind hier das eigentliche Ziel. Shors Algorithmus macht die Faktorisierung der Mathematik hinter RSA und die Berechnung der diskreten Logarithmen hinter ECC praktisch lösbar, was TLS-Handshakes, SSH-Sitzungen, VPN-Tunnel und jedes Wrapping privater Schlüssel bricht, das auf denselben Primitiven aufbaut.

Public-Key-Kryptografie trägt dieses Risiko an mehr Stellen in die alltägliche Infrastruktur, als die meisten Teams erfassen:

• TLS-1.3-Handshakes: RSA- oder ECDHE-Schlüsselaustausch, ECDSA-Zertifikate
• SSH-Schlüsselaustausch für Hosts und Benutzer
• Aushandlung von VPN-Tunneln
• Wrapping privater Schlüssel innerhalb der Schlüsselhierarchie eines Passwortmanagers
• Zertifikate für Code- und Dokumentsignierung

Die Mathematik hinter diesem Risiko ist nicht hypothetisch. Google Quantum AI hat im Mai 2025 ein Preprint veröffentlicht, das zeigt, dass RSA mit 2048 Bit theoretisch von einem ausreichend großen fehlerkorrigierten Quantencomputer faktorisiert werden könnte. Die Maschine existiert noch nicht. Die Mathematik, die es brechen würde, existiert bereits.

Ein Passwortmanager steht auf derselben Liste. Einen Tresor mit einem neuen Teammitglied teilen, einen Datensatz zwischen Geräten synchronisieren oder beim Login einen privaten Schlüssel entpacken – alles hängt irgendwo in der Kette von einer asymmetrischen Operation ab. Das Audit des Krypto-Stacks Ihres Passwortmanagers gehört in dasselbe Inventar wie Ihre TLS-Endpunkte und VPN-Konzentratoren.

Harvest now, decrypt later: Die Bedrohung, die heute existiert

Harvest now, decrypt later beschreibt einen Angreifer, der heute verschlüsselten Datenverkehr aufzeichnet und ihn entschlüsselt, sobald ein leistungsfähiger Quantencomputer existiert. Damit wird aus „Quanten sind zehn Jahre entfernt“ ein „die Sammlung hat längst begonnen“, was für alle Daten zählt, deren Vertraulichkeit ein Jahrzehnt oder länger überdauern muss.

Thales hat in 20 Ländern 3.120 Sicherheits- und IT-Experten für den Quantum & AI Threat Report 2026 befragt und dabei festgestellt, dass Harvest-now-decrypt-later deren größte quantenbezogene Sorge ist, genannt von 61 % der Befragten und damit vor Algorithmus-Abkündigung oder Compliance-Fristen. Angreifer mit der Geduld, jahrelang auf einen Ertrag zu warten, typischerweise staatliche Akteure, sind diejenigen, die diese Sammlung heute betreiben.

Die Exposition konzentriert sich auf Daten, die jahrelang vertraulich bleiben müssen: Krankenakten, Gerichtsakten, geistiges Eigentum, Behördenkommunikation. Ein TLS-Sitzungsschlüssel, der mit dem Schließen der Verbindung verworfen wird, ist ein schlechtes Ziel. Ein RSA-umschlossenes Archiv aus dem Jahr 2024, das 2034 noch auf einem Backup-Band liegt, ist genau das, worauf diese Bedrohung zielt – und ebenso ein verschlüsselter Tresor-Export in einem außer Betrieb genommenen Backup, an dessen Löschung niemand gedacht hat.

Was NIST tatsächlich entschieden hat und welche Fristen gelten

NIST hat im August 2024 seine ersten drei Standards für Post-Quanten-Kryptografie finalisiert: FIPS 203 (ML-KEM) für den Schlüsselaustausch, FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) für digitale Signaturen. NIST IR 8547 hat anschließend die Compliance-Uhr gestellt: RSA, ECDSA und EdDSA werden nach 2030 abgekündigt und nach 2035 nicht mehr zugelassen.

Symmetrische Kryptografie mit 128 Bit Sicherheit oder mehr ist davon nicht betroffen. AES-256 braucht keinen Algorithmuswechsel. Die Fristen zielen speziell auf die asymmetrische Schicht: RSA, ECDSA und EdDSA, ersetzt durch ML-KEM und ML-DSA. Die Commercial National Security Algorithm Suite 2.0 spiegelt diesen Zeitplan für US-amerikanische Systeme der nationalen Sicherheit, ein Signal dafür, wie ernst Beschaffungsteams ihn nehmen sollen.

NIST IR 8547 stellt die Post-Quanten-Migration als mehrjährige Entwicklungsaufgabe dar, in der Größenordnung eines Jahrzehnts, um sie über Produkte und Infrastruktur hinweg zu integrieren – das ist das eigentliche Argument dafür, jetzt mit einem Inventar zu beginnen und nicht bis 2029 zu warten. IBM verfolgt mit seiner öffentlichen Quanten-Roadmap bis 2033 ein System mit mehr als 100.000 Qubits. Das ist das erklärte Ziel des Anbieters selbst, keine unabhängige Prognose, aber es setzt ein ungefähres Datum dafür, ab wann „groß genug“ nicht mehr theoretisch ist.

Kryptoagilität jetzt in die Beschaffung einzubauen, also die Fähigkeit, einen Algorithmus zu tauschen, ohne die Architektur eines Produkts neu aufzusetzen, macht daraus statt einer Hauruckaktion eine planmäßige Migration.

Das 3-Schichten-Audit der Quantenexposition

Dieses Audit dauert einen Nachmittag, kein Beratungsprojekt. Sortieren Sie Ihren Passwortbestand in drei Schichten, und jede erhält ihre eigene Bewertung: sicher, beobachten oder jetzt handeln.

Schicht 1 ist die Schicht, um die Teams sich am meisten sorgen und um die sie sich am wenigsten sorgen müssen. Wenn Ihre Hashes für Login und Masterpasswort des Passwortmanagers bereits Argon2id, PBKDF2 oder bcrypt mit einem angemessenen Kostenfaktor verwenden, ändert Grovers Algorithmus Ihre Risikorechnung nicht. Die eine echte Lücke, die es zu verfolgen lohnt: Ein Altsystem, auf dem noch MD5 oder ungesalzenes SHA-1 läuft, war schon gebrochen, bevor Quanten in die Diskussion kamen.

Schicht 2 ist die Stelle, an der ein Administrator üblicherweise die tatsächliche Lücke findet: ein VPN-Konzentrator, der noch auf RSA-2048 festgelegt ist, eine interne PKI, die ECDSA-Zertifikate ohne Erneuerungsplan ausstellt, eine alte API, die nie über TLS 1.2 hinausgekommen ist. Inventarisieren Sie jede Stelle, an der RSA, ECDH oder ECDSA einen Schlüsselaustausch durchführt, und beginnen Sie mit dem, was Ihren langlebigsten Datenverkehr schützt.

Schicht 3 dreht sich um das, was bereits gesammelt wurde, nicht um das, was morgen verschlüsselt wird. Fragen Sie, welche Daten Ihre Organisation heute schützt, die 2035 noch vertraulich sein müssen: Legal Holds, Cap-Tables, Quellcode, alles unter einem mehrjährigen NDA. Prüfen Sie dann, ob diese Vertraulichkeit von einem asymmetrischen Schlüsselaustausch abhängt, der vor Jahren durchgeführt wurde.

Führen Sie das Audit einmal durch und binden Sie es dann in den Rhythmus ein, den Ihr Team ohnehin für ein Krypto-Inventar nutzt. Jährlich ist angemessen. Häufiger, wenn Sie in diesem Jahr eine neue PKI ausrollen oder einen VPN-Vertrag neu verhandeln.

Die Krypto-Dokumentation eines Passwortmanagers lesen

Die Krypto-Dokumentation eines Passwortmanagers sollte genau benennen, was Ihren Tresor auf jeder Schicht schützt. Eine vage Behauptung von „Verschlüsselung auf Militärniveau“ zählt nicht. Achten Sie auf benannte Algorithmen, angegebene Schlüssellängen, eine benannte Schlüsselableitungsfunktion und eine öffentliche Position zur Post-Quanten-Migration.

Was ein quantenbewusster Anbieter veröffentlicht:

• Die genaue symmetrische Chiffre und Schlüssellänge, die Tresordaten schützt (AES-128 und AES-256 bieten nicht denselben Spielraum, „AES“ allein genügt also nicht)
• Den genauen asymmetrischen Algorithmus für Schlüsselaustausch und das Wrapping privater Schlüssel
• Die Schlüsselableitungsfunktion und die Iterationszahl, die aus einem Masterpasswort einen Verschlüsselungsschlüssel machen
• Ob die Verschlüsselung clientseitig erfolgt, nach dem Zero-Knowledge-Modell, oder nur im Ruhezustand auf dem Server

Passwork liefert mit seiner eigenen Dokumentation ein vernünftiges Beispiel dafür, wie diese Transparenz in der Praxis aussieht. Die clientseitige Verschlüsselung wendet AES-256 auf Tresor- und Datensatzdaten an, mit einer separaten AES-256-Schicht, die die Datenbank im Ruhezustand schützt. Aus einem Masterpasswort wird über PBKDF2 (HMAC-SHA-256) ein 512-Bit-Masterschlüssel abgeleitet, der einen privaten RSA-2048-Schlüssel entpackt, und dieser entpackt wiederum die Schlüssel pro Tresor und pro Datensatz – diese Hierarchie dokumentiert die Kryptografie-Übersicht.

Lässt man diesen Stack durch das 3-Schichten-Audit laufen, ist die ehrliche Antwort eindeutig. Die AES-256-Datenschicht bleibt bei den aktuellen Schlüssellängen quantenresistent; die RSA-2048-Schicht für den Schlüsselaustausch ist die Komponente, die zu beobachten ist, während die Post-Quanten-Standards branchenweit reifen. Das ist dieselbe Antwort, die Ihnen heute jeder Anbieter geben sollte, der Schlüssel mit RSA umschließt: eine dokumentierte AES-256-Schicht, die sich nicht ändern muss, und eine asymmetrische Schicht mit einem eingeräumten Migrationspfad, nicht die Behauptung, alles sei bereits quantensicher. Unser Beitrag zu AES-256 erklärt, warum der Spielraum bei der Schlüssellänge für sich genommen zählt.

Wenn Ihr Team sein eigenes Krypto-Inventar beginnt, liefert Passwork genau einen solchen dokumentierten AES-256/RSA-2048-Stack, mit exportierbaren Audit-Logs, die direkt in Ihre Prüfung von Schicht 2 einfließen. Kostenlose Testversion starten

Was heute zu tun ist (und was warten kann)

Beginnen Sie mit dem, was heute den Schlüsselaustausch von TLS, SSH und VPN schützt, denn das ist die Schicht mit einer tatsächlichen Frist bis 2030. Passkey-Rollout, Tests für hybriden Schlüsselaustausch und ein dokumentiertes Krypto-Inventar können parallel laufen. Das Neuverschlüsseln von AES-256-Installationen oder die Sorge um die Stärke von Passwort-Hashes kann warten.

Jetzt erledigen:

1. Inventarisieren Sie jede Stelle, an der RSA, ECDH oder ECDSA einen Schlüsselaustausch durchführt: TLS-Endpunkte, SSH-Hosts, VPN-Konzentratoren, interne PKI.
2. Vergewissern Sie sich, dass Ihr Passwortmanager und Ihr Identity-Provider ihren tatsächlichen Krypto-Stack veröffentlichen statt einer vagen Behauptung von „Verschlüsselung auf Bankenniveau“. Wenn ein Anbieter seine Algorithmen und Schlüssellängen auf Anfrage nicht benennt, behandeln Sie das als die Antwort.
3. Aktivieren Sie MFA überall dort, wo sie nicht bereits verpflichtend ist. Das berührt die Quantenfrage nicht direkt, schließt aber Lücken, während die Migration läuft.

In diesem Jahr planen:

4. Bringen Sie hybriden Schlüsselaustausch (klassisch plus ML-KEM) in die Roadmap-Gespräche mit Ihren Anbietern, insbesondere für alles, was einer Frist bis 2030 unterliegt.
5. Priorisieren Sie den Passkey-Rollout für die Authentifizierung von Endbenutzern. Die Algorithmusagilität von FIDO2 bedeutet, dass der Migrationspfad bereits existiert, auch wenn heutige Passkeys noch ECDSA verwenden, und der Rollout selbst verringert, wie viel Ihres Bestands überhaupt noch von einem Passwort-Hash abhängt.
6. Beseitigen Sie verbliebene TLS-1.2-Endpunkte. Das Update auf TLS 1.3 ist eine Voraussetzung für Post-Quanten-Schlüsselaustausch, kein separates Projekt.

Beobachten:

7. Die Quanten-Hardware-Roadmaps von IBM und Google. Ein Sprung über die Meilensteine im NIST-Zeitplan oben hinaus würde Fristen nach vorn verschieben, statt sie lediglich zu bestätigen.
8. NIST-Leitlinien zu hybriden und reinen Post-Quanten-Modi, während Implementierungen von FIPS 203, 204 und 205 in gängigen TLS- und SSH-Bibliotheken reifen.

Nichts davon erfordert den Austausch eines bestehenden Passwortmanagers. Wenn er bereits einen AES-256/RSA-2048-Stack wie den oben beschriebenen veröffentlicht, tut die Plattform ihren Teil; die Inventararbeit oben ist Ihre.

Fazit

Quantencomputer kommen nicht für Ihren Passwort-Hash. Sie kommen für den RSA- und ECC-Schlüsselaustausch, der ihn transportiert, und NIST hat die Daten bereits in den Kalender geschrieben: 2030 für die Abkündigung, 2035 für das Verbot. Das 3-Schichten-Audit der Quantenexposition verwandelt dieses abstrakte Risiko in drei konkrete Prüfungen, die ein Team in diesem Quartal durchführen kann – eine davon lässt sich wahrscheinlich noch an diesem Nachmittag abschließen.

Beginnen Sie mit Schicht 2. Ziehen Sie die Liste aller Stellen, an denen RSA, ECDH oder ECDSA in Ihrer Umgebung einen Handshake abwickeln, und Sie wissen innerhalb eines Tages, mit welchen Anbietern ein Migrationsgespräch nötig ist und welche eines bereits begonnen haben.

Wenn Ihr Team dieses Inventar aufbaut, gibt Passwork Ihnen einen dokumentierten AES-256/RSA-2048-Tresor mit exportierbaren Audit-Logs, die direkt einfließen. Kostenlose Testversion starten

Häufig gestellte Fragen

Was ist Zero-Knowledge-Verschlüsselung? Funktionsweise in 5 Minuten

Zero-Knowledge-Verschlüsselung bedeutet, dass der Server nie Ihre Entschlüsselungsschlüssel hält, nur Chiffrat. Erfahren Sie, wie die Schlüsselkette funktioniert, wovor sie schützt, wovor nicht und wie sich die Behauptung eines Anbieters überprüfen lässt.

PassworkPasswork Team

Zugriffsverwaltung für KMU: Die erste Cybersicherheitsschicht

Zugriffsverwaltung gehört ganz oben auf die Cybersicherheits-Checkliste eines KMU. Erfahren Sie, wie sich Identität, Authentifizierung, Autorisierung und Entzug als System einrichten lassen, das im Alltag hält.

PassworkPasswork Team

Was ist PKI? Public-Key-Infrastruktur erklärt für 2026

Zertifikate laufen bis 2029 alle 47 Tage ab. Hier steht, was PKI tatsächlich ist, wie sie funktioniert und welche menschlichen Zugangsdaten Ihre CA am Laufen halten, die PKI selbst nicht schützt.

PassworkPasswork Team

La computación cuántica no va a romper por fuerza bruta una contraseña de 16 caracteres bien protegida con hash en un futuro próximo. El algoritmo de Grover solo reduce a la mitad el exponente de una búsqueda de hash, no el problema completo. Lo que sí rompe una máquina cuántica lo bastante grande es el intercambio de claves RSA y de curva elíptica que transporta esa contraseña hasta el servidor, y NIST ya ha fijado 2030 como plazo para sustituirlo.

Dos problemas distintos se condensan en un mismo titular: «la computación cuántica romperá sus contraseñas». Esta guía los mantiene separados y después ofrece a los equipos de TI y de seguridad un método para comprobar cuál de ellos se aplica realmente a su propia infraestructura de contraseñas y qué partes de esa infraestructura pueden esperar.

Los dos algoritmos cuánticos que importan (Shor frente a Grover)

Dos algoritmos cuánticos importan para la seguridad de las contraseñas, y hacen trabajos distintos. El algoritmo de Shor ofrece una aceleración exponencial frente a las matemáticas que sustentan RSA y la criptografía de curva elíptica, lo que rompe el intercambio de claves en cuanto exista una máquina cuántica lo bastante grande. El algoritmo de Grover ofrece solo una aceleración cuadrática frente a la búsqueda simétrica, y reduce la fuerza efectiva a la mitad en lugar de a cero.

La diferencia entre exponencial y cuadrática lo explica todo. Una aceleración cuadrática frente a un hash de 128 bits deja todavía unas 2⁶⁴ operaciones por probar, una cifra computacionalmente enorme hoy, y una función memory-hard (de uso intensivo de memoria) como Argon2id multiplica aún más ese coste. Una aceleración exponencial frente a RSA-2048 no deja un margen comparable.

Para conocer en profundidad la mecánica de los esquemas basados en retículos y de otros esquemas poscuánticos, consulte nuestro artículo explicativo sobre qué es la criptografía cuántica; esta guía se centra en lo que cambia específicamente para la infraestructura de contraseñas.

Por qué el hash de su contraseña no es el objetivo real

Romper una contraseña bien protegida con hash sigue siendo caro incluso con el algoritmo de Grover, porque el coste de la función de hash se aplica a cada uno de los intentos que hace una máquina cuántica. Argon2id y bcrypt son memory-hard por diseño, así que reducir el exponente a la mitad deja al atacante pagando un precio alto por intento.

Tome una contraseña aleatoria de 16 caracteres extraída del conjunto imprimible completo de 95 caracteres: unos 105 bits de entropía antes de que el hash intervenga. La aceleración cuadrática de Grover reduce aproximadamente a la mitad ese exponente y sitúa al atacante en torno a 2⁵² operaciones efectivas. Esa cifra queda fuera del alcance de cualquier máquina cuántica que se plantee hoy en serio, y el coste memory-hard de Argon2id multiplica además el precio de cada intento.

No todas las funciones de hash ofrecen esa protección por igual. PBKDF2 está limitada por CPU y resulta más barata de paralelizar en hardware específico. Argon2id y bcrypt obligan al atacante a pagar en memoria además de en tiempo, lo que importa más a medida que mejora el descifrado con GPU y ASIC, cuántico o no. El salting sigue siendo obligatorio con cualquier algoritmo: impide los ataques con tablas rainbow precomputadas y obliga a que cada intento se ejecute individualmente contra un único hash.

Nuestra guía sobre hashing y salting de contraseñas explica con más detalle la mecánica de cada función, incluido por qué un mínimo de 16 caracteres se ha convertido en el suelo práctico.

La capa que de verdad se rompe: El intercambio de claves

El intercambio de claves RSA-2048 y ECDH es el verdadero objetivo. El algoritmo de Shor hace tratables la factorización en la que se basa RSA y el cálculo de los logaritmos discretos en los que se basa ECC, lo que rompe los handshakes de TLS, las sesiones SSH, los túneles VPN y cualquier envoltura de clave privada construida sobre las mismas primitivas.

La criptografía de clave pública lleva ese riesgo a la infraestructura cotidiana en más lugares de los que controla la mayoría de los equipos:

• Handshakes de TLS 1.3: intercambio de claves RSA o ECDHE, certificados ECDSA
• Intercambio de claves de host y de usuario en SSH
• Negociación de túneles VPN
• Envoltura de claves privadas dentro de la jerarquía de claves de un gestor de contraseñas
• Certificados de firma de código y de firma de documentos

Las matemáticas que hay detrás de ese riesgo no son hipotéticas. Google Quantum AI publicó en mayo de 2025 un preprint que muestra que RSA de 2048 bits podría factorizarse teóricamente con una máquina cuántica con corrección de errores lo bastante grande. La máquina todavía no existe. Las matemáticas que la romperían, sí.

Un gestor de contraseñas forma parte de esa misma lista. Compartir una bóveda con un nuevo miembro del equipo, sincronizar un registro entre dispositivos o desenvolver una clave privada al iniciar sesión dependen todos de una operación asimétrica en algún punto de la cadena. Auditar el stack criptográfico del gestor de contraseñas pertenece al mismo inventario que los endpoints TLS y los concentradores VPN.

Harvest now, decrypt later: La amenaza que ya existe hoy

Harvest now, decrypt later describe a un atacante que registra hoy tráfico cifrado y lo descifra en cuanto exista una máquina cuántica capaz de hacerlo. Reformula «lo cuántico está a diez años» como «la recolección ya ha empezado», lo que importa para cualquier dato cuya confidencialidad deba sobrevivir una década o más.

Thales encuestó en su 2026 Quantum & AI Threat Report a 3120 profesionales de seguridad y de TI de 20 países y concluyó que harvest now, decrypt later es su principal preocupación cuántica, citada por el 61 % de los encuestados, por delante de la obsolescencia de algoritmos o de los plazos de cumplimiento. Los adversarios con la paciencia de esperar años para obtener un beneficio, normalmente actores estatales, son los que llevan a cabo esa recolección hoy.

La exposición se concentra en los datos que deben seguir siendo confidenciales durante años: historiales médicos, escritos judiciales, propiedad intelectual, comunicaciones gubernamentales. Una clave de sesión TLS que se descarta en el momento en que se cierra la conexión es un objetivo pobre. Un archivo envuelto con RSA de 2024 que en 2034 siga en una cinta de copia de seguridad es exactamente lo que busca esta amenaza, igual que una exportación cifrada de una bóveda guardada en una copia de seguridad retirada que nadie se acordó de purgar.

Qué decidió realmente NIST y los plazos que le obligan

NIST finalizó sus tres primeras normas de criptografía poscuántica en agosto de 2024: FIPS 203 (ML-KEM) para el intercambio de claves, FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA) para las firmas digitales. NIST IR 8547 puso después en marcha el reloj del cumplimiento: declara obsoletos RSA, ECDSA y EdDSA después de 2030 y los prohíbe después de 2035.

La criptografía simétrica con seguridad de 128 bits o más no se ve afectada por nada de esto. AES-256 no necesita ningún cambio de algoritmo. Los plazos apuntan específicamente a la capa asimétrica: RSA, ECDSA y EdDSA, sustituidos por ML-KEM y ML-DSA. El Commercial National Security Algorithm Suite 2.0 refleja este mismo calendario para los sistemas de seguridad nacional de EE. UU., una señal de la seriedad con la que se espera que los equipos de compras se lo tomen.

NIST IR 8547 plantea la migración poscuántica como un esfuerzo de ingeniería de varios años, del orden de una década para integrarla en productos e infraestructura, que es el verdadero argumento para empezar un inventario ahora en lugar de esperar a 2029. La hoja de ruta cuántica pública de IBM apunta a un sistema de más de 100 000 cúbits para 2033. Es el objetivo declarado por el propio proveedor, no una proyección independiente, pero pone una fecha aproximada a partir de la cual «lo bastante grande» deja de ser teórico.

Incorporar ya la agilidad criptográfica a las compras, es decir, la capacidad de cambiar un algoritmo sin rediseñar un producto, es lo que convierte esto en una migración planificada en lugar de una carrera a contrarreloj.

La auditoría de exposición cuántica en 3 capas

Realizar esta auditoría lleva una tarde, no un proyecto de consultoría. Clasifique la infraestructura de contraseñas en tres capas, y cada una recibe su propio veredicto: seguro, vigilar o actuar ahora.

La capa 1 es la que más preocupa a los equipos y la que menos debería preocuparles. Si los hashes de inicio de sesión y de la contraseña maestra del gestor de contraseñas ya usan Argon2id, PBKDF2 o bcrypt con un factor de trabajo razonable, el algoritmo de Grover no cambia su cálculo de riesgo. La única carencia real que merece perseguirse: un sistema heredado que todavía ejecute MD5 o SHA-1 sin sal ya estaba roto antes de que lo cuántico entrara en la conversación.

La capa 2 es donde un administrador suele encontrar la carencia real: un concentrador VPN todavía anclado a RSA-2048, una PKI interna que emite certificados ECDSA sin plan de renovación, una API heredada que nunca pasó de TLS 1.2. Inventaríe todos los lugares donde RSA, ECDH o ECDSA realizan un intercambio de claves y empiece por lo que protege el tráfico de vida más larga.

La capa 3 trata de lo que ya se ha recolectado, no de lo que se cifra mañana. Pregúntese qué datos protege hoy la organización que todavía necesitarán confidencialidad en 2035: retenciones legales, tablas de capitalización, código fuente, cualquier cosa sujeta a un NDA de varios años. Después compruebe si esa confidencialidad depende de un intercambio de claves asimétrico realizado años atrás.

Realice la auditoría una vez y luego incorpórela a la periodicidad que el equipo ya use para el inventario criptográfico. Una vez al año es razonable. Con más frecuencia si este año va a emitir una nueva PKI o renegociar un contrato de VPN.

Cómo leer la documentación criptográfica de un gestor de contraseñas

La documentación criptográfica de un gestor de contraseñas debería indicar exactamente qué protege la bóveda en cada capa. Una afirmación vaga de «cifrado de grado militar» no cuenta. Busque algoritmos con nombre, tamaños de clave declarados, una función de derivación de claves concreta y una posición pública sobre la migración poscuántica.

Qué publica un proveedor consciente de lo cuántico:

• El cifrado simétrico exacto y el tamaño de clave que protegen los datos de la bóveda (AES-128 y AES-256 no ofrecen el mismo margen, así que «AES» por sí solo no basta)
• El algoritmo asimétrico exacto que se usa para el intercambio de claves y la envoltura de claves privadas
• La función de derivación de claves y el número de iteraciones que convierten una contraseña maestra en una clave de cifrado
• Si el cifrado se realiza en el lado del cliente, el modelo de conocimiento cero o solo en reposo en el servidor

La documentación de Passwork es un ejemplo razonable de lo que significa esa transparencia en la práctica. Su cifrado del lado del cliente aplica AES-256 a los datos de bóvedas y registros, con una capa AES-256 independiente que protege la base de datos en reposo. Una contraseña maestra deriva una clave maestra de 512 bits mediante PBKDF2 (HMAC-SHA-256), que desenvuelve una clave privada RSA-2048 que, a su vez, desenvuelve las claves de cada bóveda y de cada registro, una jerarquía documentada en la visión general de la criptografía.

Pase ese stack por la auditoría de 3 capas y la respuesta honesta es sencilla. La capa de datos AES-256 sigue siendo resistente a la computación cuántica con los tamaños de clave actuales; la capa de intercambio de claves RSA-2048 es el componente que hay que vigilar a medida que maduren las normas poscuánticas en todo el sector. Esa es la misma respuesta que debería darle hoy cualquier proveedor que envuelva claves con RSA: una capa AES-256 documentada que no necesita cambiar y una capa asimétrica con una vía de migración reconocida, no la afirmación de que todo es ya a prueba de lo cuántico. Nuestro artículo explicativo sobre AES-256 explica por qué el margen del tamaño de clave importa por sí solo.

Si su equipo está empezando su propio inventario criptográfico, Passwork publica exactamente este tipo de stack AES-256/RSA-2048 documentado, con registros de auditoría exportables para incorporarlos directamente a la revisión de la capa 2. Iniciar una prueba gratuita

Qué hacer hoy (y qué puede esperar)

Empiece por lo que protege hoy el intercambio de claves de TLS, SSH y VPN, ya que es la capa con un plazo real en 2030. El despliegue de passkeys, las pruebas de intercambio de claves híbrido y un inventario criptográfico documentado pueden avanzar en paralelo. Volver a generar claves en los despliegues de AES-256 o preocuparse por la fuerza del hash de contraseñas puede esperar.

Hacer ahora:

1. Inventaríe todos los lugares donde RSA, ECDH o ECDSA realizan un intercambio de claves: endpoints TLS, hosts SSH, concentradores VPN, PKI interna.
2. Confirme que su gestor de contraseñas y su proveedor de identidad publican su stack criptográfico real en lugar de una afirmación vaga de «cifrado de nivel bancario». Si un proveedor no quiere indicar sus algoritmos y tamaños de clave cuando se le pregunta, considere que esa es la respuesta.
3. Active la MFA en todos los lugares donde aún no sea obligatoria. No afecta directamente a la cuestión cuántica, pero cierra exposición mientras avanza la migración.

Planificar este año:

4. Lleve el intercambio de claves híbrido (clásico más ML-KEM) a las conversaciones sobre la hoja de ruta de sus proveedores, especialmente para todo lo que tenga un plazo en 2030.
5. Priorice el despliegue de passkeys para la autenticación de cara al usuario. La agilidad de algoritmos de FIDO2 implica que la vía de migración ya existe, aunque las passkeys actuales sigan usando ECDSA, y el propio despliegue reduce la parte de la infraestructura que todavía depende de un hash de contraseña.
6. Cierre los endpoints que sigan en TLS 1.2. Actualizar a TLS 1.3 es un requisito previo para el intercambio de claves poscuántico, no un proyecto aparte.

Vigilar:

7. Las hojas de ruta de hardware cuántico de IBM y Google. Un salto que supere los hitos del calendario de NIST anterior adelantaría los plazos en lugar de limitarse a confirmarlos.
8. Las directrices de NIST sobre los modos híbridos y puramente poscuánticos a medida que maduren las implementaciones de FIPS 203, 204 y 205 en las principales bibliotecas de TLS y SSH.

Nada de esto exige sustituir un gestor de contraseñas ya en uso. Si ya publica un stack AES-256/RSA-2048 como el anterior, la plataforma cumple su parte; el trabajo de inventario descrito arriba le corresponde a usted.

Conclusión

La computación cuántica no va a por el hash de su contraseña. Va a por el intercambio de claves RSA y ECC que lo transporta, y NIST ya ha puesto fechas en el calendario: 2030 para declararlos obsoletos y 2035 para prohibirlos. La auditoría de exposición cuántica en 3 capas convierte ese riesgo abstracto en tres comprobaciones concretas que un equipo puede realizar este trimestre, una de las cuales probablemente pueda cerrarse esta misma tarde.

Empiece por la capa 2. Saque la lista de todos los lugares de su entorno donde RSA, ECDH o ECDSA gestionan un handshake y sabrá en un día qué proveedores necesitan una conversación sobre migración y cuáles ya la tienen iniciada.

Si su equipo está elaborando ese inventario, Passwork le ofrece una bóveda AES-256/RSA-2048 documentada con registros de auditoría exportables para incorporarlos directamente a él. Iniciar una prueba gratuita

Preguntas frecuentes

¿Qué es el cifrado de conocimiento cero? Cómo funciona en 5 minutos

El cifrado de conocimiento cero significa que el servidor nunca guarda sus claves de descifrado, solo el texto cifrado. Descubra cómo funciona la cadena de claves, de qué protege, de qué no y cómo verificar la afirmación de un proveedor.

PassworkPasswork Team

Gestión de accesos para pymes: La primera capa de ciberseguridad

La gestión de accesos debe encabezar la lista de verificación de ciberseguridad de una pyme. Descubra cómo configurar la identidad, la autenticación, la autorización y la revocación como un sistema que aguante en el día a día.

PassworkPasswork Team

¿Qué es la PKI? La infraestructura de clave pública explicada para 2026

Para 2029, los certificados caducarán cada 47 días. Esto es lo que es realmente la PKI, cómo funciona y las credenciales humanas que mantienen en marcha la CA, algo que la propia PKI no protege.

PassworkPasswork Team

Quantum computers will not brute-force a properly hashed 16-character password anytime soon. Grover's algorithm only halves the exponent of a hash search, not the whole problem. What a large enough quantum computer does break is the RSA and elliptic-curve key exchange that carries that password to your server, and NIST has already put a 2030 deadline on replacing it.

Two separate problems get collapsed into one headline: "quantum computers will break your passwords." This guide keeps them apart, then hands IT and security teams a workflow for checking which one actually applies to their own password estate, and which parts of that estate can wait.

The two quantum algorithms that matter (Shor vs Grover)

Two quantum algorithms matter for password security, and they do different jobs. Shor's algorithm delivers an exponential speedup against the math behind RSA and elliptic-curve cryptography, which breaks key exchange once a large enough quantum computer exists. Grover's algorithm delivers only a quadratic speedup against symmetric search, cutting effective strength in half rather than to zero.

The gap between exponential and quadratic is the whole story. A quadratic speedup against a 128-bit hash still leaves roughly 2⁶⁴ operations to try, which is computationally enormous today, and a memory-hard function like Argon2id multiplies that cost further. An exponential speedup against RSA-2048 doesn't leave a comparable margin.

For the deeper mechanics of lattice-based and other post-quantum schemes, see our explainer on what is quantum cryptography; this guide stays focused on what changes for password infrastructure specifically.

Why your password hash is not the real target

A properly hashed password stays expensive to crack even under Grover's algorithm, because the hashing function's cost applies to every single guess a quantum computer makes. Argon2id and bcrypt are memory-hard by design, so halving the exponent still leaves an attacker paying a steep price per attempt.

Take a 16-character random password drawn from the full 95-character printable set: roughly 105 bits of entropy before hashing touches it. Grover's quadratic speedup roughly halves that exponent, landing an attacker around 2⁵² effective operations. That number stays out of reach for any quantum computer under serious discussion today, and Argon2id's memory-hard cost multiplies the price of each guess on top of it.

Not every hashing function offers that protection equally. PBKDF2 is CPU-bound and cheaper to parallelize on custom hardware. Argon2id and bcrypt force an attacker to pay in memory as well as time, which matters more as GPU and ASIC cracking improves, quantum or not. Salting stays mandatory regardless of algorithm: it stops precomputed rainbow-table attacks and forces every guess to run individually against a single hash.

Our guide to password hashing and salting covers the mechanics of each function in more depth, including why a 16-character minimum has become the practical floor.

The layer that actually breaks: Key exchange

RSA-2048 and ECDH key exchange are the actual target here. Shor's algorithm makes factoring the math behind RSA and computing the discrete logs behind ECC tractable, which breaks TLS handshakes, SSH sessions, VPN tunnels, and any private-key wrap built on the same primitives.

Public-key cryptography carries that risk into everyday infrastructure in more places than most teams track:

• TLS 1.3 handshakes: RSA or ECDHE key exchange, ECDSA certificates
• SSH host and user key exchange
• VPN tunnel negotiation
• Private-key wrapping inside a password manager's key hierarchy
• Code-signing and document-signing certificates

The math behind that risk isn't hypothetical. Google Quantum AI published a May 2025 preprint showing that 2048-bit RSA could theoretically be factored by a sufficiently large error-corrected quantum computer. The machine doesn't exist yet. The mathematics that would break it does.

A password manager sits inside this same list. Sharing a vault with a new team member, syncing a record between devices, or unwrapping a private key at login all depend on an asymmetric operation somewhere in the chain. Auditing your password manager's crypto stack belongs in the same inventory as your TLS endpoints and VPN concentrators.

Harvest now, decrypt later: The threat that exists today

Harvest now, decrypt later describes an attacker recording encrypted traffic today and decrypting it once a capable quantum computer exists. It reframes "quantum is ten years away" into "the collection already started," which matters for any data whose confidentiality needs to survive a decade or more.

Thales's 2026 Quantum & AI Threat Report surveyed 3,120 security and IT professionals across 20 countries and found harvest-now-decrypt-later is their top quantum concern, cited by 61% of respondents, ahead of algorithm deprecation or compliance deadlines. Adversaries with the patience to wait years for a payoff, typically nation-state actors, are the ones running this collection today.

The exposure concentrates in data that needs to stay confidential for years: medical records, legal filings, intellectual property, government communications. A TLS session key discarded the moment a connection closes is a poor target. An RSA-wrapped archive from 2024 still sitting on a backup tape in 2034 is exactly what this threat targets, and so is an encrypted vault export sitting in a decommissioned backup that nobody remembered to purge.

What NIST actually decided, and the deadlines that bind you

NIST finalized its first three post-quantum cryptography standards in August 2024: FIPS 203 (ML-KEM) for key exchange, FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for digital signatures. NIST IR 8547 then set the compliance clock, deprecating RSA, ECDSA, and EdDSA after 2030 and disallowing them after 2035.

Symmetric cryptography at 128-bit security or higher is unaffected by any of this. AES-256 needs no algorithm change. The deadlines target the asymmetric layer specifically: RSA, ECDSA, and EdDSA, replaced by ML-KEM and ML-DSA. The Commercial National Security Algorithm Suite 2.0 mirrors this timeline for U.S. national security systems, one signal of how seriously procurement teams are meant to take it.

NIST IR 8547 frames post-quantum migration as a multi-year engineering effort, on the order of a decade to integrate across products and infrastructure, which is the real argument for starting an inventory now rather than waiting until 2029. IBM's public quantum roadmap targets a system of 100,000-plus qubits by 2033. That's the vendor's own stated goal, not an independent projection, but it puts a rough date on when "large enough" stops being theoretical.

Building crypto agility into procurement now, meaning the ability to swap an algorithm without rearchitecting a product, is what turns this from a scramble into a scheduled migration.

The 3-Layer Quantum Exposure Audit

Running this audit takes an afternoon, not a consulting engagement. Sort your password estate into three layers, and each one gets its own verdict: safe, watch, or act now.

Layer 1 is the one teams worry about most and need to worry about least. If your login and password-manager master-password hashes already use Argon2id, PBKDF2 or bcrypt with a reasonable work factor, Grover's algorithm doesn't change your risk calculus. The one real gap worth chasing: a legacy system still running MD5 or unsalted SHA-1 was already broken before quantum entered the conversation.

Layer 2 is where an admin usually finds the actual gap: a VPN concentrator still pinned to RSA-2048, an internal PKI issuing ECDSA certificates with no renewal plan, a legacy API that never moved past TLS 1.2. Inventory every place RSA, ECDH, or ECDSA performs a key exchange, and start with whatever protects your longest-lived traffic.

Layer 3 is about what's already been collected, not what gets encrypted tomorrow. Ask what data your organization protects today that still needs confidentiality in 2035: legal holds, cap tables, source code, anything under a multi-year NDA. Then check whether that confidentiality depends on an asymmetric key exchange performed years ago.

Run the audit once, then fold it into whatever cadence your team already uses for a crypto inventory. Annually is reasonable. Faster if you're issuing new PKI or renegotiating a VPN contract this year.

How to read a password manager's crypto documentation

A password manager's crypto documentation should name exactly what protects your vault at each layer. A vague "military-grade encryption" claim doesn't count. Look for named algorithms, stated key sizes, a named key-derivation function, and a public position on post-quantum migration.

What a quantum-aware vendor publishes:

• The exact symmetric cipher and key size protecting vault data (AES-128 and AES-256 are not the same margin, so "AES" alone isn't enough)
• The exact asymmetric algorithm used for key exchange and private-key wrapping
• The key derivation function and iteration count turning a master password into an encryption key
• Whether encryption happens client-side, the zero-knowledge model, or only at rest on the server

Passwork's own documentation is a reasonable example of what that transparency looks like in practice. Its client-side encryption applies AES-256 to vault and record data, with a separate AES-256 layer protecting the database at rest. A master password derives a 512-bit master key through PBKDF2 (HMAC-SHA-256), which unwraps an RSA-2048 private key that in turn unwraps per-vault and per-record keys, a hierarchy documented in the cryptography overview.

Run that stack through the 3-Layer Audit and the honest answer is straightforward. The AES-256 data layer stays quantum-resistant at current key sizes; the RSA-2048 key-exchange layer is the component to watch as post-quantum standards mature across the industry. That's the same answer any vendor wrapping keys with RSA should be giving you today: a documented AES-256 layer that doesn't need to change, and an asymmetric layer with an acknowledged migration path, not a claim that everything is already quantum-proof. Our AES-256 explainer covers why the key size margin matters on its own.

If your team is starting its own crypto inventory, Passwork publishes exactly this kind of documented AES-256/RSA-2048 stack, with exportable audit logs to feed straight into your Layer 2 review. Start a free trial

What to do today (and what can wait)

Start with what protects TLS, SSH, and VPN key exchange today, since that's the layer with an actual 2030 deadline. Passkey rollout, hybrid key exchange testing, and a documented crypto inventory can run in parallel. Re-keying AES-256 deployments or worrying about password hash strength can wait.

Do now:

1. Inventory every place RSA, ECDH, or ECDSA performs key exchange: TLS endpoints, SSH hosts, VPN concentrators, internal PKI.
2. Confirm your password manager and identity provider publish their actual crypto stack instead of a vague "bank-level encryption" claim. If a vendor won't name its algorithms and key sizes on request, treat that as the answer.
3. Turn on MFA everywhere it isn't already mandatory. It doesn't touch the quantum question directly, but it closes exposure while migration runs.

Plan this year:

4. Get hybrid key exchange (classical plus ML-KEM) onto your vendor roadmap conversations, especially for anything facing a 2030 deadline.
5. Prioritize passkey rollout for user-facing authentication. FIDO2's algorithm agility means the migration path already exists, even though today's passkeys still use ECDSA, and rollout itself reduces how much of your estate still depends on a password hash at all.
6. Close out any lingering TLS 1.2 endpoints. Update TLS 1.3 is a prerequisite for post-quantum key exchange, not a separate project.

Watch:

7. IBM's and Google's quantum hardware roadmaps. A jump past the milestones in the NIST timeline above would move deadlines up rather than simply confirm them.
8. NIST guidance on hybrid and pure post-quantum modes as FIPS 203, 204, and 205 implementations mature in mainstream TLS and SSH libraries.

None of this requires replacing an existing password manager. If it already publishes an AES-256/RSA-2048 stack like the one above, the platform is doing its part; the inventory work above is yours.

Conclusion

Quantum computers are not coming for your password hash. They're coming for the RSA and ECC key exchange that carries it, and NIST has already put dates on the calendar: 2030 to deprecate, 2035 to disallow. The 3-Layer Quantum Exposure Audit turns that abstract risk into three concrete checks a team can run this quarter, one of which is probably closeable this afternoon.

Start with Layer 2. Pull the list of everywhere RSA, ECDH, or ECDSA handles a handshake in your environment, and you'll know within a day which vendors need a migration conversation and which ones already have one started.

If your team is building that inventory, Passwork gives you a documented AES-256/RSA-2048 vault with exportable audit logs to feed straight into it. Start a free trial

Frequently asked questions

What is zero-knowledge encryption? How it works in 5 minutes

Zero-knowledge encryption means the server never holds your decryption keys, only ciphertext. Learn how the key chain works, what it protects against, what it doesn’t, and how to verify a vendor’s claim.

PassworkPasswork Team

Access management for SMBs: The first cybersecurity layer

Access management belongs at the top of your SMB cybersecurity checklist. Learn how to set up identity, authentication, authorization, and revocation as a system that holds up day to day.

PassworkPasswork Team

What is PKI? Public key infrastructure explained for 2026

Certificates now expire every 47 days by 2029. Here is what PKI actually is, how it works, and the human credentials that keep your CA running, which PKI itself does not protect.

PassworkPasswork Team

A gestão de acessos deve ocupar o início de uma lista de verificação de cibersegurança para PME, porque determina quem pode aceder aos sistemas em que a empresa funciona. Quando o acesso é pouco claro ou excessivo, uma correção, uma cópia de segurança ou uma ferramenta de segurança não conseguem impedir de forma fiável que a pessoa errada chegue aos dados da empresa.

Numa pequena e média empresa (PME), a gestão de acessos consiste em controlar quatro elementos: 

• Identidade: quem existe nos sistemas
• Autenticação: como essas pessoas provam quem são 
• Autorização: o que podem fazer depois de entrarem
• Revogação: como esse acesso desaparece quando deve 

A lista de verificação de cibersegurança para pequenas empresas do Passwork apresenta a base completa de que uma PME necessita. Este artigo aprofunda um elemento dessa base: como configurar identidade, autenticação, autorização e revogação como um sistema que se mantém eficaz no dia a dia.

Porque a gestão de acessos abre a lista de verificação de cibersegurança para PME

A gestão de acessos vem em primeiro lugar porque todos os outros controlos dependem dela. As cópias de segurança, a proteção de endpoints e as ferramentas de monitorização partem do princípio de que as contas que lhes acedem são as corretas, com as permissões certas, no momento certo.

A gestão de identidades e acessos (IAM) é a disciplina que trata deste domínio. NIST descreve a IAM como «uma capacidade de cibersegurança fundamental e crítica», centrada em garantir que as pessoas e as entidades certas têm o acesso certo aos recursos certos no momento certo. A autenticação confirma que um utilizador ou um sistema é quem afirma ser. A autorização determina o que esse utilizador ou sistema pode fazer depois de iniciar sessão. Ambas as etapas têm de funcionar para que qualquer controlo posterior tenha efeito.

Esta dependência manifesta-se em toda a empresa:

• As contas de correio eletrónico e de SaaS são a via de acesso às redefinições de palavras-passe, aos documentos partilhados e aos registos de clientes
• Os direitos de administrador nos endpoints determinam se um utilizador pode instalar software ou desativar definições de segurança
• As contas de administrador de cópias de segurança e as permissões de armazenamento na nuvem determinam se os dados de recuperação podem ser alterados ou eliminados
• O acesso de prestadores de serviços e fornecedores determina se as pessoas externas à empresa mantêm o acesso depois de um projeto terminar
• A resposta a incidentes depende da capacidade de desativar contas, revogar sessões e rastrear quem acedeu a determinada credencial

IBM, no relatório 2026 Cost of a Data Breach Report, situa o custo médio global de uma violação de dados em 4,99 milhões de dólares. Este valor ilustra por que razão as decisões de acesso subjacentes a uma violação têm um peso real.

Inventariar cada identidade e cada via de acesso

Um inventário de identidades lista todos os tipos de conta que podem aceder aos recursos da empresa, juntamente com a pessoa ou a equipa responsável por cada um. Vai além de uma lista genérica de ativos, porque atribui um responsável a cada entrada, incluindo as contas partilhadas, automatizadas ou externas ao sistema de processamento salarial.

Comece por separar as identidades humanas das não humanas. Os colaboradores e os administradores precisam de contas individuais. Os fornecedores, os prestadores de serviços e as caixas de correio partilhadas precisam de um responsável identificado, mesmo que a própria conta seja utilizada por mais de uma pessoa. As contas de serviço e as chaves de API, as credenciais que as aplicações utilizam para comunicar entre si, exigem a mesma responsabilização, uma vez que muitas vezes têm permissões que nenhuma conta humana possui.

Uma palavra-passe partilhada, um token de API ou um início de sessão num portal de fornecedor que não possa ser substituído de imediato continua a precisar de um responsável registado desde já. Esse único campo transforma um inventário em algo sobre o qual é possível agir durante uma revisão ou um incidente.

Autenticar identidades fortes e autorizar apenas o acesso necessário

A autenticação e a autorização são o ponto em que a maioria das tomadas de controlo de contas tem êxito ou falha. Aplicar a MFA às contas certas, substituir os inícios de sessão partilhados por acessos nominais e definir funções com base nas tarefas reais fecha as lacunas que os atacantes mais utilizam para entrar e circular no interior dos sistemas.

Aplicar a MFA às contas que controlam a empresa

A autenticação multifator (MFA), um método de início de sessão que exige mais do que um fator de verificação, deve ser imposta através de controlos técnicos e verificada. CISA orienta as pequenas empresas a impor a MFA com controlos técnicos e a ativá-la em todas as contas de administrador. Convém começar pelas contas de correio eletrónico, de administrador, de acesso remoto, financeiras, de armazenamento na nuvem e de dados sensíveis, uma vez que são as que dão ao atacante maior alcance se forem comprometidas.

A autenticação resistente a phishing associa o início de sessão ao serviço legítimo, o que dificulta muito a reutilização de credenciais roubadas. As chaves de segurança FIDO2 e as passkeys são os exemplos atuais. NIST SP 800-63B Revision 4 exige que as aplicações no Authenticator Assurance Level 2 (AAL2) ofereçam uma opção resistente a phishing, sem a impor como método único para todas as empresas. Esta opção deve ser encarada como a direção a seguir, primeiro nas contas de maior risco e depois nos restantes inícios de sessão, à medida que a configuração o permitir.

Documente separadamente os percursos de recuperação. Limite quem pode repor a MFA de outra pessoa, proteja qualquer conta de emergência break-glass com um responsável identificado e uso limitado e reveja essa conta após cada utilização.

Tornar viáveis as credenciais únicas com um gestor de palavras-passe controlado

O credential stuffing é a reutilização automatizada de pares de nome de utilizador e palavra-passe roubados noutros serviços. Funciona porque as pessoas reutilizam a mesma palavra-passe em várias contas, pelo que uma única credencial divulgada dá aos atacantes uma chave que serve em várias portas. Verizon, no relatório 2026 Data Breach Investigations Report, atribui ao abuso de credenciais 13 % dos vetores de acesso inicial e às credenciais 28 % dos tipos de dados roubados em violações.

As palavras-passe únicas travam esse ataque: uma credencial divulgada só abre o serviço de onde foi divulgada. O objetivo prático são credenciais únicas, controladas pela organização e com acesso nominal, que substituam a folha de cálculo ou a mensagem de chat em que demasiadas equipas ainda confiam. Uma política de gestão de palavras-passe que exija uma palavra-passe única e gerada para cada conta dá a este objetivo uma base escrita. Um gestor de palavras-passe concebido para equipas torna essa política realista no dia a dia, gerando e armazenando credenciais e controlando exatamente quem as pode obter.

Definir funções com base no trabalho e remover os direitos de administrador permanentes

O controlo de acesso baseado em funções (RBAC) atribui permissões com base nas funções profissionais atuais, e não no historial acumulado. Cada administrador deve ainda possuir uma conta padrão separada para o trabalho diário, para que tarefas rotineiras como o correio eletrónico e a navegação nunca sejam executadas a partir de um início de sessão com privilégios elevados.

Um exemplo breve: o pessoal de finanças tem acesso aos sistemas de contabilidade, o pessoal de suporte tem acesso à plataforma de helpdesk e os administradores de TI têm acesso administrativo aprovado à infraestrutura. Os responsáveis pelas aplicações aprovam as atribuições de funções; a TI confirma que a configuração técnica corresponde à aprovação.

Substituir o acesso partilhado anónimo por acesso com responsabilização

As contas individuais garantem melhor responsabilização do que os inícios de sessão partilhados, uma vez que cada ação pode ser atribuída a uma só pessoa. Algumas ferramentas legadas e portais de fornecedores continuam a impor credenciais partilhadas. Nesse caso, a credencial deve ser armazenada num cofre controlado, com acesso nominal por utilizador, permissões de menor privilégio, um registo de auditoria e um acionador de rotação agendado.

O ciclo de controlo de acessos das PME

O acesso tem de mudar à medida que as pessoas e as funções mudam, e alguém tem de confirmar que a mudança foi realmente efetuada. O ciclo de vida joiner-mover-leaver descreve os três momentos em que o acesso tem de ser atualizado: quando alguém entra, quando muda de função e quando sai.

A integração de colaboradores, uma mudança de função, o fim de um contrato, uma inatividade prolongada, uma alteração de sistema ou uma suspeita de comprometimento devem desencadear uma atualização de acessos. Em vez de adotar um prazo universal para a saída de colaboradores, convém documentar um nível de serviço baseado no risco para a empresa e confirmar, em cada caso, que foi cumprido.

Cenário ilustrativo: um gestor comercial sai da empresa. A equipa de TI tem de verificar a conta no fornecedor de identidade, a sessão de correio eletrónico ativa, a função no CRM, as permissões de partilha no armazenamento na nuvem, o acesso por VPN, o dispositivo móvel e qualquer pertença a cofres de credenciais. Se um único destes elementos for omitido, fica um caminho ativo para os sistemas da empresa depois de a pessoa ter saído.

O ciclo de controlo de acessos das PME, apresentado na tabela abaixo, abrange cinco fases: inventariar, autenticar, autorizar, alterar ou remover e verificar. Cada fase corresponde diretamente a um controlo que uma pequena ou média empresa consegue executar sem um orçamento de IAM empresarial.

Como o Passwork gere o acesso às credenciais

O Passwork centraliza as palavras-passe e os segredos das equipas, controla quem os pode obter e regista cada evento de acesso, funcionando em conjunto com um fornecedor de identidade, e não em substituição deste. Ocupa-se da autorização e da remoção de acessos: conceder às pessoas as credenciais certas e cortar esse acesso no momento em que uma função ou a situação laboral muda.

O fluxo de trabalho das credenciais divide-se em quatro passos:

1. Ligar a origem de identidade. Estabeleça a ligação com Active Directory, LDAP ou um fornecedor de identidade SAML 2.0, como o Microsoft Entra ID, o Okta, o ADFS ou o Google Workspace.
2. Mapear grupos para cofres. Cada grupo do diretório recebe, consoante a sua função, acesso de leitura, escrita, partilha ou apenas de auditoria a um cofre ou pasta.
3. Centralizar as credenciais. Armazene as palavras-passe, as chaves de API e os certificados em cofres partilhados, propriedade da organização, em vez de repositórios pessoais do navegador, folhas de cálculo ou conversas de chat.
4. Auditar todas as ações. Consulte o registo para saber quem acedeu a uma credencial, a alterou, a partilhou ou a exportou, e quando. Exporte-o para uma ferramenta SIEM se a equipa de segurança precisar dele aí.

O Passwork controla o acesso às credenciais. Não substitui a origem de identidade, o ciclo de vida documentado nem o responsável identificado por cada decisão de acesso. Essas responsabilidades continuam a cargo da organização.

Conclusão

Uma pequena empresa não precisa de um orçamento de IAM empresarial para acertar neste ponto. Precisa de quatro coisas por esta ordem: saber quem tem acesso, autenticá-lo e autorizá-lo corretamente, removê-lo no momento em que algo muda e verificar que a remoção ocorreu de facto. Um responsável, uma evidência, todas as vezes.

Perguntas frequentes

Lista de verificação de cibersegurança para pequenas empresas em 2026

Uma lista de verificação de segurança prática e alinhada com o NIST para pequenas empresas: 18 passos que abrangem políticas, MFA, gestão de palavras-passe, segurança de rede, cópias de segurança e resposta a incidentes, ordenados por custo e impacto.

PassworkPasswork Team

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

Guardar palavras-passe no Slack e em navegadores expõe a empresa a violações de dados. Descubra por que razão as ferramentas pessoais falham nas equipas, como efetuar a saída segura de colaboradores num só clique e por que razão as diretrizes mais recentes do NIST desaconselham a rotação forçada de palavras-passe.

Passwork BlogAlex Muntyan

Passwork vs Bitwarden: Como a arquitetura de cifragem de cofres difere

O Passwork cifra cada cofre com a sua própria chave. O Bitwarden cifra uma organização inteira com uma única chave partilhada. Esta comparação analisa o que isso significa para o raio de impacto, o isolamento entre equipas, a recuperação de contas e as respostas de auditoria quando uma credencial é divulgada.

PassworkPasswork Team

Zugriffsverwaltung steht am Anfang jeder Cybersicherheits-Checkliste für KMU, denn sie legt fest, wer die Systeme öffnen kann, auf denen das Unternehmen läuft. Ist der Zugriff unklar oder zu weitreichend, können ein Patch, ein Backup oder ein Sicherheitstool nicht zuverlässig verhindern, dass die falsche Person an Unternehmensdaten gelangt.

Für ein kleines oder mittleres Unternehmen (KMU) bedeutet Zugriffsverwaltung, vier Dinge zu kontrollieren: 

• Identität: Wer in Ihren Systemen existiert.
• Authentifizierung: Wie die Person nachweist, wer sie ist. 
• Autorisierung: Was die Person tun kann, sobald sie angemeldet ist.
• Entzug: Wie dieser Zugriff verschwindet, wenn es nötig ist. 

Passworks Cybersicherheits-Checkliste für kleine Unternehmen beschreibt die vollständige Basis, die ein KMU benötigt. Dieser Artikel vertieft einen Teil dieser Basis: wie Sie Identität, Authentifizierung, Autorisierung und Entzug als System aufbauen, das sich im Alltag bewährt.

Warum Zugriffsverwaltung in der Cybersicherheits-Checkliste für KMU an erster Stelle steht

Zugriffsverwaltung steht an erster Stelle, weil jede andere Kontrolle davon abhängt. Backups, Endpoint-Schutz und Monitoring-Tools gehen alle davon aus, dass die Konten, die mit ihnen interagieren, die richtigen sind – mit den richtigen Berechtigungen zur richtigen Zeit.

Identity and Access Management (IAM) ist die Disziplin, die genau das steuert. NIST beschreibt IAM als „eine grundlegende und kritische Cybersicherheitsfunktion", die sicherstellen soll, dass die richtigen Personen und Dinge zur richtigen Zeit den richtigen Zugriff auf die richtigen Ressourcen haben. Authentifizierung weist nach, dass ein Benutzer oder System tatsächlich der ist, der er vorgibt zu sein. Autorisierung legt fest, was dieser Benutzer oder dieses System nach der Anmeldung tun darf. Beide Schritte müssen funktionieren, damit jede nachgelagerte Kontrolle überhaupt etwas bewirkt.

Diese Abhängigkeit zeigt sich im gesamten Unternehmen:

• E-Mail- und SaaS-Konten sind der Weg zu Passwort-Zurücksetzungen, gemeinsam genutzten Dokumenten und Kundendaten.
• Administratorrechte auf Endgeräten bestimmen, ob ein Benutzer Software installieren oder Sicherheitseinstellungen deaktivieren kann.
• Backup-Administratorkonten und Cloud-Speicher-Berechtigungen bestimmen, ob Wiederherstellungsdaten verändert oder gelöscht werden können.
• Zugriff von Auftragnehmern und Dienstleistern entscheidet, ob Personen außerhalb des Unternehmens nach Projektende weiterhin Zugriff behalten.
• Incident Response hängt von der Fähigkeit ab, Konten zu deaktivieren, Sitzungen zu widerrufen und nachzuvollziehen, wer mit welchen Zugangsdaten gearbeitet hat.

Der IBM-Bericht „Cost of a Data Breach" 2026 beziffert die weltweiten durchschnittlichen Kosten eines Sicherheitsvorfalls auf 4,99 Millionen US-Dollar. Diese Zahl verdeutlicht, warum die Zugriffsentscheidungen hinter einem solchen Vorfall erhebliches Gewicht haben.

Jede Identität und jeden Zugriffspfad inventarisieren

Eine Identitätsinventur listet jeden Kontotyp auf, der auf Unternehmensressourcen zugreifen kann, zusammen mit der Person oder dem Team, das dafür verantwortlich ist. Sie geht über eine einfache Bestandsliste hinaus, da sie für jeden Eintrag einen Verantwortlichen benennt – auch für Konten, die gemeinsam genutzt, automatisiert oder außerhalb der Gehaltsabrechnung angesiedelt sind.

Trennen Sie zunächst menschliche Identitäten von nicht-menschlichen. Mitarbeiter und Administratoren benötigen individuelle Konten. Dienstleister, Auftragnehmer und gemeinsam genutzte Postfächer brauchen einen benannten Verantwortlichen, auch wenn das Konto selbst von mehreren Personen genutzt wird. Servicekonten und API-Schlüssel – die Zugangsdaten, mit denen Anwendungen miteinander kommunizieren – benötigen dieselbe Verantwortlichkeit, da sie oft Berechtigungen besitzen, über die kein menschliches Konto verfügt.

Ein gemeinsam genutztes Passwort, ein API-Token oder ein Dienstleister-Portal-Login, das sich nicht sofort ersetzen lässt, braucht trotzdem noch heute einen dokumentierten Verantwortlichen. Genau dieses eine Feld macht aus einer Inventur etwas, auf dessen Basis Sie bei einer Überprüfung oder einem Vorfall handeln können.

Starke Identitäten authentifizieren und nur den erforderlichen Zugriff autorisieren

Authentifizierung und Autorisierung sind die Punkte, an denen die meisten Kontoübernahmen gelingen oder scheitern. MFA auf den richtigen Konten einzuführen, gemeinsam genutzte Logins durch namentlich zugeordneten Zugriff zu ersetzen und Rollen anhand der tatsächlichen Aufgaben aufzubauen, schließt die Lücken, die Angreifer am häufigsten nutzen, um einzudringen und sich danach im System zu bewegen.

MFA auf die Konten anwenden, die das Unternehmen steuern

Multi-Faktor-Authentifizierung (MFA), eine Anmeldemethode, die mehr als einen Verifizierungsfaktor erfordert, sollte durch technische Kontrollen durchgesetzt und überprüft werden. CISA empfiehlt kleinen Unternehmen, MFA technisch zu erzwingen und sie für alle Administratorkonten zu aktivieren. Beginnen Sie mit E-Mail-, Administrator-, Remote-Access-, Finanz-, Cloud-Speicher- und Konten mit sensiblen Daten, da diese einem Angreifer im Falle einer Kompromittierung die größte Reichweite verschaffen.

Phishing-resistente Authentifizierung bindet die Anmeldung an den legitimen Dienst, wodurch gestohlene Zugangsdaten deutlich schwerer wiederzuverwenden sind. FIDO2-Sicherheitsschlüssel und Passkeys sind die derzeit gängigen Beispiele. NIST SP 800-63B Revision 4 verlangt von Anwendungen auf Authenticator Assurance Level 2 (AAL2), eine phishing-resistente Option anzubieten, ohne sie für jedes Unternehmen als einzige zulässige Methode vorzuschreiben. Betrachten Sie dies als die Richtung, in die Sie sich zunächst bei Ihren risikoreichsten Konten bewegen sollten, und erweitern Sie sie anschließend auf weitere Logins, soweit es Ihre Umgebung zulässt.

Dokumentieren Sie Wiederherstellungswege separat. Beschränken Sie, wer das MFA einer anderen Person zurücksetzen darf, schützen Sie jedes „Break-glass"-Notfallkonto durch einen benannten Verantwortlichen und eine begrenzte Nutzung, und überprüfen Sie dieses Konto nach jeder Verwendung.

Eindeutige Zugangsdaten mit einem kontrollierten Passwortmanager praktikabel machen

Credential Stuffing ist die automatisierte Wiederverwendung gestohlener Benutzername-Passwort-Kombinationen gegen andere Dienste. Es funktioniert, weil Menschen dasselbe Passwort für mehrere Konten verwenden – ein einziger durchgesickerter Login liefert Angreifern damit einen Schlüssel, der zu mehreren Türen passt. Der Verizon-Bericht „Data Breach Investigations Report" 2026 beziffert den Missbrauch von Zugangsdaten auf 13 % der initialen Zugriffsvektoren und Zugangsdaten auf 28 % der bei Datenschutzverletzungen gestohlenen Datentypen.

Eindeutige Passwörter durchbrechen diesen Angriff: Geleakte Zugangsdaten schalten nur den einen Dienst frei, aus dem sie stammen. Das praktische Ziel sind vom Unternehmen kontrollierte, eindeutige Zugangsdaten mit namentlich zugeordnetem Zugriff – als Ersatz für die gemeinsam genutzte Tabelle oder Chat-Nachricht, auf die sich noch zu viele Teams verlassen. Eine Passwortrichtlinie, die für jedes Konto ein eindeutiges, generiertes Passwort vorschreibt, gibt diesem Ziel eine schriftliche Grundlage. Ein für Teams konzipierter Passwortmanager macht diese Richtlinie im Alltag realistisch umsetzbar, indem er Zugangsdaten generiert und speichert und dabei genau kontrolliert, wer sie abrufen kann.

Rollen an der Arbeit ausrichten und dauerhafte Administratorrechte entfernen

Rollenbasierte Zugriffskontrolle (RBAC) vergibt Berechtigungen anhand der aktuellen Aufgaben und nicht anhand historisch angesammelter Rechte. Jeder Administrator sollte zusätzlich ein separates Standardkonto für die tägliche Arbeit besitzen, damit Routineaufgaben wie E-Mail und Surfen niemals über ein hochprivilegiertes Konto laufen.

Ein kurzes Beispiel: Mitarbeiter im Finanzbereich erhalten Zugriff auf Buchhaltungssysteme, Support-Mitarbeiter erhalten Zugriff auf die Helpdesk-Plattform, und IT-Administratoren erhalten genehmigten administrativen Zugriff auf die Infrastruktur. Anwendungsverantwortliche genehmigen die Rollenzuweisungen, die IT bestätigt, dass die technische Einrichtung der Genehmigung entspricht.

Anonymen gemeinsamen Zugriff durch nachvollziehbaren Zugriff ersetzen

Individuelle Konten sorgen für bessere Nachvollziehbarkeit als gemeinsam genutzte Logins, da sich jede Aktion auf eine Person zurückführen lässt. Einige Altsysteme und Dienstleisterportale erzwingen weiterhin gemeinsam genutzte Zugangsdaten. In diesem Fall speichern Sie die Zugangsdaten in einem kontrollierten Tresor mit namentlich zugeordnetem Benutzerzugriff, minimalen Rechten, einem Audit-Trail und einem geplanten Rotationsauslöser.

Der KMU-Zugriffskontrollkreislauf

Der Zugriff muss sich ändern, wenn sich Personen und Rollen ändern, und jemand muss bestätigen, dass diese Änderung tatsächlich erfolgt ist. Der Joiner-Mover-Leaver-Lebenszyklus beschreibt die drei Momente, in denen der Zugriff aktualisiert werden muss: wenn jemand eintritt, wenn sich die Rolle ändert und wenn die Person das Unternehmen verlässt.

Onboarding, ein Rollenwechsel, ein auslaufender Vertrag, längere Inaktivität, eine Systemänderung oder eine vermutete Kompromittierung sollten jeweils eine Zugriffsaktualisierung auslösen. Statt eines einheitlichen Zeitziels für das Offboarding sollten Sie ein risikobasiertes Service-Level für Ihr Unternehmen dokumentieren und in jedem Einzelfall bestätigen, dass Sie es eingehalten haben.

Beispielszenario: Ein Vertriebsleiter verlässt das Unternehmen. Die IT muss das Identity-Provider-Konto, die aktive E-Mail-Sitzung, die CRM-Rolle, Freigabeberechtigungen im Cloud-Speicher, den VPN-Zugriff, das Mobilgerät und jede Zugehörigkeit zu einem Zugangsdaten-Tresor prüfen. Fehlt auch nur einer dieser Punkte, bleibt ein funktionierender Zugangsweg in die Unternehmenssysteme bestehen, nachdem die Person das Unternehmen verlassen hat.

Der KMU-Zugriffskontrollkreislauf, der in der folgenden Tabelle dargestellt ist, umfasst fünf Phasen: inventarisieren, authentifizieren, autorisieren, ändern oder entfernen und überprüfen. Jede Phase lässt sich direkt einer Kontrolle zuordnen, die ein kleines oder mittleres Unternehmen auch ohne ein Enterprise-IAM-Budget umsetzen kann.

Wie Passwork die Zugriffsverwaltung für Zugangsdaten handhabt

Passwork zentralisiert Team-Passwörter und Geheimnisse, kontrolliert, wer sie abrufen kann, und protokolliert jedes Zugriffsereignis – als Ergänzung zu einem Identity-Provider, nicht als Ersatz dafür. Es übernimmt Autorisierung und Zugriffsentzug: Es gewährt Personen die richtigen Zugangsdaten und entzieht diesen Zugriff in dem Moment, in dem sich eine Rolle oder ein Beschäftigungsstatus ändert.

Der Workflow für Zugangsdaten läuft in vier Schritten ab:

1. Identitätsquelle verbinden. Verknüpfen Sie Active Directory, LDAP oder einen SAML-2.0-Identity-Provider, zum Beispiel Microsoft Entra ID, Okta, ADFS oder Google Workspace.
2. Gruppen auf Tresore abbilden. Jede Verzeichnisgruppe erhält je nach Rolle Lese-, Schreib-, Freigabe- oder reinen Prüfzugriff auf einen Tresor oder Ordner.
3. Zugangsdaten zentralisieren. Speichern Sie Passwörter, API-Schlüssel und Zertifikate in gemeinsam genutzten, unternehmenseigenen Tresoren statt in persönlichen Browser-Speichern, Tabellen oder Chat-Verläufen.
4. Jede Aktion prüfen. Prüfen Sie im Protokoll, wer wann auf Zugangsdaten zugegriffen, sie geändert, freigegeben oder exportiert hat. Exportieren Sie das Protokoll bei Bedarf in ein SIEM-Tool Ihres Sicherheitsteams.

Passwork steuert den Zugriff auf Zugangsdaten. Es ersetzt weder die Identitätsquelle noch den dokumentierten Lebenszyklus noch den benannten Verantwortlichen hinter jeder Zugriffsentscheidung. Diese Verantwortlichkeiten bleiben beim Unternehmen.

Fazit

Ein kleines Unternehmen braucht kein Enterprise-IAM-Budget, um das richtig zu machen. Es braucht vier Dinge in dieser Reihenfolge: wissen, wer Zugriff hat, ihn korrekt authentifizieren und autorisieren, ihn entfernen, sobald sich etwas ändert, und überprüfen, dass die Entfernung tatsächlich stattgefunden hat. Ein Verantwortlicher, ein Nachweis – jedes Mal.

Häufig gestellte Fragen

Cybersicherheits-Checkliste für kleine Unternehmen 2026

Eine praxisnahe, an NIST ausgerichtete Sicherheits-Checkliste für kleine Unternehmen: 18 Schritte zu Richtlinien, MFA, Passwortmanagement, Netzwerksicherheit, Backups und Incident Response, bewertet nach Kosten und Wirkung.

PassworkPasswork Team

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

Das Speichern von Passwörtern in Slack und im Browser setzt Ihr Unternehmen Sicherheitsvorfällen aus. Erfahren Sie, warum persönliche Tools für Teams versagen, wie Sie ausscheidende Mitarbeiter mit einem Klick sicher offboarden und warum die aktuellen NIST-Richtlinien von einer erzwungenen Passwort-Rotation abraten.

Passwork BlogAlex Muntyan

Passwork vs. Bitwarden: Wie sich die Tresor-Verschlüsselungsarchitektur unterscheidet

Passwork verschlüsselt jeden Tresor mit einem eigenen Schlüssel. Bitwarden verschlüsselt eine gesamte Organisation mit einem einzigen gemeinsamen Schlüssel. Dieser Vergleich zeigt, was das für den Schadensradius, die Teamisolation, die Kontowiederherstellung und belastbare Audit-Antworten bedeutet, wenn Zugangsdaten durchsickern.

PassworkPasswork Team

La gestión de accesos ocupa el primer lugar en la lista de verificación de ciberseguridad de una pyme, porque determina quién puede abrir los sistemas en los que funciona el negocio. Cuando el acceso no está claro o es excesivo, ni un parche, ni una copia de seguridad ni una herramienta de seguridad pueden impedir de forma fiable que la persona equivocada llegue a los datos de la empresa.

Para una pequeña y mediana empresa (pyme), la gestión de accesos significa controlar cuatro aspectos: 

• Identidad: quién existe en sus sistemas.
• Autenticación: cómo demuestran quiénes son. 
• Autorización: qué pueden hacer una vez dentro.
• Revocación: cómo desaparece ese acceso cuando debe hacerlo. 

La lista de verificación de ciberseguridad para pequeñas empresas de Passwork expone la base completa que necesita una pyme. Este artículo profundiza en una parte de esa base: cómo configurar la identidad, la autenticación, la autorización y la revocación como un sistema que funcione día a día.

Por qué la gestión de accesos es lo primero en la lista de verificación de ciberseguridad de una pyme

La gestión de accesos es lo primero porque todos los demás controles dependen de ella. Las copias de seguridad, la protección de endpoints y las herramientas de monitorización asumen que las cuentas que las utilizan son las correctas, con los permisos correctos, en el momento correcto.

La gestión de identidades y accesos (IAM) es la disciplina que se encarga de esto. NIST describe la IAM como «una capacidad de ciberseguridad fundamental y crítica» centrada en garantizar que las personas y los sistemas adecuados tengan el acceso adecuado a los recursos adecuados en el momento adecuado. La autenticación demuestra que un usuario o sistema es quien dice ser. La autorización decide qué puede hacer ese usuario o sistema una vez que ha iniciado sesión. Ambos pasos deben funcionar para que cualquier control posterior tenga sentido.

Esta dependencia se manifiesta en toda la empresa:

• Las cuentas de correo electrónico y SaaS son la vía de acceso a los restablecimientos de contraseña, los documentos compartidos y los registros de clientes.
• Los derechos de administrador de endpoints determinan si un usuario puede instalar software o desactivar los ajustes de seguridad.
• Las cuentas de administrador de copias de seguridad y los permisos de almacenamiento en la nube determinan si los datos de recuperación pueden alterarse o eliminarse.
• El acceso de contratistas y proveedores determina si las personas externas a la empresa conservan el acceso una vez finalizado un proyecto.
• La respuesta a incidentes depende de la capacidad de desactivar cuentas, revocar sesiones y rastrear quién ha utilizado una credencial concreta.

El informe IBM Cost of a Data Breach Report 2026 sitúa el coste medio mundial de una filtración en 4,99 millones de dólares. Esta cifra ilustra por qué las decisiones de acceso que hay detrás de una filtración tienen un peso real.

Haga un inventario de cada identidad y vía de acceso

Un inventario de identidades enumera todos los tipos de cuenta que pueden acceder a los recursos de la empresa, junto con la persona o el equipo responsable de cada una. Va más allá de una lista genérica de activos porque asigna un propietario a cada entrada, incluidas las cuentas compartidas, automatizadas o ajenas a la nómina.

Empiece separando las identidades humanas de las no humanas. Los empleados y administradores necesitan cuentas individuales. Los proveedores, contratistas y buzones compartidos necesitan un propietario designado, aunque la cuenta la utilice más de una persona. Las cuentas de servicio y las claves de API, las credenciales que usan las aplicaciones para comunicarse entre sí, requieren la misma responsabilidad, ya que a menudo tienen permisos que ninguna cuenta humana posee.

Una contraseña compartida, un token de API o un inicio de sesión en el portal de un proveedor que no se puede sustituir de inmediato sigue necesitando un propietario registrado hoy mismo. Ese único campo convierte un inventario en algo sobre lo que se puede actuar durante una revisión o un incidente.

Autentique identidades sólidas y autorice solo el acceso necesario

La autenticación y la autorización son el punto donde la mayoría de las usurpaciones de cuentas tienen éxito o fracasan. Implantar MFA en las cuentas adecuadas, sustituir los inicios de sesión compartidos por accesos nominales y diseñar roles en función de las funciones reales del puesto cierra las brechas que los atacantes utilizan con más frecuencia para entrar y moverse una vez dentro.

Aplique MFA a las cuentas que controlan el negocio

La autenticación multifactor (MFA), un método de inicio de sesión que exige más de un factor de verificación, debe implantarse mediante controles técnicos y verificarse. CISA indica a las pequeñas empresas que implanten la MFA con controles técnicos y la activen en todas las cuentas de administrador. Empiece por las cuentas de correo electrónico, administrador, acceso remoto, finanzas, almacenamiento en la nube y datos sensibles, ya que son las que ofrecen más alcance a un atacante si se ven comprometidas.

La autenticación resistente al phishing vincula el inicio de sesión al servicio legítimo, lo que hace mucho más difícil reutilizar las credenciales robadas. Las llaves de seguridad FIDO2 y las passkeys son los ejemplos actuales. NIST SP 800-63B Revisión 4 exige que las aplicaciones de Nivel de Garantía del Autenticador 2 (AAL2) ofrezcan una opción resistente al phishing, sin obligar a que sea el único método para todas las empresas. Considérelo la dirección hacia la que avanzar, primero para sus cuentas de mayor riesgo y, a medida que su configuración lo permita, para el resto de los inicios de sesión.

Documente las vías de recuperación por separado. Restrinja quién puede restablecer la MFA de otra persona, proteja cualquier cuenta de emergencia de «rotura de cristal» con un propietario designado y un uso limitado, y revise esa cuenta después de cada uso.

Haga que las credenciales únicas sean viables con un gestor de contraseñas controlado

El credential stuffing es la reutilización automatizada de pares de nombre de usuario y contraseña robados contra otros servicios. Funciona porque las personas reutilizan la misma contraseña en varias cuentas, de modo que una credencial filtrada da a los atacantes una llave que abre varias puertas. El informe Data Breach Investigations Report 2026 de Verizon sitúa el abuso de credenciales en el 13 % de los vectores de acceso inicial y las credenciales en el 28 % de los tipos de datos robados en las filtraciones.

Las contraseñas únicas frenan ese ataque: una credencial filtrada solo desbloquea el servicio del que se filtró. El objetivo práctico son las credenciales únicas y controladas por la organización, con acceso nominal, que sustituyan la hoja de cálculo compartida o el mensaje de chat de los que todavía dependen demasiados equipos. Una política de gestión de contraseñas que exija una contraseña única y generada para cada cuenta da a este objetivo una base escrita. Un gestor de contraseñas diseñado para equipos hace que esa política sea viable día a día, generando y almacenando credenciales mientras controla exactamente quién puede recuperarlas.

Diseñe los roles en función del trabajo y después elimine los derechos de administrador permanentes

El control de acceso basado en roles (RBAC) asigna permisos en función de las funciones actuales del puesto y no del historial acumulado. Todo administrador debería tener también una cuenta estándar independiente para el trabajo diario, de modo que tareas rutinarias como el correo electrónico o la navegación nunca se ejecuten desde un inicio de sesión de alto privilegio.

Un ejemplo breve: el personal de finanzas obtiene acceso a los sistemas contables, el personal de soporte obtiene acceso a la plataforma de atención al cliente y los administradores de TI obtienen acceso administrativo aprobado a la infraestructura. Los propietarios de las aplicaciones aprueban las asignaciones de roles, y TI confirma que la configuración técnica coincide con lo aprobado.

Sustituya el acceso compartido y anónimo por un acceso con responsabilidad

Las cuentas individuales ofrecen mejor trazabilidad que los inicios de sesión compartidos, ya que cada acción se puede atribuir a una persona. Algunas herramientas heredadas y portales de proveedores todavía obligan a usar credenciales compartidas. Cuando esto ocurra, guarde la credencial en una bóveda controlada con acceso de usuario nominal, permisos de mínimo privilegio, un registro de auditoría y un desencadenante de rotación programada.

El bucle de control de acceso de la pyme

El acceso debe cambiar a medida que cambian las personas y los roles, y alguien debe confirmar que el cambio se ha producido realmente. El ciclo de vida de alta, cambio y baja describe los tres momentos en los que hay que actualizar el acceso: cuando alguien se incorpora, cuando cambia de rol y cuando se marcha.

La incorporación, un cambio de puesto, el fin de un contrato, una inactividad prolongada, un cambio de sistema o una sospecha de compromiso deberían activar siempre una actualización del acceso. En lugar de adoptar un plazo universal para la baja de usuarios, documente un nivel de servicio basado en el riesgo para su empresa y confirme en cada caso que se ha cumplido.

Escenario ilustrativo: un responsable de ventas abandona la empresa. TI debe revisar la cuenta del proveedor de identidad, la sesión de correo electrónico activa, el rol en el CRM, los permisos de uso compartido del almacenamiento en la nube, el acceso VPN, el dispositivo móvil y cualquier pertenencia a una bóveda de credenciales. Pasar por alto uno solo de estos puntos deja una vía activa hacia los sistemas de la empresa después de que la persona se haya marchado.

El bucle de control de acceso de la pyme, que se muestra en la tabla siguiente, abarca cinco etapas: inventario, autenticación, autorización, cambio o eliminación, y verificación. Cada etapa corresponde directamente a un control que una pequeña o mediana empresa puede aplicar sin un presupuesto de IAM empresarial.

Cómo gestiona Passwork el acceso a las credenciales

Passwork centraliza las contraseñas y los secretos del equipo, controla quién puede recuperarlos y registra cada evento de acceso, trabajando junto a un proveedor de identidad en lugar de sustituirlo. Se encarga de la autorización y la eliminación del acceso: concede a las personas las credenciales adecuadas y corta ese acceso en el momento en que cambia un rol o una situación laboral.

El flujo de trabajo de credenciales se desarrolla en cuatro pasos:

1. Conecte la fuente de identidad. Vincule Active Directory, LDAP o un proveedor de identidad SAML 2.0, como Microsoft Entra ID, Okta, ADFS o Google Workspace.
2. Asigne los grupos a las bóvedas. Cada grupo del directorio obtiene acceso de lectura, escritura, compartición o solo auditoría a una bóveda o carpeta en función de su rol.
3. Centralice las credenciales. Guarde contraseñas, claves de API y certificados en bóvedas compartidas y propiedad de la organización, en lugar de en almacenes personales del navegador, hojas de cálculo o conversaciones de chat.
4. Audite cada acción. Consulte el registro para ver quién accedió, modificó, compartió o exportó una credencial, y cuándo. Expórtelo a una herramienta SIEM si su equipo de seguridad lo necesita allí.

Passwork gobierna el acceso a las credenciales. No sustituye a la fuente de identidad, al ciclo de vida documentado ni al propietario designado detrás de cada decisión de acceso. Esas responsabilidades siguen siendo de la organización.

Conclusión

Una pequeña empresa no necesita un presupuesto de IAM empresarial para hacer esto bien. Necesita que ocurran cuatro cosas en orden: saber quién tiene acceso, autenticarlo y autorizarlo correctamente, eliminarlo en el momento en que algo cambie y verificar que la eliminación se ha producido realmente. Un propietario, una evidencia, siempre.

Preguntas frecuentes

Lista de verificación de ciberseguridad para pequeñas empresas en 2026

Una lista de verificación de seguridad práctica y alineada con NIST para pequeñas empresas: 18 pasos que abarcan políticas, MFA, gestión de contraseñas, seguridad de red, copias de seguridad y respuesta a incidentes, clasificados por coste e impacto.

PassworkPasswork Team

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

Guardar contraseñas en Slack y en los navegadores expone su negocio a filtraciones. Descubra por qué las herramientas personales fallan a los equipos, cómo dar de baja de forma segura a los empleados que se marchan con un solo clic y por qué las últimas directrices de NIST desaconsejan la rotación forzada de contraseñas.

Passwork BlogAlex Muntyan

Passwork frente a Bitwarden: en qué se diferencia la arquitectura de cifrado de las bóvedas

Passwork cifra cada bóveda con su propia clave. Bitwarden cifra toda una organización con una única clave compartida. Esta comparación desglosa lo que eso significa para el radio de impacto, el aislamiento entre equipos, la recuperación de cuentas y las respuestas de auditoría cuando se filtra una credencial.

PassworkPasswork Team