Safeguard 5.2 Use unique passwords: evidence and cost

Safeguard 5.2 Use unique passwords: what it asks for

Safeguard 5.2 requires that every enterprise asset uses a unique password for each account, so no two accounts share the same credential and no account reuses a password that is already in service elsewhere. Your auditor or customer wants to see this as a written policy that covers every asset, backed by a way to show that the policy is applied. Shared and reused passwords are a common path to compromise because one leaked or guessed credential then opens every system that accepts it, and attackers routinely try the same password across many services. CIS sets best-practice minimum lengths of 8 characters for accounts that use multi-factor authentication (MFA) and 14 characters for accounts that do not, since MFA gives a second barrier while a password-only account needs more length to resist guessing.

In CIS Controls v8.1, Safeguard 5.2 sits in the Users asset class and the Protect security function, and it is assigned to all three Implementation Groups. That makes it part of IG1, the essential cyber hygiene baseline that CIS describes as the minimum for every enterprise, so an organization of any size is expected to meet it. The Assessment Specification scores the Safeguard as failing when no unique password policy exists. Where a policy does exist, it checks whether the policy gives guidance for accounts with and without MFA and whether that guidance reaches the 8 and 14 character minimums. Confirm the current wording of each check in the Assessment Specification before you write your policy, because the test is what your assessor will apply.

What usually makes this hard is not the policy text but the accounts that cannot follow it. Legacy applications, network appliances, printers, embedded devices and some vendor-managed systems often ship with a default or fixed password, cannot enforce a unique password policy, or cannot accept a 14 character password at all. Inventory these exceptions early, record the compensating controls you apply to each (such as restricted network access, MFA at a gateway, or vault-held credentials), and decide with the system owner whether to replace or isolate them. A password manager or a secrets vault can generate and store unique values for accounts that people do not need to type, which reduces the burden on staff while leaving a clear record for the assessor.

Which accounts and assets need unique passwords

Safeguard 5.2 applies to every enterprise asset and every account on it, so the first job is drawing the boundary. The cards below cover the decisions that change the work, from user and administrator accounts through cloud consoles and third-party managed systems, and name the team that owns each group.

Enterprise assets define the boundary

The scope of Safeguard 5.2 follows the enterprise asset definition in CIS Control 1 and the asset inventory that Safeguard 1.1 requires. Start from that inventory, not from the directory, so that devices and appliances with local accounts are not missed. Confirm with the IT operations lead that every asset class in the inventory has an owner who can answer for its accounts. Owner: IT operations with the asset management team.

Enterprise user accounts

Standard employee and contractor accounts are the simplest case: they should be in scope with the same uniqueness rule as every other account. Check whether the password policy is enforced by the central directory or by each application, because a directory rule does not cover local logins on endpoints. Owner: identity team, with HR and the service desk for joiner and leaver processes.

Administrator and privileged accounts

Administrator accounts are in scope and usually need the strictest review, because a reused or weak administrator password exposes every system it manages. Confirm that privileged accounts are not sharing a password with the everyday account that holds them, and that the policy requires unique values across both. Owner: infrastructure security, with the platform team that manages privileged access.

Service and shared accounts

Service accounts and shared logins are where uniqueness most often breaks, since a single password may be copied into scripts, configuration files and several hosts. Each one should have its own password, stored in a secrets manager rather than in plain text, and be listed in the account inventory. Owner: application owners, with the security team validating the inventory.

Network devices and appliances

Routers, switches, firewalls and load balancers are enterprise assets that often carry local administrator passwords that were never changed from the factory or copied across a fleet. Each device needs a unique password, and the change record should show that the password was set per device. Owner: network engineering, with change management approving the rotation process.

Cloud consoles, SaaS tenants and managed systems

Cloud management consoles and SaaS tenants are in scope where they authenticate with a local password, even if most users sign in through single sign-on. Third-party managed systems fall in scope when the provider holds accounts on your assets, so contracts should require unique credentials and evidence of how they are set. Owner: cloud platform team for consoles, procurement and vendor management for providers.

How an assessor tests unique passwords under 5.2

