Alex Muntyan

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

Os gestores de palavras-passe empresariais anunciam frequentemente a cifragem AES-256 e servidores que nunca veem as palavras-passe em texto não cifrado. No entanto, a força do algoritmo, por si só, não revela a quantidade de dados que uma única chave comprometida ou uma associação incorreta a um grupo pode expor.

Essa exposição depende do limite de cifragem: se uma chave desbloqueia uma organização, um cofre, uma pasta partilhada ou um segredo individual. Esta comparação analisa onde o Passwork, o Bitwarden, o Passbolt, o 1Password e o Keeper traçam esse limite, e o que os respetivos modelos significam para as permissões, o início de sessão por diretório, a automatização e a implementação.

A pergunta que revela o limite de cifragem

Imagine um gestor de palavras-passe autoalojado. Um administrador de sistemas responsável pelas cópias de segurança tem uma cópia da base de dados e junta-se à organização da empresa para aceder a uma palavra-passe partilhada. Que mais poderia decifrar com as chaves disponíveis na sua conta?

O Bitwarden cifra os itens da empresa com chaves por item, envolvidas por uma única chave simétrica da organização, de acordo com o seu white paper de segurança. Os membros da organização recebem acesso utilizável a essa chave, enquanto as coleções controlam o acesso e as permissões normais fornecidos pelo servidor, em vez de criarem limites criptográficos distintos. Num modelo de ameaça autoalojado, um atacante que obtenha os textos cifrados relevantes da base de dados e a chave de organização utilizável de um membro poderia decifrar itens da organização fora das coleções atribuídas a esse membro.

O Passwork, com a cifragem no lado do cliente ativada, utiliza uma chave distinta para cada cofre. As chaves dos itens situam-se sob as chaves dos cofres, e os utilizadores recebem uma chave de cofre envolvida apenas para os cofres a que têm acesso. Neste modelo de cifragem zero-knowledge, o mesmo administrador de sistemas consegue decifrar os cofres que lhe foram atribuídos, mas não cofres de Finanças ou Infraestrutura sem relação com a sua função.

O Passbolt cifra cada segredo separadamente para cada destinatário utilizando OpenPGP, conforme descrito na sua documentação de segurança (Pro v5.4, agosto de 2025). Não existe uma chave de contentor partilhada. Os utilizadores só conseguem decifrar os segredos cifrados para si, embora adicionar destinatários exija mais trabalho.

O 1Password isola os dados por cofre, onde as permissões também são definidas. O Keeper utiliza chaves de registo e chaves de pasta partilhada, em vez de uma única chave ao nível da organização. Nenhum dos dois oferece uma base de dados de cofre autoalojada para este teste em particular.

O Passwork e o Passbolt limitam o que uma cópia da base de dados, associada às chaves de um membro, pode revelar. O Bitwarden simplifica a distribuição de chaves, mas transforma a chave da organização num limite criptográfico mais amplo. Os produtos apenas na nuvem evitam este cenário específico de acesso à base de dados, embora a respetiva arquitetura de chaves continue a ser relevante.

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

Tipos de cofre: Governação acima dos cofres individuais

No Passwork, um tipo de cofre define quem pode criar cofres numa determinada classe e quais os administradores atribuídos automaticamente aos novos cofres desse tipo. Com a cifragem no lado do cliente ativada, esses administradores também recebem cópias envolvidas das novas chaves de cofre. O resultado é uma política repetível para departamentos e projetos.

Por exemplo, um tipo Finanças pode atribuir automaticamente o diretor financeiro a cada novo cofre financeiro. Um tipo DevOps pode manter os administradores de infraestrutura separados das vendas. Quando o responsável de um departamento sai, a empresa pode reatribuir o administrador do tipo e rever as concessões de acesso dentro dessa área, em vez de auditar uma função de administrador global dispersa. Isto torna-se útil à medida que o número de equipas e de cofres aumenta. Consulte as políticas de cofres do Passwork.

Dois tipos incorporados dispensam administradores da empresa. Um cofre pessoal pertence a um único utilizador. Um cofre privado partilhado permite que esse utilizador convide outras pessoas. Por predefinição, nem o Proprietário nem o Administrador da organização conseguem ler o respetivo conteúdo. Os administradores podem configurar quem tem permissão para criar estes tipos de cofre e partilhar informação a partir deles, incluindo desativar a criação não gerida de cofres pessoais.

Existem dois limites: atribuir um tipo não concede acesso retroativo a cofres já existentes, e os tipos só formam limites criptográficos quando a cifragem no lado do cliente está ativada. Caso contrário, permanecem apenas regras de governação.

Os concorrentes oferecem funcionalidades relacionadas, mas não a mesma camada de política. As políticas empresariais do Bitwarden regem aspetos como a autenticação, a recuperação e a pertença à organização, em vez de atribuírem automaticamente administradores por classe de cofre. O Passbolt não tem um contentor de cofre para classificar. O 1Password oferece isolamento ao nível do cofre e cofres pessoais, mas nenhuma regra equivalente à escala da classe para cofres recém-criados. As pastas partilhadas e as equipas do Keeper gerem o acesso sem políticas de criação de cofres por tipo.

Os tipos de cofre reduzem a probabilidade de os cofres departamentais recém-criados receberem uma administração inconsistente. Acrescentam uma decisão de política antecipada, mas reduzem a configuração manual repetida mais tarde.

Permissões de pasta: Herança ou modelos?

Uma árvore de pastas só é útil se as respetivas permissões se comportarem conforme os administradores esperam. Interfaces com um aspeto semelhante podem aplicar regras muito diferentes.

O Passwork oferece cinco níveis de permissão (leitura, escrita, gestão, administração e proibido) para utilizadores e grupos ao nível do cofre ou da pasta. O acesso ao cofre propaga-se para as pastas aninhadas, enquanto as regras de pasta podem restringir o acesso. Os direitos de administração e de proibição não podem ser substituídos em níveis inferiores. Quando se aplicam várias regras, prevalece o nível de prioridade mais alta. É importante notar que uma pasta não constitui um limite de cifragem distinto: o acesso ao seu conteúdo continua a depender da chave do cofre. Isto está alinhado com o modelo de controlo de acesso baseado em funções do Passwork.

O Bitwarden concede permissões através de coleções. As coleções aninhadas são etiquetas organizacionais; não herdam os itens nem os direitos da coleção principal. As pastas pessoais não têm permissões de partilha. As permissões individuais de um membro sobrepõem-se às permissões de grupo.

O Passbolt utiliza as pastas como modelos de permissões. Quando um item é criado, movido ou partilhado, aplicam-se as permissões da pasta, mas são as permissões próprias do item que determinam o acesso subsequente. Um criador pode tornar-se proprietário de uma palavra-passe e restringir o acesso mesmo quando outra pessoa é proprietária da pasta. Numa discussão da comunidade em julho de 2026 sobre a extensão v5.14.2, o Passbolt confirmou que este comportamento segue o seu modelo de permissões e referiu que estava planeada uma alteração na interface para impedir que não proprietários editassem permissões durante a criação.

O 1Password não tem pastas com permissões próprias dentro de um cofre; as etiquetas organizam os itens sem alterar o acesso. Por isso, partilhar permanentemente um subconjunto de itens exige outro cofre. Os grupos aninhados do fornecedor de identidade não são suportados para a pertença a cofres, de acordo com uma resposta da comunidade de setembro de 2026.

O Keeper suporta pastas partilhadas aninhadas e permissões ao nível do registo. As atribuições explícitas de registos sobrepõem-se aos direitos de pasta herdados. O seu modelo de pastas aninhadas tem um limite de profundidade de cinco níveis e esteve protegido por uma feature flag na versão 18.0.0 do cofre.

A árvore do Passwork suporta estruturas departamentais e exceções. O Bitwarden e o 1Password são mais simples de administrar, mas menos flexíveis para acessos profundamente aninhados. O comportamento de modelo do Passbolt exige atenção especial, porque as permissões de pasta e de item podem divergir.

Grupos: O que muda quando alguém se junta?

Com a cifragem no lado do cliente do Passwork, adicionar alguém a um grupo não lhe concede automaticamente todas as chaves de cofre associadas a esse grupo. É criado, antes, um pedido pendente para cada cofre relevante. Um detentor da chave tem de aprovar o pedido antes de o novo membro conseguir decifrar o respetivo conteúdo.

Isto separa o aprovisionamento de diretório do acesso criptográfico. A sincronização LDAP pode colocar um novo colaborador em grupos, mas o acesso a cofres sensíveis continua a exigir aprovação. Esta distinção é relevante durante a integração e a saída de colaboradores.

Para equipas que necessitam de menos aprovação manual, o Passwork oferece outro padrão: colocar os dados do departamento num único cofre e organizá-los em pastas. Aprova-se a chave de cofre do utilizador uma única vez; as permissões de pasta determinam depois o acesso dentro desse cofre à medida que a pertença aos grupos muda. A contrapartida é um limite criptográfico partilhado mais amplo do que vários cofres separados.

O Passbolt não pode utilizar este atalho. Como cada segredo é cifrado para cada destinatário, adicionar um membro ao grupo exige que alguém com acesso recifre os segredos relevantes para esse utilizador. A sincronização de diretório notifica um gestor de grupo e aguarda por este passo. O trabalho escala com o número de segredos, e não com o número de cofres.

O Bitwarden já distribui a chave da organização aos membros, pelo que as atribuições de coleções não exigem novas chaves de cifragem. No 1Password, as chaves de cofre atribuídas acompanham o acesso de grupo. O Keeper distribui o acesso através de pastas partilhadas atribuídas.

A escolha está entre pontos de aprovação mais rigorosos e um aprovisionamento mais fluido. O Passwork permite que as organizações escolham equilíbrios diferentes para departamentos diferentes; o Passbolt oferece um controlo de acesso granular por segredo, a um custo de partilha mais elevado.

O que o início de sessão por domínio realmente faz

Uma palavra-passe de domínio autentica um utilizador; não decifra os dados do cofre em nenhum destes produtos. As diferenças residem na forma como a autenticação e o aprovisionamento por diretório funcionam.

Passwork Self-hosted autentica-se diretamente junto do LDAP ou do Active Directory, incluindo ambientes com vários controladores de domínio. Os utilizadores iniciam sessão com credenciais de domínio; os grupos de diretório podem ser associados a grupos do Passwork. Com a cifragem no lado do cliente ativada, a palavra-passe de domínio autentica a sessão, enquanto chaves criptográficas distintas protegem o conteúdo dos cofres.

O Passwork Cloud ainda não oferecia LDAP à data desta comparação; estava previsto no roteiro, juntamente com o aprovisionamento SCIM. Ambas as implementações do Passwork suportam SSO SAML 2.0.

O Bitwarden Directory Connector sincroniza utilizadores e grupos, mas não os autentica junto do LDAP, conforme explica a sua documentação. O início de sessão baseado em domínio exige SSO Enterprise através de SAML ou OIDC. Em condições normais, os utilizadores continuam a desbloquear o cofre com uma palavra-passe mestra, a menos que estejam configurados dispositivos fidedignos ou o Key Connector.

O Passbolt também separa a sincronização LDAP do início de sessão. Os utilizadores autenticam-se com uma chave privada e uma frase-passe, ou através de SSO, e adicionar utilizadores sincronizados a grupos com segredos existentes exige recifragem.

O 1Password e o Keeper utilizam serviços de cofre baseados na nuvem, com integração SSO. O SSO Connect On-Prem do Keeper pode manter determinados componentes de identidade no hardware da empresa, mas o seu backend de cofre cifrado permanece na nuvem do Keeper. O Keeper lista os componentes locais suportados na sua documentação de implementação.

O início de sessão direto por LDAP do Passwork pode simplificar implementações autoalojadas sem um fornecedor de identidade separado. Os concorrentes orientados para a nuvem oferecem atualmente um aprovisionamento automatizado de identidade mais maduro; as funcionalidades previstas do Passwork não devem ser consideradas disponíveis atualmente.

Uma única API para palavras-passe e segredos de máquina

O Passwork gere as credenciais dos colaboradores e os segredos de máquina através da mesma instância, do mesmo modelo de permissões, do mesmo registo de auditoria e da mesma API REST. As equipas podem suportar fluxos de trabalho de CI/CD sem licenciar um produto de segredos separado.

Os seus clientes Web, de ambiente de trabalho, de navegador e móvel utilizam a mesma API em /api/v1. Uma CLI oficial e um conector Python de código aberto suportam fluxos de trabalho de DevOps. A CLI disponibiliza get e update para registos, api para chamadas diretas a endpoints, e exec para obter e decifrar um segredo, expor os valores como variáveis de ambiente e executar um comando. As contas de serviço são utilizadores com tokens de API criados por um administrador. Gerar um novo token pessoal revoga as sessões de API anteriores do utilizador.

Este modelo unificado tem limitações: a API é baseada em pull, sem webhooks de saída, e o /v1/batch suporta apenas agregação de leitura, até 25 subpedidos GET. As integrações orientadas por eventos têm de efetuar polling ou consumir exportações de syslog.

Os concorrentes seguem abordagens diferentes. O Bitwarden Secrets Manager é um add-on pago separado, com contas de máquina e acesso baseado em projetos, em vez de acesso através das coleções do Password Manager. O Keeper Secrets Manager é outra linha de produtos, com SDKs e uma gateway ligada à nuvem. As contas de serviço do 1Password funcionam com cofres e permissões definidos, mas o respetivo âmbito é fixado no momento da criação do token; alterá-lo exige um novo token. O Passbolt expõe uma API e ferramentas de automatização, mantendo o seu modelo de partilha por segredo.

O Passwork privilegia um único sistema operacional para pessoas e automatização. Os produtos especializados em segredos podem oferecer integrações dedicadas, mas introduzem superfícies adicionais de licenciamento e gestão.

Onde o cofre é executado

A implementação pode eliminar produtos de uma lista restrita ainda antes de qualquer comparação de funcionalidades. O Passwork, o Bitwarden e o Passbolt permitem que as organizações alojem o próprio cofre. O 1Password e o Keeper mantêm o backend do cofre nos respetivos serviços na nuvem.

O Passwork suporta implementação local (on-premise) em Linux, Windows Server ou Docker, dando às organizações controlo sobre a sua infraestrutura e cópias de segurança. A sua oferta de nuvem alojada na UE utiliza uma base de dados e um tenant separados para cada cliente, em vez de armazenar os registos de todos os clientes num único esquema partilhado. Estas opções são discutidas no guia de modelos de implementação do Passwork.

O Bitwarden também oferece autoalojamento genuíno, embora a sua licença Enterprise continue associada a uma subscrição ativa na nuvem. O Passbolt suporta tanto o autoalojamento como um serviço alojado. Os componentes de SSO e de integração do Keeper, passíveis de implementação local, não alteram a localização do respetivo backend de cofre.

O autoalojamento dá às organizações controlo sobre a localização dos dados, mas também a responsabilidade pelas atualizações, pelas cópias de segurança e pela disponibilidade. Os produtos apenas na nuvem reduzem essa carga de trabalho, desde que a política permita o alojamento externo.

Cifragem opcional no lado do cliente e metadados

O Passwork Cloud utiliza sempre a cifragem no lado do cliente. O Passwork Self-hosted permite que os administradores a desativem. Os outros quatro produtos desta comparação não oferecem um controlo equivalente.

A cifragem no lado do servidor pode ser adequada para uma equipa pequena, com administradores de confiança, que privilegie a concessão imediata de acesso e uma recuperação mais simples. Desativar a cifragem no lado do cliente elimina o isolamento criptográfico por cofre: os tipos de cofre continuam a controlar a criação e a administração, mas deixam de formar limites de cifragem distintos.

Mesmo com a cifragem no lado do cliente ativada, o servidor do Passwork consegue ler nomes de itens, logins, descrições e URLs, para suportar a pesquisa no lado do servidor. Os valores das palavras-passe permanecem cifrados no cliente e fora do índice de pesquisa. O Bitwarden e o Keeper também cifram estes campos de metadados, mantendo-os ocultos do servidor, ao custo de uma decifragem no lado do cliente para a pesquisa. O Passbolt v5 deixa os nomes de pasta e as etiquetas sem cifragem.

Trata-se de uma contrapartida real entre segurança e usabilidade. Os compradores devem avaliar tanto a confidencialidade das palavras-passe como a exposição de metadados, especialmente quando os registos contêm nomes de sistemas sensíveis ou identificadores de conta.

Quanto custa

Estes são os preços de tabela publicados por utilizador, por mês, com faturação anual, a partir de outubro de 2026. Os fornecedores utilizam moedas e pacotes diferentes, pelo que a comparação é apenas indicativa.

O Passwork Padrão custa 3 € e o Avançado 4,50 € por utilizador, por mês. O Avançado inclui gestão de segredos e funcionalidades de identidade empresarial. Os clientes autoalojados também podem optar por uma licença vitalícia paga uma única vez. O Bitwarden Teams custa 4 $ e o Enterprise 6 $, com o Secrets Manager cobrado separadamente a 6 $ e 12 $, respetivamente. O Keeper Business parte de 4 $ e o Enterprise de 6 $, enquanto o KeeperPAM é cobrado separadamente. O 1Password Business custa 8,99 $. O Passbolt Pro autoalojado custa 4,50 € com um mínimo de dez utilizadores.

O Bitwarden Secrets Manager custa 6 $ por utilizador, por mês, no Teams, ou 12 $ no Enterprise, cobrado separadamente do Password Manager. As organizações que utilizam ambos os produtos devem comparar os custos de licenciamento combinados com base no número de utilizadores em cada um. O Passwork Avançado inclui a gestão de palavras-passe e de segredos numa única subscrição. O modelo de cifragem por segredo do Passbolt acrescenta trabalho administrativo ao partilhar segredos ou ao adicionar membros a grupos, um custo que os preços de subscrição, por si só, não conseguem captar.

Onde os concorrentes levam vantagem

O Passbolt oferece partilha e revogação diretas por segredo. Cada destinatário recebe um texto cifrado com a respetiva chave pública. A revogação remove do serviço a cópia cifrada desse destinatário. Isto permite um controlo granular, mas cada destinatário adicional exige trabalho de cifragem e de armazenamento. Tal como noutros gestores de palavras-passe, a revogação não consegue apagar o texto não cifrado nem as cópias que um destinatário já tenha guardado.

O Passwork armazena um único texto cifrado partilhado e distribui chaves envolvidas, em vez de duplicar cada segredo para cada destinatário. Remover uma concessão permanente de cofre ou de pasta remove o acesso à chave correspondente. A sua caixa de entrada funciona de forma diferente: uma entrega direta entre utilizadores envolve a chave de um item para o destinatário, e um item aceite torna-se uma cópia no cofre do destinatário. A entrega por caixa de entrada de grupo utiliza um percurso sem cifragem no lado do cliente. A caixa de entrada é, portanto, uma transferência, e não uma concessão permanentemente revogável.

O Bitwarden e o Keeper protegem metadados que o Passwork expõe para a pesquisa no lado do servidor. O Keeper também oferece atalhos de registo e permissões diretas por registo em pastas partilhadas, além de uma plataforma mais ampla de acesso privilegiado. O 1Password tem menos regras de herança e exceções, o que facilita a configuração para equipas que não necessitam de permissões de pasta complexas. O Bitwarden combina um preço de entrada baixo, autoalojamento e clientes consolidados.

Estas são vantagens substanciais. A flexibilidade do Passwork ajuda organizações com estruturas de acesso complexas, mas também cria mais políticas para conceber e manter.

Como escolher: Comece pelo limite

Comece pelo cenário de falha, e não pelo algoritmo de cifragem. Se uma conta for comprometida, que registos conseguem as suas chaves decifrar? O que muda se o atacante também obtiver uma cópia de segurança da base de dados? Depois, verifique se o modelo de permissões reflete os limites departamentais e se a integração de colaboradores pode expandir o acesso por acidente.

O Passwork é adequado a organizações que necessitem de cofres departamentais separados, permissões de pasta herdadas, autenticação LDAP direta on-premise, e credenciais de colaboradores e de máquina num único sistema. O Passbolt favorece o controlo por segredo nos casos em que o custo administrativo da partilha é aceitável. O Bitwarden oferece uma distribuição de chaves simples, à escala da organização, e autoalojamento. O 1Password minimiza a complexidade de configuração num modelo centrado na nuvem. O Keeper combina controlos de pasta partilhada com uma oferta mais ampla de acesso privilegiado.

Se Finanças, Recursos Humanos e Infraestrutura forem unidades operacionais separadas, decida se também devem ter limites criptográficos separados. Essa decisão determina a potencial exposição de uma única chave comprometida de forma mais direta do que um rótulo AES-256.

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

Perguntas frequentes

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

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

PassworkPasswork Team

Passwork vs KeePass: Em que difere a arquitetura de cifragem

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

PassworkPasswork Team

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

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

PassworkPasswork Team

Business-Passwortmanager werben häufig mit AES-256-Verschlüsselung und Servern, die niemals Passwörter im Klartext sehen. Doch die Stärke der Chiffre allein sagt nichts darüber aus, wie viele Daten ein kompromittierter Schlüssel oder eine falsch zugewiesene Gruppenmitgliedschaft offenlegen können.

Wie weit diese Offenlegung reicht, hängt von der Verschlüsselungsgrenze ab: ob ein Schlüssel eine Organisation, einen Tresor, einen gemeinsam genutzten Ordner oder ein einzelnes Secret entsperrt. Dieser Vergleich untersucht, wo Passwork, Bitwarden, Passbolt, 1Password und Keeper diese Grenze ziehen und was ihre Architektur für Berechtigungen, Verzeichnisanmeldung, Automatisierung und Bereitstellung bedeutet.

Die Frage, die die Verschlüsselungsgrenze offenlegt

Stellen Sie sich einen selbst gehosteten Passwortmanager vor. Ein für Backups zuständiger Systemadministrator besitzt einen Datenbank-Dump und tritt der Unternehmensorganisation bei, um auf ein gemeinsam genutztes Passwort zuzugreifen. Was könnte er mit den seinem Konto zur Verfügung stehenden Schlüsseln noch entschlüsseln?

Bitwarden verschlüsselt Unternehmenselemente laut seinem Security-Whitepaper mit Einzelschlüsseln pro Element, die von einem symmetrischen Organisationsschlüssel umschlossen werden. Organisationsmitglieder erhalten nutzbaren Zugriff auf diesen Schlüssel, während Collections den regulären, vom Server bereitgestellten Zugriff und die Berechtigungen steuern, anstatt eigene kryptografische Grenzen zu schaffen. In einem Bedrohungsmodell für selbst gehostete Instanzen könnte ein Angreifer, der an die relevanten Datenbank-Chiffretexte und den nutzbaren Organisationsschlüssel eines Mitglieds gelangt, Organisationselemente außerhalb der diesem Mitglied zugewiesenen Collections entschlüsseln.

Passwork verwendet bei aktivierter clientseitiger Verschlüsselung für jeden Tresor einen eigenen Schlüssel. Element-Schlüssel liegen unterhalb der Tresor-Schlüssel, und Benutzer erhalten einen umschlossenen Tresor-Schlüssel nur für Tresore, auf die sie zugreifen dürfen. In diesem Zero-Knowledge-Verschlüsselungsmodell kann derselbe Systemadministrator seine zugewiesenen Tresore entschlüsseln, nicht aber unzusammenhängende Finanz- oder Infrastruktur-Tresore.

Passbolt verschlüsselt laut seiner Sicherheitsdokumentation (Pro v5.4, August 2025) jedes Secret mit OpenPGP separat für jeden Empfänger. Es gibt keinen gemeinsamen Container-Schlüssel. Benutzer können nur Secrets entschlüsseln, die für sie verschlüsselt wurden, auch wenn das Hinzufügen von Empfängern mehr Aufwand bedeutet.

1Password isoliert Daten nach Tresor, wo auch die Berechtigungen festgelegt werden. Keeper verwendet Eintrags-Schlüssel und Schlüssel für gemeinsam genutzte Ordner anstelle eines einzigen organisationsweiten Schlüssels. Für diesen speziellen Test bietet keines der beiden Produkte eine selbst gehostete Tresor-Datenbank an.

Passwork und Passbolt begrenzen, was ein Datenbank-Dump zusammen mit den Schlüsseln eines einzelnen Mitglieds offenlegen kann. Bitwarden vereinfacht die Schlüsselverteilung, macht den Organisationsschlüssel aber zu einer breiteren kryptografischen Grenze. Die reinen Cloud-Produkte umgehen dieses spezielle Datenbankzugriffsszenario, auch wenn ihre Schlüsselarchitektur weiterhin relevant ist.

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

Tresortypen: Governance oberhalb einzelner Tresore

In Passwork legt ein Tresortyp fest, wer Tresore einer bestimmten Klasse erstellen darf und welche Administratoren neuen Tresoren dieses Typs automatisch zugewiesen werden. Bei aktivierter clientseitiger Verschlüsselung erhalten diese Administratoren zusätzlich umschlossene Kopien der neuen Tresor-Schlüssel. Das Ergebnis ist eine wiederholbare Richtlinie für Abteilungen und Projekte.

Zum Beispiel kann ein Finance-Typ den CFO automatisch jedem neuen Finanz-Tresor zuweisen. Ein DevOps-Typ kann Infrastruktur-Administratoren getrennt vom Vertrieb halten. Verlässt eine Abteilungsleitung das Unternehmen, kann das Unternehmen den Typ-Administrator neu zuweisen und die Berechtigungen in diesem Bereich überprüfen, anstatt eine unübersichtliche globale Administratorrolle zu prüfen. Das wird mit wachsender Team- und Tresoranzahl nützlich. Mehr zu den Tresor-Richtlinien von Passwork.

Zwei integrierte Typen kommen ohne Unternehmens-Administratoren aus. Ein persönlicher Tresor gehört einem einzelnen Benutzer. Ein privater gemeinsam genutzter Tresor erlaubt diesem Benutzer, andere einzuladen. Standardmäßig können selbst der Besitzer oder Admin der Organisation deren Inhalte nicht lesen. Administratoren können festlegen, wer diese Tresortypen erstellen und Informationen daraus freigeben darf, einschließlich der Möglichkeit, die unkontrollierte Erstellung persönlicher Tresore zu deaktivieren.

Es gibt zwei Einschränkungen: Das Zuweisen eines Typs gewährt keinen rückwirkenden Zugriff auf bestehende Tresore, und Typen bilden nur bei aktivierter clientseitiger Verschlüsselung kryptografische Grenzen. Andernfalls bleiben sie reine Governance-Regeln.

Die Wettbewerber bieten verwandte Funktionen, aber keine vergleichbare Richtlinienebene. Bitwardens Enterprise-Richtlinien regeln Aspekte wie Authentifizierung, Wiederherstellung und Organisationsmitgliedschaft, weisen aber keine Administratoren automatisch nach Tresortyp zu. Passbolt besitzt keinen Tresor-Container, der klassifiziert werden könnte. 1Password bietet Isolation auf Tresorebene und persönliche Tresore, aber keine vergleichbare typweite Regel für neu erstellte Tresore. Keepers gemeinsam genutzte Ordner und Teams verwalten den Zugriff ohne typisierte Richtlinien zur Tresorerstellung.

Tresortypen verringern das Risiko, dass neu erstellte Abteilungstresore uneinheitlich administriert werden. Sie erfordern eine Richtlinienentscheidung im Vorfeld, reduzieren aber spätere wiederholte manuelle Konfiguration.

Ordnerberechtigungen: Vererbung oder Vorlagen?

Eine Ordnerstruktur ist nur dann nützlich, wenn sich ihre Berechtigungen so verhalten, wie Administratoren es erwarten. Ähnlich aussehende Oberflächen können sehr unterschiedliche Regeln durchsetzen.

Passwork bietet für Benutzer und Gruppen auf Tresor- oder Ordnerebene fünf Berechtigungsstufen: Lesen, Schreiben, Verwalten, Admin und Verboten. Der Tresorzugriff vererbt sich auf verschachtelte Ordner, während Ordnerregeln den Zugriff einschränken können. Admin- und Verboten-Rechte können weiter unten nicht überschrieben werden. Gelten mehrere Regeln gleichzeitig, setzt sich die Stufe mit höherer Priorität durch. Wichtig: Ein Ordner bildet keine eigene Verschlüsselungsgrenze – der Zugriff auf seine Inhalte hängt weiterhin vom Tresor-Schlüssel ab. Dies ergänzt Passworks Modell der rollenbasierten Zugriffskontrolle.

Bitwarden vergibt Berechtigungen über Collections. Verschachtelte Collections sind organisatorische Kennzeichnungen; sie erben weder die Elemente noch die Rechte der übergeordneten Collection. Persönliche Ordner besitzen keine Freigabeberechtigungen. Individuelle Mitgliederberechtigungen überschreiben Gruppenberechtigungen.

Passbolt verwendet Ordner als Berechtigungsvorlagen. Wird ein Element erstellt, verschoben oder freigegeben, gelten zunächst die Berechtigungen des Ordners; anschließend bestimmen die eigenen Berechtigungen des Elements den weiteren Zugriff. Ein Ersteller kann Besitzer eines Passworts werden und den Zugriff einschränken, selbst wenn jemand anderes Besitzer des Ordners ist. In einer Community-Diskussion vom Juli 2026 zur Erweiterung v5.14.2 bestätigte Passbolt, dass dieses Verhalten seinem Berechtigungsmodell entspricht, und kündigte eine geplante UI-Änderung an, die verhindern soll, dass Nicht-Besitzer während der Erstellung Berechtigungen bearbeiten.

1Password besitzt innerhalb eines Tresors keine berechtigungstragenden Ordner; Tags organisieren Elemente, ohne den Zugriff zu verändern. Um eine Teilmenge von Elementen dauerhaft freizugeben, ist daher ein weiterer Tresor erforderlich. Laut einer Community-Antwort vom September 2026 werden verschachtelte Identity-Provider-Gruppen für die Tresormitgliedschaft nicht unterstützt.

Keeper unterstützt verschachtelte gemeinsam genutzte Ordner und Berechtigungen auf Eintragsebene. Explizite Eintragszuweisungen überschreiben vererbte Ordnerrechte. Sein Modell verschachtelter Ordner ist auf fünf Ebenen begrenzt und war in Tresor-Release 18.0.0 hinter einem Feature-Flag verborgen.

