Password security

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

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

Ein neues Semester beginnt, und die Helpdesk-Warteschlange füllt sich mit Rücksetzungsanfragen, noch bevor die erste Vorlesung startet. Eine Mitarbeiterin kommt nicht ins Lernmanagementsystem. Eine Abteilung teilt sich einen Login für ein Forschungstool, und niemand erinnert sich mehr, wer das Passwort festgelegt hat oder wer sonst noch eine Kopie davon besitzt.

Genau das untergräbt die Passwortsicherheit in Bildungseinrichtungen: Zugangsdaten, die über Dutzende Systeme verteilt und ohne Kontrolle weitergegeben werden. Eine einzelne Schule oder Universität kann getrennte Logins für Schülerdaten, Lernplattformen, Forschungstools sowie Finanz-, HR- und Kinderschutz-Datenbanken betreiben – jede mit eigenen Passwortgewohnheiten.

Passwortchaos breitet sich vom IT-Helpdesk auf die gesamte Organisation aus. Mitarbeiter verbringen Stunden damit, sich um Zugriffsrechte zu kümmern, statt zu lehren oder zu forschen. Unverwaltete Zugangsdaten vergrößern die Angriffsflächen, über die Angreifer eindringen. Lückenhafte Zugriffsaufzeichnungen machen aus einem Routineaudit einen Compliance-Befund. Zugriffsverwaltung ist, wie Institutionen alle drei Lücken gleichzeitig schließen.

Passwortchaos ist ein Problem der Zugriffskontinuität

Passwortchaos entsteht, weil niemand eine einmal getroffene Zugriffsentscheidung erneut überprüft. Ein Login wird für ein Projekt geteilt und bleibt auch nach dessen Ende geteilt. Ein Mitarbeiter wird einem System hinzugefügt, wechselt die Rolle und behält den alten Zugriff, weil niemand für die Überprüfung zuständig ist. Multipliziert man das mit jedem System, das über ein Jahrzehnt hinzugekommen ist, kann niemand mehr mit Sicherheit sagen, wer worauf Zugriff hat.

Diese Lücke zeigt sich am deutlichsten beim Offboarding. Das Entfernen des Zugriffs eines ausscheidenden Mitarbeiters sollte eine Routineaufgabe der IT sein. Stattdessen wird es zu einer Suche durch Dutzende voneinander getrennte Systeme, weil die Aufzeichnung darüber, wer worauf Zugriff hat, von Anfang an nie zentral erfasst wurde.

Wie Passwortchaos den Bildungsbetrieb ausbremst

Passwortchaos zeigt sich zuerst als verlorene Zeit. Rücksetzungen, Entsperrungen und manuelle Kontoänderungen werden zu einer wiederkehrenden Warteschlange, die IT-Mitarbeiter von der Unterstützung der Lehre und von Sicherheitsaufgaben abzieht.

Fragmentierter Zugriff unterbricht kritische Arbeitsabläufe

Zu den wichtigsten Systemen im Bildungsbereich zählen Lernmanagementplattformen, Schülerinformationssysteme, Forschungsumgebungen, E-Mail, HR, Finanzen, Bibliothekssysteme und Kinderschutzakten. Der Verlust des Zugriffs auf eines dieser Systeme kann die Bewertung verzögern, eine Forschungsfrist blockieren oder eine Kinderschutzakte vorübergehend unerreichbar machen. Wie gravierend das wird, hängt vom Geschäftseinfluss des Systems und der Qualität seiner Wiederherstellungsmaßnahmen ab.

Geteilte Zugangsdaten verschleiern Verantwortlichkeit

Geteilte Logins heben die Verantwortlichkeit auf. Wenn mehrere Personen denselben Login für ein gemeinsames Tool nutzen, verliert die Institution die Möglichkeit zu sagen, wer was getan hat. Das spielt im Alltag eine Rolle, etwa bei der Fehlersuche nach einer unerwarteten Änderung. Es spielt eine noch größere Rolle, wenn sich eine Rolle ändert und jemandem der Zugriff entzogen werden muss, ohne das Konto für alle anderen, die es weiterhin nutzen, unbrauchbar zu machen.

Warum Passwortchaos das Risiko eines Sicherheitsvorfalls erhöht

Passwortchaos vergrößert die Angriffsflächen, über die Angreifer eindringen. Wiederverwendete Passwörter, unverwaltete geteilte Konten und mangelhaftes Offboarding machen auf Zugangsdaten basierende Angriffe leichter durchführbar und schwerer einzudämmen.

Verizons Data Breach Investigations Report 2026 ergab, dass Schwachstellen-Exploits in 31 % der Sicherheitsverletzungen zum initialen Zugriff führten und damit erstmals häufiger vorkamen als Zugangsdatenmissbrauch. Zugangsdatenmissbrauch tauchte jedoch weiterhin irgendwo in der Angriffskette von 39 % der von Verizon analysierten Sicherheitsverletzungen auf. Ein gestohlenes oder wiederverwendetes Passwort musste nicht der erste Schritt sein, um eine Rolle zu spielen. Es musste nur vorhanden und wiederverwendbar sein, sobald ein Angreifer durch eine andere Tür eindrang.

Das britische National Cyber Security Centre (NCSC) erklärt, warum diese Wiederverwendung immer wieder vorkommt: Passwortüberlastung begünstigt unsicheres Ausweichverhalten wie Wiederverwendung, vorhersehbare Muster und unsichere Speicherung. Mitarbeitern zu sagen, sie sollten „ein stärkeres Passwort wählen", behebt kein System, in dem zwölf Abteilungen jeweils ihre eigene Tabelle mit geteilten Logins führen. ENISAs Threat Landscape 2025 berichtet, dass Phishing die wichtigste Methode für den initialen Einbruch sowie eine wirksame Technik für Zugangsdatendiebstahl und Session-Hijacking blieb – genau die Art von Diebstahl, die unverwaltete, wiederverwendete Zugangsdaten erleichtert.

Wie gestohlene Zugangsdaten zu einer Sicherheitsverletzung führen

Ein einzelnes wiederverwendetes Passwort bleibt selten auf ein Konto beschränkt. Angreifer bewegen sich vom ersten kompromittierten Login zu weiterreichendem Zugriff in einer vorhersehbaren Abfolge. Jeder Schritt hängt davon ab, dass der vorherige unentdeckt bleibt.

Die Angriffskette sieht in der Regel so aus:

• Ein Angreifer verschickt eine Phishing-Nachricht, die eine bekannte Login-Seite nachbildet, oder nutzt direkt ein ungepatchtes System aus.
• Funktioniert das Phishing, gibt ein Nutzer echte Zugangsdaten weiter, ohne es zu merken.
• Der Angreifer testet diese Zugangsdaten an anderen Systemen – eine Technik, die deutlich häufiger funktioniert, wenn Passwörter wiederverwendet werden.
• Hat das kompromittierte Konto breiten, geteilten oder dauerhaften Zugriff, kann sich der Angreifer weiter ausbreiten, bevor es jemand bemerkt.

Gestohlene Zugangsdaten verursachen mehr Schaden, wenn sie weiten oder geteilten Zugriff gewähren, weil die Institution dann sowohl die Eindämmung als auch die Möglichkeit verliert, nachzuvollziehen, was passiert ist. NCSCs Einführung in die Identitäts- und Zugriffsverwaltung (IAM) macht diesen Punkt deutlich: Schwache IAM-Kontrollen lassen einen Angreifer, der eine Zugangsdatenkombination erlangt, über mehrere Systeme hinweg als legitimer Nutzer auftreten.

Fredrik Blomqvist, Chief Security Officer der Uppsala University, vertrat im März 2026 aus der eigenen Sicherheitsfunktion einer Universität heraus denselben Standpunkt: Phishing bleibt die häufigste Angriffsart, die die Institution beobachtet, und der Faktor Mensch – nicht der Technologie-Stack – ist weiterhin ihr größtes Cybersicherheitsrisiko.

Zugriff durch Drittanbieter erweitert das Zugangsdatenrisiko

Externe Anbieter schaffen eine zusätzliche Angriffsfläche, da Bildungseinrichtungen Schülerinformationssysteme, Lernplattformen und Zahlungsabwicklung routinemäßig auslagern. Verizons DBIR 2026 fand heraus, dass die Beteiligung Dritter an Sicherheitsverletzungen 48 % aller Sicherheitsverletzungen erreichte, ein Anstieg von 60 % gegenüber dem Vorjahr. Unter diesen Drittanbieter-Organisationen hatten nur 23 % fehlende oder fehlerhafte MFA auf ihren Cloud-Konten vollständig behoben. Zugriff durch Dritte kann das Zugangsdatenrisiko über die eigenen Systeme der Institution hinaus ausweiten, sodass Lieferantenverbindungen dieselbe Prüftiefe bei Identität und Zugriff benötigen wie interne Konten.