This table walks through the three checks an assessor applies to Safeguard 5.2: whether a unique password policy exists, whether it covers accounts with and without MFA, and whether its minimums meet the 8 and 14 character best practices. Read each row as a test step, the evidence it needs and the gap that most often causes a failing score.

Test step	What the assessor checks	Evidence requested	Common finding
Existence	Whether a written unique password policy applies to all enterprise assets	The approved policy document, its version history and owner sign-off	No policy exists, or it is a draft or unapproved template
Scope	Whether the policy reaches every enterprise asset, including servers, network devices and cloud consoles	Asset inventory cross-referenced with the policy scope statement	Policy covers workstations and employees only
Completeness, MFA accounts	Whether the policy gives guidance for accounts that use MFA	The policy section for MFA-protected accounts and the related configuration	MFA accounts are missing from the policy entirely
Completeness, non-MFA accounts	Whether the policy gives guidance for accounts that do not use MFA	The policy section for accounts without MFA and any exception register	Guidance exists only for MFA accounts, leaving password-only accounts unaddressed
Strength, minimum length	Whether the stated minimums meet 8 characters with MFA and 14 characters without it	Policy text plus directory and application password settings exported from the systems	Policy states a shorter minimum than the policy text requires, or the systems enforce less than the policy says
Sampled account settings	Whether live settings match the policy for a sample of accounts across systems	Configuration exports, screenshots or command output for sampled accounts and applications	Sampled applications accept shorter passwords than the directory enforces
Service and shared accounts	Whether non-human and shared accounts fall under the same unique password rules	Service account inventory, secret storage records and password rotation logs	Service accounts are silently excluded or share one credential across systems

Why CIS sets 8 characters for MFA and 14 without it

The two CIS best-practice minimums reflect where the password sits in the authentication chain. For accounts that use MFA, the password is one factor among two, so a shorter password can be an acceptable part of a layered control: an attacker who guesses or steals it still needs the second factor. For accounts without MFA, the password carries the full weight of proving identity, so CIS sets a higher floor of 14 characters for those accounts. The 8-character minimum applies only when MFA is genuinely enforced for that account, which is why the assessment's completeness check expects guidance covering both cases rather than a single length.

These figures are CIS best-practice minimums, and the CIS Controls Assessment Specification for v8.1 measures your policy against them. An assessor will check whether your password policy states a minimum for accounts with MFA and a minimum for accounts without it, and whether those minimums meet 8 and 14 characters. Confirm with your assessor how they will treat accounts that MFA covers only partially, such as legacy protocols or service logins. Ask your identity team to list every account type that falls outside MFA enforcement, because those accounts are the ones measured at the 14-character floor.

Other frameworks you may be assessed against set their own expectations for the same behavior. ISO/IEC 27001:2022 Annex A 5.17 concerns authentication information, and PCI DSS v4.0 requirement 8.3.6 sets its own password complexity and length requirements for payment environments. Those requirements can differ from the CIS minimums, so confirm with your assessor which length and complexity rules apply to each in-scope system, and document the stricter value where two frameworks overlap. The CIS Controls Navigator shows how CIS maps Safeguard 5.2 to these other frameworks, but the mapping does not replace your assessor's reading of their requirements.

How to implement unique passwords step by step

This sequence takes a team from an authentication inventory to evidence that every enterprise asset uses unique credentials that meet the CIS minimums of 8 characters with MFA and 14 characters without it. Each step produces a document or export that an assessor can check.

