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

Der Verizon 2026 Data Breach Investigations Report (DBIR) analysierte mehr als 22.000 bestätigte Datenschutzverletzungen in 145 Ländern — der größte Datensatz in der 19-jährigen Geschichte des Berichts. Die zentrale Erkenntnis: Die Ausnutzung von Schwachstellen hat den Missbrauch von Anmeldedaten als häufigsten initialen Zugriffsvektor überholt, während Ransomware, Drittanbieter-Risiken und KI-gestützte Angriffe stark zunahmen.

Dies ist die 19. Ausgabe des Berichts, und die Partnerschaft mit Anthropic, Qualys, Tenable, Tenchi Security, Fastly und DTEX ermöglichte es, über das reine Zählen von Vorfällen hinauszugehen. Der DBIR 2026 misst, wie schnell Organisationen patchen, wie lange Anbieter Multi-Faktor-Authentifizierung (MFA) deaktiviert lassen und wie Bedrohungsakteure generative KI (GenAI) in laufenden Kampagnen operationalisieren.

Die folgenden zehn Zahlen sind diejenigen, auf denen die Sicherheits-Roadmap für das nächste Jahr aufbauen sollte.

Was ist der Verizon Data Breach Investigations Report

Der Verizon Data Breach Investigations Report (DBIR) ist eine jährliche Analyse bestätigter Datenschutzverletzungen und Sicherheitsvorfälle weltweit, die seit 2008 veröffentlicht wird. Die Ausgabe 2026, die 19., umfasst Daten von Oktober 2024 bis November 2025 und stützt sich auf mehr als 31.000 Sicherheitsvorfälle, darunter über 22.000 bestätigte Datenschutzverletzungen in 145 Ländern — der größte Datensatz in der Geschichte des Berichts.

Wie die Daten zusammengestellt werden

Verizon erstellt den Bericht mit Beiträgen von fast 100 Partnerorganisationen, die jeweils Daten zu Datenschutzverletzungen und Vorfällen aus ihrem eigenen Betrieb liefern. Das DBIR-Team normalisiert diese Daten in ein gemeinsames Framework, das auf Bedrohungsakteuren, Aktionen, Assets und Attributen basiert. Dadurch können eine Datenschutzverletzung in einem Krankenhaus in Deutschland und ein Ransomware-Fall in Ohio als vergleichbare Datenpunkte erscheinen.

Im Gegensatz zu Bedrohungsberichten von Anbietern, die auf der Telemetrie eines einzelnen Unternehmens basieren, aggregiert der DBIR Daten über Branchen, Unternehmensgrößen und Regionen hinweg. Diese Breite macht ihn zu einem Referenzpunkt für Sicherheitsbudgetierung und Vorstandsberichte statt zu einer einzelnen Anbieter-Verkaufsnarrative.

Was ist neu im DBIR 2026-Datensatz

Die Partnerliste bestimmt, was der Bericht tatsächlich messen kann, und 2026 brachte eine Ergänzung, die seinen Umfang verändert. Anthropic steuerte Durchsetzungsdaten zu 793 Bedrohungsakteuren bei, die zwischen März 2025 und Februar 2026 von seinem Safeguards Team gekennzeichnet wurden und spezifischen MITRE ATT&CK-Techniken zugeordnet wurden.

Es ist das erste Mal, dass ein führendes KI-Labor diese Art von Datensatz zum DBIR beigetragen hat, und es ermöglicht dem Bericht, GenAI-Missbrauch mit tatsächlichen Durchsetzungszahlen statt mit Schätzungen zu quantifizieren.

Der vollständige Verizon 2026 Data Breach Investigations Report ist direkt bei Verizon verfügbar.

10 Statistiken aus dem DBIR 2026, die Ihre Prioritäten neu ausrichten sollten

Diese zehn Erkenntnisse markieren die deutlichsten Verschiebungen im DBIR 2026: Angreifer nutzen Schwachstellen schneller aus, als Verteidiger sie patchen, Drittanbieter-Risiken sind zu einem primären Vektor für Datenschutzverletzungen geworden, und generative KI skaliert bekannte Angriffstechniken, anstatt neue zu erfinden. Jede dieser Erkenntnisse weist auf eine spezifische Lücke in den meisten aktuellen Sicherheitsprogrammen hin.

1. Die Ausnutzung von Schwachstellen ist jetzt der häufigste initiale Zugriffsvektor

Die Ausnutzung von Schwachstellen stieg von 20 % der Datenschutzverletzungen im Bericht 2025 auf 31 % im Jahr 2026 — ein Anstieg von 55 %. Der Missbrauch von Anmeldedaten, der jahrelang den Spitzenplatz hielt, fiel im selben Zeitraum von 22 % auf 13 % als erste aufgezeichnete Aktion bei einer Datenschutzverletzung.

Die mediane Organisation musste 50 % mehr CISA Known Exploited Vulnerabilities (KEV) patchen als im Vorjahr — 16 kritische CVEs gegenüber 11 — während die vollständigen Behebungsraten auf 26 % sanken. Mehr Schwachstellen, langsameres Patchen und Angreifer, die die Ausnutzung mit KI-Unterstützung automatisieren — das ist keine Kombination, die Verteidigern in die Hände spielt. Wenn sich Ihre Patch-Kadenz seit 2023 nicht geändert hat, zeigen die Daten, dass Sie statistisch im Rückstand sind.

2. Der Missbrauch von Anmeldedaten berührt weiterhin 39 % jeder Angriffskette

Dass die Ausnutzung von Schwachstellen den Spitzenplatz beim initialen Zugriff übernommen hat, bedeutet nicht, dass gestohlene Anmeldedaten keine Rolle mehr spielen. Die 13 %-Zahl zählt nur den ersten aufgezeichneten Schritt bei einer Datenschutzverletzung. Wenn der DBIR den Missbrauch von Anmeldedaten an irgendeinem Punkt eines Angriffs verfolgt, taucht er in 39 % der Datenschutzverletzungen auf und ist damit der häufigste Engpass in fast jedem Angriffsmuster des Berichts.

Angreifer passen sich auch besser an. Viele haben Tools wie Cobalt Strike zugunsten legitimer Fernzugriffswege aufgegeben — Desktop-Sharing-Software und VPNs — was die auf Anmeldedaten basierende laterale Bewegung schwerer mit signaturbasierter Erkennung erfassbar macht. MFA ist mittlerweile Standard, reicht aber allein nicht aus.