Passworks Struktur unterstützt Abteilungsgliederungen und Ausnahmen. Bitwarden und 1Password sind einfacher zu administrieren, aber weniger flexibel bei tief verschachteltem Zugriff. Passbolts Vorlagenverhalten erfordert besondere Aufmerksamkeit, da Ordner- und Elementberechtigungen voneinander abweichen können.

Gruppen: Was ändert sich, wenn jemand beitritt?

Bei aktivierter clientseitiger Verschlüsselung in Passwork erhält eine Person, die einer Gruppe hinzugefügt wird, nicht automatisch alle mit dieser Gruppe verknüpften Tresor-Schlüssel. Stattdessen entsteht für jeden betroffenen Tresor eine ausstehende Anfrage. Ein Schlüsselinhaber muss die Anfrage genehmigen, bevor das neue Mitglied die Inhalte entschlüsseln kann.

Damit werden Verzeichnis-Provisioning und kryptografischer Zugriff getrennt. Die LDAP-Synchronisierung kann einen neuen Mitarbeiter in Gruppen aufnehmen, doch der Zugriff auf sensible Tresore erfordert weiterhin eine Genehmigung. Diese Unterscheidung ist bei Onboarding und Offboarding relevant.

Für Teams, die weniger manuelle Genehmigungen benötigen, bietet Passwork ein weiteres Muster: Die Daten der Abteilung in einem Tresor ablegen und in Ordnern organisieren. Der Tresor-Schlüssel des Benutzers wird einmalig genehmigt; Ordnerberechtigungen bestimmen anschließend den Zugriff innerhalb dieses Tresors, wenn sich die Gruppenmitgliedschaft ändert. Der Kompromiss ist eine breitere gemeinsam genutzte kryptografische Grenze als bei mehreren getrennten Tresoren.

Passbolt kann diese Abkürzung nicht nutzen. Da jedes Secret für jeden Empfänger einzeln verschlüsselt wird, muss jemand mit Zugriff die betreffenden Secrets für das neue Mitglied neu verschlüsseln, wenn eine Gruppe erweitert wird. Die Verzeichnissynchronisierung benachrichtigt einen Gruppenverantwortlichen und wartet auf diesen Schritt. Der Aufwand skaliert mit der Anzahl der Secrets, nicht mit der Anzahl der Tresore.

Bitwarden verteilt den Organisationsschlüssel bereits an die Mitglieder, sodass Collection-Zuweisungen keine neuen Verschlüsselungsschlüssel erfordern. Bei 1Password folgen zugewiesene Tresor-Schlüssel dem Gruppenzugriff. Keeper verteilt den Zugriff über zugewiesene gemeinsam genutzte Ordner.

Die Wahl besteht zwischen strengeren Genehmigungsschritten und reibungsloserem Provisioning. Passwork erlaubt es Organisationen, für unterschiedliche Abteilungen unterschiedliche Gewichtungen zu wählen; Passbolt bietet feingranularen Zugriff pro Secret zu einem höheren Freigabeaufwand.

Was die Domänenanmeldung tatsächlich bewirkt

Ein Domänenpasswort authentifiziert einen Benutzer; es entschlüsselt in keinem dieser Produkte Tresordaten. Die Unterschiede liegen darin, wie Verzeichnisauthentifizierung und Provisioning funktionieren.

Passwork Self-hosted authentifiziert direkt gegen LDAP oder Active Directory, auch in Umgebungen mit mehreren Domänencontrollern. Benutzer melden sich mit ihren Domänen-Zugangsdaten an; Verzeichnisgruppen lassen sich auf Passwork-Gruppen abbilden. Bei aktivierter clientseitiger Verschlüsselung authentifiziert das Domänenpasswort die Sitzung, während separate kryptografische Schlüssel die Tresorinhalte schützen.

Passwork Cloud bot zum Zeitpunkt dieses Vergleichs noch kein LDAP an; es stand zusammen mit SCIM-Provisioning auf der Roadmap. Beide Passwork-Bereitstellungen unterstützen SAML-2.0-SSO.

Bitwarden Directory Connector synchronisiert Benutzer und Gruppen, authentifiziert sie laut Dokumentation jedoch nicht gegen LDAP. Eine domänenbasierte Anmeldung erfordert Enterprise-SSO über SAML oder OIDC. Benutzer entsperren ihren Tresor normalerweise weiterhin mit einem Masterpasswort, sofern nicht Trusted Devices oder Key Connector konfiguriert sind.

Passbolt trennt ebenfalls LDAP-Synchronisierung und Anmeldung. Benutzer authentifizieren sich mit einem privaten Schlüssel und einer Passphrase oder per SSO, und das Hinzufügen synchronisierter Benutzer zu Gruppen mit bestehenden Secrets erfordert eine Neuverschlüsselung.

1Password und Keeper nutzen cloudbasierte Tresordienste mit SSO-Integration. Keepers SSO Connect On-Prem kann bestimmte Identitätskomponenten auf unternehmenseigener Hardware belassen, doch das verschlüsselte Tresor-Backend verbleibt in Keepers Cloud. Keeper listet die unterstützten lokalen Komponenten in seiner Bereitstellungsdokumentation auf.

Passworks direkte LDAP-Anmeldung kann selbst gehostete Bereitstellungen ohne separaten Identity-Provider vereinfachen. Cloud-first ausgerichtete Wettbewerber bieten derzeit ein ausgereifteres automatisiertes Identity-Provisioning; geplante Passwork-Funktionen sollten nicht als bereits verfügbar betrachtet werden.

Eine API für Passwörter und Machine Secrets

Passwork verwaltet Mitarbeiter-Zugangsdaten und Machine Secrets über dieselbe Instanz, dasselbe Berechtigungsmodell, dasselbe Audit-Log und dieselbe REST-API. Teams können CI/CD-Workflows unterstützen, ohne ein separates Secrets-Produkt lizenzieren zu müssen.

Die Web-, Desktop-, Browser- und Mobil-Clients nutzen dieselbe API unter /api/v1. Eine offizielle CLI und ein Open-Source-Python-Connector unterstützen DevOps-Workflows. Die CLI bietet get und update für Einträge, api für direkte Endpunktaufrufe sowie exec, um ein Secret abzurufen und zu entschlüsseln, die Werte als Umgebungsvariablen bereitzustellen und einen Befehl auszuführen. Servicekonten sind Benutzer mit von einem Administrator erstellten API-Tokens. Das Erzeugen eines neuen persönlichen Tokens widerruft die vorherigen API-Sitzungen des Benutzers.

Dieses einheitliche Modell hat Grenzen: Die API ist pull-basiert, es gibt keine ausgehenden Webhooks, und /v1/batch unterstützt nur lesende Aggregation mit bis zu 25 GET-Teilanfragen. Ereignisgesteuerte Integrationen müssen pollen oder Syslog-Exporte konsumieren.

Die Wettbewerber verfolgen andere Ansätze. Bitwarden Secrets Manager ist ein separates kostenpflichtiges Add-on mit Machine Accounts und projektbasiertem Zugriff anstelle des Zugriffs über Password-Manager-Collections. Keeper Secrets Manager ist eine eigene Produktlinie mit SDKs und einem cloudverbundenen Gateway. Die Servicekonten von 1Password arbeiten mit festgelegten Tresoren und Berechtigungen, doch ihr Geltungsbereich wird bei der Erstellung eines Tokens fixiert; eine Änderung erfordert ein neues Token. Passbolt bietet eine API und Automatisierungswerkzeuge, behält dabei aber sein Freigabemodell pro Secret bei.

Passwork setzt auf ein einziges operatives System für Mitarbeiter und Automatisierung. Spezialisierte Secrets-Produkte können dedizierte Integrationen bieten, bringen aber zusätzliche Lizenzierungs- und Verwaltungsebenen mit sich.

Wo der Tresor läuft

Die Bereitstellungsart kann Produkte schon vor jedem Funktionsvergleich von einer Auswahlliste ausschließen. Passwork, Bitwarden und Passbolt erlauben Organisationen, den Tresor selbst zu hosten. 1Password und Keeper belassen das Tresor-Backend in ihren eigenen Cloud-Diensten.

Passwork unterstützt eine On-Premise-Bereitstellung auf Linux, Windows Server oder Docker und gibt Organisationen so die Kontrolle über Infrastruktur und Backups. Das in der EU gehostete Cloud-Angebot verwendet für jeden Kunden eine separate Datenbank und einen eigenen Tenant, anstatt alle Kundendaten in einem gemeinsamen Schema zu speichern. Diese Optionen werden im Leitfaden zu Bereitstellungsmodellen von Passwork erläutert.

Bitwarden bietet ebenfalls echtes Self-Hosting an, wobei die Enterprise-Lizenz weiterhin an ein aktives Cloud-Abonnement gebunden ist. Passbolt unterstützt sowohl Self-Hosting als auch einen gehosteten Dienst. Keepers lokal bereitstellbare SSO- und Integrationskomponenten ändern nichts am Standort des Tresor-Backends.

Self-Hosting gibt Organisationen die Kontrolle über den Datenstandort, überträgt ihnen aber auch die Verantwortung für Updates, Backups und Verfügbarkeit. Reine Cloud-Produkte reduzieren diesen Aufwand, sofern die eigenen Richtlinien ein externes Hosting zulassen.

Optionale clientseitige Verschlüsselung und Metadaten

Passwork Cloud verwendet stets clientseitige Verschlüsselung. Bei selbst gehostetem Passwork können Administratoren sie deaktivieren. Die übrigen vier Produkte dieses Vergleichs bieten keine vergleichbare Option.

Serverseitige Verschlüsselung kann sich für ein kleines Team mit vertrauenswürdigen Administratoren eignen, dem sofortige Zugriffsvergabe und eine einfachere Wiederherstellung wichtiger sind. Das Deaktivieren der clientseitigen Verschlüsselung hebt die kryptografische Isolation pro Tresor auf: Tresortypen steuern weiterhin Erstellung und Administration, bilden aber keine eigenen Verschlüsselungsgrenzen mehr.

Selbst bei aktivierter clientseitiger Verschlüsselung kann der Passwork-Server Elementnamen, Logins, Beschreibungen und URLs lesen, um die serverseitige Suche zu unterstützen. Passwortwerte bleiben clientseitig verschlüsselt und außerhalb des Suchindex. Bitwarden und Keeper verschlüsseln auch diese Metadatenfelder und halten sie so vor dem Server verborgen – auf Kosten einer clientseitigen Entschlüsselung für die Suche. Passbolt v5 lässt Ordnernamen und Tags unverschlüsselt.

Das ist ein echter Kompromiss zwischen Sicherheit und Benutzerfreundlichkeit. Käufer sollten sowohl die Vertraulichkeit der Passwörter als auch die Offenlegung von Metadaten bewerten, besonders wenn Einträge sensible Systemnamen oder Kontokennungen enthalten.

Was es kostet

Dies sind veröffentlichte Listenpreise pro Benutzer und Monat bei jährlicher Abrechnung, Stand Oktober 2026. Die Anbieter verwenden unterschiedliche Währungen und Paketierungen, weshalb der Vergleich nur eine grobe Orientierung bietet.

Passwork Standard kostet 3 €, Advanced 4,50 € pro Benutzer und Monat. Advanced umfasst Secrets-Management und Enterprise-Identitätsfunktionen. Self-hosted-Kunden können außerdem eine einmalige Lifetime-Lizenz wählen. Bitwarden Teams kostet 4 $, Enterprise 6 $, wobei der Secrets Manager separat mit 6 $ beziehungsweise 12 $ berechnet wird. Keeper Business startet bei 4 $, Enterprise bei 6 $, während KeeperPAM separat berechnet wird. 1Password Business kostet 8,99 $. Passbolt Pro Self-hosted kostet 4,50 € bei einem Mindestumfang von zehn Benutzern.

Der Bitwarden Secrets Manager kostet 6 $ pro Benutzer und Monat im Tarif Teams beziehungsweise 12 $ im Tarif Enterprise und wird separat vom Password Manager abgerechnet. Organisationen, die beide Produkte nutzen, sollten die kombinierten Lizenzkosten anhand der jeweiligen Benutzerzahl vergleichen. Passwork Advanced vereint Passwort- und Secrets-Management in einem Abonnement. Passbolts Verschlüsselungsmodell pro Secret erzeugt zusätzlichen administrativen Aufwand beim Freigeben von Secrets oder beim Hinzufügen von Gruppenmitgliedern – ein Kostenfaktor, den die Abonnementpreise allein nicht abbilden.

Wo Wettbewerber im Vorteil sind

Passbolt ermöglicht direkte Freigabe und direkten Entzug pro Secret. Jeder Empfänger erhält einen mit seinem öffentlichen Schlüssel verschlüsselten Chiffretext. Ein Entzug entfernt die verschlüsselte Kopie dieses Empfängers aus dem Dienst. Das ermöglicht feingranulare Kontrolle, erfordert aber für jeden zusätzlichen Empfänger Verschlüsselungs- und Speicheraufwand. Wie bei anderen Passwortmanagern kann ein Entzug keinen Klartext oder zuvor vom Empfänger gespeicherte Kopien löschen.

Passwork speichert einen einzigen gemeinsam genutzten Chiffretext und verteilt umschlossene Schlüssel, anstatt jedes Secret für jeden Empfänger zu duplizieren. Das Entfernen einer dauerhaften Tresor- oder Ordnerfreigabe entzieht den entsprechenden Schlüsselzugriff. Der Posteingang funktioniert anders: Eine direkte Übergabe zwischen Benutzern umschließt den Schlüssel eines Elements für den Empfänger, und ein akzeptiertes Element wird zu einer Kopie im Tresor des Empfängers. Die Zustellung an einen Gruppen-Posteingang nutzt einen Pfad ohne clientseitige Verschlüsselung. Der Posteingang ist daher eine Übertragung und keine dauerhaft widerrufbare Freigabe.

Bitwarden und Keeper schützen Metadaten, die Passwork für die serverseitige Suche offenlegt. Keeper bietet außerdem Eintrags-Shortcuts und direkte Berechtigungen pro Eintrag in gemeinsam genutzten Ordnern sowie eine breitere Privileged-Access-Plattform. 1Password hat weniger Vererbungsregeln und Ausnahmen, wodurch es sich leichter für Teams konfigurieren lässt, die keine komplexen Ordnerberechtigungen benötigen. Bitwarden verbindet einen niedrigen Einstiegspreis, Self-Hosting und etablierte Clients.

Das sind handfeste Vorteile. Passworks Flexibilität hilft Organisationen mit komplexen Zugriffsstrukturen, schafft aber auch mehr Richtlinien, die entworfen und gepflegt werden müssen.

Die richtige Wahl: Bei der Grenze beginnen

Beginnen Sie mit dem Schadensszenario, nicht mit dem Verschlüsselungsalgorithmus. Welche Einträge können die Schlüssel eines kompromittierten Kontos entschlüsseln? Was ändert sich, wenn der Angreifer zusätzlich ein Datenbank-Backup erhält? Prüfen Sie anschließend, ob Ihr Berechtigungsmodell die Abteilungsgrenzen widerspiegelt und ob Onboarding den Zugriff unbeabsichtigt erweitern kann.

Passwork eignet sich für Organisationen, die separate Abteilungstresore, vererbte Ordnerberechtigungen, direkte LDAP-Authentifizierung vor Ort sowie Mitarbeiter- und Machine-Zugangsdaten in einem System benötigen. Passbolt bevorzugt Kontrolle pro Secret dort, wo der administrative Aufwand der Freigabe vertretbar ist. Bitwarden bietet unkomplizierte organisationsweite Schlüsselverteilung und Self-Hosting. 1Password minimiert die Konfigurationskomplexität in einem Cloud-first-Modell. Keeper verbindet Kontrollen für gemeinsam genutzte Ordner mit einem breiteren Privileged-Access-Angebot.

Wenn Finance, HR und Infrastruktur getrennte operative Einheiten sind, entscheiden Sie, ob sie auch getrennte kryptografische Grenzen haben sollten. Diese Entscheidung bestimmt die potenzielle Offenlegung durch einen kompromittierten Schlüssel direkter als ein AES-256-Label.

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

Häufig gestellte Fragen

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

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

PassworkPasswork Team

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

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

PassworkPasswork Team

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

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

PassworkPasswork Team

Los gestores de contraseñas empresariales suelen destacar el cifrado AES-256 y servidores que nunca ven las contraseñas en texto claro. Pero la fortaleza del cifrado por sí sola no indica cuántos datos puede exponer una clave comprometida o una membresía de grupo incorrecta.

Esa exposición depende del límite de cifrado: si una clave desbloquea una organización, una bóveda, una carpeta compartida o un secreto individual. Esta comparación analiza dónde trazan ese límite Passwork, Bitwarden, Passbolt, 1Password y Keeper, y qué implican sus diseños para los permisos, el inicio de sesión mediante directorio, la automatización y la implementación.

La pregunta que revela el límite de cifrado

Imagine un gestor de contraseñas autoalojado. Un administrador de sistemas responsable de las copias de seguridad dispone de un volcado de la base de datos y se une a la organización corporativa para acceder a una contraseña compartida. ¿Qué más podría descifrar con las claves disponibles en su cuenta?

Bitwarden cifra los elementos corporativos con claves por elemento envueltas por una única clave simétrica de la organización, según su documento técnico de seguridad. Los miembros de la organización reciben acceso utilizable a esa clave, mientras que las colecciones controlan el acceso y los permisos habituales entregados por el servidor, en lugar de crear límites criptográficos independientes. En un modelo de amenazas autoalojado, un atacante que obtenga los textos cifrados pertinentes de la base de datos y la clave utilizable de la organización de un miembro podría descifrar elementos de la organización fuera de las colecciones asignadas a ese miembro.

Passwork, con el cifrado del lado del cliente activado, utiliza una clave independiente para cada bóveda. Las claves de los elementos se sitúan bajo las claves de bóveda, y los usuarios reciben una clave de bóveda envuelta únicamente para las bóvedas a las que tienen acceso. Con este modelo de cifrado de conocimiento cero, el mismo administrador de sistemas puede descifrar sus bóvedas asignadas, pero no las bóvedas de Finanzas o Infraestructura no relacionadas.

Passbolt cifra cada secreto por separado para cada destinatario mediante OpenPGP, tal como se describe en su documentación de seguridad (Pro v5.4, agosto de 2025). No existe una clave de contenedor compartida. Los usuarios solo pueden descifrar los secretos cifrados para ellos, aunque añadir destinatarios exige más trabajo.

1Password aísla los datos por bóveda, donde también se definen los permisos. Keeper utiliza claves de registro y claves de carpeta compartida en lugar de una única clave para toda la organización. Ninguno de los dos ofrece una base de datos de bóveda autoalojada para esta prueba en concreto.

Passwork y Passbolt limitan lo que un volcado de la base de datos más las claves de un miembro pueden revelar. Bitwarden simplifica la distribución de claves, pero convierte la clave de la organización en un límite criptográfico más amplio. Los productos exclusivamente en la nube evitan este escenario concreto de acceso a la base de datos, aunque su arquitectura de claves sigue siendo relevante.

Prueba gratuita de Passwork para comprobar cómo la estructura de su bóveda limita el acceso tras el compromiso de una cuenta.

Tipos de bóveda: gobernanza por encima de las bóvedas individuales

En Passwork, un tipo de bóveda define quién puede crear bóvedas de una clase y qué administradores se asignan automáticamente a las nuevas bóvedas de ese tipo. Con el cifrado del lado del cliente activado, esos administradores también reciben copias envueltas de las nuevas claves de bóveda. El resultado es una política repetible para departamentos y proyectos.

Por ejemplo, un tipo Finanzas puede asignar automáticamente al director financiero a cada nueva bóveda de finanzas. Un tipo DevOps puede mantener a los administradores de infraestructura separados de ventas. Cuando el responsable de un departamento se marcha, la empresa puede reasignar el administrador del tipo y revisar los permisos concedidos dentro de esa área, en lugar de auditar un rol de administrador global difícil de controlar. Esto resulta útil a medida que crecen los equipos y el número de bóvedas. Consulte las políticas de bóveda de Passwork.

Dos tipos integrados evitan la intervención de administradores corporativos. Una bóveda personal pertenece a un único usuario. Una bóveda compartida privada permite que ese usuario invite a otras personas. De forma predeterminada, ni siquiera el propietario o el administrador de la organización pueden leer su contenido. Los administradores pueden configurar quién puede crear estos tipos de bóveda y compartir información desde ellas, incluida la posibilidad de desactivar la creación no gestionada de bóvedas personales.

Existen dos límites: asignar un tipo no concede acceso retroactivo a las bóvedas existentes, y los tipos solo forman límites criptográficos cuando el cifrado del lado del cliente está activado. De lo contrario, siguen siendo reglas de gobernanza.

Los competidores ofrecen funciones relacionadas, pero no la misma capa de políticas. Las políticas empresariales de Bitwarden rigen aspectos como la autenticación, la recuperación y la pertenencia a la organización, en lugar de asignar automáticamente administradores por clase de bóveda. Passbolt no cuenta con un contenedor de bóveda que clasificar. 1Password ofrece aislamiento a nivel de bóveda y bóvedas personales, pero ninguna regla equivalente a nivel de clase para las bóvedas recién creadas. Las carpetas compartidas y los equipos de Keeper gestionan el acceso sin políticas de creación de bóvedas tipificadas.

Los tipos de bóveda reducen la probabilidad de que las bóvedas departamentales recién creadas reciban una administración incoherente. Añaden una decisión de política por adelantado, pero reducen la configuración manual repetida más adelante.

Permisos de carpetas: ¿Herencia o plantillas?

Un árbol de carpetas solo resulta útil si sus permisos se comportan como esperan los administradores. Interfaces con un aspecto similar pueden aplicar reglas muy distintas.

Passwork ofrece cinco niveles de permiso (lectura, escritura, gestión, administración y prohibido) para usuarios y grupos a nivel de bóveda o de carpeta. El acceso de la bóveda se propaga a las carpetas anidadas, mientras que las reglas de carpeta pueden restringirlo. Los derechos de administración y de prohibición no se pueden anular en niveles inferiores. Cuando se aplican varias reglas, prevalece el nivel de mayor prioridad. Es importante señalar que una carpeta no constituye un límite de cifrado independiente: el acceso a su contenido sigue dependiendo de la clave de la bóveda. Esto se suma al modelo de control de acceso basado en roles de Passwork.

Bitwarden concede permisos a través de colecciones. Las colecciones anidadas son etiquetas organizativas; no heredan los elementos ni los derechos de su colección superior. Las carpetas personales no tienen permisos de uso compartido. Los permisos individuales de un miembro prevalecen sobre los permisos de grupo.

Passbolt utiliza las carpetas como plantillas de permisos. Cuando se crea, se mueve o se comparte un elemento, se aplican los permisos de la carpeta, pero los permisos propios del elemento determinan el acceso posterior. Quien lo crea puede convertirse en propietario de una contraseña y restringir el acceso aunque la carpeta pertenezca a otra persona. En un debate comunitario de julio de 2026 sobre la extensión v5.14.2, Passbolt confirmó que este comportamiento se ajusta a su modelo de permisos y señaló que estaba previsto un cambio en la interfaz para impedir que los no propietarios editaran los permisos durante la creación.

1Password no dispone de carpetas con permisos propios dentro de una bóveda; las etiquetas organizan los elementos sin modificar el acceso. Por ello, compartir de forma permanente un subconjunto de elementos exige otra bóveda. Los grupos anidados de un proveedor de identidad no son compatibles con la pertenencia a bóvedas, según una respuesta de la comunidad de septiembre de 2026.

Keeper admite carpetas compartidas anidadas y permisos a nivel de registro. Las asignaciones explícitas de registros prevalecen sobre los derechos heredados de la carpeta. Su modelo de carpetas anidadas tiene un límite de profundidad de cinco niveles y estaba detrás de un feature flag en la versión 18.0.0 de la bóveda.

El árbol de Passwork admite estructuras departamentales y excepciones. Bitwarden y 1Password son más sencillos de administrar, pero menos flexibles para el acceso con anidamiento profundo. El comportamiento de plantillas de Passbolt exige especial atención, ya que los permisos de carpeta y de elemento pueden divergir.

Grupos: ¿qué cambia cuando alguien se incorpora?

Con el cifrado del lado del cliente de Passwork, añadir a alguien a un grupo no le otorga automáticamente todas las claves de bóveda asociadas a ese grupo. Se genera una solicitud pendiente para cada bóveda pertinente. Un titular de la clave debe aprobar la solicitud antes de que el nuevo miembro pueda descifrar su contenido.

Esto separa el aprovisionamiento de directorio del acceso criptográfico. La sincronización LDAP puede incorporar a un nuevo empleado a los grupos, pero el acceso a bóvedas sensibles sigue requiriendo aprobación. Esta distinción es importante durante la incorporación y la baja de empleados.

Para los equipos que necesitan menos aprobación manual, Passwork ofrece otro patrón: colocar los datos del departamento en una única bóveda y organizarlos en carpetas. Apruebe la clave de bóveda del usuario una sola vez; a partir de ahí, los permisos de carpeta determinan el acceso dentro de esa bóveda a medida que cambia la pertenencia a los grupos. La contrapartida es un límite criptográfico compartido más amplio que el de varias bóvedas independientes.

Passbolt no puede recurrir a este atajo. Dado que cada secreto se cifra para cada destinatario, añadir un miembro al grupo exige que alguien con acceso vuelva a cifrar los secretos pertinentes para ese usuario. La sincronización de directorio notifica a un gestor del grupo y espera a que se complete este paso. El trabajo escala con el número de secretos, no con el número de bóvedas.

Bitwarden ya distribuye la clave de la organización a los miembros, por lo que las asignaciones de colección no requieren nuevas claves de cifrado. En 1Password, las claves de bóveda asignadas siguen el acceso del grupo. Keeper distribuye el acceso mediante carpetas compartidas asignadas.

La disyuntiva está entre puntos de aprobación más estrictos y un aprovisionamiento más fluido. Passwork permite a las organizaciones elegir distintos equilibrios según el departamento; Passbolt ofrece un acceso granular por secreto a un coste de uso compartido más elevado.

Qué hace realmente el inicio de sesión de dominio

Una contraseña de dominio autentica a un usuario; no descifra los datos de la bóveda en ninguno de estos productos. Sus diferencias residen en cómo funcionan la autenticación y el aprovisionamiento mediante directorio.

Passwork autoalojado autentica directamente frente a LDAP o Active Directory, incluso en entornos con varios controladores de dominio. Los usuarios inician sesión con sus credenciales de dominio; los grupos de directorio pueden asignarse a grupos de Passwork. Con el cifrado del lado del cliente activado, la contraseña de dominio autentica la sesión, mientras que claves criptográficas independientes protegen el contenido de la bóveda.

En el momento de esta comparación, Passwork Cloud aún no ofrecía LDAP; estaba en la hoja de ruta, junto con el aprovisionamiento SCIM. Ambas implementaciones de Passwork admiten SSO mediante SAML 2.0.

Bitwarden Directory Connector sincroniza usuarios y grupos, pero no los autentica frente a LDAP, tal como explica su documentación. El inicio de sesión basado en dominio requiere SSO Enterprise mediante SAML u OIDC. Por lo general, los usuarios siguen desbloqueando su bóveda con una contraseña maestra, salvo que se configuren dispositivos de confianza o Key Connector.

Passbolt también separa la sincronización LDAP del inicio de sesión. Los usuarios se autentican mediante una clave privada y una frase de contraseña, o bien SSO, y añadir usuarios sincronizados a grupos con secretos existentes exige un nuevo cifrado.

1Password y Keeper utilizan servicios de bóveda basados en la nube con integración SSO. SSO Connect On-Prem de Keeper puede mantener ciertos componentes de identidad en el hardware de la empresa, pero su backend de bóveda cifrada permanece en la nube de Keeper. Keeper enumera los componentes locales compatibles en su documentación de implementación.

El inicio de sesión LDAP directo de Passwork puede simplificar las implementaciones autoalojadas sin necesidad de un proveedor de identidad independiente. Los competidores centrados en la nube ofrecen actualmente un aprovisionamiento de identidad automatizado más maduro; las funciones previstas de Passwork no deben considerarse disponibles en la actualidad.

Una sola API para contraseñas y secretos de máquina

Passwork gestiona las credenciales de los empleados y los secretos de máquina a través de la misma instancia, el mismo modelo de permisos, el mismo registro de auditoría y la misma API REST. Los equipos pueden respaldar flujos de trabajo de CI/CD sin necesidad de licenciar un producto de secretos independiente.

Sus clientes web, de escritorio, de navegador y móviles utilizan la misma API en /api/v1. Una CLI oficial y un conector de Python de código abierto respaldan los flujos de trabajo de DevOps. La CLI ofrece get y update para los registros, api para llamadas directas a los endpoints, y exec para recuperar y descifrar un secreto, exponer los valores como variables de entorno y ejecutar un comando. Las cuentas de servicio son usuarios con tokens de API creados por un administrador. Generar un nuevo token personal revoca las sesiones de API anteriores del usuario.

Este modelo unificado tiene limitaciones: la API funciona por sondeo (pull), sin webhooks salientes, y /v1/batch solo admite la agregación de lecturas, hasta 25 subsolicitudes GET. Las integraciones basadas en eventos deben sondear la API o consumir las exportaciones de syslog.

Los competidores adoptan enfoques distintos. Bitwarden Secrets Manager es un complemento de pago independiente con cuentas de máquina y acceso basado en proyectos, en lugar de acceso a través de las colecciones de Password Manager. Keeper Secrets Manager es otra línea de producto con SDK y una puerta de enlace conectada a la nube. Las cuentas de servicio de 1Password funcionan con bóvedas y permisos definidos, pero su alcance queda fijado al crear el token; para cambiarlo se necesita un nuevo token. Passbolt expone una API y herramientas de automatización, manteniendo su modelo de uso compartido por secreto.

Passwork favorece un único sistema operativo para personas y automatización. Los productos de secretos especializados pueden ofrecer integraciones específicas, pero añaden licencias y superficies de gestión adicionales.

Dónde se ejecuta la bóveda

La implementación puede descartar productos de una preselección antes de comparar cualquier función. Passwork, Bitwarden y Passbolt permiten a las organizaciones alojar la propia bóveda. 1Password y Keeper mantienen el backend de la bóveda en sus servicios en la nube.

