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.

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.

Conclusion

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

Kindernothilfe: Simplifying global employee collaboration with Passwork

Kindernothilfe, one of Europe’s largest child aid organizations, needed a scalable password manager for a globally distributed team. They chose Passwork for self-hosting, SSO via SAML2, and an intuitive interface that simplified access management across borders.

PassworkAlex Muntyan

Password manager security features: How to evaluate them

Your vendor’s security page makes a lot of promises. Here’s the six-pillar framework for checking which ones are actually true, before you sign or renew.

PassworkPasswork Team

The city of Melle: How Passwork сentralized password management

The city of Melle, a municipality in Lower Saxony with more than 48,000 residents, is recognized for its modern approach to city administration and citizen services. The local government manages a wide range of responsibilities: urban development, education, social care, environmental protection, cultural initiatives, municipal infrastructure, and economic support for the region. In recent years, Melle has invested heavily in digital transformation, introducing online citizen services, moderniz

PassworkAlex Muntyan

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.

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.

«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.

Conclusão

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 Pegnitz: Resolver conflitos de sincronização de ficheiros com o Passwork

Pegnitz, uma cidade bávara perto de Nuremberga, geria a TI municipal com um cofre baseado em ficheiros que não suportava acesso concorrente, obrigando os administradores a coordenar verbalmente cada alteração. A equipa migrou para a plataforma autoalojada do Passwork, com acesso a credenciais em tempo real e multiutilizador.

PassworkPasswork Team

Credenciais de agentes de IA: 7 regras para um controlo de acesso seguro

Os agentes de IA já superam em número os colaboradores na maioria das empresas e detêm credenciais ativas. Atuam com base em texto persuasivo, um hábito que transforma controlos de credenciais fracos num risco para toda a frota. Este artigo mostra como delimitar, isolar e revogar credenciais de agentes para conter um único comprometimento.

PassworkPasswork Team

Kindernothilfe: Simplificar a colaboração global entre colaboradores com o Passwork

A Kindernothilfe, uma das maiores organizações europeias de apoio à infância, precisava de um gestor de palavras-passe escalável para uma equipa distribuída globalmente. Escolheu o Passwork pela opção de autoalojamento, pelo SSO via SAML2 e por uma interface intuitiva que simplificou a gestão de acessos entre fronteiras.

PassworkAlex Muntyan

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.

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.

"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.

Fazit

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 Pegnitz: Dateisynchronisierungskonflikte mit Passwork lösen

Pegnitz, eine bayerische Stadt bei Nürnberg, betrieb die kommunale IT mit einem dateibasierten Tresor, der keinen gleichzeitigen Zugriff verarbeiten konnte, sodass Administratoren jede Änderung mündlich abstimmen mussten. Das Team wechselte zur selbstgehosteten Plattform von Passwork für einen Echtzeit-Zugriff mehrerer Nutzer auf Zugangsdaten.

PassworkPasswork Team

Zugangsdaten für KI-Agenten: 7 Regeln für sichere Zugriffskontrolle

KI-Agenten übertreffen in den meisten Unternehmen inzwischen die Zahl der Mitarbeiter und verfügen über aktive Zugangsdaten. Sie handeln auf Basis überzeugend wirkender Texte – eine Eigenschaft, die aus schwachen Zugangsdatenkontrollen ein unternehmensweites Risiko macht. Dieser Artikel zeigt, wie man Zugangsdaten von Agenten eingrenzt, isoliert und widerruft, um eine einzelne Kompromittierung einzudämmen.

PassworkPasswork Team

Kindernothilfe: Globale Mitarbeiterzusammenarbeit mit Passwork vereinfachen

Kindernothilfe, eine der größten Kinderhilfsorganisationen Europas, benötigte einen skalierbaren Passwortmanager für ein global verteiltes Team. Die Organisation entschied sich für Passwork wegen des Self-Hostings, SSO über SAML2 und einer intuitiven Benutzeroberfläche, die die länderübergreifende Zugriffsverwaltung vereinfachte.

PassworkAlex Muntyan

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.

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.

«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.

Conclusión

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 Pegnitz: Resolución de conflictos de sincronización de archivos con Passwork

Pegnitz, una localidad bávara cercana a Núremberg, gestionaba su TI municipal con una bóveda basada en archivos incapaz de gestionar el acceso simultáneo, lo que obligaba a los administradores a coordinar cada cambio de forma verbal. El equipo migró a la plataforma autoalojada de Passwork para un acceso a credenciales multiusuario en tiempo real.

PassworkPasswork Team

Credenciales de agentes de IA: 7 reglas para un control de acceso seguro

Los agentes de IA ya superan en número a los empleados en la mayoría de las empresas y manejan credenciales activas. Actúan a partir de texto persuasivo, un hábito que convierte unos controles de credenciales débiles en un riesgo para toda la flota. Este artículo muestra cómo delimitar, aislar y revocar las credenciales de los agentes para contener un único compromiso de seguridad.

PassworkPasswork Team

Kindernothilfe: Simplificación de la colaboración global de los empleados con Passwork

Kindernothilfe, una de las mayores organizaciones de ayuda a la infancia de Europa, necesitaba un gestor de contraseñas escalable para un equipo distribuido globalmente. Eligieron Passwork por su autoalojamiento, el inicio de sesión único (SSO) mediante SAML2 y una interfaz intuitiva que simplificó la gestión de accesos entre fronteras.

PassworkAlex Muntyan

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.

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.

"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.

Conclusion

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 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.

PassworkPasswork Team

AI agent credentials: 7 rules for secure access control

AI agents now outnumber employees inside most companies and hold live credentials. They act on convincing text, a habit that turns weak credential controls into a fleet-wide risk. This article shows how to scope, isolate, and revoke agent credentials to contain a single compromise.

PassworkPasswork Team

Kindernothilfe: Simplifying global employee collaboration with Passwork

Kindernothilfe, one of Europe’s largest child aid organizations, needed a scalable password manager for a globally distributed team. They chose Passwork for self-hosting, SSO via SAML2, and an intuitive interface that simplified access management across borders.

PassworkAlex Muntyan

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.

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.

Experimentar o Passwork gratuitamente para testar de que forma a estrutura dos cofres limita o acesso após o comprometimento de uma conta.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Testar o Passwork na infraestrutura da organização e comparar o que uma conta comprometida poderia decifrar em cada sistema candidato.

Perguntas frequentes

Políticas de cofres do Passwork: um guia para CIOs sobre segurança empresarial

Os Tipos de Cofre do Passwork associam os direitos de administrador à própria política do cofre, e não a quem o criou, fechando uma lacuna que a maioria das empresas nem sequer sabe que existe. Este guia oferece a CIOs e CISOs um modelo de trabalho para a governação de cofres, alinhado com os requisitos da NIS2 e da ISO 27001.

PassworkPasswork Team

Passwork vs KeePass: Em que difere a arquitetura de cifragem

A criptografia do KeePass é genuinamente forte. A sua gestão de chaves para equipas não é. Aqui fica onde um ficheiro KDBX partilhado falha (ao guardar, na saída de colaboradores, na auditoria) e o que uma chave por cofre muda.

PassworkPasswork Team

Passwork vs Bitwarden: Em que difere a arquitetura de cifragem dos cofres

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

PassworkPasswork Team

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.

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.

Kostenlose Passwork-Testversion starten, um zu testen, wie Ihre Tresorstruktur den Zugriff nach einer Konto-Kompromittierung einschränkt.

Tresortypen: Governance oberhalb einzelner Tresore

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Passwork in Ihrer Infrastruktur testen und vergleichen, was ein kompromittiertes Konto in jedem der betrachteten Systeme entschlüsseln könnte.

Häufig gestellte Fragen

Passworks Tresor-Richtlinien: Ein Leitfaden für CIOs zur Unternehmenssicherheit

Passworks Tresortypen binden Administratorrechte an die Tresor-Richtlinie selbst statt an die Person, die den Tresor angelegt hat, und schließen damit eine Lücke, deren Existenz die meisten Unternehmen gar nicht kennen. Dieser Leitfaden bietet CIOs und CISOs ein praxistaugliches Modell für Tresor-Governance, abgestimmt auf die Anforderungen von NIS2 und ISO 27001.

PassworkPasswork Team

Passwork vs. KeePass: Wie sich die Verschlüsselungsarchitektur unterscheidet

Die Kryptografie von KeePass ist wirklich stark. Sein Schlüsselmanagement für Teams dagegen nicht. Hier zeigt sich, wo eine gemeinsam genutzte KDBX-Datei versagt – beim Speichern, beim Offboarding, beim Audit – und was ein Schlüssel pro Tresor daran ändert.

PassworkPasswork Team

Passwork vs. Bitwarden: Wie sich die Verschlüsselungsarchitektur der Tresore unterscheidet

