Access management

A implementação de um gestor de palavras-passe só é eficaz quando os utilizadores finais conseguem transformar o primeiro convite num fluxo de trabalho diário seguro e repetível. O Passwork apoia este objetivo com integração baseada em funções: cada grupo recebe um cenário adaptado às tarefas que tem de realizar na plataforma.

• Gestores de departamento: estruturam equipas e delegam o acesso sem recorrer à TI a cada pedido
• Administradores de TI e responsáveis pelos sistemas: implementam a plataforma, configuram cofres e gerem as definições de toda a organização
• Engenheiros de DevOps e integradores: ligam o Passwork à infraestrutura existente através da API e da CLI
• Especialistas de segurança e responsáveis pela conformidade: configuram o registo de auditoria, as políticas de acesso e os controlos associados a requisitos regulamentares
• Utilizadores finais: passam do primeiro convite ao trabalho diário em segurança

Este guia centra-se no último cenário: o que os utilizadores finais percorrem, passo a passo, desde o momento em que recebem um convite.

O percurso do utilizador num relance

O cenário Integração de utilizadores demora aproximadamente 15–30 minutos e abrange cinco etapas: ativar a conta, instalar as ferramentas do dia a dia, proteger o início de sessão, aprender as ações essenciais e trabalhar com credenciais partilhadas nos cofres adequados.

A sequência ajuda os utilizadores a passar da obtenção de acesso à criação dos hábitos de que precisarão mais tarde: utilizar o Passwork sempre que são necessárias credenciais, gerar palavras-passe em vez de as criar manualmente e perceber onde devem ficar as credenciais pessoais e as da empresa. Este foco na usabilidade reflete-se na distinção do Passwork como Best for User Interface na seleção de 2026 da Software Advice.

Começar pelo início de sessão e pela configuração de conta adequados

O primeiro passo depende da forma como a organização configurou o Passwork. Os colaboradores podem autenticar-se através de Single Sign-On (SSO) com um fornecedor de identidade da empresa, através da integração com o Active Directory por Lightweight Directory Access Protocol (LDAP) ou com uma conta local do Passwork. O registo de uma conta local pode também exigir a aprovação de um administrador.

As organizações que utilizam cifragem do lado do cliente acrescentam a palavra-passe mestra. O Passwork utiliza-a para cifrar a chave privada do utilizador no dispositivo, e a própria palavra-passe mestra nunca é transmitida ao servidor. Deve ser diferente da palavra-passe de início de sessão do utilizador no Passwork, quando aplicável, e da palavra-passe de domínio ou de SSO. Ao contrário da palavra-passe normal de uma conta, não tem mecanismo de recuperação. Um administrador pode repô-la, mas isso implica a perda dos dados cifrados privados do utilizador.

Tornar prático o fluxo de trabalho seguro

Uma vez ativa a conta, o Passwork aproxima-se de onde os colaboradores utilizam as credenciais. A extensão do navegador oferece preenchimento automático, geração de palavras-passe e acesso aos cofres diretamente no navegador. Depois de instalarem a extensão a partir da loja do navegador, os utilizadores introduzem o URL do Passwork da organização no campo do endereço do anfitrião e iniciam sessão com as suas credenciais. A aplicação móvel disponibiliza o mesmo fluxo de trabalho em iOS e Android, enquanto uma aplicação desktop para Windows e Linux pode ser implementada em ambientes onde uma extensão do navegador é menos adequada. A disponibilidade depende das permissões e da configuração da organização.

A aplicação móvel liga-se a partir da versão desktop do Passwork através da leitura de um código QR, o que oferece aos utilizadores uma forma simples de autorizar a aplicação para a sua organização.

Recomenda-se também desativar o gestor de palavras-passe integrado do navegador depois de instalar a extensão. A execução simultânea de ambos pode originar conflitos de preenchimento automático e tornar menos previsível o fluxo de trabalho pretendido.

Aqui, a conveniência tem uma finalidade de segurança: as tarefas de rotina, como iniciar sessão ou criar uma credencial, podem decorrer dentro do fluxo de trabalho gerido e não à margem dele.

Proteger a conta antes de começar o trabalho de rotina

A proteção da conta surge logo no início do cenário de utilizadores. A autenticação de dois fatores (2FA) acrescenta mais uma etapa de verificação ao início de sessão, pelo que a posse da palavra-passe da conta, por si só, não é suficiente para aceder.

Consoante a política e a configuração da organização, os utilizadores podem ligar a aplicação Passwork 2FA, um autenticador Time-based One-Time Password (TOTP), como o Google Authenticator ou o Microsoft Authenticator, ou chaves de segurança compatíveis com WebAuthn e autenticação biométrica.

Passkeys também podem estar disponíveis quando ativadas para a função do utilizador. Utilizam a biometria do dispositivo ou uma chave de segurança física compatível para autenticação sem palavra-passe, e os utilizadores podem registar várias passkeys para diferentes dispositivos.

Incluir estas opções no percurso inicial do utilizador ajuda a tornar a proteção da conta parte da configuração, e não uma tarefa de que os colaboradores têm de se lembrar mais tarde.

Ensinar as três ações do dia a dia

A maioria dos colaboradores só precisa de um pequeno conjunto de ações para começar a trabalhar de forma produtiva:

• Guardar uma credencial
• Gerar uma palavra-passe
• Utilizar o preenchimento automático

Em conjunto, estas três ações abrangem grande parte da interação diária de um colaborador com um gestor de palavras-passe.

Ao adicionar uma entrada, os utilizadores indicam o nome, o nome de utilizador, a palavra-passe, o URL e, opcionalmente, uma descrição. O URL tem uma função prática que vai além da documentação: o Passwork utiliza-o para associar as credenciais guardadas ao website adequado no preenchimento automático. Um URL incorreto ou em falta pode impedir que a entrada esperada seja apresentada.

Para novas contas e alterações de palavra-passe, os utilizadores podem gerar credenciais durante a criação de uma entrada ou através da extensão do navegador. O comprimento da palavra-passe e os conjuntos de carateres podem ser configurados no gerador, mas os requisitos que os colaboradores seguem devem ser determinados pela política de palavras-passe da própria organização.

Colocar as credenciais pessoais e partilhadas no local certo

Saber onde guardar uma credencial é tão importante como saber guardá-la.

Um cofre privado só é visível para o respetivo utilizador e destina-se a credenciais e notas pessoais. Os cofres da empresa contêm credenciais utilizadas por uma equipa ou departamento, incluindo contas de serviço partilhadas, com o acesso gerido pelo proprietário ou administrador do cofre.

Esta distinção tem uma consequência operacional. Uma credencial de equipa guardada no cofre privado de uma pessoa fica disponível apenas para essa pessoa. Guardá-la no cofre da empresa adequado mantém-na acessível aos colegas que têm as permissões necessárias, mesmo quando o colaborador original não está disponível.

Os utilizadores só veem os cofres e as pastas da empresa a que têm permissão de acesso. Quando falta algo necessário para o seu trabalho, o guia de integração orienta-os a pedir acesso ao gestor do departamento ou ao administrador do Passwork, em vez de criarem uma solução de armazenamento paralela.

Utilizar o guia como parte da implementação

Para as equipas de implementação, o cenário de utilizadores pode integrar a própria comunicação da implementação. Envie-o com o convite do Passwork e indique aos colaboradores quem pode ajudar em caso de falta de acesso a cofres ou de problemas com a conta.

Mantenha a mensagem centrada no percurso do utilizador. Os métodos de autenticação, a cifragem do lado do cliente, as opções de 2FA, as passkeys e a disponibilidade das aplicações dependem da configuração da organização, pelo que os colaboradores precisam do percurso relevante para o seu ambiente e não de detalhes administrativos sobre todas as configurações possíveis.

Um gestor de palavras-passe implementado torna-se útil quando os colaboradores sabem como o incorporar no trabalho diário. O guia de utilizadores do Passwork liga a ativação da conta a esse resultado: início de sessão seguro, acesso prático às credenciais, algumas ações repetíveis e uma distinção clara entre dados privados e dados da empresa.

Partilhe o cenário Integração de utilizadores com os novos colaboradores como parte da implementação do Passwork e dê-lhes um percurso definido do convite à utilização diária.

Se a sua equipa partilha credenciais através de folhas de cálculo, chat ou armazenamento do navegador, o Passwork oferece um cofre autoalojado com RBAC, registo de auditoria e saída de colaboradores com um clique, sem preços de nível empresarial. Instalar o Passwork na sua infraestrutura e deixe de se perguntar quem ainda tem a palavra-passe do Wi-Fi de há três admissões.

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

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

PassworkPasswork Team

Gestão de credenciais SaaS: 5 passos para centralizar o conjunto de aplicações

A gestão de credenciais SaaS transforma palavras-passe e chaves de API dispersas num único inventário, partilhado de forma deliberada e revogado na saída. Eis o modelo em cinco passos: inventário, estrutura, migração, controlo de acessos e automatização.

PassworkPasswork Team

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

Os tipos de cofre do Passwork associam os direitos de administração à própria política do cofre, e não a quem o criou, eliminando uma lacuna que a maioria das empresas nem sabe que existe. Este guia 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

Eine Passwortverwaltungs-Einführung wird erst dann effektiv, wenn Endbenutzer ihre erste Einladung in einen sicheren, wiederholbaren Arbeitsablauf für den Alltag umwandeln können. Passwork unterstützt dies mit rollenbasiertem Onboarding: Jede Gruppe erhält ein Szenario, das auf ihre Aufgaben auf der Plattform zugeschnitten ist.

• Abteilungsleiter — richten Teamstrukturen ein und delegieren Zugriffe, ohne für jede Anfrage die IT einzubeziehen.
• IT-Administratoren und Systemverantwortliche — stellen die Plattform bereit, konfigurieren Tresore und verwalten organisationsweite Einstellungen.
• DevOps-Ingenieure und Integratoren — verbinden Passwork über API und CLI mit der bestehenden Infrastruktur.
• Sicherheitsspezialisten und Compliance-Beauftragte — konfigurieren Audit-Protokollierung, Zugriffsrichtlinien und Kontrollen gemäß regulatorischer Anforderungen.
• Endbenutzer — gelangen von der ersten Einladung zur sicheren täglichen Arbeit.

Dieser Leitfaden konzentriert sich auf das letzte Szenario: Was Endbenutzer Schritt für Schritt durchlaufen, ab dem Moment, in dem sie eine Einladung erhalten.

Die Benutzerreise im Überblick

Das Szenario Benutzer-Onboarding dauert etwa 15–30 Minuten und umfasst fünf Phasen: Aktivierung des Accounts, Installation der alltäglichen Tools, Absicherung der Anmeldung, Erlernen der Kernaktionen und Arbeiten mit gemeinsam genutzten Anmeldedaten in den richtigen Tresoren.

Die Abfolge hilft Benutzern, vom Zugang zur Etablierung der Gewohnheiten zu gelangen, die sie später benötigen: Passwork dort nutzen, wo Anmeldedaten erforderlich sind, Passwörter generieren statt sie manuell zu erstellen, und verstehen, wohin persönliche und Unternehmensanmeldedaten gehören. Dieser Fokus auf Benutzerfreundlichkeit spiegelt sich darin wider, dass Passwork in der Software Advice 2026-Auswahl als Bestes für Benutzeroberfläche ausgezeichnet wurde.

Mit der richtigen Anmeldung und Account-Einrichtung beginnen

Der erste Schritt hängt davon ab, wie die Organisation Passwork konfiguriert hat. Mitarbeiter können sich über Single Sign-On (SSO) mit einem unternehmenseigenen Identity Provider authentifizieren, über Lightweight Directory Access Protocol (LDAP)-Integration mit Active Directory oder mit einem lokalen Passwork-Account. Die lokale Account-Registrierung kann auch eine Administrator-Genehmigung erfordern.

Organisationen, die clientseitige Verschlüsselung verwenden, fügen das Masterpasswort hinzu. Passwork verwendet es, um den privaten Schlüssel des Benutzers auf dem Gerät zu verschlüsseln, und das Masterpasswort selbst wird niemals an den Server übertragen. Es muss sich vom Passwork-Anmeldepasswort des Benutzers unterscheiden, sofern zutreffend, sowie von dessen Domain- oder SSO-Passwort. Anders als ein normales Account-Passwort gibt es keinen Wiederherstellungsmechanismus. Ein Administrator kann es zurücksetzen, aber dies führt zum Verlust der privaten verschlüsselten Daten des Benutzers.

Den sicheren Arbeitsablauf komfortabel gestalten

Sobald der Account aktiv ist, rückt Passwork näher dorthin, wo Mitarbeiter Anmeldedaten verwenden. Die Browsererweiterung bietet Autofill, Passwortgenerierung und Tresorzugriff direkt im Browser. Nach der Installation der Erweiterung aus dem Browser-Store geben Benutzer die Passwork-URL ihrer Organisation im Feld für die Host-Adresse ein und melden sich mit ihren Anmeldedaten an. Die mobile App bringt denselben Arbeitsablauf auf iOS und Android, während eine Desktop-Anwendung für Windows und Linux in Umgebungen eingesetzt werden kann, in denen eine Browsererweiterung weniger geeignet ist. Die Verfügbarkeit hängt von den organisatorischen Berechtigungen und der Konfiguration ab.

Die mobile App wird über die Desktop-Version von Passwork durch Scannen eines QR-Codes verbunden, was Benutzern eine unkomplizierte Möglichkeit bietet, die App für ihre Organisation zu autorisieren.

Es wird außerdem empfohlen, den integrierten Passwort-Manager des Browsers nach der Installation der Erweiterung zu deaktivieren. Der gleichzeitige Betrieb beider kann zu Autofill-Konflikten führen und den beabsichtigten Arbeitsablauf weniger vorhersehbar machen.

Komfort dient hier einem Sicherheitszweck: Routineaufgaben wie das Anmelden oder Erstellen von Anmeldedaten können innerhalb des verwalteten Arbeitsablaufs stattfinden, anstatt ihn zu umgehen.

Den Account absichern, bevor die Routinearbeit beginnt

Der Account-Schutz kommt im Benutzer-Szenario früh zum Einsatz. Die Zwei-Faktor-Authentifizierung (2FA) fügt der Anmeldung einen weiteren Verifizierungsschritt hinzu, sodass der Besitz des Account-Passworts allein für den Zugang nicht ausreicht.

Abhängig von der Organisationsrichtlinie und Konfiguration können Benutzer die Passwork 2FA-App, einen Time-based One-Time Password (TOTP)-Authenticator wie Google Authenticator oder Microsoft Authenticator oder WebAuthn-kompatible Sicherheitsschlüssel und biometrische Authentifizierung verbinden.

Passkeys können ebenfalls verfügbar sein, wenn sie für die Rolle des Benutzers aktiviert sind. Sie nutzen Geräte-Biometrie oder einen kompatiblen physischen Sicherheitsschlüssel für passwortlose Authentifizierung, und Benutzer können mehrere Passkeys für verschiedene Geräte registrieren.

Die Integration dieser Optionen in die initiale Benutzerreise hilft dabei, den Account-Schutz zu einem Teil der Einrichtung zu machen, anstatt ihn als Aufgabe zu belassen, an die sich Mitarbeiter später erinnern müssen.

Die drei alltäglichen Aktionen vermitteln

Die meisten Mitarbeiter benötigen nur eine kleine Anzahl von Aktionen, um produktiv arbeiten zu können:

• Anmeldedaten speichern
• Passwort generieren
• Autofill verwenden

Zusammen decken diese drei Aktionen einen Großteil der täglichen Interaktion ab, die ein Mitarbeiter mit einem Passwort-Manager hat.

Beim Hinzufügen eines Eintrags geben Benutzer dessen Namen, Login, Passwort, URL und eine optionale Beschreibung an. Die URL hat über die Dokumentation hinaus eine praktische Funktion: Passwork verwendet sie, um gespeicherte Anmeldedaten mit der entsprechenden Website für Autofill abzugleichen. Eine falsche oder fehlende URL kann verhindern, dass der erwartete Eintrag angezeigt wird.

Für neue Accounts und Passwortänderungen können Benutzer Anmeldedaten entweder beim Erstellen eines Eintrags oder über die Browsererweiterung generieren. Passwortlänge und Zeichensätze können im Generator konfiguriert werden, während die eigene Passwortrichtlinie der Organisation die Anforderungen bestimmen sollte, denen die Mitarbeiter folgen.

Persönliche und gemeinsam genutzte Anmeldedaten am richtigen Ort speichern

Zu wissen, wo man Anmeldedaten speichert, ist ebenso wichtig wie zu wissen, wie man sie speichert.

Ein privater Tresor ist nur für seinen Benutzer sichtbar und ist für persönliche Anmeldedaten und Notizen vorgesehen. Unternehmenstresore enthalten Anmeldedaten, die von einem Team oder einer Abteilung verwendet werden, einschließlich gemeinsam genutzter Dienstkonten, wobei der Zugriff vom Tresor-Besitzer oder Administrator verwaltet wird.