Passwork admite la implementación local en Linux, Windows Server o Docker, lo que otorga a las organizaciones control sobre su infraestructura y sus copias de seguridad. Su oferta en la nube alojada en la UE utiliza una base de datos y un tenant independientes para cada cliente, en lugar de almacenar los registros de todos los clientes en un único esquema compartido. Estas opciones se analizan en la guía de modelos de implementación de Passwork.

Bitwarden también ofrece un autoalojamiento genuino, aunque su licencia Enterprise sigue vinculada a una suscripción activa en la nube. Passbolt admite tanto el autoalojamiento como un servicio alojado. Los componentes de SSO e integración de Keeper, implementables localmente, no cambian la ubicación de su backend de bóveda.

El autoalojamiento da a las organizaciones control sobre la ubicación de los datos, pero también la responsabilidad de las actualizaciones, las copias de seguridad y la disponibilidad. Los productos exclusivamente en la nube reducen esa carga allí donde la política permite el alojamiento externo.

Cifrado del lado del cliente opcional y metadatos

Passwork Cloud utiliza siempre el cifrado del lado del cliente. En la versión autoalojada, Passwork permite a los administradores desactivarlo. Los otros cuatro productos de esta comparación no ofrecen un interruptor equivalente.

El cifrado del lado del servidor puede resultar adecuado para un equipo pequeño con administradores de confianza que prioriza la concesión inmediata de acceso y una recuperación más sencilla. Desactivar el cifrado del lado del cliente elimina el aislamiento criptográfico por bóveda: los tipos de bóveda siguen controlando la creación y la administración, pero dejan de constituir límites de cifrado independientes.

Incluso con el cifrado del lado del cliente activado, el servidor de Passwork puede leer los nombres de los elementos, los inicios de sesión, las descripciones y las URL para habilitar la búsqueda en el servidor. Los valores de las contraseñas permanecen cifrados en el cliente y fuera del índice de búsqueda. Bitwarden y Keeper también cifran estos campos de metadatos, manteniéndolos ocultos para el servidor a costa de tener que descifrarlos en el cliente para poder buscar. Passbolt v5 deja sin cifrar los nombres de carpeta y las etiquetas.

Se trata de una contrapartida real entre seguridad y usabilidad. Los compradores deben evaluar tanto la confidencialidad de las contraseñas como la exposición de metadatos, especialmente cuando los registros contienen nombres de sistemas o identificadores de cuenta sensibles.

Qué cuesta

Estos son los precios de lista publicados por usuario y mes con facturación anual, a fecha de octubre de 2026. Los proveedores utilizan monedas y combinaciones de planes distintas, por lo que la comparación es orientativa.

Passwork Standard cuesta 3 € y Advanced, 4,50 € por usuario y mes. Advanced incluye gestión de secretos y funciones de identidad empresarial. Los clientes autoalojados también pueden optar por una licencia perpetua de pago único. Bitwarden Teams cuesta 4 $ y Enterprise, 6 $, con Secrets Manager con precio aparte de 6 $ y 12 $, respectivamente. Keeper Business parte de 4 $ y Enterprise de 6 $, mientras que KeeperPAM tiene un precio independiente. 1Password Business cuesta 8,99 $. Passbolt Pro autoalojado cuesta 4,50 € con un mínimo de diez usuarios.

Bitwarden Secrets Manager cuesta 6 $ por usuario y mes en Teams, o 12 $ en Enterprise, facturado por separado de Password Manager. Las organizaciones que utilicen ambos productos deben comparar los costes de licencia combinados en función del número de usuarios de cada uno. Passwork Advanced incluye la gestión de contraseñas y de secretos en una sola suscripción. El modelo de cifrado por secreto de Passbolt añade trabajo administrativo al compartir secretos o añadir miembros a un grupo, un coste que los precios de suscripción por sí solos no reflejan.

Dónde tienen ventaja los competidores

Passbolt ofrece uso compartido y revocación directos por secreto. Cada destinatario recibe un texto cifrado con su clave pública. La revocación elimina del servicio la copia cifrada de ese destinatario. Esto permite un control granular, pero cada destinatario adicional exige trabajo de cifrado y almacenamiento. Como ocurre con otros gestores de contraseñas, la revocación no puede borrar el texto en claro ni las copias que un destinatario haya guardado previamente.

Passwork almacena un único texto cifrado compartido y distribuye claves envueltas, en lugar de duplicar cada secreto para cada destinatario. Al eliminar una concesión permanente de bóveda o carpeta se elimina el acceso a la clave correspondiente. Su bandeja de entrada funciona de otro modo: una entrega directa entre usuarios envuelve la clave de un elemento para el destinatario, y un elemento aceptado se convierte en una copia dentro de la bóveda del destinatario. La entrega a la bandeja de entrada de un grupo utiliza una vía sin cifrado del lado del cliente. Por lo tanto, la bandeja de entrada es una transferencia, no una concesión revocable de forma permanente.

Bitwarden y Keeper protegen metadatos que Passwork expone para la búsqueda en el servidor. Keeper también ofrece accesos directos a registros y permisos directos por registro en carpetas compartidas, además de una plataforma más amplia de acceso privilegiado. 1Password tiene menos reglas de herencia y excepciones, lo que facilita su configuración para equipos que no necesitan permisos de carpeta complejos. Bitwarden combina un precio de entrada bajo, autoalojamiento y clientes consolidados.

Se trata de ventajas sustanciales. La flexibilidad de Passwork ayuda a las organizaciones con estructuras de acceso complejas, pero también genera más políticas que diseñar y mantener.

Cómo elegir: Empiece por el límite

Comience por el escenario de fallo, no por el algoritmo de cifrado. Si se compromete una cuenta, ¿qué registros pueden descifrar sus claves? ¿Qué cambia si el atacante también obtiene una copia de seguridad de la base de datos? A continuación, compruebe si su modelo de permisos refleja los límites departamentales y si la incorporación de nuevos usuarios puede ampliar el acceso de forma involuntaria.

Passwork es adecuado para organizaciones que necesitan bóvedas departamentales independientes, permisos de carpeta heredados, autenticación LDAP directa en local, y credenciales de empleados y de máquina en un solo sistema. Passbolt favorece el control por secreto cuando el coste administrativo del uso compartido resulta aceptable. Bitwarden ofrece una distribución de claves sencilla para toda la organización y autoalojamiento. 1Password minimiza la complejidad de configuración en un modelo centrado en la nube. Keeper combina controles de carpeta compartida con una oferta más amplia de acceso privilegiado.

Si Finanzas, Recursos Humanos e Infraestructura son unidades operativas independientes, decida si también deben tener límites criptográficos independientes. Esa decisión determina la exposición potencial de una clave comprometida de forma más directa que una simple etiqueta AES-256.

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

Preguntas frecuentes

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

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

PassworkPasswork Team

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

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

PassworkPasswork Team

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

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

PassworkPasswork Team

Business password managers often advertise AES-256 encryption and servers that never see plaintext passwords. But cipher strength alone does not tell you how much data one compromised key or misplaced group membership can expose.

That exposure depends on the encryption boundary: whether a key unlocks an organization, a vault, a shared folder, or an individual secret. This comparison examines where Passwork, Bitwarden, Passbolt, 1Password, and Keeper draw that boundary, and what their designs mean for permissions, directory login, automation, and deployment.

The question that reveals the encryption boundary

Imagine a self-hosted password manager. A sysadmin responsible for backups has a database dump and joins the corporate organization to access one shared password. What else could they decrypt using the keys available to their account?

Bitwarden encrypts corporate items with per-item keys wrapped by one organization symmetric key, according to its security white paper. Organization members receive usable access to that key, while collections control normal server-delivered access and permissions rather than creating separate cryptographic boundaries. In a self-hosted threat model, an attacker who obtains the relevant database ciphertexts and a member’s usable organization key could decrypt organization items outside that member’s assigned collections.

Passwork, with client-side encryption enabled, uses a separate key for each vault. Item keys sit under vault keys, and users receive a wrapped vault key only for vaults they can access. Under this zero-knowledge encryption model, the same sysadmin can decrypt their assigned vaults, but not unrelated Finance or Infrastructure vaults.

Passbolt encrypts each secret separately for each recipient using OpenPGP, as described in its security documentation (Pro v5.4, August 2025). There is no shared container key. Users can decrypt only secrets encrypted for them, although adding recipients requires more work.

1Password isolates data by vault, where permissions are also defined. Keeper uses record keys and shared-folder keys rather than one organization-wide key. Neither offers a self-hosted vault database for this particular test.

Passwork and Passbolt limit what a database dump plus one member's keys can reveal. Bitwarden simplifies key distribution but makes the organization key a broader cryptographic boundary. The cloud-only products avoid this specific database-access scenario, though their key architecture still matters.

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

Vault types: governance above individual vaults

In Passwork, a vault type defines who may create vaults in a class and which administrators are automatically assigned to new vaults of that type. With client-side encryption enabled, those administrators also receive wrapped copies of the new vault keys. The result is a repeatable policy for departments and projects.

For example, a Finance type can automatically assign the CFO to each new finance vault. A DevOps type can keep infrastructure administrators separate from sales. When a department head leaves, the company can reassign the type administrator and review grants within that area instead of auditing a sprawling global admin role. This becomes useful as teams and vault counts grow. See Passwork's vault policies.

Two built-in types avoid corporate administrators. A personal vault belongs to one user. A private shared vault lets that user invite others. By default, even the organization's Owner or Admin cannot read their contents. Administrators can configure who is allowed to create these vault types and share information from them, including disabling unmanaged personal vault creation.

There are two limits: assigning a type does not retroactively grant access to existing vaults, and types form cryptographic boundaries only when client-side encryption is enabled. Otherwise they remain governance rules.

The competitors offer related features, but not the same policy layer. Bitwarden enterprise policies govern matters such as authentication, recovery, and organization membership rather than automatically assigning administrators by vault class. Passbolt has no vault container to classify. 1Password provides vault-level isolation and personal vaults, but no equivalent class-wide rule for newly created vaults. Keeper's shared folders and teams manage access without typed vault creation policies.

Vault types reduce the chance that newly created departmental vaults receive inconsistent administration. They add a policy decision upfront, but reduce repeated manual configuration later.

Folder permissions: Inheritance or templates?

A folder tree is useful only if its permissions behave as administrators expect. Similar-looking interfaces can enforce very different rules.

Passwork offers five permission levels—read, write, manage, admin, and forbidden—for users and groups at vault or folder level. Vault access flows into nested folders, while folder rules can narrow access. Admin and forbidden rights cannot be overridden further down. When multiple rules apply, the higher-priority level wins. Importantly, a folder is not a separate encryption boundary: access to its contents still relies on the vault key. This sits alongside Passwork's role-based access control model.

Bitwarden grants permissions through collections. Nested collections are organizational labels; they do not inherit their parent's items or rights. Personal folders have no sharing permissions. Individual member permissions override group permissions.

Passbolt uses folders as permission templates. When an item is created, moved, or shared, the folder's permissions are applied, but the item's own permissions determine subsequent access. A creator can become the owner of a password and restrict access even when someone else owns the folder. In a July 2026 community discussion about extension v5.14.2, Passbolt confirmed this behavior follows its permission model and said a UI change was planned to prevent non-owners editing permissions during creation.

1Password has no permission-bearing folders inside a vault; tags organize items without changing access. Sharing a subset of items permanently therefore requires another vault. Nested identity-provider groups are not supported for vault membership, according to a September 2026 community response.

Keeper supports nested shared folders and record-level permissions. Explicit record assignments override inherited folder rights. Its nested-folder model has a five-level depth limit and was behind a feature flag in vault release 18.0.0.

Passwork's tree supports departmental structures and exceptions. Bitwarden and 1Password are simpler to administer but less flexible for deeply nested access. Passbolt's template behavior requires special attention because folder and item permissions can diverge.

Groups: what changes when someone joins?

With Passwork client-side encryption, adding someone to a group does not automatically give them every vault key associated with that group. It creates a pending request for each relevant vault. A key holder must approve the request before the new member can decrypt its contents.

This separates directory provisioning from cryptographic access. LDAP synchronization can place a new employee into groups, but access to sensitive vaults still requires approval. The distinction matters during onboarding and offboarding.

For teams that need less manual approval, Passwork offers another pattern: put the department's data in one vault and organize it into folders. Approve the user's vault key once; folder permissions then determine access within that vault as group membership changes. The trade-off is a wider shared cryptographic boundary than several separate vaults.

Passbolt cannot use this shortcut. Because each secret is encrypted for each recipient, adding a group member requires someone with access to re-encrypt the relevant secrets for that user. Directory synchronization notifies a group manager and waits for this step. The work scales with the number of secrets rather than the number of vaults.

Bitwarden already distributes the organization key to members, so collection assignments do not require new encryption keys. In 1Password, assigned vault keys follow group access. Keeper distributes access through assigned shared folders.

The choice is between tighter approval checkpoints and smoother provisioning. Passwork lets organizations choose different balances for different departments; Passbolt provides fine-grained per-secret access at a higher sharing cost.

What domain login actually does

A domain password authenticates a user; it does not decrypt vault data in any of these products. Their differences lie in how directory authentication and provisioning work.

Passwork self-hosted authenticates directly against LDAP or Active Directory, including environments with multiple domain controllers. Users sign in with domain credentials; directory groups can map to Passwork groups. With client-side encryption enabled, the domain password authenticates the session while separate cryptographic keys protect vault contents.

Passwork Cloud did not yet offer LDAP at the time of this comparison; it was on the roadmap, along with SCIM provisioning. Both Passwork deployments support SAML 2.0 SSO.

Bitwarden Directory Connector synchronizes users and groups but does not authenticate them against LDAP, as its documentation explains. Domain-based sign-in requires Enterprise SSO through SAML or OIDC. Users ordinarily still unlock their vault with a master password, unless trusted devices or Key Connector are configured.

Passbolt also separates LDAP synchronization from login. Users authenticate using a private key and passphrase or SSO, and adding synced users to groups with existing secrets requires re-encryption.

1Password and Keeper use cloud-based vault services with SSO integration. Keeper's SSO Connect On-Prem can keep certain identity components on company hardware, but its encrypted vault backend remains in Keeper's cloud. Keeper lists supported local components in its deployment documentation.

Passwork's direct LDAP login can simplify self-hosted deployments without a separate identity provider. Cloud-first competitors currently offer more mature automated identity provisioning; planned Passwork features should not be treated as available today.

One API for passwords and machine secrets

Passwork manages employee credentials and machine secrets through the same instance, permission model, audit log, and REST API. Teams can support CI/CD workflows without licensing a separate secrets product.

Its web, desktop, browser, and mobile clients use the same API at /api/v1. An official CLI and open-source Python connector support DevOps workflows. The CLI provides get and update for records, api for direct endpoint calls, and exec to retrieve and decrypt a secret, expose values as environment variables, and run a command. Service accounts are users with API tokens created by an administrator. Generating a new personal token revokes the user's previous API sessions.

This unified model has limitations: the API is pull-based, with no outbound webhooks, and /v1/batch supports read aggregation only, up to 25 GET subrequests. Event-driven integrations must poll or consume syslog exports.

Competitors take different approaches. Bitwarden Secrets Manager is a separate paid add-on with machine accounts and project-based access, rather than access through Password Manager collections. Keeper Secrets Manager is another product line with SDKs and a cloud-connected gateway. 1Password service accounts work with defined vaults and permissions, but their scope is fixed when a token is created; changing it requires a new token. Passbolt exposes an API and automation tooling while retaining its per-secret sharing model.

Passwork favors a single operational system for people and automation. Specialized secrets products can offer dedicated integrations, but introduce additional licensing and management surfaces.

Where the vault runs

Deployment can eliminate products from a shortlist before any feature comparison. Passwork, Bitwarden, and Passbolt allow organizations to host the vault itself. 1Password and Keeper keep the vault backend in their cloud services.

Passwork supports on-premise deployment on Linux, Windows Server, or Docker, giving organizations control over their infrastructure and backups. Its EU-hosted cloud offering uses a separate database and tenant for each customer, rather than storing all customers' records in one shared schema. These options are discussed in Passwork's deployment models guide.

Bitwarden also offers genuine self-hosting, although its Enterprise license remains tied to an active cloud subscription. Passbolt supports self-hosting and a hosted service. Keeper's locally deployable SSO and integration components do not change the location of its vault backend.

Self-hosting gives organizations control over data location but also responsibility for updates, backups, and availability. Cloud-only products reduce that workload where policy permits external hosting.

Optional client-side encryption and metadata

Passwork Cloud always uses client-side encryption. Self-hosted Passwork lets administrators disable it. The other four products in this comparison do not offer an equivalent switch.

Server-side encryption can suit a small team with trusted administrators that prioritizes immediate access grants and simpler recovery. Disabling client-side encryption removes per-vault cryptographic isolation: vault types still control creation and administration, but no longer form separate encryption boundaries.

Even when client-side encryption is enabled, Passwork's server can read item names, logins, descriptions, and URLs to support server-side search. Password values remain encrypted on the client and outside the search index. Bitwarden and Keeper encrypt these metadata fields too, keeping them hidden from the server at the cost of client-side decryption for search. Passbolt v5 leaves folder names and tags unencrypted.

This is a real security and usability trade-off. Buyers should evaluate both password confidentiality and metadata exposure, especially when records contain sensitive system names or account identifiers.

What it costs

These are published list prices per user per month on annual billing, as of October 2026. Vendors use different currencies and packaging, so the comparison is directional.

Passwork Standard costs €3 and Advanced €4.50 per user per month. Advanced includes secrets management and enterprise identity features. Self-hosted customers can also choose a one-time lifetime license. Bitwarden Teams costs $4 and Enterprise $6, with Secrets Manager priced separately at $6 and $12, respectively. Keeper Business starts at $4 and Enterprise at $6, while KeeperPAM is priced separately. 1Password Business costs $8.99. Passbolt Pro self-hosted costs €4.50 with a ten-user minimum.

Bitwarden Secrets Manager costs $6 per user per month on Teams or $12 on Enterprise, billed separately from Password Manager. Organizations using both products should compare combined licensing costs based on the number of users in each. Passwork Advanced includes password and secrets management in one subscription. Passbolt's per-secret encryption model adds administrative work when sharing secrets or adding group members, a cost that subscription prices alone cannot capture.

Where competitors have the advantage

Passbolt provides direct per-secret sharing and revocation. Each recipient gets a ciphertext encrypted with their public key. Revocation removes that recipient's encrypted copy from the service. This supports fine-grained control, but every additional recipient requires encryption and storage work. As with other password managers, revocation cannot erase plaintext or copies a recipient previously saved.

Passwork stores one shared ciphertext and distributes wrapped keys rather than duplicating every secret for each recipient. Removing a permanent vault or folder grant removes the relevant key access. Its inbox works differently: a direct user handoff wraps an item's key for the recipient, and an accepted item becomes a copy in the recipient's vault. Group inbox delivery uses a non-client-side-encryption path. Inbox is therefore a transfer, not a permanently revocable grant.

Bitwarden and Keeper protect metadata that Passwork exposes for server-side search. Keeper also offers record shortcuts and direct per-record permissions in shared folders, plus a broader privileged-access platform. 1Password has fewer inheritance rules and exceptions, making it easier to configure for teams that do not need complex folder permissions. Bitwarden combines low entry pricing, self-hosting, and established clients.

These are substantive advantages. Passwork's flexibility helps organizations with complex access structures, but also creates more policies to design and maintain.

How to choose: Start with the boundary

Begin with the failure scenario, not the encryption algorithm. If an account is compromised, what records can its keys decrypt? What changes if the attacker also obtains a database backup? Then check whether your permission model mirrors departmental boundaries and whether onboarding can accidentally expand access.

Passwork is suited to organizations that need separate departmental vaults, inherited folder permissions, direct LDAP authentication on-premise, and employee and machine credentials in one system. Passbolt favors per-secret control where the administrative cost of sharing is acceptable. Bitwarden offers straightforward organization-wide key distribution and self-hosting. 1Password minimizes configuration complexity in a cloud-first model. Keeper combines shared-folder controls with a wider privileged-access offering.

If Finance, HR, and Infrastructure are separate operational units, decide whether they should also have separate cryptographic boundaries. That decision determines the potential exposure of one compromised key more directly than an AES-256 label.

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

Frequently asked questions

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

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

PassworkPasswork Team

Passwork vs KeePass: How encryption architecture differs

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

PassworkPasswork Team

Passwork vs Bitwarden: How vault encryption architecture differs

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

PassworkPasswork Team

O Regulamento Geral sobre a Proteção de Dados (RGPD), a lei da UE em matéria de proteção de dados, exige um mecanismo lícito de transferência para o envio de dados pessoais para fora do Espaço Económico Europeu (EEE, a UE mais a Islândia, o Listenstaine e a Noruega) e medidas de segurança adequadas ao risco. Para uma gestão de palavras-passe em conformidade com o RGPD, é necessário conhecer todos os locais onde existem dados de credenciais e dispor de prova para cada um deles.

As credenciais podem estar armazenadas num centro de dados em Frankfurt e, ainda assim, ficar sujeitas a uma ordem judicial estrangeira, se o fornecedor estiver sujeito a uma jurisdição fora da UE. Uma etiqueta «alojado na UE» também nada diz sobre a localização das cópias de segurança. Este artigo apresenta o mapa de seis zonas dos dados de credenciais: os locais onde um gestor de palavras-passe empresarial guarda dados, o artigo do RGPD que cada local ativa e as evidências que é necessário conservar. Termina com um dossiê de evidências de 8 pontos, que pode ser verificado antes de uma auditoria.

O que exige a gestão de palavras-passe em conformidade com o RGPD

O RGPD exige que os dados pessoais sejam tratados de forma segura, com proteção de dados desde a conceção e protegidos por medidas adequadas ao risco. 

A gestão de palavras-passe em conformidade com o RGPD implica poder demonstrar que os dados de credenciais são cifrados, acessíveis apenas a quem deles necessita, registados e abrangidos pelos contratos e registos adequados, onde quer que estejam armazenados.

A lei define o resultado a alcançar (artigos 5.º, n.º 1, alínea f), 25.º e 32.º). Cabe à organização escolher os controlos e provar que funcionam (artigo 5.º, n.º 2). Na prática, isto traduz-se em cinco requisitos:

• Cifrar as credenciais armazenadas. O artigo 32.º, n.º 1, alínea a), refere «a pseudonimização e a cifragem dos dados pessoais» como medida adequada.
• Limitar o acesso por função (RBAC). Cada pessoa inicia sessão com a sua própria conta e vê apenas o que a sua função exige, mesmo quando a credencial aberta é partilhada. Trata-se da proteção de dados desde a conceção (artigo 25.º) aplicada ao acesso.
• Manter o serviço disponível e testado. O artigo 32.º, n.º 1, alíneas b) a d), abrange a resiliência, o restabelecimento do acesso após um incidente e os testes regulares das medidas.
• Registar quem abriu o quê. Um registo de acessos mostra que credenciais foram acedidas e quando. É a evidência necessária para avaliar se uma violação afetou dados pessoais (artigo 33.º).
• Documentar todos os locais onde os dados se encontram. Isto implica um registo das atividades de tratamento, um contrato com cada entidade externa que trate os dados e um mecanismo lícito para qualquer transferência para fora do EEE.

Estes deveres abrangem as palavras-passe por duas razões. Um registo de credencial identifica normalmente um colaborador ou remete para um, o que o torna um dado pessoal (artigo 4.º, n.º 1: qualquer informação relativa a uma pessoa identificável). As credenciais abrem também outros sistemas, como RH, CRM e bases de dados de clientes, onde se armazenam dados pessoais. O artigo 32.º, n.º 2, exige a avaliação do risco de acesso não autorizado a dados pessoais, pelo que uma violação do gestor de palavras-passe constitui uma via de violação para todos os sistemas que ele desbloqueia. A cifragem reduz o risco sem retirar o registo do âmbito de aplicação. 

A organização é o responsável pelo tratamento do cofre, a entidade que decide por que razão e de que forma os dados de credenciais são utilizados. Um fornecedor ou prestador de alojamento que o explora ou apoia segundo as instruções da organização é um subcontratante, e o artigo 28.º exige um contrato com este. O artigo 30.º exige que se mantenha um registo das atividades de tratamento (RoPA) que enumere os destinatários, os locais e as transferências deste tratamento. Identificar esses locais é a primeira tarefa.

Residência, soberania e jurisdição são três conceitos distintos

Residência dos dados é o local onde os dados estão fisicamente armazenados. Soberania dos dados significa que os dados estão sujeitos às leis e ao controlo jurídico de um país escolhido. Jurisdição indica que tribunais e autoridades podem emitir ordens à empresa do fornecedor. Um fornecedor sujeito à lei dos EUA pode armazenar o cofre na Alemanha e, ainda assim, receber exigências legais dos EUA.

O CLOUD Act permite às autoridades dos EUA exigir aos fornecedores de serviços de comunicações eletrónicas ou de computação remota sob jurisdição dos EUA que entreguem os dados que se encontrem na sua posse, custódia ou controlo, mesmo quando estão armazenados no estrangeiro. Um fornecedor que seja uma empresa norte-americana ou tenha uma empresa-mãe nos EUA pode, por isso, receber tais exigências mesmo que o cofre esteja numa região da UE. Determinar se um dado fornecedor está abrangido pela lei é uma questão para a equipa jurídica.

O RGPD não contém qualquer regra geral de localização de dados. Regula as transferências para países terceiros no capítulo V (artigos 44.º a 50.º), e o acesso remoto a partir de fora do EEE, como o suporte do fornecedor, pode contar como transferência. Algumas regras nacionais e setoriais acrescentam exigências próprias de localização, pelo que convém verificar as que se aplicam à organização.

Transferências para fora do EEE: que mecanismos se aplicam

O capítulo V do RGPD exige um mecanismo lícito de transferência e garantias que se mantenham no país de destino. O acesso remoto de suporte a partir de fora do EEE a um cofre de palavras-passe alojado no seu interior conta como transferência, pelo que a região de alojamento, por si só, não resolve a questão. Existem três vias, e cada uma aplica-se a uma situação diferente.

• Decisão de adequação (artigo 45.º). A Comissão Europeia declarou que a proteção do país de destino é equivalente. A decisão de 10 de julho de 2023 relativa ao Quadro de Proteção de Dados UE-EUA abrange apenas as empresas dos EUA que se autocertificaram, pelo que convém verificar a entrada do fornecedor na lista do quadro. Os quadros UE-EUA anteriores foram anulados em tribunal e o atual foi contestado, pelo que as cláusulas contratuais-tipo devem permanecer como solução de recurso no DPA.
• Garantias adequadas (artigo 46.º). Normalmente, cláusulas contratuais-tipo (CCT), modelos de cláusulas contratuais aprovados pela Comissão, acompanhadas de uma avaliação de impacto da transferência (TIA). A TIA verifica se a legislação do país de destino permite às autoridades aceder aos dados. Decorre do acórdão Schrems II e das Recomendações 01/2020 do Comité Europeu para a Proteção de Dados (EDPB).
• Derrogações (artigo 49.º). Exceções restritas, como o consentimento explícito depois de a pessoa ser informada dos riscos. Adequam-se a transferências ocasionais e não servem de base ao tratamento rotineiro por fornecedores.

Uma região de alojamento na UE reduz o risco sem o eliminar. O pessoal de suporte fora do EEE, os metadados tratados noutro local e uma empresa-mãe fora do EEE com acesso podem, cada um, originar uma transferência. O poder de uma autoridade estrangeira para ordenar a uma empresa-mãe a divulgação de dados constitui um risco de jurisdição distinto (ver a secção sobre residência acima). A região deve ser considerada um dos elementos da TIA, e não a sua conclusão.

O mapa de seis zonas dos dados de credenciais

O mapa de seis zonas dos dados de credenciais divide um gestor de palavras-passe empresarial em seis locais onde existem dados de credenciais. Cada zona pode situar-se num país diferente e tem o seu próprio dever ao abrigo do RGPD, pelo que verificar apenas «o servidor» deixa de fora cópias pelas quais a organização é responsável.

Um gestor de palavras-passe é um sistema de cópias. Algumas ficam com a organização, outras com o fornecedor e as restantes com os fornecedores deste. As cópias que ficam com a organização dependem do modelo de implementação. Numa implementação em alojamento próprio, a organização é o operador de todas as zonas, pelo que cada pergunta abaixo se aplica às equipas e aos prestadores de alojamento da própria organização, em vez de a um fornecedor.

Cada zona desencadeia também um dever diferente. As cópias de segurança originam deveres de eliminação no termo do contrato (artigo 28.º, n.º 3, alínea g)) e os fornecedores originam deveres que têm de ser transmitidos ao longo da cadeia (artigo 28.º, n.º 4). As seis subsecções seguintes abordam cada zona e o que solicitar.

Zona 1: Credenciais armazenadas

As credenciais armazenadas são o conteúdo que os utilizadores guardam: inícios de sessão, notas, anexos e os segredos subjacentes aos códigos de utilização única. Com a cifragem do lado do cliente, esse conteúdo chega ao servidor como texto cifrado, dados ilegíveis sem a chave. Uma cópia roubada da base de dados expõe, assim, apenas segredos ilegíveis, desde que a chave que desbloqueia a chave privada cifrada permaneça no dispositivo do utilizador (ver Zona 2).

As credenciais cifradas continuam a ser dados pessoais quando se relacionam com uma pessoa identificável, pelo que a Zona 1 permanece no âmbito. O artigo 32.º, n.º 1, alínea a), indica a cifragem como exemplo de medida adequada, e esta reduz o risco. Na entrada do RoPA relativa ao gestor de palavras-passe, deve registar-se a localização desta zona e o método de cifragem.

Os nomes dos registos, a estrutura de pastas e os metadados de auditoria são armazenados separadamente e pertencem à Zona 3. Devem ter uma linha própria no RoPA, com a mesma localização e os mesmos detalhes de acesso.

Zona 2: Material de chaves

O material de chaves é o conjunto de chaves criptográficas que desbloqueiam as credenciais armazenadas. Quem detiver as chaves pode ler os dados, onde quer que esteja o texto cifrado, pelo que a localização das chaves e os seus detentores importam tanto como a localização do servidor. O artigo 32.º, n.º 1, alínea a), só torna a cifragem adequada se as chaves forem controladas com o mesmo cuidado que os dados. 

