Product guides

Passwork verschlüsselt jeden Tresor mit einem eigenen unabhängigen Schlüssel. Bitwarden verschlüsselt eine gesamte Organisation mit einem gemeinsamen Schlüssel. Diese einzelne Designentscheidung bestimmt, wie weit gestohlene Anmeldedaten reichen können: Ein Tresor-spezifischer Schlüssel legt nur einen Tresor offen, während ein einzelner gemeinsamer Organisationsschlüssel potenziell alle Unternehmensdaten kompromittieren kann.

Dieser Unterschied bestimmt den Schadensradius nach einer Kompromittierung, wie die Kontowiederherstellung funktioniert und ob ein Vorfall in einem Team sich auf die Daten eines anderen Teams ausbreiten kann. Beide Ansätze sind dokumentierte, legitime Zero-Knowledge-Designs. Sie haben lediglich unterschiedliche betriebliche Konsequenzen, und genau das behandelt dieser Vergleich.

Dieser Unterschied wird konkret spürbar beim Offboarding, bei einer Übernahme, bei der die Tresore zweier Teams plötzlich getrennt behandelt werden müssen, oder bei einer Post-Incident-Analyse, bei der genau angegeben werden muss, was ein Angreifer mit einem gestohlenen Schlüssel erreichen konnte. Dies vorab zu klären, macht den Rest dieses Vergleichs leichter auf Ihre eigene Umgebung anwendbar — unabhängig davon, welchen Passwort-Manager Sie heute verwenden.

Wie Passwork Tresore verschlüsselt

Passwork basiert auf einer Zero-Knowledge-Architektur: Der Server verfügt nie über genügend Informationen, um Tresordaten zu entschlüsseln, und das Masterpasswort verlässt nie das Gerät des Benutzers. Jeder kryptografische Schlüssel wird clientseitig generiert, sodass der Server nur Chiffretext und öffentliche Schlüssel speichert (Sicherheitsübersicht, Kryptografie-Übersicht).

Zwei Verschlüsselungsebenen

Passwork verwendet zwei Verschlüsselungsebenen. Die serverseitige Verschlüsselung (AES-256) schützt alles im Ruhezustand und ist immer aktiv. Die clientseitige Verschlüsselung schützt sensible Felder, bevor sie das Gerät verlassen.

Die Schlüsselhierarchie: Vom Masterpasswort zum Tresorschlüssel

Für diesen Vergleich ist die Schlüsselhierarchie am wichtigsten. Ein Masterpasswort leitet über PBKDF2 einen Master-Schlüssel ab. Dieser Master-Schlüssel entschlüsselt einen privaten RSA-Schlüssel. Der private RSA-Schlüssel entschlüsselt dann einen Tresorschlüssel: einen symmetrischen AES-256-Schlüssel, der clientseitig speziell für einen Tresor generiert wird.

Jeder Tresor erhält seinen eigenen Tresorschlüssel, der unabhängig bei der Erstellung des Tresors generiert wird. Jeder Benutzer mit Zugang besitzt eine separate verschlüsselte Kopie dieses Schlüssels, die mit seinem eigenen öffentlichen RSA-Schlüssel umschlossen ist — nur der passende private Schlüssel kann sie entschlüsseln. Die Kompromittierung eines Tresorschlüssels legt den Schlüssel keines anderen Tresors offen.

Isolation unterhalb des Tresors: Einträge und Anhänge

Die Isolation setzt sich unterhalb des Tresors fort. Jeder Eintrag erhält seinen eigenen Eintragsschlüssel, der mit dem Tresorschlüssel verschlüsselt ist, und jeder Dateianhang erhält seinen eigenen Anhangsschlüssel, der mit dem Eintragsschlüssel verschlüsselt ist. Ein geleakter Eintragsschlüssel legt einen Eintrag offen, nicht den gesamten Tresor. Ein geleakter Anhangsschlüssel legt eine Datei offen. Der Tresorschlüssel befindet sich in der Mitte dieser Kette und trennt die Einträge eines Tresors von denen aller anderen Tresore — das ist die Ebene, auf die sich dieser Vergleich konzentriert.

Teilen ohne Offenlegung des Schlüssels

Das Teilen folgt demselben Muster. Einem Kollegen Zugang zu gewähren bedeutet, dass der aktuelle Inhaber den Tresorschlüssel mit seinem eigenen privaten Schlüssel entschlüsselt und ihn mit dem öffentlichen Schlüssel des Empfängers erneut verschlüsselt. Der Server verarbeitet ausschließlich Chiffretext (Sharing-Mechanismen). Zugangsstufen wie Nur Lesen, Lesen und Bearbeiten, Vollständiger Zugang und Administrator werden von der Anwendung durchgesetzt, nicht durch die Kryptografie: Jeder mit Zugang zu einem Tresor besitzt denselben zugrundeliegenden Schlüssel, und die Berechtigungen steuern, was die Oberfläche jeder Person damit erlaubt.

Wie Bitwarden Organisationsdaten verschlüsselt

Bitwarden verschlüsselt alle organisationseigenen Tresordaten mit einem gemeinsamen Schlüssel: einem CSPRNG-abgeleiteten Organization Symmetric Key, der einmalig für die gesamte Organisation generiert wird. Laut Bitwardens eigenem Security-Whitepaper entschlüsselt dieser einzelne Schlüssel jedes Unternehmens-Tresorelement. Der ungeschützte Schlüssel selbst wird nie auf Bitwardens Servern gespeichert.

Ein Organisationsschlüssel, viele Cipher Keys

Einzelne Elemente erhalten weiterhin ihren eigenen Schlüssel. Jeder Cipher (Bitwardens Begriff für ein gespeichertes Element) hat einen einzigartigen 64-Byte Cipher Key. Dieser Cipher Key wird entweder mit einem persönlichen User Symmetric Key oder — für alles, was der Organisation gehört — mit dem einzelnen Organization Symmetric Key umschlossen. Das Entschlüsseln dieses einen Organisationsschlüssels legt alle Unternehmens-Cipher-Keys auf einmal offen, da sie alle auf denselben übergeordneten Schlüssel zurückgehen.

Collections steuern Zugang, nicht Verschlüsselung

Collections, Bitwardens Gruppierungsmechanismus, setzen darauf auf, ohne die Kryptografie zu ändern. Eine Collection steuert, welche Mitglieder und Gruppen welche Elemente sehen können, fügt aber keinen separaten Collection-spezifischen Schlüssel hinzu. Ein einzelner Organisationsschlüssel entschlüsselt den Inhalt jeder Collection dieser Organisation — ein Punkt, der sowohl durch Bitwardens eigene Server-Dokumentation bestätigt wird. Das Entfernen einer Person aus einer Collection widerruft den Zugang über die Mitgliedschaft, nicht durch eine kryptografische Grenze, die an diese spezifische Collection gebunden ist.

Kontowiederherstellung basiert auf demselben gemeinsamen Schlüssel

Die Kontowiederherstellung folgt demselben Einzelschlüssel-Muster. Wenn sich ein Mitglied für Bitwardens Kontowiederherstellungsfunktion registriert, wird sein persönlicher User Symmetric Key mit dem öffentlichen RSA-Schlüssel der Organisation umschlossen — das ergibt den sogenannten Account Recovery Key. Um ein gesperrtes Mitglied wiederherzustellen, entschlüsselt der private RSA-Schlüssel der Organisation diesen Account Recovery Key und gibt den persönlichen Verschlüsselungsschlüssel des Mitglieds frei. Ein einzelner Admin mit der Berechtigung „Manage account recovery" kann dies für jedes registrierte Mitglied durchführen.

Tresorrichtlinien vs. Collections

Passwork unterscheidet Tresore nach Typ, nicht nur nach Eigentümer. Die Dokumentation definiert zwei grundlegende Tresortypen: Unternehmenstresore, gemeinsamer Speicher mit konfigurierbaren Zugriffsrechten für ein Team, und Persönliche Tresore, Speicher, der von einem einzelnen Benutzer erstellt wird und diesem zunächst gehört.

Beide Typen erhalten die identische Tresor-spezifische Schlüsselbehandlung, sodass ein Persönlicher Tresor genauso kryptografisch vom Unternehmens-Tresor isoliert ist wie zwei Unternehmenstresore voneinander.

Persönliche Tresore können zu geteilten Tresoren werden

Ein Persönlicher Tresor ist nicht dauerhaft an eine Person gebunden. Der Eigentümer kann ihn mit Kollegen teilen, und ab diesem Zeitpunkt funktioniert er wie ein geteilter Tresor — mit derselben Zugangssteuerung wie jeder andere geteilte Tresor in Passwork.

Benutzerdefinierte Tresortypen und obligatorische Admin-Zuweisung

Passwork ermöglicht Administratoren außerdem, eine unbegrenzte Anzahl benutzerdefinierter Tresortypen zu definieren, jeweils mit eigenen designierten Administratoren und eigenen Zugriffsregeln. Das gibt einer Organisation die Möglichkeit, beispielsweise eine Admin-Gruppe für Finanztresore und eine andere für Engineering-Tresore festzulegen — ohne sich auf nachträgliche Ad-hoc-Berechtigungszuweisungen verlassen zu müssen.

Administratoren können auch die Erstellung Persönlicher Tresore vollständig deaktivieren und alle Daten in Unternehmens- oder benutzerdefinierte Tresortypen zwingen, bei denen die Admin-Zuweisung obligatorisch ist.

Wie sich das mit Bitwarden Collections und Enterprise Policies vergleicht

Bitwarden hat keine vergleichbare Tresortypen-Abstraktion. Die nächste Entsprechung — Collections — gruppiert Elemente innerhalb einer Organisation, isoliert sie aber nicht kryptografisch: Wie bereits behandelt, entschlüsselt ein einzelner Organization Symmetric Key den Inhalt jeder Collection, und das Entfernen eines Mitglieds aus einer Collection widerruft den Zugang über die Mitgliedschaft, nicht durch eine separate Schlüsselgrenze. Collections haben auch kein Konzept eines dedizierten Administrator-Sets, wie es Passworks Unternehmens- und benutzerdefinierte Tresortypen bieten.

Bitwardens Enterprise Policies arbeiten auf einer völlig anderen Ebene. Richtlinien wie „Single organization", „Centralize organization ownership", „Master password requirements", „Require two-step login" und „Account recovery administration" gelten organisationsweit, nicht pro Collection oder Tresortyp (Bitwarden-Richtliniendokumentation). Ein Administrator, der eine Masterpasswort-Stärkerichtlinie anwendet, legt beispielsweise eine Regel für die gesamte Organisation fest. Es gibt keine Collection- oder Tresortyp-spezifische Entsprechung, um diese Regel enger einzugrenzen.

Der praktische Unterschied

Passworks Tresorrichtlinien bieten Administratoren eine strukturelle Möglichkeit, individuelle Daten von Teamdaten zu trennen, verantwortliche Admins pro Typ zuzuweisen und jede Instanz beider Typen auf ihrem eigenen Schlüssel zu halten. Bitwardens Collections organisieren den Zugang innerhalb eines einzelnen gemeinsamen Schlüssels, und seine Richtlinien konfigurieren Verhalten über eine Organisation, die diesen Schlüssel bereits teilt — unabhängig davon, welche Collection oder welchen Datentyp eine bestimmte Richtlinie adressiert.

Was das in der Praxis bedeutet

Die Schlüsselarchitektur hinter jedem Produkt führt zu vier konkreten betrieblichen Unterschieden: Schadensradius nach einer Kompromittierung, wie sauber Teams isoliert werden können, wie die Wiederherstellung funktioniert und wie ein Audit die Frage „Was konnte diese Anmeldedaten entschlüsseln?" beantwortet.

Schadensradius eines einzelnen kompromittierten Geheimnisses

Bei Passwork beschränkt ein geleakter Tresorschlüssel, ein geleakter privater RSA-Schlüssel oder ein kompromittiertes Masterpasswort einen Angreifer auf einen Tresor oder auf die geteilten Tresore dieses einen Benutzers — nicht auf die gesamte Organisation. Bei Bitwarden legt die Kompromittierung des Organization Symmetric Key jedes Tresorelement offen, das der Organisation gehört, da jeder Unternehmens-Cipher-Key auf diesen einen Schlüssel zurückgeht.