Inventory authentication sources for every asset
List every enterprise asset that requires a login, including endpoints, servers, network devices, SaaS applications, databases and administrative consoles. For each one, record whether it authenticates against a central directory, a local account store, or its own built-in user table, and whether MFA is enforced. The output is an authentication source register with one row per asset or application, the account types it holds and the owner responsible for it. Treat the register as complete only when the owners have confirmed their rows, because an unlisted local store is a common source of reused passwords.
Write the unique password policy
Draft or update the password policy so it requires a unique password for every enterprise asset and prohibits reuse across accounts and systems. Set separate guidance for accounts that use MFA, with a minimum of 8 characters, and for accounts that do not, with a minimum of 14 characters, which are the CIS best-practice minimums for Safeguard 5.2. Have the policy approved by the owner accountable for identity, and record the version and approval date. The output is a signed policy document that names both minimums and the scope of assets it covers, which the assessment specification checks for completeness and strength.
Configure the directory and identity provider
Set the minimum length and uniqueness rules in the central directory or identity provider so that the policy is enforced at the point where users set or change passwords. Where the platform supports it, apply the 8 character rule to MFA-protected groups and the 14 character rule to groups without MFA, and block reuse of recent passwords. If a platform cannot express the two-tier rule, document that limitation and the compensating control in the exception register. The output is a configuration export or screenshot for each policy object, with the date it was captured.
Apply the rules to key applications and local accounts
Extend the same minimums to applications that authenticate locally, such as network appliances, databases, hypervisors and older line-of-business systems. Where an application cannot enforce a rule, record the gap, the planned remediation, and the owner in the exception register. An implementation partner can help write the configuration changes and test them in a non-production environment before rollout, but the organization owns the decision to accept each exception. The output is a per-application configuration record and an exception register with a named owner for each open item.
Replace shared and default credentials
Find shared accounts, vendor default passwords and credentials embedded in scripts or configuration files. Replace each with an individual account where the system supports it, or move the credential into a managed vault where a shared account is operationally required. Vaulted secrets, such as those held in a self-hosted secrets manager like OpenBao, can be rotated and revoked centrally, which supports the uniqueness requirement. Scan repositories for hardcoded secrets with a tool such as GitLab pipeline secret detection. The output is a log of replaced credentials, a list of vaulted secrets with their owners, and the scan reports showing that no known credentials remain in code.
Validate with configuration exports and sampling
Compare the policy document against the exported configurations for each system in the authentication source register. Confirm that every asset either enforces both minimums, or appears in the exception register with an accepted and dated justification. Sample a set of accounts to check that no password is reused across accounts, using a method the organization can repeat. The output is a validation workbook that maps each asset to its evidence, with the reviewer's name and date. Ask the independent assessor which evidence format they accept before you finalize it.
Keep the evidence current
Set a review cycle for the policy, the register and the exception list, and repeat the validation when new applications or assets are onboarded. Record each change to the policy and each closed exception so the history is traceable. Ongoing support of this kind is often run as a retainer, and the scope of that work should be agreed in writing. The output is a maintained evidence set with a change log, which lets the organization show the current state of unique passwords at any point, not only on the day the project finished.

Password policy evidence that passes Safeguard 5.2

An assessor testing Safeguard 5.2 looks first for a written unique password policy, then for proof that the policy is enforced in the systems that hold accounts. The cards below cover the artifacts that connect those two layers and how to keep each one current between assessments.

Written unique password policy

The policy must state that each enterprise asset uses a unique password and must give separate guidance for accounts that use MFA and accounts that do not. The CIS assessment specification checks completeness first, so both branches need to be present. Set the 8 character minimum for MFA accounts and the 14 character minimum for non-MFA accounts. Review the document at a fixed interval and record the approver and version date. Keep a change ticket for every revision so the assessor can see when the minimums last changed.

Directory policy configuration exports

Export the password policy settings from the directory or identity service that enforces them, not only the policy document. Compare the exported minimum length against the written minimums for each account group. Schedule the export monthly or after any directory change, store it with a timestamp, and have the identity administrator confirm that the export matches the running configuration. A mismatch between the document and the export is one of the most common reasons a strength check fails.

Register of authentication sources

List every system that authenticates users or holds local accounts, and state whether it reads from the central directory or keeps its own password store. Map each source to the asset classes it protects so the assessor can see coverage across enterprise assets. Review the register quarterly and when a new application or device class is onboarded. Any source that keeps a local password store must appear in the register with its own policy or a documented exception.

Account setting samples

Pull a sample of account records from several systems and show the password policy attributes that apply to each. Include at least one MFA-protected account and one non-MFA account so both branches of the policy are tested. Record the sample method, the date and the reviewer. Refresh the sample at each review cycle and keep the raw output. Samples that show only one account type leave the completeness check unresolved.

Exception records with expiry