Passwork verschlüsselt jeden Tresor mit einem eigenen Schlüssel. Bitwarden verschlüsselt eine gesamte Organisation mit einem einzigen gemeinsamen Schlüssel. Dieser Vergleich zeigt, was das für Blast Radius, Team-Isolation, Kontowiederherstellung und Audit-Antworten bedeutet, wenn Zugangsdaten durchsickern.

PassworkPasswork Team

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Probar Passwork en su infraestructura y comparar lo que una cuenta comprometida podría descifrar en cada sistema candidato.

Preguntas frecuentes

Las políticas de bóveda de Passwork: una guía para CIO sobre seguridad empresarial

Los tipos de bóveda de Passwork vinculan los derechos de administración a la propia política de la bóveda, no a quien la creó, cerrando así una brecha que la mayoría de las empresas ni siquiera sabe que existe. Esta guía ofrece a los CIO y CISO un modelo práctico de gobernanza de bóvedas, vinculado a los requisitos de NIS2 e ISO 27001.

PassworkPasswork Team

Passwork frente a KeePass: en qué difiere la arquitectura de cifrado

La criptografía de KeePass es realmente sólida. Su gestión de claves para equipos no lo es. Aquí es donde falla un archivo KDBX compartido —al guardar, al dar de baja a un empleado, al auditar— y lo que cambia una clave por bóveda.

PassworkPasswork Team

Passwork frente a Bitwarden: en qué difiere la arquitectura de cifrado de la bóveda

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

PassworkPasswork Team

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.

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.

Start a free Passwork trial to test how your vault structure limits access after an account compromise.

Vault types: governance above individual vaults

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Test Passwork in your infrastructure and compare what one compromised account could decrypt in each candidate system.

Frequently asked questions

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

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

PassworkPasswork Team

Passwork vs KeePass: How encryption architecture differs

KeePass’s cryptography is genuinely strong. Its key management for teams is not. Here’s where a shared KDBX file breaks down — at the save, at the offboarding, at the audit — and what a per-vault key changes.

PassworkPasswork Team

Passwork vs Bitwarden: How vault encryption architecture differs

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

PassworkPasswork Team

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.

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.

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.

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 sobre o 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.

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.

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.

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.

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.

Perguntas frequentes

Soberania dos dados e gestão de palavras-passe: Manter as credenciais onde pertencem

A soberania dos dados para credenciais exige três controlos (localização, cifragem, acesso), e não apenas a conformidade com o RGPD. Compara os modelos on-premise, air-gapped e cloud na UE e mostra onde uma arquitetura zero-knowledge como a do Passwork fecha, na realidade, a lacuna de soberania.

PassworkPasswork Team

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

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

PassworkPasswork Team

Modelos de implementação de gestores de palavras-passe: Comparação entre cloud, alojamento próprio e híbrido

Escolher onde executar o gestor de palavras-passe importa tanto como escolher qual utilizar. Este guia analisa a implementação em cloud, em alojamento próprio e híbrida, com uma matriz de conformidade para RGPD, HIPAA e NIS2 e uma visão clara das contrapartidas de cada modelo.

PassworkAlex Muntyan

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.

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.

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.

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 zu dem, 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.

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.

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.

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.

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.

Häufig gestellte Fragen

Datensouveränität und Passwortmanagement: Zugangsdaten dort behalten, wo sie hingehören

Datensouveränität für Zugangsdaten erfordert drei Kontrollen (Standort, Verschlüsselung, Zugriff) – nicht nur DSGVO-Konformität. Vergleicht On-Premise-, air-gapped- und EU-Cloud-Modelle und zeigt, wo eine Zero-Knowledge-Architektur wie die von Passwork die Souveränitätslücke tatsächlich schließt.

PassworkPasswork Team

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

Zero-Knowledge-Verschlüsselung bedeutet, dass der Server nie Ihre Entschlüsselungs-Schlüssel besitzt, nur Chiffretext. Erfahren Sie, wie die Schlüsselkette funktioniert, wogegen sie schützt, wogegen nicht, und wie Sie die Behauptung eines Anbieters überprüfen.

PassworkPasswork Team

Bereitstellungsmodelle für Passwortmanager: Cloud, Self-hosted und Hybrid im Vergleich

Wo Sie Ihren Passwortmanager betreiben, ist genauso wichtig wie welchen Sie wählen. Dieser Leitfaden schlüsselt Cloud-, Self-hosted- und Hybrid-Bereitstellung auf – mit einer Compliance-Matrix für DSGVO, HIPAA und NIS2 und einem klaren Blick auf die Kompromisse jedes Modells.

PassworkAlex Muntyan

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.

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.

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.

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 sobre qué 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.

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.

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.

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.

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.

Preguntas frecuentes

Soberanía de los datos y gestión de contraseñas: Mantener las credenciales donde deben estar

La soberanía de los datos de las credenciales exige tres controles (ubicación, cifrado, acceso), no solo el cumplimiento del RGPD. Compara los modelos on-premise, air-gapped y de nube en la UE, mostrando dónde una arquitectura de conocimiento cero como la de Passwork cierra realmente la brecha de soberanía.

PassworkPasswork Team

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

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

PassworkPasswork Team

Modelos de despliegue de gestores de contraseñas: Nube, autoalojado e híbrido comparados

Elegir dónde ejecutar su gestor de contraseñas importa tanto como elegir cuál usar. Esta guía analiza el despliegue en la nube, autoalojado e híbrido, con una matriz de cumplimiento para RGPD, HIPAA y NIS2, y una mirada clara a las ventajas y desventajas de cada modelo.

PassworkAlex Muntyan

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.

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.

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.

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 to what 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.

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.

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.

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.

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.

Frequently asked questions

Data sovereignty and password management: Keeping credentials where they belong

Data sovereignty for credentials requires three controls (location, encryption, access) not just GDPR compliance. Compares on-premise, air-gapped, and EU cloud models, showing where zero-knowledge architecture like Passwork’s actually closes the sovereignty gap.

PassworkPasswork Team

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

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

PassworkPasswork Team

Password manager deployment models: Cloud, self-hosted, and hybrid compared

Choosing where to run your password manager matters as much as choosing which one. This guide breaks down cloud, self-hosted, and hybrid deployment — with a compliance matrix for GDPR, HIPAA, and NIS2, and a clear look at the trade-offs each model carries.

PassworkAlex Muntyan

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.

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.

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.

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.

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.

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.

Perguntas frequentes

Caos de palavras-passe nas instituições de ensino: Porque é importante

O caos de palavras-passe estende-se para além do apoio informático e alcança o resto da instituição de ensino, consome tempo ao pessoal, alarga a superfície de ataque e põe em risco a conformidade. Os três maiores riscos e como os eliminar.

PassworkPasswork Team

Saída de colaboradores: Guia de revogação segura de acessos 2026

Desativar uma conta SSO não revoga o acesso. As chaves de API, as credenciais de agentes de IA e as palavras-passe partilhadas sobrevivem-lhe. Este guia abrange o procedimento completo de saída de colaboradores, dos desencadeadores à hora zero até à limpeza de NHI.

Passwork BlogAlex Muntyan

Políticas de cofres do Passwork: Guia de segurança empresarial para CIO

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

PassworkPasswork Team

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.

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.

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.

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.

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.

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.

Häufig gestellte Fragen

Passwort-Chaos in Bildungseinrichtungen: Warum es wichtig ist

Passwort-Chaos verbreitet sich über den IT-Helpdesk hinaus in der gesamten Bildungseinrichtung, kostet Mitarbeiter Zeit, vergrößert die Angriffsfläche und riskiert Compliance-Verstöße. Sehen Sie sich die drei größten Risiken an und wie Sie sie beheben.

PassworkPasswork Team

Mitarbeiter-Offboarding: Leitfaden zum sicheren Zugriffsentzug 2026

Das Deaktivieren eines SSO-Kontos entzieht keinen Zugriff. API-Schlüssel, Zugangsdaten von KI-Agenten und gemeinsam genutzte Passwörter überleben es. Dieser Leitfaden deckt das vollständige Offboarding-Playbook ab – von Zero-Hour-Triggern bis zur NHI-Bereinigung.

Passwork BlogAlex Muntyan

Passworks Tresor-Richtlinien: ein Leitfaden für CIOs zur Unternehmenssicherheit

Passworks Tresortypen (Vault Types) binden Administratorrechte an die Tresor-Richtlinie selbst, nicht an die Person, die sie erstellt hat, und schließen damit eine Lücke, von der die meisten Unternehmen nicht einmal wissen, dass sie existiert. Dieser Leitfaden gibt CIOs und CISOs ein funktionierendes Modell für die Tresor-Governance, abgebildet auf die Anforderungen von NIS2 und ISO 27001.

PassworkPasswork Team

La gestión del ciclo de vida de identidad académica rige el acceso de una persona a medida que cambia su situación como estudiante, docente, investigador o empleado. En la educación superior, funciona mejor como tres vías: para estudiantes, profesorado e instructores, y personal administrativo. Cada vía tiene sus propios desencadenantes y aprobaciones, unidas en un único registro de identidad.