A cadeia segue esta ordem: palavra-passe mestra, chave mestra, chave privada, chaves de cofre, chaves de registo. A palavra-passe mestra do utilizador gera a chave mestra através de uma função como a PBKDF2, que torna lenta a tentativa de adivinhar palavras-passe. Essa chave decifra uma chave privada, que decifra as chaves de cofre, as quais, por sua vez, desbloqueiam as chaves de cada registo.

O servidor armazena a chave privada e as chaves de cofre de forma cifrada. A chave que as decifra permanece no dispositivo do utilizador, pelo que uma cópia da base de dados, por si só, não dá acesso.

A recuperação é o único percurso de chaves que merece ser mapeado em separado. Alguns modelos incluem uma conta de recuperação ou uma chave de escrow, para que uma organização possa restabelecer o acesso após a perda da palavra-passe mestra. Quem detiver essa chave também pode aceder ao texto simples, pelo que deve ser tratada como qualquer outra chave: quem a detém, onde está armazenada e que tribunais podem obrigar o seu detentor. O guia sobre o que a cifragem zero-knowledge protege e não protege explica o funcionamento.

Zona 3: Dados de serviço

Os dados de serviço são tudo o que o sistema regista sobre a utilização, e não sobre o conteúdo. A cifragem do lado do cliente não os abrange, pelo que o operador normalmente os consegue ler. Isso torna-os dados pessoais por direito próprio e a parte do sistema a que uma exigência legal pode chegar sem tocar na cifragem. Inclui, normalmente:

• Identidades de contas, endereços de e-mail e registos de faturação
• Endereços IP de início de sessão, identificadores de dispositivos e registos de data e hora dos acessos
• Registos de auditoria, bem como nomes de registos e estrutura de pastas, se o produto não os cifrar

Aplicam-se três deveres. Os registos são a evidência para avaliar uma violação (artigos 32.º e 33.º). A conservação deve limitar-se ao necessário (artigo 5.º, n.º 1, alínea e)). Os colaboradores podem solicitar os seus próprios dados (artigo 15.º). Numa implementação em alojamento próprio, esta zona fica a cargo da própria organização.

Zona 4: Cópias de segurança, réplicas e recuperação de desastres

As cópias de segurança, as réplicas e os locais de recuperação de desastres (DR) são as cópias dos dados de credenciais que existem fora do servidor principal. Cada cópia pode situar-se num país diferente e sob um operador diferente, pelo que cada uma requer uma resposta própria sobre localização, cifragem e eliminação.

Cópias de segurança são cópias armazenadas para restaurar dados. Réplicas são cópias ativas noutros servidores. Os locais de recuperação de desastres (DR) são localizações de reserva. Apoiam a disponibilidade e a recuperação (artigo 32.º, n.º 1, alíneas b) e c)), mas cada cópia adicional alarga a superfície de ataque e o conjunto de jurisdições aplicáveis. Há três perguntas a colocar:

• Onde está armazenada cada cópia de segurança e réplica, e alguma cópia sai da UE ou do EEE? Uma cópia num país terceiro pode contar como transferência ao abrigo do capítulo V.
• As cópias de segurança são cifradas e as chaves são mantidas separadas dos dados?
• Depois de terminado o contrato, em quantos dias desaparece a última cópia e como se verifica?

O artigo 28.º, n.º 3, alínea g), exige que o subcontratante, à escolha da organização, elimine ou devolva todos os dados pessoais quando os serviços terminam e elimine as cópias existentes, salvo se a lei exigir a sua conservação. As cópias de segurança estão abrangidas por esse dever. Na prática, expiram frequentemente num ciclo de rotação, pelo que o prazo de conservação é o valor que convém obter por escrito.

Zona 5: Caches de cliente e armazenamento offline

Alguns dados saem do servidor por conceção. As aplicações para computador e móveis podem manter cópias offline, as extensões de navegador podem guardar uma chave de sessão ou de desbloqueio, e os utilizadores podem exportar ficheiros de cofre. Cada uma é uma cópia fora dos controlos centrais e acompanha o dispositivo do colaborador para onde quer que vá.

Esta é a zona em que a política da própria organização mais importa. É necessário decidir se o modo offline é permitido, exigir a cifragem de disco através da gestão de dispositivos móveis (MDM) e restringir quem pode exportar. As exportações merecem o maior cuidado, uma vez que um ficheiro CSV pode ser lido por quem o abrir. Deve perguntar-se ao fornecedor se os administradores podem limitar o modo offline por função, se os dados em cache se apagam após um período definido e se a utilização offline e as exportações são registadas.

Um dispositivo perdido com uma cópia do cofre constitui um risco nos termos do artigo 32.º, n.º 2, que refere a perda e a divulgação não autorizada, e pode desencadear os deveres de notificação de violações previstos nos artigos 33.º e 34.º. Os terminais e os locais de exportação aprovados devem ser listados no RoPA.

Zona 6: Subcontratantes ulteriores e acesso de suporte

Os subcontratantes ulteriores são os fornecedores que um fornecedor utiliza para prestar o serviço, como alojamento, envio de e-mail, monitorização e ferramentas de suporte. Ao abrigo do artigo 28.º, n.os 2 e 4, o subcontratante necessita da autorização da organização para os contratar e tem de transmitir os mesmos deveres de proteção de dados ao longo da cadeia.

Terceiros estiveram envolvidos em 48 % das violações no DBIR de 2026 da Verizon, um aumento de 60 % face ao ano anterior. O relatório agrupa estes casos em três arquétipos: um fornecedor na cadeia de fornecimento de software, um fornecedor que aloja os dados no seu ambiente e um fornecedor com ligação ao ambiente da organização. Um gestor de palavras-passe alojado é do segundo tipo, e uma ligação de suporte ou de integração aos sistemas da organização pode torná-lo do terceiro. Os fornecedores do fornecedor devem ser verificados tão rigorosamente como o seu produto.

Há quatro elementos a solicitar:

• Uma lista atual de subcontratantes ulteriores e do país em que cada um opera
• Aviso prévio de alterações, com direito de oposição
• Quem, na equipa de suporte do fornecedor, pode ver os dados de serviço (Zona 3) e mediante que aprovação
• Se algum subcontratante ulterior ou via de suporte pode aceder ao material de chaves (Zona 2)

Mapa de zonas e artigos: A obrigação e a evidência

O mapa de zonas e artigos associa cada uma das seis zonas de credenciais à disposição do RGPD que ativa, ao documento que comprova a conformidade e à parte responsável por essa obrigação. Serve de base para a entrada do RoPA relativa ao gestor de palavras-passe, e a coluna de evidências deve ser preenchida antes de um auditor perguntar. O dossiê de evidências no final lista os mesmos documentos como lista de verificação.

A repartição determina quem notifica. Nos termos do artigo 33.º, o responsável pelo tratamento notifica a autoridade de controlo no prazo de 72 horas após ter tomado conhecimento de uma violação, sempre que possível. O subcontratante tem de informar a organização «sem demora injustificada», o que não fixa qualquer prazo, pelo que se deve inscrever no DPA um prazo de notificação. Em alojamento próprio, a organização é simultaneamente responsável pelo tratamento e operador, e a coluna Responsável reduz-se às suas próprias equipas.

O DPA a obter de um fornecedor de gestores de palavras-passe

Um acordo de tratamento de dados (DPA) é o contrato que o artigo 28.º, n.º 3, exige entre um responsável pelo tratamento e um subcontratante. No caso de um fornecedor de gestores de palavras-passe, deve indicar o objeto, a duração, a natureza, a finalidade, os tipos de dados e as categorias de titulares dos dados, além de oito obrigações nas alíneas a) a h). As Diretrizes 07/2020 do EDPB sobre responsáveis pelo tratamento e subcontratantes explicam cada uma delas.

A linha das auditorias exige a leitura mais atenta. O artigo 28.º, n.º 3, alínea h), exige que o contrato faculte as informações que comprovam a conformidade e permita auditorias, incluindo inspeções. Se o fornecedor não abrir a sua infraestrutura a inspeções presenciais, o contrato deve indicar o que as substitui.

As evidências a analisar incluem, assim, a lista de subcontratantes ulteriores, uma avaliação de transferências e os relatórios de auditoria a que o contrato dá direito. Devem juntar-se os registos próprios do cofre, exportados para um SIEM (um sistema que recolhe e analisa registos de segurança).

Modelos de implementação da gestão de palavras-passe em conformidade com o RGPD

O modelo de implementação determina quais das seis zonas a equipa controla. Uma cloud de fornecedor deixa a maioria das zonas com o fornecedor, uma cloud numa região da UE reduz os locais onde se situam e o alojamento próprio transfere-as para a infraestrutura e para a lista de deveres da organização. As configurações air-gapped vão mais longe e acrescentam o tratamento offline de atualizações e registos.

Um serviço gerido pelo fornecedor oferece menos controlo sobre os formatos de exportação e o momento da saída. Antes de assinar, convém verificar como se poderia sair: que formatos se podem exportar e qual o prazo para eliminar as cópias de segurança nos termos do artigo 28.º, n.º 3, alínea g).

Alojamento próprio e RGPD: Que deveres se assumem

O alojamento próprio transfere os deveres do RGPD de um contrato com um fornecedor para os procedimentos operacionais da própria organização. A organização controla onde se situa cada zona e quem a opera, o que pode eliminar a relação de subcontratação para o próprio cofre. Passa também a ser o operador, pelo que assegura as evidências por si. A página sobre o gestor de palavras-passe on-premise descreve esta opção de implementação.

O que se ganha:

• Controlo sobre o local onde se situa cada zona, incluindo as cópias de segurança
• Nenhuma transferência para um fornecedor e nenhuma cadeia de subcontratantes ulteriores para o próprio cofre

O que passa a ser devido:

• Localizações das cópias de segurança e das réplicas, restauros testados e um calendário de conservação
• Procedimentos de recuperação de chaves, aplicação de patches e alta disponibilidade
• Um registo atualizado das atividades de tratamento (artigo 30.º)
• Um processo próprio de deteção e notificação de violações (artigo 33.º)

Exemplo hipotético: uma equipa restaura um cofre após uma falha de servidor e descobre que a tarefa de cópia de segurança noturna estava a gravar num armazenamento num segundo país, configurado anos antes por alguém que entretanto saiu. O cofre estava on-premises, mas uma cópia nunca esteve. Essa cópia é uma questão de transferência nos termos do capítulo V. Uma verificação zona a zona encontra-a antes de um incidente.

O risco interno permanece com a organização. A cifragem do lado do cliente impede os administradores de ler o conteúdo do cofre, mas estes continuam a poder eliminar dados, copiar texto cifrado e cópias de segurança, alterar a configuração ou editar registos. Convém segregar funções e registar as ações dos administradores.

As implementações air-gapped acrescentam outro dever. Sem ligação à internet, as atualizações são aplicadas e os registos movidos manualmente. O isolamento não elimina vulnerabilidades, e os suportes de dados transportados para dentro tornam-se o meio pelo qual uma atualização chega ao sistema.

O artigo 32.º, n.º 1, exige medidas adequadas ao risco. Deve documentar-se quem aprova um pacote de atualização, como se verifica a sua integridade antes da importação, com que frequência os registos saem da rede e quem trata dos suportes de dados. O procedimento de restauro também deve ser testado, uma vez que as alíneas c) e d) do n.º 1 do artigo 32.º abrangem o restabelecimento da disponibilidade e o teste regular das medidas.

Como o Passwork gere a localização e o acesso aos dados

O Passwork Self-hosted funciona numa infraestrutura sob o controlo da organização: servidores on-premises, uma cloud privada ou uma rede air-gapped. O cofre, as chaves e as cópias de segurança ficam onde a organização os colocar, pelo que é a equipa que decide onde se situa cada zona. As respostas abaixo seguem as seis zonas e as perguntas formuladas acima.

O Passwork instala-se com Docker em Linux (a via recomendada), com um script PowerShell em Windows Server ou manualmente, e existem pacotes offline para redes air-gapped. Os guias técnicos do Passwork abordam cada via.

Conteúdo do cofre e chaves (zonas 1 e 2). Os dados são cifrados no cliente com AES-256, pelo que o servidor armazena apenas texto cifrado e material de chaves cifrado. A chave mestra é derivada com PBKDF2 e nunca sai do dispositivo do utilizador em texto simples. Uma segunda camada AES-256, independente, protege a base de dados no servidor.

A arquitetura zero-knowledge determina quem pode ler os dados: apenas os utilizadores que detêm as chaves, pelo que nem os próprios administradores da organização conseguem ler o conteúdo do cofre. A recuperação faz-se através de uma conta de recuperação previamente criada, cuja palavra-passe mestra é guardada offline, e é a organização que decide quem a detém.

Dados de serviço (zona 3). O «Activity Log» (registo de atividade) regista as ações de utilizadores, administradores e do sistema, e os seus registos de auditoria estão preparados para integração com SIEM. Os nomes de registos e de pastas, a estrutura de acessos e os metadados de auditoria ficam no servidor, pelo que devem constar do RoPA. A política de conservação é definida pela organização, que mantém os registos no seu próprio armazenamento.

Cópias de segurança e réplicas (zona 4). Os replica sets do MongoDB com três ou mais membros votantes, em conjunto com servidores de aplicação escalados horizontalmente, conferem ao serviço tolerância a falhas para mais de 10 000 utilizadores. Tarefas agendadas em segundo plano criam e fazem a rotação dos ficheiros de cópia de segurança, e é a organização que escolhe onde são armazenados.

Caches de cliente e armazenamento offline (zona 5). O modo offline é só de leitura e requer ativação expressa em dois níveis: o utilizador marca um registo e depois ativa o modo offline num dispositivo específico. Os administradores controlam as funções que o podem utilizar, o número máximo de registos por dispositivo e o tempo máximo sem sincronização antes de um apagamento automático. Os descarregamentos e as visualizações offline são sincronizados com o «Activity Log» e com o «Security Dashboard» (painel de segurança) quando o dispositivo volta a ligar-se. 

Subcontratantes ulteriores (zona 6). Uma implementação em alojamento próprio não tem subcontratantes ulteriores alojados por um fornecedor. A lista de fornecedores limita-se aos prestadores de alojamento e de cópias de segurança da própria organização, e as mesmas perguntas acima aplicam-se-lhes. Um prestador de cloud privada que opere o cofre para a organização é o seu subcontratante e necessita de um DPA próprio.

O acesso segue o princípio do menor privilégio. O controlo de acesso baseado em funções (RBAC) define os níveis de acesso a cofres e pastas, a sincronização de grupos LDAP e Active Directory transpõe as alterações do diretório para o Passwork e o SAML SSO trata do início de sessão. O Passwork está certificado ISO 27001, é testado através da HackerOne e o seu código-fonte está disponível para auditoria independente.

Dossiê de evidências do RGPD para a gestão de palavras-passe

O dossiê de evidências de 8 pontos é o conjunto de documentos que se deve possuir antes de uma auditoria ao gestor de palavras-passe ao abrigo do RGPD. Abrange registos de tratamento, condições do fornecedor, avaliações de transferências, localização das cópias de segurança, revisões de acessos e procedimentos de violação. Os pontos 1 a 6 correspondem a zonas individuais, enquanto os pontos 7 e 8 abrangem o acesso e a gestão de violações em todas elas.

• Entrada do registo das atividades de tratamento para o gestor de palavras-passe, com as seis zonas (artigo 30.º)
• DPA assinado que abranja as condições do artigo 28.º, n.º 3, se um fornecedor ou prestador de alojamento tratar qualquer zona
• Lista atual de subcontratantes ulteriores e cláusula de aviso de alterações, na mesma condição
• Avaliação de impacto da transferência, se alguma zona envolver um país terceiro (capítulo V)
• Avaliação de impacto sobre a proteção de dados, se a análise de risco o exigir (artigo 35.º)
• Mapa de cópias de segurança e réplicas, com localizações e condições de eliminação
• Revisão das permissões do cofre, realizada a partir de exportações do registo de auditoria
• Procedimento de violação em 72 horas que indique quem decide e quem notifica (artigo 33.º)

O RGPD não fixa qualquer intervalo para as revisões de acessos. A cadência trimestral é comum, pelo que convém definir uma adequada ao risco e documentá-la.

O registo de auditoria é a evidência que sustenta os pontos 7 e 8. Mostra quem acedeu a que credencial e quando, o que ajuda a delimitar uma violação e a avaliar se os dados pessoais podem ter sido afetados. Deve ser exportado para um SIEM, para sobreviver ao cofre e alimentar o registo de violações exigido pelo artigo 33.º, n.º 5.

Por onde começar na gestão de palavras-passe em conformidade com o RGPD

A gestão de palavras-passe em conformidade com o RGPD começa por adequar a implementação aos dados que não podem sair da jurisdição da organização. Depois, é necessário dispor de um contrato ou registo para cada zona que um fornecedor trata: onde se situam o conteúdo, as chaves, os dados de serviço, as cópias de segurança, as caches e os subcontratantes ulteriores, e o que abrange cada um.

Comece por uma única página. Desenhe as seis zonas do gestor de palavras-passe atual e assinale aquelas a que não consegue responder. Essas são as primeiras perguntas a colocar ao fornecedor ou, em alojamento próprio, as primeiras tarefas internas. Depois de completo o mapa, o guia de segurança de palavras-passe segundo o RGPD aborda o nível seguinte: regras de palavras-passe e práticas do pessoal.

Perguntas frequentes

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

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

PassworkPasswork Team

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

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

PassworkPasswork Team

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

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

PassworkAlex Muntyan

Die Datenschutz-Grundverordnung (DSGVO), das Datenschutzgesetz der EU, verlangt für die Übermittlung personenbezogener Daten außerhalb des Europäischen Wirtschaftsraums (EWR, die EU plus Island, Liechtenstein und Norwegen) eine Rechtsgrundlage für die Übermittlung sowie Sicherheitsmaßnahmen, die dem Risiko angemessen sind. Kennen Sie für DSGVO-konformes Passwortmanagement jeden Ort, an dem Ihre Zugangsdaten vorliegen, und halten Sie für jeden einen Nachweis bereit.

Ihre Zugangsdaten können in einem Rechenzentrum in Frankfurt gespeichert sein und trotzdem einer ausländischen Gerichtsanordnung unterliegen, wenn der Anbieter einer Jurisdiktion außerhalb der EU unterliegt. Ein Label „EU-gehostet" sagt zudem nichts darüber aus, wo die Backups liegen. Dieser Artikel stellt die Sechs-Zonen-Karte der Zugangsdaten vor: die Orte, an denen ein Passwortmanager für Unternehmen Daten speichert, den DSGVO-Artikel, den jeder Ort auslöst, und die Nachweise, die Sie bereithalten müssen. Er schließt mit einem 8-Punkte-Evidenzpaket, das Sie vor einem Audit prüfen können.

Was DSGVO-konformes Passwortmanagement erfordert

Die DSGVO verlangt, dass personenbezogene Daten sicher verarbeitet werden, dass der Datenschutz von Anfang an mitgedacht wird und dass Maßnahmen greifen, die dem Risiko angemessen sind. 

DSGVO-konformes Passwortmanagement bedeutet, dass Sie nachweisen können, dass Zugangsdaten verschlüsselt sind, nur für Personen erreichbar sind, die sie benötigen, protokolliert werden und überall, wo sie gespeichert sind, durch die richtigen Verträge und Aufzeichnungen abgedeckt sind.

Das Gesetz legt das Ergebnis fest (Artikel 5(1)(f), 25 und 32). Sie wählen die Maßnahmen und weisen nach, dass sie funktionieren (Artikel 5(2)). In der Praxis ergeben sich daraus fünf Anforderungen:

• Gespeicherte Zugangsdaten verschlüsseln. Artikel 32(1)(a) nennt „die Pseudonymisierung und Verschlüsselung personenbezogener Daten" als geeignete Maßnahme.
• Zugriff über Rollen begrenzen (rollenbasierte Zugriffskontrolle, RBAC). Jede Person meldet sich unter ihrem eigenen Konto an und sieht nur, was ihre Aufgabe erfordert, selbst wenn die geöffneten Zugangsdaten gemeinsam genutzt werden. Das ist Datenschutz durch Technikgestaltung (Artikel 25), angewendet auf den Zugriff.
• Den Dienst verfügbar halten und testen. Artikel 32(1)(b) bis (d) umfasst Belastbarkeit, die Wiederherstellung des Zugriffs nach einem Vorfall und die regelmäßige Überprüfung der Maßnahmen.
• Aufzeichnen, wer was geöffnet hat. Ein Zugriffsprotokoll zeigt, auf welche Zugangsdaten wann zugegriffen wurde. Das ist der Nachweis, den Sie brauchen, um zu beurteilen, ob eine Datenschutzverletzung personenbezogene Daten betroffen hat (Artikel 33).
• Jeden Ort dokumentieren, an dem die Daten liegen. Das bedeutet ein Verzeichnis von Verarbeitungstätigkeiten, einen Vertrag mit jeder externen Partei, die die Daten verarbeitet, und eine Rechtsgrundlage für jede Übermittlung außerhalb des EWR.

Diese Pflichten erfassen Passwörter aus zwei Gründen. Ein Zugangsdatensatz nennt normalerweise einen Mitarbeiter oder verweist auf einen, was ihn zu personenbezogenen Daten macht (Artikel 4(1): jede Information, die sich auf eine identifizierbare Person bezieht). Die Zugangsdaten öffnen außerdem andere Systeme, etwa HR-, CRM- und Kundendatenbanken, in denen personenbezogene Daten gespeichert sind. Artikel 32(2) verlangt, dass Sie das Risiko eines unbefugten Zugriffs auf personenbezogene Daten bewerten – eine Datenschutzverletzung beim Passwortmanager ist damit ein Einstiegspunkt in jedes System, das er entsperrt. Verschlüsselung senkt das Risiko, nimmt den Datensatz aber nicht aus dem Anwendungsbereich. 

Ihre Organisation ist der Verantwortliche für den Tresor, also die Stelle, die entscheidet, warum und wie die Zugangsdaten verwendet werden. Ein Anbieter oder Hosting-Anbieter, der ihn auf Ihre Anweisung betreibt oder unterstützt, ist Auftragsverarbeiter, und Artikel 28 verlangt dafür einen Vertrag. Artikel 30 verlangt, dass Sie ein Verzeichnis von Verarbeitungstätigkeiten (VVT) führen, das die Empfänger, Standorte und Übermittlungen dieser Verarbeitung auflistet. Diese Standorte zu finden, ist die erste Aufgabe.

Residenz, Souveränität und Jurisdiktion sind drei verschiedene Dinge

Datenresidenz bezeichnet, wo Ihre Daten physisch gespeichert sind. Datensouveränität bedeutet, dass die Daten den Gesetzen und der Rechtskontrolle eines bestimmten Landes unterliegen. Jurisdiktion ist, welche Gerichte und Behörden dem Unternehmen des Anbieters Anordnungen erteilen können. Ein Anbieter, der US-Recht unterliegt, kann Ihren Tresor in Deutschland speichern und trotzdem US-Rechtsforderungen erhalten.

Der CLOUD Act erlaubt es US-Behörden, Anbieter elektronischer Kommunikations- oder Remote-Computing-Dienste, die der US-Jurisdiktion unterliegen, zur Herausgabe von Daten zu verpflichten, die sich in ihrem Besitz, ihrer Verwahrung oder ihrer Kontrolle befinden – auch wenn diese im Ausland gespeichert sind. Ein Anbieter, der ein US-Unternehmen ist oder eine US-Muttergesellschaft hat, kann daher solchen Forderungen ausgesetzt sein, während Ihr Tresor in einer EU-Region liegt. Ob ein bestimmter Anbieter unter das Gesetz fällt, ist eine Frage für Ihr Rechtsteam.

Die DSGVO enthält keine allgemeine Pflicht zur Datenlokalisierung. Sie regelt Übermittlungen in Drittländer in Kapitel V (Artikel 44 bis 50), und Fernzugriff von außerhalb des EWR, etwa durch den Support eines Anbieters, kann als Übermittlung gelten. Einige nationale und branchenspezifische Vorschriften fügen eigene Lokalisierungspflichten hinzu, prüfen Sie also die für Sie geltenden Regeln.

Übermittlungen außerhalb des EWR: Welche Mechanismen gelten

Kapitel V der DSGVO verlangt eine Rechtsgrundlage für die Übermittlung und Garantien, die im Zielland Bestand haben. Fernzugriff durch den Support von außerhalb des EWR auf einen innerhalb des EWR gehosteten Passwort-Tresor zählt als Übermittlung, eine Hosting-Region allein beantwortet die Frage also nicht. Es gibt drei Wege, und jeder gilt in einer anderen Situation.

• Angemessenheitsbeschluss (Artikel 45). Die Europäische Kommission hat festgestellt, dass das Schutzniveau im Zielland gleichwertig ist. Der EU-US Data Privacy Framework-Beschluss vom 10. Juli 2023 deckt nur selbstzertifizierte US-Unternehmen ab, prüfen Sie also den Eintrag des Anbieters in der Framework-Liste. Frühere EU-US-Rahmenwerke wurden gerichtlich gekippt, und das aktuelle wird angefochten, halten Sie Standardvertragsklauseln also als Rückfalloption im AVV bereit.
• Geeignete Garantien (Artikel 46). Meist Standardvertragsklauseln (SCC), von der Kommission genehmigte Musterklauseln, zusammen mit einer Transferfolgenabschätzung (TIA). Die TIA prüft, ob das Recht des Ziellands Behörden den Zugriff auf die Daten erlaubt. Sie folgt aus dem Schrems-II-Urteil und den Empfehlungen 01/2020 des EDPB.
• Ausnahmeregelungen (Artikel 49). Eng gefasste Ausnahmen, etwa die ausdrückliche Einwilligung, nachdem die betroffene Person über die Risiken informiert wurde. Sie eignen sich für gelegentliche Übermittlungen, nicht für die routinemäßige Verarbeitung durch einen Anbieter.

Eine EU-Hosting-Region senkt das Risiko, beseitigt es aber nicht. Support-Personal außerhalb des EWR, anderswo verarbeitete Metadaten und eine Muttergesellschaft außerhalb des EWR mit Zugriff können jeweils eine Übermittlung auslösen. Die Befugnis einer ausländischen Behörde, eine Muttergesellschaft zur Offenlegung von Daten zu verpflichten, ist ein eigenständiges Jurisdiktionsrisiko (siehe den Abschnitt zur Residenz oben). Behandeln Sie die Region als einen Faktor Ihrer TIA, nicht als deren Ergebnis.

Die Sechs-Zonen-Karte der Zugangsdaten

Die Sechs-Zonen-Karte der Zugangsdaten teilt einen Passwortmanager für Unternehmen in sechs Orte auf, an denen Zugangsdaten existieren. Jede Zone kann in einem anderen Land liegen und bringt ihre eigene DSGVO-Pflicht mit sich. Wer nur „den Server" prüft, übersieht Kopien, für die er verantwortlich ist.

Ein Passwortmanager ist ein System von Kopien. Einige davon halten Sie selbst, andere der Anbieter, und wieder andere die Lieferanten des Anbieters. Welche Kopien bei Ihnen liegen, hängt vom Bereitstellungsmodell ab. Bei einem selbst gehosteten Modell sind Sie der Betreiber jeder Zone, sodass sich jede Frage unten auf Ihre eigenen Teams und Hosting-Anbieter bezieht statt auf einen Anbieter.

Jede Zone löst außerdem eine andere Pflicht aus. Backups werfen Löschpflichten bei Vertragsende auf (Artikel 28(3)(g)), und Lieferanten werfen Pflichten auf, die entlang der Kette weitergegeben werden müssen (Artikel 28(4)). Die nächsten sechs Unterabschnitte behandeln jede Zone und was Sie dazu erfragen sollten.

Zone 1: Gespeicherte Zugangsdaten

Gespeicherte Zugangsdaten sind die Inhalte, die Nutzer ablegen: Logins, Notizen, Anhänge und die Geheimnisse hinter Einmalcodes. Mit clientseitiger Verschlüsselung erreicht sie der Server als Chiffretext – Daten, die ohne den Schlüssel unlesbar sind. Eine gestohlene Kopie der Datenbank legt dann nur unlesbare Geheimnisse offen, vorausgesetzt der Schlüssel, der den verschlüsselten privaten Schlüssel entschlüsselt, bleibt auf dem Gerät des Nutzers (siehe Zone 2).

Verschlüsselte Zugangsdaten bleiben personenbezogene Daten, wenn sie sich auf eine identifizierbare Person beziehen, Zone 1 bleibt also im Anwendungsbereich. Artikel 32(1)(a) nennt Verschlüsselung als Beispiel einer geeigneten Maßnahme, und sie senkt das Risiko. Erfassen Sie in Ihrem VVT-Eintrag für den Passwortmanager den Standort und die Verschlüsselungsmethode dieser Zone.

Datensatznamen, Ordnerstruktur und Audit-Metadaten werden getrennt gespeichert und gehören zu Zone 3. Führen Sie dafür eine eigene VVT-Zeile mit denselben Angaben zu Standort und Zugriff.

Zone 2: Schlüsselmaterial

Schlüsselmaterial ist die Gesamtheit der kryptografischen Schlüssel, die gespeicherte Zugangsdaten entsperren. Wer die Schlüssel besitzt, kann die Daten lesen, unabhängig davon, wo der Chiffretext liegt – Schlüsselstandort und Schlüsselinhaber sind daher ebenso wichtig wie der Serverstandort. Artikel 32(1)(a) macht Verschlüsselung nur dann zu einer geeigneten Maßnahme, wenn die Schlüssel ebenso sorgfältig kontrolliert werden wie die Daten. 

Die Kette verläuft über Masterpasswort, Hauptschlüssel, privaten Schlüssel, Tresorschlüssel, Datensatzschlüssel. Aus dem Masterpasswort des Nutzers wird der Hauptschlüssel über eine Funktion wie PBKDF2 abgeleitet, die das Erraten von Passwörtern verlangsamt. Dieser Schlüssel entschlüsselt einen privaten Schlüssel, der Tresorschlüssel entschlüsselt, die wiederum die Schlüssel einzelner Datensätze entsperren.

Der Server speichert den privaten Schlüssel und die Tresorschlüssel in verschlüsselter Form. Der Schlüssel, der sie entschlüsselt, bleibt auf dem Gerät des Nutzers, sodass eine Kopie der Datenbank allein keinen Zugriff ermöglicht.