Ransomware macht Wiederherstellung und Widerruf dringlicher

Ist ein Angreifer erst einmal im System, bestimmt die Geschwindigkeit der Eindämmung, wie viel Schaden ein einzelnes gestohlenes Zugangsdatenpaar anrichten kann. Sophos befragte 441 Bildungseinrichtungen, die im Vorjahr einen Ransomware-Angriff erlebt hatten, und stellte fest, dass 29 % der Befragten aus dem Primär- und Sekundarbereich und 58 % der Befragten aus dem Hochschulbereich einen Angriff meldeten, der zur Verschlüsselung von Daten führte. Diese Zahl beschreibt, was nach dem Eindringen eines Angreifers bei bereits betroffenen Institutionen passiert – ein Maß für die Eindämmungsgeschwindigkeit, keine Aussage über die Ursache der Sicherheitsverletzung. Das ist ein Grund, einen schnellen Widerruf von Zugangsdaten als geprüften Schritt in der Incident Response zu verankern.

Warum fehlende Zugriffsverwaltung das DSGVO- und NIS2-Compliance-Risiko erhöht

Schulen, Hochschulen und Universitäten, die personenbezogene Daten verarbeiten oder qualifizierende kritische Systeme betreiben, unterliegen der DSGVO, NIS2 oder beiden. 

• Die DSGVO wendet innerhalb festgelegter sachlicher und räumlicher Grenzen einen risikobasierten Sicherheitsstandard an. 
• NIS2 gilt für wesentliche und wichtige Einrichtungen, die die Kriterien der Richtlinie zu Einrichtungsart, Größe oder Sonderregelung erfüllen, so wie sie im nationalen Recht umgesetzt wurden. 

Die DSGVO legt einen risikobasierten Standard fest

Die DSGVO (Datenschutz-Grundverordnung) ist das zentrale Datenschutzgesetz der EU. Sie gilt für die Verarbeitung personenbezogener Daten innerhalb ihres sachlichen und räumlichen Anwendungsbereichs. Dazu zählt die Verarbeitung durch eine in der EU niedergelassene Organisation sowie bestimmte Verarbeitungen durch Organisationen außerhalb der EU, die Personen in der EU Waren oder Dienstleistungen anbieten oder deren Verhalten dort beobachten.

Artikel 5 Abs. 1 lit. f DSGVO verlangt Schutz vor unbefugter oder unrechtmäßiger Verarbeitung sowie vor unbeabsichtigtem Verlust oder unbeabsichtigter Schädigung. Artikel 32 geht weiter: Er fordert risikoangemessene Maßnahmen, gegebenenfalls einschließlich Vertraulichkeit, Integrität, Verfügbarkeit, Belastbarkeit, der Fähigkeit, den Zugriff nach einem Vorfall wiederherzustellen, und regelmäßiger Überprüfung.

Für ein Studierendensekretariat, das Schülerdaten verwaltet, bedeutet diese risikobasierte Formulierung konkrete Kontrollen: wer einen Datensatz einsehen darf, wie der Zugriff protokolliert wird und wie schnell der Zugriff wiederherstellt werden kann, wenn ein System ausfällt.

Die NIS2-Abdeckung hängt vom Anwendungsbereich ab

NIS2 (die zweite EU-Richtlinie zur Netz- und Informationssicherheit) schafft Cybersicherheitspflichten für Organisationen, die als wesentliche und wichtige Einrichtungen im Anwendungsbereich der Richtlinie eingestuft werden. Diese Einschätzung beginnt mit den eigenen Regeln der Richtlinie zu Einrichtungsart, Größe und Sonderregelung und hängt anschließend davon ab, wie der jeweilige Mitgliedstaat sie umgesetzt und angewendet hat. Bildung ist in Anhang I oder Anhang II nicht als eigenständiger Sektor aufgeführt, aber eine Schule, Hochschule oder Universität kann trotzdem über eine aufgeführte Einrichtungsart, den Status als öffentliche Verwaltung oder einen anderen anwendbaren Weg in den Anwendungsbereich fallen.

Für eine im Anwendungsbereich liegende Einrichtung verlangt Artikel 21 angemessene und verhältnismäßige Risikomanagementmaßnahmen. Erwägungsgrund 79 besagt, dass diese Maßnahmen die Sicherheit der Personalressourcen berücksichtigen und angemessene Zugriffskontrollrichtlinien umfassen sollten.

Wird einer Einrichtung ein erheblicher Vorfall bekannt, sieht Artikel 23 eine Frühwarnung innerhalb von 24 Stunden, eine Vorfallsmeldung innerhalb von 72 Stunden und einen Abschlussbericht spätestens einen Monat nach der Meldung vor. Andauernde Vorfälle folgen einem separaten Fortschrittsberichtsweg.

Um die 24-Stunden-Frist aus Artikel 23 einzuhalten, muss bekannt sein, wer Zugriff auf das kompromittierte System hatte und wann sich dieser Zugriff zuletzt geändert hat. Verwalten Abteilungen Passwörter eigenständig – eine Tabelle in einem Büro, ein per Chat weitergeleitetes Passwort in einem anderen –, ist diese Information in der Regel nirgendwo erfasst. Prüfer, die Nachweise dafür verlangen, dass Zugriffsentscheidungen verhältnismäßig, dokumentiert und überprüfbar sind, stoßen auf dieselbe Lücke.

Die Abdeckung des Bildungssektors hängt von der nationalen Umsetzung ab.  In den Niederlanden beispielsweise fallen Universitäten unter NIS2, größtenteils aufgrund des durch Forschung generierten geistigen Eigentums – die Regierung betrachtet dieses Wissen als nationales Gut. Es empfiehlt sich, den konkreten Status Ihrer Institution mit Rechts- oder Compliance-Experten zu klären, anstatt ihn in die eine oder andere Richtung anzunehmen.

Zugriffsverwaltung schließt die Lücken bei Produktivität, Risiko und Compliance

Zugriffsverwaltung beseitigt die drei oben beschriebenen Probleme: verschwendete Mitarbeiterzeit, größere Angriffsfläche und dünne Compliance-Nachweise. Sie funktioniert, indem sie Identität, Authentifizierung und Berechtigungen als einen verbundenen Prozess über alle Systeme einer Institution hinweg steuert, statt jede Anwendung ihre eigenen Passwortregeln durchsetzen zu lassen.

Ein Passwortmanager für Unternehmen ist die praktische Ebene, die das ermöglicht. 

• Zentralisierte, berechtigungsbasierte Speicherung von Zugangsdaten ersetzt die geteilte Tabelle und den Notizzettel. 
• Benannte Verantwortlichkeit und rollenbasierter Zugriff beseitigen das Rätselraten darüber, wer worauf zugreifen kann. 
• Self-Service oder delegierte Wiederherstellung reduziert die Rücksetzungswarteschlange auf die Konten, die wirklich die Hilfe der IT benötigen. 
• Audit-Protokolle und regelmäßige Zugriffsüberprüfungen liefern die dokumentierten, überprüfbaren Nachweise, die sowohl die DSGVO als auch NIS2 verlangen.

Wie Passwortmanager Bildungseinrichtungen beim Zugriffsmanagement in großem Maßstab unterstützen 

NISTs aktuelle Passwort-Richtlinie empfiehlt Multi-Faktor-Authentifizierung (MFA), behandelt Passkeys als brauchbare Alternative zu Passwörtern und empfiehlt für Konten, die weiterhin ein Passwort verwenden, Passwortmanager – sichere Zugangsdaten-Tresore, die eindeutige Passwörter generieren und speichern. Das deckt die Grundlage ab: eindeutige Zugangsdaten, sicher generiert und gespeichert, statt wiederverwendet oder aufgeschrieben.

Passwortmanager auf Enterprise-Niveau gehen weiter. Rollenbasierte Berechtigungen weisen die Verantwortlichkeit auf Tresor-Ebene zu, Audit-Protokolle und Zugriffsüberprüfungen liefern die Nachweiskette, die Prüfer verlangen, und die Verzeichnisintegration verknüpft den Kontolebenszyklus mit HR- und IT-Systemen statt mit einer manuellen Checkliste. Passworks Leitfaden zum Team-Passwortmanagement beschreibt, wie diese Bausteine in der Praxis zusammenwirken.

Auch die Wiederherstellung profitiert. Geht ein Gerät verloren oder wird eine Kompromittierung von Zugangsdaten vermutet, kann ein Administrator den Tresorzugriff dieser Person sperren und die betroffenen Zugangsdaten rotieren, ohne andere Nutzer zu stören, die weiterhin auf denselben geteilten Eintrag angewiesen sind. Ein verwaltetes System reduziert den Such- und Wiederherstellungsaufwand, den ein geteiltes Zugangsdatenpaar sonst verursacht, und lässt Administratoren über einen dokumentierten Prozess handeln, statt einen Login über Chatverläufe und Onboarding-Dokumente zu verfolgen.