Die Unterscheidung hat eine operative Konsequenz. Anmeldedaten eines Teams, die im privaten Tresor einer Person gespeichert sind, bleiben nur dieser Person zugänglich. Die Speicherung im entsprechenden Unternehmenstresor stellt sicher, dass sie für Kollegen mit den erforderlichen Berechtigungen zugänglich bleiben — auch wenn der ursprüngliche Mitarbeiter nicht verfügbar ist.

Benutzer sehen nur Unternehmenstresore und Ordner, für die sie Zugriffsberechtigungen haben. Wenn etwas für ihre Arbeit Erforderliches fehlt, weist der Onboarding-Leitfaden sie an, den Zugriff bei ihrem Abteilungsleiter oder Passwork-Administrator anzufordern, anstatt eine parallele Speicherlösung zu erstellen.

Den Leitfaden als Teil Ihrer Einführung nutzen

Für Implementierungsteams kann das Benutzer-Szenario Teil der Rollout-Kommunikation selbst werden. Senden Sie es zusammen mit der Passwork-Einladung und teilen Sie den Mitarbeitern mit, wer bei fehlendem Tresorzugriff oder Account-Problemen helfen kann.

Halten Sie die Nachricht auf die Benutzerreise fokussiert. Authentifizierungsmethoden, clientseitige Verschlüsselung, 2FA-Optionen, Passkeys und Anwendungsverfügbarkeit hängen von der Konfiguration der Organisation ab. Daher benötigen Mitarbeiter den für ihre Umgebung relevanten Pfad und keine administrativen Details zu jeder möglichen Einrichtung.

Ein bereitgestellter Passwort-Manager wird nützlich, wenn Mitarbeiter wissen, wie sie ihn in ihre tägliche Arbeit integrieren können. Der Passwork-Benutzer-Leitfaden verbindet die Account-Aktivierung mit diesem Ergebnis: sichere Anmeldung, bequemer Zugriff auf Anmeldedaten, einige wiederholbare Aktionen und eine klare Unterscheidung zwischen privaten und Unternehmensdaten.

Teilen Sie das Szenario Benutzer-Onboarding mit neuen Mitarbeitern als Teil Ihrer Passwork-Einführung und geben Sie ihnen einen definierten Weg von der Einladung bis zur täglichen Nutzung.

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

Passwork 7.7: Sicherer Offline-Modus für Desktop- und Mobile-Apps

Passwörter funktionieren jetzt auch offline. Passwork 7.7 bringt sicheren Offline-Zugriff mit vollständiger Admin-Übersicht, organisationsweite Kontrollen für Dateianhänge und fünf neue rollenbasierte Onboarding-Leitfäden für eine reibungslosere Einführung.

PassworkPasswork Team

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

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

PassworkPasswork Team

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

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

PassworkPasswork Team

La implementación de un gestor de contraseñas solo se vuelve efectiva cuando los usuarios finales pueden convertir su primera invitación en un flujo de trabajo diario seguro y repetible. Passwork respalda esto con incorporación basada en roles: cada grupo recibe un escenario diseñado en torno a lo que necesita hacer en la plataforma.

• Responsables de departamento — configuran estructuras de equipo y delegan acceso sin involucrar a TI para cada solicitud.
• Administradores de TI y propietarios de sistemas — despliegan la plataforma, configuran bóvedas y gestionan ajustes a nivel de organización.
• Ingenieros DevOps e integradores — conectan Passwork a la infraestructura existente a través de API y CLI.
• Especialistas en seguridad y responsables de cumplimiento — configuran registros de auditoría, políticas de acceso y controles vinculados a requisitos normativos.
• Usuarios finales — pasan de su primera invitación al trabajo diario seguro.

Esta guía se centra en el último escenario: lo que experimentan los usuarios finales, paso a paso, desde el momento en que reciben una invitación.

El recorrido del usuario en resumen

El escenario de incorporación de usuarios toma aproximadamente 15–30 minutos y cubre cinco etapas: activar la cuenta, instalar las herramientas cotidianas, asegurar el inicio de sesión, aprender las acciones principales y trabajar con credenciales compartidas en las bóvedas correctas.

La secuencia ayuda a los usuarios a pasar de obtener acceso a establecer los hábitos que necesitarán más adelante: usar Passwork donde se requieran credenciales, generar contraseñas en lugar de crearlas manualmente y comprender dónde pertenecen las credenciales personales y corporativas. Este enfoque en la usabilidad se refleja en que Passwork fue nombrado Mejor por Interfaz de Usuario en la selección de Software Advice de 2026.

Comience con el inicio de sesión y la configuración de cuenta correctos

El primer paso depende de cómo la organización haya configurado Passwork. Los empleados pueden autenticarse mediante Single Sign-On (SSO) con un proveedor de identidad corporativo, mediante integración Lightweight Directory Access Protocol (LDAP) con Active Directory, o con una cuenta local de Passwork. El registro de cuenta local también puede requerir aprobación del administrador.

Las organizaciones que utilizan cifrado del lado del cliente añaden la contraseña maestra. Passwork la utiliza para cifrar la clave privada del usuario en el dispositivo, y la contraseña maestra nunca se transmite al servidor. Debe ser diferente de la contraseña de inicio de sesión de Passwork del usuario, cuando corresponda, y de su contraseña de dominio o SSO. A diferencia de una contraseña de cuenta regular, no tiene mecanismo de recuperación. Un administrador puede restablecerla, pero hacerlo resulta en la pérdida de los datos privados cifrados del usuario.

Haga conveniente el flujo de trabajo seguro

Una vez que la cuenta está activa, Passwork se acerca a donde los empleados usan credenciales. La extensión del navegador proporciona autocompletado, generación de contraseñas y acceso a bóvedas directamente en el navegador. Después de instalar la extensión desde la tienda del navegador, los usuarios ingresan la URL de Passwork de su organización en el campo de dirección del host e inician sesión con sus credenciales. La aplicación móvil lleva el mismo flujo de trabajo a iOS y Android, mientras que una aplicación de escritorio para Windows y Linux puede desplegarse en entornos donde una extensión de navegador es menos adecuada. La disponibilidad depende de los permisos y la configuración de la organización.

La aplicación móvil se conecta desde la versión de escritorio de Passwork escaneando un código QR, brindando a los usuarios una forma sencilla de autorizar la aplicación para su organización.

También se recomienda desactivar el gestor de contraseñas integrado del navegador después de instalar la extensión. Ejecutar ambos puede crear conflictos de autocompletado y hacer que el flujo de trabajo previsto sea menos predecible.

La comodidad aquí sirve a un propósito de seguridad: las tareas rutinarias como iniciar sesión o crear una credencial pueden ocurrir dentro del flujo de trabajo gestionado en lugar de fuera de él.

Asegure la cuenta antes de que comience el trabajo rutinario

La protección de la cuenta aparece temprano en el escenario de usuarios. La autenticación de dos factores (2FA) añade otro paso de verificación al inicio de sesión, por lo que la posesión de la contraseña de la cuenta por sí sola no es suficiente para el acceso.

Dependiendo de la política y configuración de la organización, los usuarios pueden conectar la aplicación Passwork 2FA, un autenticador de contraseña de un solo uso basada en tiempo (TOTP) como Google Authenticator o Microsoft Authenticator, o llaves de seguridad compatibles con WebAuthn y autenticación biométrica.

Las Passkeys también pueden estar disponibles cuando están habilitadas para el rol del usuario. Utilizan biometría del dispositivo o una llave de seguridad física compatible para autenticación sin contraseña, y los usuarios pueden registrar múltiples passkeys para diferentes dispositivos.

Incluir estas opciones en el recorrido inicial del usuario ayuda a que la protección de la cuenta sea parte de la configuración en lugar de una tarea que los empleados tengan que recordar más tarde.

Enseñe las tres acciones cotidianas

La mayoría de los empleados solo necesitan un pequeño conjunto de acciones para comenzar a trabajar de manera productiva:

• Guardar una credencial
• Generar una contraseña
• Usar el autocompletado

Juntas, estas tres acciones cubren gran parte de la interacción diaria que un empleado tiene con un gestor de contraseñas.

Al añadir una entrada, los usuarios proporcionan su nombre, inicio de sesión, contraseña, URL y descripción opcional. La URL tiene un papel práctico más allá de la documentación: Passwork la utiliza para hacer coincidir las credenciales guardadas con el sitio web apropiado para el autocompletado. Una URL incorrecta o faltante puede impedir que aparezca la entrada esperada.

Para cuentas nuevas y cambios de contraseña, los usuarios pueden generar credenciales mientras crean una entrada o a través de la extensión del navegador. La longitud de la contraseña y los conjuntos de caracteres pueden configurarse en el generador, mientras que la política de contraseñas propia de la organización debe determinar los requisitos que siguen los empleados.

Coloque las credenciales personales y compartidas en el lugar correcto

Saber dónde guardar una credencial es tan importante como saber cómo guardarla.

Una bóveda privada solo es visible para su usuario y está destinada a credenciales personales y notas. Las bóvedas corporativas contienen credenciales utilizadas por un equipo o departamento, incluidas cuentas de servicio compartidas, con acceso gestionado por el propietario de la bóveda o el administrador.

La distinción tiene una consecuencia operativa. Una credencial de equipo almacenada en la bóveda privada de alguien permanece disponible solo para esa persona. Almacenarla en la bóveda corporativa apropiada la mantiene accesible para los colegas que tienen los permisos requeridos, incluso cuando el empleado original no está disponible.

Los usuarios solo ven las bóvedas y carpetas corporativas a las que tienen permiso de acceso. Cuando falta algo necesario para su trabajo, la guía de incorporación los dirige a solicitar acceso a su responsable de departamento o administrador de Passwork en lugar de crear un sistema de almacenamiento paralelo.

Use la guía como parte de su implementación

Para los equipos de implementación, el escenario de usuarios puede convertirse en parte de la comunicación de implementación. Envíelo con la invitación de Passwork e indique a los empleados quién puede ayudar con el acceso faltante a bóvedas o problemas de cuenta.

Mantenga el mensaje centrado en el recorrido del usuario. Los métodos de autenticación, el cifrado del lado del cliente, las opciones de 2FA, las passkeys y la disponibilidad de aplicaciones dependen de la configuración de la organización, por lo que los empleados necesitan la ruta relevante para su entorno en lugar de detalles administrativos sobre cada configuración posible.

Un gestor de contraseñas desplegado se vuelve útil cuando los empleados saben cómo incorporarlo a su trabajo diario. La guía de usuarios de Passwork conecta la activación de la cuenta con ese resultado: inicio de sesión seguro, acceso conveniente a credenciales, algunas acciones repetibles y una distinción clara entre datos privados y corporativos.

Comparta el escenario de incorporación de usuarios con los nuevos empleados como parte de su implementación de Passwork y bríndeles un camino definido desde la invitación hasta el uso cotidiano.

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

Passwork 7.7: Modo sin conexión seguro para aplicaciones de escritorio y móviles

Las contraseñas ahora también funcionan sin conexión. Passwork 7.7 incorpora acceso sin conexión seguro con supervisión completa del administrador, controles de archivos adjuntos a nivel de organización y cinco nuevas guías de incorporación basadas en roles para una implementación más fluida.

PassworkPasswork Team

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

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

PassworkPasswork Team

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

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

PassworkPasswork Team

A password-management rollout becomes effective only when end users can turn their first invitation into a secure, repeatable everyday workflow. Passwork supports this with role-based onboarding: each group gets a scenario built around what they need to do on the platform.

• Department managers — set up team structures and delegate access without involving IT for every request
• IT administrators and system owners — deploy the platform, configure vaults, and manage organization-wide settings
• DevOps engineers and integrators — connect Passwork to existing infrastructure through the API and CLI
• Security specialists and compliance officers — configure audit logging, access policies, and controls tied to regulatory requirements
• End users — move from their first invitation to secure daily work

This guide focuses on the last scenario: what end users go through, step by step, from the moment they receive an invitation.

The user journey at a glance

The User Onboarding scenario takes approximately 15–30 minutes and covers five stages: activating the account, installing everyday tools, securing sign-in, learning the core actions, and working with shared credentials in the right vaults.

The sequence helps users move from gaining access to establishing the habits they will need later: using Passwork where credentials are required, generating passwords instead of creating them manually, and understanding where personal and corporate credentials belong. This focus on usability is reflected in Passwork being named Best for User Interface in Software Advice’s 2026 selection.

Start with the right sign-in and account setup

The first step depends on how the organization has configured Passwork. Employees may authenticate through Single Sign-On (SSO) with a corporate identity provider, through Lightweight Directory Access Protocol (LDAP) integration with Active Directory, or with a local Passwork account. Local account registration may also require administrator approval.

Organizations using client-side encryption add the master password. Passwork uses it to encrypt the user’s private key on the device, and the master password itself is never transmitted to the server. It must be different from the user’s Passwork login password, where applicable, and from their domain or SSO password. Unlike a regular account password, it has no recovery mechanism. An administrator can reset it, but doing so results in the loss of the user’s private encrypted data.

Make the secure workflow convenient

Once the account is active, Passwork moves closer to where employees use credentials. The browser extension provides autofill, password generation, and vault access directly in the browser. After installing the extension from the browser’s store, users enter their organization’s Passwork URL in the host address field and sign in with their credentials. The mobile app brings the same workflow to iOS and Android, while a Windows and Linux desktop application can be deployed in environments where a browser extension is less suitable. Availability depends on organizational permissions and configuration.

The mobile app is connected from the desktop version of Passwork by scanning a QR code, giving users a straightforward way to authorize the app for their organization.

We also recommend disabling the browser's built-in password manager after installing the extension. Running both can create autofill conflicts and make the intended workflow less predictable.

Convenience here serves a security purpose: routine tasks such as signing in or creating a credential can happen inside the managed workflow instead of around it.

Secure the account before routine work begins

Account protection comes early in the Users scenario. Two-factor authentication (2FA) adds another verification step to sign-in, so possession of the account password alone is insufficient for access.

Depending on organizational policy and configuration, users can connect the Passwork 2FA app, a Time-based One-Time Password (TOTP) authenticator such as Google Authenticator or Microsoft Authenticator, or WebAuthn-compatible security keys and biometric authentication.

Passkeys may also be available when enabled for the user’s role. They use device biometrics or a compatible physical security key for passwordless authentication, and users can register multiple passkeys for different devices.

Putting these options into the initial user journey helps make account protection part of setup rather than a task employees have to remember later.

Teach the three everyday actions

Most employees only need a small set of actions to start working productively:

• Save a credential
• Generate a password
• Use autofill

Together, these three actions cover much of the daily interaction an employee has with a password manager.

When adding an entry, users provide its name, login, password, URL, and optional description. The URL has a practical role beyond documentation: Passwork uses it to match saved credentials with the appropriate website for autofill. An incorrect or missing URL can prevent the expected entry from appearing.

For new accounts and password changes, users can generate credentials either while creating an entry or through the browser extension. Password length and character sets can be configured in the generator, while the organization's own password policy should determine the requirements employees follow.

Put personal and shared credentials in the right place

Knowing where to save a credential is as important as knowing how to save one.

A private vault is visible only to its user and is intended for personal credentials and notes. Corporate vaults hold credentials used by a team or department, including shared service accounts, with access managed by the vault owner or administrator.

The distinction has an operational consequence. A team credential stored in someone’s private vault remains available only to that person. Storing it in the appropriate corporate vault keeps it accessible to colleagues who have the required permissions, including when the original employee is unavailable.

Users only see corporate vaults and folders they have permission to access. When something required for their work is missing, the onboarding guide directs them to request access from their department manager or Passwork administrator rather than create a parallel storage arrangement.

Use the guide as part of your rollout

For implementation teams, the Users scenario can become part of the rollout communication itself. Send it with the Passwork invitation and tell employees who can help with missing vault access or account issues.

Keep the message focused on the user journey. Authentication methods, client-side encryption, 2FA options, passkeys, and application availability depend on the organization’s configuration, so employees need the path relevant to their environment rather than administrative details about every possible setup.

A deployed password manager becomes useful when employees know how to incorporate it into their daily work. The Passwork Users guide connects account activation with that outcome: secure sign-in, convenient access to credentials, a few repeatable actions, and a clear distinction between private and corporate data.

Share the User onboarding scenario scenario with new employees as part of your Passwork rollout and give them a defined path from invitation to everyday use.

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

Passwork 7.7: Secure offline mode for desktop and mobile apps

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

PassworkPasswork Team

SaaS credential management: 5 steps to centralize your app stack

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

PassworkPasswork Team

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

«Posso migrar do [concorrente] com um único clique?» é uma das perguntas mais frequentes que os fornecedores ouvem em reuniões comerciais, sobretudo logo após a violação de dados de um concorrente ser notícia. Os fornecedores apresentam a migração com um clique como uma funcionalidade de conveniência. Em ambientes empresariais, é apenas o ponto de partida.

Uma migração de gestor de palavras-passe que funcione recria a hierarquia de cofres, a propriedade, as permissões, as contas de serviço, as automatizações e as integrações. A qualidade dessa reconstrução determina se os utilizadores, as aplicações e a infraestrutura continuam a funcionar em segurança após a transição.

