CMMC Level 2 Practice 3.5.10: Store and transmit only cryptographically-protected passwords

CMMC Level 2 Practice 3.5.10 requires you to ensure passwords are never stored or sent in plaintext; they must be protected with approved cryptography at rest and in transit across your CUI environment. Operationalize it by enforcing strong password hashing in every system that stores credentials, prohibiting password transmission via insecure channels, and collecting recurring evidence that configurations and workflows comply. ¹

Key takeaways:

• Treat “passwords” broadly: app credentials, local accounts, service accounts, and embedded secrets must be cryptographically protected. ¹
• Most assessment failures come from hidden plaintext storage (configs, scripts, tickets, logs) and legacy protocols that can expose credentials in transit. ¹
• Your fastest path to assessment readiness is a scoped inventory, hard configuration standards, and repeatable evidence capture mapped directly to 3.5.10. ²

This requirement is small on paper and painful in practice. “Store and transmit only cryptographically-protected passwords” sounds like a checkbox until you look at how many places passwords and password-equivalents actually live: directory services, local OS accounts, application databases, network device configs, CI/CD variables, automation scripts, break-glass runbooks, helpdesk tickets, and log files. CMMC Level 2 assessors will not limit their view to your SSO provider. They will follow the credential lifecycle across the CUI boundary and ask one question: can an attacker or insider recover a usable password from storage or network transmission?

Practice 3.5.10 is mapped to NIST SP 800-171 Rev. 2 control 3.5.10 and sits inside the Identification and Authentication family. ¹ The operational goal is to prevent credential disclosure that enables lateral movement, privilege escalation, and unauthorized access to CUI. Your job as a CCO/GRC lead is to make the expectation unambiguous, assign technical ownership, and collect evidence that stands up in a CMMC Level 2 assessment. ²

Requirement: cmmc level 2 practice 3.5.10: store and transmit only cryptographically-protected passwords requirement

Plain-English interpretation

You must ensure passwords are:

1. Stored only in a cryptographically protected form (for most systems this means salted, one-way password hashing; for secrets vaults it can mean encryption with strong key management), and
2. Transmitted only over cryptographically protected channels (for example, TLS-protected web logins, SSH instead of Telnet, and disallowing credential sharing via email/chat).
   This is the practical meaning of CMMC Level 2 / NIST SP 800-171r2 3.5.10. ¹

Who it applies to

Entities: Defense contractors and other federal contractors that handle Controlled Unclassified Information (CUI) and must meet CMMC Level 2 requirements. ³

Operational scope: Any system, application, service, or workflow inside (or directly supporting) the environment where CUI is processed, stored, or transmitted, plus shared identity systems that authenticate users into that environment. Assessors will expect you to scope and defend boundaries under the CMMC program. ²

Credential types to include (operators miss these):

• User passwords (AD/Entra ID sync scenarios, local OS accounts, Linux shadow passwords)
• Application user tables (custom apps storing password hashes)
• Service accounts and “app passwords”
• Device/admin credentials on network gear and appliances
• Embedded secrets that behave like passwords (database connection strings, API keys, tokens) when they grant access into the CUI environment
  NIST 800-171 uses the term “passwords,” but assessors commonly probe for password-adjacent secrets because the risk is the same: recoverable credentials. ¹

Regulatory text

Excerpt (provided): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.5.10 (Store and transmit only cryptographically-protected passwords).” ¹

What the operator must do:

• Implement technical controls so passwords are not recoverable from storage in plaintext or reversible formats in systems within scope. ¹
• Ensure password handling during authentication and administrative workflows occurs only over encrypted/cryptographically protected transport. ¹
• Document the control, map it to system components, and retain evidence that the control operates consistently, because CMMC is assessed against implemented practices, not intent. ²

What you actually need to do (step-by-step)

Step 1: Define scope and ownership

1. List in-scope systems that authenticate users/admins into the CUI environment: directories, IdPs, VPNs, bastions, privileged access tooling, critical apps, and key infrastructure devices. ²
2. Assign control owners: identity/security engineering for standards, app owners for implementation, IT ops for endpoints/servers, network for devices.
3. Write a short control statement in your SSP/control catalog that maps directly to “3.5.10” and names the technical mechanisms (hashing algorithms, TLS requirements, prohibited protocols). ¹

