We have released an updated Passwork Docker image with patched PHP (CVE-2026-109618 and CVE-2026-109619). If you run Passwork 7 or later in Docker, update today.

The update restarts the containers, so Passwork will be unavailable for a few minutes. It doesn’t change the database or Docker volumes.

Passwork Cloud was updated right after the fixes were released. No action is required from Passwork Cloud customers.

Docker installation

Run these commands on the server, in the directory that contains docker-compose.yml.

Check the PHP version:

docker exec -it passwork_php php -v

Pull the new image and recreate the PHP containers:

docker compose pull
docker compose up -d --force-recreate php-fpm cron

Create a backup and confirm that the dump appears in ./backup/:

./db-backup.sh

The first line of the output must show PHP 8.3.36 or newer.

If the version is older, the new image was not applied. Contact Support rather than leaving the server in that state.

After the check, open the Passwork web interface and confirm that it loads.

Manual installation

If you installed Passwork 7 or later without Docker, update PHP to the patched release (8.3.36 or newer), restart PHP, and confirm the version with php -v.

OS-specific instructions are in the PHP update guides.

Warnung: Kritische PHP-Schwachstellen. CVE-2026-109618 und CVE-2026-109619 können es einem nicht authentifizierten Angreifer ermöglichen, Code auf einem Server auszuführen, auf dem PHP läuft, einschließlich PHP-FPM. Beide werden auf CVSS v4.0 mit 9,2 bewertet, und laut dem PHP-Projekt ist ein Update die einzige vollständige Abhilfe. Administratoren von On-Premise-Installationen von Passwork sollten PHP auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 aktualisieren.

Update vom PHP-Projekt: Korrekturen veröffentlicht

Das PHP-Projekt hat am 20. Oktober ein kritisches Sicherheitsrelease angekündigt und am 21. Oktober veröffentlicht. PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 beheben beide Schwachstellen. Das Advisory betrifft jede PHP-Installation, die Webanfragen verarbeitet, einschließlich PHP-FPM, und hält fest, dass „es keine vollständigen Gegenmaßnahmen gibt, ein Update ist die einzig sichere Wahl.“

Self-hosted-Installationen: Update-Plan

Administratoren von Self-hosted-Installationen müssen das PHP-FPM, das Passwork ausliefert, auf die korrigierte Version ihres Branches aktualisieren, neu starten und die Version am PHP-FPM-Binary prüfen, nicht in einer Shell. Beginnen Sie mit Instanzen, die aus dem Internet erreichbar sind.

Bevor Sie Änderungen an der Produktivumgebung vornehmen:

• Erstellen Sie einen Snapshot der Datenbank und der Konfiguration und proben Sie die Wiederherstellung auf einem Ersatzhost, falls Sie dies in letzter Zeit nicht getan haben.
• Verwenden Sie die korrigierte Version des Branches, den Sie bereits einsetzen. Der Wechsel auf einen anderen Branch ist eine eigene Änderung, die einen separaten Test mit Ihrer Passwork-Version erfordert.
• Installieren Sie Builds ausschließlich aus Ihrer Distribution, von Ihrem Hersteller oder von php.net. Quell-Builds und Windows-Binaries finden Sie auf der PHP-Downloadseite. Distributions- und Long-Term-Support-Anbieter haben die Patches vorab erhalten. Suchen Sie daher zuerst nach deren Paketen, bevor Sie etwas kompilieren.

Spielen Sie das Update anschließend so ein, wie Sie PHP installiert haben (per Paket oder Container-Image), starten Sie den Dienst neu und prüfen Sie, ob das PHP-FPM, das Passwork ausliefert, eine korrigierte Version meldet. Das PHP in der Kommandozeile kann eine andere Version melden als PHP-FPM. Prüfen Sie daher die Komponente, die Webanfragen verarbeitet.

Wenn ein sofortiges Update nicht möglich ist

Beschränken Sie bis zur Installation des Updates den Kreis derer, die Passwork erreichen können. Stellen Sie es hinter ein VPN oder beschränken Sie es auf einen per Allowlist freigegebenen Netzwerkbereich, und erfassen Sie zuvor alle Clients, die von außen zugreifen: Remote-Mitarbeiter, mobile Apps, Browser-Erweiterungen, API- und CLI-Jobs. Jeder von ihnen funktioniert nicht mehr, wenn Sie den Zugriff einschränken, ohne ihn freizugeben.

Das PHP-Advisory nennt außerdem Übergangseinstellungen für jede CVE, die Speicherlimits, Grenzen für die Anfragegröße und den Upload-Fortschritt von Sitzungen betreffen. Sie schließen einzelne Angriffspfade, machen eine Installation aber nicht sicher. Testen Sie sie vor dem Produktiveinsatz auf einer Staging-Instanz, da sie das Verhalten bei Speicher, Uploads und Sitzungen verändern.

Advertencia: vulnerabilidades críticas en PHP. CVE-2026-109618 y CVE-2026-109619 pueden permitir que un atacante no autenticado ejecute código en un servidor que ejecuta PHP, incluido PHP-FPM. Ambas obtienen una puntuación de 9,2 en CVSS v4.0, y el proyecto PHP indica que actualizar es la única corrección completa. Los administradores de Passwork on-premise deberían actualizar PHP a 8.5.12, 8.4.27, 8.3.36 u 8.2.35.

Novedades de PHP: Correcciones publicadas

El proyecto PHP anunció una versión de seguridad crítica el 20 de octubre y la publicó el 21 de octubre. PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 corrigen ambas vulnerabilidades. El aviso abarca todas las instalaciones de PHP que atienden solicitudes web, incluido PHP-FPM, y afirma que «no existen mitigaciones completas, actualizar es la única opción segura».

Instalaciones self-hosted: Plan de actualización

Los administradores de instalaciones self-hosted deben actualizar el PHP-FPM que atiende a Passwork a la versión corregida de su rama, reiniciarlo y verificar la versión en el binario de PHP-FPM y no en una shell. Empiece por las instancias accesibles desde internet.

Antes de modificar el entorno de producción:

• Cree un snapshot de la base de datos y de la configuración, y pruebe la restauración en un host de repuesto si no lo ha hecho recientemente.
• Utilice la versión corregida de la rama que ya ejecuta. Cambiar a otra rama es un cambio independiente que requiere su propia prueba con la versión de Passwork en uso.
• Instale compilaciones solo de la distribución, del proveedor o de php.net. Las compilaciones desde el código fuente y los binarios de Windows están en la página de descargas de PHP, y los proveedores de distribuciones y de soporte a largo plazo recibieron los parches con antelación, por lo que debe buscar sus paquetes antes de compilar nada.

A continuación, aplique la actualización del mismo modo en que instaló PHP, mediante un paquete o una imagen de contenedor, reinicie el servicio y confirme que el PHP-FPM que atiende a Passwork informa de una versión corregida. El PHP de línea de comandos puede informar de una versión distinta a la de PHP-FPM, así que compruebe la del que atiende las solicitudes web.

Si no es posible actualizar de inmediato

Hasta que se instale la actualización, limite quién puede acceder a Passwork. Sitúe Passwork detrás de una VPN o restrinja el acceso a un rango de red incluido en una lista de permitidos, y antes enumere todos los clientes que se conectan desde el exterior: personal remoto, aplicaciones móviles, extensiones de navegador y tareas de API y de CLI. Cada uno de ellos deja de funcionar si se restringe el acceso sin permitirlo.

El aviso de PHP también enumera configuraciones provisionales para cada CVE, relativas a los límites de memoria, los límites de tamaño de las solicitudes y el progreso de carga de las sesiones. Cierran vías de ataque concretas, pero no hacen que una instalación sea segura. Pruébelas en una instancia de staging antes de pasar a producción, porque modifican el comportamiento de la memoria, de las cargas y de las sesiones.

Aviso: vulnerabilidades críticas do PHP. As CVE-2026-109618 e CVE-2026-109619 podem permitir que um atacante não autenticado execute código num servidor que corre PHP, incluindo PHP-FPM. Ambas têm uma pontuação de 9,2 no CVSS v4.0 e o projeto PHP indica que a atualização é a única correção completa. Os administradores do Passwork autoalojado devem atualizar o PHP para a versão 8.5.12, 8.4.27, 8.3.36 ou 8.2.35.

Atualização do PHP: Correções publicadas

O projeto PHP anunciou uma versão de segurança crítica a 20 de outubro e publicou-a a 21 de outubro. As versões PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 corrigem ambas as vulnerabilidades. O aviso abrange todas as instalações de PHP que processam pedidos web, incluindo PHP-FPM, e afirma que «não existem mitigações completas, a atualização é a única opção segura.»

Instalações autoalojadas: plano de atualização

Os administradores de instalações autoalojadas devem atualizar o PHP-FPM que serve o Passwork para a versão corrigida do respetivo ramo, reiniciá-lo e verificar a versão no binário do PHP-FPM, e não numa shell. Comece pelas instâncias acessíveis a partir da internet.

Antes de intervir em produção:

• Crie um snapshot da base de dados e da configuração e ensaie o restauro num anfitrião de reserva, caso não o tenha feito recentemente.
• Escolha a versão corrigida do ramo que já utiliza. A mudança para outro ramo é uma alteração distinta, que exige um teste próprio com a versão do Passwork instalada.
• Instale apenas compilações da sua distribuição, do seu fornecedor ou de php.net. As compilações a partir do código-fonte e os binários para Windows encontram-se na página de transferências do PHP, e os fornecedores de distribuições e de suporte de longo prazo receberam as correções antecipadamente, pelo que convém procurar os respetivos pacotes antes de compilar seja o que for.

Em seguida, aplique a atualização da mesma forma que instalou o PHP, através de um pacote ou de uma imagem de contentor, reinicie o serviço e confirme que o PHP-FPM que serve o Passwork indica uma versão corrigida. O PHP de linha de comandos pode indicar uma versão diferente da do PHP-FPM, por isso importa verificar a que processa os pedidos web.

Se não for possível atualizar de imediato

Até a atualização estar instalada, restrinja quem pode aceder ao Passwork. Coloque-o atrás de uma VPN ou limite-o a um intervalo de rede incluído na lista de permissões e, primeiro, enumere todos os clientes que se ligam do exterior: colaboradores remotos, aplicações móveis, extensões de navegador, tarefas de API e CLI. Cada um deixa de funcionar se o acesso for restringido sem que seja autorizado.

O aviso do PHP enumera também definições provisórias para cada CVE, relativas a limites de memória, limites de tamanho de pedidos e progresso de carregamento de ficheiros na sessão. Estas definições fecham vias de ataque individuais, mas não tornam uma instalação segura. Teste-as numa instância de teste (staging) antes de as aplicar em produção, porque alteram o comportamento da memória, dos carregamentos e das sessões.

Warning: critical PHP vulnerabilities. CVE-2026-109618 and CVE-2026-109619 can allow an unauthenticated attacker to run code on a server that runs PHP, PHP-FPM included. Both score 9.2 on CVSS v4.0, and the PHP project says updating is the only complete fix. On-premise Passwork administrators should move PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35.

Update from PHP: Fixes released

The PHP project announced a critical security release on 20 October and published it on 21 October. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix both vulnerabilities. The advisory covers every PHP installation that serves web requests, PHP-FPM included, and states that "there are no complete mitigations, updating is the only safe choice."

Self-hosted installations: update plan

Administrators of self-hosted installations must update the PHP-FPM that serves Passwork to the fixed release for their branch, restart it, and verify the version on the PHP-FPM binary rather than in a shell. Start with instances reachable from the internet.

Before you touch production:

• Snapshot the database and configuration, and rehearse the restore on a spare host if you have not done so recently.
• Take the fixed release of the branch you already run. Moving to a different branch is a separate change that needs its own test against your Passwork version.
• Install builds only from your distribution, your vendor, or php.net. Source builds and Windows binaries are on the PHP downloads page, and distribution and long-term support vendors received the patches in advance, so look for their packages before compiling anything.

Then apply the update the way you installed PHP, through a package or a container image, restart the service, and confirm that the PHP-FPM serving Passwork reports a fixed version. The command-line PHP can report a different version than PHP-FPM, so check the one that handles web requests.

If you cannot update right away

Until the update is installed, narrow who can reach Passwork. Put it behind a VPN or limit it to an allow-listed network range, and list every client that connects from outside first: remote staff, mobile apps, browser extensions, API and CLI jobs. Each of them stops working if you restrict access without allowing it.

The PHP advisory also lists interim settings for each CVE, covering memory limits, request size limits, and session upload progress. They close individual attack paths and do not make an installation safe. Test them on a staging instance before production, because they change memory, upload, and session behavior.

Há alguns anos, o conselho habitual era simples: avaliar os fornecedores, assinar um acordo de confidencialidade (NDA) e aplicar um questionário anual. Depois vieram o SolarWinds, depois o MOVEit e depois o XZ Utils, um backdoor introduzido ao longo de dois anos através de contribuições legítimas para projetos de código aberto e detetado por um engenheiro que reparou num processo a ser executado 500 ms mais lento do que deveria. Todos estes ataques entraram através de uma relação de confiança.

O padrão repete-se em todos os grandes incidentes. O envolvimento de terceiros representa já 48 % de todas as violações de dados (contra 30 % no ano anterior), segundo o Data Breach Investigations Report (DBIR) de 2026 da Verizon, e um comprometimento médio da cadeia de abastecimento custa 4,91 milhões de dólares e demora 267 dias a conter, segundo o Cost of a Data Breach Report de 2025 da IBM. 

A maioria das organizações continua a responder com questionários e auditorias anuais. Têm o seu lugar, mas um questionário não impede uma violação. Revogar os privilégios permanentes de um fornecedor impede. Este guia trata a segurança da cadeia de abastecimento como o que realmente é: um problema de gestão de identidades e acessos (IAM) e de controlo de credenciais, com uma camada de conformidade por cima.

Pontos principais

• O envolvimento de terceiros representa já 48 % de todas as violações de dados, contra 30 % no ano anterior, segundo o DBIR de 2026 da Verizon. Os ataques à cadeia de abastecimento são o vetor de violação dominante.
• Um comprometimento médio da cadeia de abastecimento custa 4,91 milhões de dólares e demora 267 dias a conter. Este tempo de permanência é o que torna tão perigosos os privilégios permanentes de fornecedores: os atacantes não precisam de agir depressa se as credenciais nunca expiram.
• Todos os grandes incidentes na cadeia de abastecimento entraram através de uma relação de confiança. SolarWinds, MOVEit, XZ Utils: em cada caso, o atacante utilizou um acesso que já estava atribuído e em que já se confiava.
• Os questionários e as auditorias anuais não impedem violações. Revogar os privilégios permanentes de fornecedores impede. Os controlos que contam são técnicos: armazenamento de credenciais em cofre, acesso just-in-time (JIT), controlo de acesso baseado em funções (RBAC) limitado ao âmbito do contrato e autenticação multifator (MFA) resistente a phishing.
• A NIS2, o DORA e o Cyber Resilience Act (CRA) da UE tornam a segurança da cadeia de abastecimento uma obrigação legal. O artigo 21.º da NIS2, os artigos 28.º a 30.º do DORA e os requisitos do CRA aplicam-se de forma escalonada até 2027.
• 70 % dos 50 principais fornecedores partilhados pelas empresas da Global 2000 têm pelo menos uma vulnerabilidade KEV (Known Exploited Vulnerabilities) por corrigir, segundo o Third-Party Breach Report de 2026 da Black Kite.

O que é a gestão de ciberriscos da cadeia de abastecimento (C-SCRM)?

A gestão de ciberriscos da cadeia de abastecimento (C-SCRM) é a disciplina que consiste em identificar, avaliar e mitigar os riscos de cibersegurança que têm origem na rede alargada de fornecedores, prestadores de serviços e dependências de software de uma organização. Abrange desde as ferramentas SaaS utilizadas pelos programadores até ao fornecedor de serviços geridos (MSP) com acesso de administrador ao ambiente de produção.

A C-SCRM situa-se na interseção entre aprovisionamento, segurança de TI e conformidade. NIST SP 800-161 Rev. 1 fornece o quadro de referência federal mais detalhado nesta matéria, ao definir a C-SCRM como um processo estruturado para gerir a exposição a riscos de cibersegurança ao longo do ciclo de vida da cadeia de abastecimento, desde a seleção inicial do fornecedor até à cessação do contrato e à revogação de acessos.

O âmbito é mais amplo do que a maioria das equipas imagina. A cadeia de abastecimento inclui:

• Fornecedores de software e dependências de código aberto
• Fornecedores de infraestrutura cloud e de SaaS
• Prestadores de serviços geridos e de apoio de TI
• Fabricantes de hardware e fornecedores de firmware
• Empresas de serviços profissionais com acesso à rede ou a dados

Cada um destes elementos é um potencial ponto de entrada. Os incidentes SolarWinds, MOVEit e XZ Utils exploraram esse ponto de entrada de formas diferentes.

O estado dos ataques à cadeia de abastecimento em 2025–2026

Os ataques à cadeia de abastecimento atingiram níveis recorde em 2025–2026. O DBIR de 2026 da Verizon registou o envolvimento de terceiros em 48 % de todas as violações analisadas, o valor mais elevado da história do relatório e um aumento de 60 % face aos 30 % do ano anterior. O Cost of a Data Breach Report de 2025 da IBM estima o custo médio de um comprometimento da cadeia de abastecimento em 4,91 milhões de dólares, com um ciclo de vida médio de 267 dias entre a deteção e a contenção.

Os agentes de ameaças perceberam que comprometer um fornecedor de confiança dá acesso, em simultâneo, a dezenas ou centenas de organizações a jusante. A economia favorece o atacante: uma intrusão bem-sucedida, multiplicada por toda a base de clientes de um fornecedor.

Segundo o Third-Party Breach Report de 2026 da Black Kite, 70 % dos 50 principais fornecedores partilhados pelas empresas da Global 2000 têm pelo menos uma vulnerabilidade por corrigir do catálogo Known Exploited Vulnerabilities (KEV) da CISA. Estes riscos não são teóricos: a CISA inclui entradas no catálogo KEV precisamente porque estão a ser ativamente exploradas em ambiente real.

Lições do SolarWinds, do MOVEit e do XZ Utils

Os três incidentes partilham um denominador comum: o vetor de acesso inicial era de confiança. Software de confiança, fornecedor de confiança, contribuidor de confiança. Uma vez dentro, o atacante moveu-se lateralmente com credenciais e acessos que já estavam atribuídos.

SolarWinds (2020)

Os atacantes comprometeram diretamente o pipeline de compilação e inseriram um backdoor numa atualização de software assinada, distribuída aos clientes como uma correção de rotina. Cerca de 18 000 organizações instalaram-na. As consequências jurídicas prolongaram-se durante anos: a SEC apresentou uma ação de execução civil contra a SolarWinds e o seu CISO em outubro de 2023, e o processo foi finalmente arquivado na totalidade em 2025.

A lição: os controlos de integridade do software e a visibilidade sobre as SBOM (listas de materiais de software, Software Bill of Materials) importam tanto como os controlos de perímetro de rede, e a exposição a responsabilidade decorrente do comprometimento de um pipeline de compilação vai muito além da violação inicial.

MOVEit (2023)

Uma vulnerabilidade zero-day de injeção de SQL (CVE-2023-34362) num produto de transferência gerida de ficheiros deu ao grupo de ransomware Cl0p acesso a dados de mais de 2700 organizações, muitas das quais não tinham qualquer relação direta com o MOVEit, mas foram afetadas pela utilização que os seus fornecedores faziam dele. O número final de vítimas ascendeu a cerca de 95 milhões de pessoas. 

A lição: a superfície de ataque inclui o software que os fornecedores utilizam, e não apenas o software utilizado pela própria organização.

XZ Utils (2024)

Uma campanha de engenharia social que durou vários anos introduziu um backdoor numa biblioteca de compressão de código aberto muito utilizada. O atacante contribuiu com código legítimo durante dois anos antes de introduzir a carga maliciosa, e o backdoor não foi detetado por nenhum processo formal de segurança, mas por um engenheiro da Microsoft que reparou num atraso de 500 ms nos inícios de sessão SSH. 

A lição: o risco das dependências de código aberto é real, as SBOM são a única forma sistemática de o acompanhar e os controlos de deteção têm de cobrir o comportamento, e não apenas assinaturas.

Principais riscos de fornecedores na cadeia de abastecimento moderna

As cinco categorias de risco mais comuns na cadeia de abastecimento são:

• Credenciais partilhadas e controlo de acessos deficiente
• Vulnerabilidades em dependências de software
• Adulteração de hardware e de componentes
• Shadow AI e exposição de dados a terceiros
• Risco de concentração de fornecedores

Cada uma exige uma resposta de controlo distinta. As falhas de credenciais partilhadas são um problema de processo. A adulteração de hardware exige a verificação física da proveniência.

Credenciais partilhadas e controlo de acessos deficiente

O risco mais comum e mais evitável da cadeia de abastecimento é também o menos apelativo: as contas partilhadas. Uma equipa de suporte de um fornecedor recebe um único conjunto de credenciais para aceder ao ambiente. Essas credenciais são partilhadas por todo o pessoal do fornecedor, guardadas numa folha de cálculo ou numa troca de e-mails e nunca são objeto de rotação depois de o contrato terminar.

Quando esse fornecedor sofre uma violação, ou quando um colaborador descontente sai, não há forma de saber quem utilizou essas credenciais, quando, nem a que acedeu. Não existe registo de auditoria. Não há forma de revogar o acesso a uma só pessoa sem alterar as credenciais de todos.

O DBIR de 2026 da Verizon identifica as falhas de autenticação (MFA ausente ou contornada, credenciais roubadas) como o principal mecanismo nos cenários de violação por terceiros. Trata-se de uma falha de processo.

Vulnerabilidades da cadeia de abastecimento de software e necessidade de SBOM

Uma lista de materiais de software (SBOM) é um inventário legível por máquina de todos os componentes de um produto de software: bibliotecas, dependências, versões e respetivas vulnerabilidades conhecidas. A Ordem Executiva 14028 dos EUA (2021) tornou obrigatórias as SBOM para o software vendido a agências federais. O Cyber Resilience Act (CRA) da UE alarga requisitos semelhantes aos produtos vendidos no mercado europeu, com obrigações de comunicação de vulnerabilidades aplicáveis a partir de setembro de 2026 e requisitos completos para os produtos a partir de dezembro de 2027.

Sem uma SBOM, não é possível responder em menos de 24 horas à pergunta «Estamos a executar a versão vulnerável do Log4j?». Com uma, é. Essa diferença de velocidade separa um incidente contido de uma violação que demora 267 dias a resolver.

Adulteração de hardware e de componentes

O risco da cadeia de abastecimento de hardware é distinto do risco de software e muitas vezes subestimado. Componentes contrafeitos ou adulterados (equipamento de rede, hardware de servidor, firmware) podem introduzir backdoors persistentes que sobrevivem à reinstalação do sistema operativo e são invisíveis para os controlos de segurança ao nível do software.

O Cyber Resilience Act da UE aborda expressamente os produtos de hardware com elementos digitais, ao exigir que os fabricantes avaliem e documentem a segurança da cadeia de abastecimento dos componentes físicos. Para as organizações que adquirem infraestrutura de rede ou sistemas de controlo industrial, isto implica verificar a proveniência dos componentes, exigir aos fornecedores atestações de integridade do firmware e manter um inventário das versões de hardware equivalente a uma SBOM de software.

Shadow AI e exposição de dados a terceiros

Verizon, no seu DBIR de 2026, identifica a shadow AI como um dos três principais comportamentos internos de risco: colaboradores que utilizam ferramentas de IA não autorizadas, que tratam dados da organização fora dos canais aprovados. O ângulo da cadeia de abastecimento: muitas destas ferramentas são produtos SaaS de terceiros, com as suas próprias políticas de retenção de dados, acordos com subcontratantes ulteriores e posturas de segurança que a organização nunca avaliou.

Quando um programador cola credenciais de uma base de dados num assistente de IA para depurar uma consulta, essas credenciais podem ser retidas, registadas ou utilizadas para treinar modelos. O risco do fornecedor não se limita ao fornecedor de IA: abrange todos os subcontratantes ulteriores da sua cadeia.

Interrupções de disponibilidade e risco de concentração de fornecedores

Uma falha de segurança na cadeia de abastecimento nem sempre significa uma violação de dados. Falhas de serviço de fornecedores, ataques de ransomware a fornecedores críticos e pontos únicos de falha em infraestruturas partilhadas podem interromper totalmente as operações. O mandato de resiliência operacional do DORA existe precisamente porque o setor financeiro da UE reconheceu que o risco de disponibilidade associado a terceiros de TIC é tão material como o risco de confidencialidade.

O risco de concentração agrava esta situação: quando 70 % das empresas da Forbes Global 2000 partilham os mesmos 50 principais fornecedores, um único comprometimento propaga-se em grande escala. Mapear as dependências críticas de fornecedores e manter planos de continuidade documentados para falhas de fornecedores de Nível 1 é um requisito do artigo 28.º do DORA para as entidades financeiras.

Requisitos regulamentares europeus e internacionais de segurança da cadeia de abastecimento

A NIS2, o DORA e o Cyber Resilience Act da UE formam, em conjunto, o quadro regulamentar vinculativo para a segurança da cadeia de abastecimento no mercado europeu. NIST CSF 2.0 e SP 800-161 são quadros de referência dos EUA, e não obrigações legais da UE, mas são amplamente referenciados por organizações multinacionais e fornecem pormenor operacional que complementa os requisitos da UE.

Diretiva NIS2 (artigo 21.º)

O artigo 21.º da NIS2 exige que as entidades abrangidas implementem «segurança da cadeia de abastecimento, incluindo aspetos relacionados com a segurança respeitantes às relações entre cada entidade e os seus fornecedores ou prestadores de serviços diretos». Trata-se de uma obrigação legal para as entidades essenciais e importantes em 18 setores, com uma fiscalização que os Estados-Membros da UE começaram a aplicar no final de 2024.

Na prática, o artigo 21.º significa que é necessário avaliar a postura de segurança dos fornecedores diretos, incluir requisitos de segurança nos contratos e manter um processo documentado para gerir incidentes relacionados com fornecedores. No que respeita à gestão de credenciais, isto traduz-se em: sem contas partilhadas, procedimentos documentados de atribuição e revogação de acessos e registos de auditoria que possam ser apresentados numa inspeção de supervisão.

Para uma análise detalhada de como a NIS2 se relaciona com os requisitos de controlo de acessos, consulte o guia de conformidade com a NIS2 do Passwork.

DORA (Regulamento sobre a Resiliência Operacional Digital)

O DORA aplica-se às entidades financeiras e aos respetivos prestadores terceiros de serviços de TIC que operam na UE. Os artigos 28.º a 30.º estabelecem um quadro detalhado de gestão do risco de terceiros de TIC, incluindo requisitos para manter um registo de todos os prestadores de TIC, realizar avaliações de risco antes da integração e assegurar que os contratos incluem disposições sobre direitos de auditoria e notificação de incidentes.

O DORA introduz também o conceito de «prestadores terceiros críticos de serviços de TIC» (CTPP), que as Autoridades Europeias de Supervisão podem designar para supervisão direta. Se a organização for um CTPP, ou depender de um, o escrutínio dos seus controlos de segurança da cadeia de abastecimento é substancialmente mais elevado. O risco de interrupção da disponibilidade descrito acima é tanto uma preocupação do DORA como de segurança: o artigo 28.º exige expressamente planos de continuidade documentados para as dependências críticas de terceiros.

Cyber Resilience Act (CRA) da UE

O CRA foi adotado em 2024 e aplica-se de forma escalonada. As obrigações de comunicação de vulnerabilidades e incidentes produzem efeitos a partir de 11 de setembro de 2026. Os requisitos completos para os produtos, incluindo a obrigatoriedade de SBOM e as avaliações de conformidade de produtos com elementos digitais, aplicam-se a partir de 11 de dezembro de 2027. As organizações que vendem hardware ou software ligado no mercado da UE têm de iniciar já o trabalho de conformidade: o prazo de 2027 chega mais depressa do que a maioria dos ciclos de desenvolvimento de produto permite.

NIST CSF 2.0 e NIST SP 800-161

NIST CSF 2.0, publicado em fevereiro de 2024, acrescentou «Govern» como sexta função essencial. A subcategoria GV.SC aborda expressamente a gestão do risco da cadeia de abastecimento e exige que as organizações integrem a C-SCRM na governação de riscos da empresa, em vez de a tratarem como um projeto de TI separado. Para as organizações da UE, o CSF 2.0 não é um requisito legal, mas oferece uma estrutura operacional útil que se articula bem com as obrigações da NIS2 e do DORA.

NIST SP 800-161 Rev. 1 fornece o pormenor operacional: como realizar avaliações de fornecedores, que controlos exigir nos contratos e como estruturar um programa de C-SCRM ao longo de todo o ciclo de vida da aquisição. Para os contratantes federais dos EUA, o alinhamento com a SP 800-161 é cada vez mais um requisito de contratação.

Como proteger o acesso de fornecedores: O modelo técnico

Os quatro controlos de maior impacto para a segurança do acesso de fornecedores são o RBAC limitado ao âmbito do contrato, o acesso privilegiado just-in-time, o armazenamento centralizado de credenciais em cofre e a MFA resistente a phishing. Aplicados por esta ordem, tratam os modos de falha mais comuns (privilégios permanentes, contas partilhadas e lacunas de autenticação) sem exigir nova infraestrutura na maioria dos ambientes.

Aplicar um controlo de acesso baseado em funções (RBAC) rigoroso

O controlo de acesso baseado em funções (RBAC) atribui permissões a funções, e não a indivíduos. Um engenheiro de suporte de um fornecedor recebe a função «monitorização de produção só de leitura», e não uma conta de administrador pessoal. Quando o contrato termina, remove-se a atribuição da função. Quando o fornecedor substitui elementos da sua equipa, não é necessário acompanhar contas individuais: a função define o que está acessível.

No acesso de fornecedores em particular, o RBAC deve limitar-se ao mínimo necessário para o contrato. Um fornecedor de bases de dados que realiza uma auditoria de desempenho não precisa de acesso de escrita à configuração das aplicações. A função deve ser definida antes de atribuir o acesso, e não depois.

Implementar acesso privilegiado just-in-time (JIT)

O acesso just-in-time (JIT) significa que as credenciais privilegiadas são emitidas para uma janela temporal definida e revogadas automaticamente quando essa janela termina. Um engenheiro do fornecedor pede acesso para uma janela de manutenção de duas horas; o sistema concede-o, regista a sessão e revoga-o à segunda hora, independentemente de o engenheiro se lembrar de terminar a sessão.

O acesso JIT elimina os privilégios permanentes: o acesso persistente e sempre ativo que os atacantes exploram durante os 267 dias de tempo médio de permanência numa violação da cadeia de abastecimento. Não há nada para roubar se as credenciais expirarem antes de o atacante as poder utilizar. O JIT é particularmente eficaz em cenários break-glass: o acesso de emergência de fornecedores durante um incidente, em que a rapidez conta, mas a responsabilização também.

Armazenamento seguro das credenciais de fornecedores em cofre

As contas partilhadas de fornecedores são um risco. A alternativa é um cofre de credenciais: um repositório centralizado e cifrado em que as credenciais dos fornecedores são detidas pela organização, e não pelo fornecedor. O fornecedor autentica-se no cofre, obtém as credenciais para a sua sessão e o cofre regista cada evento de acesso.

Esta abordagem proporciona um registo de auditoria completo de quem acedeu a quê e quando, a capacidade de fazer a rotação das credenciais sem coordenação com o fornecedor, a revogação automática quando a relação com o fornecedor termina e provas de conformidade para os requisitos de direitos de auditoria do artigo 21.º da NIS2 e do artigo 30.º do DORA.

O gestor de palavras-passe e segredos de nível empresarial do Passwork permite a partilha de credenciais com limite temporal, o registo de sessões e a integração com a infraestrutura AD/LDAP e SSO, com cifragem do lado do cliente AES-256 e uma REST API completa para integração nos fluxos de provisionamento existentes.

Exigir MFA resistente a phishing a terceiros

A MFA é o controlo com maior retorno do investimento no acesso de terceiros. O DBIR de 2026 da Verizon atribui a maioria dos cenários de violação por terceiros a falhas de autenticação, e a maior parte dessas falhas deve-se à ausência de MFA, e não à sua contornação.

Para o acesso privilegiado de fornecedores a sistemas de produção, o nível mínimo deve ser a MFA resistente a phishing: chaves de hardware FIDO2/WebAuthn ou passkeys, e não OTP por SMS. A MFA por SMS é vulnerável a SIM swapping e a proxies de phishing em tempo real. Deve exigir-se contratualmente aos fornecedores MFA resistente a phishing como condição de acesso. Deve incluir-se essa exigência na adenda de segurança dos fornecedores, e não apenas na política interna.