Some systems cannot meet the minimum length or cannot enforce a unique password. Record each exception with the affected asset, the reason, the compensating control, the approver and an expiry date. Review open exceptions at each review cycle and close those past their expiry. An exception without an approver or an end date will usually fail the assessment, because it shows the policy is not controlling the risk.

Periodic review and sign-off records

Keep a dated record of each review of the password policy, the exports, the register and the exceptions. Name the owner who signs off each review, normally the security lead for policy and the identity administrator for configuration. Link each review to the change tickets raised in that period. This record shows the assessor that the policy is maintained over time and not written once for the audit.

What meeting Safeguard 5.2 costs in money and effort

This table breaks down the cost components of meeting Safeguard 5.2 on unique passwords, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. No prices or durations are stated because none were supplied; use the questions in the last rows to compare quotes on a like-for-like basis.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Identity or directory licensing	Software vendor or internal IT budget, where a directory or identity service is already licensed	Recurring (licence renewal)	Up with each authentication source to reconcile; down when a central identity service already covers most applications
Engineering time to set password rules	Internal platform or identity engineers, or an implementation partner under a written scope	One-time, plus periodic review	Up with the number of systems that enforce their own password rules; down when one policy source feeds many applications
Remediation of shared or default credentials	Internal application and infrastructure owners, sometimes with partner help on legacy systems	One-time, then recurring as new accounts appear	Up with legacy appliances, embedded device accounts and undocumented service logins; down with a complete account inventory from Safeguard 5.1
Handling MFA exceptions	Identity team and application owners	Recurring	Up with the number of accounts that cannot use MFA, since these must meet the 14 character minimum; down when MFA covers most accounts
Evidence upkeep	Internal compliance or security staff	Recurring	Up with manual exports of policy settings and per-system screenshots; down when policy configuration and change history are kept in version control or a central log
Auditor or assessor review	Independent auditor or assessor, paid under its own engagement terms	Recurring at each assessment cycle	Up with the number of systems in scope and the sampling the auditor selects; down with a single documented policy and consistent configuration
Ask in a quote: scope	Partner or vendor	Not applicable	Which systems, directories and applications are covered, and which legacy or appliance accounts are excluded and why
Ask in a quote: deliverables and ownership	Partner or vendor	Not applicable	Which items are configuration changes, which are documentation, and which evidence the organization keeps after the engagement ends

Open-source tools that support unique password evidence

Safeguard 5.2 is judged on the password policy and the accounts it governs, so the evidence has to show both. The four tools below cover different parts of that picture: where accounts and password rules live, how accounts are removed from applications, how non-human credentials are kept short-lived, and whether secrets have leaked into code. None of them proves compliance on its own, and each depends on the password settings in your own version.

FreeIPA directory and policy

FreeIPA runs 389 Directory Server as a multi-master LDAPv3 directory that stores users, groups and hosts, with centralized access control and delegated administration through its web UI and command line tools. For Safeguard 5.2, the useful evidence is a single password policy applied to the directory, plus a record of who can change it. Confirm in your version that the policy sets the 8 and 14 character minimums for MFA and non-MFA accounts, and that policy exceptions are documented and reviewed. Bind your enterprise applications to this directory so the policy applies to them as well.

authentik user provisioning

The authentik SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0, runs a full sync every hour, and deprovisions users from the target when they lose access. This matters for unique passwords because each application account should map to one identity, not a local shared login. Export the sync logs and the list of connected applications as evidence. Confirm the sync interval and deprovisioning behavior in your deployed version, and check which target applications actually hold local passwords that SCIM does not manage.

OpenBao dynamic credentials

OpenBao stores secrets encrypted in one place, generates dynamic short-lived credentials for systems such as databases, attaches leases that revoke secrets on expiry, and can revoke single secrets or whole trees of credentials. For Safeguard 5.2, this replaces shared static service passwords with generated credentials that are unique per request. Evidence includes the secrets engine configuration, lease settings and revocation logs. Confirm which of your systems can consume dynamic credentials, since applications without that support will still need a managed static secret with a documented rotation process.

GitLab secret detection reports