Multi-Team-Isolation

Eine Organisation, die mehrere Teams in Passwork betreibt, kann jedem Team seinen eigenen Tresor mit eigenem Schlüssel geben, sodass ein Vorfall im Tresor eines Teams keinen kryptografischen Pfad in den Tresor eines anderen Teams hat. Bei Bitwarden werden Teams typischerweise mit Collections innerhalb derselben Organisation getrennt — das ist Zugangskontrolle, die auf einem gemeinsamen Organisationsschlüssel aufbaut.

Wiederherstellungsmodell

Der Wiederherstellungsprozess von Passwork stellt nicht den ursprünglichen Master-Schlüssel wieder her. Es wird ein neuer erstellt, und ein Benutzer behält nur Zugang zu Tresoren, bei denen der Zugang zuvor bereits mit einem anderen Konto geteilt wurde. Bitwardens Kontowiederherstellung basiert auf einem einzigen RSA-Schlüsselpaar der Organisation, sodass ein Admin mit der entsprechenden Berechtigung jedes registrierte Mitglied wiederherstellen kann, ohne dass dieses Mitglied zuvor etwas geteilt haben muss (Kontowiederherstellungs-Dokumentation). Das ist betrieblich praktisch. Es bedeutet aber auch, dass der private Recovery-RSA-Schlüssel der Organisation ein einzelner Expositionspunkt für den Tresor jedes registrierten Mitglieds ist.

Audit- und Compliance-Scoping

Wenn ein Auditor fragt „Was konnte diese Anmeldedaten entschlüsseln?", liefert Passworks Tresor-spezifisches Modell eine kurze, präzise Antwort: einen Tresor oder eine benannte Liste von Tresoren, auf die dieser Benutzer Zugriff hatte. Bei Bitwardens Einzelorganisationsschlüssel-Modell lautet die ehrliche Antwort auf dieselbe Frage „Alles, was der Organisation gehört", da es keine kryptografische Unterteilung unterhalb der Organisationsebene gibt. Keine der Antworten ist falsch, aber sie dokumentieren sich in einem Audit-Evidenzpaket sehr unterschiedlich.

Vergleichstabelle

Die folgende Tabelle fasst zusammen, wo die beiden Architekturen divergieren — vom Root-Schlüssel bis zu Sharing und Wiederherstellung.

Praktische Überlegungen

Die Frage ist nicht, welche Kryptografie des Anbieters abstrakt besser ist. Es geht darum, ob Ihre Daten tatsächlich Einzelschlüssel- oder Tresor-spezifische Isolation benötigen. Teams, die regulatorisch relevante Geheimnisse, die Infrastruktur eines bestimmten Kunden oder eine Compliance-Grenze verwalten, die getrennt bleiben muss, profitieren direkt von Tresor-spezifischen Schlüsseln. Teams, in denen bereits vollständiges gegenseitiges Vertrauen herrscht, profitieren weniger von der zusätzlichen Isolation.

Beide Architekturen qualifizieren sich als Zero-Knowledge. Der Unterschied liegt darin, was ein einzelner gestohlener Schlüssel danach erreichen kann: einen Tresor oder die gesamte Organisation. Das ist die Zahl, die Sie vor Ihrer nächsten Sicherheitsüberprüfung mit Ihrem eigenen Risikomodell abgleichen sollten.

Möchten Sie die Tresor-spezifische Schlüsselisolation mit Ihren eigenen Daten testen, bevor Sie sich entscheiden? Testen Sie Passwork kostenlos und prüfen Sie, wie Tresortypen, Admin-Zuweisung und Schlüsselgrenzen Ihrer eigenen Sicherheitsüberprüfung standhalten.

Häufig gestellte Fragen

SaaS-Credential-Management: 5 Schritte zur Zentralisierung Ihres App-Stacks

SaaS-Credential-Management 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: Inventarisierung, Strukturierung, Migration, Zugangskontrolle und Automatisierung.

PassworkPasswork Team

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

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

PassworkAlex Muntyan

Passworks Tresorrichtlinien: Ein Leitfaden für CIOs zur Unternehmenssicherheit

Passworks Tresortypen binden Admin-Rechte an die Tresorrichtlinie selbst, nicht an denjenigen, der sie erstellt hat — und schließen damit eine Lücke, von der die meisten Unternehmen nicht einmal wissen. Dieser Leitfaden bietet CIOs und CISOs ein Arbeitsmodell für Tresor-Governance, abgestimmt auf NIS2- und ISO-27001-Anforderungen.

PassworkPasswork Team

Passwork cifra cada bóveda con su propia clave independiente. Bitwarden cifra toda una organización con una única clave compartida. Esa única decisión de diseño determina hasta dónde puede llegar una credencial robada: una clave por bóveda expone solo esa bóveda, mientras que una única clave de organización compartida puede comprometer todos los elementos corporativos que posee la empresa.

Esta diferencia determina el radio de impacto tras un compromiso, cómo funciona la recuperación de cuentas y si un incidente de un equipo puede propagarse a los datos de otro equipo. Ambos enfoques son diseños de conocimiento cero documentados y legítimos. Simplemente conllevan diferentes consecuencias operativas, y eso es lo que cubre esta comparación.

Esta diferencia se percibe de forma concreta durante una baja de empleado, durante una adquisición donde las bóvedas de dos equipos necesitan repentinamente un manejo separado, o en una revisión post-incidente donde hay que especificar exactamente qué podría alcanzar un atacante con una sola clave robada. Nombrar esto desde el principio hace que el resto de esta comparación sea más fácil de aplicar a su propio entorno, independientemente del gestor de contraseñas que utilice actualmente.

Cómo cifra Passwork las bóvedas

Passwork funciona sobre una arquitectura de conocimiento cero: el servidor nunca tiene información suficiente para descifrar los datos de la bóveda, y la contraseña maestra nunca sale del dispositivo del usuario. Cada clave criptográfica se genera del lado del cliente, por lo que el servidor almacena solo texto cifrado y claves públicas (descripción general de seguridad, descripción general de criptografía).

Dos capas de cifrado

Passwork ejecuta dos capas de cifrado. El cifrado del lado del servidor (AES-256) protege todo en reposo y está siempre activo. El cifrado del lado del cliente protege los campos sensibles antes de que salgan del dispositivo.

La jerarquía de claves: De la contraseña maestra a la clave de bóveda

Lo más importante para esta comparación es la jerarquía de claves. Una contraseña maestra deriva una clave maestra mediante PBKDF2. Esa clave maestra descifra una clave RSA privada. La clave RSA privada luego descifra una clave de bóveda: una clave simétrica AES-256 generada en el cliente específicamente para una bóveda.

Cada bóveda obtiene su propia clave de bóveda, generada de forma independiente en el momento en que se crea la bóveda. Cada usuario con acceso tiene una copia cifrada separada de esa clave, envuelta con su propia clave pública RSA, y solo la clave privada correspondiente puede desenvolverla. Comprometer la clave de una bóveda no expone la clave de ninguna otra bóveda.

Aislamiento por debajo de la bóveda: Registros y archivos adjuntos

El aislamiento continúa por debajo de la bóveda. Cada registro obtiene su propia clave de registro, cifrada con la clave de bóveda, y cada archivo adjunto obtiene su propia clave de archivo adjunto, cifrada con la clave de registro. Una clave de registro filtrada expone un registro, no toda la bóveda. Una clave de archivo adjunto filtrada expone un archivo. La clave de bóveda se sitúa en el medio de esa cadena, separando los registros de una bóveda de los registros de todas las demás bóvedas, que es la capa en la que se centra esta comparación.

Compartir sin exponer la clave

Compartir sigue el mismo patrón. Otorgar acceso a un colega significa que el titular actual descifra la clave de bóveda con su propia clave privada y la vuelve a cifrar con la clave pública del destinatario. El servidor solo maneja texto cifrado (mecánicas de compartición). Los niveles de acceso como Ver, Editar, Acceso completo y Administrador son aplicados por la aplicación, no por la criptografía: todos los que tienen acceso a una bóveda poseen la misma clave subyacente, y los permisos gobiernan lo que la interfaz permite hacer a cada persona con ella.

Cómo cifra Bitwarden los datos de organización

Bitwarden cifra todos los datos de bóveda propiedad de la organización con una única clave compartida: una Organization Symmetric Key derivada de CSPRNG generada una vez para toda la organización. Según el propio documento técnico de seguridad de Bitwarden, esta única clave descifra todos los elementos de bóveda corporativos. La clave sin proteger nunca se almacena en los servidores de Bitwarden.

Una clave de organización, muchas claves de cifrado

Los elementos individuales siguen obteniendo su propia clave. Cada cipher (el término de Bitwarden para un elemento almacenado) tiene una Cipher Key única de 64 bytes. Esa Cipher Key está envuelta por una User Symmetric Key personal o, para cualquier cosa que posea la organización, por la única Organization Symmetric Key. Desenvolver esa única clave de organización expone todas las claves de cifrado corporativas a la vez, porque todas se remontan a la misma clave matriz.

Las colecciones controlan el acceso, no el cifrado

Las colecciones, el mecanismo de agrupación de Bitwarden, se sitúan encima de esto sin cambiar la criptografía. Una colección controla qué miembros y grupos pueden ver qué elementos, pero no añade una clave separada a nivel de colección. Una única clave de organización descifra el contenido de todas las colecciones pertenecientes a esa organización, un punto confirmado por la propia documentación del servidor de Bitwarden. Eliminar a alguien de una colección revoca el acceso a través de la membresía, no a través de un límite criptográfico vinculado a esa colección específica.

La recuperación de cuenta depende de la misma clave compartida

La recuperación de cuenta sigue el mismo patrón de clave única. Cuando un miembro se inscribe en la función de recuperación de cuenta de Bitwarden, su User Symmetric Key personal se envuelve con la clave pública RSA de la organización, formando lo que Bitwarden llama Account Recovery Key. Para recuperar a un miembro bloqueado, la clave privada RSA de la organización desenvuelve esa Account Recovery Key y obtiene la clave de cifrado personal del miembro. Un solo administrador con el permiso de gestionar recuperación de cuentas puede hacer esto para cualquier miembro inscrito.

Políticas de bóveda vs colecciones

Passwork distingue las bóvedas por tipo, no solo por propietario. La documentación define dos tipos básicos de bóveda: Bóvedas de empresa, almacenamiento compartido con derechos de acceso configurables para un equipo, y Bóvedas personales, almacenamiento creado por y perteneciente inicialmente a un único usuario.

Ambos tipos reciben el mismo tratamiento de clave por bóveda, por lo que una bóveda personal está tan aislada criptográficamente de una bóveda de empresa como dos bóvedas de empresa lo están entre sí.

Las bóvedas personales pueden convertirse en bóvedas compartidas

Una bóveda personal no está bloqueada permanentemente para una persona. Su propietario puede compartirla con colegas, y en ese momento funciona como una bóveda compartida, con el acceso gobernado de la misma manera que cualquier otra bóveda compartida en Passwork.

Tipos de bóveda personalizados y asignación obligatoria de administradores

Passwork también permite a los administradores definir un número ilimitado de tipos de bóveda personalizados, cada uno con su propio conjunto de administradores designados y sus propias reglas de acceso. Esto proporciona a una organización una forma de imponer, por ejemplo, un grupo de administradores para bóvedas de finanzas y otro diferente para bóvedas de ingeniería, sin depender de asignaciones de permisos ad hoc después del hecho.

Los administradores también pueden deshabilitar por completo la creación de bóvedas personales, forzando que todos los datos vayan a bóvedas de empresa o tipos de bóveda personalizados donde la asignación de administrador es obligatoria.

Cómo se compara esto con las colecciones y políticas empresariales de Bitwarden

Bitwarden no tiene una abstracción equivalente de bóvedas tipificadas. Su análogo más cercano, las colecciones, agrupa elementos dentro de una organización pero no los aísla criptográficamente: como se cubrió anteriormente, una única Organization Symmetric Key descifra el contenido de todas las colecciones, y eliminar a un miembro de una colección revoca el acceso a través de la membresía, no a través de un límite de clave separado. Las colecciones tampoco tienen el concepto de un conjunto de administradores dedicados como lo tienen los tipos de bóveda de empresa y personalizados de Passwork.

