Pegnitz é uma cidade industrial situada à entrada da Suíça da Francónia: compacta em dimensão, economicamente forte e culturalmente distinta. Vivem aqui cerca de 13 600 pessoas, no distrito de Bayreuth e na região metropolitana de Nuremberga, onde Pegnitz é o centro económico do distrito sul. A sua história remonta às antigas minas e à fundição Pegnitzhütte. Atualmente, a engenharia e a metalurgia coexistem com a indústria têxtil como base económica da cidade.
A vida cívica marca também o carácter da cidade. Pegnitz acolhe concertos de verão e feiras sazonais, mas o Gregori-Fest destaca-se: um festival infantil com uma tradição milenar, classificado como património cultural imaterial na Baviera. A estratégia municipal Pegnitz 2030 alarga este enfoque cívico ao planeamento económico e de infraestruturas, incluindo apoio ao emprego, desenvolvimento do centro da cidade e transição energética.
Esse crescimento chegou também às próprias operações de TI da administração. Com uma carga de trabalho mais pesada, o sistema baseado em ficheiros utilizado pela equipa para gerir acessos deixou de ser suficiente, levando-a a procurar uma alternativa self-hosted concebida para vários administradores a trabalhar em simultâneo.
Empresa: Stadt Pegnitz Localização: Baviera, Alemanha Setor: Administração municipal Dimensão da empresa: 160+ colaboradores
O desafio: Os conflitos de sincronização baseados em ficheiros atrasavam uma pequena equipa de TI
A infraestrutura de TI de Stadt Pegnitz é gerida pelo departamento de TI do município. Antes de mudar para o Passwork, a equipa utilizava um cofre de palavras-passe de código aberto e baseado em ficheiros para armazenar as credenciais dos servidores, comutadores de rede e firewalls do município. A ferramenta funcionava bem como cofre pessoal, mas não foi concebida para acesso simultâneo multiutilizador, e essa limitação manifestava-se diariamente.
Uma equipa reduzida responsável por toda a rede municipal tem pouca margem para ferramentas que acrescentem sobrecarga de coordenação. Essa fricção levou Pegnitz a procurar uma alternativa.
O ficheiro de base de dados único não suportava mais do que um administrador a abri-lo em simultâneo sem risco de conflito de fusão. Na prática, isto significava que um administrador perguntava a outro: «Está agora no cofre?» antes de fazer qualquer alteração, para evitar sobrepor-se à atualização de um colega.
A configuração anterior criava vários problemas que se agravavam mutuamente:
Cada alteração exigia coordenação verbal para evitar sobrepor as alterações de um colega
Podiam circular cópias desatualizadas da base de dados caso alguém se esquecesse de distribuir a versão mais recente
A ausência de um modelo de permissões baseado em funções impedia um controlo de acesso granular
Qualquer cofre baseado em ficheiros, sincronizado manualmente ou através de uma unidade de rede partilhada, encontra as mesmas limitações assim que mais do que uma pessoa precisa de acesso de escrita. Uma ferramenta que funciona bem para um único administrador transforma-se num problema de coordenação assim que entra uma segunda pessoa.
A solução: O Passwork cumpriu os requisitos de Pegnitz sem a sobrecarga de nível empresarial
Pegnitz precisava de uma única fonte de verdade para as credenciais de infraestrutura, sem sincronização baseada em ficheiros e sem a sobrecarga de uma implementação à escala empresarial.
«Como equipa de TI compacta, precisamos de ferramentas que facilitem o nosso trabalho, não que acrescentem sobrecarga administrativa. O Passwork tornou o nosso trabalho diário de infraestrutura mais seguro e muito mais rápido.» — Stadt Pegnitz IT team
A pesquisa, realizada em fóruns de TI e comunidades de código aberto, centrou-se em quatro requisitos que a interface e o modelo de implementação do Passwork satisfizeram diretamente:
Implementação self-hosted e on-premise, para manter os dados das credenciais sob o controlo do município
Cifragem do lado do cliente, para que os dados nunca cheguem ao servidor sem cifragem
Acesso multiutilizador sem bloqueio de ficheiros
Uma relação preço-valor razoável, uma vez que a equipa não tinha interesse em pagar por funcionalidades empresariais que não utilizaria
A interface do Passwork, concebida em torno do fluxo de trabalho real dos administradores e não como um cofre de estilo pessoal adaptado para equipas, foi a principal razão pela qual se destacou durante a avaliação.
Implementação e migração: Um lançamento rápido sem perda de dados
Dois fatores tornaram a avaliação de Pegnitz rápida:
Implementação baseada em Docker, que permitiu à equipa testar todo o conjunto de funcionalidades sem um processo de configuração demorado
Uma migração sem perdas a partir do cofre existente da equipa
Em conjunto, estes fatores resolveram os dois maiores riscos de qualquer mudança de gestor de palavras-passe: tempo de inatividade prolongado durante a implementação e perda de dados durante a migração.
A migração a partir do antigo cofre baseado em ficheiros decorreu sem problemas através da função de importação integrada do Passwork, transferindo anos de dados de credenciais acumulados sem perdas.
Resultados: Fluxo de trabalho diário mais rápido, sem sobrecarga de coordenação
O Passwork eliminou a etapa de coordenação que costumava preceder cada alteração de palavra-passe em Pegnitz. As alterações sincronizam agora com toda a equipa em tempo real, pelo que a conversa «está no cofre?» deixou de existir. A extensão do navegador reduziu o tempo despendido em inícios de sessão de rotina, e a rotação centralizada de credenciais substituiu o antigo processo manual de atualizar cópias locais uma a uma.
O ganho de segurança acompanhou o ganho de produtividade. Com as credenciais centralizadas e organizadas por funções, a equipa de TI deixou de precisar de descobrir qual a cópia local do cofre que está atualizada antes de alterar uma palavra-passe num servidor ou firewall.
A equipa de TI de Pegnitz enfrentava conflitos de fusão e uma constante coordenação verbal sempre que mais do que um administrador precisava de editar o cofre de credenciais partilhado. Resolveram o problema ao mudar para o Passwork, um cofre centralizado e self-hosted, com acesso multiutilizador em tempo real e permissões baseadas em funções.
Como resultado, a equipa eliminou por completo os conflitos de bloqueio de ficheiros e reduziu o tempo despendido na gestão de alterações de credenciais de rotina.
«O mais importante é que já não precisamos de verificar se outra pessoa está a trabalhar no cofre antes de fazer uma alteração. Podemos trabalhar em paralelo sem conflitos. Para nós, o Passwork é a solução self-hosted ideal.» — Stadt Pegnitz IT team
Stadt Pegnitz: Resolver conflitos de sincronização com o Passwork
Pegnitz, uma cidade bávara perto de Nuremberga, geria as TI municipais com um cofre baseado em ficheiros que não suportava o acesso simultâneo, obrigando os administradores a coordenar cada alteração verbalmente.
Pegnitz ist eine Industriestadt am Tor zur Fränkischen Schweiz: kompakt, wirtschaftlich stark und kulturell eigenständig. Hier leben etwa 13.600 Menschen, im Landkreis Bayreuth und in der Metropolregion Nürnberg, wo Pegnitz als wirtschaftliches Zentrum des südlichen Landkreises fungiert. Die Geschichte der Stadt reicht bis zu den früheren Bergwerken und der Pegnitzhütte zurück. Heute bilden Maschinenbau und Metallverarbeitung neben der Textilindustrie die wirtschaftliche Grundlage der Stadt.
Auch das bürgerschaftliche Leben prägt den Charakter der Stadt. Pegnitz veranstaltet Sommerkonzerte und saisonale Feste, doch das Gregori-Fest nimmt eine Sonderstellung ein: ein Kinderfest mit tausendjähriger Tradition, das in Bayern als immaterielles Kulturerbe geführt wird. Die Pegnitz-2030-Strategie der Gemeinde erweitert diesen bürgerschaftlichen Fokus auf die Wirtschafts- und Infrastrukturplanung, einschließlich Arbeitsplatzförderung, Innenstadtentwicklung und Energiewende.
Dieses Wachstum erreichte auch die IT der eigenen Verwaltung. Unter der gestiegenen Arbeitslast kam das dateibasierte System des Teams zur Zugriffsverwaltung nicht mehr hinterher, und man suchte nach einer selbst gehosteten Alternative für mehrere gleichzeitig arbeitende Administratoren.
Unternehmen: Stadt Pegnitz Standort: Bayern, Deutschland Branche: Stadtverwaltung Unternehmensgröße: 160+ Mitarbeiter
Die Herausforderung: Dateibasierte Synchronisationskonflikte bremsten ein kleines IT-Team aus
Die IT-Infrastruktur der Stadt Pegnitz wird von der IT-Abteilung der Verwaltung betreut. Vor dem Wechsel zu Passwork nutzte das Team einen dateibasierten Open-Source-Passworttresor, um Zugangsdaten für die Server, Netzwerk-Switches und Firewalls der Kommune zu speichern. Das Tool funktionierte gut als persönlicher Tresor, war aber nicht für den gleichzeitigen Zugriff mehrerer Benutzer ausgelegt – diese Einschränkung zeigte sich täglich.
Ein kleines Team, das ein gesamtes kommunales Netzwerk betreut, hat wenig Spielraum für Tools, die zusätzlichen Koordinationsaufwand verursachen. Diese Reibung veranlasste Pegnitz, nach einer Alternative zu suchen.
Die einzelne Datenbankdatei konnte nicht von mehr als einem Administrator gleichzeitig geöffnet werden, ohne einen Merge-Konflikt zu riskieren. In der Praxis bedeutete das, dass ein Administrator einen anderen fragte: „Ist gerade jemand im Tresor?", bevor er eine Änderung vornahm, um zu vermeiden, dass die Aktualisierung eines Kollegen überschrieben wird.
Die alte Lösung führte zu mehreren sich verstärkenden Problemen:
Jede Änderung erforderte eine mündliche Abstimmung, um das Überschreiben der Änderungen eines Kollegen zu vermeiden
Veraltete Datenbankkopien konnten im Umlauf bleiben, wenn jemand vergaß, die neueste Version weiterzugeben
Ohne rollenbasiertes Berechtigungsmodell war eine granulare Zugriffskontrolle nicht möglich
Jeder dateibasierte Tresor, der manuell oder über ein gemeinsames Netzlaufwerk synchronisiert wird, stößt an dieselben Grenzen, sobald mehr als eine Person Schreibzugriff benötigt. Ein Tool, das für einen einzelnen Administrator gut funktioniert, wird zum Koordinationsproblem, sobald eine zweite Person hinzukommt.
Die Lösung: Passwork erfüllte die Anforderungen von Pegnitz ohne Enterprise-Mehraufwand
Pegnitz benötigte eine zentrale, verlässliche Quelle für Infrastruktur-Zugangsdaten, ohne dateibasierte Synchronisation und ohne den Mehraufwand einer Enterprise-Lösung.
„Als kompaktes IT-Team brauchen wir Tools, die unsere Arbeit erleichtern, statt zusätzlichen Verwaltungsaufwand zu schaffen. Mit Passwork ist unsere tägliche Infrastrukturarbeit sicherer und deutlich schneller geworden." — Stadt Pegnitz IT team
Die Suche, die über IT-Foren und Open-Source-Communities erfolgte, konzentrierte sich auf vier Anforderungen, die die Oberfläche und das Bereitstellungsmodell von Passwork direkt erfüllten:
Selbst gehostetes On-Premise-Deployment, um die Zugangsdaten unter der Kontrolle der Kommune zu behalten
Clientseitige Verschlüsselung, sodass Daten den Server nie unverschlüsselt erreichen
Mehrbenutzerzugriff ohne Dateisperren
Ein angemessenes Preis-Leistungs-Verhältnis, da das Team keine Enterprise-Funktionen bezahlen wollte, die es nicht nutzen würde
Die Oberfläche von Passwork, die auf den tatsächlichen Workflow von Administratoren ausgerichtet ist und nicht auf einen für Teams nachgerüsteten Consumer-Tresor, war der Hauptgrund, warum sie sich bei der Evaluierung abhob.
Deployment und Migration: Ein schneller Rollout ohne Datenverlust
Zwei Faktoren machten die Evaluierung für Pegnitz schnell:
Docker-basiertes Deployment, mit dem das Team den vollständigen Funktionsumfang ohne aufwendigen Einrichtungsprozess testen konnte
Eine verlustfreie Migration aus dem bestehenden Tresor des Teams
Zusammen adressierten diese beiden Faktoren die größten Risiken bei jedem Wechsel des Passwortmanagers: längere Ausfallzeiten während des Rollouts und Datenverlust während des Umzugs.
Die Migration aus dem vorherigen dateibasierten Tresor verlief über die integrierte Importfunktion von Passwork reibungslos und übertrug Jahre an angesammelten Zugangsdaten ohne Verlust.
Ergebnisse: Schnellerer Arbeitsalltag, kein Koordinationsaufwand
Passwork hat den Koordinationsschritt überflüssig gemacht, der früher jeder Passwortänderung in Pegnitz vorausging. Änderungen werden jetzt in Echtzeit mit dem gesamten Team synchronisiert, sodass das Gespräch „Ist gerade jemand im Tresor?" entfällt. Die Browser-Erweiterung verkürzte die Zeit für routinemäßige Anmeldungen, und die zentrale Rotation der Zugangsdaten ersetzte den alten manuellen Prozess, bei dem lokale Kopien einzeln aktualisiert werden mussten.
Der Sicherheitsgewinn entsprach dem Produktivitätsgewinn. Da Zugangsdaten zentralisiert und rollenbasiert verwaltet werden, muss das IT-Team nicht mehr ermitteln, welche lokale Tresorkopie aktuell ist, bevor es ein Passwort auf einem Server oder einer Firewall rotiert.
Das IT-Team von Pegnitz hatte mit Merge-Konflikten und ständiger mündlicher Abstimmung zu kämpfen, sobald mehr als ein Administrator den gemeinsamen Zugangsdaten-Tresor bearbeiten musste. Gelöst wurde dies durch den Wechsel zu Passwork, einem zentralisierten, selbst gehosteten Tresor mit Echtzeit-Mehrbenutzerzugriff und rollenbasierten Berechtigungen.
Dadurch hat das Team Konflikte durch Dateisperren vollständig beseitigt und den Zeitaufwand für die Verwaltung routinemäßiger Änderungen an Zugangsdaten reduziert.
„Das Wichtigste ist: Wir müssen nicht mehr prüfen, ob jemand anderes gerade im Tresor arbeitet, bevor wir eine Änderung vornehmen. Wir können parallel arbeiten, ohne Konflikte. Für uns ist Passwork die ideale selbst gehostete Lösung." — Stadt Pegnitz IT team
Stadt Pegnitz: Dateisynchronisationskonflikte mit Passwork lösen
Pegnitz, eine bayerische Stadt bei Nürnberg, verwaltete die kommunale IT mit einem dateibasierten Tresor ohne Mehrbenutzerzugriff – jede Änderung musste mündlich abgestimmt werden. Das Team wechselte zu Passworks selbstgehosteter Plattform für Echtzeit-Zugriff mehrerer Nutzer auf Zugangsdaten.
Pegnitz es una ciudad industrial situada en la puerta de entrada a la Suiza de Franconia: de escala compacta, económicamente sólida y con una identidad cultural propia. Allí viven unos 13 600 habitantes, en el distrito de Bayreuth y la región metropolitana de Núremberg, donde Pegnitz actúa como centro económico de la zona sur del distrito. Sus orígenes se remontan a antiguas minas y a la fundición Pegnitzhütte. Hoy, la ingeniería y la metalurgia conviven con la industria textil como base económica de la ciudad.
La vida cívica define el carácter de la ciudad en la misma medida. Pegnitz acoge conciertos de verano y ferias de temporada, aunque el Gregori-Fest destaca especialmente: un festival infantil con una tradición milenaria, reconocido como patrimonio cultural inmaterial de Baviera. La estrategia municipal Pegnitz 2030 extiende este enfoque cívico a la planificación económica y de infraestructuras, incluidos el apoyo al empleo, el desarrollo del centro urbano y la transición energética.
Ese crecimiento también llegó a las operaciones de TI de la propia administración. Con una carga de trabajo mayor, el sistema basado en archivos que el equipo utilizaba para gestionar los accesos dejó de ser suficiente, por lo que empezaron a buscar una alternativa autoalojada diseñada para que varios administradores trabajaran al mismo tiempo.
Empresa: Stadt Pegnitz Ubicación: Baviera, Alemania Sector: Administración municipal Tamaño de la empresa: 160+ empleados
El reto: Los conflictos de sincronización de archivos ralentizaban a un pequeño equipo de TI
La infraestructura de TI de Stadt Pegnitz está a cargo del departamento de TI del municipio. Antes de pasar a Passwork, el equipo utilizaba una bóveda de contraseñas de código abierto basada en archivos para almacenar las credenciales de los servidores, los conmutadores de red y los cortafuegos del municipio. La herramienta funcionaba bien como bóveda personal, pero no estaba diseñada para el acceso simultáneo de varios usuarios, y esa limitación se notaba a diario.
Un equipo reducido que cubre toda la red municipal tiene poco margen para herramientas que añaden carga de coordinación. Esta fricción llevó a Pegnitz a buscar una alternativa.
El archivo de base de datos único no permitía que más de un administrador lo abriera al mismo tiempo sin arriesgarse a un conflicto de fusión. En la práctica, esto significaba que un administrador le preguntaba a otro: «¿Está en la bóveda ahora mismo?» antes de hacer cualquier cambio, para evitar sobrescribir la actualización de un compañero.
La configuración anterior generaba varios problemas que se acumulaban:
Cada modificación exigía coordinación verbal para evitar sobrescribir los cambios de un compañero
Podían circular copias desactualizadas de la base de datos si alguien olvidaba distribuir la versión más reciente
La ausencia de un modelo de permisos basado en roles impedía un control de acceso granular
Cualquier bóveda basada en archivos que se sincronice manualmente o mediante una unidad de red compartida se enfrenta a las mismas limitaciones en cuanto más de una persona necesita acceso de escritura. Una herramienta que funciona bien para un único administrador genera un problema de coordinación en cuanto se suma una segunda persona.
La solución: Passwork cumplió los requisitos de Pegnitz sin la complejidad de una solución empresarial
Pegnitz necesitaba una única fuente de verdad para las credenciales de infraestructura, sin sincronización basada en archivos y sin la complejidad de una implementación a escala empresarial.
«Como equipo de TI reducido, necesitamos herramientas que faciliten nuestro trabajo, no que añadan carga administrativa. Passwork ha hecho que nuestro trabajo diario de infraestructura sea más seguro y mucho más rápido.» — Stadt Pegnitz IT team
La búsqueda, realizada a través de foros de TI y comunidades de código abierto, se centró en cuatro requisitos que la interfaz y el modelo de implementación de Passwork cumplían directamente:
Implementación autoalojada y on-premise, para mantener los datos de credenciales bajo el control del municipio
Cifrado del lado del cliente, de modo que los datos nunca llegan al servidor sin cifrar
Acceso multiusuario sin bloqueo de archivos
Una relación precio-valor razonable, ya que el equipo no tenía interés en pagar por funciones empresariales que no iba a utilizar
La interfaz de Passwork, diseñada en torno al flujo de trabajo real de los administradores y no como una bóveda de consumo adaptada después para equipos, fue el principal motivo por el que destacó durante la evaluación.
Implementación y migración: Una puesta en marcha rápida sin pérdida de datos
Dos factores agilizaron la evaluación de Pegnitz:
Implementación basada en Docker, que permitió al equipo probar el conjunto completo de funciones sin un proceso de configuración prolongado
Una migración sin pérdida de datos desde la bóveda existente del equipo
Juntos, estos factores resolvían los dos mayores riesgos de cualquier cambio de gestor de contraseñas: el tiempo de inactividad prolongado durante la puesta en marcha y la pérdida de datos durante la migración.
La migración desde la bóveda basada en archivos anterior se realizó sin inconvenientes mediante la función de importación integrada de Passwork, conservando años de datos de credenciales acumulados sin ninguna pérdida.
Resultados: Un flujo de trabajo diario más rápido, sin carga de coordinación
Passwork eliminó el paso de coordinación que antes precede a cada modificación de contraseña en Pegnitz. Los cambios ahora se sincronizan con todo el equipo en tiempo real, por lo que la conversación «¿está en la bóveda?» ha desaparecido. La extensión del navegador redujo el tiempo dedicado a los inicios de sesión rutinarios, y la rotación centralizada de credenciales sustituyó el antiguo proceso manual de actualizar las copias locales una por una.
La mejora en seguridad estuvo a la altura de la mejora en productividad. Con las credenciales centralizadas y organizadas por roles, el equipo de TI ya no necesita averiguar qué copia local de la bóveda es la vigente antes de rotar una contraseña en un servidor o un cortafuegos.
El equipo de TI de Pegnitz se enfrentaba a conflictos de fusión y a una constante coordinación verbal cada vez que más de un administrador necesitaba modificar la bóveda de credenciales compartida. Lo resolvieron adoptando Passwork, una bóveda centralizada y autoalojada con acceso multiusuario en tiempo real y permisos basados en roles.
Como resultado, el equipo eliminó por completo los conflictos de bloqueo de archivos y redujo el tiempo dedicado a gestionar los cambios de credenciales rutinarios.
«Lo más importante es que ya no tenemos que comprobar si alguien más está trabajando en la bóveda antes de hacer un cambio. Podemos trabajar en paralelo sin conflictos. Para nosotros, Passwork es la solución autoalojada ideal.» — Stadt Pegnitz IT team
Stadt Pegnitz: Resolución de conflictos de sincronización de archivos con Passwork
Pegnitz, una localidad bávara cerca de Núremberg, gestionaba la TI municipal con una bóveda basada en archivos que no soportaba acceso concurrente, obligando a coordinar cada cambio verbalmente. El equipo migró a la plataforma autoalojada de Passwork para acceso multiusuario en tiempo real.
Pegnitz is an industrial town at the gateway to Franconian Switzerland: compact in scale, economically strong, and culturally distinct. About 13,600 people live here, in the Bayreuth district and the Nuremberg metropolitan region, where Pegnitz serves as the southern district's economic hub. Its history traces back to former mines and the Pegnitzhütte ironworks. Today engineering and metalworking sit alongside a textile industry as the town's economic base.
Civic life carries the town's character just as much. Pegnitz hosts summer concerts and seasonal fairs, though Gregori-Fest stands apart: a children's festival with a thousand-year tradition, listed as intangible cultural heritage in Bavaria. The municipality's Pegnitz 2030 strategy extends this civic focus into economic and infrastructure planning, including job support, town-center development, and the energy transition.
That growth reached the administration's own IT operations too. Under a heavier workload, the team's file-based system for managing access could no longer keep up, and they began looking for a self-hosted alternative built for multiple administrators working at the same time.
Company: Stadt Pegnitz Location: Bavaria, Germany Industry: City administration Company size: 160+ employees
The challenge: File-based sync conflicts slowed down a small IT team
Stadt Pegnitz's IT infrastructure is managed by the municipality's IT department. Before switching to Passwork, the team used an open-source, file-based password vault to store credentials for the municipality's servers, network switches, and firewalls. The tool worked well as a personal vault, but it wasn't designed for concurrent multi-user access, and that limitation showed up daily.
A small team covering an entire municipal network has little room for tools that add coordination overhead. This friction pushed Pegnitz to look for an alternative.
The single database file couldn't handle more than one administrator opening it at once without risking a merge conflict. In practice, this meant one administrator asking another, "Are you in the vault right now?" before making any change, to avoid overwriting a colleague's update.
The old setup created several compounding problems:
Every edit required verbal coordination to avoid overwriting a colleague's changes
Outdated database copies could circulate if someone forgot to redistribute the latest version
No role-based permission model meant granular access control wasn't possible
Any file-based vault synchronized manually or over a shared network drive runs into the same limits once more than one person needs write access. A tool that works well for a single administrator creates a coordination problem once a second person joins.
The solution: Passwork met Pegnitz's requirements without the enterprise overhead
Pegnitz needed a single source of truth for infrastructure credentials, without file-based sync and without the overhead of an enterprise-scale deployment.
"As a compact IT team, we need tools that make our work easier, not add administrative burden. Passwork has made our daily infrastructure work more secure and much faster." — Stadt Pegnitz IT team
The search, conducted through IT forums and open-source communities, focused on four requirements that Passwork's interface and deployment model met directly:
Self-hosted, on-premise deployment, to keep credential data under the municipality's control
Client-side encryption, so data never reaches the server unencrypted
Multi-user access with no file locking
A reasonable price-to-value ratio, since the team had no interest in paying for enterprise features it wouldn't use
Passwork's interface, built around administrators' actual workflow rather than a consumer-style vault retrofitted for teams, was the main reason it stood out during evaluation.
Deployment and migration: A fast rollout without data loss
Two factors made Pegnitz's evaluation quick:
Docker-based deployment, which let the team test the full feature set without a lengthy setup process
A lossless migration from the team's existing vault
Together, these addressed the two biggest risks in any password manager switch: extended downtime during rollout and data loss during the move.
Migration from the previous file-based vault went through cleanly using Passwork's built-in import function, carrying over years of accumulated credential data without loss.
Results: Faster daily workflow, no coordination overhead
Passwork removed the coordination step that used to precede every password edit at Pegnitz. Changes now sync to the whole team in real time, so the "are you in the vault?" conversation is gone. The browser extension cut time spent on routine logins, and centralized credential rotation replaced the old manual process of updating local copies one by one.
The security gain matched the productivity gain. With credentials centralized and role-based, the IT team no longer needs to track down which local vault copy is current before rotating a password on a server or firewall.
Pegnitz's IT team faced merge conflicts and constant verbal coordination every time more than one administrator needed to edit the shared credential vault. They solved it by moving to Passwork, a centralized, self-hosted vault with real-time multi-user access and role-based permissions.
As a result, the team eliminated file-locking conflicts entirely and cut the time spent managing routine credential changes.
"Most importantly, we no longer have to check whether someone else is working in the vault before making a change. We can work in parallel without conflicts. For us, Passwork is the ideal self-hosted solution." — Stadt Pegnitz IT team
Stadt Pegnitz: Solving file-sync conflicts with Passwork
Pegnitz, a Bavarian town near Nuremberg, ran municipal IT on a file-based vault that couldn't handle concurrent access, forcing administrators to coordinate every edit verbally. The team moved to Passwork's self-hosted platform for real-time, multi-user credential access.
Auerbach in der Oberpfalz é uma pequena cidade com 9470 habitantes na região do Alto Palatinado, na Baviera, no distrito de Amberg-Sulzbach. A cidade mantém uma história industrial ativa a par da sua histórica praça do mercado: o minério de ferro foi extraído aqui durante séculos, e esse legado continua visível no seu carácter atual. O antigo local da mina Maffei ainda tem as suas torres de extração de pé, e o local alberga atualmente um museu mineiro e um festival cultural recorrente.
Esta abordagem prática estende-se à governação local: o município obteve o estatuto de Cidade Fairtrade em 2024, renovou-o em 2026, e mantém a mesma postura orientada para a sustentabilidade e a responsabilização nas suas outras iniciativas.
A mesma lógica aplica-se à TI. Gerir infraestruturas críticas implica manter o controlo sobre os processos essenciais, incluindo a forma como as credenciais são protegidas. A equipa de administração de sistemas da Auerbach optou por uma plataforma autoalojada com cifragem zero-knowledge, combinando um controlo de acesso rigoroso com soberania total sobre os dados sensíveis.
Empresa: Auerbach in der Oberpfalz Localização: Baviera, Alemanha Setor: Administração municipal Dimensão da empresa: mais de 230 colaboradores
O desafio: A arquitetura baseada em ficheiros tornou-se um risco de segurança
Uma equipa de administradores de sistemas gere a infraestrutura de TI da Auerbach. Antes do Passwork, a equipa utilizava dois gestores de palavras-passe de código aberto, criados sobre o mesmo formato de base de dados – um baseado no navegador, o outro uma aplicação de ambiente de trabalho –, que dividiam o armazenamento das credenciais entre si.
Ambas as ferramentas assentavam numa arquitetura baseada num único ficheiro, com todas as credenciais guardadas num ficheiro cifrado partilhado pela equipa – um modelo desadequado às necessidades de acesso multiutilizador e sensível da TI municipal. Isto causava falhas de sincronização e conflitos de bloqueio de ficheiros, exigindo supervisão manual do acesso de escrita, e deixava uma lacuna maior: nenhuma permissão baseada em funções nem controlo de acesso granular.
A partilha do ficheiro do cofre através de canais inseguros criava dois riscos:
Um ficheiro de base de dados enviado por e-mail ou guardado numa unidade partilhada sem cifragem é um ponto único de falha em caso de interceção.
Sem uma fonte de verdade centralizada, cópias desatualizadas das credenciais podiam continuar em circulação, pelo que alguém poderia, sem saber, utilizar uma palavra-passe já rotacionada.
Para uma equipa de TI do setor público que gere o acesso a infraestruturas essenciais, este é o tipo de exposição que as frameworks de segurança são concebidas para prevenir.
Solução: Passwork foi ao encontro das prioridades de segurança e consistência da Auerbach
A pesquisa da Auerbach centrou-se em duas prioridades: a segurança dos dados e a consistência das credenciais numa base de dados centralizada, em vez de um conjunto de ficheiros sincronizados de forma pouco rigorosa. A interface do Passwork, concebida para administradores de sistemas e para uma colaboração estruturada em equipa, e não para uso individual de consumidor, foi a primeira razão para a considerar.
O fator decisivo para iniciar um período de teste foi a arquitetura de segurança documentada do fornecedor: a cifragem zero-knowledge que a equipa conseguiu verificar antes de se comprometer.
O que a Auerbach precisava de uma nova solução
As prioridades de segurança e consistência da Auerbach exigiam três características arquitetónicas específicas: implementação local, cifragem do lado do cliente e uma estrutura de dados capaz de escalar com a infraestrutura do município. Cada uma respondia a uma limitação específica da anterior configuração baseada em ficheiros da equipa.
Implementação autoalojada e local, para controlo total sobre dados sensíveis nos próprios servidores do município
Cifragem zero-knowledge, para eliminar a exposição de credenciais e chaves de cifragem do lado do servidor
Estrutura de cofres e pastas, para organizar o acesso por componente de infraestrutura ou sistema de cliente
A cifragem zero-knowledge significa que o servidor nunca tem acesso aos dados não cifrados nem às chaves de cifragem. Os dados são cifrados do lado do cliente antes de serem transmitidos ou armazenados. Um administrador ou atacante com acesso total ao servidor vê apenas texto cifrado. Para uma entidade do setor público que gere credenciais de infraestruturas de rede essenciais, isto elimina uma categoria inteira de risco de violação do lado do servidor.
Integração técnica
A implementação foi feita através do Docker, permitindo à equipa criar rapidamente uma instância funcional e testá-la com credenciais reais da infraestrutura, em vez de um conjunto de dados de demonstração. A migração a partir das bases de dados existentes da equipa foi feita através da interface de importação do Passwork, sem erros. A rapidez da implementação de teste e a migração sem problemas permitiram à equipa passar rapidamente da avaliação para a produção.
Resultados: De ficheiros estáticos para um sistema centralizado em tempo real
A Auerbach substituiu os seus cofres baseados em ficheiros por um sistema centralizado que se atualiza em tempo real em toda a equipa. As credenciais são agora rotacionadas e geridas com controlo de versões de forma centralizada, eliminando o risco de cópias desatualizadas das soluções anteriores. A equipa também registou poupanças de tempo graças à extensão do navegador do Passwork no trabalho diário de infraestrutura.
Aspeto
Soluções anteriores
Passwork
Modelo de armazenamento
Baseado em ficheiros, sincronizado manualmente
Base de dados centralizada, atualizada em tempo real
Controlo de acesso
Sem permissões baseadas em funções
Acesso granular baseado em funções
Cifragem
Cifragem local de ficheiros
Cifragem zero-knowledge, do lado do cliente
Partilha de credenciais
Transferência manual de ficheiros através de canais inseguros
Partilha instantânea, com registo de todos os acessos
Controlo de versões
Risco de cópias desatualizadas em circulação
Histórico completo de todas as alterações de palavras-passe
«Na administração de TI moderna, a gestão de palavras-passe não deveria ser um obstáculo. O Passwork devolveu-nos a flexibilidade e a segurança que nos faltavam com os cofres estáticos baseados em ficheiros.» — Stadt Auerbach systems administration team
A avaliação da Auerbach centrou-se numa lacuna de segurança específica: cifrar e controlar o acesso a credenciais de sistemas de infraestrutura críticos. A arquitetura de cifragem e o controlo de acesso granular tiveram tanto peso quanto a facilidade de utilização diária – a equipa precisava de um sistema suficientemente seguro para acessos sensíveis, mas suficientemente simples para ser utilizado em todo o departamento sem curva de aprendizagem.
A migração da Auerbach mostra que as ferramentas de palavras-passe baseadas num único ficheiro atingem o seu limite no ponto em que os requisitos de controlo de acesso e auditoria ultrapassam o que um ficheiro partilhado consegue oferecer. Uma equipa que gere infraestrutura municipal crítica enfrenta a mesma exposição que uma grande empresa assim que as credenciais são partilhadas sem permissões baseadas em funções ou uma fonte única de verdade. O Passwork colmatou essa lacuna para a Auerbach com uma arquitetura centralizada e zero-knowledge.
«Com o Passwork, conseguimos trabalhar em equipa sem dificuldades, manter um bom desempenho nas tarefas diárias e preservar o controlo total da nossa própria infraestrutura.» — Stadt Auerbach systems administration team
Stadt Auerbach: Segurança zero-knowledge com o Passwork
Auerbach in der Oberpfalz, uma cidade bávara com 9470 habitantes, geria a TI municipal com dois gestores de palavras-passe baseados em ficheiros, propensos a falhas de sincronização e sem controlo de acesso baseado em funções.
Auerbach in der Oberpfalz ist eine kleine Stadt mit 9.470 Einwohnern in der bayerischen Oberpfalz, im Landkreis Amberg-Sulzbach. Neben ihrem historischen Marktplatz hat die Stadt eine gewachsene Industriegeschichte: Hier wurde jahrhundertelang Eisenerz abgebaut, und dieses Erbe prägt bis heute ihren Charakter. Auf dem Gelände der ehemaligen Maffei-Grube stehen die Fördertürme noch, und dort befinden sich heute ein Bergbaumuseum und ein wiederkehrendes Kulturfestival.
Dieser pragmatische Ansatz setzt sich auch in der kommunalen Verwaltung fort: Die Gemeinde erhielt 2024 den Status einer Fairtrade-Stadt, erneuerte ihn 2026 und verfolgt denselben nachhaltigkeits- und verantwortungsorientierten Kurs auch bei ihren anderen Initiativen.
Dieselbe Logik gilt für die IT. Der Betrieb kritischer Infrastruktur bedeutet, die Kontrolle über zentrale Prozesse zu behalten – auch darüber, wie Zugangsdaten gesichert werden. Auerbachs Systemadministrationsteam entschied sich für eine selbstgehostete Plattform mit Zero-Knowledge-Verschlüsselung, die strenge Zugriffskontrolle mit voller Souveränität über sensible Daten verbindet.
Unternehmen: Auerbach in der Oberpfalz Standort: Bayern, Deutschland Branche: Stadtverwaltung Unternehmensgröße: 230+ Mitarbeiter
Die Herausforderung: Dateibasierte Architektur wurde zum Sicherheitsrisiko
Ein Team von Systemadministratoren verwaltet die IT-Infrastruktur von Auerbach. Vor Passwork setzte das Team auf zwei getrennte Open-Source-Passwortmanager mit demselben zugrunde liegenden Datenbankformat – einer browserbasiert, der andere eine Desktop-Anwendung –, wodurch sich die Speicherung der Zugangsdaten auf beide Tools verteilte.
Beide Tools setzten auf eine einzige dateibasierte Architektur, bei der alle Zugangsdaten in einer verschlüsselten Datei liegen, die im gesamten Team geteilt wird – ein Modell, das den sensiblen Mehrbenutzer-Zugriffsanforderungen der kommunalen IT nicht gerecht wird. Das führte zu Synchronisierungsfehlern und Konflikten durch Dateisperren, die eine manuelle Überwachung der Schreibrechte erforderten, und hinterließ eine größere Lücke: keine rollenbasierten Berechtigungen und keine granulare Zugriffskontrolle.
Das Teilen der Tresordatei über unsichere Kanäle schuf zwei Risiken:
Eine per E-Mail versendete oder auf einem unverschlüsselten Netzlaufwerk gespeicherte Datenbankdatei ist bei einem Abfangen ein Single Point of Failure.
Ohne eine zentrale, verbindliche Datenquelle können veraltete Kopien von Zugangsdaten im Umlauf bleiben, sodass möglicherweise unwissentlich ein bereits rotiertes Passwort verwendet wird.
Für ein IT-Team der öffentlichen Verwaltung, das den Zugriff auf zentrale Infrastruktur verwaltet, ist das genau die Art von Risiko, die Sicherheits-Frameworks verhindern sollen.
Lösung: Passwork erfüllte Auerbachs Prioritäten bei Sicherheit und Konsistenz
Bei der Suche standen für Auerbach zwei Prioritäten im Mittelpunkt: Datensicherheit und konsistente Zugangsdaten in einer zentralen Datenbank statt in lose synchronisierten Dateien. Der erste Grund, Passwork in Betracht zu ziehen, war die Benutzeroberfläche, die für Systemadministratoren und strukturierte Teamzusammenarbeit statt für die individuelle Endnutzung konzipiert ist.
Den Ausschlag für den Start einer Testphase gab die dokumentierte Sicherheitsarchitektur des Anbieters: eine Zero-Knowledge-Verschlüsselung, die das Team vor der endgültigen Entscheidung überprüfen konnte.
Was Auerbach von einer neuen Lösung brauchte
Auerbachs Prioritäten bei Sicherheit und Konsistenz erforderten drei konkrete architektonische Merkmale: eine On-Premise-Bereitstellung, eine clientseitige Verschlüsselung und eine Datenstruktur, die mit der Infrastruktur der Gemeinde mitwachsen kann. Jedes dieser Merkmale adressierte eine konkrete Einschränkung der bisherigen dateibasierten Lösung des Teams.
Selbstgehostete On-Premise-Bereitstellung für volle Kontrolle über sensible Daten auf den eigenen Servern der Gemeinde
Zero-Knowledge-Verschlüsselung, um eine serverseitige Offenlegung von Zugangsdaten und Verschlüsselungsschlüsseln auszuschließen
Tresor- und Ordnerstruktur zur Organisation des Zugriffs nach Infrastrukturkomponente oder Kundensystem
Zero-Knowledge-Verschlüsselung bedeutet, dass der Server niemals Zugriff auf unverschlüsselte Daten oder die Verschlüsselungsschlüssel hat. Daten werden clientseitig verschlüsselt, bevor sie übertragen oder gespeichert werden. Ein Administrator oder Angreifer mit vollem Serverzugriff sieht nur Chiffretext. Für eine Behörde, die Zugangsdaten für zentrale Netzwerkinfrastruktur verwaltet, entfällt dadurch eine ganze Kategorie des Risikos serverseitiger Sicherheitsvorfälle.
Technische Integration
Die Bereitstellung erfolgte über Docker, sodass das Team schnell eine funktionsfähige Instanz aufsetzen und sie mit echten Infrastruktur-Zugangsdaten statt mit einem Demo-Datensatz testen konnte. Die Migration der bestehenden Datenbanken des Teams lief fehlerfrei über die Importschnittstelle von Passwork. Die schnelle Testbereitstellung und die saubere Migration ließen das Team zügig von der Evaluierung in den produktiven Einsatz übergehen.
Ergebnisse: Von statischen Dateien zu einem zentralen Echtzeitsystem
Auerbach hat seine dateibasierten Tresore zugunsten eines zentralen Systems aufgegeben, das für das gesamte Team in Echtzeit aktualisiert wird. Zugangsdaten werden jetzt zentral rotiert und versioniert, wodurch das Risiko veralteter Kopien aus den früheren Lösungen entfällt. Das Team berichtete zudem von Zeitersparnissen durch die Browser-Erweiterung von Passwork bei der täglichen Infrastrukturarbeit.
Aspekt
Bisherige Lösungen
Passwork
Speichermodell
Dateibasiert, manuell synchronisiert
Zentrale Datenbank, in Echtzeit aktualisiert
Zugriffskontrolle
Keine rollenbasierten Berechtigungen
Granularer, rollenbasierter Zugriff
Verschlüsselung
Lokale Dateiverschlüsselung
Zero-Knowledge-Verschlüsselung, clientseitig
Weitergabe von Zugangsdaten
Manuelle Dateiübertragung über unsichere Kanäle
Sofortige Freigabe, jeder Zugriff wird protokolliert
Versionsverfolgung
Risiko veralteter Kopien im Umlauf
Vollständiger Verlauf jeder Passwortänderung
"In der modernen IT-Verwaltung darf die Passwortverwaltung keinen Engpass darstellen. Passwork hat uns die Flexibilität und Sicherheit zurückgegeben, die uns bei statischen, dateibasierten Tresoren gefehlt haben." — Systemadministrationsteam der Stadt Auerbach
Im Mittelpunkt von Auerbachs Evaluierung stand eine konkrete Sicherheitslücke: die Verschlüsselung und Zugriffskontrolle für Zugangsdaten kritischer Infrastruktursysteme. Verschlüsselungsarchitektur und granulare Zugriffskontrolle wogen ebenso schwer wie die alltägliche Benutzerfreundlichkeit – das Team brauchte ein System, das für sensible Zugriffe sicher genug, aber zugleich einfach genug war, um es abteilungsübergreifend ohne Einarbeitungszeit einzuführen.
Auerbachs Umstieg zeigt, dass einzelne dateibasierte Passwort-Tools nicht an dem Punkt an ihre Grenzen stoßen, an dem die Anforderungen an Zugriffskontrolle und Audit das übersteigen, was eine gemeinsam genutzte Datei leisten kann. Ein Team, das kritische kommunale Infrastruktur verwaltet, ist demselben Risiko ausgesetzt wie ein Großunternehmen, sobald Zugangsdaten ohne rollenbasierte Berechtigungen oder eine zentrale, verbindliche Datenquelle geteilt werden. Passwork hat diese Lücke für Auerbach mit einer zentralen Zero-Knowledge-Architektur geschlossen.
"Mit Passwork können wir nahtlos im Team arbeiten, in unseren täglichen Aufgaben eine hohe Leistung halten und die volle Kontrolle über unsere eigene Infrastruktur behalten." — Systemadministrationsteam der Stadt Auerbach
Stadt Auerbach: Zero-Knowledge-Sicherheit mit Passwork
Auerbach in der Oberpfalz, eine bayerische Stadt mit 9.470 Einwohnern, nutzte für die kommunale IT zwei dateibasierte Passwort-Manager – anfällig für Sync-Fehler, ohne Rollenkonzept. Das Team wechselte zu Passworks Zero-Knowledge-Plattform, um diese Sicherheitslücke zu schließen.
Auerbach in der Oberpfalz es una pequeña localidad de 9470 habitantes en la región bávara del Alto Palatinado, en el distrito de Amberg-Sulzbach. La ciudad combina una historia industrial activa con su histórica plaza del mercado: aquí se extrajo mineral de hierro durante siglos, y ese legado sigue siendo visible en su carácter actual. El antiguo emplazamiento de la mina Maffei todavía conserva en pie sus torres de extracción, y hoy alberga un museo minero y un festival cultural periódico.
Ese enfoque práctico se traslada también a la gestión municipal: el ayuntamiento obtuvo el estatus de Fairtrade Town en 2024, lo renovó en 2026 y mantiene la misma postura orientada a la sostenibilidad y la rendición de cuentas en el resto de sus iniciativas.
La misma lógica se aplica a la TI. Gestionar infraestructura crítica implica mantener el control sobre los procesos esenciales, incluida la forma en que se protegen las credenciales. El equipo de administración de sistemas de Auerbach eligió una plataforma autoalojada con cifrado de conocimiento cero, combinando un control de acceso estricto con soberanía total sobre los datos sensibles.
Empresa: Auerbach in der Oberpfalz Ubicación: Baviera, Alemania Sector: Administración municipal Tamaño de la empresa: 230+ empleados
El reto: La arquitectura basada en archivos se convirtió en un riesgo de seguridad
Un equipo de administradores de sistemas gestiona la infraestructura de TI de Auerbach. Antes de Passwork, el equipo utilizaba dos gestores de contraseñas de código abierto independientes, basados en el mismo formato de base de datos (uno basado en navegador y el otro una aplicación de escritorio), lo que dividía el almacenamiento de credenciales entre ambos.
Ambas herramientas se basaban en una única arquitectura de archivos, donde todas las credenciales residen en un archivo cifrado compartido por todo el equipo: un modelo poco adecuado para las necesidades de acceso multiusuario y sensible de la TI municipal. Esto provocaba fallos de sincronización y conflictos de bloqueo de archivos, lo que exigía una supervisión manual del acceso de escritura, y dejaba una brecha mayor: sin permisos basados en roles ni control de acceso granular.
Compartir el archivo de la bóveda por canales no seguros generaba dos riesgos:
Un archivo de base de datos enviado por correo electrónico o almacenado en una unidad compartida sin cifrar es un único punto de fallo si se intercepta
Sin una fuente de verdad centralizada, podían seguir circulando copias de credenciales obsoletas, de modo que alguien podía usar sin saberlo una contraseña que ya había sido rotada
Para un equipo de TI gubernamental que gestiona el acceso a infraestructura esencial, este es precisamente el tipo de exposición que los marcos de seguridad están diseñados para prevenir.
Solución: Passwork se ajustó a las prioridades de seguridad y coherencia de Auerbach
La búsqueda de Auerbach se centró en dos prioridades: la seguridad de los datos y la coherencia de las credenciales en una base de datos centralizada, en lugar de un conjunto de archivos sincronizados de forma dispersa. La interfaz de Passwork, pensada para administradores de sistemas y para la colaboración estructurada en equipo y no para el uso individual de consumo, fue la primera razón para considerarla.
El factor decisivo para iniciar una prueba fue la arquitectura de seguridad documentada del proveedor: un cifrado de conocimiento cero que el equipo podía verificar antes de comprometerse.
Lo que Auerbach necesitaba de una nueva solución
Las prioridades de seguridad y coherencia de Auerbach exigían tres características arquitectónicas específicas: implementación on-premise, cifrado del lado del cliente y una estructura de datos capaz de escalar con la infraestructura del municipio. Cada una resolvía una limitación concreta de la configuración basada en archivos que el equipo utilizaba anteriormente.
Implementación autoalojada y on-premise para un control total sobre los datos sensibles en los propios servidores del municipio
Cifrado de conocimiento cero para eliminar la exposición de credenciales y claves de cifrado en el servidor
Estructura de bóvedas y carpetas para organizar el acceso por componente de infraestructura o sistema cliente
El cifrado de conocimiento cero significa que el servidor nunca tiene acceso a los datos sin cifrar ni a las claves de cifrado. Los datos se cifran en el lado del cliente antes de transmitirse o almacenarse. Un administrador o un atacante con acceso total al servidor solo ve texto cifrado. Para un organismo del sector público que gestiona credenciales de infraestructura de red esencial, esto elimina por completo una categoría de riesgo de vulneración en el servidor.
Integración técnica
La implementación se realizó mediante Docker, lo que permitió al equipo poner en marcha una instancia funcional con rapidez y probarla con credenciales reales de infraestructura en lugar de un conjunto de datos de demostración. La migración desde las bases de datos existentes del equipo se realizó a través de la interfaz de importación de Passwork sin errores. La rápida implementación de prueba y la migración limpia permitieron al equipo pasar de la evaluación a la producción con rapidez.
Resultados: De archivos estáticos a un sistema centralizado en tiempo real
Auerbach retiró sus bóvedas basadas en archivos en favor de un sistema centralizado que se actualiza en tiempo real para todo el equipo. Las credenciales ahora se rotan y versionan de forma centralizada, lo que elimina el riesgo de copias obsoletas de las soluciones anteriores. El equipo también señaló ahorros de tiempo gracias a la extensión de navegador de Passwork en el trabajo diario de infraestructura.
Aspecto
Soluciones anteriores
Passwork
Modelo de almacenamiento
Basado en archivos, sincronización manual
Base de datos centralizada, actualizada en tiempo real
Control de acceso
Sin permisos basados en roles
Acceso granular basado en roles
Cifrado
Cifrado local de archivos
Cifrado de conocimiento cero del lado del cliente
Uso compartido de credenciales
Transferencia manual de archivos por canales no seguros
Uso compartido instantáneo, con cada acceso registrado
Control de versiones
Riesgo de copias obsoletas en circulación
Historial completo de cada cambio de contraseña
«En la administración de TI moderna, la gestión de contraseñas no debería ser un cuello de botella. Passwork nos devolvió la flexibilidad y la seguridad que nos faltaban con las bóvedas estáticas basadas en archivos.» — Stadt Auerbach systems administration team
La evaluación de Auerbach se centró en una brecha de seguridad concreta: cifrar y controlar el acceso a las credenciales de los sistemas de infraestructura crítica. La arquitectura de cifrado y el control de acceso granular tuvieron el mismo peso que la usabilidad diaria: el equipo necesitaba un sistema lo bastante seguro para el acceso sensible, pero lo bastante sencillo para implantarlo en todo el departamento sin curva de aprendizaje.
La migración de Auerbach demuestra que las herramientas de contraseñas basadas en un único archivo alcanzan su límite en el momento en que los requisitos de control de acceso y auditoría superan lo que un archivo compartido puede ofrecer. Un equipo que gestiona infraestructura municipal crítica se enfrenta a la misma exposición que una gran empresa en cuanto las credenciales se comparten sin permisos basados en roles ni una única fuente de verdad. Passwork cerró esa brecha para Auerbach con una arquitectura centralizada de conocimiento cero.
«Con Passwork, podemos trabajar sin problemas en equipo, mantener un buen rendimiento en nuestras tareas diarias y conservar el control total dentro de nuestra propia infraestructura.» — Stadt Auerbach systems administration team
Stadt Auerbach: Seguridad de conocimiento cero con Passwork
Auerbach in der Oberpfalz, una localidad bávara de 9470 habitantes, gestionaba su TI municipal con dos gestores de contraseñas basados en archivos, propensos a fallos de sincronización y sin control de acceso basado en roles. Passwork cerró esa brecha con su plataforma de conocimiento cero.
Auerbach in der Oberpfalz is a small town of 9,470 residents in Bavaria's Upper Palatinate region, in the Amberg-Sulzbach district. The town carries a working, industrial history alongside its historic market square: iron ore was mined here for centuries, and that legacy is still visible in its character today. The former Maffei mine site still has its winding towers standing, and the site now hosts a mining museum and a recurring cultural festival.
The practical approach carries over into local governance: the municipality earned Fairtrade Town status in 2024, renewed it in 2026, and takes the same sustainability-minded, accountability-driven stance across its other initiatives.
The same logic applies to IT. Managing critical infrastructure means retaining control over core processes, including how credentials are secured. Auerbach's system administration team chose a self-hosted platform with zero-knowledge encryption, combining strict access control with full sovereignty over sensitive data.
Company: Auerbach in der Oberpfalz Location: Bavaria, Germany Industry: City administration Company size: 230+ employees
The challenge: File-based architecture became a security liability
A team of system administrators manages Auerbach's IT infrastructure. Before Passwork, the team relied on two separate open-source password managers built on the same underlying database format — one browser-based, the other a desktop application — splitting credential storage between them.
Both tools relied on a single file-based architecture, where all credentials live in one encrypted file shared across the team — a model unsuited to the sensitive, multi-user access needs of municipal IT. This caused sync failures and file-locking conflicts, requiring manual oversight of write access, and left a bigger gap: no role-based permissions and no granular access control.
Sharing the vault file over insecure channels created two risks:
A database file sent by email or stored on an unencrypted shared drive is a single point of failure if intercepted.
Without a centralized source of truth, outdated credential copies could stay in circulation, so someone might unknowingly use a password that had already been rotated.
For a government IT team managing access to core infrastructure, this is the kind of exposure that security frameworks are designed to prevent.
Solution: Passwork matched Auerbach's security and consistency priorities
Auerbach's search centered on two priorities: data security and credential consistency across a centralized database, rather than a set of loosely synced files. Passwork's interface, designed for system administrators and structured team collaboration rather than individual consumer use, was the first reason to consider it.
The deciding factor for starting a trial was the vendor's documented security architecture: zero-knowledge encryption that the team could verify before committing.
What Auerbach needed from a new solution
Auerbach's security and consistency priorities required three specific architectural features: on-premise deployment, client-side encryption, and a data structure that could scale with the municipality's infrastructure. Each addressed a specific limitation of the team's previous file-based setup.
Self-hosted, on-premise deployment for full control over sensitive data on the municipality's own servers
Zero-knowledge encryption to eliminate server-side exposure of credentials and encryption keys
Vault and folder structure to organize access by infrastructure component or client system
Zero-knowledge encryption means the server never has access to unencrypted data or the encryption keys. Data is encrypted client-side before it is transmitted or stored. An administrator or attacker with full server access sees only ciphertext. For a public sector body handling credentials to core network infrastructure, this removes an entire category of server-side breach risk.
Technical integration
Deployment ran through Docker, letting the team stand up a working instance quickly and test it against real infrastructure credentials instead of a demo dataset. Migration from the team's existing databases went through Passwork's import interface without errors. The fast test deployment and clean migration let the team move from evaluation to production quickly.
Results: From static files to a real-time, centralized system
Auerbach retired its file-based vaults for a centralized system that updates in real time across the team. Credentials are now rotated and versioned centrally, removing the stale-copy risk of the previous solutions. The team also reported time savings from Passwork's browser extension in daily infrastructure work.
Aspect
Previous solutions
Passwork
Storage model
File-based, manually synced
Centralized database, updated in real time
Access control
No role-based permissions
Granular, role-based access
Encryption
Local file encryption
Zero-knowledge, client-side encryption
Credential sharing
Manual file transfer over insecure channels
Instant sharing, with every access logged
Version tracking
Risk of outdated copies in circulation
Full history of every password change
"In modern IT administration, password management shouldn’t be a bottleneck. Passwork gave us back the flexibility and security we were missing with static file-based vaults." — Stadt Auerbach systems administration team
Auerbach's evaluation centered on a specific security gap: encrypting and controlling access to credentials for critical infrastructure systems. Encryption architecture and granular access control carried equal weight with daily usability — the team needed a system secure enough for sensitive access, but simple enough to run department-wide without a learning curve.
Auerbach's migration shows that single file-based password tools reach their limit not at the point where access control and audit requirements outgrow what a shared file can provide. A team managing critical municipal infrastructure faces the same exposure as a large enterprise once credentials are shared without role-based permissions or a single source of truth. Passwork closed that gap for Auerbach with a centralized, zero-knowledge architecture.
"With Passwork, we can work seamlessly as a team, keep strong performance in our daily tasks, and maintain full control within our own infrastructure." — Stadt Auerbach systems administration team
Stadt Auerbach: Zero-knowledge security with Passwork
Auerbach in der Oberpfalz, a Bavarian town of 9,470 residents, ran municipal IT on two file-based password managers prone to sync failures and with no role-based access control. The team moved to Passwork's zero-knowledge platform to close that security gap.
Os gestores de palavras-passe empresariais anunciam frequentemente a cifragem AES-256 e servidores que nunca veem as palavras-passe em texto não cifrado. No entanto, a força do algoritmo, por si só, não revela a quantidade de dados que uma única chave comprometida ou uma associação incorreta a um grupo pode expor.
Essa exposição depende do limite de cifragem: se uma chave desbloqueia uma organização, um cofre, uma pasta partilhada ou um segredo individual. Esta comparação analisa onde o Passwork, o Bitwarden, o Passbolt, o 1Password e o Keeper traçam esse limite, e o que os respetivos modelos significam para as permissões, o início de sessão por diretório, a automatização e a implementação.
A pergunta que revela o limite de cifragem
Imagine um gestor de palavras-passe autoalojado. Um administrador de sistemas responsável pelas cópias de segurança tem uma cópia da base de dados e junta-se à organização da empresa para aceder a uma palavra-passe partilhada. Que mais poderia decifrar com as chaves disponíveis na sua conta?
O Bitwarden cifra os itens da empresa com chaves por item, envolvidas por uma única chave simétrica da organização, de acordo com o seu white paper de segurança. Os membros da organização recebem acesso utilizável a essa chave, enquanto as coleções controlam o acesso e as permissões normais fornecidos pelo servidor, em vez de criarem limites criptográficos distintos. Num modelo de ameaça autoalojado, um atacante que obtenha os textos cifrados relevantes da base de dados e a chave de organização utilizável de um membro poderia decifrar itens da organização fora das coleções atribuídas a esse membro.
O Passwork, com a cifragem no lado do cliente ativada, utiliza uma chave distinta para cada cofre. As chaves dos itens situam-se sob as chaves dos cofres, e os utilizadores recebem uma chave de cofre envolvida apenas para os cofres a que têm acesso. Neste modelo de cifragem zero-knowledge, o mesmo administrador de sistemas consegue decifrar os cofres que lhe foram atribuídos, mas não cofres de Finanças ou Infraestrutura sem relação com a sua função.
O Passbolt cifra cada segredo separadamente para cada destinatário utilizando OpenPGP, conforme descrito na sua documentação de segurança (Pro v5.4, agosto de 2025). Não existe uma chave de contentor partilhada. Os utilizadores só conseguem decifrar os segredos cifrados para si, embora adicionar destinatários exija mais trabalho.
O 1Password isola os dados por cofre, onde as permissões também são definidas. O Keeper utiliza chaves de registo e chaves de pasta partilhada, em vez de uma única chave ao nível da organização. Nenhum dos dois oferece uma base de dados de cofre autoalojada para este teste em particular.
Aspeto
Passwork
Bitwarden
Passbolt
1Password
Keeper
Limite de cifragem
Cofre
Organização
Segredo individual
Cofre
Pasta partilhada e registo
A base de dados mais a chave do membro desbloqueia
Cofres atribuídos
Registos da empresa sob a chave da organização
Segredos partilhados com esse membro
Não aplicável: cofre na nuvem
Não aplicável: cofre na nuvem
Exposição a partir de um membro comprometido com acesso à base de dados
Cofres atribuídos
Organização
Segredos atribuídos
Não diretamente comparável
Não diretamente comparável
O Passwork e o Passbolt limitam o que uma cópia da base de dados, associada às chaves de um membro, pode revelar. O Bitwarden simplifica a distribuição de chaves, mas transforma a chave da organização num limite criptográfico mais amplo. Os produtos apenas na nuvem evitam este cenário específico de acesso à base de dados, embora a respetiva arquitetura de chaves continue a ser relevante.
Tipos de cofre: Governação acima dos cofres individuais
No Passwork, um tipo de cofre define quem pode criar cofres numa determinada classe e quais os administradores atribuídos automaticamente aos novos cofres desse tipo. Com a cifragem no lado do cliente ativada, esses administradores também recebem cópias envolvidas das novas chaves de cofre. O resultado é uma política repetível para departamentos e projetos.
Por exemplo, um tipo Finanças pode atribuir automaticamente o diretor financeiro a cada novo cofre financeiro. Um tipo DevOps pode manter os administradores de infraestrutura separados das vendas. Quando o responsável de um departamento sai, a empresa pode reatribuir o administrador do tipo e rever as concessões de acesso dentro dessa área, em vez de auditar uma função de administrador global dispersa. Isto torna-se útil à medida que o número de equipas e de cofres aumenta. Consulte as políticas de cofres do Passwork.
Dois tipos incorporados dispensam administradores da empresa. Um cofre pessoal pertence a um único utilizador. Um cofre privado partilhado permite que esse utilizador convide outras pessoas. Por predefinição, nem o Proprietário nem o Administrador da organização conseguem ler o respetivo conteúdo. Os administradores podem configurar quem tem permissão para criar estes tipos de cofre e partilhar informação a partir deles, incluindo desativar a criação não gerida de cofres pessoais.
Existem dois limites: atribuir um tipo não concede acesso retroativo a cofres já existentes, e os tipos só formam limites criptográficos quando a cifragem no lado do cliente está ativada. Caso contrário, permanecem apenas regras de governação.
Os concorrentes oferecem funcionalidades relacionadas, mas não a mesma camada de política. As políticas empresariais do Bitwarden regem aspetos como a autenticação, a recuperação e a pertença à organização, em vez de atribuírem automaticamente administradores por classe de cofre. O Passbolt não tem um contentor de cofre para classificar. O 1Password oferece isolamento ao nível do cofre e cofres pessoais, mas nenhuma regra equivalente à escala da classe para cofres recém-criados. As pastas partilhadas e as equipas do Keeper gerem o acesso sem políticas de criação de cofres por tipo.
Funcionalidade
Passwork
Bitwarden
Passbolt
1Password
Keeper
Classes de cofre com administradores atribuídos
Sim
Não
Não
Não
Não
Associar automaticamente administradores a novos cofres de uma classe
Sim
Não
Não
Não
Não
Controlar quem cria uma classe
Por tipo
Parcialmente, através de política da organização
Não
Não
Não
Espaço pessoal sem administrador da empresa
Cofres pessoais e privados partilhados
My Items
Partilha por segredo individual
Cofre pessoal
Pasta pessoal
Controlar a partilha a partir de cofres pessoais por classe
Sim
Sem equivalente
Sem equivalente
Sem equivalente
Sem equivalente
Os tipos de cofre reduzem a probabilidade de os cofres departamentais recém-criados receberem uma administração inconsistente. Acrescentam uma decisão de política antecipada, mas reduzem a configuração manual repetida mais tarde.
Permissões de pasta: Herança ou modelos?
Uma árvore de pastas só é útil se as respetivas permissões se comportarem conforme os administradores esperam. Interfaces com um aspeto semelhante podem aplicar regras muito diferentes.
O Passwork oferece cinco níveis de permissão (leitura, escrita, gestão, administração e proibido) para utilizadores e grupos ao nível do cofre ou da pasta. O acesso ao cofre propaga-se para as pastas aninhadas, enquanto as regras de pasta podem restringir o acesso. Os direitos de administração e de proibição não podem ser substituídos em níveis inferiores. Quando se aplicam várias regras, prevalece o nível de prioridade mais alta. É importante notar que uma pasta não constitui um limite de cifragem distinto: o acesso ao seu conteúdo continua a depender da chave do cofre. Isto está alinhado com o modelo de controlo de acesso baseado em funções do Passwork.
O Bitwarden concede permissões através de coleções. As coleções aninhadas são etiquetas organizacionais; não herdam os itens nem os direitos da coleção principal. As pastas pessoais não têm permissões de partilha. As permissões individuais de um membro sobrepõem-se às permissões de grupo.
O Passbolt utiliza as pastas como modelos de permissões. Quando um item é criado, movido ou partilhado, aplicam-se as permissões da pasta, mas são as permissões próprias do item que determinam o acesso subsequente. Um criador pode tornar-se proprietário de uma palavra-passe e restringir o acesso mesmo quando outra pessoa é proprietária da pasta. Numa discussão da comunidade em julho de 2026 sobre a extensão v5.14.2, o Passbolt confirmou que este comportamento segue o seu modelo de permissões e referiu que estava planeada uma alteração na interface para impedir que não proprietários editassem permissões durante a criação.
O 1Password não tem pastas com permissões próprias dentro de um cofre; as etiquetas organizam os itens sem alterar o acesso. Por isso, partilhar permanentemente um subconjunto de itens exige outro cofre. Os grupos aninhados do fornecedor de identidade não são suportados para a pertença a cofres, de acordo com uma resposta da comunidade de setembro de 2026.
O Keeper suporta pastas partilhadas aninhadas e permissões ao nível do registo. As atribuições explícitas de registos sobrepõem-se aos direitos de pasta herdados. O seu modelo de pastas aninhadas tem um limite de profundidade de cinco níveis e esteve protegido por uma feature flag na versão 18.0.0 do cofre.
Aspeto
Passwork
Bitwarden
Passbolt
1Password
Keeper
Estrutura interna
Árvore de pastas
Coleções
Pastas de modelo de permissões
Etiquetas
Pastas partilhadas aninhadas
Direitos herdados
Sim, com restrições
Não
Não; as permissões são aplicadas na criação ou na movimentação
Não aplicável
Sim, cinco níveis, feature flag
Níveis de permissão
Leitura, escrita, gestão, administração, proibido
Visualizar, oculto, editar, gerir
Leitura, atualização, proprietário
Visualizar, criar, editar, arquivar, eliminar, gerir
Permissões de pasta e de registo
Partilha individual de registos
Atalhos e caixa de entrada
Item em várias coleções
Concessão direta de item
Sem concessão permanente ao nível do item
Sim
A árvore do Passwork suporta estruturas departamentais e exceções. O Bitwarden e o 1Password são mais simples de administrar, mas menos flexíveis para acessos profundamente aninhados. O comportamento de modelo do Passbolt exige atenção especial, porque as permissões de pasta e de item podem divergir.
Grupos: O que muda quando alguém se junta?
Com a cifragem no lado do cliente do Passwork, adicionar alguém a um grupo não lhe concede automaticamente todas as chaves de cofre associadas a esse grupo. É criado, antes, um pedido pendente para cada cofre relevante. Um detentor da chave tem de aprovar o pedido antes de o novo membro conseguir decifrar o respetivo conteúdo.
Isto separa o aprovisionamento de diretório do acesso criptográfico. A sincronização LDAP pode colocar um novo colaborador em grupos, mas o acesso a cofres sensíveis continua a exigir aprovação. Esta distinção é relevante durante a integração e a saída de colaboradores.
Para equipas que necessitam de menos aprovação manual, o Passwork oferece outro padrão: colocar os dados do departamento num único cofre e organizá-los em pastas. Aprova-se a chave de cofre do utilizador uma única vez; as permissões de pasta determinam depois o acesso dentro desse cofre à medida que a pertença aos grupos muda. A contrapartida é um limite criptográfico partilhado mais amplo do que vários cofres separados.
O Passbolt não pode utilizar este atalho. Como cada segredo é cifrado para cada destinatário, adicionar um membro ao grupo exige que alguém com acesso recifre os segredos relevantes para esse utilizador. A sincronização de diretório notifica um gestor de grupo e aguarda por este passo. O trabalho escala com o número de segredos, e não com o número de cofres.
O Bitwarden já distribui a chave da organização aos membros, pelo que as atribuições de coleções não exigem novas chaves de cifragem. No 1Password, as chaves de cofre atribuídas acompanham o acesso de grupo. O Keeper distribui o acesso através de pastas partilhadas atribuídas.
Aspeto
Passwork
Passbolt
Bitwarden
1Password
Keeper
A pertença a um grupo fornece automaticamente novas chaves de decifragem
Não; aprovação por cofre
Não; recifragem por segredo
Chave da organização já detida
Chaves de cofre atribuídas
Chaves de pasta partilhada atribuídas
A sincronização de diretório completa o acesso sem intervenção humana
Não, para novas chaves de cofre
Não
Sim
Sim
Sim
Principal custo de adicionar um membro
Chave envolvida por cofre
Recifragem por segredo
Atualização de pertença
Chaves para os cofres atribuídos
Chaves para as pastas atribuídas
Aprovação ao nível do contentor
Sim
Não
Pertença à organização
Cofre
Pasta partilhada
A escolha está entre pontos de aprovação mais rigorosos e um aprovisionamento mais fluido. O Passwork permite que as organizações escolham equilíbrios diferentes para departamentos diferentes; o Passbolt oferece um controlo de acesso granular por segredo, a um custo de partilha mais elevado.
O que o início de sessão por domínio realmente faz
Uma palavra-passe de domínio autentica um utilizador; não decifra os dados do cofre em nenhum destes produtos. As diferenças residem na forma como a autenticação e o aprovisionamento por diretório funcionam.
Passwork Self-hosted autentica-se diretamente junto do LDAP ou do Active Directory, incluindo ambientes com vários controladores de domínio. Os utilizadores iniciam sessão com credenciais de domínio; os grupos de diretório podem ser associados a grupos do Passwork. Com a cifragem no lado do cliente ativada, a palavra-passe de domínio autentica a sessão, enquanto chaves criptográficas distintas protegem o conteúdo dos cofres.
O Passwork Cloud ainda não oferecia LDAP à data desta comparação; estava previsto no roteiro, juntamente com o aprovisionamento SCIM. Ambas as implementações do Passwork suportam SSO SAML 2.0.
O Bitwarden Directory Connector sincroniza utilizadores e grupos, mas não os autentica junto do LDAP, conforme explica a sua documentação. O início de sessão baseado em domínio exige SSO Enterprise através de SAML ou OIDC. Em condições normais, os utilizadores continuam a desbloquear o cofre com uma palavra-passe mestra, a menos que estejam configurados dispositivos fidedignos ou o Key Connector.
O Passbolt também separa a sincronização LDAP do início de sessão. Os utilizadores autenticam-se com uma chave privada e uma frase-passe, ou através de SSO, e adicionar utilizadores sincronizados a grupos com segredos existentes exige recifragem.
O 1Password e o Keeper utilizam serviços de cofre baseados na nuvem, com integração SSO. O SSO Connect On-Prem do Keeper pode manter determinados componentes de identidade no hardware da empresa, mas o seu backend de cofre cifrado permanece na nuvem do Keeper. O Keeper lista os componentes locais suportados na sua documentação de implementação.
Aspeto
Passwork
Bitwarden
Passbolt
1Password
Keeper
Início de sessão direto com palavra-passe de domínio
LDAP/AD autoalojado
Não; SSO
Não; chave/frase-passe ou SSO
SSO
SSO
Vários controladores de domínio
Sim
Apenas sincronização
Apenas sincronização
Não aplicável
AD Bridge
Protocolo SSO documentado
SAML 2.0
SAML 2.0 ou OIDC
OpenID Connect (OIDC)
OpenID Connect (OIDC)
SAML 2.0
Aprovisionamento SCIM
Previsto
Sim
Sim
Sim
Sim
A palavra-passe de domínio decifra registos
Não
Não
Não
Não
Não
O início de sessão direto por LDAP do Passwork pode simplificar implementações autoalojadas sem um fornecedor de identidade separado. Os concorrentes orientados para a nuvem oferecem atualmente um aprovisionamento automatizado de identidade mais maduro; as funcionalidades previstas do Passwork não devem ser consideradas disponíveis atualmente.
Uma única API para palavras-passe e segredos de máquina
O Passwork gere as credenciais dos colaboradores e os segredos de máquina através da mesma instância, do mesmo modelo de permissões, do mesmo registo de auditoria e da mesma API REST. As equipas podem suportar fluxos de trabalho de CI/CD sem licenciar um produto de segredos separado.
Os seus clientes Web, de ambiente de trabalho, de navegador e móvel utilizam a mesma API em /api/v1. Uma CLI oficial e um conector Python de código aberto suportam fluxos de trabalho de DevOps. A CLI disponibiliza get e update para registos, api para chamadas diretas a endpoints, e exec para obter e decifrar um segredo, expor os valores como variáveis de ambiente e executar um comando. As contas de serviço são utilizadores com tokens de API criados por um administrador. Gerar um novo token pessoal revoga as sessões de API anteriores do utilizador.
Este modelo unificado tem limitações: a API é baseada em pull, sem webhooks de saída, e o /v1/batch suporta apenas agregação de leitura, até 25 subpedidos GET. As integrações orientadas por eventos têm de efetuar polling ou consumir exportações de syslog.
Os concorrentes seguem abordagens diferentes. O Bitwarden Secrets Manager é um add-on pago separado, com contas de máquina e acesso baseado em projetos, em vez de acesso através das coleções do Password Manager. O Keeper Secrets Manager é outra linha de produtos, com SDKs e uma gateway ligada à nuvem. As contas de serviço do 1Password funcionam com cofres e permissões definidos, mas o respetivo âmbito é fixado no momento da criação do token; alterá-lo exige um novo token. O Passbolt expõe uma API e ferramentas de automatização, mantendo o seu modelo de partilha por segredo.
Aspeto
Passwork
Bitwarden
Passbolt
1Password
Keeper
Segredos de colaboradores e de máquina
Uma única instância
Password Manager mais Secrets Manager
Um único produto
Cofres mais contas de serviço
Cofre mais Secrets Manager
Interface de automatização
API REST, CLI, conector Python
Management API e CLI/SDKs do Secrets Manager
API REST, CLI de administração
CLI, SDKs, Connect
SDKs, Commander
Identidade de máquina
Conta de serviço com token
Conta de máquina com âmbito de projeto
Utilizador com chave privada
Conta de serviço com âmbito fixo
Aplicação do Secrets Manager
Principal limitação
Sem webhooks; lote só de leitura
Subscrição de segredos separada
Sobrecarga de partilha por segredo
Âmbito do token imutável
Produto de segredos separado
O Passwork privilegia um único sistema operacional para pessoas e automatização. Os produtos especializados em segredos podem oferecer integrações dedicadas, mas introduzem superfícies adicionais de licenciamento e gestão.
Onde o cofre é executado
A implementação pode eliminar produtos de uma lista restrita ainda antes de qualquer comparação de funcionalidades. O Passwork, o Bitwarden e o Passbolt permitem que as organizações alojem o próprio cofre. O 1Password e o Keeper mantêm o backend do cofre nos respetivos serviços na nuvem.
O Passwork suporta implementação local (on-premise) em Linux, Windows Server ou Docker, dando às organizações controlo sobre a sua infraestrutura e cópias de segurança. A sua oferta de nuvem alojada na UE utiliza uma base de dados e um tenant separados para cada cliente, em vez de armazenar os registos de todos os clientes num único esquema partilhado. Estas opções são discutidas no guia de modelos de implementação do Passwork.
O Bitwarden também oferece autoalojamento genuíno, embora a sua licença Enterprise continue associada a uma subscrição ativa na nuvem. O Passbolt suporta tanto o autoalojamento como um serviço alojado. Os componentes de SSO e de integração do Keeper, passíveis de implementação local, não alteram a localização do respetivo backend de cofre.
Aspeto
Passwork
Bitwarden
Passbolt
1Password
Keeper
Cofre autoalojado
Sim
Sim
Sim
Não
Não
Nuvem do fornecedor
UE
Sim
Sim
Sim
Sim
Modelo de tenant na nuvem
Base de dados separada por tenant
Multi-tenant
Dedicado por subscrição
Multi-tenant
Multi-tenant
O autoalojamento dá às organizações controlo sobre a localização dos dados, mas também a responsabilidade pelas atualizações, pelas cópias de segurança e pela disponibilidade. Os produtos apenas na nuvem reduzem essa carga de trabalho, desde que a política permita o alojamento externo.
Cifragem opcional no lado do cliente e metadados
O Passwork Cloud utiliza sempre a cifragem no lado do cliente. O Passwork Self-hosted permite que os administradores a desativem. Os outros quatro produtos desta comparação não oferecem um controlo equivalente.
A cifragem no lado do servidor pode ser adequada para uma equipa pequena, com administradores de confiança, que privilegie a concessão imediata de acesso e uma recuperação mais simples. Desativar a cifragem no lado do cliente elimina o isolamento criptográfico por cofre: os tipos de cofre continuam a controlar a criação e a administração, mas deixam de formar limites de cifragem distintos.
Mesmo com a cifragem no lado do cliente ativada, o servidor do Passwork consegue ler nomes de itens, logins, descrições e URLs, para suportar a pesquisa no lado do servidor. Os valores das palavras-passe permanecem cifrados no cliente e fora do índice de pesquisa. O Bitwarden e o Keeper também cifram estes campos de metadados, mantendo-os ocultos do servidor, ao custo de uma decifragem no lado do cliente para a pesquisa. O Passbolt v5 deixa os nomes de pasta e as etiquetas sem cifragem.
Aspeto
Passwork
Bitwarden
Passbolt
1Password
Keeper
Desativar a cifragem no lado do cliente
Apenas autoalojado
Não
Não
Não
Não
Metadados visíveis pelo servidor com a cifragem no lado do cliente ativada
Nome, login, descrição, URL
Nenhum destes campos
Nomes de pasta e etiquetas
Nenhum destes campos
Nenhum destes campos
Pesquisa
Servidor
Cliente
Cliente
Cliente
Cliente
Trata-se de uma contrapartida real entre segurança e usabilidade. Os compradores devem avaliar tanto a confidencialidade das palavras-passe como a exposição de metadados, especialmente quando os registos contêm nomes de sistemas sensíveis ou identificadores de conta.
Quanto custa
Estes são os preços de tabela publicados por utilizador, por mês, com faturação anual, a partir de outubro de 2026. Os fornecedores utilizam moedas e pacotes diferentes, pelo que a comparação é apenas indicativa.
O Passwork Padrão custa 3 € e o Avançado 4,50 € por utilizador, por mês. O Avançado inclui gestão de segredos e funcionalidades de identidade empresarial. Os clientes autoalojados também podem optar por uma licença vitalícia paga uma única vez. O Bitwarden Teams custa 4 $ e o Enterprise 6 $, com o Secrets Manager cobrado separadamente a 6 $ e 12 $, respetivamente. O Keeper Business parte de 4 $ e o Enterprise de 6 $, enquanto o KeeperPAM é cobrado separadamente. O 1Password Business custa 8,99 $. O Passbolt Pro autoalojado custa 4,50 € com um mínimo de dez utilizadores.
Produto
Preço/utilizador/mês
Condição relevante
Passwork Padrão
3 €
Nuvem ou autoalojado
Passwork Avançado
4,50 €
SSO, mapeamento LDAP, segredos, clustering; opção de licença vitalícia autoalojada
Bitwarden Teams
4 $
Password Manager
Bitwarden Enterprise
6 $
SSO, políticas, autoalojamento; Secrets Manager à parte
Keeper Business
4 €
Alguns relatórios e funcionalidades de monitorização exigem um nível superior
Keeper Enterprise
6 €
PAM vendido separadamente
1Password Business
8,99 $
Cofre na nuvem
Passbolt Pro
4,50 €
Autoalojado; mínimo de dez utilizadores
O Bitwarden Secrets Manager custa 6 $ por utilizador, por mês, no Teams, ou 12 $ no Enterprise, cobrado separadamente do Password Manager. As organizações que utilizam ambos os produtos devem comparar os custos de licenciamento combinados com base no número de utilizadores em cada um. O Passwork Avançado inclui a gestão de palavras-passe e de segredos numa única subscrição. O modelo de cifragem por segredo do Passbolt acrescenta trabalho administrativo ao partilhar segredos ou ao adicionar membros a grupos, um custo que os preços de subscrição, por si só, não conseguem captar.
Onde os concorrentes levam vantagem
O Passbolt oferece partilha e revogação diretas por segredo. Cada destinatário recebe um texto cifrado com a respetiva chave pública. A revogação remove do serviço a cópia cifrada desse destinatário. Isto permite um controlo granular, mas cada destinatário adicional exige trabalho de cifragem e de armazenamento. Tal como noutros gestores de palavras-passe, a revogação não consegue apagar o texto não cifrado nem as cópias que um destinatário já tenha guardado.
O Passwork armazena um único texto cifrado partilhado e distribui chaves envolvidas, em vez de duplicar cada segredo para cada destinatário. Remover uma concessão permanente de cofre ou de pasta remove o acesso à chave correspondente. A sua caixa de entrada funciona de forma diferente: uma entrega direta entre utilizadores envolve a chave de um item para o destinatário, e um item aceite torna-se uma cópia no cofre do destinatário. A entrega por caixa de entrada de grupo utiliza um percurso sem cifragem no lado do cliente. A caixa de entrada é, portanto, uma transferência, e não uma concessão permanentemente revogável.
Aspeto
Passwork
Passbolt
Dados armazenados por destinatário
Um texto cifrado partilhado, chaves envolvidas
Texto cifrado por destinatário
Partilhar
Envolver uma chave
Recifrar o segredo
Revogar acesso contínuo
Remover o acesso à chave envolvida
Remover a cópia cifrada do destinatário
Entrega pontual
A caixa de entrada cria uma cópia pertencente ao destinatário após aceitação
Partilha direta de item
O Bitwarden e o Keeper protegem metadados que o Passwork expõe para a pesquisa no lado do servidor. O Keeper também oferece atalhos de registo e permissões diretas por registo em pastas partilhadas, além de uma plataforma mais ampla de acesso privilegiado. O 1Password tem menos regras de herança e exceções, o que facilita a configuração para equipas que não necessitam de permissões de pasta complexas. O Bitwarden combina um preço de entrada baixo, autoalojamento e clientes consolidados.
Estas são vantagens substanciais. A flexibilidade do Passwork ajuda organizações com estruturas de acesso complexas, mas também cria mais políticas para conceber e manter.
Como escolher: Comece pelo limite
Comece pelo cenário de falha, e não pelo algoritmo de cifragem. Se uma conta for comprometida, que registos conseguem as suas chaves decifrar? O que muda se o atacante também obtiver uma cópia de segurança da base de dados? Depois, verifique se o modelo de permissões reflete os limites departamentais e se a integração de colaboradores pode expandir o acesso por acidente.
O Passwork é adequado a organizações que necessitem de cofres departamentais separados, permissões de pasta herdadas, autenticação LDAP direta on-premise, e credenciais de colaboradores e de máquina num único sistema. O Passbolt favorece o controlo por segredo nos casos em que o custo administrativo da partilha é aceitável. O Bitwarden oferece uma distribuição de chaves simples, à escala da organização, e autoalojamento. O 1Password minimiza a complexidade de configuração num modelo centrado na nuvem. O Keeper combina controlos de pasta partilhada com uma oferta mais ampla de acesso privilegiado.
Se Finanças, Recursos Humanos e Infraestrutura forem unidades operacionais separadas, decida se também devem ter limites criptográficos separados. Essa decisão determina a potencial exposição de uma única chave comprometida de forma mais direta do que um rótulo AES-256.
O que é um limite de cifragem num gestor de palavras-passe?
É a quantidade de dados acessível com uma determinada chave ou conjunto de chaves: uma organização, um cofre, uma pasta partilhada ou um segredo individual. A hierarquia de chaves e a partilha determinam esse âmbito.
O AES-256 garante um raio de impacto reduzido?
Não. A força do algoritmo não determina até que ponto as chaves são partilhadas. Produtos que utilizam cifragem forte podem expor quantidades de dados diferentes quando uma conta ou uma chave é comprometida.
Um administrador autoalojado consegue ler todas as palavras-passe numa base de dados?
Isso depende da conceção das chaves e das chaves do administrador. No Bitwarden, um membro da organização com a chave da organização e acesso à base de dados consegue decifrar os registos da empresa. No Passwork, com a cifragem no lado do cliente ativada, as chaves de um membro desbloqueiam apenas os cofres atribuídos.
A pertença a um grupo LDAP concede automaticamente acesso a cofres?
No Passwork, com a cifragem no lado do cliente, as novas chaves de cofre exigem aprovação de um detentor da chave. Outros produtos podem aprovisionar automaticamente as chaves relevantes ou, no caso do Passbolt, exigir recifragem por segredo.
Uma única ferramenta pode gerir palavras-passe de colaboradores e segredos de DevOps?
Sim. O Passwork suporta ambos através de uma única instância, API REST, CLI e modelo de permissões. Outros produtos podem utilizar ofertas de gestão de segredos separadas ou interfaces de automatização distintas.
Uma palavra-passe de domínio decifra os dados do cofre?
Não. Autentica o utilizador diretamente junto do LDAP/AD no Passwork Self-hosted, ou através de SSO noutros produtos. A decifragem depende de chaves criptográficas separadas.
Como os gestores de palavras-passe definem o limite de cifragem
Todos os fornecedores dizem «AES-256, zero-knowledge». Isso não revela o que uma única chave comprometida realmente abre. Testámos esta questão com o Passwork, o Bitwarden, o Passbolt, o 1Password e o Keeper.
Business-Passwortmanager werben häufig mit AES-256-Verschlüsselung und Servern, die niemals Passwörter im Klartext sehen. Doch die Stärke der Chiffre allein sagt nichts darüber aus, wie viele Daten ein kompromittierter Schlüssel oder eine falsch zugewiesene Gruppenmitgliedschaft offenlegen können.
Wie weit diese Offenlegung reicht, hängt von der Verschlüsselungsgrenze ab: ob ein Schlüssel eine Organisation, einen Tresor, einen gemeinsam genutzten Ordner oder ein einzelnes Secret entsperrt. Dieser Vergleich untersucht, wo Passwork, Bitwarden, Passbolt, 1Password und Keeper diese Grenze ziehen und was ihre Architektur für Berechtigungen, Verzeichnisanmeldung, Automatisierung und Bereitstellung bedeutet.
Die Frage, die die Verschlüsselungsgrenze offenlegt
Stellen Sie sich einen selbst gehosteten Passwortmanager vor. Ein für Backups zuständiger Systemadministrator besitzt einen Datenbank-Dump und tritt der Unternehmensorganisation bei, um auf ein gemeinsam genutztes Passwort zuzugreifen. Was könnte er mit den seinem Konto zur Verfügung stehenden Schlüsseln noch entschlüsseln?
Bitwarden verschlüsselt Unternehmenselemente laut seinem Security-Whitepaper mit Einzelschlüsseln pro Element, die von einem symmetrischen Organisationsschlüssel umschlossen werden. Organisationsmitglieder erhalten nutzbaren Zugriff auf diesen Schlüssel, während Collections den regulären, vom Server bereitgestellten Zugriff und die Berechtigungen steuern, anstatt eigene kryptografische Grenzen zu schaffen. In einem Bedrohungsmodell für selbst gehostete Instanzen könnte ein Angreifer, der an die relevanten Datenbank-Chiffretexte und den nutzbaren Organisationsschlüssel eines Mitglieds gelangt, Organisationselemente außerhalb der diesem Mitglied zugewiesenen Collections entschlüsseln.
Passwork verwendet bei aktivierter clientseitiger Verschlüsselung für jeden Tresor einen eigenen Schlüssel. Element-Schlüssel liegen unterhalb der Tresor-Schlüssel, und Benutzer erhalten einen umschlossenen Tresor-Schlüssel nur für Tresore, auf die sie zugreifen dürfen. In diesem Zero-Knowledge-Verschlüsselungsmodell kann derselbe Systemadministrator seine zugewiesenen Tresore entschlüsseln, nicht aber unzusammenhängende Finanz- oder Infrastruktur-Tresore.
Passbolt verschlüsselt laut seiner Sicherheitsdokumentation (Pro v5.4, August 2025) jedes Secret mit OpenPGP separat für jeden Empfänger. Es gibt keinen gemeinsamen Container-Schlüssel. Benutzer können nur Secrets entschlüsseln, die für sie verschlüsselt wurden, auch wenn das Hinzufügen von Empfängern mehr Aufwand bedeutet.
1Password isoliert Daten nach Tresor, wo auch die Berechtigungen festgelegt werden. Keeper verwendet Eintrags-Schlüssel und Schlüssel für gemeinsam genutzte Ordner anstelle eines einzigen organisationsweiten Schlüssels. Für diesen speziellen Test bietet keines der beiden Produkte eine selbst gehostete Tresor-Datenbank an.
Aspekt
Passwork
Bitwarden
Passbolt
1Password
Keeper
Verschlüsselungsgrenze
Tresor
Organisation
Einzelnes Secret
Tresor
Gemeinsam genutzter Ordner und Eintrag
Datenbank plus Mitgliedsschlüssel entsperrt
Zugewiesene Tresore
Unternehmenseinträge unter dem Organisationsschlüssel
Mit diesem Mitglied gemeinsam genutzte Secrets
Nicht zutreffend: Cloud-Tresor
Nicht zutreffend: Cloud-Tresor
Offenlegung durch ein kompromittiertes Mitglied mit Datenbankzugriff
Zugewiesene Tresore
Organisation
Zugewiesene Secrets
Nicht direkt vergleichbar
Nicht direkt vergleichbar
Passwork und Passbolt begrenzen, was ein Datenbank-Dump zusammen mit den Schlüsseln eines einzelnen Mitglieds offenlegen kann. Bitwarden vereinfacht die Schlüsselverteilung, macht den Organisationsschlüssel aber zu einer breiteren kryptografischen Grenze. Die reinen Cloud-Produkte umgehen dieses spezielle Datenbankzugriffsszenario, auch wenn ihre Schlüsselarchitektur weiterhin relevant ist.
In Passwork legt ein Tresortyp fest, wer Tresore einer bestimmten Klasse erstellen darf und welche Administratoren neuen Tresoren dieses Typs automatisch zugewiesen werden. Bei aktivierter clientseitiger Verschlüsselung erhalten diese Administratoren zusätzlich umschlossene Kopien der neuen Tresor-Schlüssel. Das Ergebnis ist eine wiederholbare Richtlinie für Abteilungen und Projekte.
Zum Beispiel kann ein Finance-Typ den CFO automatisch jedem neuen Finanz-Tresor zuweisen. Ein DevOps-Typ kann Infrastruktur-Administratoren getrennt vom Vertrieb halten. Verlässt eine Abteilungsleitung das Unternehmen, kann das Unternehmen den Typ-Administrator neu zuweisen und die Berechtigungen in diesem Bereich überprüfen, anstatt eine unübersichtliche globale Administratorrolle zu prüfen. Das wird mit wachsender Team- und Tresoranzahl nützlich. Mehr zu den Tresor-Richtlinien von Passwork.
Zwei integrierte Typen kommen ohne Unternehmens-Administratoren aus. Ein persönlicher Tresor gehört einem einzelnen Benutzer. Ein privater gemeinsam genutzter Tresor erlaubt diesem Benutzer, andere einzuladen. Standardmäßig können selbst der Besitzer oder Admin der Organisation deren Inhalte nicht lesen. Administratoren können festlegen, wer diese Tresortypen erstellen und Informationen daraus freigeben darf, einschließlich der Möglichkeit, die unkontrollierte Erstellung persönlicher Tresore zu deaktivieren.
Es gibt zwei Einschränkungen: Das Zuweisen eines Typs gewährt keinen rückwirkenden Zugriff auf bestehende Tresore, und Typen bilden nur bei aktivierter clientseitiger Verschlüsselung kryptografische Grenzen. Andernfalls bleiben sie reine Governance-Regeln.
Die Wettbewerber bieten verwandte Funktionen, aber keine vergleichbare Richtlinienebene. Bitwardens Enterprise-Richtlinien regeln Aspekte wie Authentifizierung, Wiederherstellung und Organisationsmitgliedschaft, weisen aber keine Administratoren automatisch nach Tresortyp zu. Passbolt besitzt keinen Tresor-Container, der klassifiziert werden könnte. 1Password bietet Isolation auf Tresorebene und persönliche Tresore, aber keine vergleichbare typweite Regel für neu erstellte Tresore. Keepers gemeinsam genutzte Ordner und Teams verwalten den Zugriff ohne typisierte Richtlinien zur Tresorerstellung.
Funktion
Passwork
Bitwarden
Passbolt
1Password
Keeper
Tresortypen mit zugewiesenen Administratoren
Ja
Nein
Nein
Nein
Nein
Administratoren automatisch neuen Tresoren eines Typs zuweisen
Ja
Nein
Nein
Nein
Nein
Steuerung, wer einen Typ erstellen darf
Pro Typ
Teilweise, über Organisationsrichtlinien
Nein
Nein
Nein
Persönlicher Bereich ohne Unternehmens-Administrator
Persönliche und private gemeinsam genutzte Tresore
„My Items"
Freigabe pro Secret
Persönlicher Tresor
Persönlicher Ordner
Steuerung der Freigabe aus persönlichen Tresoren nach Typ
Ja
Keine Entsprechung
Keine Entsprechung
Keine Entsprechung
Keine Entsprechung
Tresortypen verringern das Risiko, dass neu erstellte Abteilungstresore uneinheitlich administriert werden. Sie erfordern eine Richtlinienentscheidung im Vorfeld, reduzieren aber spätere wiederholte manuelle Konfiguration.
Ordnerberechtigungen: Vererbung oder Vorlagen?
Eine Ordnerstruktur ist nur dann nützlich, wenn sich ihre Berechtigungen so verhalten, wie Administratoren es erwarten. Ähnlich aussehende Oberflächen können sehr unterschiedliche Regeln durchsetzen.
Passwork bietet für Benutzer und Gruppen auf Tresor- oder Ordnerebene fünf Berechtigungsstufen: Lesen, Schreiben, Verwalten, Admin und Verboten. Der Tresorzugriff vererbt sich auf verschachtelte Ordner, während Ordnerregeln den Zugriff einschränken können. Admin- und Verboten-Rechte können weiter unten nicht überschrieben werden. Gelten mehrere Regeln gleichzeitig, setzt sich die Stufe mit höherer Priorität durch. Wichtig: Ein Ordner bildet keine eigene Verschlüsselungsgrenze – der Zugriff auf seine Inhalte hängt weiterhin vom Tresor-Schlüssel ab. Dies ergänzt Passworks Modell der rollenbasierten Zugriffskontrolle.
Bitwarden vergibt Berechtigungen über Collections. Verschachtelte Collections sind organisatorische Kennzeichnungen; sie erben weder die Elemente noch die Rechte der übergeordneten Collection. Persönliche Ordner besitzen keine Freigabeberechtigungen. Individuelle Mitgliederberechtigungen überschreiben Gruppenberechtigungen.
Passbolt verwendet Ordner als Berechtigungsvorlagen. Wird ein Element erstellt, verschoben oder freigegeben, gelten zunächst die Berechtigungen des Ordners; anschließend bestimmen die eigenen Berechtigungen des Elements den weiteren Zugriff. Ein Ersteller kann Besitzer eines Passworts werden und den Zugriff einschränken, selbst wenn jemand anderes Besitzer des Ordners ist. In einer Community-Diskussion vom Juli 2026 zur Erweiterung v5.14.2 bestätigte Passbolt, dass dieses Verhalten seinem Berechtigungsmodell entspricht, und kündigte eine geplante UI-Änderung an, die verhindern soll, dass Nicht-Besitzer während der Erstellung Berechtigungen bearbeiten.
1Password besitzt innerhalb eines Tresors keine berechtigungstragenden Ordner; Tags organisieren Elemente, ohne den Zugriff zu verändern. Um eine Teilmenge von Elementen dauerhaft freizugeben, ist daher ein weiterer Tresor erforderlich. Laut einer Community-Antwort vom September 2026 werden verschachtelte Identity-Provider-Gruppen für die Tresormitgliedschaft nicht unterstützt.
Keeper unterstützt verschachtelte gemeinsam genutzte Ordner und Berechtigungen auf Eintragsebene. Explizite Eintragszuweisungen überschreiben vererbte Ordnerrechte. Sein Modell verschachtelter Ordner ist auf fünf Ebenen begrenzt und war in Tresor-Release 18.0.0 hinter einem Feature-Flag verborgen.
Aspekt
Passwork
Bitwarden
Passbolt
1Password
Keeper
Interne Struktur
Ordnerstruktur
Collections
Ordner als Berechtigungsvorlagen
Tags
Verschachtelte gemeinsam genutzte Ordner
Vererbte Rechte
Ja, mit Einschränkungen
Nein
Nein; Berechtigungen gelten bei Erstellung oder Verschiebung
Nicht zutreffend
Ja, fünf Ebenen, Feature-Flag
Berechtigungsstufen
Lesen, Schreiben, Verwalten, Admin, Verboten
Anzeigen, Verbergen, Bearbeiten, Verwalten
Lesen, Aktualisieren, Besitzer
Anzeigen, Erstellen, Bearbeiten, Archivieren, Löschen, Verwalten
Ordner- und Eintragsberechtigungen
Freigabe einzelner Einträge
Shortcuts und Posteingang
Element in mehreren Collections
Direkte Elementfreigabe
Keine dauerhafte Freigabe auf Elementebene
Ja
Passworks Struktur unterstützt Abteilungsgliederungen und Ausnahmen. Bitwarden und 1Password sind einfacher zu administrieren, aber weniger flexibel bei tief verschachteltem Zugriff. Passbolts Vorlagenverhalten erfordert besondere Aufmerksamkeit, da Ordner- und Elementberechtigungen voneinander abweichen können.
Gruppen: Was ändert sich, wenn jemand beitritt?
Bei aktivierter clientseitiger Verschlüsselung in Passwork erhält eine Person, die einer Gruppe hinzugefügt wird, nicht automatisch alle mit dieser Gruppe verknüpften Tresor-Schlüssel. Stattdessen entsteht für jeden betroffenen Tresor eine ausstehende Anfrage. Ein Schlüsselinhaber muss die Anfrage genehmigen, bevor das neue Mitglied die Inhalte entschlüsseln kann.
Damit werden Verzeichnis-Provisioning und kryptografischer Zugriff getrennt. Die LDAP-Synchronisierung kann einen neuen Mitarbeiter in Gruppen aufnehmen, doch der Zugriff auf sensible Tresore erfordert weiterhin eine Genehmigung. Diese Unterscheidung ist bei Onboarding und Offboarding relevant.
Für Teams, die weniger manuelle Genehmigungen benötigen, bietet Passwork ein weiteres Muster: Die Daten der Abteilung in einem Tresor ablegen und in Ordnern organisieren. Der Tresor-Schlüssel des Benutzers wird einmalig genehmigt; Ordnerberechtigungen bestimmen anschließend den Zugriff innerhalb dieses Tresors, wenn sich die Gruppenmitgliedschaft ändert. Der Kompromiss ist eine breitere gemeinsam genutzte kryptografische Grenze als bei mehreren getrennten Tresoren.
Passbolt kann diese Abkürzung nicht nutzen. Da jedes Secret für jeden Empfänger einzeln verschlüsselt wird, muss jemand mit Zugriff die betreffenden Secrets für das neue Mitglied neu verschlüsseln, wenn eine Gruppe erweitert wird. Die Verzeichnissynchronisierung benachrichtigt einen Gruppenverantwortlichen und wartet auf diesen Schritt. Der Aufwand skaliert mit der Anzahl der Secrets, nicht mit der Anzahl der Tresore.
Bitwarden verteilt den Organisationsschlüssel bereits an die Mitglieder, sodass Collection-Zuweisungen keine neuen Verschlüsselungsschlüssel erfordern. Bei 1Password folgen zugewiesene Tresor-Schlüssel dem Gruppenzugriff. Keeper verteilt den Zugriff über zugewiesene gemeinsam genutzte Ordner.
Aspekt
Passwork
Passbolt
Bitwarden
1Password
Keeper
Gruppenmitgliedschaft liefert automatisch neue Entschlüsselungsschlüssel
Nein; Genehmigung pro Tresor
Nein; Neuverschlüsselung pro Secret
Organisationsschlüssel bereits vorhanden
Zugewiesene Tresor-Schlüssel
Schlüssel zugewiesener gemeinsam genutzter Ordner
Verzeichnissynchronisierung gewährt Zugriff ohne menschliches Eingreifen
Nein, für neue Tresor-Schlüssel
Nein
Ja
Ja
Ja
Hauptaufwand beim Hinzufügen eines Mitglieds
Umschlossener Schlüssel pro Tresor
Neuverschlüsselung pro Secret
Mitgliedschaftsaktualisierung
Schlüssel für zugewiesene Tresore
Schlüssel für zugewiesene Ordner
Genehmigung auf Container-Ebene
Ja
Nein
Organisationsmitgliedschaft
Tresor
Gemeinsam genutzter Ordner
Die Wahl besteht zwischen strengeren Genehmigungsschritten und reibungsloserem Provisioning. Passwork erlaubt es Organisationen, für unterschiedliche Abteilungen unterschiedliche Gewichtungen zu wählen; Passbolt bietet feingranularen Zugriff pro Secret zu einem höheren Freigabeaufwand.
Was die Domänenanmeldung tatsächlich bewirkt
Ein Domänenpasswort authentifiziert einen Benutzer; es entschlüsselt in keinem dieser Produkte Tresordaten. Die Unterschiede liegen darin, wie Verzeichnisauthentifizierung und Provisioning funktionieren.
Passwork Self-hosted authentifiziert direkt gegen LDAP oder Active Directory, auch in Umgebungen mit mehreren Domänencontrollern. Benutzer melden sich mit ihren Domänen-Zugangsdaten an; Verzeichnisgruppen lassen sich auf Passwork-Gruppen abbilden. Bei aktivierter clientseitiger Verschlüsselung authentifiziert das Domänenpasswort die Sitzung, während separate kryptografische Schlüssel die Tresorinhalte schützen.
Passwork Cloud bot zum Zeitpunkt dieses Vergleichs noch kein LDAP an; es stand zusammen mit SCIM-Provisioning auf der Roadmap. Beide Passwork-Bereitstellungen unterstützen SAML-2.0-SSO.
Bitwarden Directory Connector synchronisiert Benutzer und Gruppen, authentifiziert sie laut Dokumentation jedoch nicht gegen LDAP. Eine domänenbasierte Anmeldung erfordert Enterprise-SSO über SAML oder OIDC. Benutzer entsperren ihren Tresor normalerweise weiterhin mit einem Masterpasswort, sofern nicht Trusted Devices oder Key Connector konfiguriert sind.
Passbolt trennt ebenfalls LDAP-Synchronisierung und Anmeldung. Benutzer authentifizieren sich mit einem privaten Schlüssel und einer Passphrase oder per SSO, und das Hinzufügen synchronisierter Benutzer zu Gruppen mit bestehenden Secrets erfordert eine Neuverschlüsselung.
1Password und Keeper nutzen cloudbasierte Tresordienste mit SSO-Integration. Keepers SSO Connect On-Prem kann bestimmte Identitätskomponenten auf unternehmenseigener Hardware belassen, doch das verschlüsselte Tresor-Backend verbleibt in Keepers Cloud. Keeper listet die unterstützten lokalen Komponenten in seiner Bereitstellungsdokumentation auf.
Aspekt
Passwork
Bitwarden
Passbolt
1Password
Keeper
Direkte Anmeldung mit Domänenpasswort
Self-hosted LDAP/AD
Nein; SSO
Nein; Schlüssel/Passphrase oder SSO
SSO
SSO
Mehrere Domänencontroller
Ja
Nur Synchronisierung
Nur Synchronisierung
Nicht zutreffend
AD Bridge
Dokumentiertes SSO-Protokoll
SAML 2.0
SAML 2.0 oder OIDC
OpenID Connect (OIDC)
OpenID Connect (OIDC)
SAML 2.0
SCIM-Provisioning
Geplant
Ja
Ja
Ja
Ja
Domänenpasswort entschlüsselt Einträge
Nein
Nein
Nein
Nein
Nein
Passworks direkte LDAP-Anmeldung kann selbst gehostete Bereitstellungen ohne separaten Identity-Provider vereinfachen. Cloud-first ausgerichtete Wettbewerber bieten derzeit ein ausgereifteres automatisiertes Identity-Provisioning; geplante Passwork-Funktionen sollten nicht als bereits verfügbar betrachtet werden.
Eine API für Passwörter und Machine Secrets
Passwork verwaltet Mitarbeiter-Zugangsdaten und Machine Secrets über dieselbe Instanz, dasselbe Berechtigungsmodell, dasselbe Audit-Log und dieselbe REST-API. Teams können CI/CD-Workflows unterstützen, ohne ein separates Secrets-Produkt lizenzieren zu müssen.
Die Web-, Desktop-, Browser- und Mobil-Clients nutzen dieselbe API unter /api/v1. Eine offizielle CLI und ein Open-Source-Python-Connector unterstützen DevOps-Workflows. Die CLI bietet get und update für Einträge, api für direkte Endpunktaufrufe sowie exec, um ein Secret abzurufen und zu entschlüsseln, die Werte als Umgebungsvariablen bereitzustellen und einen Befehl auszuführen. Servicekonten sind Benutzer mit von einem Administrator erstellten API-Tokens. Das Erzeugen eines neuen persönlichen Tokens widerruft die vorherigen API-Sitzungen des Benutzers.
Dieses einheitliche Modell hat Grenzen: Die API ist pull-basiert, es gibt keine ausgehenden Webhooks, und /v1/batch unterstützt nur lesende Aggregation mit bis zu 25 GET-Teilanfragen. Ereignisgesteuerte Integrationen müssen pollen oder Syslog-Exporte konsumieren.
Die Wettbewerber verfolgen andere Ansätze. Bitwarden Secrets Manager ist ein separates kostenpflichtiges Add-on mit Machine Accounts und projektbasiertem Zugriff anstelle des Zugriffs über Password-Manager-Collections. Keeper Secrets Manager ist eine eigene Produktlinie mit SDKs und einem cloudverbundenen Gateway. Die Servicekonten von 1Password arbeiten mit festgelegten Tresoren und Berechtigungen, doch ihr Geltungsbereich wird bei der Erstellung eines Tokens fixiert; eine Änderung erfordert ein neues Token. Passbolt bietet eine API und Automatisierungswerkzeuge, behält dabei aber sein Freigabemodell pro Secret bei.
Aspekt
Passwork
Bitwarden
Passbolt
1Password
Keeper
Mitarbeiter- und Machine Secrets
Eine Instanz
Password Manager plus Secrets Manager
Ein Produkt
Tresore plus Servicekonten
Tresor plus Secrets Manager
Automatisierungsschnittstelle
REST-API, CLI, Python-Connector
Management-API sowie Secrets Manager CLI/SDKs
REST-API, Admin-CLI
CLI, SDKs, Connect
SDKs, Commander
Maschinenidentität
Servicekonto mit Token
Projektbezogener Machine Account
Benutzer mit privatem Schlüssel
Servicekonto mit festem Geltungsbereich
Secrets-Manager-Anwendung
Hauptbeschränkung
Keine Webhooks; nur lesender Batch-Zugriff
Separates Secrets-Abonnement
Zusätzlicher Aufwand durch Freigabe pro Secret
Token-Geltungsbereich unveränderlich
Separates Secrets-Produkt
Passwork setzt auf ein einziges operatives System für Mitarbeiter und Automatisierung. Spezialisierte Secrets-Produkte können dedizierte Integrationen bieten, bringen aber zusätzliche Lizenzierungs- und Verwaltungsebenen mit sich.
Wo der Tresor läuft
Die Bereitstellungsart kann Produkte schon vor jedem Funktionsvergleich von einer Auswahlliste ausschließen. Passwork, Bitwarden und Passbolt erlauben Organisationen, den Tresor selbst zu hosten. 1Password und Keeper belassen das Tresor-Backend in ihren eigenen Cloud-Diensten.
Passwork unterstützt eine On-Premise-Bereitstellung auf Linux, Windows Server oder Docker und gibt Organisationen so die Kontrolle über Infrastruktur und Backups. Das in der EU gehostete Cloud-Angebot verwendet für jeden Kunden eine separate Datenbank und einen eigenen Tenant, anstatt alle Kundendaten in einem gemeinsamen Schema zu speichern. Diese Optionen werden im Leitfaden zu Bereitstellungsmodellen von Passwork erläutert.
Bitwarden bietet ebenfalls echtes Self-Hosting an, wobei die Enterprise-Lizenz weiterhin an ein aktives Cloud-Abonnement gebunden ist. Passbolt unterstützt sowohl Self-Hosting als auch einen gehosteten Dienst. Keepers lokal bereitstellbare SSO- und Integrationskomponenten ändern nichts am Standort des Tresor-Backends.
Aspekt
Passwork
Bitwarden
Passbolt
1Password
Keeper
Selbst gehosteter Tresor
Ja
Ja
Ja
Nein
Nein
Anbieter-Cloud
EU
Ja
Ja
Ja
Ja
Cloud-Tenant-Modell
Separate Datenbank pro Tenant
Multi-Tenant
Dediziert pro Abonnement
Multi-Tenant
Multi-Tenant
Self-Hosting gibt Organisationen die Kontrolle über den Datenstandort, überträgt ihnen aber auch die Verantwortung für Updates, Backups und Verfügbarkeit. Reine Cloud-Produkte reduzieren diesen Aufwand, sofern die eigenen Richtlinien ein externes Hosting zulassen.
Optionale clientseitige Verschlüsselung und Metadaten
Passwork Cloud verwendet stets clientseitige Verschlüsselung. Bei selbst gehostetem Passwork können Administratoren sie deaktivieren. Die übrigen vier Produkte dieses Vergleichs bieten keine vergleichbare Option.
Serverseitige Verschlüsselung kann sich für ein kleines Team mit vertrauenswürdigen Administratoren eignen, dem sofortige Zugriffsvergabe und eine einfachere Wiederherstellung wichtiger sind. Das Deaktivieren der clientseitigen Verschlüsselung hebt die kryptografische Isolation pro Tresor auf: Tresortypen steuern weiterhin Erstellung und Administration, bilden aber keine eigenen Verschlüsselungsgrenzen mehr.
Selbst bei aktivierter clientseitiger Verschlüsselung kann der Passwork-Server Elementnamen, Logins, Beschreibungen und URLs lesen, um die serverseitige Suche zu unterstützen. Passwortwerte bleiben clientseitig verschlüsselt und außerhalb des Suchindex. Bitwarden und Keeper verschlüsseln auch diese Metadatenfelder und halten sie so vor dem Server verborgen – auf Kosten einer clientseitigen Entschlüsselung für die Suche. Passbolt v5 lässt Ordnernamen und Tags unverschlüsselt.
Aspekt
Passwork
Bitwarden
Passbolt
1Password
Keeper
Clientseitige Verschlüsselung deaktivierbar
Nur selbst gehostet
Nein
Nein
Nein
Nein
Für den Server sichtbare Metadaten bei clientseitiger Verschlüsselung
Name, Login, Beschreibung, URL
Keines dieser Felder
Ordnernamen und Tags
Keines dieser Felder
Keines dieser Felder
Suche
Server
Client
Client
Client
Client
Das ist ein echter Kompromiss zwischen Sicherheit und Benutzerfreundlichkeit. Käufer sollten sowohl die Vertraulichkeit der Passwörter als auch die Offenlegung von Metadaten bewerten, besonders wenn Einträge sensible Systemnamen oder Kontokennungen enthalten.
Was es kostet
Dies sind veröffentlichte Listenpreise pro Benutzer und Monat bei jährlicher Abrechnung, Stand Oktober 2026. Die Anbieter verwenden unterschiedliche Währungen und Paketierungen, weshalb der Vergleich nur eine grobe Orientierung bietet.
Passwork Standard kostet 3 €, Advanced 4,50 € pro Benutzer und Monat. Advanced umfasst Secrets-Management und Enterprise-Identitätsfunktionen. Self-hosted-Kunden können außerdem eine einmalige Lifetime-Lizenz wählen. Bitwarden Teams kostet 4 $, Enterprise 6 $, wobei der Secrets Manager separat mit 6 $ beziehungsweise 12 $ berechnet wird. Keeper Business startet bei 4 $, Enterprise bei 6 $, während KeeperPAM separat berechnet wird. 1Password Business kostet 8,99 $. Passbolt Pro Self-hosted kostet 4,50 € bei einem Mindestumfang von zehn Benutzern.
Produkt
Preis/Benutzer/Monat
Relevante Bedingung
Passwork Standard
3 €
Cloud oder selbst gehostet
Passwork Advanced
4,50 €
SSO, LDAP-Zuordnung, Secrets, Clustering; Lifetime-Option für Self-hosted
Einige Berichte und Überwachungsfunktionen erfordern eine höhere Stufe
Keeper Enterprise
6 €
PAM wird separat verkauft
1Password Business
8,99 $
Cloud-Tresor
Passbolt Pro
4,50 €
Self-hosted; Mindestens zehn Benutzer
Der Bitwarden Secrets Manager kostet 6 $ pro Benutzer und Monat im Tarif Teams beziehungsweise 12 $ im Tarif Enterprise und wird separat vom Password Manager abgerechnet. Organisationen, die beide Produkte nutzen, sollten die kombinierten Lizenzkosten anhand der jeweiligen Benutzerzahl vergleichen. Passwork Advanced vereint Passwort- und Secrets-Management in einem Abonnement. Passbolts Verschlüsselungsmodell pro Secret erzeugt zusätzlichen administrativen Aufwand beim Freigeben von Secrets oder beim Hinzufügen von Gruppenmitgliedern – ein Kostenfaktor, den die Abonnementpreise allein nicht abbilden.
Wo Wettbewerber im Vorteil sind
Passbolt ermöglicht direkte Freigabe und direkten Entzug pro Secret. Jeder Empfänger erhält einen mit seinem öffentlichen Schlüssel verschlüsselten Chiffretext. Ein Entzug entfernt die verschlüsselte Kopie dieses Empfängers aus dem Dienst. Das ermöglicht feingranulare Kontrolle, erfordert aber für jeden zusätzlichen Empfänger Verschlüsselungs- und Speicheraufwand. Wie bei anderen Passwortmanagern kann ein Entzug keinen Klartext oder zuvor vom Empfänger gespeicherte Kopien löschen.
Passwork speichert einen einzigen gemeinsam genutzten Chiffretext und verteilt umschlossene Schlüssel, anstatt jedes Secret für jeden Empfänger zu duplizieren. Das Entfernen einer dauerhaften Tresor- oder Ordnerfreigabe entzieht den entsprechenden Schlüsselzugriff. Der Posteingang funktioniert anders: Eine direkte Übergabe zwischen Benutzern umschließt den Schlüssel eines Elements für den Empfänger, und ein akzeptiertes Element wird zu einer Kopie im Tresor des Empfängers. Die Zustellung an einen Gruppen-Posteingang nutzt einen Pfad ohne clientseitige Verschlüsselung. Der Posteingang ist daher eine Übertragung und keine dauerhaft widerrufbare Freigabe.
Aspekt
Passwork
Passbolt
Pro Empfänger gespeicherte Daten
Ein gemeinsam genutzter Chiffretext, umschlossene Schlüssel
Chiffretext pro Empfänger
Freigeben
Schlüssel umschließen
Secret neu verschlüsseln
Laufenden Zugriff widerrufen
Zugriff auf umschlossenen Schlüssel entfernen
Chiffretext-Kopie des Empfängers entfernen
Einmalige Übergabe
Posteingang erstellt bei Annahme eine Kopie im Besitz des Empfängers
Direkte Elementfreigabe
Bitwarden und Keeper schützen Metadaten, die Passwork für die serverseitige Suche offenlegt. Keeper bietet außerdem Eintrags-Shortcuts und direkte Berechtigungen pro Eintrag in gemeinsam genutzten Ordnern sowie eine breitere Privileged-Access-Plattform. 1Password hat weniger Vererbungsregeln und Ausnahmen, wodurch es sich leichter für Teams konfigurieren lässt, die keine komplexen Ordnerberechtigungen benötigen. Bitwarden verbindet einen niedrigen Einstiegspreis, Self-Hosting und etablierte Clients.
Das sind handfeste Vorteile. Passworks Flexibilität hilft Organisationen mit komplexen Zugriffsstrukturen, schafft aber auch mehr Richtlinien, die entworfen und gepflegt werden müssen.
Die richtige Wahl: Bei der Grenze beginnen
Beginnen Sie mit dem Schadensszenario, nicht mit dem Verschlüsselungsalgorithmus. Welche Einträge können die Schlüssel eines kompromittierten Kontos entschlüsseln? Was ändert sich, wenn der Angreifer zusätzlich ein Datenbank-Backup erhält? Prüfen Sie anschließend, ob Ihr Berechtigungsmodell die Abteilungsgrenzen widerspiegelt und ob Onboarding den Zugriff unbeabsichtigt erweitern kann.
Passwork eignet sich für Organisationen, die separate Abteilungstresore, vererbte Ordnerberechtigungen, direkte LDAP-Authentifizierung vor Ort sowie Mitarbeiter- und Machine-Zugangsdaten in einem System benötigen. Passbolt bevorzugt Kontrolle pro Secret dort, wo der administrative Aufwand der Freigabe vertretbar ist. Bitwarden bietet unkomplizierte organisationsweite Schlüsselverteilung und Self-Hosting. 1Password minimiert die Konfigurationskomplexität in einem Cloud-first-Modell. Keeper verbindet Kontrollen für gemeinsam genutzte Ordner mit einem breiteren Privileged-Access-Angebot.
Wenn Finance, HR und Infrastruktur getrennte operative Einheiten sind, entscheiden Sie, ob sie auch getrennte kryptografische Grenzen haben sollten. Diese Entscheidung bestimmt die potenzielle Offenlegung durch einen kompromittierten Schlüssel direkter als ein AES-256-Label.
Was ist eine Verschlüsselungsgrenze bei einem Passwortmanager?
Sie bezeichnet die Datenmenge, auf die ein bestimmter Schlüssel oder eine bestimmte Schlüsselgruppe zugreifen kann: eine Organisation, ein Tresor, ein gemeinsam genutzter Ordner oder ein einzelnes Secret. Schlüsselhierarchie und Freigabe bestimmen diesen Umfang.
Garantiert AES-256 einen kleinen Blast Radius?
Nein. Die Stärke der Chiffre bestimmt nicht, wie breit Schlüssel verteilt werden. Produkte mit starker Verschlüsselung können bei einem kompromittierten Konto oder Schlüssel unterschiedlich viele Daten offenlegen.
Kann ein Administrator bei einer selbst gehosteten Instanz jedes Passwort in der Datenbank lesen?
Das hängt vom Schlüsseldesign und den Schlüsseln des Administrators ab. Bei Bitwarden kann ein Organisationsmitglied mit Organisationsschlüssel und Datenbankzugriff Unternehmenseinträge entschlüsseln. Bei Passwork mit aktivierter clientseitiger Verschlüsselung entsperren die Schlüssel eines Mitglieds nur zugewiesene Tresore.
Gewährt eine LDAP-Gruppenmitgliedschaft automatisch Tresorzugriff?
Bei Passwork mit clientseitiger Verschlüsselung erfordern neue Tresor-Schlüssel die Genehmigung eines Schlüsselinhabers. Andere Produkte stellen die relevanten Schlüssel möglicherweise automatisch bereit oder erfordern, wie bei Passbolt, eine Neuverschlüsselung pro Secret.
Kann ein einziges Tool Mitarbeiter-Passwörter und DevOps-Secrets verwalten?
Ja. Passwork unterstützt beides über eine einzige Instanz, REST-API, CLI und ein gemeinsames Berechtigungsmodell. Andere Produkte verwenden möglicherweise separate Secrets-Management-Angebote oder unterschiedliche Automatisierungsschnittstellen.
Entschlüsselt ein Domänenpasswort Tresordaten?
Nein. Es authentifiziert den Benutzer bei selbst gehostetem Passwork direkt gegen LDAP/AD oder bei anderen Produkten über SSO. Die Entschlüsselung erfolgt über separate kryptografische Schlüssel.
Wie Passwort-Manager die Verschlüsselungsgrenze ziehen
Jeder Anbieter verspricht „AES-256, Zero-Knowledge". Das sagt nichts darüber aus, was ein einziger kompromittierter Schlüssel tatsächlich öffnet. Diese Frage wurde an Passwork, Bitwarden, Passbolt, 1Password und Keeper gestellt.
Los gestores de contraseñas empresariales suelen destacar el cifrado AES-256 y servidores que nunca ven las contraseñas en texto claro. Pero la fortaleza del cifrado por sí sola no indica cuántos datos puede exponer una clave comprometida o una membresía de grupo incorrecta.
Esa exposición depende del límite de cifrado: si una clave desbloquea una organización, una bóveda, una carpeta compartida o un secreto individual. Esta comparación analiza dónde trazan ese límite Passwork, Bitwarden, Passbolt, 1Password y Keeper, y qué implican sus diseños para los permisos, el inicio de sesión mediante directorio, la automatización y la implementación.
La pregunta que revela el límite de cifrado
Imagine un gestor de contraseñas autoalojado. Un administrador de sistemas responsable de las copias de seguridad dispone de un volcado de la base de datos y se une a la organización corporativa para acceder a una contraseña compartida. ¿Qué más podría descifrar con las claves disponibles en su cuenta?
Bitwarden cifra los elementos corporativos con claves por elemento envueltas por una única clave simétrica de la organización, según su documento técnico de seguridad. Los miembros de la organización reciben acceso utilizable a esa clave, mientras que las colecciones controlan el acceso y los permisos habituales entregados por el servidor, en lugar de crear límites criptográficos independientes. En un modelo de amenazas autoalojado, un atacante que obtenga los textos cifrados pertinentes de la base de datos y la clave utilizable de la organización de un miembro podría descifrar elementos de la organización fuera de las colecciones asignadas a ese miembro.
Passwork, con el cifrado del lado del cliente activado, utiliza una clave independiente para cada bóveda. Las claves de los elementos se sitúan bajo las claves de bóveda, y los usuarios reciben una clave de bóveda envuelta únicamente para las bóvedas a las que tienen acceso. Con este modelo de cifrado de conocimiento cero, el mismo administrador de sistemas puede descifrar sus bóvedas asignadas, pero no las bóvedas de Finanzas o Infraestructura no relacionadas.
Passbolt cifra cada secreto por separado para cada destinatario mediante OpenPGP, tal como se describe en su documentación de seguridad (Pro v5.4, agosto de 2025). No existe una clave de contenedor compartida. Los usuarios solo pueden descifrar los secretos cifrados para ellos, aunque añadir destinatarios exige más trabajo.
1Password aísla los datos por bóveda, donde también se definen los permisos. Keeper utiliza claves de registro y claves de carpeta compartida en lugar de una única clave para toda la organización. Ninguno de los dos ofrece una base de datos de bóveda autoalojada para esta prueba en concreto.
Aspecto
Passwork
Bitwarden
Passbolt
1Password
Keeper
Límite de cifrado
Bóveda
Organización
Secreto individual
Bóveda
Carpeta compartida y registro
La base de datos más la clave de un miembro desbloquea
Bóvedas asignadas
Registros corporativos bajo la clave de la organización
Secretos compartidos con ese miembro
No aplicable: bóveda en la nube
No aplicable: bóveda en la nube
Exposición por un miembro comprometido con acceso a la base de datos
Bóvedas asignadas
Organización
Secretos asignados
No comparable directamente
No comparable directamente
Passwork y Passbolt limitan lo que un volcado de la base de datos más las claves de un miembro pueden revelar. Bitwarden simplifica la distribución de claves, pero convierte la clave de la organización en un límite criptográfico más amplio. Los productos exclusivamente en la nube evitan este escenario concreto de acceso a la base de datos, aunque su arquitectura de claves sigue siendo relevante.
Prueba gratuita de Passwork para comprobar cómo la estructura de su bóveda limita el acceso tras el compromiso de una cuenta.
Tipos de bóveda: gobernanza por encima de las bóvedas individuales
En Passwork, un tipo de bóveda define quién puede crear bóvedas de una clase y qué administradores se asignan automáticamente a las nuevas bóvedas de ese tipo. Con el cifrado del lado del cliente activado, esos administradores también reciben copias envueltas de las nuevas claves de bóveda. El resultado es una política repetible para departamentos y proyectos.
Por ejemplo, un tipo Finanzas puede asignar automáticamente al director financiero a cada nueva bóveda de finanzas. Un tipo DevOps puede mantener a los administradores de infraestructura separados de ventas. Cuando el responsable de un departamento se marcha, la empresa puede reasignar el administrador del tipo y revisar los permisos concedidos dentro de esa área, en lugar de auditar un rol de administrador global difícil de controlar. Esto resulta útil a medida que crecen los equipos y el número de bóvedas. Consulte las políticas de bóveda de Passwork.
Dos tipos integrados evitan la intervención de administradores corporativos. Una bóveda personal pertenece a un único usuario. Una bóveda compartida privada permite que ese usuario invite a otras personas. De forma predeterminada, ni siquiera el propietario o el administrador de la organización pueden leer su contenido. Los administradores pueden configurar quién puede crear estos tipos de bóveda y compartir información desde ellas, incluida la posibilidad de desactivar la creación no gestionada de bóvedas personales.
Existen dos límites: asignar un tipo no concede acceso retroactivo a las bóvedas existentes, y los tipos solo forman límites criptográficos cuando el cifrado del lado del cliente está activado. De lo contrario, siguen siendo reglas de gobernanza.
Los competidores ofrecen funciones relacionadas, pero no la misma capa de políticas. Las políticas empresariales de Bitwarden rigen aspectos como la autenticación, la recuperación y la pertenencia a la organización, en lugar de asignar automáticamente administradores por clase de bóveda. Passbolt no cuenta con un contenedor de bóveda que clasificar. 1Password ofrece aislamiento a nivel de bóveda y bóvedas personales, pero ninguna regla equivalente a nivel de clase para las bóvedas recién creadas. Las carpetas compartidas y los equipos de Keeper gestionan el acceso sin políticas de creación de bóvedas tipificadas.
Capacidad
Passwork
Bitwarden
Passbolt
1Password
Keeper
Clases de bóveda con administradores asignados
Sí
No
No
No
No
Asignar administradores automáticamente a las nuevas bóvedas de una clase
Sí
No
No
No
No
Controlar quién crea una clase
Por tipo
Parcialmente, mediante política de la organización
No
No
No
Espacio personal sin administrador corporativo
Bóvedas personales y compartidas privadas
Mis elementos
Uso compartido por secreto
Bóveda personal
Carpeta personal
Controlar el uso compartido desde bóvedas personales por clase
Sí
Sin equivalente
Sin equivalente
Sin equivalente
Sin equivalente
Los tipos de bóveda reducen la probabilidad de que las bóvedas departamentales recién creadas reciban una administración incoherente. Añaden una decisión de política por adelantado, pero reducen la configuración manual repetida más adelante.
Permisos de carpetas: ¿Herencia o plantillas?
Un árbol de carpetas solo resulta útil si sus permisos se comportan como esperan los administradores. Interfaces con un aspecto similar pueden aplicar reglas muy distintas.
Passwork ofrece cinco niveles de permiso (lectura, escritura, gestión, administración y prohibido) para usuarios y grupos a nivel de bóveda o de carpeta. El acceso de la bóveda se propaga a las carpetas anidadas, mientras que las reglas de carpeta pueden restringirlo. Los derechos de administración y de prohibición no se pueden anular en niveles inferiores. Cuando se aplican varias reglas, prevalece el nivel de mayor prioridad. Es importante señalar que una carpeta no constituye un límite de cifrado independiente: el acceso a su contenido sigue dependiendo de la clave de la bóveda. Esto se suma al modelo de control de acceso basado en roles de Passwork.
Bitwarden concede permisos a través de colecciones. Las colecciones anidadas son etiquetas organizativas; no heredan los elementos ni los derechos de su colección superior. Las carpetas personales no tienen permisos de uso compartido. Los permisos individuales de un miembro prevalecen sobre los permisos de grupo.
Passbolt utiliza las carpetas como plantillas de permisos. Cuando se crea, se mueve o se comparte un elemento, se aplican los permisos de la carpeta, pero los permisos propios del elemento determinan el acceso posterior. Quien lo crea puede convertirse en propietario de una contraseña y restringir el acceso aunque la carpeta pertenezca a otra persona. En un debate comunitario de julio de 2026 sobre la extensión v5.14.2, Passbolt confirmó que este comportamiento se ajusta a su modelo de permisos y señaló que estaba previsto un cambio en la interfaz para impedir que los no propietarios editaran los permisos durante la creación.
1Password no dispone de carpetas con permisos propios dentro de una bóveda; las etiquetas organizan los elementos sin modificar el acceso. Por ello, compartir de forma permanente un subconjunto de elementos exige otra bóveda. Los grupos anidados de un proveedor de identidad no son compatibles con la pertenencia a bóvedas, según una respuesta de la comunidad de septiembre de 2026.
Keeper admite carpetas compartidas anidadas y permisos a nivel de registro. Las asignaciones explícitas de registros prevalecen sobre los derechos heredados de la carpeta. Su modelo de carpetas anidadas tiene un límite de profundidad de cinco niveles y estaba detrás de un feature flag en la versión 18.0.0 de la bóveda.
El árbol de Passwork admite estructuras departamentales y excepciones. Bitwarden y 1Password son más sencillos de administrar, pero menos flexibles para el acceso con anidamiento profundo. El comportamiento de plantillas de Passbolt exige especial atención, ya que los permisos de carpeta y de elemento pueden divergir.
Grupos: ¿qué cambia cuando alguien se incorpora?
Con el cifrado del lado del cliente de Passwork, añadir a alguien a un grupo no le otorga automáticamente todas las claves de bóveda asociadas a ese grupo. Se genera una solicitud pendiente para cada bóveda pertinente. Un titular de la clave debe aprobar la solicitud antes de que el nuevo miembro pueda descifrar su contenido.
Esto separa el aprovisionamiento de directorio del acceso criptográfico. La sincronización LDAP puede incorporar a un nuevo empleado a los grupos, pero el acceso a bóvedas sensibles sigue requiriendo aprobación. Esta distinción es importante durante la incorporación y la baja de empleados.
Para los equipos que necesitan menos aprobación manual, Passwork ofrece otro patrón: colocar los datos del departamento en una única bóveda y organizarlos en carpetas. Apruebe la clave de bóveda del usuario una sola vez; a partir de ahí, los permisos de carpeta determinan el acceso dentro de esa bóveda a medida que cambia la pertenencia a los grupos. La contrapartida es un límite criptográfico compartido más amplio que el de varias bóvedas independientes.
Passbolt no puede recurrir a este atajo. Dado que cada secreto se cifra para cada destinatario, añadir un miembro al grupo exige que alguien con acceso vuelva a cifrar los secretos pertinentes para ese usuario. La sincronización de directorio notifica a un gestor del grupo y espera a que se complete este paso. El trabajo escala con el número de secretos, no con el número de bóvedas.
Bitwarden ya distribuye la clave de la organización a los miembros, por lo que las asignaciones de colección no requieren nuevas claves de cifrado. En 1Password, las claves de bóveda asignadas siguen el acceso del grupo. Keeper distribuye el acceso mediante carpetas compartidas asignadas.
Aspecto
Passwork
Passbolt
Bitwarden
1Password
Keeper
La pertenencia a un grupo proporciona automáticamente nuevas claves de descifrado
No; aprobación por bóveda
No; nuevo cifrado por secreto
La clave de la organización ya está en su poder
Claves de bóveda asignadas
Claves de carpeta compartida asignadas
La sincronización de directorio completa el acceso sin intervención humana
No, en el caso de nuevas claves de bóveda
No
Sí
Sí
Sí
Principal coste de añadir un miembro
Clave envuelta por bóveda
Nuevo cifrado por secreto
Actualización de pertenencia
Claves para las bóvedas asignadas
Claves para las carpetas asignadas
Aprobación a nivel de contenedor
Sí
No
Pertenencia a la organización
Bóveda
Carpeta compartida
La disyuntiva está entre puntos de aprobación más estrictos y un aprovisionamiento más fluido. Passwork permite a las organizaciones elegir distintos equilibrios según el departamento; Passbolt ofrece un acceso granular por secreto a un coste de uso compartido más elevado.
Qué hace realmente el inicio de sesión de dominio
Una contraseña de dominio autentica a un usuario; no descifra los datos de la bóveda en ninguno de estos productos. Sus diferencias residen en cómo funcionan la autenticación y el aprovisionamiento mediante directorio.
Passwork autoalojado autentica directamente frente a LDAP o Active Directory, incluso en entornos con varios controladores de dominio. Los usuarios inician sesión con sus credenciales de dominio; los grupos de directorio pueden asignarse a grupos de Passwork. Con el cifrado del lado del cliente activado, la contraseña de dominio autentica la sesión, mientras que claves criptográficas independientes protegen el contenido de la bóveda.
En el momento de esta comparación, Passwork Cloud aún no ofrecía LDAP; estaba en la hoja de ruta, junto con el aprovisionamiento SCIM. Ambas implementaciones de Passwork admiten SSO mediante SAML 2.0.
Bitwarden Directory Connector sincroniza usuarios y grupos, pero no los autentica frente a LDAP, tal como explica su documentación. El inicio de sesión basado en dominio requiere SSO Enterprise mediante SAML u OIDC. Por lo general, los usuarios siguen desbloqueando su bóveda con una contraseña maestra, salvo que se configuren dispositivos de confianza o Key Connector.
Passbolt también separa la sincronización LDAP del inicio de sesión. Los usuarios se autentican mediante una clave privada y una frase de contraseña, o bien SSO, y añadir usuarios sincronizados a grupos con secretos existentes exige un nuevo cifrado.
1Password y Keeper utilizan servicios de bóveda basados en la nube con integración SSO. SSO Connect On-Prem de Keeper puede mantener ciertos componentes de identidad en el hardware de la empresa, pero su backend de bóveda cifrada permanece en la nube de Keeper. Keeper enumera los componentes locales compatibles en su documentación de implementación.
Aspecto
Passwork
Bitwarden
Passbolt
1Password
Keeper
Inicio de sesión directo con contraseña de dominio
LDAP/AD autoalojado
No; SSO
No; clave/frase de contraseña o SSO
SSO
SSO
Varios controladores de dominio
Sí
Solo sincronización
Solo sincronización
No aplicable
AD Bridge
Protocolo SSO documentado
SAML 2.0
SAML 2.0 u OIDC
OpenID Connect (OIDC)
OpenID Connect (OIDC)
SAML 2.0
Aprovisionamiento SCIM
Previsto
Sí
Sí
Sí
Sí
La contraseña de dominio descifra los registros
No
No
No
No
No
El inicio de sesión LDAP directo de Passwork puede simplificar las implementaciones autoalojadas sin necesidad de un proveedor de identidad independiente. Los competidores centrados en la nube ofrecen actualmente un aprovisionamiento de identidad automatizado más maduro; las funciones previstas de Passwork no deben considerarse disponibles en la actualidad.
Una sola API para contraseñas y secretos de máquina
Passwork gestiona las credenciales de los empleados y los secretos de máquina a través de la misma instancia, el mismo modelo de permisos, el mismo registro de auditoría y la misma API REST. Los equipos pueden respaldar flujos de trabajo de CI/CD sin necesidad de licenciar un producto de secretos independiente.
Sus clientes web, de escritorio, de navegador y móviles utilizan la misma API en /api/v1. Una CLI oficial y un conector de Python de código abierto respaldan los flujos de trabajo de DevOps. La CLI ofrece get y update para los registros, api para llamadas directas a los endpoints, y exec para recuperar y descifrar un secreto, exponer los valores como variables de entorno y ejecutar un comando. Las cuentas de servicio son usuarios con tokens de API creados por un administrador. Generar un nuevo token personal revoca las sesiones de API anteriores del usuario.
Este modelo unificado tiene limitaciones: la API funciona por sondeo (pull), sin webhooks salientes, y /v1/batch solo admite la agregación de lecturas, hasta 25 subsolicitudes GET. Las integraciones basadas en eventos deben sondear la API o consumir las exportaciones de syslog.
Los competidores adoptan enfoques distintos. Bitwarden Secrets Manager es un complemento de pago independiente con cuentas de máquina y acceso basado en proyectos, en lugar de acceso a través de las colecciones de Password Manager. Keeper Secrets Manager es otra línea de producto con SDK y una puerta de enlace conectada a la nube. Las cuentas de servicio de 1Password funcionan con bóvedas y permisos definidos, pero su alcance queda fijado al crear el token; para cambiarlo se necesita un nuevo token. Passbolt expone una API y herramientas de automatización, manteniendo su modelo de uso compartido por secreto.
Aspecto
Passwork
Bitwarden
Passbolt
1Password
Keeper
Secretos de empleados y de máquina
Una sola instancia
Password Manager más Secrets Manager
Un solo producto
Bóvedas más cuentas de servicio
Bóveda más Secrets Manager
Interfaz de automatización
API REST, CLI, conector de Python
API de gestión y CLI/SDK de Secrets Manager
API REST, CLI de administración
CLI, SDK, Connect
SDK, Commander
Identidad de máquina
Cuenta de servicio con token
Cuenta de máquina con ámbito de proyecto
Usuario con clave privada
Cuenta de servicio con ámbito fijo
Aplicación de Secrets Manager
Principal limitación
Sin webhooks; lotes de solo lectura
Suscripción de secretos independiente
Sobrecarga de uso compartido por secreto
Ámbito del token inmutable
Producto de secretos independiente
Passwork favorece un único sistema operativo para personas y automatización. Los productos de secretos especializados pueden ofrecer integraciones específicas, pero añaden licencias y superficies de gestión adicionales.
Dónde se ejecuta la bóveda
La implementación puede descartar productos de una preselección antes de comparar cualquier función. Passwork, Bitwarden y Passbolt permiten a las organizaciones alojar la propia bóveda. 1Password y Keeper mantienen el backend de la bóveda en sus servicios en la nube.
Passwork admite la implementación local en Linux, Windows Server o Docker, lo que otorga a las organizaciones control sobre su infraestructura y sus copias de seguridad. Su oferta en la nube alojada en la UE utiliza una base de datos y un tenant independientes para cada cliente, en lugar de almacenar los registros de todos los clientes en un único esquema compartido. Estas opciones se analizan en la guía de modelos de implementación de Passwork.
Bitwarden también ofrece un autoalojamiento genuino, aunque su licencia Enterprise sigue vinculada a una suscripción activa en la nube. Passbolt admite tanto el autoalojamiento como un servicio alojado. Los componentes de SSO e integración de Keeper, implementables localmente, no cambian la ubicación de su backend de bóveda.
Aspecto
Passwork
Bitwarden
Passbolt
1Password
Keeper
Bóveda autoalojada
Sí
Sí
Sí
No
No
Nube del proveedor
UE
Sí
Sí
Sí
Sí
Modelo de tenant en la nube
Base de datos independiente por tenant
Multiinquilino
Dedicado por suscripción
Multiinquilino
Multiinquilino
El autoalojamiento da a las organizaciones control sobre la ubicación de los datos, pero también la responsabilidad de las actualizaciones, las copias de seguridad y la disponibilidad. Los productos exclusivamente en la nube reducen esa carga allí donde la política permite el alojamiento externo.
Cifrado del lado del cliente opcional y metadatos
Passwork Cloud utiliza siempre el cifrado del lado del cliente. En la versión autoalojada, Passwork permite a los administradores desactivarlo. Los otros cuatro productos de esta comparación no ofrecen un interruptor equivalente.
El cifrado del lado del servidor puede resultar adecuado para un equipo pequeño con administradores de confianza que prioriza la concesión inmediata de acceso y una recuperación más sencilla. Desactivar el cifrado del lado del cliente elimina el aislamiento criptográfico por bóveda: los tipos de bóveda siguen controlando la creación y la administración, pero dejan de constituir límites de cifrado independientes.
Incluso con el cifrado del lado del cliente activado, el servidor de Passwork puede leer los nombres de los elementos, los inicios de sesión, las descripciones y las URL para habilitar la búsqueda en el servidor. Los valores de las contraseñas permanecen cifrados en el cliente y fuera del índice de búsqueda. Bitwarden y Keeper también cifran estos campos de metadatos, manteniéndolos ocultos para el servidor a costa de tener que descifrarlos en el cliente para poder buscar. Passbolt v5 deja sin cifrar los nombres de carpeta y las etiquetas.
Aspecto
Passwork
Bitwarden
Passbolt
1Password
Keeper
Desactivar el cifrado del lado del cliente
Solo en la versión autoalojada
No
No
No
No
Metadatos visibles para el servidor con el cifrado del lado del cliente
Nombre, inicio de sesión, descripción, URL
Ninguno de estos campos
Nombres de carpeta y etiquetas
Ninguno de estos campos
Ninguno de estos campos
Búsqueda
Servidor
Cliente
Cliente
Cliente
Cliente
Se trata de una contrapartida real entre seguridad y usabilidad. Los compradores deben evaluar tanto la confidencialidad de las contraseñas como la exposición de metadatos, especialmente cuando los registros contienen nombres de sistemas o identificadores de cuenta sensibles.
Qué cuesta
Estos son los precios de lista publicados por usuario y mes con facturación anual, a fecha de octubre de 2026. Los proveedores utilizan monedas y combinaciones de planes distintas, por lo que la comparación es orientativa.
Passwork Standard cuesta 3 € y Advanced, 4,50 € por usuario y mes. Advanced incluye gestión de secretos y funciones de identidad empresarial. Los clientes autoalojados también pueden optar por una licencia perpetua de pago único. Bitwarden Teams cuesta 4 $ y Enterprise, 6 $, con Secrets Manager con precio aparte de 6 $ y 12 $, respectivamente. Keeper Business parte de 4 $ y Enterprise de 6 $, mientras que KeeperPAM tiene un precio independiente. 1Password Business cuesta 8,99 $. Passbolt Pro autoalojado cuesta 4,50 € con un mínimo de diez usuarios.
Producto
Precio por usuario y mes
Condición relevante
Passwork Standard
3 €
En la nube o autoalojado
Passwork Advanced
4,50 €
SSO, asignación LDAP, secretos, clustering; opción de licencia perpetua autoalojada
Bitwarden Teams
4 $
Password Manager
Bitwarden Enterprise
6 $
SSO, políticas, autoalojamiento; Secrets Manager aparte
Keeper Business
4 €
Algunos informes y funciones de supervisión requieren un nivel superior
Keeper Enterprise
6 €
PAM con venta independiente
1Password Business
8,99 $
Bóveda en la nube
Passbolt Pro
4,50 €
Autoalojado; mínimo de diez usuarios
Bitwarden Secrets Manager cuesta 6 $ por usuario y mes en Teams, o 12 $ en Enterprise, facturado por separado de Password Manager. Las organizaciones que utilicen ambos productos deben comparar los costes de licencia combinados en función del número de usuarios de cada uno. Passwork Advanced incluye la gestión de contraseñas y de secretos en una sola suscripción. El modelo de cifrado por secreto de Passbolt añade trabajo administrativo al compartir secretos o añadir miembros a un grupo, un coste que los precios de suscripción por sí solos no reflejan.
Dónde tienen ventaja los competidores
Passbolt ofrece uso compartido y revocación directos por secreto. Cada destinatario recibe un texto cifrado con su clave pública. La revocación elimina del servicio la copia cifrada de ese destinatario. Esto permite un control granular, pero cada destinatario adicional exige trabajo de cifrado y almacenamiento. Como ocurre con otros gestores de contraseñas, la revocación no puede borrar el texto en claro ni las copias que un destinatario haya guardado previamente.
Passwork almacena un único texto cifrado compartido y distribuye claves envueltas, en lugar de duplicar cada secreto para cada destinatario. Al eliminar una concesión permanente de bóveda o carpeta se elimina el acceso a la clave correspondiente. Su bandeja de entrada funciona de otro modo: una entrega directa entre usuarios envuelve la clave de un elemento para el destinatario, y un elemento aceptado se convierte en una copia dentro de la bóveda del destinatario. La entrega a la bandeja de entrada de un grupo utiliza una vía sin cifrado del lado del cliente. Por lo tanto, la bandeja de entrada es una transferencia, no una concesión revocable de forma permanente.
Aspecto
Passwork
Passbolt
Datos almacenados por destinatario
Un único texto cifrado compartido, claves envueltas
Texto cifrado por destinatario
Compartir
Envolver una clave
Volver a cifrar el secreto
Revocar el acceso continuo
Eliminar el acceso a la clave envuelta
Eliminar la copia cifrada del destinatario
Entrega puntual
La bandeja de entrada crea una copia propiedad del destinatario al aceptarla
Uso compartido directo del elemento
Bitwarden y Keeper protegen metadatos que Passwork expone para la búsqueda en el servidor. Keeper también ofrece accesos directos a registros y permisos directos por registro en carpetas compartidas, además de una plataforma más amplia de acceso privilegiado. 1Password tiene menos reglas de herencia y excepciones, lo que facilita su configuración para equipos que no necesitan permisos de carpeta complejos. Bitwarden combina un precio de entrada bajo, autoalojamiento y clientes consolidados.
Se trata de ventajas sustanciales. La flexibilidad de Passwork ayuda a las organizaciones con estructuras de acceso complejas, pero también genera más políticas que diseñar y mantener.
Cómo elegir: Empiece por el límite
Comience por el escenario de fallo, no por el algoritmo de cifrado. Si se compromete una cuenta, ¿qué registros pueden descifrar sus claves? ¿Qué cambia si el atacante también obtiene una copia de seguridad de la base de datos? A continuación, compruebe si su modelo de permisos refleja los límites departamentales y si la incorporación de nuevos usuarios puede ampliar el acceso de forma involuntaria.
Passwork es adecuado para organizaciones que necesitan bóvedas departamentales independientes, permisos de carpeta heredados, autenticación LDAP directa en local, y credenciales de empleados y de máquina en un solo sistema. Passbolt favorece el control por secreto cuando el coste administrativo del uso compartido resulta aceptable. Bitwarden ofrece una distribución de claves sencilla para toda la organización y autoalojamiento. 1Password minimiza la complejidad de configuración en un modelo centrado en la nube. Keeper combina controles de carpeta compartida con una oferta más amplia de acceso privilegiado.
Si Finanzas, Recursos Humanos e Infraestructura son unidades operativas independientes, decida si también deben tener límites criptográficos independientes. Esa decisión determina la exposición potencial de una clave comprometida de forma más directa que una simple etiqueta AES-256.
¿Qué es un límite de cifrado en un gestor de contraseñas?
Es la cantidad de datos accesibles con una clave o un conjunto de claves determinado: una organización, una bóveda, una carpeta compartida o un secreto individual. La jerarquía de claves y el uso compartido determinan ese alcance.
¿Garantiza AES-256 un alcance de exposición reducido?
No. La fortaleza del cifrado no determina cuán ampliamente se comparten las claves. Productos que utilizan un cifrado robusto pueden exponer distintas cantidades de datos cuando se compromete una cuenta o una clave.
¿Puede un administrador autoalojado leer todas las contraseñas de una base de datos?
Depende del diseño de las claves y de las claves del administrador. En Bitwarden, un miembro de la organización con la clave de la organización y acceso a la base de datos puede descifrar los registros corporativos. En Passwork, con el cifrado del lado del cliente activado, las claves de un miembro solo desbloquean las bóvedas asignadas.
¿La pertenencia a un grupo LDAP concede automáticamente acceso a la bóveda?
En Passwork, con el cifrado del lado del cliente, las nuevas claves de bóveda requieren la aprobación de un titular de la clave. Otros productos pueden aprovisionar automáticamente las claves pertinentes o, en el caso de Passbolt, exigir un nuevo cifrado por secreto.
¿Puede una sola herramienta gestionar las contraseñas de los empleados y los secretos de DevOps?
Sí. Passwork admite ambos mediante una sola instancia, API REST, CLI y modelo de permisos. Otros productos pueden recurrir a ofertas de gestión de secretos independientes o a interfaces de automatización distintas.
¿Una contraseña de dominio descifra los datos de la bóveda?
No. Autentica al usuario directamente frente a LDAP/AD en el caso de Passwork autoalojado, o mediante SSO en otros productos. El descifrado depende de claves criptográficas independientes.
Cómo los gestores de contraseñas trazan el límite de cifrado
Todos los proveedores dicen «AES-256, conocimiento cero». Nada de eso indica qué puede abrir realmente una clave comprometida. Esta comparación plantea esa pregunta a Passwork, Bitwarden, Passbolt, 1Password y Keeper.
Business password managers often advertise AES-256 encryption and servers that never see plaintext passwords. But cipher strength alone does not tell you how much data one compromised key or misplaced group membership can expose.
That exposure depends on the encryption boundary: whether a key unlocks an organization, a vault, a shared folder, or an individual secret. This comparison examines where Passwork, Bitwarden, Passbolt, 1Password, and Keeper draw that boundary, and what their designs mean for permissions, directory login, automation, and deployment.
The question that reveals the encryption boundary
Imagine a self-hosted password manager. A sysadmin responsible for backups has a database dump and joins the corporate organization to access one shared password. What else could they decrypt using the keys available to their account?
Bitwarden encrypts corporate items with per-item keys wrapped by one organization symmetric key, according to its security white paper. Organization members receive usable access to that key, while collections control normal server-delivered access and permissions rather than creating separate cryptographic boundaries. In a self-hosted threat model, an attacker who obtains the relevant database ciphertexts and a member’s usable organization key could decrypt organization items outside that member’s assigned collections.
Passwork, with client-side encryption enabled, uses a separate key for each vault. Item keys sit under vault keys, and users receive a wrapped vault key only for vaults they can access. Under this zero-knowledge encryption model, the same sysadmin can decrypt their assigned vaults, but not unrelated Finance or Infrastructure vaults.
Passbolt encrypts each secret separately for each recipient using OpenPGP, as described in its security documentation (Pro v5.4, August 2025). There is no shared container key. Users can decrypt only secrets encrypted for them, although adding recipients requires more work.
1Password isolates data by vault, where permissions are also defined. Keeper uses record keys and shared-folder keys rather than one organization-wide key. Neither offers a self-hosted vault database for this particular test.
Aspect
Passwork
Bitwarden
Passbolt
1Password
Keeper
Encryption boundary
Vault
Organization
Individual secret
Vault
Shared folder and record
Database plus member key unlocks
Assigned vaults
Corporate records under the organization key
Secrets shared with that member
Not applicable: cloud vault
Not applicable: cloud vault
Exposure from one compromised member with database access
Assigned vaults
Organization
Assigned secrets
Not directly comparable
Not directly comparable
Passwork and Passbolt limit what a database dump plus one member's keys can reveal. Bitwarden simplifies key distribution but makes the organization key a broader cryptographic boundary. The cloud-only products avoid this specific database-access scenario, though their key architecture still matters.
In Passwork, a vault type defines who may create vaults in a class and which administrators are automatically assigned to new vaults of that type. With client-side encryption enabled, those administrators also receive wrapped copies of the new vault keys. The result is a repeatable policy for departments and projects.
For example, a Finance type can automatically assign the CFO to each new finance vault. A DevOps type can keep infrastructure administrators separate from sales. When a department head leaves, the company can reassign the type administrator and review grants within that area instead of auditing a sprawling global admin role. This becomes useful as teams and vault counts grow. See Passwork's vault policies.
Two built-in types avoid corporate administrators. A personal vault belongs to one user. A private shared vault lets that user invite others. By default, even the organization's Owner or Admin cannot read their contents. Administrators can configure who is allowed to create these vault types and share information from them, including disabling unmanaged personal vault creation.
There are two limits: assigning a type does not retroactively grant access to existing vaults, and types form cryptographic boundaries only when client-side encryption is enabled. Otherwise they remain governance rules.
The competitors offer related features, but not the same policy layer. Bitwarden enterprise policies govern matters such as authentication, recovery, and organization membership rather than automatically assigning administrators by vault class. Passbolt has no vault container to classify. 1Password provides vault-level isolation and personal vaults, but no equivalent class-wide rule for newly created vaults. Keeper's shared folders and teams manage access without typed vault creation policies.
Capability
Passwork
Bitwarden
Passbolt
1Password
Keeper
Vault classes with assigned administrators
Yes
No
No
No
No
Automatically attach admins to new vaults of a class
Yes
No
No
No
No
Control who creates a class
Per type
Partly, via organization policy
No
No
No
Personal space without a corporate admin
Personal and private shared vaults
My Items
Per-secret sharing
Personal vault
Personal folder
Control sharing from personal vaults by class
Yes
No equivalent
No equivalent
No equivalent
No equivalent
Vault types reduce the chance that newly created departmental vaults receive inconsistent administration. They add a policy decision upfront, but reduce repeated manual configuration later.
Folder permissions: Inheritance or templates?
A folder tree is useful only if its permissions behave as administrators expect. Similar-looking interfaces can enforce very different rules.
Passwork offers five permission levels—read, write, manage, admin, and forbidden—for users and groups at vault or folder level. Vault access flows into nested folders, while folder rules can narrow access. Admin and forbidden rights cannot be overridden further down. When multiple rules apply, the higher-priority level wins. Importantly, a folder is not a separate encryption boundary: access to its contents still relies on the vault key. This sits alongside Passwork's role-based access control model.
Bitwarden grants permissions through collections. Nested collections are organizational labels; they do not inherit their parent's items or rights. Personal folders have no sharing permissions. Individual member permissions override group permissions.
Passbolt uses folders as permission templates. When an item is created, moved, or shared, the folder's permissions are applied, but the item's own permissions determine subsequent access. A creator can become the owner of a password and restrict access even when someone else owns the folder. In a July 2026 community discussion about extension v5.14.2, Passbolt confirmed this behavior follows its permission model and said a UI change was planned to prevent non-owners editing permissions during creation.
1Password has no permission-bearing folders inside a vault; tags organize items without changing access. Sharing a subset of items permanently therefore requires another vault. Nested identity-provider groups are not supported for vault membership, according to a September 2026 community response.
Keeper supports nested shared folders and record-level permissions. Explicit record assignments override inherited folder rights. Its nested-folder model has a five-level depth limit and was behind a feature flag in vault release 18.0.0.
Aspect
Passwork
Bitwarden
Passbolt
1Password
Keeper
Internal structure
Folder tree
Collections
Permission-template folders
Tags
Nested shared folders
Inherited rights
Yes, with restrictions
No
No; permissions applied at creation or move
Not applicable
Yes, five levels, feature flag
Permission levels
Read, write, manage, admin, forbidden
View, hidden, edit, manage
Read, update, owner
View, create, edit, archive, delete, manage
Folder and record permissions
Individual record sharing
Shortcuts and inbox
Item in multiple collections
Direct item grant
No permanent item-level grant
Yes
Passwork's tree supports departmental structures and exceptions. Bitwarden and 1Password are simpler to administer but less flexible for deeply nested access. Passbolt's template behavior requires special attention because folder and item permissions can diverge.
Groups: what changes when someone joins?
With Passwork client-side encryption, adding someone to a group does not automatically give them every vault key associated with that group. It creates a pending request for each relevant vault. A key holder must approve the request before the new member can decrypt its contents.
This separates directory provisioning from cryptographic access. LDAP synchronization can place a new employee into groups, but access to sensitive vaults still requires approval. The distinction matters during onboarding and offboarding.
For teams that need less manual approval, Passwork offers another pattern: put the department's data in one vault and organize it into folders. Approve the user's vault key once; folder permissions then determine access within that vault as group membership changes. The trade-off is a wider shared cryptographic boundary than several separate vaults.
Passbolt cannot use this shortcut. Because each secret is encrypted for each recipient, adding a group member requires someone with access to re-encrypt the relevant secrets for that user. Directory synchronization notifies a group manager and waits for this step. The work scales with the number of secrets rather than the number of vaults.
Bitwarden already distributes the organization key to members, so collection assignments do not require new encryption keys. In 1Password, assigned vault keys follow group access. Keeper distributes access through assigned shared folders.
Aspect
Passwork
Passbolt
Bitwarden
1Password
Keeper
Group membership automatically supplies new decryption keys
No; per-vault approval
No; re-encrypt per secret
Organization key already held
Assigned vault keys
Assigned shared-folder keys
Directory sync completes access without human intervention
No, for new vault keys
No
Yes
Yes
Yes
Main cost of adding a member
Wrapped key per vault
Re-encryption per secret
Membership update
Keys for assigned vaults
Keys for assigned folders
Container-level approval
Yes
No
Organization membership
Vault
Shared folder
The choice is between tighter approval checkpoints and smoother provisioning. Passwork lets organizations choose different balances for different departments; Passbolt provides fine-grained per-secret access at a higher sharing cost.
What domain login actually does
A domain password authenticates a user; it does not decrypt vault data in any of these products. Their differences lie in how directory authentication and provisioning work.
Passwork self-hosted authenticates directly against LDAP or Active Directory, including environments with multiple domain controllers. Users sign in with domain credentials; directory groups can map to Passwork groups. With client-side encryption enabled, the domain password authenticates the session while separate cryptographic keys protect vault contents.
Passwork Cloud did not yet offer LDAP at the time of this comparison; it was on the roadmap, along with SCIM provisioning. Both Passwork deployments support SAML 2.0 SSO.
Bitwarden Directory Connector synchronizes users and groups but does not authenticate them against LDAP, as its documentation explains. Domain-based sign-in requires Enterprise SSO through SAML or OIDC. Users ordinarily still unlock their vault with a master password, unless trusted devices or Key Connector are configured.
Passbolt also separates LDAP synchronization from login. Users authenticate using a private key and passphrase or SSO, and adding synced users to groups with existing secrets requires re-encryption.
1Password and Keeper use cloud-based vault services with SSO integration. Keeper's SSO Connect On-Prem can keep certain identity components on company hardware, but its encrypted vault backend remains in Keeper's cloud. Keeper lists supported local components in its deployment documentation.
Aspect
Passwork
Bitwarden
Passbolt
1Password
Keeper
Direct domain-password login
Self-hosted LDAP/AD
No; SSO
No; key/passphrase or SSO
SSO
SSO
Multiple domain controllers
Yes
Sync only
Sync only
Not applicable
AD Bridge
Documented SSO protocol
SAML 2.0
SAML 2.0 or OIDC
OpenID Connect (OIDC)
OpenID Connect (OIDC)
SAML 2.0
SCIM provisioning
Planned
Yes
Yes
Yes
Yes
Domain password decrypts records
No
No
No
No
No
Passwork's direct LDAP login can simplify self-hosted deployments without a separate identity provider. Cloud-first competitors currently offer more mature automated identity provisioning; planned Passwork features should not be treated as available today.
One API for passwords and machine secrets
Passwork manages employee credentials and machine secrets through the same instance, permission model, audit log, and REST API. Teams can support CI/CD workflows without licensing a separate secrets product.
Its web, desktop, browser, and mobile clients use the same API at /api/v1. An official CLI and open-source Python connector support DevOps workflows. The CLI provides get and update for records, api for direct endpoint calls, and exec to retrieve and decrypt a secret, expose values as environment variables, and run a command. Service accounts are users with API tokens created by an administrator. Generating a new personal token revokes the user's previous API sessions.
This unified model has limitations: the API is pull-based, with no outbound webhooks, and /v1/batch supports read aggregation only, up to 25 GET subrequests. Event-driven integrations must poll or consume syslog exports.
Competitors take different approaches. Bitwarden Secrets Manager is a separate paid add-on with machine accounts and project-based access, rather than access through Password Manager collections. Keeper Secrets Manager is another product line with SDKs and a cloud-connected gateway. 1Password service accounts work with defined vaults and permissions, but their scope is fixed when a token is created; changing it requires a new token. Passbolt exposes an API and automation tooling while retaining its per-secret sharing model.
Aspect
Passwork
Bitwarden
Passbolt
1Password
Keeper
Employee and machine secrets
One instance
Password Manager plus Secrets Manager
One product
Vaults plus service accounts
Vault plus Secrets Manager
Automation interface
REST API, CLI, Python connector
Management API and Secrets Manager CLI/SDKs
REST API, admin CLI
CLI, SDKs, Connect
SDKs, Commander
Machine identity
Service account with token
Project-scoped machine account
User with private key
Fixed-scope service account
Secrets Manager application
Main limitation
No webhooks; read-only batch
Separate secrets subscription
Per-secret sharing overhead
Token scope immutable
Separate secrets product
Passwork favors a single operational system for people and automation. Specialized secrets products can offer dedicated integrations, but introduce additional licensing and management surfaces.
Where the vault runs
Deployment can eliminate products from a shortlist before any feature comparison. Passwork, Bitwarden, and Passbolt allow organizations to host the vault itself. 1Password and Keeper keep the vault backend in their cloud services.
Passwork supports on-premise deployment on Linux, Windows Server, or Docker, giving organizations control over their infrastructure and backups. Its EU-hosted cloud offering uses a separate database and tenant for each customer, rather than storing all customers' records in one shared schema. These options are discussed in Passwork's deployment models guide.
Bitwarden also offers genuine self-hosting, although its Enterprise license remains tied to an active cloud subscription. Passbolt supports self-hosting and a hosted service. Keeper's locally deployable SSO and integration components do not change the location of its vault backend.
Aspect
Passwork
Bitwarden
Passbolt
1Password
Keeper
Self-hosted vault
Yes
Yes
Yes
No
No
Vendor cloud
EU
Yes
Yes
Yes
Yes
Cloud tenant model
Separate database per tenant
Multi-tenant
Dedicated per subscription
Multi-tenant
Multi-tenant
Self-hosting gives organizations control over data location but also responsibility for updates, backups, and availability. Cloud-only products reduce that workload where policy permits external hosting.
Optional client-side encryption and metadata
Passwork Cloud always uses client-side encryption. Self-hosted Passwork lets administrators disable it. The other four products in this comparison do not offer an equivalent switch.
Server-side encryption can suit a small team with trusted administrators that prioritizes immediate access grants and simpler recovery. Disabling client-side encryption removes per-vault cryptographic isolation: vault types still control creation and administration, but no longer form separate encryption boundaries.
Even when client-side encryption is enabled, Passwork's server can read item names, logins, descriptions, and URLs to support server-side search. Password values remain encrypted on the client and outside the search index. Bitwarden and Keeper encrypt these metadata fields too, keeping them hidden from the server at the cost of client-side decryption for search. Passbolt v5 leaves folder names and tags unencrypted.
Aspect
Passwork
Bitwarden
Passbolt
1Password
Keeper
Disable client-side encryption
Self-hosted only
No
No
No
No
Metadata visible to server with client-side encryption
Name, login, description, URL
None of these fields
Folder names and tags
None of these fields
None of these fields
Search
Server
Client
Client
Client
Client
This is a real security and usability trade-off. Buyers should evaluate both password confidentiality and metadata exposure, especially when records contain sensitive system names or account identifiers.
What it costs
These are published list prices per user per month on annual billing, as of October 2026. Vendors use different currencies and packaging, so the comparison is directional.
Passwork Standard costs €3 and Advanced €4.50 per user per month. Advanced includes secrets management and enterprise identity features. Self-hosted customers can also choose a one-time lifetime license. Bitwarden Teams costs $4 and Enterprise $6, with Secrets Manager priced separately at $6 and $12, respectively. Keeper Business starts at $4 and Enterprise at $6, while KeeperPAM is priced separately. 1Password Business costs $8.99. Passbolt Pro self-hosted costs €4.50 with a ten-user minimum.
SSO, policies, self-hosting; Secrets Manager extra
Keeper Business
€4
Some reporting and monitoring require higher tier
Keeper Enterprise
€6
PAM sold separately
1Password Business
$8.99
Cloud vault
Passbolt Pro
€4.50
Self-hosted; ten-user minimum
Bitwarden Secrets Manager costs $6 per user per month on Teams or $12 on Enterprise, billed separately from Password Manager. Organizations using both products should compare combined licensing costs based on the number of users in each. Passwork Advanced includes password and secrets management in one subscription. Passbolt's per-secret encryption model adds administrative work when sharing secrets or adding group members, a cost that subscription prices alone cannot capture.
Where competitors have the advantage
Passbolt provides direct per-secret sharing and revocation. Each recipient gets a ciphertext encrypted with their public key. Revocation removes that recipient's encrypted copy from the service. This supports fine-grained control, but every additional recipient requires encryption and storage work. As with other password managers, revocation cannot erase plaintext or copies a recipient previously saved.
Passwork stores one shared ciphertext and distributes wrapped keys rather than duplicating every secret for each recipient. Removing a permanent vault or folder grant removes the relevant key access. Its inbox works differently: a direct user handoff wraps an item's key for the recipient, and an accepted item becomes a copy in the recipient's vault. Group inbox delivery uses a non-client-side-encryption path. Inbox is therefore a transfer, not a permanently revocable grant.
Aspect
Passwork
Passbolt
Data stored per recipient
One shared ciphertext, wrapped keys
Ciphertext per recipient
Share
Wrap a key
Re-encrypt the secret
Revoke ongoing access
Remove wrapped-key access
Remove recipient's ciphertext copy
One-off handoff
Inbox creates recipient-owned copy on acceptance
Direct item sharing
Bitwarden and Keeper protect metadata that Passwork exposes for server-side search. Keeper also offers record shortcuts and direct per-record permissions in shared folders, plus a broader privileged-access platform. 1Password has fewer inheritance rules and exceptions, making it easier to configure for teams that do not need complex folder permissions. Bitwarden combines low entry pricing, self-hosting, and established clients.
These are substantive advantages. Passwork's flexibility helps organizations with complex access structures, but also creates more policies to design and maintain.
How to choose: Start with the boundary
Begin with the failure scenario, not the encryption algorithm. If an account is compromised, what records can its keys decrypt? What changes if the attacker also obtains a database backup? Then check whether your permission model mirrors departmental boundaries and whether onboarding can accidentally expand access.
Passwork is suited to organizations that need separate departmental vaults, inherited folder permissions, direct LDAP authentication on-premise, and employee and machine credentials in one system. Passbolt favors per-secret control where the administrative cost of sharing is acceptable. Bitwarden offers straightforward organization-wide key distribution and self-hosting. 1Password minimizes configuration complexity in a cloud-first model. Keeper combines shared-folder controls with a wider privileged-access offering.
If Finance, HR, and Infrastructure are separate operational units, decide whether they should also have separate cryptographic boundaries. That decision determines the potential exposure of one compromised key more directly than an AES-256 label.
What is an encryption boundary in a password manager?
It is the amount of data accessible with a particular key or set of keys: an organization, vault, shared folder, or individual secret. Key hierarchy and sharing determine that scope.
Does AES-256 guarantee a small blast radius?
No. Cipher strength does not determine how broadly keys are shared. Products using strong encryption can expose different amounts of data when an account or key is compromised.
Can a self-hosted administrator read every password in a database?
That depends on the key design and the administrator's keys. In Bitwarden, an organization member with the organization key and database access can decrypt corporate records. In Passwork with client-side encryption enabled, a member's keys unlock only assigned vaults.
Does LDAP group membership automatically grant vault access?
In Passwork with client-side encryption, new vault keys require approval from a key holder. Other products may provision relevant keys automatically or, in Passbolt, require per-secret re-encryption.
Can one tool manage employee passwords and DevOps secrets?
Yes. Passwork supports both through one instance, REST API, CLI, and permission model. Other products may use separate secrets-management offerings or distinct automation interfaces.
Does a domain password decrypt vault data?
No. It authenticates the user directly against LDAP/AD in self-hosted Passwork or through SSO in other products. Decryption relies on separate cryptographic keys.
How password managers draw the encryption boundary
Every vendor says "AES-256, zero-knowledge." None of that tells you what one compromised key actually opens. We ran the question against Passwork, Bitwarden, Passbolt, 1Password and Keeper.
O Regulamento Geral sobre a Proteção de Dados (RGPD), a lei da UE em matéria de proteção de dados, exige um mecanismo lícito de transferência para o envio de dados pessoais para fora do Espaço Económico Europeu (EEE, a UE mais a Islândia, o Listenstaine e a Noruega) e medidas de segurança adequadas ao risco. Para uma gestão de palavras-passe em conformidade com o RGPD, é necessário conhecer todos os locais onde existem dados de credenciais e dispor de prova para cada um deles.
As credenciais podem estar armazenadas num centro de dados em Frankfurt e, ainda assim, ficar sujeitas a uma ordem judicial estrangeira, se o fornecedor estiver sujeito a uma jurisdição fora da UE. Uma etiqueta «alojado na UE» também nada diz sobre a localização das cópias de segurança. Este artigo apresenta o mapa de seis zonas dos dados de credenciais: os locais onde um gestor de palavras-passe empresarial guarda dados, o artigo do RGPD que cada local ativa e as evidências que é necessário conservar. Termina com um dossiê de evidências de 8 pontos, que pode ser verificado antes de uma auditoria.
Pontos principais
O RGPD regula a forma como os dados pessoais saem do EEE, e cada transferência exige um mecanismo lícito.
Uma credencial armazenada identifica, em regra, um colaborador, pelo que constitui um dado pessoal. A cifragem não altera esse facto.
Os dados de credenciais encontram-se em seis zonas: conteúdo do cofre, material de chaves, dados de serviço, cópias de segurança e réplicas, caches de cliente e subcontratantes ulteriores. Cada zona tem o seu próprio dever e a sua própria prova.
Se um fornecedor tratar qualquer zona, tem de assinar um acordo de tratamento de dados (DPA), um contrato que define o que pode fazer com os dados.
Ao optar por alojamento próprio, a organização assume as cópias de segurança, a recuperação de chaves e a manutenção de registos que, de outro modo, ficariam a cargo do fornecedor.
O registo de auditoria mostra quem abriu cada credencial e quando, o que ajuda a delimitar uma violação de dados e a decidir se se aplica a notificação no prazo de 72 horas.
O que exige a gestão de palavras-passe em conformidade com o RGPD
O RGPD exige que os dados pessoais sejam tratados de forma segura, com proteção de dados desde a conceção e protegidos por medidas adequadas ao risco.
A gestão de palavras-passe em conformidade com o RGPD implica poder demonstrar que os dados de credenciais são cifrados, acessíveis apenas a quem deles necessita, registados e abrangidos pelos contratos e registos adequados, onde quer que estejam armazenados.
A lei define o resultado a alcançar (artigos 5.º, n.º 1, alínea f), 25.º e 32.º). Cabe à organização escolher os controlos e provar que funcionam (artigo 5.º, n.º 2). Na prática, isto traduz-se em cinco requisitos:
Cifrar as credenciais armazenadas. O artigo 32.º, n.º 1, alínea a), refere «a pseudonimização e a cifragem dos dados pessoais» como medida adequada.
Limitar o acesso por função (RBAC). Cada pessoa inicia sessão com a sua própria conta e vê apenas o que a sua função exige, mesmo quando a credencial aberta é partilhada. Trata-se da proteção de dados desde a conceção (artigo 25.º) aplicada ao acesso.
Manter o serviço disponível e testado. O artigo 32.º, n.º 1, alíneas b) a d), abrange a resiliência, o restabelecimento do acesso após um incidente e os testes regulares das medidas.
Registar quem abriu o quê. Um registo de acessos mostra que credenciais foram acedidas e quando. É a evidência necessária para avaliar se uma violação afetou dados pessoais (artigo 33.º).
Documentar todos os locais onde os dados se encontram. Isto implica um registo das atividades de tratamento, um contrato com cada entidade externa que trate os dados e um mecanismo lícito para qualquer transferência para fora do EEE.
Estes deveres abrangem as palavras-passe por duas razões. Um registo de credencial identifica normalmente um colaborador ou remete para um, o que o torna um dado pessoal (artigo 4.º, n.º 1: qualquer informação relativa a uma pessoa identificável). As credenciais abrem também outros sistemas, como RH, CRM e bases de dados de clientes, onde se armazenam dados pessoais. O artigo 32.º, n.º 2, exige a avaliação do risco de acesso não autorizado a dados pessoais, pelo que uma violação do gestor de palavras-passe constitui uma via de violação para todos os sistemas que ele desbloqueia. A cifragem reduz o risco sem retirar o registo do âmbito de aplicação.
A organização é o responsável pelo tratamento do cofre, a entidade que decide por que razão e de que forma os dados de credenciais são utilizados. Um fornecedor ou prestador de alojamento que o explora ou apoia segundo as instruções da organização é um subcontratante, e o artigo 28.º exige um contrato com este. O artigo 30.º exige que se mantenha um registo das atividades de tratamento (RoPA) que enumere os destinatários, os locais e as transferências deste tratamento. Identificar esses locais é a primeira tarefa.
Residência, soberania e jurisdição são três conceitos distintos
Residência dos dados é o local onde os dados estão fisicamente armazenados. Soberania dos dados significa que os dados estão sujeitos às leis e ao controlo jurídico de um país escolhido. Jurisdição indica que tribunais e autoridades podem emitir ordens à empresa do fornecedor. Um fornecedor sujeito à lei dos EUA pode armazenar o cofre na Alemanha e, ainda assim, receber exigências legais dos EUA.
Termo
O que indica
O que deixa em aberto
Residência
Que país aloja os servidores
Que leis podem abranger os dados
Soberania
Leis de que país regem os dados
Se uma autoridade estrangeira ainda pode chegar ao fornecedor
Jurisdição
Que autoridades podem ordenar ao fornecedor que atue
Onde estão armazenados os dados
O CLOUD Act permite às autoridades dos EUA exigir aos fornecedores de serviços de comunicações eletrónicas ou de computação remota sob jurisdição dos EUA que entreguem os dados que se encontrem na sua posse, custódia ou controlo, mesmo quando estão armazenados no estrangeiro. Um fornecedor que seja uma empresa norte-americana ou tenha uma empresa-mãe nos EUA pode, por isso, receber tais exigências mesmo que o cofre esteja numa região da UE. Determinar se um dado fornecedor está abrangido pela lei é uma questão para a equipa jurídica.
O RGPD não contém qualquer regra geral de localização de dados. Regula as transferências para países terceiros no capítulo V (artigos 44.º a 50.º), e o acesso remoto a partir de fora do EEE, como o suporte do fornecedor, pode contar como transferência. Algumas regras nacionais e setoriais acrescentam exigências próprias de localização, pelo que convém verificar as que se aplicam à organização.
Transferências para fora do EEE: que mecanismos se aplicam
O capítulo V do RGPD exige um mecanismo lícito de transferência e garantias que se mantenham no país de destino. O acesso remoto de suporte a partir de fora do EEE a um cofre de palavras-passe alojado no seu interior conta como transferência, pelo que a região de alojamento, por si só, não resolve a questão. Existem três vias, e cada uma aplica-se a uma situação diferente.
Decisão de adequação (artigo 45.º). A Comissão Europeia declarou que a proteção do país de destino é equivalente. A decisão de 10 de julho de 2023 relativa ao Quadro de Proteção de Dados UE-EUA abrange apenas as empresas dos EUA que se autocertificaram, pelo que convém verificar a entrada do fornecedor na lista do quadro. Os quadros UE-EUA anteriores foram anulados em tribunal e o atual foi contestado, pelo que as cláusulas contratuais-tipo devem permanecer como solução de recurso no DPA.
Garantias adequadas (artigo 46.º). Normalmente, cláusulas contratuais-tipo (CCT), modelos de cláusulas contratuais aprovados pela Comissão, acompanhadas de uma avaliação de impacto da transferência (TIA). A TIA verifica se a legislação do país de destino permite às autoridades aceder aos dados. Decorre do acórdão Schrems II e das Recomendações 01/2020 do Comité Europeu para a Proteção de Dados (EDPB).
Derrogações (artigo 49.º). Exceções restritas, como o consentimento explícito depois de a pessoa ser informada dos riscos. Adequam-se a transferências ocasionais e não servem de base ao tratamento rotineiro por fornecedores.
Uma região de alojamento na UE reduz o risco sem o eliminar. O pessoal de suporte fora do EEE, os metadados tratados noutro local e uma empresa-mãe fora do EEE com acesso podem, cada um, originar uma transferência. O poder de uma autoridade estrangeira para ordenar a uma empresa-mãe a divulgação de dados constitui um risco de jurisdição distinto (ver a secção sobre residência acima). A região deve ser considerada um dos elementos da TIA, e não a sua conclusão.
O mapa de seis zonas dos dados de credenciais
O mapa de seis zonas dos dados de credenciais divide um gestor de palavras-passe empresarial em seis locais onde existem dados de credenciais. Cada zona pode situar-se num país diferente e tem o seu próprio dever ao abrigo do RGPD, pelo que verificar apenas «o servidor» deixa de fora cópias pelas quais a organização é responsável.
Zona
Significado simples
Dever ao abrigo do RGPD
1. Credenciais armazenadas
As credenciais de início de sessão, notas e ficheiros armazenados
Os fornecedores do fornecedor e o acesso de suporte
Art. 28.º, n.os 2 e 4, capítulo V
Um gestor de palavras-passe é um sistema de cópias. Algumas ficam com a organização, outras com o fornecedor e as restantes com os fornecedores deste. As cópias que ficam com a organização dependem do modelo de implementação. Numa implementação em alojamento próprio, a organização é o operador de todas as zonas, pelo que cada pergunta abaixo se aplica às equipas e aos prestadores de alojamento da própria organização, em vez de a um fornecedor.
Cada zona desencadeia também um dever diferente. As cópias de segurança originam deveres de eliminação no termo do contrato (artigo 28.º, n.º 3, alínea g)) e os fornecedores originam deveres que têm de ser transmitidos ao longo da cadeia (artigo 28.º, n.º 4). As seis subsecções seguintes abordam cada zona e o que solicitar.
Zona 1: Credenciais armazenadas
As credenciais armazenadas são o conteúdo que os utilizadores guardam: inícios de sessão, notas, anexos e os segredos subjacentes aos códigos de utilização única. Com a cifragem do lado do cliente, esse conteúdo chega ao servidor como texto cifrado, dados ilegíveis sem a chave. Uma cópia roubada da base de dados expõe, assim, apenas segredos ilegíveis, desde que a chave que desbloqueia a chave privada cifrada permaneça no dispositivo do utilizador (ver Zona 2).
As credenciais cifradas continuam a ser dados pessoais quando se relacionam com uma pessoa identificável, pelo que a Zona 1 permanece no âmbito. O artigo 32.º, n.º 1, alínea a), indica a cifragem como exemplo de medida adequada, e esta reduz o risco. Na entrada do RoPA relativa ao gestor de palavras-passe, deve registar-se a localização desta zona e o método de cifragem.
Os nomes dos registos, a estrutura de pastas e os metadados de auditoria são armazenados separadamente e pertencem à Zona 3. Devem ter uma linha própria no RoPA, com a mesma localização e os mesmos detalhes de acesso.
Zona 2: Material de chaves
O material de chaves é o conjunto de chaves criptográficas que desbloqueiam as credenciais armazenadas. Quem detiver as chaves pode ler os dados, onde quer que esteja o texto cifrado, pelo que a localização das chaves e os seus detentores importam tanto como a localização do servidor. O artigo 32.º, n.º 1, alínea a), só torna a cifragem adequada se as chaves forem controladas com o mesmo cuidado que os dados.
A cadeia segue esta ordem: palavra-passe mestra, chave mestra, chave privada, chaves de cofre, chaves de registo. A palavra-passe mestra do utilizador gera a chave mestra através de uma função como a PBKDF2, que torna lenta a tentativa de adivinhar palavras-passe. Essa chave decifra uma chave privada, que decifra as chaves de cofre, as quais, por sua vez, desbloqueiam as chaves de cada registo.
O servidor armazena a chave privada e as chaves de cofre de forma cifrada. A chave que as decifra permanece no dispositivo do utilizador, pelo que uma cópia da base de dados, por si só, não dá acesso.
A recuperação é o único percurso de chaves que merece ser mapeado em separado. Alguns modelos incluem uma conta de recuperação ou uma chave de escrow, para que uma organização possa restabelecer o acesso após a perda da palavra-passe mestra. Quem detiver essa chave também pode aceder ao texto simples, pelo que deve ser tratada como qualquer outra chave: quem a detém, onde está armazenada e que tribunais podem obrigar o seu detentor. O guia sobreo que a cifragem zero-knowledge protege e não protege explica o funcionamento.
Zona 3: Dados de serviço
Os dados de serviço são tudo o que o sistema regista sobre a utilização, e não sobre o conteúdo. A cifragem do lado do cliente não os abrange, pelo que o operador normalmente os consegue ler. Isso torna-os dados pessoais por direito próprio e a parte do sistema a que uma exigência legal pode chegar sem tocar na cifragem. Inclui, normalmente:
Identidades de contas, endereços de e-mail e registos de faturação
Endereços IP de início de sessão, identificadores de dispositivos e registos de data e hora dos acessos
Registos de auditoria, bem como nomes de registos e estrutura de pastas, se o produto não os cifrar
Aplicam-se três deveres. Os registos são a evidência para avaliar uma violação (artigos 32.º e 33.º). A conservação deve limitar-se ao necessário (artigo 5.º, n.º 1, alínea e)). Os colaboradores podem solicitar os seus próprios dados (artigo 15.º). Numa implementação em alojamento próprio, esta zona fica a cargo da própria organização.
Zona 4: Cópias de segurança, réplicas e recuperação de desastres
As cópias de segurança, as réplicas e os locais de recuperação de desastres (DR) são as cópias dos dados de credenciais que existem fora do servidor principal. Cada cópia pode situar-se num país diferente e sob um operador diferente, pelo que cada uma requer uma resposta própria sobre localização, cifragem e eliminação.
Cópias de segurança são cópias armazenadas para restaurar dados. Réplicas são cópias ativas noutros servidores. Os locais de recuperação de desastres (DR) são localizações de reserva. Apoiam a disponibilidade e a recuperação (artigo 32.º, n.º 1, alíneas b) e c)), mas cada cópia adicional alarga a superfície de ataque e o conjunto de jurisdições aplicáveis. Há três perguntas a colocar:
Onde está armazenada cada cópia de segurança e réplica, e alguma cópia sai da UE ou do EEE? Uma cópia num país terceiro pode contar como transferência ao abrigo do capítulo V.
As cópias de segurança são cifradas e as chaves são mantidas separadas dos dados?
Depois de terminado o contrato, em quantos dias desaparece a última cópia e como se verifica?
O artigo 28.º, n.º 3, alínea g), exige que o subcontratante, à escolha da organização, elimine ou devolva todos os dados pessoais quando os serviços terminam e elimine as cópias existentes, salvo se a lei exigir a sua conservação. As cópias de segurança estão abrangidas por esse dever. Na prática, expiram frequentemente num ciclo de rotação, pelo que o prazo de conservação é o valor que convém obter por escrito.
Zona 5: Caches de cliente e armazenamento offline
Alguns dados saem do servidor por conceção. As aplicações para computador e móveis podem manter cópias offline, as extensões de navegador podem guardar uma chave de sessão ou de desbloqueio, e os utilizadores podem exportar ficheiros de cofre. Cada uma é uma cópia fora dos controlos centrais e acompanha o dispositivo do colaborador para onde quer que vá.
Esta é a zona em que a política da própria organização mais importa. É necessário decidir se o modo offline é permitido, exigir a cifragem de disco através da gestão de dispositivos móveis (MDM) e restringir quem pode exportar. As exportações merecem o maior cuidado, uma vez que um ficheiro CSV pode ser lido por quem o abrir. Deve perguntar-se ao fornecedor se os administradores podem limitar o modo offline por função, se os dados em cache se apagam após um período definido e se a utilização offline e as exportações são registadas.
Um dispositivo perdido com uma cópia do cofre constitui um risco nos termos do artigo 32.º, n.º 2, que refere a perda e a divulgação não autorizada, e pode desencadear os deveres de notificação de violações previstos nos artigos 33.º e 34.º. Os terminais e os locais de exportação aprovados devem ser listados no RoPA.
Zona 6: Subcontratantes ulteriores e acesso de suporte
Os subcontratantes ulteriores são os fornecedores que um fornecedor utiliza para prestar o serviço, como alojamento, envio de e-mail, monitorização e ferramentas de suporte. Ao abrigo do artigo 28.º, n.os 2 e 4, o subcontratante necessita da autorização da organização para os contratar e tem de transmitir os mesmos deveres de proteção de dados ao longo da cadeia.
Terceiros estiveram envolvidos em 48 % das violações no DBIR de 2026 da Verizon, um aumento de 60 % face ao ano anterior. O relatório agrupa estes casos em três arquétipos: um fornecedor na cadeia de fornecimento de software, um fornecedor que aloja os dados no seu ambiente e um fornecedor com ligação ao ambiente da organização. Um gestor de palavras-passe alojado é do segundo tipo, e uma ligação de suporte ou de integração aos sistemas da organização pode torná-lo do terceiro. Os fornecedores do fornecedor devem ser verificados tão rigorosamente como o seu produto.
Há quatro elementos a solicitar:
Uma lista atual de subcontratantes ulteriores e do país em que cada um opera
Aviso prévio de alterações, com direito de oposição
Quem, na equipa de suporte do fornecedor, pode ver os dados de serviço (Zona 3) e mediante que aprovação
Se algum subcontratante ulterior ou via de suporte pode aceder ao material de chaves (Zona 2)
Mapa de zonas e artigos: A obrigação e a evidência
O mapa de zonas e artigos associa cada uma das seis zonas de credenciais à disposição do RGPD que ativa, ao documento que comprova a conformidade e à parte responsável por essa obrigação. Serve de base para a entrada do RoPA relativa ao gestor de palavras-passe, e a coluna de evidências deve ser preenchida antes de um auditor perguntar. O dossiê de evidências no final lista os mesmos documentos como lista de verificação.
Zona
Base no RGPD
Evidências a conservar
Responsável
1. Credenciais armazenadas
Art. 32.º, n.º 1, al. a); art. 30.º
Descrição da cifragem, entrada do RoPA
Decide o responsável pelo tratamento, implementa o subcontratante
2. Material de chaves
Art. 32.º, n.º 1, al. a); art. 25.º
Hierarquia de chaves e conceção da recuperação
Subcontratante, revisto pelo responsável pelo tratamento
Localização das cópias de segurança, prazo de conservação, condições de eliminação
Subcontratante, verificado pelo responsável pelo tratamento
5. Caches de cliente
Art. 32.º, n.º 2; arts. 33.º e 34.º
Política de dispositivos, regras de exportação
Responsável pelo tratamento
6. Subcontratantes ulteriores
Art. 28.º, n.os 2 e 4
Lista de subcontratantes ulteriores, aviso de alterações
Subcontratante, aprovado pelo responsável pelo tratamento
A repartição determina quem notifica. Nos termos do artigo 33.º, o responsável pelo tratamento notifica a autoridade de controlo no prazo de 72 horas após ter tomado conhecimento de uma violação, sempre que possível. O subcontratante tem de informar a organização «sem demora injustificada», o que não fixa qualquer prazo, pelo que se deve inscrever no DPA um prazo de notificação. Em alojamento próprio, a organização é simultaneamente responsável pelo tratamento e operador, e a coluna Responsável reduz-se às suas próprias equipas.
O DPA a obter de um fornecedor de gestores de palavras-passe
Um acordo de tratamento de dados (DPA) é o contrato que o artigo 28.º, n.º 3, exige entre um responsável pelo tratamento e um subcontratante. No caso de um fornecedor de gestores de palavras-passe, deve indicar o objeto, a duração, a natureza, a finalidade, os tipos de dados e as categorias de titulares dos dados, além de oito obrigações nas alíneas a) a h). As Diretrizes 07/2020 do EDPB sobre responsáveis pelo tratamento e subcontratantes explicam cada uma delas.
Termo
Artigo
O que solicitar ao fornecedor
Instruções documentadas
28.º, n.º 3, al. a)
Tratamento apenas mediante instruções escritas da organização, incluindo as transferências para países terceiros, e dever de informar de imediato se uma instrução violar a lei
Confidencialidade
28.º, n.º 3, al. b)
Todas as pessoas autorizadas a tratar os dados, incluindo o pessoal de suporte, vinculadas à confidencialidade
Medidas de segurança
28.º, n.º 3, al. c)
As medidas do artigo 32.º, enumeradas num anexo
Subcontratantes ulteriores
28.º, n.º 3, al. d), e n.os 2 e 4
Autorização da organização, aviso de alterações com direito de oposição, transmissão das mesmas obrigações
Direitos dos titulares dos dados
28.º, n.º 3, al. e)
Ajuda para responder a pedidos de acesso e de apagamento
Assistência
28.º, n.º 3, al. f)
Ajuda em matéria de segurança, notificação de violações e avaliações de impacto (artigos 32.º a 36.º)
Eliminação ou devolução
28.º, n.º 3, al. g)
Eliminação ou devolução, à escolha da organização, no termo do contrato, com prazo definido para as cópias de segurança
Auditorias
28.º, n.º 3, al. h)
Informações que comprovem a conformidade e auditorias, incluindo inspeções
A linha das auditorias exige a leitura mais atenta. O artigo 28.º, n.º 3, alínea h), exige que o contrato faculte as informações que comprovam a conformidade e permita auditorias, incluindo inspeções. Se o fornecedor não abrir a sua infraestrutura a inspeções presenciais, o contrato deve indicar o que as substitui.
As evidências a analisar incluem, assim, a lista de subcontratantes ulteriores, uma avaliação de transferências e os relatórios de auditoria a que o contrato dá direito. Devem juntar-se os registos próprios do cofre, exportados para um SIEM (um sistema que recolhe e analisa registos de segurança).
Modelos de implementação da gestão de palavras-passe em conformidade com o RGPD
O modelo de implementação determina quais das seis zonas a equipa controla. Uma cloud de fornecedor deixa a maioria das zonas com o fornecedor, uma cloud numa região da UE reduz os locais onde se situam e o alojamento próprio transfere-as para a infraestrutura e para a lista de deveres da organização. As configurações air-gapped vão mais longe e acrescentam o tratamento offline de atualizações e registos.
Opção
Onde se encontram os dados
Posição quanto a transferências
Deveres herdados
Cloud do fornecedor, qualquer região
À escolha do fornecedor
Mecanismo e TIA se os dados ou o acesso saírem do EEE
DPA, análise de subcontratantes ulteriores, prazo de notificação de violações
Cloud em região da UE
Região da UE escolhida
Menor exposição, mas não nula
DPA, análise de subcontratantes ulteriores, condições de acesso de suporte
Alojamento soberano da UE
Fornecedor da UE, de capital da UE
A menor para um serviço alojado
DPA, auditoria ao fornecedor
Alojamento próprio on-premises
A infraestrutura da organização
Nenhuma, salvo se o acesso de suporte ou as cópias de segurança saírem do EEE
Cópias de segurança, chaves, aplicação de patches, registos
Air-gapped
Rede isolada
Nenhuma
Deveres do alojamento próprio, mais atualizações offline
Um serviço gerido pelo fornecedor oferece menos controlo sobre os formatos de exportação e o momento da saída. Antes de assinar, convém verificar como se poderia sair: que formatos se podem exportar e qual o prazo para eliminar as cópias de segurança nos termos do artigo 28.º, n.º 3, alínea g).
Alojamento próprio e RGPD: Que deveres se assumem
O alojamento próprio transfere os deveres do RGPD de um contrato com um fornecedor para os procedimentos operacionais da própria organização. A organização controla onde se situa cada zona e quem a opera, o que pode eliminar a relação de subcontratação para o próprio cofre. Passa também a ser o operador, pelo que assegura as evidências por si. A página sobre o gestor de palavras-passe on-premise descreve esta opção de implementação.
O que se ganha:
Controlo sobre o local onde se situa cada zona, incluindo as cópias de segurança
Nenhuma transferência para um fornecedor e nenhuma cadeia de subcontratantes ulteriores para o próprio cofre
O que passa a ser devido:
Localizações das cópias de segurança e das réplicas, restauros testados e um calendário de conservação
Procedimentos de recuperação de chaves, aplicação de patches e alta disponibilidade
Um registo atualizado das atividades de tratamento (artigo 30.º)
Um processo próprio de deteção e notificação de violações (artigo 33.º)
Exemplo hipotético: uma equipa restaura um cofre após uma falha de servidor e descobre que a tarefa de cópia de segurança noturna estava a gravar num armazenamento num segundo país, configurado anos antes por alguém que entretanto saiu. O cofre estava on-premises, mas uma cópia nunca esteve. Essa cópia é uma questão de transferência nos termos do capítulo V. Uma verificação zona a zona encontra-a antes de um incidente.
O risco interno permanece com a organização. A cifragem do lado do cliente impede os administradores de ler o conteúdo do cofre, mas estes continuam a poder eliminar dados, copiar texto cifrado e cópias de segurança, alterar a configuração ou editar registos. Convém segregar funções e registar as ações dos administradores.
As implementações air-gapped acrescentam outro dever. Sem ligação à internet, as atualizações são aplicadas e os registos movidos manualmente. O isolamento não elimina vulnerabilidades, e os suportes de dados transportados para dentro tornam-se o meio pelo qual uma atualização chega ao sistema.
O artigo 32.º, n.º 1, exige medidas adequadas ao risco. Deve documentar-se quem aprova um pacote de atualização, como se verifica a sua integridade antes da importação, com que frequência os registos saem da rede e quem trata dos suportes de dados. O procedimento de restauro também deve ser testado, uma vez que as alíneas c) e d) do n.º 1 do artigo 32.º abrangem o restabelecimento da disponibilidade e o teste regular das medidas.
Como o Passwork gere a localização e o acesso aos dados
O Passwork Self-hosted funciona numa infraestrutura sob o controlo da organização: servidores on-premises, uma cloud privada ou uma rede air-gapped. O cofre, as chaves e as cópias de segurança ficam onde a organização os colocar, pelo que é a equipa que decide onde se situa cada zona. As respostas abaixo seguem as seis zonas e as perguntas formuladas acima.
O Passwork instala-se com Docker em Linux (a via recomendada), com um script PowerShell em Windows Server ou manualmente, e existem pacotes offline para redes air-gapped. Os guias técnicos do Passwork abordam cada via.
Conteúdo do cofre e chaves (zonas 1 e 2). Os dados são cifrados no cliente com AES-256, pelo que o servidor armazena apenas texto cifrado e material de chaves cifrado. A chave mestra é derivada com PBKDF2 e nunca sai do dispositivo do utilizador em texto simples. Uma segunda camada AES-256, independente, protege a base de dados no servidor.
A arquitetura zero-knowledge determina quem pode ler os dados: apenas os utilizadores que detêm as chaves, pelo que nem os próprios administradores da organização conseguem ler o conteúdo do cofre. A recuperação faz-se através de uma conta de recuperação previamente criada, cuja palavra-passe mestra é guardada offline, e é a organização que decide quem a detém.
Dados de serviço (zona 3). O «Activity Log» (registo de atividade) regista as ações de utilizadores, administradores e do sistema, e os seus registos de auditoria estão preparados para integração com SIEM. Os nomes de registos e de pastas, a estrutura de acessos e os metadados de auditoria ficam no servidor, pelo que devem constar do RoPA. A política de conservação é definida pela organização, que mantém os registos no seu próprio armazenamento.
Cópias de segurança e réplicas (zona 4). Os replica sets do MongoDB com três ou mais membros votantes, em conjunto com servidores de aplicação escalados horizontalmente, conferem ao serviço tolerância a falhas para mais de 10 000 utilizadores. Tarefas agendadas em segundo plano criam e fazem a rotação dos ficheiros de cópia de segurança, e é a organização que escolhe onde são armazenados.
Caches de cliente e armazenamento offline (zona 5). O modo offline é só de leitura e requer ativação expressa em dois níveis: o utilizador marca um registo e depois ativa o modo offline num dispositivo específico. Os administradores controlam as funções que o podem utilizar, o número máximo de registos por dispositivo e o tempo máximo sem sincronização antes de um apagamento automático. Os descarregamentos e as visualizações offline são sincronizados com o «Activity Log» e com o «Security Dashboard» (painel de segurança) quando o dispositivo volta a ligar-se.
Subcontratantes ulteriores (zona 6). Uma implementação em alojamento próprio não tem subcontratantes ulteriores alojados por um fornecedor. A lista de fornecedores limita-se aos prestadores de alojamento e de cópias de segurança da própria organização, e as mesmas perguntas acima aplicam-se-lhes. Um prestador de cloud privada que opere o cofre para a organização é o seu subcontratante e necessita de um DPA próprio.
O acesso segue o princípio do menor privilégio. O controlo de acesso baseado em funções (RBAC) define os níveis de acesso a cofres e pastas, a sincronização de grupos LDAP e Active Directory transpõe as alterações do diretório para o Passwork e o SAML SSO trata do início de sessão. O Passwork está certificado ISO 27001, é testado através da HackerOne e o seu código-fonte está disponível para auditoria independente.
Se o caso de conformidade depender de onde se situam o cofre, as chaves e as cópias de segurança, convém testá-lo no próprio ambiente. Experimentar o Passwork grátis.
Dossiê de evidências do RGPD para a gestão de palavras-passe
O dossiê de evidências de 8 pontos é o conjunto de documentos que se deve possuir antes de uma auditoria ao gestor de palavras-passe ao abrigo do RGPD. Abrange registos de tratamento, condições do fornecedor, avaliações de transferências, localização das cópias de segurança, revisões de acessos e procedimentos de violação. Os pontos 1 a 6 correspondem a zonas individuais, enquanto os pontos 7 e 8 abrangem o acesso e a gestão de violações em todas elas.
Entrada do registo das atividades de tratamento para o gestor de palavras-passe, com as seis zonas (artigo 30.º)
DPA assinado que abranja as condições do artigo 28.º, n.º 3, se um fornecedor ou prestador de alojamento tratar qualquer zona
Lista atual de subcontratantes ulteriores e cláusula de aviso de alterações, na mesma condição
Avaliação de impacto da transferência, se alguma zona envolver um país terceiro (capítulo V)
Avaliação de impacto sobre a proteção de dados, se a análise de risco o exigir (artigo 35.º)
Mapa de cópias de segurança e réplicas, com localizações e condições de eliminação
Revisão das permissões do cofre, realizada a partir de exportações do registo de auditoria
Procedimento de violação em 72 horas que indique quem decide e quem notifica (artigo 33.º)
O RGPD não fixa qualquer intervalo para as revisões de acessos. A cadência trimestral é comum, pelo que convém definir uma adequada ao risco e documentá-la.
O registo de auditoria é a evidência que sustenta os pontos 7 e 8. Mostra quem acedeu a que credencial e quando, o que ajuda a delimitar uma violação e a avaliar se os dados pessoais podem ter sido afetados. Deve ser exportado para um SIEM, para sobreviver ao cofre e alimentar o registo de violações exigido pelo artigo 33.º, n.º 5.
Por onde começar na gestão de palavras-passe em conformidade com o RGPD
A gestão de palavras-passe em conformidade com o RGPD começa por adequar a implementação aos dados que não podem sair da jurisdição da organização. Depois, é necessário dispor de um contrato ou registo para cada zona que um fornecedor trata: onde se situam o conteúdo, as chaves, os dados de serviço, as cópias de segurança, as caches e os subcontratantes ulteriores, e o que abrange cada um.
Comece por uma única página. Desenhe as seis zonas do gestor de palavras-passe atual e assinale aquelas a que não consegue responder. Essas são as primeiras perguntas a colocar ao fornecedor ou, em alojamento próprio, as primeiras tarefas internas. Depois de completo o mapa, o guia de segurança de palavras-passe segundo o RGPD aborda o nível seguinte: regras de palavras-passe e práticas do pessoal.
O RGPD exige que os dados de palavras-passe sejam armazenados na UE?
Não, como regra geral. O RGPD não impõe uma exigência generalizada de localização de dados. Restringe as transferências de dados pessoais para fora do EEE e exige um mecanismo lícito, como uma decisão de adequação ou cláusulas contratuais-tipo apoiadas por uma avaliação de impacto da transferência (artigos 44.º a 49.º). Regras nacionais ou setoriais podem acrescentar limites.
Uma palavra-passe armazenada é um dado pessoal ao abrigo do RGPD?
Em regra, sim. Um registo de credencial inclui normalmente um nome de utilizador, um e-mail ou um histórico de acessos que identifica uma pessoa, pelo que fica abrangido pelos deveres dos artigos 5.º, n.º 1, alínea f), 25.º e 32.º. Os dados cifrados continuam a ser dados pessoais. A cifragem é uma medida de proteção e não retira os dados do âmbito do regulamento.
A cifragem zero-knowledge torna uma organização conforme com o RGPD?
Não. Protege o conteúdo do cofre, que constitui uma das medidas previstas no artigo 32.º. Quando um fornecedor aloja o serviço, metadados como identidades de contas, endereços IP de início de sessão e registos de data e hora dos acessos permanecem tipicamente legíveis para o prestador. Os deveres relativos a contratos, registos de tratamento e notificação de violações continuam a aplicar-se.
É necessário um acordo de tratamento de dados com o fornecedor do gestor de palavras-passe?
Sim, se o fornecedor tratar dados pessoais por conta da organização. Passa então a ser subcontratante, e o artigo 28.º, n.º 3, exige um contrato que abranja instruções documentadas, confidencialidade, segurança, subcontratantes ulteriores, direitos dos titulares dos dados, eliminação ou devolução e direitos de auditoria. Uma implementação em alojamento próprio sem acesso do fornecedor pode não necessitar de nenhum. Convém confirmar com a equipa jurídica.
O que tem de ser documentado ao abrigo do artigo 32.º?
O artigo 32.º exige medidas adequadas ao risco, como a cifragem, a pseudonimização, a resiliência e os testes regulares. O dever de responsabilização previsto no artigo 5.º, n.º 2, implica que seja possível demonstrá-las. Na prática, convém manter um registo das medidas, a prova de que estão em funcionamento e as exportações do registo de auditoria.
Gestão de palavras-passe conforme com o RGPD: onde estão os dados
Um cofre em Frankfurt pode responder a uma ordem judicial estrangeira, e o selo «alojado na UE» nada diz sobre onde estão as cópias de segurança. Use o mapa de seis zonas para encontrar todos os locais das suas credenciais, o dever do RGPD de cada um e as provas a reunir antes de uma auditoria.
Die Datenschutz-Grundverordnung (DSGVO), das Datenschutzgesetz der EU, verlangt für die Übermittlung personenbezogener Daten außerhalb des Europäischen Wirtschaftsraums (EWR, die EU plus Island, Liechtenstein und Norwegen) eine Rechtsgrundlage für die Übermittlung sowie Sicherheitsmaßnahmen, die dem Risiko angemessen sind. Kennen Sie für DSGVO-konformes Passwortmanagement jeden Ort, an dem Ihre Zugangsdaten vorliegen, und halten Sie für jeden einen Nachweis bereit.
Ihre Zugangsdaten können in einem Rechenzentrum in Frankfurt gespeichert sein und trotzdem einer ausländischen Gerichtsanordnung unterliegen, wenn der Anbieter einer Jurisdiktion außerhalb der EU unterliegt. Ein Label „EU-gehostet" sagt zudem nichts darüber aus, wo die Backups liegen. Dieser Artikel stellt die Sechs-Zonen-Karte der Zugangsdaten vor: die Orte, an denen ein Passwortmanager für Unternehmen Daten speichert, den DSGVO-Artikel, den jeder Ort auslöst, und die Nachweise, die Sie bereithalten müssen. Er schließt mit einem 8-Punkte-Evidenzpaket, das Sie vor einem Audit prüfen können.
Das Wichtigste in Kürze
Die DSGVO regelt, wie personenbezogene Daten den EWR verlassen, und jede Übermittlung benötigt eine Rechtsgrundlage.
Gespeicherte Zugangsdaten identifizieren in der Regel einen Mitarbeiter und sind damit personenbezogene Daten. Verschlüsselung ändert daran nichts.
Zugangsdaten liegen in sechs Zonen: Tresorinhalt, Schlüsselmaterial, Servicedaten, Backups und Replikate, Client-Caches und Unterauftragsverarbeiter. Jede Zone hat ihre eigene Pflicht und ihren eigenen Nachweis.
Verarbeitet ein Anbieter eine dieser Zonen, muss er einen Auftragsverarbeitungsvertrag (AVV) unterschreiben – einen Vertrag, der festlegt, was er mit Ihren Daten tun darf.
Beim Self-Hosting übernehmen Sie Backups, Schlüsselwiederherstellung und Dokumentation, die sonst ein Anbieter übernehmen würde.
Ihr Audit-Protokoll zeigt, wer welche Zugangsdaten wann geöffnet hat. Das hilft Ihnen, das Ausmaß einer Datenschutzverletzung einzuschätzen und zu entscheiden, ob die 72-Stunden-Meldepflicht greift.
Was DSGVO-konformes Passwortmanagement erfordert
Die DSGVO verlangt, dass personenbezogene Daten sicher verarbeitet werden, dass der Datenschutz von Anfang an mitgedacht wird und dass Maßnahmen greifen, die dem Risiko angemessen sind.
DSGVO-konformes Passwortmanagement bedeutet, dass Sie nachweisen können, dass Zugangsdaten verschlüsselt sind, nur für Personen erreichbar sind, die sie benötigen, protokolliert werden und überall, wo sie gespeichert sind, durch die richtigen Verträge und Aufzeichnungen abgedeckt sind.
Das Gesetz legt das Ergebnis fest (Artikel 5(1)(f), 25 und 32). Sie wählen die Maßnahmen und weisen nach, dass sie funktionieren (Artikel 5(2)). In der Praxis ergeben sich daraus fünf Anforderungen:
Gespeicherte Zugangsdaten verschlüsseln. Artikel 32(1)(a) nennt „die Pseudonymisierung und Verschlüsselung personenbezogener Daten" als geeignete Maßnahme.
Zugriff über Rollen begrenzen (rollenbasierte Zugriffskontrolle, RBAC). Jede Person meldet sich unter ihrem eigenen Konto an und sieht nur, was ihre Aufgabe erfordert, selbst wenn die geöffneten Zugangsdaten gemeinsam genutzt werden. Das ist Datenschutz durch Technikgestaltung (Artikel 25), angewendet auf den Zugriff.
Den Dienst verfügbar halten und testen. Artikel 32(1)(b) bis (d) umfasst Belastbarkeit, die Wiederherstellung des Zugriffs nach einem Vorfall und die regelmäßige Überprüfung der Maßnahmen.
Aufzeichnen, wer was geöffnet hat. Ein Zugriffsprotokoll zeigt, auf welche Zugangsdaten wann zugegriffen wurde. Das ist der Nachweis, den Sie brauchen, um zu beurteilen, ob eine Datenschutzverletzung personenbezogene Daten betroffen hat (Artikel 33).
Jeden Ort dokumentieren, an dem die Daten liegen. Das bedeutet ein Verzeichnis von Verarbeitungstätigkeiten, einen Vertrag mit jeder externen Partei, die die Daten verarbeitet, und eine Rechtsgrundlage für jede Übermittlung außerhalb des EWR.
Diese Pflichten erfassen Passwörter aus zwei Gründen. Ein Zugangsdatensatz nennt normalerweise einen Mitarbeiter oder verweist auf einen, was ihn zu personenbezogenen Daten macht (Artikel 4(1): jede Information, die sich auf eine identifizierbare Person bezieht). Die Zugangsdaten öffnen außerdem andere Systeme, etwa HR-, CRM- und Kundendatenbanken, in denen personenbezogene Daten gespeichert sind. Artikel 32(2) verlangt, dass Sie das Risiko eines unbefugten Zugriffs auf personenbezogene Daten bewerten – eine Datenschutzverletzung beim Passwortmanager ist damit ein Einstiegspunkt in jedes System, das er entsperrt. Verschlüsselung senkt das Risiko, nimmt den Datensatz aber nicht aus dem Anwendungsbereich.
Ihre Organisation ist der Verantwortliche für den Tresor, also die Stelle, die entscheidet, warum und wie die Zugangsdaten verwendet werden. Ein Anbieter oder Hosting-Anbieter, der ihn auf Ihre Anweisung betreibt oder unterstützt, ist Auftragsverarbeiter, und Artikel 28 verlangt dafür einen Vertrag. Artikel 30 verlangt, dass Sie ein Verzeichnis von Verarbeitungstätigkeiten (VVT) führen, das die Empfänger, Standorte und Übermittlungen dieser Verarbeitung auflistet. Diese Standorte zu finden, ist die erste Aufgabe.
Residenz, Souveränität und Jurisdiktion sind drei verschiedene Dinge
Datenresidenz bezeichnet, wo Ihre Daten physisch gespeichert sind. Datensouveränität bedeutet, dass die Daten den Gesetzen und der Rechtskontrolle eines bestimmten Landes unterliegen. Jurisdiktion ist, welche Gerichte und Behörden dem Unternehmen des Anbieters Anordnungen erteilen können. Ein Anbieter, der US-Recht unterliegt, kann Ihren Tresor in Deutschland speichern und trotzdem US-Rechtsforderungen erhalten.
Begriff
Was er Ihnen sagt
Was er offenlässt
Datenresidenz
Welches Land die Server hostet
Welche Gesetze auf die Daten zugreifen können
Datensouveränität
Welches Landesrecht für die Daten gilt
Ob eine ausländische Behörde den Anbieter trotzdem erreichen kann
Jurisdiktion
Welche Behörden den Anbieter zum Handeln verpflichten können
Wo Ihre Daten gespeichert sind
Der CLOUD Act erlaubt es US-Behörden, Anbieter elektronischer Kommunikations- oder Remote-Computing-Dienste, die der US-Jurisdiktion unterliegen, zur Herausgabe von Daten zu verpflichten, die sich in ihrem Besitz, ihrer Verwahrung oder ihrer Kontrolle befinden – auch wenn diese im Ausland gespeichert sind. Ein Anbieter, der ein US-Unternehmen ist oder eine US-Muttergesellschaft hat, kann daher solchen Forderungen ausgesetzt sein, während Ihr Tresor in einer EU-Region liegt. Ob ein bestimmter Anbieter unter das Gesetz fällt, ist eine Frage für Ihr Rechtsteam.
Die DSGVO enthält keine allgemeine Pflicht zur Datenlokalisierung. Sie regelt Übermittlungen in Drittländer in Kapitel V (Artikel 44 bis 50), und Fernzugriff von außerhalb des EWR, etwa durch den Support eines Anbieters, kann als Übermittlung gelten. Einige nationale und branchenspezifische Vorschriften fügen eigene Lokalisierungspflichten hinzu, prüfen Sie also die für Sie geltenden Regeln.
Übermittlungen außerhalb des EWR: Welche Mechanismen gelten
Kapitel V der DSGVO verlangt eine Rechtsgrundlage für die Übermittlung und Garantien, die im Zielland Bestand haben. Fernzugriff durch den Support von außerhalb des EWR auf einen innerhalb des EWR gehosteten Passwort-Tresor zählt als Übermittlung, eine Hosting-Region allein beantwortet die Frage also nicht. Es gibt drei Wege, und jeder gilt in einer anderen Situation.
Angemessenheitsbeschluss (Artikel 45). Die Europäische Kommission hat festgestellt, dass das Schutzniveau im Zielland gleichwertig ist. Der EU-US Data Privacy Framework-Beschluss vom 10. Juli 2023 deckt nur selbstzertifizierte US-Unternehmen ab, prüfen Sie also den Eintrag des Anbieters in der Framework-Liste. Frühere EU-US-Rahmenwerke wurden gerichtlich gekippt, und das aktuelle wird angefochten, halten Sie Standardvertragsklauseln also als Rückfalloption im AVV bereit.
Geeignete Garantien (Artikel 46). Meist Standardvertragsklauseln (SCC), von der Kommission genehmigte Musterklauseln, zusammen mit einer Transferfolgenabschätzung (TIA). Die TIA prüft, ob das Recht des Ziellands Behörden den Zugriff auf die Daten erlaubt. Sie folgt aus dem Schrems-II-Urteil und den Empfehlungen 01/2020 des EDPB.
Ausnahmeregelungen (Artikel 49). Eng gefasste Ausnahmen, etwa die ausdrückliche Einwilligung, nachdem die betroffene Person über die Risiken informiert wurde. Sie eignen sich für gelegentliche Übermittlungen, nicht für die routinemäßige Verarbeitung durch einen Anbieter.
Eine EU-Hosting-Region senkt das Risiko, beseitigt es aber nicht. Support-Personal außerhalb des EWR, anderswo verarbeitete Metadaten und eine Muttergesellschaft außerhalb des EWR mit Zugriff können jeweils eine Übermittlung auslösen. Die Befugnis einer ausländischen Behörde, eine Muttergesellschaft zur Offenlegung von Daten zu verpflichten, ist ein eigenständiges Jurisdiktionsrisiko (siehe den Abschnitt zur Residenz oben). Behandeln Sie die Region als einen Faktor Ihrer TIA, nicht als deren Ergebnis.
Die Sechs-Zonen-Karte der Zugangsdaten
Die Sechs-Zonen-Karte der Zugangsdaten teilt einen Passwortmanager für Unternehmen in sechs Orte auf, an denen Zugangsdaten existieren. Jede Zone kann in einem anderen Land liegen und bringt ihre eigene DSGVO-Pflicht mit sich. Wer nur „den Server" prüft, übersieht Kopien, für die er verantwortlich ist.
Zone
Einfach erklärt
DSGVO-Pflicht
1. Gespeicherte Zugangsdaten
Die gespeicherten Logins, Notizen und Dateien
Art. 32(1)(a), Verschlüsselung
2. Schlüsselmaterial
Die Schlüssel, die sie entsperren
Art. 32(1)(a), Schlüsselkontrolle
3. Servicedaten
Aufzeichnungen darüber, wer das System wann genutzt hat
Art. 30, Art. 33
4. Backups und Replikate
Gespeicherte und laufende Kopien auf anderen Servern
Art. 28(3)(g), Art. 32(1)(c)
5. Client-Caches
Kopien auf den Geräten der Nutzer
Art. 32
6. Unterauftragsverarbeiter
Die Lieferanten und der Support-Zugriff des Anbieters
Art. 28(2), 28(4), Kapitel V
Ein Passwortmanager ist ein System von Kopien. Einige davon halten Sie selbst, andere der Anbieter, und wieder andere die Lieferanten des Anbieters. Welche Kopien bei Ihnen liegen, hängt vom Bereitstellungsmodell ab. Bei einem selbst gehosteten Modell sind Sie der Betreiber jeder Zone, sodass sich jede Frage unten auf Ihre eigenen Teams und Hosting-Anbieter bezieht statt auf einen Anbieter.
Jede Zone löst außerdem eine andere Pflicht aus. Backups werfen Löschpflichten bei Vertragsende auf (Artikel 28(3)(g)), und Lieferanten werfen Pflichten auf, die entlang der Kette weitergegeben werden müssen (Artikel 28(4)). Die nächsten sechs Unterabschnitte behandeln jede Zone und was Sie dazu erfragen sollten.
Zone 1: Gespeicherte Zugangsdaten
Gespeicherte Zugangsdaten sind die Inhalte, die Nutzer ablegen: Logins, Notizen, Anhänge und die Geheimnisse hinter Einmalcodes. Mit clientseitiger Verschlüsselung erreicht sie der Server als Chiffretext – Daten, die ohne den Schlüssel unlesbar sind. Eine gestohlene Kopie der Datenbank legt dann nur unlesbare Geheimnisse offen, vorausgesetzt der Schlüssel, der den verschlüsselten privaten Schlüssel entschlüsselt, bleibt auf dem Gerät des Nutzers (siehe Zone 2).
Verschlüsselte Zugangsdaten bleiben personenbezogene Daten, wenn sie sich auf eine identifizierbare Person beziehen, Zone 1 bleibt also im Anwendungsbereich. Artikel 32(1)(a) nennt Verschlüsselung als Beispiel einer geeigneten Maßnahme, und sie senkt das Risiko. Erfassen Sie in Ihrem VVT-Eintrag für den Passwortmanager den Standort und die Verschlüsselungsmethode dieser Zone.
Datensatznamen, Ordnerstruktur und Audit-Metadaten werden getrennt gespeichert und gehören zu Zone 3. Führen Sie dafür eine eigene VVT-Zeile mit denselben Angaben zu Standort und Zugriff.
Zone 2: Schlüsselmaterial
Schlüsselmaterial ist die Gesamtheit der kryptografischen Schlüssel, die gespeicherte Zugangsdaten entsperren. Wer die Schlüssel besitzt, kann die Daten lesen, unabhängig davon, wo der Chiffretext liegt – Schlüsselstandort und Schlüsselinhaber sind daher ebenso wichtig wie der Serverstandort. Artikel 32(1)(a) macht Verschlüsselung nur dann zu einer geeigneten Maßnahme, wenn die Schlüssel ebenso sorgfältig kontrolliert werden wie die Daten.
Die Kette verläuft über Masterpasswort, Hauptschlüssel, privaten Schlüssel, Tresorschlüssel, Datensatzschlüssel. Aus dem Masterpasswort des Nutzers wird der Hauptschlüssel über eine Funktion wie PBKDF2 abgeleitet, die das Erraten von Passwörtern verlangsamt. Dieser Schlüssel entschlüsselt einen privaten Schlüssel, der Tresorschlüssel entschlüsselt, die wiederum die Schlüssel einzelner Datensätze entsperren.
Der Server speichert den privaten Schlüssel und die Tresorschlüssel in verschlüsselter Form. Der Schlüssel, der sie entschlüsselt, bleibt auf dem Gerät des Nutzers, sodass eine Kopie der Datenbank allein keinen Zugriff ermöglicht.
Die Wiederherstellung ist der eine Schlüsselpfad, den es sich lohnt, gesondert zu betrachten. Manche Designs enthalten ein Wiederherstellungskonto oder einen Hinterlegungsschlüssel, damit eine Organisation den Zugriff nach einem verlorenen Masterpasswort wiederherstellen kann. Wer diesen Schlüssel besitzt, kann ebenfalls auf Klartext zugreifen – behandeln Sie ihn also wie jeden anderen Schlüssel: wer ihn besitzt, wo er gespeichert ist und welche Gerichte seinen Inhaber zur Herausgabe verpflichten können. Unser Leitfaden zudem, was Zero-Knowledge-Verschlüsselung schützt und was nicht, erklärt die Mechanik.
Zone 3: Servicedaten
Servicedaten sind alles, was das System über die Nutzung aufzeichnet, statt über den Inhalt. Clientseitige Verschlüsselung deckt sie nicht ab, sodass der Betreiber sie meist lesen kann. Das macht sie selbst zu personenbezogenen Daten und zu dem Teil des Systems, den eine behördliche Anordnung erreichen kann, ohne die Verschlüsselung anzutasten. Dazu gehören typischerweise:
Kontoidentitäten, E-Mail-Adressen und Rechnungsdaten
Anmelde-IP-Adressen, Geräte-Kennungen und Zugriffszeitstempel
Audit-Protokolle sowie Datensatznamen und Ordnerstruktur, falls das Produkt sie nicht verschlüsselt
Drei Pflichten gelten hier. Protokolle sind Ihr Nachweis zur Beurteilung einer Datenschutzverletzung (Artikel 32 und 33). Die Speicherdauer muss auf das Nötige begrenzt sein (Artikel 5(1)(e)). Mitarbeiter können ihre eigenen Daten anfordern (Artikel 15). Bei einem selbst gehosteten Modell halten Sie diese Zone selbst.
Zone 4: Backups, Replikate und Disaster Recovery
Backups, Replikate und Disaster-Recovery-Standorte (DR) sind die Kopien von Zugangsdaten, die außerhalb des primären Servers liegen. Jede Kopie kann in einem anderen Land und unter einem anderen Betreiber liegen, sodass für jede eine eigene Antwort zu Standort, Verschlüsselung und Löschung nötig ist.
Backups sind gespeicherte Kopien zur Wiederherstellung von Daten. Replikate sind laufende Kopien auf anderen Servern. Disaster-Recovery-Standorte (DR) sind Standby-Standorte. Sie unterstützen Verfügbarkeit und Wiederherstellung (Artikel 32(1)(b) und (c)), aber jede zusätzliche Kopie vergrößert die Angriffsfläche und die Zahl der geltenden Jurisdiktionen. Fragen Sie drei Dinge ab:
Wo wird jedes Backup und Replikat gespeichert, und verlässt eine Kopie die EU oder den EWR? Eine Kopie in einem Drittland kann nach Kapitel V als Übermittlung zählen.
Sind die Backups verschlüsselt, und werden die Schlüssel getrennt von den Daten aufbewahrt?
Wie viele Tage dauert es nach Vertragsende, bis die letzte Kopie gelöscht ist, und wie überprüfen Sie das?
Artikel 28(3)(g) verpflichtet den Auftragsverarbeiter, nach Ihrer Wahl alle personenbezogenen Daten bei Beendigung der Dienste zu löschen oder zurückzugeben und vorhandene Kopien zu löschen, sofern das Recht keine Speicherung verlangt. Backups fallen unter diese Pflicht. In der Praxis laufen sie oft über einen Rotationszyklus aus, die Aufbewahrungsdauer ist also die Zahl, die Sie sich schriftlich geben lassen sollten.
Zone 5: Client-Caches und Offline-Speicher
Manche Daten verlassen den Server konstruktionsbedingt. Desktop- und Mobil-Apps können Offline-Kopien vorhalten, Browser-Erweiterungen können eine Sitzung oder einen Entsperrschlüssel vorhalten, und Nutzer können Tresordateien exportieren. Jede davon ist eine Kopie außerhalb Ihrer zentralen Kontrolle und reist dorthin, wohin das Gerät des Mitarbeiters reist.
Das ist die Zone, in der Ihre eigene Richtlinie am meisten zählt. Legen Sie fest, ob der Offline-Modus erlaubt ist, verlangen Sie Festplattenverschlüsselung über Mobile Device Management (MDM), und schränken Sie ein, wer exportieren darf. Behandeln Sie Exporte mit der größten Sorgfalt, da eine CSV-Datei für jeden lesbar ist, der sie öffnet. Fragen Sie den Anbieter, ob Administratoren den Offline-Modus nach Rolle einschränken können, ob zwischengespeicherte Daten sich nach einer festgelegten Zeit selbst löschen und ob Offline-Nutzung und Exporte protokolliert werden.
Ein verlorenes Gerät mit einer Tresorkopie ist ein Risiko nach Artikel 32(2), der Verlust und unbefugte Offenlegung nennt, und kann die Meldepflichten bei Datenschutzverletzungen nach Artikel 33 und 34 auslösen. Listen Sie Endgeräte und zugelassene Exportorte in Ihrem VVT auf.
Zone 6: Unterauftragsverarbeiter und Support-Zugriff
Unterauftragsverarbeiter sind die Lieferanten, die ein Anbieter zur Erbringung des Dienstes einsetzt, etwa für Hosting, E-Mail-Zustellung, Monitoring und Support-Tools. Nach Artikel 28(2) und 28(4) braucht der Auftragsverarbeiter Ihre Genehmigung, um sie einzubinden, und muss dieselben Datenschutzpflichten entlang der Kette weitergeben.
Dritte waren laut Verizons DBIR 2026 an 48 % der Datenschutzverletzungen beteiligt – ein Anstieg von 60 % gegenüber dem Vorjahr. Der Bericht ordnet diese Fälle drei Archetypen zu: einem Anbieter in Ihrer Software-Lieferkette, einem Anbieter, der Ihre Daten in seiner Umgebung hostet, und einem Anbieter mit einer Verbindung in Ihre Umgebung. Ein gehosteter Passwortmanager ist der zweite Typ, und eine Support- oder Integrationsverbindung in Ihre Systeme kann ihn zum dritten machen. Prüfen Sie die Lieferanten des Anbieters so genau wie dessen Produkt.
Fordern Sie vier Dinge an:
Eine aktuelle Liste der Unterauftragsverarbeiter und des Landes, in dem jeder tätig ist
Vorabbenachrichtigung über Änderungen, mit einem Widerspruchsrecht
Wer im Support-Team des Anbieters Servicedaten einsehen kann (Zone 3) und unter welcher Genehmigung
Ob ein Unterauftragsverarbeiter oder Support-Zugang auf Schlüsselmaterial zugreifen kann (Zone 2)
Zone-zu-Artikel-Karte: Die Pflicht und der Nachweis
Die Zone-zu-Artikel-Karte ordnet jeder der sechs Zugangsdaten-Zonen die DSGVO-Vorschrift zu, die sie auslöst, das Dokument, das die Einhaltung belegt, und die Partei, die dafür verantwortlich ist. Nutzen Sie sie als Grundgerüst für Ihren VVT-Eintrag zum Passwortmanager, und füllen Sie die Nachweis-Spalte aus, bevor ein Auditor fragt. Das Evidenzpaket am Ende listet dieselben Dokumente als Checkliste.
Zone
DSGVO-Bezug
Vorzuhaltender Nachweis
Verantwortlich
1. Gespeicherte Zugangsdaten
Art. 32(1)(a), Art. 30
Beschreibung der Verschlüsselung, VVT-Eintrag
Verantwortlicher entscheidet, Auftragsverarbeiter setzt um
2. Schlüsselmaterial
Art. 32(1)(a), Art. 25
Schlüsselhierarchie und Wiederherstellungskonzept
Auftragsverarbeiter, geprüft vom Verantwortlichen
3. Servicedaten
Art. 15, Art. 28(3)(e), Art. 44-46
Datenbestandsverzeichnis, Verfahren für den Protokollexport, Transferfolgenabschätzung
Auftragsverarbeiter, verifiziert vom Verantwortlichen
5. Client-Caches
Art. 32(2), Art. 33-34
Geräterichtlinie, Exportregeln
Verantwortlicher
6. Unterauftragsverarbeiter
Art. 28(2), Art. 28(4)
Liste der Unterauftragsverarbeiter, Änderungsmitteilung
Auftragsverarbeiter, genehmigt vom Verantwortlichen
Diese Aufteilung entscheidet, wer meldet. Nach Artikel 33 meldet der Verantwortliche die Datenschutzverletzung der Aufsichtsbehörde innerhalb von 72 Stunden, nachdem er davon Kenntnis erlangt hat, soweit möglich. Der Auftragsverarbeiter muss Sie „unverzüglich" informieren, was keine Zahl festlegt – schreiben Sie also eine Meldefrist in den AVV. Beim Self-Hosting sind Sie zugleich Verantwortlicher und Betreiber, und die Spalte „Verantwortlich" fällt auf Ihre eigenen Teams zusammen.
Der AVV, den Sie von einem Passwortmanager-Anbieter brauchen
Ein Auftragsverarbeitungsvertrag (AVV) ist der Vertrag, den Artikel 28(3) zwischen einem Verantwortlichen und einem Auftragsverarbeiter vorschreibt. Für einen Passwortmanager-Anbieter muss er Gegenstand, Dauer, Art, Zweck, Datenarten und Kategorien betroffener Personen festlegen, zuzüglich acht Pflichten in den Punkten (a) bis (h). Die EDPB Guidelines 07/2020 zu Verantwortlichen und Auftragsverarbeitern erläutern jede davon.
Begriff
Artikel
Was Sie vom Anbieter verlangen sollten
Dokumentierte Anweisungen
28(3)(a)
Verarbeitung nur auf Ihre schriftliche Anweisung, einschließlich Übermittlungen in Drittländer, und die Pflicht, Sie sofort zu informieren, wenn eine Anweisung gegen das Recht verstößt
Vertraulichkeit
28(3)(b)
Alle zur Verarbeitung befugten Personen, einschließlich Support-Mitarbeiter, zur Vertraulichkeit verpflichtet
Sicherheitsmaßnahmen
28(3)(c)
Die Maßnahmen nach Artikel 32, benannt in einem Anhang
Unterauftragsverarbeiter
28(3)(d), 28(2), 28(4)
Ihre Genehmigung, Mitteilung von Änderungen mit Widerspruchsrecht, dieselben Pflichten entlang der Kette weitergegeben
Rechte der betroffenen Personen
28(3)(e)
Unterstützung bei der Beantwortung von Auskunfts- und Löschanfragen
Unterstützung
28(3)(f)
Unterstützung bei Sicherheit, Meldung von Datenschutzverletzungen und Folgenabschätzungen (Artikel 32 bis 36)
Löschung oder Rückgabe
28(3)(g)
Löschung oder Rückgabe nach Ihrer Wahl bei Vertragsende, mit einer festgelegten Frist für Backups
Audits
28(3)(h)
Informationen, die die Einhaltung belegen, sowie Audits einschließlich Inspektionen
Die Zeile zu Audits verdient die genaueste Lektüre. Artikel 28(3)(h) verlangt, dass Ihnen der Vertrag die Informationen gibt, die die Einhaltung belegen, und Audits einschließlich Inspektionen erlaubt. Öffnet der Anbieter seine Infrastruktur nicht für eine Inspektion vor Ort, sollte der Vertrag festlegen, was stattdessen gilt.
Die Nachweise, die Sie dann prüfen, umfassen die Liste der Unterauftragsverarbeiter, eine Transferfolgenabschätzung und die Audit-Berichte, auf die Ihnen der Vertrag Anspruch gibt. Ergänzen Sie Ihre eigenen Tresor-Protokolle, exportiert in ein SIEM (ein System, das Sicherheitsprotokolle sammelt und auswertet).
Bereitstellungsmodelle für DSGVO-konformes Passwortmanagement
Ihr Bereitstellungsmodell entscheidet, welche der sechs Zonen Ihr Team kontrolliert. Eine Anbieter-Cloud belässt die meisten Zonen beim Anbieter, eine EU-Region-Cloud schränkt ein, wo sie liegen, und Self-Hosting verlagert sie auf Ihre Infrastruktur und Ihre Pflichtenliste. Air-gapped-Umgebungen gehen am weitesten und ergänzen den Umgang mit Offline-Updates und Protokollen.
Option
Wo die Daten liegen
Übermittlungsposition
Pflichten, die Sie übernehmen
Anbieter-Cloud, beliebige Region
Wahl des Anbieters
Mechanismus und TIA, wenn Daten oder Zugriff den EWR verlassen
AVV, Prüfung der Unterauftragsverarbeiter, Meldefrist
EU-Region-Cloud
Gewählte EU-Region
Geringere Exposition, nicht null
AVV, Prüfung der Unterauftragsverarbeiter, Regeln für Support-Zugriff
EU-souveränes Hosting
EU-Anbieter, in EU-Besitz
Am niedrigsten für einen gehosteten Dienst
AVV, Anbieter-Audit
Self-hosted, On-Premises
Ihre Infrastruktur
Keine, außer Support-Zugriff oder Backups verlassen den EWR
Backups, Schlüssel, Patching, Aufzeichnungen
Air-gapped
Isoliertes Netzwerk
Keine
Self-Hosting-Pflichten, plus Offline-Updates
Ein vom Anbieter verwalteter Dienst gibt Ihnen weniger Kontrolle über Exportformate und den Zeitpunkt eines Ausstiegs. Prüfen Sie vor der Unterschrift, wie Sie den Dienst verlassen würden: welche Formate Sie exportieren können und welche Frist für die Löschung von Backups nach Artikel 28(3)(g) gilt.
Self-Hosting und DSGVO: Welche Pflichten Sie übernehmen
Self-Hosting verlagert DSGVO-Pflichten von einem Anbietervertrag in Ihre eigenen Betriebsabläufe. Sie kontrollieren, wo jede Zone liegt und wer sie betreibt, wodurch das Auftragsverarbeiterverhältnis für den Tresor selbst entfallen kann. Sie werden außerdem selbst zum Betreiber und tragen die Nachweise damit selbst. Unsere Seite zum On-Premises-Passwortmanager behandelt diese Bereitstellungsoption.
Was Sie gewinnen:
Kontrolle darüber, wo jede Zone liegt, einschließlich Backups
Keine Übermittlung an einen Anbieter und keine Kette von Unterauftragsverarbeitern für den Tresor selbst
Was Sie nun schulden:
Standorte von Backups und Replikaten, getestete Wiederherstellungen und einen Aufbewahrungsplan
Verfahren zur Schlüsselwiederherstellung, Patching und Hochverfügbarkeit
Ein aktuelles Verzeichnis von Verarbeitungstätigkeiten (Artikel 30)
Ihren eigenen Prozess zur Erkennung und Meldung von Datenschutzverletzungen (Artikel 33)
Hypothetisches Beispiel: Ein Team stellt einen Tresor nach einem Server-Absturz wieder her und stellt fest, dass der nächtliche Backup-Job seit Jahren in einen Speicher in einem zweiten Land schreibt, eingerichtet von jemandem, der das Unternehmen inzwischen verlassen hat. Der Tresor lag on-premises, eine Kopie jedoch nie. Diese Kopie ist eine Übermittlungsfrage nach Kapitel V. Eine Prüfung Zone für Zone findet das, bevor es ein Vorfall tut.
Das Insider-Risiko bleibt bei Ihnen. Clientseitige Verschlüsselung bedeutet, dass Administratoren Tresorinhalte nicht lesen können, aber sie können weiterhin Daten löschen, Chiffretext und Backups kopieren, die Konfiguration ändern oder Protokolle bearbeiten. Trennen Sie Zuständigkeiten, und protokollieren Sie Administratorhandlungen.
Air-gapped-Bereitstellungen bringen eine weitere Pflicht mit sich. Ohne Internetverbindung spielen Sie Updates manuell ein und bewegen Protokolle manuell. Isolation entfernt keine Schwachstellen, und der Datenträger, den Sie hineintragen, wird zum Weg, auf dem ein Update das System erreicht.
Artikel 32(1) verlangt dem Risiko angemessene Maßnahmen. Dokumentieren Sie, wer ein Update-Paket genehmigt, wie Sie seine Integrität vor dem Import prüfen, wie oft Protokolle das Netzwerk verlassen und wer die Datenträger handhabt. Testen Sie auch das Wiederherstellungsverfahren, denn 32(1)(c) und (d) decken die Wiederherstellung der Verfügbarkeit und die regelmäßige Überprüfung Ihrer Maßnahmen ab.
Wie Passwork Datenstandort und Zugriff handhabt
Passwork Self-hosted läuft auf Infrastruktur, die Sie kontrollieren: On-Premises-Server, eine Private Cloud oder ein air-gapped Netzwerk. Der Tresor, die Schlüssel und die Backups liegen dort, wo Sie sie platzieren, Ihr Team entscheidet also, wo jede Zone liegt. Die Antworten unten folgen den sechs Zonen und den oben gestellten Fragen.
Passwork wird mit Docker auf Linux installiert (der empfohlene Weg), mit einem PowerShell-Skript auf Windows Server oder manuell, und Offline-Pakete decken air-gapped Netzwerke ab. Die technischen Leitfäden von Passwork behandeln jeden Weg.
Tresorinhalt und Schlüssel (Zonen 1 und 2). Daten werden clientseitig mit AES-256 verschlüsselt, der Server speichert also nur Chiffretext und verschlüsseltes Schlüsselmaterial. Der Hauptschlüssel wird mit PBKDF2 abgeleitet und verlässt das Gerät des Nutzers nie im Klartext. Eine zweite, unabhängige AES-256-Schicht schützt die Datenbank auf dem Server.
Zero-Knowledge-Architektur entscheidet, wer die Daten lesen kann: nur die Nutzer, die die Schlüssel besitzen, sodass auch Ihre eigenen Administratoren die Tresorinhalte nicht lesen können. Die Wiederherstellung läuft über ein vorab eingerichtetes Wiederherstellungskonto, dessen Masterpasswort Sie offline speichern, und Sie entscheiden, wer es besitzt.
Servicedaten (Zone 3). Das Aktivitätsprotokoll erfasst Nutzer-, Admin- und Systemaktionen, und seine Audit-Trails sind bereit für die SIEM-Integration. Datensatz- und Ordnernamen, Zugriffsstruktur und Audit-Metadaten liegen auf dem Server, listen Sie sie also in Ihrem VVT auf. Sie legen die Aufbewahrungsrichtlinie fest und bewahren die Protokolle auf Ihrem eigenen Speicher auf.
Backups und Replikate (Zone 4). MongoDB-Replikatsets mit drei oder mehr stimmberechtigten Mitgliedern geben dem Dienst zusammen mit horizontal skalierten Anwendungsservern Fehlertoleranz für über 10.000 Nutzer. Geplante Hintergrundaufgaben erstellen und rotieren Backup-Archive, und Sie wählen, wo sie gespeichert werden.
Client-Caches und Offline-Speicher (Zone 5). Der Offline-Modus ist nur lesend und auf zwei Ebenen opt-in: Der Nutzer markiert einen Datensatz und aktiviert dann Offline auf einem bestimmten Gerät. Administratoren legen fest, welche Rollen ihn nutzen dürfen, die maximale Anzahl an Datensätzen pro Gerät und die maximale nicht synchronisierte Zeit vor einer automatischen Löschung. Offline-Downloads und -Ansichten werden mit dem Aktivitätsprotokoll und dem Sicherheits-Dashboard synchronisiert, sobald das Gerät wieder verbunden ist.
Unterauftragsverarbeiter (Zone 6). Eine selbst gehostete Bereitstellung hat keinen vom Anbieter gehosteten Unterauftragsverarbeiter. Ihre Lieferantenliste beschränkt sich auf Ihre eigenen Hosting- und Backup-Anbieter, und dieselben Fragen von oben gelten für sie. Ein Private-Cloud-Host, der den Tresor für Sie betreibt, ist Ihr Auftragsverarbeiter und braucht seinen eigenen AVV.
Der Zugriff folgt dem Prinzip der geringsten Privilegien. Rollenbasierte Zugriffskontrolle (RBAC) legt Zugriffslevel für Tresore und Ordner fest, LDAP- und Active-Directory-Gruppensynchronisierung überträgt Verzeichnisänderungen nach Passwork, und SAML SSO übernimmt die Anmeldung. Passwork ist ISO-27001-zertifiziert, über HackerOne getestet, und der Quellcode steht für eine unabhängige Prüfung zur Verfügung.
Wenn Ihr Compliance-Fall davon abhängt, wo der Tresor, die Schlüssel und die Backups liegen, testen Sie es in Ihrer eigenen Umgebung. Kostenlose Passwork-Testversion starten.
DSGVO-Evidenzpaket für Passwortmanagement
Das 8-Punkte-Evidenzpaket ist die Zusammenstellung der Dokumente, die Sie vor einem DSGVO-Audit Ihres Passwortmanagers bereithalten sollten. Es umfasst Verarbeitungsaufzeichnungen, Anbieterbedingungen, Transferfolgenabschätzungen, Backup-Standorte, Zugriffsüberprüfungen und Verfahren bei Datenschutzverletzungen. Punkte 1 bis 6 sind einzelnen Zonen zugeordnet, während Punkte 7 und 8 Zugriff und den Umgang mit Datenschutzverletzungen über alle Zonen hinweg abdecken.
Eintrag im Verzeichnis von Verarbeitungstätigkeiten für den Passwortmanager, der alle sechs Zonen aufführt (Artikel 30)
Unterschriebener AVV, der die Bedingungen nach Artikel 28(3) abdeckt, falls ein Anbieter oder Hosting-Anbieter eine Zone verarbeitet
Aktuelle Liste der Unterauftragsverarbeiter und die Klausel zur Änderungsmitteilung, unter derselben Bedingung
Transferfolgenabschätzung, falls eine Zone ein Drittland berührt (Kapitel V)
Datenschutz-Folgenabschätzung, falls Ihre Risikobewertung eine erfordert (Artikel 35)
Backup- und Replikat-Karte mit Standorten und Löschfristen
Zugriffsüberprüfung der Tresor-Berechtigungen, durchgeführt anhand von Audit-Protokoll-Exporten
Ein 72-Stunden-Verfahren bei Datenschutzverletzungen, das benennt, wer entscheidet und wer meldet (Artikel 33)
Die DSGVO legt kein festes Intervall für Zugriffsüberprüfungen fest. Vierteljährlich ist ein gängiger Rhythmus, legen Sie also einen fest, der zu Ihrem Risiko passt, und dokumentieren Sie ihn.
Das Audit-Protokoll ist der Nachweis hinter Punkt 7 und 8. Es zeigt, wer wann auf welche Zugangsdaten zugegriffen hat, was Ihnen hilft, das Ausmaß einer Datenschutzverletzung einzuschätzen und zu beurteilen, ob personenbezogene Daten betroffen sein könnten. Exportieren Sie es in Ihr SIEM, damit es den Tresor überlebt und das von Artikel 33(5) vorgeschriebene Verzeichnis der Datenschutzverletzungen speist.
Wo Sie mit DSGVO-konformem Passwortmanagement anfangen
DSGVO-konformes Passwortmanagement beginnt damit, die Bereitstellung an die Daten anzupassen, die Ihre Jurisdiktion nicht verlassen dürfen. Halten Sie dann für jede Zone, die ein Anbieter verarbeitet, einen Vertrag oder Nachweis bereit: wo Inhalt, Schlüssel, Servicedaten, Backups, Caches und Unterauftragsverarbeiter liegen und was jeweils greift.
Beginnen Sie mit einer einzigen Seite. Zeichnen Sie die sechs Zonen für Ihren aktuellen Passwortmanager auf, und markieren Sie die, die Sie nicht beantworten können. Das sind Ihre ersten Fragen an den Anbieter oder Ihre ersten internen Aufgaben, wenn Sie selbst hosten. Sobald die Karte vollständig ist, behandelt der DSGVO-Leitfaden zur Passwortsicherheit die nächste Ebene: Passwortregeln und die Praxis der Mitarbeiter.
Verlangt die DSGVO, dass Passwortdaten in der EU gespeichert werden?
Nicht grundsätzlich. Die DSGVO kennt keine pauschale Pflicht zur Datenlokalisierung. Sie schränkt Übermittlungen personenbezogener Daten außerhalb des EWR ein und verlangt eine Rechtsgrundlage, etwa einen Angemessenheitsbeschluss oder Standardvertragsklauseln, gestützt auf eine Transferfolgenabschätzung (Artikel 44 bis 49). Nationale oder branchenspezifische Vorschriften können weitere Grenzen setzen.
Sind gespeicherte Passwörter personenbezogene Daten nach der DSGVO?
Meist ja. Ein Zugangsdatensatz enthält normalerweise einen Benutzernamen, eine E-Mail-Adresse oder einen Zugriffsverlauf, der eine Person identifiziert, und fällt damit unter die Pflichten in Artikel 5(1)(f), 25 und 32. Verschlüsselte Daten bleiben personenbezogene Daten. Verschlüsselung ist eine Schutzmaßnahme und nimmt Daten nicht aus dem Anwendungsbereich der Verordnung.
Macht Zero-Knowledge-Verschlüsselung uns DSGVO-konform?
Nein. Sie schützt den Tresorinhalt, was eine Maßnahme unter Artikel 32 darstellt. Hostet ein Anbieter den Dienst, bleiben Metadaten wie Kontoidentitäten, Anmelde-IP-Adressen und Zugriffszeitstempel in der Regel für den Anbieter lesbar. Ihre Pflichten zu Verträgen, Verzeichnissen von Verarbeitungstätigkeiten und der Meldung von Datenschutzverletzungen gelten weiterhin.
Brauchen wir einen Auftragsverarbeitungsvertrag mit unserem Passwortmanager-Anbieter?
Ja, wenn der Anbieter personenbezogene Daten für Sie verarbeitet. Er ist dann Auftragsverarbeiter, und Artikel 28(3) verlangt einen Vertrag, der dokumentierte Anweisungen, Vertraulichkeit, Sicherheit, Unterauftragsverarbeiter, Rechte der betroffenen Personen, Löschung oder Rückgabe sowie Prüfungsrechte abdeckt. Ein selbst gehostetes Modell ohne Anbieterzugriff braucht möglicherweise keinen. Klären Sie das mit Ihrem Rechtsteam.
Was muss nach Artikel 32 dokumentiert werden?
Artikel 32 verlangt Maßnahmen, die zu Ihrem Risiko passen, etwa Verschlüsselung, Pseudonymisierung, Belastbarkeit und regelmäßige Tests. Die Rechenschaftspflicht in Artikel 5(2) bedeutet, dass Sie diese nachweisen können müssen. Führen Sie in der Praxis eine Aufzeichnung der Maßnahmen, einen Nachweis, dass sie funktionieren, und Exporte des Audit-Protokolls.
DSGVO-konformes Passwortmanagement: Wo Ihre Daten liegen
Ein Tresor in Frankfurt kann trotzdem einer ausländischen Gerichtsanordnung unterliegen, und das Label „EU-gehostet" sagt nichts darüber, wo die Backups liegen.
El Reglamento General de Protección de Datos (RGPD), la ley de protección de datos de la UE, exige un mecanismo de transferencia lícito para enviar datos personales fuera del Espacio Económico Europeo (EEE, la UE más Islandia, Liechtenstein y Noruega), y medidas de seguridad adecuadas al riesgo. Para una gestión de contraseñas conforme al RGPD, es necesario saber en qué lugares existen los datos de las credenciales y disponer de pruebas para cada uno de ellos.
Sus credenciales pueden almacenarse en un centro de datos de Fráncfort y, aun así, quedar sujetas a una orden judicial extranjera si el proveedor está sometido a una jurisdicción ajena a la UE. Una etiqueta «alojado en la UE» tampoco dice nada sobre dónde están las copias de seguridad. Este artículo presenta el mapa de seis zonas de datos de credenciales: los lugares donde un gestor de contraseñas empresarial guarda datos, el artículo del RGPD que activa cada uno y las pruebas que debe conservar. Termina con un paquete de evidencias de 8 puntos que puede comprobar antes de una auditoría.
Puntos clave
El RGPD regula la salida de datos personales del EEE, y cada transferencia necesita un mecanismo lícito.
Una credencial almacenada suele identificar a un empleado, por lo que es un dato personal. El cifrado no cambia eso.
Los datos de las credenciales se reparten en seis zonas: el contenido de la bóveda, el material de claves, los datos de servicio, las copias de seguridad y réplicas, las cachés de los clientes y los subencargados. Cada zona tiene su propia obligación y su propia evidencia.
Si un proveedor trata alguna de las zonas, debe firmar un acuerdo de tratamiento de datos (DPA), un contrato que establece lo que puede hacer con sus datos.
Cuando aloja el sistema usted mismo, asume las copias de seguridad, la recuperación de claves y el mantenimiento de registros que, de otro modo, gestionaría un proveedor.
Su registro de auditoría muestra quién abrió cada credencial y cuándo, lo que ayuda a delimitar el alcance de una vulneración y a decidir si corresponde la notificación de 72 horas.
Qué exige la gestión de contraseñas conforme al RGPD
El RGPD exige que los datos personales se procesen de forma segura, que la protección de datos se integre desde el diseño y que se apliquen medidas proporcionales al riesgo.
Una gestión de contraseñas conforme al RGPD significa poder demostrar que los datos de las credenciales están cifrados, que solo pueden acceder a ellos las personas que los necesitan, que quedan registrados y que están cubiertos por los contratos y registros adecuados, sea donde sea que se almacenen.
La ley fija el resultado (artículos 5(1)(f), 25 y 32). Usted elige los controles y demuestra que funcionan (artículo 5(2)). En la práctica, esto se traduce en cinco requisitos:
Cifre las credenciales almacenadas. El artículo 32(1)(a) cita «la seudonimización y el cifrado de datos personales» como una medida adecuada.
Limite el acceso por rol (RBAC). Cada persona inicia sesión con su propia cuenta y solo ve lo que su trabajo requiere, incluso cuando la credencial que abre es compartida. Esto es protección de datos desde el diseño (artículo 25) aplicada al acceso.
Mantenga el servicio disponible y probado. El artículo 32(1)(b) a (d) cubre la resiliencia, la restauración del acceso tras un incidente y las pruebas periódicas de sus medidas.
Registre quién abrió qué. Un registro de accesos muestra qué credenciales se consultaron y cuándo. Es la evidencia que necesita para valorar si una vulneración afectó a datos personales (artículo 33).
Documente cada lugar donde residen los datos. Esto implica un registro de tratamiento, un contrato con cada tercero que trate los datos y un mecanismo lícito para cualquier transferencia fuera del EEE.
Estas obligaciones alcanzan a las contraseñas por dos motivos. Un registro de credenciales suele identificar a un empleado o estar vinculado a uno, lo que lo convierte en un dato personal (artículo 4(1): cualquier información relativa a una persona identificable). Las credenciales también dan acceso a otros sistemas, como RR. HH., CRM y bases de datos de clientes, donde se almacenan datos personales. El artículo 32(2) exige evaluar el riesgo de acceso no autorizado a datos personales, por lo que una vulneración del gestor de contraseñas es una vía de entrada a todos los sistemas que desbloquea. El cifrado reduce el riesgo, pero no excluye el registro del ámbito de aplicación.
Su organización es el responsable del tratamiento de la bóveda, la parte que decide por qué y cómo se usan los datos de las credenciales. Un proveedor o proveedor de alojamiento que lo opera o lo respalda siguiendo sus instrucciones es un encargado del tratamiento, y el artículo 28 exige un contrato con él. El artículo 30 exige mantener un registro de actividades de tratamiento (RoPA) que recoja los destinatarios, las ubicaciones y las transferencias de este tratamiento. Encontrar esas ubicaciones es la primera tarea.
Residencia, soberanía y jurisdicción son tres cosas distintas
La residencia de los datos es el lugar donde se almacenan físicamente. La soberanía de los datos significa que los datos están sujetos a las leyes y al control legal de un país determinado. La jurisdicción es qué tribunales y autoridades pueden emitir órdenes contra la empresa del proveedor. Un proveedor sujeto a la legislación de EE. UU. puede almacenar su bóveda en Alemania y, aun así, recibir requerimientos legales estadounidenses.
Término
Qué indica
Qué deja abierto
Residencia
Qué país alberga los servidores
Qué leyes pueden alcanzar los datos
Soberanía
Las leyes de qué país rigen los datos
Si una autoridad extranjera puede seguir alcanzando al proveedor
Jurisdicción
Qué autoridades pueden ordenar actuar al proveedor
Dónde se almacenan sus datos
La CLOUD Act permite a las autoridades estadounidenses exigir a los proveedores de servicios de comunicación electrónica o de computación remota sujetos a la jurisdicción de EE. UU. que entreguen los datos que posean, custodien o controlen, incluso cuando estén almacenados en el extranjero. Por tanto, un proveedor que sea una empresa estadounidense o que tenga una matriz estadounidense puede enfrentarse a este tipo de requerimientos aunque su bóveda esté en una región de la UE. Si un proveedor concreto queda sujeto a esta ley es una cuestión para su equipo legal.
El RGPD no contiene una regla general de localización de datos. Regula las transferencias a terceros países en el capítulo V (artículos 44 a 50), y el acceso remoto desde fuera del EEE, como el soporte del proveedor, puede considerarse una transferencia. Algunas normas nacionales o sectoriales añaden requisitos de localización propios, así que compruebe las que se aplican en su caso.
Transferencias fuera del EEE: Qué mecanismos se aplican
El capítulo V del RGPD exige un mecanismo de transferencia lícito y garantías que se mantengan en el país de destino. El acceso remoto de soporte desde fuera del EEE a una bóveda de contraseñas alojada dentro de él cuenta como una transferencia, por lo que la región de alojamiento por sí sola no resuelve la cuestión. Existen tres vías, y cada una se aplica a una situación distinta.
Decisión de adecuación (artículo 45). La Comisión Europea ha determinado que la protección del país de destino es equivalente. La decisión del Marco de Privacidad de Datos UE-EE. UU. del 10 de julio de 2023 solo cubre a las empresas estadounidenses autocertificadas, así que compruebe si el proveedor figura en la lista del marco. Marcos anteriores entre la UE y EE. UU. fueron anulados por los tribunales, y el actual también ha sido impugnado, por lo que conviene mantener las cláusulas contractuales tipo como respaldo en el DPA.
Garantías adecuadas (artículo 46). Normalmente, cláusulas contractuales tipo (SCC), modelos de contrato aprobados por la Comisión, junto con una evaluación de impacto de la transferencia (TIA). La TIA comprueba si la legislación del país de destino permite a las autoridades acceder a los datos. Se deriva de la sentencia Schrems II y de las Recomendaciones 01/2020 del Comité Europeo de Protección de Datos (CEPD).
Excepciones (artículo 49). Excepciones limitadas, como el consentimiento explícito tras informar al interesado de los riesgos. Son adecuadas para transferencias puntuales y no amparan el tratamiento habitual por parte de un proveedor.
Alojar los datos en una región de la UE reduce el riesgo, pero no lo elimina. El personal de soporte fuera del EEE, los metadatos tratados en otro lugar y una matriz fuera del EEE con acceso pueden, cada uno, generar una transferencia. La capacidad de una autoridad extranjera para ordenar a una matriz que divulgue datos es un riesgo de jurisdicción distinto (véase el apartado de residencia anterior). Trate la región como un factor más en su TIA, no como su conclusión.
El mapa de seis zonas de datos de credenciales
El mapa de seis zonas de datos de credenciales divide un gestor de contraseñas empresarial en seis lugares donde existen datos de credenciales. Cada zona puede estar en un país distinto y conlleva su propia obligación bajo el RGPD, por lo que comprobar solo «el servidor» deja fuera copias de las que usted es responsable.
Zona
Significado
Obligación del RGPD
1. Credenciales almacenadas
Los inicios de sesión, notas y archivos guardados
Art. 32(1)(a), cifrado
2. Material de claves
Las claves que las desbloquean
Art. 32(1)(a), control de claves
3. Datos de servicio
Registros de quién usó el sistema y cuándo
Art. 30, art. 33
4. Copias de seguridad y réplicas
Copias almacenadas y activas en otros servidores
Art. 28(3)(g), art. 32(1)(c)
5. Cachés de los clientes
Copias en los dispositivos de los usuarios
Art. 32
6. Subencargados
Los proveedores del fabricante y el acceso de soporte
Art. 28(2), 28(4), capítulo V
Un gestor de contraseñas es un sistema de copias. Usted conserva algunas, el proveedor conserva otras, y los proveedores del proveedor conservan el resto. Qué copias quedan en sus manos depende del modelo de despliegue. En un despliegue autoalojado, usted es el operador de todas las zonas, por lo que cada pregunta siguiente se aplica a sus propios equipos y proveedores de alojamiento en lugar de a un proveedor externo.
Cada zona también activa una obligación distinta. Las copias de seguridad generan obligaciones de eliminación al finalizar el contrato (artículo 28(3)(g)), y los proveedores generan obligaciones que deben trasladarse a lo largo de la cadena (artículo 28(4)). Los seis apartados siguientes tratan cada zona y qué pedir.
Zona 1: Credenciales almacenadas
Las credenciales almacenadas son el contenido que guardan los usuarios: inicios de sesión, notas, archivos adjuntos y los secretos que hay detrás de los códigos de un solo uso. Con el cifrado del lado del cliente, llegan al servidor como texto cifrado, datos ilegibles sin la clave. Una copia robada de la base de datos solo expone entonces secretos ilegibles, siempre que la clave que desbloquea la clave privada cifrada permanezca en el dispositivo del usuario (véase la zona 2).
Las credenciales cifradas siguen siendo datos personales cuando se refieren a una persona identificable, por lo que la zona 1 sigue dentro del ámbito de aplicación. El artículo 32(1)(a) cita el cifrado como ejemplo de medida adecuada, y reduce el riesgo. En la entrada de su RoPA para el gestor de contraseñas, anote la ubicación de esta zona y el método de cifrado.
Los nombres de los registros, la estructura de carpetas y los metadatos de auditoría se almacenan por separado y pertenecen a la zona 3. Asígneles su propia línea en el RoPA con la misma ubicación y los mismos detalles de acceso.
Zona 2: Material de claves
El material de claves es el conjunto de claves criptográficas que desbloquean las credenciales almacenadas. Quien posea las claves puede leer los datos, estén donde estén el texto cifrado, por lo que la ubicación de las claves y quién las posee importan tanto como la ubicación del servidor. El artículo 32(1)(a) solo considera el cifrado una medida adecuada cuando las claves se controlan con el mismo cuidado que los datos.
La cadena recorre la contraseña maestra, la clave maestra, la clave privada, las claves de bóveda y las claves de registro. La contraseña maestra del usuario deriva la clave maestra mediante una función como PBKDF2, que ralentiza los intentos de adivinar la contraseña. Esa clave descifra una clave privada, que descifra las claves de bóveda, las cuales a su vez desbloquean las claves de cada registro.
El servidor almacena la clave privada y las claves de bóveda en forma cifrada. La clave que las descifra permanece en el dispositivo del usuario, por lo que una copia de la base de datos por sí sola no concede acceso.
La recuperación es la única vía de claves que merece un mapeo aparte. Algunos diseños incluyen una cuenta de recuperación o una clave en depósito para que una organización pueda restaurar el acceso tras perder la contraseña maestra. Quien posea esa clave también puede acceder al texto en claro, así que trátela como cualquier otra clave: quién la posee, dónde se almacena y qué tribunales pueden obligar a revelarla a quien la posee. Nuestra guía sobrequé protege y qué no protege el cifrado de conocimiento cero explica el mecanismo.
Zona 3: Datos de servicio
Los datos de servicio son todo lo que el sistema registra sobre el uso, no sobre el contenido. El cifrado del lado del cliente no los cubre, por lo que el operador normalmente puede leerlos. Esto los convierte en datos personales por derecho propio y en la parte del sistema a la que puede llegar un requerimiento legal sin tocar el cifrado. Suele incluir:
Identidades de cuenta, direcciones de correo electrónico y registros de facturación
Direcciones IP de inicio de sesión, identificadores de dispositivo y marcas de tiempo de acceso
Registros de auditoría, además de los nombres de los registros y la estructura de carpetas si el producto no los cifra
Se aplican tres obligaciones. Los registros son su evidencia para valorar una vulneración (artículos 32 y 33). La conservación debe limitarse a lo que necesite (artículo 5(1)(e)). Los empleados pueden solicitar sus propios datos (artículo 15). En un despliegue autoalojado, usted mismo gestiona esta zona.
Zona 4: Copias de seguridad, réplicas y recuperación ante desastres
Las copias de seguridad, las réplicas y los sitios de recuperación ante desastres (DR) son las copias de datos de credenciales que existen fuera del servidor principal. Cada copia puede estar en un país distinto y bajo un operador distinto, por lo que cada una necesita su propia respuesta sobre ubicación, cifrado y eliminación.
Las copias de seguridad son copias almacenadas para restaurar datos. Las réplicas son copias activas en otros servidores. Los sitios de recuperación ante desastres (DR) son ubicaciones en espera. Respaldan la disponibilidad y la recuperación (artículo 32(1)(b) y (c)), pero cada copia adicional amplía la superficie de ataque y el conjunto de jurisdicciones aplicables. Pregunte tres cosas:
¿Dónde se almacena cada copia de seguridad y cada réplica, y sale alguna copia de la UE o del EEE? Una copia en un tercer país puede contar como una transferencia conforme al capítulo V.
¿Las copias de seguridad están cifradas, y las claves se mantienen separadas de los datos?
Una vez finalizado el contrato, ¿cuántos días tardan en desaparecer todas las copias, y cómo lo verifica?
El artículo 28(3)(g) exige que el encargado del tratamiento, a elección del responsable, elimine o devuelva todos los datos personales cuando finalicen los servicios, y que elimine las copias existentes salvo que la ley exija su conservación. Las copias de seguridad quedan sujetas a esta obligación. En la práctica, suelen caducar en un ciclo de rotación, por lo que el plazo de conservación es el dato que conviene obtener por escrito.
Zona 5: Cachés de los clientes y almacenes sin conexión
Algunos datos salen del servidor por diseño. Las aplicaciones de escritorio y móviles pueden conservar copias sin conexión, las extensiones del navegador pueden conservar una sesión o una clave de desbloqueo, y los usuarios pueden exportar archivos de la bóveda. Cada una es una copia fuera de sus controles centrales que viaja allí donde va el dispositivo del empleado.
Esta es la zona donde más importa su propia política. Decida si se permite el modo sin conexión, exija el cifrado de disco mediante la gestión de dispositivos móviles (MDM), y restrinja quién puede exportar. Trate las exportaciones con el máximo cuidado, ya que un archivo CSV es legible por cualquiera que lo abra. Pregunte al proveedor si los administradores pueden limitar el modo sin conexión por rol, si los datos en caché se borran automáticamente tras un periodo determinado, y si el uso sin conexión y las exportaciones quedan registrados.
Un dispositivo perdido con una copia de la bóveda es un riesgo conforme al artículo 32(2), que menciona la pérdida y la divulgación no autorizada, y puede activar las obligaciones de notificación de vulneraciones de los artículos 33 y 34. Enumere los endpoints y las ubicaciones de exportación aprobadas en su RoPA.
Zona 6: Subencargados y acceso de soporte
Los subencargados son los proveedores que utiliza un proveedor para prestar el servicio, como el alojamiento, el envío de correo electrónico, la monitorización y las herramientas de soporte. Conforme a los artículos 28(2) y 28(4), el encargado del tratamiento necesita su autorización para contratarlos y debe trasladar las mismas obligaciones de protección de datos a lo largo de la cadena.
Los terceros estuvieron implicados en el 48 % de las vulneraciones registradas en el DBIR 2026 de Verizon, un aumento del 60 % respecto al año anterior. El informe agrupa estos casos en tres arquetipos: un proveedor en su cadena de suministro de software, un proveedor que aloja sus datos en su propio entorno y un proveedor con una conexión a su entorno. Un gestor de contraseñas alojado es del segundo tipo, y un enlace de soporte o integración con sus sistemas puede convertirlo en el tercero. Revise a los proveedores del proveedor con la misma atención que su producto.
Pida cuatro cosas:
Una lista actualizada de subencargados y el país en el que opera cada uno
Aviso previo de los cambios, con derecho a oponerse
Quién del equipo de soporte del proveedor puede ver datos de servicio (zona 3), y bajo qué autorización
Si algún subencargado o canal de soporte puede acceder al material de claves (zona 2)
Mapa de zonas a artículos: La obligación y la evidencia
El mapa de zonas a artículos vincula cada una de las seis zonas de credenciales con la disposición del RGPD que activa, el documento que demuestra el cumplimiento y la parte responsable de aportarlo. Utilícelo como esqueleto para la entrada de su RoPA sobre el gestor de contraseñas, y complete la columna de evidencias antes de que un auditor la solicite. El paquete de evidencias del final enumera los mismos documentos como lista de verificación.
Zona
Disposición del RGPD
Evidencia que conservar
Responsable
1. Credenciales almacenadas
Art. 32(1)(a), art. 30
Descripción del cifrado, entrada del RoPA
El responsable decide, el encargado implementa
2. Material de claves
Art. 32(1)(a), art. 25
Jerarquía de claves y diseño de recuperación
El encargado, revisado por el responsable
3. Datos de servicio
Art. 15, art. 28(3)(e), arts. 44-46
Inventario de datos, procedimiento de exportación de registros, evaluación de transferencia
El responsable decide, el encargado opera
4. Copias de seguridad y réplicas
Art. 28(3)(g), art. 32(1)(c), arts. 44-46
Ubicaciones de las copias, plazo de conservación, condiciones de eliminación
El encargado, verificado por el responsable
5. Cachés de los clientes
Art. 32(2), arts. 33-34
Política de dispositivos, normas de exportación
El responsable
6. Subencargados
Art. 28(2), art. 28(4)
Lista de subencargados, aviso de cambios
El encargado, aprobado por el responsable
Este reparto decide quién notifica. Conforme al artículo 33, el responsable notifica a la autoridad de control en un plazo de 72 horas desde que tiene conocimiento de la vulneración, siempre que sea posible. El encargado debe informarle «sin dilación indebida», una expresión que no fija un número, así que conviene recoger un plazo de notificación en el DPA. Cuando aloja el sistema usted mismo, es a la vez responsable y operador, y la columna de responsable se reduce a sus propios equipos.
El DPA que necesita de un proveedor de gestores de contraseñas
Un acuerdo de tratamiento de datos (DPA) es el contrato que exige el artículo 28(3) entre un responsable y un encargado del tratamiento. En el caso de un proveedor de gestores de contraseñas, debe especificar el objeto, la duración, la naturaleza, la finalidad, los tipos de datos y las categorías de interesados, además de ocho obligaciones recogidas en los puntos (a) a (h). Las Directrices 07/2020 del CEPD sobre responsables y encargados explican cada una.
Término
Artículo
Qué pedir al proveedor
Instrucciones documentadas
28(3)(a)
Tratamiento solo conforme a sus instrucciones por escrito, incluidas las transferencias a terceros países, y la obligación de informarle de inmediato si una instrucción infringe la ley
Confidencialidad
28(3)(b)
Todas las personas autorizadas a tratar los datos, incluido el personal de soporte, sujetas a un deber de confidencialidad
Medidas de seguridad
28(3)(c)
Las medidas del artículo 32, detalladas en un anexo
Subencargados
28(3)(d), 28(2), 28(4)
Su autorización, aviso de cambios con derecho a oponerse, las mismas obligaciones trasladadas a la cadena
Derechos de los interesados
28(3)(e)
Ayuda para responder a solicitudes de acceso y eliminación
Asistencia
28(3)(f)
Ayuda con la seguridad, la notificación de vulneraciones y las evaluaciones de impacto (artículos 32 a 36)
Eliminación o devolución
28(3)(g)
Eliminación o devolución, a su elección, al finalizar el contrato, con un plazo indicado para las copias de seguridad
Auditorías
28(3)(h)
Información que demuestre el cumplimiento, y auditorías que incluyan inspecciones
La fila de auditorías es la que exige una lectura más atenta. El artículo 28(3)(h) exige que el contrato le facilite la información que demuestre el cumplimiento y permita auditorías, incluidas inspecciones. Si el proveedor no abre su infraestructura a una inspección in situ, el contrato debería indicar qué la sustituye.
La evidencia que revisa entonces incluye la lista de subencargados, una evaluación de transferencia y los informes de auditoría a los que el contrato le da derecho. Añada sus propios registros de la bóveda, exportados a un SIEM (sistema de gestión de eventos e información de seguridad).
Modelos de despliegue para una gestión de contraseñas conforme al RGPD
Su modelo de despliegue decide cuáles de las seis zonas controla su equipo. Una nube del proveedor deja la mayoría de las zonas en manos del proveedor, una nube en región de la UE reduce dónde se ubican, y el autoalojamiento las traslada a su infraestructura y a su lista de obligaciones. Los entornos aislados (air-gapped) van más allá y añaden la gestión de actualizaciones y registros sin conexión.
Opción
Dónde residen los datos
Situación de transferencia
Obligaciones que asume
Nube del proveedor, cualquier región
A elección del proveedor
Mecanismo y TIA si los datos o el acceso salen del EEE
DPA, revisión de subencargados, plazo de notificación de vulneraciones
Nube en región de la UE
Región de la UE elegida
Exposición menor, no nula
DPA, revisión de subencargados, condiciones de acceso de soporte
Alojamiento soberano de la UE
Proveedor de la UE, de propiedad de la UE
La más baja para un servicio alojado
DPA, auditoría del proveedor
Autoalojado en las instalaciones
Su infraestructura
Ninguna, salvo que el acceso de soporte o las copias de seguridad salgan del EEE
Copias de seguridad, claves, parches, registros
Aislado (air-gapped)
Red aislada
Ninguna
Obligaciones del autoalojamiento, más actualizaciones sin conexión
Un servicio gestionado por el proveedor le da menos control sobre los formatos de exportación y los plazos de salida. Antes de firmar, compruebe cómo saldría: qué formatos puede exportar y el plazo para eliminar las copias de seguridad conforme al artículo 28(3)(g).
Autoalojamiento y RGPD: Qué obligaciones asume
El autoalojamiento traslada las obligaciones del RGPD de un contrato con un proveedor a sus propios procedimientos operativos. Usted controla dónde se ubica cada zona y quién la opera, lo que puede eliminar la relación de encargado del tratamiento para la propia bóveda. Usted también se convierte en el operador, por lo que es usted quien aporta la evidencia. Nuestra página sobre el gestor de contraseñas on-premise trata esta opción de despliegue.
Lo que gana:
Control sobre dónde se ubica cada zona, incluidas las copias de seguridad
Ninguna transferencia a un proveedor ni cadena de subencargados para la propia bóveda
Lo que ahora debe:
Ubicaciones de las copias de seguridad y réplicas, restauraciones probadas y un calendario de conservación
Procedimientos de recuperación de claves, aplicación de parches y alta disponibilidad
Un registro actualizado de actividades de tratamiento (artículo 30)
Su propio proceso de detección y notificación de vulneraciones (artículo 33)
Ejemplo hipotético: un equipo restaura una bóveda tras una caída del servidor y descubre que la tarea de copia de seguridad nocturna llevaba tiempo escribiendo en un almacenamiento situado en un segundo país, configurado años antes por alguien que ya no está en la empresa. La bóveda estaba on-premises, pero una copia nunca lo estuvo. Esa copia plantea una cuestión de transferencia conforme al capítulo V. Una revisión zona por zona la detecta antes de que lo haga un incidente.
El riesgo interno sigue siendo suyo. El cifrado del lado del cliente significa que los administradores no pueden leer el contenido de la bóveda, pero sí pueden eliminar datos, copiar texto cifrado y copias de seguridad, cambiar la configuración o modificar registros. Separe funciones y registre las acciones de los administradores.
Los despliegues aislados (air-gapped) añaden otra obligación. Sin conexión a internet, usted aplica las actualizaciones y traslada los registros manualmente. El aislamiento no elimina las vulnerabilidades, y el soporte físico que introduce se convierte en la vía por la que una actualización llega al sistema.
El artículo 32(1) exige medidas proporcionales al riesgo. Documente quién aprueba un paquete de actualización, cómo verifica su integridad antes de importarlo, con qué frecuencia salen los registros de la red y quién gestiona el soporte físico. Pruebe también el procedimiento de restauración, ya que el 32(1)(c) y (d) cubren la restauración de la disponibilidad y las pruebas periódicas de sus medidas.
Cómo gestiona Passwork la ubicación de los datos y el acceso
Passwork Self-hosted funciona sobre infraestructura que usted controla: servidores on-premises, una nube privada o una red aislada. La bóveda, las claves y las copias de seguridad se ubican donde usted las ponga, de modo que su equipo decide dónde vive cada zona. Las respuestas siguientes siguen las seis zonas y las preguntas planteadas más arriba.
Passwork se instala con Docker en Linux (la vía recomendada), con un script de PowerShell en Windows Server, o manualmente, y los paquetes sin conexión cubren las redes aisladas. Las guías técnicas de Passwork explican cada vía.
Contenido de la bóveda y claves (zonas 1 y 2). Los datos se cifran en el cliente con AES-256, por lo que el servidor solo almacena texto cifrado y material de claves cifrado. La clave maestra se deriva con PBKDF2 y nunca sale del dispositivo del usuario en texto claro. Una segunda capa independiente de AES-256 protege la base de datos en el servidor.
La arquitectura de conocimiento cero decide quién puede leer los datos: solo los usuarios que poseen las claves, de modo que tampoco sus propios administradores pueden leer el contenido de la bóveda. La recuperación se realiza mediante una cuenta de recuperación preconfigurada cuya contraseña maestra usted almacena fuera de línea, y usted decide quién la posee.
Datos de servicio (zona 3). El registro de actividad recoge las acciones de usuarios, administradores y del sistema, y sus pistas de auditoría están listas para integrarse con un SIEM. Los nombres de registros y carpetas, la estructura de acceso y los metadatos de auditoría residen en el servidor, así que incorpórelos a su RoPA. Usted define la política de conservación y mantiene los registros en su propio almacenamiento.
Copias de seguridad y réplicas (zona 4). Los conjuntos de réplicas de MongoDB con tres o más miembros votantes, junto con servidores de aplicación escalados horizontalmente, dan al servicio tolerancia a fallos para más de 10 000 usuarios. Tareas programadas en segundo plano crean y rotan los archivos de copia de seguridad, y usted elige dónde se almacenan.
Cachés de los clientes y almacenes sin conexión (zona 5). El modo sin conexión es de solo lectura y debe activarse voluntariamente en dos niveles: el usuario marca un registro y, después, activa el modo sin conexión en un dispositivo concreto. Los administradores controlan qué roles pueden usarlo, el número máximo de registros por dispositivo y el tiempo máximo sin sincronizar antes de un borrado automático. Las descargas y visualizaciones sin conexión se sincronizan con el registro de actividad y el panel de seguridad cuando el dispositivo vuelve a conectarse.
Subencargados (zona 6). Un despliegue autoalojado no tiene ningún subencargado alojado por un proveedor. Su lista de proveedores se limita a sus propios proveedores de alojamiento y de copias de seguridad, y se les aplican las mismas preguntas anteriores. Un proveedor de nube privada que opere la bóveda por usted es su encargado del tratamiento y necesita su propio DPA.
El acceso sigue el principio de mínimo privilegio. El control de acceso basado en roles (RBAC) define los niveles de acceso para bóvedas y carpetas, la sincronización de grupos de LDAP y Active Directory traslada los cambios del directorio a Passwork, y el SSO mediante SAML gestiona el inicio de sesión. Passwork está certificado según ISO 27001, se somete a pruebas a través de HackerOne, y su código fuente está disponible para auditoría independiente.
Si su caso de cumplimiento depende de dónde están la bóveda, las claves y las copias de seguridad, lo mejor es comprobarlo en su propio entorno. Probar Passwork gratis.
Paquete de evidencias del RGPD para la gestión de contraseñas
El paquete de evidencias de 8 puntos es el conjunto de documentos que debería tener antes de una auditoría del RGPD de su gestor de contraseñas. Cubre los registros de tratamiento, las condiciones del proveedor, las evaluaciones de transferencia, las ubicaciones de las copias de seguridad, las revisiones de acceso y los procedimientos ante vulneraciones. Los puntos 1 a 6 corresponden a zonas individuales, mientras que los puntos 7 y 8 cubren el acceso y la gestión de vulneraciones en todas ellas.
Entrada del registro de actividades de tratamiento del gestor de contraseñas, con las seis zonas (artículo 30)
DPA firmado que cubra las condiciones del artículo 28(3), si un proveedor o proveedor de alojamiento trata alguna zona
Lista actualizada de subencargados y la cláusula de aviso de cambios, en la misma condición
Evaluación de impacto de la transferencia, si alguna zona afecta a un tercer país (capítulo V)
Evaluación de impacto relativa a la protección de datos, si su revisión de riesgos la exige (artículo 35)
Mapa de copias de seguridad y réplicas con ubicaciones y condiciones de eliminación
Revisión de accesos de los permisos de la bóveda, realizada a partir de exportaciones del registro de auditoría
Un procedimiento de vulneraciones de 72 horas que indique quién decide y quién notifica (artículo 33)
El RGPD no fija un intervalo concreto para las revisiones de acceso. Una cadencia trimestral es habitual, así que establezca una que se ajuste a su riesgo y documéntela.
El registro de auditoría es la evidencia que respalda los puntos 7 y 8. Muestra quién accedió a cada credencial y cuándo, lo que ayuda a delimitar el alcance de una vulneración y a valorar si pueden verse afectados datos personales. Expórtelo a su SIEM para que sobreviva a la bóveda y alimente el registro de vulneraciones que exige el artículo 33(5).
Por dónde empezar con la gestión de contraseñas conforme al RGPD
Una gestión de contraseñas conforme al RGPD empieza por hacer coincidir el despliegue con los datos que no puede permitir que salgan de su jurisdicción. Después, mantenga un contrato o un registro para cada zona que gestione un proveedor: dónde se ubican el contenido, las claves, los datos de servicio, las copias de seguridad, las cachés y los subencargados, y qué lo cubre a cada uno.
Empiece con una sola página. Dibuje las seis zonas de su gestor de contraseñas actual y marque las que no puede responder. Esas son sus primeras preguntas para el proveedor, o sus primeras tareas internas si se autoaloja. Una vez completo el mapa, la guía de seguridad de contraseñas del RGPD cubre la siguiente capa: normas de contraseñas y prácticas del personal.
¿Quiere ver cómo se ajusta una bóveda autoalojada a su mapa de zonas? Probar Passwork gratis.
Preguntas frecuentes
¿Exige el RGPD que los datos de las contraseñas se almacenen en la UE?
No, como regla general. El RGPD no impone un requisito general de localización de datos. Restringe las transferencias de datos personales fuera del EEE y exige un mecanismo lícito, como una decisión de adecuación o cláusulas contractuales tipo respaldadas por una evaluación de impacto de la transferencia (artículos 44 a 49). Las normas nacionales o sectoriales pueden añadir límites adicionales.
¿Es una contraseña almacenada un dato personal conforme al RGPD?
Por lo general, sí. Un registro de credenciales suele incluir un nombre de usuario, un correo electrónico o un historial de accesos que identifica a una persona, por lo que queda sujeto a las obligaciones de los artículos 5(1)(f), 25 y 32. Los datos cifrados siguen siendo datos personales. El cifrado es una medida de protección y no excluye los datos del ámbito del reglamento.
¿El cifrado de conocimiento cero nos hace cumplir el RGPD?
No. Protege el contenido de la bóveda, que es una de las medidas del artículo 32. Cuando un proveedor aloja el servicio, los metadatos, como las identidades de cuenta, las direcciones IP de inicio de sesión y las marcas de tiempo de acceso, suelen seguir siendo legibles para el proveedor. Sus obligaciones en materia de contratos, registros de tratamiento y notificación de vulneraciones siguen aplicándose.
¿Necesitamos un acuerdo de tratamiento de datos con el proveedor de nuestro gestor de contraseñas?
Sí, si el proveedor trata datos personales en su nombre. En ese caso es un encargado del tratamiento, y el artículo 28(3) exige un contrato que cubra las instrucciones documentadas, la confidencialidad, la seguridad, los subencargados, los derechos de los interesados, la eliminación o devolución, y los derechos de auditoría. Un despliegue autoalojado sin acceso del proveedor puede no necesitar ninguno. Confírmelo con su equipo legal.
¿Qué hay que documentar conforme al artículo 32?
El artículo 32 exige medidas adecuadas a su riesgo, como el cifrado, la seudonimización, la resiliencia y las pruebas periódicas. El deber de responsabilidad proactiva del artículo 5(2) implica que debe poder demostrarlas. En la práctica, conserve un registro de las medidas, pruebas de que funcionan y exportaciones del registro de auditoría.
Contraseñas conformes al RGPD: Dónde viven sus datos
Una bóveda en Fráncfort puede seguir sujeta a una orden judicial extranjera, y una etiqueta «alojado en la UE» no dice nada sobre dónde están las copias de seguridad.
The General Data Protection Regulation (GDPR), the EU's data protection law, requires a lawful transfer mechanism for sending personal data outside the European Economic Area (EEA, the EU plus Iceland, Liechtenstein and Norway), and security measures that fit the risk. For GDPR-compliant password management, know every place your credential data exists and hold proof for each one.
Your credentials can be stored in a Frankfurt data centre and still fall under a foreign court order if the provider is subject to a non-EU jurisdiction. An "EU hosted" label also says nothing about where the backups are. This article introduces the six-zone credential data map: the places where an enterprise password manager keeps data, the GDPR article each place triggers, and the evidence you need to hold. It ends with an 8-point evidence pack you can check before an audit.
Key takeaways
GDPR controls how personal data leaves the EEA, and each transfer needs a lawful mechanism.
A stored credential usually identifies an employee, so it is personal data. Encryption does not change that.
Credential data sits in six zones: vault payload, key material, service data, backups and replicas, client caches, and sub-processors. Each zone has its own duty and its own proof.
If a vendor processes any zone, it must sign a data processing agreement (DPA), a contract that sets what it may do with your data.
When you self-host, you take over backups, key recovery and record-keeping that a vendor would otherwise handle.
Your audit log shows who opened which credential and when, which helps you scope a breach and decide whether the 72-hour notification applies.
What GDPR-compliant password management requires
GDPR requires personal data to be processed securely, built with data protection from the start, and protected by measures that fit the risk.
GDPR-compliant password management means you can show that credential data is encrypted, reachable only by people who need it, logged, and covered by the right contracts and records wherever it is stored.
The law sets the outcome (Articles 5(1)(f), 25 and 32). You choose the controls and prove they work (Article 5(2)). In practice, that breaks down into five requirements:
Encrypt stored credentials. Article 32(1)(a) names "the pseudonymisation and encryption of personal data" as an appropriate measure.
Limit access by role (RBAC). Each person signs in under their own account and sees only what their job needs, even when the credential they open is shared. This is data protection by design (Article 25) applied to access.
Keep the service available and tested. Article 32(1)(b) to (d) covers resilience, restoring access after an incident and regular testing of your measures.
Record who opened what. An access log shows which credentials were reached and when. It is the evidence you need to judge whether a breach affected personal data (Article 33).
Document every place the data lives. That means a record of processing, a contract with each outside party that handles the data, and a lawful mechanism for any transfer outside the EEA.
These duties reach passwords for two reasons. A credential record normally names an employee or links to one, which makes it personal data (Article 4(1): any information relating to an identifiable person). The credentials also open other systems, such as HR, CRM and customer databases, where personal data is stored. Article 32(2) requires you to assess the risk of unauthorised access to personal data, so a breach of the password manager is a breach path into every system it unlocks. Encryption lowers the risk without taking the record out of scope.
Your organisation is the controller for the vault, the party that decides why and how the credential data is used. A vendor or hosting provider that runs or supports it on your instructions is a processor, and Article 28 requires a contract with it. Article 30 requires you to keep a record of processing activities (RoPA) that lists the recipients, locations and transfers for this processing. Finding those locations is the first job.
Residency, sovereignty and jurisdiction are three different things
Data residency is where your data is physically stored. Data sovereignty means the data is subject to the laws and legal control of a chosen country. Jurisdiction is which courts and authorities can issue orders to the vendor's company. A vendor subject to US law can store your vault in Germany and still receive US legal demands.
Term
What it tells you
What it leaves open
Residency
Which country holds the servers
Which laws can reach the data
Sovereignty
Which country's laws govern the data
Whether a foreign authority can still reach the vendor
Jurisdiction
Which authorities can order the vendor to act
Where your data is stored
The CLOUD Act lets US authorities require providers of electronic communication or remote computing services under US jurisdiction to hand over data in their possession, custody or control, even when it is stored abroad. A vendor that is a US company or has a US parent may therefore face such demands while your vault sits in an EU region. Whether a given vendor falls within the statute is a question for your legal team.
GDPR contains no general data-localisation rule. It regulates transfers to third countries in Chapter V (Articles 44 to 50), and remote access from outside the EEA, such as vendor support, can count as a transfer. Some national and sector rules add localisation requirements of their own, so check the ones that apply to you.
Transfers outside the EEA: Which mechanisms apply
Chapter V of GDPR requires a lawful transfer mechanism and safeguards that hold in the destination country. Remote support access from outside the EEA to a password vault hosted inside it counts as a transfer, so a hosting region alone does not settle the question. Three routes exist, and each applies in a different situation.
Adequacy decision (Article 45). The European Commission has ruled that the destination country's protection is equivalent. The EU-US Data Privacy Framework decision of 10 July 2023 covers only US companies that have self-certified, so check the vendor's entry on the framework list. Earlier EU-US frameworks were struck down in court, and the current one has been challenged, so keep standard contractual clauses as a fallback in the DPA.
Appropriate safeguards (Article 46). Usually standard contractual clauses (SCCs), model contract terms approved by the Commission, plus a transfer impact assessment (TIA). The TIA checks whether the destination country's law lets authorities access the data. It follows from the Schrems II ruling and the EDPB's Recommendations 01/2020.
Derogations (Article 49). Narrow exceptions, such as explicit consent after the individual is told of the risks. They suit occasional transfers and do not support routine vendor processing.
An EU hosting region lowers risk without removing it. Support staff outside the EEA, metadata handled elsewhere and a non-EEA parent company with access can each create a transfer. A foreign authority's power to order a parent to disclose data is a separate jurisdiction risk (see the residency section above). Treat the region as one input to your TIA, not as its conclusion.
The six-zone credential data map
The six-zone credential data map splits an enterprise password manager into six places where credential data exists. Each zone can sit in a different country and carries its own GDPR duty, so checking only "the server" misses copies you are responsible for.
Zone
Plain meaning
GDPR duty
1. Stored credentials
The stored logins, notes and files
Art. 32(1)(a), encryption
2. Key material
The keys that unlock them
Art. 32(1)(a), key control
3. Service data
Records of who used the system and when
Art. 30, Art. 33
4. Backups and replicas
Stored and live copies on other servers
Art. 28(3)(g), Art. 32(1)(c)
5. Client caches
Copies on user devices
Art. 32
6. Sub-processors
The vendor's suppliers and support access
Art. 28(2), 28(4), Chapter V
A password manager is a system of copies. You hold some of them, the vendor holds others, and the vendor's suppliers hold the rest. Which copies sit with you depends on the deployment model. In a self-hosted deployment you are the operator of every zone, so each question below applies to your own teams and hosting providers instead of a vendor.
Each zone also triggers a different duty. Backups raise deletion duties at contract end (Article 28(3)(g)), and suppliers raise duties that must pass down the chain (Article 28(4)). The next six subsections cover each zone and what to ask for.
Zone 1: Stored credentials
Stored credentials are the content users store: logins, notes, attachments and the secrets behind one-time codes. With client-side encryption, it reaches the server as ciphertext, data that is unreadable without the key. A stolen copy of the database then exposes only unreadable secrets, provided the key that unwraps the encrypted private key stays on the user's device (see Zone 2).
Encrypted credentials are still personal data when they relate to an identifiable person, so Zone 1 stays in scope. Article 32(1)(a) lists encryption as an example of an appropriate measure, and it lowers the risk. In your RoPA entry for the password manager, record this zone's location and encryption method.
Record names, folder structure and audit metadata are stored separately and belong to Zone 3. Give them their own RoPA line with the same location and access details.
Zone 2: Key material
Key material is the set of cryptographic keys that unlock stored credentials. Whoever holds the keys can read the data, wherever the ciphertext sits, so key location and key holders matter as much as server location. Article 32(1)(a) makes encryption appropriate only when the keys are controlled as carefully as the data.
The chain runs master password, master key, private key, vault keys, record keys. The user's master password derives the master key through a function such as PBKDF2, which makes password guessing slow. That key decrypts a private key, which decrypts vault keys, which in turn unlock the keys of individual records.
The server stores the private key and vault keys in encrypted form. The key that decrypts them stays on the user's device, so a copy of the database alone does not give access.
Recovery is the one key path worth mapping separately. Some designs include a recovery account or escrow key so an organisation can restore access after a lost master password. Whoever holds that key can also reach plaintext, so treat it like any other key: who holds it, where it is stored, and which courts can compel its holder. Our guide towhat zero-knowledge encryption does and does not protect explains the mechanics.
Zone 3: Service data
Service data is everything the system records about use rather than content. Client-side encryption does not cover it, so the operator can usually read it. That makes it personal data in its own right and the part of the system a legal demand can reach without touching the encryption. It typically includes:
Account identities, email addresses and billing records
Sign-in IP addresses, device identifiers and access timestamps
Audit logs, plus record names and folder structure if the product does not encrypt them
Three duties apply. Logs are your evidence for judging a breach (Articles 32 and 33). Retention must be limited to what you need (Article 5(1)(e)). Employees can request their own data (Article 15). In a self-hosted deployment, you hold this zone yourself.
Zone 4: Backups, replicas and disaster recovery
Backups, replicas and disaster recovery (DR) sites are the copies of credential data that live outside the primary server. Each copy can sit in a different country and under a different operator, so each needs its own answer on location, encryption and deletion.
Backups are stored copies for restoring data. Replicas are live copies on other servers. Disaster recovery (DR) sites are standby locations. They support availability and recovery (Article 32(1)(b) and (c)), but every extra copy widens the attack surface and the set of jurisdictions that apply. Ask three things:
Where is each backup and replica stored, and does any copy leave the EU or EEA? A copy in a third country can count as a transfer under Chapter V.
Are backups encrypted, and are the keys kept apart from the data?
After the contract ends, how many days until the last copy is gone, and how do you verify it?
Article 28(3)(g) requires the processor, at your choice, to delete or return all personal data when the services end, and to delete existing copies unless the law requires storage. Backups fall under that duty. In practice they often expire on a rotation cycle, so the retention window is the figure to get in writing.
Zone 5: Client caches and offline stores
Some data leaves the server by design. Desktop and mobile apps may keep offline copies, browser extensions may keep a session or unlock key, and users can export vault files. Each is a copy outside your central controls and travels wherever the employee's device does.
This is the zone where your own policy matters most. Decide whether offline mode is allowed, require disk encryption through mobile device management (MDM), and restrict who can export. Treat exports with the most care, since a CSV file is readable by anyone who opens it. Ask the vendor whether administrators can limit offline mode by role, whether cached data wipes itself after a set period, and whether offline use and exports are logged.
A lost device with a vault copy is a risk under Article 32(2), which names loss and unauthorised disclosure, and may trigger the breach-notification duties in Articles 33 and 34. List endpoints and approved export locations in your RoPA.
Zone 6: Sub-processor and support access
Sub-processors are the suppliers a vendor uses to deliver the service, such as hosting, email delivery, monitoring and support tooling. Under Article 28(2) and 28(4), the processor needs your authorisation to engage them and must pass the same data protection duties down the chain.
Third parties were involved in 48% of breaches in Verizon's 2026 DBIR, a 60% rise on the previous year. The report groups these cases into three archetypes: a vendor in your software supply chain, a vendor hosting your data in its environment, and a vendor with a connection to your environment. A hosted password manager is the second kind, and a support or integration link into your systems can make it the third. Check the vendor's suppliers as closely as its product.
Ask for four things:
A current list of sub-processors and the country each operates in
Advance notice of changes, with a right to object
Who on the vendor's support team can see service data (Zone 3), and under what approval
Whether any sub-processor or support route can touch key material (Zone 2)
Zone-to-article map: The obligation and the evidence
The zone-to-article map pairs each of the six credential zones with the GDPR provision it triggers, the document that proves compliance, and the party who owns it. Use it as the skeleton for your RoPA entry on the password manager, and fill the evidence column before an auditor asks. The evidence pack at the end lists the same documents as a checklist.
Zone
GDPR hook
Evidence to hold
Owner
1. Stored credentials
Art. 32(1)(a), Art. 30
Encryption description, RoPA entry
Controller decides, processor implements
2. Key material
Art. 32(1)(a), Art. 25
Key hierarchy and recovery design
Processor, reviewed by controller
3. Service data
Art. 15, Art. 28(3)(e), Arts. 44-46
Data inventory, log export procedure, transfer assessment
The split decides who notifies. Under Article 33, the controller notifies the supervisory authority within 72 hours of becoming aware of a breach, where feasible. The processor must tell you "without undue delay", which sets no number, so write a notification window into the DPA. When you self-host, you are both controller and operator, and the Owner column collapses to your own teams.
The DPA you need from a password manager vendor
A data processing agreement (DPA) is the contract that Article 28(3) requires between a controller and a processor. For a password manager vendor, it must state the subject matter, duration, nature, purpose, data types and data subject categories, plus eight obligations in points (a) to (h). The EDPB Guidelines 07/2020 on controllers and processors explain each one.
Term
Article
What to ask the vendor for
Documented instructions
28(3)(a)
Processing only on your written instructions, transfers to third countries included, and a duty to tell you at once if an instruction breaks the law
Confidentiality
28(3)(b)
Everyone authorised to process, support staff included, bound by confidentiality
Security measures
28(3)(c)
The Article 32 measures, named in an annex
Sub-processors
28(3)(d), 28(2), 28(4)
Your authorisation, notice of changes with a right to object, the same obligations passed down
Data subject rights
28(3)(e)
Help answering access and erasure requests
Assistance
28(3)(f)
Help with security, breach notification and impact assessments (Articles 32 to 36)
Deletion or return
28(3)(g)
Deletion or return at your choice when the contract ends, with a stated deadline for backups
Audits
28(3)(h)
Information that proves compliance, and audits including inspections
The audit row needs the closest reading. Article 28(3)(h) requires the contract to give you the information that proves compliance and to allow audits, including inspections. If the vendor won't open its infrastructure to on-site inspection, the contract should state what replaces it.
The evidence you review then includes the sub-processor list, a transfer assessment and the audit reports the contract entitles you to. Add your own vault logs, exported to a SIEM (a system that collects and analyses security logs).
Deployment models for GDPR-compliant password management
Your deployment model decides which of the six zones your team controls. A vendor cloud leaves most zones with the vendor, an EU-region cloud narrows where they sit, and self-hosting moves them onto your infrastructure and your duties list. Air-gapped setups go furthest and add offline update and log handling.
Option
Where data sits
Transfer position
Duties you inherit
Vendor cloud, any region
Vendor's choice
Mechanism and TIA if data or access leaves the EEA
DPA, sub-processor review, breach window
EU-region cloud
Chosen EU region
Lower exposure, not zero
DPA, sub-processor review, support-access terms
EU-sovereign hosting
EU provider, EU-owned
Lowest for a hosted service
DPA, provider audit
Self-hosted on-premises
Your infrastructure
None, unless support access or backups leave the EEA
Backups, keys, patching, records
Air-gapped
Isolated network
None
Self-hosted duties, plus offline updates
A vendor-managed service gives you less control over export formats and exit timing. Before you sign, check how you would leave: which formats you can export, and the deadline for deleting backups under Article 28(3)(g).
Self-hosting and GDPR: Which duties you take on
Self-hosting moves GDPR duties from a vendor contract into your own operating procedures. You control where every zone sits and who operates it, which can remove the processor relationship for the vault itself. You also become the operator, so you carry the evidence yourself. Our on-premise password manager page covers the deployment option.
What you gain:
Control over where every zone sits, including backups
No transfer to a vendor and no sub-processor chain for the vault itself
What you now owe:
Backup and replica locations, tested restores and a retention schedule
Key recovery procedures, patching and high availability
An updated record of processing activities (Article 30)
Your own breach detection and notification process (Article 33)
Hypothetical example: a team restores a vault after a server crash and finds that the nightly backup job has been writing to storage in a second country, set up years earlier by someone who has since left. The vault was on-premises, but one copy never was. That copy is a transfer question under Chapter V. A zone-by-zone check finds it before an incident does.
Insider risk stays with you. Client-side encryption means administrators can't read vault contents, but they can still delete data, copy ciphertext and backups, change configuration or edit logs. Separate duties and log administrator actions.
Air-gapped deployments add another duty. With no internet connection, you apply updates and move logs manually. Isolation doesn't remove vulnerabilities, and the media you carry in becomes the way an update reaches the system.
Article 32(1) requires measures appropriate to the risk. Document who approves an update package, how you verify its integrity before import, how often logs leave the network and who handles the media. Test the restore procedure too, since 32(1)(c) and (d) cover restoring availability and regularly testing your measures.
How Passwork handles data location and access
Passwork self-hosted runs on infrastructure you control: on-premises servers, a private cloud or an air-gapped network. The vault, the keys and the backups sit where you put them, so your team decides where each zone lives. The answers below follow the six zones and the questions asked above.
Passwork installs with Docker on Linux (the recommended path), with a PowerShell script on Windows Server, or manually, and offline packages cover air-gapped networks. The Passwork tech guides cover each route.
Vault payload and keys (zones 1 and 2). Data is encrypted on the client with AES-256, so the server stores only ciphertext and encrypted key material. The master key is derived with PBKDF2 and never leaves the user's device in plaintext. A second, independent AES-256 layer protects the database on the server.
Zero-knowledge architecture decides who can read the data: only the users who hold the keys, so your own administrators can't read vault contents either. Recovery runs through a pre-provisioned recovery account whose master password you store offline, and you decide who holds it.
Service data (zone 3). The Activity Log records user, admin and system actions, and its audit trails are ready for SIEM integration. Record and folder names, access structure and audit metadata sit on the server, so list them in your RoPA. You set the retention policy and keep the logs on your own storage.
Backups and replicas (zone 4). MongoDB replica sets with three or more voting members, together with horizontally scaled application servers, give the service fault tolerance for 10,000+ users. Scheduled background tasks create and rotate backup archives, and you choose where they are stored.
Client caches and offline stores (zone 5). Offline mode is read-only and opt-in at two levels: the user marks a record, then enables offline on a specific device. Administrators control which roles may use it, the maximum records per device and the maximum unsynced time before an automatic wipe. Offline downloads and views sync to the Activity Log and the Security Dashboard when the device reconnects.
Sub-processors (zone 6). A self-hosted deployment has no vendor-hosted sub-processor. Your supplier list is limited to your own hosting and backup providers, and the same questions above apply to them. A private-cloud host that runs the vault for you is your processor and needs its own DPA.
Access follows least privilege. Role-based access control (RBAC) sets access levels for vaults and folders, LDAP and Active Directory group sync carries directory changes into Passwork, and SAML SSO handles sign-in. Passwork is ISO 27001 certified, tested through HackerOne, and its source code is available for independent audit.
If your compliance case turns on where the vault, the keys and the backups sit, test it in your own environment. Start a free Passwork trial.
GDPR evidence pack for password management
The 8-point evidence pack is the set of documents you should hold before a GDPR audit of your password manager. It covers processing records, vendor terms, transfer assessments, backup locations, access reviews and breach procedures. Items 1 to 6 map to individual zones, while items 7 and 8 cover access and breach handling across all of them.
Record of processing activities entry for the password manager, listing all six zones (Article 30)
Signed DPA covering the Article 28(3) terms, if a vendor or hosting provider processes any zone
Current sub-processor list and the change-notice clause, under the same condition
Transfer impact assessment, if any zone touches a third country (Chapter V)
Data protection impact assessment, if your risk review requires one (Article 35)
Backup and replica map with locations and deletion terms
Access review of vault permissions, run from audit log exports
A 72-hour breach procedure that names who decides and who notifies (Article 33)
GDPR sets no fixed interval for access reviews. Quarterly is a common cadence, so set one that matches your risk and document it.
The audit log is the evidence behind items 7 and 8. It shows who accessed which credential and when, which helps you scope a breach and judge whether personal data may be affected. Export it to your SIEM so it outlives the vault and feeds the breach record required by Article 33(5).
Where to start with GDPR-compliant password management
GDPR-compliant password management starts with matching the deployment to the data you cannot let leave your jurisdiction. Then hold a contract or record for every zone a vendor handles: where the payload, keys, service data, backups, caches and sub-processors sit, and what covers each.
Start with a single page. Draw the six zones for your current password manager and mark the ones you cannot answer. Those are your first vendor questions, or your first internal tasks if you self-host. Once the map is complete, the GDPR password security guide covers the next layer: password rules and staff practice.
Does GDPR require password data to be stored in the EU?
Not as a general rule. GDPR has no blanket data-localisation requirement. It restricts transfers of personal data outside the EEA and requires a lawful mechanism, such as an adequacy decision or standard contractual clauses backed by a transfer impact assessment (Articles 44 to 49). National or sector rules may add limits.
Is a stored password personal data under GDPR?
Usually, yes. A credential record normally includes a username, email or access history that identifies a person, so it falls under the duties in Articles 5(1)(f), 25 and 32. Encrypted data remains personal data. Encryption is a protective measure and does not take data outside the regulation.
Does zero-knowledge encryption make us GDPR compliant?
No. It protects the vault payload, which is one measure under Article 32. When a vendor hosts the service, metadata such as account identities, sign-in IP addresses and access timestamps typically remains readable by the provider. Your duties on contracts, records of processing and breach notification still apply.
Do we need a data processing agreement with our password manager vendor?
Yes, if the vendor processes personal data for you. It is then a processor, and Article 28(3) requires a contract covering documented instructions, confidentiality, security, sub-processors, data subject rights, deletion or return, and audit rights. A self-hosted deployment with no vendor access may need none. Confirm with your legal team.
What has to be documented under Article 32?
Article 32 requires measures that fit your risk, such as encryption, pseudonymisation, resilience and regular testing. The accountability duty in Article 5(2) means you must be able to show them. In practice, keep a record of the measures, proof that they operate, and audit log exports.
GDPR-compliant password management: Where your data lives
A vault in Frankfurt can still answer to a foreign court order, and an "EU hosted" label says nothing about where the backups are. Use the six-zone map to find every place your credentials live, the GDPR duty each one triggers, and the evidence to hold before an audit.
A gestão do ciclo de vida de identidades académicas rege o acesso de uma pessoa à medida que muda a sua situação como estudante, docente, investigador ou colaborador. No ensino superior, funciona melhor em três percursos: para estudantes, para docentes e instrutores e para pessoal não docente. Cada percurso tem os seus próprios desencadeadores e aprovações, unidos num único registo de identidade.
Um estudante que conclui o curso, um docente convidado cujo período letivo terminou e um colaborador que se demite desencadeiam, muitas vezes, o mesmo pedido de saída, embora cada um deva perder acessos diferentes em datas diferentes. Este guia apresenta uma matriz de ciclo de vida para as três populações, regras para funções sobrepostas e uma lista de verificação de implementação a 90 dias.
Pontos principais
Os estudantes, os docentes e instrutores e o pessoal não docente precisam de regras de acesso separadas, porque cada grupo é criado e alterado por um sistema diferente e por um evento de negócio diferente.
Uma pessoa pode ter várias funções em simultâneo. O sistema de identidade deve manter um único registo dessa pessoa e adicionar ou remover acessos por função, e não reconstruir a conta.
O sistema de registo do estado académico, do estado laboral e das atribuições letivas raramente é o mesmo. Regras de precedência escritas resolvem os conflitos entre eles.
O provisionamento automatizado só funciona depois de os dados que o alimentam serem fiáveis. A revisão e o tratamento de exceções continuam a ser importantes depois de a automatização estar em vigor.
Porque é que a gestão do ciclo de vida de identidades académicas exige três percursos
O ensino exige ciclos de vida de acesso separados, porque o estatuto de estudante, as nomeações docentes e o emprego do pessoal são criados e alterados por sistemas e eventos diferentes. Um único processo genérico de integração e saída tem dificuldade em conceder o acesso certo a tempo e em removê-lo quando o motivo desse acesso termina.
O acesso de um estudante está associado à matrícula, à inscrição em unidades curriculares e à situação académica.
O acesso de um membro do pessoal não docente está associado a uma função e a um registo laboral.
O acesso de um docente depende frequentemente de uma nomeação e de uma atribuição letiva específica, que podem começar e terminar num calendário distinto do do registo laboral.
Este padrão costuma ser descrito como Joiner-Mover-Leaver (JML): um quadro de referência para acompanhar quando alguém entra numa organização, muda de função e acaba por sair. No ensino, «leaver» (quem sai) é a designação errada para um estudante que conclui o curso mas mantém acesso limitado como alumni, ou para um docente cuja atribuição letiva termina enquanto a nomeação continua. Um fluxo JML genérico oculta estes casos, a menos que modele eventos específicos de cada função, períodos de tolerância e afiliações sobrepostas. O modelo de três percursos fá-lo.
A mesa-redonda de 2025 da InCommon sobre práticas de identidade no ensino superior concluiu que 27 % dos inquiridos tinham mais dificuldade com políticas e normas, 23 % com o controlo de acesso baseado em funções (RBAC) e 14 % com a compreensão de como as diferentes populações percorrem os seus ciclos de vida. A sondagem não permite identificar uma causa única. Mostra, porém, que a política, a conceção de funções e a responsabilidade pelo ciclo de vida merecem tanta atenção como a escolha da tecnologia.
A matriz do ciclo de vida de acesso académico
A matriz do ciclo de vida de acesso académico (AALM) transforma a conceção do ciclo de vida em oito decisões, repetidas para cada uma das três populações: evento desencadeador, fonte de autoridade, atributos de identidade, acesso de base, acesso condicional, responsável pela aprovação, ponto de revisão e ação de fim de acesso. O preenchimento destes oito campos para estudantes, docentes e instrutores e pessoal não docente dá à instituição um documento de política utilizável, em vez de um quadro abstrato.
O guia federal de gestão do ciclo de vida de identidades descreve a criação, a modificação e a eliminação como as fases centrais para provisionar, ajustar e revogar acessos segundo o princípio do menor privilégio, ou seja, os utilizadores recebem apenas o acesso que a sua função atual exige. A AALM adapta essa lógica ao ensino, onde a «modificação» abrange uma variedade muito maior do que uma mudança de função típica numa empresa.
Campo da AALM
Estudantes
Docentes/instrutores
Pessoal não docente
Exemplos de desencadeadores
Matrícula, mudança de unidade curricular, interrupção, conclusão
Nomeação, atribuição letiva, alteração de contrato
Contratação, mudança de departamento, cessação
Fonte de autoridade
Sistema de informação de estudantes (SIS), secretaria académica
RH/HCM e dados dos assuntos académicos
RH/HCM, processamento salarial
Atributos de identidade
Número de estudante, curso, estado da matrícula, situação académica
Número de colaborador, tipo de nomeação, departamento, atribuições letivas
Número de colaborador, código da função, departamento, superior hierárquico
Acesso de base
Fornecedor de identidade, e-mail, sistema de gestão de aprendizagem (LMS)
Fornecedor de identidade, e-mail, ferramentas das unidades curriculares atribuídas
Fornecedor de identidade, aplicações de negócio relevantes para a função
Lançamento de notas, investigação, administração do departamento
Finanças, administração de TI, portais de fornecedores
Responsável pela aprovação
Secretaria académica ou autoridade académica
Departamento e responsável pela aplicação
Superior hierárquico e RH
Ponto de revisão
Início de cada período letivo, alteração de estado, conclusão do curso
Início do período letivo, prazo de lançamento de notas, fim do período letivo
Recertificação anual, mudança de função
Ação de fim de acesso
Desistência, conclusão do curso, política para alumni
Fim do período letivo, período de tolerância aprovado por política
Cessação, mudança de função
As três secções seguintes mostram como os mesmos campos mudam consoante a população. O acesso de base, os atributos e as fontes de autoridade variam de instituição para instituição. A matriz deve ser tratada como ponto de partida para o planeamento: convém preencher os sistemas e os responsáveis pela aprovação da própria instituição antes de considerar definitiva qualquer linha.
Gestão de acessos de estudantes, da matrícula ao estatuto de alumni
A gestão de acessos de estudantes liga os eventos do estado académico a um modelo de direitos de acesso que adiciona, ajusta ou retira acessos sem criar uma nova identidade sempre que a situação de um estudante muda. A matrícula, a interrupção, a desistência, a conclusão do curso e a passagem ao estatuto de alumni alteram, cada uma, aquilo a que o estudante pode aceder, enquanto o registo da pessoa se mantém.
A cadeia de eventos do estudante
A cadeia estende-se, normalmente, do acesso prévio à chegada, concedido a candidatos, à matrícula ou ingresso, às alterações de curso e de unidades curriculares, à interrupção de estudos, à desistência, à conclusão do curso e à passagem ao estatuto de alumni. Convém avaliar, para cada evento, se deve criar uma nova identidade, alterar o acesso existente ou desencadear uma revisão de estado. Na maioria dos casos, o registo da pessoa já existe e o evento altera o acesso em vez de criar uma segunda identidade.
Ligar o acesso aos dados académicos
O SIS ou a secretaria académica funciona habitualmente como fonte de autoridade para os atributos do estado académico e alimenta o LMS, a jusante, com os dados de inscrição em unidades curriculares. Convém documentar o modo como esses dados chegam ao LMS (integração direta, middleware ou uma camada de governação de identidades), em vez de presumir um caminho fixo. Quando o registo de um estudante não corresponde de forma limpa, por exemplo após uma alteração de nome, uma candidatura duplicada ou uma transferência de estudante com duas contas anteriores, deve encaminhar-se para uma fila de exceções. Não se deve permitir que o sistema crie silenciosamente uma segunda conta.
Proteger os registos educativos e os dados de apoio financeiro
O 34 CFR § 99.31(c) exige que as instituições utilizem métodos razoáveis para identificar e autenticar as pessoas a quem divulgam informações de identificação pessoal constantes de registos educativos. A conservação de registos de pedidos e de divulgações enquadra-se no § 99.32. Esse requisito abrange a divulgação de informações dos registos educativos. Não substitui o registo habitual de acessos ao nível da aplicação.
Quando estão em causa dados de apoio financeiro, a orientação GEN-25-08 do Departamento de Educação aborda o acesso permitido a Federal Tax Information e a dados do FAFSA por parte de instituições elegíveis. Nenhuma das fontes define uma arquitetura técnica. O departamento jurídico da instituição deve confirmar de que forma cada uma se aplica aos sistemas existentes.
O acesso de docentes e instrutores exige um ciclo de vida próprio
O acesso de docentes e instrutores exige um ciclo de vida próprio, porque o acesso para lecionar depende de uma nomeação, de uma atribuição letiva concreta e de obrigações de lançamento de notas, e não de uma data normal de início e de fim de contrato. Os docentes convidados e os docentes visitantes tornam isto evidente: o respetivo acesso ao LMS pode ter de começar antes do contrato e prolongar-se para além do período letivo.
A EDUCAUSE descreve um cenário comum: um instrutor de curta duração precisa de acesso ao LMS antes da data oficial de início para preparar uma unidade curricular e pode precisar de acesso limitado depois do fim do período letivo para concluir o lançamento de notas. Um ciclo de vida genérico de colaborador, construído em torno de uma única data de contratação e de uma única data de cessação, trata mal este padrão. As instituições precisam de uma política documentada com um período de tolerância explícito.
Evento letivo
Ação de acesso
Responsável
Ponto de revisão
Nomeação aprovada
Provisionar acesso de base
Assuntos académicos
No início da nomeação
Atribuição letiva confirmada
Adicionar acesso ao LMS por unidade curricular
Departamento, responsável pela aplicação
No início do período letivo
Lançamento de notas concluído
Assinalar para revisão
Secretaria académica
No prazo de lançamento de notas
Fim do contrato ou do período letivo
Expirar o acesso às unidades curriculares; manter o acesso de base em caso de renomeação
Departamento
No fim do período letivo
Prorrogação aprovada
Prorrogar o período de tolerância com data de fim documentada
Diretor de departamento
No pedido de prorrogação
O direito de acesso individual de um docente ao LMS ou ao e-mail pertence ao modelo de acessos da IAM/IGA. Uma camada de gestão de credenciais é mais relevante para as contas operacionais partilhadas que a TI ou um responsável designado controla diretamente, como sistemas de laboratório ou credenciais de fornecedores.
Ciclo de vida do pessoal não docente: Eventos laborais, mudanças de função e saídas
O acesso do pessoal não docente deve seguir eventos validados de emprego e de mudança de funções, com o superior hierárquico ou o responsável de negócio relevante a confirmar qualquer acesso para além do pacote padrão da função. Os desencadeadores típicos são a contratação, a transferência, a promoção, a licença e a cessação, e cada um deve reavaliar os direitos de acesso existentes, e não apenas adicionar novos.
Um modo de falha comum é a acumulação de privilégios (privilege creep): alguém recebe novo acesso após uma promoção e ninguém remove o acesso associado à função anterior. A recertificação regular de acessos, uma revisão agendada em que o superior hierárquico confirma que o acesso de cada pessoa continua a ser necessário, deteta este problema antes de se tornar uma constatação de auditoria.
O NIST SP 1800-35 apresenta o acesso autorizado seguro como uma decisão contínua, e não como uma concessão pontual, assente numa governação de identidades reforçada em recursos distribuídos, on-premises e na nuvem. Aplicar isto ao acesso do pessoal é uma opção de conceção, e não um requisito do NIST: tratar cada mudança de função como um desencadeador para reavaliar os direitos de acesso existentes.
Uma pessoa, várias funções: Governar transições e sobreposições
Um modelo de identidade com várias funções mantém um único registo por pessoa e concede apenas o acesso justificado por cada função ativa. Isto evita contas duplicadas e permite remover o acesso associado a uma função sem alterar o acesso proveniente de outra.
Seis cenários abrangem a maioria das sobreposições com que as instituições se deparam:
Um estudante passa a colaborador, como quando estudantes trabalhadores assumem funções a tempo parcial
Um membro do pessoal ou do corpo docente matricula-se como estudante
Um docente é, em simultâneo, instrutor, investigador e administrador de departamento
Um estudante trabalhador muda de departamento ou tem dois empregos ao mesmo tempo
Um alumnus ou reformado recebe acesso limitado e com prazo definido a um serviço específico
Um prestador de serviços ou colaborador externo precisa de um acesso que expira automaticamente numa data definida
A regra mais importante: quando uma afiliação termina, deve remover-se apenas o acesso associado a essa afiliação. Podem ocorrer dois erros. O sistema pode retirar acesso que outra função ativa continua a justificar ou pode deixar acesso em vigor depois de a afiliação ter terminado. A correspondência fiável de identidades (confirmar que dois registos pertencem à mesma pessoa) e uma fila de revisão documentada para os casos que as regras automáticas não conseguem resolver mantêm ambos os erros sob controlo.
As credenciais partilhadas de laboratórios, de TI e de fornecedores ficam muitas vezes fora dos fluxos de ciclo de vida. Experimentar o Passwork gratuitamente permite colocá-las sob acesso baseado em funções e registo de auditoria.
Construir a camada de dados e de integração antes de automatizar
A automatização funciona quando uma instituição já identificou as suas fontes de autoridade, construiu uma correspondência fiável de identidades e definiu a precedência dos dados em caso de conflito entre sistemas. Sem estes três elementos, as regras de provisionamento atuam sobre registos desatualizados ou sem correspondência e concedem acesso demasiado cedo ou deixam-no em vigor durante demasiado tempo.
Deve atribuir-se a fonte de autoridade por atributo e não por sistema. Um modelo comum atribui os atributos do estado académico ao SIS ou à secretaria académica, os atributos laborais ao RH/HCM e ao processamento salarial e os atributos de atribuição letiva a um sistema de planeamento de horários ou de assuntos académicos. A titularidade varia de campus para campus, pelo que convém documentar a autoridade e a precedência ao nível do atributo para o ambiente da própria instituição.
Algumas credenciais não têm um responsável natural em nenhum destes sistemas. Uma credencial partilhada de administração na nuvem, utilizada por três engenheiros de infraestrutura, não pertence nem aos RH nem ao SIS. Uma camada de governação e administração de identidades (IGA) pode registar que a equipa de infraestrutura é responsável por ela. O segredo propriamente dito continua a exigir um sistema concebido para armazenar, rodar e auditar credenciais partilhadas. Trata-se de um controlo distinto.
Um fluxo de eventos básico é o seguinte:
Ocorre um evento no sistema de registo
A correspondência de identidades confirma a que pessoa se aplica
Uma regra de política avalia o que deve mudar
Realiza-se uma aprovação, quando exigida
Executa-se o provisionamento ou a revogação
Um evento de auditoria regista o que aconteceu
Qualquer passo que falhe, como uma identidade sem correspondência ou um evento desatualizado, deve seguir para uma fila de exceções visível, com um responsável atribuído. Não deve desaparecer em silêncio.
O NIST SP 800-63-4 estabelece requisitos para a verificação de identidade, a inscrição, a gestão de autenticadores, a autenticação e a federação. É uma referência útil para a camada de identidade subjacente a esta automatização, embora não prescreva uma arquitetura para o ensino.
Aplicar controlos de acesso e evidências proporcionais ao risco
Os controlos de acesso devem corresponder à sensibilidade do recurso e à função atual da pessoa, ao passo que as evidências de auditoria devem mostrar quem aprovou o acesso, quando foi alterado e se continua justificado. Os controlos de base abrangem o princípio do menor privilégio, o controlo de acesso baseado em funções (RBAC), a MFA, o SSO, as revisões agendadas, o acesso com limite de tempo e a segregação de funções.
A segregação de funções impede que uma mesma pessoa solicite e aprove o seu próprio acesso. As regras baseadas em políticas podem acrescentar contexto que uma função, por si só, não transporta, como as datas de nomeação ou as atribuições letivas. As contas órfãs, ou seja, contas que continuam ativas depois de terminada a afiliação que as justificava, devem ser assinaladas automaticamente, em vez de serem descobertas durante uma auditoria.
As credenciais operacionais partilhadas precisam da sua própria camada. Um programa de IAM/IGA pode governar a titularidade e a revisão de uma conta de serviço partilhada, de um sistema de laboratório ou das credenciais de um portal de fornecedores, determinando quem é responsável e quando o acesso é recertificado. Não armazena, não roda nem partilha o segredo em segurança. É aí que uma camada de gestão de credenciais assume o papel.
Testar o Passwork na infraestrutura da organização com um teste gratuito. 50 % de desconto para instituições de ensino e organizações sem fins lucrativos em compras até ao final do ano.
Lista de verificação de implementação da gestão do ciclo de vida de identidades académicas: Os primeiros 90 dias
Os primeiros 90 dias devem servir para definir a política, modelar as três populações, validar os dados de origem, pilotar um número reduzido de aplicações e medir as exceções por resolver antes de a automatização se alargar. A lista de verificação abaixo segue essa ordem e termina com a revisão jurídica e de privacidade. Cada passo produz um documento ou uma métrica que o grupo de governação pode rever.
A lista de verificação de 90 dias do ciclo de vida de identidades académicas (10 pontos)
Constitua um grupo de governação: secretaria académica, RH, assuntos académicos, IAM/TI, segurança, responsáveis pelas aplicações e apoio ao utilizador
Defina o registo da pessoa e as regras de correspondência de identidades entre sistemas
Mapeie os estados do ciclo de vida e os respetivos desencadeadores para estudantes, docentes/instrutores e pessoal não docente
Atribua uma fonte de autoridade e uma regra de precedência a cada atributo-chave
Elabore a AALM para as primeiras cinco aplicações ou serviços
Redija as regras de aprovação, de exceção, de período de tolerância e de saída de emergência
Pilote o provisionamento e o desprovisionamento automatizados com monitorização ativa
Defina as métricas de referência: tempo de provisionamento, tempo de desativação, acumulação de exceções, contas dormentes, acessos temporários em atraso e taxa de conclusão das revisões
Realize exercícios de simulação (tabletop) para cenários de várias funções e de fim de período letivo antes da entrada em produção
Peça aos responsáveis jurídicos e de privacidade que revejam a política antes de a aplicar em larga escala
A InCommon recomenda a mesma sequência: definir as necessidades locais do ciclo de vida, mapeá-las visualmente, estabelecer a governação, melhorar a qualidade dos dados de origem, planear as exceções e documentar as decisões.
Conclusão
O ciclo de vida de identidades académicas deve ser tratado primeiro como um problema de política e só depois como um problema de ferramentas. Três fluxos de eventos, três responsáveis, um único registo por pessoa: é isto que permite remover o acesso ao laboratório de um estudante que concluiu o curso sem afetar o emprego que passou a ter na secretaria académica.
Passo seguinte: reunir o grupo de governação e acordar as primeiras cinco aplicações a mapear, ordenadas pela sensibilidade dos dados que contêm.
Depois de definida a política de ciclo de vida, iniciar um teste gratuito do Passwork para gerir as credenciais partilhadas que as equipas de TI e de operações ainda tratam fora da plataforma de IAM.
Perguntas frequentes
Qual é a diferença entre a gestão de acessos de estudantes e a do pessoal?
O acesso dos estudantes está associado ao estado académico e à participação nas unidades curriculares, enquanto o acesso do pessoal está associado ao emprego e às funções exercidas. O acesso de docentes e instrutores combina frequentemente uma nomeação com uma atribuição letiva concreta, pelo que precisa de um ciclo de vida próprio, em vez de ser agrupado com o acesso do pessoal em geral. Cada grupo tem um sistema de origem e aprovadores diferentes.
Que sistema deve ser a fonte de autoridade para o acesso académico?
Nenhum sistema único serve todas as instituições. Uma abordagem comum utiliza o SIS ou a secretaria académica para o estado académico, o RH/HCM para o estado laboral e um sistema de planeamento de horários ou de assuntos académicos para as atribuições letivas. A camada de IAM/IGA aplica então regras de precedência documentadas quando estas fontes entram em conflito, de modo que cada atributo tenha um responsável nomeado.
O que acontece quando um estudante passa a ser colaborador?
Mantenha um único registo por pessoa e adicione a afiliação laboral depois de validada. Provisione o acesso associado à função através do fluxo normal e mantenha o acesso de estudante que continue justificado pela matrícula ativa. Quando o emprego terminar, remova apenas o acesso associado à função. Isto evita contas duplicadas e mantém o registo de auditoria associado a uma única identidade.
Quando devem os docentes ou instrutores perder o acesso depois de terminado o período letivo?
Baseie a decisão em regras documentadas de atribuição letiva, de lançamento de notas e de período de tolerância. Indique o aprovador que pode prorrogar o acesso, liste as aplicações afetadas e defina um evento de expiração claro. Registe cada prorrogação com uma data de fim, para que o registo de auditoria mostre quem a aprovou e porque é que o acesso se prolongou para além do período letivo.
Como podem as instituições reduzir as contas órfãs?
Desencadeie as alterações das contas a partir de eventos do ciclo de vida provenientes das fontes de autoridade, automatize as alterações de estado, limite no tempo todas as exceções e reveja periodicamente as contas inativas ou sem correspondência com uma identidade válida. A EDUCAUSE recomenda uma política documentada de ciclo de vida das contas e um processo de governação de identidades, em vez de exceções manuais permanentes.
Gestão do ciclo de vida de identidades de estudantes e pessoal
Um estudante diplomado, um docente convidado sem contrato e um demissionário são três eventos distintos, mas a maioria das ferramentas de identidade trata-os como uma só «saída». Crie ciclos de acesso separados, una-os num registo de identidade e retire apenas o acesso que já não se justifica.
Akademisches Identity-Lifecycle-Management regelt den Zugriff einer Person, wenn sich ihr Status als Studierende, Lehrkraft, Forschende oder Mitarbeiter ändert. Im Hochschulbereich funktioniert es am besten mit drei Tracks: für Studierende, Lehrkräfte und Dozierende sowie für Mitarbeiter. Jeder Track hat eigene Trigger und Freigaben, die in einem Identitätsdatensatz zusammenlaufen.
Ein Studierender, der seinen Abschluss macht, ein Lehrbeauftragter mit auslaufendem Vertrag und ein kündigender Mitarbeiter lösen oft dasselbe Offboarding-Ticket aus, obwohl jeder zu einem anderen Zeitpunkt unterschiedlichen Zugriff verlieren sollte. Dieser Leitfaden bietet eine Lifecycle-Matrix für alle drei Gruppen, Regeln für überlappende Rollen und eine 90-Tage-Checkliste für den Rollout.
Das Wichtigste in Kürze
Studierende, Lehrkräfte und Dozierende sowie Mitarbeiter benötigen separate Zugriffsregeln, da jede Gruppe von einem anderen System und einem anderen geschäftlichen Ereignis angelegt und verändert wird.
Eine Person kann mehrere Rollen gleichzeitig innehaben. Das Identitätssystem sollte einen einzigen Datensatz für diese Person führen und Zugriff je Rolle hinzufügen oder entfernen, statt das Konto neu aufzubauen.
Das führende System für akademischen Status, Beschäftigungsstatus und Lehraufträge ist selten dasselbe System. Schriftlich festgelegte Vorrangregeln lösen Konflikte zwischen ihnen auf.
Automatisiertes Provisioning funktioniert nur, wenn die zugrunde liegenden Daten zuverlässig sind. Überprüfung und Ausnahmebehandlung bleiben auch nach der Automatisierung wichtig.
Warum akademisches Identity-Lifecycle-Management drei Tracks braucht
Bildungseinrichtungen brauchen separate Zugriffs-Lifecycles, weil Studierendenstatus, Lehraufträge und Beschäftigungsverhältnisse des Personals von unterschiedlichen Systemen und unterschiedlichen Ereignissen angelegt und verändert werden. Ein einzelner, generischer Onboarding- und Offboarding-Prozess hat Schwierigkeiten, den richtigen Zugriff rechtzeitig zu gewähren und ihn zu entfernen, sobald der Grund für diesen Zugriff entfällt.
Der Zugriff eines Studierenden ist an Einschreibung, Kursanmeldung und akademischen Status gebunden
Der Zugriff eines Mitarbeiters ist an eine Stelle und einen Beschäftigungsdatensatz gebunden
Der Zugriff einer Lehrkraft hängt oft sowohl von einer Anstellung als auch von einem bestimmten Lehrauftrag ab, die nach einem anderen Zeitplan beginnen und enden können als der Beschäftigungsdatensatz
Dieses Muster wird meist als Joiner-Mover-Leaver (JML) bezeichnet: ein Framework, das erfasst, wann jemand einer Organisation beitritt, innerhalb ihrer die Rolle wechselt und sie schließlich verlässt. Im Bildungsbereich ist „Leaver“ das falsche Wort für einen Studierenden, der seinen Abschluss macht, aber eingeschränkten Alumni-Zugriff behält, oder für eine Lehrkraft, deren Lehrauftrag endet, während die Anstellung weiterläuft. Ein generischer JML-Ablauf verdeckt diese Fälle, sofern er nicht rollenspezifische Ereignisse, Übergangsfristen und überlappende Zugehörigkeiten abbildet. Das Drei-Track-Modell tut das.
Die 2025er-Gesprächsrunde von InCommon zu Identitätspraktiken im Hochschulbereich ergab, dass 27 % der Befragten die größten Schwierigkeiten mit Richtlinien und Standards hatten, 23 % mit rollenbasierter Zugriffskontrolle (RBAC) und 14 % damit, wie unterschiedliche Gruppen ihren Lifecycle durchlaufen. Die Umfrage belegt keine einzelne Grundursache. Sie zeigt aber, dass Richtlinien, Rollendesign und die Verantwortung für den Lifecycle ebenso viel Aufmerksamkeit verdienen wie die Auswahl der Technologie.
Die Academic Access Lifecycle Matrix
Die Academic Access Lifecycle Matrix (AALM) übersetzt das Lifecycle-Design in acht Entscheidungen, die für jede der drei Gruppen wiederholt werden: Trigger, maßgebliche Quelle, Identitätsattribute, Basiszugriff, bedingter Zugriff, Freigabeverantwortlicher, Überprüfungszeitpunkt und Maßnahme bei Zugriffsende. Werden diese acht Felder für Studierende, Lehrkräfte und Dozierende sowie Mitarbeiter ausgefüllt, erhält eine Institution ein funktionierendes Richtliniendokument statt eines abstrakten Frameworks.
Das föderale Identity-Lifecycle-Management-Playbook beschreibt Erstellung, Änderung und Löschung als Kernphasen für die Bereitstellung, Anpassung und den Entzug von Zugriff nach dem Prinzip der geringsten Privilegien – das heißt, Benutzer erhalten nur den Zugriff, den ihre aktuelle Rolle erfordert. Die AALM überträgt diese Logik auf den Bildungsbereich, wo „Änderung“ weit mehr Varianten umfasst als ein typischer Rollenwechsel im Unternehmen.
Semesterbeginn, Abgabetermin für Noten, Semesterende
Jährliche Rezertifizierung, Rollenwechsel
Maßnahme bei Zugriffsende
Exmatrikulation, Abschluss, Alumni-Richtlinie
Semesterende, richtlinienkonforme Übergangsfrist
Kündigung, Rollenwechsel
Die nächsten drei Abschnitte zeigen, wie sich dieselben Felder je nach Gruppe ändern. Basiszugriff, Attribute und maßgebliche Quellen variieren je nach Institution. Betrachten Sie diese Matrix als Ausgangspunkt für die Planung und tragen Sie Ihre eigenen Systeme und Freigabeverantwortlichen ein, bevor Sie eine Zeile als endgültig behandeln.
Zugriffsmanagement für Studierende von der Einschreibung bis zum Alumni-Status
Das Zugriffsmanagement für Studierende verknüpft Ereignisse des akademischen Status mit einem Berechtigungsmodell, das Zugriff hinzufügt, anpasst oder stilllegt, ohne bei jeder Statusänderung eine neue Identität anzulegen. Einschreibung, Beurlaubung, Exmatrikulation, Abschluss und der Übergang in den Alumni-Status verändern jeweils, worauf ein Studierender zugreifen kann, während der Personendatensatz derselbe bleibt.
Die Ereigniskette der Studierenden
Die Kette verläuft typischerweise vom Zugriff für Bewerber vor der Ankunft über Einschreibung oder Immatrikulation, Studiengang- und Kurswechsel, eine Beurlaubung, Exmatrikulation, Abschluss bis zum Übergang in den Alumni-Status. Prüfen Sie bei jedem Ereignis, ob es eine neue Identität anlegen, bestehenden Zugriff ändern oder eine Statusüberprüfung auslösen sollte. In den meisten Fällen existiert der Personendatensatz bereits, und das Ereignis ändert den Zugriff, statt eine zweite Identität anzulegen.
Zugriff mit akademischen Daten verknüpfen
Das SIS oder das Prüfungsamt dient üblicherweise als maßgebliche Quelle für Attribute des akademischen Status und speist Daten zur Kurseinschreibung nachgelagert in das LMS ein. Dokumentieren Sie, wie diese Daten das LMS erreichen (direkte Integration, Middleware oder eine Identity-Governance-Schicht), statt von einem einzigen festen Weg auszugehen. Passt ein Studierendendatensatz nicht eindeutig zusammen, etwa nach einer Namensänderung, einer doppelten Bewerbung oder bei einem Wechselstudierenden mit zwei bestehenden Konten, leiten Sie ihn in eine Ausnahmewarteschlange weiter. Lassen Sie das System nicht stillschweigend ein zweites Konto anlegen.
Bildungsunterlagen und Daten zur Studienfinanzierung schützen
34 CFR § 99.31(c) verpflichtet Institutionen, angemessene Methoden einzusetzen, um die Personen zu identifizieren und zu authentifizieren, denen sie personenbezogene Daten aus Bildungsunterlagen offenlegen. Die Dokumentation von Anfragen und Offenlegungen fällt unter § 99.32. Diese Anforderung deckt die Offenlegung von Informationen aus Bildungsunterlagen ab. Sie ersetzt nicht die übliche Zugriffsprotokollierung auf Anwendungsebene.
Sind Daten zur Studienfinanzierung betroffen, behandelt die Leitlinie GEN-25-08 des Bildungsministeriums den zulässigen Zugriff auf Federal Tax Information und FAFSA-Daten für berechtigte Institutionen. Keine der beiden Quellen definiert eine technische Architektur. Die Rechtsabteilung der Institution sollte prüfen, wie jede davon auf Ihre Systeme zutrifft.
Der Zugriff von Lehrkräften und Dozierenden braucht einen eigenen Lifecycle
Der Zugriff von Lehrkräften und Dozierenden braucht einen eigenen Lifecycle, weil der Lehrzugriff von einer Anstellung, einem bestimmten Kurszuschnitt und Pflichten zur Notenerfassung abhängt und nicht von einem üblichen Start- und Enddatum als Mitarbeiter. Lehrbeauftragte und Gastdozierende machen das deutlich: Ihr LMS-Zugriff muss möglicherweise vor Vertragsbeginn starten und über das Semesterende hinaus bestehen bleiben.
EDUCAUSE beschreibt ein gängiges Szenario: Eine kurzfristig eingesetzte Lehrkraft benötigt LMS-Zugriff vor dem offiziellen Starttermin, um einen Kurs aufzubauen, und braucht nach Semesterende möglicherweise eingeschränkten Zugriff, um die Notenerfassung abzuschließen. Ein generischer Mitarbeiter-Lifecycle, der auf einem einzigen Einstellungs- und einem einzigen Kündigungsdatum aufbaut, bildet dieses Muster schlecht ab. Institutionen brauchen eine dokumentierte Richtlinie mit einer benannten Übergangsfrist.
Lehrereignis
Zugriffsmaßnahme
Verantwortlicher
Überprüfungszeitpunkt
Anstellung genehmigt
Basiszugriff bereitstellen
Akademische Verwaltung
Bei Anstellungsbeginn
Lehrauftrag bestätigt
Kursbezogenen LMS-Zugriff hinzufügen
Abteilung, Anwendungsverantwortlicher
Bei Semesterbeginn
Notenerfassung abgeschlossen
Zur Überprüfung markieren
Prüfungsamt
Beim Abgabetermin für Noten
Vertrag oder Semester endet
Kurszugriff ablaufen lassen, Basiszugriff bei Wiederanstellung behalten
Abteilung
Bei Semesterende
Verlängerung genehmigt
Übergangsfrist mit dokumentiertem Enddatum verlängern
Abteilungsleitung
Bei Verlängerungsantrag
Die individuelle LMS- oder E-Mail-Berechtigung einer Lehrkraft gehört in das IAM/IGA-Zugriffsmodell. Eine Schicht für Credential-Management ist eher für gemeinsam genutzte operative Konten relevant, die IT oder ein benannter Verantwortlicher direkt kontrolliert, etwa Laborsysteme oder Lieferantenzugänge.
Lifecycle für Mitarbeiter: Beschäftigungsereignisse, Rollenwechsel und Austritte
Der Zugriff von Mitarbeitern sollte validierten Beschäftigungs- und Stellenwechsel-Ereignissen folgen, wobei der zuständige Vorgesetzte oder Fachverantwortliche jeden Zugriff über das Standardrollenpaket hinaus bestätigt. Typische Trigger sind Einstellung, Versetzung, Beförderung, Beurlaubung und Kündigung, und jedes davon sollte bestehende Berechtigungen neu bewerten, statt nur neue hinzuzufügen.
Ein häufiges Fehlermuster ist Privilege Creep: Jemand erhält nach einer Beförderung neuen Zugriff, und niemand entfernt den Zugriff, der an die alte Rolle gebunden war. Regelmäßige Zugriffsrezertifizierung – eine geplante Überprüfung, bei der ein Vorgesetzter bestätigt, dass der Zugriff jeder Person noch benötigt wird – erkennt das, bevor es zu einem Prüfungsbefund wird.
NIST SP 1800-35 beschreibt sicheren autorisierten Zugriff als fortlaufende Entscheidung statt als einmalige Gewährung, aufbauend auf erweiterter Identity-Governance über verteilte On-Premises- und Cloud-Ressourcen. Das auf den Zugriff von Mitarbeitern anzuwenden ist eine Designentscheidung und keine NIST-Anforderung: Behandeln Sie jeden Rollenwechsel als Anlass, bestehende Berechtigungen neu zu bewerten.
Eine Person, mehrere Rollen: Übergänge und Überlappungen steuern
Ein Mehrfachrollen-Identitätsmodell führt einen einzigen Personendatensatz und gewährt nur den Zugriff, der durch jede aktive Rolle gerechtfertigt ist. Das verhindert doppelte Konten und ermöglicht es, den an eine Rolle gebundenen Zugriff zu entfernen, während der Zugriff aus einer anderen Rolle unberührt bleibt.
Sechs Szenarien decken die meisten Überlappungen ab, auf die Institutionen stoßen:
Ein Studierender wird Mitarbeiter, etwa wenn Werkstudenten in Teilzeitrollen wechseln
Ein Mitarbeiter oder eine Lehrkraft schreibt sich als Studierender ein
Eine Lehrkraft ist gleichzeitig Dozent, Forscher und Verwaltungsverantwortlicher der Abteilung
Ein Werkstudent wechselt die Abteilung oder hat gleichzeitig zwei Stellen
Ein Alumnus oder Ruheständler erhält eingeschränkten, zeitlich begrenzten Zugriff auf einen bestimmten Dienst
Ein Auftragnehmer oder externer Mitarbeiter benötigt Zugriff, der automatisch zu einem festgelegten Datum abläuft
Die wichtigste Regel: Wenn eine Zugehörigkeit endet, entfernen Sie nur den an diese Zugehörigkeit gebundenen Zugriff. Zwei Fehler sind möglich. Das System kann Zugriff entziehen, den eine andere aktive Rolle weiterhin rechtfertigt, oder es kann Zugriff bestehen lassen, nachdem die Zugehörigkeit geendet hat. Zuverlässiger Identitätsabgleich (die Bestätigung, dass zwei Datensätze zur selben Person gehören) und eine dokumentierte Prüfwarteschlange für Fälle, die die automatisierten Regeln nicht lösen können, halten beide Fehler beherrschbar.
Gemeinsam genutzte Zugangsdaten für Labore, IT und Lieferanten liegen oft außerhalb der Lifecycle-Workflows. Testen Sie Passwork kostenlos, um sie unter rollenbasierten Zugriff und Audit-Protokollierung zu bringen.
Die Daten- und Integrationsschicht vor der Automatisierung aufbauen
Automatisierung funktioniert, sobald eine Institution ihre maßgeblichen Quellen benannt, einen zuverlässigen Identitätsabgleich aufgebaut und eine Datenvorrangregel für Konflikte zwischen Systemen festgelegt hat. Ohne diese drei Voraussetzungen wirken Provisioning-Regeln auf veraltete oder nicht übereinstimmende Datensätze und gewähren Zugriff entweder zu früh oder lassen ihn zu lange bestehen.
Weisen Sie die maßgebliche Quelle je Attribut zu, nicht je System. Ein gängiges Modell ordnet Attribute des akademischen Status dem SIS oder dem Prüfungsamt zu, Beschäftigungsattribute HR/HCM und der Gehaltsabrechnung und Attribute zu Lehraufträgen einem Planungssystem oder der akademischen Verwaltung. Die Zuständigkeit variiert je Campus. Dokumentieren Sie daher die Zuständigkeit und den Vorrang auf Attributebene für Ihre eigene Umgebung.
Manche Zugangsdaten haben in keinem dieser Systeme einen natürlichen Eigentümer. Gemeinsam genutzte Cloud-Admin-Zugangsdaten, die von drei Infrastruktur-Ingenieuren verwendet werden, gehören weder zu HR noch zum SIS. Eine Identity-Governance-and-Administration-Schicht (IGA) kann festhalten, dass das Infrastrukturteam dafür verantwortlich ist. Das Secret selbst braucht weiterhin ein System, das gemeinsam genutzte Zugangsdaten speichert, rotiert und protokolliert. Das ist eine separate Kontrollmaßnahme.
Ein grundlegender Ereignisablauf sieht so aus:
Ein Ereignis im führenden System tritt ein
Der Identitätsabgleich bestätigt, auf welche Person es sich bezieht
Eine Richtlinienregel bewertet, was sich ändern soll
Eine Freigabe erfolgt, wo erforderlich
Provisioning oder Entzug wird ausgeführt
Ein Audit-Ereignis protokolliert, was passiert ist
Jeder Schritt, der fehlschlägt, etwa eine nicht zugeordnete Identität oder ein veraltetes Ereignis, sollte in eine sichtbare Ausnahmewarteschlange mit einem benannten Verantwortlichen gehen. Er sollte nicht stillschweigend verschwinden.
NIST SP 800-63-4 legt Anforderungen für Identitätsprüfung, Registrierung, Authenticator-Management, Authentifizierung und Federation fest. Es ist eine nützliche Referenz für die Identitätsschicht unter dieser Automatisierung, schreibt jedoch keine Architektur für den Bildungsbereich vor.
Zugriffskontrollen und Nachweise anwenden, die zum Risiko passen
Zugriffskontrollen sollten der Sensibilität der Ressource und der aktuellen Rolle der Person entsprechen, während Audit-Nachweise zeigen sollten, wer den Zugriff genehmigt hat, wann er sich geändert hat und ob er weiterhin gerechtfertigt ist. Grundlegende Kontrollen umfassen das Prinzip der geringsten Privilegien, rollenbasierte Zugriffskontrolle (RBAC), MFA, SSO, geplante Überprüfungen, zeitlich begrenzten Zugriff und Funktionstrennung.
Funktionstrennung verhindert, dass eine Person den eigenen Zugriff sowohl beantragt als auch genehmigt. Richtlinienbasierte Regeln können Kontext hinzufügen, den eine Rolle allein nicht trägt, etwa Anstellungsdaten oder Kurszuweisungen. Verwaiste Konten – also Konten, die noch aktiv sind, nachdem die Zugehörigkeit, die sie rechtfertigte, geendet hat – sollten automatisch markiert werden, statt erst bei einem Audit entdeckt zu werden.
Gemeinsam genutzte operative Zugangsdaten benötigen eine eigene Schicht. Ein IAM/IGA-Programm kann Eigentümerschaft und Überprüfung eines gemeinsam genutzten Servicekontos, eines Laborsystems oder eines Lieferantenportal-Logins steuern und festlegen, wer verantwortlich ist und wann der Zugriff rezertifiziert wird. Es speichert, rotiert oder teilt das Secret nicht sicher. Dort übernimmt eine Schicht für Credential-Management.
Testen Sie Passwork in Ihrer Infrastruktur mit einer kostenlosen Testversion. 50 % Rabatt für Bildungseinrichtungen und Non-Profit-Organisationen auf Käufe bis Ende des Jahres.
Umsetzungscheckliste für akademisches Identity-Lifecycle-Management: die ersten 90 Tage
In den ersten 90 Tagen sollten Sie die Richtlinie festlegen, die drei Gruppen modellieren, die Quelldaten validieren, eine kleine Anzahl von Anwendungen pilotieren und ungelöste Ausnahmen messen, bevor die Automatisierung ausgeweitet wird. Die folgende Checkliste folgt dieser Reihenfolge und endet mit der rechtlichen Prüfung und der Datenschutzprüfung. Jeder Schritt liefert ein Dokument oder eine Kennzahl, die das Governance-Gremium überprüfen kann.
Die 90-Tage-Checkliste für akademisches Identity-Lifecycle-Management (10 Punkte)
Bilden Sie ein Governance-Gremium: Prüfungsamt, HR, akademische Verwaltung, IAM/IT, Sicherheit, Anwendungsverantwortliche und Service-Desk
Definieren Sie den Personendatensatz und die Regeln für den Identitätsabgleich über Systeme hinweg
Bilden Sie die Lifecycle-Zustände und Trigger für Studierende, Lehrkräfte/Dozierende und Mitarbeiter ab
Weisen Sie jedem Schlüsselattribut eine maßgebliche Quelle und eine Vorrangregel zu
Bauen Sie die AALM für Ihre ersten fünf Anwendungen oder Dienste auf
Erstellen Sie Regeln für Freigabe, Ausnahmen, Übergangsfristen und Notfall-Offboarding
Erproben Sie automatisiertes Provisioning und Deprovisioning mit aktivem Monitoring
Legen Sie Basiskennzahlen fest: Zeit bis zur Bereitstellung, Zeit bis zur Deaktivierung, Rückstand bei Ausnahmen, inaktive Konten, überfälliger temporärer Zugriff und Abschlussquote der Überprüfungen
Führen Sie vor dem Go-Live Planübungen für Mehrfachrollen- und Semesterende-Szenarien durch
Lassen Sie die Richtlinie von Rechts- und Datenschutzverantwortlichen prüfen, bevor Sie sie flächendeckend durchsetzen
InCommon empfiehlt dieselbe Abfolge: lokale Lifecycle-Anforderungen definieren, sie visuell abbilden, Governance etablieren, die Qualität der Quelldaten verbessern, Ausnahmen einplanen und Entscheidungen dokumentieren.
Fazit
Behandeln Sie den akademischen Identity-Lifecycle zuerst als Richtlinienproblem und erst danach als Tooling-Problem. Drei Ereignisströme, drei Verantwortliche, ein Personendatensatz: Das ermöglicht es, den Laborzugriff eines Studierenden nach dessen Abschluss zu entfernen, ohne die Stelle zu berühren, die er im Prüfungsamt angetreten hat.
Nächster Schritt: Bringen Sie das Governance-Gremium zusammen und einigen Sie sich auf die ersten fünf abzubildenden Anwendungen, eingestuft nach der Sensibilität der Daten, die sie enthalten.
Sobald Ihre Lifecycle-Richtlinie steht, starten Sie eine kostenlose Testversion von Passwork, um die gemeinsam genutzten Zugangsdaten zu verwalten, die Ihre IT- und Betriebsteams noch außerhalb Ihrer IAM-Plattform handhaben.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Zugriffsmanagement für Studierende und für Mitarbeiter?
Der Zugriff von Studierenden ist an den akademischen Status und die Kursteilnahme gebunden, während der Zugriff von Mitarbeitern an Beschäftigung und Aufgaben gebunden ist. Der Zugriff von Lehrkräften und Dozierenden kombiniert oft eine Anstellung mit einem bestimmten Lehrauftrag und braucht deshalb einen eigenen Lifecycle, statt mit dem allgemeinen Mitarbeiterzugriff zusammengefasst zu werden. Jede Gruppe hat ein anderes Quellsystem und andere Freigabeverantwortliche.
Welches System sollte die maßgebliche Quelle für akademischen Zugriff sein?
Kein einzelnes System passt zu jeder Institution. Ein gängiger Ansatz verwendet das SIS oder das Prüfungsamt für den akademischen Status, HR/HCM für den Beschäftigungsstatus und ein Planungssystem oder die akademische Verwaltung für Lehraufträge. Die IAM/IGA-Schicht wendet dann dokumentierte Vorrangregeln an, wenn diese Quellen im Konflikt stehen, sodass jedes Attribut einen benannten Verantwortlichen hat.
Was passiert, wenn ein Studierender Mitarbeiter wird?
Behalten Sie einen einzigen Personendatensatz und fügen Sie die Beschäftigungszugehörigkeit hinzu, sobald sie validiert ist. Stellen Sie stellenbezogenen Zugriff über den normalen Workflow bereit und behalten Sie jeden Studierendenzugriff, der weiterhin durch eine aktive Einschreibung gerechtfertigt ist. Endet die Stelle, entfernen Sie nur den stellenbezogenen Zugriff. Das vermeidet doppelte Konten und hält den Audit-Trail an einer Identität.
Wann sollten Lehrkräfte oder Dozierende nach Semesterende den Zugriff verlieren?
Stützen Sie die Entscheidung auf dokumentierte Regeln zu Lehrauftrag, Notenerfassung und Übergangsfrist. Benennen Sie den Verantwortlichen, der den Zugriff verlängern kann, listen Sie die betroffenen Anwendungen auf und legen Sie ein klares Ablaufereignis fest. Dokumentieren Sie jede Verlängerung mit einem Enddatum, sodass der Audit-Trail zeigt, wer sie genehmigt hat und warum der Zugriff über das Semester hinaus bestand.
Wie können Institutionen verwaiste Konten reduzieren?
Leiten Sie Kontoänderungen von maßgeblichen Lifecycle-Ereignissen ab, automatisieren Sie Statusänderungen, befristen Sie jede Ausnahme und überprüfen Sie Konten, die inaktiv sind oder keiner gültigen Identität zugeordnet werden können, nach einem festen Zeitplan. EDUCAUSE empfiehlt eine dokumentierte Richtlinie für den Kontolebenszyklus und einen Identity-Governance-Prozess statt dauerhafter manueller Ausnahmen.
Akademisches Identity-Lifecycle-Management für Studium und Beruf
Ein Studierender beim Abschluss, ein Lehrbeauftragter mit auslaufendem Vertrag und ein kündigender Mitarbeiter sind drei verschiedene Ereignisse – doch die meisten Identitätstools behandeln sie als einen einzigen „Leaver“-Fall.
Alex Muntyan
Passwork Team
Alex Muntyan
