Self-hosted password manager for CIS Control 5.2

Self-hosted password manager for CIS Control 5.2: what the safeguard asks for

CIS Safeguard 5.2 requires unique passwords on all enterprise assets, and a self-hosted password manager is the practical way to meet it for shared and service accounts. The safeguard sits under Control 5, Account Management, and CIS places it in the Users asset class and the Protect security function. It belongs to Implementation Group 1, the essential cyber hygiene baseline that CIS expects every enterprise to meet, so it applies whatever your size or sector. In your own words, the safeguard asks three things: that no two accounts share a password, that the organization has a written policy saying so, and that the policy covers both people and non-person accounts such as service logins, appliance admin accounts and vendor access. CIS also publishes best-practice minimum lengths of 8 characters for accounts that use MFA and 14 characters for accounts that do not, so your policy should state both.

The CIS Controls Assessment Specification for v8.1 is the document auditors and internal assessors use to test this safeguard. It treats the safeguard as failing when no unique password policy exists, and otherwise checks whether the policy gives guidance for accounts with and without MFA and whether that guidance meets the minimum lengths. Confirm with your assessor which evidence they will accept for each check, such as the policy text, a configuration export from the vault or a sample of account records. Also note that the CIS Controls do not replace regulatory or compliance schemes. A bank, hospital or contractor will still face its own rules on password management, so this safeguard is a baseline you map to those rules, not a substitute for them.

How Safeguard 5.2 maps to vault configuration

This table maps each part of Safeguard 5.2 and the related CAS checks to a vault setting or operating practice, and notes which edition supplies it. Read it as a checklist: each row names what an assessor will look for and what you must confirm in your own vault before claiming coverage.

Requirement	What the vault must do	Configuration and evidence to confirm
Safeguard 5.2: unique passwords on all enterprise assets	Give every account on an enterprise asset its own password, with no reuse across users, services or systems	Generate passwords in the vault, not by hand. Confirm the generator settings and password policy apply to every collection that holds enterprise credentials.
CAS completeness: policy exists	Provide a documented unique password policy that the CAS treats as the baseline (no policy means failure)	Record the written policy and its owner. In Passbolt Pro, confirm passphrase and password policies are enabled; in Vaultwarden or Bitwarden, confirm the organization policy and generator rules are set.
CAS completeness: guidance for accounts with MFA	Set separate guidance for accounts that use MFA, so the rule is explicit for each account type	Document the MFA-protected account category and link it to the collections that hold those accounts. Confirm MFA is enforced for vault users in the edition you chose.
CAS completeness: guidance for accounts without MFA	Set separate guidance for accounts that do not use MFA, which the CAS expects to be stricter	Document the non-MFA category and assign those accounts to a dedicated collection with the stricter generator length. Confirm the policy reflects a 14 character minimum.
CAS strength: 8 character minimum for MFA accounts	Ensure the generator and policy never allow a shorter password for MFA-protected accounts	Set the generator minimum to at least 8 characters for this category. Test by generating and saving a sample entry, then review the stored length in an export or audit.
CAS strength: 14 character minimum for non-MFA accounts	Ensure the generator and policy never allow a shorter password for accounts without MFA	Set the generator minimum to at least 14 characters. Confirm imported legacy entries are reviewed, since the generator does not change passwords already stored.
Shared and service accounts	Keep shared logins in one controlled place so each one has a single unique password without being copied to personal vaults	Use collections or shared folders with defined members. Record the owner of each shared account and confirm rotation happens when membership changes.
Edition and MFA policy	Enforce MFA on vault access and, where the audit needs it, on login to the vault itself	Community Edition and Vaultwarden offer two-factor options; Passbolt MFA policies and passphrase and password policies are listed as Pro features on the Passbolt pricing comparison. Confirm the feature set with the vendor before purchase.
Dependency: Safeguard 4.7	Safeguard 4.7 lists 5.2 as a prerequisite, so unique password rules must exist before default or unused account handling can be measured	Confirm the 5.2 policy and inventory are in place before you assess 4.7. Treat the vault records as an input to both checks.

Which self-hosted vault fits which CIS scenario