Las políticas empresariales de Bitwarden funcionan en una capa completamente diferente. Políticas como organización única, centralizar propiedad de la organización, requisitos de contraseña maestra, requerir inicio de sesión en dos pasos y administración de recuperación de cuenta se aplican a toda la organización, no por colección o tipo de bóveda (documentación de políticas de Bitwarden). Un administrador que aplica una política de fortaleza de contraseña maestra, por ejemplo, establece una regla para toda la organización. No existe un equivalente por colección o por tipo de bóveda para limitar esa regla de manera más específica.

La diferencia práctica

Las políticas de bóveda de Passwork proporcionan al administrador una forma estructural de separar los datos individuales de los datos del equipo, asignar administradores responsables por tipo y mantener cada instancia de cualquier tipo en su propia clave. Las colecciones de Bitwarden organizan el acceso dentro de una única clave compartida, y sus políticas configuran el comportamiento en toda una organización que ya comparte esa clave, independientemente de qué colección o tipo de datos sea el objetivo de una política determinada.

Qué significa esto en la práctica

La arquitectura de claves detrás de cada producto produce cuatro diferencias operativas concretas: radio de impacto después de un compromiso, qué tan limpiamente se pueden aislar los equipos, cómo funciona la recuperación y cómo una auditoría responde «qué podría descifrar esta credencial».

Radio de impacto de un único secreto comprometido

En Passwork, una clave de bóveda filtrada, una clave RSA privada filtrada o una contraseña maestra comprometida limita al atacante a una bóveda o a las bóvedas compartidas de ese usuario, no a toda la organización. En Bitwarden, debido a que cada clave de cifrado corporativa se remonta a una única Organization Symmetric Key, comprometer esa clave expone todos los elementos de bóveda que posee la organización.

Aislamiento multi-equipo

Una organización que ejecuta varios equipos en Passwork puede dar a cada equipo su propia bóveda, cada una con su propia clave, por lo que un incidente en la bóveda de un equipo no tiene camino criptográfico hacia la bóveda de otro equipo. En Bitwarden, los equipos típicamente se separan con colecciones dentro de la misma organización, que es control de acceso superpuesto a una única clave de organización compartida.

Modelo de recuperación

El proceso de recuperación de Passwork no restaura la clave maestra original. Establece una nueva, y un usuario mantiene el acceso solo a las bóvedas donde el acceso ya estaba compartido con otra cuenta de antemano. La recuperación de cuenta de Bitwarden depende de un único par de claves RSA de organización, por lo que un administrador con el permiso adecuado puede recuperar a cualquier miembro inscrito sin que ese miembro haya pre-compartido nada (documentación de recuperación de cuenta). Eso es operativamente conveniente. También significa que la clave privada RSA de recuperación de la organización es un único punto de exposición para la bóveda de cada miembro inscrito.

Alcance de auditoría y cumplimiento

Cuando un auditor pregunta «qué podría descifrar esta credencial», el modelo por bóveda de Passwork proporciona una respuesta corta y específica: una bóveda, o una lista nombrada de bóvedas a las que este usuario tenía acceso. En el modelo de clave única de organización de Bitwarden, la respuesta honesta a la misma pregunta es «todo lo que posee la organización», porque no hay subdivisión criptográfica por debajo del nivel de organización a la que apuntar. Ninguna respuesta es incorrecta, pero se documentan de manera muy diferente en un paquete de evidencia de auditoría.

Tabla comparativa

La tabla a continuación resume dónde divergen las dos arquitecturas, desde la clave raíz hasta la compartición y la recuperación.

Siendo prácticos al respecto

La pregunta no es qué criptografía de proveedor es mejor en abstracto. Es si sus datos realmente necesitan aislamiento de clave única o por bóveda. Los equipos que manejan secretos con alcance regulatorio, la infraestructura de un cliente específico o un límite de cumplimiento que debe mantenerse separado obtienen un beneficio directo de las claves por bóveda. Los equipos donde todos ya comparten plena confianza mutua obtienen menos beneficio del aislamiento adicional.

Ambas arquitecturas califican como conocimiento cero. La diferencia es qué puede alcanzar una única clave robada después: una bóveda, o toda la organización. Ese es el número que debe verificar contra su propio modelo de riesgo antes de su próxima revisión de seguridad.

¿Desea ver el aislamiento de clave por bóveda en sus propios datos antes de decidir? Pruebe Passwork gratis y compruebe cómo los tipos de bóveda, la asignación de administradores y los límites de clave resisten su propia revisión de seguridad.

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 único 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 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 considerablemente. Aquí están los 10 números que importan.

PassworkAlex Muntyan

Políticas de bóveda de Passwork: Una guía para CIO sobre seguridad empresarial

Los tipos de bóveda de Passwork vinculan los derechos de administrador a la propia política de bóveda, 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 los CIO y CISO un modelo de trabajo para la gobernanza de bóvedas, mapeado a los requisitos de NIS2 e ISO 27001.

PassworkPasswork Team

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

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

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

How Passwork encrypts vaults

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

Two layers of encryption

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

The key hierarchy: From master password to vault key

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

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

Isolation below the vault: Records and attachments

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

Sharing without exposing the key

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

How Bitwarden encrypts organization data

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

One organization key, many cipher keys

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

Collections control access, not encryption

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

Account recovery relies on the same shared key

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

Vault policies vs collections

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

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

Personal vaults can become shared vaults

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

Custom vault types and mandatory admin assignment

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

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

How this compares to Bitwarden collections and Enterprise Policies

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

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

The practical difference

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

What this means in practice

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

Blast radius of a single compromised secret

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

Multi-team isolation

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

Recovery model

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

Audit and compliance scoping

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

Comparison table

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

Getting practical about it

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

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

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

Frequently asked questions

SaaS credential management: 5 steps to centralize your app stack

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

PassworkPasswork Team

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

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

PassworkAlex Muntyan

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

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

PassworkPasswork Team

Gestão de credenciais SaaS é a prática de registar todas as palavras-passe, inícios de sessão partilhados e chaves de acesso que uma empresa utiliza em aplicações na nuvem, como o Salesforce ou o Slack, e de controlar quem pode ver e utilizar cada uma. Implica tratar cada credencial como um inventário que se pode localizar, partilhar de forma intencional e revogar quando as pessoas saem. O objetivo é um único cofre controlado para as palavras-passe de utilizadores e os segredos de máquinas, e não cinco ferramentas que guardam, cada uma, uma parte da verdade

A maioria das empresas utiliza mais aplicações SaaS do que a TI regista oficialmente: um início de sessão do CRM num perfil do navegador, uma palavra-passe do Gmail partilhada através do Slack, cadeias de ligação a bases de dados de staging num repositório privado. Ninguém é responsável centralmente por nenhum destes inícios de sessão, pelo que ninguém os supervisiona. Cada um é um ponto de entrada aberto, que pode permanecer assim durante meses até alguém reparar que foi utilizado indevidamente.

O Passwork foi concebido para esta função: um gestor de palavras-passe e segredos para empresas, que pode ser executado em servidores próprios ou como serviço na nuvem, com cofres partilhados, acesso baseado em funções, LDAP/SSO e uma REST API para automação. Os cinco passos abaixo funcionam da mesma forma para as equipas que já utilizam o Passwork e para as que ainda estão a avaliar um sistema.

O que conta como credencial SaaS

Uma credencial SaaS é tudo o que serve para comprovar uma identidade e obter acesso: uma palavra-passe, um início de sessão partilhado, uma chave de API ou um certificado de segurança. A lista de aplicações SaaS de uma empresa (o que paga) não é o mesmo que a lista das suas credenciais (como cada aplicação é realmente acedida). Uma aplicação pode ter várias: dez pessoas a iniciar sessão através de SSO, uma conta de faturação partilhada e uma chave de API que um script utiliza para extrair relatórios.

Conhecer as aplicações que uma empresa utiliza mostra o que está a pagar. Conhecer as credenciais mostra quem pode entrar, e é essa a lista que importa para a segurança.

Passo 1: Criar o inventário de credenciais SaaS

Comece por uma lista de credenciais SaaS. Agrupe-a por risco. Não faça «limpezas» durante este passo. Limpar a meio do inventário cria uma segunda confusão. Primeiro registar, depois mover. Para cada aplicação SaaS e serviço interno, registe:

• Que ferramenta é (nome da aplicação SaaS)
• Quem é o responsável pela conta (pessoa ou equipa)
• Onde se encontra hoje o segredo (chat, wiki, variável de CI, nota autocolante)
• Quem vai precisar dele no próximo trimestre (novos colaboradores, projetos ou equipas)
• O que deixa de funcionar se desaparecer (fluxos de trabalho, integrações ou serviços dependentes)

Exemplo:

Uma entrada como esta indica a qualquer pessoa a quem perguntar, onde procurar e o que está em jogo.

Passo 2: Estruturar cofres e pastas que reflitam a forma de trabalhar

Um cofre de palavras-passe só ajuda na gestão de credenciais SaaS quando a hierarquia de pastas corresponde à forma como as equipas já procuram os acessos, e não à forma como o sistema antigo e caótico foi crescendo. A centralização falha quando o novo repositório se limita a mudar a confusão de sítio. Escolha uma hierarquia que alguém consiga explicar numa frase. Agrupe os cofres por departamento ou produto e divida depois os segredos de infraestrutura por ambiente.

Na maioria dos ramos, o aninhamento mantém-se pouco profundo. Dois níveis costumam bastar: um cofre para a equipa e uma pasta para a categoria de ferramenta. Só se deve acrescentar um terceiro nível quando uma pasta de segundo nível não é uniforme por si só. Se uma pasta já descreve tudo o que contém, convém parar aí.

Exemplo de hierarquia de dados:

Dois públicos utilizam esta mesma árvore de formas diferentes. As pessoas navegam pelo nome da equipa. Os pipelines obtêm por ID de pasta, razão pela qual a documentação de integração para DevOps recomenda pastas organizadas primeiro por ambiente: uma tarefa pode obter tudo o que necessita com um único --folder-id em vez de incorporar credenciais SaaS no código.

As regras de nomenclatura ajudam mais do que a profundidade do aninhamento:

• Preferir stripe-prod-dashboard a New password (2)
• Colocar o ambiente no nome ou na pasta, e não apenas na cabeça de alguém
• Utilizar campos personalizados para segredos que não são palavras-passe (chaves de API, IDs de cliente) em vez de pôr tudo no campo da palavra-passe

A última decisão é quem vê sequer o cofre. Os cofres da empresa são o lugar das credenciais SaaS das equipas. Os cofres privados destinam-se a inícios de sessão de trabalho pessoais, que não devem sobreviver ao colaborador.

Passo 3: Migrar uma só vez e eliminar depois os repositórios paralelos

A migração de credenciais SaaS só reduz o risco de gestão na nuvem quando o armazenamento antigo é desativado numa data fixa. Manter um canal de chat, uma folha de cálculo e um gestor de palavras-passe lado a lado, como fontes de verdade concorrentes, limita-se a recriar a dispersão que a migração devia resolver.

Importar é melhor do que reescrever. O Passwork aceita importações estruturadas (JSON, CSV e formatos comuns de exportação de gestores de palavras-passe). Comece por migrar um departamento-piloto, com registos suficientes para que as pessoas sintam o incómodo da forma antiga, mas não tantos que um mau desenho de pastas se torne permanente.

Regras que mantêm a migração rigorosa:

1. Uma única fonte de verdade após a transição. O canal do Slack e a folha de cálculo partilhada do Google passam a ser arquivos só de leitura e são eliminados numa data previamente anunciada.
2. Rodar as credenciais SaaS após a importação quando o canal antigo era partilhado. Tudo o que esteve num chat está comprometido por definição. Alterar a palavra-passe na aplicação SaaS e atualizar depois o cofre é preferível a atualizar primeiro o cofre e esperar que a aplicação ainda aceite o valor antigo.
3. Atalhos em vez de cópias. Se duas equipas precisam da mesma credencial SaaS, deve partilhar-se o acesso ou utilizar-se um atalho, em vez de duplicar o segredo. As cópias divergem com o tempo.

