IA-5(18): Password Managers

IA-5(18) requires you to employ an organization-approved password manager to generate and manage passwords for covered accounts and systems. To operationalize it, standardize on a managed password manager, define where it must be used (workforce, privileged, service accounts), enforce configuration baselines, and retain evidence that the tool is deployed, used, and governed. ¹

Key takeaways:

• Standardize on one approved password manager with policy-backed scope, not “optional best practice.” ¹
• Prove operations, not intent: deployment records, configuration baselines, and adoption/usage evidence matter most in audits. ¹
• Treat exceptions (service accounts, shared accounts, break-glass) as first-class workflows with compensating controls and documented approvals. ¹

The ia-5(18): password managers requirement is a control enhancement under NIST SP 800-53 Rev. 5 in the Identification and Authentication (IA) family. Practically, assessors read it as: “Show me the standard tool you approved, show me that users and admins actually use it to create strong passwords, and show me governance around how passwords are stored, shared, recovered, and audited.” ²

This requirement often fails in implementation for a simple reason: teams buy a password manager but do not turn it into an enforceable standard. They leave gaps for privileged administrators, service accounts, shared operational credentials, or third-party access. Then, during an assessment, the organization can’t demonstrate consistent use, can’t explain exceptions, or can’t produce evidence beyond a screenshot of a license. ¹

This page gives requirement-level implementation guidance for a Compliance Officer, CCO, or GRC lead who needs to assign ownership, set scope, align IT/SecOps, and produce audit-ready artifacts without turning password management into a months-long program.

Regulatory text

Requirement excerpt: “Employ {{ insert: param, ia-05.18_odp.01 }} to generate and manage passwords; and” ¹

Operator interpretation of the text: NIST is directing you to use an organization-defined password manager (the parameter placeholder indicates you must define the specific solution or class of solutions in your control statement) for two purposes: (1) generate passwords and (2) manage passwords. “Manage” is where audits concentrate: storage, synchronization, access control, recovery, and controlled sharing for business use. ¹

What the assessor will expect you to show:

• The named password manager product/service (or an approved shortlist) and a configuration baseline. ¹
• A documented scope of accounts/systems required to use it. ¹
• Evidence of deployment and ongoing administration (SSO, MFA, policy settings, user provisioning). ¹
• Evidence that password generation is enabled and used in practice (not just “available”). ¹

Plain-English interpretation (what IA-5(18) is really asking)

You must make password managers a standard control, not a convenience tool:

• Users should not invent memorable passwords for systems that still rely on passwords.
• Passwords should be generated by the manager (random, unique per site/system).
• Passwords should be stored and retrieved through the manager with access controls, audit logs, and a recovery process owned by the organization. ²

Who it applies to

Entity scope (typical):

• Federal information systems.
• Contractor systems handling federal data (including many environments aligned to NIST SP 800-53 through agency requirements and assessment regimes). ¹

Operational scope (what to include in your boundary):

• Workforce identities (employees, interns, temps).
• Privileged administrators (domain admins, cloud admins, DBAs).
• Shared operational credentials where they still exist (network devices, legacy apps).
• Third-party access accounts when the third party authenticates with passwords to your systems.
• Break-glass accounts and emergency access workflows. ²

What you actually need to do (step-by-step)

1) Name the control owner and decision rights

Assign a single operational owner (usually IAM, Security Engineering, or IT Operations) and a GRC control owner accountable for evidence. Auditors look for clarity on who can approve exceptions, who manages the tenant, and who reviews logs. ¹

Daydream fit (practical): Track IA-5(18) ownership, procedure, and recurring evidence tasks as a control record so it does not degrade into “tribal knowledge” during staff turnover. ¹

2) Define the “organization-defined password manager” parameter

Document one of these patterns:

• Single approved password manager (preferred for enforcement and evidence).
• Approved list (only if you can still prove governance and consistent outcomes). ¹

Your control statement should include:

• Product name(s)
• Hosting model (cloud/SaaS or self-hosted)
• Tenant ownership (which org unit administers)
• Required integrations (SSO, MFA, SCIM, directory)
• Required features (generator, vault, sharing, logging, admin controls) ²

3) Set a usage policy that is enforceable

Write a short standard that answers:

• Which accounts must be stored in the manager (work accounts, privileged, shared, third-party-provisioned).
• Prohibited patterns (reused passwords, storing passwords in browsers, spreadsheets, tickets, wikis).
• When sharing is allowed and how (shared vaults, item-level sharing, time-bound access).
• Exception handling (who approves, what compensating controls apply, review cadence). ¹

4) Implement a configuration baseline (minimum viable)

Your baseline should be concrete and testable:

• Enforce SSO and MFA for the password manager itself.
• Disable weak recovery paths that bypass org control (or document compensating controls if business-required).
• Restrict exports; require admin approval or logging for exports where supported.
• Enable audit logging and retain logs according to your logging standard.
• Configure sharing controls (limit external sharing; require shared vaults for teams).
• Enable password generator defaults (length/complexity) aligned to your password policy. ²

5) Cover privileged and non-human credentials explicitly

This is where programs fail.

Privileged admins:

• Require storage of admin credentials in the manager or a dedicated privileged access system, but your IA-5(18) narrative must explain which tool covers which credential class.
• Require individual accountability: no generic “admin/admin” entries shared without traceability. ¹

Service accounts / application secrets:

• If credentials are machine-consumed, a workforce password manager may be the wrong storage mechanism. Document the boundary: store machine secrets in a secrets manager and explain how it meets “manage passwords” intent for that class, or document an exception and compensating controls. Keep the mapping explicit so auditors don’t treat it as a gap. ²