Die Zahlen zur Passworthygiene erklären, warum der Missbrauch von Anmeldedaten fortbesteht. Anmeldedaten selbst tauchen als gestohlener Datentyp in 28 % der Datenschutzverletzungen auf, und Passwortrichtlinien gehören zu den Schutzmaßnahmen, die der DBIR neben Berechtigungsmanagement und Konfigurationshärtung als Kontrollmaßnahmen gegen Angriffstechniken hervorhebt. Grundlegende Härtungsprüfungen bestätigen die Lücke: 97 % der bewerteten Geräte scheiterten bei der Prüfung zur Begrenzung fehlgeschlagener Anmeldeversuche vor der Sperrung, und 90 % scheiterten bei der Durchsetzung einer Mindestlänge von 15 Zeichen.

3. Ransomware trifft 48 % der Datenschutzverletzungen, aber Opfer zahlen weniger

Ransomware stieg von 44 % auf 48 % der Datenschutzverletzungen in diesem Jahr und bleibt die schädlichste Bedrohungskategorie. Der kontraintuitive Teil: 69 % der Ransomware-Opfer weigerten sich zu zahlen, und die mediane Zahlung sank von 150.000 USD auf 139.875 USD.

Diese Kombination deutet darauf hin, dass Backup-Strategien, Incident-Response-Reife und Strafverfolgungsmaßnahmen an Boden gewinnen. Aber das schiere Volumen der Ransomware-Vorfälle, angetrieben von Initial Access Brokern und Infostealer-Märkten, bedeutet, dass es ein Fehler ist, sie als ein Problem zu behandeln, das allein durch Backups gelöst wird. Die Organisationen, die einen Angriff am besten überstanden, waren diejenigen, die nie verhandeln mussten.

4. Drittanbieter-Datenschutzverletzungen machen jetzt 48 % aller Vorfälle aus

Die Beteiligung von Drittanbietern an Datenschutzverletzungen erreichte 48 %, gegenüber 30 % ein Jahr zuvor — ein Anstieg von 60 % zusätzlich zu einer Verdopplung im Vorjahr. Mehrere der disruptivsten Datenschutzverletzungen des Jahres 2025 betrafen mehrere kompromittierte Anbieter gleichzeitig.

Die Grundursachen sind gewöhnlich: fehlende MFA bei Cloud-Konten, übermäßige Berechtigungen und schwache Passwörter. Nur 23 % der Drittanbieter-Organisationen beheben MFA-Lücken bei ihren Cloud-Konten vollständig, obwohl die Hälfte aller MFA-Befunde innerhalb eines Monats gelöst wurde.

Schwache Passwörter und Berechtigungsfehlkonfigurationen schnitten weitaus schlechter ab: Die mediane Zeit zur Behebung der Hälfte dieser Befunde erstreckte sich auf fast acht Monate. Jährliche Anbieterfragebögen können ein Problem nicht erfassen, dessen Behebung auf Anbieterseite acht Monate dauert.

5. Nur 26 % der kritischen Schwachstellen wurden vollständig behoben

Die vollständige Behebung von CISA KEV-Schwachstellen sank von 38 % auf 26 %, und die mediane Patch-Zeit stieg von 32 auf 43 Tage. Der Anteil der Schwachstellen, die vollständig unbehoben blieben, wuchs von 12 % auf 16 %.

Die Überlebenskurve ist schlechter als die Durchschnittswerte vermuten lassen. Am Tag 28 nach der Erkennung blieben 35 % der KEV-Schwachstellen offen, was 184 Millionen Schwachstelleninstanzen entspricht (gegenüber 31 Millionen vor drei Jahren). Das Erkennungsvolumen wuchs fast achtfach, von 68,7 Millionen Datensätzen im Jahr 2022 auf 527,3 Millionen im Jahr 2025, während die Patch-Kapazität sich kaum bewegte.

Patchen allein wird diese Lücke nicht schließen. Da es bei aktuellen Volumina unrealistisch ist, alles zu beheben, muss die Behebung nach Ausnutzungsrisiko statt nur nach CVSS-Score priorisiert werden. Der deutlichste Beweis des Berichts dafür: 80 % der dauerhaft ausgenutzten Schwachstellen waren mehr als zwei Jahre alt, was bedeutet, dass Angreifer größtenteils Schwachstellen bearbeiten, die Organisationen bereits kannten und sich entschieden hatten, nicht zu priorisieren.

6. Bedrohungsakteure nutzen generative KI über einen Median von 15 ATT&CK-Techniken

Die Zusammenarbeit von Verizon mit Anthropic lieferte einen der wesentlichsten Beiträge des Berichts: eine Analyse von 793 Bedrohungsakteuren, die zwischen März 2025 und Februar 2026 gegen die Nutzungsrichtlinien von Anthropic verstoßen haben. Der mediane Akteur nutzte KI-Unterstützung über 15 verschiedene MITRE ATT&CK-Techniken.

Die Extremfälle sind der aufschlussreichere Datenpunkt. Einige Kampagnen umfassten 40–50 Techniken in mehrstufigen, agentischen Operationen, bei denen die KI als Co-Entwickler über die gesamte Angriffskette fungierte.

Dieses Ausmaß hat keine neuartigen Bedrohungen hervorgebracht. Weniger als 1 % dieser Akteure fielen in die Kategorie hohes oder kritisches Risiko, und die meiste KI-unterstützte Malware verwendete gut dokumentierte Techniken wieder: Die mediane Beobachtung hatte 55 vorhandene Malware-Beispiele, die dieselbe Funktion ausführten. Nur 2,5 % betrafen wirklich seltene Techniken.

KI skaliert, was bereits funktioniert, und erzeugt keine neuen Angriffsklassen. Detection-Engineering-Teams müssen noch keine neuartigen KI-generierten Taktiken verfolgen. Aber die Geschwindigkeit und das Volumen, mit denen Angreifer jetzt operieren, lassen die Mean Time to Detect (MTTD)- und Mean Time to Respond (MTTR)-Benchmarks von 2024 bereits veraltet erscheinen.

7. Mobiles Phishing erzielt 40 % höhere Klickraten als E-Mail