A small team with a few shared accounts and a single host often starts with Vaultwarden. It is an alternative server implementation of the Bitwarden Client API, works with the official Bitwarden clients, and supports organizations with collections, password sharing, member roles, groups and event logs. Its maintainers state that they focus on individuals, families and small organizations, so this fit is the one the project itself describes.

Shared accounts: Organizations with collections let you assign each shared service login to a defined group rather than a personal vault.
Database choice: Vaultwarden uses SQLite by default, while its configuration template marks PostgreSQL as recommended for larger deployments set through DATABASE_URL.
HTTPS requirement: The web vault needs HTTPS because of the Web Crypto API, so plan a reverse proxy and certificate from the start.
Support boundary: Bugs go to the Vaultwarden project, not Bitwarden support, and the maintainers state they cannot be held liable for data loss, so backups of files and the database are your responsibility.
Recovery features: Confirm which account recovery and policy controls you need, since these are the areas where paid editions of other products differ.

Before choosing, confirm with the vendor and your own environment whether a single server meets your availability and backup targets.

Platforms that fit CIS 5.2 and why

Safeguard 5.2 is met by a vault that holds every shared and service credential with its own unique password. The options below differ mainly in license, sharing model and which features sit behind a paid edition, so the choice depends on what your team must prove and who will support the server.

Passbolt Community

Passbolt Community is the free self-hosted edition under AGPL-3.0, with unlimited users according to Passbolt's pricing page. Each shared resource is encrypted with OpenPGP for every user who has access, so the server only stores ciphertext. For 5.2, the vault gives shared and service accounts a single home for generated unique passwords. Check which controls you need that sit outside this edition, such as LDAP provisioning, account recovery and MFA policies, which the comparison lists as Pro features.

Passbolt Pro

Passbolt Pro adds the controls that a CIS 5.2 assessment often relies on in practice: password and passphrase policies, password expiry, MFA policies, syslog activity logs and SCIM. Pricing is listed per user per month with a 10-user minimum and volume discounts after 100 users. Confirm with Passbolt which items are one-time versus recurring in a quote, and ask whether the Pro features cover your directory and recovery requirements before you commit.

Vaultwarden

Vaultwarden is a Rust server compatible with the official Bitwarden clients, licensed under AGPL-3.0. It supports organizations with collections, password sharing, groups, event logs, policies and SSO through OpenID Connect since version 1.35.0. The caveat is support: the project is not associated with Bitwarden, Inc., and its README asks users to report bugs to Vaultwarden rather than Bitwarden support. Plan regular backups of the database and files, because the maintainers state they cannot be held liable for data loss.

Self-hosted Bitwarden

Self-hosted Bitwarden runs the official server on infrastructure you control, so the client, server and support path all come from one vendor. It is the option to weigh when your auditors or procurement want the official product rather than a community server. Confirm the license terms, supported features by edition, resource requirements and backup procedure with Bitwarden directly before the design is fixed, since this page does not set out those details.

Keycloak or authentik for vault SSO

Vault logins are the first place where unique passwords meet MFA, so the identity layer matters. Keycloak (Apache-2.0, version 26.8.1) and authentik (MIT for the core, with a separate enterprise license for the authentik/enterprise directory) can supply SSO, MFA and directory federation to the vault. Check which license covers the features you intend to use, and confirm the vault's SSO setting works with your chosen provider before you rely on it for sign-in.

How to measure unique password coverage

The CIS Controls Assessment Specification scores Safeguard 5.2 in a fixed order. If there is no unique password policy at all, the Safeguard fails outright. If a policy exists, the assessor then checks completeness, meaning whether the policy gives guidance for accounts that use MFA and for accounts that do not, and strength, meaning whether that guidance meets CIS's best-practice minimums of 8 characters for MFA accounts and 14 characters for non-MFA accounts. Use the same two questions to test your own program: does a written rule exist, does it cover both account types, and do the length requirements in your vault settings match the numbers. The CIS Controls Assessment Specification for Safeguard 5.2 is the place to confirm the exact wording before you write your policy.

Build a small set of measures that answer those questions with evidence. Start with the number of accounts per asset in your inventory, split into personal, shared and service accounts, because this is the denominator for everything else. Next, record the share of those credentials stored in the vault versus outside it, using vault exports or a sampled check of where shared admin and service logins are kept. Then run a duplicate check: import or export the vault in encrypted form and count repeated credential values, or run the same comparison against a credential list your team can produce from its directory or PAM tooling. Finally, calculate the share of accounts whose stored passwords meet the length guidance, which in a self-hosted vault can be checked against the policy settings you enforce. Because the Assessment Specification defines what to measure but not how, document the method, data source and owner for each measure so an auditor can repeat it.