A maioria das falhas de controlo de acesso descritas neste guia tem a mesma causa de fundo: credenciais de fornecedores que nunca foram devidamente guardadas em cofre, limitadas ao âmbito necessário ou revogadas. O Passwork responde diretamente a esse problema: armazenamento centralizado de credenciais em cofre, acesso baseado em funções, partilha com limite temporal e um registo de auditoria completo associado a identidades nominais. Disponível em modo autoalojado ou como implementação na cloud, integra-se com AD/LDAP e SAML SSO e tem certificação ISO 27001.

Criar um modelo de avaliação do risco de fornecedores

Um modelo de avaliação do risco de fornecedores classifica os terceiros por nível de acesso e aplica requisitos de segurança proporcionais a cada nível. O modelo de 5 níveis apresentado abaixo vai desde os fornecedores de Nível 1, com acesso privilegiado à produção, que exigem avaliações de segurança completas e revisões anuais, até aos fornecedores de Nível 5, sem acesso a dados nem a sistemas, para os quais basta a due diligence de aquisição habitual.

O modelo de classificação de risco de fornecedores em 5 níveis:

A classificação determina o esforço proporcional. Não é necessário um relatório completo de teste de intrusão do fornecedor de material de escritório. É necessário, sim, o do MSP com acesso de administrador ao Active Directory.

Lista de verificação de controlo de acesso de fornecedores

A seguinte lista de verificação de acesso de fornecedores pré-auditoria corresponde diretamente aos requisitos do artigo 21.º da NIS2, do artigo 28.º do DORA e da publicação NIST SP 800-161. Deve ser utilizada na integração do fornecedor e em cada revisão anual.

Antes da atribuição do acesso:

•  Fornecedor classificado por nível, com base no nível de acesso
•  Âmbito mínimo de acesso necessário definido por escrito
•  Pessoas identificadas nominalmente (sem contas partilhadas ou genéricas)
•  Requisito de MFA confirmado e testado
•  Acesso atribuído através do cofre de credenciais, e não por partilha direta de credenciais
•  Registo de sessões ativado

Durante o contrato:

•  Âmbito de acesso revisto se o âmbito do contrato se alterar
•  Padrões de acesso invulgares assinalados para revisão
•  Cláusula de notificação de incidentes do fornecedor ativa no contrato

Revogação de acessos:

•  Evento desencadeador da saída do fornecedor definido (fim do contrato, mudança de pessoal, incidente)
•  Credenciais sujeitas a rotação imediata na saída do fornecedor
•  Acesso ao cofre revogado e registo de auditoria exportado
•  Revisão de acessos documentada para os registos de conformidade

Conclusão: Tornar a segurança da cadeia de abastecimento operacional

As organizações que gerem bem esta área não têm menos fornecedores; têm controlos mais rigorosos sobre a forma como esses fornecedores se autenticam, a que podem aceder e durante quanto tempo.

O modelo técnico é claro: classificar os fornecedores por nível de acesso, eliminar as contas partilhadas, guardar as credenciais centralmente em cofre, aplicar acesso JIT às sessões privilegiadas e exigir MFA resistente a phishing. A NIS2, o DORA e o CRA proporcionam a estrutura de governação e a margem contratual para exigir aos fornecedores o mesmo nível de rigor.

Recomenda-se começar pelos fornecedores de Nível 1, ou seja, os que têm acesso privilegiado a sistemas de produção. Deve auditar-se o âmbito de acesso atual, confirmar a atribuição de contas individuais e verificar que a MFA está ativa. Essa única passagem revela mais riscos acionáveis do que um ano de questionários.

Perguntas frequentes

Qual é a diferença entre segurança da cadeia de abastecimento e gestão do risco de fornecedores?

A gestão do risco de fornecedores (VRM) é a disciplina mais ampla, que abrange os riscos financeiros, operacionais, reputacionais e de cibersegurança associados a terceiros. A segurança da cadeia de abastecimento é o subconjunto específico de cibersegurança: proteger sistemas, dados e a integridade do software contra ameaças que entram através das relações com fornecedores. A VRM fundamenta as decisões de aquisição; a segurança da cadeia de abastecimento rege os controlos técnicos de acesso e a integridade do software.

Que regulamentos exigem controlos de segurança da cadeia de abastecimento em 2025–2026?

O artigo 21.º da Diretiva NIS2 exige que as entidades essenciais e importantes da UE avaliem e giram os riscos de segurança dos fornecedores. Os artigos 28.º a 30.º do DORA impõem obrigações de gestão do risco de terceiros de TIC às entidades financeiras da UE. O Cyber Resilience Act da UE exige a comunicação de vulnerabilidades a partir de setembro de 2026 e requisitos completos de SBOM e de conformidade a partir de dezembro de 2027. Nos EUA, a NIST SP 800-161 e a Ordem Executiva 14028 definem as expectativas de C-SCRM para os contratantes federais.

O que é o acesso just-in-time (JIT) e porque é importante para a segurança de fornecedores?

O acesso JIT emite credenciais privilegiadas para uma janela temporal definida e revoga-as automaticamente quando essa janela termina. Elimina os privilégios permanentes, ou seja, o acesso persistente que os atacantes exploram durante o tempo de permanência prolongado típico das violações da cadeia de abastecimento. Os dados da IBM de 2025 mostram que os comprometimentos da cadeia de abastecimento demoram, em média, 267 dias a identificar e conter; o acesso JIT reduz a janela explorável a horas, e não a meses.

Como reduzem as SBOM o risco da cadeia de abastecimento?

Uma lista de materiais de software (SBOM) é um inventário legível por máquina de todos os componentes de software e respetivas versões. Quando é divulgada uma nova vulnerabilidade, como a Log4Shell em 2021, uma SBOM permite determinar em minutos se algum dos sistemas ou software fornecido por fornecedores contém o componente afetado. Sem uma SBOM, essa mesma determinação pode demorar dias ou semanas, período durante o qual a vulnerabilidade permanece por corrigir e explorável.

O que deve incluir uma adenda de segurança contratual para fornecedores?

No mínimo: a exigência de contas individuais nominais (sem credenciais partilhadas), MFA resistente a phishing para o acesso privilegiado, obrigações de notificação no prazo de 24 a 72 horas após um incidente de segurança, direitos de auditoria que permitam à organização rever os registos de acesso e um processo de saída definido, incluindo a rotação de credenciais. O artigo 21.º da NIS2 e o artigo 30.º do DORA exigem disposições contratuais de segurança: a adenda é a prova de conformidade.

Como devem as organizações classificar os fornecedores para efeitos de avaliação de risco?

A classificação deve basear-se no nível de acesso, e não no valor do contrato nem na dimensão do fornecedor. Uma pequena consultora com acesso de administrador ao ambiente de produção representa um risco mais elevado do que um grande fornecedor de software sem acesso direto a sistemas. O modelo de classificação de risco de fornecedores em 5 níveis apresentado acima oferece uma estrutura prática: do Nível 1 (acesso privilegiado à produção) ao Nível 5 (sem acesso a dados nem a sistemas), com requisitos de avaliação e frequência de revisão dimensionados em conformidade.

Qual é a falha de controlo de acesso mais comum nas violações por terceiros?

Credenciais partilhadas sem responsabilização individual. Um único conjunto de credenciais emitido para uma equipa de um fornecedor, guardado fora de um cofre, nunca sujeito a rotação e nunca revogado quando o contrato termina. O DBIR de 2026 da Verizon identifica as falhas de autenticação como o principal mecanismo nos cenários de violação por terceiros. A solução passa por contas nominais individuais, armazenamento de credenciais em cofre e um processo de saída documentado, e não por tecnologia mais complexa.

O que é o risco da cadeia de abastecimento de hardware e em que difere do risco da cadeia de abastecimento de software?

O risco da cadeia de abastecimento de hardware envolve componentes físicos contrafeitos ou adulterados (equipamento de rede, hardware de servidor, firmware) que podem introduzir backdoors persistentes, invisíveis para os controlos de segurança ao nível do software. Ao contrário das vulnerabilidades de software, a adulteração de hardware sobrevive à reinstalação do sistema operativo. O Cyber Resilience Act da UE aborda diretamente esta questão, ao exigir que os fabricantes documentem a segurança da cadeia de abastecimento dos produtos de hardware com elementos digitais.

Ataques reais à cadeia de abastecimento: Bitwarden CLI, Axios e Vercel

Porquê violar a rede quando os atacantes podem comprometer uma dependência de confiança com milhões de descargas e infiltrar-se em silêncio em milhares de organizações ao mesmo tempo? Três campanhas de 2026 demonstram que os ataques à cadeia de abastecimento já não são incidentes isolados.

Passwork BlogAlex Muntyan

Shadow IT vs shadow AI: Porque é que a IA é a maior ameaça

Os colaboradores utilizam ferramentas de IA que não foram aprovadas, em contas que não é possível monitorizar, com dados que não é possível recuperar. Eis o que o risco representa na realidade e o que a governação tem de abordar.

Passwork BlogAlex Muntyan

Controlos de acesso da NIS2 para a segurança da cadeia de abastecimento

48 % das violações envolvem agora terceiros. O artigo 21.º da NIS2 torna a governação dos acessos de fornecedores uma obrigação legal. Eis como mapear os acessos de fornecedores, aplicar MFA e o princípio do menor privilégio e manter as provas de auditoria que demonstram que os controlos funcionam.

Passwork BlogAlex Muntyan

Pelo terceiro trimestre consecutivo, o Passwork recebeu o distintivo Top Performer do SourceForge, desta vez o de outono de 2026. O SourceForge ajuda os compradores de TI a comparar software empresarial com base em opiniões verificadas de clientes, e esta distinção reflete a experiência sincera e contínua das equipas que utilizam o Passwork em produção.

Desde a distinção de verão, o Passwork acrescentou dois outros reconhecimentos independentes: um lugar na Capterra Shortlist 2026 de gestão de palavras-passe e a distinção Best for User Interface com o distintivo FrontRunners 2026, da Software Advice; ambos, tal como o distintivo do SourceForge, assentam inteiramente em opiniões verificadas de utilizadores e não em juízos editoriais.

O que dizem os clientes sobre o Passwork

Visibilidade sobre quem acedeu a quê, até ao nível de cada palavra-passe. Os registos de atividade detalhados de cada elemento mantêm as auditorias e as implementações on-premises assentes em factos e não em suposições.

«Valorizamos também muito os registos de atividade detalhados disponíveis para cada palavra-passe, que permitem saber quem acedeu a informações sensíveis ou as modificou.» — Systems Administrator

Uma extensão de navegador que acompanha o número de sites com que uma equipa realmente trabalha. Para equipas que gerem dezenas de inícios de sessão por dia, a comodidade do preenchimento automático é o teste diário que os avaliadores continuam a premiar.

«A extensão de navegador é provavelmente a funcionalidade que mais utilizamos, uma vez que mantemos mais de uma centena de sites e esta torna muito cómodo o acesso a todas essas credenciais.» — Software Developer

Capacidades de administração e auditoria que resistem à avaliação. Mesmo as equipas que ainda estão no período de teste apontam as mesmas duas coisas: a facilidade de utilização e a supervisão.

«A nossa experiência inicial com o Passwork tem sido muito positiva. A plataforma é de fácil utilização, oferece sólidas funcionalidades de organização e disponibiliza capacidades úteis de administração e auditoria.» — IT Manager

Sobre a distinção

O SourceForge é o maior diretório mundial de avaliação e comparação de software B2B, com quase 20 milhões de utilizadores mensais a avaliar software empresarial. Atribui o distintivo Top Performer quatro vezes por ano (primavera, verão, outono e inverno) aos produtos que se classificam nos 10 % melhores de mais de 100 000 soluções listadas na plataforma. As classificações dependem exclusivamente do volume, da atualidade e da classificação das avaliações verificadas, sem qualquer intervenção editorial.

«Três trimestres de reconhecimento consistente não são um acaso: são o resultado direto de ouvir as pessoas que utilizam o Passwork todos os dias e de criar aquilo que realmente pedem.» — Alex Muntyan, CEO of Passwork

O Passwork tem uma classificação global de 4,8 em 5 estrelas no SourceForge.

Veja porque é que os avaliadores continuam a colocar o Passwork nos 10 % melhores. Experimentar o Passwork grátis com acesso total.

Passwork distinguido como Best for User Interface e reconhecido como FrontRunner 2026

O Passwork foi distinguido como Best for User Interface na seleção de software de gestão de palavras-passe de 2026 da Software Advice e recebeu o selo FrontRunners 2026.

PassworkPasswork Team

Passwork incluído na Capterra Shortlist 2026

O Passwork obteve um lugar na Capterra Shortlist 2026 de gestão de palavras-passe. O reconhecimento baseia-se em avaliações verificadas que destacam a facilidade de configuração, a migração a partir de ferramentas legadas e uma integração com o navegador que acelera a utilização diária.

PassworkPasswork Team

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

As palavras-passe passam a funcionar também offline. O Passwork 7.7 traz acesso offline seguro com total supervisão do administrador, 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 fluida.

PassworkPasswork Team

Zum dritten Quartal in Folge hat Passwork das Top-Performer-Badge von SourceForge erhalten, diesmal für Herbst 2026. SourceForge hilft IT-Einkäufern, Unternehmenssoftware anhand verifizierter Kundenbewertungen zu vergleichen, und diese Auszeichnung spiegelt die ehrlichen, fortlaufenden Erfahrungen von Teams wider, die Passwork im Produktivbetrieb einsetzen.

Seit der Auszeichnung im Sommer hat Passwork zwei weitere unabhängige Anerkennungen erhalten: einen Platz auf der Capterra Shortlist 2026 für Passwortmanagement sowie die Auszeichnung Best for User Interface mit dem FrontRunners-Badge 2026 von Software Advice. Beide beruhen, wie das SourceForge-Badge, ausschließlich auf verifiziertem Benutzerfeedback und nicht auf redaktioneller Einschätzung.

Das sagen Kunden über Passwork

Einblick, wer worauf zugegriffen hat, bis hinunter zum einzelnen Passwort. Detaillierte Aktivitätsprotokolle pro Eintrag sorgen dafür, dass Audits und On-Premises-Installationen auf Fakten statt auf Vermutungen beruhen.

„Außerdem schätzen wir die detaillierten Aktivitätsprotokolle zu jedem Passwort sehr, die Einblick geben, wer auf sensible Informationen zugegriffen oder sie geändert hat.“ — Systems Administrator

Eine Browser-Erweiterung, die mit der Zahl der Websites mitwächst, mit denen ein Team tatsächlich arbeitet. Für Teams, die täglich Dutzende Logins verwalten, ist der Komfort des automatischen Ausfüllens der tägliche Test, den Rezensenten immer wieder honorieren.

„Die Browser-Erweiterung ist wahrscheinlich die Funktion, die wir am häufigsten nutzen, da wir mehr als hundert Websites betreuen und der Zugriff auf all diese Zugangsdaten damit sehr bequem ist.“ — Software Developer

Administrations- und Audit-Funktionen, die einer Prüfung standhalten. Selbst Teams, die sich noch in der Testphase befinden, nennen dieselben zwei Punkte: Benutzerfreundlichkeit und Kontrolle.

„Unsere ersten Erfahrungen mit Passwork waren sehr positiv. Die Plattform ist benutzerfreundlich, bietet leistungsstarke Organisationsfunktionen und stellt nützliche Administrations- und Audit-Funktionen bereit.“ — IT Manager

Über die Auszeichnung

SourceForge ist das weltweit größte Verzeichnis für Bewertungen und Vergleiche von B2B-Software, mit fast 20 Millionen monatlichen Benutzern, die Unternehmenssoftware evaluieren. SourceForge vergibt das Top-Performer-Badge viermal im Jahr (Frühjahr, Sommer, Herbst und Winter) an Produkte, die zu den besten 10 % von mehr als 100.000 Lösungen auf der Plattform gehören. Die Rankings richten sich ausschließlich nach Anzahl, Aktualität und Bewertung der verifizierten Rezensionen, ohne redaktionellen Einfluss.

„Drei Quartale in Folge Anerkennung sind kein Zufall: Sie sind das direkte Ergebnis davon, dass wir den Menschen zuhören, die Passwork täglich nutzen, und genau das entwickeln, was sie sich wünschen.“ — Alex Muntyan, CEO of Passwork

Passwork hat auf SourceForge eine Gesamtbewertung von 4,8 von 5 Sternen.

