Passwork Team

Passwork encrypts every vault with its own independent key. Bitwarden encrypts an entire organization with one shared key. That single design choice decides how far a stolen credential can reach: a per-vault key exposes one vault, while a single shared organization key may compromise every corporate item the company owns.

This difference determines the blast radius after a compromise, how account recovery works, and whether one team's incident can spread into another team's data. Both approaches are documented, legitimate zero-knowledge designs. They just carry different operational consequences, and that's what this comparison covers.

You'll feel this difference concretely during an offboarding, during an acquisition where two teams' vaults suddenly need separate handling, or in a post-incident review where you have to state exactly what an attacker could reach with one stolen key. Naming that up front makes the rest of this comparison easier to apply to your own environment, whichever password manager you run today.

How Passwork encrypts vaults

Passwork runs on a zero-knowledge architecture: the server never holds enough information to decrypt vault data, and the master password never leaves the user's device. Every cryptographic key is generated client-side, so the server stores only ciphertext and public keys (security overview, cryptography overview).

Two layers of encryption

Passwork runs two layers of encryption. Server-side encryption (AES-256) protects everything at rest and is always active. Client-side encryption protects sensitive fields before they ever leave the device.

The key hierarchy: From master password to vault key

What matters most for this comparison is the key hierarchy. A master password derives a master key through PBKDF2. That master key decrypts a private RSA key. The private RSA key then decrypts a vault key: a symmetric AES-256 key generated on the client specifically for one vault.

Every vault gets its own vault key, generated independently the moment the vault is created. Each user with access holds a separate encrypted copy of that key, wrapped with their own public RSA key, and only the matching private key can unwrap it. Compromising one vault's key does not expose the key of any other vault.

Isolation below the vault: Records and attachments

The isolation continues below the vault. Each record gets its own record key, encrypted with the vault key, and each file attachment gets its own attachment key, encrypted with the record key. A leaked record key exposes one record, not the whole vault. A leaked attachment key exposes one file. The vault key sits in the middle of that chain, separating one vault's records from every other vault's records, which is the layer this comparison focuses on.

Sharing without exposing the key

Sharing follows the same pattern. Granting a colleague access means the current holder decrypts the vault key with their own private key and re-encrypts it with the recipient's public key. The server only ever handles ciphertext (sharing mechanics). Access levels such as View, Edit, Full access, and Administrator are enforced by the application, not by the cryptography: everyone with access to a vault holds the same underlying key, and permissions govern what the interface lets each person do with it.

How Bitwarden encrypts organization data

Bitwarden encrypts all organization-owned vault data with one shared key: a CSPRNG-derived Organization Symmetric Key generated once for the entire organization. According to Bitwarden's own security whitepaper, this single key decrypts every corporate vault item. The unprotected key itself is never stored on Bitwarden's servers.

One organization key, many cipher keys