Un estudiante que se gradúa, un profesor adjunto cuyo contrato ha terminado y un empleado que renuncia suelen generar el mismo ticket de baja, aunque cada uno debería perder un acceso distinto en una fecha distinta. Esta guía ofrece una matriz de ciclo de vida para las tres poblaciones, reglas para roles superpuestos y una lista de verificación de implementación de 90 días.

Por qué la gestión del ciclo de vida de identidad académica necesita tres vías

La educación necesita ciclos de acceso independientes porque la situación del estudiante, los nombramientos docentes y el empleo del personal se crean y se modifican mediante sistemas y eventos distintos. Un único proceso genérico de incorporación y baja tiene dificultades para conceder el acceso correcto a tiempo y para eliminarlo una vez que desaparece el motivo de ese acceso.

• El acceso de un estudiante está vinculado a la matrícula, la inscripción en cursos y su situación académica.
• El acceso de un miembro del personal está vinculado a un puesto y a un registro de empleo.
• El acceso de un miembro del profesorado suele depender tanto de un nombramiento como de una asignación docente específica, que puede empezar y terminar en un calendario distinto al del registro de empleo.

Este patrón suele describirse como Joiner-Mover-Leaver (JML): un marco para seguir el momento en que alguien se incorpora a una organización, cambia de rol dentro de ella y finalmente la abandona. En el ámbito educativo, «baja» es la palabra equivocada para un estudiante que se gradúa pero conserva un acceso de antiguo alumno limitado, o para un miembro del profesorado cuya asignación docente termina mientras el nombramiento continúa. Un flujo JML genérico oscurece estos casos a menos que modele eventos específicos de cada rol, periodos de gracia y afiliaciones superpuestas. El modelo de tres vías sí lo hace.

La mesa redonda de 2025 de InCommon sobre prácticas de identidad en la educación superior encontró que el 27 % de los encuestados tenía más dificultades con la política y los estándares, el 23 % con el control de acceso basado en roles (RBAC) y el 14 % con entender cómo las distintas poblaciones avanzan por sus ciclos de vida. La encuesta no establece una única causa raíz. Sí demuestra que la política, el diseño de roles y la propiedad del ciclo de vida merecen tanta atención como la selección de tecnología.

La matriz de ciclo de vida de acceso académico

La matriz de ciclo de vida de acceso académico (Academic Access Lifecycle Matrix, AALM) convierte el diseño del ciclo de vida en ocho decisiones, repetidas para cada una de las tres poblaciones: desencadenante, fuente autorizada, atributos de identidad, acceso base, acceso condicional, responsable de la aprobación, punto de revisión y acción de fin de acceso. Completar estos ocho campos para estudiantes, profesorado e instructores, y personal administrativo proporciona a la institución un documento de política operativo en lugar de un marco abstracto.

El manual federal de gestión del ciclo de vida de identidad describe la creación, la modificación y la eliminación como las etapas principales para aprovisionar, ajustar y revocar el acceso según los principios de mínimo privilegio, lo que significa que los usuarios solo obtienen el acceso que requiere su rol actual. La AALM adapta esa lógica a la educación, donde «modificación» abarca mucha más variedad que un cambio de rol corporativo habitual.

Las tres secciones siguientes muestran cómo cambian estos mismos campos según la población. El acceso base, los atributos y las fuentes de autoridad varían según la institución. Trate esta matriz como un punto de partida para la planificación y complete sus propios sistemas y responsables de aprobación antes de considerar definitiva ninguna fila.

Gestión del acceso de los estudiantes: de la matrícula a la condición de antiguo alumno

La gestión del acceso de los estudiantes conecta los eventos de situación académica con un modelo de derechos que añade, ajusta o retira el acceso sin crear una nueva identidad cada vez que cambia la situación del estudiante. La matrícula, el permiso, la baja, la graduación y el paso a la condición de antiguo alumno modifican lo que el estudiante puede alcanzar, mientras que el registro de la persona permanece igual.

La cadena de eventos del estudiante

La cadena normalmente va desde el acceso previo a la llegada para los solicitantes, pasando por la matrícula, los cambios de programa y de curso, un permiso de ausencia, la baja, la graduación, hasta el paso a la condición de antiguo alumno. Para cada evento, pregúntese si debe crear una nueva identidad, cambiar el acceso existente o desencadenar una revisión de la situación. En la mayoría de los casos, el registro de la persona ya existe, y el evento cambia el acceso en lugar de crear una segunda identidad.

Vincular el acceso a los datos académicos

El SIS o la secretaría académica suelen actuar como fuente autorizada para los atributos de situación académica y envían los datos de inscripción en cursos al LMS más adelante en el flujo. Documente cómo llegan esos datos al LMS (integración directa, middleware o una capa de gobernanza de identidad) en lugar de asumir una única ruta fija. Cuando el registro de un estudiante no coincide con claridad, como tras un cambio de nombre, una solicitud duplicada o un estudiante de traslado con dos cuentas previas, derívelo a una cola de excepciones. No permita que el sistema cree en silencio una segunda cuenta.

Proteger los registros educativos y los datos de ayuda financiera

El 34 CFR § 99.31(c) exige a las instituciones utilizar métodos razonables para identificar y autenticar a las personas a quienes revelan información de identificación personal procedente de registros educativos. El registro de las solicitudes y divulgaciones se rige por el § 99.32. Ese requisito cubre las divulgaciones de información de registros educativos. No sustituye el registro habitual de acceso a nivel de aplicación.

Cuando se trata de datos de ayuda financiera, la guía del Departamento de Educación GEN-25-08 aborda el acceso permitido a la información tributaria federal y a los datos de la FAFSA para las instituciones elegibles. Ninguna de las dos fuentes define una arquitectura técnica. La asesoría jurídica de la institución debe confirmar cómo se aplica cada una a sus sistemas.

El acceso del profesorado y los instructores necesita su propio ciclo de vida

El acceso del profesorado y los instructores necesita su propio ciclo de vida porque el acceso docente depende de un nombramiento, una asignación de curso específica y las tareas de envío de calificaciones, no de una fecha estándar de inicio y fin de empleo. Los profesores adjuntos y visitantes hacen esto visible: su acceso al LMS puede necesitar empezar antes del contrato y durar más que el periodo.

EDUCAUSE describe un escenario habitual: un instructor de corta duración necesita acceso al LMS antes de la fecha oficial de inicio para preparar un curso, y puede necesitar un acceso limitado después de que termine el periodo para finalizar las calificaciones. Un ciclo de vida de empleado genérico, construido en torno a una fecha de contratación y una fecha de cese, gestiona mal ese patrón. Las instituciones necesitan una política documentada con un periodo de gracia definido.

El derecho individual de un miembro del profesorado al LMS o al correo electrónico pertenece al modelo de acceso IAM/IGA. Una capa de gestión de credenciales es más relevante para las cuentas operativas compartidas que TI o un responsable designado controla directamente, como los sistemas de laboratorio o los inicios de sesión de proveedores.

Ciclo de vida del personal administrativo: eventos de empleo, cambios de rol y salidas

El acceso del personal administrativo debería seguir eventos validados de empleo y cambio de puesto, con el responsable directo o el propietario del negocio pertinente confirmando cualquier acceso que exceda el paquete estándar del rol. Los desencadenantes habituales son la contratación, el traslado, el ascenso, el permiso y el cese, y cada uno debería reevaluar los derechos existentes, no solo añadir otros nuevos.

Un modo de fallo habitual es la acumulación de privilegios: alguien obtiene un nuevo acceso tras un ascenso y nadie elimina el acceso vinculado al antiguo rol. La recertificación periódica del acceso, una revisión programada en la que un responsable confirma que el acceso de cada persona sigue siendo necesario, detecta esto antes de que se convierta en un hallazgo de auditoría.

NIST SP 1800-35 plantea el acceso autorizado seguro como una decisión continua en lugar de una concesión única, construida sobre una gobernanza de identidad reforzada en recursos locales y en la nube distribuidos. Aplicar esto al acceso del personal es una decisión de diseño, no un requisito del NIST: trate cada cambio de rol como un desencadenante para reevaluar los derechos existentes.

Una persona, varios roles: gobernar las transiciones y las superposiciones

Un modelo de identidad multirrol mantiene un único registro de la persona y concede únicamente el acceso justificado por cada rol activo. Esto evita las cuentas duplicadas y permite eliminar el acceso vinculado a un rol sin afectar al acceso de otro.

Seis escenarios cubren la mayoría de las superposiciones con las que se encuentran las instituciones:

• Un estudiante se convierte en miembro del personal, como cuando los estudiantes trabajadores pasan a roles a tiempo parcial.
• Un miembro del personal o del profesorado se matricula como estudiante.
• Un miembro del profesorado es simultáneamente instructor, investigador y administrador de departamento.
• Un estudiante trabajador cambia de departamento o tiene dos puestos a la vez.
• Un antiguo alumno o jubilado recibe un acceso limitado y con plazo definido a un servicio específico.
• Un contratista o colaborador externo necesita un acceso que caduca automáticamente en una fecha establecida.

La regla más importante: cuando termina una afiliación, elimine únicamente el acceso vinculado a esa afiliación. Son posibles dos errores. El sistema puede retirar un acceso que otro rol activo todavía justifica, o puede dejar el acceso vigente después de que la afiliación haya terminado. Una coincidencia de identidad fiable (confirmar que dos registros pertenecen a la misma persona) y una cola de revisión documentada para los casos que las reglas automatizadas no pueden resolver mantienen ambos errores bajo control.

Construir la capa de datos e integración antes de automatizar

La automatización funciona una vez que una institución ha designado sus fuentes autorizadas, ha construido una coincidencia de identidad fiable y ha definido la precedencia de datos para los conflictos entre sistemas. Sin esos tres elementos, las reglas de aprovisionamiento actúan sobre registros obsoletos o no coincidentes, y conceden el acceso demasiado pronto o lo mantienen vigente demasiado tiempo.

Asigne una fuente de autoridad por atributo, no por sistema. Un modelo habitual asigna los atributos de situación académica al SIS o a la secretaría académica, los atributos de empleo a RR. HH./HCM y nómina, y los atributos de asignación docente a un sistema de programación o de asuntos académicos. La propiedad varía según el campus, así que documente la autoridad y la precedencia a nivel de atributo para su propio entorno.

Algunas credenciales no tienen un propietario natural en ninguno de esos sistemas. Una credencial de administrador en la nube compartida, utilizada por tres ingenieros de infraestructura, no pertenece ni a RR. HH. ni al SIS. Una capa de gobernanza y administración de identidad (IGA) puede registrar que el equipo de infraestructura es responsable de ella. El secreto en sí todavía necesita un sistema diseñado para almacenar, rotar y auditar credenciales compartidas. Ese es un control independiente.

Un flujo de eventos básico tiene este aspecto:

• Se produce un evento en el sistema de referencia.
• La coincidencia de identidad confirma a qué persona se aplica.
• Una regla de política evalúa qué debe cambiar.
• Se produce una aprobación donde es necesaria.
• Se ejecuta el aprovisionamiento o la revocación.
• Un evento de auditoría registra lo ocurrido.

Cualquier paso que falle, como una identidad sin coincidencia o un evento obsoleto, debe pasar a una cola de excepciones visible con un responsable asignado. No debe desaparecer en silencio.

NIST SP 800-63-4 establece requisitos para la verificación de identidad, la inscripción, la gestión de autenticadores, la autenticación y la federación. Es una referencia útil para la capa de identidad que sustenta esta automatización, aunque no prescribe una arquitectura educativa.

Aplicar controles de acceso y evidencias acordes con el riesgo

Los controles de acceso deben corresponder a la sensibilidad del recurso y al rol actual de la persona, mientras que la evidencia de auditoría debe mostrar quién aprobó el acceso, cuándo cambió y si sigue estando justificado. Los controles base incluyen el mínimo privilegio, el control de acceso basado en roles (RBAC), la MFA, el SSO, las revisiones programadas, el acceso con plazo limitado y la segregación de funciones.

La segregación de funciones impide que una misma persona solicite y apruebe su propio acceso. Las reglas basadas en políticas pueden añadir un contexto que el rol por sí solo no aporta, como las fechas de nombramiento o las asignaciones de curso. Las cuentas huérfanas, es decir, las cuentas que siguen activas después de que haya terminado la afiliación que las justificaba, deben marcarse automáticamente en lugar de descubrirse durante una auditoría.

Las credenciales operativas compartidas necesitan su propia capa. Un programa IAM/IGA puede gobernar la propiedad y la revisión de una cuenta de servicio compartida, un sistema de laboratorio o un inicio de sesión de un portal de proveedores, decidiendo quién es responsable y cuándo se recertifica el acceso. No almacena, rota ni comparte de forma segura el secreto. Ahí es donde entra en juego una capa de gestión de credenciales.

Lista de verificación de implementación para la gestión del ciclo de vida de identidad académica: los primeros 90 días

Los primeros 90 días deben definir la política, modelar las tres poblaciones, validar los datos de origen, pilotar un pequeño número de aplicaciones y medir las excepciones sin resolver antes de ampliar la automatización. La lista de verificación siguiente sigue ese orden y termina con la revisión legal y de privacidad. Cada paso produce un documento o una métrica que el grupo de gobernanza puede revisar.

La lista de verificación de 90 días del ciclo de vida de identidad académica (10 puntos)

• Forme un grupo de gobernanza: secretaría académica, RR. HH., asuntos académicos, IAM/TI, seguridad, responsables de aplicaciones y el servicio de asistencia.
• Defina el registro de la persona y las reglas para hacer coincidir identidades entre sistemas.
• Trace los estados del ciclo de vida de estudiantes, profesorado/instructores y personal, junto con sus desencadenantes.
• Asigne una fuente de autoridad y una regla de precedencia para cada atributo clave.
• Construya la AALM para sus primeras cinco aplicaciones o servicios.
• Redacte las reglas de aprobación, excepción, periodo de gracia y baja de emergencia.
• Pilote el aprovisionamiento y la revocación automatizados con supervisión activa.
• Establezca métricas base: tiempo de aprovisionamiento, tiempo de deshabilitación, acumulación de excepciones, cuentas inactivas, acceso temporal vencido y tasa de finalización de revisiones.
• Realice simulacros de mesa para los escenarios multirrol y de fin de periodo antes de la puesta en marcha.
• Haga que las partes interesadas legales y de privacidad revisen la política antes de aplicarla a gran escala.

InCommon recomienda la misma secuencia: definir las necesidades locales del ciclo de vida, representarlas visualmente, establecer la gobernanza, mejorar la calidad de los datos de origen, planificar las excepciones y documentar las decisiones.

Conclusión

Trate el ciclo de vida de identidad académica primero como un problema de política y después como un problema de herramientas. Tres flujos de eventos, tres responsables, un único registro de persona: eso es lo que permite eliminar el acceso al laboratorio de un estudiante graduado sin afectar al puesto que ocupó en la secretaría académica.

Siguiente paso: convoque al grupo de gobernanza y acuerden las primeras cinco aplicaciones que se van a trazar, clasificadas según la sensibilidad de los datos que contienen.

Preguntas frecuentes

El caos de contraseñas en las instituciones educativas: por qué importa

El caos de contraseñas se extiende más allá del servicio de asistencia de TI hacia el resto de la institución educativa, consumiendo tiempo del personal, ampliando la superficie de ataque y poniendo en riesgo el cumplimiento normativo. Vea los tres mayores riesgos y cómo solucionarlos.

PassworkPasswork Team

Baja de empleados: guía de revocación segura de acceso 2026

Deshabilitar una cuenta SSO no revoca el acceso. Las claves API, las credenciales de agentes de IA y las contraseñas compartidas lo sobreviven. Esta guía cubre el manual completo de baja: desde los desencadenantes de hora cero hasta la limpieza de identidades no humanas (NHI).

Passwork BlogAlex Muntyan

Las políticas de bóvedas de Passwork: una guía para CIO sobre seguridad empresarial

Los tipos de bóveda de Passwork vinculan los derechos de administrador a la propia política de la bóveda, no a quien la creó, cerrando una brecha que la mayoría de las empresas ni siquiera sabe que existe. Esta guía ofrece a los CIO y CISO un modelo operativo de gobernanza de bóvedas, vinculado a los requisitos de NIS2 e ISO 27001.

PassworkPasswork Team

Academic identity lifecycle management governs a person's access as their student, teaching, research, or employment status changes. In higher education it works best as three tracks: for students, faculty and instructors, and professional staff. Each track has its own triggers and approvals, joined at one identity record.

A graduating student, an adjunct whose term has ended, and a resigning employee often trigger the same offboarding ticket, although each should lose different access on a different date. This guide gives you a lifecycle matrix for all three populations, rules for overlapping roles, and a 90-day rollout checklist.

Why academic identity lifecycle management needs three tracks

Education needs separate access lifecycles because student status, teaching appointments, and staff employment are created and changed by different systems and different events. A single generic onboarding and offboarding process struggles to grant the right access on time and to remove it once the reason for that access ends.

• A student's access is tied to enrollment, course registration, and academic standing.
• A staff member's access is tied to a job and an employment record.
• A faculty member's access often depends on both an appointment and a specific teaching assignment, which can start and end on a different schedule than the employment record.

This pattern is usually described as Joiner-Mover-Leaver (JML): a framework for tracking when someone joins an organization, changes role within it, and eventually leaves. In education, "leaver" is the wrong word for a student who graduates but keeps limited alumni access, or for a faculty member whose teaching assignment ends while the appointment continues. A generic JML flow obscures these cases unless it models role-specific events, grace periods, and overlapping affiliations. The three-track model does.