Verizon, no Data Breach Investigations Report de 2026, concluiu que 39 % dos incidentes de System Intrusion envolveram credenciais roubadas, enquanto 84 % envolveram servidores. À medida que os gestores de palavras-passe passam a fazer parte do plano de controlo da infraestrutura, a precisão da migração afeta diretamente a fiabilidade operacional e a segurança.

Este artigo explica porque é que a migração empresarial é um projeto de engenharia e como executá-la sem interromper o acesso em produção pelo caminho.

A migração começa pelo mapeamento dos modelos de acesso

Nenhuma ferramenta de importação universal consegue recriar com rigor o modelo de acesso de uma organização, porque os modelos de segurança raramente coincidem entre plataformas.

Os diferentes gestores de palavras-passe implementam de forma distinta o controlo de acesso baseado em funções, a herança de permissões, a propriedade de cofres partilhados e a pertença a grupos. Mesmo quando dois sistemas admitem os mesmos conceitos, a implementação assenta frequentemente em pressupostos diferentes.

Veja-se o caso de três organizações:

• A empresa A organiza os cofres por função de negócio
• A empresa B organiza-os por equipas de produto
• A empresa C organiza-os por clientes e projetos

A hierarquia é apenas a parte visível do problema. O verdadeiro desafio consiste em traduzir a semântica de segurança entre sistemas.

A plataforma de origem pode herdar permissões através de grupos aninhados. O destino pode, em vez disso, exigir atribuições explícitas. A propriedade de cofres partilhados pode não ter equivalente direto. Uma função administrativa pode agregar privilégios que, após a migração, têm de ser distribuídos por várias funções. Os modelos RBAC quase nunca têm correspondência um para um.

Os tipos de cofre do próprio Passwork mostram porquê. Um cofre da empresa partilhado e um cofre de utilizador partilhado assentam em pressupostos diferentes sobre quem pode ver o quê. O importador tem de tomar essa decisão e não a inferir a partir do nome de uma pasta.

O mesmo princípio aplica-se ao tratamento da estrutura. Durante a importação, um administrador pode:

• Reconstruir a hierarquia de origem numa pasta existente
• Aplanar tudo num único destino
• Recriar a árvore completa de cofres na raiz

Cada opção é uma escolha deliberada sobre a forma como a organização pretende operar daqui em diante, e essa escolha depende da maneira como a organização realmente funciona.

Um importador genérico copia valores de campos. Decidir que permissões preservar, converter, fundir ou descartar exige um discernimento que um script não tem.

Os atacantes visam cada vez mais o acesso administrativo legítimo, precisamente o que está a ser migrado: contas de confiança e os caminhos que permitem as operações privilegiadas. Uma migração correta garante que esses caminhos continuam a comportar-se como previsto após a transição.

Alguns objetos podem ser copiados, outros têm de ser redesenhados

A migração de um gestor de palavras-passe empresarial remodela o modelo de acesso da organização em quatro camadas distintas: contexto de identidade, políticas de acesso, integrações operacionais e fronteiras de confiança. Cada camada introduz restrições técnicas que um ficheiro de importação plano não consegue representar.

A diferença entre copiado e redesenhado é bem visível nas ferramentas de migração reais. O importador oficial de Bitwarden do Passwork, por exemplo, move automaticamente itens de início de sessão, notas seguras, coleções, estrutura de pastas, URLs e códigos TOTP. Ignora deliberadamente os anexos e qualquer tipo de item que não reconheça, registando cada omissão em vez de tentar adivinhar um mapeamento. Trata-se de uma decisão de conceção, e não de uma limitação: alguns objetos podem ser copiados com segurança, e outros exigem que uma pessoa decida o que lhes acontece.

As contas de serviço sem proprietários claros, as permissões herdadas, as integrações obsoletas e os cofres partilhados esquecidos há muito tempo pertencem à segunda categoria. Uma migração bem-sucedida preserva apenas o que ainda reflete o modelo de acesso pretendido pela organização.

Qualquer um destes elementos, se tratado incorretamente, cria uma lacuna: uma integração órfã, um prestador de serviços que mantém acesso à produção ou uma conta de automatização que se autentica no destino errado. Nenhuma destas situações surge como erro de importação. Normalmente manifestam-se semanas depois sob a forma de incidentes.

O modelo mental certo para a migração e como o Passwork o aplica

Quando a migração é tratada como uma transformação arquitetural, a implementação segue naturalmente os mesmos princípios de engenharia aplicados noutros projetos de infraestrutura: tornar cada passo explícito, revisável e reproduzível.

Em vez de depender de um importador de caixa negra para interpretar a estrutura de uma organização, o processo de migração deve expor cada transformação sob a forma de código. Os engenheiros devem poder inspecionar os dados exportados, definir como são convertidos e controlar exatamente como cada objeto é recriado no sistema de destino.

O Passwork disponibiliza três caminhos de migração, escolhidos em função da origem e do volume, e não da conveniência:

Os dois primeiros cobrem a maioria das migrações reais. O terceiro torna visível o princípio da «transformação como código». Um script de migração construído sobre o conector Python do Passwork autentica-se, cria explicitamente o cofre de destino e a estrutura de pastas e grava cada item com exatamente os campos que a organização pretende preservar:

from passwork_client import PassworkClient

passwork = PassworkClient("https://passwork.example.com")
passwork.set_tokens(access_token, refresh_token)
passwork.set_master_key(master_key)

vault_type = passwork.find_vault_type(code="company")
vault_id = passwork.create_vault("Migrated – IT", vault_type["id"])
vault = passwork.get_vault(vault_id)

folder = passwork.call("POST", "/api/v1/folders", {
    "name": "Databases",
    "vaultId": vault["id"],
})

passwork.create_item({
    "name": "Postgres primary",
    "login": "app_rw",
    "password": "...",
    "urls": ["https://db.internal"],
    "description": "Imported from Bitwarden",
    "vaultId": vault["id"],
    "folderId": folder["id"],
    "customs": [
        {"name": "TOTP", "value": "otpauth://...", "type": "totp"},
    ],
})

Nada chega a um cofre, a uma pasta ou a um conjunto de permissões sem que o script o determine. Numa migração completa de Passwork para Passwork, a mesma lógica escala para os endpoints REST em massa vaults/import, folders/import e items/import, que devolvem um mapa sourceId → id para que os objetos-pai sejam criados antes dos objetos-filho e todas as relações se mantenham intactas.

A fase de transformação é onde a migração se torna previsível. Os engenheiros podem codificar explicitamente as regras de migração: renomear cofres, reatribuir proprietários, dividir funções administrativas, aplanar permissões herdadas ou excluir por completo registos obsoletos. Estas decisões passam a ser código revisável, e não pressupostos escondidos num assistente de importação genérico. Se for necessário repetir ou auditar a migração mais tarde, a lógica de transformação mantém-se transparente e reproduzível.

Isto altera também a forma como a própria migração é protegida. As importações tradicionais com um clique geram, normalmente, uma exportação intermédia em texto em claro, muitas vezes um CSV, que é depois processada por um analisador genérico com conhecimento limitado do ambiente de destino. Cada fase introduz as suas próprias considerações de segurança.

Se algo correr mal a meio de um lote, a recuperação é manual: eliminar ou enviar para a reciclagem o cofre afetado e voltar a executar o script no ambiente de teste (staging). É precisamente por isso que uma execução de teste (dry run) justifica a hora extra antes de uma transição para produção.

Validar o comportamento, e não apenas os registos importados

A importação e a migração são dois pontos de controlo distintos. A importação confirma que as credenciais existem no cofre de destino. A migração confirma que o ambiente se comporta exatamente como previsto quando as cargas de trabalho de produção passam a depender dele.

Uma fase de validação prática deve responder a perguntas como:

• Todos os utilizadores autorizados conseguem aceder aos cofres que se espera que utilizem?
• Os utilizadores não autorizados veem o acesso corretamente negado?
• Os pipelines de CI/CD, a automatização da infraestrutura e as integrações de API obtêm segredos sem modificações?
• As contas de serviço funcionam com as permissões esperadas?
• Os registos de auditoria captam corretamente os eventos de autenticação, as alterações de permissões e as ações administrativas?

Estas verificações revelam muitas vezes problemas que só surgem depois de a importação terminar. Uma credencial migrada pode estar na pasta correta e, ainda assim, continuar inacessível à automatização que dela depende. Um erro na conversão de funções pode conceder silenciosamente um acesso mais amplo do que o pretendido e passar sem problemas na validação da importação.

O registo de atividade do Passwork (eventos como item_imported e vault_imported) fornece aos auditores um rasto documental para precisamente este tipo de verificação, e o Security Dashboard (painel de segurança) assinala as palavras-passe fracas ou duplicadas que vieram do cofre antigo, para que possam ser substituídas em vez de transitarem para o novo ambiente. Vale também a pena rever os registos sem URL: o preenchimento automático não funcionará neles até que alguém corrija o campo.

O êxito de uma migração mede-se pelo comportamento operacional. O sistema de destino deve aplicar o mesmo modelo de segurança que anteriormente, ou um modelo deliberadamente melhorado, e não limitar-se a conter os mesmos segredos.

Transformar a migração do gestor de palavras-passe numa auditoria de segurança

A migração é muitas vezes o único momento em que uma organização revê em simultâneo todas as credenciais armazenadas e todas as permissões.

A administração quotidiana tende a ser incremental: adicionam-se utilizadores, os projetos evoluem, as integrações acumulam-se e os direitos de acesso expandem-se gradualmente. Uma migração interrompe esse processo e obriga cada objeto a justificar o seu lugar no novo ambiente. Por isso, uma migração estruturada funciona frequentemente como a revisão de acessos mais abrangente que uma organização realizou em anos.

Durante esta revisão, as equipas descobrem tipicamente:

• Segredos órfãos pertencentes a colaboradores que saíram há meses
• Credenciais duplicadas do mesmo serviço armazenadas em vários cofres
• Utilizadores inativos que mantêm acesso à produção
• Chaves de API que expiraram mas nunca foram removidas
• Credenciais pessoais armazenadas em cofres da empresa
• Credenciais de sistemas desativados há muito tempo mas nunca eliminadas

Uma importação em massa transporta silenciosamente estes problemas para a nova plataforma. Uma migração baseada em transformação expõe-nos, porque cada credencial, cada proprietário e cada permissão têm de ser avaliados antes de serem recriados.

Verizon, no DBIR de 2026, refere que 27 % das vítimas de ransomware tinham indícios de um infostealer ou de uma fuga de credenciais durante o ano anterior e que, entre essas organizações, metade ficou exposta nos 95 dias anteriores ao incidente de ransomware. A migração é uma das poucas oportunidades para revogar credenciais expostas ou obsoletas antes de passarem a fazer parte de uma cadeia de ataque.

O mesmo relatório refere também que a resolução de palavras-passe fracas e de configurações incorretas de permissões em ambientes cloud de terceiros demora, em média, quase oito meses às organizações. Efetuar essa revisão durante a migração comprime esses oito meses numa atividade de engenharia planeada, em vez de um esforço de correção prolongado.

Ao abrigo do artigo 32.º do RGPD, as organizações têm de aplicar medidas técnicas e organizativas adequadas aos riscos do tratamento de dados pessoais. A remoção de acessos obsoletos e de credenciais órfãs durante a migração demonstra esses controlos na prática, em vez de apenas os documentar.

Sete passos para reduzir o risco da migração antes da produção

O fluxo de migração do Passwork trata a migração como um projeto de engenharia com pontos de controlo explícitos, e não como uma única operação de importação.

1. Inventário

Documente os cofres, as contas de serviço, as integrações, as automatizações e as dependências externas existentes antes de escrever qualquer código de migração.

2. Exportação

Extraia os dados do sistema de origem num formato estruturado. O JSON é, em geral, preferível porque preserva as relações hierárquicas: a exportação JSON do próprio Passwork mantém intactas a estrutura de cofres e pastas, enquanto o CSV reduz tudo a uma tabela.

3. Revisão

Identifique as credenciais obsoletas, duplicadas, órfãs ou com privilégios excessivos antes de serem migradas.

4. Transformação

Implemente regras de migração que mapeiem o ambiente de origem para a hierarquia de destino, o modelo de propriedade, a configuração RBAC e as convenções de nomenclatura.

5. Importação de teste

Execute a migração num ambiente de teste (staging) para verificar se os objetos são criados corretamente antes de tocar na produção. A orientação do próprio Passwork para o script do Bitwarden é explícita neste ponto: fazer uma cópia de segurança da base de dados de destino e executar um teste (dry run) no staging antes de uma transição real.

6. Validação de permissões

Confirme que:

• os utilizadores autorizados têm acesso;
• os utilizadores não autorizados não têm;
• as contas de serviço se autenticam com êxito;
• os pipelines de CI/CD e as integrações continuam a funcionar;
• os registos de auditoria captam os eventos de segurança esperados.

7. Migração para produção

Execute a migração para produção por fases e não de uma só vez: primeiro as credenciais partilhadas de TI e infraestrutura, depois os cofres dos departamentos, uma equipa de cada vez, e por fim os cofres privados, quando os utilizadores estiverem ativados. Mantenha os sistemas antigo e novo em paralelo durante duas a quatro semanas, faça verificações pontuais com o responsável de cada departamento e só desative a plataforma de origem quando a adoção for real, e não presumida.

Saltar qualquer uma das fases de teste ou de validação de permissões não elimina, normalmente, o trabalho. Apenas o adia para o momento em que os utilizadores de produção ou os sistemas automatizados começam a falhar após a transição.

Acertar na migração

As migrações mais fáceis movem palavras-passe. As migrações bem-sucedidas recriam a forma como uma organização funciona: quem é o proprietário de cada credencial, como as permissões são herdadas, que sistemas dependem de segredos partilhados e que caminhos de acesso já não devem existir.

As importações com um clique otimizam a velocidade. As migrações empresariais otimizam a correção, a auditabilidade e um comportamento previsível após a transição. Estes objetivos raramente apontam na mesma direção.

Se há uma ação que vale a pena executar antes de agendar uma migração, é o primeiro passo do fluxo acima: elaborar um inventário rigoroso dos cofres, das contas de serviço, das integrações e do modelo de permissões antes de escrever uma única linha de lógica de migração.

Os melhores scripts de migração documentam cada decisão de migração ao longo do processo. Muito depois da transição, estas regras de transformação passam a ser um registo do motivo pelo qual o acesso foi mapeado de determinada forma, o que facilita significativamente futuras auditorias, a resolução de problemas e novas migrações.

As equipas que migram de outro gestor de palavras-passe obtêm um desconto de 10 % no Passwork. Consultar a documentação para saber como mudar para o Passwork a partir dos gestores de palavras-passe mais populares.

Perguntas frequentes sobre a migração de gestores de palavras-passe

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

A soberania de dados das credenciais exige três controlos (localização, cifragem e acesso), e não apenas conformidade com o RGPD. Compara modelos on-premise, com isolamento físico (air gap) e de cloud na UE, mostrando onde uma arquitetura zero-knowledge como a do Passwork realmente fecha a lacuna de soberania.

PassworkPasswork Team

Políticas de cofre do Passwork: guia do CIO para a segurança empresarial

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

PassworkPasswork Team

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

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

PassworkPasswork Team

„Kann ich mit einem Klick von [Mitbewerber] migrieren?" ist eine der häufigsten Fragen, die Anbieter in Verkaufsgesprächen hören — besonders direkt nachdem eine Sicherheitslücke bei einem Wettbewerber Schlagzeilen macht. Anbieter präsentieren die Ein-Klick-Migration als Komfortfunktion. In Unternehmensumgebungen ist sie nur der Ausgangspunkt.

Eine funktionierende Passwort-Manager-Migration bildet Tresor-Hierarchie, Eigentümerschaft, Berechtigungen, Service-Accounts, Automatisierung und Integrationen nach. Die Qualität dieser Rekonstruktion entscheidet darüber, ob Benutzer, Anwendungen und Infrastruktur nach der Umstellung weiterhin sicher funktionieren.

Der Data Breach Investigations Report 2026 von Verizon ergab, dass 39 % der System-Intrusion-Verstöße gestohlene Anmeldedaten betrafen, während bei 84 % Server involviert waren. Da Passwort-Manager Teil der Infrastruktur-Steuerungsebene werden, wirkt sich die Migrationsgenauigkeit direkt auf die betriebliche Zuverlässigkeit und Sicherheit aus.

Dieser Artikel erklärt, warum Enterprise-Migration ein Engineering-Projekt ist und wie man eines durchführt, ohne dabei den Produktionszugriff zu gefährden.

Migration beginnt mit der Abbildung von Zugriffsmodellen

Kein universelles Import-Tool kann das Zugriffsmodell einer Organisation genau nachbilden, da Sicherheitsmodelle selten zwischen Plattformen übereinstimmen.

Verschiedene Passwort-Manager implementieren rollenbasierte Zugriffskontrolle, Berechtigungsvererbung, Shared-Vault-Eigentümerschaft und Gruppenmitgliedschaft unterschiedlich. Selbst wenn zwei Systeme dieselben Konzepte unterstützen, implementieren sie diese oft mit unterschiedlichen Annahmen.

