Identification and Authentication 3.5.10 (3.5.10)
Store and transmit only cryptographically-protected passwords.
Get Full GuidanceWhat Is This CMMC Control?
This control requires that passwords are never stored or transmitted in plain text. Instead, passwords must be protected using cryptographic techniques - specifically salted one-way hashing for storage and encryption for transmission. This prevents passwords from being readable if intercepted during transmission or if storage systems are compromised.
Control Intent
Prevent unauthorized access to passwords by ensuring they cannot be read or recovered in their original form during storage or transmission, thereby protecting user credentials from compromise even if underlying systems or communications are breached.
Who This Control Applies To
- •All systems that store user passwords or password hashes
- •All systems that transmit passwords during authentication
- •Authentication servers and identity management systems
- •Applications with local user accounts
- •Web applications and portals requiring user login
- •Remote access systems (VPN, RDP, SSH)
- •Database systems storing user credentials
- •Active Directory and LDAP directories
- •Cloud identity providers and SSO systems
- •API authentication systems using password-based methods
Not Applicable When
- •Systems using only certificate-based authentication with no password storage
- •Systems using only hardware token authentication (smart cards, FIDO2) with no password fallback
- •Passwordless authentication systems using only biometrics or cryptographic keys
- •Systems that exclusively use federated authentication with no local password storage
- •Read-only systems with no authentication requirements
- •Systems that have been decommissioned and contain no active credentials
Key Objectives
- 1Passwords stored in systems must use salted one-way cryptographic hashing to prevent recovery of plaintext passwords from stored values.
- 2Passwords transmitted across networks must be encrypted to prevent interception and unauthorized disclosure during authentication processes.
- 3Cryptographic protections for passwords must use approved algorithms and implementations that resist known attack methods.
Sample Self-Assessment Questions (Partial)
Does your organization store any user passwords in databases, configuration files, or other storage systems?
Are passwords transmitted over networks during user login or authentication processes?
Implementation Approaches (High-Level)
Modern Password Hashing with Bcrypt/PBKDF2/Argon2
Implement industry-standard password hashing using bcrypt, PBKDF2, scrypt, or Argon2 with unique per-user salts and appropriate work factors. Transmit passwords only over TLS 1.2+ encrypted connections.
Active Directory with Kerberos/NTLM
Leverage Windows Active Directory for centralized authentication using Kerberos or NTLM protocols, which provide cryptographic protection for passwords during storage and transmission.
Federated SSO with SAML/OAuth/OIDC
Implement federated single sign-on using SAML, OAuth 2.0, or OpenID Connect, where passwords are only stored and validated by the identity provider and never transmitted to relying applications.
Database Native Password Hashing
Use database management system built-in password hashing and authentication mechanisms that provide cryptographic protection for stored credentials.
Secrets Management Systems
Use dedicated secrets management platforms to store and transmit passwords and credentials with cryptographic protection, eliminating plaintext storage in code or configuration files.
Evidence & Assessment Notes
Expected Evidence
Organizations should maintain documentation and evidence demonstrating compliance with this control. This may include policy documentation, configuration records, audit logs, access reviews, and other relevant artifacts that show how the control is implemented and maintained.
Plan of Action & Milestones (POA&M)
If legacy systems cannot support modern password hashing, document specific technical limitations, plan for system upgrades or replacements, and implement compensating controls such as network segmentation and enhanced monitoring For systems using weak hashing algorithms (MD5, SHA-1), create a migration plan to bcrypt, PBKDF2, or Argon2 with specific timelines and resource requirements If passwords must be transmitted over unencrypted channels due to legacy system constraints, document the specific systems, implement network-level encryption (VPN, IPsec), and plan for application upgrades For hardcoded passwords in scripts or configuration files, implement secrets management solutions with specific deployment timelines and training requirements If third-party applications store passwords insecurely, document vendor limitations, request security roadmap from vendor, and consider alternative solutions if vendor cannot meet requirements When implementing password hashing upgrades, plan for user password resets or migration strategies that maintain security during transition For database systems using legacy authentication, plan for version upgrades and test compatibility with applications before deployment Include specific technical requirements, resource needs, responsible parties, and measurable milestones in all POA&M entries
Frequently Asked Questions
What is the difference between encryption and hashing for password storage?
Encryption is reversible - encrypted passwords can be decrypted back to plaintext if you have the key. Hashing is one-way - hashed passwords cannot be reversed to obtain the original password. This control requires one-way hashing for storage because even if an attacker gains access to the password database, they cannot recover the actual passwords. Encryption is acceptable for transmission (like TLS) because the password needs to reach the authentication system, but storage must use irreversible hashing.
Are there any situations where storing passwords in reversible encryption is acceptable?
Generally no - the control specifically requires cryptographically-protected passwords using one-way hashing for storage. However, some legacy systems or specific technical architectures may require reversible encryption as a temporary measure. If this is necessary, it must be documented with technical justification, implemented with strong encryption (AES-256), protected with strict access controls, and included in a POA&M with a plan to migrate to proper one-way hashing.
What hashing algorithms are acceptable for CMMC compliance?
Acceptable algorithms include bcrypt, PBKDF2 (with SHA-256 or SHA-512), scrypt, and Argon2. These are specifically designed for password hashing with built-in salting and configurable work factors. Weak or deprecated algorithms like MD5, SHA-1, or unsalted SHA-256 are not acceptable. The algorithm must use unique per-user salts and sufficient computational cost to resist brute-force attacks.
Does this control apply to service accounts and API keys?
Yes, this control applies to all passwords including service accounts, application passwords, and any credential used for authentication. API keys and tokens should also be cryptographically protected during storage and transmission. Service account passwords hardcoded in scripts or configuration files violate this control - they should be stored in secrets management systems or protected using equivalent cryptographic methods.
How do we handle password transmission during initial account setup or password resets?
Password transmission during setup or reset must occur only over encrypted channels (HTTPS/TLS). Best practice is to never transmit actual passwords - instead, send password reset links that allow users to set passwords securely. If temporary passwords must be provided, they should be transmitted over encrypted channels, expire quickly, and require immediate change upon first use. Sending passwords via unencrypted email violates this control.
What if a third-party SaaS application we use does not meet this requirement?
You must verify that all systems processing CUI meet CMMC requirements, including third-party applications. If a SaaS provider cannot demonstrate compliant password storage and transmission, you should request evidence of their security practices, consider alternative providers, or exclude that system from CUI processing. Document any third-party security limitations and include remediation plans in your POA&M if the system is necessary for operations.
How ConformatIQ Helps With CMMC Readiness
ConformatIQ is an AI-assisted CMMC readiness platform designed to help organizations prepare for assessments more efficiently. The platform supports document generation such as SSPs and POA&Ms, guided readiness workflows, centralized evidence tracking, and interview preparation for assessments.
Ready to Get Full Guidance?
Access complete implementation details, detailed assessment questions, evidence requirements, and expert guidance for this control.
Request Full GuidanceInformation sourced from NIST SP 800-171 Rev. 2. See full disclaimer.