Zwei Prioritäten speziell für den Bildungsbereich

Joiner-Mover-Leaver-Prozesse verdienen im Bildungsbereich besondere Aufmerksamkeit, da Veränderungen bei Studierenden, befristetem Personal, externen Dienstleistern und Semesterzeiten zu häufigen, vorhersehbar terminierten Kontoänderungen führen. Die Automatisierung von Provisionierung und Deprovisionierung rund um diese bekannten Zyklen entfernt den manuellen Schritt, bei dem der Zugriff am häufigsten übersehen wird.

Geteilte Konten sollten eine kontrollierte Ausnahme bleiben: bewusst vergeben, namentlich verantwortet und nach einem festen Rhythmus überprüft. Passworks Leitfaden zum sicheren Passwort-Sharing beschreibt, wie ein geteiltes Abteilungstool trotzdem benannte Verantwortliche und rollenbasierten Zugriff innerhalb eines sicheren Tresors mit Audit-Protokollierung haben kann, statt eines Logins, der per Chatnachricht weitergegeben wird, ohne dass erfasst ist, wer ihn besitzt.

Ein Fünf-Schritte-Startplan für IT-Verantwortliche im Bildungsbereich

Diese fünfstufige Abfolge lässt sich an den Semesterkalender anpassen, sodass IT-Teams sofort starten können, ohne auf eine systemweite Pause zu warten. Verstehen Sie sie als Ausgangspunkt, nicht als vollständigen Rollout-Plan.

• Identifizieren Sie die Systeme, bei denen verlorener oder unbefugter Zugriff den größten Schaden anrichten würde. Stufen Sie Schülerdaten, Kinderschutzdaten, Forschungssysteme und Finanzen höher ein als Tools mit geringerem Risiko.
• Erfassen Sie geteilte, privilegierte und nicht zugeordnete Konten und weisen Sie jedem einen namentlich benannten Verantwortlichen zu. Allein dieser Schritt bringt in der Regel Konten zum Vorschein, an deren Einrichtung sich niemand mehr erinnert.
• Messen Sie Ihre aktuelle Ausgangslage, bevor Sie Richtlinien ändern. Verfolgen Sie das Volumen an Rücksetzungen, Sperrungen sowie Verzögerungen beim On- oder Offboarding, damit Sie erkennen können, ob eine Änderung tatsächlich geholfen hat. Genau hier zahlt sich auch ein Konfigurationsaudit aus: Verizons DBIR 2026 fand heraus, dass in der untersuchten Geräte-Stichprobe 97 % der Geräte die Prüfung auf zulässige Anmeldeversuche vor einer Sperrung nicht bestanden und 90 % die Prüfung auf Passwörter mit mindestens 15 Zeichen nicht bestanden. Diese Lücke zwischen dokumentierter Richtlinie und tatsächlich durchgesetzter Konfiguration lohnt sich, direkt zu testen.
• Priorisieren Sie MFA und den sicheren Umgang mit Zugangsdaten zuerst für Nutzer mit hohem Risiko. Administratoren, IT-Mitarbeiter und alle mit Zugriff auf Finanz- oder Kinderschutzsysteme sollten vor der allgemeinen Studierendenschaft umgestellt werden.
• Testen Sie zunächst in einer Abteilung, bevor Sie skalieren. Führen Sie den neuen Prozess in einem einzelnen Team durch, überprüfen Sie die Kontrollen, die betriebliche Reibung und die beobachteten Ergebnisse, und erweitern Sie ihn dann. Institutionen ohne durchgehende Sicherheitsbesetzung müssen das nicht allein lösen: Polens Hochschulsektor beispielsweise organisiert gemeinsame regionale Überwachungskapazitäten speziell für Universitäten, die keine 24/7-Abdeckung intern aufbauen können.

NISTs Empfehlung, MFA zu kombinieren, Passkeys dort zu berücksichtigen, wo sie passen, und für Konten, die weiterhin ein Passwort benötigen, einen Passwortmanager zu verwenden, gilt direkt für Schritt vier. Bei Studierenden und Schülern ändert sich die Rechnung: Alter, Barrierefreiheitsbedarf und Geräteverfügbarkeit beeinflussen, welche Kontrollen für welche Gruppe sinnvoll sind. Eine Kontrolle, die für Finanzmitarbeiter funktioniert, kann für eine Zwölfjährige, die sich in einer Lese-App anmeldet, die falsche Wahl sein.

Vom Passwortchaos zu einem verwalteten System

Passwortchaos kündigt sich selten als Krise an. Es baut sich Login für Login und Rücksetzung für Rücksetzung auf, bis eine Institution nicht mehr mit Sicherheit sagen kann, wer worauf Zugriff hat. Es zu beheben bedeutet, Passwortsicherheit in Bildungseinrichtungen als Betriebsmodell zu behandeln: jedes Konto verantworten, verfolgen und als fortlaufende Praxis nach einem festen Rhythmus überprüfen.

Für Teams, die geteilte Zugangsdaten zentralisieren und den Zugriff mit bestehenden Identitätssystemen verbinden möchten, bietet Passwork kontrollierte Tresore, rollenbasierte Berechtigungen, Verzeichnissynchronisation und Audit-Aufzeichnungen. Diese Funktionen können Teile eines umfassenderen Access-Governance-Programms unterstützen. Ob sie ausreichen, hängt von den Systemen, der Konfiguration, der Risikobewertung und den weiteren Compliance-Kontrollen der Institution ab.

Häufig gestellte Fragen

Passwortchaos: Warum es ein Geschäftsproblem ist und wie man es behebt

Ein vergessenes Passwort kostet 70 US-Dollar. Eine Sicherheitsverletzung kostet 4,44 Millionen US-Dollar. Beide beginnen gleich – Zugangsdaten werden über Slack geteilt, in Tabellen gespeichert und nie rotiert. Was Passwortchaos wirklich kostet und wie man es beseitigt.

Passwork BlogAlex Muntyan

Was ist Passwortmanagement?

Passwortmanagement ist die Praxis, Passwörter und andere Authentifizierungsdaten sicher zu erstellen, zu speichern, zu organisieren und den Zugriff darauf zu kontrollieren. Es verbindet menschliche Prozesse mit spezialisierten Softwaretools, um sicherzustellen, dass jedes Konto ein starkes, eindeutiges Passwort verwendet, ohne dass sich Nutzer alle merken müssen. Ob Sie als Privatperson Ihr Online-Leben schützen oder als IT-Administrator die digitalen Werte Ihrer Organisation absichern möchten – das Verständnis von Passwortmanagement ist unerlässlich.

PassworkPasswork Team

Kindern Passwortsicherheit vermitteln: Tipps für Eltern

Ein Leitfaden für Eltern, um Kindern Passwortsicherheit zu vermitteln: echte Motivation wecken, Lektionen altersgerecht anpassen, starke Passphrasen erstellen, 2FA oder Passkeys einrichten, Phishing-Versuche erkennen und Konten gelassen über eine wiederholbare Routine aus Erstellen, Schützen, Wiederherstellen zurückgewinnen.

PassworkPasswork Team

Comienza un nuevo periodo académico y la cola de la mesa de ayuda se llena de solicitudes de restablecimiento antes de la primera clase. Un miembro del personal no puede iniciar sesión en el sistema de gestión del aprendizaje. Un departamento comparte un mismo inicio de sesión para una herramienta de investigación y nadie recuerda quién estableció la contraseña ni quién más tiene una copia de ella.

Así es como se rompe la seguridad de las contraseñas en las instituciones educativas: credenciales dispersas en docenas de sistemas y compartidas sin ninguna supervisión. Un mismo centro escolar o universidad puede gestionar inicios de sesión independientes para los expedientes del alumnado, las plataformas de aprendizaje, las herramientas de investigación y las bases de datos de finanzas, RR. HH. y protección de menores, cada uno con sus propios hábitos de contraseñas.

El caos de contraseñas se extiende más allá de la mesa de ayuda de TI al resto de la organización. El personal pierde horas tratando de recuperar el acceso en lugar de dedicarse a la enseñanza o la investigación. Las credenciales sin gestionar amplían las vías que los atacantes utilizan para entrar. Unos registros de acceso deficientes convierten una auditoría de rutina en un hallazgo de incumplimiento. La gestión de accesos es la forma en que las instituciones cierran las tres brechas a la vez.

El caos de contraseñas es un problema de continuidad del acceso