InCommon's 2025 roundtable on higher-education identity practices found that 27% of respondents struggled most with policy and standards, 23% with role-based access control (RBAC), and 14% with understanding how different populations move through their lifecycles. The poll doesn't establish a single root cause. It does show that policy, role design, and lifecycle ownership deserve as much attention as technology selection.

The Academic Access Lifecycle Matrix

The Academic Access Lifecycle Matrix (AALM) turns lifecycle design into eight decisions, repeated for each of the three populations: trigger, authoritative source, identity attributes, baseline access, conditional access, approval owner, review point, and end-of-access action. Filling in these eight fields for students, faculty and instructors, and staff gives an institution a working policy document instead of an abstract framework.

The federal identity lifecycle management playbook describes creation, modification, and deletion as the core stages for provisioning, adjusting, and revoking access under least-privilege principles, meaning users get only the access their current role requires. The AALM adapts that logic to education, where "modification" covers far more variety than a typical corporate role change.

The next three sections show how the same fields change by population. Baseline access, attributes, and sources of authority vary by institution. Treat this matrix as a planning starting point and fill in your own systems and approval owners before treating any row as final.

Student access management from enrollment to alumni status

Student access management connects academic-status events to an entitlement model that adds, adjusts, or retires access without creating a new identity every time a student's situation changes. Enrollment, leave, withdrawal, graduation, and the move to alumni status each change what a student can reach, while the person record stays the same.

The student event chain

The chain typically runs from pre-arrival access for applicants through enrollment or matriculation, program and course changes, a leave of absence, withdrawal, graduation, and the move to alumni status. For each event, ask whether it should create a new identity, change existing access, or trigger a status review. In most cases the person record already exists, and the event changes access rather than creating a second identity.

Linking access to academic data

The SIS or registrar commonly serves as the authoritative source for academic-status attributes and feeds course-enrollment data downstream to the LMS. Document how that data reaches the LMS (direct integration, middleware, or an identity governance layer) instead of assuming one fixed path. When a student record doesn't match cleanly, such as after a name change, a duplicate application, or a transfer student with two prior accounts, route it to an exception queue. Don't let the system quietly create a second account.

Protecting education records and financial-aid data

34 CFR § 99.31(c) requires institutions to use reasonable methods to identify and authenticate the people to whom they disclose personally identifiable information from education records. Recordkeeping for requests and disclosures falls under § 99.32. That requirement covers disclosures of education-record information. It doesn't replace ordinary application-level access logging.

Where financial-aid data is involved, the Department of Education's GEN-25-08 guidance addresses permitted access to Federal Tax Information and FAFSA data for eligible institutions. Neither source defines a technical architecture. Institutional counsel should confirm how each applies to your systems.

Faculty and instructor access needs its own lifecycle

Faculty and instructor access needs its own lifecycle because teaching access depends on an appointment, a specific course assignment, and grade-submission duties, not on a standard employee start and end date. Adjuncts and visiting faculty make this visible: their LMS access may need to start before the contract and outlast the term.

EDUCAUSE describes a common scenario: a short-term instructor needs LMS access before the official start date to build a course, and may need limited access after the term ends to finish grading. A generic employee lifecycle, built around one hire date and one termination date, handles that pattern poorly. Institutions need a documented policy with a named grace period.

A faculty member's individual LMS or email entitlement belongs in the IAM/IGA access model. A credential-management layer is more relevant to shared operational accounts that IT or a designated owner controls directly, such as lab systems or vendor logins.

Professional staff lifecycle: employment events, role changes, and exits

Professional-staff access should follow validated employment and job-change events, with the relevant manager or business owner confirming any access beyond the standard role package. Typical triggers are hiring, transfer, promotion, leave, and termination, and each one should re-evaluate existing entitlements, not only add new ones.

A common failure mode is privilege creep: someone gets new access after a promotion, and nobody removes the access tied to the old role. Regular access recertification, a scheduled review where a manager confirms each person's access is still needed, catches this before it becomes an audit finding.

NIST SP 1800-35 frames secure authorized access as a continuous decision rather than a one-time grant, built on enhanced identity governance across distributed on-premises and cloud resources. Applying that to staff access is a design choice, not a NIST requirement: treat every role change as a trigger to re-evaluate existing entitlements.

One person, several roles: governing transitions and overlaps

A multi-role identity model keeps one person record and grants only the access justified by each active role. This prevents duplicate accounts and makes it possible to remove access tied to one role while leaving access from another role untouched.

Six scenarios cover most of the overlaps institutions run into:

• A student becomes a staff member, as when student workers move into part-time roles.
• A staff or faculty member enrolls as a student.
• A faculty member is simultaneously an instructor, a researcher, and a department administrator.
• A student worker changes departments or holds two jobs at once.
• An alumnus or retiree receives limited, time-bounded access to a specific service.
• A contractor or external collaborator needs access that expires automatically at a set date.

The rule that matters most: when one affiliation ends, remove only the access tied to that affiliation. Two errors are possible. The system can strip access that another active role still justifies, or it can leave access in place after the affiliation has ended. Reliable identity matching (confirming that two records belong to the same person) and a documented review queue for cases the automated rules can't resolve keep both errors manageable.

Build the data and integration layer before automating

Automation works once an institution has named its authoritative sources, built reliable identity matching, and defined data precedence for conflicts between systems. Without those three, provisioning rules act on stale or mismatched records and either grant access too early or leave it in place too long.

Assign a source of authority by attribute, not by system. A common model gives academic-status attributes to the SIS or registrar, employment attributes to HR/HCM and payroll, and teaching-assignment attributes to a scheduling or academic-affairs system. Ownership varies by campus, so document attribute-level authority and precedence for your own environment.

Some credentials have no natural owner in any of those systems. A shared cloud-admin credential used by three infrastructure engineers belongs to neither HR nor the SIS. An identity governance and administration (IGA) layer can record that the infrastructure team is accountable for it. The secret itself still needs a system built to store, rotate, and audit shared credentials. That is a separate control.

A basic event flow looks like this:

• A system-of-record event occurs.
• Identity matching confirms which person it applies to.
• A policy rule evaluates what should change.
• An approval happens where required.
• Provisioning or revocation runs.
• An audit event records what happened.

Any step that fails, such as an unmatched identity or a stale event, should go to a visible exception queue with an assigned owner. It should not disappear silently.

NIST SP 800-63-4 sets requirements for identity proofing, enrollment, authenticator management, authentication, and federation. It is a useful reference for the identity layer underneath this automation, though it doesn't prescribe an education architecture.

Apply access controls and evidence that match the risk

Access controls should match the sensitivity of the resource and the person's current role, while audit evidence should show who approved access, when it changed, and whether it is still justified. Baseline controls cover least privilege, role-based access control (RBAC), MFA, SSO, scheduled reviews, time-limited access, and segregation of duties.

Segregation of duties prevents one person from both requesting and approving their own access. Policy-based rules can add context that a role alone doesn't carry, such as appointment dates or course assignments. Orphaned accounts, meaning accounts still active after the affiliation that justified them has ended, should be flagged automatically instead of found during an audit.

Shared operational credentials need their own layer. An IAM/IGA program can govern ownership and review of a shared service account, a lab system, or a vendor portal login, deciding who is accountable and when access is recertified. It does not store, rotate, or safely share the secret. A credential-management layer takes over there.

Implementation checklist for academic identity lifecycle management: the first 90 days

The first 90 days should define policy, model the three populations, validate source data, pilot a small number of applications, and measure unresolved exceptions before automation expands. The checklist below follows that order and ends with legal and privacy review. Each step produces a document or metric the governance group can review.

The 90-day academic identity lifecycle checklist (10 points)

• Form a governance group: registrar, HR, academic affairs, IAM/IT, security, application owners, and the service desk.
• Define the person record and the rules for matching identities across systems.
• Map student, faculty/instructor, and staff lifecycle states and their triggers.
• Assign a source of authority and a precedence rule for each key attribute.
• Build the AALM for your first five applications or services.
• Write approval, exception, grace-period, and emergency-offboarding rules.
• Pilot automated provisioning and deprovisioning with active monitoring.
• Set baseline metrics: time to provision, time to disable, exception backlog, dormant accounts, overdue temporary access, and review completion rate.
• Run tabletop exercises for multi-role and end-of-term scenarios before go-live.
• Have legal and privacy stakeholders review the policy before enforcing it at scale.

InCommon recommends the same sequence: define local lifecycle needs, map them visually, establish governance, improve source-data quality, plan for exceptions, and document decisions.

Conclusion

Treat the academic identity lifecycle as a policy problem first and a tooling problem second. Three event streams, three owners, one person record: that is what lets you remove a graduated student's lab access without touching the job they took in the registrar's office.