Convém contar com duas semanas caóticas. É normal. O modo de falha é deixar o Notion e o cofre de palavras-passe como «oficiais» durante seis meses.

Passo 4: Controlar o acesso com funções, grupos e permissões de cofre

O armazenamento centralizado de credenciais SaaS sem o princípio do menor privilégio transforma um cofre de palavras-passe num pastebin muito grande e pesquisável. Uma gestão eficaz de credenciais SaaS separa o que uma pessoa pode fazer à própria plataforma do que pode fazer a um conjunto específico de segredos partilhados.

O Passwork separa duas camadas:

• Funções do sistema – o que alguém pode fazer à instância (convidar utilizadores, alterar o SSO, ler o registo de atividade). Incluem-se as funções Proprietário, Admin e Utilizador. As funções personalizadas, em número ilimitado, permitem definir perfis como Suporte ou Auditor sem conceder administração total.
• Grupos de utilizadores – o que podem fazer às credenciais SaaS partilhadas. Os níveis vão de Proibido a Leitura, Edição e Acesso total, até Admin sobre esse recurso.

Conceda acesso a grupos e atribua depois as pessoas aos grupos. Quando alguém entra no Suporte, herda o acesso aos cofres com o grupo. Quando sai, remove-se a pessoa uma única vez. O LDAP/AD pode sincronizar a pertença a grupos, para que as alterações no diretório passem para o cofre de palavras-passe sem esperar por um ticket.

Ser rigoroso com o nível Admin nos cofres. A maioria das pessoas precisa de Leitura nas aplicações que utiliza. O nível Admin destina-se aos responsáveis de equipa que organizam as pastas e revêem quem tem acesso.

Passo 5: Ligar a identidade, a automação e a saída de colaboradores

Um cofre de palavras-passe utilizado apenas para inícios de sessão interativos cobre metade da gestão de credenciais SaaS. A outra metade são os segredos de máquina para máquina que os pipelines obtêm durante a compilação ou a implementação. Ligar o cofre ao SSO, ao LDAP/AD e a uma API adequada a CI transforma-o no ponto de controlo único, tanto para os inícios de sessão de pessoas como para os fluxos de trabalho automatizados de gestão na nuvem.

• SAML SSO para que as pessoas entrem no cofre de palavras-passe com o mesmo fornecedor de identidade (IdP) que utilizam para o resto das aplicações SaaS (Azure AD, Okta, ADFS, Google Workspace e semelhantes).
• LDAP/AD quando o diretório é a fonte de verdade para as contas e para o acesso aos cofres baseado em grupos.
• Extensão de navegador e clientes para computador e dispositivos móveis para que o percurso diário seja o preenchimento automático, e não copiar e colar a partir de um separador do navegador.

Do lado das máquinas, convém manter as pessoas fora do CI:

• Utilizar uma conta de serviço com uma chave de API (ou tokens de sessão consumidos pelo passwork-cli), limitada aos cofres e pastas de que o pipeline necessita para aceder às credenciais SaaS.
• Obter os segredos no momento da execução da tarefa. Não os incorporar nas imagens.
• Rodar: atualizar primeiro o segredo no sistema de destino e guardar depois o novo valor no cofre de palavras-passe, pois a ordem inversa provoca interrupções silenciosas.
• Rever o registo de atividade (e a exportação Syslog/CEF para um SIEM, se existir) quanto a cópias, exportações e alterações de acesso.

A saída de colaboradores é onde esta configuração compensa. Desative a conta do utilizador que sai, revogue as suas sessões de API e confirme que foi removido de todos os grupos. Se uma palavra-passe de administração SaaS partilhada existia apenas no cofre, rodá-la é uma única ação, e não uma busca por cinco caixas de correio para saber quem mais tinha uma cópia.

Como é a gestão de credenciais SaaS bem feita

A gestão de credenciais SaaS está centralizada quando o acesso flui através de grupos e não de mensagens diretas, a saída de colaboradores revoga o acesso ao cofre de palavras-passe numa única ação e cada consulta de credenciais pode ser rastreada num registo de atividade. Nada disto exige um programa longo: o inventário, a estrutura e a migração decorrem em paralelo ao longo de algumas semanas.

A centralização está conseguida quando:

• Um novo colaborador obtém acesso ao cofre através de um grupo, e não de uma mensagem direta com cinco palavras-passe
• Um colaborador que sai perde o acesso às aplicações SaaS sem uma busca exaustiva
• Os engenheiros podem apontar um pipeline para um ID de pasta e deixar de fazer commit de ficheiros .env 
• A equipa de segurança consegue responder a «quem podia ver o início de sessão do Stripe no mês passado?» a partir do registo de atividade

Nada disto exige um programa de doze meses. Inventário numa semana. Estrutura e piloto na seguinte. Migração por fases. Permissões e SSO em paralelo com as fases. Automação no fim, depois de as pastas existirem.

Conclusão

Centralizar as credenciais SaaS só funciona se a ferramenta que as guarda impuser a responsabilidade por cada cofre, mantiver separados os inícios de sessão de pessoas e as contas de serviço e produzir um registo que se possa entregar à equipa de segurança sem o reconstruir de memória.

O Passwork associa essa responsabilidade a uma função definida à partida, e não a quem calhou clicar primeiro em «criar cofre». Assim, quando a pessoa que configurou o cofre de Marketing sai da empresa, a supervisão não sai com ela: mantém-se com a função. As contas de serviço tratam o lado das máquinas da mesma forma: um pipeline de CI recebe a sua própria identidade limitada, em vez de funcionar discretamente com o início de sessão pessoal de alguém muito depois de essa pessoa ter mudado de equipa.

As palavras-passe de utilizadores e os segredos de máquinas ficam na mesma plataforma, sob um único preço. É um fornecedor para gerir em vez de dois e um registo de atividade para consultar em vez de juntar exportações de um gestor de palavras-passe e de uma ferramenta de segredos separada.

Perguntas frequentes

Verizon DBIR 2026: 10 estatísticas que devem mudar a estratégia de segurança

O DBIR 2026 da Verizon analisou mais de 22 000 violações em 145 países. A exploração de vulnerabilidades ultrapassou o abuso de credenciais como principal vetor de ataque, enquanto o ransomware, o risco de terceiros e os ataques assistidos por IA cresceram de forma acentuada. Estes são os 10 números que importam.

PassworkAlex Muntyan

As políticas de cofre do Passwork: um guia do CIO para a segurança empresarial

Os tipos de cofre (Vault Types) do Passwork associam os direitos de administração à própria política do cofre, e não a quem o criou, eliminando uma lacuna que a maioria das empresas nem sabe que existe. Este guia apresenta a CIOs e CISOs um modelo prático de governação de cofres, alinhado com os requisitos da NIS2 e da ISO 27001.

PassworkPasswork Team

O que é a gestão de acessos privilegiados? Guia completo

As contas privilegiadas são os alvos de maior valor para os atacantes. Uma única credencial de administrador comprometida dá controlo total sobre a infraestrutura, os dados e as aplicações. A PAM resolve este problema com o armazenamento de credenciais em cofre, a monitorização de sessões e a aplicação do princípio do menor privilégio. Eis como funciona na prática.

Passwork BlogAlex Muntyan

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

A versão mais recente do Passwork centra-se num problema com que todas as equipas distribuídas acabam por se deparar: o que acontece ao acesso às palavras-passe quando a ligação falha. O Passwork 7.7 adiciona o modo offline seguro às aplicações de desktop e móveis, mantendo os administradores com controlo total sobre o que fica em cache no dispositivo.

Acesso offline seguro em aplicações de desktop e móveis

Os utilizadores podem agora abrir registos de palavras-passe mesmo quando o dispositivo não tem ligação ao servidor. Para isso são necessários dois passos deliberados, pelo que nada fica num dispositivo por acidente.

Primeiro, o utilizador marca um registo específico com o ícone offline , disponível tanto no cartão de informações da palavra-passe como na lista geral de palavras-passe. Isto adiciona os registos selecionados a uma lista sincronizada, visível em todos os dispositivos desse utilizador no separador Offline do painel de navegação. Neste momento, ainda nada é transferido nem fica disponível offline.

Segundo, no dispositivo, o utilizador abre o separador Offline na aplicação de desktop ou móvel e seleciona Ativar neste dispositivo. Só então o Passwork transfere os registos cifrados para uma cache local nesse dispositivo específico.

Ao abrir a aplicação de desktop ou móvel sem ligação à Internet, só estão disponíveis os registos previamente guardados para acesso offline. Se o servidor ficar inacessível a meio de uma sessão, a aplicação oferece três opções:

• Terminar sessão na aplicação de desktop ou móvel
• Tentar novamente a ligação ao servidor
• Mudar para o modo offline para consultar apenas os registos em cache

Quando a conectividade é restabelecida, o Passwork sincroniza a cache e envia para o servidor um log de cada visualização offline.

Controlos de administração, visibilidade e acompanhamento de riscos

O acesso offline é regido ao nível da função e não funciona sem controlo. Os administradores mantêm controlo total sobre quem o utiliza e sobre a forma como é monitorizado.

Permissões baseadas em funções

Os administradores decidem que funções podem utilizar o acesso offline, durante quanto tempo um dispositivo pode ficar sem sincronizar antes de a cache ser apagada e quantos registos um único dispositivo pode conter.

Registo de auditoria completo

Cada transferência offline aparece no registo de eventos e no painel de segurança. Todas as ações realizadas em registos offline refletem-se também no registo de atividade assim que o dispositivo sincroniza, tal como acontece com qualquer outra palavra-passe. Assim, as equipas de segurança dispõem, sobre o acesso offline, do mesmo nível de supervisão que já têm sobre a atividade online.

Visibilidade ao nível do dispositivo

Os administradores podem ver quem colocou um registo em cache, em que dispositivo e quando esse dispositivo sincronizou pela última vez. A janela de acesso de uma pasta ou de um cofre mostra também o nome do utilizador e do dispositivo, pelo que os administradores podem rastrear a atividade offline até ao dispositivo concreto sem sair da vista de permissões.

Acompanhamento da exposição

O painel de segurança do Passwork trata um registo offline como uma potencial exposição a partir do momento em que fica numa cache local, quer o utilizador o abra ou não. Segue-se a mesma lógica já aplicada aos registos consultados.

Política de desativação por predefinição

Após a atualização para a versão 7.7, a funcionalidade fica ativada por predefinição apenas para as funções Proprietário e Administrador. Todos os restantes começam com a funcionalidade desativada.

Aspetos essenciais do modo offline

• Onde funciona. Os registos podem ser marcados para acesso offline a partir de qualquer aplicação e cliente web, mas a sua consulta offline só está disponível nas aplicações móveis e de desktop. Tem de ser ativado separadamente em cada dispositivo.
• Que dados estão disponíveis. Sem ligação, os utilizadores só podem consultar as palavras-passe que já adicionaram à lista offline e sincronizaram previamente.
• Expiração automática. Se um dispositivo não sincronizar dentro do prazo definido pelo administrador, os registos em cache são apagados automaticamente.
• Definições por função. Os administradores definem as regras para os utilizadores: quantos registos podem ser guardados por dispositivo e durante quanto tempo permanecem válidos sem sincronização.
• Controlo administrativo. Os administradores decidem que funções podem, de todo, utilizar o acesso offline e podem desativá-lo por completo para funções específicas. Cada registo em cache permanece visível no registo de atividade e nas janelas de acesso, indicando que utilizador o colocou em cache, em que dispositivo e quando foi a última sincronização.
• Monitorização da atividade. Quando um dispositivo volta a ligar-se, todas as ações realizadas offline são sincronizadas com o registo de atividade e surgem a par do histórico habitual do registo, o que dá aos administradores visibilidade total, tal como em qualquer atividade online.

Limitações do modo offline

• Só de leitura. No modo offline, os registos só podem ser consultados. Criar, editar ou eliminar uma palavra-passe exige ligação ao servidor.
• Revogação. A revogação do acesso a um registo não apaga a cópia local de imediato: a alteração só produz efeito quando o dispositivo volta a ficar online.
• Disponibilidade por licença. O acesso offline só está disponível na licença avançada.