El caos de contraseñas se acumula porque nadie vuelve a revisar una decisión de acceso una vez tomada. Un inicio de sesión se comparte para un proyecto y sigue compartido después de que el proyecto termine. Un miembro del personal se añade a un sistema, cambia de puesto y conserva el acceso anterior porque nadie tiene la tarea de comprobarlo. Multiplique esto por cada sistema añadido durante una década y nadie podrá decir con certeza quién tiene acceso a qué.

Esa brecha se nota especialmente en el proceso de baja. Eliminar el acceso de un empleado que se marcha debería ser una tarea rutinaria de TI. En cambio, se convierte en una búsqueda por docenas de sistemas desconectados, porque el registro de quién tiene acceso a qué nunca se centralizó.

Cómo el caos de contraseñas ralentiza el trabajo en el sector educativo

El caos de contraseñas se manifiesta primero como tiempo perdido. Los restablecimientos, los desbloqueos y los cambios manuales de cuentas se convierten en una cola recurrente que aparta al personal de TI del soporte a la docencia y del trabajo de seguridad.

El acceso fragmentado interrumpe flujos de trabajo críticos

Entre los sistemas esenciales del sector educativo se encuentran las plataformas de gestión del aprendizaje, los sistemas de información del alumnado, los entornos de investigación, el correo electrónico, RR. HH., finanzas, los sistemas de biblioteca y los registros de protección de menores. Perder el acceso a cualquiera de ellos puede retrasar la calificación de exámenes, bloquear un plazo de investigación o dejar temporalmente inaccesible un registro de protección de menores. La gravedad depende del impacto del sistema en la actividad de la institución y de la calidad de sus mecanismos de recuperación.

Las credenciales compartidas difuminan la responsabilidad

Los inicios de sesión compartidos eliminan la trazabilidad. Cuando varias personas usan el mismo inicio de sesión para una herramienta compartida, la institución pierde la capacidad de saber quién hizo qué. Esto importa en el día a día, al investigar un cambio inesperado. Importa aún más cuando cambia un puesto y alguien debe perder el acceso sin dejar sin cuenta al resto de quienes todavía la utilizan.

Por qué el caos de contraseñas aumenta el riesgo de un incidente de seguridad

El caos de contraseñas amplía las vías que los atacantes utilizan para entrar. Las contraseñas reutilizadas, las cuentas compartidas sin gestionar y unos procesos de baja deficientes facilitan los ataques basados en credenciales y dificultan su contención.

Verizon informó, en su Data Breach Investigations Report (DBIR) de 2026, que la explotación de vulnerabilidades fue la vía de acceso inicial en el 31 % de las brechas, por delante del uso indebido de credenciales por primera vez. Pero el uso indebido de credenciales siguió apareciendo en algún punto de la cadena de ataque en el 39 % de las brechas que analizó Verizon. Una contraseña robada o reutilizada no tenía que ser el primer paso para ser relevante. Bastaba con que estuviera ahí, reutilizable, en cuanto un atacante entrara por otra puerta.

El Centro Nacional de Ciberseguridad del Reino Unido (NCSC) explica por qué se sigue produciendo esa reutilización: la sobrecarga de contraseñas fomenta comportamientos de afrontamiento inseguros, como la reutilización, las fórmulas predecibles y el almacenamiento inseguro. Decirle al personal que «elija una contraseña más segura» no soluciona un sistema en el que doce departamentos mantienen cada uno su propia hoja de cálculo de inicios de sesión compartidos. ENISA informa, en su Threat Landscape 2025, que el phishing siguió siendo el método principal de intrusión inicial y una técnica eficaz para el robo de credenciales y el secuestro de sesiones, exactamente el tipo de robo que las credenciales sin gestionar y reutilizadas facilitan.

Cómo una credencial robada se convierte en una brecha

Rara vez una sola contraseña reutilizada permanece limitada a una cuenta. Los atacantes avanzan desde el primer inicio de sesión comprometido hacia un acceso más amplio siguiendo una secuencia predecible. Cada paso depende de que el anterior pase inadvertido.

La cadena de ataque suele seguir este patrón:

• Un atacante envía un mensaje de phishing que imita una página de inicio de sesión conocida, o explota directamente un sistema sin parchear.
• Si el phishing funciona, un usuario entrega credenciales reales sin darse cuenta.
• El atacante prueba esas credenciales en otros sistemas, una técnica que funciona con mucha más frecuencia cuando las contraseñas se reutilizan.
• Si la cuenta comprometida tiene un acceso amplio, compartido o persistente, el atacante puede avanzar más antes de que alguien lo note.

Una credencial robada causa más daño cuando concede un acceso amplio o compartido, porque la institución pierde tanto la contención como la capacidad de rastrear lo ocurrido. NCSC lo expone directamente en su introducción a la gestión de identidades y accesos: unos controles de IAM débiles permiten que un atacante que obtiene una sola credencial se presente como un usuario legítimo en varios sistemas.

Fredrik Blomqvist, director de seguridad de la Universidad de Upsala, planteó la misma idea desde dentro de la propia función de seguridad de una universidad en marzo de 2026: el phishing sigue siendo el tipo de ataque más frecuente que observa la institución, y el factor humano, no la pila tecnológica, sigue siendo su mayor riesgo de ciberseguridad.

El acceso de terceros amplía el riesgo de las credenciales

Los proveedores externos añaden otra capa de exposición, porque las instituciones educativas suelen externalizar los sistemas de información del alumnado, las plataformas de aprendizaje y el procesamiento de pagos. Verizon constató, en su DBIR de 2026, que la participación de terceros alcanzó el 48 % de todas las brechas, un 60 % más que el año anterior. Entre esas organizaciones externas, solo el 23 % había corregido por completo la falta o la configuración incorrecta de la MFA en sus cuentas en la nube. El acceso de terceros puede extender el riesgo de las credenciales más allá de los sistemas propios de la institución, por lo que las conexiones con proveedores necesitan el mismo nivel de revisión de identidad y accesos que las cuentas internas.

El ransomware hace más urgentes la recuperación y la revocación

Una vez que un atacante está dentro, la velocidad de contención determina cuánto daño puede causar una sola credencial robada. Sophos encuestó a 441 instituciones educativas que habían sufrido un ataque de ransomware en el año anterior y constató que el 29 % de los encuestados de centros de enseñanza no universitaria y el 58 % de los de educación superior declararon un ataque que provocó el cifrado de datos. Esa cifra describe lo que ocurre después de que un atacante entra, entre instituciones que ya han sido atacadas: es una medida de la velocidad de contención, no una afirmación sobre la causa de la brecha. Es una razón para tratar la revocación rápida de credenciales como un paso probado en la respuesta a incidentes.

Por qué la falta de gestión de accesos aumenta el riesgo de cumplimiento del RGPD y de NIS2

Los centros escolares y las universidades que tratan datos personales o gestionan sistemas críticos que cumplen los requisitos quedan sujetos al RGPD, a NIS2 o a ambos. 

• El RGPD aplica una norma de seguridad basada en el riesgo dentro de unos límites materiales y territoriales definidos. 
• NIS2 se aplica a las entidades esenciales e importantes que cumplen los criterios de tipo de entidad, tamaño o vía especial de la directiva, según se haya transpuesto en el derecho nacional. 

El RGPD establece una norma basada en el riesgo

El RGPD (Reglamento General de Protección de Datos) es la ley fundamental de protección de datos de la UE. Se aplica al tratamiento de datos personales dentro de su ámbito material y territorial. Esto incluye el tratamiento en el contexto de una organización establecida en la UE, así como determinados tratamientos realizados por organizaciones fuera de la UE que ofrecen bienes o servicios a personas en la UE o que supervisan su comportamiento allí.

El artículo 5, apartado 1, letra f), del RGPD exige protección frente al tratamiento no autorizado o ilícito y frente a la pérdida o el daño accidental. El artículo 32 va más allá: exige medidas adecuadas al riesgo, incluyendo, cuando proceda, la confidencialidad, la integridad, la disponibilidad, la resiliencia, la capacidad de restablecer el acceso tras un incidente y la realización de pruebas periódicas.

Para una oficina de registro académico que custodia expedientes de alumnos, ese lenguaje basado en el riesgo se traduce en controles prácticos: quién puede ver un expediente, cómo se registra el acceso y con qué rapidez puede restablecerse el acceso si un sistema falla.

La cobertura de NIS2 depende del ámbito de aplicación

