Passwords must be protected at rest and in transit. At rest, they should be hashed using approved algorithms. In transit, they should be encrypted using TLS or similar. This is mostly handled automatically by modern systems. Windows hashes passwords. Cloud providers use approved methods. The failure usually comes from legacy applications or manual password storage (spreadsheets, documents).
The assessor wants to hear that you’re not storing passwords in plain text and that you’re using TLS or HTTPS for authentication traffic. For most contractors, this is straightforward. This practice works with IA.L2-3.5.7 (complexity) and IA.L2-3.5.8 (reuse restrictions) to provide defense in depth for password security.
What the assessor is actually evaluating
The assessor is checking two things. One: how do you store passwords? Are they hashed? Are they in a secure vault? Are they ever stored in plain text? Two: how are passwords transmitted when users authenticate? Are connections encrypted?
For passwords stored in systems like Active Directory or Azure AD, the assessor knows these use approved hashing. They won’t push on this. For passwords stored in credential vaults, they want to know the vault uses encryption. For passwords in custom applications, they want to see that hashing is used.
For transmission, they want to see HTTPS or TLS for all authentication. No HTTP, no unencrypted protocols.
What a realistic SSP definition looks like
Practice IA.L2-3.5.10: Cryptographically-Protected Passwords
Passwords are protected using approved cryptographic methods both when stored and when transmitted.
Password Storage at Rest:
User passwords in Active Directory are stored using NTLM and Kerberos hashing. These are built-in Windows security methods that hash passwords rather than storing them in plain text. No user passwords are stored in plain text anywhere in our systems.
Cloud-based passwords in Azure AD are hashed using Azure AD’s built-in password hashing mechanisms, which use industry-standard algorithms.
Service account credentials are stored in [credential vault solution] which encrypts all stored credentials at rest using [encryption method / built-in encryption]. Credentials are never stored in plain text files, spreadsheets, or documents.
Legacy application passwords (if any) are stored in the [credential vault] and are protected with encryption. Applications authenticate to the vault using separate service account credentials that are also encrypted.
Password Transmission in Transit:
All authentication traffic to systems containing CUI is encrypted using TLS or HTTPS. This includes:
- Network logons use Kerberos over encrypted domain connections
- Remote access via VPN uses TLS encryption
- Cloud access via web uses HTTPS with TLS
- Email and web applications use HTTPS
- API access uses HTTPS with TLS
All authentication endpoints are configured to require HTTPS or TLS. HTTP without encryption is not permitted for any authentication functionality.
Insecure Transmission Prevention:
We do not:
- Transmit passwords via email
- Use unencrypted protocols (HTTP, telnet, etc.) for authentication
- Send passwords through chat or messaging applications
- Store passwords in shared documents or spreadsheets
Credential Vault Administration:
Our credential vault is administered by [IT manager / MSSP]. Access to the vault is restricted to authorized personnel only. Vault contents are audited quarterly to ensure only needed credentials are stored.
This is thorough and specific. The assessor reads this and knows you’re using approved methods for storage and transmission.
How to present your evidence
- System documentation stating password hashing methods (NTLM/Kerberos, Azure hashing, etc.)
- Network configuration showing TLS/HTTPS is enforced for authentication
- Credential vault documentation and encryption method
- Policy statement documenting no plain-text password storage or transmission
Your evidence includes:
System documentation stating password hashing methods. For Active Directory, document that Windows uses NTLM/Kerberos hashing. For cloud, Azure AD documentation. For custom applications, documentation showing the hashing algorithm used.
Network configuration showing TLS/HTTPS is enforced. Screenshots of your VPN requiring TLS. Web application configuration showing HTTPS is required. Domain controller configuration showing Kerberos is used.
Credential vault documentation. If you store service account credentials in a vault, show the vault is encrypted and document the encryption method.
Policy statement. Your SSP statement (above) is evidence by itself.
Configuration audit. Show that HTTP redirects to HTTPS, unencrypted protocols are disabled, etc.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Common failures
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
If you use an MSP or MSSP
Your MSSP should be handling credential storage and transmission security. They configure your systems to use TLS, set up credential vaults, and ensure service accounts are managed securely.
Ask your MSSP: “How are service account passwords stored and transmitted securely in our environment?” They should describe their credential vault or secure management method. If they don’t have one, ask why.
In the assessment, the MSSP can explain their credential management approach and show the vault if needed. The contractor can speak to the policy.
This guidance is based on assessment room experience and reflects one practitioner’s interpretation of CMMC Level 2 requirements. It is not legal or compliance advice. Always consult your compliance team and official CMMC documentation for final guidance.