Controlo de anexos de ficheiros

Os administradores podem agora desativar os anexos de ficheiros nos registos em toda a organização. Depois de desativados, os utilizadores não podem adicionar ficheiros a nenhum registo de palavra-passe, independentemente da função ou das permissões do cofre. A definição encontra-se em Gestão de cofres → Definições → Geral.

Melhorias na pesquisa e na navegação

Os resultados de pesquisa incluem agora uma coluna URLs a par de uma coluna com o diretório principal das pastas, o que facilita identificar onde se encontram os itens sem os abrir. A barra de pesquisa ativa-se agora automaticamente assim que o utilizador começa a escrever. Foi também removida a divisão das consultas de pesquisa em subcadeias de texto, pelo que os resultados correspondem agora com maior precisão à intenção do utilizador.

Aplicações de desktop e móveis

Tanto as aplicações de desktop como as móveis incluem agora a implementação do acesso offline descrita acima. A aplicação móvel recebe ainda outras melhorias: controlos ao nível da organização para bloquear capturas de ecrã e gravação de ecrã (Definições do sistema → Extensões do navegador e aplicações móveis) e pesquisa entre pastas, e não apenas em registos individuais. Foi também adicionado o suporte para a transferência do pacote MSI na aplicação de desktop.

Novo: Guias de integração

Em simultâneo com a versão, foi publicada uma secção completa de integração estruturada em torno de cinco funções: utilizadores, gestores de departamento, administradores de TI, engenheiros de DevOps e especialistas em segurança. Cada guia abrange exatamente o que uma pessoa nessa função precisa de configurar no primeiro dia, sem pressupor familiaridade prévia com o produto.

Os administradores que implementam o Passwork em toda a organização dispõem de um guia prático que abrange a integração com LDAP e SSO, a estrutura de cofres e o aprovisionamento de utilizadores em massa. As equipas de DevOps dispõem de um percurso separado para a utilização da CLI e do SDK, contas de serviço e injeção de segredos em pipelines de CI/CD. Os responsáveis pela segurança e pela conformidade podem percorrer listas de verificação alinhadas com a ISO 27001, o RGPD e o NIST.

Passwork conquista o Top Performer Summer 2026 da SourceForge

O Passwork recebe o galardão Top Performer da SourceForge para o verão de 2026, o segundo trimestre consecutivo, com base em avaliações verificadas e numa classificação global de 4,9/5.

PassworkPasswork Team

Resumo das notícias de cibersegurança: O mês em que os agentes de IA começaram a atacar por conta própria

Um agente GPT-5.6 escapou da sua sandbox e comprometeu a infraestrutura da Hugging Face. A SonicWall lançou duas vulnerabilidades 0-day que obrigaram a uma reposição completa de palavras-passe e de TOTP. O relatório de 2026 da IBM sobre o custo das violações de dados atingiu um recorde de 4,99 milhões de dólares. Eis o que aconteceu em cibersegurança neste mês de julho e o que a equipa tem de corrigir primeiro.

PassworkPasswork Team

IBM Cost of a Data Breach Report 2026: A ameaça de IA de 6 milhões de dólares que ninguém está a resolver

Os custos globais das violações de dados atingiram um recorde de 4,99 milhões de dólares em 2026, com a deteção a demorar 247 dias. Os ataques baseados em IA aumentam 56 %, mas a verdadeira crise é outra: os defensores utilizam IA em todo o lado, exceto onde os atacantes entram. 92 % das organizações violadas com recurso a IA não tinham quaisquer controlos de acesso adequados.

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

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

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

As políticas de cofre do Passwork (também designadas tipos de cofre ou Vault Types): uma camada de governação configurável que permite aos administradores definir, para cada categoria de cofre, quem são os seus administradores permanentes, que nível de acesso têm os criadores do cofre e quem pode criar cofres desse tipo. Uma vez definidas, estas regras aplicam-se automaticamente a todos os cofres criados nesse tipo.

A maioria das empresas não consegue afirmar com certeza quem tem direitos de administrador sobre o cofre de credenciais partilhadas de uma determinada equipa, porque o acesso de administração é atribuído de modo informal, sem uma política que o sustente. As políticas de cofre de palavras-passe empresariais resolvem este problema ao associar os direitos de administração à própria política do cofre, e não a quem o criou.

Este guia explica como a arquitetura de tipos de cofre (Vault Types) do Passwork dá aos diretores de TI (CIO) e aos responsáveis pela segurança da informação (CISO) um modelo prático de governação de cofres, que vai além das regras básicas de palavras-passe.

O que são as políticas de cofre e porque é que os CIO precisam delas

As políticas de cofre são regras de governação que determinam quem pode criar um cofre, a quem é atribuído automaticamente o acesso de administrador e quem não pode ser removido desse acesso. Deslocam o debate dos «requisitos de complexidade das palavras-passe» para a governação de cofres: um controlo estrutural sobre o armazenamento de credenciais da empresa, e não apenas sobre as próprias credenciais.

Três categorias de ferramentas afirmam resolver este problema: 

• Os gestores de palavras-passe de consumo tratam bem a partilha de credenciais pessoais ou de pequenas equipas, mas não foram concebidos para a governação departamental em escala 
• As plataformas de gestão de acessos privilegiados (PAM) protegem contas ao nível da infraestrutura e contas de serviço, mas acrescentam custos e complexidade de que a maioria dos casos de partilha de credenciais não precisa 
• Os gestores de palavras-passe empresariais com motores dedicados de políticas de cofre situam-se entre os dois, e é esta a abordagem em que o presente artigo se centra

Ação para o CIO: Audite a organização à procura de «cofres não autorizados»: pastas partilhadas ou cofres de equipa criados sem o conhecimento da TI, muitas vezes numa ferramenta de consumo que um departamento adotou por iniciativa própria.

Arquitetura das políticas de cofre: como o Passwork estrutura os acessos

O Passwork 7.1 introduziu uma arquitetura de tipos de cofre em que cada política de cofre define os seus próprios administradores, permissões de criação e regras de criação antes de existir um único cofre. Todos os novos cofres criados ao abrigo dessa política herdam automaticamente os administradores designados, e o proprietário do cofre não os pode remover.

Por predefinição, existem dois tipos básicos de cofre: os Cofres de utilizador, repositórios de credenciais privados ou partilhados, controlados inteiramente pelo seu criador, e os Cofres da empresa, que incluem sempre os administradores da empresa. Além destes, os administradores podem criar um número ilimitado de tipos de cofre personalizados, um por departamento, projeto ou nível de acesso, cada um com os seus próprios administradores designados e regras de criação.

Daqui resultam três benefícios concretos para o negócio:

• Controlo sobre os cofres de equipa sem que um único superadministrador detenha uma chave mestra de todas as palavras-passe da empresa
• Um caminho de recuperação que funciona quando alguém sai ou perde o acesso, através de uma conta de recuperação previamente aprovisionada, cuja palavra-passe mestra é guardada offline
• Nenhum «botão único» ou chave mestra obrigatória que desbloqueie de uma só vez as credenciais de toda a organização

A versão 7.4 acrescentou controlos de restrição específicos para os cofres de utilizador, que permitem aos administradores limitar também as permissões de partilha e de criação no nível dos cofres pessoais, fechando uma lacuna que os tipos de cofre básicos, por si sós, não cobriam.

Ação para o CIO: Mapeie a estrutura organizacional para tipos de cofre, um por departamento ou projeto, e atribua administradores da empresa antes de as equipas começarem a criar cofres por iniciativa própria.

O Passwork face a outras abordagens de controlo de acesso a cofres

Para qualquer ferramenta de gestão de credenciais, importa saber se a função de administrador está associada previamente a uma política e se a recuperação de acessos exige uma chave que também abre tudo o resto na organização. Na tabela seguinte, a resposta pretendida na coluna da chave única é «Não»: significa que não existe um ponto único de falha integrado.

Os gestores de palavras-passe orientados para o consumidor permitem muitas vezes que os administradores de equipa giram um cofre partilhado, mas raramente aplicam essa política automaticamente a todos os novos cofres criados por um departamento. 

Algumas ferramentas dependem de um único superadministrador, que pode repor a palavra-passe de qualquer utilizador e aceder a todas as pastas partilhadas da empresa. Outras associam todos os cofres da empresa a uma única chave de cifragem partilhada, pelo que o comprometimento dessa chave expõe tudo de uma só vez. 

As plataformas PAM resolvem um problema diferente: guardam em cofre as credenciais privilegiadas da infraestrutura, muitas vezes protegidas pela sua própria chave mestra ou chave break-glass, em vez de governarem a partilha de palavras-passe ao nível das equipas.

Ação para o CIO: Avalie a ferramenta de credenciais atual segundo estes três critérios: atribuição de administradores associada a políticas, um caminho de recuperação funcional e a ausência de uma chave universal obrigatória.

Lista de verificação de governação de cofres com cinco políticas para CIO

Cinco decisões de configuração específicas transformam a implementação de um gestor de palavras-passe numa governação de cofres funcional. Cada uma corresponde a um modo de falha distinto, observado em intervenções reais de resposta a incidentes, e não a um risco teórico.

• Desative a criação e a partilha de cofres privados onde não sejam necessárias. Os cofres privados sem restrições são precisamente a forma como se criam cofres não autorizados fora da visibilidade da TI. Restrinja a criação de cofres privados às funções que realmente precisam dela.
• Atribua administradores da empresa a cada política de cofre de equipa e de departamento. Assim garante-se uma supervisão contínua, sem depender de que uma única pessoa se lembre de se adicionar.
• Defina uma política de acesso de emergência antes de precisar dela. Decida entre um único circuito de recuperação à escala da organização ou contas de recuperação separadas por departamento, e guarde offline as credenciais mestras dessa conta de recuperação.
• Implemente o controlo de acessos baseado em funções (RBAC) através do Active Directory ou do LDAP. A sincronização de grupos e funções aplica automaticamente o princípio do menor privilégio e elimina erros de aprovisionamento manual quando os colaboradores mudam de função.
• Alinhe o comprimento e as regras de rotação das palavras-passe com as orientações atuais do NIST. A publicação NIST SP 800-63B Rev. 4 (2025) estabelece um mínimo de 15 caracteres para as palavras-passe usadas como único fator de autenticação e retira formalmente o requisito obrigatório de rotação a cada 90 dias (NIST SP 800-63B, 2025) [verificar o URL exato da publicação antes da impressão]. A rotação forçada sem indícios de comprometimento leva os utilizadores para palavras-passe previsíveis, apenas incrementadas, que é precisamente o resultado que as orientações agora desencorajam.

Ação para o CIO: Realize, ainda neste trimestre, uma auditoria de lacunas face às cinco políticas e atribua um responsável a cada constatação, em vez de tratar a auditoria como um relatório pontual.

Cumprir os requisitos da NIS2 e da ISO 27001 com a governação de cofres

As políticas de cofre correspondem diretamente aos dois requisitos que os auditores verificam primeiro: controlo de acessos documentado e um registo de auditoria verificável. A Diretiva NIS2 (UE) 2022/2555, no artigo 21.º, n.º 2, exige políticas de controlo de acessos e autenticação multifator como parte das medidas de gestão dos riscos de cibersegurança de uma entidade. Os controlos 5.15 e 8.15 da norma ISO/IEC 27001:2022 exigem o mesmo par: um modelo de acesso definido e um registo de quem o exerceu e quando.

Os administradores da empresa associados a uma política de cofre cobrem o lado do controlo de acessos sem folhas de cálculo manuais. Os registos de auditoria exportáveis e com data e hora cobrem o resto.

O DBIR 2026 da Verizon verificou que as credenciais estiveram presentes, em alguma fase, em 39 % das violações de dados, como vetor de acesso inicial em 13 % das violações confirmadas e como principal vetor em 52 % dos Basic Web Application Attacks (ataques básicos a aplicações web). IBM indica, no 2026 Cost of a Data Breach Report, que o custo médio global de uma violação de dados é de 4,99 milhões de dólares, um aumento de 12 % em relação ao ano passado e um máximo histórico.