Individual items still get their own key. Each cipher (Bitwarden's term for a stored item) has a unique 64-byte Cipher Key. That Cipher Key is wrapped by either a personal User Symmetric Key or, for anything the organization owns, the single Organization Symmetric Key. Unwrapping that one organization key exposes every corporate cipher key at once, because they all trace back to the same parent key.

Collections control access, not encryption

Collections, Bitwarden's grouping mechanism, sit on top of this without changing the cryptography. A collection controls which members and groups can see which items, but adds no separate collection-level key. A single organization key decrypts the contents of every collection belonging to that org, a point confirmed both by Bitwarden's own server documentation. Removing someone from a collection revokes access through membership, not through a cryptographic boundary tied to that specific collection.

Account recovery relies on the same shared key

Account recovery follows the same single-key pattern. When a member enrolls in Bitwarden's account recovery feature, their personal User Symmetric Key gets wrapped with the organization's RSA public key, forming what Bitwarden calls the Account Recovery Key. To recover a locked-out member, the organization's private RSA key unwraps that Account Recovery Key and yields the member's personal encryption key. A single admin holding the Manage account recovery permission can do this for any enrolled member.

Vault policies vs collections

Passwork distinguishes vaults by type, not only by owner. The documentation defines two basic vault types: Company vaults, shared storage with configurable access rights for a team, and Personal vaults, storage created by and initially belonging to a single user.

Both types get identical per-vault key treatment, so a Personal vault is as cryptographically isolated from a Company vault as any two Company vaults are from each other.

Personal vaults can become shared vaults

A Personal vault isn't locked to one person permanently. Its owner can share it with colleagues, and at that point it functions as a shared vault, with access governed the same way as any other shared vault in Passwork.

Custom vault types and mandatory admin assignment

Passwork also lets administrators define an unlimited number of custom vault types, each with its own set of designated administrators and its own access rules. That gives an organization a way to enforce, say, one admin group for finance vaults and a different one for engineering vaults, without relying on ad hoc permission assignments after the fact.

Administrators can also disable Personal vault creation altogether, forcing all data into Company or custom vault types where the admin assignment is mandatory.

How this compares to Bitwarden collections and Enterprise Policies

Bitwarden has no equivalent typed-vault abstraction. Its closest analogue, collections, group items inside an organization but don't isolate them cryptographically: as covered earlier, a single Organization Symmetric Key decrypts every collection's contents, and removing a member from a collection revokes access through membership, not through a separate key boundary. Collections also carry no concept of a dedicated administrator set the way Passwork's Company and custom vault types do.

Bitwarden's Enterprise Policies work at a different layer entirely. Policies like Single organization, Centralize organization ownership, Master password requirements, Require two-step login, and Account recovery administration apply organization-wide, not per collection or vault type (Bitwarden policies documentation). An administrator applying a master-password-strength policy, for example, sets a rule for the whole organization. There's no per-collection or per-vault-type equivalent to scope that rule more narrowly.

The practical difference

Passwork's vault policies give an administrator a structural way to separate individual data from team data, assign accountable admins per type, and keep every instance of either type on its own key. Bitwarden's collections organize access within a single shared key, and its policies configure behavior across an organization that already shares that key, regardless of which collection or data type a given policy targets.

What this means in practice

The key architecture behind each product produces four concrete operational differences: blast radius after a compromise, how cleanly teams can be isolated, how recovery works, and how an audit answers "what could this credential decrypt."

Blast radius of a single compromised secret

In Passwork, a leaked vault key, a leaked private RSA key, or a compromised master password limits an attacker to one vault or to that one user's shared vaults, not the whole organization. In Bitwarden, because every corporate cipher key traces back to one Organization Symmetric Key, compromising that key exposes every vault item the organization owns.

Multi-team isolation

An organization running several teams in Passwork can give each team its own vault, each on its own key, so an incident in one team's vault has no cryptographic path into another team's vault. In Bitwarden, teams are typically separated with collections inside the same organization, which is access control layered on top of one shared organization key.

Recovery model

Passwork's recovery process doesn't restore the original master key. It establishes a new one, and a user keeps access only to vaults where access was already shared with another account beforehand. Bitwarden's account recovery relies on a single organization RSA key pair, so one admin with the right permission can recover any enrolled member without that member having pre-shared anything (account recovery documentation). That's operationally convenient. It also means the organization's recovery RSA private key is a single point of exposure for every enrolled member's vault.

Audit and compliance scoping

When an auditor asks "what could this credential decrypt," Passwork's per-vault model gives a short, specific answer: one vault, or a named list of vaults this user had access to. In Bitwarden's single-organization-key model, the honest answer to the same question is "everything the organization owns," because there's no cryptographic subdivision below the organization level to point to. Neither answer is wrong, but they document very differently in an audit evidence package.

Comparison table

The table below summarizes where the two architectures diverge, from the root key down to sharing and recovery.

Getting practical about it

The question isn't which vendor's cryptography is better in the abstract. It's whether your data actually needs single-key or per-vault isolation. Teams handling regulatory-scoped secrets, a specific client's infrastructure, or a compliance boundary that has to stay separate get a direct benefit from per-vault keys. Teams where everyone already shares full mutual trust get less benefit from the extra isolation.

Both architectures qualify as zero-knowledge. The difference is what a single stolen key can reach afterward: one vault, or the whole organization. That's the number to check against your own risk model before your next security review.

Want to see per-vault key isolation on your own data before deciding? Try Passwork free and test how vault types, admin assignment, and key boundaries hold up against your own security review.

Frequently asked questions

SaaS credential management: 5 steps to centralize your app stack

SaaS credential management turns scattered passwords and API keys into one inventory you can share on purpose and revoke on exit. Here’s the five-step framework: inventory, structure, migration, access control, and automation.

PassworkPasswork Team

Verizon DBIR 2026: 10 stats that should change your security strategy

Verizon’s 2026 DBIR analyzed 22,000+ breaches across 145 countries. Vulnerability exploitation overtook credential abuse as the top attack vector, while ransomware, third-party risk, and AI-assisted attacks all grew sharply. Here are the 10 numbers that matter.

PassworkAlex Muntyan

Passwork’s vault policies: a CIO’s guide to enterprise security

Passwork’s Vault Types bind admin rights to the vault policy itself, not to whoever created it, closing a gap most enterprises don’t even know exists. This guide gives CIOs and CISOs a working model for vault governance, mapped to NIS2 and ISO 27001 requirements.

PassworkPasswork Team

Zentralisierte Passwortverwaltung für KMU bezeichnet die Praxis, alle Geschäftszugangsdaten über eine einzige gesicherte Plattform zu speichern, zu teilen und zu kontrollieren — anstatt über Tabellen, Browser oder Chat-Nachrichten. Sie bietet kleinen und mittelständischen Unternehmen dieselbe Kontrolle über Zugangsdaten, auf die auch Großunternehmen setzen — ohne das Preisschild und ohne das Sicherheitsteam, das für den Betrieb erforderlich wäre.

Die meisten kleinen und mittelständischen Unternehmen „verwalten Passwörter" bereits auf irgendeine Weise. Jemand speichert Zugangsdaten im Browser. Jemand anderes nutzt einen kostenlosen lokalen persönlichen Tresor wie KeePass. Gemeinsam genutzte Admin-Logins für Stripe, Google Workspace oder das ERP befinden sich in einem Slack-Thread vom letzten Jahr. Das ist Passwortspeicherung. Es ist keine zentralisierte Passwortverwaltung.

Im Jahr 2026 bedeutet zentralisierte Passwortverwaltung für KMU ein unternehmenseigenes System, in dem Team-Zugangsdaten in gemeinsamen Tresoren liegen, Zugriff bewusst gewährt wird und ausscheidende Mitarbeiter keine Firmen-Logins mehr sehen — ohne aufwendige Suche. Derselbe Zugangsdaten-Tresor kann menschliche Passwörter und maschinelle Geheimnisse (API-Schlüssel, Tokens, Datenbank-Verbindungsstrings) aufnehmen, da der Stack nicht mehr zwischen „Apps, die Menschen anklicken" und „Apps, die Pipelines aufrufen" unterscheidet.

Was zentralisierte Passwortverwaltung tatsächlich bedeutet

Zentralisierte Passwortverwaltung bedeutet, dass ein unternehmenseigenes System alle gemeinsam genutzten Geschäftszugangsdaten speichert und kontrolliert — mit definierten Rollen, Berechtigungsstufen und einem Nachweis darüber, wer auf was zugegriffen hat. Sie unterscheidet sich von einem persönlichen Passwort-Manager (z. B. KeePass), der die Logins einer einzelnen Person schützt, und von Enterprise Privileged Access Management (PAM), das zusätzlich Sitzungsaufzeichnung und Just-in-Time-Erhöhung für Infrastrukturzugriff bietet.

Ein persönlicher Passwort-Manager löst das Login-Problem einer einzelnen Person. Zentralisierte Passwortverwaltung löst das Problem der Organisation: Wer kann auf was zugreifen, wann und mit wessen Genehmigung. Diese Unterscheidung ist der entscheidende Punkt.

In der Praxis basiert Zentralisierung auf fünf Mechanismen:

1. Ein System of Record für Unternehmenszugangsdaten — nicht fünf inoffizielle Kopien, die über verschiedene Tools verstreut sind.
2. Gemeinsame Tresore und Ordner nach Teams oder Abteilungen strukturiert, sodass die gemeinsame Nutzung von Zugangsdaten dem Organigramm folgt.
3. Zugangslevel, von Nur-Lesen bis Tresor-Admin, damit niemand einen einzigen gemeinsamen Master-Login für das gesamte Büro benötigt.
4. Ein Aktivitätsprotokoll, das beantwortet, wer bestimmte Zugangsdaten angesehen, geändert oder exportiert hat.
5. Raum zum Wachsen. Die Plattform sollte LDAP/AD oder SSO unterstützen, sobald das Unternehmen dafür bereit ist, damit das Identitätsmanagement mit dem Team skaliert, anstatt später ein neues Tool zu erfordern.

Persönliche Passwort-Manager bleiben nützlich für persönliche Konten. Sie versagen, wenn die Zugangsdaten dem Unternehmen gehören: Rechnungsverantwortliche wechseln, Auftragnehmer rotieren, und niemand kann nachweisen, wer noch das AWS-Root-E-Mail-Passwort hat.

Warum KMU dies 2026 stärker spüren

Vier Belastungen kommen gleichzeitig zusammen, und keine davon existierte in dieser Kombination vor fünf Jahren. Ein 40-Personen-Unternehmen betreibt heute Dutzende von SaaS-Tools ohne ein dediziertes Sicherheitsteam, verteilt seine Belegschaft auf Home-Netzwerke und Cafés und fügt zunehmend Zugangsdaten in KI-Tools ein, die niemand geprüft hat.

• SaaS-Wildwuchs ohne eine IT-Abteilung von zwanzig Mitarbeitern. Ein kleines Unternehmen kann am Ende Dutzende von Cloud-Tools betreiben, ohne dass jemand dediziert für die Zugriffsverwaltung zuständig ist. Jedes Tool benötigt ein Admin-Login, und die meisten Teams lösen dies auf die schnelle Art: ein gemeinsames Postfach und ein Passwort, das irgendwo notiert ist, wo jeder es finden kann. Sechs Monate später ist niemand mehr für dieses Passwort verantwortlich, und niemand erinnert sich, wer es gesehen hat.
• Hybrides und Remote-Arbeiten. Ein Passwort über Slack oder E-Mail zu senden war schon riskant, als alle im selben Büro arbeiteten. Wenn sich Mitarbeiter über Heimrouter und private Laptops einloggen, ist Autofill aus einem gemeinsamen Tresor die einzige Option, die kein Eintippen eines Passworts in ein Chat-Fenster erfordert.
• Offboarding-Risiko. Wenn jemand geht, geht alles mit, was in seinem persönlichen Tresor, Browser oder Notizen-App gespeichert war. Ein zentralisierter Passwort-Manager ermöglicht es, das Konto zu deaktivieren, die Person aus jeder Gruppe zu entfernen und die gemeinsamen SaaS-Logins zu rotieren, die nur auf deren Laptop existierten. Ohne dies findet eine Zugriffsüberprüfung erst statt, nachdem etwas schiefgegangen ist.
• Schatten-KI ist das neueste Leck. Mitarbeiter fügen jetzt API-Schlüssel, Datenbank-Strings und Passwörter bei der Fehlerbehebung in ChatGPT oder Copilot ein, und keine dieser Aktivitäten berührt einen Tresor oder ein Audit-Protokoll. Laut IBMs Cost of a Data Breach Report 2026 war Schatten-KI an 43 % der Sicherheitsverletzungen beteiligt — gegenüber 20 % im Vorjahr — und 92 % der Organisationen, die von einer KI-bezogenen Verletzung betroffen waren, fehlten grundlegende KI-Zugriffskontrollen.

Wo steht Ihr Unternehmen tatsächlich bei der Passwortverwaltung

Die meisten KMU befinden sich in einer von vier erkennbaren Phasen — von Ad-hoc-Chaos bis hin zu zentralisierter Governance. Jede Phase birgt ein spezifisches Risiko, und der Übergang zur nächsten schließt es.

Phase 1: Ad-hoc-Chaos

Tabellen, Haftnotizen, Slack-Direktnachrichten mit eingefügtem Passwort.

Phase 2: Browser-basierte Speicherung

Chrome oder Edge speichert die Passwörter.

Phase 3: Einfacher Passwort-Manager

Ein Team hat ein Tool eingeführt, aber niemand verwaltet es.

Phase 4: Zentralisierte Governance

Ein strukturierter Tresor, RBAC, Audit-Protokollierung und eine durchgesetzte Richtlinie arbeiten zusammen. Das Risiko sinkt deutlich.

Laut Verizons Data Breach Investigations Report 2026 tauchten gestohlene oder wiederverwendete Zugangsdaten bei 39 % aller Sicherheitsverletzungen auf — in der Regel gepaart mit einer ausgenutzten Schwachstelle oder einem kompromittierten Drittanbieter, anstatt allein zu agieren. Diese Angreifer passen ihre Methoden nicht an die Unternehmensgröße an. CrowdStrikes State of SMB Cybersecurity Survey 2025 stellte fest, dass unter KMU, die einen Cyber-Vorfall erlebten, 29 % derjenigen mit weniger als 25 Mitarbeitern von Ransomware betroffen waren — die höchste Rate aller Unternehmensgrößengruppen, größere KMU eingeschlossen.

Die kleinsten Teams sind am wenigsten in der Lage, diesen Treffer zu verkraften. Teams in den Phasen 1 und 2 haben keinen Mechanismus, um kompromittierte Zugangsdaten zu erkennen oder schnell zu widerrufen, weil überhaupt nichts zentralisiert genug ist, um es zu überprüfen. Genau diese Lücke schließt Phase 4.

Warum KMU das Ziel sind, nicht die Ausnahme

KMU sind denselben Verletzungsmustern ausgesetzt wie Organisationen jeder Größe, und Angreifer wählen sie selten nach Branche oder Umsatz aus. Laut Verizons Data Breach Investigations Report 2026 bleibt System Intrusion das häufigste Verletzungsmuster bei kleinen Organisationen — dasselbe Muster, das auch bei Großunternehmen führend ist — und finanziell motivierte externe Akteure führen die meisten dieser Angriffe durch.

„Wir sind zu klein, um interessant zu sein" ist die falsche Einschätzung der Bedrohungslage. Verizons eigene Forscher formulieren es direkt: Angreifer, die KMU treffen, „werfen weite Netze aus" in der Hoffnung, dass genug Opfer zahlen — ohne vorher Unternehmensgröße oder Branche zu recherchieren. Was entscheidet, wer angegriffen wird, ist einfacher und banaler: ob ihre Zugangsdaten bereits kompromittiert waren oder ihre Edge-Geräte eine ungepatchte Lücke hatten.

Die Daten auf Aktionsebene bestätigen dies. Unter den von Verizon analysierten KMU-Verletzungen trat Ransomware in 83 % der Vorfälle auf, die Verwendung gestohlener Zugangsdaten in 39 % und ausgenutzte Schwachstellen in 30 %. Die Ransomware-Zahlen treffen speziell die kleinsten Unternehmen am härtesten: Bei den Ransomware-Fällen, bei denen Verizon die Organisationsgröße bestätigen konnte, waren etwa 96 % der Opfer KMU.

Vor dem Hintergrund solcher Zahlen ist eine Passwort-Plattform mit Preis pro Benutzer pro Monat keine diskussionswürdige Ausgabe. Es sind kleine, vorhersehbare Kosten gegen eine Bedrohung, die nicht nach Unternehmensgröße diskriminiert.

Die Lücke zu schließen, die gestohlene Zugangsdaten hinterlassen, erfordert kein großes Budget oder eine lange Einführungsphase. Testen Sie Passwork kostenlos und sehen Sie, wie ein strukturierter Tresor, rollenbasierte Zugriffskontrolle und Audit-Protokollierung in Ihrer eigenen Infrastruktur aussehen.

Worauf Sie bei einer zentralisierten Passwortverwaltungs-Plattform achten sollten

Eine zentralisierte Passwortverwaltungs-Plattform für KMU benötigt gemeinsame Tresore mit Ordnerstruktur, granulare RBAC, vollständige Audit-Protokollierung, erzwungene MFA und ein Bereitstellungsmodell, das zu Ihren Compliance-Anforderungen passt — ob Self-Hosted oder Cloud-Hosted. Automatisiertes Offboarding und API-Zugriff werden relevant, sobald das Team über eine Handvoll Personen hinauswächst.

Hier ist, was Sie vor der Auswahl prüfen sollten:

Tresorstruktur

Ordner oder Tags, die nach Abteilungen organisiert sind, halten Zugangsdaten auffindbar, ohne dass eine Suchleiste die ganze Arbeit erledigen muss.

Passwork organisiert Zugangsdaten in Tresoren und verschachtelten Ordnern, die auf Abteilungen und Projekte abgebildet sind. Das Hinzufügen eines neuen Benutzers sollte nicht bedeuten, durch zwanzig Passwörter klicken zu müssen. Die spätere Zuordnung von Verzeichnisgruppen (LDAP/AD) ist optional — die Gruppen-Gewohnheit sollte vom ersten Tag an beginnen.

RBAC-Granularität

Gute Plattformen trennen zwei Berechtigungsebenen: Systemrollen (wer kann Benutzer einladen, SSO konfigurieren, Protokolle lesen) und Ressourcen-Zugangslevel (wer kann einen bestimmten Tresor oder Ordner sehen oder bearbeiten). Die meisten Mitarbeiter benötigen nur Lese- oder Schreibzugriff auf den Tresor ihres eigenen Teams. Admin-Rollen sollten selten bleiben.

Passwork wird mit vordefinierten Rollen ausgeliefert und ermöglicht das Erstellen benutzerdefinierter Rollen, wie AD Administrator oder DevOps, die genau auf die Berechtigungen beschränkt sind, die diese Rolle benötigt. Diese Trennung ist in der Praxis wichtig: Ein Auditor, der das Protokoll überprüfen kann, sollte nicht automatisch Tresorinhalte bearbeiten können, und ein Systemadministrator, der LDAP-Sync verwaltet, sollte keinen Zugriff auf die Zugangsdaten der Finanzabteilung benötigen.

Audit-Protokollierung

Das Protokoll sollte Ansichten, Bearbeitungen und Exporte abdecken — nicht nur Anmeldungen. Ohne dies hat „Wer hat letzten Monat auf die Datenbank-Zugangsdaten des Kunden zugegriffen" keine Antwort.

Das Aktivitätsprotokoll von Passwork zeichnet jede Aktion im System auf. Wenn sich die Berechtigungen eines Ordners ändern oder ein Masterpasswort zurückgesetzt wird, erscheint der Eintrag sofort — durchsuchbar nach Benutzer, Datum oder Aktionstyp.

MFA-Durchsetzung

NIST SP 800-63B empfiehlt Multi-Faktor-Authentifizierung für jedes Konto mit erhöhtem Zugriff. Erzwingen Sie sie für jede Rolle, die sensible Tresore sehen kann — nicht nur für das Admin-Konto.

Passwork unterstützt MFA auf Kontoebene und ermöglicht es Administratoren, sie organisationsweit zu verlangen, anstatt sie pro Benutzer optional zu belassen. Das schließt die Lücke, bei der der CEO Zwei-Faktor-Authentifizierung aktiviert, aber der Auftragnehmer mit Datenbankzugriff sich nie darum kümmert.

Automatisiertes Offboarding

Ein Klick sollte den Tresorzugriff eines ausscheidenden Mitarbeiters über jeden gemeinsamen Ordner hinweg deaktivieren, den er berührt hat — nicht fünfzehn separate Widerrufe.

In Passwork widerruft das Deaktivieren eines einzelnen Benutzerkontos sofort dessen Zugriff auf alle Tresore und Ordner, für die Berechtigungen bestanden — unabhängig davon, wie viele Teams oder Projekte das umfasste.

Das Sicherheits-Dashboard zeigt genau, worauf dieses Konto vor der Deaktivierung zugreifen konnte, sodass ein Administrator, der einen Offboarding-Fall überprüft, die Zugriffshistorie nicht aus dem Gedächtnis oder allein aus dem Audit-Protokoll rekonstruieren muss.

Browser-Erweiterung, Desktop- und Mobile-Apps

Autofill aus einem gemeinsamen Tresor schlägt das Kopieren eines Passworts aus einem Chat-Thread. Die Akzeptanz hängt davon ab.

Die Browser-Erweiterung von Passwork funktioniert mit Chrome, Firefox, Edge und Safari und füllt Zugangsdaten direkt aus gemeinsamen Tresoren aus, ohne die Seite zu verlassen. Mobile- und Desktop-Apps decken denselben Bereich für Mitarbeiter ab, die Tresorzugriff außerhalb eines Browsers benötigen — insbesondere Außendiensttechniker und Remote-Vertriebsmitarbeiter.

Das Sicherheits-Dashboard zeigt genau, worauf dieses Konto vor der Deaktivierung zugreifen konnte, sodass ein Administrator, der einen Offboarding-Fall überprüft, die Zugriffshistorie nicht aus dem Gedächtnis oder allein aus dem Audit-Protokoll rekonstruieren muss.

API-Zugriff

Anfangs optional. Wird relevant, sobald Teams beginnen, Geheimnisse in CI/CD-Pipelines zu ziehen, anstatt sie in .env-Dateien zu committen.

Die REST API von Passwork ermöglicht es DevOps-Teams, Geheimnisse zum Zeitpunkt des Deployments programmatisch abzurufen, Zugangsdaten nach einem Zeitplan zu rotieren und den Tresorzugriff in bestehende Automatisierung zu integrieren, anstatt Schlüssel manuell zwischen Systemen zu kopieren. Dies ist der Punkt, an dem ein Passwort-Manager aufhört, eine Browser-Bequemlichkeit zu sein, und beginnt, als Infrastruktur zu fungieren.

Raum zum Wachsen: SSO und LDAP

Nichts davon erfordert SSO oder LDAP am ersten Tag. Ein Fünf-Personen-Team kann vollständig mit lokalen Konten und manuellen Einladungen arbeiten. In dem Moment, in dem die Mitarbeiterzahl 20 bis 30 überschreitet, oder die Organisation bereits Active Directory für alles andere betreibt, wird die manuelle Benutzerverwaltung zu einem Teilzeitjob.

Die LDAP/AD-Integration synchronisiert Ihre bestehende Verzeichnisstruktur in das Gruppen- und Rollensystem von Passwork. Ein neuer Mitarbeiter, der der „Developer"-AD-Gruppe hinzugefügt wird, erbt automatisch den entsprechenden Tresorzugriff — ohne separaten Bereitstellungsschritt in Passwork selbst.

Der praktische Nutzen zeigt sich wieder beim Offboarding. Deaktivieren Sie einen Benutzer in Active Directory, und sein Passwork-Zugriff verschwindet im selben Synchronisierungszyklus.

Fazit

Zentralisierte Passwortverwaltung ist keine Enterprise-Funktion, die für kleine Teams herunterskaliert wurde. Es ist eine gezielte Kontrolle gegen den Angriffsvektor, der KMU am härtesten trifft: Zugangsdaten, die gültig blieben, nachdem sie hätten widerrufen werden sollen.

Beginnen Sie diese Woche mit einer Pilotabteilung. Importieren Sie deren Zugangsdaten in Passwork, richten Sie gruppenbasierten Zugriff ein und legen Sie einen Umstellungstermin fest, um die Tabelle endgültig außer Dienst zu stellen.

Wenn Ihr Team Zugangsdaten über Tabellen, Chat oder Browser-Speicherung teilt, bietet Passwork einen Self-Hosted-Tresor mit RBAC, Audit-Protokollierung und Offboarding mit einem Klick — ohne Enterprise-Preise. Richten Sie Passwork auf Ihrer Infrastruktur ein und hören Sie auf, sich zu fragen, wer noch das WLAN-Passwort von vor drei Einstellungen hat.

Häufig gestellte Fragen

Was ist Schatten-KI: Die versteckte Bedrohung, die Unternehmen 670.000 $ pro Sicherheitsverletzung kostet

Schatten-KI kostet Unternehmen 670.000 $ extra pro Sicherheitsverletzung — und das meiste davon lässt sich auf Zugangsdaten zurückführen, die in öffentliche LLMs eingefügt wurden. Erfahren Sie, wie Schatten-KI tatsächlich aussieht, warum sie schwerer zu stoppen ist als Schatten-IT und wie man sie steuert.

PassworkAlex Muntyan

SaaS-Zugangsdatenverwaltung: 5 Schritte zur Zentralisierung Ihres App-Stacks

SaaS-Zugangsdatenverwaltung verwandelt verstreute Passwörter und API-Schlüssel in ein Inventar, das Sie gezielt teilen und beim Ausscheiden widerrufen können. Hier ist das Fünf-Schritte-Framework: Inventur, Struktur, Migration, Zugriffskontrolle und Automatisierung.

PassworkPasswork Team

Passwork gewinnt Top Performer Sommer 2026 auf SourceForge

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

PassworkPasswork Team

La gestión centralizada de contraseñas para pymes es la práctica de almacenar, compartir y controlar todas las credenciales empresariales a través de una plataforma segura en lugar de hojas de cálculo, navegadores o mensajes de chat. Proporciona a las pequeñas y medianas empresas el mismo control de credenciales en el que confían las grandes corporaciones, sin el coste elevado ni el equipo de seguridad necesario para gestionarlo.

La mayoría de las pequeñas y medianas empresas ya «gestionan contraseñas». Alguien guarda las credenciales en un navegador. Otra persona utiliza una bóveda personal local gratuita como KeePass. Los inicios de sesión de administrador compartidos para Stripe, Google Workspace o el ERP están en un hilo de Slack del año pasado. Eso es almacenamiento de contraseñas. No es gestión centralizada de contraseñas.

En 2026, la gestión centralizada de contraseñas para pymes significa un sistema propiedad de la organización donde las credenciales del equipo residen en bóvedas compartidas, el acceso se otorga de forma intencional y los empleados que se marchan dejan de ver los inicios de sesión de la empresa sin necesidad de una búsqueda exhaustiva. La misma bóveda de credenciales puede contener contraseñas humanas y secretos de máquinas (claves API, tokens, cadenas de conexión de bases de datos) porque la infraestructura ya no separa «aplicaciones que las personas usan» de «aplicaciones que los pipelines invocan».

Qué significa realmente la gestión centralizada de contraseñas

La gestión centralizada de contraseñas significa que un sistema propiedad de la organización almacena y controla todas las credenciales empresariales compartidas, con roles definidos, niveles de permisos y un registro de quién accedió a qué. Es distinta de un gestor de contraseñas personal (por ejemplo, KeePass), que protege los inicios de sesión de una sola persona, y de la gestión de acceso privilegiado (PAM) empresarial, que añade grabación de sesiones y elevación justo a tiempo para el acceso a infraestructura.

Un gestor de contraseñas personal resuelve el problema de inicio de sesión de una persona. La gestión centralizada de contraseñas resuelve el problema de la organización: quién puede acceder a qué, cuándo y con la aprobación de quién. Esa distinción es el punto central.

En la práctica, la centralización se basa en cinco mecanismos:

1. Un sistema único de registro para las credenciales de la empresa, no cinco copias no oficiales dispersas entre herramientas.
2. Bóvedas y carpetas compartidas mapeadas a equipos o departamentos, para que el intercambio de credenciales siga el organigrama.
3. Niveles de acceso, desde solo lectura hasta administrador de bóveda, para que nadie necesite un único inicio de sesión maestro compartido para toda la oficina.
4. Un registro de actividad que responda quién vio, cambió o exportó una credencial determinada.
5. Capacidad de crecimiento. La plataforma debe soportar LDAP/AD o SSO cuando la empresa esté preparada, para que la gestión de identidades escale con el equipo en lugar de requerir una nueva herramienta más adelante.

Los gestores de contraseñas personales siguen siendo útiles para cuentas personales. Fallan cuando la credencial pertenece a la empresa: los propietarios de facturación cambian, los contratistas rotan y nadie puede demostrar quién todavía tiene la contraseña del correo raíz de AWS.

Por qué las pymes lo sienten más difícil en 2026

Cuatro presiones se acumulan a la vez, y ninguna existía en esta combinación hace cinco años. Una empresa de 40 personas ahora ejecuta docenas de herramientas SaaS sin un equipo de seguridad dedicado, divide su fuerza laboral entre redes domésticas y cafeterías, y cada vez más pega credenciales en herramientas de IA que nadie ha evaluado.

• Proliferación de SaaS sin un departamento de TI de veinte personas. Una pequeña empresa puede terminar ejecutando docenas de herramientas en la nube sin nadie dedicado a gestionar el acceso. Cada herramienta necesita un inicio de sesión de administrador, y la mayoría de los equipos resuelven esto de forma rápida: un buzón compartido y una contraseña escrita en algún lugar donde todos puedan encontrarla. Nadie es propietario de esa contraseña seis meses después, y nadie recuerda quién la ha visto.
• Trabajo híbrido y remoto. Enviar una contraseña por Slack o correo electrónico ya era arriesgado cuando todos trabajaban desde una sola oficina. Con personas iniciando sesión desde routers domésticos y portátiles personales, el autocompletado desde una bóveda compartida es la única opción que no implica escribir una contraseña en una ventana de chat.
• Riesgo en la baja de empleados. Cuando alguien se va, lo que residía en su bóveda personal, navegador o aplicación de notas se va con esa persona. Un gestor de contraseñas centralizado permite desactivar la cuenta, eliminarla de todos los grupos y rotar los inicios de sesión SaaS compartidos que existían solo en su portátil. Sin él, la revisión de acceso ocurre solo después de que algo sale mal.
• La IA en la sombra es la fuga más reciente. Los empleados ahora pegan claves API, cadenas de bases de datos y contraseñas en ChatGPT o Copilot mientras solucionan problemas, y ninguna de esas actividades toca una bóveda o un registro de auditoría. Según el informe Cost of a Data Breach 2026 de IBM, la IA en la sombra estuvo involucrada en el 43% de las brechas, frente al 20% del año anterior, y el 92% de las organizaciones afectadas por una brecha relacionada con IA carecían de controles básicos de acceso a IA.

¿En qué punto se encuentra realmente su empresa en la gestión de contraseñas?

La mayoría de las pymes se encuentran en una de cuatro etapas reconocibles, desde el caos improvisado hasta la gobernanza centralizada. Cada etapa conlleva un riesgo específico, y pasar a la siguiente lo cierra.

Etapa 1: Caos improvisado

Hojas de cálculo, notas adhesivas, mensajes directos de Slack con una contraseña pegada.

Etapa 2: Almacenamiento en el navegador

Chrome o Edge guardan las contraseñas.

Etapa 3: Gestor de contraseñas básico

Un equipo adoptó una herramienta, pero nadie la gobierna.

Etapa 4: Gobernanza centralizada

Una bóveda estructurada, RBAC, registro de auditoría y una política aplicada trabajan juntos. El riesgo se reduce drásticamente.

Según el Data Breach Investigations Report 2026 de Verizon, las credenciales robadas o reutilizadas aparecieron en el 39% de todas las brechas, generalmente combinadas con una vulnerabilidad explotada o un tercero comprometido en lugar de actuar solas. Estos atacantes no calibran sus métodos según el tamaño de la empresa. La encuesta State of SMB Cybersecurity Survey 2025 de CrowdStrike encontró que entre las pymes que experimentaron un incidente cibernético, el 29% de aquellas con menos de 25 empleados fueron afectadas por ransomware, la tasa más alta de cualquier grupo de tamaño de empresa, incluidas las pymes más grandes.

Los equipos más pequeños son los menos preparados para absorber ese golpe. Los equipos que se encuentran en las etapas 1 y 2 no tienen ningún mecanismo para detectar una credencial comprometida o revocarla rápidamente, porque nada está lo suficientemente centralizado como para verificar en primer lugar. Esa brecha es exactamente lo que cierra la etapa 4.

Por qué las pymes son el objetivo, no la excepción

Las pymes enfrentan los mismos patrones de brecha que las organizaciones de cualquier tamaño, y los atacantes rara vez las seleccionan según su industria o ingresos. Según el Data Breach Investigations Report 2026 de Verizon, la intrusión en sistemas sigue siendo el principal patrón de brecha en las organizaciones pequeñas, el mismo patrón que lidera en las grandes empresas también, y los actores externos con motivación financiera llevan a cabo la mayoría de estos ataques.

«Somos demasiado pequeños para importar» es una lectura incorrecta de la amenaza. Los propios investigadores de Verizon lo expresan claramente: los atacantes que golpean a las pymes están «lanzando redes amplias» esperando que suficientes víctimas paguen, no investigando primero el tamaño o sector de la empresa. Lo que decide quién sufre una brecha es más simple y mundano: si sus credenciales ya estaban comprometidas o si sus dispositivos perimetrales tenían un agujero sin parchear.

Los datos a nivel de acción respaldan esto. Entre las brechas de pymes que Verizon analizó, el ransomware apareció en el 83% de los incidentes, el uso de credenciales robadas en el 39% y las vulnerabilidades explotadas en el 30%. Las cifras de ransomware golpean más fuerte específicamente a las empresas más pequeñas: de los casos de ransomware donde Verizon pudo confirmar el tamaño de la organización, aproximadamente el 96% de las víctimas eran pymes.

Frente a números como estos, una plataforma de contraseñas con precio por usuario al mes no es un gasto que valga la pena debatir. Es un coste pequeño y predecible frente a una amenaza que no discrimina por tamaño de empresa.

Cerrar la brecha que dejan las credenciales robadas no requiere un gran presupuesto ni una implementación prolongada. Pruebe Passwork gratis y vea cómo una bóveda estructurada, control de acceso basado en roles y registro de auditoría funcionan en su propia infraestructura.

Qué buscar en una plataforma de gestión centralizada de contraseñas

Una plataforma de gestión centralizada de contraseñas para pymes necesita bóvedas compartidas con estructura de carpetas, RBAC granular, registro de auditoría completo, MFA obligatorio y un modelo de implementación que coincida con sus necesidades de cumplimiento, ya sea autoalojado o en la nube. La baja automatizada y el acceso API son importantes una vez que el equipo crece más allá de un puñado de personas.

Esto es lo que debe verificar antes de elegir una:

Estructura de la bóveda

Las carpetas o etiquetas organizadas por departamento mantienen las credenciales localizables sin que la barra de búsqueda haga todo el trabajo.

Passwork organiza las credenciales en bóvedas y carpetas anidadas que se mapean a departamentos y proyectos. Añadir un nuevo usuario no debería significar hacer clic en veinte contraseñas. Mapear grupos de directorio (LDAP/AD) más adelante es opcional — el hábito de grupos debería comenzar desde el primer día.

Granularidad del RBAC

Las buenas plataformas separan dos capas de permisos: roles del sistema (quién puede invitar usuarios, configurar SSO, leer registros) y niveles de acceso a recursos (quién puede ver o editar una bóveda o carpeta específica). La mayoría del personal solo necesita acceso de lectura o escritura a la bóveda de su propio equipo. Los roles de administrador deberían ser escasos.

Passwork viene con roles predefinidos y permite crear roles personalizados, como AD Administrator o DevOps, delimitados exactamente a los permisos que ese rol necesita. Esta separación importa en la práctica: un auditor que puede revisar el registro no debería automáticamente poder editar el contenido de la bóveda, y un administrador del sistema que gestiona la sincronización LDAP no debería necesitar acceso a las credenciales de Finanzas.

Registro de auditoría

El registro debe cubrir visualizaciones, ediciones y exportaciones, no solo inicios de sesión. Sin esto, «quién accedió a las credenciales de la base de datos del cliente el mes pasado» no tiene respuesta.

El registro de actividad de Passwork registra cada acción en el sistema. Cuando los permisos de una carpeta cambian o se restablece una contraseña maestra, la entrada aparece inmediatamente, buscable por usuario, fecha o tipo de acción.

Aplicación de MFA

NIST SP 800-63B recomienda la autenticación multifactor para cualquier cuenta con acceso elevado. Aplíquelo a cualquier rol que pueda ver bóvedas sensibles, no solo a la cuenta de administrador.

Passwork soporta MFA a nivel de cuenta y permite a los administradores requerirlo en toda la organización en lugar de dejarlo como opcional por usuario. Esto cierra la brecha donde el CEO habilita la autenticación de dos factores pero el contratista con acceso a la base de datos nunca se molesta.

Baja automatizada

Un solo clic debería desactivar el acceso a la bóveda de un empleado saliente en todas las carpetas compartidas que tocó, no quince revocaciones separadas.

En Passwork, desactivar la cuenta de un solo usuario revoca inmediatamente su acceso en todas las bóvedas y carpetas en las que tenía permisos, independientemente de cuántos equipos o proyectos abarcara.

El panel de Seguridad muestra exactamente a qué podía acceder esa cuenta antes de la desactivación, para que un administrador revisando un caso de baja no tenga que reconstruir el historial de acceso de memoria o solo del registro de auditoría.

Extensión de navegador, aplicaciones de escritorio y móvil

El autocompletado desde una bóveda compartida supera copiar una contraseña de un hilo de chat. La adopción depende de ello.

La extensión de navegador de Passwork funciona con Chrome, Firefox, Edge y Safari, autocompletando credenciales directamente desde bóvedas compartidas sin salir de la página. Las aplicaciones móviles y de escritorio cubren el mismo terreno para el personal que necesita acceso a la bóveda fuera de un navegador, técnicos de campo y representantes de ventas remotos en particular.

El panel de Seguridad muestra exactamente a qué podía acceder esa cuenta antes de la desactivación, para que un administrador revisando un caso de baja no tenga que reconstruir el historial de acceso de memoria o solo del registro de auditoría.

Acceso API

Opcional al principio. Se vuelve relevante una vez que los equipos comienzan a extraer secretos en pipelines CI/CD en lugar de confirmarlos en archivos .env.

La REST API de Passwork permite a los equipos de DevOps extraer secretos programáticamente en el momento del despliegue, rotar credenciales en un horario e integrar el acceso a la bóveda en la automatización existente en lugar de copiar manualmente claves entre sistemas. Este es el punto donde un gestor de contraseñas deja de ser una comodidad de navegación y comienza a funcionar como infraestructura.

Capacidad de crecimiento: SSO y LDAP

Nada de lo anterior requiere SSO o LDAP desde el primer día. Un equipo de cinco personas puede funcionar completamente con cuentas locales e invitaciones manuales. En el momento en que el personal supera los 20 a 30, o la organización ya ejecuta Active Directory para todo lo demás, la gestión manual de usuarios se convierte en un trabajo a tiempo parcial.

La integración LDAP/AD sincroniza su estructura de directorio existente en el sistema de grupos y roles de Passwork, de modo que un nuevo empleado añadido al grupo AD «Developer» hereda automáticamente el acceso correspondiente a la bóveda, sin un paso de aprovisionamiento separado en Passwork mismo.

El beneficio práctico aparece en la baja, nuevamente. Desactive un usuario en Active Directory, y su acceso a Passwork desaparece en el mismo ciclo de sincronización.

Conclusión

La gestión centralizada de contraseñas no es una función empresarial reducida para equipos pequeños. Es un control específico contra el vector de brecha que golpea más fuerte a las pymes: credenciales que permanecieron válidas después de que deberían haber sido revocadas.

Comience con un departamento piloto esta semana. Importe sus credenciales en Passwork, configure el acceso basado en grupos y elija una fecha de transición para retirar la hoja de cálculo definitivamente.

Si su equipo comparte credenciales a través de hojas de cálculo, chat o almacenamiento del navegador, Passwork le ofrece una bóveda autoalojada con RBAC, registro de auditoría y baja con un solo clic, sin precios empresariales. Configure Passwork en su infraestructura y deje de preguntarse quién todavía tiene la contraseña del Wi-Fi de hace tres contrataciones.

Preguntas frecuentes

Qué es la IA en la sombra: La amenaza oculta que cuesta a las empresas $670K por brecha

La IA en la sombra cuesta a las empresas $670K adicionales por brecha — y la mayoría se remonta a credenciales pegadas en LLMs públicos. Aprenda cómo es realmente la IA en la sombra, por qué es más difícil de detener que la TI en la sombra, y cómo gobernarla.

PassworkAlex Muntyan

Gestión de credenciales SaaS: 5 pasos para centralizar su stack de aplicaciones

La gestión de credenciales SaaS convierte contraseñas dispersas y claves API en un inventario que puede compartir de forma intencional y revocar a la salida. Aquí está el marco de cinco pasos: inventario, estructura, migración, control de acceso y automatización.

PassworkPasswork Team

Passwork gana Top Performer Verano 2026 en SourceForge

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

PassworkPasswork Team

Centralized password management for SMBs is the practice of storing, sharing, and controlling every business credential through one secured platform instead of spreadsheets, browsers, or chat messages. It gives small and mid-sized businesses the same credential control enterprises rely on, minus the price tag and the security team required to run it.

Most small and mid-sized businesses already "manage passwords." Someone keeps credentials in a browser. Someone else uses a free local personal vault like KeePass. Shared admin logins for Stripe, Google Workspace, or the ERP sit in a Slack thread from last year. That is password storage. It is not centralized password management.

In 2026, centralized password management for SMBs means one organization-owned system where team credentials live in shared vaults, access is granted on purpose, and leaving employees stop seeing company logins without a scavenger hunt. The same credential vault can hold human passwords and machine secrets (API keys, tokens, database strings) because the stack no longer separates "apps people click" from "apps pipelines call."

What centralized password management actually means

Centralized password management means one organization-owned system stores and controls every shared business credential, with defined roles, permission levels, and a record of who accessed what. It is distinct from a personal password manager (e.g., KeePass), which protects one person's logins, and from enterprise privileged access management (PAM), which adds session recording and just-in-time elevation for infrastructure access.

A personal password manager solves one person's login problem. Centralized password management solves the organization's problem: who can access what, when, and with whose approval. That distinction is the whole point.

In practice, centralization rests on five mechanics:

1. One system of record for company credentials, not five unofficial copies scattered across tools.
2. Shared vaults and folders mapped to teams or departments, so credential sharing follows the org chart.
3. Access levels, from read-only to vault admin, so nobody needs a single shared master login for the whole office.
4. An activity log that answers who viewed, changed, or exported a given credential.
5. Room to grow. The platform should support LDAP/AD or SSO once the company is ready for them, so identity management scales with the team instead of requiring a new tool later.

Personal password managers remain useful for personal accounts. They break down when the credential belongs to the company: billing owners change, contractors rotate, and nobody can prove who still has the AWS root email password.

Why SMBs feel this harder in 2026

Four pressures stack at once, and none of them existed in this combination five years ago. A 40-person company now runs dozens of SaaS tools without a dedicated security team, splits its workforce across home networks and coffee shops, and increasingly pastes credentials into AI tools nobody vetted.

• SaaS sprawl without an IT department of twenty. A small company can end up running dozens of cloud tools without anyone dedicated to managing access. Each tool needs an admin login, and most teams solve this the fast way: a shared inbox and a password written down somewhere everyone can find it. Nobody owns that password six months later, and nobody remembers who has seen it.
• Hybrid and remote work. Sending a password over Slack or email was already risky when everyone worked from one office. With people logging in from home routers and personal laptops, autofill from a shared vault is the only option that doesn't involve typing a password into a chat window.
• Offboarding risk. When someone leaves, whatever lived in their personal vault, browser, or notes app leaves with them. A centralized password manager lets you disable the account, pull them from every group, and rotate the shared SaaS logins that existed only in their laptop. Without it, access review happens only after something goes wrong.
• Shadow AI is the newest leak. Employees now paste API keys, database strings, and passwords into ChatGPT or Copilot while troubleshooting, and none of that activity touches a vault or an audit log. According to IBM's Cost of a Data Breach Report 2026, shadow AI was involved in 43% of breaches, up from 20% the year before, and 92% of organizations hit by an AI-related breach lacked basic AI access controls.

Where does your business actually stand on password management

Most SMBs fall into one of four recognizable stages, from ad-hoc chaos to centralized governance. Each stage carries a specific risk, and moving to the next closes it.

Stage 1: Ad-hoc chaos

Spreadsheets, sticky notes, Slack DMs with a password pasted in.

Stage 2: Browser-based storage

Chrome or Edge saves the passwords.

Stage 3: Basic password manager

A team adopted a tool, but nobody governs it.

Stage 4: Centralized governance

A structured vault, RBAC, audit logging, and an enforced policy work together. Risk drops sharply.

According to Verizon's 2026 Data Breach Investigations Report, stolen or reused credentials showed up in 39% of all breaches, usually paired with an exploited vulnerability or a compromised third party rather than acting alone. These attackers don't calibrate their methods to company size. CrowdStrike's 2025 State of SMB Cybersecurity Survey found that among SMBs that experienced a cyber incident, 29% of those with fewer than 25 employees were hit by ransomware, the highest rate of any company size group, larger SMBs included.

The smallest teams are the least equipped to absorb that hit. Teams sitting at stages 1 and 2 have no mechanism to detect a compromised credential or revoke it quickly, because nothing is centralized enough to check in the first place. That gap is exactly what stage 4 closes.

Why SMBs are the target, not the exception

SMBs face the same breach patterns as organizations of any size, and attackers rarely single them out based on industry or revenue. According to Verizon's 2026 Data Breach Investigations Report, System Intrusion remains the top breach pattern in small organization breaches, the same pattern that leads across large enterprises too, and financially motivated external actors carry out most of these attacks.

"We're too small to matter" is the wrong read on the threat. Verizon's own researchers put it plainly: attackers hitting SMBs are "casting out wide nets" hoping enough victims pay, not researching company size or sector first. What decides who gets breached is simpler and more mundane: whether their credentials were already compromised or their edge devices had an unpatched hole.

The action-level data backs this up. Among the SMB breaches Verizon analyzed, ransomware appeared in 83% of incidents, the use of stolen credentials in 39%, and exploited vulnerabilities in 30%. The ransomware numbers land hardest on the smallest companies specifically: of the ransomware cases where Verizon could confirm organization size, about 96% of the victims were SMBs.

Set against numbers like these, a password platform priced per user per month is not an expense worth debating. It is a small, predictable cost against a threat that does not discriminate by company size.

Closing the gap that stolen credentials leave open doesn't require a big budget or a long rollout. Try Passwork free and see how a structured vault, role-based access control, and audit logging look in your own infrastructure.

What to look for in a centralized password management platform

A centralized password management platform for SMBs needs shared vaults with folder structure, granular RBAC, complete audit logging, enforced MFA, and a deployment model that matches your compliance needs, whether that's self-hosted or cloud-hosted. Automated offboarding and API access matter once the team scales past a handful of people.

Here is what to check before choosing one:

Vault structure

Folders or tags organized by department keep credentials findable without a search bar doing all the work.

Passwork organizes credentials into vaults and nested folders that map to departments and projects. Adding a new user should not mean clicking through twenty passwords. Mapping directory groups (LDAP/AD) later is optional — the group habit should start on day one.

RBAC granularity

Good platforms separate two layers of permission: system roles (who can invite users, configure SSO, read logs) and resource access levels (who can see or edit a specific vault or folder). Most staff only need read or write access to their own team's vault. Admin roles should stay rare.

Passwork ships with predefined roles and lets you build custom ones, such as AD Administrator or DevOps, scoped to exactly the permissions that role needs. This separation matters in practice: an auditor who can review the log shouldn't automatically be able to edit vault contents, and a system administrator managing LDAP sync shouldn't need access to Finance's credentials.

Audit logging

The log should cover views, edits, and exports, not just logins. Without this, "who accessed the client's database credentials last month" has no answer.

Passwork's activity log records every action in the system. When a folder's permissions change or a master password gets reset, the entry shows up immediately, searchable by user, date, or action type.

MFA enforcement

NIST SP 800-63B recommends multi-factor authentication for any account with elevated access. Enforce it on any role that can see sensitive vaults, not just the admin account.

Passwork supports MFA at the account level and lets administrators require it organization-wide rather than leaving it opt-in per user. That closes the gap where the CEO enables two-factor authentication but the contractor with database access never bothers.

Automated offboarding

One click should disable a departing employee's vault access across every shared folder they touched, not fifteen separate revocations.

In Passwork, disabling a single user's account immediately revokes their access across every vault and folder they had permissions to, regardless of how many teams or projects that spanned.

The Security dashboard shows exactly what that account could reach before deactivation, so an admin reviewing an offboarding case doesn't have to reconstruct access history from memory or the audit log alone.

Browser extension, desktop and mobile apps

Autofill from a shared vault beats copying a password out of a chat thread. Adoption depends on it.

Passwork's browser extension works with Chrome, Firefox, Edge, and Safari, autofilling credentials directly from shared vaults without leaving the page. Mobile and desktop apps cover the same ground for staff who need vault access outside a browser, field technicians and remote sales reps in particular.

The Security dashboard shows exactly what that account could reach before deactivation, so an admin reviewing an offboarding case doesn't have to reconstruct access history from memory or the audit log alone.

API access

Optional at first. Becomes relevant once teams start pulling secrets into CI/CD pipelines instead of committing them to .env files.

Passwork's REST API lets DevOps teams pull secrets programmatically at deploy time, rotate credentials on a schedule, and integrate vault access into existing automation instead of manually copying keys between systems. This is the point where a password manager stops being a browsing convenience and starts functioning as infrastructure.

Room to grow: SSO and LDAP

None of the above requires SSO or LDAP on day one. A five-person team can run entirely on local accounts and manual invites. The moment headcount crosses 20 to 30, or the org already runs Active Directory for everything else, manual user management turns into a part-time job.

LDAP/AD integration syncs your existing directory structure into Passwork's group and role system, so a new hire added to the "Developer" AD group automatically inherits the matching vault access, no separate provisioning step in Passwork itself.

The practical benefit shows up at offboarding, again. Disable a user in Active Directory, and their Passwork access disappears in the same sync cycle.

Bottom line

Centralized password management isn't an enterprise feature scaled down for small teams. It's a targeted control against the breach vector that hits SMBs hardest: credentials that stayed valid after they should have been revoked.

Start with one pilot department this week. Import its credentials into Passwork, set up group-based access, and pick a cutover date to retire the spreadsheet for good.

If your team shares credentials through spreadsheets, chat, or browser storage, Passwork gives you a self-hosted vault with RBAC, audit logging, and one-click offboarding, without enterprise pricing. Set up Passwork on your infrastructure and stop wondering who still has the Wi-Fi password from three hires ago.

Frequently asked questions

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

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

PassworkAlex Muntyan

SaaS credential management: 5 steps to centralize your app stack

SaaS credential management turns scattered passwords and API keys into one inventory you can share on purpose and revoke on exit. Here’s the five-step framework: inventory, structure, migration, access control, and automation.

PassworkPasswork Team

Passwork wins Top Performer Summer 2026 on SourceForge

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

PassworkPasswork Team

Datensouveränität ist die Fähigkeit, physisch, rechtlich und kryptografisch zu bestimmen, wer auf bestimmte Daten zugreifen kann und unter welcher Gerichtsbarkeit. Ein Unternehmen kann auf dem Papier vollständig DSGVO-konform sein und dennoch keine echte Kontrolle darüber haben, wo seine Passwörter gespeichert sind. Bei Unternehmens-Zugangsdaten ist diese Lücke zwischen „konform" und „unter Kontrolle" der Punkt, an dem Sicherheitsverletzungen, behördliche Anfragen und fehlgeschlagene Audits ihren Ursprung haben.

Die Datenschutz-Grundverordnung (DSGVO) setzt die Grundlage, die die meisten Organisationen zur Beurteilung ihrer Datenpraktiken heranziehen: Sie regelt, wie personenbezogene Daten erhoben, gespeichert und übertragen werden. Gemäß Artikel 3 erstreckt sich ihr räumlicher Anwendungsbereich auf jedes Unternehmen, das Daten von EU-Bürgern verarbeitet — unabhängig davon, wo dieses Unternehmen seinen Hauptsitz hat. 

Passwörter und Geheimnisse sind keine gewöhnlichen Daten, weshalb die Passwortverwaltung ein eigenes Souveränitätsmodell benötigt, das von der allgemeinen Dateispeicherung getrennt ist. Sie öffnen den Zugang zu allem anderen, werden ständig zwischen Mitarbeitern weitergegeben und durchlaufen selten die Data Loss Prevention (DLP)- oder Klassifizierungstools, die Verträge und Kundendaten überwachen. Zugangsdaten, die auf dem falschen Server, im falschen Land und unter fremden Verschlüsselungsschlüsseln gespeichert sind, stellen eine Haftung dar, die die meisten Compliance-Checklisten nicht erfassen.

Dieser Artikel erläutert, was Souveränität auf drei Ebenen bedeutet: physischer Standort, Verschlüsselung und Zugriffsgovernance. Er vergleicht On-Premise-, Air-Gapped- und EU-Cloud-Modelle und zeigt, wo ein selbstgehosteter Zero-Knowledge-Passwortmanager wie Passwork in diese Entscheidung passt.

Was Datensouveränität für Zugangsdaten wirklich bedeutet

Datensouveränität ist die Kombination aus drei separaten Kontrollen: wo sich Daten physisch befinden, wer die Verschlüsselungsschlüssel hält und wer den Zugriff darauf regelt. Der Verlust einer dieser drei Komponenten bricht die Souveränität, selbst wenn die anderen beiden solide sind. Die meisten Anbieter bewerben nur die erste.

• Physischer Standort beantwortet, wo sich die Server befinden. Ein in Frankfurt gehosteter Passwortmanager unterliegt weiterhin dem räumlichen Anwendungsbereich der DSGVO — aber das gilt auch für einen in Virginia gehosteten, wenn er Daten von EU-Bürgern verarbeitet. Der Standort ist relevant für die Gerichtsbarkeit, nicht automatisch für die rechtliche Gefährdung.
• Verschlüsselungskontrolle beantwortet, wer die Daten entschlüsseln kann. Wenn der Anbieter die Schlüssel hält, können behördliche Anfragen, Insider oder ein Sicherheitsvorfall in der Infrastruktur des Anbieters Ihre Zugangsdaten offenlegen — unabhängig vom Serverstandort.
• Zugriffsgovernance beantwortet, wer innerhalb Ihrer Organisation was sehen kann. Rollenbasierte Zugriffskontrolle (RBAC) und Audit-Logs bestimmen, ob der Zugriff eines ausscheidenden Mitarbeiters innerhalb von Minuten widerrufen oder erst sechs Monate später entdeckt wird.

Echte Datensouveränität erfordert alle drei Elemente. Das Weglassen einer Komponente reduziert die Architektur auf eine formale Compliance-Checkliste.

Warum Zugangsdaten eine eigene Datenklasse sind

Zugangsdaten verdienen eine separate Behandlung, weil sie hochwertig, weit verbreitet und für Standard-Data-Governance-Tools weitgehend unsichtbar sind. Ein geleakter Kundendatensatz legt einen Datensatz offen. Ein geleaktes Admin-Passwort legt jedes System offen, auf das dieser Admin zugreifen kann — und es funktioniert weiter, bis jemand es rotiert.

Der Data Breach Investigations Report 2026 von Verizon ergab, dass gestohlene Zugangsdaten 13 % der initialen Zugriffsvektoren ausmachten. Diese Zahl verdreifachte sich jedoch (39 %) über den gesamten Verlauf der Sicherheitsverletzung. Passwörter bewegen sich auch ständig: Sie werden beim Onboarding geteilt, in Tickets kopiert, in Chat-Threads eingefügt und weitergeleitet, wenn ein Projekt den Besitzer wechselt. DLP-Tools, die für das Erkennen von Dokumenten-Exfiltration entwickelt wurden, erfassen selten ein Passwort, das in einer Slack-Nachricht gepostet wird.

Diese Kombination aus hoher Auswirkung und geringer Sichtbarkeit ist der Grund, warum die Speicherung von Zugangsdaten ein eigenes Souveränitätsmodell benötigt, anstatt die Richtlinien für allgemeine Dateispeicherung zu übernehmen.

Wo Standard-Cloud-Speicherung rechtliche Reibungspunkte verursacht

Standard-Cloud-Passwortmanager verursachen rechtliche Gefährdung durch Unterauftragsverarbeiter-Ketten, grenzüberschreitende Datenübertragungen und Zugriff durch Anbieter-Mitarbeiter — selbst wenn der Anbieter vollständig DSGVO-konform ist. Verschlüsselung im Ruhezustand beseitigt diese Risiken nicht, wenn der Anbieter und nicht der Kunde die Entschlüsselungsschlüssel hält.

Drei spezifische Reibungspunkte treten bei Beschaffungsprüfungen wiederholt auf:

• Unterauftragsverarbeiter. Die meisten Cloud-Anbieter nutzen unterbeauftragte Infrastruktur-, Monitoring- oder Support-Anbieter. Jeder Unterauftragsverarbeiter ist eine separate Einheit mit eigener Zugriffsoberfläche. Artikel 28(2) der DSGVO verlangt, dass der Auftragsverarbeiter ohne vorherige gesonderte oder allgemeine schriftliche Genehmigung des Verantwortlichen keinen weiteren Auftragsverarbeiter (Unterauftragsverarbeiter) hinzuziehen darf.
• Drittstaaten-Übermittlungen. Kapitel V der DSGVO regelt die Übermittlung personenbezogener Daten außerhalb der EU/des EWR. Artikel 44 legt den Grundsatz fest, dass jede Übermittlung das durch die Verordnung garantierte Schutzniveau nicht untergraben darf. Artikel 46 verlangt geeignete Garantien, wie Standardvertragsklauseln, wenn kein Angemessenheitsbeschluss vorliegt. Zugangsdaten-Tresore, die in einem Drittland gehostet oder zu Backup-Zwecken dorthin repliziert werden, fallen direkt unter dieses Kapitel.
• Anbieter-Mitarbeiterzugriff und rechtliche Anfragen. Wenn der Anbieter technisch in der Lage ist, Kundendaten zu entschlüsseln, unterliegen diese Daten rechtlichen Verfahren in der Gerichtsbarkeit des Anbieters. Eine Vorladung, ein Durchsuchungsbeschluss oder eine ausländische Offenlegungsanordnung kann den Zugriff erzwingen — unabhängig davon, wo Ihr Unternehmen registriert ist.

NIS2 fügt einen vierten Aspekt hinzu: Artikel 21(2)(d) verlangt von wesentlichen und wichtigen Einrichtungen, die Sicherheit der Lieferkette zu bewerten — einschließlich der Anbieter und Tools, die sie zur Verwaltung von Zugangsdaten verwenden. Ein Passwort-Tresor, der bei einem nicht geprüften Drittanbieter-Unterauftragsverarbeiter liegt, fällt genau unter diese Anforderung.

Nichts davon macht Cloud-Speicherung per se nicht-konform. Es bedeutet, dass „DSGVO-konform" eine notwendige, aber keine hinreichende Bedingung für die Souveränität über Zugangsdaten ist.

Die drei Ebenen auf Bereitstellungsmodelle abbilden

Eine Lücke in einer einzelnen Ebene öffnet erneut die Gefährdung, die die anderen beiden schließen sollten. Die folgende Tabelle wendet die drei Kontrollen aus dem ersten Abschnitt — Standort, Entschlüsselung und Zugriff — auf die Modelle an, zwischen denen Organisationen tatsächlich wählen.

• Air-Gapped beschreibt Infrastruktur ohne jeglichen Netzwerkpfad zum Internet — die strengste Form der physischen Isolation.
• Zero-Knowledge bedeutet, dass der Anbieter Ihre Daten unter keinen Umständen lesen kann. 
• Clientseitige Verschlüsselung ist der Mechanismus, der diese Garantie erzeugt: Verschlüsselung und Entschlüsselung erfolgen auf dem Gerät des Benutzers unter Verwendung eines Masterpassworts, das der Anbieter niemals erhält oder speichert. Der Server hält und überträgt somit nur Chiffretext. 

Ein schlecht implementiertes clientseitiges Verschlüsselungsschema — eines mit einem wiederherstellbaren Masterpasswort oder einer schwachen Schlüsselableitungsfunktion — liefert nicht automatisch eine echte Zero-Knowledge-Garantie. Diese Unterscheidung bestimmt, ob „in der Cloud verschlüsselt" tatsächlich etwas für die Souveränität bedeutet.

On-Premise und Air-Gapped: Vollständige Isolation auf Kosten des Betriebsaufwands

On-Premise-Bereitstellung gibt einer Organisation die vollständige physische und kryptografische Kontrolle über ihren Zugangsdaten-Tresor, da die Daten niemals die Infrastruktur verlassen, die die Organisation besitzt und verwaltet. Air-Gapping geht einen Schritt weiter: Die Infrastruktur hat überhaupt keinen Netzwerkpfad zum Internet — das einzige Setup, das externe Netzwerkabhängigkeit vollständig beseitigt.

Isolation vom Anbieter: Zero-Knowledge-Verschlüsselung

Passwork läuft vollständig innerhalb des Unternehmensperimeters, auf Infrastruktur, die die Organisation von Anfang bis Ende kontrolliert. Der Passwort- und Geheimnismanager verschlüsselt und entschlüsselt Daten vollständig auf der Clientseite unter Verwendung eines Schlüssels, der vom Masterpasswort des Benutzers abgeleitet wird. Der Server erhält oder speichert zu keinem Zeitpunkt Klartext — er hält nur verschlüsselte Blobs und verfügt über keinen Schlüssel, der sie entschlüsseln könnte. Für Organisationen mit Air-Gap-Anforderungen und strengen Segmentierungsrichtlinien ist dies oft die einzige Architektur, die interne Sicherheitsrichtlinien erfüllt. 

Eine solche Behauptung sollte nicht auf Vertrauen basieren. Der Quellcode von Passwork ist für das eigene Sicherheitsteam der Organisation zur direkten Prüfung verfügbar — Zeile für Zeile — anstatt sich auf die Beschreibung des Anbieters zu verlassen, wie die Verschlüsselung implementiert ist.

Der operative Kompromiss

Dieses Maß an Isolation hat seinen Preis — bezahlt in operativem Aufwand. On-Premise verlagert Serverwartung, Patching, Backup-Management und Verfügbarkeitsverantwortung vom Anbieter auf Ihr eigenes IT-Team. Jemand muss Updates einspielen, Speicherplatz überwachen, TLS-Zertifikate verwalten und Disaster Recovery handhaben. Für ein kleines IT-Team, das bereits mit anderen Prioritäten ausgelastet ist, sind das echte Kosten. Organisationen, die Self-Hosting wählen, benötigen entweder eine dedizierte Systemadministrator-Ressource oder einen verwalteten internen Prozess, um die Bereitstellung aktuell zu halten.

Die Zero-Knowledge-Verschlüsselung von Passwork hält Ihre Daten für alle außer Ihren eigenen Benutzern unlesbar. Prüfen Sie die Architektur in den Benutzerhandbüchern, bevor Sie Infrastruktur bereitstellen, oder testen Sie die vollständige Bereitstellung kostenlos, um sie auf Ihren eigenen Servern laufen zu sehen.

EU-Cloud-Hosting: Tragfähig, aber nur mit clientseitiger Verschlüsselung

EU-Cloud-Hosting kann jurisdiktionelle Anforderungen für kleinere Teams ohne dediziertes Infrastrukturpersonal erfüllen — aber nur, wenn der Anbieter obligatorische clientseitige Verschlüsselung (CSE) implementiert. Ohne CSE lässt ein EU-gehosteter Tresor den Anbieter weiterhin in der Lage, Kundendaten zu entschlüsseln, was dieselbe Gefährdung wieder öffnet, die das Hosting in der EU schließen sollte.

Bei einem ordnungsgemäßen CSE-Modell verlässt das Masterpasswort niemals das Gerät des Benutzers, und die Server des Anbieters verarbeiten und speichern nur Chiffretext. Selbst mit vollem physischen Zugriff auf den Server kann der Anbieter den Inhalt des Tresors nicht lesen. Dies ist eine wesentlich andere Garantie als „unsere Rechenzentren befinden sich in der EU", was die Gerichtsbarkeit adressiert, aber nichts darüber aussagt, wer die Schlüssel hält.

EU-Cloud-Hosting mit CSE verringert die rechtliche Gefährdung und erfüllt Datenresidenz-Anforderungen für viele Compliance-Frameworks, aber es ist nicht dieselbe Garantie wie vollständige On-Premise-Souveränität. Die Infrastruktur, Netzwerkschicht und physische Hardware bleiben außerhalb der direkten Kontrolle des Kunden. Für Organisationen mit Air-Gap-Vorgaben oder strengen Self-Hosting-Richtlinien ist EU-Cloud kein Ersatz — unabhängig von der Verschlüsselungsstärke.

On-Premise ohne Zero-Knowledge vertraut lokalen Administratoren dennoch Klartextzugriff an. EU-Cloud ohne Zero-Knowledge vertraut dem Infrastrukturpersonal des Anbieters. In beiden Fällen gilt die Garantie nur, wenn das Masterpasswort niemals das Gerät des Benutzers verlässt.

Anbieteraussagen überprüfen: Was der Einkauf prüfen sollte

Souveränitätsaussagen sind nur so glaubwürdig wie die Nachweise Dritter dahinter. Diese Prüfung gilt unabhängig davon, welches Bereitstellungsmodell Sie wählen: Ein Zertifikat sagt Ihnen nicht, wo sich Daten befinden, aber es sagt Ihnen, ob die anderen Aussagen eines Anbieters standhalten. Einkaufsteams sollten eine Self-Hosting-Entscheidung auf interne Admin-Kapazitäten und Richtlinienanforderungen stützen und dann den in die engere Wahl gezogenen Anbieter durch unabhängige Zertifizierung, eigene Prüfung und öffentliche Sicherheitstests validieren.

Vier Prüfungen sind in der Praxis relevant:

• ISO/IEC 27001-Zertifizierung bestätigt, dass ein Informationssicherheits-Managementsystem unabhängig nach dem internationalen Standard geprüft wurde. Passwork besitzt die ISO/IEC 27001:2022-Zertifizierung, ausgestellt von MSECB und überprüfbar über die IAF CertSearch-Datenbank.
• NIS2- und DSGVO-Bereitschaft ist relevant für jede Organisation, die unter den Geltungsbereich einer der beiden Verordnungen fällt. Die Lieferketten-Anforderungen in Artikel 21 von NIS2 erstrecken sich auf die Tools, die wesentliche und wichtige Einrichtungen zur Verwaltung von Zugangsdaten verwenden, während Artikel 32 der DSGVO „geeignete technische und organisatorische Maßnahmen", einschließlich Verschlüsselung, für jedes System verlangt, das personenbezogene Daten verarbeitet. Organisationen, die Anbieter gegen diese Anforderungen bewerten, können den Ansatz von Passwork zur NIS2-Compliance als einen Referenzpunkt heranziehen.
• Quellcode-Prüfrechte bestätigen, dass eine Zero-Knowledge-Behauptung tatsächlich wahr ist und keine Marketing-Sprache. Bei einem echten Zero-Knowledge-Design kann der Anbieter unter keinen Umständen das Masterpasswort eines einzelnen Benutzers wiederherstellen — nicht durch einen Backend-Reset, nicht durch ein Support-Ticket, nicht unter rechtlichem Druck. Wenn ein Benutzer es vergisst, sind die dahinter liegenden Daten absichtlich verloren, weil der Anbieter den Schlüssel nie besessen hat. Passwork öffnet seinen Quellcode für die eigenen Sicherheitsteams der Kunden genau aus diesem Grund: Es ist der Weg zu bestätigen, dass die Verschlüsselungsimplementierung der vom Anbieter beschriebenen Architektur entspricht.
• Öffentliche Penetrationstests liefern Nachweise über die selbst gemeldete Sicherheitslage hinaus. Passwork hat einen unabhängigen Penetrationstest über HackerOne abgeschlossen, der sichere Datenverarbeitung, die OWASP Top 10 und SANS Top 25, Authentifizierung und API-Zugriffskontrolle abdeckt.

Ein Bereitstellungsmodell wählen: Ein Entscheidungsrahmen

Das richtige Bereitstellungsmodell hängt von fünf praktischen Faktoren ab: 

• Air-Gap-Anforderungen 
• Obligatorisches EU-Hosting 
• Größe des Admin-Teams
• Interne Self-Hosting-Richtlinie
• Anforderungen an die Infrastrukturkontrolle

Das Abgleichen dieser Faktoren mit den Bereitstellungsoptionen vermeidet den häufigen Fehler, allein auf Basis von Preis oder Markenbekanntheit zu wählen. Verwenden Sie diese Entscheidungsmatrix für die Datenresidenz von Zugangsdaten, um organisatorische Einschränkungen einem Bereitstellungsmodell zuzuordnen:

Keine dieser Zeilen schließt sich in der Praxis gegenseitig aus. Ein Finanzinstitut könnte On-Premise für seinen Kern-Tresor betreiben und gleichzeitig Cloud-basierte Tools für Workflows mit geringerer Sensibilität akzeptieren. Die Matrix ist ein Ausgangspunkt für das Gespräch mit Sicherheits- und Compliance-Stakeholdern.

Wie die Architektur von Passwork auf diese Ebenen abgebildet wird

Die selbstgehostete Bereitstellung von Passwork adressiert die in diesem Artikel beschriebene Souveränitätslücke, indem sie physische Isolation, Zero-Knowledge-Verschlüsselung und vom Kunden kontrollierte Zugriffsgovernance in einer Architektur vereint. Der Tresor wird auf Infrastruktur bereitgestellt, die der Kunde besitzt — ob auf einem einzelnen Linux-Server, einer Windows Server-Umgebung oder einem Docker-Container in einem Air-Gapped-Netzwerk.

Die Verschlüsselung verwendet AES-256 mit einem Zero-Knowledge-Design, was bedeutet, dass die Infrastruktur — selbst wenn sie kompromittiert würde — nur Chiffretext enthält. Der Zugriff wird durch rollenbasierte Berechtigungen und ein vollständiges Audit-Log geregelt, sodass Administratoren sehen können, wer wann auf welche Zugangsdaten zugegriffen hat, und den Zugriff sofort widerrufen können, wenn jemand die Rolle wechselt oder das Unternehmen verlässt. Die Integration mit AD/LDAP und SAML SSO ermöglicht es, die Zugriffsgovernance an die bestehende Identitätsinfrastruktur anzubinden, anstatt als separates Silo zu laufen.

Dies ist bewusst keine Behauptung, dass Self-Hosting für jeden geeignet ist. Organisationen ohne Air-Gap-Anforderungen oder strenge Self-Hosting-Vorgaben können eine Cloud-Option mit ordnungsgemäßer clientseitiger Verschlüsselung als ausreichend erachten. Der Punkt ist, dass die Architektur strukturell dafür ausgelegt sein muss, wenn vollständige Souveränität die Anforderung ist.

Datensouveränität in der Passwortverwaltung: Wie Sie sie in Ihre Bewertung einbeziehen

Souveränität ist eine fortlaufende Abstimmung zwischen dem Ort, an dem sich Daten befinden, demjenigen, der die Schlüssel hält, und demjenigen, der den Zugriff regelt — und diese Abstimmung muss überprüft werden, wann immer sich Ihre Infrastruktur, Anbieterverträge oder der regulatorische Geltungsbereich ändern.

Beginnen Sie damit, Ihre eigene Organisation anhand der vier Faktoren in der Entscheidungsmatrix zu bewerten: Air-Gap-Anforderung, obligatorisches EU-Hosting, Größe des Admin-Teams und interne Self-Hosting-Richtlinie. Diese Zuordnung wird Ihnen mehr über das richtige Bereitstellungsmodell sagen als jede Marketingseite eines Anbieters.

Der einzige Weg zu bestätigen, dass eine selbstgehostete Architektur zu Ihrer Infrastruktur passt, ist sie dort auszuführen. Passwork bietet eine kostenlose Testversion, die Sie auf Ihren eigenen Servern bereitstellen können — mit vollem Funktionsumfang und ohne dass Daten jemals Ihre Umgebung verlassen.

Häufig gestellte Fragen

SaaS-Zugangsdatenverwaltung: 5 Schritte zur Zentralisierung Ihres App-Stacks

SaaS-Zugangsdatenverwaltung verwandelt verstreute Passwörter und API-Schlüssel in ein Inventar, das Sie gezielt teilen und bei Austritt widerrufen können. Hier ist das Fünf-Schritte-Framework: Inventarisierung, Strukturierung, Migration, Zugriffskontrolle und Automatisierung.

PassworkPasswork Team

Verizon DBIR 2026: 10 Statistiken, die Ihre Sicherheitsstrategie ändern sollten

Der DBIR 2026 von Verizon analysierte über 22.000 Sicherheitsverletzungen in 145 Ländern. Die Ausnutzung von Schwachstellen überholte den Missbrauch von Zugangsdaten als wichtigsten Angriffsvektor, während Ransomware, Drittanbieter-Risiken und KI-gestützte Angriffe stark zunahmen. Hier sind die 10 Zahlen, die zählen.

Passwork BlogAlex Muntyan

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

Zero-Knowledge-Verschlüsselung bedeutet, dass der Server niemals Ihre Entschlüsselungsschlüssel hält — nur Chiffretext. Erfahren Sie, wie die Schlüsselkette funktioniert, wovor sie schützt, wovor nicht, und wie Sie die Behauptung eines Anbieters überprüfen können.

PassworkPasswork Team

La soberanía de datos es la capacidad de determinar — física, legal y criptográficamente — quién puede acceder a un dato y bajo qué jurisdicción. Una empresa puede cumplir plenamente con el RGPD en el papel y aún así no tener control real sobre dónde residen sus contraseñas. Para las credenciales corporativas, esa brecha entre «cumplimiento» y «control» es donde comienzan las filtraciones, los requerimientos judiciales y las auditorías fallidas.

El Reglamento General de Protección de Datos (RGPD) establece la base que la mayoría de las organizaciones utilizan para evaluar sus prácticas de datos: regula cómo se recopilan, almacenan y transfieren los datos personales, y según el Artículo 3, su ámbito territorial se extiende a cualquier empresa que procese datos de residentes de la UE, independientemente de dónde tenga su sede. 

Las contraseñas y los secretos no son datos ordinarios, por eso la gestión de contraseñas necesita su propio modelo de soberanía, separado del almacenamiento general de archivos. Abren el acceso a todo lo demás, se mueven constantemente entre empleados y rara vez pasan por las herramientas de prevención de pérdida de datos (DLP) o clasificación que vigilan contratos y registros de clientes. Una credencial almacenada en el servidor equivocado, en el país equivocado, bajo las claves de cifrado de otra persona, es una responsabilidad que la mayoría de las listas de verificación de cumplimiento no detectan.

Este artículo desglosa lo que la soberanía realmente significa en tres niveles: ubicación física, cifrado y gobernanza de acceso. Compara los modelos on-premise, aislados y de nube en la UE, y muestra dónde encaja un gestor de contraseñas autoalojado y de conocimiento cero como Passwork en esa decisión.

Qué significa realmente la soberanía de datos para las credenciales

La soberanía de datos es la combinación de tres controles separados: dónde residen físicamente los datos, quién posee las claves de cifrado y quién gobierna el acceso. Perder cualquiera de los tres rompe la soberanía, incluso si los otros dos son sólidos. La mayoría de los proveedores solo publicitan el primero.

• La ubicación física responde dónde están los servidores. Un gestor de contraseñas alojado en Fráncfort todavía cae bajo el ámbito territorial del RGPD, pero también uno alojado en Virginia si procesa datos de residentes de la UE. La ubicación importa para la jurisdicción, no automáticamente para la exposición legal.
• El control del cifrado responde quién puede descifrar los datos. Si el proveedor tiene las claves, una solicitud gubernamental, un infiltrado o una brecha en la infraestructura del proveedor pueden exponer sus credenciales independientemente de la ubicación del servidor.
• La gobernanza de acceso responde quién dentro de su organización puede ver qué. El control de acceso basado en roles (RBAC) y los registros de auditoría determinan si el acceso de un empleado que se va se revoca en minutos o se descubre seis meses después.

La verdadera soberanía de datos requiere los tres elementos. Omitir cualquier componente reduce la arquitectura a una lista de verificación de cumplimiento formal.

Por qué las credenciales son una clase de datos distinta

Las credenciales merecen un tratamiento separado porque son de alto valor, alta circulación y en gran medida invisibles para las herramientas estándar de gobernanza de datos. Un registro de cliente filtrado expone un conjunto de datos. Una contraseña de administrador filtrada expone todos los sistemas a los que ese administrador puede acceder, y sigue funcionando hasta que alguien la rota.

El Informe de Investigaciones de Filtraciones de Datos 2026 de Verizon encontró que las credenciales robadas representaron el 13% de los vectores de acceso inicial, pero esa cifra se triplicó (39%) a lo largo de toda la progresión de la filtración. Las contraseñas también se mueven constantemente: compartidas durante la incorporación, copiadas en tickets, pegadas en hilos de chat, reenviadas cuando un proyecto cambia de manos. Las herramientas DLP diseñadas para detectar la exfiltración de documentos rara vez marcan una contraseña enviada en un mensaje de Slack.

Esa combinación de alto impacto y baja visibilidad es la razón por la que el almacenamiento de credenciales necesita su propio modelo de soberanía en lugar de heredar cualquier política que cubra el almacenamiento general de archivos.

Dónde el almacenamiento estándar en la nube introduce fricción legal

Los gestores de contraseñas estándar en la nube introducen exposición legal a través de cadenas de subprocesadores, transferencias de datos transfronterizas y acceso del personal del proveedor, incluso cuando el proveedor cumple plenamente con el RGPD. El cifrado en reposo no elimina estos riesgos si el proveedor, no el cliente, posee las claves de descifrado.

Tres puntos de fricción específicos aparecen repetidamente durante las revisiones de adquisiciones:

• Subprocesadores. La mayoría de los proveedores de nube dependen de infraestructura, monitoreo o proveedores de soporte subcontratados. Cada subprocesador es una entidad separada con su propia superficie de acceso. El Artículo 28(2) del RGPD requiere que el encargado no recurrirá a otro encargado (subprocesador) sin la autorización previa por escrito, específica o general, del responsable.
• Transferencias a terceros países. El Capítulo V del RGPD regula las transferencias de datos personales fuera de la UE/EEE. El Artículo 44 establece el principio general de que cualquier transferencia no debe socavar el nivel de protección garantizado por el reglamento, y el Artículo 46 requiere garantías apropiadas, como las Cláusulas Contractuales Tipo, cuando no aplica ninguna decisión de adecuación. Las bóvedas de credenciales alojadas en un tercer país, o replicadas a uno con fines de copia de seguridad, caen directamente bajo este capítulo.
• Acceso del personal del proveedor y solicitudes legales. Si el proveedor puede técnicamente descifrar los datos del cliente, esos datos están sujetos al proceso legal en la jurisdicción del proveedor. Una citación, orden judicial o solicitud de divulgación extranjera puede obligar el acceso independientemente de dónde esté registrada su empresa.

NIS2 añade un cuarto ángulo: el Artículo 21(2)(d) requiere que las entidades esenciales e importantes evalúen la seguridad de la cadena de suministro, incluyendo los proveedores y herramientas que utilizan para gestionar credenciales de acceso. Una bóveda de contraseñas situada con un subprocesador externo que no ha verificado cae directamente en ese requisito.

Nada de esto hace que el almacenamiento en la nube sea incumplidor por defecto. Significa que «cumple con el RGPD» es una condición necesaria para la soberanía de credenciales.

Mapeo de las tres capas a modelos de despliegue

Una brecha en cualquier capa individual reabre la exposición que las otras dos pretendían cerrar. La tabla siguiente aplica los tres controles de la primera sección — ubicación, descifrado y acceso — a los modelos entre los que las organizaciones realmente eligen.

• Aislado describe una infraestructura sin ninguna ruta de red a internet, la forma más estricta de aislamiento físico.
• Conocimiento cero significa que el proveedor nunca puede leer sus datos, bajo ninguna circunstancia. 
• Cifrado del lado del cliente es el mecanismo que produce esa garantía: el cifrado y descifrado ocurren en el dispositivo del usuario, usando una contraseña maestra que el proveedor nunca recibe ni almacena, por lo que el servidor solo recibe y transmite texto cifrado. 

Un esquema de cifrado del lado del cliente mal implementado — uno con una contraseña maestra recuperable o una función de derivación de clave débil — no proporciona automáticamente una verdadera garantía de conocimiento cero. Esta distinción determina si «cifrado en la nube» realmente significa algo para la soberanía.

On-premise y aislado: Aislamiento completo, a costa de carga operativa

El despliegue on-premise otorga a una organización control físico y criptográfico completo sobre su bóveda de credenciales, porque los datos nunca abandonan la infraestructura que la organización posee y administra. El aislamiento lleva esto un paso más allá: la infraestructura no tiene ninguna ruta de red a internet, que es la única configuración que elimina completamente la dependencia de la red externa.

Aislamiento del proveedor: Cifrado de conocimiento cero

Passwork se ejecuta completamente dentro del perímetro corporativo, en infraestructura que la organización controla de extremo a extremo. El gestor de contraseñas y secretos cifra y descifra los datos completamente en el lado del cliente, usando una clave derivada de la contraseña maestra del usuario. El servidor nunca recibe ni almacena texto sin formato en ningún momento — solo contiene blobs cifrados y no tiene ninguna clave capaz de descifrarlos. Para organizaciones con requisitos de aislamiento y políticas de segmentación estrictas, esta es a menudo la única arquitectura que satisface la política de seguridad interna. 

Una afirmación como esa no debería aceptarse por fe. El código fuente de Passwork está abierto para que el propio equipo de seguridad de la organización lo audite directamente, línea por línea, en lugar de depender de la descripción del proveedor sobre cómo se implementa el cifrado.

La contrapartida operativa

Ese nivel de aislamiento tiene un coste, pagado en esfuerzo operativo. On-premise traslada el mantenimiento del servidor, los parches, la gestión de copias de seguridad y la responsabilidad del tiempo de actividad del proveedor a su propio equipo de TI. Alguien tiene que aplicar actualizaciones, monitorear el espacio en disco, gestionar certificados TLS y manejar la recuperación ante desastres. Para un pequeño equipo de TI ya sobrecargado con otras prioridades, eso es un coste real. Las organizaciones que eligen el autoalojamiento necesitan un recurso de administrador de sistemas dedicado o un proceso interno gestionado para mantener el despliegue actualizado.

El cifrado de conocimiento cero de Passwork mantiene sus datos ilegibles para cualquiera excepto sus propios usuarios. Revise la arquitectura en las guías de usuario antes de comprometer infraestructura, o pruebe el despliegue completo gratis para verlo funcionando en sus propios servidores.

Alojamiento en la nube de la UE: Viable, pero solo con cifrado del lado del cliente

El alojamiento en la nube de la UE puede satisfacer los requisitos jurisdiccionales para equipos más pequeños sin personal de infraestructura dedicado, pero solo si el proveedor implementa cifrado obligatorio del lado del cliente (CSE). Sin CSE, una bóveda alojada en la UE todavía deja al proveedor capaz de descifrar los datos del cliente, lo que reabre la misma exposición que el alojamiento en la UE debía cerrar.

Bajo un modelo CSE adecuado, la contraseña maestra nunca abandona el dispositivo del usuario, y los servidores del proveedor procesan y almacenan solo texto cifrado. Incluso con acceso físico completo al servidor, el proveedor no puede leer el contenido de la bóveda. Esta es una garantía significativamente diferente a «nuestros centros de datos están en la UE», que aborda la jurisdicción pero no dice nada sobre quién tiene las claves.

El alojamiento en la nube de la UE con CSE reduce la exposición legal y satisface los requisitos de residencia de datos para muchos marcos de cumplimiento, pero no es la misma garantía que la soberanía on-premise completa. La infraestructura, la capa de red y el hardware físico permanecen fuera del control directo del cliente. Para organizaciones con mandatos de aislamiento o políticas estrictas de autoalojamiento, la nube de la UE no es un sustituto, independientemente de la fortaleza del cifrado.

On-premise sin conocimiento cero todavía confía a los administradores locales el acceso al texto sin formato. La nube de la UE sin él todavía confía al personal de infraestructura del proveedor. De cualquier manera, la garantía solo se mantiene cuando la contraseña maestra nunca abandona el dispositivo del usuario.

Verificación de las afirmaciones del proveedor: Qué debe comprobar el departamento de compras

Las afirmaciones de soberanía son tan creíbles como la evidencia de terceros que las respalda. Esta verificación se aplica independientemente del modelo de despliegue que elija: un certificado no le dice dónde residen los datos, pero sí le dice si las otras afirmaciones del proveedor se sostienen. Los equipos de compras deben basar una decisión de autoalojamiento en la capacidad administrativa interna y los requisitos de política, luego validar al proveedor preseleccionado a través de certificación independiente, auditoría propia y pruebas de seguridad públicas.

Cuatro verificaciones importan en la práctica:

• La certificación ISO/IEC 27001 confirma que un sistema de gestión de seguridad de la información ha sido auditado de forma independiente según el estándar internacional. Passwork posee certificación ISO/IEC 27001:2022, emitida por MSECB y verificable a través de la base de datos IAF CertSearch.
• La preparación para NIS2 y RGPD importa para cualquier organización que caiga bajo el alcance de cualquiera de las dos regulaciones. Los requisitos de cadena de suministro del Artículo 21 de NIS2 se extienden a las herramientas que las entidades esenciales e importantes utilizan para gestionar credenciales de acceso, mientras que el Artículo 32 del RGPD requiere «medidas técnicas y organizativas apropiadas», incluyendo cifrado, para cualquier sistema que maneje datos personales. Las organizaciones que evalúan proveedores contra estos requisitos pueden revisar el enfoque de Passwork sobre el cumplimiento de NIS2 como un punto de referencia.
• Los derechos de auditoría del código fuente confirman que una afirmación de conocimiento cero es realmente verdadera en lugar de lenguaje de marketing. En un diseño de conocimiento cero genuino, el proveedor no puede recuperar la contraseña maestra de un usuario individual bajo ninguna circunstancia — ni mediante un reinicio del backend, ni mediante un ticket de soporte, ni bajo presión legal. Si un usuario la olvida, los datos detrás de ella desaparecen por diseño, porque el proveedor nunca tuvo la clave en primer lugar. Passwork abre su código fuente a los propios equipos de seguridad de los clientes exactamente por esta razón: es la forma de confirmar que la implementación del cifrado coincide con la arquitectura que el proveedor describe.
• Las pruebas de penetración públicas proporcionan evidencia más allá de la postura de seguridad autodeclarada. Passwork ha completado una prueba de penetración independiente a través de HackerOne, que cubre el manejo seguro de datos, el OWASP Top 10 y SANS Top 25, autenticación y control de acceso a API.

Elección de un modelo de despliegue: Un marco de decisión

El modelo de despliegue correcto depende de cinco factores prácticos: 

• Requisitos de aislamiento 
• Alojamiento obligatorio en la UE 
• Tamaño del equipo de administración
• Política interna de autoalojamiento
• Requisitos de control de infraestructura

Mapear estos factores contra las opciones de despliegue evita el error común de elegir basándose solo en el precio o el reconocimiento de marca. Utilice esta matriz de decisión de residencia de credenciales para mapear las restricciones organizacionales a un modelo de despliegue:

Ninguna de estas filas es mutuamente excluyente en la práctica. Una institución financiera podría ejecutar on-premise para su bóveda principal mientras acepta herramientas basadas en la nube para flujos de trabajo de menor sensibilidad. La matriz es un punto de partida para la conversación con los interesados de seguridad y cumplimiento.

Cómo la arquitectura de Passwork se mapea a estas capas

El despliegue autoalojado de Passwork aborda la brecha de soberanía descrita a lo largo de este artículo combinando aislamiento físico, cifrado de conocimiento cero y gobernanza de acceso controlada por el cliente en una sola arquitectura. La bóveda se despliega en infraestructura que el cliente posee, ya sea un servidor Linux individual, un entorno de Windows Server o un contenedor Docker dentro de una red aislada.

El cifrado utiliza AES-256 con un diseño de conocimiento cero, lo que significa que la infraestructura, si alguna vez fuera comprometida, solo contiene texto cifrado. El acceso se gobierna a través de permisos basados en roles y un registro de auditoría completo, para que los administradores puedan ver quién accedió a qué credencial y cuándo, y revocar el acceso inmediatamente cuando alguien cambia de rol o se va. La integración con AD/LDAP y SAML SSO permite que la gobernanza de acceso se conecte a la infraestructura de identidad existente en lugar de funcionar como un silo separado.

Esto deliberadamente no es una afirmación de que el autoalojamiento sea adecuado para todos. Las organizaciones sin requisitos de aislamiento o mandatos estrictos de autoalojamiento pueden encontrar suficiente una opción en la nube con cifrado del lado del cliente apropiado. El punto es que cuando la soberanía total es el requisito, la arquitectura necesita soportarlo estructuralmente.

Soberanía de datos en la gestión de contraseñas: Cómo aplicarla a su evaluación

La soberanía es una alineación continua entre dónde residen los datos, quién tiene las claves y quién gobierna el acceso — y esa alineación necesita revisarse cada vez que cambia su infraestructura, contratos con proveedores o alcance regulatorio.

Comience mapeando su propia organización contra los cuatro factores de la matriz de decisión: requisito de aislamiento, alojamiento obligatorio en la UE, tamaño del equipo de administración y política interna de autoalojamiento. Ese mapeo le dirá más sobre el modelo de despliegue correcto que cualquier página de marketing de proveedores.

La única forma de confirmar que una arquitectura autoalojada se adapta a su infraestructura es ejecutarla allí. Passwork ofrece una prueba gratuita que puede desplegar en sus propios servidores, con funcionalidad completa y sin que ningún dato abandone su entorno.

Preguntas frecuentes

Gestión de credenciales SaaS: 5 pasos para centralizar su pila de aplicaciones

La gestión de credenciales SaaS convierte contraseñas dispersas y claves API en un inventario que puede compartir intencionalmente y revocar al salir. Aquí está el marco de cinco pasos: inventario, estructura, migración, control de acceso y automatización.

PassworkPasswork Team

Verizon DBIR 2026: 10 estadísticas que deberían cambiar su estrategia de seguridad

El DBIR 2026 de Verizon analizó más de 22.000 filtraciones en 145 países. La explotación de vulnerabilidades superó al abuso de credenciales como principal vector de ataque, mientras que el ransomware, el riesgo de terceros y los ataques asistidos por IA crecieron significativamente. Aquí están los 10 números que importan.

Passwork BlogAlex Muntyan

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

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

PassworkPasswork Team

Data sovereignty is the ability to determine, physically, legally, and cryptographically, who can access a piece of data and under which jurisdiction. A company can be fully GDPR-compliant on paper and still have no real control over where its passwords live. For corporate credentials, that gap between "compliant" and "in control" is where breaches, subpoenas, and failed audits start.

The General Data Protection Regulation (GDPR) sets the baseline most organizations use to judge their data practices: it governs how personal data is collected, stored, and transferred, and under Article 3 its territorial scope extends to any company processing EU residents' data, regardless of where that company is headquartered. 

Passwords and secrets are not ordinary data, which is why password management needs its own sovereignty model, separate from general file storage. They open access to everything else, they move between employees constantly, and they rarely pass through the data loss prevention (DLP) or classification tools that watch over contracts and customer records. A credential stored on the wrong server, in the wrong country, under someone else's encryption keys, is a liability that most compliance checklists don't catch.

This article breaks down what sovereignty actually means at three levels: physical location, encryption, and access governance. It compares on-premise, air-gapped, and EU cloud models, and shows where a self-hosted, zero-knowledge password manager like Passwork fits into that decision.

What data sovereignty actually means for credentials

Data sovereignty is the combination of three separate controls: where data physically sits, who holds the encryption keys, and who governs access to it. Losing any one of the three breaks sovereignty, even if the other two are solid. Most vendors advertise only the first.

• Physical location answers where the servers are. A password manager hosted in Frankfurt still falls under GDPR's territorial scope, but so does one hosted in Virginia if it processes EU residents' data. Location matters for jurisdiction, not automatically for legal exposure.
• Encryption control answers who can decrypt the data. If the vendor holds the keys, a government request, an insider, or a breach at the vendor's infrastructure can expose your credentials regardless of server location.
• Access governance answers who inside your organization can see what. Role-based access control (RBAC) and audit logs determine whether a departing employee's access is revoked in minutes or discovered six months later.

True data sovereignty requires all three elements. Omitting any component reduces the architecture to a formal compliance checklist.

Why credentials are a distinct data class

Credentials deserve separate handling because they are high-value, high-circulation, and largely invisible to standard data governance tools. A leaked customer record exposes one dataset. A leaked admin password exposes every system that admin can reach, and it keeps working until someone rotates it.

Verizon's 2026 Data Breach Investigations Report found stolen credentials accounted for 13% of initial access vectors, but that figure tripled (39%) across the full breach progression. Passwords also move constantly: shared during onboarding, copied into tickets, pasted into chat threads, forwarded when a project changes hands. DLP tools built to catch document exfiltration rarely flag a password dropped into a Slack message.

That combination of high impact and low visibility is why credential storage needs its own sovereignty model instead of inheriting whatever policy covers general file storage.

Where standard cloud storage introduces legal friction

Standard cloud password managers introduce legal exposure through subprocessor chains, cross-border data transfers, and vendor staff access, even when the vendor is fully GDPR-compliant. Encryption at rest does not remove these risks if the vendor, not the customer, holds the decryption keys.

Three specific friction points show up repeatedly during procurement reviews:

• Subprocessors. Most cloud vendors rely on subcontracted infrastructure, monitoring, or support providers. Each subprocessor is a separate entity with its own access surface. GDPR Article 28(2) requires that the processor shall not engage another processor (subprocessor) without prior specific or general written authorisation of the controller.
• Third-country transfers. GDPR Chapter V governs transfers of personal data outside the EU/EEA. Article 44 sets the general principle that any transfer must not undermine the level of protection guaranteed by the regulation, and Article 46 requires appropriate safeguards, such as Standard Contractual Clauses, when no adequacy decision applies. Credential vaults hosted in a third country, or replicated to one for backup purposes, fall squarely under this chapter.
• Vendor staff access and legal requests. If the vendor can technically decrypt customer data, that data is subject to legal process in the vendor's jurisdiction. A subpoena, warrant, or foreign disclosure order can compel access regardless of where your company is registered.

NIS2 adds a fourth angle: Article 21(2)(d) requires essential and important entities to assess supply chain security, including the vendors and tools they use to manage access credentials. A password vault sitting with a third-party subprocessor you haven't vetted falls squarely into that requirement.

None of this makes cloud storage non-compliant by default. It means "GDPR-compliant" is a necessary condition for credential sovereignty.

Mapping the three layers to deployment models

A gap in any single layer reopens the exposure the other two were meant to close. The table below applies the three controls from the first section, location, decryption, and access, to the models organizations actually choose between.

• Air-gapped describes infrastructure with no network path to the internet at all, the strictest form of physical isolation.
• Zero-knowledge means the vendor can never read your data, under any circumstances. 
• Client-side encryption is the mechanism that produces that guarantee: encryption and decryption happen on the user's device, using a master password the vendor never receives or stores, so the server only ever holds and transmits ciphertext. 

A poorly implemented client-side encryption scheme, one with a recoverable master password or a weak key derivation function, doesn't automatically deliver a true zero-knowledge guarantee. This distinction determines whether "encrypted in the cloud" actually means anything for sovereignty.

On-premise and air-gapped: Complete isolation, at the cost of operational load

On-premise deployment gives an organization complete physical and cryptographic control over its credential vault, because the data never leaves infrastructure the organization owns and administers. Air-gapping takes this a step further: the infrastructure has no network path to the internet at all, which is the only setup that removes external network dependency entirely.

Isolation from the provider: zero-knowledge encryption

Passwork runs entirely inside the corporate perimeter, on infrastructure the organization controls end to end. The password and secrets manager encrypts and decrypts data entirely on the client side, using a key derived from the user's master password. The server never receives or stores plaintext at any point, it holds only encrypted blobs and has no key capable of decrypting them. For organizations with air-gap requirements and strict segmentation policies, this is often the only architecture that satisfies internal security policy. 

A claim like that shouldn't be taken on faith. Passwork's source code is open for the organization's own security team to audit directly, line by line, instead of relying on the vendor's description of how encryption is implemented.

The operational trade-off

That level of isolation comes with a bill, paid in operational effort. On-premise shifts server maintenance, patching, backup management, and uptime responsibility from the vendor to your own IT team. Someone has to apply updates, monitor disk space, manage TLS certificates, and handle disaster recovery. For a small IT team already stretched across other priorities, that's a real cost. Organizations choosing self-hosting need either a dedicated sysadmin resource or a managed internal process for keeping the deployment current.

Passwork's zero-knowledge encryption keeps your data unreadable to anyone but your own users. Review the architecture in the user guides before committing infrastructure, or test the full deployment free to see it running on your own servers.

EU cloud hosting: Viable, but only with client-side encryption

EU cloud hosting can satisfy jurisdictional requirements for smaller teams without dedicated infrastructure staff, but only if the vendor implements mandatory client-side encryption (CSE). Without CSE, an EU-hosted vault still leaves the vendor capable of decrypting customer data, which reopens the same exposure that hosting in the EU was supposed to close.

Under a proper CSE model, the master password never leaves the user's device, and the vendor's servers process and store only ciphertext. Even with full physical access to the server, the vendor cannot read the vault's contents. This is a meaningfully different guarantee than "our data centers are in the EU," which addresses jurisdiction but says nothing about who holds the keys.

EU cloud hosting with CSE narrows legal exposure and satisfies data residency requirements for many compliance frameworks, but it isn't the same guarantee as full on-premise sovereignty. The infrastructure, network layer, and physical hardware remain outside the customer's direct control. For organizations with air-gap mandates or strict self-hosting policies, EU cloud is not a substitute, regardless of encryption strength.

On-premise without zero-knowledge still trusts local admins with plaintext access. EU cloud without it still trusts the vendor's infrastructure staff. Either way, the guarantee only holds when the master password never leaves the user's device.

Verifying vendor claims: What procurement should check

Sovereignty claims are only as credible as the third-party evidence behind them. This check applies regardless of which deployment model you choose: a certificate doesn't tell you where data sits, but it does tell you whether a vendor's other claims hold up. Procurement teams should base a self-hosting decision on internal admin capacity and policy requirements, then validate the shortlisted vendor through independent certification, own audit, and public security testing.

Four checks matter in practice:

• ISO/IEC 27001 certification confirms an information security management system has been independently audited against the international standard. Passwork holds ISO/IEC 27001:2022 certification, issued by MSECB and verifiable through the IAF CertSearch database.
• NIS2 and GDPR readiness matters for any organization that falls under either regulation's scope. NIS2 Article 21's supply chain requirements extend to the tools essential and important entities use to manage access credentials, while GDPR Article 32 requires "appropriate technical and organisational measures," including encryption, for any system handling personal data. Organizations evaluating vendors against these requirements can review Passwork's approach to NIS2 compliance as one reference point.
• Source code audit rights confirm that a zero-knowledge claim is actually true rather than marketing language. In a genuine zero-knowledge design, the vendor cannot recover an individual user's master password under any circumstance, not through a backend reset, not through a support ticket, not under legal pressure. If a user forgets it, the data behind it is gone by design, because the vendor never held the key in the first place. Passwork opens its source code to customers' own security teams for exactly this reason: it's the way to confirm the encryption implementation matches the architecture the vendor describes.
• Public penetration testing provides evidence beyond self-reported security posture. Passwork has completed an independent penetration test through HackerOne, covering secure data handling, the OWASP Top 10 and SANS Top 25, authentication, and API access control.

Choosing a deployment model: A decision framework

The right deployment model depends on five practical factors: 

• Air-gap requirements 
• Mandatory EU hosting 
• Admin team size
• Internal self-hosting policy
• Infrastructure control requirements

Matching these factors against deployment options avoids the common mistake of choosing based on price or brand recognition alone. Use this credential residency decision matrix to map organizational constraints to a deployment model:

None of these rows are mutually exclusive in practice. A financial institution might run on-premise for its core vault while accepting cloud-based tools for lower-sensitivity workflows. The matrix is a starting point for the conversation with security and compliance stakeholders.

How Passwork's architecture maps to these layers

Passwork's self-hosted deployment addresses the sovereignty gap described throughout this article by combining physical isolation, zero-knowledge encryption, and customer-controlled access governance in one architecture. The vault deploys on infrastructure the customer owns, whether that's a single Linux server, a Windows Server environment, or a Docker container inside an air-gapped network.

Encryption uses AES-256 with a zero-knowledge design, meaning the infrastructure, if it were ever compromised, holds only ciphertext. Access is governed through role-based permissions and a full audit log, so administrators can see who accessed which credential and when, and revoke access immediately when someone changes roles or leaves. Integration with AD/LDAP and SAML SSO lets access governance plug into existing identity infrastructure rather than running as a separate silo.

This is deliberately not a claim that self-hosting is right for everyone. Organizations without air-gap requirements or strict self-hosting mandates may find a cloud option with proper client-side encryption sufficient. The point is that when full sovereignty is the requirement, the architecture needs to support it structurally.

Data sovereignty in password management: How to apply it to your evaluation

Sovereignty is an ongoing alignment between where data sits, who holds the keys, and who governs access, and that alignment needs revisiting whenever your infrastructure, vendor contracts, or regulatory scope changes.

Start by mapping your own organization against the four factors in the decision matrix: air-gap requirement, mandatory EU hosting, admin team size, and internal self-hosting policy. That mapping will tell you more about the right deployment model than any vendor's marketing page.

The only way to confirm a self-hosted architecture fits your infrastructure is to run it there. Passwork offers a free trial you can deploy on your own servers, with full functionality and no data ever leaving your environment.

Frequently Asked Questions

SaaS credential management: 5 steps to centralize your app stack

SaaS credential management turns scattered passwords and API keys into one inventory you can share on purpose and revoke on exit. Here’s the five-step framework: inventory, structure, migration, access control, and automation.

PassworkPasswork Team

Verizon DBIR 2026: 10 stats that should change your security strategy

Verizon’s 2026 DBIR analyzed 22,000+ breaches across 145 countries. Vulnerability exploitation overtook credential abuse as the top attack vector, while ransomware, third-party risk, and AI-assisted attacks all grew sharply. Here are the 10 numbers that matter.

Passwork BlogAlex 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

SaaS-Zugangsdatenverwaltung bezeichnet die Praxis, jedes Passwort, jeden gemeinsam genutzten Login und jeden Zugriffsschlüssel zu erfassen, den ein Unternehmen für Cloud-Anwendungen wie Salesforce oder Slack verwendet, und zu kontrollieren, wer jeden einzelnen davon einsehen und nutzen kann. Es bedeutet, jede Zugangsdaten als Inventar zu behandeln, das Sie finden, gezielt teilen und entziehen können, wenn Mitarbeiter das Unternehmen verlassen. Das Ziel ist ein kontrollierter Tresor für menschliche Passwörter und maschinelle Secrets — nicht fünf Tools, von denen jedes nur einen Teil der Wahrheit enthält.

Die meisten Unternehmen nutzen mehr SaaS-Anwendungen, als die IT offiziell erfasst: ein CRM-Login in einem Browser-Profil, ein Gmail-Passwort, das über Slack geteilt wird, Staging-Datenbank-Strings, die in einem privaten Repository liegen. Niemand ist zentral für diese Logins verantwortlich, was bedeutet, dass auch niemand sie überwacht. Jedes einzelne ist ein offener Einstiegspunkt, der monatelang bestehen kann, bevor jemand bemerkt, dass er missbraucht wurde.

Passwork ist für genau diese Aufgabe konzipiert: ein Business-Passwort- und Secrets-Manager, den Sie auf Ihren eigenen Servern oder als Cloud-Dienst betreiben können, mit gemeinsam genutzten Tresoren, rollenbasiertem Zugriff, LDAP/SSO und einer REST API für die Automatisierung. Die fünf Schritte unten funktionieren gleichermaßen für Teams, die Passwork bereits nutzen, wie für Teams, die noch ein System evaluieren.

Was als SaaS-Zugangsdaten zählt

SaaS-Zugangsdaten sind alles, was verwendet wird, um Identität nachzuweisen und Zugang zu erhalten: ein Passwort, ein gemeinsam genutzter Login, ein API-Schlüssel oder ein Sicherheitszertifikat. Die Liste der SaaS-Anwendungen eines Unternehmens (wofür es bezahlt) ist nicht dasselbe wie die Liste seiner Zugangsdaten (wie auf jede Anwendung tatsächlich zugegriffen wird). Eine Anwendung kann mehrere haben: zehn Personen, die sich über SSO anmelden, ein gemeinsam genutztes Abrechnungskonto und ein API-Schlüssel, den ein Skript verwendet, um Berichte abzurufen.

Die Anwendungen zu kennen, die ein Unternehmen nutzt, zeigt, wofür es bezahlt. Die Zugangsdaten zu kennen zeigt, wer Zugang hat, und das ist die Liste, die für die Sicherheit relevant ist.

Schritt 1: Erstellen Sie Ihr SaaS-Zugangsdatenverwaltungs-Inventar

Beginnen Sie mit einer SaaS-Zugangsdatenliste. Gruppieren Sie nach Risiko. Führen Sie während dieses Schritts keine „Aufräumarbeiten" durch. Aufräumen während der Inventur schafft ein zweites Chaos. Erfassen, dann verschieben. Notieren Sie für jede SaaS-Anwendung und jeden internen Dienst:

• Um welches Tool es sich handelt (Name der SaaS-Anwendung)
• Wer für das Konto verantwortlich ist (Person oder Team)
• Wo das Secret aktuell liegt (Chat, Wiki, CI-Variable, Klebezettel)
• Wer es im nächsten Quartal benötigt (neue Mitarbeiter, Projekte oder Teams)
• Was ausfällt, wenn es verschwindet (abhängige Workflows, Integrationen oder Dienste)

Beispiel:

Ein solcher Eintrag sagt jedem genau, wen er fragen muss, wo er suchen soll und was auf dem Spiel steht.

Schritt 2: Gestalten Sie Tresore und Ordner entsprechend Ihrer Arbeitsweise

Ein Passwort-Tresor unterstützt die SaaS-Zugangsdatenverwaltung nur dann, wenn seine Ordnerhierarchie widerspiegelt, wie Teams bereits nach Zugriffen suchen — nicht wie das alte, chaotische System gewachsen ist. Zentralisierung scheitert, wenn der neue Speicherort das Chaos nur verlagert. Wählen Sie eine Hierarchie, die jemand in einem Satz erklären kann. Gruppieren Sie Tresore nach Abteilung oder Produkt, dann teilen Sie Infrastruktur-Secrets nach Umgebung auf.

Die Verschachtelung bleibt in den meisten Bereichen flach. Zwei Ebenen sind normalerweise ausreichend: ein Tresor für das Team, ein Ordner für die Tool-Kategorie. Fügen Sie eine dritte Ebene nur hinzu, wenn ein Ordner der zweiten Ebene allein nicht einheitlich ist. Wenn ein Ordner bereits alles beschreibt, was er enthält, hören Sie dort auf.

Beispiel für eine Datenhierarchie:

Zwei Zielgruppen nutzen denselben Baum unterschiedlich. Menschen navigieren nach Teamnamen. Pipelines rufen nach Ordner-ID ab, weshalb Onboarding-Dokumentationen für DevOps Umgebungs-basierte Ordner empfehlen: Ein Job kann alles, was er braucht, mit einer einzigen --folder-id abrufen, anstatt SaaS-Zugangsdaten in Code einzufügen.

Namensregeln helfen mehr als tiefe Verschachtelung:

• Bevorzugen Sie stripe-prod-dashboard gegenüber Neues Passwort (2)
• Setzen Sie die Umgebung in den Namen oder Ordner, nicht nur in jemandes Kopf
• Verwenden Sie benutzerdefinierte Felder für Nicht-Passwort-Secrets (API-Schlüssel, Client-IDs), anstatt alles in das Passwortfeld zu packen

Die letzte Entscheidung ist, wer den Tresor überhaupt sehen kann. Unternehmenstresore sind der Ort, an den Team-SaaS-Zugangsdaten gehören. Private Tresore sind für persönliche Arbeits-Logins, die den Mitarbeiter nicht überdauern sollten.

Schritt 3: Einmal migrieren, dann die parallelen Speicherorte löschen

Die Migration von SaaS-Zugangsdaten reduziert das Cloud-Management-Risiko nur dann, wenn der alte Speicherort zu einem festen Datum abgeschaltet wird. Einen Chat-Kanal, eine Tabelle und einen Passwort-Manager parallel als konkurrierende Wahrheitsquellen zu betreiben, reproduziert nur das Chaos, das die Migration eigentlich beheben sollte.

Import schlägt Neueintippen. Passwork akzeptiert strukturierte Importe (JSON, CSV und gängige Passwort-Manager-Exportformate). Migrieren Sie zuerst eine Pilotabteilung — genug Datensätze, damit die Leute den Schmerz der alten Methode spüren, aber nicht so viele, dass ein schlechtes Ordnerdesign permanent wird.

Regeln für eine ehrliche Migration:

1. Eine Wahrheitsquelle nach der Umstellung. Der Slack-Kanal und das gemeinsam genutzte Google Sheet werden zu schreibgeschützten Archiven und werden dann an einem veröffentlichten Datum gelöscht.
2. Rotieren Sie SaaS-Zugangsdaten nach dem Import, wenn der alte Kanal geteilt wurde. Alles, was im Chat existierte, ist per Definition kompromittiert. Das Passwort in der SaaS-Anwendung zu ändern und dann den Tresor zu aktualisieren, ist besser, als zuerst den Tresor zu aktualisieren und zu hoffen, dass die Anwendung den alten Wert noch akzeptiert.
3. Shortcuts statt Kopien. Wenn zwei Teams dieselben SaaS-Zugangsdaten benötigen, teilen Sie den Zugriff oder verwenden Sie einen Shortcut, anstatt das Secret zu duplizieren. Duplikate driften auseinander.

Rechnen Sie mit zwei chaotischen Wochen. Das ist normal. Der Fehlermodus ist, Notion und den Passwort-Tresor sechs Monate lang beide als „offiziell" zu belassen.

Schritt 4: Zugriff mit Rollen, Gruppen und Tresor-Berechtigungen steuern

Zentrale SaaS-Zugangsdatenspeicherung ohne Least-Privilege-Prinzip macht aus einem Passwort-Tresor eine sehr große, durchsuchbare Ablage. Effektive SaaS-Zugangsdatenverwaltung trennt, was eine Person mit der Plattform selbst tun kann, von dem, was sie mit einem bestimmten Satz gemeinsam genutzter Secrets tun kann.

Passwork trennt zwei Ebenen:

• Systemrollen — was jemand mit der Instanz tun kann (Benutzer einladen, SSO ändern, das Aktivitätsprotokoll lesen). Integrierte Rollen umfassen Besitzer, Admin und Benutzer. Unbegrenzte benutzerdefinierte Rollen ermöglichen es, Support- oder Auditor-Rollen zu erstellen, ohne vollständige Admin-Rechte zu vergeben.
• Benutzergruppen — was sie mit gemeinsam genutzten SaaS-Zugangsdaten tun können. Die Stufen reichen von Verboten über Lesen, Bearbeiten und Vollständiger Zugang bis hin zu Admin für diese Ressource.

Erteilen Sie Zugriff an Gruppen und ordnen Sie dann Personen den Gruppen zu. Wenn jemand dem Support beitritt, erbt er den Tresor-Zugriff mit der Gruppe. Wenn er geht, entfernen Sie ihn einmal. LDAP/AD kann die Gruppenmitgliedschaft synchronisieren, sodass Verzeichnisänderungen in den Passwort-Tresor fließen, anstatt auf ein Ticket zu warten.

Seien Sie streng mit Admin-Rechten für Tresore. Die meisten Personen benötigen Lese-Zugriff auf die Anwendungen, die sie nutzen. Admin ist für Teamleiter, die Ordner organisieren und überprüfen, wer Zugriff hat.

Schritt 5: Identität, Automatisierung und Offboarding verbinden

Ein Passwort-Tresor, der nur für interaktive Logins verwendet wird, deckt die Hälfte der SaaS-Zugangsdatenverwaltung ab. Die andere Hälfte sind die Machine-to-Machine-Secrets, die Pipelines zur Build- oder Deploy-Zeit abrufen. Die Anbindung des Tresors an SSO, LDAP/AD und eine CI-kompatible API macht ihn zum einzigen Kontrollpunkt für sowohl menschliche Logins als auch automatisierte Cloud-Management-Workflows.

• SAML SSO damit Personen den Passwort-Tresor mit demselben IdP betreten, den sie für den Rest des SaaS-Stacks verwenden (Azure AD, Okta, ADFS, Google Workspace und ähnliche).
• LDAP/AD wenn das Verzeichnis die Wahrheitsquelle für Konten und gruppenbasierten Tresor-Zugriff ist.
• Browser-Erweiterung und Desktop-/Mobile-Clients damit der tägliche Weg Autofill ist, nicht Kopieren-Einfügen aus einem Web-Tab.

Für die maschinelle Seite des Stacks halten Sie Menschen aus CI heraus:

• Verwenden Sie ein Service-Konto mit einem API-Schlüssel (oder Sitzungs-Tokens, die von passwork-cli verwendet werden), das auf die Tresore und Ordner beschränkt ist, die die Pipeline für den SaaS-Zugangsdatenzugriff benötigt.
• Rufen Sie Secrets zur Job-Zeit ab. Baken Sie sie nicht in Images ein.
• Rotieren: Aktualisieren Sie das Secret zuerst im Zielsystem, dann speichern Sie den neuen Wert im Passwort-Tresor — die umgekehrte Reihenfolge verursacht stille Ausfälle.
• Überprüfen Sie das Aktivitätsprotokoll (und Syslog/CEF-Export an SIEM, falls vorhanden) auf Kopien, Exporte und Zugriffsänderungen.

Offboarding ist der Punkt, an dem sich dieses Setup auszahlt. Deaktivieren Sie das Konto des ausscheidenden Benutzers, widerrufen Sie seine API-Sitzungen und bestätigen Sie, dass er aus jeder Gruppe entfernt wurde. Wenn ein gemeinsam genutztes SaaS-Admin-Passwort nur im Tresor lag, ist das Rotieren eine Aktion, keine Suche durch fünf Postfächer, um zu sehen, wer sonst noch eine Kopie hatte.

Wie richtige SaaS-Zugangsdatenverwaltung aussieht

SaaS-Zugangsdatenverwaltung ist zentralisiert, wenn der Zugriff über Gruppen statt über Direktnachrichten läuft, das Offboarding den Passwort-Tresor-Zugriff mit einer Aktion entzieht und jede Zugangsdatenabfrage in einem Aktivitätsprotokoll nachverfolgt werden kann. Nichts davon erfordert ein langes Programm — Inventur, Struktur und Migration laufen parallel über einige Wochen.

Sie sind zentralisiert, wenn:

• Ein neuer Mitarbeiter Tresor-Zugriff über eine Gruppe erhält, nicht über eine Direktnachricht mit fünf Passwörtern
• Ein ausscheidender Mitarbeiter den SaaS-Zugriff verliert, ohne eine Schnitzeljagd
• Entwickler eine Pipeline auf eine Ordner-ID richten können und aufhören, .env-Dateien zu committen
• Die Sicherheitsabteilung die Frage „Wer konnte den Stripe-Login letzten Monat sehen?" aus dem Aktivitätsprotokoll beantworten kann

Nichts davon erfordert ein Zwölf-Monats-Programm. Inventur in einer Woche. Struktur und Pilot in einer weiteren. Migration in Wellen. Berechtigungen und SSO parallel zu den Wellen. Automatisierung zuletzt — nachdem die Ordnerstruktur steht.

Fazit

Die Zentralisierung von SaaS-Zugangsdaten funktioniert nur, wenn das Tool, das sie verwaltet, durchsetzt, wer für jeden Tresor verantwortlich ist, menschliche Logins und Service-Konten auf getrennten Pfaden hält und einen Nachweis produziert, den Sie der Sicherheitsabteilung übergeben können, ohne ihn aus dem Gedächtnis zu rekonstruieren.

Passwork bindet diese Verantwortlichkeit an eine Rolle, die Sie im Voraus definieren, nicht an denjenigen, der zufällig zuerst auf „Tresor erstellen" geklickt hat. Wenn also die Person, die den Marketing-Tresor eingerichtet hat, das Unternehmen verlässt, verschwindet die Aufsicht nicht mit ihr — sie bleibt bei der Rolle. Service-Konten handhaben die maschinelle Seite auf dieselbe Weise: Eine CI-Pipeline erhält ihre eigene begrenzte Identität, anstatt still auf dem persönlichen Login von jemandem zu laufen, lange nachdem diese Person das Team gewechselt hat.

Menschliche Passwörter und maschinelle Secrets landen auf derselben Plattform, zu einem Preis. Das ist ein Anbieter statt zwei und ein Aktivitätsprotokoll statt zusammengestückter Exporte aus einem Passwort-Manager und einem separaten Secrets-Tool.

Häufig gestellte Fragen

Verizon DBIR 2026: 10 Statistiken, die Ihre Sicherheitsstrategie ändern sollten

Verizons DBIR 2026 analysierte über 22.000 Sicherheitsverletzungen in 145 Ländern. Die Ausnutzung von Schwachstellen überholte den Missbrauch von Zugangsdaten als häufigster Angriffsvektor, während Ransomware, Drittanbieter-Risiken und KI-gestützte Angriffe alle stark zunahmen. Hier sind die 10 Zahlen, die zählen.

PassworkAlex Muntyan

Passworks Tresor-Richtlinien: Ein CIO-Leitfaden für Unternehmenssicherheit

Passworks Tresor-Typen binden Admin-Rechte an die Tresor-Richtlinie selbst, nicht an denjenigen, der ihn erstellt hat, und schließen damit eine Lücke, von der die meisten Unternehmen nicht einmal wissen, dass sie existiert. Dieser Leitfaden gibt CIOs und CISOs ein funktionierendes Modell für Tresor-Governance, abgestimmt auf NIS2- und ISO 27001-Anforderungen.

PassworkPasswork Team

Was ist Privileged Access Management? Ein vollständiger Leitfaden

Privilegierte Konten sind die wertvollsten Ziele für Angreifer. Eine kompromittierte Admin-Zugangsdaten gibt volle Kontrolle über Infrastruktur, Daten und Anwendungen. PAM adressiert dies durch Credential Vaulting, Sitzungsüberwachung und Durchsetzung des Least-Privilege-Prinzips. So funktioniert es in der Praxis.

Passwork BlogAlex Muntyan

La gestión de credenciales SaaS es la práctica de rastrear cada contraseña, inicio de sesión compartido y clave de acceso que una empresa utiliza para aplicaciones en la nube como Salesforce o Slack, y controlar quién puede ver y usar cada una. Significa tratar cada credencial como un inventario que se puede encontrar, compartir de forma deliberada y revocar cuando las personas se van. El objetivo es una bóveda controlada única para contraseñas humanas y secretos de máquinas — no cinco herramientas que cada una guarda una parte de la verdad

La mayoría de las empresas usan más aplicaciones SaaS de las que TI rastrea oficialmente: un inicio de sesión de CRM en un perfil de navegador, una contraseña de Gmail compartida por Slack, cadenas de conexión de bases de datos de staging en un repositorio privado. Nadie es propietario central de ninguno de estos inicios de sesión, lo que significa que nadie los está vigilando tampoco. Cada uno es un punto de entrada abierto que podría permanecer ahí durante meses antes de que alguien note que ha sido mal utilizado.

Passwork está diseñado para ese trabajo: un gestor de contraseñas y secretos empresarial que puede ejecutarse en sus propios servidores o como servicio en la nube, con bóvedas compartidas, acceso basado en roles, LDAP/SSO y una REST API para automatización. Los cinco pasos a continuación funcionan de la misma manera para equipos que ya usan Passwork y para equipos que todavía están evaluando un sistema.

Qué cuenta como credencial SaaS

Una credencial SaaS es cualquier cosa utilizada para demostrar identidad y obtener acceso: una contraseña, un inicio de sesión compartido, una clave API o un certificado de seguridad. La lista de aplicaciones SaaS de una empresa (lo que paga) no es lo mismo que su lista de credenciales (cómo se accede realmente a cada aplicación). Una aplicación puede tener varias: diez personas iniciando sesión a través de SSO, una cuenta de facturación compartida y una clave API que un script usa para extraer informes.

Conocer las aplicaciones que usa una empresa muestra por qué está pagando. Conocer las credenciales muestra quién puede entrar, y esa es la lista que importa para la seguridad.

Paso 1: Construya su inventario de gestión de credenciales SaaS

Comience con una lista de credenciales SaaS. Agrupe por riesgo. No «limpie» durante este paso. Limpiar a mitad del inventario crea un segundo desorden. Capture, luego mueva. Para cada aplicación SaaS y servicio interno, escriba:

• Qué herramienta es (nombre de la aplicación SaaS)
• Quién es propietario de la cuenta (persona o equipo)
• Dónde está el secreto hoy (chat, wiki, variable de CI, nota adhesiva)
• Quién lo necesita el próximo trimestre (nuevas contrataciones, proyectos o equipos)
• Qué se rompe si desaparece (flujos de trabajo dependientes, integraciones o servicios)

Ejemplo:

Una entrada como esta le dice a cualquiera exactamente a quién preguntar, dónde buscar y qué está en juego.

Paso 2: Diseñe bóvedas y carpetas que coincidan con su forma de trabajar

Una bóveda de contraseñas solo ayuda a la gestión de credenciales SaaS cuando su jerarquía de carpetas coincide con la forma en que los equipos ya buscan el acceso, no con cómo creció el antiguo sistema caótico. La centralización falla cuando el nuevo almacén simplemente reubica el desorden. Elija una jerarquía que alguien pueda explicar en una oración. Agrupe las bóvedas por departamento o producto, luego divida los secretos de infraestructura por entorno.

El anidamiento se mantiene poco profundo en la mayoría de las ramas. Dos niveles suelen ser suficientes: una bóveda para el equipo, una carpeta para la categoría de herramienta. Añada un tercer nivel solo cuando una carpeta de segundo nivel no sea uniforme por sí misma. Si una carpeta ya describe todo lo que contiene, deténgase ahí.

Ejemplo de jerarquía de datos:

Dos audiencias usan este mismo árbol de manera diferente. Los humanos navegan por nombre de equipo. Los pipelines obtienen por ID de carpeta, por eso la documentación de incorporación para DevOps recomienda carpetas por entorno primero: un trabajo puede extraer todo lo que necesita con un solo --folder-id en lugar de incorporar credenciales SaaS en el código.

Las reglas de nomenclatura ayudan más que la profundidad de anidamiento:

• Prefiera stripe-prod-dashboard sobre Nueva contraseña (2)
• Ponga el entorno en el nombre o en la carpeta, no solo en la cabeza de alguien
• Use campos personalizados para secretos que no son contraseñas (claves API, IDs de cliente) en lugar de meter todo en el campo de contraseña

La última decisión es quién ve la bóveda en absoluto. Las bóvedas corporativas son donde pertenecen las credenciales SaaS del equipo. Las bóvedas privadas son para inicios de sesión de trabajo personales que no deberían sobrevivir al empleado.

Paso 3: Migre una vez, luego elimine los almacenes paralelos

La migración de credenciales SaaS solo reduce el riesgo de gestión en la nube cuando el almacenamiento antiguo se cierra en una fecha fija. Ejecutar un canal de chat, una hoja de cálculo y un gestor de contraseñas en paralelo como fuentes de verdad competidoras simplemente recrea la dispersión que la migración se suponía debía solucionar.

Importar es mejor que volver a escribir. Passwork acepta importaciones estructuradas (JSON, CSV y formatos de exportación comunes de gestores de contraseñas). Mueva primero un departamento piloto — suficientes registros para que las personas sientan el dolor de la forma antigua, no tantos como para que un mal diseño de carpetas se vuelva permanente.

Reglas que mantienen la migración honesta:

1. Una fuente de verdad única después de la transición. El canal de Slack y la hoja de cálculo compartida de Google se convierten en archivos de solo lectura, luego se eliminan en una fecha publicada.
2. Rote las credenciales SaaS después de importar cuando el canal antiguo era compartido. Cualquier cosa que vivió en el chat está comprometida por definición. Cambiar la contraseña en la aplicación SaaS, luego actualizar la bóveda, es mejor que actualizar la bóveda primero y esperar que la aplicación todavía acepte el valor antiguo.
3. Accesos directos en lugar de copias. Si dos equipos necesitan la misma credencial SaaS, comparta el acceso o use un acceso directo en lugar de duplicar el secreto. Los duplicados divergen.

Espere dos semanas desordenadas. Eso es normal. El modo de fallo es dejar Notion y la bóveda de contraseñas ambos «oficiales» durante seis meses.

Paso 4: Controle el acceso con roles, grupos y permisos de bóveda

El almacenamiento centralizado de credenciales SaaS sin privilegio mínimo convierte una bóveda de contraseñas en un pastebin muy grande y con búsqueda. La gestión efectiva de credenciales SaaS separa lo que una persona puede hacer a la plataforma en sí de lo que puede hacer a un conjunto específico de secretos compartidos.

Passwork separa dos capas:

• Roles del sistema — lo que alguien puede hacer a la instancia (invitar usuarios, cambiar SSO, leer el registro de actividad). Los incorporados incluyen Propietario, Admin y Usuario. Los roles personalizados ilimitados permiten crear Soporte o Auditor sin entregar acceso de admin completo.
• Grupos de usuarios — lo que pueden hacer con las credenciales SaaS compartidas. Los niveles van desde Prohibido a través de Lectura, Edición y Acceso completo hasta Admin en ese recurso.

Conceda acceso a grupos, luego asigne personas a los grupos. Cuando alguien se une a Soporte, hereda el acceso a la bóveda con el grupo. Cuando se va, lo elimina una vez. LDAP/AD puede sincronizar la membresía del grupo para que los cambios del directorio fluyan a la bóveda de contraseñas en lugar de esperar un ticket.

Sea estricto con Admin en las bóvedas. La mayoría de las personas necesitan Lectura en las aplicaciones que usan. Admin es para líderes de equipo que organizan carpetas y revisan quién tiene acceso.

Paso 5: Conecte identidad, automatización y baja de empleados

Una bóveda de contraseñas utilizada solo para inicios de sesión interactivos cubre la mitad de la gestión de credenciales SaaS. La otra mitad son los secretos de máquina a máquina que los pipelines extraen en el momento de compilación o despliegue. Conectar la bóveda a SSO, LDAP/AD y una API compatible con CI la convierte en el punto de control único tanto para inicios de sesión humanos como para flujos de trabajo automatizados de gestión en la nube.

• SAML SSO para que las personas entren a la bóveda de contraseñas con el mismo IdP que usan para el resto de la pila SaaS (Azure AD, Okta, ADFS, Google Workspace y similares).
• LDAP/AD cuando el directorio es la fuente de verdad para cuentas y acceso a bóvedas basado en grupos.
• Extensión de navegador y clientes de escritorio/móvil para que el camino diario sea autocompletar, no copiar y pegar desde una pestaña web.

Para el lado de máquinas de la pila, mantenga a los humanos fuera de CI:

• Use una cuenta de servicio con una clave API (o tokens de sesión consumidos por passwork-cli), con alcance limitado a las bóvedas y carpetas que el pipeline necesita para el acceso a credenciales SaaS.
• Extraiga secretos en el momento del trabajo. No los incorpore en las imágenes.
• Rote: actualice el secreto en el sistema de destino primero, luego guarde el nuevo valor en la bóveda de contraseñas — el orden inverso crea interrupciones silenciosas.
• Revise el registro de actividad (y la exportación Syslog/CEF a SIEM si tiene uno) para copias, exportaciones y cambios de acceso.

La baja de empleados es donde esta configuración da sus frutos. Desactive la cuenta del usuario que se va, revoque sus sesiones API y confirme que ha sido eliminado de cada grupo. Si una contraseña de admin SaaS compartida vivía solo en la bóveda, rotarla es una acción, no una búsqueda en cinco bandejas de entrada para ver quién más tenía una copia.

Cómo se ve la gestión de credenciales SaaS bien hecha

La gestión de credenciales SaaS está centralizada cuando el acceso fluye a través de grupos en lugar de mensajes directos, la baja revoca el acceso a la bóveda de contraseñas en una acción, y cada búsqueda de credenciales se puede rastrear en un registro de actividad. Nada de esto necesita un programa largo — inventario, estructura y migración se ejecutan en paralelo durante unas pocas semanas.

Está centralizado cuando:

• Un nuevo empleado obtiene acceso a la bóveda a través de un grupo, no un mensaje directo con cinco contraseñas
• Un empleado que se va pierde el alcance SaaS sin una búsqueda del tesoro
• Los ingenieros pueden apuntar un pipeline a un ID de carpeta y dejar de hacer commit de archivos .env
• Seguridad puede responder «¿quién pudo ver el inicio de sesión de Stripe el mes pasado?» desde el registro de actividad

Nada de eso requiere un programa de doce meses. Inventario en una semana. Estructura y piloto en otra. Migración en oleadas. Permisos y SSO en paralelo con las oleadas. Automatización al final — después de que las carpetas existan.

Conclusión

Centralizar las credenciales SaaS solo funciona si la herramienta que las contiene impone quién es responsable de cada bóveda, mantiene los inicios de sesión humanos y las cuentas de servicio en pistas separadas, y produce un registro que puede entregar a seguridad sin reconstruirlo de memoria.

Passwork vincula esa responsabilidad a un rol que define desde el principio, no a quien por casualidad hizo clic en «crear bóveda» primero. Así que cuando la persona que configuró la bóveda de Marketing deja la empresa, la supervisión no se va con ella — se queda con el rol. Las cuentas de servicio manejan el lado de las máquinas de la misma manera: un pipeline de CI obtiene su propia identidad con alcance limitado en lugar de ejecutarse silenciosamente con el inicio de sesión personal de alguien mucho después de que esa persona haya cambiado de equipo.

Las contraseñas humanas y los secretos de máquinas terminan en la misma plataforma, bajo un solo precio. Eso es un proveedor que gestionar en lugar de dos, y un registro de actividad que revisar en lugar de juntar exportaciones de un gestor de contraseñas y una herramienta de secretos separada.

Preguntas frecuentes

Verizon DBIR 2026: 10 estadísticas que deberían cambiar su estrategia de seguridad

El DBIR 2026 de Verizon analizó más de 22.000 brechas en 145 países. La explotación de vulnerabilidades superó al abuso de credenciales como el principal vector de ataque, mientras que el ransomware, el riesgo de terceros y los ataques asistidos por IA crecieron significativamente. Aquí están los 10 números que importan.

PassworkAlex Muntyan

Políticas de bóvedas de Passwork: guía para CIOs sobre seguridad empresarial

Los Tipos de Bóvedas de Passwork vinculan los derechos de admin a la política de la bóveda en sí, no a quien la creó, cerrando una brecha que la mayoría de las empresas ni siquiera saben que existe. Esta guía proporciona a CIOs y CISOs un modelo funcional para la gobernanza de bóvedas, mapeado a los requisitos de NIS2 e ISO 27001.

PassworkPasswork Team

¿Qué es la Gestión de Acceso Privilegiado? Una guía completa

Las cuentas privilegiadas son los objetivos de mayor valor para los atacantes. Una credencial de admin comprometida da control total sobre infraestructura, datos y aplicaciones. PAM aborda esto a través del almacenamiento de credenciales, monitorización de sesiones y aplicación del privilegio mínimo. Así es como funciona en la práctica.

Passwork BlogAlex Muntyan

SaaS credential management is the practice of tracking every password, shared login, and access key a company uses for cloud apps like Salesforce or Slack, and controlling who can see and use each one. It means treating every credential as inventory you can find, share on purpose, and revoke when people leave. The goal is one controlled vault for human passwords and machine secrets — not five tools that each hold a slice of the truth

Most companies use more SaaS apps than IT officially tracks: a CRM login in a browser profile, a Gmail password shared over Slack, staging database strings sitting in a private repo. Nobody centrally owns any of these logins, which means nobody is watching them either. Each one is an open entry point that could sit there for months before anyone notices it's been misused.

Passwork is built for that job: a business password and secrets manager you can run on your own servers or as a cloud service, with shared vaults, role-based access, LDAP/SSO, and a REST API for automation. The five steps below work the same way for teams already running Passwork and for teams still evaluating a system.

What counts as a SaaS credential

A SaaS credential is anything used to prove identity and get access: a password, a shared login, an API key, or a security certificate. A company's list of SaaS apps (what it pays for) is not the same as its list of credentials (how each app is actually accessed). One app can have several: ten people logging in through SSO, one shared billing account, and an API key a script uses to pull reports.

Knowing the apps a company uses shows what it's paying for. Knowing the credentials shows who can get in, and that's the list that matters for security.

Step 1: Build your SaaS credential management inventory

Start with a SaaS credential list. Group by risk. Do not "clean up" during this step. Cleaning mid-inventory creates a second mess. Capture, then move. For each SaaS app and internal service, write:

• Which tool this is (SaaS app name)
• Who owns the account (person or team)
• Where the secret sits today (chat, wiki, CI variable, sticky note)
• Who needs it next quarter (upcoming hires, projects, or teams)
• What breaks if it disappears (dependent workflows, integrations, or services)

Example:

One entry like this tells anyone exactly who to ask, where to look, and what's at stake.

Step 2: Design vaults and folders that match how you work

A password vault only helps SaaS credential management when its folder hierarchy matches how teams already search for access, not how the old, chaotic system grew. Centralization fails when the new store just relocates the mess. Pick a hierarchy someone can explain in one sentence. Group vaults by department or product, then split infrastructure secrets by environment.

Nesting stays shallow in most branches. Two levels are usually enough: a vault for the team, a folder for the tool category. Add a third level only when a second-level folder isn't uniform on its own. If a folder already describes everything inside it, stop there.

Data hierarchy example:

Two audiences use this same tree differently. Humans browse by team name. Pipelines fetch by folder ID, which is why onboarding docs for DevOps recommend environment-first folders: a job can pull everything it needs with one --folder-id instead of stitching SaaS credentials into code.

Naming rules help more than nested depth:

• Prefer stripe-prod-dashboard over New password (2)
• Put the environment in the name or the folder, not only in someone's head
• Use custom fields for non-password secrets (API keys, client IDs) instead of stuffing everything into the password field

The last decision is who sees the vault at all. Corporate vaults are where team SaaS credentials belong. Private vaults are for personal work logins that should not outlive the employee.

Step 3: Migrate once, then delete the parallel stores

SaaS credential migration only reduces cloud management risk when the old storage gets shut down on a fixed date. Running a chat channel, a spreadsheet, and a password manager side by side as competing sources of truth just recreates the sprawl the migration was supposed to fix.

Import beats retyping. Passwork accepts structured imports (JSON, CSV and common password-manager export formats). Move a pilot department first — enough records that people feel the pain of the old way, not so many that a bad folder design becomes permanent.

Rules that keep migration honest:

1. One source of truth after cutover. The Slack channel and the shared Google Sheet become read-only archives, then get deleted on a published date.
2. Rotate SaaS credentials after import when the old channel was shared. Anything that lived in chat is compromised by definition. Changing the password in the SaaS app, then updating the vault, beats updating the vault first and hoping the app still accepts the old value.
3. Shortcuts instead of copies. If two teams need the same SaaS credential, share access or use a shortcut rather than duplicating the secret. Duplicates drift.

Expect a messy two weeks. That is normal. The failure mode is leaving Notion and the password vault both "official" for six months.

Step 4: Gate access with roles, groups, and vault permissions

Central SaaS credential storage without least privilege turns a password vault into a very large, searchable pastebin. Effective SaaS credential management separates what a person can do to the platform itself from what they can do to a specific set of shared secrets.

Passwork separates two layers:

• System roles — what someone can do to the instance (invite users, change SSO, read the activity log). Built-ins include Owner, Admin, and User. Unlimited custom roles let you carve out Support or Auditor without handing out full admin.
• User groups — what they can do to shared SaaS credentials. Levels run from Forbidden through Read, Edit, and Full access up to Admin on that resource.

Grant access to groups, then map people into groups. When someone joins Support, they inherit vault access with the group. When they leave, you remove them once. LDAP/AD can sync group membership so directory changes flow into the password vault instead of waiting on a ticket.

Be strict with Admin on vaults. Most people need Read on the apps they use. Admin is for team leads who organize folders and review who has access.

Step 5: Connect identity, automation, and offboarding

A password vault used only for interactive logins covers half of SaaS credential management. The other half is the machine-to-machine secrets pipelines pull at build or deploy time. Wiring the vault to SSO, LDAP/AD, and a CI-friendly API turns it into the single control point for both human logins and automated cloud management workflows.

• SAML SSO so people enter the password vault with the same IdP they use for the rest of the SaaS stack (Azure AD, Okta, ADFS, Google Workspace, and similar).
• LDAP/AD when the directory is the source of truth for accounts and group-based vault access.
• Browser extension and desktop/mobile clients so the daily path is autofill, not copy-paste from a web tab.

For the machine side of the stack, keep humans out of CI:

• Use a service account with an API key (or session tokens consumed by passwork-cli), scoped to the vaults and folders the pipeline needs for SaaS credential access.
• Pull secrets at job time. Do not bake them into images.
• Rotate: update the secret in the target system first, then save the new value in the password vault — the reverse order creates silent outages.
• Review the activity log (and Syslog/CEF export to SIEM if you have one) for copies, exports, and access changes.

Offboarding is where this setup pays off. Disable the departing user's account, revoke their API sessions, and confirm they're removed from every group. If a shared SaaS admin password lived only in the vault, rotating it is one action, not a search through five inboxes to see who else had a copy.

What SaaS credential management done right looks like

SaaS credential management is centralized when access flows through groups instead of DMs, offboarding revokes password vault access in one action, and every credential lookup can be traced in an activity log. None of this needs a long program — inventory, structure, and migration run in parallel over a few weeks.

You are centralized when:

• A new hire gets vault access through a group, not a DM with five passwords
• A departing hire loses SaaS reach without a scavenger hunt
• Engineers can point a pipeline at a folder ID and stop committing .env files
• Security can answer "who could see the Stripe login last month?" from the activity log

None of that requires a twelve-month program. Inventory in a week. Structure and pilot in another. Migrate in waves. Permissions and SSO in parallel with the waves. Automation last — after the folders exist.

Conclusion

Centralizing SaaS credentials only works if the tool holding them enforces who's accountable for each vault, keeps human logins and service accounts on separate tracks, and produces a record you can hand to security without reconstructing it from memory.

Passwork ties that accountability to a role you define upfront, not to whoever happened to click "create vault" first. So when the person who set up the Marketing vault leaves the company, oversight doesn't leave with them — it stays with the role. Service accounts handle the machine side the same way: a CI pipeline gets its own scoped identity instead of quietly running on someone's personal login long after that person has moved teams.

Human passwords and machine secrets end up on the same platform, under one price. That's one vendor to manage instead of two, and one activity log to check instead of piecing together exports from a password manager and a separate secrets tool.

Frequently asked questions

Verizon DBIR 2026: 10 stats that should change your security strategy

Verizon’s 2026 DBIR analyzed 22,000+ breaches across 145 countries. Vulnerability exploitation overtook credential abuse as the top attack vector, while ransomware, third-party risk, and AI-assisted attacks all grew sharply. Here are the 10 numbers that matter.

PassworkAlex Muntyan

Passwork’s vault policies: a CIO’s guide to enterprise security

Passwork’s Vault Types bind admin rights to the vault policy itself, not to whoever created it, closing a gap most enterprises don’t even know exists. This guide gives CIOs and CISOs a working model for vault governance, mapped to NIS2 and ISO 27001 requirements.

PassworkPasswork Team

What is Privileged Access Management? A Complete Guide

Privileged accounts are the highest-value targets for attackers. One compromised admin credential gives full control over infrastructure, data, and applications. PAM addresses this through credential vaulting, session monitoring, and least privilege enforcement. Here’s how it works in practice.

Passwork BlogAlex Muntyan

La última versión de Passwork se centra en un problema que todo equipo distribuido termina enfrentando: qué sucede con el acceso a las contraseñas cuando se pierde la conexión. Passwork 7.7 añade un modo sin conexión seguro tanto a las aplicaciones de escritorio como móviles, manteniendo a los administradores con control total sobre lo que se almacena en caché localmente.

Acceso seguro sin conexión para aplicaciones de escritorio y móviles

Los usuarios ahora pueden abrir registros de contraseñas incluso cuando su dispositivo no tiene conexión con el servidor. Lograrlo requiere dos pasos deliberados, por lo que nada termina en un dispositivo por accidente.

Primero, el usuario marca un registro específico con un icono de sin conexión , disponible tanto en la tarjeta de información de la contraseña como en la lista general de contraseñas. Esto añade los registros seleccionados a una lista sincronizada visible en todos los dispositivos del usuario en la pestaña Sin conexión del panel de navegación — en este punto nada se descarga ni está disponible sin conexión todavía.

Segundo, en un dispositivo, el usuario abre la pestaña Sin conexión en la aplicación de escritorio o móvil y selecciona Habilitar en este dispositivo. Solo entonces Passwork descarga los registros cifrados a una caché local en ese dispositivo específico.

Al abrir la aplicación de escritorio o móvil sin conexión a internet, solo están disponibles los registros previamente guardados para acceso sin conexión. Si el servidor se vuelve inaccesible durante una sesión, la aplicación ofrece tres opciones:

• Cerrar sesión de la aplicación de escritorio o móvil
• Reintentar la conexión al servidor
• Cambiar al modo sin conexión para ver solo los registros en caché

Una vez que se restablece la conectividad, Passwork sincroniza la caché y carga un registro de cada visualización sin conexión al servidor.

Controles de administrador, visibilidad y seguimiento de riesgos

El acceso sin conexión se gestiona a nivel de rol y no funciona sin control. Los administradores mantienen control total sobre quién lo usa y cómo se rastrea.

Permisos basados en roles

Los administradores deciden qué roles pueden usar el acceso sin conexión, cuánto tiempo puede pasar un dispositivo sin sincronizar antes de que se borre su caché, y cuántos registros puede almacenar un solo dispositivo.

Registro de auditoría completo

Cada descarga sin conexión aparece en el registro de eventos y en el panel de seguridad. Todas las acciones realizadas en registros sin conexión también se reflejan en el Registro de actividad una vez que el dispositivo se sincroniza, igual que cualquier otra contraseña. Esto proporciona a los equipos de seguridad el mismo nivel de supervisión sobre el acceso sin conexión que ya tienen sobre la actividad en línea.

Información a nivel de dispositivo

Los administradores pueden ver quién almacenó en caché un registro, en qué dispositivo y cuándo ese dispositivo se sincronizó por última vez. El modal de acceso para una carpeta o bóveda también muestra el nombre del usuario y del dispositivo, para que los administradores puedan rastrear la actividad sin conexión hasta el dispositivo específico sin salir de la vista de permisos.

Seguimiento de exposición

El Panel de seguridad de Passwork trata un registro sin conexión como una exposición potencial en el momento en que llega a una caché local, independientemente de si el usuario realmente lo abre. Esto sigue la misma lógica ya aplicada a los registros visualizados.

Política desactivada por defecto

Después de actualizar a la versión 7.7, la función está habilitada por defecto solo para los roles de Propietario y Administrador. Todos los demás comienzan con la función desactivada.

Aspectos esenciales del modo sin conexión

• Dónde funciona. Los registros pueden marcarse para acceso sin conexión desde cualquier aplicación y cliente web, pero visualizarlos sin conexión solo está disponible en las aplicaciones móviles y de escritorio. Debe habilitarse por separado en cada dispositivo.
• Qué datos están disponibles. Sin conexión, los usuarios solo pueden ver las contraseñas que ya han añadido a la lista sin conexión y sincronizado previamente.
• Expiración automática. Si un dispositivo no se sincroniza dentro del período establecido por el administrador, los registros en caché se eliminan automáticamente.
• Configuración de roles. Los administradores establecen las reglas para los usuarios: cuántos registros pueden almacenarse por dispositivo y cuánto tiempo permanecen válidos sin sincronizar.
• Control del administrador. Los administradores deciden qué roles pueden usar el acceso sin conexión y pueden deshabilitarlo completamente para roles específicos. Cada registro en caché permanece visible en el Registro de actividad y los modales de acceso, mostrando qué usuario lo almacenó en caché, en qué dispositivo y cuándo se sincronizó por última vez.
• Seguimiento de actividad. Una vez que un dispositivo se reconecta, todas las acciones realizadas sin conexión se sincronizan con el Registro de actividad, apareciendo junto con el historial regular del registro — proporcionando a los administradores visibilidad completa, igual que con cualquier actividad en línea.

Limitaciones del modo sin conexión

• Solo lectura. En modo sin conexión, los registros solo pueden visualizarse. Crear, editar o eliminar una contraseña requiere conexión al servidor.
• Revocación. Revocar el acceso a un registro no elimina la copia local instantáneamente — el cambio solo surte efecto una vez que el dispositivo vuelve a estar en línea.
• Disponibilidad del plan. El acceso sin conexión está disponible solo en el plan avanzado.

Controles de archivos adjuntos

Los administradores ahora pueden deshabilitar los archivos adjuntos a los registros en toda la organización. Una vez desactivado, los usuarios no pueden añadir archivos a ningún registro de contraseña, independientemente del rol o los permisos de la bóveda. La configuración se encuentra en Gestión de bóvedas → Configuración → General.

Mejoras en búsqueda y navegación

Los resultados de búsqueda ahora incluyen una columna de URLs junto con una columna de directorio principal para carpetas, facilitando la identificación de dónde se encuentran los elementos sin abrirlos. La barra de búsqueda ahora se activa automáticamente en cuanto comienza a escribir. También se eliminó la división de subcadenas en las consultas de búsqueda, por lo que los resultados ahora coinciden con su intención de manera más precisa.

Aplicaciones de escritorio y móviles

Tanto las aplicaciones de escritorio como móviles ahora incluyen la implementación de acceso sin conexión descrita anteriormente. La aplicación móvil recibe actualizaciones adicionales: controles a nivel de organización para bloquear capturas de pantalla y grabación de pantalla (Configuración del sistema → Extensiones de navegador y aplicaciones móviles) y búsqueda entre carpetas en lugar de solo registros individuales. También se añadió soporte de descarga de paquete MSI para la aplicación de escritorio.

Nuevo: Guías de incorporación

Junto con el lanzamiento, se publicó una sección completa de incorporación construida en torno a cinco roles — usuarios, gerentes de departamento, administradores de TI, ingenieros DevOps y especialistas en seguridad. Cada guía cubre exactamente lo que alguien en ese rol necesita configurar en el primer día, sin asumir familiaridad previa con el producto.

Los administradores que implementan Passwork en toda la organización obtienen un manual que cubre la integración con LDAP y SSO, la estructura de bóvedas y el aprovisionamiento masivo de usuarios. Los equipos de DevOps tienen un itinerario separado para el uso de CLI y SDK, cuentas de servicio e inyección de secretos en pipelines de CI/CD. Los oficiales de seguridad y cumplimiento pueden trabajar con listas de verificación mapeadas a ISO 27001, GDPR y NIST.

Passwork gana Top Performer Verano 2026 en SourceForge

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

PassworkPasswork Team

Resumen de noticias de ciberseguridad: El mes en que los agentes de IA comenzaron a atacar por su cuenta

Un agente GPT-5.6 escapó de su sandbox y vulneró la infraestructura de Hugging Face. SonicWall lanzó dos 0-days que forzaron un restablecimiento completo de contraseñas y TOTP. El informe de costos de brechas 2026 de IBM alcanzó un récord de $4.99 millones. Esto es lo que sucedió en ciberseguridad este julio y lo que su equipo necesita parchear primero.

PassworkPasswork Team

Informe IBM del Costo de una Brecha de Datos 2026: La amenaza de $6M de la IA que nadie está solucionando

Los costos globales de brechas alcanzaron un récord de $4.99M en 2026, con una detección que toma 247 días. Los ataques impulsados por IA aumentaron un 56%, pero la verdadera crisis: los defensores despliegan IA en todas partes excepto donde los atacantes entran. El 92% de las organizaciones vulneradas por IA no tenían controles de acceso adecuados.

PassworkAlex Muntyan

Das neueste Passwork-Release konzentriert sich auf ein Problem, das jedes verteilte Team früher oder später trifft: Was passiert mit dem Passwortzugriff, wenn die Verbindung abbricht? Passwork 7.7 fügt einen sicheren Offline-Modus sowohl für Desktop- als auch für mobile Apps hinzu, während Administratoren die volle Kontrolle darüber behalten, was lokal zwischengespeichert wird.

Sicherer Offline-Zugriff für Desktop- und mobile Apps

Benutzer können jetzt Passwort-Datensätze öffnen, auch wenn ihr Gerät keine Verbindung zum Server hat. Dafür sind zwei bewusste Schritte erforderlich, sodass nichts versehentlich auf einem Gerät landet.

Erstens markiert ein Benutzer einen bestimmten Datensatz mit einem Offline-Symbol , das sowohl in der Passwort-Infokarte als auch in der allgemeinen Passwortliste verfügbar ist. Dies fügt ausgewählte Datensätze zu einer synchronisierten Liste hinzu, die auf allen Geräten des Benutzers unter dem Tab Offline im Navigationsbereich sichtbar ist — zu diesem Zeitpunkt wird noch nichts heruntergeladen oder ist offline verfügbar.

Zweitens öffnet der Benutzer auf einem Gerät den Tab Offline in der Desktop- oder mobilen App und wählt Auf diesem Gerät aktivieren. Erst dann lädt Passwork die verschlüsselten Datensätze in einen lokalen Cache auf diesem spezifischen Gerät.

Beim Öffnen der Desktop- oder mobilen App ohne Internetverbindung sind nur Datensätze verfügbar, die zuvor für den Offline-Zugriff gespeichert wurden. Wenn der Server während einer Sitzung nicht mehr erreichbar ist, bietet die App drei Optionen:

• Abmelden von der Desktop- oder mobilen App
• Verbindung erneut versuchen zum Server
• In den Offline-Modus wechseln um nur zwischengespeicherte Datensätze anzuzeigen

Sobald die Konnektivität wiederhergestellt ist, synchronisiert Passwork den Cache und lädt ein Protokoll jedes Offline-Zugriffs auf den Server hoch.

Admin-Steuerung, Transparenz und Risikoverfolgung

Der Offline-Zugriff wird auf Rollenebene gesteuert und läuft nicht unkontrolliert. Administratoren behalten die volle Kontrolle darüber, wer ihn nutzt und wie er verfolgt wird.

Rollenbasierte Berechtigungen

Administratoren entscheiden, welche Rollen den Offline-Zugriff nutzen können, wie lange ein Gerät ohne Synchronisierung bleiben kann, bevor sein Cache gelöscht wird, und wie viele Datensätze ein einzelnes Gerät speichern kann.

Vollständiger Audit-Trail

Jeder Offline-Download erscheint im Ereignisprotokoll und auf dem Sicherheits-Dashboard. Alle an Offline-Datensätzen durchgeführten Aktionen werden nach der Synchronisierung des Geräts ebenfalls im Aktivitätsprotokoll erfasst, genau wie bei jedem anderen Passwort. Dies gibt Sicherheitsteams das gleiche Maß an Kontrolle über den Offline-Zugriff wie über Online-Aktivitäten.

Geräteebenen-Einblick

Administratoren können sehen, wer einen Datensatz zwischengespeichert hat, auf welchem Gerät und wann dieses Gerät zuletzt synchronisiert wurde. Das Zugriffsmodal für einen Ordner oder Tresor zeigt auch den Benutzer- und Gerätenamen an, sodass Administratoren Offline-Aktivitäten bis zum spezifischen Gerät nachverfolgen können, ohne die Berechtigungsansicht zu verlassen.

Expositionsverfolgung

Das Sicherheits-Panel von Passwork behandelt einen Offline-Datensatz als potenzielle Exposition, sobald er in einem lokalen Cache landet — unabhängig davon, ob der Benutzer ihn tatsächlich öffnet. Dies folgt der gleichen Logik, die bereits auf angesehene Datensätze angewendet wird.

Standardmäßig deaktiviert

Nach dem Upgrade auf Version 7.7 ist die Funktion standardmäßig nur für die Rollen Besitzer und Administrator aktiviert. Für alle anderen ist sie zunächst deaktiviert.

Offline-Grundlagen

• Wo es funktioniert. Datensätze können von jeder App und jedem Web-Client für den Offline-Zugriff markiert werden, aber das Offline-Anzeigen ist nur in den mobilen und Desktop-Apps verfügbar. Die Funktion muss auf jedem Gerät separat aktiviert werden.
• Welche Daten verfügbar sind. Ohne Verbindung können Benutzer nur Passwörter anzeigen, die sie zuvor zur Offline-Liste hinzugefügt und synchronisiert haben.
• Automatischer Ablauf. Wenn ein Gerät nicht innerhalb des vom Administrator festgelegten Zeitrahmens synchronisiert wird, werden zwischengespeicherte Datensätze automatisch gelöscht.
• Rolleneinstellungen. Administratoren legen die Regeln für Benutzer fest: wie viele Datensätze pro Gerät gespeichert werden können und wie lange sie ohne Synchronisierung gültig bleiben.
• Admin-Kontrolle. Administratoren entscheiden, welche Rollen den Offline-Zugriff überhaupt nutzen können, und können ihn für bestimmte Rollen vollständig deaktivieren. Jeder zwischengespeicherte Datensatz bleibt im Aktivitätsprotokoll und in den Zugriffsmodalen sichtbar und zeigt an, welcher Benutzer ihn zwischengespeichert hat, auf welchem Gerät und wann die letzte Synchronisierung stattfand.
• Aktivitätsverfolgung. Sobald ein Gerät wieder verbunden ist, werden alle offline durchgeführten Aktionen mit dem Aktivitätsprotokoll synchronisiert und erscheinen neben dem regulären Verlauf des Datensatzes — dies gibt Administratoren volle Transparenz, genau wie bei jeder Online-Aktivität.

Offline-Einschränkungen

• Schreibgeschützt. Im Offline-Modus können Datensätze nur angezeigt werden. Das Erstellen, Bearbeiten oder Löschen eines Passworts erfordert eine Verbindung zum Server.
• Widerruf. Das Widerrufen des Zugriffs auf einen Datensatz löscht die lokale Kopie nicht sofort — die Änderung wird erst wirksam, wenn das Gerät wieder online ist.
• Planverfügbarkeit. Der Offline-Zugriff ist nur in der Erweiterten Lizenz verfügbar.

Dateianhang-Steuerung

Administratoren können jetzt Dateianhänge an Datensätze für die gesamte Organisation deaktivieren. Nach der Deaktivierung können Benutzer keine Dateien zu Passwort-Datensätzen hinzufügen, unabhängig von Rolle oder Tresor-Berechtigungen. Die Einstellung befindet sich unter Tresorverwaltung → Einstellungen → Allgemein.

Such- und Navigationsverbesserungen

Suchergebnisse enthalten jetzt neben einer übergeordneten Verzeichnisspalte für Ordner auch eine URLs-Spalte, die es einfacher macht zu erkennen, wo sich Elemente befinden, ohne sie zu öffnen. Die Suchleiste wird jetzt automatisch aktiviert, sobald Sie mit der Eingabe beginnen. Zusätzlich wurde die Teilstring-Aufteilung in Suchanfragen entfernt, sodass die Ergebnisse jetzt genauer Ihrer Absicht entsprechen.

Desktop- und mobile Apps

Sowohl Desktop- als auch mobile Apps beinhalten jetzt die oben beschriebene Offline-Zugriffs-Implementierung. Die Mobile-App erhält zusätzliche Updates: organisationsweite Steuerungen zum Blockieren von Screenshots und Bildschirmaufnahmen (Systemeinstellungen → Browser-Erweiterungen und mobile Apps) sowie Suche über Ordner hinweg statt nur einzelner Datensätze. Zusätzlich wurde MSI-Paket-Download-Unterstützung für die Desktop-App hinzugefügt.

Neu: Onboarding-Anleitungen

Parallel zum Release wurde ein vollständiger Onboarding-Bereich veröffentlicht, der auf fünf Rollen ausgerichtet ist — Benutzer, Abteilungsleiter, IT-Administratoren, DevOps-Ingenieure und Sicherheitsspezialisten. Jede Anleitung behandelt genau das, was jemand in dieser Rolle am ersten Tag konfigurieren muss, ohne Vorkenntnisse des Produkts vorauszusetzen.

Administratoren, die Passwork organisationsweit einführen, erhalten ein Playbook mit LDAP- und SSO-Integration, Tresorstruktur und Massen-Benutzerbereitstellung. DevOps-Teams erhalten einen separaten Track für CLI- und SDK-Nutzung, Service-Accounts und Secret-Injection in CI/CD-Pipelines. Sicherheits- und Compliance-Verantwortliche können Checklisten durcharbeiten, die auf ISO 27001, DSGVO und NIST abgestimmt sind.

Passwork gewinnt Top Performer Sommer 2026 auf SourceForge

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

PassworkPasswork Team

Cybersecurity-News-Rückblick: Der Monat, in dem KI-Agenten eigenständig anzugreifen begannen

Ein GPT-5.6-Agent entkam seiner Sandbox und durchbrach die Hugging-Face-Infrastruktur. SonicWall lieferte zwei 0-Days, die einen vollständigen Passwort- und TOTP-Reset erzwangen. IBMs Breach-Cost-Report 2026 erreichte einen Rekord von 4,99 Millionen Dollar. Hier erfahren Sie, was im Juli in der Cybersicherheit passiert ist und was Ihr Team zuerst patchen sollte.

PassworkPasswork Team

IBM Cost of a Data Breach Report 2026: Die 6-Millionen-Dollar-KI-Bedrohung, die niemand behebt

Globale Breach-Kosten erreichen 2026 einen Rekord von 4,99 Millionen Dollar, wobei die Erkennung 247 Tage dauert. KI-gesteuerte Angriffe steigen um 56 %, aber die eigentliche Krise: Verteidiger setzen KI überall ein, außer dort, wo Angreifer einbrechen. 92 % der von KI betroffenen Organisationen hatten keine angemessenen Zugriffskontrollen.

PassworkAlex Muntyan

Passwork's latest release focuses on one problem every distributed team eventually runs into: what happens to password access when the connection drops. Passwork 7.7 adds secure offline mode to both desktop and mobile apps, while keeping admins fully in control of what gets cached locally.

Secure offline access for desktop and mobile apps

Users can now open password records even when their device has no connection to the server. Getting there takes two deliberate steps, so nothing ends up on a device by accident.

First, a user marks specific record with an offline icon , available both in the password info card and in the general password list. This adds selected records to a synced list visible across all that user's devices under the Offline tab in the navigation panel — at this point nothing is downloaded or available offline yet.

Second, on a device, the user opens the Offline tab in the desktop or mobile app and selects Enable on this device. Only then does Passwork pull the encrypted records into a local cache on that specific device.

When opening the desktop or mobile app without an internet connection, only records previously saved for offline access are available. If the server becomes unreachable mid-session, the app offers three options:

• Sign out of the desktop or mobile app
• Retry the connection to the server
• Switch to offline mode to view only cached records

Once connectivity returns, Passwork syncs the cache and uploads a log of every offline view to the server.

Admin controls, visibility, and risk tracking

Offline access is governed at the role level and doesn't run unchecked. Admins retain full control over who uses it and how it's tracked.

Role-based permissions

Administrators decide which roles can use offline access, how long a device can go unsynced before its cache is wiped, and how many records a single device can hold.

Full audit trail

Every offline download appears in the event log and on the security dashboard. All actions performed on offline records are also reflected in the Activity log once the device syncs, just like any other password. This gives security teams the same level of oversight over offline access as they already have over online activity.

Device-level insight

Admins can see who cached a record, on which device, and when that device last synced. The access modal for a folder or vault also displays the user and device name, so admins can trace offline activity down to the specific device without leaving the permissions view.

Exposure tracking

Passwork Security panel treats an offline record as a potential exposure the moment it lands in a local cache, whether or not the user actually opens it. This follows the same logic already applied to viewed records.

Default-off policy

After upgrading to version 7.7, the feature is enabled by default only for Owner and Administrator roles. Everyone else starts with it off.

Offline essentials

• Where it works. Records can be marked for offline access from any app and web client, but viewing them offline is only available in the mobile and desktop apps. It must be enabled separately on each device.
• What data is available. Without a connection, users can only view passwords they've already added to the offline list and synced beforehand.
• Automatic expiration. If a device doesn't sync within the timeframe set by the administrator, cached records are automatically wiped.
• Role settings. Administrators set the rules for users: how many records can be stored per device and how long they remain valid without syncing.
• Admin control. Administrators decide which roles can use offline access at all and can disable it entirely for specific roles. Every cached record stays visible in the Activity log and access modals, showing which user cached it, on which device, and when it last synced.
• Activity tracking. Once a device reconnects, all actions performed offline sync to the Activity log, appearing alongside the record's regular history — giving admins full visibility, just as with any online activity.

Offline limitations

• Read-only. In offline mode, records can only be viewed. Creating, editing, or deleting a password requires a connection to the server.
• Revocation. Revoking access to a record doesn't wipe the local copy instantly — the change only takes effect once the device comes back online.
• Plan availability. Offline access is available only in the Advanced plan.

File attachment controls

Administrators can now disable file attachments to records across the entire organization. Once turned off, users can't add files to any password record, regardless of role or vault permissions. The setting is located under Vault management → Settings → General.

Search and navigation improvements

Search results now include a URLs column alongside a parent directory column for folders, making it easier to identify where items live without opening them. The search bar now activates automatically as soon as you start typing. We also removed substring splitting in search queries, so results now match your intent more accurately.

Desktop and mobile apps

Both desktop and mobile apps now include the offline access implementation described above. Mobile picks up additional updates: org-wide controls to block screenshots and screen recording (System settings → Browser extensions and mobile apps) and search across folders instead of just individual records. Also added MSI package download support for the desktop app.

New: Onboarding guides

Alongside the release, we published a full onboarding section built around five roles — users, department managers, IT administrators, DevOps engineers, and security specialists. Each guide covers exactly what someone in that role needs to configure on day one, with no assumption of prior familiarity with the product.

Administrators rolling out Passwork organization-wide get a playbook covering LDAP and SSO integration, vault structure, and bulk user provisioning. DevOps teams get a separate track for CLI and SDK usage, service accounts, and secret injection into CI/CD pipelines. Security and compliance officers can work through checklists mapped to ISO 27001, GDPR, and NIST.

Passwork wins Top Performer Summer 2026 on SourceForge

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

PassworkPasswork Team

Cybersecurity news recap: The month AI agents started attacking on their own

A GPT-5.6 agent escaped its sandbox and breached Hugging Face infrastructure. SonicWall shipped two 0-days that forced a full password and TOTP reset. IBM’s 2026 breach cost report hit a record $4.99 million. Here’s what happened in cybersecurity this July and what your team needs to patch first.

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

Tresor-Richtlinien in Passwork (auch als Tresortypen bezeichnet): eine konfigurierbare Governance-Ebene, mit der Administratoren für jede Kategorie von Tresoren festlegen können, wer die permanenten Administratoren sind, welches Zugangslevel die Ersteller des Tresors erhalten und wer Tresore dieses Typs erstellen darf. Einmal festgelegt, gelten diese Regeln automatisch für jeden Tresor, der unter diesem Typ erstellt wird.

Die meisten Unternehmen können nicht mit Sicherheit sagen, wer Administratorrechte über den gemeinsamen Anmeldedaten-Tresor eines bestimmten Teams hat, da Admin-Zugriff informell gewährt wird, ohne eine zugrundeliegende Richtlinie. Enterprise-Passwort-Tresor-Richtlinien beheben dies, indem sie Admin-Rechte an die Tresor-Richtlinie selbst binden und nicht an denjenigen, der den Tresor zufällig erstellt hat.

Dieser Leitfaden erklärt, wie die Tresortypen-Architektur von Passwork CIOs und CISOs ein funktionierendes Modell für Tresor-Governance bietet, das über einfache Passwortregeln hinausgeht.

Was sind Tresor-Richtlinien und warum CIOs sie benötigen

Tresor-Richtlinien sind Governance-Regeln, die festlegen, wer einen Tresor erstellen kann, wer automatisch Administratorzugriff erhält und wer nicht von diesem Zugriff entfernt werden kann. Sie verlagern das Gespräch von „Passwort-Komplexitätsanforderungen" zu Tresor-Governance: strukturelle Kontrolle über die Speicherung von Unternehmensanmeldedaten, nicht nur über die Anmeldedaten selbst.

Drei Kategorien von Tools beanspruchen, dieses Problem zu lösen: 

• Consumer-Passwortmanager handhaben die gemeinsame Nutzung von Anmeldedaten für Einzelpersonen oder kleine Teams gut, wurden aber nicht für abteilungsübergreifende Governance im großen Maßstab entwickelt. 
• Privileged Access Management (PAM)-Plattformen sichern Infrastruktur- und Dienstkonten ab, verursachen aber Kosten und Komplexität, die die meisten Anwendungsfälle für die gemeinsame Nutzung von Anmeldedaten nicht benötigen. 
• Enterprise-Passwortmanager mit dedizierten Tresor-Richtlinien-Engines befinden sich zwischen beiden — und dieser Ansatz ist der Fokus dieses Artikels.

Handlungsempfehlung für CIOs: Führen Sie in Ihrer Organisation ein Audit nach „Schatten-Tresoren" durch — gemeinsame Ordner oder Team-Tresore, die ohne Wissen der IT erstellt wurden, oft innerhalb eines Consumer-Tools, das eine einzelne Abteilung eigenständig eingeführt hat.

Die Architektur hinter Tresor-Richtlinien: Wie Passwork die Zugangskontrolle strukturiert

Passwork 7.1 führte eine Tresortypen-Architektur ein, bei der jede Tresor-Richtlinie ihre eigenen Administratoren, Ersteller-Berechtigungen und Erstellungsregeln definiert, bevor ein einziger Tresor existiert. Jeder neue Tresor, der unter dieser Richtlinie erstellt wird, erbt automatisch die zugewiesenen Administratoren, und der Besitzer des Tresors kann diese nicht entfernen.

Zwei grundlegende Tresortypen werden standardmäßig mitgeliefert: Benutzer-Tresore, private oder gemeinsame Anmeldedatenspeicher, die vollständig von ihrem Ersteller kontrolliert werden, und Unternehmens-Tresore, die immer die Unternehmensadministratoren der Organisation einschließen. Darüber hinaus können Administratoren unbegrenzt viele benutzerdefinierte Tresortypen erstellen — einen pro Abteilung, Projekt oder Zugangsstufe — jeweils mit eigenen zugewiesenen Administratoren und Erstellungsregeln.

Dies führt zu drei konkreten Ergebnissen für das Unternehmen:

• Kontrolle über Team-Tresore ohne einen einzelnen Super-Administrator, der einen Masterschlüssel zu jedem Passwort im Unternehmen besitzt.
• Ein Wiederherstellungspfad, der funktioniert, wenn jemand das Unternehmen verlässt oder den Zugriff verliert, durch ein vorab bereitgestelltes Wiederherstellungskonto, dessen Masterpasswort offline gespeichert ist.
• Kein obligatorischer „Ein-Knopf"- oder Masterschlüssel, der alle Anmeldedaten der gesamten Organisation auf einmal entsperrt.

Version 7.4 fügte Einschränkungskontrollen speziell für Benutzer-Tresore hinzu, mit denen Administratoren auch auf der Ebene der persönlichen Tresore Freigabe- und Erstellungsberechtigungen einschränken können. Dies schließt eine Lücke, die die grundlegenden Tresortypen allein nicht abdeckten.

Handlungsempfehlung für CIOs: Ordnen Sie Ihre Organisationsstruktur den Tresortypen zu — einen pro Abteilung oder Projekt — und weisen Sie Unternehmensadministratoren zu, bevor Teams beginnen, eigenständig Tresore zu erstellen.

Wie Passwork im Vergleich zu anderen Ansätzen zur Tresor-Zugangskontrolle abschneidet

Für jedes Tool zur Verwaltung von Anmeldedaten ist entscheidend, ob die Admin-Rolle vorab an eine Richtlinie gebunden ist und ob die Wiederherstellung des Zugriffs einen Schlüssel erfordert, der gleichzeitig alles andere in der Organisation öffnet. In der folgenden Tabelle ist „Nein" in der Spalte „Einzelner Schlüssel" die gewünschte Antwort: Es bedeutet, dass es keinen eingebauten Single Point of Failure gibt.

Consumer-orientierte Passwortmanager erlauben es Team-Admins oft, einen gemeinsamen Tresor zu verwalten, wenden diese Richtlinie aber selten automatisch auf jeden neuen Tresor an, den eine Abteilung erstellt. 

Einige Tools setzen auf einen einzelnen Super-Admin, der das Passwort jedes Benutzers zurücksetzen und auf jeden gemeinsamen Ordner im Unternehmen zugreifen kann. Andere binden alle Unternehmens-Tresore an einen einzigen gemeinsamen Verschlüsselungsschlüssel, sodass die Kompromittierung dieses Schlüssels alles auf einmal offenlegt. 

PAM-Plattformen lösen ein anderes Problem: Sie sichern privilegierte Infrastruktur-Anmeldedaten, oft hinter einem eigenen Master- oder Breakglass-Schlüssel, anstatt die Passwort-Freigabe auf Teamebene zu regeln.

Handlungsempfehlung für CIOs: Bewerten Sie Ihr aktuelles Anmeldedaten-Tool anhand dieser drei Kriterien: richtliniengebundene Admin-Zuweisung, ein funktionierender Wiederherstellungspfad und das Fehlen eines obligatorischen universellen Schlüssels.

Die 5-Punkte-Tresor-Governance-Checkliste, die jeder CIO umsetzen sollte

Fünf spezifische Konfigurationsentscheidungen verwandeln die Bereitstellung eines Passwortmanagers in funktionierende Tresor-Governance. Jede adressiert einen bestimmten Fehlermodus, der bei echten Incident-Response-Einsätzen beobachtet wurde — kein theoretisches Risiko.

• Deaktivieren Sie die Erstellung und Freigabe privater Tresore, wo sie nicht benötigt wird. Uneingeschränkte private Tresore sind genau der Weg, wie Schatten-Tresore außerhalb der Sichtbarkeit der IT entstehen. Beschränken Sie die Erstellung privater Tresore auf Rollen, die sie wirklich benötigen.
• Weisen Sie jeder Team- und Abteilungs-Tresor-Richtlinie Unternehmensadministratoren zu. Dies garantiert eine kontinuierliche Aufsicht, ohne davon abhängig zu sein, dass sich jemand daran erinnert, sich selbst hinzuzufügen.
• Definieren Sie eine Notfallzugriffsrichtlinie, bevor Sie sie benötigen. Entscheiden Sie sich zwischen einem einzigen organisationsweiten Wiederherstellungsbereich oder separaten Wiederherstellungskonten pro Abteilung und speichern Sie die Master-Anmeldedaten für dieses Wiederherstellungskonto offline.
• Implementieren Sie RBAC (rollenbasierte Zugangskontrolle) über Active Directory oder LDAP. Die automatische Synchronisierung von Gruppen und Rollen wendet das Prinzip der minimalen Rechtevergabe an und eliminiert manuelle Bereitstellungsfehler, wenn Mitarbeiter ihre Rollen wechseln.
• Richten Sie Passwortlänge und Rotationsregeln an den aktuellen NIST-Richtlinien aus. NIST SP 800-63B Rev. 4 (2025) setzt ein Minimum von 15 Zeichen für Passwörter fest, die als einziger Authentifizierungsfaktor verwendet werden, und schafft die obligatorische 90-Tage-Rotationsanforderung offiziell ab (NIST SP 800-63B, 2025) [exakte Veröffentlichungs-URL vor dem Druck überprüfen]. Erzwungene Rotation ohne Hinweise auf eine Kompromittierung führt dazu, dass Benutzer vorhersehbare, inkrementierte Passwörter verwenden — genau das Ergebnis, das die Richtlinie jetzt unterbinden soll.

Handlungsempfehlung für CIOs: Führen Sie in diesem Quartal ein Gap-Audit gegen alle fünf Richtlinien durch und weisen Sie für jede Feststellung einen Verantwortlichen zu, anstatt das Audit als einmaligen Bericht zu behandeln.

Erfüllung von NIS2- und ISO 27001-Anforderungen mit Tresor-Governance

Tresor-Richtlinien ordnen sich direkt zwei Anforderungen zu, die Prüfer zuerst überprüfen: dokumentierte Zugangskontrolle und ein überprüfbarer Audit-Trail. Die NIS2-Richtlinie (EU) 2022/2555, Artikel 21(2), verlangt Zugangskontrollrichtlinien und Multi-Faktor-Authentifizierung als Teil der Cybersicherheits-Risikomanagementmaßnahmen einer Einrichtung. Die Kontrollen 5.15 und 8.15 von ISO/IEC 27001:2022 erfordern dieselbe Kombination: ein definiertes Zugangsmodell plus einen Nachweis darüber, wer es wann genutzt hat.

An eine Tresor-Richtlinie gebundene Unternehmensadministratoren decken die Zugangskontrollseite ab, ohne eine manuelle Tabelle zu erfordern. Zeitgestempelte, exportierbare Audit-Logs decken den Rest ab.

Verizons 2026 DBIR stellte fest, dass Anmeldedaten in irgendeiner Phase bei 39 % der Sicherheitsverletzungen eine Rolle spielten, in 13 % der bestätigten Sicherheitsverletzungen der initiale Zugriffsvektor waren und der führende Vektor bei 52 % der Basic Web Application Attacks. IBMs 2026 Cost of a Data Breach Report beziffert die globalen durchschnittlichen Kosten einer Sicherheitsverletzung auf 4,99 Millionen US-Dollar — ein Anstieg von 12 % gegenüber dem Vorjahr und ein Rekordhoch.

Handlungsempfehlung für CIOs: Fordern Sie diesen Monat von Ihrem Sicherheitsteam einen aktuellen NIS2-Zugangskontroll-Abdeckungsbericht an — bevor ein Prüfer zuerst danach fragt.

Was das für Ihren Rollout bedeutet

Tresor-Governance ist eine strukturelle Entscheidung, die genauso getroffen wird wie Netzwerksegmentierung: Sie wird um Abteilungen und Risikostufen herum entworfen, bevor ein Vorfall eine Neugestaltung erzwingt. Die Organisationen, die dies richtig machen, behandeln es von Anfang an so. Unter NIS2 und DSGVO ist diese Struktur nun eine Anforderung für Unternehmen im Geltungsbereich.

Beginnen Sie mit dem Audit, nicht mit dem Tool. Erfassen Sie, welche Tresore heute existieren, wer sie tatsächlich kontrolliert und wo der Wiederherstellungspfad unterbrochen wird, wenn eine Person das Unternehmen verlässt.

Häufig gestellte Fragen

Las políticas de bóvedas de Passwork (también llamadas Tipos de Bóveda): una capa de gobernanza configurable que permite a los administradores definir, para cada categoría de bóveda, quiénes son sus administradores permanentes, qué nivel de acceso obtienen los creadores de bóvedas y quién tiene permitido crear bóvedas de ese tipo. Una vez establecidas, estas reglas se aplican automáticamente a cada bóveda creada bajo ese tipo.

La mayoría de las empresas no pueden afirmar con certeza quién tiene derechos de administrador sobre la bóveda de credenciales compartidas de un equipo determinado, porque el acceso de administrador se otorga de manera informal, sin una política detrás. Las políticas de bóvedas de contraseñas empresariales solucionan esto vinculando los derechos de administrador a la política de la bóveda en sí, no a quien la creó.

Esta guía explica cómo la arquitectura de Tipos de Bóveda de Passwork proporciona a los CIO y CISO un modelo funcional para la gobernanza de bóvedas, más allá de las reglas básicas de contraseñas.

Qué son las políticas de bóvedas y por qué los CIO las necesitan

Las políticas de bóvedas son reglas de gobernanza que determinan quién puede crear una bóveda, quién obtiene automáticamente acceso de administrador a ella y quién no puede ser removido de ese acceso. Cambian la conversación de «requisitos de complejidad de contraseñas» a gobernanza de bóvedas: control estructural sobre el almacenamiento de credenciales corporativas, no solo sobre las credenciales en sí.

Tres categorías de herramientas afirman resolver esto: 

• Los gestores de contraseñas de consumo manejan bien el intercambio de credenciales personales o de equipos pequeños, pero no fueron diseñados para la gobernanza departamental a escala. 
• Las plataformas de gestión de acceso privilegiado (PAM) aseguran cuentas de servicio y de nivel de infraestructura, pero añaden costos y complejidad que la mayoría de los casos de uso de intercambio de credenciales no necesitan. 
• Los gestores de contraseñas empresariales con motores de políticas de bóvedas dedicados se sitúan entre ambos, y ese es el enfoque en el que se centra este artículo.

Acción para el CIO: Audite su organización en busca de «bóvedas no autorizadas» — carpetas compartidas o bóvedas de equipo creadas sin conocimiento de TI, a menudo dentro de una herramienta de consumo que un departamento individual adoptó de forma independiente.

La arquitectura detrás de las políticas de bóvedas: cómo Passwork estructura el control de acceso

Passwork 7.1 introdujo una arquitectura de tipos de bóveda donde cada política de bóveda define sus propios administradores, permisos del creador y reglas de creación antes de que exista una sola bóveda. Cada nueva bóveda construida bajo esa política hereda automáticamente sus administradores designados, y el propietario de la bóveda no puede eliminarlos.

Dos tipos de bóveda básicos vienen por defecto: Bóvedas de usuario, almacenes de credenciales privados o compartidos controlados completamente por su creador, y Bóvedas de empresa, que siempre incluyen a los administradores corporativos de la organización. Más allá de estos, los administradores pueden crear tipos de bóveda personalizados ilimitados, uno por departamento, proyecto o nivel de acceso, cada uno con sus propios administradores designados y reglas de creación.

Esto produce tres resultados concretos para el negocio:

• Control sobre las bóvedas de equipo sin un único superadministrador que posea una clave maestra para todas las contraseñas de la empresa.
• Una ruta de recuperación que funciona cuando alguien se va o pierde acceso, a través de una cuenta de recuperación preaprovisionada cuya contraseña maestra se almacena fuera de línea.
• Sin «un botón» obligatorio ni clave maestra que desbloquee todas las credenciales de la organización a la vez.

La versión 7.4 añadió controles de restricción específicamente para Bóvedas de usuario, permitiendo a los administradores limitar los permisos de compartir y creación también en el nivel de bóveda personal, cerrando una brecha que los tipos de bóveda básicos por sí solos no cubrían.

Acción para el CIO: Mapee su estructura organizacional a tipos de bóveda, uno por departamento o proyecto, y asigne administradores corporativos antes de que los equipos comiencen a crear bóvedas por su cuenta.

Cómo se compara Passwork con otros enfoques de control de acceso a bóvedas

Lo que importa para cualquier herramienta de gestión de credenciales es si el rol de administrador está vinculado a una política de antemano, y si recuperar el acceso requiere una clave que también abre todo lo demás en la organización. En la tabla siguiente, «No» en la columna de clave única es la respuesta deseada: significa que no hay un único punto de fallo incorporado.

Los gestores de contraseñas orientados al consumidor a menudo permiten que los administradores de equipo gestionen una bóveda compartida, pero rara vez aplican esa política automáticamente a cada nueva bóveda que crea un departamento. 

Algunas herramientas dependen de un único superadministrador que puede restablecer la contraseña de cualquier usuario y acceder a cada carpeta compartida en la empresa. Otras vinculan todas las bóvedas corporativas a una única clave de cifrado compartida, de modo que comprometer esa clave expone todo a la vez. 

Las plataformas PAM resuelven un problema diferente: almacenan credenciales privilegiadas de infraestructura, a menudo detrás de su propia clave maestra o de emergencia, en lugar de gobernar el intercambio de contraseñas a nivel de equipo.

Acción para el CIO: Evalúe su herramienta de credenciales actual contra estos tres criterios: asignación de administradores vinculada a políticas, una ruta de recuperación funcional y la ausencia de una clave universal obligatoria.

La lista de verificación de 5 políticas de gobernanza de bóvedas que todo CIO debería implementar

Cinco decisiones de configuración específicas convierten una implementación de gestor de contraseñas en gobernanza de bóvedas funcional. Cada una aborda un modo de fallo distinto observado en compromisos reales de respuesta a incidentes, no un riesgo teórico.

• Desactive la creación y el intercambio de bóvedas privadas donde no sea necesario. Las bóvedas privadas sin restricciones son exactamente cómo se forman las bóvedas no autorizadas fuera de la visibilidad de TI. Restrinja la creación de bóvedas privadas a los roles que realmente lo necesiten.
• Asigne administradores corporativos a cada política de bóveda de equipo y departamental. Esto garantiza supervisión continua sin depender de que ningún individuo recuerde añadirse a sí mismo.
• Defina una política de acceso de emergencia antes de necesitarla. Decida entre un contorno de recuperación único para toda la organización o cuentas de recuperación separadas por departamento, y almacene las credenciales maestras de esa cuenta de recuperación fuera de línea.
• Implemente RBAC (control de acceso basado en roles) a través de Active Directory o LDAP. La sincronización de grupos y roles aplica automáticamente el principio de mínimo privilegio y elimina errores de aprovisionamiento manual cuando el personal cambia de rol.
• Alinee las reglas de longitud y rotación de contraseñas con la guía NIST actual. NIST SP 800-63B Rev. 4 (2025) establece un mínimo de 15 caracteres para contraseñas usadas como único factor de autenticación y retira formalmente el requisito de rotación obligatoria cada 90 días (NIST SP 800-63B, 2025) [verificar URL de publicación exacta antes de imprimir]. La rotación forzada sin evidencia de compromiso empuja a los usuarios hacia contraseñas predecibles e incrementadas, que es precisamente el resultado que la guía ahora desaconseja.

Acción para el CIO: Realice una auditoría de brechas contra las cinco políticas este trimestre, y asigne un responsable para cada hallazgo en lugar de tratar la auditoría como un informe único.

Cumplimiento de los requisitos de NIS2 e ISO 27001 con gobernanza de bóvedas

Las políticas de bóvedas se mapean directamente a dos requisitos que los auditores verifican primero: control de acceso documentado y una pista de auditoría verificable. La Directiva NIS2 (UE) 2022/2555, Artículo 21(2), requiere políticas de control de acceso y autenticación multifactor como parte de las medidas de gestión de riesgos de ciberseguridad de una entidad. Los controles 5.15 y 8.15 de ISO/IEC 27001:2022 requieren la misma combinación: un modelo de acceso definido más un registro de quién lo ejerció y cuándo.

Los administradores corporativos vinculados a una política de bóveda cubren el lado del control de acceso sin una hoja de cálculo manual. Los registros de auditoría con marca de tiempo y exportables cubren el resto.

El DBIR 2026 de Verizon encontró credenciales presentes en alguna etapa del 39% de las brechas, como vector de acceso inicial en el 13% de las brechas confirmadas, y como vector principal detrás del 52% de los Ataques Básicos a Aplicaciones Web. El informe Cost of a Data Breach 2026 de IBM sitúa el costo promedio global de una brecha en $4,99 millones, un aumento del 12% respecto al año pasado y un máximo histórico.

Acción para el CIO: Solicite a su equipo de seguridad un informe actual de cobertura de control de acceso NIS2 este mes, antes de que un auditor lo solicite primero.

Qué significa esto para su implementación

La gobernanza de bóvedas es una decisión estructural, tomada de la misma manera que la segmentación de red: diseñada en torno a departamentos y niveles de riesgo antes de que un incidente fuerce un rediseño. Las organizaciones que hacen esto bien lo tratan así desde el principio. Bajo NIS2 y GDPR, esa estructura es ahora un requisito para las empresas dentro del alcance.

Comience con la auditoría, no con la herramienta. Mapee qué bóvedas existen hoy, quién las controla realmente y dónde se rompe la ruta de recuperación si una persona se va.

Preguntas frecuentes

Passwork's vault policies (also called Vault Types): a configurable governance layer that lets administrators define, for each category of vault, who its permanent administrators are, what access level vault creators get, and who is allowed to create vaults of that type. Once set, these rules apply automatically to every vault created under that type.

Most enterprises can't say with certainty who has administrator rights over a given team's shared credential vault, because admin access gets granted informally, without a policy behind it. Enterprise password vault policies fix this by binding admin rights to the vault's policy itself, not to whoever happened to create it.

This guide explains how Passwork's Vault Types architecture gives CIOs and CISOs a working model for vault governance, beyond basic password rules.

What are vault policies and why CIOs need them

Vault policies are governance rules that determine who can create a vault, who is automatically granted administrator access to it, and who cannot be removed from that access. They shift the conversation from "password complexity requirements" to vault governance: structural control over corporate credential storage, not just the credentials themselves.

Three categories of tools claim to solve this: 

• Consumer password managers handle personal or small-team credential sharing well but were not built for departmental governance at scale. 
• Privileged access management (PAM) platforms secure infrastructure-level and service accounts but add cost and complexity that most credential-sharing use cases don't need. 
• Enterprise password managers with dedicated vault policy engines sit between the two, and that's the approach this article focuses on.

CIO action item: Audit your organization for "rogue vaults" — shared folders or team vaults created without IT's knowledge, often inside a consumer tool an individual department adopted independently.

The architecture behind vault policies: how Passwork structures access control

Passwork 7.1 introduced a vault types architecture where each vault policy defines its own administrators, creator permissions, and creation rules before a single vault exists. Every new vault built under that policy automatically inherits its designated administrators, and the vault's owner cannot remove them.

Two basic vault types ship by default: User vaults, private or shared credential stores controlled entirely by their creator, and Company vaults, which always include the organization's corporate administrators. Beyond these, administrators can create unlimited custom vault types, one per department, project, or access tier, each with its own designated administrators and creation rules.

This produces three concrete outcomes for the business:

• Command over team vaults without a single super-administrator holding a master key to every password in the company.
• A recovery path that works when someone leaves or loses access, through a pre-provisioned recovery account whose master password is stored offline.
• No mandatory "one button" or master key that unlocks the entire organization's credentials at once.

Version 7.4 added restriction controls specifically for User vaults, letting administrators limit sharing and creation permissions on the personal-vault tier too, closing a gap that basic vault types alone didn't cover.

CIO action item: Map your organizational structure to vault types, one per department or project, and assign corporate administrators before teams start creating vaults on their own.

How Passwork compares to other approaches to vault access control

What matters for any credential management tool is whether the admin role is bound to a policy in advance, and whether recovering access requires a key that also opens everything else in the organization. In the table below, "No" in the single-key column is the answer you want: it means there's no built-in single point of failure.

Consumer-oriented password managers often let team admins manage a shared vault, but rarely apply that policy automatically to every new vault a department creates. 

Some tools rely on a single super admin who can reset any user's password and reach every shared folder in the company. Others tie all corporate vaults to one shared encryption key, so compromising that key exposes everything at once. 

PAM platforms solve a different problem: they vault privileged infrastructure credentials, often behind their own master or breakglass key, rather than governing team-level password sharing.

CIO action item: Score your current credential tool against these three criteria: policy-bound admin assignment, a working recovery path, and the absence of a mandatory universal key.

The 5-policy vault governance checklist every CIO should implement

Five specific configuration decisions turn a password manager deployment into functioning vault governance. Each addresses a distinct failure mode observed in real incident response engagements, not a theoretical risk.

• Disable private vault creation and sharing where it isn't required. Unrestricted private vaults are exactly how rogue vaults form outside IT's visibility. Restrict private vault creation to roles that genuinely need it.
• Assign corporate administrators to every team and departmental vault policy. This guarantees continuous oversight without depending on any single individual remembering to add themselves.
• Define an emergency access policy before you need one. Decide between a single organization-wide recovery contour or separate recovery accounts per department, and store master credentials for that recovery account offline.
• Implement RBAC (role-based access control) through Active Directory or LDAP. Syncing groups and roles automatically applies the principle of least privilege and removes manual provisioning errors when staff change roles.
• Align password length and rotation rules with current NIST guidance. NIST SP 800-63B Rev. 4 (2025) sets a 15-character minimum for passwords used as the sole authentication factor and formally retires the mandatory 90-day rotation requirement (NIST SP 800-63B, 2025) [verify exact publication URL before print]. Forced rotation without evidence of compromise pushes users toward predictable, incremented passwords, which is precisely the outcome the guidance now discourages.

CIO action item: Run a gap audit against all five policies this quarter, and assign an owner for each finding rather than treating the audit as a one-time report.

Meeting NIS2 and ISO 27001 requirements with vault governance

Vault policies map directly onto two requirements auditors check first: documented access control and a verifiable audit trail. NIS2 Directive (EU) 2022/2555, Article 21(2), requires access control policies and multi-factor authentication as part of an entity's cybersecurity risk-management measures. ISO/IEC 27001:2022 controls 5.15 and 8.15 require the same pairing: a defined access model plus a record of who exercised it and when.

Corporate administrators bound to a vault policy cover the access-control side without a manual spreadsheet. Timestamped, exportable audit logs cover the rest.

Verizon's 2026 DBIR found credentials present at some stage of 39% of breaches, as the initial access vector in 13% of confirmed breaches, and the lead vector behind 52% of Basic Web Application Attacks. IBM's 2026 Cost of a Data Breach Report puts the global average breach cost at $4.99 million, a 12% increase over last year and a record high.

CIO action item: Ask your security team for a current NIS2 access-control coverage report this month, before an auditor asks for it first.

What this means for your rollout

Vault governance is a structural decision, made the way network segmentation is: designed around departments and risk tiers before an incident forces a redesign. The organizations that get this right treat it that way from the start. Under NIS2 and GDPR, that structure is now a requirement for enterprises in scope.

Start with the audit, not the tool. Map which vaults exist today, who actually controls them, and where the recovery path breaks if one person leaves.

Frequently asked questions

Passwork 7.7: Secure offline mode for desktop and mobile apps

Passwords now work offline too. Passwork 7.7 brings secure offline access with full admin oversight, org-wide file attachment controls, and five new role-based onboarding guides for a smoother rollout.

Passwork BlogPasswork Team

Verizon DBIR 2026: 10 stats that should change your security strategy

Verizon’s 2026 DBIR analyzed 22,000+ breaches across 145 countries. Vulnerability exploitation overtook credential abuse as the top attack vector, while ransomware, third-party risk, and AI-assisted attacks all grew sharply. Here are the 10 numbers that matter.

Passwork BlogAlex Muntyan

NIS2 password requirements: What European companies must do in 2026

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

Passwork BlogAlex Muntyan

Biometrische Authentifizierung verifiziert eine Person anhand eines Merkmals wie eines Fingerabdrucks oder Gesichtsscans. Bei einer Passkey-Anmeldung entsperrt diese biometrische Eigenschaft oder eine lokale PIN einen auf dem Gerät gespeicherten kryptografischen Schlüssel, anstatt ein Passwort irgendwohin zu senden. NIST SP 800-63B Revision 4 behandelt Biometrie als Teil der Multi-Faktor-Authentifizierung in Verbindung mit einem physischen Authenticator, nicht als eigenständigen Remote-Authenticator.

Für unternehmensweite Passwort-Tresore ergibt sich der Sicherheitsvorteil aus der Credential-Architektur, der Endpunkt-Integrität und der Autorisierungsrichtlinie — nicht allein aus der biometrischen Geste. Die operative Entscheidung für IT-Verantwortliche lautet, ob die Organisation verwaltete Endpunkte, einen getesteten nicht-biometrischen Fallback und eine ausreichend solide Tresor-Governance unterstützen kann, sobald die Anmeldereibung entfällt.

Was ist biometrische Authentifizierung

Biometrische Authentifizierung verifiziert die Identität einer Person anhand eines physischen Merkmals wie eines Fingerabdrucks, Gesichts oder Irismusters — anstelle eines auswendig gelernten Geheimnisses. Auf modernen Geräten erfolgt die Prüfung lokal: Der Sensor vergleicht den Live-Scan mit einer auf dem Gerät gespeicherten Vorlage und entsperrt bei Übereinstimmung einen kryptografischen Schlüssel oder gewährt Zugang zum System.

Es handelt sich um eine Verifizierungsmethode, nicht um ein Zugriffskontrollsystem. Ein Fingerabdruck- oder Gesichtsscan bestätigt, wer am Gerät sitzt. Er sagt nichts darüber aus, auf welche Dateien, Systeme oder Tresore diese Person zugreifen darf — das ist eine separate Ebene, die durch Rollen, Berechtigungen und Richtlinien gesteuert wird.

Gängige Implementierungen umfassen:

• Fingerabdruckerkennung, ausgelesen durch einen kapazitiven Sensor, der in einen Laptop, ein Telefon oder einen eigenständigen Schlüsselanhänger eingebaut ist.
• Gesichtserkennung, wie Face ID oder Windows Hello, unter Verwendung einer Kamera und auf den meisten Geräten eines Infrarot-Tiefensensors zur Abwehr von Foto-Spoofing.
• Iris- und Retina-Scanning, hauptsächlich in Hochsicherheitseinrichtungen eingesetzt und nicht für die alltägliche Unternehmensanmeldung.
• Spracherkennung, weniger verbreitet für die Geräteanmeldung, häufiger bei Identitätsprüfungen im Call-Center.

Im Unternehmenskontext erscheint Biometrie fast immer als lokaler Entsperrschritt in einem größeren Authentifizierungsablauf — am häufigsten bei einem WebAuthn-Passkey — und nicht als eigenständiger Weg zu Unternehmenssystemen. NIST SP 800-63B Revision 4 formalisiert diese Rolle: Biometrie funktioniert als Teil der Multi-Faktor-Authentifizierung in Verbindung mit einem physischen Authenticator, nicht als eigenständiges Remote-Credential.

Was biometrische Authentifizierung absichert (und was nicht)

Biometrie verifiziert die Person lokal, auf dem Gerät oder Authenticator. Sie sichert allein nichts auf Serverseite ab. Diese Aufgabe übernimmt die kryptografische WebAuthn-Assertion zusammen mit den Rollen- und Tresor-Richtlinien des Passwort-Managers, die festlegen, worauf die verifizierte Person tatsächlich zugreifen kann.

Passwörter sind wiederholbare Geheimnisse, die ein Mitarbeiter in ein Anmeldefeld eingibt — was sie phishbar und systemübergreifend wiederverwendbar macht. Eine lokale biometrische Geste autorisiert stattdessen die Nutzung eines privaten Schlüssels, der unter der Kontrolle eines Authenticators bleibt — es gibt also kein gemeinsames Geheimnis, das während der Übertragung abgefangen werden könnte.

Die W3C WebAuthn Level 3-Spezifikation definiert hier zwei Credential-Typen. Ein Einzelgerät-Credential kann nicht exportiert werden. Ein backup-fähiges Multigerät-Credential, allgemein als synchronisierter Passkey bezeichnet, kann auf den Geräten eines Benutzers innerhalb desselben Plattform-Ökosystems verfügbar sein. Beide halten den privaten Schlüssel aus den Händen der vertrauenden Partei. Nur das erste kann zutreffend als an ein Gerät gebunden beschrieben werden.

Vorteile der biometrischen Authentifizierung

Die biometrische Anmeldung eliminiert den Schritt, bei dem ein Mitarbeiter ein Geheimnis eingibt, das gephisht, erraten oder wiederverwendet werden kann. In Kombination mit einem Passkey ersetzt sie ein wiederholbares Passwort durch einen privaten Schlüssel, der das Gerät niemals verlässt — und Branchendaten zeigen messbare Gewinne bei der Anmeldegeschwindigkeit sowie weniger Help-Desk-Tickets im Zusammenhang mit verlorenen Anmeldedaten.

Der Vorteil ist struktureller Natur, nicht kosmetisch. Ein Passwort in einem Anmeldefeld kann von einer gefälschten Website, einem Keylogger oder einer Liste wiederverwendeter Anmeldedaten erfasst werden. Ein biometrisch entsperrter Passkey bietet nichts Vergleichbares, das während der Übertragung gestohlen werden könnte, da der private Schlüssel niemals das Netzwerk überquert.

Der Geschwindigkeitsgewinn ist dokumentiert. Der Passkey Index der FIDO Alliance berichtet von einer Erfolgsquote von 93 % bei Passkey-Anmeldungen gegenüber 63 % bei anderen Methoden, einem Rückgang der Anmeldezeit um 73 % und einer Reduzierung anmeldebezogener Help-Desk-Vorfälle um bis zu 81 %. Dies sind branchenweit gemeldete Zahlen von teilnehmenden Organisationen, keine Garantie für eine bestimmte Bereitstellung.

Nichts davon macht Biometrie allein zu einer vollständigen Lösung. Der Gewinn zeigt sich, wenn eine biometrische Eigenschaft ein gut verwaltetes Credential autorisiert. Als bloßer eigenständiger Faktor verwendet, tauscht sie ein widerrufbares Geheimnis gegen ein permanentes — genau der Kompromiss, den der nächste Abschnitt behandelt.

Risiken der biometrischen Authentifizierung

Biometrische Authentifizierung bindet den Zugang an einen Fingerabdruck, Gesichtsscan oder ein Irismuster, das bei Kompromittierung nicht geändert werden kann. Anders als bei einem Passwort kann ein Fingerabdruck nach einer Datenschutzverletzung nicht rotiert werden, und zentralisierte biometrische Datenbanken werden zu hochwertigen Zielen für Angreifer. Diese Risiken machen Biometrie zu einem schlechten eigenständigen Ersatz für das Credential-Management.

• Unwiderruflichkeit ist das Kernproblem. NIST SP 800-63B klassifiziert Biometrie als Identifikator, nicht als Geheimnis, da sie nicht wie ein Passwort zurückgesetzt werden kann (NIST SP 800-63B, Abschnitt 5.2.3). Sobald eine Vorlage durchsickert, ist dieser Faktor dauerhaft kompromittiert.
• Zentralisierte Daten sind ein Single Point of Failure. Die Speicherung biometrischer Vorlagen in einer Datenbank schafft ein hochwertiges Ziel: Eine Verletzung dort legt Fingerabdruck- oder Gesichtsdaten für jeden registrierten Benutzer auf einmal offen. Eine Passwortverletzung erzwingt ein Zurücksetzen. Eine biometrische Verletzung hat keine gleichwertige Lösung. Dies unterscheidet sich von der später in diesem Artikel diskutierten „zentralen Governance", die zentralisiert, wer auf ein Geheimnis zugreifen kann — nicht die biometrische Vorlage selbst.
• Spoofing. Fotos und Deepfake-Videos haben in unabhängigen Tests Consumer-Grade-Sensoren überwunden, und die Genauigkeit variiert stark je nach Sensorqualität und Beleuchtung.
• Regulatorische Exposition. DSGVO Artikel 9 behandelt biometrische Identifikatoren als besondere Kategorie von Daten und erfordert ausdrückliche Einwilligung sowie strengere Schutzmaßnahmen als bei Standardanmeldedaten.

Nichts davon macht Biometrie allein zu einer vollständigen Lösung. Der Gewinn zeigt sich, wenn eine biometrische Eigenschaft ein gut verwaltetes Credential autorisiert. Als bloßer eigenständiger Faktor verwendet, tauscht sie ein widerrufbares Geheimnis gegen ein permanentes — genau der Kompromiss, den der nächste Abschnitt behandelt.

Biometrie, Passkeys und WebAuthn: Die Kontrollgrenze

Die Kontrollgrenze ist die Linie zwischen dem, was eine biometrische Eigenschaft lokal autorisiert, und dem, was WebAuthn gegenüber einem Server beweist. Ein Fingerabdruck oder Gesichtsscan entsperrt einen gerätegebundenen Schlüssel; die kryptografische Assertion, die dieser Schlüssel erzeugt und die an eine Relying Party ID gebunden ist, ist das, was der Server tatsächlich prüft.

Fingerabdruck- und Gesichtsauthentifizierung funktionieren beide für die Mitarbeiteranmeldung auf unterstützten verwalteten Geräten, aber die richtige Wahl hängt von der Sensorqualität, der Reife des Gerätemanagements, den Barrierefreiheitsanforderungen und dem akzeptablen Risikoniveau ab. Keine der Methoden ist eine universelle Lösung. Beide schneiden bei Geschwindigkeit, Zuverlässigkeit und Governance-Aufwand unterschiedlich ab.

Lokale Verifizierung versus zentrale biometrische Abgleichung

Lokale Verifizierung prüft eine biometrische Eigenschaft gegen eine auf dem Gerät selbst gespeicherte Vorlage. Zentrale Verifizierung prüft sie gegen eine anderswo gehaltene Referenzdatenbank. NIST empfiehlt lokale Verifizierung, da sie die Notwendigkeit eines zentral gehaltenen biometrischen Speichers eliminiert oder stark reduziert, der bei einer Verletzung zu einem Single Point of Failure wird.

Der Unterschied lässt sich am einfachsten anhand zweier vertrauter Beispiele erkennen:

• Lokale Verifizierung: Windows Hello oder Touch ID prüft einen Fingerabdruck gegen eine Vorlage, die in einer sicheren Hardware-Enklave auf dem Gerät gespeichert ist. Die Vorlage verlässt niemals den Chip.
• Zentrale Verifizierung: Grenzkontrollschleusen am Flughafen gleichen das Gesicht eines Reisenden mit einer auf einem Server gehaltenen Passdatenbank ab, nicht auf der Schleuse selbst.

Organisationen sollten das Vorlagen-Handhabungsmodell für jede Geräteplattform und Produktintegration bestätigen, anstatt anzunehmen, dass es überall identisch ist. Lokale Verifizierung und zentralisierte Geheimnis-Governance stehen nicht im Widerspruch. Das Ziel ist, biometrische Vorlagen lokal zu halten und gleichzeitig die Kontrolle darüber zu zentralisieren, wer auf ein bestimmtes Credential zugreifen kann — zwei verschiedene Dinge werden aus zwei verschiedenen Gründen zentralisiert (oder nicht).

NIST SP 800-63B Revision 4 legt drei spezifische Benchmarks für anwendbare Bereitstellungen fest:

• False Match Rate (FMR): Die Wahrscheinlichkeit, dass die falsche Person akzeptiert wird. NIST fordert 1 zu 10.000 oder besser.
• False Non-Match Rate (FNMR): Die Wahrscheinlichkeit, dass der legitime Benutzer abgelehnt wird. NIST empfiehlt unter 5 %.
• Presentation Attack Detection (PAD): Erforderlich für Gesichtserkennung, empfohlen für Fingerabdruck- und Iris-Modalitäten.

Behandeln Sie diese Zahlen als Beschaffungs-Benchmarks für die Anbieterprüfung, nicht als garantierte reale Leistung. Die tatsächliche Sensorgenauigkeit variiert je nach Hersteller.

Fingerabdruck versus Gesichtserkennung auf verwalteten Geräten

Fingerabdruck- und Gesichtserkennung scheitern unterschiedlich, und beide benötigen einen getesteten Fallback anstelle der Standardannahme, dass der Sensor immer funktioniert.

Eine Gesichtserkennungs-Einführung ohne PAD im Umfang ist nach NIST-Richtlinien unvollständig. Unabhängige Forschung hat gezeigt, dass Gesichtssensoren mit einem modifizierten Bild statt einem Live-Gesicht umgangen werden können — genau der Angriff, den PAD erkennen soll.

Was tatsächlich als Faktor bei der Multi-Faktor-biometrischen Authentifizierung zählt

Eine biometrische Eigenschaft funktioniert nach NIST-Richtlinien niemals als eigenständiger Faktor. Multi-Faktor-biometrische Authentifizierung kombiniert eine lokale „Etwas, das Sie sind"-Prüfung mit einem physischen, kryptografischen Authenticator, der „Etwas, das Sie haben" repräsentiert. Die biometrische Eigenschaft aktiviert diesen Authenticator. Sie dient nicht allein als Identitätsnachweis, und die Registrierung eines Fingerabdrucks und eines Gesichts auf demselben Gerät erzeugt keine zwei Faktoren, sondern nur zwei Möglichkeiten, denselben zu entsperren.

Zwei Authenticator-Typen stecken hinter diesen Aufforderungen, und sie überleben einen Geräteverlust unterschiedlich. Ein Plattform-Authenticator ist in das Gerät des Mitarbeiters eingebaut und geht mit diesem verloren. Ein Hardware-Sicherheitsschlüssel wandert zwischen Geräten und fügt einen physischen Besitzfaktor hinzu, der einen verlorenen oder gelöschten Laptop überlebt.

WebAuthn-Credentials fügen eine zweite Schutzebene über dem Faktor selbst hinzu: Jedes Credential ist an eine Relying Party ID gebunden — die Kennung der spezifischen Website oder des Dienstes, bei dem es registriert ist. Ein für eine vertrauende Partei registriertes Credential kann nicht auf einer nicht verwandten, ähnlich aussehenden Domain verwendet werden. Diese Bindung, nicht die biometrische Eigenschaft, verleiht WebAuthn seine Phishing-Resistenz.

Nichts davon ersetzt separate Richtlinienkontrollen. MFA-Einstellungen, Gerätevertrauenshaltung, Sitzungs-Timeout und bedingter Zugriff für risikoreiche Aktionen sitzen weiterhin auf der Anmeldemethode selbst.

Die fünf Kontrollen für die Unternehmenseinführung

Biometrischer Komfort bleibt auf dem Gerät des Mitarbeiters. Geheimnis-Governance bleibt bei zentral verwalteten Identitäts- und Passwort-Tresor-Kontrollen. Die Trennung der beiden eliminiert die Notwendigkeit, eine unternehmenseigene biometrische Datenbank aufzubauen, während die volle organisatorische Kontrolle darüber erhalten bleibt, wer auf welches Geheimnis zugreifen kann.

Die drei Faktoren, die diesen Artikel eröffnet haben — verwaltete Endpunkte, ein funktionierender Fallback und Tresor-Governance — gliedern sich in fünf spezifische Kontrollen auf, sobald Sie bereit sind, sie zu operationalisieren. Dies ist das Modell Lokale biometrische Entsperrung / Zentrale Geheimnis-Governance, ein praktisches Framework anstelle eines formalen Standards.

Verwaltete Endpunkte und Benutzerverifizierung

• Verwalteter Endpunkt und unterstützter Authenticator. Definieren Sie, welche Geräte, Betriebssystemversionen und Sensoren berechtigt sind, bevor jemand sich registriert.
• Lokale Benutzerverifizierung. Eine biometrische Eigenschaft oder PIN entsperrt den Authenticator. Eine alternative nicht-biometrische Methode bleibt für jeden verfügbar, der sie benötigt.

Identitätsrichtlinie und zentrale Geheimnis-Governance

• Identitäts- und Step-up-Richtlinie. SSO, MFA, Sitzungsdauer und zusätzliche Verifizierung für risikoreiche administrative Aktionen.
• Zentrale Geheimnis-Governance. Rollen, Least Privilege, Tresor-Segmentierung, Aktivitätsprüfung und sicheres Teilen regeln die tatsächlichen Unternehmens-Credentials.

Wiederherstellung und Widerruf

• Wiederherstellung und Widerruf. Ein dokumentierter Prozess deckt die Reaktion auf Geräteverlust, Passkey-Zurücksetzung oder -Entfernung, Break-Glass-Zugang und Audit-Überprüfung ab.

Biometrische Daten, die eine Person eindeutig identifizieren können, werden laut der Anleitung des ICO zur biometrischen Erkennung nach der britischen DSGVO als besondere Kategorie von Daten klassifiziert. Einwilligung allein ist nicht der entscheidende Faktor: Anwendbares Recht kann eine Rechtsgrundlage, eine Bedingung für besondere Kategorien, Transparenz und Datenminimierung zusätzlich erfordern, und die Einzelheiten variieren je nach Rechtsordnung. Diese Bewertung gehört zu den Rechts- und Datenschutzteams der Organisation. Dieses Modell löst sie nicht; es reduziert, wie viele biometrische Daten überhaupt zentral existieren müssen.

Verwendung von Passwork-Passkeys mit Tresor-Governance

Passwork unterstützt Passkey-Anmeldung auf Basis des WebAuthn-Standards und ermöglicht Benutzern die Authentifizierung mit einem gerätegebundenen Schlüssel anstelle eines Passworts. Unterstützte Plattform-Authenticatoren umfassen Face ID, Touch ID, Windows Hello und kompatible Hardware-Sicherheitsschlüssel. Ein Administrator aktiviert diese Funktion für bestimmte Rollen, und jedes Mitglied dieser Rolle kann dann einen Passkey registrieren.

Der 4-Schritte-Passkey-Anmelde-Workflow

Die Passkey-Einführung in Passwork folgt einer festen Sequenz, die Authentifizierungsänderungen innerhalb des bestehenden Rollen- und Audit-Modells hält, anstatt als separates System daneben zu laufen.

1. Rolleneinstellung aktivieren. Ein Administrator entscheidet, welche Rollen die Anmeldeoption „Passkey anstelle von Passwort verwenden" nutzen dürfen.
2. Passkey registrieren. Ein Mitarbeiter registriert einen Plattform-Passkey oder einen WebAuthn-Sicherheitsschlüssel auf der Authentifizierungsseite seines Kontos.
3. Mit lokaler Verifizierung anmelden. Der Mitarbeiter bestätigt eine gerätelokale biometrische oder PIN-Aufforderung. Der Passkey beweist den Schlüsselbesitz, ohne jemals das lokale oder Domain-Passwort zu übertragen.
4. Offboarding oder Verlust handhaben. Wenn ein Gerät verloren geht, ersetzt wird oder ein Mitarbeiter das Unternehmen verlässt, entfernt oder setzt der Administrator den Passkey zurück und folgt dem Wiederherstellungs- und Zugriffsprüfungsverfahren der Organisation.

Pilot-Metriken und Rollout-Checkliste

Eine biometrische Einführung ist bereit, über eine Pilotgruppe hinaus zu expandieren, sobald jede der fünf oben genannten Kontrollen einen Verantwortlichen, einen Bereitschaftsnachweis und eine definierte Fehlerreaktion hat. Diese Pilot-Bereitschafts-Checkliste verwandelt das Modell in eine Go/No-Go-Entscheidung anstelle einer Einführung, die auf Annahmen skaliert.

Verfolgen Sie die Registrierungsabschlussrate, Authentifizierungserfolgsrate, Falsch-Ablehnungs- und Fallback-Häufigkeit, Help-Desk-Volumen, Zeit zum Entfernen eines verlorenen Geräts und Zeit zum Widerrufen des Zugangs nach dem Offboarding. Vergleichen Sie Ihre Zahlen mit den zuvor zitierten FIDO Alliance-Benchmarks: Eine Abschluss- oder Erfolgsrate weit unter 93 % oder eine Fallback-Rate weit über dem, was Ihre Pilotgruppe vorhergesagt hat, ist es wert, untersucht zu werden, bevor Sie über das erste Team hinaus skalieren.

Fazit

Biometrische Authentifizierung und Passwort-Manager-Governance lösen unterschiedliche Probleme. Die Vermischung ist der Punkt, an dem die meisten Einführungen scheitern. Biometrie entsperrt das Gerät; Tresor-Governance entscheidet, wer auf welches Geheimnis zugreift. Halten Sie diese Aufgaben getrennt, und der Gewinn ist schnellere Anmeldung ohne eine biometrische Datenbank, die niemand aufbauen wollte, oder einen einzelnen Schwachpunkt, der echte Zugriffskontrolle ersetzt.

Wählen Sie ein Team, das bereits gemeinsame Admin-, SaaS- oder Infrastruktur-Credentials verwaltet, und pilotieren Sie die Trennung, bevor sie zur unternehmensweiten Praxis wird.

Häufig gestellte Fragen

IBM Cost of a Data Breach Report 2026: Die 6-Millionen-Dollar-KI-Bedrohung, die niemand behebt

Globale Kosten für Datenschutzverletzungen erreichen 2026 mit 4,99 Mio. $ einen Rekord, wobei die Erkennung 247 Tage dauert. KI-gesteuerte Angriffe steigen um 56 %, aber die eigentliche Krise: Verteidiger setzen KI überall ein, nur nicht dort, wo Angreifer einbrechen. 92 % der von KI-Verletzungen betroffenen Organisationen hatten keine angemessenen Zugriffskontrollen.

Passwork BlogAlex Muntyan

Shadow AI: Die versteckte Bedrohung, die Unternehmen 670.000 $ pro Datenschutzverletzung kostet

Shadow AI kostet Unternehmen 670.000 $ extra pro Datenschutzverletzung — und das meiste davon lässt sich auf Anmeldedaten zurückführen, die in öffentliche LLMs eingefügt wurden. Erfahren Sie, wie Shadow AI tatsächlich aussieht, warum es schwerer zu stoppen ist als Schatten-IT, und wie es verwaltet werden kann.

Passwork BlogAlex Muntyan

11 Risiken der Passwortwiederverwendung und wie man sie vermeidet

Die Wiederverwendung eines Passworts fühlt sich harmlos an. Ist es aber nicht. Hier erfahren Sie, warum ein geleaktes Credential die gesamte Sicherheit Ihrer Organisation gefährden kann — und wie Sie das verhindern können.

Passwork BlogAlex Muntyan

La autenticación biométrica verifica a una persona mediante una característica como una huella dactilar o un escaneo facial. En un flujo de inicio de sesión con passkey, ese dato biométrico, o un PIN local, desbloquea una clave criptográfica almacenada en el dispositivo en lugar de enviar una contraseña a ningún lugar. NIST SP 800-63B Revisión 4 trata los datos biométricos como parte de la autenticación multifactor combinada con un autenticador físico, no como un autenticador remoto independiente.

Para las bóvedas de contraseñas empresariales, el beneficio de seguridad proviene de la arquitectura de credenciales, la integridad del endpoint y la política de autorización, no solo del gesto biométrico. La decisión operativa para los líderes de TI es si la organización puede soportar endpoints gestionados, un respaldo alternativo no biométrico probado y una gobernanza de bóvedas lo suficientemente sólida como para importar una vez que desaparezca la fricción del inicio de sesión.

Qué es la autenticación biométrica

La autenticación biométrica verifica la identidad de una persona utilizando un rasgo físico, como una huella dactilar, rostro o patrón de iris, en lugar de un secreto memorizado. En los dispositivos modernos, la verificación ocurre localmente: el sensor compara el escaneo en vivo con una plantilla almacenada en el dispositivo y, si coincide, desbloquea una clave criptográfica u otorga acceso al sistema.

Es un método de verificación, no un sistema de control de acceso. Una huella dactilar o escaneo facial confirma quién está frente al dispositivo. No dice nada sobre qué archivos, sistemas o bóvedas debería poder alcanzar esa persona — eso es una capa separada, gestionada por roles, permisos y políticas.

Las implementaciones comunes incluyen:

• Reconocimiento de huellas dactilares, leído por un sensor capacitivo integrado en una laptop, teléfono o llavero de seguridad independiente.
• Reconocimiento facial, como Face ID o Windows Hello, utilizando una cámara y, en la mayoría de los dispositivos, un sensor de profundidad infrarrojo para resistir la suplantación con fotos.
• Escaneo de iris y retina, utilizado principalmente en instalaciones de alta seguridad en lugar del inicio de sesión corporativo cotidiano.
• Reconocimiento de voz, menos común para el inicio de sesión en dispositivos, más común en verificaciones de identidad en centros de llamadas.

En un contexto empresarial, los datos biométricos casi siempre aparecen como el paso de desbloqueo local en un flujo de autenticación más amplio, más comúnmente una passkey WebAuthn, en lugar de una forma independiente de acceder a los sistemas corporativos. NIST SP 800-63B Revisión 4 formaliza ese rol: los datos biométricos funcionan como parte de la autenticación multifactor, combinados con un autenticador físico, no como una credencial remota por sí solos.

Qué asegura (y qué no asegura) la autenticación biométrica

Los datos biométricos verifican a la persona localmente, en el dispositivo o autenticador. Por sí solos, no aseguran nada del lado del servidor. Ese trabajo pertenece a la aserción criptográfica WebAuthn y a la política de roles y bóvedas del gestor de contraseñas, que deciden a qué puede acceder realmente la persona verificada.

Las contraseñas son secretos reproducibles que un empleado escribe en un campo de inicio de sesión, lo que las hace susceptibles a phishing y reutilizables entre sistemas. Un gesto biométrico local, en cambio, autoriza el uso de una clave privada que permanece bajo el control de un autenticador, por lo que no hay ningún secreto compartido que interceptar en tránsito.

La especificación W3C WebAuthn Nivel 3 define dos tipos de credenciales aquí. Una credencial de dispositivo único no puede exportarse. Una credencial multidispositivo elegible para respaldo, comúnmente llamada passkey sincronizada, puede estar disponible en los dispositivos de un usuario dentro del mismo ecosistema de plataforma. Ambas mantienen la clave privada fuera de las manos de la parte que confía. Solo la primera se describe con precisión como vinculada a un dispositivo.

Ventajas de la autenticación biométrica

El inicio de sesión biométrico elimina el paso donde un empleado escribe un secreto que puede ser objeto de phishing, adivinado o reutilizado. Combinado con una passkey, reemplaza una contraseña reproducible con una clave privada que nunca sale del dispositivo, y los datos de la industria muestran ganancias medibles en la velocidad de inicio de sesión y menos tickets de soporte técnico relacionados con credenciales perdidas.

La ventaja es estructural, no cosmética. Una contraseña en un campo de inicio de sesión puede ser capturada por un sitio falso, un keylogger o una lista de credenciales reutilizadas. Una passkey desbloqueada biométricamente no tiene nada equivalente que robar en tránsito, porque la clave privada nunca atraviesa la red.

La ganancia de velocidad está documentada. El Índice de Passkeys de FIDO Alliance reporta una tasa de éxito del 93% para inicios de sesión con passkey frente al 63% para otros métodos, una disminución del 73% en el tiempo de inicio de sesión y hasta un 81% de reducción en incidentes de soporte técnico relacionados con el inicio de sesión. Estas son cifras reportadas por la asociación a nivel de toda la industria de organizaciones participantes, no una garantía para ninguna implementación específica.

Nada de esto convierte a los datos biométricos en una respuesta completa por sí solos. La ganancia aparece cuando un dato biométrico autoriza una credencial bien gobernada. Usado como un factor independiente básico, intercambia un secreto revocable por uno permanente, que es exactamente el compromiso que cubre la siguiente sección.

Riesgos de la autenticación biométrica

La autenticación biométrica vincula el acceso a una huella dactilar, escaneo facial o patrón de iris que no se puede cambiar si se ve comprometido. A diferencia de una contraseña, no se puede rotar una huella dactilar después de una brecha, y las bases de datos biométricas centralizadas se convierten en objetivos de alto valor para los atacantes. Estos riesgos hacen que los datos biométricos sean un mal reemplazo independiente para la gestión de credenciales.

• La irrevocabilidad es el problema central. NIST SP 800-63B clasifica los datos biométricos como un identificador, no un secreto, ya que no se pueden restablecer como una contraseña (NIST SP 800-63B, Sección 5.2.3). Una vez que se filtra una plantilla, ese factor queda comprometido para siempre.
• Los datos centralizados son un único punto de fallo. Almacenar plantillas biométricas en una base de datos crea un único objetivo de alto valor: una brecha allí expone los datos de huellas dactilares o faciales de todos los usuarios registrados a la vez. Una brecha de contraseñas obliga a un restablecimiento. Una brecha biométrica no tiene una solución equivalente. Este es un objeto diferente de la «gobernanza central» discutida más adelante en este artículo, que centraliza quién puede acceder a un secreto, no la plantilla biométrica en sí.
• Suplantación. Fotos y videos deepfake han vencido a sensores de grado consumidor en pruebas independientes, y la precisión varía ampliamente según la calidad del sensor y la iluminación.
• Exposición regulatoria. El Artículo 9 del GDPR trata los identificadores biométricos como datos de categoría especial, requiriendo consentimiento explícito y salvaguardas más estrictas que las credenciales estándar.

Nada de esto convierte a los datos biométricos en una respuesta completa por sí solos. La ganancia aparece cuando un dato biométrico autoriza una credencial bien gobernada. Usado como un factor independiente básico, intercambia un secreto revocable por uno permanente, que es exactamente el compromiso que cubre la siguiente sección.

Biometría, passkeys y WebAuthn: El límite de control

El límite de control es la línea entre lo que un dato biométrico autoriza localmente y lo que WebAuthn demuestra a un servidor. Una huella dactilar o escaneo facial desbloquea una clave vinculada al dispositivo; la aserción criptográfica que esa clave produce, limitada a un Relying Party ID, es lo que el servidor realmente verifica.

La autenticación por huella dactilar y facial funcionan ambas para el inicio de sesión de empleados en dispositivos gestionados compatibles, pero la elección correcta depende de la calidad del sensor, la madurez de la gestión de dispositivos, las necesidades de accesibilidad y el nivel de riesgo aceptable. Ningún método es una respuesta universal. Ambos tienen diferentes compensaciones en velocidad, fiabilidad y carga de gobernanza.

Verificación local versus coincidencia biométrica central

La verificación local compara un dato biométrico con una plantilla almacenada en el propio dispositivo. La verificación central lo compara con una base de datos de referencia mantenida en otro lugar. NIST recomienda la verificación local porque elimina, o reduce drásticamente, la necesidad de un almacén biométrico centralizado que se convierte en un único punto de fallo si se ve comprometido.

La distinción es más fácil de ver a través de dos ejemplos familiares:

• Verificación local: Windows Hello o Touch ID compara una huella dactilar con una plantilla almacenada en un enclave de hardware seguro en el dispositivo. La plantilla nunca sale del chip.
• Verificación central: las puertas de control fronterizo en aeropuertos comparan el rostro de un viajero con una base de datos de pasaportes mantenida en un servidor, no en la propia puerta.

Las organizaciones deben confirmar el modelo de manejo de plantillas para cada plataforma de dispositivo e integración de producto en lugar de asumir que es idéntico en todas partes. La verificación local y la gobernanza centralizada de secretos no están en conflicto. El objetivo es mantener las plantillas biométricas locales mientras se centraliza el control sobre quién puede acceder a una credencial determinada — dos cosas diferentes que se centralizan (o no) por dos razones diferentes.

NIST SP 800-63B Revisión 4 establece tres puntos de referencia específicos para implementaciones aplicables:

• Tasa de falsa aceptación (FMR): la probabilidad de que se acepte a la persona equivocada. NIST requiere 1 en 10.000 o mejor.
• Tasa de falso rechazo (FNMR): la probabilidad de que se rechace al usuario legítimo. NIST recomienda por debajo del 5%.
• Detección de ataques de presentación (PAD): requerida para reconocimiento facial, recomendada para modalidades de huella dactilar e iris.

Trate estas cifras como puntos de referencia de adquisición para la evaluación de proveedores, no como rendimiento garantizado en el mundo real. La precisión real del sensor varía según el fabricante.

Huella dactilar versus reconocimiento facial en dispositivos gestionados

El reconocimiento de huellas dactilares y facial fallan de manera diferente, y ambos necesitan un respaldo probado en lugar de una suposición predeterminada de que el sensor siempre funcionará.

Una implementación de reconocimiento facial sin PAD en el alcance está incompleta según la guía de NIST. La investigación independiente ha demostrado que los sensores faciales pueden ser eludidos con una imagen modificada en lugar de un rostro vivo, que es exactamente el ataque que PAD está diseñado para detectar.

Qué cuenta realmente como un factor en la autenticación biométrica multifactor

Un dato biométrico nunca funciona como un factor independiente bajo la guía de NIST. La autenticación biométrica multifactor combina una verificación local de «algo que eres» con un autenticador criptográfico físico que representa «algo que tienes». El dato biométrico activa ese autenticador. No sirve como prueba de identidad por sí solo, y registrar una huella dactilar y un rostro en el mismo dispositivo no crea dos factores, solo dos formas de desbloquear el mismo.

Dos tipos de autenticadores están detrás de estas solicitudes, y sobreviven a la pérdida del dispositivo de manera diferente. Un autenticador de plataforma está integrado en el dispositivo del empleado y se pierde junto con él. Una llave de seguridad de hardware se mueve entre dispositivos, añadiendo un factor de posesión física que sobrevive a una laptop perdida o borrada.

Las credenciales WebAuthn añaden una segunda capa de protección además del factor en sí: cada credencial está limitada a un Relying Party ID, el identificador del sitio o servicio específico en el que está registrada. Una credencial registrada para una parte que confía no se puede usar en un dominio similar no relacionado. Esa limitación, no el dato biométrico, es lo que le da a WebAuthn su resistencia al phishing.

Nada de esto reemplaza los controles de política separados. La configuración de MFA, la postura de confianza del dispositivo, el tiempo de espera de sesión y el acceso condicional para acciones de alto riesgo siguen estando por encima del método de inicio de sesión en sí.

Los cinco controles para la implementación empresarial

La conveniencia biométrica permanece en el dispositivo del empleado. La gobernanza de secretos permanece con los controles de identidad y bóveda de contraseñas gestionados centralmente. Separar los dos elimina la necesidad de construir una base de datos biométrica de la empresa mientras se mantiene el control organizacional completo sobre quién accede a qué secreto.

Los tres factores que abrieron este artículo — endpoints gestionados, un respaldo funcional y gobernanza de bóvedas — se desglosan en cinco controles específicos una vez que esté listo para operacionalizarlos. Este es el modelo de Desbloqueo Biométrico Local / Gobernanza Central de Secretos, un marco práctico en lugar de un estándar formal.

Endpoints gestionados y verificación de usuario

• Endpoint gestionado y autenticador compatible. Defina qué dispositivos, versiones de SO y sensores son elegibles antes de que alguien se registre.
• Verificación de usuario local. Un dato biométrico o PIN desbloquea el autenticador. Un método alternativo no biométrico permanece disponible para cualquiera que lo necesite.

Política de identidad y gobernanza central de secretos

• Política de identidad y autenticación adicional. SSO, MFA, duración de sesión y verificación adicional para acciones administrativas de alto riesgo.
• Gobernanza central de secretos. Roles, privilegio mínimo, segmentación de bóvedas, revisión de actividad y compartición segura gobiernan las credenciales corporativas reales.

Recuperación y revocación

• Recuperación y revocación. Un proceso documentado cubre la respuesta a dispositivos perdidos, restablecimiento o eliminación de passkey, acceso de emergencia y revisión de auditoría.

Los datos biométricos capaces de identificar de manera única a una persona se clasifican como datos de categoría especial bajo el GDPR del Reino Unido, según la guía de la ICO sobre reconocimiento biométrico. El consentimiento por sí solo no es el factor decisivo: la ley aplicable puede requerir una base legal, una condición de categoría especial, transparencia y minimización de datos además, y los detalles varían según la jurisdicción. Esa evaluación corresponde a los equipos legales y de privacidad de la organización. Este modelo no lo resuelve; reduce cuántos datos biométricos necesitan existir centralmente en primer lugar.

Uso de passkeys de Passwork con gobernanza de bóvedas

Passwork admite el inicio de sesión con passkey basado en el estándar WebAuthn, permitiendo a los usuarios autenticarse con una clave vinculada al dispositivo en lugar de una contraseña. Los autenticadores de plataforma compatibles incluyen Face ID, Touch ID, Windows Hello y llaves de seguridad de hardware compatibles. Un administrador lo habilita para roles específicos, y cada miembro de ese rol puede entonces elegir registrar una passkey.

El flujo de trabajo de inicio de sesión con passkey en 4 pasos

La adopción de passkey en Passwork sigue una secuencia fija que mantiene los cambios de autenticación dentro del modelo existente de roles y auditoría, en lugar de ejecutarse junto a él como un sistema separado.

1. Habilitar la configuración del rol. Un administrador decide qué roles pueden usar la opción de inicio de sesión «Usar passkey en lugar de contraseña».
2. Registrar la passkey. Un empleado registra una passkey de plataforma o una llave de seguridad WebAuthn en la página de Autenticación de su cuenta.
3. Iniciar sesión con verificación local. El empleado aprueba una solicitud local de biometría o PIN del dispositivo. La passkey demuestra la propiedad de la clave sin transmitir nunca la contraseña local o de dominio.
4. Gestionar la baja o pérdida. Si se pierde o reemplaza un dispositivo, o un empleado se va, el administrador elimina o restablece la passkey y sigue el procedimiento de recuperación y revisión de acceso de la organización.

Métricas piloto y lista de verificación de implementación

Una implementación biométrica está lista para expandirse más allá de un grupo piloto una vez que cada uno de los cinco controles anteriores tiene un propietario, evidencia de preparación y una respuesta de fallo definida. Esta lista de verificación de preparación piloto convierte el modelo en una puerta de decisión ir/no-ir en lugar de una implementación que escala sobre suposiciones.

Rastree la tasa de finalización de registro, tasa de éxito de autenticación, frecuencia de falso rechazo y respaldo, volumen de soporte técnico, tiempo para eliminar un dispositivo perdido y tiempo para revocar acceso después de la baja. Compare sus números con los puntos de referencia de FIDO Alliance citados anteriormente: una tasa de finalización o éxito muy por debajo del 93%, o una tasa de respaldo muy por encima de lo que predijo su grupo piloto, vale la pena investigar antes de escalar más allá del primer equipo.

Conclusión

La autenticación biométrica y la gobernanza del gestor de contraseñas resuelven problemas diferentes. Mezclarlos es donde la mayoría de las implementaciones fallan. Los datos biométricos desbloquean el dispositivo; la gobernanza de bóvedas decide quién accede a qué secreto. Mantenga esos trabajos separados, y el beneficio es un inicio de sesión más rápido sin una base de datos biométrica que nadie pretendía construir, o un único punto débil sustituyendo un control de acceso real.

Elija un equipo que ya maneje credenciales compartidas de administración, SaaS o infraestructura, y pruebe la separación antes de que se convierta en práctica de toda la empresa.

Preguntas frecuentes

Informe IBM 2026 sobre el costo de una brecha de datos: La amenaza de IA de $6M que nadie está solucionando

Los costos globales de brechas alcanzan un récord de $4.99M en 2026, con una detección que toma 247 días. Los ataques impulsados por IA aumentan un 56%, pero la verdadera crisis: los defensores despliegan IA en todas partes excepto donde los atacantes entran. El 92% de las organizaciones afectadas por brechas de IA tenían cero controles de acceso adecuados.

Passwork BlogAlex Muntyan

Shadow AI: La amenaza oculta que cuesta a las empresas $670K por brecha

Shadow AI cuesta a las empresas $670K extra por brecha — y la mayoría se remonta a credenciales pegadas en LLMs públicos. Aprenda qué aspecto tiene realmente shadow AI, por qué es más difícil de detener que shadow IT y cómo gobernarlo.

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

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

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

What is biometric authentication

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

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

Common implementations include:

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

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

What biometric authentication does (and does not) secure

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

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

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

Advantages of biometric authentication

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

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

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

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

Risks of biometric authentication

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

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

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

Biometrics, passkeys, and WebAuthn: The control boundary

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

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

Local verification versus central biometric matching

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

The distinction is easiest to see through two familiar examples:

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

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

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

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

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

Fingerprint versus facial recognition on managed devices

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

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

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

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

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

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

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

The five controls for enterprise rollout

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

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

Managed endpoints and user verification

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

Identity policy and central secret governance

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

Recovery and revocation

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

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

Using Passwork passkeys with vault governance

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

The 4-step passkey sign-in workflow

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

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

Pilot metrics and rollout checklist

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

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

Conclusion

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

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

Frequently asked questions

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

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

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

11 password reuse risks and how to avoid them

Reusing a password feels harmless. It isn’t. Here’s why one leaked credential can unravel your entire organization’s security — and how to stop it from happening.

Passwork BlogAlex Muntyan

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

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

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

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

Bedrohungen und Angriffe: Vorfälle des Monats

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

Claude kompromittierte drei Unternehmen während interner Tests

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

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

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

Quelle: Anthropic — 31. Juli 2026 

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

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

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

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

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

Quelle: Hugging Face Blog — 16. Juli 2026

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

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

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

Quelle: BleepingComputer — 27. Juli 2026 

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

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

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

Quelle: Help Net Security — 20. Juli 2026 

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

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

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

Quelle: CybersecurityDive — 10. Juli 2026 

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

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

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

Quelle: eSecurityPlanet — 22. Juli 2026 

Credential Stuffing gegen SonicWall-VPN kompromittiert 92 Konten

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

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

Quelle: CyberScoop — 28. Juli 2026 

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

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

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

Quelle: Cloud Security Alliance — 16. Juli 2026 

Schwachstellen: Patches und dringende Fixes

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

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

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

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

Quelle: CISA — 29. Juli 2026

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

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

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

Quelle: The Hacker News — 19. Juli 2026 

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

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

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

Quelle: The Hacker News — 23. Juli 2026

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

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

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

Quelle: Orca.security — 15. Juli 2026

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

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

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

Quelle: CISA KEV Alert — 28. Juli 2026 

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

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

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

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

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

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

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

Quelle: The Hacker News — 13. Juli 2026 

Authentifizierung und Zugriffsmanagement: Trends und Strategie

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

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

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

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

Quelle: Microsoft Security Blog — 13. Juli 2026 

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

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

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

Quelle: Infopoint Security — 15. Juli 2026 

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

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

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

Quelle: Help Net Security — 30. Juli 2026 

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

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

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

Quelle: IBM Security — 29. Juli 2026 

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

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

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

Quelle: Identity Theft Resource Center — 24. Juli 2026 

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

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

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

Quelle: Wyden Senate — 27. Juli 2026 

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

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

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

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

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

Quelle: Europäische Kommission — 8. Juli 2026

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

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

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

Quelle: Europäische Kommission — Juli 2026 

Zusammenfassung dieses Monats

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

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

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

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

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

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

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

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

Passwork BlogAlex Muntyan

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

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

PassworkPasswork Team

Passwork gewinnt Top Performer Sommer 2026 auf SourceForge

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

PassworkPasswork Team

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

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

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

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

Amenazas y ataques: Incidentes del mes

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

Claude vulneró tres empresas durante pruebas internas

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

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

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

Fuente: Anthropic – 31 de julio de 2026 

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

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

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

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

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

Fuente: Hugging Face Blog – 16 de julio de 2026

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

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

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

Fuente: BleepingComputer – 27 de julio de 2026 

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

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

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

Fuente: Help Net Security – 20 de julio de 2026 

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

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

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

Fuente: CybersecurityDive – 10 de julio de 2026 

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

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

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

Fuente: eSecurityPlanet – 22 de julio de 2026 

Credential stuffing contra SonicWall VPN compromete 92 cuentas

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

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

Fuente: CyberScoop – 28 de julio de 2026 

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

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

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

Fuente: Cloud Security Alliance – 16 de julio de 2026 

Vulnerabilidades: Parches y correcciones urgentes

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

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

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

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

Fuente: CISA – 29 de julio de 2026

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

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

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

Fuente: The Hacker News – 19 de julio de 2026 

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

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

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

Fuente: The Hacker News – 23 de julio de 2026

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

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

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

Fuente: Orca.security – 15 de julio de 2026

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

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

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

Fuente: Alerta CISA KEV – 28 de julio de 2026 

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

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

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

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

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

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

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

Fuente: The Hacker News – 13 de julio de 2026 

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

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

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

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

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

Fuente: Microsoft Security Blog – 13 de julio de 2026 

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

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

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

Fuente: Infopoint Security – 15 de julio de 2026 

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

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

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

Fuente: Help Net Security – 30 de julio de 2026 

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

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

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

Fuente: IBM Security – 29 de julio de 2026 

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

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

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

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

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

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

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

Fuente: Wyden Senate – 27 de julio de 2026 

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

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

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

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

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

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

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

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

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

Fuente: Comisión Europea – Julio de 2026 

Resumen del mes

Los eventos de julio se remontan a dos patrones.

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

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

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

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

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

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

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

Passwork BlogAlex Muntyan

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

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

PassworkPasswork Team

Passwork gana Top Performer Verano 2026 en SourceForge

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

PassworkPasswork Team

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

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

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

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

Threats and attacks: Incidents of the month

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

Claude breached three companies during internal tests

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

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

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

Source: Anthropic – July 31, 2026 

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

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

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

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

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

Source: Hugging Face Blog – July 16, 2026

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

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

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

Source: BleepingComputer – July 27, 2026 

Paidwork breach exposes 23.3 million users in Poland

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

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

Source: Help Net Security – July 20, 2026 

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

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

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

Source: CybersecurityDive – July 10, 2026 

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

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

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

Source: eSecurityPlanet – July 22, 2026 

Credential stuffing against SonicWall VPN compromises 92 accounts

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

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

Source: CyberScoop – July 28, 2026 

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

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

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

Source: Cloud Security Alliance – July 16, 2026 

Vulnerabilities: Patches and urgent fixes

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

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

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

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

Source: CISA – July 29, 2026

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

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

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

Source: The Hacker News – July 19, 2026 

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

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

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

Source: The Hacker News – July 23, 2026

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

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

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

Source: Orca.security – July 15, 2026

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

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

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

Source: CISA KEV Alert – July 28, 2026 

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

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

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

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

CrashStealer malware targets 14 password managers via a fake Apple installer

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

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

Source: The Hacker News – July 13, 2026 

Authentication and access management: trends and strategy

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

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

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

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

Source: Microsoft Security Blog – July 13, 2026 

Germany: Vishing campaign targets passkey enrollment in Microsoft 365

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

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

Source: Infopoint Security – July 15, 2026 

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

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

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

Source: Help Net Security – July 30, 2026 

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

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

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

Source: IBM Security – July 29, 2026 

ITRC: H1 2026 breach notifications already exceed all of 2025

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

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

Source: Identity Theft Resource Center – July 24, 2026 

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

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

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

Source: Wyden Senate – July 27, 2026 

EU regulation and standards: what's changing in Europe

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

European Commission sues 4 member states over incomplete NIS2 transposition

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

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

Source: European Commission – July 8, 2026

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

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

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

Source: European Commission – July 2026 

This month's recap

July's events trace back to two patterns.

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

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

Post-breach credential checklist (3 points):

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

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

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

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

Passwork BlogAlex Muntyan

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

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

PassworkPasswork Team

Passwork wins Top Performer Summer 2026 on SourceForge

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

PassworkPasswork Team

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

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

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

Was sind Passwortkomplexitätsregeln

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

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

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

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

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

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

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

Hier die Änderung in der Praxis:

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

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

Das Verhaltensversagen von Komplexitätsregeln

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

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

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

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

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

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

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

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

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

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

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

Wie Sie sich von Komplexitätsregeln verabschieden

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

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

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

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

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

Warum MFA und Passkeys das eigentliche Ziel sind

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

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

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

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

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

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

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

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

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

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

Die Umstellung vollziehen

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

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

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

Häufig gestellte Fragen

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

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

Passwork BlogAlex Muntyan

Sind Ihre Daten sicher? Aufsehenerregende Datenlecks 2025-2026 Leitfaden

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

Passwork BlogPasswork Team

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

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

Passwork BlogAlex Muntyan

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

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

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

Qué son las reglas de complejidad de contraseñas

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

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

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

Qué cambió NIST — y por qué importa

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

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

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

Este es el cambio en la práctica:

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

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

El fallo conductual de las reglas de complejidad

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

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

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

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

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

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

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

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

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

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

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

Cómo abandonar las reglas de complejidad

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Realizando el cambio

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

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

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

Preguntas frecuentes

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

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

Passwork BlogAlex Muntyan

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

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

Passwork BlogPasswork Team

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

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

Passwork BlogAlex Muntyan

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

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

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

What are password complexity rules

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

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

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

What NIST changed — and why it matters

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

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

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

Here is the shift in practice:

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

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

The behavioral failure of complexity rules

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

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

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

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

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

Length and randomness beat complexity — the math

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

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

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

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

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

How to move away from complexity rules

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

The 5-step complexity rule migration checklist:

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

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

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

Why MFA and passkeys are the real endgame

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

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

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

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

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

What a password manager enforces that Group Policy cannot

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

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

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

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

Making the switch

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

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

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

Frequently asked questions

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

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

Passwork BlogAlex Muntyan

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

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

Passwork BlogPasswork Team

Team password management: The complete guide for 2026

Learn how teams share credentials securely in 2026 — RBAC, audit logs, offboarding checklists, NIST SP 800-63B Rev. 4 requirements, and self-hosted vs. cloud deployment.

Passwork BlogAlex Muntyan

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

Was Zero-Knowledge tatsächlich bedeutet

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

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

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

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

Wie die Verschlüsselungskette funktioniert: Ein praktisches Beispiel

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

Hier ist die clientseitige Kette Schritt für Schritt:

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

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

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

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

Was Zero-Knowledge schützt — und was nicht

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

Schützt vor:

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

Schützt nicht vor:

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

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

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

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

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

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

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

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

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

Zero-Knowledge in der Praxis verstärken

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

Sicherheitsgrundlage:

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

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

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

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

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

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

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

Das Fazit

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

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

FAQ

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

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

Passwork BlogAlex Muntyan