Next step: convene the governance group and agree on the first five applications to map, ranked by the sensitivity of the data they hold.

Frequently asked questions

Password chaos in educational institutions: Why it matters

Password chaos spreads past the IT helpdesk into the rest of the educational institution, draining staff time, widening the attack surface, and risking compliance failures. See the three biggest risks and how to close them.

PassworkPasswork Team

Employee offboarding: Secure access revocation guide 2026

Disabling an SSO account doesn’t revoke access. API keys, AI agent credentials, and shared passwords survive it. This guide covers the full offboarding playbook — from zero-hour triggers to NHI cleanup.

Passwork BlogAlex Muntyan

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

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

PassworkPasswork Team

As notícias de cibersegurança de setembro de 2026 foram dominadas por tokens forjados, sessões reproduzidas e chaves de API divulgadas que continuaram a funcionar depois de a palavra-passe ter sido alterada, ou que nunca a exigiram. Duas vulnerabilidades constam já do catálogo Known Exploited Vulnerabilities da CISA e uma chave de fornecedor divulgada colocou em risco mais de 100 000 sites.

• Cisco ISE: CVE-2026-76460, um contorno de autenticação com exploração ativa confirmada (Cisco).
• EvilTokens: a Microsoft desarticulou um serviço de phishing por código de dispositivo associado a mais de 12 000 caixas de correio comprometidas em mais de 10 000 organizações (Microsoft).
• Brevo e Cloudflare: uma chave de API comprometida colocou mais de 100 000 sites em risco potencial (Sansec).
• JFrog Artifactory: uma falha explorada em honeypots para gerar tokens de administrador (SecurityWeek).
• Cleo Harmony: um exploit público para uma falha nos tokens de atualização JWT (SecurityWeek).
• CyberArk: 10 boletins de segurança em quatro datas, incluindo um crítico (CyberArk).
• Chaves de GitHub App: a GitGuardian verificou que 474 de 4802 chaves privadas divulgadas continuavam válidas e se autenticavam como 440 aplicações (GitGuardian).
• NIST IR 8587: orientações finais sobre a proteção de tokens e asserções, publicadas a 15 de setembro (NIST).

Cada caso abaixo mostra uma forma diferente de uma credencial continuar a funcionar quando já deveria ter deixado de o fazer: forjada, reproduzida, divulgada ou gerada a pedido. Seguem-se os detalhes, as versões afetadas e as correções, com uma breve lista de ações ao nível da equipa no final.

Exploração ativa de um contorno de autenticação no Cisco Identity Services Engine (CVE-2026-76460)

A Cisco publicou, a 16 de setembro de 2026, um aviso sobre o CVE-2026-76460, uma vulnerabilidade crítica de contorno de autenticação, explorável sem autenticação, numa API do Identity Services Engine (ISE). A Cisco classifica-a com CVSS 3.1 Base 10,0 (crítica) e confirmou a exploração ativa. A CISA acrescentou o CVE ao seu catálogo Known Exploited Vulnerabilities no mesmo dia.

O que aconteceu: Um pedido especialmente construído para o endpoint da API afetado permite a um atacante contornar a interface de gestão web do ISE e obter acesso não autorizado a um dispositivo ISE ou ISE-PIC afetado, sem credenciais válidas. O PSIRT da Cisco confirmou ter conhecimento de ataques em ambiente real. A data exata em que a exploração começou não foi divulgada.

Porque isto importa: O ISE é uma plataforma de políticas de acesso à rede. O acesso não autorizado pode criar um risco grave, dependente de cada implementação, para as operações de administração e de políticas, mas as fontes disponíveis não demonstram que as decisões de RBAC ou de MFA a jusante de todos os clientes tenham sido alteradas. O impacto depende da forma como cada organização implementou o ISE.

A lição defensiva: A Cisco indica que nenhuma solução alternativa resolve a falha. A atualização para uma versão corrigida é a correção completa. Como mitigação temporária, a Cisco recomenda listas de controlo de acesso de infraestrutura (iACL) que permitam apenas o tráfego de gestão e de plano de controlo necessário para o dispositivo afetado. Reveja o access.log de cada nó em busca de nomes de utilizador suspeitos e cruze os registos de rede e de firewall fora do próprio equipamento. Estes passos são de deteção e resposta e não substituem a aplicação da correção.

Fontes: Cisco; CISA KEV

A Microsoft desarticula o EvilTokens, um serviço de phishing por código de dispositivo OAuth

A 22 de setembro de 2026, a Digital Crimes Unit da Microsoft, em colaboração com parceiros, desarticulou a infraestrutura do EvilTokens, uma plataforma de phishing como serviço associada a mais de 12 000 caixas de correio comprometidas em mais de 10 000 organizações em todo o mundo.

O que aconteceu: O EvilTokens abusou dos fluxos de autorização de dispositivos do OAuth 2.0, o mecanismo concebido para dispositivos sem navegador, como televisores inteligentes ou ferramentas CLI, para levar os utilizadores a aprovar um início de sessão em nome do atacante. Separadamente, a Microsoft divulgou atividade de engenharia social com o tema das passkeys, observada desde maio de 2026. Numa das sequências investigadas, uma isca com passkeys conduziu a phishing por código de dispositivo. Noutros padrões investigados, os atacantes recorreram a pretextos de apoio técnico ou registaram métodos de autenticação controlados pelo atacante. Os relatórios da Microsoft não demonstram que todas as sequências tenham combinado todos estes passos numa única cadeia de ataque.

Porque isto importa: O phishing por código de dispositivo contorna as partes da autenticação que recebem mais atenção defensiva. Não há uma página de início de sessão falsa para identificar nem uma palavra-passe introduzida num site do atacante. A vítima aprova o início de sessão na página legítima da própria Microsoft, convencida de que trata de um procedimento de rotina. Ainda assim, uma vítima sem sessão Microsoft ativa pode continuar a ser solicitada a introduzir uma palavra-passe real e a responder a um desafio de MFA, pelo que esta técnica não elimina, em todos os casos, cada etapa de autenticação.

A lição defensiva: Desative os fluxos de autenticação por código de dispositivo para os utilizadores que não precisam deles do ponto de vista operacional e monitorize o volume anómalo de inícios de sessão por código de dispositivo como sinal de deteção. Quando o fluxo for genuinamente necessário, condicione-o a uma política de acesso condicional.

Fontes: Microsoft; Microsoft (atividade com o tema das passkeys)

Uma única chave de API da Cloudflare com privilégios excessivos colocou em risco mais de 100 000 sites

A 14 de setembro de 2026, atacantes utilizaram uma chave de API da Cloudflare comprometida e com privilégios amplos, pertencente à Brevo, uma plataforma de e-mail e marketing, para implementar um Cloudflare Worker malicioso que alterou recursos incorporados da Brevo em sites de clientes.

O que aconteceu: A telemetria da Sansec registou o Worker malicioso a servir conteúdo das 16:05 às 20:13 UTC de 14 de setembro, cerca de quatro horas. O relatório do incidente da Brevo descreve o Worker como ativo durante cerca de cinco horas e meia, uma janela mais longa do que a observada diretamente pela Sansec. A Sansec estimou que mais de 100 000 sites que utilizam componentes da Brevo afetados poderão ter estado expostos a conteúdo malicioso durante esse período.

Porque isto importa: Uma única chave de API da Cloudflare, de longa duração e com permissões totais, associada a um fornecedor de automatização de marketing, tornou-se um canal de distribuição de código malicioso por um grande número de sites de terceiros. As chaves de API de nuvem com âmbitos amplos e sem expiração são precisamente o tipo de credencial que a política tradicional de palavras-passe não abrange.

A lição defensiva: Limite as chaves de API ao conjunto mínimo de permissões de que uma integração realmente necessita, defina prazos de expiração mesmo para chaves ao nível do serviço e execute uma análise contínua de segredos nos repositórios e nos pipelines de implementação, e não apenas nos cofres de palavras-passe dos colaboradores. A monitorização de implementações inesperadas de Workers ou de alterações de encaminhamento teria provavelmente permitido detetar o problema mais depressa do que uma auditoria manual.

Fontes: Sansec; Brevo

Falha do JFrog Artifactory utilizada para gerar tokens de administrador (CVE-2026-82329)

A JFrog publicou uma correção para o CVE-2026-82329 a 28 de agosto de 2026. A 1 de setembro, a WatchTowr reportou atividade em honeypots compatível com a exploração da falha por atacantes para gerar tokens de administrador.

O que aconteceu: Os honeypots da WatchTowr captaram tentativas de exploração a partir de um pequeno número de IPs de origem, algumas das quais pareciam ser apenas atividade de verificação e não ataques de seguimento. Isto é prova de que a vulnerabilidade é explorável e está a ser sondada. Não demonstra um varrimento generalizado da internet nem a exploração em massa confirmada de instâncias de clientes.