GitLab Community Edition pipeline secret detection scans files committed and pushed to the repository in a CI/CD job and writes detected secrets to a gl-secret-detection-report.json job artifact in every tier. Hard-coded passwords in source code are a common reason a password is not unique or not protected, so this report is useful evidence that the organization looks for them. Keep the artifacts from each pipeline run and track findings to remediation. Confirm the scanner's coverage for your languages and file types, because a clean report does not show that no credentials exist outside the scanned paths.

Who does what for unique password compliance

Your organization owns the control. Safeguard 5.2 asks for unique passwords on every enterprise asset, and that decision cannot be delegated to a vendor. Your security leadership writes the password policy, decides whether to enforce the CIS best-practice minimums of 8 characters for accounts using MFA and 14 characters for accounts without it, and accepts any risk where an enforced rule is not possible. Account owners remain accountable for the accounts they hold, including shared or legacy accounts that must be retired or made unique.

Policy ownership: Approve a written unique password policy that covers every asset class in scope, including workstations, servers, network devices and cloud consoles.
Enforcement decision: Decide which rules are enforced by technology and which depend on user behavior, and document that choice.
Exception handling: Record each exception, its owner, its compensating control and its review date.
Account owner duties: Confirm that each account has a named owner who can attest that the password is not reused elsewhere.
Internal review: Sample accounts and systems before the auditor arrives so gaps are found by you first.

Check that your policy names owners and exception approvers by role, not by individual name, so the control survives staff changes.

Where organizations fall short on unique passwords

Most organizations have a password policy somewhere, but Safeguard 5.2 is tested against what the policy does in practice. The gaps below are the ones that most often separate a written policy from unique, enforced credentials on every enterprise asset.

Shared administrator and service passwords

Administrator and service accounts often share one password across several systems, so a single disclosure opens every one of them. Safeguard 5.2 asks for unique passwords on all enterprise assets, and a shared credential fails that test even when each individual system has a strong policy. Check whether privileged and service credentials are listed per system and per account. The closure step is to move these credentials into a secrets store that issues unique values and rotates them, so no human needs to remember them.

Policy exists but is not enforced

A written unique password policy is only half the evidence. Assessors look for the policy setting in each application or directory, because an application that accepts reused or short passwords breaks the requirement regardless of what the policy document says. Compare the documented rules with the actual configuration of each system that holds accounts. The closure step is to record which settings enforce the policy in each system and to test a reused password against each one.

No separate guidance for MFA accounts

The CIS best-practice minimums differ by authentication method: 8 characters for accounts that use MFA and 14 characters for accounts that do not. A single length rule either weakens accounts without MFA or adds needless friction to accounts that have it. Review whether the policy states both minimums and which accounts fall under each. The closure step is to tie the password length rule to the MFA status recorded in the identity system, so the rule updates when an account's MFA status changes.

Default credentials left on appliances

Network appliances, sensors, printers and embedded devices often ship with vendor default passwords that are widely documented. Safeguard 5.2 requires each enterprise asset to have its own unique password, so a default that remains in place is a direct gap. Inventory the devices that have local accounts and confirm each one has been changed from its default. The closure step is to include a credential change in the build or onboarding procedure for every new asset, and to record the change as evidence.

Exceptions that never expire

Teams often receive temporary exceptions for legacy systems that cannot enforce the policy, and those exceptions then remain in place for years. An exception without an owner, a reason and an end date quietly becomes the rule for that system. Ask for the exception register and check each entry for an approver, a compensating control and a review date. The closure step is to set a fixed expiry on every exception, review it on that date, and retire the system or fix its configuration when the exception lapses.

Questions buyers ask about Safeguard 5.2

What does it cost to make passwords unique across our enterprise assets?

The cost comes from people's time and system changes, not from a licence for the password requirement itself. Most of the work is an internal effort: a policy owner writes the password rules, identity administrators configure directories and applications to enforce them, and teams review systems that cannot yet meet the minimums. External help is priced from a written scope, so the cost moves with the number of identity sources, applications and enterprise assets in scope, how many accounts must be migrated or reset, and whether the organization needs evidence packaged for an assessor. Ask any partner for a quote that lists each system, the deliverables, and what is one-time work versus ongoing support. DeployOpen does not publish prices, and any figure you see elsewhere should be checked against its stated scope.