Betrachten Sie drei Organisationen:

• Unternehmen A organisiert Tresore nach Geschäftsfunktion.
• Unternehmen B organisiert sie nach Produktteams.
• Unternehmen C organisiert sie nach Kunden und Projekten.

Die Hierarchie ist nur der sichtbare Teil des Problems. Die eigentliche Herausforderung besteht darin, Sicherheitssemantiken zwischen Systemen zu übersetzen.

Eine Quellplattform kann Berechtigungen durch verschachtelte Gruppen vererben. Das Zielsystem erfordert möglicherweise stattdessen explizite Zuweisungen. Shared-Vault-Eigentümerschaft hat möglicherweise kein direktes Äquivalent. Eine administrative Rolle kann Privilegien bündeln, die nach der Migration zu mehreren Rollen werden müssen. RBAC-Modelle lassen sich fast nie eins zu eins abbilden.

Passworks eigene Tresor-Typen zeigen, warum. Ein geteilter Unternehmens-Tresor und ein geteilter Benutzer-Tresor haben unterschiedliche Annahmen darüber, wer was sehen kann. Ein Importer muss diese Entscheidung treffen, nicht aus einem Ordnernamen ableiten.

Dieselbe Logik gilt für die Strukturbehandlung. Während des Imports kann ein Admin:

• Die Quellhierarchie unter einem bestehenden Ordner nachbilden
• Alles in ein Ziel einebnen
• Den vollständigen Tresor-Baum im Stammverzeichnis nachbilden

Jede Option ist eine bewusste Entscheidung darüber, wie die Organisation künftig arbeiten möchte — und diese Entscheidung hängt davon ab, wie die Organisation tatsächlich funktioniert.

Ein generischer Importer kopiert Feldwerte. Zu entscheiden, welche Berechtigungen erhalten, übersetzt, zusammengeführt oder entfernt werden sollen, erfordert Urteilsvermögen, das ein Skript nicht hat.

Angreifer zielen zunehmend auf legitimen administrativen Zugriff ab — genau das, was migriert wird: vertrauenswürdige Accounts und die Pfade, die privilegierte Operationen ermöglichen. Eine korrekte Migration stellt sicher, dass diese Pfade nach der Umstellung wie beabsichtigt funktionieren.

Einige Objekte können kopiert werden, andere müssen neu konzipiert werden

Die Migration eines Enterprise-Passwort-Managers formt das Zugriffsmodell einer Organisation über vier verschiedene Ebenen hinweg um: Identitätskontext, Zugriffsrichtlinien, operative Integrationen und Vertrauensgrenzen. Jede Ebene führt technische Einschränkungen ein, die eine flache Importdatei nicht darstellen kann.

Die Lücke zwischen kopiert und neu konzipiert zeigt sich deutlich in echten Migrations-Tools. Passworks offizieller Bitwarden-Importer beispielsweise verschiebt Login-Elemente, sichere Notizen, Sammlungen, Ordnerstruktur, URLs und TOTP-Codes automatisch. Er überspringt bewusst Anhänge und jeden Elementtyp, den er nicht erkennt, und protokolliert jeden Überspringvorgang, anstatt eine Zuordnung zu erraten. Das ist eine Designentscheidung, keine Einschränkung: Einige Objekte können sicher kopiert werden, und bei einigen muss ein Mensch entscheiden, was mit ihnen passiert.

Service-Accounts ohne klare Eigentümer, vererbte Berechtigungen, veraltete Integrationen und längst vergessene geteilte Tresore fallen in die zweite Kategorie. Eine erfolgreiche Migration behält nur das bei, was noch dem beabsichtigten Zugriffsmodell der Organisation entspricht.

Jede dieser Komponenten, die falsch behandelt wird, erzeugt eine Lücke: eine verwaiste Integration, ein Auftragnehmer mit weiterhin bestehendem Produktionszugriff oder ein Automatisierungs-Account, der sich gegen das falsche Ziel authentifiziert. Nichts davon erscheint als Importfehler. Sie tauchen gewöhnlich Wochen später als Vorfälle auf.

Das richtige Denkmodell für Migration — und wie Passwork es anwendet

Sobald Migration als architektonische Transformation behandelt wird, folgt die Implementierung natürlich denselben Engineering-Prinzipien, die auch anderswo in Infrastrukturprojekten verwendet werden: jeden Schritt explizit, überprüfbar und reproduzierbar machen.

Anstatt sich auf einen Black-Box-Importer zu verlassen, der die Struktur einer Organisation interpretiert, sollte der Migrationsprozess jede Transformation als Code offenlegen. Ingenieure sollten exportierte Daten inspizieren, definieren können, wie sie übersetzt werden, und genau kontrollieren, wie jedes Objekt im Zielsystem neu erstellt wird.

Passwork unterstützt drei Migrationspfade, ausgewählt nach Quelle und Volumen statt nach Bequemlichkeit:

Die ersten beiden decken die meisten realen Umzüge ab. Der dritte macht das Prinzip „Transformation als Code" sichtbar. Ein auf Passworks Python-Connector aufgebautes Migrationsskript authentifiziert sich, erstellt die Ziel-Tresor- und Ordnerstruktur explizit und schreibt jedes Element mit genau den Feldern, die die Organisation erhalten möchte:

from passwork_client import PassworkClient

passwork = PassworkClient("https://passwork.example.com")
passwork.set_tokens(access_token, refresh_token)
passwork.set_master_key(master_key)

vault_type = passwork.find_vault_type(code="company")
vault_id = passwork.create_vault("Migrated – IT", vault_type["id"])
vault = passwork.get_vault(vault_id)

folder = passwork.call("POST", "/api/v1/folders", {
    "name": "Databases",
    "vaultId": vault["id"],
})

passwork.create_item({
    "name": "Postgres primary",
    "login": "app_rw",
    "password": "...",
    "urls": ["https://db.internal"],
    "description": "Imported from Bitwarden",
    "vaultId": vault["id"],
    "folderId": folder["id"],
    "customs": [
        {"name": "TOTP", "value": "otpauth://...", "type": "totp"},
    ],
})

Nichts landet in einem Tresor, einem Ordner oder einer Berechtigungsgruppe, es sei denn, das Skript sagt es. Für einen vollständigen Passwork-zu-Passwork-Umzug skaliert dieselbe Logik auf Bulk-REST-Endpunkte — vaults/import, folders/import und items/import — die eine sourceId → id-Zuordnung zurückgeben, sodass übergeordnete Objekte vor ihren untergeordneten erstellt werden und jede Beziehung intakt bleibt.

Die Transformationsphase ist der Punkt, an dem Migration vorhersehbar wird. Ingenieure können Migrationsregeln explizit kodieren: Tresore umbenennen, Eigentümer neu zuordnen, administrative Rollen aufteilen, vererbte Berechtigungen einebnen oder veraltete Einträge vollständig ausschließen. Diese Entscheidungen werden zu überprüfbarem Code statt zu Annahmen, die in einem generischen Import-Assistenten versteckt sind. Wenn die Migration später wiederholt oder auditiert werden muss, bleibt die Transformationslogik transparent und reproduzierbar.

Dies ändert auch, wie die Migration selbst abgesichert wird. Traditionelle Ein-Klick-Importe erzeugen typischerweise einen Klartext-Zwischenexport, oft eine CSV, die dann von einem generischen Parser mit begrenztem Verständnis der Zielumgebung verarbeitet wird. Jede Phase bringt ihre eigenen Sicherheitsüberlegungen mit sich.

Wenn mitten im Batch etwas schiefgeht, ist die Wiederherstellung manuell: den betroffenen Tresor löschen oder in den Papierkorb verschieben, dann das Skript erneut gegen Staging ausführen. Das ist genau der Grund, warum ein Probelauf die zusätzliche Stunde vor einer Produktionsumstellung wert ist.

Validieren Sie das Verhalten, nicht nur importierte Datensätze

Import und Migration markieren zwei getrennte Prüfpunkte. Der Import bestätigt, dass Anmeldedaten im Ziel-Tresor vorhanden sind. Die Migration bestätigt, dass die Umgebung sich genau wie beabsichtigt verhält, sobald Produktions-Workloads davon abhängen.

Eine praktische Validierungsphase sollte Fragen beantworten wie:

• Kann jeder autorisierte Benutzer auf die Tresore zugreifen, die er verwenden soll?
• Wird nicht autorisierten Benutzern der Zugriff korrekt verweigert?
• Rufen CI/CD-Pipelines, Infrastruktur-Automatisierung und API-Integrationen Secrets ohne Änderung ab?
• Funktionieren Service-Accounts mit den erwarteten Berechtigungen?
• Zeichnen Audit-Logs Authentifizierungsereignisse, Berechtigungsänderungen und administrative Aktionen korrekt auf?

Diese Prüfungen decken oft Probleme auf, die erst nach Abschluss des Imports auftreten. Eine migrierte Anmeldedaten kann sich im richtigen Ordner befinden, während sie für die Automatisierung, die davon abhängt, unzugänglich bleibt. Ein Rollenübersetzungsfehler kann stillschweigend breiteren Zugriff als beabsichtigt gewähren und dabei die Importvalidierung sauber bestehen.

Passworks Aktivitätsprotokoll (Ereignisse wie item_imported und vault_imported) gibt Auditoren einen Prüfpfad für genau diese Art von Prüfung, und das Sicherheits-Dashboard markiert schwache oder doppelte Passwörter, die aus dem alten Tresor mitgekommen sind, damit sie rotiert werden können, anstatt weitergetragen zu werden. Einträge ohne URL sind ebenfalls einen zweiten Durchgang wert: Auto-Ausfüllen funktioniert bei ihnen nicht, bis jemand das Feld korrigiert.

Erfolgreiche Migration wird am operativen Verhalten gemessen. Das Zielsystem sollte dasselbe Sicherheitsmodell wie zuvor durchsetzen oder ein bewusst verbessertes — nicht lediglich dieselben Secrets enthalten.

Passwort-Manager-Migration in ein Sicherheits-Audit verwandeln

Migration ist oft der einzige Moment, in dem eine Organisation jede gespeicherte Anmeldedaten und jede Berechtigung gleichzeitig überprüft.

Die alltägliche Administration ist tendenziell inkrementell: Benutzer werden hinzugefügt, Projekte entwickeln sich, Integrationen sammeln sich an und Zugriffsrechte erweitern sich schrittweise. Eine Migration unterbricht diesen Prozess und zwingt jedes Objekt, seinen Platz in der neuen Umgebung zu rechtfertigen. Deshalb dient eine strukturierte Migration oft gleichzeitig als die umfassendste Zugriffsprüfung, die eine Organisation seit Jahren durchgeführt hat.

Während dieser Überprüfung entdecken Teams typischerweise:

• Verwaiste Secrets, die Mitarbeitern gehören, die vor Monaten ausgeschieden sind
• Doppelte Anmeldedaten für denselben Dienst, die in mehreren Tresoren gespeichert sind
• Inaktive Benutzer, die immer noch Produktionszugriff haben
• API-Schlüssel, die abgelaufen sind, aber nie entfernt wurden
• Persönliche Anmeldedaten, die in Unternehmens-Tresoren gespeichert sind
• Anmeldedaten für Systeme, die längst außer Betrieb genommen, aber nie gelöscht wurden

Ein Bulk-Import trägt diese Probleme stillschweigend in die neue Plattform. Eine transformationsbasierte Migration legt sie offen, weil jede Anmeldedaten, jeder Eigentümer und jede Berechtigung bewertet werden muss, bevor sie neu erstellt wird.

Der DBIR 2026 von Verizon berichtet, dass 27 % der Ransomware-Opfer im Vorjahr Hinweise auf einen Infostealer oder ein Credential-Leak hatten, und unter diesen Organisationen waren die Hälfte innerhalb von 95 Tagen vor dem Ransomware-Vorfall exponiert. Migration ist eine der wenigen Gelegenheiten, exponierte oder veraltete Anmeldedaten zu widerrufen, bevor sie Teil einer Angriffskette werden.

Derselbe Bericht stellt auch fest, dass die Behebung schwacher Passwörter und Berechtigungsfehlkonfigurationen in Cloud-Umgebungen von Drittanbietern Organisationen durchschnittlich fast acht Monate kostet. Diese Überprüfung während der Migration durchzuführen, komprimiert diese acht Monate in eine geplante Engineering-Aktivität anstelle einer langwierigen Behebungsarbeit.

Gemäß DSGVO Artikel 32 müssen Organisationen technische und organisatorische Maßnahmen implementieren, die den Risiken der Verarbeitung personenbezogener Daten angemessen sind. Das Entfernen veralteter Zugriffsrechte und verwaister Anmeldedaten während der Migration demonstriert diese Kontrollen in der Praxis, anstatt sie nur zu dokumentieren.

Sieben Schritte, die das Migrationsrisiko vor der Produktion reduzieren

Der Passwork-Migrations-Workflow behandelt Migration als Engineering-Projekt mit expliziten Prüfpunkten statt als einzelne Importoperation.

1. Inventarisierung

Dokumentieren Sie bestehende Tresore, Service-Accounts, Integrationen, Automatisierung und externe Abhängigkeiten, bevor Sie Migrationscode schreiben.

2. Export

Extrahieren Sie Daten aus dem Quellsystem in einem strukturierten Format. JSON ist im Allgemeinen vorzuziehen, da es hierarchische Beziehungen bewahrt — Passworks eigener JSON-Export erhält die Tresor- und Ordnerstruktur, während CSV alles in eine Tabelle einebnet.

3. Überprüfung

Identifizieren Sie veraltete, doppelte, verwaiste oder überprivilegierte Anmeldedaten, bevor sie migriert werden.

4. Transformation

Implementieren Sie Migrationsregeln, die die Quellumgebung auf die Zielhierarchie, das Eigentümermodell, die RBAC-Konfiguration und die Namenskonventionen abbilden.

5. Testimport

Führen Sie die Migration gegen eine Staging-Umgebung aus, um zu verifizieren, dass Objekte korrekt erstellt werden, bevor Sie die Produktion berühren. Passworks eigene Anleitung für das Bitwarden-Skript ist in diesem Punkt explizit: Sichern Sie die Zieldatenbank und führen Sie einen Probelauf in Staging durch, bevor Sie eine echte Umstellung vornehmen.

6. Berechtigungen validieren

Bestätigen Sie, dass:

• autorisierte Benutzer Zugang haben;
• nicht autorisierte Benutzer keinen haben;
• Service-Accounts sich erfolgreich authentifizieren;
• CI/CD-Pipelines und Integrationen weiterhin funktionieren;
• Audit-Logs erwartete Sicherheitsereignisse erfassen.

7. Produktionsmigration

Führen Sie die Produktionsmigration in Phasen statt in einem Durchgang durch — zuerst geteilte IT- und Infrastruktur-Anmeldedaten, dann Abteilungs-Tresore Team für Team, dann private Tresore, sobald Benutzer aktiviert sind. Betreiben Sie die alten und neuen Systeme zwei bis vier Wochen parallel, führen Sie Stichprobenprüfungen mit jedem Abteilungsleiter durch und nehmen Sie das Quellsystem erst außer Betrieb, wenn die Akzeptanz real ist, nicht angenommen.

Das Überspringen der Test- oder Berechtigungsvalidierungsphasen eliminiert die Arbeit normalerweise nicht. Es verschiebt sie, bis Produktionsbenutzer oder automatisierte Systeme nach der Umstellung zu versagen beginnen.

Migration richtig durchführen

Die einfachsten Migrationen verschieben Passwörter. Erfolgreiche Migrationen bilden nach, wie eine Organisation arbeitet: wer jede Anmeldedaten besitzt, wie Berechtigungen vererbt werden, welche Systeme von geteilten Secrets abhängen und welche Zugriffspfade nicht mehr existieren sollten.

Ein-Klick-Importe optimieren auf Geschwindigkeit. Enterprise-Migrationen optimieren auf Korrektheit, Prüfbarkeit und vorhersehbares Verhalten nach der Umstellung. Diese Ziele weisen selten in dieselbe Richtung.

Wenn es eine Aktion gibt, die sich vor der Planung einer Migration lohnt, dann ist es der erste Schritt im obigen Workflow: Erstellen Sie eine genaue Inventur Ihrer Tresore, Service-Accounts, Integrationen und Ihres Berechtigungsmodells, bevor Sie eine einzige Zeile Migrationslogik schreiben.

Die besten Migrationsskripte dokumentieren jede Migrationsentscheidung unterwegs. Lange nach der Umstellung werden diese Transformationsregeln zu einer Aufzeichnung darüber, warum der Zugriff so abgebildet wurde, wie er war — was zukünftige Audits, Fehlerbehebung und wiederholte Migrationen erheblich erleichtert.

Teams, die von einem anderen Passwort-Manager migrieren, erhalten 10 % Rabatt auf Passwork. Lesen Sie die Dokumentation, um zu erfahren, wie Sie von gängigen Passwort-Managern zu Passwork wechseln.

FAQ zur Passwort-Manager-Migration

Datensouveränität und Passwortverwaltung: Anmeldedaten dort behalten, wo sie hingehören

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