Die Wiederherstellung ist der eine Schlüsselpfad, den es sich lohnt, gesondert zu betrachten. Manche Designs enthalten ein Wiederherstellungskonto oder einen Hinterlegungsschlüssel, damit eine Organisation den Zugriff nach einem verlorenen Masterpasswort wiederherstellen kann. Wer diesen Schlüssel besitzt, kann ebenfalls auf Klartext zugreifen – behandeln Sie ihn also wie jeden anderen Schlüssel: wer ihn besitzt, wo er gespeichert ist und welche Gerichte seinen Inhaber zur Herausgabe verpflichten können. Unser Leitfaden zu dem, was Zero-Knowledge-Verschlüsselung schützt und was nicht, erklärt die Mechanik.

Zone 3: Servicedaten

Servicedaten sind alles, was das System über die Nutzung aufzeichnet, statt über den Inhalt. Clientseitige Verschlüsselung deckt sie nicht ab, sodass der Betreiber sie meist lesen kann. Das macht sie selbst zu personenbezogenen Daten und zu dem Teil des Systems, den eine behördliche Anordnung erreichen kann, ohne die Verschlüsselung anzutasten. Dazu gehören typischerweise:

• Kontoidentitäten, E-Mail-Adressen und Rechnungsdaten
• Anmelde-IP-Adressen, Geräte-Kennungen und Zugriffszeitstempel
• Audit-Protokolle sowie Datensatznamen und Ordnerstruktur, falls das Produkt sie nicht verschlüsselt

Drei Pflichten gelten hier. Protokolle sind Ihr Nachweis zur Beurteilung einer Datenschutzverletzung (Artikel 32 und 33). Die Speicherdauer muss auf das Nötige begrenzt sein (Artikel 5(1)(e)). Mitarbeiter können ihre eigenen Daten anfordern (Artikel 15). Bei einem selbst gehosteten Modell halten Sie diese Zone selbst.

Zone 4: Backups, Replikate und Disaster Recovery

Backups, Replikate und Disaster-Recovery-Standorte (DR) sind die Kopien von Zugangsdaten, die außerhalb des primären Servers liegen. Jede Kopie kann in einem anderen Land und unter einem anderen Betreiber liegen, sodass für jede eine eigene Antwort zu Standort, Verschlüsselung und Löschung nötig ist.

Backups sind gespeicherte Kopien zur Wiederherstellung von Daten. Replikate sind laufende Kopien auf anderen Servern. Disaster-Recovery-Standorte (DR) sind Standby-Standorte. Sie unterstützen Verfügbarkeit und Wiederherstellung (Artikel 32(1)(b) und (c)), aber jede zusätzliche Kopie vergrößert die Angriffsfläche und die Zahl der geltenden Jurisdiktionen. Fragen Sie drei Dinge ab:

• Wo wird jedes Backup und Replikat gespeichert, und verlässt eine Kopie die EU oder den EWR? Eine Kopie in einem Drittland kann nach Kapitel V als Übermittlung zählen.
• Sind die Backups verschlüsselt, und werden die Schlüssel getrennt von den Daten aufbewahrt?
• Wie viele Tage dauert es nach Vertragsende, bis die letzte Kopie gelöscht ist, und wie überprüfen Sie das?

Artikel 28(3)(g) verpflichtet den Auftragsverarbeiter, nach Ihrer Wahl alle personenbezogenen Daten bei Beendigung der Dienste zu löschen oder zurückzugeben und vorhandene Kopien zu löschen, sofern das Recht keine Speicherung verlangt. Backups fallen unter diese Pflicht. In der Praxis laufen sie oft über einen Rotationszyklus aus, die Aufbewahrungsdauer ist also die Zahl, die Sie sich schriftlich geben lassen sollten.

Zone 5: Client-Caches und Offline-Speicher

Manche Daten verlassen den Server konstruktionsbedingt. Desktop- und Mobil-Apps können Offline-Kopien vorhalten, Browser-Erweiterungen können eine Sitzung oder einen Entsperrschlüssel vorhalten, und Nutzer können Tresordateien exportieren. Jede davon ist eine Kopie außerhalb Ihrer zentralen Kontrolle und reist dorthin, wohin das Gerät des Mitarbeiters reist.

Das ist die Zone, in der Ihre eigene Richtlinie am meisten zählt. Legen Sie fest, ob der Offline-Modus erlaubt ist, verlangen Sie Festplattenverschlüsselung über Mobile Device Management (MDM), und schränken Sie ein, wer exportieren darf. Behandeln Sie Exporte mit der größten Sorgfalt, da eine CSV-Datei für jeden lesbar ist, der sie öffnet. Fragen Sie den Anbieter, ob Administratoren den Offline-Modus nach Rolle einschränken können, ob zwischengespeicherte Daten sich nach einer festgelegten Zeit selbst löschen und ob Offline-Nutzung und Exporte protokolliert werden.

Ein verlorenes Gerät mit einer Tresorkopie ist ein Risiko nach Artikel 32(2), der Verlust und unbefugte Offenlegung nennt, und kann die Meldepflichten bei Datenschutzverletzungen nach Artikel 33 und 34 auslösen. Listen Sie Endgeräte und zugelassene Exportorte in Ihrem VVT auf.

Zone 6: Unterauftragsverarbeiter und Support-Zugriff

Unterauftragsverarbeiter sind die Lieferanten, die ein Anbieter zur Erbringung des Dienstes einsetzt, etwa für Hosting, E-Mail-Zustellung, Monitoring und Support-Tools. Nach Artikel 28(2) und 28(4) braucht der Auftragsverarbeiter Ihre Genehmigung, um sie einzubinden, und muss dieselben Datenschutzpflichten entlang der Kette weitergeben.

Dritte waren laut Verizons DBIR 2026 an 48 % der Datenschutzverletzungen beteiligt – ein Anstieg von 60 % gegenüber dem Vorjahr. Der Bericht ordnet diese Fälle drei Archetypen zu: einem Anbieter in Ihrer Software-Lieferkette, einem Anbieter, der Ihre Daten in seiner Umgebung hostet, und einem Anbieter mit einer Verbindung in Ihre Umgebung. Ein gehosteter Passwortmanager ist der zweite Typ, und eine Support- oder Integrationsverbindung in Ihre Systeme kann ihn zum dritten machen. Prüfen Sie die Lieferanten des Anbieters so genau wie dessen Produkt.

Fordern Sie vier Dinge an:

• Eine aktuelle Liste der Unterauftragsverarbeiter und des Landes, in dem jeder tätig ist
• Vorabbenachrichtigung über Änderungen, mit einem Widerspruchsrecht
• Wer im Support-Team des Anbieters Servicedaten einsehen kann (Zone 3) und unter welcher Genehmigung
• Ob ein Unterauftragsverarbeiter oder Support-Zugang auf Schlüsselmaterial zugreifen kann (Zone 2)

Zone-zu-Artikel-Karte: Die Pflicht und der Nachweis

Die Zone-zu-Artikel-Karte ordnet jeder der sechs Zugangsdaten-Zonen die DSGVO-Vorschrift zu, die sie auslöst, das Dokument, das die Einhaltung belegt, und die Partei, die dafür verantwortlich ist. Nutzen Sie sie als Grundgerüst für Ihren VVT-Eintrag zum Passwortmanager, und füllen Sie die Nachweis-Spalte aus, bevor ein Auditor fragt. Das Evidenzpaket am Ende listet dieselben Dokumente als Checkliste.

Diese Aufteilung entscheidet, wer meldet. Nach Artikel 33 meldet der Verantwortliche die Datenschutzverletzung der Aufsichtsbehörde innerhalb von 72 Stunden, nachdem er davon Kenntnis erlangt hat, soweit möglich. Der Auftragsverarbeiter muss Sie „unverzüglich" informieren, was keine Zahl festlegt – schreiben Sie also eine Meldefrist in den AVV. Beim Self-Hosting sind Sie zugleich Verantwortlicher und Betreiber, und die Spalte „Verantwortlich" fällt auf Ihre eigenen Teams zusammen.

Der AVV, den Sie von einem Passwortmanager-Anbieter brauchen

Ein Auftragsverarbeitungsvertrag (AVV) ist der Vertrag, den Artikel 28(3) zwischen einem Verantwortlichen und einem Auftragsverarbeiter vorschreibt. Für einen Passwortmanager-Anbieter muss er Gegenstand, Dauer, Art, Zweck, Datenarten und Kategorien betroffener Personen festlegen, zuzüglich acht Pflichten in den Punkten (a) bis (h). Die EDPB Guidelines 07/2020 zu Verantwortlichen und Auftragsverarbeitern erläutern jede davon.

Die Zeile zu Audits verdient die genaueste Lektüre. Artikel 28(3)(h) verlangt, dass Ihnen der Vertrag die Informationen gibt, die die Einhaltung belegen, und Audits einschließlich Inspektionen erlaubt. Öffnet der Anbieter seine Infrastruktur nicht für eine Inspektion vor Ort, sollte der Vertrag festlegen, was stattdessen gilt.

Die Nachweise, die Sie dann prüfen, umfassen die Liste der Unterauftragsverarbeiter, eine Transferfolgenabschätzung und die Audit-Berichte, auf die Ihnen der Vertrag Anspruch gibt. Ergänzen Sie Ihre eigenen Tresor-Protokolle, exportiert in ein SIEM (ein System, das Sicherheitsprotokolle sammelt und auswertet).

Bereitstellungsmodelle für DSGVO-konformes Passwortmanagement

Ihr Bereitstellungsmodell entscheidet, welche der sechs Zonen Ihr Team kontrolliert. Eine Anbieter-Cloud belässt die meisten Zonen beim Anbieter, eine EU-Region-Cloud schränkt ein, wo sie liegen, und Self-Hosting verlagert sie auf Ihre Infrastruktur und Ihre Pflichtenliste. Air-gapped-Umgebungen gehen am weitesten und ergänzen den Umgang mit Offline-Updates und Protokollen.

Ein vom Anbieter verwalteter Dienst gibt Ihnen weniger Kontrolle über Exportformate und den Zeitpunkt eines Ausstiegs. Prüfen Sie vor der Unterschrift, wie Sie den Dienst verlassen würden: welche Formate Sie exportieren können und welche Frist für die Löschung von Backups nach Artikel 28(3)(g) gilt.

Self-Hosting und DSGVO: Welche Pflichten Sie übernehmen

Self-Hosting verlagert DSGVO-Pflichten von einem Anbietervertrag in Ihre eigenen Betriebsabläufe. Sie kontrollieren, wo jede Zone liegt und wer sie betreibt, wodurch das Auftragsverarbeiterverhältnis für den Tresor selbst entfallen kann. Sie werden außerdem selbst zum Betreiber und tragen die Nachweise damit selbst. Unsere Seite zum On-Premises-Passwortmanager behandelt diese Bereitstellungsoption.

Was Sie gewinnen:

• Kontrolle darüber, wo jede Zone liegt, einschließlich Backups
• Keine Übermittlung an einen Anbieter und keine Kette von Unterauftragsverarbeitern für den Tresor selbst

Was Sie nun schulden:

• Standorte von Backups und Replikaten, getestete Wiederherstellungen und einen Aufbewahrungsplan
• Verfahren zur Schlüsselwiederherstellung, Patching und Hochverfügbarkeit
• Ein aktuelles Verzeichnis von Verarbeitungstätigkeiten (Artikel 30)
• Ihren eigenen Prozess zur Erkennung und Meldung von Datenschutzverletzungen (Artikel 33)

Hypothetisches Beispiel: Ein Team stellt einen Tresor nach einem Server-Absturz wieder her und stellt fest, dass der nächtliche Backup-Job seit Jahren in einen Speicher in einem zweiten Land schreibt, eingerichtet von jemandem, der das Unternehmen inzwischen verlassen hat. Der Tresor lag on-premises, eine Kopie jedoch nie. Diese Kopie ist eine Übermittlungsfrage nach Kapitel V. Eine Prüfung Zone für Zone findet das, bevor es ein Vorfall tut.

Das Insider-Risiko bleibt bei Ihnen. Clientseitige Verschlüsselung bedeutet, dass Administratoren Tresorinhalte nicht lesen können, aber sie können weiterhin Daten löschen, Chiffretext und Backups kopieren, die Konfiguration ändern oder Protokolle bearbeiten. Trennen Sie Zuständigkeiten, und protokollieren Sie Administratorhandlungen.

Air-gapped-Bereitstellungen bringen eine weitere Pflicht mit sich. Ohne Internetverbindung spielen Sie Updates manuell ein und bewegen Protokolle manuell. Isolation entfernt keine Schwachstellen, und der Datenträger, den Sie hineintragen, wird zum Weg, auf dem ein Update das System erreicht.

Artikel 32(1) verlangt dem Risiko angemessene Maßnahmen. Dokumentieren Sie, wer ein Update-Paket genehmigt, wie Sie seine Integrität vor dem Import prüfen, wie oft Protokolle das Netzwerk verlassen und wer die Datenträger handhabt. Testen Sie auch das Wiederherstellungsverfahren, denn 32(1)(c) und (d) decken die Wiederherstellung der Verfügbarkeit und die regelmäßige Überprüfung Ihrer Maßnahmen ab.

Wie Passwork Datenstandort und Zugriff handhabt

Passwork Self-hosted läuft auf Infrastruktur, die Sie kontrollieren: On-Premises-Server, eine Private Cloud oder ein air-gapped Netzwerk. Der Tresor, die Schlüssel und die Backups liegen dort, wo Sie sie platzieren, Ihr Team entscheidet also, wo jede Zone liegt. Die Antworten unten folgen den sechs Zonen und den oben gestellten Fragen.

Passwork wird mit Docker auf Linux installiert (der empfohlene Weg), mit einem PowerShell-Skript auf Windows Server oder manuell, und Offline-Pakete decken air-gapped Netzwerke ab. Die technischen Leitfäden von Passwork behandeln jeden Weg.

Tresorinhalt und Schlüssel (Zonen 1 und 2). Daten werden clientseitig mit AES-256 verschlüsselt, der Server speichert also nur Chiffretext und verschlüsseltes Schlüsselmaterial. Der Hauptschlüssel wird mit PBKDF2 abgeleitet und verlässt das Gerät des Nutzers nie im Klartext. Eine zweite, unabhängige AES-256-Schicht schützt die Datenbank auf dem Server.

Zero-Knowledge-Architektur entscheidet, wer die Daten lesen kann: nur die Nutzer, die die Schlüssel besitzen, sodass auch Ihre eigenen Administratoren die Tresorinhalte nicht lesen können. Die Wiederherstellung läuft über ein vorab eingerichtetes Wiederherstellungskonto, dessen Masterpasswort Sie offline speichern, und Sie entscheiden, wer es besitzt.

Servicedaten (Zone 3). Das Aktivitätsprotokoll erfasst Nutzer-, Admin- und Systemaktionen, und seine Audit-Trails sind bereit für die SIEM-Integration. Datensatz- und Ordnernamen, Zugriffsstruktur und Audit-Metadaten liegen auf dem Server, listen Sie sie also in Ihrem VVT auf. Sie legen die Aufbewahrungsrichtlinie fest und bewahren die Protokolle auf Ihrem eigenen Speicher auf.

Backups und Replikate (Zone 4). MongoDB-Replikatsets mit drei oder mehr stimmberechtigten Mitgliedern geben dem Dienst zusammen mit horizontal skalierten Anwendungsservern Fehlertoleranz für über 10.000 Nutzer. Geplante Hintergrundaufgaben erstellen und rotieren Backup-Archive, und Sie wählen, wo sie gespeichert werden.

Client-Caches und Offline-Speicher (Zone 5). Der Offline-Modus ist nur lesend und auf zwei Ebenen opt-in: Der Nutzer markiert einen Datensatz und aktiviert dann Offline auf einem bestimmten Gerät. Administratoren legen fest, welche Rollen ihn nutzen dürfen, die maximale Anzahl an Datensätzen pro Gerät und die maximale nicht synchronisierte Zeit vor einer automatischen Löschung. Offline-Downloads und -Ansichten werden mit dem Aktivitätsprotokoll und dem Sicherheits-Dashboard synchronisiert, sobald das Gerät wieder verbunden ist. 

Unterauftragsverarbeiter (Zone 6). Eine selbst gehostete Bereitstellung hat keinen vom Anbieter gehosteten Unterauftragsverarbeiter. Ihre Lieferantenliste beschränkt sich auf Ihre eigenen Hosting- und Backup-Anbieter, und dieselben Fragen von oben gelten für sie. Ein Private-Cloud-Host, der den Tresor für Sie betreibt, ist Ihr Auftragsverarbeiter und braucht seinen eigenen AVV.

Der Zugriff folgt dem Prinzip der geringsten Privilegien. Rollenbasierte Zugriffskontrolle (RBAC) legt Zugriffslevel für Tresore und Ordner fest, LDAP- und Active-Directory-Gruppensynchronisierung überträgt Verzeichnisänderungen nach Passwork, und SAML SSO übernimmt die Anmeldung. Passwork ist ISO-27001-zertifiziert, über HackerOne getestet, und der Quellcode steht für eine unabhängige Prüfung zur Verfügung.

DSGVO-Evidenzpaket für Passwortmanagement

Das 8-Punkte-Evidenzpaket ist die Zusammenstellung der Dokumente, die Sie vor einem DSGVO-Audit Ihres Passwortmanagers bereithalten sollten. Es umfasst Verarbeitungsaufzeichnungen, Anbieterbedingungen, Transferfolgenabschätzungen, Backup-Standorte, Zugriffsüberprüfungen und Verfahren bei Datenschutzverletzungen. Punkte 1 bis 6 sind einzelnen Zonen zugeordnet, während Punkte 7 und 8 Zugriff und den Umgang mit Datenschutzverletzungen über alle Zonen hinweg abdecken.

• Eintrag im Verzeichnis von Verarbeitungstätigkeiten für den Passwortmanager, der alle sechs Zonen aufführt (Artikel 30)
• Unterschriebener AVV, der die Bedingungen nach Artikel 28(3) abdeckt, falls ein Anbieter oder Hosting-Anbieter eine Zone verarbeitet
• Aktuelle Liste der Unterauftragsverarbeiter und die Klausel zur Änderungsmitteilung, unter derselben Bedingung
• Transferfolgenabschätzung, falls eine Zone ein Drittland berührt (Kapitel V)
• Datenschutz-Folgenabschätzung, falls Ihre Risikobewertung eine erfordert (Artikel 35)
• Backup- und Replikat-Karte mit Standorten und Löschfristen
• Zugriffsüberprüfung der Tresor-Berechtigungen, durchgeführt anhand von Audit-Protokoll-Exporten
• Ein 72-Stunden-Verfahren bei Datenschutzverletzungen, das benennt, wer entscheidet und wer meldet (Artikel 33)

Die DSGVO legt kein festes Intervall für Zugriffsüberprüfungen fest. Vierteljährlich ist ein gängiger Rhythmus, legen Sie also einen fest, der zu Ihrem Risiko passt, und dokumentieren Sie ihn.

Das Audit-Protokoll ist der Nachweis hinter Punkt 7 und 8. Es zeigt, wer wann auf welche Zugangsdaten zugegriffen hat, was Ihnen hilft, das Ausmaß einer Datenschutzverletzung einzuschätzen und zu beurteilen, ob personenbezogene Daten betroffen sein könnten. Exportieren Sie es in Ihr SIEM, damit es den Tresor überlebt und das von Artikel 33(5) vorgeschriebene Verzeichnis der Datenschutzverletzungen speist.

Wo Sie mit DSGVO-konformem Passwortmanagement anfangen

DSGVO-konformes Passwortmanagement beginnt damit, die Bereitstellung an die Daten anzupassen, die Ihre Jurisdiktion nicht verlassen dürfen. Halten Sie dann für jede Zone, die ein Anbieter verarbeitet, einen Vertrag oder Nachweis bereit: wo Inhalt, Schlüssel, Servicedaten, Backups, Caches und Unterauftragsverarbeiter liegen und was jeweils greift.

Beginnen Sie mit einer einzigen Seite. Zeichnen Sie die sechs Zonen für Ihren aktuellen Passwortmanager auf, und markieren Sie die, die Sie nicht beantworten können. Das sind Ihre ersten Fragen an den Anbieter oder Ihre ersten internen Aufgaben, wenn Sie selbst hosten. Sobald die Karte vollständig ist, behandelt der DSGVO-Leitfaden zur Passwortsicherheit die nächste Ebene: Passwortregeln und die Praxis der Mitarbeiter.

Häufig gestellte Fragen

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

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

PassworkPasswork Team

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

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

PassworkPasswork Team

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

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

PassworkAlex Muntyan

El Reglamento General de Protección de Datos (RGPD), la ley de protección de datos de la UE, exige un mecanismo de transferencia lícito para enviar datos personales fuera del Espacio Económico Europeo (EEE, la UE más Islandia, Liechtenstein y Noruega), y medidas de seguridad adecuadas al riesgo. Para una gestión de contraseñas conforme al RGPD, es necesario saber en qué lugares existen los datos de las credenciales y disponer de pruebas para cada uno de ellos.

Sus credenciales pueden almacenarse en un centro de datos de Fráncfort y, aun así, quedar sujetas a una orden judicial extranjera si el proveedor está sometido a una jurisdicción ajena a la UE. Una etiqueta «alojado en la UE» tampoco dice nada sobre dónde están las copias de seguridad. Este artículo presenta el mapa de seis zonas de datos de credenciales: los lugares donde un gestor de contraseñas empresarial guarda datos, el artículo del RGPD que activa cada uno y las pruebas que debe conservar. Termina con un paquete de evidencias de 8 puntos que puede comprobar antes de una auditoría.

Qué exige la gestión de contraseñas conforme al RGPD

El RGPD exige que los datos personales se procesen de forma segura, que la protección de datos se integre desde el diseño y que se apliquen medidas proporcionales al riesgo. 

Una gestión de contraseñas conforme al RGPD significa poder demostrar que los datos de las credenciales están cifrados, que solo pueden acceder a ellos las personas que los necesitan, que quedan registrados y que están cubiertos por los contratos y registros adecuados, sea donde sea que se almacenen.

La ley fija el resultado (artículos 5(1)(f), 25 y 32). Usted elige los controles y demuestra que funcionan (artículo 5(2)). En la práctica, esto se traduce en cinco requisitos:

• Cifre las credenciales almacenadas. El artículo 32(1)(a) cita «la seudonimización y el cifrado de datos personales» como una medida adecuada.
• Limite el acceso por rol (RBAC). Cada persona inicia sesión con su propia cuenta y solo ve lo que su trabajo requiere, incluso cuando la credencial que abre es compartida. Esto es protección de datos desde el diseño (artículo 25) aplicada al acceso.
• Mantenga el servicio disponible y probado. El artículo 32(1)(b) a (d) cubre la resiliencia, la restauración del acceso tras un incidente y las pruebas periódicas de sus medidas.
• Registre quién abrió qué. Un registro de accesos muestra qué credenciales se consultaron y cuándo. Es la evidencia que necesita para valorar si una vulneración afectó a datos personales (artículo 33).
• Documente cada lugar donde residen los datos. Esto implica un registro de tratamiento, un contrato con cada tercero que trate los datos y un mecanismo lícito para cualquier transferencia fuera del EEE.

Estas obligaciones alcanzan a las contraseñas por dos motivos. Un registro de credenciales suele identificar a un empleado o estar vinculado a uno, lo que lo convierte en un dato personal (artículo 4(1): cualquier información relativa a una persona identificable). Las credenciales también dan acceso a otros sistemas, como RR. HH., CRM y bases de datos de clientes, donde se almacenan datos personales. El artículo 32(2) exige evaluar el riesgo de acceso no autorizado a datos personales, por lo que una vulneración del gestor de contraseñas es una vía de entrada a todos los sistemas que desbloquea. El cifrado reduce el riesgo, pero no excluye el registro del ámbito de aplicación. 

Su organización es el responsable del tratamiento de la bóveda, la parte que decide por qué y cómo se usan los datos de las credenciales. Un proveedor o proveedor de alojamiento que lo opera o lo respalda siguiendo sus instrucciones es un encargado del tratamiento, y el artículo 28 exige un contrato con él. El artículo 30 exige mantener un registro de actividades de tratamiento (RoPA) que recoja los destinatarios, las ubicaciones y las transferencias de este tratamiento. Encontrar esas ubicaciones es la primera tarea.

Residencia, soberanía y jurisdicción son tres cosas distintas

La residencia de los datos es el lugar donde se almacenan físicamente. La soberanía de los datos significa que los datos están sujetos a las leyes y al control legal de un país determinado. La jurisdicción es qué tribunales y autoridades pueden emitir órdenes contra la empresa del proveedor. Un proveedor sujeto a la legislación de EE. UU. puede almacenar su bóveda en Alemania y, aun así, recibir requerimientos legales estadounidenses.

La CLOUD Act permite a las autoridades estadounidenses exigir a los proveedores de servicios de comunicación electrónica o de computación remota sujetos a la jurisdicción de EE. UU. que entreguen los datos que posean, custodien o controlen, incluso cuando estén almacenados en el extranjero. Por tanto, un proveedor que sea una empresa estadounidense o que tenga una matriz estadounidense puede enfrentarse a este tipo de requerimientos aunque su bóveda esté en una región de la UE. Si un proveedor concreto queda sujeto a esta ley es una cuestión para su equipo legal.

El RGPD no contiene una regla general de localización de datos. Regula las transferencias a terceros países en el capítulo V (artículos 44 a 50), y el acceso remoto desde fuera del EEE, como el soporte del proveedor, puede considerarse una transferencia. Algunas normas nacionales o sectoriales añaden requisitos de localización propios, así que compruebe las que se aplican en su caso.

Transferencias fuera del EEE: Qué mecanismos se aplican

El capítulo V del RGPD exige un mecanismo de transferencia lícito y garantías que se mantengan en el país de destino. El acceso remoto de soporte desde fuera del EEE a una bóveda de contraseñas alojada dentro de él cuenta como una transferencia, por lo que la región de alojamiento por sí sola no resuelve la cuestión. Existen tres vías, y cada una se aplica a una situación distinta.

• Decisión de adecuación (artículo 45). La Comisión Europea ha determinado que la protección del país de destino es equivalente. La decisión del Marco de Privacidad de Datos UE-EE. UU. del 10 de julio de 2023 solo cubre a las empresas estadounidenses autocertificadas, así que compruebe si el proveedor figura en la lista del marco. Marcos anteriores entre la UE y EE. UU. fueron anulados por los tribunales, y el actual también ha sido impugnado, por lo que conviene mantener las cláusulas contractuales tipo como respaldo en el DPA.
• Garantías adecuadas (artículo 46). Normalmente, cláusulas contractuales tipo (SCC), modelos de contrato aprobados por la Comisión, junto con una evaluación de impacto de la transferencia (TIA). La TIA comprueba si la legislación del país de destino permite a las autoridades acceder a los datos. Se deriva de la sentencia Schrems II y de las Recomendaciones 01/2020 del Comité Europeo de Protección de Datos (CEPD).
• Excepciones (artículo 49). Excepciones limitadas, como el consentimiento explícito tras informar al interesado de los riesgos. Son adecuadas para transferencias puntuales y no amparan el tratamiento habitual por parte de un proveedor.

Alojar los datos en una región de la UE reduce el riesgo, pero no lo elimina. El personal de soporte fuera del EEE, los metadatos tratados en otro lugar y una matriz fuera del EEE con acceso pueden, cada uno, generar una transferencia. La capacidad de una autoridad extranjera para ordenar a una matriz que divulgue datos es un riesgo de jurisdicción distinto (véase el apartado de residencia anterior). Trate la región como un factor más en su TIA, no como su conclusión.

El mapa de seis zonas de datos de credenciales

El mapa de seis zonas de datos de credenciales divide un gestor de contraseñas empresarial en seis lugares donde existen datos de credenciales. Cada zona puede estar en un país distinto y conlleva su propia obligación bajo el RGPD, por lo que comprobar solo «el servidor» deja fuera copias de las que usted es responsable.

Un gestor de contraseñas es un sistema de copias. Usted conserva algunas, el proveedor conserva otras, y los proveedores del proveedor conservan el resto. Qué copias quedan en sus manos depende del modelo de despliegue. En un despliegue autoalojado, usted es el operador de todas las zonas, por lo que cada pregunta siguiente se aplica a sus propios equipos y proveedores de alojamiento en lugar de a un proveedor externo.

Cada zona también activa una obligación distinta. Las copias de seguridad generan obligaciones de eliminación al finalizar el contrato (artículo 28(3)(g)), y los proveedores generan obligaciones que deben trasladarse a lo largo de la cadena (artículo 28(4)). Los seis apartados siguientes tratan cada zona y qué pedir.

Zona 1: Credenciales almacenadas

Las credenciales almacenadas son el contenido que guardan los usuarios: inicios de sesión, notas, archivos adjuntos y los secretos que hay detrás de los códigos de un solo uso. Con el cifrado del lado del cliente, llegan al servidor como texto cifrado, datos ilegibles sin la clave. Una copia robada de la base de datos solo expone entonces secretos ilegibles, siempre que la clave que desbloquea la clave privada cifrada permanezca en el dispositivo del usuario (véase la zona 2).

Las credenciales cifradas siguen siendo datos personales cuando se refieren a una persona identificable, por lo que la zona 1 sigue dentro del ámbito de aplicación. El artículo 32(1)(a) cita el cifrado como ejemplo de medida adecuada, y reduce el riesgo. En la entrada de su RoPA para el gestor de contraseñas, anote la ubicación de esta zona y el método de cifrado.

Los nombres de los registros, la estructura de carpetas y los metadatos de auditoría se almacenan por separado y pertenecen a la zona 3. Asígneles su propia línea en el RoPA con la misma ubicación y los mismos detalles de acceso.

Zona 2: Material de claves

El material de claves es el conjunto de claves criptográficas que desbloquean las credenciales almacenadas. Quien posea las claves puede leer los datos, estén donde estén el texto cifrado, por lo que la ubicación de las claves y quién las posee importan tanto como la ubicación del servidor. El artículo 32(1)(a) solo considera el cifrado una medida adecuada cuando las claves se controlan con el mismo cuidado que los datos. 