Erfahren Sie, warum Rezensenten Passwork immer wieder unter den besten 10 % einordnen. Kostenlose Passwork-Testversion mit vollem Zugriff starten.

Passwork als Best for User Interface ausgezeichnet und als FrontRunner 2026 anerkannt

Passwork wurde in der Auswahl von Software Advice für Passwortmanagement-Software 2026 als Best for User Interface ausgezeichnet und erhielt das FrontRunners-Badge 2026.

PassworkPasswork Team

Passwork in die Capterra Shortlist 2026 aufgenommen

Passwork hat sich einen Platz auf der Capterra Shortlist 2026 für Passwortmanagement gesichert. Die Auszeichnung beruht auf verifizierten Rezensionen, die die einfache Einrichtung, die Migration aus Legacy-Tools und eine Browser-Integration hervorheben, die den täglichen Einsatz beschleunigt.

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 Administrator-Kontrolle, organisationsweite Steuerung von Dateianhängen und fünf neue rollenbasierte Onboarding-Leitfäden für einen reibungsloseren Rollout.

PassworkPasswork Team

Por tercer trimestre consecutivo, Passwork ha obtenido la insignia Top Performer de SourceForge, esta vez la de otoño de 2026. SourceForge ayuda a los responsables de compras de TI a comparar software empresarial a partir de opiniones verificadas de clientes, y este reconocimiento refleja la experiencia sincera y continuada de los equipos que utilizan Passwork en producción.

Desde el reconocimiento de verano, Passwork ha sumado otras dos distinciones independientes: un puesto en la Capterra Shortlist 2026 de gestión de contraseñas y la distinción Best for User Interface con la insignia FrontRunners 2026 de Software Advice; ambas, igual que la insignia de SourceForge, se basan íntegramente en opiniones verificadas de usuarios y no en criterios editoriales.

Lo que opinan los clientes sobre Passwork

Visibilidad sobre quién ha accedido a qué, hasta el nivel de cada contraseña. Los registros de actividad detallados de cada elemento mantienen las auditorías y las instalaciones on-premises basadas en hechos, no en suposiciones.

«También valoramos mucho los registros de actividad detallados disponibles para cada contraseña, que ofrecen visibilidad sobre quién ha accedido a información sensible o la ha modificado.» — Systems Administrator

Una extensión de navegador que se adapta al número de sitios con los que trabaja realmente un equipo. Para los equipos que manejan decenas de inicios de sesión al día, la comodidad del autocompletado es la prueba diaria que los evaluadores siguen premiando.

«La extensión de navegador es probablemente la función que más utilizamos, ya que mantenemos más de un centenar de sitios web y facilita mucho el acceso a todas esas credenciales.» — Software Developer

Funciones de administración y auditoría que resisten una evaluación. Incluso los equipos que aún están en el período de prueba señalan las mismas dos cosas: la facilidad de uso y la supervisión.

«Nuestra experiencia inicial con Passwork ha sido muy positiva. La plataforma es fácil de usar, ofrece sólidas funciones de organización y proporciona útiles capacidades de administración y auditoría.» — IT Manager

Sobre el reconocimiento

SourceForge es el mayor directorio mundial de reseñas y comparación de software B2B, con casi 20 millones de usuarios mensuales que evalúan software empresarial. Concede la insignia Top Performer cuatro veces al año (primavera, verano, otoño e invierno) a los productos que se sitúan en el 10 % superior de más de 100 000 soluciones incluidas en la plataforma. Las clasificaciones dependen exclusivamente del volumen, la actualidad y la valoración de las reseñas verificadas, sin intervención editorial.

«Tres trimestres de reconocimiento constante no son casualidad: son el resultado directo de escuchar a las personas que usan Passwork a diario y de crear lo que realmente piden.» — Alex Muntyan, CEO of Passwork

Passwork tiene una valoración global de 4,8 sobre 5 estrellas en SourceForge.

Vea por qué los evaluadores siguen situando a Passwork en el 10 % superior. Probar Passwork gratis con acceso completo.

Passwork, nombrado Best for User Interface y reconocido como FrontRunner 2026

Passwork fue nombrado Best for User Interface en la selección de software de gestión de contraseñas de 2026 de Software Advice y obtuvo la insignia FrontRunners 2026.

PassworkPasswork Team

Passwork, incluido en la Capterra Shortlist 2026

Passwork obtuvo un puesto en la Capterra Shortlist 2026 de gestión de contraseñas. El reconocimiento se basa en reseñas verificadas que destacan la facilidad de configuración, la migración desde herramientas heredadas y una integración con el navegador que agiliza el uso diario.

PassworkPasswork Team

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

Ahora las contraseñas también funcionan sin conexión. Passwork 7.7 incorpora acceso sin conexión seguro con plena supervisión del administrador, controles de archivos adjuntos para toda la organización y cinco nuevas guías de incorporación por rol para un despliegue más fluido.

PassworkPasswork Team

For the third consecutive quarter, Passwork has earned SourceForge's Top Performer badge — this time for Fall 2026. SourceForge helps IT buyers compare business software based on verified customer feedback, and this award reflects the honest, ongoing experience of teams running Passwork in production.

Since the Summer win, Passwork has added two more independent recognitions: a spot on the Capterra Shortlist 2026 for Password Management, and Best for User Interface honors with a 2026 FrontRunners badge from Software Advice — both, like the SourceForge badge, built entirely on verified user feedback rather than editorial judgment.

What customers say about Passwork

Visibility into who touched what, down to the password. Detailed, per-record activity logs keep audits and on-premises deployments grounded in fact, not guesswork.

"We also highly value the detailed activity logs available for every password, which provide visibility into who accessed or modified sensitive information." — Systems Administrator

A browser extension that scales with how many sites a team actually touches. For teams juggling dozens of logins a day, autofill convenience is the daily test reviewers keep rewarding.

"The browser extension is probably the feature we use the most, as we maintain more than a hundred websites and it makes accessing all those credentials very convenient." — Software Developer

Administrative and auditing capabilities that hold up under evaluation. Even teams still inside their trial window point to the same two things: usability and oversight.

"Our initial experience with Passwork has been very positive. The platform is user-friendly, offers strong organizational features, and provides useful administrative and auditing capabilities." — IT Manager

About the award

SourceForge is the largest B2B software review and comparison directory in the world, with nearly 20 million monthly users evaluating business software. It issues the Top Performer badge four times a year (spring, summer, fall, and winter) to products ranking in the top 10% out of more than 100,000 solutions listed on the platform. Rankings are driven purely by the volume, recency, and rating of verified reviews, with no editorial input.

"Three quarters of consistent recognition is not an accident — it's the direct result of listening to the people who use Passwork every day and building what they actually ask for." — Alex Muntyan, CEO of Passwork

Passwork holds a 4.8 out of 5 stars overall rating on SourceForge.

See why reviewers keep ranking Passwork in the top 10%. Start a free Passwork trial with full access.

Passwork named Best for User Interface and recognized as a 2026 FrontRunner

Passwork was named Best for User Interface in Software Advice's 2026 password management software selection and got the FrontRunners 2026 badge.

PassworkPasswork Team

Passwork named to Capterra Shortlist 2026

Passwork earned a spot on the Capterra Shortlist 2026 for Password Management. The recognition is built on verified reviews citing ease of setup, legacy-tool migration, and browser integration that speeds up daily use.

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

In 2026, password manager compliance means proving control over credentials. These password manager compliance standards overlap in places, but they don't add up to one universal policy.

Requirements differ by industry, geography, system scope, and audit boundary, so no single certification covers every organization equally. Framework applicability depends on entity type, system and data scope, jurisdiction, contracts, and risk. This guide gives you a cross-framework standards map, a resolution to the recurring NIST-versus-PCI rotation conflict, and a passkey mapping you can use when writing policy.

Compliance standards for password managers: 2026 status

Compliance evidence is the set of policies, configuration records, approval trails, access reviews, logs, and test results that show a control operates as designed, not just that it exists on paper. For password managers, the 2026 baseline is a governed credential lifecycle: unique identities, controlled vault access, strong authentication, auditable changes, tested recovery, and a framework-specific policy overlay.

No single global law rewrote password manager compliance in 2026. What changed is the combination: 