PassworkPasswork Team

Passworks Tresor-Richtlinien: Ein CIO-Leitfaden zur Enterprise-Sicherheit

Passworks Tresor-Typen binden Admin-Rechte an die Tresor-Richtlinie selbst, nicht an denjenigen, der 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 Tresor-Governance, abgebildet auf NIS2- und ISO 27001-Anforderungen.

PassworkPasswork Team

Passwork 7.7: Sicherer Offline-Modus für Desktop- und Mobile-Apps

Passwörter funktionieren jetzt auch offline. Passwork 7.7 bringt sicheren Offline-Zugriff mit voller Admin-Aufsicht, organisationsweite Dateianhang-Kontrollen und fünf neue rollenbasierte Onboarding-Leitfäden für eine reibungslosere Einführung.

PassworkPasswork Team

«¿Puedo migrar desde [competidor] con un solo clic?» es una de las preguntas más frecuentes que escuchan los proveedores en las llamadas comerciales, especialmente justo después de que una brecha de un competidor se convierte en noticia. Los proveedores presentan la migración con un clic como una función de conveniencia. En entornos empresariales, es solo el punto de partida.

Una migración de gestor de contraseñas funcional recrea la jerarquía de bóvedas, la propiedad, los permisos, las cuentas de servicio, la automatización y las integraciones. La calidad de esa reconstrucción determina si los usuarios, las aplicaciones y la infraestructura continúan operando de forma segura después del cambio.

El Informe de Investigaciones de Brechas de Datos 2026 de Verizon encontró que el 39% de las brechas por intrusión en sistemas involucraron credenciales robadas, mientras que el 84% involucraron servidores. A medida que los gestores de contraseñas se convierten en parte del plano de control de la infraestructura, la precisión de la migración afecta directamente la fiabilidad operativa y la seguridad.

Este artículo explica por qué la migración empresarial es un proyecto de ingeniería y cómo ejecutar uno sin interrumpir el acceso de producción en el camino.

La migración comienza con el mapeo de modelos de acceso

Ninguna herramienta de importación universal puede recrear con precisión el modelo de acceso de una organización, porque los modelos de seguridad rara vez coinciden entre plataformas.

Los diferentes gestores de contraseñas implementan el control de acceso basado en roles, la herencia de permisos, la propiedad de bóvedas compartidas y la membresía de grupos de manera diferente. Incluso cuando dos sistemas admiten los mismos conceptos, a menudo los implementan con diferentes supuestos.

Considere tres organizaciones:

• La empresa A organiza las bóvedas por función de negocio.
• La empresa B las organiza por equipos de producto.
• La empresa C las organiza por clientes y proyectos.

La jerarquía es solo la parte visible del problema. El verdadero desafío es traducir la semántica de seguridad entre sistemas.

Una plataforma de origen puede heredar permisos a través de grupos anidados. El destino puede requerir asignaciones explícitas en su lugar. La propiedad de bóvedas compartidas podría no tener un equivalente directo. Un rol administrativo puede agrupar privilegios que deben convertirse en múltiples roles después de la migración. Los modelos RBAC casi nunca se corresponden uno a uno.

Los propios tipos de bóveda de Passwork muestran por qué. Una bóveda compartida de empresa y una bóveda compartida de usuario conllevan diferentes supuestos sobre quién puede ver qué. Un importador tiene que tomar esa decisión, no inferirla de un nombre de carpeta.

La misma lógica aplica al manejo de la estructura. Durante la importación, un administrador puede:

• Reconstruir la jerarquía de origen bajo una carpeta existente
• Aplanar todo en un solo destino
• Recrear el árbol completo de bóvedas en la raíz

Cada opción es una elección deliberada sobre cómo la organización quiere operar en adelante, y esa elección depende de cómo funciona realmente la organización.

Un importador genérico copia valores de campos. Decidir qué permisos preservar, traducir, fusionar o eliminar requiere un juicio que un script no tiene.

Los atacantes se dirigen cada vez más al acceso administrativo legítimo, exactamente lo que se está migrando: cuentas de confianza y las rutas que hacen funcionar las operaciones privilegiadas. Una migración correcta mantiene esas rutas comportándose como se pretendía después del cambio.

Algunos objetos pueden copiarse, otros deben rediseñarse

La migración de un gestor de contraseñas empresarial remodela el modelo de acceso de una organización a través de cuatro capas distintas: contexto de identidad, políticas de acceso, integraciones operativas y límites de confianza. Cada capa introduce restricciones técnicas que un archivo de importación plano no puede representar.

La brecha entre copiado y rediseñado se muestra claramente en las herramientas de migración reales. El importador oficial de Bitwarden de Passwork, por ejemplo, mueve elementos de inicio de sesión, notas seguras, colecciones, estructura de carpetas, URLs y códigos TOTP automáticamente. Deliberadamente omite los archivos adjuntos y cualquier tipo de elemento que no reconozca, registrando cada omisión en lugar de adivinar un mapeo. Esa es una decisión de diseño, no una limitación: algunos objetos pueden copiarse de forma segura, y algunos necesitan que un humano decida qué sucede con ellos.

Las cuentas de servicio sin propietarios claros, los permisos heredados, las integraciones obsoletas y las bóvedas compartidas olvidadas hace tiempo caen en la segunda categoría. Una migración exitosa preserva solo lo que aún refleja el modelo de acceso previsto de la organización.

Cualquiera de estos manejados incorrectamente crea una brecha: una integración huérfana, un contratista que retiene acceso de producción, o una cuenta de automatización autenticándose contra el destino incorrecto. Ninguno de estos aparece como errores de importación. Usualmente emergen semanas después como incidentes.

El modelo mental correcto para la migración, y cómo lo aplica Passwork

Una vez que la migración se trata como una transformación arquitectónica, la implementación sigue naturalmente los mismos principios de ingeniería utilizados en otros proyectos de infraestructura: hacer cada paso explícito, revisable y reproducible.

En lugar de depender de un importador de caja negra para interpretar la estructura de una organización, el proceso de migración debe exponer cada transformación como código. Los ingenieros deben poder inspeccionar los datos exportados, definir cómo se traducen y controlar exactamente cómo se recrea cada objeto en el sistema de destino.

Passwork admite tres rutas de migración, elegidas por origen y volumen en lugar de por conveniencia:

Las dos primeras cubren la mayoría de las migraciones del mundo real. La tercera hace visible el principio de «transformación como código». Un script de migración construido sobre el conector Python de Passwork se autentica, crea la bóveda de destino y la estructura de carpetas explícitamente, y escribe cada elemento con exactamente los campos que la organización quiere preservar:

from passwork_client import PassworkClient

passwork = PassworkClient("https://passwork.example.com")
passwork.set_tokens(access_token, refresh_token)
passwork.set_master_key(master_key)

vault_type = passwork.find_vault_type(code="company")
vault_id = passwork.create_vault("Migrated – IT", vault_type["id"])
vault = passwork.get_vault(vault_id)

folder = passwork.call("POST", "/api/v1/folders", {
    "name": "Databases",
    "vaultId": vault["id"],
})

passwork.create_item({
    "name": "Postgres primary",
    "login": "app_rw",
    "password": "...",
    "urls": ["https://db.internal"],
    "description": "Imported from Bitwarden",
    "vaultId": vault["id"],
    "folderId": folder["id"],
    "customs": [
        {"name": "TOTP", "value": "otpauth://...", "type": "totp"},
    ],
})

Nada llega a una bóveda, una carpeta o un conjunto de permisos a menos que el script lo indique. Para una migración completa de Passwork a Passwork, la misma lógica se escala a endpoints REST masivos — vaults/import, folders/import, e items/import — que devuelven un mapa sourceId → id para que los objetos padre se creen antes que sus hijos y cada relación permanezca intacta.

La etapa de transformación es donde la migración se vuelve predecible. Los ingenieros pueden codificar reglas de migración explícitamente: renombrar bóvedas, reasignar propietarios, dividir roles administrativos, aplanar permisos heredados o excluir registros obsoletos por completo. Esas decisiones se convierten en código revisable en lugar de suposiciones ocultas dentro de un asistente de importación genérico. Si la migración necesita repetirse o auditarse más tarde, la lógica de transformación permanece transparente y reproducible.

Esto también cambia cómo se asegura la propia migración. Las importaciones tradicionales de un clic típicamente generan una exportación intermedia en texto plano, a menudo un CSV, que luego es procesada por un analizador genérico con comprensión limitada del entorno de destino. Cada etapa introduce sus propias consideraciones de seguridad.

Si algo sale mal a mitad del lote, la recuperación es manual: eliminar o enviar a la papelera la bóveda afectada, luego volver a ejecutar el script contra staging. Por eso exactamente una prueba en seco vale la hora extra antes de un cambio a producción.

Valide el comportamiento, no solo los registros importados

La importación y la migración marcan dos puntos de control separados. La importación confirma que las credenciales existen en la bóveda de destino. La migración confirma que el entorno se comporta exactamente como se pretende una vez que las cargas de trabajo de producción dependen de él.

Una fase de validación práctica debe responder preguntas como:

• ¿Puede cada usuario autorizado acceder a las bóvedas que se espera que utilice?
• ¿Se deniega correctamente el acceso a los usuarios no autorizados?
• ¿Los pipelines de CI/CD, la automatización de infraestructura y las integraciones de API recuperan secretos sin modificación?
• ¿Las cuentas de servicio funcionan con los permisos esperados?
• ¿Los registros de auditoría registran correctamente los eventos de autenticación, los cambios de permisos y las acciones administrativas?

Estas comprobaciones a menudo revelan problemas que aparecen solo después de que la importación se completa. Una credencial migrada puede estar en la carpeta correcta mientras permanece inaccesible para la automatización que depende de ella. Un error de traducción de roles puede otorgar silenciosamente un acceso más amplio de lo previsto, pasando la validación de importación sin problemas.

El registro de actividad de Passwork (eventos como item_imported y vault_imported) proporciona a los auditores un rastro documental para exactamente este tipo de verificación, y el Panel de Seguridad señala contraseñas débiles o duplicadas que vinieron junto con la migración desde la bóveda antigua, para que puedan rotarse en lugar de trasladarse. Los registros que carecen de una URL también merecen una segunda revisión: el autocompletado no funcionará en ellos hasta que alguien corrija el campo.

El éxito de la migración se mide por el comportamiento operativo. El sistema de destino debe aplicar el mismo modelo de seguridad que antes, o uno deliberadamente mejorado, en lugar de simplemente contener los mismos secretos.

Convertir la migración del gestor de contraseñas en una auditoría de seguridad

La migración es a menudo el único momento en que una organización revisa cada credencial almacenada y cada permiso al mismo tiempo.

La administración del día a día tiende a ser incremental: se añaden usuarios, los proyectos evolucionan, las integraciones se acumulan y los derechos de acceso se expanden gradualmente. Una migración interrumpe ese proceso y obliga a cada objeto a justificar su lugar en el nuevo entorno. Por eso una migración estructurada a menudo sirve como la revisión de acceso más completa que una organización ha realizado en años.

Durante esta revisión, los equipos típicamente descubren:

• Secretos huérfanos que pertenecen a empleados que se fueron hace meses
• Credenciales duplicadas para el mismo servicio almacenadas en múltiples bóvedas
• Usuarios inactivos que aún tienen acceso de producción
• Claves API que expiraron pero nunca se eliminaron
• Credenciales personales almacenadas dentro de bóvedas corporativas
• Credenciales para sistemas dados de baja hace tiempo pero nunca eliminadas

Una importación masiva traslada silenciosamente estos problemas a la nueva plataforma. Una migración basada en transformación los expone, porque cada credencial, propietario y permiso debe evaluarse antes de recrearse.

El DBIR 2026 de Verizon informa que el 27% de las víctimas de ransomware tenían evidencia de un infostealer o filtración de credenciales durante el año anterior, y entre esas organizaciones, la mitad estuvo expuesta dentro de los 95 días antes de que ocurriera el incidente de ransomware. La migración es una de las pocas oportunidades para revocar credenciales expuestas u obsoletas antes de que se conviertan en parte de una cadena de ataque.

El mismo informe también señala que resolver contraseñas débiles y configuraciones incorrectas de permisos en entornos de nube de terceros toma a las organizaciones casi ocho meses en promedio. Hacer esa revisión durante la migración comprime esos ocho meses en una actividad de ingeniería planificada en lugar de un esfuerzo de remediación prolongado.

Bajo el Artículo 32 del RGPD, las organizaciones deben implementar medidas técnicas y organizativas apropiadas para los riesgos del procesamiento de datos personales. Eliminar accesos obsoletos y credenciales huérfanas durante la migración demuestra esos controles en la práctica en lugar de simplemente documentarlos.

Siete pasos que reducen el riesgo de migración antes de producción

El flujo de trabajo de migración de Passwork trata la migración como un proyecto de ingeniería con puntos de control explícitos en lugar de una sola operación de importación.

1. Inventario

Documente las bóvedas existentes, cuentas de servicio, integraciones, automatización y dependencias externas antes de escribir cualquier código de migración.

2. Exportación

Extraiga datos del sistema de origen en un formato estructurado. JSON es generalmente preferible porque preserva las relaciones jerárquicas — la propia exportación JSON de Passwork mantiene intacta la estructura de bóvedas y carpetas, mientras que CSV aplana todo en una tabla.

3. Revisión

Identifique credenciales obsoletas, duplicadas, huérfanas o con privilegios excesivos antes de migrarlas.

4. Transformación

Implemente reglas de migración que mapeen el entorno de origen a la jerarquía de destino, modelo de propiedad, configuración RBAC y convenciones de nomenclatura.

5. Importación de prueba

Ejecute la migración contra un entorno de staging para verificar que los objetos se crean correctamente antes de tocar producción. La propia guía de Passwork para el script de Bitwarden es explícita en este punto: haga una copia de seguridad de la base de datos de destino y ejecute una prueba en seco en staging antes de un cambio real.

6. Validación de permisos

Confirme que:

• los usuarios autorizados tienen acceso;
• los usuarios no autorizados no lo tienen;
• las cuentas de servicio se autentican correctamente;
• los pipelines de CI/CD y las integraciones continúan funcionando;
• los registros de auditoría capturan los eventos de seguridad esperados.

7. Migración a producción

Ejecute la migración a producción en fases en lugar de un solo barrido — primero las credenciales compartidas de TI e infraestructura, luego las bóvedas de departamento un equipo a la vez, luego las bóvedas privadas una vez que los usuarios estén activados. Ejecute los sistemas antiguo y nuevo en paralelo durante dos a cuatro semanas, verifique con cada propietario de departamento, y solo dé de baja la plataforma de origen una vez que la adopción sea real, no asumida.

Omitir las etapas de prueba o validación de permisos usualmente no elimina el trabajo. Lo pospone hasta que los usuarios de producción o los sistemas automatizados comiencen a fallar después del cambio.

Hacer la migración correctamente

Las migraciones más fáciles mueven contraseñas. Las migraciones exitosas recrean cómo opera una organización: quién es propietario de cada credencial, cómo se heredan los permisos, qué sistemas dependen de secretos compartidos y qué rutas de acceso ya no deberían existir.

Las importaciones de un clic optimizan la velocidad. Las migraciones empresariales optimizan la corrección, la auditabilidad y el comportamiento predecible después del cambio. Esos objetivos rara vez apuntan en la misma dirección.

Si hay una acción que vale la pena tomar antes de programar una migración, es el primer paso en el flujo de trabajo anterior: construir un inventario preciso de sus bóvedas, cuentas de servicio, integraciones y modelo de permisos antes de escribir una sola línea de lógica de migración.

Los mejores scripts de migración documentan cada decisión de migración en el camino. Mucho después del cambio, esas reglas de transformación se convierten en un registro de por qué el acceso se mapeó de la manera en que lo hizo — haciendo las auditorías futuras, la resolución de problemas y las migraciones repetidas significativamente más fáciles.

Los equipos que migran desde otro gestor de contraseñas obtienen un 10% de descuento en Passwork. Consulte la documentación para ver cómo cambiar a Passwork desde gestores de contraseñas populares.

Preguntas frecuentes sobre migración de gestores de contraseñas

Soberanía de datos y gestión de contraseñas: Manteniendo las credenciales donde pertenecen

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

PassworkPasswork Team

Políticas de bóveda de Passwork: Guía para CIOs sobre seguridad empresarial

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

PassworkPasswork Team

Passwork 7.7: Modo sin conexión seguro para aplicaciones de escritorio y móviles

Las contraseñas ahora también funcionan sin conexión. Passwork 7.7 trae acceso sin conexión seguro con supervisión completa del administrador, controles de archivos adjuntos a nivel de organización y cinco nuevas guías de incorporación basadas en roles para un despliegue más fluido.

PassworkPasswork Team

"Can I migrate from [competitor] in one click?" is one of the most common questions vendors hear on sales calls, especially right after a competitor's breach makes headlines. Vendors present one-click migration as a convenience feature. In enterprise environments, it's only the starting point.