Porque isto importa: Os repositórios de artefactos situam-se perto do centro da cadeia de fornecimento de software. Mantêm relações de confiança de federação com outros repositórios e transportam com frequência credenciais incorporadas para sistemas a jusante. Um atacante que consiga gerar um token de administrador não precisa de o roubar: cria acesso válido a pedido.

A lição defensiva: No caso do Artifactory self-hosted, atualize para a versão corrigida do respetivo ramo: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 ou 7.161.20. A JFrog afirma que os ambientes de nuvem afetados já foram reforçados. Se os registos mostrarem exploração ou emissão suspeita de tokens, revogue e volte a emitir os tokens de administrador potencialmente expostos e audite as configurações de federação. Os relatórios disponíveis sustentam a exploração observada em honeypots, e não o comprometimento confirmado de instâncias de clientes.

Fontes: JFrog; SecurityWeek

Exploit público para uma falha nos tokens de atualização JWT do Cleo Harmony (CVE-2026-84115)

Foi reportado um exploit público para o CVE-2026-84115 a 2 de setembro de 2026, pouco depois de o registo do CVE ter sido publicado, a 1 de setembro.

O que aconteceu: A falha afeta as versões do Cleo Harmony até à 5.8.1.10, inclusive, e está corrigida no Harmony 5.8.1.11. O registo do CVE descreve um problema explorável remotamente no JWT Refresh Token Handler de /api/connections: a manipulação do argumento Bearer resulta numa gestão indevida de privilégios. A SecurityWeek descreve o mesmo problema como uma falha que permite contornar a autenticação e elevar privilégios. Os relatórios disponíveis estabelecem a possibilidade de exploração pública e a reprodução por investigadores. Não demonstram a exploração confirmada de sistemas de clientes, nem que um token manipulado persista para além da expiração da sessão original.

Porque isto importa: Os tokens de atualização destinam-se a prolongar uma sessão de forma discreta, sem obrigar a um novo início de sessão. Uma falha na forma como um deles é validado transforma essa funcionalidade de conveniência num potencial risco de persistência, o que é motivo suficiente para aplicar a correção mesmo sem exploração confirmada.

A lição defensiva: Atualize para o Harmony 5.8.1.11 com brevidade. Se houver suspeita de exposição, siga as orientações atuais da Cleo, reveja as alterações de autenticação e de privilégios do período em causa e revogue os tokens de atualização pendentes quando a implementação for compatível com esse controlo. A existência de um exploit público não confirma, por si só, comprometimento nem acesso persistente.

Fontes: NVD; SecurityWeek

A CyberArk publica dez boletins de segurança em toda a sua linha de produtos PAM

A CyberArk publicou 10 boletins de segurança em setembro de 2026, em quatro lotes datados.

O que aconteceu: A CyberArk publicou 10 boletins de segurança em quatro lotes durante setembro de 2026, que tratam problemas de gravidade alta em agentes de gestão de privilégios em endpoints, componentes self-hosted de gateway e de cofre, análise de acessos privilegiados e gestão de credenciais de bases de dados, bem como um problema crítico (CA26-44) que afeta determinadas versões self-hosted do Password Vault Web Access (PVWA).

Porque isto importa: Os sistemas de gestão de acessos privilegiados (PAM) gerem ou dão acesso, com frequência, a credenciais privilegiadas e a infraestrutura sensível. Um conjunto concentrado de atualizações de segurança é um lembrete de que estes ambientes exigem uma gestão contínua de correções, uma governação de acessos clara e uma auditabilidade fiável. Os avisos não indicam, por si só, exploração ativa.

A lição defensiva: As organizações que utilizam os produtos afetados devem rever os avisos e dar prioridade à correção de acordo com a gravidade, a exposição e o impacto potencial nos sistemas relacionados com credenciais. De um modo mais geral, as equipas de segurança devem manter visibilidade sobre quem pode aceder a credenciais sensíveis e ser capazes de rever esse acesso quando necessário.

Fonte: CyberArk; quadro de boletins da CyberIAM

As chaves privadas de GitHub App divulgadas continuam a funcionar muito tempo depois da exposição

A GitGuardian testou 4802 chaves privadas de GitHub App divulgadas, encontradas em fontes públicas, e verificou que 474 continuavam a autenticar-se como 440 aplicações ativas distintas.

O que aconteceu: Uma chave privada de GitHub App não tem expiração automática e pode permanecer utilizável até ser revogada ou eliminada manualmente. Das 474 chaves ainda válidas testadas pela GitGuardian, 207 tinham permissão de escrita no conteúdo de repositórios, 40 podiam administrar runners self-hosted, 98 podiam controlar workflows e 44 detinham privilégios de administração da organização. Uma chave incluída num commit há anos pode continuar a autenticar-se se não tiver sido revogada ou eliminada.

Um padrão relacionado surgiu numa falha na gestão de APIs da WSO2, o CVE-2026-5430. O aviso data de maio de 2026 e o CVE foi publicado em agosto. A notícia de setembro foi a divulgação de exploração, e não uma nova divulgação da falha. Um atacante pode construir um JWT com um algoritmo de assinatura não admitido e explorar a validação defeituosa da WSO2 para contornar a autenticação. O serviço não precisa de emitir ele próprio um token. O honeypot da WatchTowr captou, a 13 de setembro, JWT forjados com privilégios de administrador contra o serviço, e a CISA acrescentou o CVE ao seu catálogo Known Exploited Vulnerabilities a 24 de setembro. As credenciais de back-end, as chaves de consumidor ou os segredos foram reportados como potencialmente acessíveis, e não como roubados de forma confirmada.

Porque isto importa: Uma fuga pública cria um acesso potencialmente persistente até a chave ser revogada ou eliminada. Por si só, não prova que a chave tenha sido utilizada nem que os dados tenham sido acedidos. O caso da WSO2 mostra um padrão relacionado uma camada abaixo na pilha: um atacante não precisa de forma alguma de uma chave divulgada se a própria lógica de validação puder ser enganada para aceitar uma chave forjada.

A lição defensiva: Mantenha um responsável e um processo documentado de rotação e revogação para cada chave de GitHub App. Se a exposição for suspeita ou confirmada, gere uma chave de substituição e revogue ou elimine prontamente a antiga; a rotação periódica reduz o tempo de exposição, embora o GitHub não prescreva um calendário universal. Nas implementações da WSO2, aplique a correção do fabricante, reveja os registos do período de exploração de setembro e faça a rotação das credenciais a que a camada de gestão de APIs tinha acesso.

Fontes: GitGuardian; documentação do GitHub; aviso da WSO2; The Hacker News

O NIST e a CISA finalizam orientações sobre a proteção de tokens de identidade e de acesso

O NIST e a CISA finalizaram o IR 8587 a 15 de setembro de 2026, após um rascunho público inicial de 22 de dezembro de 2025.

O que aconteceu: As orientações de implementação destinam-se principalmente às agências federais e aos fornecedores de serviços de nuvem que estas utilizam, e abrangem tokens de identidade, tokens de acesso e asserções em cenários de SSO, federação e acesso a APIs. As suas recomendações resumem práticas de gestão de chaves, verificação de tokens, ciclo de vida (incluindo duração e revogação) e monitorização contínua, com as responsabilidades repartidas entre fornecedores, agências consumidoras e consumidores de nuvem.

Porque isto importa: Várias das falhas descritas acima (JWT forjados, tokens de administrador gerados através de falhas de validação, chaves de API sem expiração) enquadram-se nas categorias abordadas por este relatório: lacunas de verificação, falta de controlos de ciclo de vida e responsabilidade pouco clara entre fornecedor e cliente quanto à revogação. Essa sobreposição é útil mesmo para organizações fora do setor federal.

A lição defensiva: Utilize o NIST IR 8587 como lista de verificação de trabalho face às práticas atuais: confirme que a duração dos tokens é limitada, que os percursos de revogação são testados e não apenas documentados, e que o registo de sessões capta detalhe suficiente para reconstituir, a posteriori, um incidente baseado em tokens.

Fontes: NIST; CISA

A CloudSEK detalha o BigBear 2.0, um serviço de atacante intermediário (adversary-in-the-middle) que reproduz sessões do Microsoft 365 após a MFA

A CloudSEK publicou a sua investigação sobre o BigBear 2.0 a 7 de setembro de 2026. A equipa TRIAD descobriu a operação em junho, o que não permite determinar quando começou toda a atividade da campanha.

O que aconteceu: O serviço de atacante intermediário baseado no Evilginx2 retransmitia inícios de sessão do Microsoft 365. Capturava as credenciais e o cookie de sessão emitido pela Microsoft depois de as vítimas concluírem a MFA, e depois permitia aos atacantes reproduzir as sessões autenticadas. O painel da CloudSEK continha 4148 registos de cookies de sessão e 474 autenticações concluídas com a MFA contornada. A BleepingComputer reportou que 258 organizações distintas tinham pelo menos um desses comprometimentos concluídos, enquanto 461 organizações constavam do conjunto de dados de alvos mais alargado. O valor de 4148 é uma contagem de registos de cookies e não uma contagem confirmada de vítimas únicas. (CloudSEK; BleepingComputer)