Ação para o CIO: Peça à equipa de segurança um relatório atualizado de cobertura do controlo de acessos da NIS2 ainda este mês, antes que seja um auditor a pedi-lo primeiro.

O que isto significa para a implementação

A governação de cofres é uma decisão estrutural, tomada como a segmentação de rede: concebida em função dos departamentos e dos níveis de risco antes de um incidente forçar uma reformulação. As organizações que acertam nisto tratam-no assim desde o início. Ao abrigo da NIS2 e do RGPD, essa estrutura é hoje um requisito para as empresas abrangidas.

Comece pela auditoria, não pela ferramenta. Identifique os cofres que existem hoje, quem realmente os controla e onde o caminho de recuperação falha se uma só pessoa sair.

Perguntas frequentes

Passwork 7.7: modo offline seguro para aplicações de computador e móveis

As palavras-passe passam a funcionar também offline. O Passwork 7.7 traz acesso offline seguro com supervisão administrativa total, controlos de anexos de ficheiros ao nível da organização e cinco novos guias de integração baseados em funções, para uma implementação mais tranquila.

Passwork BlogPasswork Team

DBIR 2026 da Verizon: 10 estatísticas que devem mudar a estratégia de segurança

O DBIR 2026 da Verizon analisou mais de 22 000 violações de dados em 145 países. A exploração de vulnerabilidades ultrapassou o abuso de credenciais como principal vetor de ataque, enquanto o ransomware, o risco de terceiros e os ataques assistidos por IA cresceram de forma acentuada. Estes são os 10 números que importam.

Passwork BlogAlex Muntyan

Requisitos de palavras-passe da NIS2: o que as empresas europeias têm de fazer em 2026

As lacunas de credenciais são o principal ponto de falha nas auditorias da NIS2 em 2026. Este guia abrange os requisitos de palavras-passe do artigo 21.º, o alinhamento com a NIST SP 800-63B, as medidas de reforço (hardening) do AD e as provas de auditoria que os reguladores pedem primeiro.

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

Tresortypen

Passwork 7.1 führt eine robuste Tresortypen-Architektur ein, die unternehmensgerechte Zugangskontrolle für verbesserte Sicherheit und Verwaltung bietet. Tresortypen adressieren eine zentrale Herausforderung für Administratoren: die Kontrolle des Datenzugriffs und die Delegation der Tresorverwaltung in großen Organisationen. Bisher war die Auswahl auf zwei Typen beschränkt. Jetzt können Sie benutzerdefinierte Tresortypen erstellen, die auf jede Aufgabe oder Organisationsstruktur zugeschnitten sind.

Für jede Abteilung oder jedes Projekt können Sie einen dedizierten Tresortyp erstellen, spezifische Administratoren zuweisen, Ersteller-Berechtigungen festlegen und definieren, wer Tresore dieses Typs erstellen darf.

Beispielsweise können Sie separate Tresore für die IT-Abteilung, Finanzen, Personalwesen oder temporäre Projektteams erstellen. Administratoren, die einem bestimmten Tresortyp zugewiesen sind, werden automatisch zu allen neuen Tresoren dieses Typs hinzugefügt, was kontinuierliche Kontrolle und Transparenz gewährleistet.

Was sind Tresortypen

Tresortypen ermöglichen es Administratoren, Tresorvorlagen mit vordefinierten Zugriffsverwaltungseinstellungen zu erstellen. Für jeden Tresortyp können Sie spezifische Administratoren bestimmen, Ersteller-Berechtigungen konfigurieren und Regeln oder Einschränkungen für die Erstellung neuer Tresore festlegen.

Sie können Tresore nach Abteilung, Projekt oder Zugangslevel organisieren und so sicherstellen, dass Berechtigungen präzise zugewiesen werden

Wenn ein Tresor erstellt wird, erhalten die in den Tresortyp-Einstellungen angegebenen Administratoren automatisch Zugriff. Diese Administratoren können nicht entfernt oder herabgestuft werden, was sicherstellt, dass Schlüsselpersonen — wie Abteilungsleiter oder IT-Administratoren — stets die Kontrolle über kritische Daten behalten.

Grundlegende Tresortypen

Passwork verfügt über zwei grundlegende Tresortypen: Benutzertresore und Unternehmenstresore — diese können nicht gelöscht oder umbenannt werden:

• Benutzertresore: Standardmäßig sind diese nur für ihre Ersteller zugänglich und werden entweder als privat oder geteilt kategorisiert. Ein privater Tresor wird geteilt, wenn der Besitzer dieses Tresors anderen Benutzern Zugriff gewährt.
• Unternehmenstresore: Diese Tresore sind sowohl für den Ersteller als auch für Unternehmensadministratoren verfügbar, die automatisch Zugriff erhalten. Unternehmensadministratoren können nicht entfernt oder herabgestuft werden, was kontinuierliche Überwachung und Kontrolle gewährleistet.

Neben den grundlegenden Typen können Sie unbegrenzt benutzerdefinierte Tresortypen erstellen.

Vorteile von Tresortypen

Tresortypen ermöglichen es Passwork-Administratoren zu kontrollieren, wer Tresore erstellen kann, automatisch Administratoren zuzuweisen, die nicht entfernt werden können, und Ersteller-Berechtigungen effektiv zu verwalten.

• Kontinuierliche Kontrolle: Neue Tresore eines bestimmten Typs enthalten automatisch nicht entfernbare Administratoren, was kontinuierlichen Zugriff auf kritische Daten und konsistente Sicherheitsstandards über alle Tresore desselben Typs gewährleistet.
• Flexibilität bei Berechtigungen: Sie können Benutzern erlauben, Tresore zu erstellen, während Sie bestimmte Aktionen einschränken, wie z. B. das Verbot, andere Benutzer einzuladen.
• Delegation: Tresortypen ermöglichen eine granulare Berechtigungsverteilung — beispielsweise kann der IT-Leiter IT-Tresore verwalten, während der Vertriebsleiter die Tresore der Vertriebsabteilung überwacht.
• Audit und Analyse: Sehen Sie einfach alle Tresore im System zusammen mit ihren Typen und zugehörigen Benutzern ein und passen Sie Tresortypen bei Bedarf schnell an.
• Vereinfachte Tresorerstellung: Keine Notwendigkeit, Berechtigungen jedes Mal von Grund auf neu zu konfigurieren.

Tresore aller Typen unterstützen eine mehrstufige, ordnerbasierte Struktur, die es Administratoren ermöglicht, Hierarchien mit verschachtelten Elementen zu erstellen

Tresortypen verwalten

Auf der Seite Tresoreinstellungen können Sie alle Tresortypen verwalten, ihre Liste einsehen und Berechtigungen für Aktionszugriffe konfigurieren. Der Zugriff auf diesen Bereich wird durch individuelle Rollen-Berechtigungen gesteuert, was sicherstellt, dass nur autorisierte Benutzer kritische Einstellungen ändern können.

Tresortypen erstellen

Sie können aus grundlegenden Tresortypen wählen oder eigene benutzerdefinierte Typen erstellen. Um einen benutzerdefinierten Tresortyp einzurichten, klicken Sie auf Tresortyp erstellen.

Das Fenster zur Tresortyp-Erstellung bietet folgende Optionen:

• Name — geben Sie den Namen des Tresortyps an.
• Administratoren — wählen Sie Benutzer aus, die automatisch zu allen Tresoren dieses Typs mit Administrator-Berechtigungen hinzugefügt werden.
• Ersteller-Zugriff — definieren Sie das Zugangslevel, das Benutzern gewährt wird, die Tresore dieses Typs erstellen. Beispielsweise können Sie Mitarbeitern erlauben, Tresore zu erstellen, ohne ihnen zu gestatten, andere Benutzer einzuladen.
• Wer kann Tresore erstellen — bestimmen Sie, wer Tresore dieses Typs erstellen darf: bestimmte Benutzer, Gruppen, Rollen oder alle Benutzer.

Tresortypen bearbeiten

Benutzer mit Zugriff auf den Reiter Tresortypen können Tresortypen ändern, indem sie diese umbenennen, Administratoren hinzufügen oder entfernen und Tresorerstellungs-Berechtigungen aktualisieren. Um einen Tresortyp zu bearbeiten, wählen Sie ihn aus der Liste aller Typen aus und passen Sie die erforderlichen Felder an.

Wenn ein Benutzer als Administrator zu einem bestehenden Tresortyp hinzugefügt wird, müssen Sie die Anfrage bestätigen, um ihm Zugriff auf die entsprechenden Tresore zu gewähren.

Tresortypen löschen

Um einen Tresortyp zu löschen, wählen Sie einen oder mehrere Typen im Reiter Tresortypen aus und klicken Sie auf Löschen im Dropdown-Menü oben in der Liste.

Audit und Tresortyp-Änderung

Im Reiter Alle Tresore können Sie alle Tresore zusammen mit ihren Typen, Benutzerlisten und Administratoren einsehen. Zusätzlich können Sie den Typ eines Tresors schnell ändern — beispielsweise wenn eine Abteilung reorganisiert wird oder ein neues Projekt erstellt wird.

Sie haben die Möglichkeit, Tresore nach Typ zu filtern oder nur diejenigen anzuzeigen, auf die Sie Zugriff haben.

Einstellungen

Der Reiter Einstellungen ermöglicht es, das erforderliche Mindestzugangslevel für die Ausführung bestimmter Aktionen innerhalb von Verzeichnissen zu definieren sowie die maximale Dateigröße für Anhänge festzulegen, die mit Passwörtern verknüpft sind.

Migration von früheren Versionen

Bei der Migration von früheren Versionen können Sie importierten Tresoren im Tresor-Import-Fenster einen Tresortyp zuweisen, sofern Sie die Option wählen, in das Stammverzeichnis zu importieren.

Beim Upgrade von Passwork 6 auf Version 7 konvertiert das System bestehende Tresore automatisch:

• Private Tresore bleiben privat und erhalten den Typ Benutzertresore. Ihre Berechtigungen und Zugriffsrechte bleiben unverändert.
• Geteilte Tresore erhalten ebenfalls den Typ Benutzertresore. Alle Benutzer und ihre Berechtigungen bleiben erhalten.
• Organisationstresore werden in den Unternehmens-Tresortyp konvertiert. Administratoren werden wiederhergestellt und werden nicht entfernbar, wobei die Zugriffsstruktur erhalten bleibt.

Häufig gestellte Fragen

• Was ist der Unterschied zwischen Tresortypen und regulären Tresoren? Reguläre Tresore sind Container zur Speicherung von Passwörtern. Tresortypen sind Regeln und Vorlagen, die definieren, wie Tresore eines bestimmten Typs erstellt und verwaltet werden.
• Ist die Verwendung von Tresortypen obligatorisch? Nein, die Verwendung benutzerdefinierter Tresortypen ist nicht obligatorisch. Sie haben immer Zugang zu grundlegenden Typen: private Tresore für persönliche Passwörter und geteilte Tresore für Passwörter, die Benutzer selbstständig teilen.

• Wie unterscheiden sich Unternehmensadministratoren von regulären Administratoren? Unternehmensadministratoren sind Benutzer, die automatisch Administratorrechte in allen Tresoren eines bestimmten Typs erhalten. Die Zuweisung von Unternehmensadministratoren gewährleistet permanente Kontrolle über kritische Daten.

• Kann ich Administratoren in einem bestehenden Typ ändern? Ja, Sie können die Liste der Administratoren in den Tresortyp-Einstellungen ändern. Beim Hinzufügen eines neuen Benutzers erstellt das System automatisch Anfragen, den neuen Administrator zu allen bestehenden Tresoren dieses Typs hinzuzufügen.