A working password manager migration recreates vault hierarchy, ownership, permissions, service accounts, automation, and integrations. The quality of that reconstruction decides whether users, applications, and infrastructure keep operating securely after cutover.

Verizon's 2026 Data Breach Investigations Report found that 39% of System Intrusion breaches involved stolen credentials, while 84% involved servers. As password managers become part of the infrastructure control plane, migration accuracy directly affects operational reliability and security.

This article explains why enterprise migration is an engineering project and how to run one without breaking production access on the way.

Migration starts with mapping access models

No universal import tool can accurately recreate an organization's access model, because security models rarely match between platforms.

Different password managers implement role-based access control, permission inheritance, shared vault ownership, and group membership differently. Even when two systems support the same concepts, they often implement them with different assumptions.

Consider three organizations:

• Company A organizes vaults by business function.
• Company B organizes them by product teams.
• Company C organizes them by customers and projects.

Hierarchy is only the visible part of the problem. The real challenge is translating security semantics between systems.

A source platform may inherit permissions through nested groups. The destination may require explicit assignments instead. Shared vault ownership might have no direct equivalent. An administrative role may bundle privileges that need to become multiple roles after migration. RBAC models almost never map one-to-one.

Passwork's own vault types show why. A shared company vault and a shared user vault carry different assumptions about who can see what. An importer has to make that call, not infer it from a folder name.

The same logic applies to structure handling. During import, an admin can:

• Rebuild the source hierarchy under an existing folder
• Flatten everything into one destination
• Recreate the full vault tree at the root

Each option is a deliberate choice about how the organization wants to operate going forward, and that choice depends on how the organization actually works.

A generic importer copies field values. Deciding which permissions to preserve, translate, merge, or drop requires judgment a script doesn't have.

Attackers increasingly target legitimate administrative access, exactly what's being migrated: trusted accounts and the paths that make privileged operations work. A correct migration keeps those paths behaving as intended after cutover.

Some objects can be copied, others must be redesigned

Enterprise password manager migration reshapes an organization's access model across four distinct layers: identity context, access policies, operational integrations, and trust boundaries. Each layer introduces technical constraints that a flat import file cannot represent.

The gap between copied and redesigned shows up clearly in real migration tooling. Passwork's official Bitwarden importer, for example, moves login items, secure notes, collections, folder structure, URLs, and TOTP codes automatically. It deliberately skips attachments and any item type it doesn't recognize, logging each skip instead of guessing at a mapping. That's a design decision, not a limitation: some objects can be copied safely, and some need a human to decide what happens to them.

Service accounts without clear owners, inherited permissions, obsolete integrations, and long-forgotten shared vaults fall into the second category. A successful migration preserves only what still reflects the organization's intended access model.

Any one of these handled incorrectly creates a gap: an orphaned integration, a contractor retaining production access, or an automation account authenticating against the wrong destination. None of these appear as import errors. They usually surface weeks later as incidents.

The right mental model for migration, and how Passwork applies it

Once migration is treated as an architectural transformation, the implementation naturally follows the same engineering principles used elsewhere in infrastructure projects: make every step explicit, reviewable, and reproducible.

Rather than relying on a black-box importer to interpret an organization's structure, the migration process should expose every transformation as code. Engineers should be able to inspect exported data, define how it is translated, and control exactly how every object is recreated in the destination system.

Passwork supports three migration paths, chosen by source and volume rather than by convenience:

The first two cover most real-world moves. The third makes the "transformation as code" principle visible. A migration script built on Passwork's Python connector authenticates, creates the destination vault and folder structure explicitly, and writes each item with exactly the fields the organization wants preserved:

from passwork_client import PassworkClient

passwork = PassworkClient("https://passwork.example.com")
passwork.set_tokens(access_token, refresh_token)
passwork.set_master_key(master_key)

vault_type = passwork.find_vault_type(code="company")
vault_id = passwork.create_vault("Migrated – IT", vault_type["id"])
vault = passwork.get_vault(vault_id)

folder = passwork.call("POST", "/api/v1/folders", {
    "name": "Databases",
    "vaultId": vault["id"],
})

passwork.create_item({
    "name": "Postgres primary",
    "login": "app_rw",
    "password": "...",
    "urls": ["https://db.internal"],
    "description": "Imported from Bitwarden",
    "vaultId": vault["id"],
    "folderId": folder["id"],
    "customs": [
        {"name": "TOTP", "value": "otpauth://...", "type": "totp"},
    ],
})

Nothing lands in a vault, a folder, or a permission set unless the script says so. For a full Passwork-to-Passwork move, the same logic scales to bulk REST endpoints — vaults/import, folders/import, and items/import — which return a sourceId → id map so parent objects are created before their children and every relationship stays intact.

The transformation stage is where migration becomes predictable. Engineers can encode migration rules explicitly: rename vaults, remap owners, split administrative roles, flatten inherited permissions, or exclude obsolete records altogether. Those decisions become reviewable code rather than assumptions hidden inside a generic import wizard. If the migration needs to be repeated or audited later, the transformation logic stays transparent and reproducible.

This also changes how the migration itself is secured. Traditional one-click imports typically generate an intermediate plaintext export, often a CSV, that is then processed by a generic parser with limited understanding of the destination environment. Each stage introduces its own security considerations.

If something goes wrong mid-batch, recovery is manual: delete or bin the affected vault, then re-run the script against staging. That's exactly why a dry run is worth the extra hour before a production cutover.

Validate behavior, not just imported records

Import and migration mark two separate checkpoints. Import confirms that credentials exist in the destination vault. Migration confirms that the environment behaves exactly as intended once production workloads depend on it.

A practical validation phase should answer questions such as:

• Can every authorized user access the vaults they're expected to use?
• Are unauthorized users correctly denied access?
• Do CI/CD pipelines, infrastructure automation, and API integrations retrieve secrets without modification?
• Are service accounts functioning with the expected permissions?
• Do audit logs record authentication events, permission changes, and administrative actions correctly?

These checks often surface issues that appear only after import completes. A migrated credential may sit in the correct folder while remaining inaccessible to the automation that depends on it. A role translation error may silently grant broader access than intended, passing import validation cleanly.

Passwork's activity log (events like item_imported and vault_imported) gives auditors a paper trail for exactly this kind of check, and the Security Dashboard flags weak or duplicate passwords that came along for the ride from the old vault, so they can be rotated rather than carried forward. Records missing a URL are worth a second pass too: autofill won't work on them until someone fixes the field.

Successful migration is measured by operational behavior. The destination system should enforce the same security model as before, or a deliberately improved one, rather than merely hold the same secrets.

Turning password manager migration into a security audit

Migration is often the only moment when an organization reviews every stored credential and every permission at the same time.

Day-to-day administration tends to be incremental: users are added, projects evolve, integrations accumulate, and access rights gradually expand. A migration interrupts that process and forces every object to justify its place in the new environment. That's why a structured migration often doubles as the most comprehensive access review an organization has performed in years.

During this review, teams typically discover:

• Orphaned secrets belonging to employees who left months ago
• Duplicate credentials for the same service stored across multiple vaults
• Inactive users still holding production access
• API keys that expired but were never removed
• Personal credentials stored inside corporate vaults
• Credentials for systems decommissioned long ago but never deleted

A bulk import silently carries these problems into the new platform. A transformation-based migration exposes them, because every credential, owner, and permission must be evaluated before it's recreated.

Verizon's 2026 DBIR reports that 27% of ransomware victims had evidence of an infostealer or credential leak during the previous year, and among those organizations, half were exposed within 95 days before the ransomware incident occurred. Migration is one of the few opportunities to revoke exposed or obsolete credentials before they become part of an attack chain.

The same report also notes that resolving weak passwords and permission misconfigurations across third-party cloud environments takes organizations nearly eight months on average. Doing that review during migration compresses those eight months into a planned engineering activity instead of a prolonged remediation effort.

Under GDPR Article 32, organizations must implement technical and organizational measures appropriate to the risks of processing personal data. Removing stale access and orphaned credentials during migration demonstrates those controls in practice rather than simply documenting them.

Seven steps that reduce migration risk before production

The Passwork migration workflow treats migration as an engineering project with explicit checkpoints rather than a single import operation.

1. Inventory

Document existing vaults, service accounts, integrations, automation, and external dependencies before writing any migration code.

2. Export

Extract data from the source system in a structured format. JSON is generally preferable because it preserves hierarchical relationships — Passwork's own JSON export keeps vault and folder structure intact, while CSV flattens everything into a table.

3. Review

Identify stale, duplicate, orphaned, or over-privileged credentials before they're migrated.

4. Transform

Implement migration rules that map the source environment to the destination hierarchy, ownership model, RBAC configuration, and naming conventions.

5. Test import

Run the migration against a staging environment to verify objects are created correctly before touching production. Passwork's own guidance for the Bitwarden script is explicit on this point: back up the destination database and dry-run on staging before a real cutover.

6. Validate permissions

Confirm that:

• authorized users have access;
• unauthorized users do not;
• service accounts authenticate successfully;
• CI/CD pipelines and integrations continue to function;
• audit logs capture expected security events.

7. Production migration

Execute the production migration in phases rather than one sweep — shared IT and infrastructure credentials first, then department vaults one team at a time, then private vaults once users are activated. Run the old and new systems in parallel for two to four weeks, spot-check with each department owner, and only decommission the source platform once adoption is real, not assumed.

Skipping either the testing or permission validation stages usually doesn't eliminate the work. It postpones it until production users or automated systems start failing after cutover.

Getting migration right

The easiest migrations move passwords. Successful migrations recreate how an organization operates: who owns each credential, how permissions are inherited, which systems depend on shared secrets, and which access paths should no longer exist.

One-click imports optimize for speed. Enterprise migrations optimize for correctness, auditability, and predictable behavior after cutover. Those goals rarely point in the same direction.

If there's one action worth taking before scheduling a migration, it's the first step in the workflow above: build an accurate inventory of your vaults, service accounts, integrations, and permission model before writing a single line of migration logic.

The best migration scripts document every migration decision along the way. Long after cutover, those transformation rules become a record of why access was mapped the way it was — making future audits, troubleshooting, and repeat migrations significantly easier.

Teams migrating from another password manager get a 10% discount on Passwork. Check the documentation to see how to switch to Passwork from popular password managers.

Password manager migration FAQ

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

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 7.7: Secure offline mode for desktop and mobile apps

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

PassworkPasswork Team

A gestão centralizada de palavras-passe para PMEs consiste em armazenar, partilhar e controlar todas as credenciais empresariais numa única plataforma segura, em vez de folhas de cálculo, navegadores ou mensagens de chat. Dá às pequenas e médias empresas o mesmo controlo de credenciais em que as grandes empresas confiam, sem o preço nem a equipa de segurança necessária para o gerir.

A maioria das pequenas e médias empresas já «gere palavras-passe». Alguém guarda as credenciais num navegador. Outra pessoa usa um cofre pessoal local gratuito, como o KeePass. Os acessos de administrador partilhados do Stripe, do Google Workspace ou do ERP estão numa conversa do Slack do ano passado. Isso é armazenamento de palavras-passe. Não é gestão centralizada de palavras-passe.

Em 2026, a gestão centralizada de palavras-passe para PMEs significa um único sistema pertencente à organização, onde as credenciais da equipa ficam em cofres partilhados, o acesso é concedido de forma deliberada e os colaboradores que saem deixam de ver os acessos da empresa sem uma busca manual. O mesmo cofre de credenciais pode guardar palavras-passe de pessoas e segredos de máquinas (chaves de API, tokens, cadeias de ligação a bases de dados), porque a pilha tecnológica já não separa as «aplicações em que as pessoas clicam» das «aplicações que os pipelines invocam».

O que significa realmente a gestão centralizada de palavras-passe

A gestão centralizada de palavras-passe significa que um único sistema pertencente à organização armazena e controla todas as credenciais empresariais partilhadas, com funções definidas, níveis de permissão e um registo de quem acedeu a quê. Distingue-se de um gestor de palavras-passe pessoal (por exemplo, o KeePass), que protege os acessos de uma só pessoa, e da gestão de acessos privilegiados (PAM) ao nível empresarial, que acrescenta gravação de sessões e elevação de privilégios just-in-time para o acesso à infraestrutura.

Um gestor de palavras-passe pessoal resolve o problema de início de sessão de uma pessoa. A gestão centralizada de palavras-passe resolve o problema da organização: quem pode aceder a quê, quando e com a aprovação de quem. Essa distinção é o ponto essencial.

Na prática, a centralização assenta em cinco mecanismos:

1. Um único sistema de referência para as credenciais da empresa, e não cinco cópias não oficiais espalhadas por várias ferramentas.
2. Cofres e pastas partilhados associados a equipas ou departamentos, de modo que a partilha de credenciais siga o organigrama.
3. Níveis de acesso, de «só de leitura» a administrador do cofre, para que ninguém precise de uma única credencial mestra partilhada por todo o escritório.
4. Um registo de atividade que responde a quem viu, alterou ou exportou determinada credencial.
5. Margem para crescer. A plataforma deve ser compatível com LDAP/AD ou Single Sign-On (SSO) quando a empresa estiver preparada para os utilizar, para que a gestão de identidades acompanhe o crescimento da equipa em vez de exigir uma nova ferramenta mais tarde.

Os gestores de palavras-passe pessoais continuam a ser úteis para contas pessoais. Deixam de funcionar quando a credencial pertence à empresa: os responsáveis pela faturação mudam, os subcontratados vão rodando e ninguém consegue provar quem ainda tem a palavra-passe do e-mail da conta raiz da AWS.

Porque é que as PMEs sentem isto com mais força em 2026

Quatro pressões acumulam-se em simultâneo e nenhuma delas existia nesta combinação há cinco anos. Uma empresa de 40 pessoas gere hoje dezenas de ferramentas SaaS sem uma equipa de segurança dedicada, tem a força de trabalho dispersa por redes domésticas e cafés e cola cada vez mais credenciais em ferramentas de IA que ninguém avaliou.

• Proliferação de SaaS sem um departamento de TI de vinte pessoas. Uma pequena empresa pode acabar por usar dezenas de ferramentas na nuvem sem ninguém dedicado à gestão de acessos. Cada ferramenta exige um início de sessão de administrador e a maioria das equipas resolve-o da forma mais rápida: uma caixa de correio partilhada e uma palavra-passe escrita num local que todos conseguem encontrar. Seis meses depois, ninguém é responsável por essa palavra-passe e ninguém se lembra de quem a viu.
• Trabalho híbrido e remoto. Enviar uma palavra-passe por Slack ou por e-mail já era arriscado quando todos trabalhavam no mesmo escritório. Com pessoas a iniciar sessão a partir de routers domésticos e portáteis pessoais, o preenchimento automático a partir de um cofre partilhado é a única opção que não envolve escrever uma palavra-passe numa janela de chat.
• Risco na saída de colaboradores. Quando alguém sai, tudo o que estava no seu cofre pessoal, no navegador ou na aplicação de notas sai com essa pessoa. Um gestor de palavras-passe centralizado permite desativar a conta, retirá-la de todos os grupos e rodar as credenciais SaaS partilhadas que existiam apenas no portátil dessa pessoa. Sem ele, a revisão de acessos só acontece depois de algo correr mal.
• A shadow AI é a fuga mais recente. Os colaboradores colam agora chaves de API, cadeias de ligação a bases de dados e palavras-passe no ChatGPT ou no Copilot ao resolver problemas, e nada dessa atividade passa por um cofre ou por um registo de auditoria. Segundo o Cost of a Data Breach Report 2026 da IBM, a shadow AI esteve envolvida em 43 % das violações de dados, contra 20 % no ano anterior, e 92 % das organizações afetadas por uma violação relacionada com IA não tinham controlos de acesso básicos para IA.

Em que ponto está a empresa em matéria de gestão de palavras-passe

A maioria das PMEs encontra-se numa de quatro fases reconhecíveis, do caos improvisado à governação centralizada. Cada fase comporta um risco específico e passar à seguinte elimina-o.

Fase 1: Caos improvisado

Folhas de cálculo, notas autocolantes, mensagens diretas no Slack com uma palavra-passe colada.

Fase 2: Armazenamento no navegador

O Chrome ou o Edge guardam as palavras-passe.

Fase 3: Gestor de palavras-passe básico

Uma equipa adotou uma ferramenta, mas ninguém a governa.

Fase 4: Governação centralizada

Um cofre estruturado, RBAC, registo de auditoria e uma política imposta funcionam em conjunto. O risco diminui drasticamente.

De acordo com o Data Breach Investigations Report 2026 da Verizon, as credenciais roubadas ou reutilizadas surgiram em 39 % de todas as violações, normalmente associadas a uma vulnerabilidade explorada ou a um terceiro comprometido, e não de forma isolada. Estes atacantes não ajustam os métodos à dimensão da empresa. O 2025 State of SMB Cybersecurity Survey da CrowdStrikeconcluiu que, entre as PMEs que sofreram um incidente de cibersegurança, 29 % das que têm menos de 25 colaboradores foram atingidas por ransomware, a taxa mais elevada de todos os grupos por dimensão de empresa, incluindo as PMEs maiores.