Porque isto importa: A MFA que a vítima conclui numa página retransmitida através de um proxy não protege nada depois de o cookie de sessão ser roubado. O atacante herda uma sessão já autenticada. Os códigos e as aprovações por notificação push não travam este padrão.

A lição defensiva: Dê prioridade a métodos resistentes a phishing, como as passkeys e as chaves de segurança FIDO2, para os administradores e os utilizadores de alto risco. Reveja as políticas de acesso condicional que associam as sessões a dispositivos em conformidade. Crie alertas para inícios de sessão em que o endereço IP ou o dispositivo da sessão mude pouco depois da MFA.

Fontes: CloudSEK; BleepingComputer

A Okta analisa um dump de infostealer com 44 791 JWT únicos e 1843 tokens ainda válidos na data de divulgação

A Okta publicou, a 9 de setembro de 2026, uma investigação sobre um dump de infostealer de 7 GB publicado no Telegram a 2 de agosto.

O que aconteceu: O dump continha dados de 5871 máquinas infetadas. A Okta identificou 44 791 JWT únicos, incluindo 555 provavelmente relacionados com a autenticação em serviços de IA, além de 2937 JWE relacionados com autenticação. À data da divulgação do dump, 1843 JWT e JWE ainda não tinham expirado. A Okta afirmou que os segredos de sessão não expirados poderiam, potencialmente, ser reproduzidos para contornar a autenticação baseada em credenciais. A investigação não reportou nenhuma reprodução bem-sucedida nem nenhuma tomada de controlo de conta confirmada. O êxito da reprodução depende do serviço e de controlos como o token binding ou as listas de IPs autorizados. (Okta)

Porque isto importa: Os infostealers levam tudo o que se encontra no endpoint, e os tokens fazem parte desse saque. A duração de um token determina durante quanto tempo um segredo roubado continua útil. Os tokens de serviços de IA no conjunto mostram que a exposição abrange agora ferramentas mais recentes, que as equipas adotam muitas vezes fora da gestão central de identidades.

A lição defensiva: Reduza a duração dos tokens sempre que o serviço o permita e associe os tokens a um dispositivo ou a uma rede quando tal for possível. Após uma infeção por infostealer, revogue as sessões e faça a rotação dos segredos, e não apenas a reposição da palavra-passe. Inclua as contas de serviços de IA no inventário de tokens e de chaves de API.

Fonte: Okta

A extensão JeetBot para a Twitch reencaminhava tokens OAuth através de proxies controlados pelo operador

A extensão maliciosa de navegador para a Twitch JeetBot tinha cerca de 30 500 instalações nas lojas, entre o Chrome e o Firefox (uma estimativa de instalações e não uma contagem confirmada de comprometimentos).

O que aconteceu: A Socket verificou que a extensão captava tokens OAuth da Twitch associados à conta e reencaminhava-os num parâmetro de consulta &auth= através de proxies controlados pelo operador. Os relatórios não demonstram que os tokens tenham sido utilizados para atividade não autorizada. A versão 85.8.7 do Firefox (16 de setembro) e a versão 85.8.9 do Chrome (reportada a 25 de setembro) pararam o reencaminhamento. O operador contestou a classificação da extensão como maliciosa, mas reconheceu problemas de segurança e de divulgação. (Socket)

A lição defensiva: Audite as extensões de navegador instaladas e trate como exposto qualquer token que tenha aparecido num URL. Os utilizadores do JeetBot devem revogar o acesso da aplicação à respetiva conta da Twitch.

Fonte: Socket

O Microsoft Entra começa a ativar automaticamente as passkeys antes da retirada da MFA por SMS e por chamada de voz

O Microsoft Entra começou a ativar automaticamente as passkeys a 1 de setembro de 2026 para os utilizadores da nuvem pública já ativados para MFA por SMS ou por chamada de voz na Entra Authentication Methods Policy ou nas definições legadas.

O que aconteceu: Quando estes utilizadores iniciarem sessão da próxima vez e concluírem a MFA, são incentivados a registar uma passkey. Este incentivo pode, em regra, ser adiado, e está disponível uma exclusão temporária ao nível do tenant até 1 de fevereiro de 2027. A entrega de SMS e de chamadas de voz fornecida pela Microsoft termina a 1 de fevereiro de 2027 para a maioria dos utilizadores e a 1 de julho de 2027 para os Global Administrators e os utilizadores externos. As organizações com uma necessidade legítima podem continuar a utilizar SMS ou chamadas de voz através de um fornecedor de telefonia compatível. Essa opção de configuração está prevista para 30 de outubro de 2026.

Porque isto importa: A alteração afasta a predefinição dos fatores baseados no telefone, o tipo que a campanha BigBear 2.0 acima mostra poder ser retransmitido. Os tenants que não façam nada verão agora pedidos de registo e perderão em 2027 a entrega de SMS e de chamadas de voz fornecida pela Microsoft.

A lição defensiva: Inventarie os utilizadores e os processos de serviço que ainda dependem de SMS ou de chamadas de voz. Comece o registo de passkeys pelos administradores e pelos utilizadores externos, cujo prazo é o mais próximo. Decida antes de 1 de fevereiro de 2027 se é necessário um fornecedor de telefonia ou se estes métodos podem ser totalmente retirados.

Fonte: Microsoft Learn

O que isto significa para a equipa

A maioria dos casos deste mês resume-se a credenciais que continuaram a funcionar quando já deveriam ter deixado de o fazer. Seis passos que a equipa pode seguir para evitar problemas semelhantes:

1. Inventariar as credenciais não humanas. Liste as chaves de API, os tokens de contas de serviço, as chaves privadas de GitHub App e os segredos de CI/CD tal como se listam as contas de utilizador. Atribua a cada uma um responsável identificado e um plano documentado de expiração ou rotação. Os casos da Brevo e das GitHub Apps envolveram chaves que ninguém acompanhava.
2. Limitar o âmbito e definir a expiração. Atribua a cada chave apenas as permissões de que a integração necessita e defina uma expiração sempre que o fornecedor a permita. Quando não o permita, agende a rotação manual.
3. Testar a revogação antes de ser necessária. Para cada fornecedor, confirme o que a revogação de uma sessão, de um JWT, de uma concessão OAuth ou de um token de atualização faz realmente. Após um incidente, execute o percurso de revogação de ponta a ponta, em vez de confiar na documentação. Revogue as sessões e faça a rotação dos segredos, e não apenas a reposição da palavra-passe.
4. Fechar as lacunas de OAuth e de sessão. Desative os fluxos de código de dispositivo para os utilizadores que não precisam deles e passe os administradores para passkeys ou chaves FIDO2 antes da retirada do SMS e das chamadas de voz pela Microsoft em 2027. Sempre que for possível, associe as sessões a dispositivos.
5. Corrigir primeiro a infraestrutura de identidade exposta. O Cisco ISE, o JFrog Artifactory, o Cleo Harmony e a WSO2 emitem ou validam o acesso a tudo o que está por trás deles. Trate as respetivas atualizações como prioridade em relação à aplicação rotineira de correções.
6. Registar o suficiente para reconstituir um incidente. Mantenha registos de sessão e de tokens suficientemente detalhados para mostrar quem se autenticou, a partir de onde e com que token. O NIST IR 8587 é uma lista de verificação utilizável para este ponto e para os anteriores.

Para leitura complementar, recomendam-se os guias sobre o ciclo de vida da rotação de segredos e sobre os segredos hardcoded.

Notícias mensais de cibersegurança: Autenticação sob cerco

Os incidentes de agosto de 2026 contornaram totalmente a autenticação: exploits confirmados no N-able N-central e no SharePoint, mais de 9 300 chaves AWS expostas e o Mirage2FA a sequestrar sessões após a MFA. Eis o que as equipas de TI e de segurança precisam de corrigir e auditar em primeiro lugar.

PassworkPasswork Team

Segurança de palavras-passe pós-quântica: o que muda e o que fazer

O algoritmo de Grover quase não afeta uma palavra-passe devidamente protegida com hash. O algoritmo de Shor inutiliza a troca de chaves RSA que a acompanha. Eis a auditoria em 3 camadas que permite determinar qual dos dois é, de facto, o problema.

PassworkPasswork Team

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

Os custos globais das violações atingiram um máximo histórico de 4,99 milhões de dólares em 2026, com uma deteção que demora 247 dias. Os ataques impulsionados por IA aumentam 56 %, mas a verdadeira crise é esta: os defensores implementam IA em todo o lado, exceto onde os atacantes entram. 92 % das organizações afetadas por violações relacionadas com IA não tinham qualquer controlo de acesso adequado.

PassworkAlex Muntyan