Store and transmit only cryptographically-protected passwords
π What This Means
This control requires that all passwords stored in your systems or transmitted across networks are protected using strong cryptographic methods. In plain terms, it means passwords should never be saved or sent as plain textβthey must always be scrambled (hashed or encrypted) using approved algorithms. For example, when a user creates a password, your system should immediately hash it using a method like SHA-256 before storing it. Similarly, when a user logs in, their password should be transmitted over an encrypted connection (like HTTPS). A real-world example: If your company uses Active Directory, it should be configured to store passwords as NTLM hashes (not plain text). Another example: Your web application login page must use TLS encryption to protect passwords during transmission.
π― Why It Matters
Unprotected passwords are a top target for attackers. If passwords are stored or transmitted without encryption, a single breach can expose all user credentials, leading to account takeovers, data theft, and system compromises. In 2021, a major defense contractor was fined $9.6M after plaintext passwords were found in log files, exposing sensitive DoD systems. The DoD specifically requires cryptographic protection to prevent credential theft and meet CMMC Level 2 requirements. Without this control, your organization risks failing compliance audits, losing contracts, and becoming an easy target for credential-stuffing attacks (which account for 34% of all breaches, per Verizon DBIR).
β How to Implement
- 1. In AWS: Enable password hashing in Cognito or IAM using AWS KMS (Key Management Service) with AES-256 encryption.
- 2. In Azure: Configure Azure AD to store passwords using PBKDF2 hashing (Settings > Authentication Methods > Password Protection).
- 3. For cloud apps: Enforce HTTPS/TLS 1.2+ for all authentication traffic (e.g., configure ALB/ELB in AWS or Azure Front Door).
- 4. Use AWS Secrets Manager or Azure Key Vault to store service account passwords (never in plaintext config files).
- 5. Enable logging for password-related events (e.g., AWS CloudTrail for IAM or Azure AD audit logs).
π Evidence Examples
Password Policy Document
Active Directory Password Settings Screenshot
TLS Configuration Test Report
Code Review for Password Handling
Incident Response Log
π SSP Guidance
Use this guidance when writing the System Security Plan (SSP) narrative for this control.
How to Write the SSP Narrative
For IA.L2-3.5.10 ("Store and transmit only cryptographically-protected passwords"), your SSP narrative should specifically describe: (1) the tools and technologies you use to implement this control, (2) the configuration or process that enforces it, (3) who is responsible for maintaining it, and (4) what evidence proves it's working. Describe how users, devices, and processes are identified and authenticated, including your IAM platform, password policies, MFA implementation, certificate management, and service account controls. Be specific -- name your actual products, settings, and responsible personnel.
Example SSP Narratives
"IA.L2-3.5.10 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to store and transmit only cryptographically-protected passwords. The configuration is managed through [Azure Policy/AWS Config/Terraform] and monitored via [SIEM tool]. Responsible party: [IT Security Manager]. Evidence: [specific artifact, e.g., 'Azure AD Conditional Access policy screenshot, CloudTrail logs']."
"IA.L2-3.5.10 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to store and transmit only cryptographically-protected passwords. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."
"IA.L2-3.5.10 is implemented across both cloud and on-premise environments. [Organization] uses [Azure AD Connect/hybrid tool] to ensure consistent enforcement. Cloud resources are managed via [cloud tool] and on-premise systems via [on-prem tool]. Both environments report to [centralized SIEM]. Responsible party: [IT Director]. Evidence: [artifacts from both environments]."
System Boundary Considerations
- β’ Identify all authentication entry points (local login, VPN, cloud, API)
- β’ Document the identity provider(s) and authentication flow
- β’ Specify MFA methods and coverage
- β’ Ensure this control covers all systems within your defined CUI boundary where store and transmit only cryptographically-protected passwords applies
- β’ Document any systems where this control is not applicable and explain why
Key Documentation to Reference in SSP
- π Identification and Authentication Policy
- π Password policy configuration
- π MFA enrollment records
- π Service account registry
- π Evidence artifacts specific to IA.L2-3.5.10
- π POA&M entry if control is not fully implemented
What the Assessor Looks For
The assessor will test authentication mechanisms, verify MFA is enforced for required access paths, check password policy configuration, and review service account documentation.
π¬ Self-Assessment Questions
Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.
Question 1: Are all passwords stored using FIPS 140-2 validated cryptographic hashes (e.g., PBKDF2, bcrypt)?
Question 2: Is TLS 1.2 or higher enforced for all password transmissions?
Question 3: Have you verified no systems store passwords in plaintext (including logs, configs, backups)?
Question 4: Is there documented evidence of cryptographic controls for passwords?
Question 5: Have all IT staff received training on proper password handling?
β οΈ Common Mistakes (What Auditors Flag)
1. Plaintext passwords in application logs.
2. Using deprecated hashing (MD5, SHA-1).
3. Missing TLS on internal password transmissions.
4. No evidence of cryptographic validation.
5. Service accounts with plaintext passwords in scripts.
π Parent Policy
This practice is governed by the Identification and Authentication Policy