NIS2 (la segunda Directiva de la UE sobre Seguridad de las Redes y de la Información) crea obligaciones de ciberseguridad para las organizaciones clasificadas como entidades esenciales e importantes que entran dentro del ámbito de la directiva. Esa evaluación comienza con las propias normas de la directiva sobre tipo de entidad, tamaño y vías especiales, y después depende de cómo el Estado miembro correspondiente las haya transpuesto y aplicado. La educación no figura como sector independiente en el anexo I ni en el anexo II, pero un centro escolar, una universidad o un instituto superior pueden entrar en el ámbito de aplicación a través de un tipo de entidad incluido en la lista, de su condición de administración pública o de otra vía aplicable.

Para una entidad incluida en el ámbito de aplicación, el artículo 21 exige medidas de gestión de riesgos que sean adecuadas y proporcionadas. El considerando 79 establece que esas medidas deben abordar la seguridad de los recursos humanos e incluir políticas de control de acceso adecuadas.

Para una entidad que tenga conocimiento de un incidente significativo, el artículo 23 establece una fase de alerta temprana dentro de las 24 horas, una fase de notificación del incidente dentro de las 72 horas y un informe final a más tardar un mes después de la notificación. Los incidentes en curso siguen una vía independiente de informes de progreso.

Cumplir el plazo de 24 horas del artículo 23 exige saber quién tenía acceso al sistema comprometido y cuándo cambió ese acceso por última vez. Cuando los departamentos gestionan las contraseñas de forma independiente (una hoja de cálculo en una oficina, una contraseña reenviada por chat en otra), esa información normalmente no queda registrada en ningún sitio. Los auditores que pidan pruebas de que las decisiones de acceso son proporcionadas, están documentadas y pueden revisarse encontrarán la misma carencia.

La cobertura del sector educativo depende de la aplicación nacional.  En los Países Bajos, por ejemplo, las universidades quedan sujetas a NIS2, principalmente por la propiedad intelectual generada a través de la investigación: el gobierno considera que ese conocimiento es un activo nacional. Recomendamos confirmar la situación específica de su institución con especialistas jurídicos o de cumplimiento normativo, en lugar de asumir una cosa u otra.

La gestión de accesos cierra las brechas de productividad, riesgo y cumplimiento

La gestión de accesos es lo que elimina los tres problemas descritos anteriormente: el tiempo de personal desperdiciado, la mayor exposición a brechas y unas evidencias de cumplimiento insuficientes. Funciona controlando la identidad, la autenticación y los permisos como un único proceso conectado en todos los sistemas que utiliza una institución, en lugar de dejar que cada aplicación aplique sus propias normas de contraseñas.

Un gestor de contraseñas empresarial es la capa práctica que hace esto posible. 

• El almacenamiento centralizado y controlado por permisos de las credenciales sustituye a la hoja de cálculo compartida y a la nota adhesiva. 
• La propiedad designada y el acceso basado en roles eliminan las conjeturas sobre quién puede acceder a qué. 
• La recuperación autogestionada o delegada reduce la cola de restablecimientos a las cuentas que realmente necesitan la ayuda de TI. 
• Los registros de auditoría y las revisiones periódicas de accesos generan las evidencias documentadas y revisables que exigen tanto el RGPD como NIS2.

Cómo los gestores de contraseñas ayudan al sector educativo a gestionar el acceso a gran escala 

NIST recomienda, en su guía actual sobre contraseñas, la autenticación multifactor (MFA), considera las passkeys una alternativa viable a las contraseñas y recomienda los gestores de contraseñas, bóvedas seguras de credenciales que generan y almacenan contraseñas únicas, para las cuentas que todavía utilizan una. Esto cubre el nivel básico: credenciales únicas, generadas y almacenadas de forma segura, en lugar de reutilizadas o anotadas.

Los gestores de contraseñas de nivel empresarial van más allá. Los permisos basados en roles asignan la propiedad a nivel de bóveda, los registros de auditoría y las revisiones de accesos generan el rastro de evidencias que piden los auditores, y la integración con el directorio vincula el ciclo de vida de las cuentas a los sistemas de RR. HH. y de TI en lugar de a una lista de verificación manual. La guía de Passwork sobre la gestión de contraseñas en equipo explica cómo funcionan estas piezas juntas en la práctica.

La recuperación también se beneficia. Cuando se pierde un dispositivo o se sospecha que una credencial está comprometida, un administrador puede suspender el acceso a la bóveda de esa persona y rotar las credenciales afectadas sin afectar a otros usuarios que todavía dependen de la misma entrada compartida. Un sistema gestionado reduce el trabajo de búsqueda y recuperación que de otro modo genera una credencial compartida, y permite que los administradores actúen mediante un proceso documentado en lugar de rastrear un inicio de sesión a través de hilos de chat y documentos de incorporación.

Dos prioridades específicas del sector educativo

Los procesos de alta, cambio y baja merecen especial atención en el sector educativo, porque los cambios de alumnado, personal temporal, contratistas y los propios del calendario académico generan cambios de cuenta frecuentes en un calendario predecible. Automatizar el aprovisionamiento y el desaprovisionamiento en torno a esos ciclos conocidos elimina el paso manual en el que el acceso se queda atrás con más frecuencia.

Las cuentas compartidas deben seguir siendo una excepción controlada: concedidas de forma deliberada, con un propietario identificado y revisadas según un calendario. La guía de Passwork sobre el uso compartido seguro de contraseñas explica cómo una herramienta departamental compartida puede tener propietarios identificados y acceso basado en roles dentro de una bóveda segura con registro de auditoría, en lugar de un único inicio de sesión que circula por mensajes de chat sin ningún registro de quién lo tiene.

Un plan inicial de cinco pasos para responsables de TI del sector educativo

Esta secuencia de cinco pasos se adapta al calendario académico, de modo que los equipos de TI pueden empezar ahora sin esperar una pausa generalizada. Trátela como un punto de partida, no como un plan de implementación completo.

• Identifique los sistemas en los que la pérdida de acceso o el acceso no autorizado causarían más daño. Priorice los expedientes del alumnado, los datos de protección de menores, los sistemas de investigación y finanzas por delante de las herramientas de menor riesgo.
• Inventaríe las cuentas compartidas, privilegiadas y sin propietario, y asigne un propietario identificado a cada una. Solo este paso suele revelar cuentas que nadie recuerda haber creado.
• Mida su punto de partida actual antes de cambiar la política. Realice un seguimiento del volumen de restablecimientos, los bloqueos y los retrasos en la incorporación o la baja, para poder comprobar si un cambio realmente ayudó. Aquí es también donde una auditoría de configuración demuestra su valor: Verizon constató, en su DBIR de 2026, que en su muestra de dispositivos evaluados, el 97 % no superó la comprobación del número de intentos de inicio de sesión permitidos antes del bloqueo, y el 90 % no superó la comprobación que exige contraseñas de al menos 15 caracteres. Vale la pena comprobar directamente esa diferencia entre la política documentada y la configuración aplicada.
• Priorice primero la MFA y el manejo seguro de credenciales para los usuarios de mayor riesgo. Los administradores, el personal de TI y cualquier persona con acceso a sistemas financieros o de protección de menores deben pasar a esta fase antes que el conjunto del alumnado.
• Pilote el proceso en un departamento antes de escalarlo. Ejecute el nuevo proceso en un solo equipo, revise los controles, la fricción operativa y los resultados observados, y después amplíelo. Las instituciones sin personal de seguridad permanente no tienen por qué resolver esto solas: el sector de educación superior de Polonia, por ejemplo, está organizando una capacidad de supervisión regional compartida específicamente para las universidades que no pueden crear una cobertura propia las 24 horas del día, los 7 días de la semana.

La recomendación de NIST de combinar la MFA, valorar las passkeys donde resulten adecuadas y usar un gestor de contraseñas para las cuentas que todavía necesiten una se aplica directamente al cuarto paso. En el caso del alumnado, el cálculo cambia: la edad, las necesidades de accesibilidad y la disponibilidad de dispositivos determinan qué controles tienen sentido para cada grupo. Un control que funciona para el personal de finanzas puede no ser adecuado para un niño de doce años que inicia sesión en una aplicación de lectura.

Del caos de contraseñas a un sistema gestionado

El caos de contraseñas rara vez se presenta como una crisis. Se acumula un inicio de sesión compartido y un restablecimiento manual a la vez, hasta que una institución no puede decir con certeza quién tiene acceso a qué. Solucionarlo implica tratar la seguridad de las contraseñas en las instituciones educativas como un modelo operativo: asignar la propiedad de cada cuenta, hacerle seguimiento y revisarla según un calendario, como una práctica continua.

Para los equipos que estén listos para centralizar las credenciales compartidas y conectar el acceso a los sistemas de identidad existentes, Passwork ofrece bóvedas controladas, permisos basados en roles, sincronización con el directorio y registros de auditoría. Estas funciones pueden respaldar partes de un programa más amplio de gobernanza de accesos. Su idoneidad depende de los sistemas, la configuración, la evaluación de riesgos y los controles de cumplimiento más amplios de la institución.