Be explicit about what a password manager cannot prove on its own. A vault can show that a password is unique within its own records, but it cannot see passwords set directly in an application or on a device that never touched the vault. Confirm with each system owner whether local or default accounts exist, and treat any duplicate count below your true total as a floor, not a result. Ask your implementation partner to design the duplicate check and length report as repeatable jobs, and to show which vault data fields they read, so the measure stays accurate after go-live.

Evidence auditors ask for under Safeguard 5.2

This table lists the records an assessor is likely to ask for when testing unique passwords under Safeguard 5.2, and which component produces each one. Read each row as a checklist item: confirm the named component can export that record in your edition and configuration before you promise it to an auditor. DeployOpen prepares these records and evidence, but independent auditors decide whether they are sufficient.

Evidence item	Produced by	What to confirm before the assessment
Written unique password policy	Your internal policy document, approved by the policy owner	Policy states that each enterprise asset account has its own password, with separate guidance for accounts with and without MFA (8 and 14 character minimums)
Vault policy configuration export	Passbolt Pro policies (passphrase and password policies) or Vaultwarden admin settings and environment file	Export or screenshot shows minimum length, complexity and generator settings in effect on the assessment date
Password generator usage evidence	Passbolt or Vaultwarden generator settings, plus activity records showing resource creation or update	Confirm whether generated values are enforced by policy or only offered to users
Collection and group membership records	Passbolt groups and folder sharing views, or Vaultwarden organizations, collections and groups	Snapshot of who can access each shared account, dated close to the assessment
Event and activity logs	Passbolt syslog activity logs (Pro edition) or Vaultwarden organization event logs	Confirm log retention, export format and whether logs are forwarded to a SIEM such as Wazuh
Shared and service account inventory mapped to vault items	Your asset inventory, cross-referenced with vault resource IDs and owners	Each enterprise asset account maps to exactly one vault item, with a named owner
Identity provider records for SSO and MFA	Keycloak, authentik, ZITADEL or other SSO provider logs and MFA enrollment reports	Shows which vault users authenticate with MFA, which matters for the 8 and 14 character tiers
Offboarding and access removal records	Identity provider deprovisioning logs, plus vault membership removal events	Removal timestamps for leavers align with account disablement and shared password rotation records
Import logs and migration records	Passbolt or Vaultwarden import history, plus the source tool export record	Shows what was moved from spreadsheets or previous managers, and that cleartext exports were disabled afterward

What a password manager alone does not satisfy

A password manager gives every shared and service account a unique, stored credential, but Safeguard 5.2 coverage depends on what sits around the vault. The gaps below are where assessors and auditors most often find unique passwords still in use, unreviewed or unrecoverable.

Devices and apps outside the vault

Network gear, printers, legacy line-of-business applications and appliances often have local accounts that cannot be fed into a browser-based vault. Each one still needs a unique password, and the vault only helps if someone records it and changes the default. Inventory these assets, confirm which ones accept SSO or certificates, and list the rest as manual entries with an owner. Confirm the vendor's password rules before you set policy.

Rotation after exposure

A unique password stops reuse, but it does not help once a credential has been pasted into a ticket, shared in chat or seen by a departing employee. The vault should record who had access and when, so the team can rotate the password on the target system and update the stored entry. Check whether your process covers rotation on the system side, not only a change in the vault.

Break-glass and emergency accounts

Emergency administrator accounts are the most valuable entries in the vault and are often the ones with the weakest controls. They need restricted access, alerting on retrieval and a tested procedure for use when single sign-on is down. Store them in a separate, tightly scoped collection and confirm that the vault still opens when the identity provider is unavailable.

Privileged session control

A vault releases a password, but it does not control or record what an administrator does after login. Where regulators or your own standard require session recording, approvals or just-in-time elevation, a privileged access management tool is the right control. Map which accounts need session-level evidence and which only need a unique, stored credential. Related guidance sits in the privileged access management group.

Account review under Safeguard 4.7