La cadena recorre la contraseña maestra, la clave maestra, la clave privada, las claves de bóveda y las claves de registro. La contraseña maestra del usuario deriva la clave maestra mediante una función como PBKDF2, que ralentiza los intentos de adivinar la contraseña. Esa clave descifra una clave privada, que descifra las claves de bóveda, las cuales a su vez desbloquean las claves de cada registro.

El servidor almacena la clave privada y las claves de bóveda en forma cifrada. La clave que las descifra permanece en el dispositivo del usuario, por lo que una copia de la base de datos por sí sola no concede acceso.

La recuperación es la única vía de claves que merece un mapeo aparte. Algunos diseños incluyen una cuenta de recuperación o una clave en depósito para que una organización pueda restaurar el acceso tras perder la contraseña maestra. Quien posea esa clave también puede acceder al texto en claro, así que trátela como cualquier otra clave: quién la posee, dónde se almacena y qué tribunales pueden obligar a revelarla a quien la posee. Nuestra guía sobre qué protege y qué no protege el cifrado de conocimiento cero explica el mecanismo.

Zona 3: Datos de servicio

Los datos de servicio son todo lo que el sistema registra sobre el uso, no sobre el contenido. El cifrado del lado del cliente no los cubre, por lo que el operador normalmente puede leerlos. Esto los convierte en datos personales por derecho propio y en la parte del sistema a la que puede llegar un requerimiento legal sin tocar el cifrado. Suele incluir:

• Identidades de cuenta, direcciones de correo electrónico y registros de facturación
• Direcciones IP de inicio de sesión, identificadores de dispositivo y marcas de tiempo de acceso
• Registros de auditoría, además de los nombres de los registros y la estructura de carpetas si el producto no los cifra

Se aplican tres obligaciones. Los registros son su evidencia para valorar una vulneración (artículos 32 y 33). La conservación debe limitarse a lo que necesite (artículo 5(1)(e)). Los empleados pueden solicitar sus propios datos (artículo 15). En un despliegue autoalojado, usted mismo gestiona esta zona.

Zona 4: Copias de seguridad, réplicas y recuperación ante desastres

Las copias de seguridad, las réplicas y los sitios de recuperación ante desastres (DR) son las copias de datos de credenciales que existen fuera del servidor principal. Cada copia puede estar en un país distinto y bajo un operador distinto, por lo que cada una necesita su propia respuesta sobre ubicación, cifrado y eliminación.

Las copias de seguridad son copias almacenadas para restaurar datos. Las réplicas son copias activas en otros servidores. Los sitios de recuperación ante desastres (DR) son ubicaciones en espera. Respaldan la disponibilidad y la recuperación (artículo 32(1)(b) y (c)), pero cada copia adicional amplía la superficie de ataque y el conjunto de jurisdicciones aplicables. Pregunte tres cosas:

• ¿Dónde se almacena cada copia de seguridad y cada réplica, y sale alguna copia de la UE o del EEE? Una copia en un tercer país puede contar como una transferencia conforme al capítulo V.
• ¿Las copias de seguridad están cifradas, y las claves se mantienen separadas de los datos?
• Una vez finalizado el contrato, ¿cuántos días tardan en desaparecer todas las copias, y cómo lo verifica?

El artículo 28(3)(g) exige que el encargado del tratamiento, a elección del responsable, elimine o devuelva todos los datos personales cuando finalicen los servicios, y que elimine las copias existentes salvo que la ley exija su conservación. Las copias de seguridad quedan sujetas a esta obligación. En la práctica, suelen caducar en un ciclo de rotación, por lo que el plazo de conservación es el dato que conviene obtener por escrito.

Zona 5: Cachés de los clientes y almacenes sin conexión

Algunos datos salen del servidor por diseño. Las aplicaciones de escritorio y móviles pueden conservar copias sin conexión, las extensiones del navegador pueden conservar una sesión o una clave de desbloqueo, y los usuarios pueden exportar archivos de la bóveda. Cada una es una copia fuera de sus controles centrales que viaja allí donde va el dispositivo del empleado.

Esta es la zona donde más importa su propia política. Decida si se permite el modo sin conexión, exija el cifrado de disco mediante la gestión de dispositivos móviles (MDM), y restrinja quién puede exportar. Trate las exportaciones con el máximo cuidado, ya que un archivo CSV es legible por cualquiera que lo abra. Pregunte al proveedor si los administradores pueden limitar el modo sin conexión por rol, si los datos en caché se borran automáticamente tras un periodo determinado, y si el uso sin conexión y las exportaciones quedan registrados.

Un dispositivo perdido con una copia de la bóveda es un riesgo conforme al artículo 32(2), que menciona la pérdida y la divulgación no autorizada, y puede activar las obligaciones de notificación de vulneraciones de los artículos 33 y 34. Enumere los endpoints y las ubicaciones de exportación aprobadas en su RoPA.

Zona 6: Subencargados y acceso de soporte

Los subencargados son los proveedores que utiliza un proveedor para prestar el servicio, como el alojamiento, el envío de correo electrónico, la monitorización y las herramientas de soporte. Conforme a los artículos 28(2) y 28(4), el encargado del tratamiento necesita su autorización para contratarlos y debe trasladar las mismas obligaciones de protección de datos a lo largo de la cadena.

Los terceros estuvieron implicados en el 48 % de las vulneraciones registradas en el DBIR 2026 de Verizon, un aumento del 60 % respecto al año anterior. El informe agrupa estos casos en tres arquetipos: un proveedor en su cadena de suministro de software, un proveedor que aloja sus datos en su propio entorno y un proveedor con una conexión a su entorno. Un gestor de contraseñas alojado es del segundo tipo, y un enlace de soporte o integración con sus sistemas puede convertirlo en el tercero. Revise a los proveedores del proveedor con la misma atención que su producto.

Pida cuatro cosas:

• Una lista actualizada de subencargados y el país en el que opera cada uno
• Aviso previo de los cambios, con derecho a oponerse
• Quién del equipo de soporte del proveedor puede ver datos de servicio (zona 3), y bajo qué autorización
• Si algún subencargado o canal de soporte puede acceder al material de claves (zona 2)

Mapa de zonas a artículos: La obligación y la evidencia

El mapa de zonas a artículos vincula cada una de las seis zonas de credenciales con la disposición del RGPD que activa, el documento que demuestra el cumplimiento y la parte responsable de aportarlo. Utilícelo como esqueleto para la entrada de su RoPA sobre el gestor de contraseñas, y complete la columna de evidencias antes de que un auditor la solicite. El paquete de evidencias del final enumera los mismos documentos como lista de verificación.

Este reparto decide quién notifica. Conforme al artículo 33, el responsable notifica a la autoridad de control en un plazo de 72 horas desde que tiene conocimiento de la vulneración, siempre que sea posible. El encargado debe informarle «sin dilación indebida», una expresión que no fija un número, así que conviene recoger un plazo de notificación en el DPA. Cuando aloja el sistema usted mismo, es a la vez responsable y operador, y la columna de responsable se reduce a sus propios equipos.

El DPA que necesita de un proveedor de gestores de contraseñas

Un acuerdo de tratamiento de datos (DPA) es el contrato que exige el artículo 28(3) entre un responsable y un encargado del tratamiento. En el caso de un proveedor de gestores de contraseñas, debe especificar el objeto, la duración, la naturaleza, la finalidad, los tipos de datos y las categorías de interesados, además de ocho obligaciones recogidas en los puntos (a) a (h). Las Directrices 07/2020 del CEPD sobre responsables y encargados explican cada una.

La fila de auditorías es la que exige una lectura más atenta. El artículo 28(3)(h) exige que el contrato le facilite la información que demuestre el cumplimiento y permita auditorías, incluidas inspecciones. Si el proveedor no abre su infraestructura a una inspección in situ, el contrato debería indicar qué la sustituye.

La evidencia que revisa entonces incluye la lista de subencargados, una evaluación de transferencia y los informes de auditoría a los que el contrato le da derecho. Añada sus propios registros de la bóveda, exportados a un SIEM (sistema de gestión de eventos e información de seguridad).

Modelos de despliegue para una gestión de contraseñas conforme al RGPD

Su modelo de despliegue decide cuáles de las seis zonas controla su equipo. Una nube del proveedor deja la mayoría de las zonas en manos del proveedor, una nube en región de la UE reduce dónde se ubican, y el autoalojamiento las traslada a su infraestructura y a su lista de obligaciones. Los entornos aislados (air-gapped) van más allá y añaden la gestión de actualizaciones y registros sin conexión.

Un servicio gestionado por el proveedor le da menos control sobre los formatos de exportación y los plazos de salida. Antes de firmar, compruebe cómo saldría: qué formatos puede exportar y el plazo para eliminar las copias de seguridad conforme al artículo 28(3)(g).

Autoalojamiento y RGPD: Qué obligaciones asume

El autoalojamiento traslada las obligaciones del RGPD de un contrato con un proveedor a sus propios procedimientos operativos. Usted controla dónde se ubica cada zona y quién la opera, lo que puede eliminar la relación de encargado del tratamiento para la propia bóveda. Usted también se convierte en el operador, por lo que es usted quien aporta la evidencia. Nuestra página sobre el gestor de contraseñas on-premise trata esta opción de despliegue.

Lo que gana:

• Control sobre dónde se ubica cada zona, incluidas las copias de seguridad
• Ninguna transferencia a un proveedor ni cadena de subencargados para la propia bóveda

Lo que ahora debe:

• Ubicaciones de las copias de seguridad y réplicas, restauraciones probadas y un calendario de conservación
• Procedimientos de recuperación de claves, aplicación de parches y alta disponibilidad
• Un registro actualizado de actividades de tratamiento (artículo 30)
• Su propio proceso de detección y notificación de vulneraciones (artículo 33)

Ejemplo hipotético: un equipo restaura una bóveda tras una caída del servidor y descubre que la tarea de copia de seguridad nocturna llevaba tiempo escribiendo en un almacenamiento situado en un segundo país, configurado años antes por alguien que ya no está en la empresa. La bóveda estaba on-premises, pero una copia nunca lo estuvo. Esa copia plantea una cuestión de transferencia conforme al capítulo V. Una revisión zona por zona la detecta antes de que lo haga un incidente.

El riesgo interno sigue siendo suyo. El cifrado del lado del cliente significa que los administradores no pueden leer el contenido de la bóveda, pero sí pueden eliminar datos, copiar texto cifrado y copias de seguridad, cambiar la configuración o modificar registros. Separe funciones y registre las acciones de los administradores.

Los despliegues aislados (air-gapped) añaden otra obligación. Sin conexión a internet, usted aplica las actualizaciones y traslada los registros manualmente. El aislamiento no elimina las vulnerabilidades, y el soporte físico que introduce se convierte en la vía por la que una actualización llega al sistema.

El artículo 32(1) exige medidas proporcionales al riesgo. Documente quién aprueba un paquete de actualización, cómo verifica su integridad antes de importarlo, con qué frecuencia salen los registros de la red y quién gestiona el soporte físico. Pruebe también el procedimiento de restauración, ya que el 32(1)(c) y (d) cubren la restauración de la disponibilidad y las pruebas periódicas de sus medidas.

Cómo gestiona Passwork la ubicación de los datos y el acceso

Passwork Self-hosted funciona sobre infraestructura que usted controla: servidores on-premises, una nube privada o una red aislada. La bóveda, las claves y las copias de seguridad se ubican donde usted las ponga, de modo que su equipo decide dónde vive cada zona. Las respuestas siguientes siguen las seis zonas y las preguntas planteadas más arriba.

Passwork se instala con Docker en Linux (la vía recomendada), con un script de PowerShell en Windows Server, o manualmente, y los paquetes sin conexión cubren las redes aisladas. Las guías técnicas de Passwork explican cada vía.

Contenido de la bóveda y claves (zonas 1 y 2). Los datos se cifran en el cliente con AES-256, por lo que el servidor solo almacena texto cifrado y material de claves cifrado. La clave maestra se deriva con PBKDF2 y nunca sale del dispositivo del usuario en texto claro. Una segunda capa independiente de AES-256 protege la base de datos en el servidor.

La arquitectura de conocimiento cero decide quién puede leer los datos: solo los usuarios que poseen las claves, de modo que tampoco sus propios administradores pueden leer el contenido de la bóveda. La recuperación se realiza mediante una cuenta de recuperación preconfigurada cuya contraseña maestra usted almacena fuera de línea, y usted decide quién la posee.

Datos de servicio (zona 3). El registro de actividad recoge las acciones de usuarios, administradores y del sistema, y sus pistas de auditoría están listas para integrarse con un SIEM. Los nombres de registros y carpetas, la estructura de acceso y los metadatos de auditoría residen en el servidor, así que incorpórelos a su RoPA. Usted define la política de conservación y mantiene los registros en su propio almacenamiento.

Copias de seguridad y réplicas (zona 4). Los conjuntos de réplicas de MongoDB con tres o más miembros votantes, junto con servidores de aplicación escalados horizontalmente, dan al servicio tolerancia a fallos para más de 10 000 usuarios. Tareas programadas en segundo plano crean y rotan los archivos de copia de seguridad, y usted elige dónde se almacenan.

Cachés de los clientes y almacenes sin conexión (zona 5). El modo sin conexión es de solo lectura y debe activarse voluntariamente en dos niveles: el usuario marca un registro y, después, activa el modo sin conexión en un dispositivo concreto. Los administradores controlan qué roles pueden usarlo, el número máximo de registros por dispositivo y el tiempo máximo sin sincronizar antes de un borrado automático. Las descargas y visualizaciones sin conexión se sincronizan con el registro de actividad y el panel de seguridad cuando el dispositivo vuelve a conectarse. 

Subencargados (zona 6). Un despliegue autoalojado no tiene ningún subencargado alojado por un proveedor. Su lista de proveedores se limita a sus propios proveedores de alojamiento y de copias de seguridad, y se les aplican las mismas preguntas anteriores. Un proveedor de nube privada que opere la bóveda por usted es su encargado del tratamiento y necesita su propio DPA.

El acceso sigue el principio de mínimo privilegio. El control de acceso basado en roles (RBAC) define los niveles de acceso para bóvedas y carpetas, la sincronización de grupos de LDAP y Active Directory traslada los cambios del directorio a Passwork, y el SSO mediante SAML gestiona el inicio de sesión. Passwork está certificado según ISO 27001, se somete a pruebas a través de HackerOne, y su código fuente está disponible para auditoría independiente.

Paquete de evidencias del RGPD para la gestión de contraseñas

El paquete de evidencias de 8 puntos es el conjunto de documentos que debería tener antes de una auditoría del RGPD de su gestor de contraseñas. Cubre los registros de tratamiento, las condiciones del proveedor, las evaluaciones de transferencia, las ubicaciones de las copias de seguridad, las revisiones de acceso y los procedimientos ante vulneraciones. Los puntos 1 a 6 corresponden a zonas individuales, mientras que los puntos 7 y 8 cubren el acceso y la gestión de vulneraciones en todas ellas.

• Entrada del registro de actividades de tratamiento del gestor de contraseñas, con las seis zonas (artículo 30)
• DPA firmado que cubra las condiciones del artículo 28(3), si un proveedor o proveedor de alojamiento trata alguna zona
• Lista actualizada de subencargados y la cláusula de aviso de cambios, en la misma condición
• Evaluación de impacto de la transferencia, si alguna zona afecta a un tercer país (capítulo V)
• Evaluación de impacto relativa a la protección de datos, si su revisión de riesgos la exige (artículo 35)
• Mapa de copias de seguridad y réplicas con ubicaciones y condiciones de eliminación
• Revisión de accesos de los permisos de la bóveda, realizada a partir de exportaciones del registro de auditoría
• Un procedimiento de vulneraciones de 72 horas que indique quién decide y quién notifica (artículo 33)

El RGPD no fija un intervalo concreto para las revisiones de acceso. Una cadencia trimestral es habitual, así que establezca una que se ajuste a su riesgo y documéntela.

El registro de auditoría es la evidencia que respalda los puntos 7 y 8. Muestra quién accedió a cada credencial y cuándo, lo que ayuda a delimitar el alcance de una vulneración y a valorar si pueden verse afectados datos personales. Expórtelo a su SIEM para que sobreviva a la bóveda y alimente el registro de vulneraciones que exige el artículo 33(5).

Por dónde empezar con la gestión de contraseñas conforme al RGPD

Una gestión de contraseñas conforme al RGPD empieza por hacer coincidir el despliegue con los datos que no puede permitir que salgan de su jurisdicción. Después, mantenga un contrato o un registro para cada zona que gestione un proveedor: dónde se ubican el contenido, las claves, los datos de servicio, las copias de seguridad, las cachés y los subencargados, y qué lo cubre a cada uno.

Empiece con una sola página. Dibuje las seis zonas de su gestor de contraseñas actual y marque las que no puede responder. Esas son sus primeras preguntas para el proveedor, o sus primeras tareas internas si se autoaloja. Una vez completo el mapa, la guía de seguridad de contraseñas del RGPD cubre la siguiente capa: normas de contraseñas y prácticas del personal.

Preguntas frecuentes

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

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

PassworkPasswork Team

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

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

PassworkPasswork Team

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

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

PassworkAlex Muntyan

The General Data Protection Regulation (GDPR), the EU's data protection law, requires a lawful transfer mechanism for sending personal data outside the European Economic Area (EEA, the EU plus Iceland, Liechtenstein and Norway), and security measures that fit the risk. For GDPR-compliant password management, know every place your credential data exists and hold proof for each one.

Your credentials can be stored in a Frankfurt data centre and still fall under a foreign court order if the provider is subject to a non-EU jurisdiction. An "EU hosted" label also says nothing about where the backups are. This article introduces the six-zone credential data map: the places where an enterprise password manager keeps data, the GDPR article each place triggers, and the evidence you need to hold. It ends with an 8-point evidence pack you can check before an audit.

What GDPR-compliant password management requires

GDPR requires personal data to be processed securely, built with data protection from the start, and protected by measures that fit the risk. 

GDPR-compliant password management means you can show that credential data is encrypted, reachable only by people who need it, logged, and covered by the right contracts and records wherever it is stored.

The law sets the outcome (Articles 5(1)(f), 25 and 32). You choose the controls and prove they work (Article 5(2)). In practice, that breaks down into five requirements:

• Encrypt stored credentials. Article 32(1)(a) names "the pseudonymisation and encryption of personal data" as an appropriate measure.
• Limit access by role (RBAC). Each person signs in under their own account and sees only what their job needs, even when the credential they open is shared. This is data protection by design (Article 25) applied to access.
• Keep the service available and tested. Article 32(1)(b) to (d) covers resilience, restoring access after an incident and regular testing of your measures.
• Record who opened what. An access log shows which credentials were reached and when. It is the evidence you need to judge whether a breach affected personal data (Article 33).
• Document every place the data lives. That means a record of processing, a contract with each outside party that handles the data, and a lawful mechanism for any transfer outside the EEA.

These duties reach passwords for two reasons. A credential record normally names an employee or links to one, which makes it personal data (Article 4(1): any information relating to an identifiable person). The credentials also open other systems, such as HR, CRM and customer databases, where personal data is stored. Article 32(2) requires you to assess the risk of unauthorised access to personal data, so a breach of the password manager is a breach path into every system it unlocks. Encryption lowers the risk without taking the record out of scope. 

Your organisation is the controller for the vault, the party that decides why and how the credential data is used. A vendor or hosting provider that runs or supports it on your instructions is a processor, and Article 28 requires a contract with it. Article 30 requires you to keep a record of processing activities (RoPA) that lists the recipients, locations and transfers for this processing. Finding those locations is the first job.

Residency, sovereignty and jurisdiction are three different things

Data residency is where your data is physically stored. Data sovereignty means the data is subject to the laws and legal control of a chosen country. Jurisdiction is which courts and authorities can issue orders to the vendor's company. A vendor subject to US law can store your vault in Germany and still receive US legal demands.

The CLOUD Act lets US authorities require providers of electronic communication or remote computing services under US jurisdiction to hand over data in their possession, custody or control, even when it is stored abroad. A vendor that is a US company or has a US parent may therefore face such demands while your vault sits in an EU region. Whether a given vendor falls within the statute is a question for your legal team.

GDPR contains no general data-localisation rule. It regulates transfers to third countries in Chapter V (Articles 44 to 50), and remote access from outside the EEA, such as vendor support, can count as a transfer. Some national and sector rules add localisation requirements of their own, so check the ones that apply to you.

Transfers outside the EEA: Which mechanisms apply

Chapter V of GDPR requires a lawful transfer mechanism and safeguards that hold in the destination country. Remote support access from outside the EEA to a password vault hosted inside it counts as a transfer, so a hosting region alone does not settle the question. Three routes exist, and each applies in a different situation.

• Adequacy decision (Article 45). The European Commission has ruled that the destination country's protection is equivalent. The EU-US Data Privacy Framework decision of 10 July 2023 covers only US companies that have self-certified, so check the vendor's entry on the framework list. Earlier EU-US frameworks were struck down in court, and the current one has been challenged, so keep standard contractual clauses as a fallback in the DPA.
• Appropriate safeguards (Article 46). Usually standard contractual clauses (SCCs), model contract terms approved by the Commission, plus a transfer impact assessment (TIA). The TIA checks whether the destination country's law lets authorities access the data. It follows from the Schrems II ruling and the EDPB's Recommendations 01/2020.
• Derogations (Article 49). Narrow exceptions, such as explicit consent after the individual is told of the risks. They suit occasional transfers and do not support routine vendor processing.

An EU hosting region lowers risk without removing it. Support staff outside the EEA, metadata handled elsewhere and a non-EEA parent company with access can each create a transfer. A foreign authority's power to order a parent to disclose data is a separate jurisdiction risk (see the residency section above). Treat the region as one input to your TIA, not as its conclusion.

The six-zone credential data map

The six-zone credential data map splits an enterprise password manager into six places where credential data exists. Each zone can sit in a different country and carries its own GDPR duty, so checking only "the server" misses copies you are responsible for.

A password manager is a system of copies. You hold some of them, the vendor holds others, and the vendor's suppliers hold the rest. Which copies sit with you depends on the deployment model. In a self-hosted deployment you are the operator of every zone, so each question below applies to your own teams and hosting providers instead of a vendor.

Each zone also triggers a different duty. Backups raise deletion duties at contract end (Article 28(3)(g)), and suppliers raise duties that must pass down the chain (Article 28(4)). The next six subsections cover each zone and what to ask for.

Zone 1: Stored credentials

Stored credentials are the content users store: logins, notes, attachments and the secrets behind one-time codes. With client-side encryption, it reaches the server as ciphertext, data that is unreadable without the key. A stolen copy of the database then exposes only unreadable secrets, provided the key that unwraps the encrypted private key stays on the user's device (see Zone 2).

Encrypted credentials are still personal data when they relate to an identifiable person, so Zone 1 stays in scope. Article 32(1)(a) lists encryption as an example of an appropriate measure, and it lowers the risk. In your RoPA entry for the password manager, record this zone's location and encryption method.

Record names, folder structure and audit metadata are stored separately and belong to Zone 3. Give them their own RoPA line with the same location and access details.

Zone 2: Key material

Key material is the set of cryptographic keys that unlock stored credentials. Whoever holds the keys can read the data, wherever the ciphertext sits, so key location and key holders matter as much as server location. Article 32(1)(a) makes encryption appropriate only when the keys are controlled as carefully as the data. 

The chain runs master password, master key, private key, vault keys, record keys. The user's master password derives the master key through a function such as PBKDF2, which makes password guessing slow. That key decrypts a private key, which decrypts vault keys, which in turn unlock the keys of individual records.

The server stores the private key and vault keys in encrypted form. The key that decrypts them stays on the user's device, so a copy of the database alone does not give access.

Recovery is the one key path worth mapping separately. Some designs include a recovery account or escrow key so an organisation can restore access after a lost master password. Whoever holds that key can also reach plaintext, so treat it like any other key: who holds it, where it is stored, and which courts can compel its holder. Our guide to what zero-knowledge encryption does and does not protect explains the mechanics.

Zone 3: Service data

Service data is everything the system records about use rather than content. Client-side encryption does not cover it, so the operator can usually read it. That makes it personal data in its own right and the part of the system a legal demand can reach without touching the encryption. It typically includes:

• Account identities, email addresses and billing records
• Sign-in IP addresses, device identifiers and access timestamps
• Audit logs, plus record names and folder structure if the product does not encrypt them

Three duties apply. Logs are your evidence for judging a breach (Articles 32 and 33). Retention must be limited to what you need (Article 5(1)(e)). Employees can request their own data (Article 15). In a self-hosted deployment, you hold this zone yourself.

Zone 4: Backups, replicas and disaster recovery

Backups, replicas and disaster recovery (DR) sites are the copies of credential data that live outside the primary server. Each copy can sit in a different country and under a different operator, so each needs its own answer on location, encryption and deletion.

Backups are stored copies for restoring data. Replicas are live copies on other servers. Disaster recovery (DR) sites are standby locations. They support availability and recovery (Article 32(1)(b) and (c)), but every extra copy widens the attack surface and the set of jurisdictions that apply. Ask three things:

• Where is each backup and replica stored, and does any copy leave the EU or EEA? A copy in a third country can count as a transfer under Chapter V.
• Are backups encrypted, and are the keys kept apart from the data?
• After the contract ends, how many days until the last copy is gone, and how do you verify it?

Article 28(3)(g) requires the processor, at your choice, to delete or return all personal data when the services end, and to delete existing copies unless the law requires storage. Backups fall under that duty. In practice they often expire on a rotation cycle, so the retention window is the figure to get in writing.

Zone 5: Client caches and offline stores

Some data leaves the server by design. Desktop and mobile apps may keep offline copies, browser extensions may keep a session or unlock key, and users can export vault files. Each is a copy outside your central controls and travels wherever the employee's device does.

This is the zone where your own policy matters most. Decide whether offline mode is allowed, require disk encryption through mobile device management (MDM), and restrict who can export. Treat exports with the most care, since a CSV file is readable by anyone who opens it. Ask the vendor whether administrators can limit offline mode by role, whether cached data wipes itself after a set period, and whether offline use and exports are logged.

A lost device with a vault copy is a risk under Article 32(2), which names loss and unauthorised disclosure, and may trigger the breach-notification duties in Articles 33 and 34. List endpoints and approved export locations in your RoPA.

Zone 6: Sub-processor and support access

Sub-processors are the suppliers a vendor uses to deliver the service, such as hosting, email delivery, monitoring and support tooling. Under Article 28(2) and 28(4), the processor needs your authorisation to engage them and must pass the same data protection duties down the chain.

Third parties were involved in 48% of breaches in Verizon's 2026 DBIR, a 60% rise on the previous year. The report groups these cases into three archetypes: a vendor in your software supply chain, a vendor hosting your data in its environment, and a vendor with a connection to your environment. A hosted password manager is the second kind, and a support or integration link into your systems can make it the third. Check the vendor's suppliers as closely as its product.

Ask for four things:

• A current list of sub-processors and the country each operates in
• Advance notice of changes, with a right to object
• Who on the vendor's support team can see service data (Zone 3), and under what approval
• Whether any sub-processor or support route can touch key material (Zone 2)

Zone-to-article map: The obligation and the evidence

The zone-to-article map pairs each of the six credential zones with the GDPR provision it triggers, the document that proves compliance, and the party who owns it. Use it as the skeleton for your RoPA entry on the password manager, and fill the evidence column before an auditor asks. The evidence pack at the end lists the same documents as a checklist.

The split decides who notifies. Under Article 33, the controller notifies the supervisory authority within 72 hours of becoming aware of a breach, where feasible. The processor must tell you "without undue delay", which sets no number, so write a notification window into the DPA. When you self-host, you are both controller and operator, and the Owner column collapses to your own teams.

The DPA you need from a password manager vendor

A data processing agreement (DPA) is the contract that Article 28(3) requires between a controller and a processor. For a password manager vendor, it must state the subject matter, duration, nature, purpose, data types and data subject categories, plus eight obligations in points (a) to (h). The EDPB Guidelines 07/2020 on controllers and processors explain each one.

The audit row needs the closest reading. Article 28(3)(h) requires the contract to give you the information that proves compliance and to allow audits, including inspections. If the vendor won't open its infrastructure to on-site inspection, the contract should state what replaces it.

The evidence you review then includes the sub-processor list, a transfer assessment and the audit reports the contract entitles you to. Add your own vault logs, exported to a SIEM (a system that collects and analyses security logs).

Deployment models for GDPR-compliant password management

Your deployment model decides which of the six zones your team controls. A vendor cloud leaves most zones with the vendor, an EU-region cloud narrows where they sit, and self-hosting moves them onto your infrastructure and your duties list. Air-gapped setups go furthest and add offline update and log handling.

A vendor-managed service gives you less control over export formats and exit timing. Before you sign, check how you would leave: which formats you can export, and the deadline for deleting backups under Article 28(3)(g).

Self-hosting and GDPR: Which duties you take on

Self-hosting moves GDPR duties from a vendor contract into your own operating procedures. You control where every zone sits and who operates it, which can remove the processor relationship for the vault itself. You also become the operator, so you carry the evidence yourself. Our on-premise password manager page covers the deployment option.

What you gain:

• Control over where every zone sits, including backups
• No transfer to a vendor and no sub-processor chain for the vault itself

What you now owe:

• Backup and replica locations, tested restores and a retention schedule
• Key recovery procedures, patching and high availability
• An updated record of processing activities (Article 30)
• Your own breach detection and notification process (Article 33)

Hypothetical example: a team restores a vault after a server crash and finds that the nightly backup job has been writing to storage in a second country, set up years earlier by someone who has since left. The vault was on-premises, but one copy never was. That copy is a transfer question under Chapter V. A zone-by-zone check finds it before an incident does.

Insider risk stays with you. Client-side encryption means administrators can't read vault contents, but they can still delete data, copy ciphertext and backups, change configuration or edit logs. Separate duties and log administrator actions.

Air-gapped deployments add another duty. With no internet connection, you apply updates and move logs manually. Isolation doesn't remove vulnerabilities, and the media you carry in becomes the way an update reaches the system.

Article 32(1) requires measures appropriate to the risk. Document who approves an update package, how you verify its integrity before import, how often logs leave the network and who handles the media. Test the restore procedure too, since 32(1)(c) and (d) cover restoring availability and regularly testing your measures.