Preguntas frecuentes

Caos de contraseñas: Por qué es un problema de negocio y cómo solucionarlo

Una contraseña olvidada cuesta 70 dólares. Una brecha cuesta 4,44 millones de dólares. Ambas empiezan igual: credenciales compartidas por Slack, guardadas en hojas de cálculo, nunca rotadas. Esto es lo que realmente cuesta el caos de contraseñas y cómo eliminarlo.

Passwork BlogAlex Muntyan

¿Qué es la gestión de contraseñas?

La gestión de contraseñas es la práctica de crear, almacenar, organizar y controlar de forma segura el acceso a las contraseñas y otras credenciales de autenticación. Combina procesos humanos con herramientas de software especializadas para garantizar que cada cuenta utilice una contraseña fuerte y única sin exigir a los usuarios que las memoricen todas. Tanto si es una persona que busca proteger su vida en línea como un administrador de TI que protege los activos digitales de su organización, comprender la gestión de contraseñas es esencial.

PassworkPasswork Team

Cómo enseñar a los niños sobre seguridad de contraseñas: Consejos para padres

Una guía para padres sobre cómo enseñar seguridad de contraseñas a los niños: despertar una motivación real, adaptar las lecciones según la edad, crear frases de contraseña seguras, añadir 2FA o passkeys, detectar intentos de phishing y recuperar cuentas con calma mediante una rutina repetible de Crear, Proteger, Recuperar.

PassworkPasswork Team

A new term starts, and the helpdesk queue fills with reset requests before the first lecture begins. A staff member can't log into the learning management system. A department shares one login for a research tool, and nobody remembers who set the password or who else has a copy of it.

That's what breaks password security for educational institutions: credentials scattered across dozens of systems and shared without oversight. A single school or university might run separate logins for student records, learning platforms, research tools, and finance, HR, and safeguarding databases — each with its own password habits.

Password chaos spreads past the IT helpdesk into the rest of the organization. Staff lose hours chasing access instead of teaching or research. Unmanaged credentials widen the paths attackers use to get in. Weak access records turn a routine audit into a compliance finding. Access management is how institutions close all three gaps at once.

Password chaos is an access-continuity problem

Password chaos accumulates because nothing revisits an access decision once it's made. A login gets shared for one project and stays shared after the project ends. A staff member gets added to a system, changes roles, and keeps the old access because no one is assigned to check. Multiply that by every system added over a decade, and no one can say with confidence who has access to what.

That gap surfaces hardest during offboarding. Removing a leaving staff member's access should be a routine IT task. Instead it becomes a search across dozens of disconnected systems, because the record of who has access to what was never centralized in the first place.

How password chaos slows education work

Password chaos shows up first as lost time. Resets, unlocks, and manual account changes turn into a recurring queue that pulls IT staff away from teaching-support and security work.

Fragmented access interrupts critical workflows

Essential systems in education include learning-management platforms, student-information systems, research environments, email, HR, finance, library systems, and safeguarding records. Losing access to any of these can delay grading, block a research deadline, or leave a safeguarding record temporarily unreachable. How severe that becomes depends on the system's business impact and the quality of its recovery arrangements.

Shared credentials obscure responsibility

Shared logins erase accountability. When several people use one login for a shared tool, the institution loses the ability to say who did what. That matters day to day, when troubleshooting an unexpected change. It matters more when a role changes and someone needs to lose access without breaking the account for everyone else still using it.

Why password chaos raises the risk of a security incident

Password chaos widens the paths attackers use to get in. Reused passwords, unmanaged shared accounts, and weak offboarding make credential-based attacks easier to pull off and harder to contain.

Verizon's 2026 Data Breach Investigations Report found vulnerability exploitation leading initial access in 31% of breaches, ahead of credential abuse for the first time. But credential abuse still showed up somewhere in the attack chain of 39% of the breaches Verizon analyzed. A stolen or reused password didn't have to be the opening move to matter. It just had to be sitting there, reusable, once an attacker got in through some other door.

The UK's National Cyber Security Centre explains why that reuse keeps happening: password overload encourages insecure coping behavior such as reuse, predictable formulas, and unsafe storage. Telling staff to "choose a stronger password" doesn't fix a system where twelve departments each keep their own spreadsheet of shared logins. ENISA's 2025 Threat Landscape reports that phishing remained the primary method for initial intrusion and an effective technique for credential theft and session hijacking — exactly the kind of theft that unmanaged, reused credentials make easier to pull off.

How a stolen credential turns into a breach

A single reused password rarely stays contained to one account. Attackers move from the first compromised login to broader access in a predictable sequence. Each step depends on the last one going unnoticed.

The attack chain usually looks like this:

• An attacker sends a phishing message that mimics a familiar login page, or exploits an unpatched system directly.
• If phishing works, a user hands over real credentials without realizing it.
• The attacker tests those credentials against other systems, a technique that works far more often when passwords are reused.
• If the compromised account has broad, shared, or persistent access, the attacker can move further before anyone notices.

A stolen credential does more damage when it grants wide or shared access, because the institution loses both containment and the ability to trace what happened. NCSC's introduction to identity and access management makes this point directly: weak IAM controls let an attacker who obtains one credential appear as a legitimate user across multiple systems.

Fredrik Blomqvist, Uppsala University's Chief Security Officer, made the same point from inside a university's own security function in March 2026: phishing remains the most common attack type the institution sees, and the human factor, not the technology stack, is still its greatest cybersecurity risk.

Third-party access extends credential risk

External vendors add another layer of exposure, because education institutions routinely outsource student-information systems, learning platforms, and payment processing. Verizon's 2026 DBIR found third-party involvement in breaches reached 48% of all breaches, up 60% year over year. Among those third-party organizations, only 23% had fully remediated missing or improper MFA on their cloud accounts. Third-party access can extend credential risk beyond the institution's own systems, so vendor connections need the same level of identity and access review as internal accounts.

Ransomware makes recovery and revocation more urgent

Once an attacker is inside, the speed of containment determines how much damage a single stolen credential can do. Sophos surveyed 441 education institutions that had experienced a ransomware attack in the prior year and found that 29% of lower-education respondents and 58% of higher-education respondents reported an attack that resulted in data encryption. That figure describes what happens after an attacker gets in among institutions already hit, a containment-speed measure rather than a cause-of-breach statement. It's a reason to treat fast credential revocation as a tested step in incident response.

Why the lack of access management raises GDPR and NIS2 compliance risk

Schools, colleges, and universities that handle personal data or operate qualifying critical systems fall under GDPR, NIS2, or both. 

• GDPR applies a risk-based security standard within defined material and territorial limits. 
• NIS2 applies to essential and important entities that meet the Directive's entity-type, size, or special-route criteria, as implemented under national law. 

GDPR sets a risk-based standard

GDPR (General Data Protection Regulation) is the EU's core data-protection law. It applies to processing of personal data within its material and territorial scope. This includes processing in the context of an organization established in the EU, as well as certain processing by organizations outside the EU that offer goods or services to people in the EU or monitor their behavior there.

GDPR's Article 5(1)(f) requires protection against unauthorized or unlawful processing and against accidental loss or damage. Article 32 goes further: it calls for measures appropriate to risk, including, as appropriate, confidentiality, integrity, availability, resilience, the ability to restore access after an incident, and regular testing.

For a registrar's office holding student records, that risk-based language translates into practical controls: who can view a record, how access is logged, and how quickly access can be restored if a system goes down.

NIS2 coverage depends on scope