• Wie schränke ich ein, wer Tresore eines bestimmten Typs erstellen kann? Beim Erstellen oder Bearbeiten eines Tresortyps gehen Sie zu Wer kann Tresore erstellen und wählen Sie eine der Optionen: Alle Benutzer — jeder Benutzer kann einen Tresor dieses Typs erstellen, oder eingeschränkter Zugang — nur ausgewählte Benutzer, Rollen oder Gruppen.
• Kann ich den Typ eines bestehenden Tresors ändern? Ja, Sie können den Typ eines bestehenden Tresors ändern, aber nur wenn Sie Administratorrechte in diesem Tresor haben. Beim Ändern des Typs werden Unternehmensadministratoren des neuen Typs automatisch zum Tresor hinzugefügt, neue Zugriffsregeln werden angewendet und Benutzerverbindungsanfragen werden erstellt.
• Warum kann ich bestimmte Administratoren nicht aus einem Tresor entfernen? Wenn Sie Administratoren nicht aus einem Tresor entfernen können, handelt es sich um Unternehmensadministratoren. Unternehmensadministratoren können nur durch Ändern der entsprechenden Tresortyp-Einstellung entfernt werden (erfordert Administratorrechte).

Grundlegende Anwendungsfälle

Erstellung privater Tresore verbieten

Aufgabe: Mitarbeiter daran hindern, private Tresore zu erstellen.
Lösung: Öffnen Sie in den Tresoreinstellungen den Typ Benutzertresore. Entfernen Sie unter Wer kann Tresore erstellen alle Benutzer oder belassen Sie nur diejenigen, die dieses Recht behalten sollen.

Tresore mit obligatorischen Administratoren

Aufgabe: Alle von Benutzern erstellten Tresore müssen Unternehmensadministratoren enthalten.
Lösung: Erstellen Sie in den Tresoreinstellungen einen oder mehrere neue Tresortypen. Fügen Sie im Abschnitt Administratoren die erforderlichen Benutzer (Unternehmensadministratoren) hinzu — sie werden automatisch zu allen Tresoren dieses Typs mit Rechten hinzugefügt, die nicht geändert oder widerrufen werden können. Verbieten Sie die Erstellung anderer Tresortypen.

Erstellung privater Tresore ohne Benutzereinladungsrechte

Aufgabe: Benutzern erlauben, eigene Tresore zu erstellen, aber das Einladen anderer Benutzer verbieten.
Lösung: Erstellen Sie in den Tresoreinstellungen einen neuen Typ mit dem Zugangslevel „Vollständiger Zugang" für den Ersteller — dieses Level verbietet das Hinzufügen anderer Benutzer.

Delegation administrativer Verantwortlichkeiten

Aufgabe: Das System so konfigurieren, dass verschiedene Abteilungen oder Projekte ihre eigenen Administratoren haben.
Lösung: Erstellen Sie in den Tresoreinstellungen separate Typen für jede Abteilung und fügen Sie entsprechende Rollen hinzu.

Tresorverwaltung einschränken

Aufgabe: Administratoren daran hindern, die Liste aller Tresore einzusehen, Tresortypen zu verwalten und Zugangslevel-Einstellungen zu ändern.
Lösung: Öffnen Sie in den Rolleneinstellungen die Administrator-Rolle. Deaktivieren Sie im Abschnitt Tresore die erforderlichen Berechtigungen — Sie können den Zugriff auf den Bereich mit der Liste aller Tresore oder auf die gesamte Seite Tresoreinstellungen einschränken.

Fazit: Datenkontrolle und Effizienz

Tresortypen adressieren eine zentrale Herausforderung für wachsende Unternehmen: die Kontrolle des Datenzugriffs ohne Überlastung der IT-Abteilung. Administratoren erhalten automatisch Zugriff auf neue Tresore ihres Typs, während Abteilungsleiter Daten eigenständig verwalten können. Passwork skaliert mit Ihrer Organisation und stellt sicher, dass Daten sicher bleiben, Prozesse automatisiert sind und Mitarbeiter effizient arbeiten können.

Weiterführende Lektüre

Incident response planning: Preparedness vs. reality

Discover key insights from Passwork webinar on incident response planning. Why teamwork and tools drive real cybersecurity resilience.

Passwork BlogTurpal Makh

GDPR password security: Guide to effective staff training

Learn proven strategies to train employees for GDPR password security compliance. Reduce breach risks with practical training methods.

Passwork BlogAna Moore

Passwork 7: Security verified by HackerOne

Passwork has successfully completed the penetration testing, carried out by HackerOne — the world's largest platform for coordinating bug bounty programs and security assessments. This independent evaluation confirmed Passwork's highest level of data protection and strong resilience against modern cyber threats. What the pentest covered Security architecture and data

Passwork BlogEirik Salmi

Tipos de bóvedas

Passwork 7.1 introduce una arquitectura robusta de tipos de bóvedas, proporcionando control de acceso de nivel empresarial para una seguridad y gestión mejoradas. Los tipos de bóvedas abordan un desafío clave para los administradores: controlar el acceso a los datos y delegar la gestión de bóvedas en organizaciones grandes. Anteriormente, la elección se limitaba a dos tipos. Ahora, puede crear tipos de bóvedas personalizados adaptados a cualquier tarea o estructura organizativa.

Para cada departamento o proyecto, puede crear un tipo de bóveda dedicado, asignar administradores específicos, elegir los permisos del creador y definir quién puede crear bóvedas de este tipo.

Por ejemplo, puede crear bóvedas separadas para el departamento de TI, finanzas, recursos humanos o equipos de proyectos temporales. Los administradores asignados a un tipo de bóveda específico se añadirán automáticamente a todas las nuevas bóvedas de este tipo, asegurando un control y transparencia constantes.

Qué son los tipos de bóvedas

Los tipos de bóvedas permiten a los administradores establecer plantillas de bóvedas con configuraciones de gestión de acceso predefinidas. Para cada tipo de bóveda, puede designar administradores específicos, configurar los permisos del creador de la bóveda y establecer reglas o restricciones para crear nuevas bóvedas.

Puede organizar las bóvedas por departamento, proyecto o nivel de acceso, asegurando que los permisos se asignen con precisión

Cuando se crea una bóveda, los administradores especificados en la configuración del tipo de bóveda reciben acceso automáticamente. Estos administradores no pueden ser eliminados ni degradados, asegurando que el personal clave — como jefes de departamento o administradores de TI — siempre mantenga el control sobre los datos críticos.

Tipos de bóvedas básicos

Passwork tiene dos tipos de bóvedas básicos: Bóvedas de usuario y Bóvedas de empresa — no pueden eliminarse ni renombrarse:

• Bóvedas de usuario: Por defecto, estas solo son accesibles para sus creadores y se categorizan como privadas o compartidas. Una bóveda privada se convierte en compartida cuando el propietario de esta bóveda otorga acceso a otros usuarios.
• Bóvedas de empresa: Estas bóvedas están disponibles tanto para el creador como para los administradores corporativos, quienes reciben acceso automáticamente. Los administradores corporativos no pueden ser eliminados ni degradados, asegurando una supervisión y control continuos.

Además de los tipos básicos, puede crear tipos de bóvedas personalizados ilimitados.

Ventajas de los tipos de bóvedas

Los tipos de bóvedas permiten a los administradores de Passwork controlar quién puede crear bóvedas, asignar automáticamente administradores que no pueden ser eliminados y gestionar eficazmente los permisos de los creadores.

• Control constante: Las nuevas bóvedas de un tipo específico incluyen automáticamente administradores no eliminables, asegurando un acceso continuo a los datos críticos y estándares de seguridad consistentes en todas las bóvedas del mismo tipo.
• Flexibilidad de permisos: Puede permitir que los usuarios creen bóvedas mientras restringe ciertas acciones, como prohibirles invitar a otros usuarios.
• Delegación: Los tipos de bóvedas permiten una distribución granular de permisos — por ejemplo, el director de TI puede gestionar las bóvedas de TI, mientras que el director de ventas supervisa las bóvedas del departamento de ventas.
• Auditoría y análisis: Vea fácilmente todas las bóvedas del sistema, junto con sus tipos y usuarios asociados, y ajuste rápidamente los tipos de bóvedas según sea necesario.
• Creación de bóvedas simplificada: No es necesario configurar los permisos desde cero cada vez.

Las bóvedas de todos los tipos admiten una estructura multinivel basada en carpetas, lo que permite a los administradores crear jerarquías con elementos anidados

Gestión de tipos de bóvedas

En la página Configuración de bóvedas, puede gestionar todos los tipos de bóvedas, ver su lista y configurar los permisos de acceso a acciones. El acceso a esta sección está controlado por permisos de rol individuales, asegurando que solo los usuarios autorizados puedan modificar configuraciones críticas.

Creación de tipos de bóvedas

Puede elegir entre los tipos de bóvedas básicos o crear sus propios tipos personalizados. Para configurar un tipo de bóveda personalizado, haga clic en Crear tipo de bóveda.

La ventana de creación de tipo de bóveda ofrece las siguientes opciones:

• Nombre — especifique el nombre del tipo de bóveda.
• Administradores — seleccione los usuarios que se añadirán automáticamente a todas las bóvedas de este tipo con permisos de administrador.
• Acceso del creador — defina el nivel de acceso otorgado a los usuarios que crean bóvedas de este tipo. Por ejemplo, puede permitir que los empleados creen bóvedas sin permitirles invitar a otros usuarios.
• Quién puede crear bóvedas — determine quién puede crear bóvedas de este tipo: usuarios específicos, grupos, roles o todos los usuarios.

Edición de tipos de bóvedas

Los usuarios con acceso a la pestaña Tipos de bóvedas pueden modificar los tipos de bóvedas renombrándolos, añadiendo o eliminando administradores y actualizando los permisos de creación de bóvedas. Para editar un tipo de bóveda, selecciónelo de la lista de todos los tipos y ajuste los campos necesarios.

Si se añade un usuario como administrador a un tipo de bóveda existente, debe confirmar la solicitud para otorgarle acceso a las bóvedas correspondientes.

Eliminación de tipos de bóvedas

Para eliminar un tipo de bóveda, seleccione uno o más tipos en la pestaña Tipos de bóvedas y haga clic en Eliminar en el menú desplegable en la parte superior de la lista.

Auditoría y cambio de tipo de bóveda

En la pestaña Todas las bóvedas, puede ver todas las bóvedas junto con sus tipos, listas de usuarios y administradores. Además, puede cambiar rápidamente el tipo de una bóveda — por ejemplo, cuando se reorganiza un departamento o se crea un nuevo proyecto.

Tiene la opción de filtrar las bóvedas por tipo o mostrar solo aquellas a las que tiene acceso.

Configuración

La pestaña Configuración permite definir el nivel de acceso mínimo requerido para realizar acciones específicas dentro de los directorios, así como establecer el tamaño máximo de archivo para los adjuntos vinculados a contraseñas.

Migración desde versiones anteriores

Al migrar desde versiones anteriores, puede asignar un tipo de bóveda a las bóvedas importadas en la ventana de importación de bóvedas, siempre que elija la opción de importar al directorio raíz.

Al actualizar de Passwork 6 a la versión 7, el sistema convierte automáticamente las bóvedas existentes:

• Las bóvedas privadas permanecen privadas y reciben el tipo Bóvedas de usuario. Sus permisos y derechos de acceso permanecen sin cambios.
• Las bóvedas compartidas también reciben el tipo Bóvedas de usuario. Todos los usuarios y sus permisos se conservan.
• Las bóvedas de organización se convierten al tipo de bóveda de empresa. Los administradores se restauran y se vuelven no eliminables, con la estructura de acceso conservada.

Preguntas frecuentes

• ¿Cuál es la diferencia entre los tipos de bóvedas y las bóvedas normales? Las bóvedas normales son contenedores para almacenar contraseñas. Los tipos de bóvedas son reglas y plantillas que definen cómo se crean y gestionan las bóvedas de un tipo específico.
• ¿Es obligatorio usar tipos de bóvedas? No, usar tipos de bóvedas personalizados no es obligatorio. Siempre tendrá acceso a los tipos básicos: bóvedas privadas para contraseñas personales y bóvedas compartidas para contraseñas que los usuarios comparten de forma independiente.

• ¿En qué se diferencian los administradores corporativos de los normales? Los administradores corporativos son usuarios que reciben automáticamente derechos de administrador en todas las bóvedas de un tipo específico. Asignar administradores corporativos garantiza un control permanente sobre los datos críticos.

