How a self-hosted password manager supports ISO 27001 A.5.17
If your ISMS team has shared admin logins sitting in spreadsheets or chat threads, the first thing ISO/IEC 27001:2022 Annex A control A.5.17 asks you to fix is not the tool but the process. The control requires that the allocation and management of authentication information be controlled by a management process, including advising personnel on how to handle it. A self-hosted vault such as Passbolt, Vaultwarden or self-hosted Bitwarden can operate much of that process by holding credentials, enforcing sharing rules and recording who accessed what. It cannot complete the process alone, because the policy, ownership decisions and periodic reviews still have to be written and run by your organization. The control merges three 2013 controls, A.9.2.4 (management of secret authentication information of users), A.9.3.1 (use of secret authentication information) and A.9.4.3 (password management system), and NIST's crosswalk relates it to IA-5 Authenticator Management in SP 800-53 Rev. 5.
Be clear about who decides certification. ISO does not certify organizations, accredited certification bodies do, and they audit against the standard and the ISO/IEC 27002:2022 guidance. DeployOpen plans, implements and documents self-hosted platforms and prepares the controls and evidence an auditor will request, but it does not issue audit reports, attestations or certificates. Your certification body decides whether your password management process meets the requirement, so confirm its expectations on evidence format and sampling before you design the records.
Start with a written authentication information standard that names the vault as the system of record, lists which credential types must be stored there (shared admin, service and break-glass accounts), and assigns an owner for each shared resource. Then configure the vault to match it: role-based groups, least-privilege sharing, MFA enforced for all users and, where your edition supports it, password and passphrase policies and SSO with your identity provider. Offboarding must be a documented step that removes group membership and shared access and triggers rotation of any credential the leaver knew. Confirm with each vendor which of these settings are in your edition, because Passbolt lists several as Pro features.
Mapping A.5.17 to vault configuration and offboarding steps
This table maps the main jobs behind ISO/IEC 27001 Annex A 5.17 to what the vault must do and how Passbolt or Vaultwarden can be configured to support it. Read each row as a question an assessor may ask, then confirm the setting in your own edition and environment. The main takeaway is that most of the evidence comes from policy, configuration exports and recorded offboarding, not from the software alone.
| Requirement area | What the function must do | How to configure Passbolt or Vaultwarden |
|---|---|---|
| A.5.17 management process (IA-5 crosswalk) | Govern how authentication information is issued, changed and retired through a documented process with named owners, covering the authenticator lifecycle described under IA-5 in NIST SP 800-53. | Write a credential handling standard that names the vault owner and admins. Assign roles in Passbolt or Vaultwarden organization settings and keep a dated record of role changes. |
| Advice to personnel on handling authentication information | Tell staff how to create, store, share and report compromised credentials, and record that they received this guidance. | Publish the standard in the intranet and link it from the vault onboarding email. Keep training attendance records and acknowledgments per user. |
| Allocation of individual credentials | Ensure each person has their own account and that personal secrets stay out of shared storage. | Use personal vault areas for individual secrets. Require SSO or unique logins through directory sync (LDAP in Passbolt Pro, Directory Connector support in Vaultwarden). Confirm sync rules in your edition. |
| Allocation of shared and service credentials | Limit shared accounts to documented business need, assign each to a named owner and restrict access by group. | Create groups by team or system and share folders with groups, not individuals. In Passbolt, each shared resource is encrypted for each recipient. In Vaultwarden, use collections and group permissions within an organization. |
| Password and passphrase policy | Set minimum strength, uniqueness and expiry rules and enforce them in the tool rather than relying on staff memory. | Enable passphrase and password policies and password expiry in Passbolt Pro. In Vaultwarden, set master password policies and enforce MFA through two-factor login. Test policy enforcement with a sample account. |
| Multi-factor and SSO sign-in | Require strong authentication for vault access and keep the sign-in method consistent with the identity provider. | Enable MFA policies and SSO with your identity provider in Passbolt Pro. In Vaultwarden, enable OpenID Connect SSO (added in 1.35.0) and FIDO2 or authenticator-based two-factor login. Confirm which factors apply to admin accounts. |
| Access review | Review who can see which shared credentials at a set cadence and record the decisions and any removals. | Export group and member lists and the activity log to syslog or your SIEM. Ask the vendor how to produce a permissions report by resource. Keep signed review records outside the vault. |
| Export controls | Prevent bulk copies of credentials leaving the vault in cleartext and document any exceptions. | In Passbolt 5.10 and later, cleartext CSV export is disabled by default. Keep it disabled, or allow it only under a documented exception. Restrict export rights in the export policy. |
| Offboarding and credential rotation | Remove the leaver's access to vault items, transfer ownership of shared items and rotate any credential they could have seen. | Disable the account and remove group memberships on the day of exit. Reassign ownership of shared folders before deletion. Rotate shared passwords the leaver accessed and log each step with a ticket reference. |
Which self-hosted password managers fit an ISMS
Annex A 5.17 asks for authentication information to be allocated and managed through a controlled process, so the vault has to support that process in practice. The cards below compare the three self-hosted options and the identity sources they can sit behind, with the features that matter most for policy, sharing and evidence.
Passbolt Community and Pro
Passbolt uses OpenPGP end-to-end encryption, so each user holds a key pair and the server stores only ciphertext. The Community Edition is free and self-hosted, but several controls an ISMS usually needs sit in Pro: account recovery, MFA policies, password expiry policy, syslog activity logs and SCIM provisioning. Confirm each requirement against the current edition before you design around it. The server is licensed under AGPL-3.0.
Vaultwarden for small organizations
Vaultwarden is a Rust implementation of the Bitwarden Client API, licensed under AGPL-3.0, and it covers organizations with collections, groups, member roles, event logs and policies. It is not affiliated with Bitwarden, Inc., and its maintainers focus on individuals, families and small organizations, so bug reports go to the Vaultwarden project. Check that your support and recovery model fits that scope before you commit, and plan regular backups of the database and files.
Self-hosted Bitwarden server
The official Bitwarden server can be self-hosted and paired with the same clients that Vaultwarden supports. Its fit depends on the edition, the license terms and the hardware you can commit to, since it is heavier to run than Vaultwarden. Ask the vendor which organization, policy, event log and SSO features are included in the self-hosted plan you would deploy, and get that answer in writing for each control you must evidence.
Identity sources for SSO
Passbolt Pro and Vaultwarden both accept SSO, so the identity provider you already run becomes the control point for joiner, mover and leaver access. Keycloak, authentik and ZITADEL are common self-hosted sources. Confirm which protocol each product supports for your vault (OpenID Connect, SAML or SCIM), how MFA is enforced at the identity provider, and whether disabling a user there also removes vault access.
Sharing and audit evidence
Auditors will ask who could see a shared credential, who changed it and when access was removed. Check each candidate for group or collection sharing, per-item access rights, activity logs that can be exported to your SIEM and retention of those logs. Test an offboarding case end to end, then keep the export as evidence. Treat the answers as product-specific and confirm them against the edition you buy.
Which vault settings satisfy the management process and which need a process around them
ISO/IEC 27001 Annex A control 5.17 expects the allocation and management of authentication information to run under a controlled process, and the password manager is where many of those rules get enforced. In Passbolt, MFA policies, passphrase and password policies, password expiry, SSO and SCIM are Pro features, so the edition you buy decides which settings exist at all. Vaultwarden offers two-factor login, SSO through OpenID Connect since version 1.35.0 and organization policies, and its SSO_SIGNUPS_ALLOWED setting controls whether SSO can create new accounts. Record each value you set as a decision with the setting, the value, the approver, the date and the reason. The vault's activity log shows what users did after a setting changed, while the decision record shows why the change was made. Confirm whether configuration changes themselves appear in the logs of your chosen edition.
A vault records what happens inside it: who opened a shared credential, who was granted access and when an export ran. It cannot decide whether a shared administrator account should exist, who owns it, when it must be rotated after a staff change, or what personnel should do when they are tempted to share a password in chat. Those decisions belong in the ISMS documents: an approval step for new shared accounts, a named owner for each account, rotation triggers such as departures or suspected exposure, and written advice to staff on handling authentication information. Export restrictions show the split clearly. Since Passbolt 5.10, cleartext CSV exports are disabled by default, but an administrator can allow them again in the export policies, so that decision needs a documented approver and a reason. Auditors will ask for the procedure and for evidence that it ran.
Passbolt's server only receives and stores ciphertext. Each user has a key pair, and each user with access to a shared resource receives a copy encrypted with their public key, so the server cannot read the secrets it holds. That is a strong confidentiality property, and it also sets the recovery design. If a user loses their key or passphrase and no recovery path exists, the secrets encrypted to that user may be unreadable, including to administrators, and the records an auditor expects to see could be lost with them. Account recovery is a Pro feature in Passbolt, so confirm how it works, who can start it, what evidence it leaves and whether your procedure treats it as a controlled event. For Vaultwarden, check the project's documentation for each recovery path, including admin password reset and emergency access, and write down what each path can and cannot reach before you publish the procedure.
Evidence auditors ask for and which component produces it
This table maps each evidence item an assessor is likely to request for A.5.17 to the component that produces it and the retention or review cadence to confirm with your auditor. Read it as a checklist for designing exports and recurring reviews before the audit window opens. The main takeaway is that the vault alone rarely produces the full set, so the SSO, ticketing and ISMS records must be connected to it.
| Evidence item | Source component | Retention or review frequency to confirm |
|---|---|---|
| Access and sharing register (who holds which shared credential, with what permission) | Vault: organization collections, groups and member roles export | Confirm with the auditor whether a point-in-time export per review cycle is acceptable or whether continuous evidence is expected |
| Group membership export (vault groups and their members) | Vault groups, mirrored from the directory if LDAP or SCIM provisioning is enabled | Confirm the review interval for group membership and who signs off each review |
| Activity and event logs (creation, sharing, viewing and changes to secrets) | Vault event logs, forwarded to a SIEM or log store where syslog export is available | Confirm the minimum retention period with the auditor and the internal log retention policy |
| Offboarding tickets with proof of revoked access | Ticketing system linked to the IdP account disablement and the vault membership removal | Confirm how long closed tickets are kept and whether the auditor samples leavers from a defined period |
| Policy configuration screenshots or exports (MFA, password and passphrase rules, expiry, sharing and export settings) | Vault admin console or configuration files, stored under change control in the ISMS repository | Confirm the review frequency for policy settings and whether each change needs a recorded approval |
| Staff advice records on handling authentication information and training acknowledgments | ISMS documents and the learning or HR system where acknowledgments are recorded | Confirm the training cycle and the period a signed acknowledgment must cover for the auditor |
| Recovery and backup test records (restore of the vault database and attachments, account recovery drills) | Backup system job logs and restore test reports, kept with the ISMS | Confirm the test frequency and the evidence format the auditor accepts for a restore test |
| Management review minutes covering authentication information risks and metrics | ISMS documents, including management review records and the risk register | Confirm the management review cadence that the ISMS defines and which metrics must appear in the minutes |
What the password manager alone does not satisfy
A self-hosted vault stores and shares credentials, but A.5.17 is about the management process around authentication information. The cards below cover the gaps auditors most often find once the vault is live, and each one needs an owner, a record and a check outside the password manager itself.
No documented authentication information process
A.5.17 expects allocation and management of authentication information to run under a management process, with personnel advised on how to handle it. A vault with no written policy leaves that advice undocumented. Check for a written standard covering password length, generation, MFA for vault access, sharing approval and recovery, plus evidence that staff acknowledged it. Confirm the expected format of this evidence with your certification body.
No named owner for shared accounts
Shared administrator, vendor and service logins stored in a vault still need one accountable owner each. Without an owner, nobody approves access, rotates the password after a staff change or answers an auditor's question about who held the credential. Keep an inventory that maps each shared item to an owner, its approved users and its review date, and check that the vault's group and collection structure matches that inventory.
Vault activity logs that nobody forwards or reviews
Sharing, viewing and export events are only useful if they reach a system someone reviews. Confirm which events your chosen edition records, whether they can be sent to your SIEM and how often a named person reviews them. Passbolt lists syslog activity logs as a Pro feature, so check this before you design the log path. Test one event end to end, from vault to log platform to reviewer.
Offboarding that relies on manual steps
A leaver's access has to end in the vault, in SSO and in every shared credential they knew. Manual removal from a vault often misses shared items that the person viewed but did not own, and cached copies can remain on devices. Document one offboarding runbook that removes vault membership, revokes sessions and triggers rotation of any credential the person could see, then record the time each step was completed.
Service and machine credentials in a secrets manager
API keys, database passwords and pipeline tokens are used by software, not people, and they need rotation and short-lived issuance that a human-facing vault does not provide. OpenBao and Infisical are built for secrets distribution to workloads. Decide which credentials stay in the password manager and which move to a secrets manager, and document that split in the authentication information standard so auditors can see both paths.
Privileged sessions that need PAM
Retrieving an admin password from a vault does not record what the administrator did once logged in, nor does it enforce approval for each session. Where administrators, vendors or engineers open privileged sessions on servers, databases or Kubernetes, a privileged access management tool supplies session recording and approval flows. Confirm with your certification body whether the vault plus PAM design covers the access control expectations in your scope.
Questions buyers ask before certifying A.5.17
How much does a self-hosted password manager implementation cost?
The software cost depends on the edition, and the implementation cost depends on scope. Passbolt's community edition is free to self-host with unlimited users, while its Pro edition is published at $4.9 per user per month billed annually with a 10-user minimum and volume discounts after 100 users, according to Passbolt pricing. Vaultwarden and self-hosted Bitwarden carry no per-seat license fee for the open-source server. Recurring costs include the server, backups, upgrades and support. One-time costs include design, import, SSO and log integration, rollout and training. DeployOpen does not publish prices. A quote follows from a written scope that lists the editions, the number of shared accounts, the directory and SSO integrations, and the hosting target.
Which Passbolt edition do we need for SSO, MFA and activity logs?
For Passbolt, SSO with Microsoft, Google, OpenID and AD FS, MFA policies, syslog activity logs, account recovery, LDAP provisioning, SCIM and password expiry policies are listed as Pro features, not Community Edition features, in Passbolt's pricing comparison. Confirm this against the current comparison before you buy, since editions change. For Vaultwarden, SSO with OpenID Connect was added in version 1.35.0, and it supports two-factor login with an authenticator app, email, FIDO2 WebAuthn, YubiKey and Duo, along with event logs. Ask each vendor which features are available in the edition you plan to run and how logs are exported to your SIEM.
How long does a self-hosted vault implementation take?
Duration depends on the number of users, the number of shared accounts that must be inventoried and moved, the directory and SSO integrations, and how many approvals the policy design requires. Import is usually the step that takes longest when the current tool holds many shared credentials, because each shared account needs an owner and a group. Passbolt supports CSV imports from common managers and encrypted KDBX imports, which reduces manual work but still needs review. Ask for a timeline in the written scope with milestones for policy approval, pilot users, production cutover and the first access review. DeployOpen does not publish timelines before scope is agreed.
What must our internal team provide before the engagement starts?
Auditors will look for named owners, so the internal team must provide them. Expect to supply: a named owner for the password management process, an owner for each shared account group, decisions on password length, rotation and sharing rules, and the approval path for exceptions. HR must provide a reliable leaver and mover feed so that access is removed when someone leaves or changes role. Security must confirm which systems require MFA and which logs must reach the SIEM. Without these inputs, the policy in the vault will not match the control that A.5.17 describes in the management process.
Can our own team run the implementation without outside help?
A capable internal team can install Passbolt or Vaultwarden, since Passbolt documents installation on Debian, Ubuntu, Red Hat family systems, Docker and Kubernetes with a Helm chart, and Vaultwarden recommends its container images. The harder work is the design: encryption and recovery decisions, sharing models, SSO and MFA configuration, backup and restore testing, and the evidence trail. Vaultwarden's maintainers state that they cannot be held liable for data loss and recommend regular backups of files and the database. Many teams keep the platform in-house and buy a fixed-scope implementation for design, hardening and the evidence pack. Confirm which parts your team will own after go-live.
Will auditors accept a self-hosted password vault for A.5.17?
ISO/IEC 27001 does not certify tools. An accredited certification body audits whether your management process for authentication information works and is evidenced. A self-hosted vault can support that process if it records who holds each credential, how it is shared, how access is removed, and how exceptions are approved. Auditors will also check the supporting controls, such as the access and logging records. The NIST crosswalk relates A.5.17 to IA-5 Authenticator Management, which is a useful reference when mapping your evidence. Confirm the auditor's expectations early, since certification bodies apply ISO/IEC 27006-1:2024 to all clients.
Where does the vault's encryption leave the server blind to our credentials?
Passbolt uses end-to-end encryption based on OpenPGP, and according to its documentation the server only receives and stores ciphertext. Each user with access to a shared resource receives their own encrypted copy. Metadata such as names, URLs and descriptions is encrypted only with the v5 format and when the organization enables metadata encryption, so confirm that setting during design. Vaultwarden is a Bitwarden-compatible server, and the cryptographic model should be checked against the Bitwarden client documentation for the version you run. Ask whether a lost private key can be recovered, what the account recovery feature requires, and who can reset access.
How to build the evidence trail before the certification audit
Start with a written authentication information procedure, because A.5.17 expects allocation and management of authentication information to run under a management process, with personnel advised on how to handle it. Name the owner of the vault, the roles that may create shared folders or groups, the minimum password and passphrase rules, and how break-glass or service credentials are classified. Then configure the vault to match that document. In Passbolt Pro, the password and passphrase policies, password expiry policy, MFA policies, SSO and LDAP or SCIM provisioning are the settings an auditor will want to see reflected in screenshots or exported configuration. In Vaultwarden, the equivalent controls sit in organization roles, collections, policies and the SSO settings. Confirm in your own environment which of these features your chosen edition actually provides before you write them into the procedure.
Next, import and classify existing credentials, then run an offboarding drill. Import from the current tool using the supported formats, record what was imported, who owns each shared resource and which items are still unowned. Unowned credentials are the most common gap an assessor finds. For the drill, pick a test account, remove it from SSO and the vault, confirm that its shared access is revoked, and check that any shared secrets it knew are scheduled for rotation. Keep the ticket, timestamps, the access review output and the rotation record together. ISO/IEC 17021-1 certification cycles include at least one audit in every calendar year, so these records must be produced continuously, not assembled once before the visit. Ask your implementation partner to set up a recurring review that produces dated evidence, and confirm with your certification body which samples and formats it will request.
How DeployOpen scopes and delivers the password manager for ISMS evidence
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For an ISO 27001 authentication information control, that means a written scope that names the vault edition, the policies, the sharing model and the evidence an auditor will ask to see, delivered in your cloud account, data center or air-gapped network.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names the vault edition, hosting model, user groups and the authentication information covered by the control.
- Scope lists the policy records, sharing rules, offboarding steps and log exports the client expects to present to an auditor.
How we build
- Installation covers the chosen platform, such as Passbolt or Vaultwarden, on infrastructure the client controls, with HTTPS and a reverse proxy.
- Configuration covers collections or folders, roles, SSO or directory sync, MFA settings and password policies as agreed in scope.
- Testing covers access checks for each role, backup restore, and confirmation that offboarding removes access as documented.
How we hand over
- Documentation covers the authentication information management process, administrator procedures and the sharing and offboarding runbooks.
- Handover includes the evidence set mapped to the control, such as configuration exports, access reviews and log samples, for the client's own records.
- Training sessions cover administrators and team owners on handling authentication information and on running the recurring reviews.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, separate from the initial fixed-scope delivery.
- Upgrade planning tracks the vendor release cycle and records each change so the control evidence stays current.
- DeployOpen prepares systems and evidence for assessment. Certification decisions rest with the accredited certification body the client selects.
