The Ultimate Guide to CMMC Password Vaults (IA.L2-3.5.10)

For CMMC 2.0 Level 2 IA.L2-3.5.10, your organization must ensure passwords are cryptographically protected wherever they are stored and transmitted: systems must store password verifiers as strong one-way hashes, password vaults must encrypt retained secrets, and authentication traffic must use protected protocols such as TLS. This cmmc password vault guide gives an ISSO or FSO a practical method to identify password exposure, configure systems and vaults correctly, collect objective evidence, and test the result before an assessment.

What does IA.L2-3.5.10 actually require?

NIST SP 800-171 Rev. 2 requirement 3.5.10 states: “Store and transmit only cryptographically-protected passwords.” The corresponding CMMC Level 2 practice, IA.L2-3.5.10, has two assessment objectives: passwords are cryptographically protected in storage, and passwords are cryptographically protected in transit.

The central distinction is important for assessment preparation. A system that validates a user password should not retain the original password in a database, configuration file, spreadsheet, script, or ticket. Instead, it should retain a one-way password verifier, generally a salted hash produced with a password-specific algorithm such as Argon2id, bcrypt, scrypt, or PBKDF2. A one-way transformation is designed to prevent recovery of the original password from the stored value.

Passwords held in a password manager are somewhat different. A vault must be able to reveal a saved credential to an authorized user, so the vault uses strong encryption rather than a one-way hash for those retrievable secrets. That does not make a vault noncompliant; it means you should document the distinction between an application’s password-verifier database and an enterprise vault’s encrypted credential store.

Which passwords and systems fall within the control?

Start with every password used to access systems that process, store, or transmit CUI, plus supporting systems whose compromise could affect the CUI environment. For a small contractor, that commonly includes Microsoft 365 or Google Workspace identities, Windows Active Directory accounts, VPN accounts, engineering file repositories, managed firewalls, backup consoles, endpoint-management tools, cloud administrative accounts, accounting or ERP integrations, and administrator credentials stored in a vault.

Do not limit scope to employee workstation passwords. Service accounts, local administrator accounts, API secrets used as passwords, emergency “break-glass” accounts, shared vendor-support credentials, and passwords embedded in scripts are frequent assessment and security weaknesses. A stored password in a PowerShell script on an engineering server is still a stored password, even if the script is used only monthly.

Document the system owner, authentication method, storage location, transmission path, and evidence source for each category. This inventory gives you a defensible answer when an assessor asks where passwords exist and how you verified their protection.

How should password storage be protected?

For internally developed applications, require unique salts and an adaptive, password-hashing function. Avoid general-purpose fast hashes such as unsalted MD5, SHA-1, SHA-256, or SHA-512 as standalone password storage mechanisms. A fast hash may be one-way in theory, but it is much easier to crack offline after database theft. This is where IA.L2-3.5.7 matters: weak passwords can still be guessed if attackers obtain their hashes.

For commercial or cloud services, the ISSO usually cannot inspect the hashing algorithm directly. Instead, maintain vendor documentation, security attestations, contractual security information, system configuration records, and an account of why the service is approved for the CUI boundary. Do not invent technical claims about a SaaS provider’s internal password hashing that you cannot substantiate.

Password vaults should use an encrypted vault architecture, a strong master-password or SSO-based authentication process, MFA, role-based access, and audit logging. Restrict vault exports, prohibit unencrypted emergency credential lists, and make sure the vault itself is included in backup and recovery planning.

How must passwords be protected in transit?

Passwords must not traverse networks in cleartext. Require HTTPS with modern TLS for web applications, secure VPN authentication, encrypted remote administration protocols, and secure directory-service connections. Disable or remediate legacy services and protocols that expose credentials or password-equivalent values, including Telnet, FTP, HTTP administration portals, LDAP simple bind without TLS, and NTLMv1 where it remains enabled.

A practical design point: do not send a reusable password hash from a client as though it were the password. If intercepted, that hash can become a pass-the-hash credential. For normal web authentication, the user enters the password into a TLS-protected session, and the server compares it to its stored verifier. For other protocols, use supported secure authentication methods rather than custom password-handling designs.

What should a cmmc password vault guide include for evidence?

Your evidence package should connect policy, technical configuration, and operating practice. An assessor should be able to see that your written policy requires cryptographic protection, your systems enforce it, and your personnel actually use the approved vault and access methods.

How do you implement IA.L2-3.5.10 step by step?