6) Drive adoption with operational hooks (not training-only)

Adoption evidence is easier if you connect the manager to workflows:

• New hire onboarding includes vault provision.
• Privileged access requests require storing credentials in an approved vault before access is granted.
• Offboarding includes transfer of ownership for shared credentials and team vaults. ¹

7) Establish monitoring and recurring reviews

Define and execute:

• Admin review of password manager audit logs for anomalous exports, mass sharing, failed MFA, and admin actions.
• Quarterly access reviews for shared vault membership and privileged vaults (or align to your existing access review cycle, but document it).
• Periodic exception review with expiry dates. ¹

Required evidence and artifacts to retain

Keep artifacts that prove design, implementation, and operation:

Design (what you intended):

• Control narrative for IA-5(18) naming the password manager and scope. ¹
• Password management standard (generation, storage, sharing, exceptions). ²

Implementation (what you configured):

• Screenshot/export of key tenant settings (SSO/MFA required, sharing restrictions, export controls, logging enabled).
• SSO/MFA configuration evidence (IdP policy + app configuration).
• User provisioning evidence (SCIM config, group mappings). ¹

Operation (what you do repeatedly):

• Audit log samples showing real use (logins, item creation, sharing events) with sensitive fields redacted.
• Access review results for shared vaults.
• Exception register with approvals and compensating controls.
• Offboarding tickets showing vault access removal and credential ownership transitions. ¹

Common exam/audit questions and hangups

Expect these questions and pre-answer them in your control narrative:

1. “Which password manager do you employ?” Have the tool name and ownership ready. ¹
2. “Who must use it?” Show scope by role/account type, not “employees.” ²
3. “How do you enforce use?” If you cannot enforce, show governance and monitoring that creates a real standard. ¹
4. “How do you handle shared credentials?” Show shared vault design and access review. ²
5. “What about service accounts?” Provide an explicit boundary statement and compensating controls. ¹

Frequent implementation mistakes (and how to avoid them)

• Buying licenses without scope. Fix: publish a one-page standard that states where the password manager is mandatory and where it is prohibited to store secrets (for example, production app secrets if you use a secrets manager). ²
• Ignoring privileged workflows. Fix: require privileged credentials to be stored in controlled vaults; document break-glass handling. ¹
• Allowing uncontrolled sharing to personal vaults. Fix: enforce team vaults, restrict external sharing, and review memberships. ²
• No evidence of generation. Fix: configure generator defaults and retain a configuration screenshot; show item creation logs as operational proof. ¹
• Exception sprawl. Fix: require written approvals, compensating controls, and expirations for exceptions; review them regularly. ²

Enforcement context and risk implications

No public enforcement cases are provided in the source catalog for this requirement. From a risk standpoint, assessors and customer security reviews treat weak password practices as a predictable path to account compromise, especially where MFA coverage is incomplete or where shared credentials exist. IA-5(18) is a control you can make auditable quickly because the evidence is mostly administrative: configuration, logs, and governance artifacts. ²

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and governance)

• Assign control owner(s) and write the IA-5(18) control narrative naming the password manager. ¹
• Publish the password manager standard: required use cases, sharing rules, and exception process. ²
• Configure SSO + MFA for the password manager and enable audit logging. ¹
• Stand up an exception register and intake workflow (ticket form + approvals). ²

Days 31–60 (implement and prove operation)

• Roll out to priority populations: admins, IT, security, finance, and any team with shared operational credentials.
• Implement shared vault structure and membership management tied to HR/IdP groups.
• Collect initial evidence pack: settings screenshots, SSO/MFA proof, sample logs, onboarding/offboarding procedures. ¹

Days 61–90 (close edge cases and make it repeatable)

• Address service accounts and machine secrets with an explicit boundary statement and documented compensating controls where needed. ²
• Run the first access review for shared vaults; document findings and remediation.
• Establish a recurring evidence calendar (monthly log review, periodic access review, exception review). Track tasks and artifacts in Daydream so evidence collection is continuous, not a scramble before an assessment. ¹

Frequently Asked Questions

Does IA-5(18) require a specific password manager product?

No. The control text uses an organization-defined parameter, so you must name what you approved and show it is used to generate and manage passwords. Document the selection and scope in your control narrative. ¹

Can we rely on browser password storage instead of a dedicated tool?

Treat that as high-risk unless you can govern it equivalently. Auditors typically expect an organization-managed password manager with centralized controls and audit evidence. ²

How do we handle service accounts that can’t use a human password vault?

Define a credential-class boundary: workforce passwords go in the password manager; machine credentials go in a secrets manager or other controlled system. Document the mapping and any exceptions so IA-5(18) does not look incomplete. ²

What evidence is most persuasive in an audit?

Configuration baselines (SSO/MFA, logging, sharing restrictions), provisioning records, and audit logs showing real item creation/sharing activity. Pair that with an exception register and an access review record for shared vaults. ¹

Are shared team credentials allowed under IA-5(18)?

The requirement does not ban sharing, but you need controlled sharing: shared vaults, least-privilege membership, and reviewable access. Avoid unmanaged spreadsheets or emailing credentials. ²

How should a GRC team operationalize this without becoming the system admin?

Own the requirement statement, scope, evidence map, and review cadence, then hold IAM/IT accountable for configuration and logs. Daydream can track the control owner, procedure, and recurring evidence artifacts so you stay audit-ready. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5