How long does it take to get unique password rules in place?

The duration depends mostly on how many systems must enforce the policy and how many of them can be configured centrally. A single directory with a few connected applications is a much smaller task than dozens of standalone systems, each with its own password settings and local accounts. Plan time for policy approval, configuration of each enforcement point, testing that the 8-character MFA and 14-character non-MFA minimums are applied, and communication to users. Those phases should be written into the fixed-scope plan so that every system has a named owner and a finish point. DeployOpen agrees timelines in writing before work starts, so ask for the schedule by system rather than a single number.

What must our organization provide before a password project starts?

Three inputs are needed before work begins. First, a named policy owner who can approve the password standard and its exceptions, since the rules affect every user and service. Second, read and configuration access to the directory or identity provider, along with a list of the systems that authenticate against it. Third, application administrators for each system that keeps local accounts or its own password settings, because those settings must be changed by someone who can change them safely. Without these people, the work stalls at the first system that cannot be changed centrally. Confirm access, change windows and rollback steps in the statement of work.

Can our internal team implement Safeguard 5.2 without outside help?

Yes, many internal teams can, provided they have identity administration skills and the time to work through each system. The task is conceptually simple: define a unique password policy, set minimum lengths that match the CIS best-practice minimums, distinguish accounts with MFA from accounts without it, and show that the rules are enforced. The difficulty lies in coverage. Teams often find legacy applications, network devices and service accounts whose settings cannot be changed easily. An outside partner is most useful for that coverage work, for hardening self-hosted platforms, and for organizing evidence. Whichever route you take, the organization remains responsible for its controls.

Do the 8 and 14 character minimums satisfy other frameworks?

Not automatically. The CIS Controls Navigator for v8.1 links Safeguard 5.2 to NIST SP 800-53 Rev. 5 IA-5(1), ISO/IEC 27001:2022 Annex A 5.17, SOC 2 CC6.1, and PCI DSS v4.0 requirements 2.2.2, 8.3.5, 8.3.6 and 8.6.3. Those mappings show where the topics overlap, but they do not mean one password rule satisfies every framework. Each framework has its own test, and PCI DSS in particular sets its own password requirements. Ask your assessor to confirm which length, complexity and MFA rules they will accept for your environment before you build the policy around the CIS minimums.

What does an implementation partner do, and what does the auditor test?

An implementation partner prepares the systems and evidence. That includes configuring enforcement in the directory and applications, documenting the policy, collecting exports that show the rules in force, and packaging them for review. DeployOpen works this way and does not issue audit reports or certifications. The auditor or assessor independently tests the result. Under the CIS Controls Assessment Specification, a Safeguard 5.2 review fails when no unique password policy exists, then checks whether guidance covers accounts with and without MFA and whether it meets the 8 and 14 character minimums. Only the independent assessor reaches a conclusion about compliance.

How DeployOpen prepares unique password evidence

DeployOpen plans, implements and documents the systems that show unique passwords are enforced for Safeguard 5.2 Use unique passwords, inside your own infrastructure. We prepare the policy, identity configuration and evidence an assessor will check, while your organization keeps ownership of its controls and the independent assessor decides whether the Safeguard is met.

How we scope

The written scope lists which enterprise assets, directories and applications fall under the unique password policy.
Scope records whether accounts use MFA, since the 8 and 14 character minimums depend on that split.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We configure the password policy and identity provider so guidance for MFA and non-MFA accounts is written down and enforced.
We check that the policy meets the 8 character minimum for MFA accounts and the 14 character minimum for accounts without MFA.
Where service credentials exist, we move them toward generated, short-lived secrets instead of shared static passwords.

How we hand over

You receive the written password policy, configuration exports and test results mapped to the assessment checks for Safeguard 5.2.
Runbooks explain how administrators review password settings and handle exceptions or credential rotation.
Your team owns the controls and evidence, and an independent assessor reviews them before any report is issued.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover periodic re-checks of policy settings after platform upgrades or directory changes.
Ask your assessor which evidence formats and sample sizes they expect before we finalize the handover package.