1. Define the authentication boundary. Identify CUI systems and the supporting identity, network, backup, and administrative systems that could affect them. Include third-party hosted services and remote-access paths.
2. Create a password-flow inventory. For each in-scope system, record where a password originates, whether it is stored, the storage format, how it travels, and who administers the system. Flag cleartext configuration files, shared spreadsheets, browser-saved credentials, and legacy protocols.
3. Set an approved password-storage standard. State that internally developed systems must use salted, adaptive password hashing, and that recoverable credentials must be stored only in the approved encrypted vault. Require review by IT or the security lead before a new application is placed into production.
4. Configure the enterprise vault. Require MFA for all vault users, use role-based collections instead of shared master passwords, assign named custodians for emergency accounts, enable event logging, and restrict vault exports. Review vault membership at least quarterly and immediately after termination or role change.
5. Harden password transmission. Enforce HTTPS and TLS 1.2 or TLS 1.3 on internal and external web services, redirect HTTP to HTTPS where appropriate, disable insecure management interfaces, and use LDAPS or StartTLS for directory integrations.
6. Remediate embedded and shared credentials. Replace passwords in scripts with managed service accounts, certificate-based authentication, cloud secret-management services, or vault-based secret injection where technically feasible. If a legacy application requires a fixed credential, store it in the vault and document the compensating controls and remediation plan.
7. Test and retain evidence. Review TLS scanner results, test authentication paths, inspect application configurations, review vault audit logs, and retain screenshots or exports with dates and responsible personnel.

For example, a 68-person aerospace component manufacturer uses Microsoft 365, a Windows domain, a VPN, SolidWorks PDM, and a cloud backup console to support controlled engineering drawings. Its ISSO identifies that the backup console password was copied into a workstation script for nightly validation. The organization replaces the script with a service account and a vault-managed secret retrieval method, limits vault access to the IT manager and backup administrator, and retains the revised script review, vault event log, and backup-console access configuration as evidence.

For a self-hosted supplier portal, the same organization can document its HTTPS and password-verifier configuration in an implementation record such as the following:

password_hashing_algorithm = Argon2id
argon2_memory_cost_kib = 65536
argon2_time_cost = 3
argon2_parallelism = 4
minimum_tls_version = TLSv1.2
http_login_endpoint = disabled
secure_cookie = true
http_only_cookie = true

Exact parameters should be validated against the application framework, available server resources, and current vendor guidance. The compliance point is not a particular number; it is demonstrating that the organization deliberately uses a modern password-hashing method and a protected authentication channel.

What is the IA.L2-3.5.10 compliance checklist?

• ☐ An inventory identifies every in-scope system that stores, validates, transmits, or administers passwords.
• ☐ Internally developed applications store only salted, one-way password verifiers using an approved adaptive algorithm.
• ☐ No passwords are retained in spreadsheets, tickets, scripts, emails, shared documents, or unencrypted configuration files.
• ☐ Recoverable administrator, service, vendor, and emergency credentials are held in an approved encrypted vault.
• ☐ Vault MFA, role-based access, audit logging, access reviews, and export restrictions are configured and evidenced.
• ☐ Web login pages and administrative interfaces use HTTPS with current TLS settings.
• ☐ Cleartext and weak authentication paths, including Telnet, FTP, HTTP administration, and unsecured LDAP binds, are disabled or remediated.
• ☐ Password policy and MFA controls support IA.L2-3.5.7 and reduce offline cracking risk.
• ☐ Configuration exports, vendor documentation, test results, screenshots, and review records are retained in the assessment evidence repository.
• ☐ The SSP describes the implementation, system scope, responsible roles, and any documented POA&M items.

Frequently asked questions about CMMC password vaults

Does CMMC require us to buy a password manager?

No. IA.L2-3.5.10 does not name a product. However, an encrypted enterprise password vault is often the most practical way for a small contractor to eliminate shared spreadsheets, unmanaged browser passwords, and insecure handling of privileged credentials.

Is a password hash the same thing as encryption?

No. A password hash is intended to be one-way and is used by systems that verify passwords. Encryption is reversible by an authorized party holding the key, which is necessary when a vault must retrieve a stored credential for an approved user or process.

Can we use SHA-256 to store application passwords?

Not by itself. SHA-256 is a general-purpose fast hash and is not appropriate as the sole password-storage mechanism. Use a salted, adaptive password-hashing function such as Argon2id, bcrypt, scrypt, or PBKDF2, following your platform’s supported implementation guidance.

Does TLS alone satisfy the transmission portion of IA.L2-3.5.10?

TLS is a primary control for protecting passwords entered into web applications and administrative portals in transit, but you must verify the entire authentication path. A TLS-protected login page does not correct a backend system that stores plaintext passwords or a separate legacy protocol that transmits credentials without encryption.

What evidence will an assessor expect for this practice?

Expect requests for policy language, system inventories, vault configuration and access records, screenshots or exports showing TLS and identity settings, application design or vendor documentation, vulnerability-scan results, and interviews with personnel responsible for account and vault administration.

Schedule a focused password-flow review with your IT administrator and system owners, then add the resulting evidence and remediation items to your CMMC assessment repository.