NIS2 (the EU's second Network and Information Security Directive) creates cybersecurity obligations for organizations classified as essential and important entities that fall within the Directive's scope. That assessment begins with the Directive's own entity-type, size, and special-route rules, then depends on how the relevant member state has transposed and applied them. Education is not listed as a standalone sector in Annex I or Annex II, but a school, college, or university may still be in scope through a listed entity type, public-administration status, or another applicable route.

For an entity in scope, Article 21 requires risk-management measures that are appropriate and proportionate. Recital 79 states that those measures should address human-resources security and include appropriate access-control policies.

For an entity that becomes aware of a significant incident, Article 23 sets an early-warning stage within 24 hours, an incident-notification stage within 72 hours, and a final report no later than one month after notification. Ongoing incidents follow a separate progress-report path.

Meeting Article 23's 24-hour clock requires knowing who had access to the compromised system and when that access last changed. Where departments manage passwords independently — a spreadsheet in one office, a password forwarded over chat in another — that information typically isn't recorded anywhere. Auditors asking for evidence that access decisions are proportionate, documented, and reviewable will find the same gap.

Coverage of the education sector depends on national implementation.  In the Netherlands, for instance, universities fall under NIS2 largely because of the intellectual property generated through research — the government considers that knowledge a national asset. We recommend confirming your institution's specific status with legal or compliance specialists rather than assuming it either way.

Access management closes the productivity, risk, and compliance gaps

Access management is what eliminates the three problems described above: wasted staff time, wider breach exposure, and thin compliance evidence. It works by controlling identity, authentication, and permissions as one connected process across every system an institution runs, instead of leaving each application to enforce its own password rules.

A business password manager is the practical layer that makes this possible. 

• Centralized, permissioned credential storage replaces the shared spreadsheet and the sticky note. 
• Named ownership and role-based access remove the guesswork over who can reach what. 
• Self-service or delegated recovery cuts the reset queue down to the accounts that genuinely need IT's help. 
• Audit logs and periodic access reviews produce the documented, reviewable evidence GDPR and NIS2 both ask for.

How password managers help education manage access at scale 

NIST's current password guidance recommends multi-factor authentication (MFA), treats passkeys as a viable alternative to passwords, and recommends password managers, secure credential vaults that generate and store unique passwords, for accounts that still use one. That covers the baseline: unique credentials, generated and stored securely, instead of reused or written down.

Enterprise-grade password managers extend further. Role-based permissions assign ownership at the vault level, audit logs and access reviews produce the evidence trail auditors ask for, and directory integration ties account lifecycle to HR and IT systems instead of a manual checklist. Passwork's guide to team password management covers how these pieces work together in practice.

Recovery benefits too. When a device goes missing or a credential is suspected compromised, an administrator can suspend that person's vault access and rotate the affected credentials without disrupting other users still relying on the same shared entry. A managed system reduces the search-and-recovery work a shared credential otherwise creates, and lets administrators act through a documented process rather than tracking a login across chat threads and onboarding documents.

Two priorities specific to education

Joiner, mover, and leaver processes deserve particular attention in education, because student, temporary-staff, contractor, and term-time changes create frequent account changes on a predictable calendar. Automating provisioning and deprovisioning around those known cycles removes the manual step where access most often gets left behind.

Shared accounts should stay a controlled exception: granted deliberately, owned by name, and reviewed on a schedule. Passwork's guide to secure password sharing covers how a shared departmental tool can still have named owners and role-based access inside a secure vault with audit logging, rather than one login circulated by chat message with no record of who has it.

A five-step starting plan for education IT leaders

This five-step sequence fits around a term calendar, so IT teams can start now without waiting for a system-wide pause. Treat it as a starting point, not a complete rollout plan.

• Identify the systems where lost or unauthorized access would do the most damage. Rank student records, safeguarding data, research systems, and finance ahead of lower-stakes tools.
• Inventory shared, privileged, and unowned accounts, and assign a named owner to each. This step alone usually surfaces accounts nobody remembers creating.
• Measure your current baseline before changing policy. Track reset volume, lockouts, and onboarding or offboarding delays, so you can tell whether a change actually helped. This is also where a configuration audit earns its keep: Verizon's 2026 DBIR found that in its assessed-device sample, 97% of devices failed the check for allowed login attempts before lockout, and 90% failed the check requiring passwords of at least 15 characters. That gap between documented policy and enforced configuration is worth testing directly.
• Prioritize MFA and secure credential handling for high-risk users first. Administrators, IT staff, and anyone with access to financial or safeguarding systems should move before the general student population.
• Pilot in one department before scaling. Run the new process in a single team, review the controls, operational friction, and outcomes observed, then extend it. Institutions without round-the-clock security staffing aren't limited to solving this alone: Poland's higher-education sector, for example, is organizing shared regional monitoring capacity specifically for universities that can't build 24/7 coverage in-house.

NIST's guidance to combine MFA, consider passkeys where they fit, and use a password manager for accounts that still need one applies directly to step four. For students, the calculus changes: age, accessibility needs, and device availability affect which controls make sense for which group. A control that works for finance staff may be the wrong fit for a twelve-year-old logging into a reading app.

Getting from password chaos to a managed system

Password chaos rarely announces itself as a crisis. It builds up one shared login and one manual reset at a time, until an institution can't say with confidence who has access to what. Fixing it means treating password security for educational institutions as an operating model: own each account, track it, and review it on a schedule as an ongoing practice.

For teams ready to centralize shared credentials and connect access to existing identity systems, Passwork provides controlled vaults, role-based permissions, directory synchronization, and audit records. These capabilities can support parts of a broader access-governance program. Their adequacy depends on the institution's systems, configuration, risk assessment, and wider compliance controls.

Frequently asked questions

Password chaos: Why it’s a business problem and how to fix it

A forgotten password costs $70. A breach costs $4.44 million. Both start the same way — credentials shared over Slack, stored in spreadsheets, never rotated. Here’s what password chaos actually costs and how to eliminate it.

Passwork BlogAlex Muntyan

What is password management?

Password management is the practice of securely creating, storing, organizing, and controlling access to passwords and other authentication credentials. It combines human processes with specialized software tools to ensure that every account uses a strong, unique password without requiring users to memorize them all. Whether you’re an individual trying to secure your online life or an IT administrator protecting your organization’s digital assets, understanding password management is essential.

PassworkPasswork Team

How to teach children about password security: Tips for parents

A parent’s guide to teaching kids password security: spark real motivation, tailor lessons by age, build strong passphrases, add 2FA or passkeys, spot phishing attempts, and recover accounts calmly through a repeatable Create, Protect, Recover routine.

PassworkPasswork Team

A gestão de acessos deve ocupar o início de uma lista de verificação de cibersegurança para PME, porque determina quem pode aceder aos sistemas em que a empresa funciona. Quando o acesso é pouco claro ou excessivo, uma correção, uma cópia de segurança ou uma ferramenta de segurança não conseguem impedir de forma fiável que a pessoa errada chegue aos dados da empresa.

Numa pequena e média empresa (PME), a gestão de acessos consiste em controlar quatro elementos: 

• Identidade: quem existe nos sistemas
• Autenticação: como essas pessoas provam quem são 
• Autorização: o que podem fazer depois de entrarem
• Revogação: como esse acesso desaparece quando deve 

A lista de verificação de cibersegurança para pequenas empresas do Passwork apresenta a base completa de que uma PME necessita. Este artigo aprofunda um elemento dessa base: como configurar identidade, autenticação, autorização e revogação como um sistema que se mantém eficaz no dia a dia.

Porque a gestão de acessos abre a lista de verificação de cibersegurança para PME

A gestão de acessos vem em primeiro lugar porque todos os outros controlos dependem dela. As cópias de segurança, a proteção de endpoints e as ferramentas de monitorização partem do princípio de que as contas que lhes acedem são as corretas, com as permissões certas, no momento certo.

A gestão de identidades e acessos (IAM) é a disciplina que trata deste domínio. NIST descreve a IAM como «uma capacidade de cibersegurança fundamental e crítica», centrada em garantir que as pessoas e as entidades certas têm o acesso certo aos recursos certos no momento certo. A autenticação confirma que um utilizador ou um sistema é quem afirma ser. A autorização determina o que esse utilizador ou sistema pode fazer depois de iniciar sessão. Ambas as etapas têm de funcionar para que qualquer controlo posterior tenha efeito.

Esta dependência manifesta-se em toda a empresa:

• As contas de correio eletrónico e de SaaS são a via de acesso às redefinições de palavras-passe, aos documentos partilhados e aos registos de clientes
• Os direitos de administrador nos endpoints determinam se um utilizador pode instalar software ou desativar definições de segurança
• As contas de administrador de cópias de segurança e as permissões de armazenamento na nuvem determinam se os dados de recuperação podem ser alterados ou eliminados
• O acesso de prestadores de serviços e fornecedores determina se as pessoas externas à empresa mantêm o acesso depois de um projeto terminar
• A resposta a incidentes depende da capacidade de desativar contas, revogar sessões e rastrear quem acedeu a determinada credencial

IBM, no relatório 2026 Cost of a Data Breach Report, situa o custo médio global de uma violação de dados em 4,99 milhões de dólares. Este valor ilustra por que razão as decisões de acesso subjacentes a uma violação têm um peso real.

Inventariar cada identidade e cada via de acesso

Um inventário de identidades lista todos os tipos de conta que podem aceder aos recursos da empresa, juntamente com a pessoa ou a equipa responsável por cada um. Vai além de uma lista genérica de ativos, porque atribui um responsável a cada entrada, incluindo as contas partilhadas, automatizadas ou externas ao sistema de processamento salarial.

Comece por separar as identidades humanas das não humanas. Os colaboradores e os administradores precisam de contas individuais. Os fornecedores, os prestadores de serviços e as caixas de correio partilhadas precisam de um responsável identificado, mesmo que a própria conta seja utilizada por mais de uma pessoa. As contas de serviço e as chaves de API, as credenciais que as aplicações utilizam para comunicar entre si, exigem a mesma responsabilização, uma vez que muitas vezes têm permissões que nenhuma conta humana possui.

Uma palavra-passe partilhada, um token de API ou um início de sessão num portal de fornecedor que não possa ser substituído de imediato continua a precisar de um responsável registado desde já. Esse único campo transforma um inventário em algo sobre o qual é possível agir durante uma revisão ou um incidente.

Autenticar identidades fortes e autorizar apenas o acesso necessário

A autenticação e a autorização são o ponto em que a maioria das tomadas de controlo de contas tem êxito ou falha. Aplicar a MFA às contas certas, substituir os inícios de sessão partilhados por acessos nominais e definir funções com base nas tarefas reais fecha as lacunas que os atacantes mais utilizam para entrar e circular no interior dos sistemas.

Aplicar a MFA às contas que controlam a empresa

A autenticação multifator (MFA), um método de início de sessão que exige mais do que um fator de verificação, deve ser imposta através de controlos técnicos e verificada. CISA orienta as pequenas empresas a impor a MFA com controlos técnicos e a ativá-la em todas as contas de administrador. Convém começar pelas contas de correio eletrónico, de administrador, de acesso remoto, financeiras, de armazenamento na nuvem e de dados sensíveis, uma vez que são as que dão ao atacante maior alcance se forem comprometidas.

A autenticação resistente a phishing associa o início de sessão ao serviço legítimo, o que dificulta muito a reutilização de credenciais roubadas. As chaves de segurança FIDO2 e as passkeys são os exemplos atuais. NIST SP 800-63B Revision 4 exige que as aplicações no Authenticator Assurance Level 2 (AAL2) ofereçam uma opção resistente a phishing, sem a impor como método único para todas as empresas. Esta opção deve ser encarada como a direção a seguir, primeiro nas contas de maior risco e depois nos restantes inícios de sessão, à medida que a configuração o permitir.

Documente separadamente os percursos de recuperação. Limite quem pode repor a MFA de outra pessoa, proteja qualquer conta de emergência break-glass com um responsável identificado e uso limitado e reveja essa conta após cada utilização.

Tornar viáveis as credenciais únicas com um gestor de palavras-passe controlado

O credential stuffing é a reutilização automatizada de pares de nome de utilizador e palavra-passe roubados noutros serviços. Funciona porque as pessoas reutilizam a mesma palavra-passe em várias contas, pelo que uma única credencial divulgada dá aos atacantes uma chave que serve em várias portas. Verizon, no relatório 2026 Data Breach Investigations Report, atribui ao abuso de credenciais 13 % dos vetores de acesso inicial e às credenciais 28 % dos tipos de dados roubados em violações.

As palavras-passe únicas travam esse ataque: uma credencial divulgada só abre o serviço de onde foi divulgada. O objetivo prático são credenciais únicas, controladas pela organização e com acesso nominal, que substituam a folha de cálculo ou a mensagem de chat em que demasiadas equipas ainda confiam. Uma política de gestão de palavras-passe que exija uma palavra-passe única e gerada para cada conta dá a este objetivo uma base escrita. Um gestor de palavras-passe concebido para equipas torna essa política realista no dia a dia, gerando e armazenando credenciais e controlando exatamente quem as pode obter.

Definir funções com base no trabalho e remover os direitos de administrador permanentes

O controlo de acesso baseado em funções (RBAC) atribui permissões com base nas funções profissionais atuais, e não no historial acumulado. Cada administrador deve ainda possuir uma conta padrão separada para o trabalho diário, para que tarefas rotineiras como o correio eletrónico e a navegação nunca sejam executadas a partir de um início de sessão com privilégios elevados.

Um exemplo breve: o pessoal de finanças tem acesso aos sistemas de contabilidade, o pessoal de suporte tem acesso à plataforma de helpdesk e os administradores de TI têm acesso administrativo aprovado à infraestrutura. Os responsáveis pelas aplicações aprovam as atribuições de funções; a TI confirma que a configuração técnica corresponde à aprovação.

Substituir o acesso partilhado anónimo por acesso com responsabilização

As contas individuais garantem melhor responsabilização do que os inícios de sessão partilhados, uma vez que cada ação pode ser atribuída a uma só pessoa. Algumas ferramentas legadas e portais de fornecedores continuam a impor credenciais partilhadas. Nesse caso, a credencial deve ser armazenada num cofre controlado, com acesso nominal por utilizador, permissões de menor privilégio, um registo de auditoria e um acionador de rotação agendado.

O ciclo de controlo de acessos das PME

O acesso tem de mudar à medida que as pessoas e as funções mudam, e alguém tem de confirmar que a mudança foi realmente efetuada. O ciclo de vida joiner-mover-leaver descreve os três momentos em que o acesso tem de ser atualizado: quando alguém entra, quando muda de função e quando sai.

A integração de colaboradores, uma mudança de função, o fim de um contrato, uma inatividade prolongada, uma alteração de sistema ou uma suspeita de comprometimento devem desencadear uma atualização de acessos. Em vez de adotar um prazo universal para a saída de colaboradores, convém documentar um nível de serviço baseado no risco para a empresa e confirmar, em cada caso, que foi cumprido.

Cenário ilustrativo: um gestor comercial sai da empresa. A equipa de TI tem de verificar a conta no fornecedor de identidade, a sessão de correio eletrónico ativa, a função no CRM, as permissões de partilha no armazenamento na nuvem, o acesso por VPN, o dispositivo móvel e qualquer pertença a cofres de credenciais. Se um único destes elementos for omitido, fica um caminho ativo para os sistemas da empresa depois de a pessoa ter saído.

O ciclo de controlo de acessos das PME, apresentado na tabela abaixo, abrange cinco fases: inventariar, autenticar, autorizar, alterar ou remover e verificar. Cada fase corresponde diretamente a um controlo que uma pequena ou média empresa consegue executar sem um orçamento de IAM empresarial.

Como o Passwork gere o acesso às credenciais

O Passwork centraliza as palavras-passe e os segredos das equipas, controla quem os pode obter e regista cada evento de acesso, funcionando em conjunto com um fornecedor de identidade, e não em substituição deste. Ocupa-se da autorização e da remoção de acessos: conceder às pessoas as credenciais certas e cortar esse acesso no momento em que uma função ou a situação laboral muda.

O fluxo de trabalho das credenciais divide-se em quatro passos:

1. Ligar a origem de identidade. Estabeleça a ligação com Active Directory, LDAP ou um fornecedor de identidade SAML 2.0, como o Microsoft Entra ID, o Okta, o ADFS ou o Google Workspace.
2. Mapear grupos para cofres. Cada grupo do diretório recebe, consoante a sua função, acesso de leitura, escrita, partilha ou apenas de auditoria a um cofre ou pasta.
3. Centralizar as credenciais. Armazene as palavras-passe, as chaves de API e os certificados em cofres partilhados, propriedade da organização, em vez de repositórios pessoais do navegador, folhas de cálculo ou conversas de chat.
4. Auditar todas as ações. Consulte o registo para saber quem acedeu a uma credencial, a alterou, a partilhou ou a exportou, e quando. Exporte-o para uma ferramenta SIEM se a equipa de segurança precisar dele aí.

O Passwork controla o acesso às credenciais. Não substitui a origem de identidade, o ciclo de vida documentado nem o responsável identificado por cada decisão de acesso. Essas responsabilidades continuam a cargo da organização.

Conclusão

Uma pequena empresa não precisa de um orçamento de IAM empresarial para acertar neste ponto. Precisa de quatro coisas por esta ordem: saber quem tem acesso, autenticá-lo e autorizá-lo corretamente, removê-lo no momento em que algo muda e verificar que a remoção ocorreu de facto. Um responsável, uma evidência, todas as vezes.

Perguntas frequentes

Lista de verificação de cibersegurança para pequenas empresas em 2026

Uma lista de verificação de segurança prática e alinhada com o NIST para pequenas empresas: 18 passos que abrangem políticas, MFA, gestão de palavras-passe, segurança de rede, cópias de segurança e resposta a incidentes, ordenados por custo e impacto.

PassworkPasswork Team

Gestão de palavras-passe para equipas: A solução de que toda a PME precisa

Guardar palavras-passe no Slack e em navegadores expõe a empresa a violações de dados. Descubra por que razão as ferramentas pessoais falham nas equipas, como efetuar a saída segura de colaboradores num só clique e por que razão as diretrizes mais recentes do NIST desaconselham a rotação forçada de palavras-passe.

Passwork BlogAlex Muntyan

Passwork vs Bitwarden: Como a arquitetura de cifragem de cofres difere

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

PassworkPasswork Team