Phishing-Simulationsdaten zeigen E-Mail-Klickraten mit einem Median von 1,4 %, während telefonzentrierte Methoden (Voice und SMS) näher bei 2 % liegen — eine um 40 % höhere Erfolgsrate. Pretexting — Live-Manipulation per Telefon oder SMS — macht jetzt 6 % aller Datenschutzverletzungen aus und ist zunehmend der initiale Zugriffsvektor für Ransomware- und Erpressungsangriffe.

Gegenmaßnahmen für Phishing und Pretexting sind nicht dasselbe. E-Mail-Training lehrt Menschen, einen verdächtigen Link zu erkennen. Pretexting erfordert Regeln auf Geschäftsebene — das Helpdesk-Personal zu schulen, nicht hilfreich zu sein, wenn jemand es manipuliert, ein Passwort zurückzusetzen oder MFA zu deaktivieren. Security-Awareness-Programme, die nur auf E-Mail-Simulationen aufbauen, testen auf die falsche Bedrohung.

8. Die Nutzung von Schatten-KI verdreifachte sich auf 45 % der Mitarbeiter

Im DBIR 2025 waren 15 % der Mitarbeiter regelmäßige KI-Nutzer auf Unternehmensgeräten. Diese Zahl verdreifachte sich 2026 auf 45 %. Gleichzeitig greifen 67 % der Nutzer über nicht-unternehmenseigene Konten auf KI-Dienste zu — ein moderater Rückgang gegenüber dem Vorjahr, aber immer noch eine große unautorisierte Angriffsfläche.

Schatten-KI ist jetzt die dritthäufigste nicht-böswillige Insider-Aktion, die in Data Loss Prevention (DLP)-Datensätzen erkannt wird — ein vierfacher Anstieg im Jahresvergleich. Quellcode ist der häufigste Datentyp, der an nicht genehmigte GenAI-Tools übermittelt wird, gefolgt von Bildern und strukturierten Daten. In 3,2 % der DLP-Richtlinienverletzungen gelangten Forschungs- und technische Dokumentation an externe KI-Systeme — eine direkte Exposition geistigen Eigentums.

9. 60–70 % der bekannten ausgenutzten Schwachstellen bleiben am Tag 7 offen, unabhängig vom Reifegrad

Die ernüchterndste Zahl im Bericht: Am Tag 7 nach der Erkennung — ein ambitioniertes Ziel nach jedem Standard — bleiben 60 % bis 70 % der CISA KEV-Schwachstellen ungepatcht. Diese Zahl hat sich über drei Jahre zusätzlicher Tools, Prozessinvestitionen und regulatorischen Drucks kaum verändert.

Das Team von Verizon nennt dies ein Lichtgeschwindigkeitslimit — eine praktische Obergrenze dafür, wie schnell die Schwachstellenbehebung bei aktuellen Ressourcenniveaus erfolgen kann. Selbst leistungsstarke Organisationen beheben höchstens 30–40 % der KEV-Instanzen in der ersten Woche.

Die Priorisierung entscheidet jetzt über das Ergebnis: Welche Schwachstelle zuerst gepatcht wird, ist wichtiger als wie viele gepatcht werden. Die Priorisierung nach tatsächlicher Ausnutzungsaktivität ist besser als sich allein auf CVSS (Common Vulnerability Scoring System)-Scores zu verlassen. Fast die Hälfte der KEV-Schwachstellen zeigt laut Bericht anhaltende Ausnutzung — im Durchschnitt an 96 % der Tage aktiv.

10. 89 % der Organisationen liefern immer noch Memory-Safety-Schwachstellen aus

Die Common Weakness Enumeration (CWE)-Analyse des DBIR ergab, dass 89 % der Organisationen Memory-Safety-Probleme patchen mussten — Buffer Overflows, Use-after-free-Bugs, Out-of-bounds-Reads — drei Jahrzehnte nachdem Smashing the Stack for Fun and Profit diese Fehlerklasse erstmals in Phrack im Jahr 1996 beschrieb. Die eigene Formulierung des Berichts: „Was machen wir hier eigentlich noch?"

Die Top-5-CWE-Kategorien — Memory Safety, Access Control, Resource Lifecycle Management, Improper Neutralization und File Handling — tauchten in mehr als 75 % der Organisationen auf. Wenn diese Fehler während der Entwicklung auftreten, beträgt die mediane Zeit zur Behebung der Hälfte davon sechs bis sieben Monate.