• NIST (the US National Institute of Standards and Technology) Rev. 4 became the current technical benchmark for authenticators
• PCI DSS (Payment Card Industry Data Security Standard) v4.0.1 is the active PCI standard
• DORA (the EU's Digital Operational Resilience Act) has applied since 17 January 2025
• NIS2 (the EU's second Network and Information Security Directive) moved into national enforcement
• Gap persists between HIPAA's (Health Insurance Portability and Accountability Act) current rule and its proposed multi-factor authentication (MFA) update.

Password manager compliance standards by framework

The Credential Governance Overlay (CGO) maps each framework to the control it demands, the evidence an auditor can test, and the password manager capability that makes the control operational. Each framework below covers what it requires and what that means for vault configuration. The table further down summarizes the evidence to retain for each.

NIST SP 800-63B Rev. 4

For centrally verified passwords, NIST SP 800-63B Rev. 4 sets a 15-character minimum for single-factor authentication. An 8-character minimum applies only when the password is used solely as part of MFA. Verifiers shall not impose composition rules or periodic changes, and shall screen new passwords against known common, expected, or compromised values.

For a password manager, this means generating long, unique credentials, allowing autofill, permitting paste where autofill is unavailable, running compromise detection, and protecting vault authentication with MFA.

ISO/IEC 27001:2022

ISO 27001 is the international standard for information security management systems. Annex A controls A.5.16 (identity management), A.5.18 (access rights), A.8.5 (secure authentication), and A.8.24 (cryptography) flow through the risk treatment plan and Statement of Applicability, a document listing which controls apply and why. These controls are selected through risk treatment; ISO does not mandate every Annex A control or a specific password manager product.

Operationally, this points to a joiner-mover-leaver workflow, role-based access control (RBAC), MFA where risk requires it, and documented encryption and key management.

SOC 2

SOC 2 is an auditing framework for service organizations. AICPA's Trust Services Criteria CC6.1-CC6.8 are outcome-based controls covering access architecture, registration and authorization, access changes, physical protection, secure disposal, boundary protection, authorized transfer or removal of information (CC6.7), and malware defense. Auditors test evidence appropriate to the system boundary, risks, and selected controls.

Treat the vault as one component inside the audited system boundary. Control administrators, exports, integrations, and logging, not passwords alone.

PCI DSS v4.0.1

PCI DSS protects payment-card data. Requirement 8 governs identification and authentication for the cardholder data environment (CDE), the systems and people in scope for payment-card data. Under Requirement 8.3.6, passwords or passphrases used as authentication factors must be at least 12 characters, or at least 8 where the system does not support 12.

Where a password or passphrase is the only authentication factor for user access, Requirement 8.3.9 requires a change at least every 90 days or automatic access decisions based on dynamic analysis of the account's security posture. The requirement may be marked not applicable only where MFA protects access to all in-scope system components, or where the component and access path fall within PCI SSC's defined single-factor conditions. MFA obligations themselves are governed separately, under Requirements 8.4.2-8.4.4, based on the access path.

Segment PCI-scoped credentials, confirm whether Requirement 8.3.9 applies before assuming it doesn't, and check which MFA requirement governs each access path.

HIPAA Security Rule

HIPAA protects health information in the US. Current 45 CFR §164.312 requires access control, unique user identification, an emergency access procedure, and person/entity authentication for electronic protected health information (ePHI) systems. A 2025 HHS proposal would add MFA with limited exceptions, but that requirement remains proposed, not final law.

Use unique vault accounts, preserve emergency-access procedures, restrict ePHI credential sharing, and review access and logs regularly.

NIS2

NIS2 is the EU directive on network and information security. Article 20 requires management bodies to approve and oversee Article 21 measures, and allows liability under applicable national law. Article 21 requires proportionate measures including access-control policies, cryptography, cyber hygiene, and MFA or continuous authentication where appropriate. Article 34 requires member states to set maximum administrative fines of at least €10 million or 2% of worldwide turnover for essential entities, whichever is higher.

This translates into a board-approved risk-management program covering access reviews, training, incident response, and vendor oversight.

DORA

DORA governs ICT risk for in-scope EU financial entities and has applied since 17 January 2025. Article 9 requires ICT security policies and controls, including least-privilege access, strong authentication, and cryptographic-key protections. Article 10 covers detection mechanisms; Article 11 covers ICT business continuity, response, recovery, backup, and restoration.

Treat the vault as an ICT service: test recovery, control privileged access, monitor anomalies, and assess hosted-vendor risk.

GDPR

GDPR is the EU's general data protection law. Article 25 requires data protection by design and default. Article 32 requires security appropriate to risk, including confidentiality, resilience, and tested restoration. Both sit under the accountability principle: the organization must be able to demonstrate compliance, not just claim it.

Map vault data flows, access, telemetry, recovery, retention, and processor or subprocessor relationships.

An enterprise can run one baseline vault policy but must layer stricter scoped overlays where PCI, financial-sector rules, healthcare law, national NIS2 legislation, contracts, or internal risk appetite demand more. That keeps policy manageable without treating a general NIST baseline as a legal override for scoped systems.

Table: password manager compliance controls by framework.

Resolve the NIST-PCI password-rotation conflict by scope

Do not choose between NIST and PCI globally. Apply each standard to the accounts and systems it governs. Scope means the people, systems, data, and processes a given requirement actually applies to, and getting scope wrong is a common source of conflicting password policy inside one organization.

NIST Rev. 4 states that verifiers shall not require periodic password changes. PCI DSS v4.0.1 Requirement 8.3.9 creates a different rule where a password or passphrase is the only authentication factor for user access: change it at least every 90 days or use dynamic security-posture analysis to determine access. The rule may not apply where MFA protects access to all in-scope components, subject to PCI's applicability notes and PCI SSC guidance. The two standards therefore conflict only for the applicable PCI-scoped, single-factor password accounts. They should not be treated as a universal policy conflict.

Use this three-step resolution:

• Maintain a labeled inventory of applications and accounts, including whether each one sits inside the CDE and whether it relies on a password as the sole factor.
• For PCI-scoped, single-factor accounts, confirm whether MFA covers all in-scope components before assuming Requirement 8.3.9 doesn't apply. Where it does apply, enforce the 90-day change or the permitted dynamic-analysis exception.
• Apply NIST's length, blocklist, no-composition, compromise-triggered-change model to non-PCI systems where NIST is the governing baseline.

Confirm the final scope and exception mapping with your organization's PCI assessor before changing policy on any scoped account.

Map passkeys to framework outcomes, not compliance labels

A passkey is a FIDO2/WebAuthn public-key credential that signs a challenge for a specific website instead of transmitting a reusable password. A synced passkey is available across a user's devices through a sync service. A device-bound authenticator keeps the key on one authenticator. That difference matters for NIST's authentication assurance levels (AALs), which measure confidence in an authentication event.

NIST defines three tiers. AAL1 requires only single-factor authentication and permits a standard password. AAL2 and AAL3 are where passkey choice actually changes what you can claim.

Where a passkey supports AAL2

AAL2 requires two distinct authentication factors or a qualifying multi-factor authenticator, and applications must offer a phishing-resistant option. A passkey can support AAL2 when the deployment meets those conditions.

User verification matters here: a WebAuthn credential without user verification is single-factor cryptographic authentication, not automatic AAL2. For a synced passkey, AAL2 also requires the Appendix B safeguards and AAL2-equivalent MFA for access to the sync fabric.

Why synced passkeys cannot reach AAL3

AAL3 requires a phishing-resistant authenticator with a non-exportable key and two distinct factors. A device-bound, non-exportable authenticator is the relevant direction here. Syncing makes the authentication key exportable, so a synced authenticator cannot meet AAL3's non-exportability requirement, regardless of how well it performs at AAL2.

How passkeys affect the other frameworks

For ISO 27001, SOC 2, NIS2, DORA, HIPAA, and GDPR, passkeys can support secure authentication and reduce phishing exposure, but they don't replace access reviews, RBAC, recovery controls, logging, or vendor assurance. For PCI DSS, phishing-resistant authentication can affect which MFA requirement applies to a given access path, but it is not a blanket PCI exemption. Confirm the exact mapping with your assessor.

A passkey strengthens authentication, but compliance still depends on who can enroll it, how access is revoked, how recovery works, and what evidence you keep. A synced passkey on a low-risk internal tool and a device-bound passkey guarding a PCI-scoped administrator account satisfy very different policy requirements, even though both are called "passkeys."

Implement the Credential Governance Overlay

The CGO translates the standards map into five operational layers, each with its own action and evidence trail. A common audit problem is failing to show the credential lifecycle.

• Identity lifecycle. Connect the vault to an authoritative identity source. Approve access before issuance, adjust it on role change, and remove it at offboarding. A departing contractor's vault access should be revoked the day the contract ends, not the following payroll cycle. Retain approval and deprovisioning records.
• Authenticator policy. Separate single-factor, MFA, and phishing-resistant paths. Allow long generated passwords and autofill, screen new passwords for compromise, and apply a distinct policy for privileged and PCI-scoped accounts, such as an administrator account inside the CDE. Retain policy configurations and screening results.
• Vault access. Use individual accounts, least-privilege roles, segmented vaults, and time-bound third-party access. Retain access matrices, review records, and export or share events.
• Evidence and monitoring. Send credential-access events to a reviewable log or a security information and event management (SIEM) system. Review anomalies, exports, and role changes. Retain investigation records, not only raw logs.
• Resilience and privacy. Test vault recovery, backup, emergency access, and key-management procedures. Retain test results, recovery approvals, and risk decisions.

The strongest password manager audit record proves the lifecycle of a credential: approved, issued, used, reviewed, revoked, and recoverable under controlled conditions.

Turn controls into operating evidence with Passwork

A product should be evaluated against that evidence model, not against a compliance badge. Passwork's access-management controls can help operationalize several CGO layers, though no single tool satisfies a framework on its own: Active Directory (AD) and LDAP group-driven permissions, granular vault, folder, and password-level permissions, SAML single sign-on, two-factor authentication with YubiKey support, and audit logging for read, write, share, and export activity.

Mapped to the CGO: AD/LDAP integration and RBAC support identity lifecycle, and segmented vault permissions support least privilege. Audit logs support the evidence layer. The choice between self-hosted and cloud deployment supports data-residency decisions specific to your scope.

None of this makes an organization compliant by itself. It gives a security team the configuration and records to support that work, which still has to be mapped to the organization's own scope and policies.

Put these password manager compliance standards into practice

Password manager compliance in 2026 comes down to four moves: 

• Inventory your accounts and systems 
• Label which regulatory scope each falls under
• Map the Credential Governance Overlay to the strictest applicable control
• Test whether your evidence trail holds up under review 

These password manager compliance standards agree on outcomes, not on a single product requirement.

Use a password management program to turn credential policy into a control your security team can operate and your auditors can verify. Start with the account inventory this week, then read our guide on how to use a password manager for the next step.

Frequently asked questions

Uma migração do KeePass para o Passwork decide onde deve ficar cada palavra-passe, quem lhe pode aceder e como provar que o resultado funciona, antes de alguém desativar o fluxo de trabalho antigo. Para quem ainda está a avaliar se deve mudar, Gestão de palavras-passe e de acessos para PME: o KeePass é suficiente? aborda essa questão. Este guia parte do princípio de que a decisão já foi tomada e explica a mecânica do processo.

Planear a migração do KeePass para o Passwork antes de exportar

Confirme o cofre de destino, o responsável, o modelo de acesso e o ponto de rollback antes de exportar o KeePass. O ponto de rollback é a base de dados de origem intacta, mantida até a aceitação ser formalmente aprovada. Sem este passo, uma migração de credenciais transforma-se numa transferência de ficheiros descontrolada, sem responsável e sem forma de retroceder.

Antes de utilizar a função de exportação, percorra estes passos:

1. Construir um inventário de origem com grupos, número de entradas e quaisquer anexos ou campos personalizados
2. Atribuir um responsável para cada credencial partilhada, especialmente contas de TI e contas de serviço
3. Assinalar entradas obsoletas ou duplicadas para exclusão, em vez de importar dados sem utilidade
4. Confirmar quem está autorizado a executar a exportação e a importação
5. Elaborar o plano de cofres e pastas de destino no Passwork antes de mover quaisquer dados
6. Definir uma janela de manutenção, caso as credenciais em causa afetem sistemas de produção

A autorização merece atenção redobrada quando está envolvido um contratante ou um prestador de serviços geridos. O envolvimento de terceiros foi responsável por 48 % das violações, face a 30 % no ano anterior, segundo o Verizon 2026 Data Breach Investigations Report. Se uma parte externa realizar a exportação ou a importação, aplique a mesma aprovação, o mesmo acesso de privilégio mínimo e o mesmo limite de tempo que aplicaria a um administrador interno.

Planeie o acesso no Passwork antes da importação. Uma exportação do KeePass, por si só, não define os utilizadores, os grupos ou os direitos que devem reger o destino. Mapeie os responsáveis e o acesso necessário de forma deliberada, e configure os direitos de acesso a cofres e pastas antes de disponibilizar os registos aos utilizadores.

Uma migração deve preservar ou melhorar deliberadamente o acesso, porque o Passwork atribui direitos de cofre e de pasta de forma explícita, em vez de os derivar de uma exportação do KeePass.

Escolher XML ou CSV do KeePass antes de exportar

Utilize o XML do KeePass quando preservar a hierarquia for importante. Utilize o CSV apenas quando uma tabela plana e um mapeamento manual de campos forem aceitáveis. Cada gestor de palavras-passe utiliza a sua própria estrutura de base de dados — a própria documentação do KeePass é explícita quanto à inexistência de um padrão comum em que se possa confiar. Nem o CSV nem o XML garantem que outro produto interprete os campos ou a hierarquia da mesma forma. Valide a exportação antes de a importar.

Nenhum dos dois formatos garante que todos os anexos, campos personalizados, entradas de histórico ou permissões sejam transferidos. Crie um registo de exceções desde cedo, para que estes itens sejam revistos antes da transição.

Exportar o KeePass sem criar um segredo não controlado

Trate a exportação como um conjunto de credenciais temporário, não como um documento comum. Crie-a apenas numa estação de trabalho de administrador aprovada. Mantenha-a num local local restrito e conserve-a apenas o tempo necessário para importar e verificar os dados.

Mantenha a exportação fora do e-mail, do chat e do armazenamento pessoal na cloud. A política de tratamento de dados da sua organização, e não uma recomendação de ferramenta específica, deve determinar como e quando o ficheiro é eliminado.

Uma sequência funcional tem este aspeto:

1. Faça uma cópia de segurança e abra a base de dados de origem do KeePass
2. Exporte o formato escolhido (XML ou CSV) para o caminho local restrito
3. Dê ao ficheiro um nome com data e âmbito, mas sem segredos no próprio nome do ficheiro
4. Registe a localização do ficheiro e o operador que o criou
5. Confirme que o ficheiro não foi partilhado ou sincronizado acidentalmente em lado nenhum
6. Importe-o prontamente, em vez de o deixar parado

Combine palavras-passe fortes e únicas com MFA resistente a phishing, e torne um gestor de palavras-passe parte dos seus controlos de credenciais habituais. Uma exportação temporária pode ficar fora dos controlos de acesso normais do cofre de origem. Mantenha-a numa estação de trabalho de administrador aprovada e remova-a depois da importação e das verificações de aceitação.

Preparar o destino no Passwork e importar os dados

Crie o cofre de destino e o respetivo modelo de acesso previsto antes de carregar um ficheiro. A ferramenta de importação do Passwork aceita JSON, XML do KeePass e CSV num cofre, numa pasta ou no diretório raiz à escolha.

As importações XML podem preservar ou simplificar a estrutura de origem, e as importações CSV incluem um passo de pré-visualização com controlos de delimitador e de mapeamento de campos.

Percorra a importação por esta ordem:

1. Crie ou selecione o cofre de destino.
2. Decida se vai preservar ou ignorar a estrutura de pastas de origem.
3. Configure os direitos de acesso a cofres e pastas antes de convidar alguém a utilizá-los.
4. Escolha Importar dados e carregue o ficheiro exportado.
5. Para CSV, defina o delimitador e reveja a pré-visualização com atenção.
6. Mapeie cada coluna ou campo de origem para o campo correto do cartão de palavra-passe do Passwork.
7. Antes de uma importação em produção, utilize a pré-visualização para confirmar o destino, o delimitador e o mapeamento de campos.
8. Para um âmbito alargado ou crítico para o negócio, execute um piloto numa instância de teste separada ou num cofre de teste isolado, sem acesso de utilizadores normais. Confirme ali o mapeamento e o processo de exceções antes de importar para o cofre de produção.
9. Conclua a importação em produção assim que o piloto for validado.

O Passwork documenta cinco níveis de acesso: Proibido, Só de leitura, Ler e editar, Acesso total e Administrador. Tem também uma opção separada, «Connect without access» (ligar sem acesso), para utilizadores associados a um cofre sem direitos diretos. Aplique o princípio do menor privilégio por predefinição e alargue o acesso apenas quando uma função específica o exigir.

Realizar o Teste de Aceitação de Migração KeePass-Passwork

Uma importação bem-sucedida prova que os registos foram criados. Uma migração bem-sucedida prova que os registos, a estrutura, o acesso e as evidências cumprem um padrão de aceitação acordado. O Teste de Aceitação de Migração KeePass-Passwork é uma lista de verificação de seis controlos que transforma «a importação terminou» num resultado documentado e pronto para aprovação formal.

O histórico do cofre do Passwork regista adições, edições e eliminações de palavras-passe, bem como alterações de acesso, com data, hora e utilizador responsável. Quando a definição de função exigida está ativada, o registo de atividade a nível do sistema acrescenta um registo de auditoria mais abrangente.

Utilize esta evidência para apoiar o controlo 6, não para substituir os controlos 1 a 5. Os registos confirmam o que aconteceu depois da importação. Não confirmam que os dados ou o acesso estavam corretos à partida.

Fazer a transição em segurança e eliminar a exportação temporária

Só avance para a transição depois de o responsável técnico e o responsável pelo acesso darem aprovação formal. Em seguida, comunique a nova localização, remova a exportação temporária e conserve a base de dados de origem durante a janela de rollback acordada.

A sequência final:

1. Comunique a nova localização de trabalho às equipas afetadas.
2. Atualize quaisquer procedimentos operacionais documentados que façam referência ao cofre antigo.
3. Rode as credenciais de alto risco, partilhadas e anteriormente expostas, de acordo com a política.
4. Remova o acesso ao ficheiro de exportação temporário.
5. Conserve a fonte original do KeePass no local de rollback aprovado durante o período acordado.
6. Elimine o fluxo de trabalho partilhado antigo assim que ambos os responsáveis derem a sua aprovação.

Uma pessoa que tenha saído da equipa ou perdido autorização pode ainda lembrar-se de uma palavra-passe antiga, mesmo depois de o próprio cofre estar bloqueado. Rode as credenciais sempre que uma saída de colaborador ou um evento de risco o justifique, não apenas quando a migração termina. As orientações sobre saída de colaboradores do Passwork traçam a mesma distinção entre remover o acesso e rodar a própria credencial.

Conclusão

Escolha XML ou CSV, construa o plano de acesso de destino e importe os dados. Mantenha o resultado como provisório até os seis controlos passarem. Ignorar a validação pode deixar por descobrir, até depois da transição, anexos em falta, mapeamentos de campos incompletos ou acessos não pretendidos.

Se a sua equipa estiver a substituir um fluxo de trabalho partilhado do KeePass, comece pelo guia de importação do Passwork para carregar os dados e, depois, configure os direitos de acesso a cofres e pastas antes da transição. Para uma visão mais alargada do planeamento de uma migração de credenciais a nível empresarial, para além deste formato, veja porque é que a migração de gestor de palavras-passe num clique não existe em 2026.

Pronto para deixar de vez um ficheiro KeePass partilhado? Descubra como o Passwork estrutura cofres, pastas e direitos de acesso.

Perguntas frequentes

Passwork vs KeePass: Diferenças na arquitetura de cifragem

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

PassworkPasswork Team

O KeePass é suficiente? Gestão de palavras-passe e de acessos para PME

O KeePass é uma solução popular para uso individual, mas deixa de funcionar quando várias pessoas precisam de aceder às mesmas credenciais: alterações substituídas, uma única palavra-passe mestra para todos e nenhum registo de auditoria. Veja do que as PME precisam quando entram em cena a saída de colaboradores, o NIS2 e as auditorias SOC 2.

Passwork BlogAlex Muntyan

Porque é que a migração de gestor de palavras-passe num clique não existe em 2026

Uma migração de gestor de palavras-passe é uma oportunidade rara para rever todo o ambiente de acessos da organização. Veja como avançar com segurança, eliminando riscos ocultos sem perturbar o acesso em produção.

PassworkAlex Muntyan

Eine Migration von KeePass zu Passwork legt fest, wo jedes Passwort abgelegt wird, wer darauf zugreifen kann und wie sich das Ergebnis nachweisen lässt – bevor der alte Workflow stillgelegt wird. Wer noch abwägt, ob ein Wechsel überhaupt sinnvoll ist, findet die Antwort in Passwort- und Zugriffsverwaltung für KMU: Reicht KeePass aus?. Dieser Leitfaden setzt die Entscheidung voraus und beschreibt die praktische Umsetzung.

Die Migration von KeePass zu Passwork vor dem Export planen

Bestätigen Sie den Ziel-Tresor, den Verantwortlichen, das Zugriffsmodell und den Rollback-Punkt, bevor Sie KeePass exportieren. Der Rollback-Punkt ist die unveränderte Quelldatenbank, die bis zur Freigabe der Abnahme aufbewahrt wird. Ohne diesen Schritt wird aus einer Migration von Zugangsdaten eine unkontrollierte Dateiübertragung ohne Verantwortlichen und ohne Rückweg.

Bevor Sie die Exportfunktion verwenden, gehen Sie diese Schritte durch:

1. Erstellen Sie eine Bestandsaufnahme der Quelle mit Gruppen, Eintragsanzahl sowie eventuellen Anhängen oder benutzerdefinierten Feldern.
2. Weisen Sie jedem gemeinsam genutzten Zugangsdatensatz einen Verantwortlichen zu, insbesondere bei IT- und Servicekonten.
3. Markieren Sie veraltete oder doppelte Einträge zum Ausschluss, statt totes Gewicht zu importieren.
4. Bestätigen Sie, wer zur Durchführung von Export und Import berechtigt ist.
5. Entwerfen Sie den Tresor- und Ordnerplan des Ziels in Passwork, bevor Daten verschoben werden.
6. Legen Sie ein Wartungsfenster fest, wenn die betroffenen Zugangsdaten produktive Systeme betreffen.

Autorisierung verdient besondere Aufmerksamkeit, wenn ein Auftragnehmer oder Managed-Service-Provider beteiligt ist. Die Beteiligung Dritter war laut dem 2026 Data Breach Investigations Report von Verizon für 48 % der Sicherheitsverstöße verantwortlich – ein Anstieg gegenüber 30 % im Vorjahr. Wenn eine externe Partei den Export oder Import durchführt, wenden Sie dieselbe Freigabe, denselben Zugriff nach dem Prinzip der geringsten Privilegien und dieselbe zeitliche Begrenzung an wie bei einem internen Administrator.

Planen Sie den Zugriff in Passwork vor dem Import. Ein eigenständiger KeePass-Export definiert nicht die Benutzer, Gruppen oder Rechte, die für das Ziel gelten sollen. Ordnen Sie Verantwortliche und erforderlichen Zugriff bewusst zu, und konfigurieren Sie die erforderlichen Tresor- und Ordner-Zugriffsrechte, bevor Datensätze für Benutzer verfügbar sind.

Eine Migration sollte den Zugriff erhalten oder bewusst verbessern, da Passwork Tresor- und Ordnerrechte explizit vergibt, statt sie aus einem KeePass-Export abzuleiten.

KeePass-XML oder CSV vor dem Export wählen

Verwenden Sie KeePass-XML, wenn der Erhalt der Hierarchie wichtig ist. Verwenden Sie CSV nur, wenn eine flache Tabelle und eine manuelle Feldzuordnung akzeptabel sind. Jeder Passwortmanager verwendet sein eigenes Datenbankformat – die eigene Dokumentation von KeePass stellt ausdrücklich klar, dass es keinen gemeinsamen Standard gibt, auf den man sich verlassen kann. CSV und XML garantieren nicht, dass ein anderes Produkt Feldbedeutungen oder Hierarchien auf die gleiche Weise interpretiert. Prüfen Sie den Export, bevor Sie ihn importieren.

Keines der beiden Formate garantiert, dass jeder Anhang, jedes benutzerdefinierte Feld, jeder Verlaufseintrag oder jede Berechtigung übertragen wird. Legen Sie frühzeitig ein Ausnahmeregister an, damit diese Punkte vor dem Cutover geprüft werden.

KeePass exportieren, ohne ein unverwaltetes Geheimnis zu erzeugen

Behandeln Sie den Export als temporären Zugangsdaten-Datensatz, nicht als gewöhnliches Dokument. Erstellen Sie ihn nur auf einer freigegebenen Administrator-Workstation. Bewahren Sie ihn an einem eingeschränkten lokalen Ort auf, und behalten Sie ihn nur so lange, wie es zum Importieren und Prüfen der Daten nötig ist.

Halten Sie den Export vollständig von E-Mail, Chat und privatem Cloud-Speicher fern. Wie und wann die Datei vernichtet wird, sollte sich nach der Daten-Richtlinie Ihrer Organisation richten, nicht nach der Empfehlung eines bestimmten Tools.

Eine praktikable Abfolge sieht so aus:

1. Sichern Sie die Quell-Datenbank von KeePass, und öffnen Sie sie.
2. Exportieren Sie das gewählte Format (XML oder CSV) in den eingeschränkten lokalen Pfad.
3. Benennen Sie die Datei mit Datum und Umfang, jedoch ohne Geheimnisse im Dateinamen selbst.
4. Dokumentieren Sie den Speicherort der Datei und den Bearbeiter, der sie erstellt hat.
5. Bestätigen Sie, dass die Datei nirgends versehentlich freigegeben oder synchronisiert wurde.
6. Importieren Sie sie umgehend, statt sie liegen zu lassen.

Kombinieren Sie starke, einzigartige Passwörter mit phishing-resistenter MFA, und machen Sie einen Passwortmanager zu einem festen Bestandteil Ihrer Standard-Zugangskontrollen. Ein temporärer Export kann außerhalb der normalen Zugriffskontrollen des Quell-Tresors liegen. Bewahren Sie ihn auf einer freigegebenen Administrator-Workstation auf, und entfernen Sie ihn nach Import und Abnahmeprüfung.

Das Passwork-Ziel vorbereiten und die Daten importieren

Erstellen Sie den Ziel-Tresor und das vorgesehene Zugriffsmodell, bevor Sie eine Datei hochladen. Das Importtool von Passwork akzeptiert JSON, KeePass-XML und CSV in einen gewählten Tresor, Ordner oder das Stammverzeichnis.

XML-Importe können die Quellstruktur beibehalten oder sie abflachen, und CSV-Importe enthalten einen Vorschauschritt mit Einstellungen für Trennzeichen und Feldzuordnung.

Gehen Sie den Import in dieser Reihenfolge durch:

1. Erstellen oder wählen Sie den Ziel-Tresor.
2. Entscheiden Sie, ob die Ordnerstruktur der Quelle beibehalten oder ignoriert werden soll.
3. Konfigurieren Sie die Tresor- und Ordner-Zugriffsrechte, bevor Sie jemanden zur Nutzung einladen.
4. Wählen Sie „Daten importieren“, und laden Sie die exportierte Datei hoch.
5. Legen Sie bei CSV das Trennzeichen fest, und prüfen Sie die Vorschau sorgfältig.
6. Ordnen Sie jede Quellspalte oder jedes Quellfeld dem richtigen Passwork-Passwortkartenfeld zu.
7. Nutzen Sie vor einem Produktivimport die Vorschau, um Ziel, Trennzeichen und Feldzuordnung zu bestätigen.
8. Führen Sie bei einem großen oder geschäftskritischen Umfang einen Pilotlauf in einer separaten Testinstanz oder einem isolierten Test-Tresor ohne Zugriff für normale Benutzer durch. Bestätigen Sie dort die Zuordnung und den Ausnahmeprozess, bevor Sie in den Produktiv-Tresor importieren.
9. Schließen Sie den Produktivimport ab, sobald der Pilotlauf erfolgreich war.

Passwork dokumentiert fünf Zugriffslevel: Verboten, Nur Lesen, Lesen und Bearbeiten, Vollständiger Zugang und Administrator. Zusätzlich gibt es die separate Option „Ohne Zugriff verbinden“ für Benutzer, die mit einem Tresor verknüpft sind, aber keine direkten Rechte besitzen. Wenden Sie standardmäßig das Prinzip der geringsten Privilegien an, und erweitern Sie den Zugriff nur, wenn eine bestimmte Rolle dies erfordert.

Den KeePass-zu-Passwork-Migrationsabnahmetest durchführen

Ein erfolgreicher Import beweist, dass Datensätze angelegt wurden. Eine erfolgreiche Migration beweist, dass Datensätze, Struktur, Zugriff und Nachweise einem vereinbarten Abnahmestandard entsprechen. Der KeePass-zu-Passwork-Migrationsabnahmetest ist eine Checkliste mit sechs Kontrollen, die aus „der Import ist abgeschlossen“ ein dokumentiertes, freigabereifes Ergebnis macht.

Der Tresorverlauf von Passwork erfasst das Hinzufügen, Bearbeiten und Löschen von Passwörtern sowie Zugriffsänderungen mit Zeitstempel und ausführendem Benutzer. Ist die erforderliche Rolleneinstellung aktiviert, ergänzt das systemweite Activity-Log einen umfassenderen Audit-Trail.

Nutzen Sie diese Nachweise zur Unterstützung von Kontrolle 6, nicht als Ersatz für die Kontrollen 1 bis 5. Protokolle bestätigen, was nach dem Import geschehen ist. Sie bestätigen nicht, dass die Daten oder der Zugriff von Anfang an korrekt waren.

Den Cutover sicher durchführen und den temporären Export stilllegen

Führen Sie den Cutover erst durch, wenn der technische Verantwortliche und der Zugriffsverantwortliche die Freigabe erteilt haben. Kommunizieren Sie anschließend den neuen Speicherort, entfernen Sie den temporären Export, und bewahren Sie die Quelldatenbank für das vereinbarte Rollback-Fenster auf.

Die Abschlussfolge:

1. Kommunizieren Sie den neuen Arbeitsspeicherort an die betroffenen Teams.
2. Aktualisieren Sie alle dokumentierten Betriebsabläufe, die auf den alten Tresor verweisen.
3. Rotieren Sie risikoreiche, gemeinsam genutzte und zuvor offengelegte Zugangsdaten gemäß Ihrer Richtlinie.
4. Entfernen Sie den Zugriff auf die temporäre Exportdatei.
5. Bewahren Sie die ursprüngliche KeePass-Quelle für den vereinbarten Zeitraum am freigegebenen Rollback-Ort auf.
6. Stellen Sie den alten gemeinsam genutzten Workflow ein, sobald beide Verantwortlichen zustimmen.

Eine Person, die das Team verlassen hat oder deren Berechtigung entzogen wurde, kann sich weiterhin an ein altes Passwort erinnern – selbst wenn der Tresor bereits gesperrt ist. Rotieren Sie Zugangsdaten immer dann, wenn ein Offboarding- oder Risikoereignis dies rechtfertigt, nicht nur zum Abschluss der Migration. Die Offboarding-Hinweise von Passwork ziehen dieselbe Trennlinie zwischen dem Entzug des Zugriffs und der Rotation der Zugangsdaten selbst.

Fazit

Wählen Sie XML oder CSV, erstellen Sie den Zugriffsplan für das Ziel, und importieren Sie die Daten. Betrachten Sie das Ergebnis als vorläufig, bis alle sechs Kontrollen bestanden sind. Wird die Validierung übersprungen, bleiben fehlende Anhänge, unvollständige Feldzuordnungen oder unbeabsichtigter Zugriff möglicherweise bis nach dem Cutover unentdeckt.

Wenn Ihr Team einen gemeinsam genutzten KeePass-Workflow ablöst, beginnen Sie mit dem Importleitfaden von Passwork, um die Daten zu laden, und konfigurieren Sie anschließend die Tresor- und Ordner-Zugriffsrechte vor dem Cutover. Einen umfassenderen Blick auf die Planung einer unternehmensweiten Migration von Zugangsdaten über dieses eine Format hinaus bietet Warum es 2026 keine Passwortmanager-Migration per Klick gibt.

Bereit, eine gemeinsam genutzte KeePass-Datei endgültig abzulösen? Erfahren Sie, wie Passwork Tresore, Ordner und Zugriffsrechte strukturiert.

Häufig gestellte Fragen

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

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

PassworkPasswork Team

Reicht KeePass aus? Passwort- und Zugriffsverwaltung für KMU

KeePass ist eine beliebte Lösung für den individuellen Einsatz, funktioniert aber nicht mehr, sobald mehrere Personen auf dieselben Zugangsdaten zugreifen müssen: überschriebene Änderungen, ein Master-Passwort für alle und kein Audit-Trail. Hier erfahren Sie, was KMU benötigen, sobald Offboarding, NIS2 und SOC-2-Audits ins Spiel kommen.

Passwork BlogAlex Muntyan

Warum es 2026 keine Passwortmanager-Migration per Klick gibt

Eine Passwortmanager-Migration ist eine seltene Gelegenheit, die gesamte Zugriffsumgebung Ihrer Organisation zu überprüfen. Erfahren Sie, wie Sie sie sicher umsetzen und verborgene Risiken beseitigen, ohne den produktiven Zugriff zu stören.

PassworkAlex Muntyan

Una migración de KeePass a Passwork decide dónde debe estar cada contraseña, quién puede acceder a ella y cómo demostrar que el resultado funciona, antes de retirar el flujo de trabajo anterior. Si todavía está valorando si conviene migrar, Gestión de contraseñas y accesos para pymes: ¿Es KeePass suficiente? aborda esa pregunta. Esta guía asume que la decisión ya está tomada y explica la mecánica del proceso.

Planificar la migración de KeePass a Passwork antes de exportar

Confirme la bóveda de destino, el responsable, el modelo de acceso y el punto de reversión antes de exportar KeePass. El punto de reversión es la base de datos de origen, sin modificar, que se conserva hasta que se firme la aceptación. Sin este paso, una migración de credenciales se convierte en una transferencia de archivos sin control, sin responsable y sin posibilidad de retroceder.

Antes de utilizar la función de exportación, complete estos pasos:

1. Elabore un inventario del origen con los grupos, el número de entradas y los posibles archivos adjuntos o campos personalizados
2. Asigne un responsable para cada credencial compartida, especialmente las cuentas de TI y de servicio
3. Marque las entradas obsoletas o duplicadas para excluirlas, en lugar de importar datos innecesarios
4. Confirme quién está autorizado a ejecutar la exportación y la importación
5. Diseñe el plan de bóvedas y carpetas de destino en Passwork antes de mover ningún dato
6. Establezca una ventana de mantenimiento si las credenciales del alcance afectan a sistemas de producción

La autorización merece atención adicional cuando interviene un contratista o un proveedor de servicios gestionados. La participación de terceros representó el 48 % de las brechas, frente al 30 % del año anterior, según el informe Data Breach Investigations Report de 2026 de Verizon. Si una parte externa gestiona la exportación o la importación, aplique la misma aprobación, el mismo acceso de mínimo privilegio y el mismo límite de tiempo que aplicaría a un administrador interno.

Planifique el acceso en Passwork antes de importar. Un archivo de exportación de KeePass por sí solo no define los usuarios, los grupos ni los permisos que deben regir el destino. Asigne los responsables y el acceso necesario de forma deliberada, y configure los permisos de bóveda y carpeta requeridos antes de que los registros queden disponibles para los usuarios.

Una migración debe conservar el acceso existente o mejorarlo de forma deliberada, ya que Passwork concede los permisos de bóveda y carpeta de forma explícita, en lugar de derivarlos de una exportación de KeePass.

Elegir XML o CSV de KeePass antes de exportar

Utilice XML de KeePass cuando conservar la jerarquía sea importante. Utilice CSV solo cuando una tabla plana y el mapeo manual de campos sean aceptables. Cada gestor de contraseñas utiliza su propio formato de base de datos: la propia documentación de KeePass es explícita en que no existe ningún estándar compartido en el que apoyarse. CSV y XML no garantizan que otro producto interprete el significado de los campos o la jerarquía de la misma manera. Valide la exportación antes de importarla.

Ningún formato garantiza que se transfieran todos los archivos adjuntos, campos personalizados, entradas de historial o permisos. Cree un registro de excepciones desde el principio para revisar estos elementos antes de la puesta en marcha.

Exportar KeePass sin crear un secreto sin gestionar

Trate la exportación como un conjunto temporal de credenciales, no como un documento ordinario. Créela únicamente en una estación de trabajo de administrador aprobada. Consérvela en una ubicación local restringida y manténgala solo el tiempo necesario para importar y verificar los datos.

Mantenga la exportación totalmente fuera del correo electrónico, el chat y el almacenamiento personal en la nube. La política de gestión de datos de su organización, y no una recomendación de una herramienta concreta, debe determinar cómo y cuándo se destruye el archivo.

Una secuencia viable sería la siguiente:

1. Haga una copia de seguridad y abra la base de datos de origen de KeePass
2. Exporte el formato elegido (XML o CSV) a la ruta local restringida
3. Asigne al archivo un nombre con la fecha y el alcance, pero sin secretos en el propio nombre
4. Registre la ubicación del archivo y el operador que lo creó
5. Confirme que el archivo no se ha compartido ni sincronizado accidentalmente en ningún sitio
6. Impórtelo de inmediato, en lugar de dejarlo sin usar

Combine contraseñas seguras y únicas con una MFA resistente al phishing, e incorpore un gestor de contraseñas como parte de sus controles de credenciales habituales. Una exportación temporal puede quedar fuera de los controles de acceso normales de la bóveda de origen. Manténgala en una estación de trabajo de administrador aprobada y elimínela después de las comprobaciones de importación y aceptación.

Preparar el destino en Passwork e importar los datos

Cree la bóveda de destino y su modelo de acceso previsto antes de subir ningún archivo. La herramienta de importación de Passwork admite JSON, XML de KeePass y CSV en una bóveda, una carpeta o el directorio raíz elegidos.

Las importaciones en XML pueden conservar la estructura de origen o aplanarla, y las importaciones en CSV incluyen un paso de vista previa con controles de delimitador y mapeo de campos.

Siga este orden para la importación:

1. Cree o seleccione la bóveda de destino.
2. Decida si va a conservar o a ignorar la estructura de carpetas de origen.
3. Configure los permisos de bóveda y carpeta antes de invitar a nadie a utilizarla.
4. Seleccione Importar datos y cargue el archivo exportado.
5. Para CSV, establezca el delimitador y revise la vista previa con atención.
6. Asigne cada columna o campo de origen al campo correspondiente de la tarjeta de contraseña de Passwork.
7. Antes de una importación en producción, utilice la vista previa para confirmar el destino, el delimitador y el mapeo de campos.
8. En un alcance grande o crítico para el negocio, ejecute una prueba piloto en una instancia de prueba independiente o en una bóveda de prueba aislada sin acceso de usuarios normales. Confirme allí el mapeo y el proceso de excepciones antes de importar en la bóveda de producción.
9. Complete la importación en producción una vez que la prueba piloto se haya validado.

Passwork documenta cinco niveles de acceso: Prohibido, Solo lectura, Leer y editar, Acceso completo y Administrador. También dispone de una opción independiente de «Conectar sin acceso» para los usuarios vinculados a una bóveda sin permisos directos. Aplique el principio de mínimo privilegio de forma predeterminada y amplíe el acceso solo cuando un rol concreto lo requiera.

Ejecutar la prueba de aceptación de la migración de KeePass a Passwork

Una importación correcta demuestra que se crearon los registros. Una migración correcta demuestra que los registros, la estructura, el acceso y las evidencias cumplen un estándar de aceptación acordado. La prueba de aceptación de la migración de KeePass a Passwork es una lista de verificación de seis controles que convierte «la importación ha finalizado» en un resultado documentado y listo para su aprobación.

El historial de la bóveda de Passwork registra las altas, ediciones y eliminaciones de contraseñas, así como los cambios de acceso, con marca de tiempo y el usuario que los realizó. Cuando el ajuste de rol necesario está habilitado, el registro de actividad global del sistema añade un rastro de auditoría más amplio.

Utilice estas evidencias para respaldar el control 6, no para sustituir los controles 1 a 5. Los registros confirman lo que ocurrió después de la importación, pero no confirman que los datos o el acceso fueran correctos desde el principio.

Completar el cambio de forma segura y retirar la exportación temporal

Realice el cambio únicamente después de que el responsable técnico y el responsable de accesos lo aprueben. A continuación, comunique la nueva ubicación, elimine la exportación temporal y conserve la base de datos de origen durante el período de reversión acordado.

La secuencia final:

1. Comunique la nueva ubicación de trabajo a los equipos afectados
2. Actualice cualquier procedimiento operativo documentado que haga referencia a la bóveda anterior
3. Rote las credenciales de alto riesgo, compartidas o expuestas previamente, según la política
4. Elimine el acceso al archivo de exportación temporal
5. Conserve el origen original de KeePass en la ubicación de reversión aprobada durante el período acordado
6. Retire el antiguo flujo de trabajo compartido una vez que ambos responsables lo aprueben

Una persona que ha dejado el equipo o ha perdido la autorización puede seguir recordando una contraseña antigua, incluso después de que la propia bóveda quede bloqueada. Rote las credenciales siempre que una baja o un evento de riesgo lo justifique, no solo cuando finalice la migración. La guía de bajas de Passwork traza la misma línea entre retirar el acceso y rotar la propia credencial.

Conclusión

Elija XML o CSV, defina el plan de acceso de destino e importe los datos. Mantenga el resultado como provisional hasta que se superen los seis controles. Omitir la validación puede dejar sin detectar archivos adjuntos ausentes, mapeos de campos incompletos o accesos no previstos hasta después de la puesta en marcha.

Si su equipo está sustituyendo un flujo de trabajo compartido de KeePass, empiece por la guía de importación de Passwork para cargar los datos y, a continuación, configure los permisos de bóveda y carpeta antes de la puesta en marcha. Para una perspectiva más amplia sobre cómo planificar una migración de credenciales a escala empresarial más allá de este formato, consulte por qué la migración de gestores de contraseñas con un solo clic no existe en 2026.

¿Listo para dejar atrás definitivamente un archivo de KeePass compartido? Descubra cómo Passwork estructura las bóvedas, las carpetas y los permisos de acceso.

Preguntas frecuentes

Passwork frente a KeePass: En qué se diferencia la arquitectura de cifrado

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

PassworkPasswork Team

¿Es KeePass suficiente? Gestión de contraseñas y accesos para pymes

KeePass es una solución popular para uso individual, pero deja de funcionar cuando varias personas necesitan acceder a las mismas credenciales: cambios sobrescritos, una única contraseña maestra para todos y ausencia de un registro de auditoría. Descubra qué necesitan las pymes cuando entran en juego las bajas de personal, NIS2 y las auditorías SOC 2.

Passwork BlogAlex Muntyan

Por qué la migración de gestores de contraseñas con un solo clic no existe en 2026

Una migración de gestor de contraseñas es una oportunidad poco frecuente para revisar todo el entorno de accesos de su organización. Descubra cómo llevarla a cabo de forma segura, eliminando riesgos ocultos sin interrumpir el acceso en producción.

PassworkAlex Muntyan

A KeePass to Passwork migration decides where each password belongs, who can reach it, and how you prove the result works — before anyone retires the old workflow. If you're still weighing whether to move at all, Password and access management for SMBs: Is KeePass enough? covers that question. This guide assumes the decision is made and walks through the mechanics.

Plan your KeePass to Passwork migration before you export

Confirm the destination vault, the responsible owner, the access model, and the rollback point before you export KeePass. The rollback point is the untouched source database retained until acceptance is signed off. Without this step, a credential migration turns into an uncontrolled file transfer with no owner and no way back.

Before touching the export function, work through these steps:

1. Build a source inventory of groups, entry counts, and any attachments or custom fields.
2. Assign an owner for every shared credential, especially IT and service accounts.
3. Flag obsolete or duplicate entries for exclusion rather than importing dead weight.
4. Confirm who is authorized to run the export and the import.
5. Draft the target vault and folder plan in Passwork before any data moves.
6. Set a maintenance window if the credentials in scope touch production systems.

Authorization deserves extra attention when a contractor or managed service provider is involved. Third-party involvement accounted for 48% of breaches, up from 30% the year before, per Verizon's 2026 Data Breach Investigations Report. If an outside party handles the export or import, apply the same approval, least-privilege access, and time limit you would apply to an internal administrator.

Plan access in Passwork before import. A standalone KeePass export does not define the users, groups, or rights that should govern the destination. Map owners and required access deliberately, and configure the required vault and folder access rights before records are available to users.

A migration should preserve or deliberately improve access, because Passwork grants vault and folder rights explicitly rather than deriving them from a KeePass export.

Choose KeePass XML or CSV before exporting

Use KeePass XML when retaining hierarchy matters. Use CSV only when a flat table and manual field mapping are acceptable. Every password manager uses its own database layout — KeePass's own documentation is explicit that no shared standard exists to lean on. CSV and XML do not guarantee that another product will interpret field meanings or hierarchy in the same way. Validate the export before importing it.

Neither format guarantees that every attachment, custom field, history entry, or permission will transfer. Create an exception register early so these items get reviewed before cutover.

Export KeePass without creating an unmanaged secret

Treat the export as a temporary credential dataset, not as an ordinary document. Create it only on an approved administrator workstation. Keep it in a restricted local location and retain it only long enough to import and verify the data.

Keep the export off email, chat, and personal cloud storage entirely. Your organization's own data-handling policy, not a specific tool recommendation, should govern how and when the file gets destroyed.

A workable sequence looks like this:

1. Back up and open the source KeePass database.
2. Export the chosen format (XML or CSV) to the restricted local path.
3. Name the file with a date and scope, but no secrets, in the filename itself.
4. Record the file's location and the operator who created it.
5. Confirm the file has not been accidentally shared or synced anywhere.
6. Import it promptly rather than letting it sit.

Pair strong, unique passwords with phishing-resistant MFA, and make a password manager part of your standard credential controls. A temporary export may sit outside the source vault's normal access controls. Keep it on an approved administrator workstation and remove it after import and acceptance checks.

Prepare the Passwork destination and import the data

Create the destination vault and its intended access model before you upload a file. Passwork's import tool accepts JSON, KeePass XML, and CSV into a chosen vault, folder, or the root directory.

XML imports can preserve the source structure or flatten it, and CSV imports include a preview step with delimiter and field-mapping controls.

Work through the import in this order:

1. Create or select the destination vault.
2. Decide whether to preserve or ignore the source folder structure.
3. Configure vault and folder access rights before inviting anyone to use it.
4. Choose Import data and upload the exported file.
5. For CSV, set the delimiter and review the preview carefully.
6. Map each source column or field to the correct Passwork password-card field.
7. Before a production import, use the preview to confirm the destination, delimiter, and field mapping.
8. For a large or business-critical scope, run a pilot in a separate test instance or an isolated test vault with no normal-user access. Confirm the mapping and exception process there before importing into the production vault.
9. Complete the production import once the pilot checks out.

Passwork documents five access levels: Forbidden, Read only, Read and edit, Full access, and Administrator. It also has a separate "Connect without access" option for users linked to a vault without direct rights. Apply least privilege by default and widen access only when a specific role requires it.

Run the KeePass-to-Passwork Migration Acceptance Test

A successful import proves that records were created. A successful migration proves that the records, structure, access, and evidence meet an agreed acceptance standard. The KeePass-to-Passwork Migration Acceptance Test is a six-control checklist that converts "the import finished" into a documented, sign-off-ready result.

Passwork's vault history records password additions, edits, deletions, and access changes with timestamps and acting users. Where the required role setting is enabled, the system-wide Activity log adds a broader audit trail.

Use this evidence to support control 6, not to replace controls 1 through 5. Logs confirm what happened after import. They don't confirm the data or access were correct in the first place.

Cut over safely and retire the temporary export

Cut over only after the technical owner and access owner sign off. Then communicate the new location, remove the temporary export, and retain the source database for the agreed rollback window.

The finish sequence:

1. Communicate the new working location to affected teams.
2. Update any documented operational procedures that reference the old vault.
3. Rotate high-risk, shared, and previously exposed credentials according to policy.
4. Remove access to the temporary export file.
5. Retain the original KeePass source in the approved rollback location for the agreed period.
6. Retire the old shared workflow once both owners approve.

A person who has left the team or lost authorization may still remember an old password, even after the vault itself is locked down. Rotate credentials whenever an offboarding or risk event justifies it, not only when the migration finishes. Passwork's offboarding guidance draws the same line between removing access and rotating the credential itself.

Conclusion

Choose XML or CSV, build the destination access plan, and import the data. Keep the result provisional until all six controls pass. Skipping validation can leave missing attachments, incomplete field mappings, or unintended access undiscovered until after cutover.

If your team is replacing a shared KeePass workflow, start with Passwork's import guide to load the data, then configure vault and folder access rights before cutover. For a broader look at planning an enterprise-wide credential migration beyond this one format, see why 1-click password manager migration doesn't exist in 2026.

Ready to move off a shared KeePass file for good? Explore how Passwork structures vaults, folders, and access rights.

Frequently asked questions

Passwork vs KeePass: How encryption architecture differs

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

PassworkPasswork Team

Is KeePass enough? Password and access management for SMBs

KeePass is a popular solution for individual use, but it stops working when several people need access to the same credentials: overwritten changes, one master password for everyone, and no audit trail. See what SMBs need once offboarding, NIS2 and SOC 2 audits enter the picture.

Passwork BlogAlex Muntyan

Why 1-click password manager migration doesn’t exist in 2026

A password manager migration is a rare chance to review your organization’s entire access environment. Learn how to carry it forward securely while removing hidden risk without disrupting production access.

PassworkAlex Muntyan

Pegnitz é uma cidade industrial situada à entrada da Suíça da Francónia: compacta em dimensão, economicamente forte e culturalmente distinta. Vivem aqui cerca de 13 600 pessoas, no distrito de Bayreuth e na região metropolitana de Nuremberga, onde Pegnitz é o centro económico do distrito sul. A sua história remonta às antigas minas e à fundição Pegnitzhütte. Atualmente, a engenharia e a metalurgia coexistem com a indústria têxtil como base económica da cidade.

A vida cívica marca também o carácter da cidade. Pegnitz acolhe concertos de verão e feiras sazonais, mas o Gregori-Fest destaca-se: um festival infantil com uma tradição milenar, classificado como património cultural imaterial na Baviera. A estratégia municipal Pegnitz 2030 alarga este enfoque cívico ao planeamento económico e de infraestruturas, incluindo apoio ao emprego, desenvolvimento do centro da cidade e transição energética.

Esse crescimento chegou também às próprias operações de TI da administração. Com uma carga de trabalho mais pesada, o sistema baseado em ficheiros utilizado pela equipa para gerir acessos deixou de ser suficiente, levando-a a procurar uma alternativa self-hosted concebida para vários administradores a trabalhar em simultâneo.

O desafio: Os conflitos de sincronização baseados em ficheiros atrasavam uma pequena equipa de TI

A infraestrutura de TI de Stadt Pegnitz é gerida pelo departamento de TI do município. Antes de mudar para o Passwork, a equipa utilizava um cofre de palavras-passe de código aberto e baseado em ficheiros para armazenar as credenciais dos servidores, comutadores de rede e firewalls do município. A ferramenta funcionava bem como cofre pessoal, mas não foi concebida para acesso simultâneo multiutilizador, e essa limitação manifestava-se diariamente.

Uma equipa reduzida responsável por toda a rede municipal tem pouca margem para ferramentas que acrescentem sobrecarga de coordenação. Essa fricção levou Pegnitz a procurar uma alternativa.

O ficheiro de base de dados único não suportava mais do que um administrador a abri-lo em simultâneo sem risco de conflito de fusão. Na prática, isto significava que um administrador perguntava a outro: «Está agora no cofre?» antes de fazer qualquer alteração, para evitar sobrepor-se à atualização de um colega.

A configuração anterior criava vários problemas que se agravavam mutuamente:

• Cada alteração exigia coordenação verbal para evitar sobrepor as alterações de um colega
• Podiam circular cópias desatualizadas da base de dados caso alguém se esquecesse de distribuir a versão mais recente
• A ausência de um modelo de permissões baseado em funções impedia um controlo de acesso granular

Qualquer cofre baseado em ficheiros, sincronizado manualmente ou através de uma unidade de rede partilhada, encontra as mesmas limitações assim que mais do que uma pessoa precisa de acesso de escrita. Uma ferramenta que funciona bem para um único administrador transforma-se num problema de coordenação assim que entra uma segunda pessoa.

A solução: O Passwork cumpriu os requisitos de Pegnitz sem a sobrecarga de nível empresarial

Pegnitz precisava de uma única fonte de verdade para as credenciais de infraestrutura, sem sincronização baseada em ficheiros e sem a sobrecarga de uma implementação à escala empresarial.

«Como equipa de TI compacta, precisamos de ferramentas que facilitem o nosso trabalho, não que acrescentem sobrecarga administrativa. O Passwork tornou o nosso trabalho diário de infraestrutura mais seguro e muito mais rápido.» — Stadt Pegnitz IT team

A pesquisa, realizada em fóruns de TI e comunidades de código aberto, centrou-se em quatro requisitos que a interface e o modelo de implementação do Passwork satisfizeram diretamente:

• Implementação self-hosted e on-premise, para manter os dados das credenciais sob o controlo do município
• Cifragem do lado do cliente, para que os dados nunca cheguem ao servidor sem cifragem
• Acesso multiutilizador sem bloqueio de ficheiros
• Uma relação preço-valor razoável, uma vez que a equipa não tinha interesse em pagar por funcionalidades empresariais que não utilizaria

A interface do Passwork, concebida em torno do fluxo de trabalho real dos administradores e não como um cofre de estilo pessoal adaptado para equipas, foi a principal razão pela qual se destacou durante a avaliação.

Implementação e migração: Um lançamento rápido sem perda de dados

Dois fatores tornaram a avaliação de Pegnitz rápida:

• Implementação baseada em Docker, que permitiu à equipa testar todo o conjunto de funcionalidades sem um processo de configuração demorado
• Uma migração sem perdas a partir do cofre existente da equipa

Em conjunto, estes fatores resolveram os dois maiores riscos de qualquer mudança de gestor de palavras-passe: tempo de inatividade prolongado durante a implementação e perda de dados durante a migração. 

A migração a partir do antigo cofre baseado em ficheiros decorreu sem problemas através da função de importação integrada do Passwork, transferindo anos de dados de credenciais acumulados sem perdas. 

Resultados: Fluxo de trabalho diário mais rápido, sem sobrecarga de coordenação

O Passwork eliminou a etapa de coordenação que costumava preceder cada alteração de palavra-passe em Pegnitz. As alterações sincronizam agora com toda a equipa em tempo real, pelo que a conversa «está no cofre?» deixou de existir. A extensão do navegador reduziu o tempo despendido em inícios de sessão de rotina, e a rotação centralizada de credenciais substituiu o antigo processo manual de atualizar cópias locais uma a uma.

O ganho de segurança acompanhou o ganho de produtividade. Com as credenciais centralizadas e organizadas por funções, a equipa de TI deixou de precisar de descobrir qual a cópia local do cofre que está atualizada antes de alterar uma palavra-passe num servidor ou firewall.

Conclusão

A equipa de TI de Pegnitz enfrentava conflitos de fusão e uma constante coordenação verbal sempre que mais do que um administrador precisava de editar o cofre de credenciais partilhado. Resolveram o problema ao mudar para o Passwork, um cofre centralizado e self-hosted, com acesso multiutilizador em tempo real e permissões baseadas em funções.

Como resultado, a equipa eliminou por completo os conflitos de bloqueio de ficheiros e reduziu o tempo despendido na gestão de alterações de credenciais de rotina.

«O mais importante é que já não precisamos de verificar se outra pessoa está a trabalhar no cofre antes de fazer uma alteração. Podemos trabalhar em paralelo sem conflitos. Para nós, o Passwork é a solução self-hosted ideal.» — Stadt Pegnitz IT team

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

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

PassworkAlex Muntyan

Funcionalidades de segurança dos gestores de palavras-passe: como avaliá-las

A página de segurança do seu fornecedor faz muitas promessas. Eis o modelo de seis pilares para verificar quais são realmente verdadeiras, antes de assinar ou renovar.

PassworkPasswork Team

A cidade de Melle: como o Passwork centralizou a gestão de palavras-passe

A cidade de Melle, um município na Baixa Saxónia com mais de 48 000 habitantes, é reconhecida pela sua abordagem moderna à administração municipal e aos serviços ao cidadão. O governo local gere um vasto leque de responsabilidades: desenvolvimento urbano, educação, assistência social, proteção ambiental, iniciativas culturais, infraestruturas municipais e apoio económico à região. Nos últimos anos, Melle tem investido fortemente na transformação digital, com a introdução de serviços de atendimento ao cidadão em linha e a moderniz

PassworkAlex Muntyan

Pegnitz ist eine Industriestadt am Tor zur Fränkischen Schweiz: kompakt, wirtschaftlich stark und kulturell eigenständig. Hier leben etwa 13.600 Menschen, im Landkreis Bayreuth und in der Metropolregion Nürnberg, wo Pegnitz als wirtschaftliches Zentrum des südlichen Landkreises fungiert. Die Geschichte der Stadt reicht bis zu den früheren Bergwerken und der Pegnitzhütte zurück. Heute bilden Maschinenbau und Metallverarbeitung neben der Textilindustrie die wirtschaftliche Grundlage der Stadt.

Auch das bürgerschaftliche Leben prägt den Charakter der Stadt. Pegnitz veranstaltet Sommerkonzerte und saisonale Feste, doch das Gregori-Fest nimmt eine Sonderstellung ein: ein Kinderfest mit tausendjähriger Tradition, das in Bayern als immaterielles Kulturerbe geführt wird. Die Pegnitz-2030-Strategie der Gemeinde erweitert diesen bürgerschaftlichen Fokus auf die Wirtschafts- und Infrastrukturplanung, einschließlich Arbeitsplatzförderung, Innenstadtentwicklung und Energiewende.

Dieses Wachstum erreichte auch die IT der eigenen Verwaltung. Unter der gestiegenen Arbeitslast kam das dateibasierte System des Teams zur Zugriffsverwaltung nicht mehr hinterher, und man suchte nach einer selbst gehosteten Alternative für mehrere gleichzeitig arbeitende Administratoren.

Die Herausforderung: Dateibasierte Synchronisationskonflikte bremsten ein kleines IT-Team aus

Die IT-Infrastruktur der Stadt Pegnitz wird von der IT-Abteilung der Verwaltung betreut. Vor dem Wechsel zu Passwork nutzte das Team einen dateibasierten Open-Source-Passworttresor, um Zugangsdaten für die Server, Netzwerk-Switches und Firewalls der Kommune zu speichern. Das Tool funktionierte gut als persönlicher Tresor, war aber nicht für den gleichzeitigen Zugriff mehrerer Benutzer ausgelegt – diese Einschränkung zeigte sich täglich.

Ein kleines Team, das ein gesamtes kommunales Netzwerk betreut, hat wenig Spielraum für Tools, die zusätzlichen Koordinationsaufwand verursachen. Diese Reibung veranlasste Pegnitz, nach einer Alternative zu suchen.

Die einzelne Datenbankdatei konnte nicht von mehr als einem Administrator gleichzeitig geöffnet werden, ohne einen Merge-Konflikt zu riskieren. In der Praxis bedeutete das, dass ein Administrator einen anderen fragte: „Ist gerade jemand im Tresor?", bevor er eine Änderung vornahm, um zu vermeiden, dass die Aktualisierung eines Kollegen überschrieben wird.

Die alte Lösung führte zu mehreren sich verstärkenden Problemen:

• Jede Änderung erforderte eine mündliche Abstimmung, um das Überschreiben der Änderungen eines Kollegen zu vermeiden
• Veraltete Datenbankkopien konnten im Umlauf bleiben, wenn jemand vergaß, die neueste Version weiterzugeben
• Ohne rollenbasiertes Berechtigungsmodell war eine granulare Zugriffskontrolle nicht möglich

Jeder dateibasierte Tresor, der manuell oder über ein gemeinsames Netzlaufwerk synchronisiert wird, stößt an dieselben Grenzen, sobald mehr als eine Person Schreibzugriff benötigt. Ein Tool, das für einen einzelnen Administrator gut funktioniert, wird zum Koordinationsproblem, sobald eine zweite Person hinzukommt.

Die Lösung: Passwork erfüllte die Anforderungen von Pegnitz ohne Enterprise-Mehraufwand

Pegnitz benötigte eine zentrale, verlässliche Quelle für Infrastruktur-Zugangsdaten, ohne dateibasierte Synchronisation und ohne den Mehraufwand einer Enterprise-Lösung.

„Als kompaktes IT-Team brauchen wir Tools, die unsere Arbeit erleichtern, statt zusätzlichen Verwaltungsaufwand zu schaffen. Mit Passwork ist unsere tägliche Infrastrukturarbeit sicherer und deutlich schneller geworden." — Stadt Pegnitz IT team

Die Suche, die über IT-Foren und Open-Source-Communities erfolgte, konzentrierte sich auf vier Anforderungen, die die Oberfläche und das Bereitstellungsmodell von Passwork direkt erfüllten:

• Selbst gehostetes On-Premise-Deployment, um die Zugangsdaten unter der Kontrolle der Kommune zu behalten
• Clientseitige Verschlüsselung, sodass Daten den Server nie unverschlüsselt erreichen
• Mehrbenutzerzugriff ohne Dateisperren
• Ein angemessenes Preis-Leistungs-Verhältnis, da das Team keine Enterprise-Funktionen bezahlen wollte, die es nicht nutzen würde

Die Oberfläche von Passwork, die auf den tatsächlichen Workflow von Administratoren ausgerichtet ist und nicht auf einen für Teams nachgerüsteten Consumer-Tresor, war der Hauptgrund, warum sie sich bei der Evaluierung abhob.

Deployment und Migration: Ein schneller Rollout ohne Datenverlust

Zwei Faktoren machten die Evaluierung für Pegnitz schnell:

• Docker-basiertes Deployment, mit dem das Team den vollständigen Funktionsumfang ohne aufwendigen Einrichtungsprozess testen konnte
• Eine verlustfreie Migration aus dem bestehenden Tresor des Teams

Zusammen adressierten diese beiden Faktoren die größten Risiken bei jedem Wechsel des Passwortmanagers: längere Ausfallzeiten während des Rollouts und Datenverlust während des Umzugs. 

Die Migration aus dem vorherigen dateibasierten Tresor verlief über die integrierte Importfunktion von Passwork reibungslos und übertrug Jahre an angesammelten Zugangsdaten ohne Verlust. 

Ergebnisse: Schnellerer Arbeitsalltag, kein Koordinationsaufwand

Passwork hat den Koordinationsschritt überflüssig gemacht, der früher jeder Passwortänderung in Pegnitz vorausging. Änderungen werden jetzt in Echtzeit mit dem gesamten Team synchronisiert, sodass das Gespräch „Ist gerade jemand im Tresor?" entfällt. Die Browser-Erweiterung verkürzte die Zeit für routinemäßige Anmeldungen, und die zentrale Rotation der Zugangsdaten ersetzte den alten manuellen Prozess, bei dem lokale Kopien einzeln aktualisiert werden mussten.

Der Sicherheitsgewinn entsprach dem Produktivitätsgewinn. Da Zugangsdaten zentralisiert und rollenbasiert verwaltet werden, muss das IT-Team nicht mehr ermitteln, welche lokale Tresorkopie aktuell ist, bevor es ein Passwort auf einem Server oder einer Firewall rotiert.

Fazit

Das IT-Team von Pegnitz hatte mit Merge-Konflikten und ständiger mündlicher Abstimmung zu kämpfen, sobald mehr als ein Administrator den gemeinsamen Zugangsdaten-Tresor bearbeiten musste. Gelöst wurde dies durch den Wechsel zu Passwork, einem zentralisierten, selbst gehosteten Tresor mit Echtzeit-Mehrbenutzerzugriff und rollenbasierten Berechtigungen.

Dadurch hat das Team Konflikte durch Dateisperren vollständig beseitigt und den Zeitaufwand für die Verwaltung routinemäßiger Änderungen an Zugangsdaten reduziert.

„Das Wichtigste ist: Wir müssen nicht mehr prüfen, ob jemand anderes gerade im Tresor arbeitet, bevor wir eine Änderung vornehmen. Wir können parallel arbeiten, ohne Konflikte. Für uns ist Passwork die ideale selbst gehostete Lösung." — Stadt Pegnitz IT team

Kindernothilfe: Globale Mitarbeiterzusammenarbeit mit Passwork vereinfachen

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

PassworkAlex Muntyan

Sicherheitsfunktionen von Passwortmanagern: So lassen sie sich bewerten

Die Sicherheitsseite Ihres Anbieters verspricht viel. Hier ist das Sechs-Säulen-Framework, mit dem Sie prüfen, welche Versprechen tatsächlich zutreffen, bevor Sie unterschreiben oder verlängern.

PassworkPasswork Team

Die Stadt Melle: Wie Passwork die Passwortverwaltung zentralisierte

Die Stadt Melle, eine Gemeinde in Niedersachsen mit mehr als 48.000 Einwohnern, ist für ihren modernen Ansatz in der Stadtverwaltung und bei den Bürgerdiensten bekannt. Die Kommunalverwaltung verantwortet ein breites Aufgabenspektrum: Stadtentwicklung, Bildung, Sozialfürsorge, Umweltschutz, kulturelle Initiativen, kommunale Infrastruktur und Wirtschaftsförderung für die Region. In den letzten Jahren hat Melle stark in die digitale Transformation investiert, mit der Einführung von Online-Bürgerdiensten, der Modernis

PassworkAlex Muntyan

Pegnitz es una ciudad industrial situada en la puerta de entrada a la Suiza de Franconia: de escala compacta, económicamente sólida y con una identidad cultural propia. Allí viven unos 13 600 habitantes, en el distrito de Bayreuth y la región metropolitana de Núremberg, donde Pegnitz actúa como centro económico de la zona sur del distrito. Sus orígenes se remontan a antiguas minas y a la fundición Pegnitzhütte. Hoy, la ingeniería y la metalurgia conviven con la industria textil como base económica de la ciudad.

La vida cívica define el carácter de la ciudad en la misma medida. Pegnitz acoge conciertos de verano y ferias de temporada, aunque el Gregori-Fest destaca especialmente: un festival infantil con una tradición milenaria, reconocido como patrimonio cultural inmaterial de Baviera. La estrategia municipal Pegnitz 2030 extiende este enfoque cívico a la planificación económica y de infraestructuras, incluidos el apoyo al empleo, el desarrollo del centro urbano y la transición energética.

Ese crecimiento también llegó a las operaciones de TI de la propia administración. Con una carga de trabajo mayor, el sistema basado en archivos que el equipo utilizaba para gestionar los accesos dejó de ser suficiente, por lo que empezaron a buscar una alternativa autoalojada diseñada para que varios administradores trabajaran al mismo tiempo.

El reto: Los conflictos de sincronización de archivos ralentizaban a un pequeño equipo de TI

La infraestructura de TI de Stadt Pegnitz está a cargo del departamento de TI del municipio. Antes de pasar a Passwork, el equipo utilizaba una bóveda de contraseñas de código abierto basada en archivos para almacenar las credenciales de los servidores, los conmutadores de red y los cortafuegos del municipio. La herramienta funcionaba bien como bóveda personal, pero no estaba diseñada para el acceso simultáneo de varios usuarios, y esa limitación se notaba a diario.

Un equipo reducido que cubre toda la red municipal tiene poco margen para herramientas que añaden carga de coordinación. Esta fricción llevó a Pegnitz a buscar una alternativa.

El archivo de base de datos único no permitía que más de un administrador lo abriera al mismo tiempo sin arriesgarse a un conflicto de fusión. En la práctica, esto significaba que un administrador le preguntaba a otro: «¿Está en la bóveda ahora mismo?» antes de hacer cualquier cambio, para evitar sobrescribir la actualización de un compañero.

La configuración anterior generaba varios problemas que se acumulaban:

• Cada modificación exigía coordinación verbal para evitar sobrescribir los cambios de un compañero
• Podían circular copias desactualizadas de la base de datos si alguien olvidaba distribuir la versión más reciente
• La ausencia de un modelo de permisos basado en roles impedía un control de acceso granular

Cualquier bóveda basada en archivos que se sincronice manualmente o mediante una unidad de red compartida se enfrenta a las mismas limitaciones en cuanto más de una persona necesita acceso de escritura. Una herramienta que funciona bien para un único administrador genera un problema de coordinación en cuanto se suma una segunda persona.

La solución: Passwork cumplió los requisitos de Pegnitz sin la complejidad de una solución empresarial

Pegnitz necesitaba una única fuente de verdad para las credenciales de infraestructura, sin sincronización basada en archivos y sin la complejidad de una implementación a escala empresarial.

«Como equipo de TI reducido, necesitamos herramientas que faciliten nuestro trabajo, no que añadan carga administrativa. Passwork ha hecho que nuestro trabajo diario de infraestructura sea más seguro y mucho más rápido.» — Stadt Pegnitz IT team

La búsqueda, realizada a través de foros de TI y comunidades de código abierto, se centró en cuatro requisitos que la interfaz y el modelo de implementación de Passwork cumplían directamente:

• Implementación autoalojada y on-premise, para mantener los datos de credenciales bajo el control del municipio
• Cifrado del lado del cliente, de modo que los datos nunca llegan al servidor sin cifrar
• Acceso multiusuario sin bloqueo de archivos
• Una relación precio-valor razonable, ya que el equipo no tenía interés en pagar por funciones empresariales que no iba a utilizar

La interfaz de Passwork, diseñada en torno al flujo de trabajo real de los administradores y no como una bóveda de consumo adaptada después para equipos, fue el principal motivo por el que destacó durante la evaluación.

Implementación y migración: Una puesta en marcha rápida sin pérdida de datos

Dos factores agilizaron la evaluación de Pegnitz:

• Implementación basada en Docker, que permitió al equipo probar el conjunto completo de funciones sin un proceso de configuración prolongado
• Una migración sin pérdida de datos desde la bóveda existente del equipo

Juntos, estos factores resolvían los dos mayores riesgos de cualquier cambio de gestor de contraseñas: el tiempo de inactividad prolongado durante la puesta en marcha y la pérdida de datos durante la migración. 

La migración desde la bóveda basada en archivos anterior se realizó sin inconvenientes mediante la función de importación integrada de Passwork, conservando años de datos de credenciales acumulados sin ninguna pérdida. 

Resultados: Un flujo de trabajo diario más rápido, sin carga de coordinación

Passwork eliminó el paso de coordinación que antes precede a cada modificación de contraseña en Pegnitz. Los cambios ahora se sincronizan con todo el equipo en tiempo real, por lo que la conversación «¿está en la bóveda?» ha desaparecido. La extensión del navegador redujo el tiempo dedicado a los inicios de sesión rutinarios, y la rotación centralizada de credenciales sustituyó el antiguo proceso manual de actualizar las copias locales una por una.

La mejora en seguridad estuvo a la altura de la mejora en productividad. Con las credenciales centralizadas y organizadas por roles, el equipo de TI ya no necesita averiguar qué copia local de la bóveda es la vigente antes de rotar una contraseña en un servidor o un cortafuegos.

Conclusión

El equipo de TI de Pegnitz se enfrentaba a conflictos de fusión y a una constante coordinación verbal cada vez que más de un administrador necesitaba modificar la bóveda de credenciales compartida. Lo resolvieron adoptando Passwork, una bóveda centralizada y autoalojada con acceso multiusuario en tiempo real y permisos basados en roles.

Como resultado, el equipo eliminó por completo los conflictos de bloqueo de archivos y redujo el tiempo dedicado a gestionar los cambios de credenciales rutinarios.

«Lo más importante es que ya no tenemos que comprobar si alguien más está trabajando en la bóveda antes de hacer un cambio. Podemos trabajar en paralelo sin conflictos. Para nosotros, Passwork es la solución autoalojada ideal.» — Stadt Pegnitz IT team

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

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

PassworkAlex Muntyan

Funciones de seguridad de los gestores de contraseñas: Cómo evaluarlas

La página de seguridad del proveedor hace muchas promesas. Este es el marco de seis pilares para comprobar cuáles son realmente ciertas antes de firmar o renovar.

PassworkPasswork Team

La ciudad de Melle: Cómo Passwork centralizó la gestión de contraseñas

La ciudad de Melle, un municipio de Baja Sajonia con más de 48 000 habitantes, es reconocida por su enfoque moderno de la administración municipal y los servicios a la ciudadanía. El gobierno local gestiona una amplia gama de responsabilidades: desarrollo urbano, educación, atención social, protección del medio ambiente, iniciativas culturales, infraestructura municipal y apoyo económico para la región. En los últimos años, Melle ha invertido considerablemente en la transformación digital, introduciendo servicios ciudadanos en línea, moderniz

PassworkAlex Muntyan