Step 2: Build a credential storage standard (what “cryptographically protected” means in your environment)

Create a standard that covers three buckets:

A) Operating systems and directories

• Ensure OS and directory platforms store passwords using their native secure mechanisms (for example, Windows/AD and modern Linux distributions do not store plaintext passwords by default). Document versions and hardening baselines that support this expectation. ¹

B) Applications you build or configure

• Require salted, one-way hashing for password fields in app databases; prohibit reversible encryption for user passwords except where a specific system design demands it and you can justify it with compensating controls. Tie this to your secure SDLC and code review checklist for in-scope apps. ¹

C) “Secrets” that are really passwords

• For service account passwords and connection strings, require storage in an approved secrets manager or vault and prohibit storage in source code, spreadsheets, tickets, or wikis. Treat secrets vault encryption and access controls as part of satisfying “cryptographically protected.” ¹

Practical note: assessors usually want to see you understand the difference between hashing (for password verification) and encryption (for secrets you must retrieve). Your documentation should make that distinction explicit.

Step 3: Lock down password transmission paths

1. Set an approved transport list for authentication and admin access within scope (examples: HTTPS with TLS, SSH, RDP with Network Level Authentication, LDAPS where applicable). Document what is allowed and what is banned. ¹
2. Disable insecure protocols where feasible (common targets: Telnet, FTP, HTTP admin pages, LDAP without TLS, legacy SNMP community strings passed in plaintext, and “email me the password” workflows). ¹
3. Enforce MFA and SSO where appropriate, but keep the focus of this practice narrow: even with MFA, storing a recoverable password or transmitting it in cleartext can still fail 3.5.10. ¹

Step 4: Hunt for plaintext and reversible credential exposures

Run a targeted discovery effort across the in-scope environment:

• Configuration repositories: scripts, automation (PowerShell/Bash/Ansible), infra-as-code, router/switch backups
• Endpoint/server artifacts: saved RDP files, scheduled tasks, service configs, registry entries, environment variables
• Operational systems: ITSM tickets, knowledge base pages, “onboarding” emails, chat exports
• Logs: application logs accidentally printing credentials during auth errors

Document what you searched, where you searched, and what you remediated. That documentation becomes assessment evidence. ²

Step 5: Put recurring evidence capture on rails

CMMC assessments reward repeatability. Build a lightweight evidence routine:

• Quarterly (or at a defined cadence you can defend), export configurations or screenshots for: IdP settings, secrets vault policies, server baselines, and application password hashing settings.
• Capture a sample of network/security scans that demonstrate insecure services are not present on in-scope segments.
• Retain change tickets or pull requests that show remediation of plaintext credential findings. ²

Daydream fit (earned, not forced): teams use Daydream to map 3.5.10 to a documented control, assign owners, and schedule recurring evidence capture so assessment prep is not a spreadsheet scramble. ²

Required evidence and artifacts to retain

Keep evidence tightly tied to the two verbs in the requirement: store and transmit.

Policy/standard artifacts

• Password and credential handling standard defining approved hashing/encryption approaches and prohibited storage locations ¹
• Secure configuration baseline for in-scope OS, directories, and network devices ¹

Technical evidence (examples assessors accept)

• Screenshots/exports showing TLS enforced for admin consoles and authentication endpoints ¹
• App design/code review evidence showing password hashing implementation for in-scope apps ¹
• Secrets manager configuration: encryption enabled, access policies, audit logging enabled ¹
• Scan results or configuration reports showing insecure protocols disabled within scope ¹

Operational evidence

• Tickets/PRs documenting removal of plaintext credentials from scripts/configs
• A repeatable evidence log that ties artifacts to the practice identifier “3.5.10” for assessment readiness ²

Common exam/audit questions and hangups

Assessors tend to press on these points:

1. “Show me where passwords are stored for System X.” Be ready with architecture diagrams and a direct explanation: hashed in app DB, secrets in vault, no plaintext anywhere. ¹
2. “Can an admin recover a user’s password?” If yes, you may be using reversible encryption where hashing should be used. Have a clear justification if an exception exists. ¹
3. “How do you know credentials aren’t being emailed or chatted?” Point to procedures, DLP controls if you have them, and training plus ticket templates that prohibit it. ¹
4. “What about service accounts and scripts?” This is a frequent gap. Expect deep sampling of automation repos and server configs. ²

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails 3.5.10	How to avoid it
Storing passwords with reversible encryption in an app DB	Stored passwords are recoverable if keys are compromised	Use salted one-way hashing for user passwords; reserve encryption for retrievable secrets 1
Allowing helpdesk or onboarding workflows to share passwords	Transmission is not cryptographically protected and creates uncontrolled copies	Use reset links, temporary access methods, or managed password delivery in a secure tool 1
Assuming “we have TLS” without proof	Assessors need evidence; some endpoints still allow plaintext	Capture configs, scans, and test results; block plaintext listeners at the network layer 2
Ignoring device and appliance admin credentials	Network gear often retains legacy services and weak handling	Standardize management plane access (SSH/HTTPS), disable insecure protocols, rotate and vault secrets 1
No recurring evidence	You cannot prove ongoing compliance	Schedule periodic checks and store artifacts mapped to 3.5.10 2

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific practice, so you should treat risk as assessment and contractual exposure under the CMMC program rather than tying it to a named case. ³ Operationally, plaintext or recoverable passwords increase breach impact and can directly undermine access controls expected across NIST SP 800-171 implementations. ¹

Practical 30/60/90-day execution plan

First 30 days: Contain the obvious failure modes

• Publish a short credential storage/transmission standard for in-scope systems, including banned channels for password sharing. ¹
• Inventory where passwords and secrets live across your CUI boundary: directories, apps, devices, automation, ITSM. ²
• Disable or restrict the highest-risk plaintext protocols on in-scope networks where feasible and document exceptions. ¹

Days 31–60: Remediate and prove it

• Fix application password storage patterns (hashing) and migrate service account secrets into a managed vault. ¹
• Implement admin access standards for infrastructure (SSH/HTTPS management, TLS enforced) and validate with configuration exports or scans. ¹
• Start an evidence register for 3.5.10 with named owners and artifact locations. ²

Days 61–90: Make it repeatable

• Add controls into CI/CD and change management: block secrets in repos, require approved libraries for hashing, and require TLS-only endpoints for auth. ¹
• Run a second plaintext credential hunt to confirm remediation holds, then record results as evidence. ²
• Operationalize ongoing evidence capture in your GRC workflow (Daydream or your existing system) so the control stays “always ready.” ²

Frequently Asked Questions

Does 3.5.10 require a specific hashing algorithm like bcrypt?

The requirement states passwords must be cryptographically protected, but it does not name a specific algorithm in the provided text. Document your approved approach and show it is implemented consistently in scope. ¹

Do encrypted passwords count as “cryptographically protected” for storage?

Encryption is cryptography, but for user passwords you generally want one-way hashing so passwords are not recoverable. If you encrypt passwords, be ready to explain why the system needs reversibility and what compensating controls apply. ¹

Are API keys and tokens in scope, or only human passwords?

Assessors often evaluate password-equivalent secrets because they grant access into the CUI environment. Treat them with the same discipline: store in a vault and transmit only over encrypted channels. ¹

What evidence is “enough” for a CMMC Level 2 assessment?

You need proof of configuration and operation: standards, system settings showing secure storage/transport, and records of recurring checks or scans. Map each artifact directly to 3.5.10 so it is easy to review. ²

We use SSO everywhere. Are we automatically compliant?

SSO reduces password handling, but it does not eliminate passwords in local admin accounts, service accounts, devices, and edge cases. You still need to prove passwords are not stored or sent in plaintext anywhere in scope. ¹

How do we handle third parties that administer in-scope systems?

Require third parties to use your approved secure remote access methods and prohibit sending passwords over email/chat. Contractually require secure credential handling and collect evidence from their access method and your logging. ²

Footnotes

1. NIST SP 800-171 Rev. 2

2. DoD CMMC Program Guidance

3. 32 CFR Part 170