• ¿Puedo cambiar los administradores en un tipo existente? Sí, puede modificar la lista de administradores en la configuración del tipo de bóveda. Al añadir un nuevo usuario, el sistema crea automáticamente solicitudes para añadir al nuevo administrador a todas las bóvedas existentes de ese tipo.

• ¿Cómo restrinjo quién puede crear bóvedas de un tipo específico? Al crear o editar un tipo de bóveda, vaya a Quién puede crear bóvedas y elija una de las opciones: Todos los usuarios — cualquier usuario puede crear una bóveda de este tipo, o acceso limitado — solo usuarios, roles o grupos seleccionados.
• ¿Puedo cambiar el tipo de una bóveda existente? Sí, puede cambiar el tipo de una bóveda existente, pero solo si tiene derechos de administrador en esa bóveda. Al cambiar el tipo, los administradores corporativos del nuevo tipo se añaden automáticamente a la bóveda, se aplican las nuevas reglas de acceso y se crean solicitudes de conexión de usuarios.
• ¿Por qué no puedo eliminar ciertos administradores de una bóveda? Si no puede eliminar administradores de una bóveda, son administradores corporativos. Los administradores corporativos solo pueden ser eliminados cambiando la configuración del tipo de bóveda correspondiente (requiere derechos de administrador).

Casos de uso básicos

Prohibir la creación de bóvedas privadas

Tarea: Impedir que los empleados creen bóvedas privadas.
Solución: En Configuración de bóvedas, abra el tipo Bóvedas de usuario. En Quién puede crear bóvedas, elimine a todos los usuarios o deje solo a aquellos que necesiten conservar este derecho.

Bóvedas con administradores obligatorios

Tarea: Todas las bóvedas creadas por usuarios deben incluir administradores corporativos.
Solución: En Configuración de bóvedas, cree uno o más nuevos tipos de bóvedas. En la sección Administradores, añada los usuarios requeridos (administradores corporativos) — estos se añadirán automáticamente a todas las bóvedas de este tipo con derechos que no pueden ser cambiados ni revocados. Prohíba la creación de otros tipos de bóvedas.

Creación de bóvedas privadas sin derechos de invitación de usuarios

Tarea: Permitir que los usuarios creen sus propias bóvedas pero prohibir invitar a otros usuarios.
Solución: En Configuración de bóvedas, cree un nuevo tipo con nivel de acceso completo para el creador — este nivel prohíbe añadir a otros usuarios.

Delegación de responsabilidades administrativas

Tarea: Configurar el sistema para que diferentes departamentos o proyectos tengan sus propios administradores.
Solución: En Configuración de bóvedas, cree tipos separados para cada departamento y añada los roles correspondientes.

Limitar la gestión de bóvedas

Tarea: Impedir que los administradores vean la lista de todas las bóvedas, gestionen los tipos de bóvedas y la configuración de niveles de acceso.
Solución: En la configuración de roles, abra el rol de Administrador. En la sección Bóvedas, deshabilite los permisos necesarios — puede restringir el acceso a la sección con la lista de todas las bóvedas o a toda la página de Configuración de bóvedas.

Conclusión: Control de datos y eficiencia

Los tipos de bóvedas abordan un desafío clave para las empresas en crecimiento: controlar el acceso a los datos sin sobrecargar al departamento de TI. Los administradores obtienen automáticamente acceso a las nuevas bóvedas de su tipo, mientras que los jefes de departamento pueden gestionar los datos de forma independiente. Passwork escala con su organización, asegurando que los datos permanezcan seguros, los procesos estén automatizados y los empleados puedan trabajar eficientemente.

Lecturas adicionales

Planificación de respuesta a incidentes: Preparación vs. realidad

Descubra información clave del webinar de Passwork sobre planificación de respuesta a incidentes. Por qué el trabajo en equipo y las herramientas impulsan la verdadera resiliencia en ciberseguridad.

Passwork BlogTurpal Makh

Seguridad de contraseñas GDPR: Guía para una formación eficaz del personal

Aprenda estrategias probadas para formar a los empleados en el cumplimiento de seguridad de contraseñas GDPR. Reduzca los riesgos de brechas con métodos de formación prácticos.

Passwork BlogAna Moore

Passwork 7: Seguridad verificada por HackerOne

Passwork ha completado exitosamente las pruebas de penetración, realizadas por HackerOne — la plataforma más grande del mundo para coordinar programas de bug bounty y evaluaciones de seguridad. Esta evaluación independiente confirmó el más alto nivel de protección de datos de Passwork y su fuerte resiliencia contra las amenazas cibernéticas modernas. Qué cubrió el pentest Arquitectura de seguridad y datos

Passwork BlogEirik Salmi

Vault types

Passwork 7.1 introduces a robust vault types architecture, providing enterprise-grade access control for enhanced security and management. Vault types address a key challenge for administrators: controlling data access and delegating vault management across large organizations. Previously, the choice was limited to two types. Now, you can create custom vault types tailored to any task or organizational structure.

For each department or project, you can create a dedicated vault type, assign specific administrators, choose creator permissions, and define who can create vaults of this type.

For example, you can create separate vaults for IT department, finance, HR, or temporary project teams. Administrators assigned to a specific vault type will be automatically added to all new vaults of this type, ensuring constant control and transparency.

What are vault types

Vault types allow administrators to establish vault templates with predefined access management settings. For each vault type, you can designate specific administrators, configure vault creator permissions, and set rules or restrictions for creating new vaults.

You can organize vaults by department, project, or access level, ensuring that permissions are assigned accurately

When a vault is created, administrators specified in the vault type settings are automatically granted access. These administrators cannot be removed or demoted, ensuring that key personnel — such as department heads or IT administrators — always retain control over critical data.

Basic vault types

Passwork has two basic vault types: User vaults and Company vaults — they cannot be deleted or renamed:

• User vaults: By default, these are accessible only to their creators and are categorized as either private or shared. A private vault becomes shared when the owner of this vault grants access to other users.
• Company vaults: These vaults are available to both the creator and corporate administrators, who are automatically assigned access. Corporate administrators cannot be removed or demoted, ensuring continuous oversight and control.

Besides basic types, you can create unlimited custom vault types.

Advantages of vault types

Vault types empower Passwork administrators to control who can create vaults, automatically assign administrators who cannot be removed, and effectively manage creator permissions.

• Constant control: New vaults of a specific type automatically include non-removable administrators, ensuring continuous access to critical data and consistent security standards across all vaults of the same type.
• Permission flexibility: You can allow users to create vaults while restricting certain actions, such as prohibiting them from inviting other users.
• Delegation: Vault types enable granular permission distribution — for example, the IT director can manage IT vaults, while the sales director oversees sales department vaults.
• Audit and analysis: Easily view all vaults in the system, along with their types and associated users, and quickly adjust vault types as needed.
• Streamlined vault creation: No need to configure permissions from scratch each time.

Vaults of all types support a multi-level, folder-based structure, allowing administrators to create hierarchies with nested elements

Managing vault types

On the Vault settings page, you can manage all vault types, view their list, and configure action access permissions. Access to this section is controlled by individual role permissions, ensuring that only authorized users can modify critical settings.

Creating vault types

You can choose from basic vault types or create your own custom types. To set up a custom vault type, click Create vault type.

The vault type creation window offers the following options:

• Name — specify the vault type name.
• Administrators — select users who will be automatically added to all vaults of this type with Administrator permissions.
• Creator access — define the access level granted to users who create vaults of this type. For example, you can allow employees to create vaults without permitting them to invite other users.
• Who can create vaults — determine who is allowed to create vaults of this type: specific users, groups, roles, or all users.

Editing vault types

Users with access to the Vault types tab can modify vault types by renaming them, adding or removing administrators, and updating vault creation permissions. To edit a vault type, select it from the list of all types and adjust the necessary fields.

If a user is added as an administrator to an existing vault type, you must confirm the request to grant them access to the corresponding vaults.

Deleting vault types

To delete a vault type, select one or more types on the Vault types tab and click Delete in the dropdown menu at the top of the list.

Audit and vault type change

On the All vaults tab, you can view all vaults along with their types, user lists, and administrators. Additionally, you can quickly change a vault’s type — for example, when a department is reorganized or a new project is created.

You have the option to filter vaults by type or display only those to which you have access.

Settings

The Settings tab makes it possible to define the minimum required access level for performing specific actions within directories, as well as set the maximum file size for attachments linked to passwords.

Migration from previous versions

When migrating from previous versions, you can assign a vault type to imported vaults in the vault import window, provided you choose the option to import to the root directory.

When upgrading from Passwork 6 to version 7, the system automatically converts existing vaults:

• Private vaults remain private and receive the User vaults type. Your permissions and access rights remain unchanged.
• Shared vaults also receive the User vaults type. All users and their permissions are preserved.
• Organization vaults are converted to company vault type. Administrators are restored and become non-removable, with the access structure preserved.

Frequently asked questions

• What's the difference between vault types and regular vaults? Regular vaults are containers for storing passwords. Vault types are rules and templates that define how vaults of a specific type are created and managed.
• Is it mandatory to use vault types? No, using custom vault types is not mandatory. You'll always have access to basic types: private vaults for personal passwords and shared vaults for passwords users share independently.

• How do corporate administrators differ from regular ones? Corporate administrators are users who automatically receive administrator rights in all vaults of a specific type. Assigning corporate administrators ensures permanent control over critical data.

• Can I change administrators in an existing type? Yes, you can modify the list of administrators in the vault type settings. When adding a new user, the system automatically creates requests to add the new administrator to all existing vaults of that type.

• How do I restrict who can create vaults of a specific type? When creating or editing a vault type, go to Who can create vaults and choose one of the options: All users — any user can create a vault of this type, or limited access — only selected users, roles, or groups.
• Can I change the type of an existing vault? Yes, you can change an existing vault's type, but only if you have administrator rights in that vault. When changing the type, corporate administrators of the new type are automatically added to the vault, new access rules are applied, and user connection requests are created.
• Why can't I remove certain administrators from a vault? If you cannot remove administrators from a vault, they are corporate administrators. Corporate administrators can only be removed by changing the corresponding vault type setting (requires administrator rights).

Basic use cases

Prohibit private vaults creation

Task: Prevent employees from creating private vaults.
Solution: In Vault settings, open the User vaults type. In Who can create vaults, remove all users or leave only those who need to retain this right.

Vaults with mandatory administrators

Task: All vaults created by users must include corporate administrators.
Solution: In Vault settings, create one or more new vault types. In the Administrators section, add the required users (corporate administrators) — they will automatically be added to all vaults of this type with rights that cannot be changed or revoked. Prohibit creation of other vault types.

Private vaults creation without user invitation rights

Task: Allow users to create their own vaults but prohibit inviting other users.
Solution: In Vault settings, create a new type with Full access level for the creator—this level prohibits adding other users.

Delegating administrative responsibilities

Task: Configure the system so different departments or projects have their own administrators.
Solution: In Vault settings, create separate types for each department and add corresponding roles.

Limit vault management

Task: Prevent administrators from viewing the list of all vaults, managing vault types, and access level settings.
Solution: In role settings, open the Administrator role. In the Vaults section, disable the necessary permissions — you can restrict access to the section with the list of all vaults or to the entire Vault settings page.

Conclusion: Data control and efficiency

Vault types address a key challenge for growing companies: controlling data access without overwhelming the IT department. Administrators automatically gain access to new vaults of their type, while department heads can manage data independently. Passwork scales with your organization, ensuring data remains secure, processes are automated, and employees can work efficiently.

Further reading

Incident response planning: Preparedness vs. reality

Discover key insights from Passwork webinar on incident response planning. Why teamwork and tools drive real cybersecurity resilience.

Passwork BlogTurpal Makh

GDPR password security: Guide to effective staff training

Learn proven strategies to train employees for GDPR password security compliance. Reduce breach risks with practical training methods.

Passwork BlogAna Moore

Passwork 7: Security verified by HackerOne

Passwork has successfully completed the penetration testing, carried out by HackerOne — the world’s largest platform for coordinating bug bounty programs and security assessments. This independent evaluation confirmed Passwork’s highest level of data protection and strong resilience against modern cyber threats. What the pentest covered Security architecture and data

Passwork BlogEirik Salmi