Safeguard 4.7 asks for periodic review of dormant and unused accounts, and it lists Safeguard 5.2 as a prerequisite. A vault shows who holds a shared credential, but it does not decide whether the account should still exist. Pair the vault's sharing report with a regular review that removes dormant accounts and confirms that each shared entry still has an owner. The CIS Controls Assessment Specification describes what to measure.

Recovery when a user loses their key

In an end-to-end encrypted vault, a user who loses their key or master secret can lock themselves out of their own entries. Ask how the product handles account recovery, whether recovery is an administrator action, and whether it needs an edition with paid features. Test the recovery path with a dummy account before go-live, and document who can approve it.

Questions buyers ask about CIS 5.2 and password managers

Does a password manager satisfy CIS Safeguard 5.2 on its own?

No. A password manager makes unique passwords practical, but Safeguard 5.2 is about the password policy and how it is applied across all enterprise assets. You still need a written policy that sets rules for accounts with MFA and accounts without it, and you need to show that every shared, service and administrator account follows it. The Safeguard's assessment checks whether the policy exists and whether its guidance meets the 8 and 14 character minimums CIS publishes, so the vault is one part of the evidence. Confirm the exact measures in the CIS Controls Assessment Specification for Safeguard 5.2 before you map your controls.

What drives the cost of a self-hosted vault compared with Passbolt Pro?

The two models pay for different things. Passbolt publishes Pro pricing at $4.9 per user per month billed annually, with a 10-user minimum and volume discounts after 100 users, according to its pricing page. That is a recurring license cost that scales with headcount. A self-hosted Vaultwarden or Passbolt Community deployment has no per-user license fee, so its cost sits in the servers, backups, certificates, staff time, upgrades and support. Ask any quote to separate one-time setup from recurring operations, and to state who carries each cost: your team, a hosting provider or a support partner.

How long does a rollout take and what does it depend on?

The duration depends on the number of accounts to migrate, how many teams own shared credentials, how many systems need SSO or directory sync, and how much of the hosting is already in place. Discovery of shared and service accounts usually takes the most time, because those accounts are often undocumented. Import from the current tool is usually quick once the folder and group design is agreed. Your partner should give a duration only in a written scope that lists these inputs, so ask for each dependency to be stated as a milestone rather than a single estimate.

What does the work need from our own team?

Most of the effort falls on people who know the accounts. You need an owner for the password policy, system owners who can confirm which shared and service accounts exist, and an identity or directory contact if you want LDAP or SSO integration. Your infrastructure team must provide the hosting target, DNS, HTTPS certificates and backup storage. Security or compliance staff should review the policy text and the evidence set. Name these owners in the statement of work, since the vault cannot close gaps in account ownership on its own.

Can we run Vaultwarden or Passbolt Community ourselves?

It is possible for a team with container and database skills, but the choice depends on what you need to operate. Vaultwarden is a community server for the Bitwarden client API, and its README says the project is not associated with Bitwarden, Inc., that its maintainers focus on individuals, families and small organizations, and that users should keep regular backups. Passbolt Community is free to self-host, but several features are listed as Pro only, including LDAP provisioning, account recovery, SSO, MFA policies and SCIM. Check which of these your controls need before deciding to run the community edition alone.

How do we keep the vault secure and supported after go-live?

After go-live, the work is recurring: applying upgrades, monitoring the service, testing restores, reviewing admin and event logs, and removing access when people leave. Vaultwarden and Passbolt both publish frequent releases, so a patch cadence and a named owner matter. Test restores on a schedule, because the vault is only as recoverable as its last verified backup. Decide in advance who answers outages and who signs off on upgrades, and whether that is your team, a managed service or a retained support agreement with DeployOpen. Ask any partner to describe these operating tasks in writing.

Which evidence will an assessor expect for unique passwords?

Assessors usually want the written password policy, proof that it covers all enterprise assets, a list of shared and service accounts with owners, and records of who can access each vault item. Vault event logs, admin access records and offboarding tickets help show that policy is applied. Keep a dated export of the account inventory for each review cycle. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or attestation.

Where does a password manager end and privileged access management begin?

