What HITRUST 10 Password Management asks for and why it is hard to pass
Password Management is one of the 19 HITRUST assessment domains, and it covers traditional passwords and credentials: the policies that set how they must be built and changed, how they are stored, and the multi-factor authentication that backs them up. If you are preparing for an e1, i1 or r2 assessment, this domain is scored alongside the other 18, and the domain average must clear the threshold HITRUST sets for your assessment type. Password Management is not a domain you can pass by pointing at one policy document. An assessor will look at how credentials behave in every system in scope.
The domain is hard for three recurring reasons. First, the number of places a credential can live is large: directories, applications, databases, network devices, admin consoles, service accounts and CI/CD pipelines each carry their own rules. Second, shared and generic accounts are common in older environments and are difficult to tie to a named owner or to rotate. Third, MFA is often enforced on the main login portal but not on every administrative path, legacy application or remote access route. The HITRUST 2025 Trust Report names Password Management, tied with Data Protection & Privacy in 2024, as the lowest scoring r2 domain in 2024, and as the lowest r2 domain in 2023. Treat that as a signal that assessors are finding the same gaps repeatedly.
Before you start evidence collection, build an inventory of every credential store and authentication path inside your assessed scope, then confirm which ones your policy actually governs. Ask your team to show you, system by system, the password rule, the storage method and the MFA state. Where a system cannot meet the rule, record the gap now, since it will be scored later. Confirm with your assessor which requirement statements in this domain apply to your r2 scope and how they are sampled, because the scoring treatment differs by assessment type.
Which systems, users and credentials fall in scope for password management
Scope determines how much password and credential work a HITRUST assessment covers. The decisions below change the control population more than any single tool choice, so settle them before readiness work starts.
In-scope applications and their user populations
Every application that stores, processes or transmits in-scope data needs an explicit answer on how its users authenticate. List each application, its login method and the user groups that reach it, including administrators and any shared or legacy logins. Ask whether a single identity provider covers each application or whether some still hold local password stores. Each gap is a place where a requirement statement could fail.
Workforce versus customer identities
Workforce accounts and customer accounts often follow different password policies, recovery flows and MFA rules, yet both may sit in the assessed scope. Decide whether customer-facing login pages are in scope and document which population each control covers. Assessors will ask whether the same policy applies to each population or whether the difference is justified.
Service and administrative accounts
Service accounts, scheduled jobs and privileged administrator accounts usually carry passwords that never expire and are shared among several people. Inventory them, record their owners and state how each credential is stored and rotated. These accounts are frequently the weakest part of the password story, so an incomplete inventory is a common source of gaps.
Password vaults and secrets stores
Vaults and secrets stores hold credentials for other systems, so they become in-scope components in their own right. Confirm which product holds each secret, who can read it and how access is logged. A tool such as OpenBao, which issues dynamic short-lived credentials and revokes them on expiry, changes what must be evidenced, so describe its configuration in the scope document rather than assuming its features satisfy the requirement.
Identity providers and the customer's inherited boundary
Identity providers that authenticate users and enforce second factors are in scope whether they run in the organization's own environment or a cloud provider's. In HITRUST's OCI inheritance example, the cloud provider's controls can be inherited, but the customer still defines and enforces credential policies and MFA for its own application users. Confirm with the provider's shared responsibility matrix exactly which password and MFA controls stay with the organization.
How an assessor tests password policy, storage and MFA
The assessor starts by reading what the organization has defined for passwords and credentials: the written password policy, the standards that implement it, and the configuration of the identity provider, directory and applications that enforce it. The assessor compares the two. A policy that sets a minimum length, reuse rule or lockout threshold is only meaningful if the system settings match it, so the assessor looks for the actual values in exported configuration rather than accepting a summary. Expect to show who approved the policy, when it was last reviewed and how changes to it are recorded.
- Written policy: A dated, approved document covering credential creation, complexity, reuse, expiry where used, and storage rules.
- Enforcement settings: Exported configuration from directories, identity providers and key applications showing the values in force.
- Secrets handling standards: Rules for service accounts, API keys and shared credentials, including who may hold them.
- Change history: Records showing when settings were changed, by whom and under which approval.
- MFA policy statements: The defined scope of multi-factor authentication, including which user groups and access paths it covers.
Before fieldwork, confirm that every configuration value cited in the policy can be exported with a timestamp and matched to the written standard.
Live testing checks whether the configured controls behave as documented. The assessor, or a tester working under the assessor's direction, attempts logins and credential changes against systems in scope and observes the result. The goal is to confirm enforcement at the point of use: a password that violates the policy should be rejected, repeated failed attempts should trigger lockout, and an MFA prompt should appear where the policy says it must. Testing usually covers each major authentication path, not only the primary web login.
- Creation and reuse: Attempts to set a non-compliant or previously used password should be refused by the system.
- Lockout behavior: Repeated failed logins should produce the configured lockout or delay, with the event recorded in logs.
- Second factor on each path: Web, API, administrative and remote access should each show the required second factor.
- Storage inspection: Passwords should not be readable in plain text in databases, configuration files or logs, and should be stored using an approved hashing method.
- Secrets in code: Repositories and pipelines may be scanned for committed credentials.
Confirm test accounts, test windows and rollback steps with the assessor before live testing, so that production users are not disrupted.
Assessors do not check every account. They select a sample from the population of user, administrator and service accounts in scope, then trace each sampled account back to its approval, its current configuration and its authentication record. Sampling tests whether the controls are applied consistently in practice, which is where many gaps appear. The assessor also reviews exceptions: accounts exempted from MFA, passwords set to never expire, shared credentials and temporary waivers. Each exception should have a documented reason, an owner, an approval and an end date.
- Account population: A complete, current list of accounts in scope, generated from the directory rather than assembled by hand.
- Individual tracing: For each sampled account, the enrollment record, the enforced second factor and the most recent authentication event.
- Exception register: Every waiver with its justification, approver, compensating control and expiry.
- Lockout and failed-login records: Evidence that lockout events were generated and reviewed.
- Departed users: Sampled leavers whose accounts were disabled or removed on time.
When preparing, ask whether the population report can be produced for any date in the assessment period, since assessors may ask for it.
Password Management is among the domains that organizations find hardest to score well in, and the findings tend to follow a few patterns. The most common is a policy that exists on paper but is not enforced by the systems that matter. The second is MFA that protects the main login page while leaving a legacy protocol, an administrative console, an API or a remote access route without a second factor. Assessors also report exceptions that have no owner, expiry or compensating control. These findings are usually found by comparing the three evidence types, which is why a gap in one often shows up as a contradiction between the others.
- Policy not enforced: The written rule requires a control that the system does not apply, or applies only to some users.
- Partial MFA coverage: Second factors missing from one access path, such as a legacy protocol, a service portal or a vendor-hosted application.
- Undocumented exceptions: Waivers granted informally, with no approval, expiry or review.
- Shared and service credentials: Passwords shared among staff or embedded in scripts without rotation or ownership.
- Logs that do not match: Lockout or failed-login events absent from logs, so the control cannot be shown to operate.
Before fieldwork, test each access path yourself and reconcile the configuration export against the account population.
Implementing password management controls in a self-hosted environment
This sequence moves password management from scattered accounts and hard-coded secrets to one inventory, one approved policy, centrally enforced MFA and a managed secrets store. Each step ends with a record an assessor can sample.
Inventory every credential and account
Start by listing every account that can reach the in-scope environment: human user accounts, service accounts, application logins, database users, API keys, CI/CD tokens and shared administrator accounts. The security team and system owners do this together, because application owners usually know about accounts that the directory does not show. Record the owner, the system, the account type and whether it is interactive or non-interactive. The output is a credentials inventory that is reviewed and signed off by the control owner. You are done when a sample of production systems can be traced back to a named inventory entry.
Define and approve the password and MFA policy
Write the password and authentication policy that governs the inventory: minimum length and complexity, rules for reuse and rotation where still required, lockout behavior, recovery and reset procedures, where MFA is mandatory and which accounts can never use a static password. Management approves the policy, and the document names the control owner and the review cycle. Your policy must match what the platforms can actually enforce, so confirm each setting against the product documentation before approval. The output is an approved, versioned policy that maps each rule to a system that enforces it.
Centralize identity and enforce MFA
Route interactive logins for the self-hosted applications through one identity provider so that password rules and second factors are applied in one place rather than per application. For example, authentik can validate enrolled second factors during login, including TOTP apps, WebAuthn and FIDO2 passkeys, and static recovery codes. For Linux hosts and internal directories, FreeIPA supports HOTP and TOTP tokens, including hardware tokens, and can proxy OTP checks to an existing RADIUS server during migration. Confirm which factor types your organization permits and how recovery codes are issued and stored. The output is a configuration export and a test record showing that an account without a second factor cannot complete login to a protected application.
Move secrets out of code and configuration
Search source repositories, pipeline definitions, container images and configuration files for embedded passwords, tokens and keys. GitLab Community Edition pipeline secret detection scans files committed and pushed to the repository in a CI/CD job and writes findings to a gl-secret-detection-report.json artifact, which gives you a repeatable scan and a record. Rotate every credential found, because removing it from the code does not invalidate it. Keep the scan as a required pipeline job so new commits are checked. The output is a scan report for each in-scope repository and a list of rotated credentials with the date and owner of each rotation.
Store secrets in a managed vault with short-lived credentials
Place the remaining secrets in a central store. OpenBao stores secrets encrypted in one place, can generate dynamic short-lived credentials for systems such as databases, attaches leases that revoke secrets automatically on expiry, and can revoke single secrets or whole trees of credentials. Replace static shared accounts with dynamic credentials wherever the target system supports it, and document the exceptions that still need static secrets along with their compensating controls. Confirm the storage, unseal and audit logging features in your deployed version before you rely on them. The output is a secrets register listing each secret path, the consuming system, the credential type (static or dynamic), the owner and the lease or rotation method.
Set review, rotation and offboarding routines
Schedule recurring reviews of the credentials inventory, the secrets register and the MFA enrollment status for privileged and service accounts. Define the trigger for each review, such as a role change, a system retirement or an employee leaving, and link offboarding to disabling directory accounts, revoking sessions, removing enrolled tokens and revoking any secrets the person could read. Keep a record of each review with the reviewer, the date, the findings and the actions taken. The output is a signed review record for each cycle and an offboarding checklist tied to the directory and vault. Ask your assessor which review frequency they expect for your scope and check it against the requirement statements in the assessment.
Evidence that passes password management testing and how to keep it current
Assessors testing 10 Password Management look for a written policy, proof that it is enforced in each system, and records that show it held over the assessment period. The cards below cover the artifacts that usually carry that proof, and the routine exports that keep them current between assessments so that nothing has to be rebuilt in the weeks before fieldwork begins.
Approved password and MFA policy
The policy is the anchor artifact. It should state minimum length, complexity or passphrase rules, reuse and history limits, rotation rules where they still apply, lockout thresholds, and which applications must enforce MFA. Confirm that the approval date, owner and version are on the document, and that the policy names the systems it covers. A policy that describes controls no system enforces is one of the most common reasons this domain scores low.
Identity provider and MFA enrollment exports
Export enrollment status from the identity provider on a fixed schedule, listing each user, the second factors enrolled, and any accounts without MFA. For authentik, the authenticator validation stage determines which second factors a login can use, including TOTP, WebAuthn and FIDO2 passkeys, so keep the stage configuration and a dated export of enrolled devices together. Record who approved each exception to MFA and when it expires.
Secrets store audit and lease records
OpenBao keeps secrets encrypted in one place, issues dynamic short-lived credentials for systems such as databases, and attaches leases that revoke secrets on expiry. Retain the audit device output, the lease listings and records of manual revocations. Assessors often ask to see that a credential was revoked after a staff change, so show both the revocation event and the time it took place.
Pipeline secret detection reports
Secret detection in the CI/CD pipeline scans committed and pushed files and writes results to a gl-secret-detection-report.json artifact. Archive these reports per pipeline run, not only the latest one, and record how each finding was triaged, rotated or marked as a false positive. A dated series of reports shows that scanning ran continuously, while an unexplained gap in the series is a finding in its own right.
Access review and exception records
Periodic reviews confirm that each account still needs its credentials, MFA settings and privileged access. Keep the signed review, the list of accounts reviewed, the reviewer, the removals made and the follow-up dates. Exceptions, such as service accounts that cannot use MFA or legacy applications with static passwords, need a documented reason, a compensating control and an expiry date that someone reviews.
Lockout and authentication settings snapshots
Capture configuration snapshots of lockout thresholds, lockout duration, session timeouts and password rules from each in-scope identity and application system. Store them with a date and the name of the person who exported them. Comparing a snapshot against the approved policy each quarter shows drift early, and a change record should explain any setting that differs from the policy.
What meeting HITRUST password management costs in money and effort
This table breaks down the cost components of meeting the Password Management domain, showing who gets paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to build a quote request, since no prices or durations are published here and the real figures depend on your environment and written scope.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Licenses or tooling | Software vendor or subscription provider | Recurring | Commercial credential vaults and MFA licenses scale with users or applications; self-hosted open-source options such as OpenBao, authentik and FreeIPA can remove license spend but not operating effort |
| Engineering time to configure and migrate | Internal platform team or implementation partner | One-time | Number of applications, legacy systems without MFA support, and whether FreeIPA or authentik needs to proxy an existing RADIUS server during migration |
| Service account and secret inventory | Internal security and platform engineers | One-time, then recurring | Number of service accounts and hard-coded credentials found; each one needs an owner, a rotation approach and a documented exception if it cannot be rotated |
| Secret scanning and pipeline controls | Internal DevOps team | One-time setup, recurring upkeep | Number of repositories and CI/CD pipelines; pipeline secret detection writes a report artifact on each run that someone must review and act on |
| Evidence upkeep | Internal compliance or security staff | Recurring | Frequency of password policy reviews, access reviews, MFA enrollment reports and rotation logs, and the number of systems each one covers |
| External readiness review | Independent consultant or readiness licensee, if engaged | One-time, sometimes repeated before each assessment | Scope size, maturity of existing evidence and how many gaps the team has already closed; ask for the review scope in writing |
| Assessor fees | Authorized HITRUST External Assessor organization | Recurring per assessment cycle | Assessment type (e1, i1 or r2), number of requirement statements in scope and the fieldwork window, which is at most 90 days for validated assessments |
Who owns password management, who helps, and where the auditor stops
Your organization owns the credential decisions that HITRUST expects to be made, approved and enforced by management, not delegated to a tool. Policy, account exceptions and risk acceptance stay with you, and an assessor will ask who made each decision and when. Because this domain depends heavily on how your own application users sign in, much of the work sits with your product and identity owners.
- Password policy: Define length, complexity, reuse, lockout and expiry rules, and record who approved them.
- MFA scope: Decide which user groups, applications and privileged accounts must use a second factor, and which exceptions apply.
- Exception handling: Approve, time-limit and review any deviation from policy, with a named owner.
- Credential lifecycle: Set rules for issuing, resetting, recovering and retiring credentials for staff and customers.
- Evidence ownership: Keep the policy, approval records and exception log current, since these are what the assessor samples first.
Check that each decision has a named approver and a review date, because missing ownership is a common reason this domain falls short.
An implementation partner such as DeployOpen can configure the systems that enforce your password and MFA decisions and prepare the records that show they operate. The partner works inside your infrastructure on self-hosted open-source platforms, but it does not decide policy and it does not issue any report or certification. Its output is a working, documented system and a set of evidence your team owns.
- Identity configuration: Set up directory and login flows, password rules and enrolled second factors, such as TOTP, WebAuthn and FIDO2 passkeys, in platforms like FreeIPA or authentik.
- Secrets handling: Configure a secrets store such as OpenBao for short-lived, revocable credentials, and scan repositories for committed secrets with a pipeline check.
- Evidence preparation: Export configuration, enrollment and detection reports, and organize them against each requirement statement.
- Gap testing: Verify that enforcement works as the policy states, and document the results for your own review.
- Documentation and handover: Write runbooks so your staff can operate and audit the controls after the engagement ends.
Confirm the scope, deliverables and timeline in writing before work starts, since engagements are fixed-scope.
The independent assessor tests your controls and writes the report. Only Authorized HITRUST External Assessor organizations may perform the validated assessments submitted for certification, and HITRUST performs central quality assurance before any report is issued. Neither your organization nor an implementation partner can produce a validated result, however well prepared the evidence is.
- Independence: Confirm the assessor is an Authorized HITRUST External Assessor organization using HITRUST's public assessor directory before you engage it.
- Testing: Expect the assessor to sample accounts, MFA enrollments, exception approvals and secret scan results, and to compare them with policy.
- Fieldwork window: The validated fieldwork window is at most 90 days for e1, i1 and r2 assessments.
- Scoring: The assessor scores requirement statements; HITRUST reviews the submission before the report is issued.
- Separation of roles: Keep the implementation partner and the assessor separate so the assessor's testing stays independent of the work it reviews.
Ask the assessor how it samples this domain and which evidence it expects before the fieldwork begins.
Common password management gaps and how to close them
Password Management is one of the domains HITRUST reports as the lowest scoring in r2 assessments, and the gaps behind that score tend to repeat across organizations. The cards below cover the places where credentials escape policy: shared accounts, legacy paths, code, service credentials, configuration and records. Each card ends with the check to run before an assessor does.
Shared and generic admin accounts
Shared administrator logins, such as a single root or admin account used by several engineers, break the link between a person and an action. Assessors look for named accounts, a documented reason for every generic account that remains, and a record of who holds the password. Close the gap by issuing named privileged accounts, placing any break-glass credential in a vault with checkout logging, and listing every remaining generic account with an owner.
MFA gaps on legacy and API paths
Most organizations enforce MFA on the web console and miss older protocols, mail clients, VPN fallbacks and API endpoints that accept a password alone. An assessor who tests one of these paths can fail the requirement even when the main login is strong. Inventory every authentication entry point, confirm which ones accept single-factor credentials, and either enforce a second factor or document a compensating control and its owner.
Hard-coded secrets in repositories
Passwords, API keys and tokens committed to source code remain readable in version history long after they are removed from the current file. Run secret detection on every commit and push, retain the scan output, and treat each finding as a credential to rotate. For example, a pipeline job that writes a secret detection report as a build artifact gives the assessor a dated record of the scan and its findings.
Unrotated service credentials
Database passwords and service account secrets often stay unchanged for years because no one owns the rotation. A credential that never expires is hard to justify in a validated assessment. Move these secrets into a central store that issues short-lived credentials where the target system supports it, attach a lease so each credential revokes itself, and record who approved any long-lived exception.
Policies not enforced in configuration
A written password policy with a minimum length, a lockout threshold and a reuse rule means little if the identity provider accepts weaker values. Assessors compare the policy document with the live settings and ask for exported configuration as evidence. Export the directory or identity provider settings, compare them with the written policy line by line, and correct any mismatch before the assessment window opens.
Missing review and exception records
Access to credentials changes as people join, move and leave, and assessors ask for proof that someone checked. Gaps appear when reviews happen informally, exceptions have no expiry and no approver, or review results are not kept. Schedule periodic reviews of privileged and service credentials, keep signed or ticketed records of each review, and set a review date on every exception so it cannot persist unnoticed.
Questions buyers ask about HITRUST password management
How much effort does password management take in a HITRUST assessment?
Password management is one of the domains that needs the most attention in a HITRUST assessment, and the effort depends mostly on how many of your own application users and administrative accounts sit in scope. The Trust Report states that Password Management, tied with Data Protection & Privacy, was the lowest scoring r2 domain in 2024 and the lowest r2 domain in 2023, so buyers should plan for more than a policy document. Effort comes from three areas: written credential policies, technical enforcement in each system, and evidence that the enforcement works over the assessment period. Ask any consultant to break their quote down by these three areas and to name the systems they expect to review.
Can we run HITRUST password management controls in-house?
Yes, an organization can build and operate these controls with its own staff, and HITRUST does not require an outside consultant to do so. The harder question is whether your team can produce consistent evidence across every in-scope system and keep it current through the assessment fieldwork. Internal teams often underestimate the work of tying policy settings to configuration exports, MFA enrollment records and access logs. A useful self-check is whether one person can show, for each in-scope application, how passwords are stored, how second factors are enrolled and how a failed login is handled.
What does password management ask from the engineering and identity teams?
The work falls into three groups that engineers can plan against:
- Storage and secrets: keep credentials out of source code and configuration files, and hold application secrets in a managed store. OpenBao stores secrets encrypted in one place, can issue dynamic short-lived credentials for systems such as databases, and attaches leases that revoke secrets automatically on expiry.
- Repository hygiene: scan committed code for leaked secrets. GitLab Community Edition pipeline secret detection scans files committed and pushed to the repository in a CI/CD job and writes the results to a gl-secret-detection-report.json artifact in every tier.
- Second factors: enforce MFA for your own application users. authentik's authenticator validation stage checks enrolled TOTP apps, WebAuthn and FIDO2 passkeys, Duo, SMS codes, email codes and static recovery codes during login.
Confirm each tool's current capabilities against its documentation and your own environment before you rely on it as evidence.
How does password management affect e1 scoring compared with r2?
The scoring rules differ, so the same weak control can cost you more under one assessment type. For e1 and i1 certifications, the core requirement statements in each domain must average at least 83. For r2, each domain must average at least 62 across all of its requirement statements. The e1 has 44 requirement statements in v11.9.0, and the Trust Report notes that 30% of e1 requirements relate to the Access Control and Password Management domains combined, so a weak result here can drag down a small assessment quickly. Because every e1 requirement is also in the i1 and r2 baselines, work done for an e1 carries forward, but the r2 averaging rule leaves less room to absorb a poor domain.
Can password management be inherited from a cloud provider?
Only in small part. HITRUST's inheritance example for Oracle Cloud Infrastructure shows Password Management as only slightly inheritable: the customer still defines and enforces credential policies and multi-factor authentication for its own application users. A provider may cover the identity platform's own administrative accounts or underlying infrastructure, but the application layer usually stays with you. Check the provider's shared responsibility matrix line by line, and confirm with your assessor which requirement statements the provider's result actually covers before you plan evidence collection.
How should we choose a partner for HITRUST password management work?
Separate the partner's role from the assessor's role. An implementation partner, such as DeployOpen, can plan, configure and document the controls, and prepare the evidence, in your own infrastructure. Only an Authorized HITRUST External Assessor organization can perform the validated assessment submitted for certification, and HITRUST performs central quality assurance before issuing reports. Ask prospective partners for a written scope that names the systems, the credential and MFA settings they will change, the evidence they will hand over, and what they will not do. Ask for the assessor's independence rules too, so the same firm is not both designing and testing your controls.
How long does a validated assessment fieldwork window last?
The assessor's validated assessment fieldwork window is at most 90 days for e1, i1 and r2 assessments, according to the HITRUST Assessment Handbook v1.1. Password management evidence should be stable well before fieldwork starts, because changing a credential policy mid-window creates questions the assessor must test. Plan for your password settings, MFA enrollment and secret handling to be in their final state for a meaningful period before the window opens. Confirm the exact timing with your External Assessor, since their engagement plan sets the schedule.
How DeployOpen prepares password management for a HITRUST assessment
DeployOpen works as an implementation partner for the password management domain. We plan, implement, harden and document the self-hosted identity, multi-factor authentication and secrets platforms that your organization runs inside its own cloud accounts, data centers or air-gapped networks, and we prepare the configuration records, screenshots, exports and evidence trails that an assessor will ask for. The organization still owns its credential policies, its MFA enforcement for application users and its decisions about lockout and recovery. DeployOpen does not issue HITRUST reports or certifications. Only an Authorized HITRUST External Assessor performs the validated assessment, and HITRUST performs its own quality assurance before any report is issued. Scope, deliverables and timelines are agreed in writing before work begins, so you can see which platform components, policies and evidence sets are covered and which are left to your team.
In practice, the platform work for this domain usually covers three areas. A secrets platform such as OpenBao can hold service credentials in one encrypted store and issue short-lived, leased credentials for databases and other systems, which gives the assessor a clear record of how credentials are created, renewed and revoked. An identity provider such as authentik can enforce second factors at login, including TOTP apps, WebAuthn and FIDO2 passkeys, and it can hold a defined set of recovery codes under documented rules. Where directory services are involved, FreeIPA supports HOTP and TOTP tokens and can proxy OTP checks to an existing RADIUS server during migration. Each of these needs a written configuration baseline, a tested enrollment and recovery procedure and logs that show enforcement, which is where most of the evidence effort sits. A repository secret scan, such as GitLab pipeline secret detection writing to its JSON report artifact, can add a check that credentials are not committed to code. Confirm with each vendor which settings and log fields your version exposes before you rely on them as evidence.