How Passwork handles data location and access

Passwork self-hosted runs on infrastructure you control: on-premises servers, a private cloud or an air-gapped network. The vault, the keys and the backups sit where you put them, so your team decides where each zone lives. The answers below follow the six zones and the questions asked above.

Passwork installs with Docker on Linux (the recommended path), with a PowerShell script on Windows Server, or manually, and offline packages cover air-gapped networks. The Passwork tech guides cover each route.

Vault payload and keys (zones 1 and 2). Data is encrypted on the client with AES-256, so the server stores only ciphertext and encrypted key material. The master key is derived with PBKDF2 and never leaves the user's device in plaintext. A second, independent AES-256 layer protects the database on the server.

Zero-knowledge architecture decides who can read the data: only the users who hold the keys, so your own administrators can't read vault contents either. Recovery runs through a pre-provisioned recovery account whose master password you store offline, and you decide who holds it.

Service data (zone 3). The Activity Log records user, admin and system actions, and its audit trails are ready for SIEM integration. Record and folder names, access structure and audit metadata sit on the server, so list them in your RoPA. You set the retention policy and keep the logs on your own storage.

Backups and replicas (zone 4). MongoDB replica sets with three or more voting members, together with horizontally scaled application servers, give the service fault tolerance for 10,000+ users. Scheduled background tasks create and rotate backup archives, and you choose where they are stored.

Client caches and offline stores (zone 5). Offline mode is read-only and opt-in at two levels: the user marks a record, then enables offline on a specific device. Administrators control which roles may use it, the maximum records per device and the maximum unsynced time before an automatic wipe. Offline downloads and views sync to the Activity Log and the Security Dashboard when the device reconnects. 

Sub-processors (zone 6). A self-hosted deployment has no vendor-hosted sub-processor. Your supplier list is limited to your own hosting and backup providers, and the same questions above apply to them. A private-cloud host that runs the vault for you is your processor and needs its own DPA.

Access follows least privilege. Role-based access control (RBAC) sets access levels for vaults and folders, LDAP and Active Directory group sync carries directory changes into Passwork, and SAML SSO handles sign-in. Passwork is ISO 27001 certified, tested through HackerOne, and its source code is available for independent audit.

GDPR evidence pack for password management

The 8-point evidence pack is the set of documents you should hold before a GDPR audit of your password manager. It covers processing records, vendor terms, transfer assessments, backup locations, access reviews and breach procedures. Items 1 to 6 map to individual zones, while items 7 and 8 cover access and breach handling across all of them.

• Record of processing activities entry for the password manager, listing all six zones (Article 30)
• Signed DPA covering the Article 28(3) terms, if a vendor or hosting provider processes any zone
• Current sub-processor list and the change-notice clause, under the same condition
• Transfer impact assessment, if any zone touches a third country (Chapter V)
• Data protection impact assessment, if your risk review requires one (Article 35)
• Backup and replica map with locations and deletion terms
• Access review of vault permissions, run from audit log exports
• A 72-hour breach procedure that names who decides and who notifies (Article 33)

GDPR sets no fixed interval for access reviews. Quarterly is a common cadence, so set one that matches your risk and document it.

The audit log is the evidence behind items 7 and 8. It shows who accessed which credential and when, which helps you scope a breach and judge whether personal data may be affected. Export it to your SIEM so it outlives the vault and feeds the breach record required by Article 33(5).

Where to start with GDPR-compliant password management

GDPR-compliant password management starts with matching the deployment to the data you cannot let leave your jurisdiction. Then hold a contract or record for every zone a vendor handles: where the payload, keys, service data, backups, caches and sub-processors sit, and what covers each.

Start with a single page. Draw the six zones for your current password manager and mark the ones you cannot answer. Those are your first vendor questions, or your first internal tasks if you self-host. Once the map is complete, the GDPR password security guide covers the next layer: password rules and staff practice.

Frequently asked questions

Data sovereignty and password management: Keeping credentials where they belong

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

PassworkPasswork Team

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

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

PassworkPasswork Team

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

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

PassworkAlex Muntyan

A gestão do ciclo de vida de identidades académicas rege o acesso de uma pessoa à medida que muda a sua situação como estudante, docente, investigador ou colaborador. No ensino superior, funciona melhor em três percursos: para estudantes, para docentes e instrutores e para pessoal não docente. Cada percurso tem os seus próprios desencadeadores e aprovações, unidos num único registo de identidade.

Um estudante que conclui o curso, um docente convidado cujo período letivo terminou e um colaborador que se demite desencadeiam, muitas vezes, o mesmo pedido de saída, embora cada um deva perder acessos diferentes em datas diferentes. Este guia apresenta uma matriz de ciclo de vida para as três populações, regras para funções sobrepostas e uma lista de verificação de implementação a 90 dias.

Porque é que a gestão do ciclo de vida de identidades académicas exige três percursos

O ensino exige ciclos de vida de acesso separados, porque o estatuto de estudante, as nomeações docentes e o emprego do pessoal são criados e alterados por sistemas e eventos diferentes. Um único processo genérico de integração e saída tem dificuldade em conceder o acesso certo a tempo e em removê-lo quando o motivo desse acesso termina.

• O acesso de um estudante está associado à matrícula, à inscrição em unidades curriculares e à situação académica.
• O acesso de um membro do pessoal não docente está associado a uma função e a um registo laboral.
• O acesso de um docente depende frequentemente de uma nomeação e de uma atribuição letiva específica, que podem começar e terminar num calendário distinto do do registo laboral.

Este padrão costuma ser descrito como Joiner-Mover-Leaver (JML): um quadro de referência para acompanhar quando alguém entra numa organização, muda de função e acaba por sair. No ensino, «leaver» (quem sai) é a designação errada para um estudante que conclui o curso mas mantém acesso limitado como alumni, ou para um docente cuja atribuição letiva termina enquanto a nomeação continua. Um fluxo JML genérico oculta estes casos, a menos que modele eventos específicos de cada função, períodos de tolerância e afiliações sobrepostas. O modelo de três percursos fá-lo.

A mesa-redonda de 2025 da InCommon sobre práticas de identidade no ensino superior concluiu que 27 % dos inquiridos tinham mais dificuldade com políticas e normas, 23 % com o controlo de acesso baseado em funções (RBAC) e 14 % com a compreensão de como as diferentes populações percorrem os seus ciclos de vida. A sondagem não permite identificar uma causa única. Mostra, porém, que a política, a conceção de funções e a responsabilidade pelo ciclo de vida merecem tanta atenção como a escolha da tecnologia.

A matriz do ciclo de vida de acesso académico

A matriz do ciclo de vida de acesso académico (AALM) transforma a conceção do ciclo de vida em oito decisões, repetidas para cada uma das três populações: evento desencadeador, fonte de autoridade, atributos de identidade, acesso de base, acesso condicional, responsável pela aprovação, ponto de revisão e ação de fim de acesso. O preenchimento destes oito campos para estudantes, docentes e instrutores e pessoal não docente dá à instituição um documento de política utilizável, em vez de um quadro abstrato.

O guia federal de gestão do ciclo de vida de identidades descreve a criação, a modificação e a eliminação como as fases centrais para provisionar, ajustar e revogar acessos segundo o princípio do menor privilégio, ou seja, os utilizadores recebem apenas o acesso que a sua função atual exige. A AALM adapta essa lógica ao ensino, onde a «modificação» abrange uma variedade muito maior do que uma mudança de função típica numa empresa.

As três secções seguintes mostram como os mesmos campos mudam consoante a população. O acesso de base, os atributos e as fontes de autoridade variam de instituição para instituição. A matriz deve ser tratada como ponto de partida para o planeamento: convém preencher os sistemas e os responsáveis pela aprovação da própria instituição antes de considerar definitiva qualquer linha.

Gestão de acessos de estudantes, da matrícula ao estatuto de alumni

A gestão de acessos de estudantes liga os eventos do estado académico a um modelo de direitos de acesso que adiciona, ajusta ou retira acessos sem criar uma nova identidade sempre que a situação de um estudante muda. A matrícula, a interrupção, a desistência, a conclusão do curso e a passagem ao estatuto de alumni alteram, cada uma, aquilo a que o estudante pode aceder, enquanto o registo da pessoa se mantém.

A cadeia de eventos do estudante

A cadeia estende-se, normalmente, do acesso prévio à chegada, concedido a candidatos, à matrícula ou ingresso, às alterações de curso e de unidades curriculares, à interrupção de estudos, à desistência, à conclusão do curso e à passagem ao estatuto de alumni. Convém avaliar, para cada evento, se deve criar uma nova identidade, alterar o acesso existente ou desencadear uma revisão de estado. Na maioria dos casos, o registo da pessoa já existe e o evento altera o acesso em vez de criar uma segunda identidade.

Ligar o acesso aos dados académicos

O SIS ou a secretaria académica funciona habitualmente como fonte de autoridade para os atributos do estado académico e alimenta o LMS, a jusante, com os dados de inscrição em unidades curriculares. Convém documentar o modo como esses dados chegam ao LMS (integração direta, middleware ou uma camada de governação de identidades), em vez de presumir um caminho fixo. Quando o registo de um estudante não corresponde de forma limpa, por exemplo após uma alteração de nome, uma candidatura duplicada ou uma transferência de estudante com duas contas anteriores, deve encaminhar-se para uma fila de exceções. Não se deve permitir que o sistema crie silenciosamente uma segunda conta.

Proteger os registos educativos e os dados de apoio financeiro

O 34 CFR § 99.31(c) exige que as instituições utilizem métodos razoáveis para identificar e autenticar as pessoas a quem divulgam informações de identificação pessoal constantes de registos educativos. A conservação de registos de pedidos e de divulgações enquadra-se no § 99.32. Esse requisito abrange a divulgação de informações dos registos educativos. Não substitui o registo habitual de acessos ao nível da aplicação.

Quando estão em causa dados de apoio financeiro, a orientação GEN-25-08 do Departamento de Educação aborda o acesso permitido a Federal Tax Information e a dados do FAFSA por parte de instituições elegíveis. Nenhuma das fontes define uma arquitetura técnica. O departamento jurídico da instituição deve confirmar de que forma cada uma se aplica aos sistemas existentes.

O acesso de docentes e instrutores exige um ciclo de vida próprio

O acesso de docentes e instrutores exige um ciclo de vida próprio, porque o acesso para lecionar depende de uma nomeação, de uma atribuição letiva concreta e de obrigações de lançamento de notas, e não de uma data normal de início e de fim de contrato. Os docentes convidados e os docentes visitantes tornam isto evidente: o respetivo acesso ao LMS pode ter de começar antes do contrato e prolongar-se para além do período letivo.

A EDUCAUSE descreve um cenário comum: um instrutor de curta duração precisa de acesso ao LMS antes da data oficial de início para preparar uma unidade curricular e pode precisar de acesso limitado depois do fim do período letivo para concluir o lançamento de notas. Um ciclo de vida genérico de colaborador, construído em torno de uma única data de contratação e de uma única data de cessação, trata mal este padrão. As instituições precisam de uma política documentada com um período de tolerância explícito.

O direito de acesso individual de um docente ao LMS ou ao e-mail pertence ao modelo de acessos da IAM/IGA. Uma camada de gestão de credenciais é mais relevante para as contas operacionais partilhadas que a TI ou um responsável designado controla diretamente, como sistemas de laboratório ou credenciais de fornecedores.

Ciclo de vida do pessoal não docente: Eventos laborais, mudanças de função e saídas

O acesso do pessoal não docente deve seguir eventos validados de emprego e de mudança de funções, com o superior hierárquico ou o responsável de negócio relevante a confirmar qualquer acesso para além do pacote padrão da função. Os desencadeadores típicos são a contratação, a transferência, a promoção, a licença e a cessação, e cada um deve reavaliar os direitos de acesso existentes, e não apenas adicionar novos.

Um modo de falha comum é a acumulação de privilégios (privilege creep): alguém recebe novo acesso após uma promoção e ninguém remove o acesso associado à função anterior. A recertificação regular de acessos, uma revisão agendada em que o superior hierárquico confirma que o acesso de cada pessoa continua a ser necessário, deteta este problema antes de se tornar uma constatação de auditoria.

O NIST SP 1800-35 apresenta o acesso autorizado seguro como uma decisão contínua, e não como uma concessão pontual, assente numa governação de identidades reforçada em recursos distribuídos, on-premises e na nuvem. Aplicar isto ao acesso do pessoal é uma opção de conceção, e não um requisito do NIST: tratar cada mudança de função como um desencadeador para reavaliar os direitos de acesso existentes.

Uma pessoa, várias funções: Governar transições e sobreposições

Um modelo de identidade com várias funções mantém um único registo por pessoa e concede apenas o acesso justificado por cada função ativa. Isto evita contas duplicadas e permite remover o acesso associado a uma função sem alterar o acesso proveniente de outra.

Seis cenários abrangem a maioria das sobreposições com que as instituições se deparam:

• Um estudante passa a colaborador, como quando estudantes trabalhadores assumem funções a tempo parcial
• Um membro do pessoal ou do corpo docente matricula-se como estudante
• Um docente é, em simultâneo, instrutor, investigador e administrador de departamento
• Um estudante trabalhador muda de departamento ou tem dois empregos ao mesmo tempo
• Um alumnus ou reformado recebe acesso limitado e com prazo definido a um serviço específico
• Um prestador de serviços ou colaborador externo precisa de um acesso que expira automaticamente numa data definida

A regra mais importante: quando uma afiliação termina, deve remover-se apenas o acesso associado a essa afiliação. Podem ocorrer dois erros. O sistema pode retirar acesso que outra função ativa continua a justificar ou pode deixar acesso em vigor depois de a afiliação ter terminado. A correspondência fiável de identidades (confirmar que dois registos pertencem à mesma pessoa) e uma fila de revisão documentada para os casos que as regras automáticas não conseguem resolver mantêm ambos os erros sob controlo.

Construir a camada de dados e de integração antes de automatizar

A automatização funciona quando uma instituição já identificou as suas fontes de autoridade, construiu uma correspondência fiável de identidades e definiu a precedência dos dados em caso de conflito entre sistemas. Sem estes três elementos, as regras de provisionamento atuam sobre registos desatualizados ou sem correspondência e concedem acesso demasiado cedo ou deixam-no em vigor durante demasiado tempo.

Deve atribuir-se a fonte de autoridade por atributo e não por sistema. Um modelo comum atribui os atributos do estado académico ao SIS ou à secretaria académica, os atributos laborais ao RH/HCM e ao processamento salarial e os atributos de atribuição letiva a um sistema de planeamento de horários ou de assuntos académicos. A titularidade varia de campus para campus, pelo que convém documentar a autoridade e a precedência ao nível do atributo para o ambiente da própria instituição.

Algumas credenciais não têm um responsável natural em nenhum destes sistemas. Uma credencial partilhada de administração na nuvem, utilizada por três engenheiros de infraestrutura, não pertence nem aos RH nem ao SIS. Uma camada de governação e administração de identidades (IGA) pode registar que a equipa de infraestrutura é responsável por ela. O segredo propriamente dito continua a exigir um sistema concebido para armazenar, rodar e auditar credenciais partilhadas. Trata-se de um controlo distinto.

Um fluxo de eventos básico é o seguinte:

• Ocorre um evento no sistema de registo
• A correspondência de identidades confirma a que pessoa se aplica
• Uma regra de política avalia o que deve mudar
• Realiza-se uma aprovação, quando exigida
• Executa-se o provisionamento ou a revogação
• Um evento de auditoria regista o que aconteceu

Qualquer passo que falhe, como uma identidade sem correspondência ou um evento desatualizado, deve seguir para uma fila de exceções visível, com um responsável atribuído. Não deve desaparecer em silêncio.

O NIST SP 800-63-4 estabelece requisitos para a verificação de identidade, a inscrição, a gestão de autenticadores, a autenticação e a federação. É uma referência útil para a camada de identidade subjacente a esta automatização, embora não prescreva uma arquitetura para o ensino.

Aplicar controlos de acesso e evidências proporcionais ao risco

Os controlos de acesso devem corresponder à sensibilidade do recurso e à função atual da pessoa, ao passo que as evidências de auditoria devem mostrar quem aprovou o acesso, quando foi alterado e se continua justificado. Os controlos de base abrangem o princípio do menor privilégio, o controlo de acesso baseado em funções (RBAC), a MFA, o SSO, as revisões agendadas, o acesso com limite de tempo e a segregação de funções.

A segregação de funções impede que uma mesma pessoa solicite e aprove o seu próprio acesso. As regras baseadas em políticas podem acrescentar contexto que uma função, por si só, não transporta, como as datas de nomeação ou as atribuições letivas. As contas órfãs, ou seja, contas que continuam ativas depois de terminada a afiliação que as justificava, devem ser assinaladas automaticamente, em vez de serem descobertas durante uma auditoria.

As credenciais operacionais partilhadas precisam da sua própria camada. Um programa de IAM/IGA pode governar a titularidade e a revisão de uma conta de serviço partilhada, de um sistema de laboratório ou das credenciais de um portal de fornecedores, determinando quem é responsável e quando o acesso é recertificado. Não armazena, não roda nem partilha o segredo em segurança. É aí que uma camada de gestão de credenciais assume o papel.

Lista de verificação de implementação da gestão do ciclo de vida de identidades académicas: Os primeiros 90 dias

Os primeiros 90 dias devem servir para definir a política, modelar as três populações, validar os dados de origem, pilotar um número reduzido de aplicações e medir as exceções por resolver antes de a automatização se alargar. A lista de verificação abaixo segue essa ordem e termina com a revisão jurídica e de privacidade. Cada passo produz um documento ou uma métrica que o grupo de governação pode rever.

A lista de verificação de 90 dias do ciclo de vida de identidades académicas (10 pontos)

• Constitua um grupo de governação: secretaria académica, RH, assuntos académicos, IAM/TI, segurança, responsáveis pelas aplicações e apoio ao utilizador
• Defina o registo da pessoa e as regras de correspondência de identidades entre sistemas
• Mapeie os estados do ciclo de vida e os respetivos desencadeadores para estudantes, docentes/instrutores e pessoal não docente
• Atribua uma fonte de autoridade e uma regra de precedência a cada atributo-chave
• Elabore a AALM para as primeiras cinco aplicações ou serviços
• Redija as regras de aprovação, de exceção, de período de tolerância e de saída de emergência
• Pilote o provisionamento e o desprovisionamento automatizados com monitorização ativa
• Defina as métricas de referência: tempo de provisionamento, tempo de desativação, acumulação de exceções, contas dormentes, acessos temporários em atraso e taxa de conclusão das revisões
• Realize exercícios de simulação (tabletop) para cenários de várias funções e de fim de período letivo antes da entrada em produção
• Peça aos responsáveis jurídicos e de privacidade que revejam a política antes de a aplicar em larga escala

A InCommon recomenda a mesma sequência: definir as necessidades locais do ciclo de vida, mapeá-las visualmente, estabelecer a governação, melhorar a qualidade dos dados de origem, planear as exceções e documentar as decisões.

Conclusão

O ciclo de vida de identidades académicas deve ser tratado primeiro como um problema de política e só depois como um problema de ferramentas. Três fluxos de eventos, três responsáveis, um único registo por pessoa: é isto que permite remover o acesso ao laboratório de um estudante que concluiu o curso sem afetar o emprego que passou a ter na secretaria académica.

Passo seguinte: reunir o grupo de governação e acordar as primeiras cinco aplicações a mapear, ordenadas pela sensibilidade dos dados que contêm.

Perguntas frequentes

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

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

PassworkPasswork Team

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

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

Passwork BlogAlex Muntyan

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

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

PassworkPasswork Team

Akademisches Identity-Lifecycle-Management regelt den Zugriff einer Person, wenn sich ihr Status als Studierende, Lehrkraft, Forschende oder Mitarbeiter ändert. Im Hochschulbereich funktioniert es am besten mit drei Tracks: für Studierende, Lehrkräfte und Dozierende sowie für Mitarbeiter. Jeder Track hat eigene Trigger und Freigaben, die in einem Identitätsdatensatz zusammenlaufen.

Ein Studierender, der seinen Abschluss macht, ein Lehrbeauftragter mit auslaufendem Vertrag und ein kündigender Mitarbeiter lösen oft dasselbe Offboarding-Ticket aus, obwohl jeder zu einem anderen Zeitpunkt unterschiedlichen Zugriff verlieren sollte. Dieser Leitfaden bietet eine Lifecycle-Matrix für alle drei Gruppen, Regeln für überlappende Rollen und eine 90-Tage-Checkliste für den Rollout.

Warum akademisches Identity-Lifecycle-Management drei Tracks braucht

Bildungseinrichtungen brauchen separate Zugriffs-Lifecycles, weil Studierendenstatus, Lehraufträge und Beschäftigungsverhältnisse des Personals von unterschiedlichen Systemen und unterschiedlichen Ereignissen angelegt und verändert werden. Ein einzelner, generischer Onboarding- und Offboarding-Prozess hat Schwierigkeiten, den richtigen Zugriff rechtzeitig zu gewähren und ihn zu entfernen, sobald der Grund für diesen Zugriff entfällt.

• Der Zugriff eines Studierenden ist an Einschreibung, Kursanmeldung und akademischen Status gebunden
• Der Zugriff eines Mitarbeiters ist an eine Stelle und einen Beschäftigungsdatensatz gebunden
• Der Zugriff einer Lehrkraft hängt oft sowohl von einer Anstellung als auch von einem bestimmten Lehrauftrag ab, die nach einem anderen Zeitplan beginnen und enden können als der Beschäftigungsdatensatz

Dieses Muster wird meist als Joiner-Mover-Leaver (JML) bezeichnet: ein Framework, das erfasst, wann jemand einer Organisation beitritt, innerhalb ihrer die Rolle wechselt und sie schließlich verlässt. Im Bildungsbereich ist „Leaver“ das falsche Wort für einen Studierenden, der seinen Abschluss macht, aber eingeschränkten Alumni-Zugriff behält, oder für eine Lehrkraft, deren Lehrauftrag endet, während die Anstellung weiterläuft. Ein generischer JML-Ablauf verdeckt diese Fälle, sofern er nicht rollenspezifische Ereignisse, Übergangsfristen und überlappende Zugehörigkeiten abbildet. Das Drei-Track-Modell tut das.

Die 2025er-Gesprächsrunde von InCommon zu Identitätspraktiken im Hochschulbereich ergab, dass 27 % der Befragten die größten Schwierigkeiten mit Richtlinien und Standards hatten, 23 % mit rollenbasierter Zugriffskontrolle (RBAC) und 14 % damit, wie unterschiedliche Gruppen ihren Lifecycle durchlaufen. Die Umfrage belegt keine einzelne Grundursache. Sie zeigt aber, dass Richtlinien, Rollendesign und die Verantwortung für den Lifecycle ebenso viel Aufmerksamkeit verdienen wie die Auswahl der Technologie.

Die Academic Access Lifecycle Matrix

Die Academic Access Lifecycle Matrix (AALM) übersetzt das Lifecycle-Design in acht Entscheidungen, die für jede der drei Gruppen wiederholt werden: Trigger, maßgebliche Quelle, Identitätsattribute, Basiszugriff, bedingter Zugriff, Freigabeverantwortlicher, Überprüfungszeitpunkt und Maßnahme bei Zugriffsende. Werden diese acht Felder für Studierende, Lehrkräfte und Dozierende sowie Mitarbeiter ausgefüllt, erhält eine Institution ein funktionierendes Richtliniendokument statt eines abstrakten Frameworks.

Das föderale Identity-Lifecycle-Management-Playbook beschreibt Erstellung, Änderung und Löschung als Kernphasen für die Bereitstellung, Anpassung und den Entzug von Zugriff nach dem Prinzip der geringsten Privilegien – das heißt, Benutzer erhalten nur den Zugriff, den ihre aktuelle Rolle erfordert. Die AALM überträgt diese Logik auf den Bildungsbereich, wo „Änderung“ weit mehr Varianten umfasst als ein typischer Rollenwechsel im Unternehmen.

Die nächsten drei Abschnitte zeigen, wie sich dieselben Felder je nach Gruppe ändern. Basiszugriff, Attribute und maßgebliche Quellen variieren je nach Institution. Betrachten Sie diese Matrix als Ausgangspunkt für die Planung und tragen Sie Ihre eigenen Systeme und Freigabeverantwortlichen ein, bevor Sie eine Zeile als endgültig behandeln.

Zugriffsmanagement für Studierende von der Einschreibung bis zum Alumni-Status

Das Zugriffsmanagement für Studierende verknüpft Ereignisse des akademischen Status mit einem Berechtigungsmodell, das Zugriff hinzufügt, anpasst oder stilllegt, ohne bei jeder Statusänderung eine neue Identität anzulegen. Einschreibung, Beurlaubung, Exmatrikulation, Abschluss und der Übergang in den Alumni-Status verändern jeweils, worauf ein Studierender zugreifen kann, während der Personendatensatz derselbe bleibt.

Die Ereigniskette der Studierenden

Die Kette verläuft typischerweise vom Zugriff für Bewerber vor der Ankunft über Einschreibung oder Immatrikulation, Studiengang- und Kurswechsel, eine Beurlaubung, Exmatrikulation, Abschluss bis zum Übergang in den Alumni-Status. Prüfen Sie bei jedem Ereignis, ob es eine neue Identität anlegen, bestehenden Zugriff ändern oder eine Statusüberprüfung auslösen sollte. In den meisten Fällen existiert der Personendatensatz bereits, und das Ereignis ändert den Zugriff, statt eine zweite Identität anzulegen.

Zugriff mit akademischen Daten verknüpfen

Das SIS oder das Prüfungsamt dient üblicherweise als maßgebliche Quelle für Attribute des akademischen Status und speist Daten zur Kurseinschreibung nachgelagert in das LMS ein. Dokumentieren Sie, wie diese Daten das LMS erreichen (direkte Integration, Middleware oder eine Identity-Governance-Schicht), statt von einem einzigen festen Weg auszugehen. Passt ein Studierendendatensatz nicht eindeutig zusammen, etwa nach einer Namensänderung, einer doppelten Bewerbung oder bei einem Wechselstudierenden mit zwei bestehenden Konten, leiten Sie ihn in eine Ausnahmewarteschlange weiter. Lassen Sie das System nicht stillschweigend ein zweites Konto anlegen.

Bildungsunterlagen und Daten zur Studienfinanzierung schützen

34 CFR § 99.31(c) verpflichtet Institutionen, angemessene Methoden einzusetzen, um die Personen zu identifizieren und zu authentifizieren, denen sie personenbezogene Daten aus Bildungsunterlagen offenlegen. Die Dokumentation von Anfragen und Offenlegungen fällt unter § 99.32. Diese Anforderung deckt die Offenlegung von Informationen aus Bildungsunterlagen ab. Sie ersetzt nicht die übliche Zugriffsprotokollierung auf Anwendungsebene.

Sind Daten zur Studienfinanzierung betroffen, behandelt die Leitlinie GEN-25-08 des Bildungsministeriums den zulässigen Zugriff auf Federal Tax Information und FAFSA-Daten für berechtigte Institutionen. Keine der beiden Quellen definiert eine technische Architektur. Die Rechtsabteilung der Institution sollte prüfen, wie jede davon auf Ihre Systeme zutrifft.

Der Zugriff von Lehrkräften und Dozierenden braucht einen eigenen Lifecycle

Der Zugriff von Lehrkräften und Dozierenden braucht einen eigenen Lifecycle, weil der Lehrzugriff von einer Anstellung, einem bestimmten Kurszuschnitt und Pflichten zur Notenerfassung abhängt und nicht von einem üblichen Start- und Enddatum als Mitarbeiter. Lehrbeauftragte und Gastdozierende machen das deutlich: Ihr LMS-Zugriff muss möglicherweise vor Vertragsbeginn starten und über das Semesterende hinaus bestehen bleiben.

EDUCAUSE beschreibt ein gängiges Szenario: Eine kurzfristig eingesetzte Lehrkraft benötigt LMS-Zugriff vor dem offiziellen Starttermin, um einen Kurs aufzubauen, und braucht nach Semesterende möglicherweise eingeschränkten Zugriff, um die Notenerfassung abzuschließen. Ein generischer Mitarbeiter-Lifecycle, der auf einem einzigen Einstellungs- und einem einzigen Kündigungsdatum aufbaut, bildet dieses Muster schlecht ab. Institutionen brauchen eine dokumentierte Richtlinie mit einer benannten Übergangsfrist.

Die individuelle LMS- oder E-Mail-Berechtigung einer Lehrkraft gehört in das IAM/IGA-Zugriffsmodell. Eine Schicht für Credential-Management ist eher für gemeinsam genutzte operative Konten relevant, die IT oder ein benannter Verantwortlicher direkt kontrolliert, etwa Laborsysteme oder Lieferantenzugänge.

Lifecycle für Mitarbeiter: Beschäftigungsereignisse, Rollenwechsel und Austritte

Der Zugriff von Mitarbeitern sollte validierten Beschäftigungs- und Stellenwechsel-Ereignissen folgen, wobei der zuständige Vorgesetzte oder Fachverantwortliche jeden Zugriff über das Standardrollenpaket hinaus bestätigt. Typische Trigger sind Einstellung, Versetzung, Beförderung, Beurlaubung und Kündigung, und jedes davon sollte bestehende Berechtigungen neu bewerten, statt nur neue hinzuzufügen.

Ein häufiges Fehlermuster ist Privilege Creep: Jemand erhält nach einer Beförderung neuen Zugriff, und niemand entfernt den Zugriff, der an die alte Rolle gebunden war. Regelmäßige Zugriffsrezertifizierung – eine geplante Überprüfung, bei der ein Vorgesetzter bestätigt, dass der Zugriff jeder Person noch benötigt wird – erkennt das, bevor es zu einem Prüfungsbefund wird.

NIST SP 1800-35 beschreibt sicheren autorisierten Zugriff als fortlaufende Entscheidung statt als einmalige Gewährung, aufbauend auf erweiterter Identity-Governance über verteilte On-Premises- und Cloud-Ressourcen. Das auf den Zugriff von Mitarbeitern anzuwenden ist eine Designentscheidung und keine NIST-Anforderung: Behandeln Sie jeden Rollenwechsel als Anlass, bestehende Berechtigungen neu zu bewerten.