A password manager stores and shares credentials, while privileged access management controls how administrators reach systems, records sessions and approves elevated access. For Safeguard 5.2, a vault may be enough to keep each credential unique and recorded. Where you need session recording, just-in-time approval or per-command logging, you will need a separate PAM tool. Decide early which accounts stay in the vault and which move to a PAM platform, so the policy names both controls clearly.

Rolling out unique passwords in phases

This sequence moves an organization from scattered shared logins to a vault where every enterprise asset has a unique, policy-governed credential, with evidence that the coverage can be measured and kept current.

Inventory accounts and enterprise assets
Identify every enterprise asset and account that needs a password, including shared mailboxes, admin logins, service accounts, network devices and application console users. Your IT and security owners compile the list and note which accounts use MFA and which do not, because CIS guidance sets different minimum lengths for each group. The step is done when each account has an owner, a system and an MFA status recorded in a single register.
Write the unique password policy
Draft a written policy that requires a unique password for every enterprise asset, sets minimum lengths of 8 characters for accounts that use MFA and 14 characters for accounts that do not, and states who may create, share and retire credentials. Security leadership approves the document and the vault configuration is aligned to it. The step closes when the policy names the owner of each control and the vault settings for password generation and policy enforcement match the stated minimums.
Choose the vault edition and hosting
Select the password manager product and edition that fits your sharing, directory and recovery needs, such as Vaultwarden, Passbolt Community or a paid Passbolt or Bitwarden tier. Confirm in writing which features your policy depends on, such as directory sync, MFA policies, activity logs and account recovery, because some sit only in paid editions. The hosting design is set in the same step. The step is done when the edition decision and the hosting plan are signed off and their licenses are recorded.
Import and rotate shared and service credentials
Move existing credentials into the vault, first by importing from the current tool or a controlled export, then by changing each shared or service password so it is unique and stored only in the vault. Assign each credential to a group or collection with named access. Where a credential cannot be rotated safely, record the exception and the reason. The step closes when no tracked account still uses a password listed as shared or duplicated in the register, and exceptions are approved.
Enforce MFA where the system supports it
For every account that supports multi-factor authentication, enable it and record the method used. Use the vault's own two-factor options for vault logins, and integrate SSO where the directory supports it. Accounts that cannot use MFA move to the longer 14 character minimum and to a documented compensating control. The step is complete when the register shows MFA status for each account and the vault login itself is protected by MFA.
Measure coverage against the policy
Run a review that compares the register with vault contents and checks each account against the policy: unique password present, correct length class, owner assigned and access limited to named users. Record coverage as a count of compliant and non-compliant accounts, and list each gap with an owner and a close date agreed in writing. This produces the evidence an assessor would ask for under CIS Safeguard 5.2 and the related account management controls. The step closes when every gap is either fixed or formally accepted.
Set a recurring review and offboarding cycle
Schedule a recurring review of the register, vault access, group membership and exceptions, and link offboarding to it so that departing staff lose vault access and any credentials they held are rotated. Keep the review records and vault event logs where your retention rules require. The cycle is in place when the review owner, the frequency and the offboarding trigger are documented and the first review has been completed and recorded.

How DeployOpen scopes and supports a CIS 5.2 password manager

DeployOpen plans, implements, customizes, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, so a password manager for CIS Safeguard 5.2 runs on servers you control. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory shared, service and break-glass accounts that must follow the unique password rule for enterprise assets
Agree which platform fits the team, whether Vaultwarden, Passbolt or self-hosted Bitwarden, and which edition features are required
Write down the password policy guidance for accounts with and without MFA, matching the 8 and 14 character minimums to be tested

How we build

Deploy the vault in your cloud account, data center or air-gapped network with HTTPS, a reverse proxy and a managed database
Configure organizations, collections, groups and roles so every shared credential has a defined owner and access list
Test sharing, recovery, two-factor login and event log output against the written scope before handover

How we hand over

Document the password policy, sharing model, onboarding and offboarding steps, and the evidence each step produces
Provide a coverage method that counts accounts stored in the vault against the enterprise asset inventory
Train administrators on backups, upgrades, audit log review and the procedure for resetting shared credentials

How we support

Offer ongoing support, upgrades and backup verification as a retainer after go-live
Track upstream release notes and schedule updates for the server, database and browser extension components
Prepare the system, controls and records that your independent auditor will review, without issuing any attestation

Self-hosted password manager for CIS Control 5.2 unique passwords