As equipas mais pequenas são as menos preparadas para absorver esse impacto. As equipas nas fases 1 e 2 não dispõem de qualquer mecanismo para detetar uma credencial comprometida nem para a revogar rapidamente, porque nada está suficientemente centralizado para se poder verificar. É precisamente essa lacuna que a fase 4 fecha.

Porque é que as PMEs são o alvo, e não a exceção

As PMEs enfrentam os mesmos padrões de violação que organizações de qualquer dimensão e raramente são escolhidas pelos atacantes com base no setor ou na faturação. De acordo com o Data Breach Investigations Report 2026 da Verizon, o padrão System Intrusion continua a ser o principal padrão de violação em pequenas organizações, o mesmo que lidera também nas grandes empresas, e a maioria destes ataques é realizada por agentes externos com motivação financeira.

«Somos demasiado pequenos para importar» é a leitura errada da ameaça. Os próprios investigadores da Verizon dizem-no sem rodeios: os atacantes que visam PMEs estão a «lançar redes amplas» na esperança de que vítimas suficientes paguem, sem investigar previamente a dimensão ou o setor da empresa. O que decide quem sofre uma violação é mais simples e mais banal: se as credenciais já estavam comprometidas ou se os dispositivos de periferia tinham uma falha por corrigir.

Os dados ao nível das ações confirmam-no. Nas violações em PMEs analisadas pela Verizon, o ransomware surgiu em 83 % dos incidentes, a utilização de credenciais roubadas em 39 % e a exploração de vulnerabilidades em 30 %. Os números do ransomware pesam sobretudo nas empresas mais pequenas: nos casos de ransomware em que a Verizon conseguiu confirmar a dimensão da organização, cerca de 96 % das vítimas eram PMEs.

Face a números como estes, uma plataforma de palavras-passe com preço por utilizador por mês não é uma despesa que valha a pena debater. É um custo pequeno e previsível perante uma ameaça que não discrimina pela dimensão da empresa.

Fechar a lacuna que as credenciais roubadas deixam aberta não exige um grande orçamento nem uma implementação demorada. Experimentar o Passwork gratuitamente e ver como se apresentam, na própria infraestrutura, um cofre estruturado, o controlo de acesso baseado em funções e o registo de auditoria.

O que procurar numa plataforma de gestão centralizada de palavras-passe

Uma plataforma de gestão centralizada de palavras-passe para PMEs precisa de cofres partilhados com estrutura de pastas, RBAC granular, registo de auditoria completo, MFA imposta e um modelo de implementação adequado às necessidades de conformidade, quer seja autoalojado, quer alojado na nuvem. A saída de colaboradores automatizada e o acesso por API tornam-se relevantes quando a equipa ultrapassa um punhado de pessoas.

O que verificar antes de escolher uma:

Estrutura dos cofres

Pastas ou etiquetas organizadas por departamento mantêm as credenciais fáceis de encontrar sem depender apenas da barra de pesquisa.

O Passwork organiza as credenciais em cofres e pastas aninhadas que correspondem a departamentos e projetos. Adicionar um novo utilizador não deve implicar percorrer vinte palavras-passe. Mapear mais tarde os grupos do diretório (LDAP/AD) é opcional; o hábito de trabalhar por grupos deve começar no primeiro dia.

Granularidade do RBAC

As boas plataformas separam duas camadas de permissões: funções do sistema (quem pode convidar utilizadores, configurar o SSO, ler registos) e níveis de acesso aos recursos (quem pode ver ou editar um cofre ou uma pasta específicos). A maioria dos colaboradores só precisa de acesso de leitura ou de escrita ao cofre da própria equipa. As funções de administrador devem continuar a ser raras.

O Passwork inclui funções predefinidas e permite criar funções personalizadas, como Administrador de AD ou DevOps, limitadas exatamente às permissões de que essa função precisa. Esta separação é importante na prática: um auditor que pode consultar o registo não deve poder editar automaticamente o conteúdo dos cofres, e um administrador de sistemas que gere a sincronização LDAP não deve precisar de acesso às credenciais das Finanças.

Registo de auditoria

O registo deve abranger visualizações, edições e exportações, e não apenas inícios de sessão. Sem isso, «quem acedeu às credenciais da base de dados do cliente no mês passado» não tem resposta.

O registo de atividade do Passwork regista todas as ações no sistema. Quando as permissões de uma pasta mudam ou uma palavra-passe mestra é redefinida, a entrada aparece de imediato, com pesquisa por utilizador, data ou tipo de ação.

MFA obrigatória

NIST SP 800-63B recomenda a autenticação multifator para qualquer conta com acesso elevado. Deve ser imposta a qualquer função que possa ver cofres sensíveis, e não apenas à conta de administrador.

O Passwork é compatível com a MFA ao nível da conta e permite aos administradores exigi-la em toda a organização, em vez de a deixar opcional para cada utilizador. Isto elimina a falha em que o CEO ativa a autenticação de dois fatores, mas o prestador de serviços com acesso à base de dados nunca se dá a esse trabalho.

Saída de colaboradores automatizada

Um clique deve desativar o acesso de um colaborador que sai a todas as pastas partilhadas em que trabalhou, e não quinze revogações separadas.

No Passwork, desativar a conta de um único utilizador revoga de imediato o seu acesso a todos os cofres e pastas para os quais tinha permissões, independentemente do número de equipas ou projetos abrangidos.

O painel de segurança mostra exatamente a que essa conta tinha acesso antes da desativação, pelo que um administrador que analise um caso de saída não tem de reconstruir o histórico de acessos de memória nem apenas a partir do registo de auditoria.

Extensão de navegador, aplicações para computador e para dispositivos móveis

O preenchimento automático a partir de um cofre partilhado é preferível a copiar uma palavra-passe de uma conversa. A adoção depende disso.

A extensão de navegador do Passwork funciona com Chrome, Firefox, Edge e Safari e preenche automaticamente as credenciais diretamente a partir dos cofres partilhados, sem sair da página. As aplicações para dispositivos móveis e para computador cobrem o mesmo âmbito para os colaboradores que precisam de aceder ao cofre fora do navegador, em particular técnicos de campo e equipas comerciais remotas.

O painel de segurança mostra exatamente a que essa conta tinha acesso antes da desativação, pelo que um administrador que analise um caso de saída não tem de reconstruir o histórico de acessos de memória nem apenas a partir do registo de auditoria.

Acesso por API

Opcional no início. Torna-se relevante quando as equipas começam a obter segredos em pipelines de CI/CD em vez de os guardarem nos .env ficheiros.

A REST API do Passwork permite que as equipas de DevOps obtenham segredos por programação no momento da implementação, rodem credenciais de forma agendada e integrem o acesso ao cofre na automatização existente, em vez de copiarem chaves manualmente entre sistemas. É neste ponto que um gestor de palavras-passe deixa de ser uma comodidade de navegação e passa a funcionar como infraestrutura.

Margem para crescer: SSO e LDAP

Nada do que foi indicado exige SSO nem LDAP no primeiro dia. Uma equipa de cinco pessoas pode funcionar inteiramente com contas locais e convites manuais. Quando o número de colaboradores ultrapassa os 20 a 30, ou a organização já usa o Active Directory para tudo o resto, a gestão manual de utilizadores transforma-se num trabalho a tempo parcial.

A integração LDAP/AD sincroniza a estrutura de diretório existente com o sistema de grupos e funções do Passwork, pelo que um novo colaborador adicionado ao grupo «Developer» do AD herda automaticamente o acesso aos cofres correspondentes, sem um passo de aprovisionamento separado no próprio Passwork.

O benefício prático volta a surgir na saída de colaboradores. Ao desativar um utilizador no Active Directory, o seu acesso ao Passwork desaparece no mesmo ciclo de sincronização.

Conclusão

A gestão centralizada de palavras-passe não é uma funcionalidade empresarial reduzida para equipas pequenas. É um controlo dirigido ao vetor de violação que mais atinge as PMEs: credenciais que continuaram válidas depois de deverem ter sido revogadas.

Comece por um departamento-piloto esta semana. Importe as respetivas credenciais para o Passwork, configure o acesso baseado em grupos e escolha uma data de transição para abandonar definitivamente a folha de cálculo.

Se a equipa partilha credenciais por folhas de cálculo, chat ou armazenamento no navegador, o Passwork oferece um cofre autoalojado com RBAC, registo de auditoria e saída de colaboradores com um clique, sem preços de nível empresarial. Implementar o Passwork na infraestrutura própria e deixar de se perguntar quem ainda tem a palavra-passe do Wi-Fi de há três admissões.

Perguntas frequentes

O que é a shadow AI: A ameaça oculta que custa 670 mil dólares por violação às empresas

A shadow AI custa às empresas mais 670 mil dólares por violação, e grande parte tem origem em credenciais coladas em LLMs públicos. O artigo explica o que é a shadow AI na prática, por que razão é mais difícil de travar do que a shadow IT e como a governar.

PassworkAlex Muntyan

Gestão de credenciais SaaS: 5 passos para centralizar o conjunto de aplicações

A gestão de credenciais SaaS transforma palavras-passe e chaves de API dispersas num inventário único, que pode ser partilhado de forma deliberada e revogado na saída. O modelo de cinco passos: inventário, estrutura, migração, controlo de acesso e automatização.

PassworkPasswork Team

O Passwork distinguido com o Top Performer Summer 2026 no SourceForge

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

PassworkPasswork Team

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

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

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

Was zentralisierte Passwortverwaltung tatsächlich bedeutet

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

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

In der Praxis basiert Zentralisierung auf fünf Mechanismen:

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

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

Warum KMU dies 2026 stärker spüren

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

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

Wo steht Ihr Unternehmen tatsächlich bei der Passwortverwaltung

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

Phase 1: Ad-hoc-Chaos

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

Phase 2: Browser-basierte Speicherung

Chrome oder Edge speichert die Passwörter.

Phase 3: Einfacher Passwort-Manager

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

Phase 4: Zentralisierte Governance

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

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

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

Warum KMU das Ziel sind, nicht die Ausnahme

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

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

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

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

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

Worauf Sie bei einer zentralisierten Passwortverwaltungs-Plattform achten sollten

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

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

Tresorstruktur

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

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

RBAC-Granularität

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

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

Audit-Protokollierung

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

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

MFA-Durchsetzung

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

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

Automatisiertes Offboarding

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

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

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

Browser-Erweiterung, Desktop- und Mobile-Apps

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

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

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

API-Zugriff

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

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

Raum zum Wachsen: SSO und LDAP

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

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

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

Fazit

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

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

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

Häufig gestellte Fragen

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

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

PassworkAlex Muntyan

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

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

PassworkPasswork Team

Passwork gewinnt Top Performer Sommer 2026 auf SourceForge

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

PassworkPasswork Team

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Etapa 1: Caos improvisado

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

Etapa 2: Almacenamiento en el navegador

Chrome o Edge guardan las contraseñas.

Etapa 3: Gestor de contraseñas básico

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

Etapa 4: Gobernanza centralizada

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

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

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

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

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

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

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

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

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

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

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

Esto es lo que debe verificar antes de elegir una:

Estructura de la bóveda

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

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

Granularidad del RBAC

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

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

Registro de auditoría

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

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

Aplicación de MFA

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

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

Baja automatizada

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

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

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

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

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

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

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

Acceso API

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

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

Capacidad de crecimiento: SSO y LDAP

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

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

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

Conclusión

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

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

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

Preguntas frecuentes

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

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

PassworkAlex Muntyan

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

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

PassworkPasswork Team

Passwork gana Top Performer Verano 2026 en SourceForge

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

PassworkPasswork Team

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

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

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

What centralized password management actually means

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

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

In practice, centralization rests on five mechanics:

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

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

Why SMBs feel this harder in 2026

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

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

Where does your business actually stand on password management

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

Stage 1: Ad-hoc chaos

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

Stage 2: Browser-based storage

Chrome or Edge saves the passwords.

Stage 3: Basic password manager

A team adopted a tool, but nobody governs it.

Stage 4: Centralized governance

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

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

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

Why SMBs are the target, not the exception

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

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

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

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

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

What to look for in a centralized password management platform

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

Here is what to check before choosing one:

Vault structure

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

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

RBAC granularity

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

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

Audit logging

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

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

MFA enforcement

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

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

Automated offboarding

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

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

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

Browser extension, desktop and mobile apps

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

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

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

API access

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

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

Room to grow: SSO and LDAP

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

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

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

Bottom line

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

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

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

Frequently asked questions

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

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

PassworkAlex Muntyan

SaaS credential management: 5 steps to centralize your app stack

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

PassworkPasswork Team

Passwork wins Top Performer Summer 2026 on SourceForge

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

PassworkPasswork Team

A soberania de dados é a capacidade de determinar, a nível físico, jurídico e criptográfico, quem pode aceder a determinados dados e sob que jurisdição. Uma empresa pode estar totalmente em conformidade com o RGPD no papel e, ainda assim, não ter qualquer controlo real sobre o local onde residem as suas palavras-passe. No caso das credenciais empresariais, essa lacuna entre «em conformidade» e «sob controlo» é onde começam as violações de dados, as intimações e as auditorias reprovadas.

O Regulamento Geral sobre a Proteção de Dados (RGPD) estabelece a base de referência que a maioria das organizações utiliza para avaliar as suas práticas de dados: regula a forma como os dados pessoais são recolhidos, armazenados e transferidos e, nos termos do artigo 3.º, o seu âmbito territorial abrange qualquer empresa que trate dados de residentes na UE, independentemente do local da sua sede. 

As palavras-passe e os segredos não são dados comuns, razão pela qual a gestão de palavras-passe necessita de um modelo de soberania próprio, distinto do armazenamento geral de ficheiros. Dão acesso a tudo o resto, circulam constantemente entre colaboradores e raramente passam pelas ferramentas de prevenção de perda de dados (DLP) ou de classificação que vigiam contratos e registos de clientes. Uma credencial armazenada no servidor errado, no país errado, sob chaves de cifragem de terceiros, é um risco que a maioria das listas de verificação de conformidade não deteta.

Este artigo analisa o que a soberania significa realmente em três níveis: localização física, cifragem e governação de acessos. Compara os modelos on-premise, com isolamento físico (air gap) e cloud na UE, e mostra onde um gestor de palavras-passe autoalojado e zero-knowledge, como o Passwork, se enquadra nessa decisão.

O que significa realmente a soberania de dados para as credenciais

A soberania de dados é a combinação de três controlos distintos: onde os dados se encontram fisicamente, quem detém as chaves de cifragem e quem governa o acesso aos mesmos. A perda de qualquer um dos três compromete a soberania, mesmo que os outros dois sejam sólidos. A maioria dos fornecedores anuncia apenas o primeiro.

• A localização física indica onde estão os servidores. Um gestor de palavras-passe alojado em Frankfurt continua abrangido pelo âmbito territorial do RGPD, mas o mesmo sucede com um alojado na Virgínia, se tratar dados de residentes na UE. A localização importa para a jurisdição, não automaticamente para a exposição jurídica.
• O controlo da cifragem indica quem pode decifrar os dados. Se o fornecedor detém as chaves, um pedido governamental, uma pessoa com acesso interno ou uma violação na infraestrutura do fornecedor podem expor as credenciais, independentemente da localização do servidor.
• A governação de acessos indica quem, dentro da organização, pode ver o quê. O controlo de acesso baseado em funções (RBAC) e os registos de auditoria determinam se o acesso de um colaborador que sai é revogado em minutos ou descoberto seis meses mais tarde.

A verdadeira soberania de dados exige os três elementos. A omissão de qualquer componente reduz a arquitetura a uma lista de verificação de conformidade meramente formal.

Porque as credenciais são uma classe de dados distinta

As credenciais merecem um tratamento separado por serem de elevado valor, de elevada circulação e em grande parte invisíveis para as ferramentas habituais de governação de dados. Um registo de cliente divulgado expõe um único conjunto de dados. Uma palavra-passe de administrador divulgada expõe todos os sistemas a que esse administrador tem acesso e continua a funcionar até que alguém a substitua.

Verizon, no 2026 Data Breach Investigations Report, concluiu que as credenciais roubadas representaram 13 % dos vetores de acesso inicial, mas que esse valor triplicou (39 %) ao longo de toda a progressão da violação de dados. As palavras-passe também circulam constantemente: são partilhadas durante a integração de colaboradores, copiadas para tickets, coladas em conversas de chat e reencaminhadas quando um projeto muda de mãos. As ferramentas de DLP concebidas para detetar a exfiltração de documentos raramente assinalam uma palavra-passe colocada numa mensagem do Slack.

Esta combinação de elevado impacto e baixa visibilidade é a razão pela qual o armazenamento de credenciais necessita do seu próprio modelo de soberania, em vez de herdar a política que abrange o armazenamento geral de ficheiros.

Onde o armazenamento cloud padrão introduz atrito jurídico

Os gestores de palavras-passe cloud convencionais introduzem exposição jurídica através de cadeias de subcontratantes ulteriores, transferências transfronteiriças de dados e acesso do pessoal do fornecedor, mesmo quando este cumpre integralmente o RGPD. A cifragem em repouso não elimina estes riscos se quem detém as chaves de decifragem for o fornecedor e não o cliente.