Eine Person, mehrere Rollen: Übergänge und Überlappungen steuern

Ein Mehrfachrollen-Identitätsmodell führt einen einzigen Personendatensatz und gewährt nur den Zugriff, der durch jede aktive Rolle gerechtfertigt ist. Das verhindert doppelte Konten und ermöglicht es, den an eine Rolle gebundenen Zugriff zu entfernen, während der Zugriff aus einer anderen Rolle unberührt bleibt.

Sechs Szenarien decken die meisten Überlappungen ab, auf die Institutionen stoßen:

• Ein Studierender wird Mitarbeiter, etwa wenn Werkstudenten in Teilzeitrollen wechseln
• Ein Mitarbeiter oder eine Lehrkraft schreibt sich als Studierender ein
• Eine Lehrkraft ist gleichzeitig Dozent, Forscher und Verwaltungsverantwortlicher der Abteilung
• Ein Werkstudent wechselt die Abteilung oder hat gleichzeitig zwei Stellen
• Ein Alumnus oder Ruheständler erhält eingeschränkten, zeitlich begrenzten Zugriff auf einen bestimmten Dienst
• Ein Auftragnehmer oder externer Mitarbeiter benötigt Zugriff, der automatisch zu einem festgelegten Datum abläuft

Die wichtigste Regel: Wenn eine Zugehörigkeit endet, entfernen Sie nur den an diese Zugehörigkeit gebundenen Zugriff. Zwei Fehler sind möglich. Das System kann Zugriff entziehen, den eine andere aktive Rolle weiterhin rechtfertigt, oder es kann Zugriff bestehen lassen, nachdem die Zugehörigkeit geendet hat. Zuverlässiger Identitätsabgleich (die Bestätigung, dass zwei Datensätze zur selben Person gehören) und eine dokumentierte Prüfwarteschlange für Fälle, die die automatisierten Regeln nicht lösen können, halten beide Fehler beherrschbar.

Die Daten- und Integrationsschicht vor der Automatisierung aufbauen

Automatisierung funktioniert, sobald eine Institution ihre maßgeblichen Quellen benannt, einen zuverlässigen Identitätsabgleich aufgebaut und eine Datenvorrangregel für Konflikte zwischen Systemen festgelegt hat. Ohne diese drei Voraussetzungen wirken Provisioning-Regeln auf veraltete oder nicht übereinstimmende Datensätze und gewähren Zugriff entweder zu früh oder lassen ihn zu lange bestehen.

Weisen Sie die maßgebliche Quelle je Attribut zu, nicht je System. Ein gängiges Modell ordnet Attribute des akademischen Status dem SIS oder dem Prüfungsamt zu, Beschäftigungsattribute HR/HCM und der Gehaltsabrechnung und Attribute zu Lehraufträgen einem Planungssystem oder der akademischen Verwaltung. Die Zuständigkeit variiert je Campus. Dokumentieren Sie daher die Zuständigkeit und den Vorrang auf Attributebene für Ihre eigene Umgebung.

Manche Zugangsdaten haben in keinem dieser Systeme einen natürlichen Eigentümer. Gemeinsam genutzte Cloud-Admin-Zugangsdaten, die von drei Infrastruktur-Ingenieuren verwendet werden, gehören weder zu HR noch zum SIS. Eine Identity-Governance-and-Administration-Schicht (IGA) kann festhalten, dass das Infrastrukturteam dafür verantwortlich ist. Das Secret selbst braucht weiterhin ein System, das gemeinsam genutzte Zugangsdaten speichert, rotiert und protokolliert. Das ist eine separate Kontrollmaßnahme.

Ein grundlegender Ereignisablauf sieht so aus:

• Ein Ereignis im führenden System tritt ein
• Der Identitätsabgleich bestätigt, auf welche Person es sich bezieht
• Eine Richtlinienregel bewertet, was sich ändern soll
• Eine Freigabe erfolgt, wo erforderlich
• Provisioning oder Entzug wird ausgeführt
• Ein Audit-Ereignis protokolliert, was passiert ist

Jeder Schritt, der fehlschlägt, etwa eine nicht zugeordnete Identität oder ein veraltetes Ereignis, sollte in eine sichtbare Ausnahmewarteschlange mit einem benannten Verantwortlichen gehen. Er sollte nicht stillschweigend verschwinden.

NIST SP 800-63-4 legt Anforderungen für Identitätsprüfung, Registrierung, Authenticator-Management, Authentifizierung und Federation fest. Es ist eine nützliche Referenz für die Identitätsschicht unter dieser Automatisierung, schreibt jedoch keine Architektur für den Bildungsbereich vor.

Zugriffskontrollen und Nachweise anwenden, die zum Risiko passen

Zugriffskontrollen sollten der Sensibilität der Ressource und der aktuellen Rolle der Person entsprechen, während Audit-Nachweise zeigen sollten, wer den Zugriff genehmigt hat, wann er sich geändert hat und ob er weiterhin gerechtfertigt ist. Grundlegende Kontrollen umfassen das Prinzip der geringsten Privilegien, rollenbasierte Zugriffskontrolle (RBAC), MFA, SSO, geplante Überprüfungen, zeitlich begrenzten Zugriff und Funktionstrennung.

Funktionstrennung verhindert, dass eine Person den eigenen Zugriff sowohl beantragt als auch genehmigt. Richtlinienbasierte Regeln können Kontext hinzufügen, den eine Rolle allein nicht trägt, etwa Anstellungsdaten oder Kurszuweisungen. Verwaiste Konten – also Konten, die noch aktiv sind, nachdem die Zugehörigkeit, die sie rechtfertigte, geendet hat – sollten automatisch markiert werden, statt erst bei einem Audit entdeckt zu werden.

Gemeinsam genutzte operative Zugangsdaten benötigen eine eigene Schicht. Ein IAM/IGA-Programm kann Eigentümerschaft und Überprüfung eines gemeinsam genutzten Servicekontos, eines Laborsystems oder eines Lieferantenportal-Logins steuern und festlegen, wer verantwortlich ist und wann der Zugriff rezertifiziert wird. Es speichert, rotiert oder teilt das Secret nicht sicher. Dort übernimmt eine Schicht für Credential-Management.

Umsetzungscheckliste für akademisches Identity-Lifecycle-Management: die ersten 90 Tage

In den ersten 90 Tagen sollten Sie die Richtlinie festlegen, die drei Gruppen modellieren, die Quelldaten validieren, eine kleine Anzahl von Anwendungen pilotieren und ungelöste Ausnahmen messen, bevor die Automatisierung ausgeweitet wird. Die folgende Checkliste folgt dieser Reihenfolge und endet mit der rechtlichen Prüfung und der Datenschutzprüfung. Jeder Schritt liefert ein Dokument oder eine Kennzahl, die das Governance-Gremium überprüfen kann.

Die 90-Tage-Checkliste für akademisches Identity-Lifecycle-Management (10 Punkte)

• Bilden Sie ein Governance-Gremium: Prüfungsamt, HR, akademische Verwaltung, IAM/IT, Sicherheit, Anwendungsverantwortliche und Service-Desk
• Definieren Sie den Personendatensatz und die Regeln für den Identitätsabgleich über Systeme hinweg
• Bilden Sie die Lifecycle-Zustände und Trigger für Studierende, Lehrkräfte/Dozierende und Mitarbeiter ab
• Weisen Sie jedem Schlüsselattribut eine maßgebliche Quelle und eine Vorrangregel zu
• Bauen Sie die AALM für Ihre ersten fünf Anwendungen oder Dienste auf
• Erstellen Sie Regeln für Freigabe, Ausnahmen, Übergangsfristen und Notfall-Offboarding
• Erproben Sie automatisiertes Provisioning und Deprovisioning mit aktivem Monitoring
• Legen Sie Basiskennzahlen fest: Zeit bis zur Bereitstellung, Zeit bis zur Deaktivierung, Rückstand bei Ausnahmen, inaktive Konten, überfälliger temporärer Zugriff und Abschlussquote der Überprüfungen
• Führen Sie vor dem Go-Live Planübungen für Mehrfachrollen- und Semesterende-Szenarien durch
• Lassen Sie die Richtlinie von Rechts- und Datenschutzverantwortlichen prüfen, bevor Sie sie flächendeckend durchsetzen

InCommon empfiehlt dieselbe Abfolge: lokale Lifecycle-Anforderungen definieren, sie visuell abbilden, Governance etablieren, die Qualität der Quelldaten verbessern, Ausnahmen einplanen und Entscheidungen dokumentieren.

Fazit

Behandeln Sie den akademischen Identity-Lifecycle zuerst als Richtlinienproblem und erst danach als Tooling-Problem. Drei Ereignisströme, drei Verantwortliche, ein Personendatensatz: Das ermöglicht es, den Laborzugriff eines Studierenden nach dessen Abschluss zu entfernen, ohne die Stelle zu berühren, die er im Prüfungsamt angetreten hat.

Nächster Schritt: Bringen Sie das Governance-Gremium zusammen und einigen Sie sich auf die ersten fünf abzubildenden Anwendungen, eingestuft nach der Sensibilität der Daten, die sie enthalten.

Häufig gestellte Fragen

Passwort-Chaos in Bildungseinrichtungen: Warum es wichtig ist

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

PassworkPasswork Team

Mitarbeiter-Offboarding: Leitfaden zum sicheren Zugriffsentzug 2026

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

Passwork BlogAlex Muntyan

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

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

PassworkPasswork Team

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

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

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

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

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

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

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

La matriz de ciclo de vida de acceso académico

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

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

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

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

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

La cadena de eventos del estudiante

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

Vincular el acceso a los datos académicos

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

Proteger los registros educativos y los datos de ayuda financiera

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Un flujo de eventos básico tiene este aspecto:

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

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

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

Aplicar controles de acceso y evidencias acordes con el riesgo

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

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

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

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

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

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

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

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

Conclusión

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

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

Preguntas frecuentes

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

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

PassworkPasswork Team

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

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

Passwork BlogAlex Muntyan

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

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

PassworkPasswork Team

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

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

Why academic identity lifecycle management needs three tracks

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

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

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

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

The Academic Access Lifecycle Matrix

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

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

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

Student access management from enrollment to alumni status

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

The student event chain

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

Linking access to academic data

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

Protecting education records and financial-aid data

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

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

Faculty and instructor access needs its own lifecycle

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

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

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

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

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

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

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

One person, several roles: governing transitions and overlaps

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

Six scenarios cover most of the overlaps institutions run into:

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

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

Build the data and integration layer before automating

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

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

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

A basic event flow looks like this:

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

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

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

Apply access controls and evidence that match the risk

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

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

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

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

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

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

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

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

Conclusion

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

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

Frequently asked questions

Password chaos in educational institutions: Why it matters

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

PassworkPasswork Team

Employee offboarding: Secure access revocation guide 2026

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

Passwork BlogAlex Muntyan

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

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

PassworkPasswork Team

Começa um novo período letivo e a fila do helpdesk enche-se de pedidos de reposição antes de arrancar a primeira aula. Um colaborador não consegue iniciar sessão no sistema de gestão da aprendizagem. Um departamento partilha um único início de sessão numa ferramenta de investigação e ninguém se lembra de quem definiu a palavra-passe nem de quem mais tem uma cópia.

É isto que compromete a segurança das palavras-passe nas instituições de ensino: credenciais dispersas por dezenas de sistemas e partilhadas sem supervisão. Uma escola ou universidade pode manter inícios de sessão separados para registos de estudantes, plataformas de aprendizagem, ferramentas de investigação e bases de dados de finanças, RH e proteção de menores, cada um com os seus próprios hábitos de palavra-passe.

O caos das palavras-passe alastra para além do helpdesk de TI e chega ao resto da organização. Os colaboradores perdem horas a tentar obter acesso em vez de ensinar ou investigar. As credenciais não geridas alargam os caminhos que os atacantes utilizam para entrar. Registos de acesso deficientes transformam uma auditoria de rotina numa constatação de incumprimento. A gestão de acessos é a forma de as instituições fecharem estas três lacunas em simultâneo.

O caos das palavras-passe é um problema de continuidade de acesso

O caos das palavras-passe acumula-se porque nada volta a rever uma decisão de acesso depois de tomada. Um início de sessão é partilhado para um projeto e continua partilhado depois de o projeto terminar. Um colaborador é adicionado a um sistema, muda de função e mantém o acesso antigo porque ninguém tem a tarefa de o verificar. Multiplique-se isto por cada sistema acrescentado ao longo de uma década e ninguém consegue dizer com certeza quem tem acesso a quê.

Esta lacuna manifesta-se de forma mais evidente na saída de colaboradores. Remover o acesso de um colaborador que sai devia ser uma tarefa de TI de rotina. Em vez disso, transforma-se numa busca por dezenas de sistemas desligados entre si, porque o registo de quem tem acesso a quê nunca foi centralizado.

Como o caos das palavras-passe atrasa o trabalho no ensino

O caos das palavras-passe revela-se primeiro como perda de tempo. Reposições, desbloqueios e alterações manuais de contas transformam-se numa fila recorrente que afasta a equipa de TI do apoio ao ensino e do trabalho de segurança.

O acesso fragmentado interrompe fluxos de trabalho críticos

Os sistemas essenciais no ensino incluem plataformas de gestão da aprendizagem, sistemas de informação de estudantes, ambientes de investigação, e-mail, RH, finanças, sistemas de biblioteca e registos de proteção de menores. Perder o acesso a qualquer um deles pode atrasar a atribuição de classificações, bloquear um prazo de investigação ou deixar temporariamente inacessível um registo de proteção de menores. A gravidade depende do impacto do sistema na atividade e da qualidade dos mecanismos de recuperação.

As credenciais partilhadas diluem a responsabilidade

Os inícios de sessão partilhados eliminam a responsabilização. Quando várias pessoas utilizam o mesmo início de sessão numa ferramenta partilhada, a instituição perde a capacidade de dizer quem fez o quê. Isso importa no dia a dia, ao investigar uma alteração inesperada. Importa ainda mais quando uma função muda e alguém precisa de perder o acesso sem inutilizar a conta para todos os que continuam a utilizá-la.

Porque o caos das palavras-passe aumenta o risco de incidentes de segurança

O caos das palavras-passe alarga os caminhos que os atacantes utilizam para entrar. Palavras-passe reutilizadas, contas partilhadas não geridas e uma saída de colaboradores deficiente tornam os ataques baseados em credenciais mais fáceis de concretizar e mais difíceis de conter.

O 2026 Data Breach Investigations Report da Verizon concluiu que a exploração de vulnerabilidades liderou o acesso inicial em 31 % das violações, à frente do abuso de credenciais pela primeira vez. Mas o abuso de credenciais continuou a surgir, em algum ponto da cadeia de ataque, em 39 % das violações analisadas pela Verizon. Uma palavra-passe roubada ou reutilizada não tinha de ser o primeiro passo para ter importância. Bastava estar ali, reutilizável, depois de um atacante entrar por outra porta.

O National Cyber Security Centre do Reino Unido explica porque é que essa reutilização persiste: a sobrecarga de palavras-passe incentiva comportamentos de compensação inseguros, como a reutilização, fórmulas previsíveis e armazenamento inseguro. Pedir aos colaboradores que «escolham uma palavra-passe mais forte» não resolve um sistema em que doze departamentos mantêm, cada um, a sua própria folha de cálculo de inícios de sessão partilhados. O 2025 Threat Landscape da ENISA indica que o phishing continuou a ser o principal método de intrusão inicial e uma técnica eficaz para o roubo de credenciais e o sequestro de sessões, precisamente o tipo de roubo que as credenciais não geridas e reutilizadas facilitam.

Como uma credencial roubada se transforma numa violação de dados

Uma única palavra-passe reutilizada raramente fica confinada a uma só conta. Os atacantes passam do primeiro início de sessão comprometido a um acesso mais amplo numa sequência previsível. Cada passo depende de o anterior passar despercebido.

A cadeia de ataque costuma ter este aspeto:

• Um atacante envia uma mensagem de phishing que imita uma página de início de sessão conhecida ou explora diretamente um sistema sem correções
• Se o phishing resultar, um utilizador entrega credenciais reais sem se aperceber
• O atacante testa essas credenciais noutros sistemas, uma técnica que funciona muito mais vezes quando as palavras-passe são reutilizadas
• Se a conta comprometida tiver acesso amplo, partilhado ou persistente, o atacante pode avançar mais antes de alguém dar por isso

Uma credencial roubada causa mais danos quando concede acesso amplo ou partilhado, porque a instituição perde tanto a contenção como a capacidade de rastrear o que aconteceu. A introdução à gestão de identidades e acessos do NCSC afirma-o de forma direta: controlos de IAM fracos permitem que um atacante que obtenha uma credencial se faça passar por utilizador legítimo em vários sistemas.

Fredrik Blomqvist, diretor de segurança da Uppsala University, defendeu a mesma ideia a partir da própria função de segurança de uma universidade, em março de 2026: o phishing continua a ser o tipo de ataque mais comum que a instituição regista e o fator humano, e não a infraestrutura tecnológica, continua a ser o seu maior risco de cibersegurança.

O acesso de terceiros alarga o risco das credenciais

Os fornecedores externos acrescentam mais uma camada de exposição, porque as instituições de ensino subcontratam com frequência sistemas de informação de estudantes, plataformas de aprendizagem e processamento de pagamentos. O 2026 DBIR da Verizon concluiu que o envolvimento de terceiros atingiu 48 % de todas as violações, um aumento de 60 % face ao ano anterior. Entre essas organizações terceiras, apenas 23 % tinham corrigido por completo a MFA em falta ou incorreta nas respetivas contas cloud. O acesso de terceiros pode estender o risco das credenciais para além dos sistemas da própria instituição, pelo que as ligações de fornecedores exigem o mesmo nível de revisão de identidades e acessos que as contas internas.

O ransomware torna a recuperação e a revogação mais urgentes

Depois de um atacante entrar, a rapidez da contenção determina a dimensão dos danos que uma única credencial roubada pode causar. A Sophos inquiriu 441 instituições de ensino que tinham sofrido um ataque de ransomware no ano anterior e concluiu que 29 % dos inquiridos do ensino básico e secundário e 58 % dos inquiridos do ensino superior declararam um ataque que resultou na cifragem de dados. Este valor descreve o que acontece depois de um atacante entrar, entre instituições já atingidas: é uma medida da rapidez de contenção, não uma afirmação sobre a causa da violação. É um motivo para tratar a revogação rápida de credenciais como uma etapa testada da resposta a incidentes.

Porque a falta de gestão de acessos aumenta o risco de conformidade com o RGPD e a NIS2

As escolas, os colégios e as universidades que tratam dados pessoais ou operam sistemas críticos elegíveis ficam abrangidos pelo RGPD, pela NIS2 ou por ambos. 

• O RGPD aplica um critério de segurança baseado no risco, dentro de limites materiais e territoriais definidos 
• A NIS2 aplica-se a entidades essenciais e importantes que cumpram os critérios da Diretiva quanto ao tipo de entidade, à dimensão ou a vias especiais, conforme a respetiva transposição para o direito nacional 

O RGPD estabelece um critério baseado no risco

RGPD (Regulamento Geral sobre a Proteção de Dados) é a lei central da UE em matéria de proteção de dados. Aplica-se ao tratamento de dados pessoais no seu âmbito material e territorial. Isto inclui o tratamento efetuado no contexto de uma organização estabelecida na UE, bem como determinados tratamentos realizados por organizações fora da UE que oferecem bens ou serviços a pessoas na UE ou monitorizam o seu comportamento nesse território.

O artigo 5.º, n.º 1, alínea f), do RGPD exige proteção contra o tratamento não autorizado ou ilícito e contra a perda ou os danos acidentais. O artigo 32.º vai mais longe: prevê medidas adequadas ao risco, incluindo, consoante o caso, a confidencialidade, a integridade, a disponibilidade, a resiliência, a capacidade de restabelecer o acesso após um incidente e testes regulares.

Numa secretaria académica que guarda os registos dos estudantes, esta formulação baseada no risco traduz-se em controlos práticos: quem pode consultar um registo, como o acesso é registado e com que rapidez o acesso pode ser restabelecido se um sistema falhar.

A abrangência da NIS2 depende do âmbito

NIS2 (a segunda Diretiva da UE relativa à Segurança das Redes e da Informação) cria obrigações de cibersegurança para as organizações classificadas como entidades essenciais e importantes que se enquadrem no âmbito da Diretiva. Essa avaliação começa nas regras da própria Diretiva sobre tipo de entidade, dimensão e vias especiais e depende depois da forma como o Estado-Membro em causa as transpôs e aplicou. O ensino não consta como setor autónomo no Anexo I nem no Anexo II, mas uma escola, um colégio ou uma universidade pode, ainda assim, estar no âmbito da Diretiva por via de um tipo de entidade listado, do estatuto de administração pública ou de outra via aplicável.

Para uma entidade abrangida, o artigo 21.º exige medidas de gestão de riscos adequadas e proporcionadas. O considerando 79 refere que essas medidas devem abordar a segurança dos recursos humanos e incluir políticas de controlo de acesso adequadas.

Para uma entidade que tome conhecimento de um incidente significativo, o artigo 23.º estabelece uma fase de alerta rápido no prazo de 24 horas, uma fase de notificação do incidente no prazo de 72 horas e um relatório final, o mais tardar, um mês após a notificação. Os incidentes em curso seguem um percurso separado de relatórios intercalares.

Cumprir o prazo de 24 horas do artigo 23.º exige saber quem tinha acesso ao sistema comprometido e quando esse acesso foi alterado pela última vez. Quando os departamentos gerem as palavras-passe de forma independente, com uma folha de cálculo num gabinete e uma palavra-passe reencaminhada por chat noutro, essa informação, em regra, não fica registada em lado nenhum. Os auditores que peçam provas de que as decisões de acesso são proporcionadas, documentadas e passíveis de revisão encontrarão a mesma lacuna.

A abrangência do setor da educação depende da implementação nacional.  Nos Países Baixos, por exemplo, as universidades ficam abrangidas pela NIS2 em grande parte devido à propriedade intelectual gerada pela investigação, pois o governo considera esse conhecimento um ativo nacional. Recomenda-se confirmar o estatuto específico da instituição junto de especialistas jurídicos ou de conformidade, em vez de o assumir num sentido ou noutro.

A gestão de acessos fecha as lacunas de produtividade, risco e conformidade

A gestão de acessos é o que elimina os três problemas descritos acima: tempo dos colaboradores desperdiçado, maior exposição a violações e provas de conformidade insuficientes. Funciona ao controlar a identidade, a autenticação e as permissões como um único processo interligado em todos os sistemas que a instituição utiliza, em vez de deixar cada aplicação aplicar as suas próprias regras de palavra-passe.

Um gestor de palavras-passe empresarial é a camada prática que torna isto possível. 

• O armazenamento centralizado de credenciais, com permissões substitui a folha de cálculo partilhada e o post-it 
• A atribuição de responsáveis e o acesso baseado em funções eliminam as dúvidas sobre quem pode aceder a quê 
• A recuperação em autosserviço ou delegada reduz a fila de reposições às contas que realmente precisam da ajuda da equipa de TI 
• Os registos de auditoria e as revisões periódicas de acessos produzem as provas documentadas e passíveis de revisão que tanto o RGPD como a NIS2 exigem

Como os gestores de palavras-passe ajudam o ensino a gerir acessos em grande escala 

As orientações atuais do NIST sobre palavras-passe recomendam a autenticação multifator (MFA), tratam as passkeys como uma alternativa viável às palavras-passe e recomendam os gestores de palavras-passe, cofres seguros de credenciais que geram e armazenam palavras-passe únicas, para as contas que ainda utilizam uma. Isto cobre o nível de base: credenciais únicas, geradas e armazenadas de forma segura, em vez de reutilizadas ou anotadas.

Os gestores de palavras-passe de nível empresarial vão mais longe. As permissões baseadas em funções atribuem a responsabilidade ao nível do cofre, os registos de auditoria e as revisões de acessos produzem o rasto de provas que os auditores pedem, e a integração com diretórios liga o ciclo de vida das contas aos sistemas de RH e de TI em vez de uma lista de verificação manual. O guia do Passwork sobre gestão de palavras-passe em equipa explica como estes elementos funcionam em conjunto na prática.

A recuperação também sai beneficiada. Quando um dispositivo desaparece ou se suspeita de que uma credencial foi comprometida, um administrador pode suspender o acesso dessa pessoa ao cofre e rodar as credenciais afetadas sem perturbar os outros utilizadores que continuam a depender da mesma entrada partilhada. Um sistema gerido reduz o trabalho de busca e recuperação que uma credencial partilhada de outro modo cria e permite que os administradores atuem através de um processo documentado, em vez de seguirem um início de sessão por conversas de chat e documentos de integração.

Duas prioridades específicas do ensino

Os processos de joiner, mover e leaver (entrada, mudança e saída) merecem atenção especial no ensino, porque as mudanças de estudantes, de pessoal temporário, de prestadores de serviços e do período letivo originam alterações frequentes de contas, segundo um calendário previsível. A automatização do aprovisionamento e do desaprovisionamento em torno desses ciclos conhecidos elimina o passo manual em que o acesso mais vezes fica esquecido.

As contas partilhadas devem continuar a ser uma exceção controlada: concedidas deliberadamente, com responsável nomeado e revistas de forma periódica. O guia de partilha segura de palavras-passe do Passwork explica como uma ferramenta departamental partilhada pode manter responsáveis designados e acesso baseado em funções dentro de um cofre seguro com registo de auditoria, em vez de um único início de sessão a circular por mensagem de chat sem registo de quem o tem.

Um plano inicial em cinco passos para responsáveis de TI no ensino

Esta sequência de cinco passos adapta-se ao calendário letivo, pelo que as equipas de TI podem começar já, sem esperar por uma paragem de todo o sistema. Deve ser encarada como ponto de partida, não como um plano de implementação completo.

• Identifique os sistemas em que a perda de acesso ou o acesso não autorizado causaria mais danos. Dê prioridade aos registos de estudantes, aos dados de proteção de menores, aos sistemas de investigação e às finanças, à frente de ferramentas de menor risco.
• Inventarie as contas partilhadas, privilegiadas e sem responsável e atribua um responsável designado a cada uma. Só este passo costuma revelar contas de cuja criação ninguém se recorda.
• Meça a linha de base atual antes de alterar a política. Registe o volume de reposições, os bloqueios e os atrasos na integração ou na saída de colaboradores, para poder avaliar se uma alteração ajudou realmente. É também aqui que uma auditoria de configuração se justifica: o 2026 DBIR da Verizon concluiu que, na sua amostra de dispositivos avaliados, 97 % dos dispositivos falharam a verificação do número de tentativas de início de sessão permitidas antes do bloqueio e 90 % falharam a verificação que exige palavras-passe com pelo menos 15 carateres. Vale a pena testar diretamente esta distância entre a política documentada e a configuração aplicada.
• Dê prioridade, primeiro, à MFA e ao tratamento seguro de credenciais dos utilizadores de risco elevado. Os administradores, a equipa de TI e quem tenha acesso a sistemas financeiros ou de proteção de menores devem avançar antes da população geral de estudantes.
• Realize um piloto num departamento antes de alargar a escala. Execute o novo processo numa única equipa, reveja os controlos, a fricção operacional e os resultados observados e depois alargue-o. As instituições sem pessoal de segurança disponível 24 horas por dia não estão limitadas a resolver isto sozinhas: o setor do ensino superior da Polónia, por exemplo, está a organizar capacidade regional partilhada de monitorização especificamente para as universidades que não conseguem montar internamente uma cobertura 24/7.

A recomendação do NIST de combinar a MFA, ponderar as passkeys onde sejam adequadas e utilizar um gestor de palavras-passe nas contas que ainda precisam de um aplica-se diretamente ao passo quatro. Para os estudantes, o cálculo muda: a idade, as necessidades de acessibilidade e a disponibilidade de dispositivos influenciam que controlos fazem sentido para cada grupo. Um controlo que funciona para os colaboradores das finanças pode ser inadequado para uma criança de doze anos que inicia sessão numa aplicação de leitura.

Do caos das palavras-passe a um sistema gerido

O caos das palavras-passe raramente se anuncia como uma crise. Constrói-se um início de sessão partilhado e uma reposição manual de cada vez, até a instituição já não conseguir dizer com certeza quem tem acesso a quê. Resolvê-lo implica tratar a segurança das palavras-passe nas instituições de ensino como um modelo operacional: atribuir um responsável a cada conta, acompanhá-la e revê-la de forma periódica, como prática contínua.

Para as equipas prontas a centralizar credenciais partilhadas e a ligar o acesso aos sistemas de identidade existentes, o Passwork disponibiliza cofres controlados, permissões baseadas em funções, sincronização de diretórios e registos de auditoria. Estas capacidades podem apoiar partes de um programa mais amplo de governação de acessos. A sua adequação depende dos sistemas da instituição, da configuração, da avaliação de risco e dos restantes controlos de conformidade.

Perguntas frequentes

Caos das palavras-passe: Porque é um problema de negócio e como resolvê-lo

Uma palavra-passe esquecida custa 70 dólares. Uma violação de dados custa 4,44 milhões de dólares. Ambas começam da mesma forma: credenciais partilhadas pelo Slack, guardadas em folhas de cálculo e nunca rodadas. Eis o custo real do caos das palavras-passe e como eliminá-lo.

Passwork BlogAlex Muntyan

O que é a gestão de palavras-passe?

A gestão de palavras-passe é a prática de criar, armazenar, organizar e controlar o acesso a palavras-passe e a outras credenciais de autenticação de forma segura. Combina processos humanos com ferramentas de software especializadas para garantir que cada conta utiliza uma palavra-passe forte e única, sem exigir que os utilizadores as memorizem todas. Quer se trate de um indivíduo que procura proteger a sua vida online, quer de um administrador de TI que protege os ativos digitais da organização, compreender a gestão de palavras-passe é essencial.

PassworkPasswork Team

Como ensinar as crianças sobre segurança de palavras-passe: Dicas para pais

Um guia para pais sobre como ensinar segurança de palavras-passe às crianças: despertar uma motivação genuína, adaptar as lições à idade, criar frases-passe fortes, adicionar 2FA ou passkeys, detetar tentativas de phishing e recuperar contas com calma através de uma rotina repetível de Criar, Proteger e Recuperar.

PassworkPasswork Team