Für Teams, die Software entwickeln oder beschaffen, spricht das für Memory-safe-Sprachen (Rust, Go, C#) in Entwicklungsstandards — ein Ansatz, den der DBIR ausdrücklich mit CISAs Secure by Design-Initiative verknüpft. Der günstigste Patch ist die Schwachstelle, die nie ausgeliefert wird.

Verizon 2026 DBIR: Die Zahlen auf einen Blick

Die folgenden Tabellen fassen die oben nicht ausführlich behandelten Kategorien zusammen — nützlich als schnelle Referenz gegenüber Ihren eigenen Metriken.

Muster bei Datenschutzverletzungen, Drei-Jahres-Trend

Akteure, Motive und Auswirkungen

Assets und Infrastruktur-Exposition

Server bleiben das Hauptziel, gefolgt von Person als Social-Engineering-Ziel. Netzwerkgeräte stiegen stark an und sind jetzt ungefähr gleichauf mit Benutzergeräten bei jeweils etwa 5 %. Die Forscher von Verizon identifizierten auch 45.000–50.000 End-of-Life-Mobilfunkrouter mit öffentlich zugänglichen Verwaltungsschnittstellen in OT-nahen Sektoren — ein Befund, der für jedes Team relevant ist, das entfernte industrielle Infrastruktur verwaltet.

Drei strategische Verschiebungen, die der DBIR 2026 erfordert

Der DBIR 2026 fordert eine schnellere, besser priorisierte Version des Sicherheitsprogramms, das die meisten Organisationen bereits betreiben. Patching, MFA, Anmeldedaten-Hygiene, Anbieterüberwachung und Security Awareness funktionieren alle noch. Das Problem ist, dass das Bedrohungsvolumen die Kapazität der meisten Teams übersteigt, im gleichen Tempo zu reagieren.

Der DBIR 2026 weist auf drei Prioritätsverschiebungen hin: Geschwindigkeit vor Vollständigkeit, Drittanbieter-Sichtbarkeit statt punktuellem Vertrauen, und KI-skalierte Verteidigung statt KI-skalierter Angst.

Geschwindigkeit ist wichtiger als Vollständigkeit

Sie können nicht alles patchen, und die Daten beweisen es: Selbst Spitzenreiter beheben höchstens 40 % der kritischen Schwachstellen in der ersten Woche. Priorisierung basierend auf tatsächlicher Ausnutzungsaktivität — nicht allein auf CVSS-Score — ist der einzige Ansatz, der mit 527 Millionen jährlichen Schwachstellenerkennungen skaliert.

Drittanbieter sind Teil Ihrer Angriffsfläche

Wenn fast die Hälfte aller Datenschutzverletzungen einen Drittanbieter involviert, hat die Anbieterüberwachung das gleiche Gewicht wie interne Kontrollen. Ein TPRM (Third-Party Risk Management)-Prozess, der auf jährlichen Fragebögen basiert, kann eine achtmonatige MFA-Lücke auf der Cloud-Konsole eines Anbieters nicht erfassen.

KI skaliert bekannte Techniken, erfindet aber keine neuen

Angreifer nutzen GenAI, um bestehende Playbooks schneller und in größerem Umfang auszuführen, so die Anthropic-Analyse im DBIR 2026. Ihre bestehenden Verteidigungsmaßnahmen gelten weiterhin. Sie müssen nur mit der Geschwindigkeit und dem Umfang operieren, die Angreifer bereits erreicht haben.

Häufig gestellte Fragen

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

Ein GPT-5.6-Agent entkam seiner Sandbox und drang in die Hugging-Face-Infrastruktur ein. SonicWall lieferte zwei 0-Days aus, die ein vollständiges Zurücksetzen von Passwort und TOTP erforderten. Der IBM-Bericht zu Breach-Kosten 2026 erreichte einen Rekord von 4,99 Millionen USD. Hier erfahren Sie, was diesen Juli in der Cybersicherheit passiert ist und was Ihr Team zuerst patchen muss.

PassworkPasswork Team

Schatten-KI: Die verborgene Bedrohung, die Unternehmen 670.000 USD pro Datenschutzverletzung kostet

Schatten-KI kostet Unternehmen 670.000 USD extra pro Datenschutzverletzung — und das meiste davon geht auf Anmeldedaten zurück, die in öffentliche LLMs eingefügt werden. Erfahren Sie, wie Schatten-KI tatsächlich aussieht, warum sie schwerer zu stoppen ist als Schatten-IT und wie Sie sie kontrollieren können.

Passwork BlogAlex Muntyan

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

NIST hat obligatorische Passwortkomplexitätsregeln gestrichen. 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

El Verizon 2026 Data Breach Investigations Report (DBIR) analizó más de 22.000 filtraciones confirmadas en 145 países, lo que lo convierte en el conjunto de datos más grande en los 19 años de historia del informe. Su hallazgo principal: la explotación de vulnerabilidades superó al abuso de credenciales como el principal vector de acceso inicial, mientras que el ransomware, el riesgo de terceros y los ataques asistidos por IA crecieron considerablemente.

Esta es la 19ª edición del informe, y contó con la colaboración de Anthropic, Qualys, Tenable, Tenchi Security, Fastly y DTEX para ir más allá del simple conteo de incidentes. El DBIR 2026 mide la velocidad de parcheo de las organizaciones, cuánto tiempo los proveedores dejan deshabilitada la autenticación multifactor (MFA) y cómo los actores de amenazas están operacionalizando la IA generativa (GenAI) en campañas activas.

Los diez números a continuación son los que vale la pena considerar para construir la hoja de ruta de seguridad del próximo año.

Qué es el Informe de Investigaciones de Filtraciones de Datos de Verizon

El Verizon 2026 Data Breach Investigations Report (DBIR) es un análisis anual, a nivel mundial, de filtraciones de datos confirmadas e incidentes de seguridad, publicado desde 2008. La edición 2026, la 19ª, cubre datos desde octubre de 2024 hasta noviembre de 2025 y se basa en más de 31.000 incidentes de seguridad, incluyendo más de 22.000 filtraciones confirmadas en 145 países — el conjunto de datos más grande en la historia del informe.

Cómo se recopilan los datos

Verizon elabora el informe con contribuciones de casi 100 organizaciones asociadas, cada una aportando datos de filtraciones e incidentes de sus propias operaciones. El equipo del DBIR normaliza estos datos en un marco común construido en torno a actores de amenazas, acciones, activos y atributos, lo que permite que una filtración hospitalaria en Alemania y un caso de ransomware en Ohio aparezcan como puntos de datos comparables.

A diferencia de los informes de amenazas de proveedores basados en la telemetría de una sola empresa, el DBIR agrega datos de distintas industrias, tamaños de empresa y geografías. Esa amplitud es lo que lo convierte en un punto de referencia para la presupuestación de seguridad y los informes a nivel directivo, en lugar de una narrativa de ventas de un solo proveedor.

Novedades en el conjunto de datos del DBIR 2026

La lista de socios determina lo que el informe puede medir realmente, y 2026 trajo una incorporación que redefine su alcance. Anthropic contribuyó con datos de aplicación de políticas sobre 793 actores de amenazas identificados por su Equipo de Salvaguardas entre marzo de 2025 y febrero de 2026, mapeados a técnicas específicas de MITRE ATT&CK.

Es la primera vez que un laboratorio de IA de frontera suministra este tipo de conjunto de datos al DBIR, y permite que el informe cuantifique el uso indebido de GenAI con números reales de aplicación de políticas en lugar de estimaciones.

El informe completo Verizon 2026 Data Breach Investigations Report está disponible directamente en el sitio web de Verizon.

10 estadísticas del DBIR 2026 que deberían reformular sus prioridades

Estos diez hallazgos marcan los cambios más claros en el DBIR 2026: los atacantes están explotando vulnerabilidades más rápido de lo que los defensores las parchean, el riesgo de terceros se ha convertido en un vector de filtración principal, y la IA generativa está escalando técnicas de ataque conocidas en lugar de inventar nuevas. Cada uno apunta a una brecha específica en la mayoría de los programas de seguridad actuales.

1. La explotación de vulnerabilidades es ahora el vector de acceso inicial #1

La explotación de vulnerabilidades subió del 20% de las filtraciones en el informe de 2025 al 31% en 2026, un aumento del 55%. El abuso de credenciales, que ocupó el primer lugar durante años, cayó del 22% al 13% en el mismo período como la primera acción registrada en una filtración.

La organización media tuvo que parchear un 50% más de Vulnerabilidades Explotadas Conocidas de CISA (KEV) que el año anterior, 16 CVE críticos frente a 11, mientras que las tasas de remediación completa cayeron al 26%. Más vulnerabilidades, parcheo más lento y atacantes automatizando la explotación con asistencia de IA no es una combinación que favorezca a los defensores. Si su cadencia de parcheo no ha cambiado desde 2023, los datos indican que estadísticamente está rezagado.

2. El abuso de credenciales todavía afecta al 39% de cada cadena de ataque

Que la explotación de vulnerabilidades ocupe el primer lugar como acceso inicial no significa que las credenciales robadas hayan dejado de importar. La cifra del 13% solo cuenta el primer paso registrado en una filtración. Cuando el DBIR rastrea el abuso de credenciales en cualquier punto de un ataque, aparece en el 39% de las filtraciones, convirtiéndolo en el punto de estrangulamiento más común en casi todos los patrones de ataque del informe.

Los atacantes también se están camuflando mejor. Muchos han abandonado herramientas como Cobalt Strike en favor de rutas de acceso remoto legítimas, software de escritorio compartido y VPN, lo que hace que el movimiento lateral basado en credenciales sea más difícil de detectar con detección basada en firmas. MFA es lo mínimo indispensable a estas alturas, pero no es suficiente por sí solo.

Los números de higiene de contraseñas explican por qué persiste el abuso de credenciales. Las credenciales aparecen como tipo de dato robado en el 28% de las filtraciones, y la política de contraseñas es una de las salvaguardas que el DBIR señala como control mitigador en todas las técnicas de ataque, junto con la gestión de privilegios y el endurecimiento de configuraciones. Las verificaciones básicas de endurecimiento confirman la brecha: el 97% de los dispositivos evaluados no cumplieron la verificación de limitar los intentos de inicio de sesión fallidos antes del bloqueo, y el 90% no aplicó una longitud mínima de 15 caracteres.

3. El ransomware afecta al 48% de las filtraciones, pero las víctimas pagan menos

El ransomware creció del 44% al 48% de las filtraciones este año y sigue siendo la categoría de amenaza más dañina. La parte contraintuitiva: el 69% de las víctimas de ransomware se negó a pagar, y el pago medio cayó de $150.000 a $139.875.

Esa combinación sugiere que las estrategias de respaldo, la madurez en respuesta a incidentes y la interrupción por parte de las fuerzas del orden están ganando terreno. Pero el gran volumen de incidentes de ransomware, impulsado por intermediarios de acceso inicial y mercados de infostealers, significa que tratarlo como un problema resuelto solo con respaldos es un error. Las organizaciones que salieron de un ataque en mejor forma fueron las que nunca tuvieron que negociar.

4. Las filtraciones de terceros ahora representan el 48% de todos los incidentes

La participación de terceros en las filtraciones alcanzó el 48%, frente al 30% del año anterior, un salto del 60% sobre una duplicación del año previo. Varias de las filtraciones más disruptivas de 2025 involucraron múltiples proveedores comprometidos simultáneamente.

Las causas raíz son ordinarias: MFA ausente en cuentas en la nube, permisos excesivos y contraseñas débiles. Solo el 23% de las organizaciones terceras remediaron completamente las brechas de MFA en sus cuentas en la nube, aunque la mitad de todos los hallazgos de MFA se resolvieron en un mes.

Las contraseñas débiles y las configuraciones incorrectas de permisos tuvieron resultados mucho peores: el tiempo medio para resolver la mitad de esos hallazgos se extendió a casi ocho meses. Los cuestionarios anuales de proveedores no pueden detectar un problema que tarda ocho meses en solucionarse del lado del proveedor.

5. Solo el 26% de las vulnerabilidades críticas fueron completamente remediadas

La remediación completa de vulnerabilidades CISA KEV cayó del 38% al 26%, y el tiempo medio de parcheo se extendió de 32 a 43 días. La proporción de vulnerabilidades que quedaron completamente sin remediar creció del 12% al 16%.

La curva de supervivencia es peor de lo que sugieren los promedios. Al día 28 después de la detección, el 35% de las vulnerabilidades KEV permanecían abiertas, representando 184 millones de instancias de vulnerabilidades (frente a 31 millones tres años antes). El volumen de detección creció casi ocho veces, de 68,7 millones de registros en 2022 a 527,3 millones en 2025, mientras que la capacidad de parcheo apenas se movió.

El parcheo por sí solo no cerrará esa brecha. Como arreglar todo no es realista a los volúmenes actuales, la remediación debe priorizarse por riesgo de explotación en lugar de solo por puntuación CVSS. La evidencia más clara del informe para esto: el 80% de las vulnerabilidades explotadas persistentemente tenían más de dos años de antigüedad, lo que significa que los atacantes están principalmente trabajando con vulnerabilidades que las organizaciones ya conocían y decidieron no priorizar.

6. Los actores de amenazas están usando IA generativa en una mediana de 15 técnicas ATT&CK

La colaboración de Verizon con Anthropic produjo una de las contribuciones más sustanciales del informe: análisis de 793 actores de amenazas que violaron la política de uso aceptable de Anthropic entre marzo de 2025 y febrero de 2026. El actor mediano usó asistencia de IA en 15 técnicas distintas de MITRE ATT&CK.

Los casos extremos son el punto de datos más revelador. Algunas campañas abarcaron 40-50 técnicas en operaciones multisesión y agénticas donde la IA funcionó como codesarrollador a lo largo de toda la cadena de ataque.

Esa escala no ha producido amenazas novedosas. Menos del 1% de estos actores cayeron en la categoría de riesgo alto o crítico, y la mayoría del malware asistido por IA reutilizó técnicas bien documentadas: la observación mediana tenía 55 ejemplos de malware existentes que realizaban la misma función. Solo el 2,5% involucró técnicas genuinamente raras.

La IA está escalando lo que ya funciona, no generando nuevas clases de ataque. Los equipos de ingeniería de detección no necesitan perseguir tácticas novedosas generadas por IA todavía. Pero la velocidad y el volumen con que los atacantes ahora operan dejan los puntos de referencia de tiempo medio de detección (MTTD) y tiempo medio de respuesta (MTTR) de la era 2024 ya obsoletos.

7. El phishing móvil produce tasas de clics un 40% más altas que el correo electrónico

Los datos de simulación de phishing muestran tasas de clics de correo electrónico en una mediana de 1,4%, mientras que los métodos centrados en el teléfono (voz y SMS) alcanzan cerca del 2%, una tasa de éxito un 40% más alta. El pretexting, manipulación en vivo por teléfono o texto, ahora representa el 6% de todas las filtraciones y es cada vez más el vector de acceso inicial para ataques de ransomware y extorsión.

Las contramedidas para phishing y pretexting no son lo mismo. La capacitación en correo electrónico enseña a las personas a detectar un enlace sospechoso. El pretexting requiere reglas a nivel empresarial, capacitando al personal de soporte técnico para que no sea servicial cuando alguien los manipula para restablecer una contraseña o deshabilitar MFA. Los programas de concienciación de seguridad construidos solo en torno a simulaciones de correo electrónico están probando para la amenaza equivocada.

8. El uso de Shadow AI se triplicó al 45% de los empleados

En el DBIR 2025, el 15% de los empleados eran usuarios regulares de IA en dispositivos corporativos. Ese número se triplicó al 45% en 2026. Mientras tanto, el 67% de los usuarios accede a servicios de IA a través de cuentas no corporativas, una modesta caída respecto al año anterior pero todavía una gran superficie no autorizada.

Shadow AI es ahora la tercera acción interna no maliciosa más común detectada en conjuntos de datos de prevención de pérdida de datos (DLP), cuadruplicándose año tras año. El código fuente es el tipo de dato más común enviado a herramientas GenAI no autorizadas, seguido de imágenes y datos estructurados. En el 3,2% de las violaciones de políticas DLP, documentación de investigación y técnica fue enviada a sistemas de IA externos, una exposición directa de propiedad intelectual.

9. El 60-70% de las vulnerabilidades explotadas conocidas permanecen abiertas al día 7, independientemente de la madurez

El número más aleccionador del informe: al día 7 después de la detección, un objetivo agresivo bajo cualquier estándar, del 60% al 70% de las vulnerabilidades CISA KEV permanecen sin parchear. Esa cifra apenas se ha movido en tres años de herramientas adicionales, inversión en procesos y presión regulatoria.

El equipo de Verizon llama a esto un límite de velocidad de la luz, un techo práctico sobre cuán rápido puede moverse la remediación de vulnerabilidades con los niveles de recursos actuales. Incluso las organizaciones con mejor rendimiento corrigen como máximo del 30-40% de las instancias KEV en la primera semana.

La priorización ahora decide el resultado: qué vulnerabilidad se parchea primero importa más que cuántas se parchean. Clasificar por actividad de explotación real supera depender solo de puntuaciones CVSS (Sistema Común de Puntuación de Vulnerabilidades). Casi la mitad de las vulnerabilidades KEV muestran explotación persistente, activas en el 96% de los días en promedio, según el informe.

10. El 89% de las organizaciones todavía distribuyen vulnerabilidades de seguridad de memoria

El análisis de Enumeración de Debilidades Comunes (CWE) del DBIR encontró que el 89% de las organizaciones tuvo que parchear problemas de seguridad de memoria, desbordamientos de búfer, errores de uso después de liberación, lecturas fuera de límites, tres décadas después de que Smashing the Stack for Fun and Profit describiera por primera vez esta clase de error en Phrack en 1996. El propio enfoque del informe: «¿Qué seguimos haciendo aquí?»

Las cinco principales categorías de CWE — seguridad de memoria, control de acceso, gestión del ciclo de vida de recursos, neutralización incorrecta y manejo de archivos — aparecieron en más del 75% de las organizaciones. Cuando estos defectos aparecen durante el desarrollo, el tiempo medio para corregir la mitad de ellos es de seis a siete meses.

Para los equipos que desarrollan o adquieren software, eso argumenta a favor de lenguajes con seguridad de memoria (Rust, Go, C#) en los estándares de desarrollo, un enfoque que el DBIR vincula explícitamente con la iniciativa Secure by Design de CISA. El parche más barato es la vulnerabilidad que nunca se distribuye.

DBIR 2026 de Verizon: Los números de un vistazo

Las tablas a continuación resumen las categorías no cubiertas en profundidad anteriormente, útiles como referencia rápida contra sus propias métricas.

Patrones de filtración, tendencia de tres años

Actores, motivos e impacto

Activos y exposición de infraestructura

Los servidores siguen siendo el objetivo principal, seguidos de persona como objetivo de ingeniería social. Los dispositivos de red aumentaron considerablemente y ahora están aproximadamente empatados con los dispositivos de usuario en alrededor del 5% cada uno. Los investigadores de Verizon también identificaron 45.000-50.000 routers celulares al final de su vida útil con interfaces de gestión accesibles públicamente en sectores adyacentes a la tecnología operativa, un hallazgo que vale la pena señalar a cualquier equipo que gestione infraestructura industrial remota.

Tres cambios estratégicos que exige el DBIR 2026

El DBIR 2026 exige una versión más rápida y mejor priorizada del programa de seguridad que la mayoría de las organizaciones ya ejecutan. El parcheo, MFA, la higiene de credenciales, la supervisión de proveedores y la concienciación de seguridad todavía funcionan. El problema es que el volumen de amenazas ha superado la capacidad de respuesta de la mayoría de los equipos al mismo ritmo.

El DBIR 2026 apunta a tres cambios de prioridad: velocidad sobre completitud, visibilidad de terceros sobre confianza puntual, y defensa escalada por IA sobre miedo escalado por IA.

La velocidad importa más que la completitud

No puede parchear todo, y los datos lo demuestran: incluso los mejores ejecutores corrigen como máximo el 40% de las vulnerabilidades críticas en la primera semana. La priorización basada en actividad de explotación real, no solo en puntuación CVSS, es el único enfoque que escala con 527 millones de detecciones anuales de vulnerabilidades.

Los terceros son parte de su superficie de ataque

Cuando casi la mitad de todas las filtraciones involucran a un tercero, la supervisión de proveedores tiene el mismo peso que los controles internos. Un proceso de TPRM (gestión de riesgos de terceros) construido sobre cuestionarios anuales no puede detectar una brecha de MFA de ocho meses en la consola en la nube de un proveedor.

La IA está escalando técnicas conocidas, no inventando nuevas

Los atacantes usan GenAI para ejecutar manuales de estrategias existentes más rápido y con mayor volumen, según el análisis de Anthropic en el DBIR 2026. Sus defensas existentes todavía aplican. Solo necesitan operar a la velocidad y escala que los atacantes ya han alcanzado.

Preguntas frecuentes

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 distribuyó dos 0-days que forzaron un restablecimiento completo de contraseñas y TOTP. El informe de costos de filtraciones 2026 de IBM alcanzó un récord de $4,99 millones. Esto es lo que pasó en ciberseguridad este julio y lo que su equipo necesita parchear primero.

PassworkPasswork Team

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

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

Passwork BlogAlex Muntyan

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

NIST eliminó las reglas obligatorias de complejidad de contraseñas. Aquí está 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 Directiva de Grupo fuera de la lista de verificación de la era 2010.

PassworkPasswork Team

Verizon's 2026 Data Breach Investigations Report (DBIR) analyzed more than 22,000 confirmed breaches across 145 countries, the largest dataset in the report's 19-year history. Its headline finding: vulnerability exploitation overtook credential abuse as the top initial access vector, while ransomware, third-party risk, and AI-assisted attacks all grew sharply.

This is the 19th edition of the report, and it partnered with Anthropic, Qualys, Tenable, Tenchi Security, Fastly, and DTEX to go beyond counting incidents. The 2026 DBIR measures how fast organizations patch, how long vendors leave multi-factor authentication (MFA) disabled, and how threat actors are operationalizing generative AI (GenAI) in live campaigns.

The ten numbers below are the ones worth building next year's security roadmap around.

What is Verizon's Data Breach Investigations Report

The Verizon Data Breach Investigations Report (DBIR) is an annual analysis of confirmed data breaches and security incidents worldwide, published since 2008. The 2026 edition, its 19th, covers data from October 2024 through November 2025 and draws on more than 31,000 security incidents, including over 22,000 confirmed breaches across 145 countries — the largest dataset in the report's history.

How the data comes together

Verizon compiles the report with contributions from nearly 100 partner organizations, each supplying breach and incident data from its own operations. The DBIR team normalizes this data into a common framework built around threat actors, actions, assets, and attributes, which is what lets a hospital breach in Germany and a ransomware case in Ohio show up as comparable data points.

Unlike vendor threat reports built on a single company's telemetry, the DBIR aggregates data across industries, company sizes, and geographies. That breadth is what makes it a reference point for security budgeting and board-level reporting rather than a single-vendor sales narrative.

What's new in the DBIR 2026 dataset

The partner list determines what the report can actually measure, and 2026 brought an addition that reshapes its scope. Anthropic contributed enforcement data on 793 threat actors flagged by its Safeguards Team between March 2025 and February 2026, mapped to specific MITRE ATT&CK techniques.

It's the first time a frontier AI lab has supplied this kind of dataset to the DBIR, and it lets the report quantify GenAI misuse with actual enforcement numbers instead of estimates.

The full Verizon 2026 Data Breach Investigations Report is available directly from Verizon.

10 stats from the 2026 DBIR that should reshape your priorities

These ten findings mark the clearest shifts in the 2026 DBIR: attackers are exploiting vulnerabilities faster than defenders patch them, third-party risk has become a primary breach vector, and generative AI is scaling known attack techniques rather than inventing new ones. Each one points to a specific gap in most current security programs.

1. Vulnerability exploitation is now the #1 initial access vector

Exploitation of vulnerabilities climbed from 20% of breaches in the 2025 report to 31% in 2026, a 55% increase. Credential abuse, which held the top spot for years, dropped from 22% to 13% over the same period as the first recorded action in a breach.

The median organization had to patch 50% more CISA Known Exploited Vulnerabilities (KEV) than the year before, 16 critical CVEs versus 11, while full remediation rates fell to 26%. More vulnerabilities, slower patching, and attackers automating exploitation with AI assistance is not a combination that favors defenders. If your patching cadence has not changed since 2023, the data says you are statistically behind.

2. Credential abuse still touches 39% of every attack chain

Vulnerability exploitation taking the top initial-access spot doesn't mean stolen credentials stopped mattering. The 13% figure only counts the first recorded step in a breach. When the DBIR tracks credential abuse at any point in an attack, it shows up in 39% of breaches, making it the most common chokepoint across nearly every attack pattern in the report.

Attackers are also blending in better. Many have abandoned tools like Cobalt Strike in favor of legitimate remote access paths, desktop-sharing software and VPNs, which makes credential-based lateral movement harder to catch with signature-based detection. MFA is table stakes at this point, but it is not sufficient on its own.

The password hygiene numbers explain why credential abuse persists. Credentials themselves show up as a stolen data type in 28% of breaches, and password policy is one of the safeguards the DBIR flags as a mitigating control across attack techniques, alongside privilege management and configuration hardening. Basic hardening checks confirm the gap: 97% of assessed devices failed the check for limiting failed login attempts before lockout, and 90% failed to enforce a 15-character minimum length.

3. Ransomware hits 48% of breaches, but victims are paying less

Ransomware grew from 44% to 48% of breaches this year and remains the single most damaging threat category. The counterintuitive part: 69% of ransomware victims refused to pay, and the median payment fell from $150,000 to $139,875.

That combination suggests backup strategies, incident response maturity, and law enforcement disruption are gaining ground. But the sheer volume of ransomware incidents, fueled by initial access brokers and infostealer markets, means treating it as a problem solved by backups alone is a mistake. The organizations that came out of an attack in the best shape were the ones that never had to negotiate.

4. Third-party breaches now account for 48% of all incidents

Third-party involvement in breaches reached 48%, up from 30% a year earlier, a 60% jump on top of a doubling the year before that. Several of 2025's most disruptive breaches involved multiple compromised vendors at once.

The root causes are ordinary: missing MFA on cloud accounts, excessive permissions, and weak passwords. Only 23% of third-party organizations fully remediated MFA gaps on their cloud accounts, though half of all MFA findings were resolved within a month.

Weak passwords and permission misconfigurations fared far worse: the median time to resolve half of those findings stretched to almost eight months. Annual vendor questionnaires cannot catch a problem that takes eight months to fix on the vendor's side.

5. Only 26% of critical vulnerabilities were fully remediated

Full remediation of CISA KEV vulnerabilities dropped from 38% to 26%, and the median time to patch stretched from 32 to 43 days. The share of vulnerabilities left completely unremediated grew from 12% to 16%.

The survival curve is worse than the averages suggest. By day 28 after detection, 35% of KEV vulnerabilities remained open, representing 184 million vulnerability instances (up from 31 million three years earlier). Detection volume grew nearly eightfold, from 68.7 million records in 2022 to 527.3 million in 2025, while patching capacity barely moved.

Patching alone will not close that gap. Since fixing everything isn't realistic at current volumes, remediation has to be ranked by exploitation risk rather than CVSS score alone. The report's clearest evidence for this: 80% of persistently exploited vulnerabilities were more than two years old, meaning attackers are largely working through vulnerabilities organizations already knew about and chose not to prioritize.

6. Threat actors are using generative AI across a median of 15 ATT&CK techniques

Verizon's collaboration with Anthropic produced one of the report's most substantial contributions: analysis of 793 threat actors who violated Anthropic's acceptable use policy between March 2025 and February 2026. The median actor used AI assistance across 15 distinct MITRE ATT&CK techniques.

The extreme cases are the more telling data point. Some campaigns spanned 40-50 techniques in multi-session, agentic operations where the AI functioned as a co-developer across the full attack chain.

That scale hasn't produced novel threats. Less than 1% of these actors fell into the high or critical risk category, and most AI-assisted malware reused well-documented techniques: the median observation had 55 existing malware examples performing the same function. Only 2.5% involved genuinely rare techniques.

AI is scaling what already works, not generating new attack classes. Detection engineering teams don't need to chase novel AI-generated tactics yet. But the speed and volume at which attackers now operate leaves 2024-era mean time to detect (MTTD) and mean time to respond (MTTR) benchmarks already outdated.

7. Mobile phishing produces 40% higher click rates than email

Phishing simulation data shows email click rates at a median 1.4%, while phone-centric methods (voice and SMS) reach closer to 2%, a 40% higher success rate. Pretexting, live manipulation over phone or text, now accounts for 6% of all breaches and is increasingly the initial access vector for ransomware and extortion attacks.

Countermeasures for phishing and pretexting are not the same thing. Email training teaches people to spot a suspicious link. Pretexting requires business-level rules, training help desk staff not to be helpful when someone is manipulating them into resetting a password or disabling MFA. Security awareness programs built only around email simulations are testing for the wrong threat.

8. Shadow AI use tripled to 45% of employees

In the 2025 DBIR, 15% of employees were regular AI users on corporate devices. That number tripled to 45% in 2026. Meanwhile, 67% of users access AI services through non-corporate accounts, a modest drop from the prior year but still a large unauthorized surface.

Shadow AI is now the third most common non-malicious insider action detected in data loss prevention (DLP) datasets, up fourfold year over year. Source code is the most common data type submitted to unsanctioned GenAI tools, followed by images and structured data. In 3.2% of DLP policy violations, research and technical documentation went to external AI systems, a direct intellectual property exposure.

9. 60-70% of known exploited vulnerabilities remain open at day 7, regardless of maturity

The most sobering number in the report: by day 7 after detection, an aggressive target by any standard, 60% to 70% of CISA KEV vulnerabilities remain unpatched. That figure has barely moved across three years of additional tooling, process investment, and regulatory pressure.

Verizon's team calls this a speed of light limit, a practical ceiling on how fast vulnerability remediation can move at current resource levels. Even top-performing organizations fix at most 30-40% of KEV instances in the first week.

Prioritization now decides the outcome: which vulnerability gets patched first matters more than how many get patched. Ranking by actual exploitation activity beats relying on CVSS (Common Vulnerability Scoring System) scores alone. Nearly half of KEV vulnerabilities show persistent exploitation, active on 96% of days on average, according to the report.

10. 89% of organizations still ship memory safety vulnerabilities

The DBIR's Common Weakness Enumeration (CWE) analysis found that 89% of organizations had to patch memory safety issues, buffer overflows, use-after-free bugs, out-of-bounds reads, three decades after Smashing the Stack for Fun and Profit first described the class of bug in Phrack in 1996. The report's own framing: "What are we still doing here?"

The top five CWE categories, memory safety, access control, resource lifecycle management, improper neutralization, and file handling, showed up in more than 75% of organizations. When these flaws surface during development, the median time to fix half of them runs six to seven months.

For teams that build or procure software, that argues for memory-safe languages (Rust, Go, C#) in development standards, an approach the DBIR explicitly ties to CISA's Secure by Design initiative. The cheapest patch is the vulnerability that never ships.

Verizon 2026 DBIR: The numbers at a glance

The tables below summarize the categories not covered in depth above, useful as a quick reference against your own metrics.

Breach patterns, three-year trend

Actors, motives, and impact

Assets and infrastructure exposure

Servers remain the top target, followed by person as a social engineering target. Network devices rose sharply and are now roughly tied with user devices at around 5% each. Verizon's researchers also identified 45,000-50,000 end-of-life cellular routers with publicly accessible management interfaces in operational technology-adjacent sectors, a finding worth flagging to any team managing remote industrial infrastructure.

Three strategic shifts the 2026 DBIR demands

The 2026 DBIR calls for a faster, better-prioritized version of the security program most organizations already run. Patching, MFA, credential hygiene, vendor oversight, and security awareness all still work. The problem is that threat volume has outgrown most teams' capacity to respond at the same pace.

The 2026 DBIR points to three shifts in priority: speed over completeness, third-party visibility over point-in-time trust, and AI-scaled defense over AI-scaled fear.

Speed matters more than completeness

You cannot patch everything, and the data proves it: even top performers fix at most 40% of critical vulnerabilities in the first week. Prioritization based on real exploitation activity, not CVSS score alone, is the only approach that scales with 527 million annual vulnerability detections.

Third parties are part of your attack surface

When nearly half of all breaches involve a third party, vendor oversight carries the same weight as internal controls. A TPRM (third-party risk management) process built on annual questionnaires cannot catch an eight-month MFA gap on a vendor's cloud console.

AI is scaling known techniques, not inventing new ones

Attackers use GenAI to run existing playbooks faster and at higher volume, according to Anthropic's analysis in the 2026 DBIR. Your existing defenses still apply. They just need to operate at the speed and scale attackers have already reached.

Frequently Asked Questions

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

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

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

Passwork BlogAlex Muntyan

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

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

PassworkPasswork Team

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