Três pontos de atrito concretos surgem repetidamente nas análises de aquisição:

• Subcontratantes ulteriores. A maioria dos fornecedores cloud recorre a prestadores subcontratados de infraestrutura, monitorização ou suporte. Cada subcontratante ulterior é uma entidade distinta, com a sua própria superfície de acesso. No RGPD, o artigo 28.º, n.º 2 exige que o subcontratante não contrate outro subcontratante (subcontratante ulterior) sem autorização prévia, específica ou geral, por escrito, do responsável pelo tratamento.
• Transferências para países terceiros. O capítulo V do RGPD rege as transferências de dados pessoais para fora da UE/EEE. O artigo 44.º estabelece o princípio geral de que nenhuma transferência pode comprometer o nível de proteção garantido pelo regulamento, e o artigo 46.º exige garantias adequadas, como as cláusulas contratuais-tipo, quando não se aplica nenhuma decisão de adequação. Os cofres de credenciais alojados num país terceiro, ou replicados para um país terceiro para fins de cópia de segurança, enquadram-se inteiramente neste capítulo.
• Acesso do pessoal do fornecedor e pedidos legais. Se o fornecedor puder decifrar tecnicamente os dados dos clientes, esses dados ficam sujeitos a processos judiciais na jurisdição do fornecedor. Uma intimação, um mandado ou uma ordem de divulgação estrangeira podem obrigar ao acesso, independentemente do local onde a empresa está registada.

A NIS2 acrescenta uma quarta perspetiva: o artigo 21.º, n.º 2, alínea d) exige que as entidades essenciais e importantes avaliem a segurança da cadeia de abastecimento, incluindo os fornecedores e as ferramentas que utilizam para gerir credenciais de acesso. Um cofre de palavras-passe alojado junto de um subcontratante ulterior externo que não foi previamente avaliado enquadra-se inteiramente nesse requisito.

Nada disto torna o armazenamento cloud não conforme por defeito. Significa que «em conformidade com o RGPD» é uma condição necessária para a soberania das credenciais.

Associar as três camadas aos modelos de implementação

Uma lacuna em qualquer uma das camadas volta a abrir a exposição que as outras duas deviam fechar. A tabela abaixo aplica os três controlos da primeira secção, localização, decifragem e acesso, aos modelos entre os quais as organizações realmente escolhem.

• Com isolamento físico (air gap) designa uma infraestrutura sem qualquer caminho de rede para a internet, a forma mais estrita de isolamento físico.
• Zero-knowledge significa que o fornecedor nunca pode ler os dados, em circunstância alguma. 
• A cifragem do lado do cliente é o mecanismo que produz essa garantia: a cifragem e a decifragem ocorrem no dispositivo do utilizador, com uma palavra-passe mestra que o fornecedor nunca recebe nem armazena, pelo que o servidor apenas guarda e transmite texto cifrado. 

Um esquema de cifragem do lado do cliente mal implementado, com uma palavra-passe mestra recuperável ou uma função de derivação de chaves fraca, não oferece automaticamente uma garantia zero-knowledge verdadeira. Esta distinção determina se «cifrado na cloud» tem realmente algum significado para a soberania.

On-premise e com isolamento físico: Isolamento total, com custo operacional

A implementação on-premise confere a uma organização controlo físico e criptográfico total sobre o seu cofre de credenciais, porque os dados nunca saem da infraestrutura que a organização possui e administra. O isolamento físico vai um passo além: a infraestrutura não tem qualquer caminho de rede para a internet, o que é a única configuração que elimina por completo a dependência de rede externa.

Isolamento em relação ao fornecedor: Cifragem zero-knowledge

Passwork funciona integralmente dentro do perímetro corporativo, numa infraestrutura que a organização controla de ponta a ponta. O gestor de palavras-passe e segredos cifra e decifra os dados inteiramente do lado do cliente, com uma chave derivada da palavra-passe mestra do utilizador. O servidor nunca recebe nem armazena texto em claro, em momento algum: guarda apenas blobs cifrados e não dispõe de nenhuma chave capaz de os decifrar. Para organizações com requisitos de air gap e políticas de segmentação rigorosas, esta é frequentemente a única arquitetura que cumpre a política de segurança interna. 

Uma afirmação destas não deve ser aceite apenas com base na confiança. O código-fonte do Passwork está aberto para que a própria equipa de segurança da organização o audite diretamente, linha a linha, em vez de depender da descrição do fornecedor sobre a forma como a cifragem é implementada.

A contrapartida operacional

Esse nível de isolamento tem um preço, pago em esforço operacional. On-premise transfere a manutenção do servidor, a aplicação de patches, a gestão de cópias de segurança e a responsabilidade pela disponibilidade do fornecedor para a equipa de TI da própria organização. Alguém tem de aplicar atualizações, monitorizar o espaço em disco, gerir certificados TLS e tratar da recuperação de desastres. Para uma equipa de TI pequena, já sobrecarregada com outras prioridades, trata-se de um custo real. As organizações que optam pelo autoalojamento precisam de um administrador de sistemas dedicado ou de um processo interno gerido para manter a implementação atualizada.

A cifragem zero-knowledge do Passwork mantém os dados ilegíveis para todos, exceto para os próprios utilizadores. Consultar a arquitetura nos guias do utilizador antes de comprometer a infraestrutura, ou testar gratuitamente a implementação completa para a ver em funcionamento nos próprios servidores.

Alojamento cloud na UE: Viável, mas apenas com cifragem do lado do cliente

O alojamento cloud na UE pode satisfazer os requisitos jurisdicionais de equipas mais pequenas sem pessoal de infraestrutura dedicado, mas apenas se o fornecedor implementar cifragem do lado do cliente (CSE) obrigatória. Sem CSE, um cofre alojado na UE continua a permitir que o fornecedor decifre os dados dos clientes, o que reabre a mesma exposição que o alojamento na UE devia eliminar.

Num modelo CSE adequado, a palavra-passe mestra nunca sai do dispositivo do utilizador e os servidores do fornecedor processam e armazenam apenas texto cifrado. Mesmo com acesso físico total ao servidor, o fornecedor não consegue ler o conteúdo do cofre. Esta garantia é substancialmente diferente de «os nossos centros de dados estão na UE», que aborda a jurisdição, mas nada diz sobre quem detém as chaves.

O alojamento cloud na UE com CSE reduz a exposição jurídica e satisfaz os requisitos de residência de dados de muitos quadros de conformidade, mas não é a mesma garantia que a soberania total on-premise. A infraestrutura, a camada de rede e o hardware físico permanecem fora do controlo direto do cliente. Para organizações com obrigações de air gap ou políticas rigorosas de autoalojamento, a cloud na UE não é um substituto, independentemente da robustez da cifragem.

On-premise sem zero-knowledge continua a confiar o acesso a texto em claro aos administradores locais. A cloud na UE sem zero-knowledge continua a confiar no pessoal de infraestrutura do fornecedor. Em ambos os casos, a garantia só se mantém quando a palavra-passe mestra nunca sai do dispositivo do utilizador.

Verificar as afirmações dos fornecedores: O que as aquisições devem confirmar

As afirmações de soberania só são tão credíveis quanto as provas de terceiros que as sustentam. Esta verificação aplica-se independentemente do modelo de implementação escolhido: um certificado não indica onde os dados se encontram, mas indica se as restantes afirmações do fornecedor se sustentam. As equipas de aquisições devem basear a decisão de autoalojamento na capacidade administrativa interna e nos requisitos de política, e depois validar o fornecedor pré-selecionado através de certificação independente, auditoria própria e testes de segurança públicos.

Quatro verificações são relevantes na prática:

• Certificação ISO/IEC 27001 confirma que um sistema de gestão de segurança da informação foi auditado de forma independente face à norma internacional. O Passwork possui a certificação ISO/IEC 27001:2022, emitida pela MSECB e verificável através da base de dados IAF CertSearch.
• A preparação para a NIS2 e o RGPD é relevante para qualquer organização abrangida pelo âmbito de um destes regulamentos. Os requisitos de cadeia de abastecimento do artigo 21.º da NIS2 estendem-se às ferramentas que as entidades essenciais e importantes utilizam para gerir credenciais de acesso, enquanto o artigo 32.º do RGPD exige «medidas técnicas e organizativas adequadas», incluindo a cifragem, para qualquer sistema que trate dados pessoais. As organizações que avaliem fornecedores face a estes requisitos podem consultar a abordagem do Passwork à conformidade com a NIS2 como um ponto de referência.
• Direitos de auditoria do código-fonte confirmam que uma afirmação de zero-knowledge é efetivamente verdadeira e não linguagem de marketing. Numa conceção zero-knowledge genuína, o fornecedor não consegue recuperar a palavra-passe mestra de um utilizador individual em circunstância alguma: nem através de uma reposição no backend, nem através de um pedido de suporte, nem sob pressão legal. Se um utilizador a esquecer, os dados que protege perdem-se por conceção, porque o fornecedor nunca teve a chave. O Passwork abre o seu código-fonte às equipas de segurança dos clientes precisamente por esta razão: é a forma de confirmar que a implementação da cifragem corresponde à arquitetura descrita pelo fornecedor.
• Testes de intrusão públicos fornecem provas que vão além da postura de segurança autodeclarada. O Passwork concluiu um teste de intrusão independente através da HackerOne, abrangendo o tratamento seguro de dados, o OWASP Top 10 e o SANS Top 25, a autenticação e o controlo de acesso à API.

Escolher um modelo de implementação: Um modelo de decisão

O modelo de implementação adequado depende de cinco fatores práticos: 

• Requisitos de air gap 
• Alojamento obrigatório na UE 
• Dimensão da equipa de administração
• Política interna de autoalojamento
• Requisitos de controlo da infraestrutura

Confrontar estes fatores com as opções de implementação evita o erro comum de escolher apenas com base no preço ou na notoriedade da marca. Utilize esta matriz de decisão de residência de credenciais para fazer corresponder as restrições da organização a um modelo de implementação:

Na prática, nenhuma destas linhas é mutuamente exclusiva. Uma instituição financeira pode operar on-premise para o seu cofre principal e, ao mesmo tempo, aceitar ferramentas baseadas na cloud para fluxos de trabalho de menor sensibilidade. A matriz é um ponto de partida para a conversa com as partes interessadas de segurança e conformidade.

Como a arquitetura do Passwork se enquadra nestas camadas

A implementação autoalojada do Passwork responde à lacuna de soberania descrita ao longo deste artigo, combinando isolamento físico, cifragem zero-knowledge e governação de acessos controlada pelo cliente numa única arquitetura. O cofre é implementado na infraestrutura que o cliente possui, seja um único servidor Linux, um ambiente Windows Server ou um contentor Docker numa rede com isolamento físico.

A cifragem utiliza AES-256 com um desenho zero-knowledge, o que significa que a infraestrutura, caso alguma vez fosse comprometida, apenas contém texto cifrado. O acesso é governado através de permissões baseadas em funções e de um registo de auditoria completo, pelo que os administradores podem ver quem acedeu a que credencial e quando, e revogar o acesso de imediato quando alguém muda de função ou sai. A integração com AD/LDAP e SAML SSO permite que a governação de acessos se ligue à infraestrutura de identidade existente, em vez de funcionar como um silo separado.

Isto não é, deliberadamente, uma afirmação de que o autoalojamento é adequado para todos. As organizações sem requisitos de air gap nem obrigações estritas de autoalojamento podem considerar suficiente uma opção cloud com cifragem do lado do cliente adequada. O ponto é que, quando a soberania total é o requisito, a arquitetura tem de a viabilizar de forma estrutural.

Soberania de dados na gestão de palavras-passe: Como aplicá-la na avaliação

A soberania é um alinhamento contínuo entre o local onde os dados se encontram, quem detém as chaves e quem governa o acesso, e esse alinhamento tem de ser revisto sempre que a infraestrutura, os contratos com fornecedores ou o âmbito regulamentar se alterem.

Comece por mapear a organização face aos quatro fatores da matriz de decisão: requisito de air gap, alojamento obrigatório na UE, dimensão da equipa de administração e política interna de autoalojamento. Esse mapeamento diz mais sobre o modelo de implementação adequado do que a página de marketing de qualquer fornecedor.

A única forma de confirmar que uma arquitetura autoalojada se adequa à infraestrutura é executá-la nela. O Passwork oferece um período de teste gratuito que pode ser implementado nos próprios servidores, com todas as funcionalidades e sem que quaisquer dados saiam do ambiente do cliente.

Perguntas frequentes

Gestão de credenciais SaaS: 5 passos para centralizar o conjunto de aplicações

A gestão de credenciais SaaS transforma palavras-passe e chaves de API dispersas num único inventário que pode ser partilhado de forma deliberada e revogado na saída. Segue-se o modelo de cinco passos: inventário, estrutura, migração, controlo de acessos e automatização.

PassworkPasswork Team

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

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

Passwork BlogAlex Muntyan

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. Saiba como funciona a cadeia de chaves, o que protege, o que não cobre e como verificar a afirmação de um fornecedor.

PassworkPasswork Team

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

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

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

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

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

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

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

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

Warum Zugangsdaten eine eigene Datenklasse sind

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

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

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

Wo Standard-Cloud-Speicherung rechtliche Reibungspunkte verursacht

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

Drei spezifische Reibungspunkte treten bei Beschaffungsprüfungen wiederholt auf:

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

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

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

Die drei Ebenen auf Bereitstellungsmodelle abbilden

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

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

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

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

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

Isolation vom Anbieter: Zero-Knowledge-Verschlüsselung

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

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

Der operative Kompromiss

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

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

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

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

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

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

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

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

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

Vier Prüfungen sind in der Praxis relevant:

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

Ein Bereitstellungsmodell wählen: Ein Entscheidungsrahmen

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

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

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

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

Wie die Architektur von Passwork auf diese Ebenen abgebildet wird

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

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

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

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

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

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

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

Häufig gestellte Fragen

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

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

PassworkPasswork Team

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

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

Passwork BlogAlex Muntyan

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

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

PassworkPasswork Team

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

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

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

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

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

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

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

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

Por qué las credenciales son una clase de datos distinta

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

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

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

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

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

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

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

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

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

Mapeo de las tres capas a modelos de despliegue

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

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

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

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

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

Aislamiento del proveedor: Cifrado de conocimiento cero

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

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

La contrapartida operativa

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

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

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

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

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

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

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

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

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

Cuatro verificaciones importan en la práctica:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Preguntas frecuentes

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

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

PassworkPasswork Team

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

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

Passwork BlogAlex Muntyan

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

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

PassworkPasswork Team

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

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

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

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

What data sovereignty actually means for credentials

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

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

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

Why credentials are a distinct data class

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

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

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

Where standard cloud storage introduces legal friction

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

Three specific friction points show up repeatedly during procurement reviews:

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

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

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

Mapping the three layers to deployment models

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

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

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

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

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

Isolation from the provider: zero-knowledge encryption

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

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

The operational trade-off

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

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

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

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

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

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

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

Verifying vendor claims: What procurement should check

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

Four checks matter in practice:

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

Choosing a deployment model: A decision framework

The right deployment model depends on five practical factors: 

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

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

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

How Passwork's architecture maps to these layers

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

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

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

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

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

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

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

Frequently Asked Questions

SaaS credential management: 5 steps to centralize your app stack

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

PassworkPasswork Team

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

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

Passwork BlogAlex Muntyan

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

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

PassworkPasswork Team

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

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

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

O que conta como credencial SaaS

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

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

Passo 1: Criar o inventário de credenciais SaaS

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

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

Exemplo:

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

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

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

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

Exemplo de hierarquia de dados:

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

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

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

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

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

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

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

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

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

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

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

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

O Passwork separa duas camadas:

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

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

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

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

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

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

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

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

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

Como é a gestão de credenciais SaaS bem feita

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

A centralização está conseguida quando:

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

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

Conclusão

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

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

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

Perguntas frequentes

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

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

PassworkAlex Muntyan

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

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

PassworkPasswork Team

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

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

Passwork BlogAlex Muntyan

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

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

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

Was als SaaS-Zugangsdaten zählt

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

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

Schritt 1: Erstellen Sie Ihr SaaS-Zugangsdatenverwaltungs-Inventar

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

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

Beispiel:

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

Schritt 2: Gestalten Sie Tresore und Ordner entsprechend Ihrer Arbeitsweise

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

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

Beispiel für eine Datenhierarchie:

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

Namensregeln helfen mehr als tiefe Verschachtelung:

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

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

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

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

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

Regeln für eine ehrliche Migration:

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

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

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

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

Passwork trennt zwei Ebenen:

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

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

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

Schritt 5: Identität, Automatisierung und Offboarding verbinden

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

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

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

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

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

Wie richtige SaaS-Zugangsdatenverwaltung aussieht

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

Sie sind zentralisiert, wenn:

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

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

Fazit

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

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

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

Häufig gestellte Fragen

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

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

PassworkAlex Muntyan

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

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

PassworkPasswork Team

Was ist Privileged Access Management? Ein vollständiger Leitfaden

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

Passwork BlogAlex Muntyan