Skip to content
ControlVerdict
Sign in
IA.L2-3.5.10CMMC Level 2Level 2

Cryptographically-protected Passwords

Submit your own example

Practice statement

Store and transmit only cryptographically-protected passwords.

Quoted verbatim from NIST SP 800-171 Rev. 2 §3.5.10.Source

The source document’s non-normative “Discussion” section is not reproduced here. ControlVerdict quotes normative text verbatim or omits it — it never paraphrases a standard. Follow the source link above for the full context.

Assessment Objectives(2)

An assessor determines each objective separately. “Mostly implemented” is not a result — every objective below has to stand on its own.

  1. [a]

    passwords are cryptographically protected in storage; and

    1 example covers this

  2. [b]

    passwords are cryptographically protected in transit.

    1 example covers this

Objective text quoted verbatim from NIST SP 800-171A via the CMMC Level 2 assessment guide.

Implementation examples(1)

Submit your own example
  • addresses
    IA.L2-3.5.10Cryptographically-protected Passwords
    Store and transmit only cryptographically-protected passwords.

    • [a]

      passwords are cryptographically protected in storage; and

    • [b]

      passwords are cryptographically protected in transit.

    Salted hashes at rest, no cleartext protocols on the wire, and a CI check against logging secrets

    ControlVerdict Corpus@cv-corpusOSCJul 31, 2026
    Community is just starting — add yours. No verdicts yet.

    Implementation

    AO coverage. Addresses both Cryptographically-protected Passwords objectives — storage and transit — for the directories, applications, and network devices in scope.

    Storage. The directory stores salted hashes with reversible encryption disabled. In-house applications hash with Argon2id, and the cost parameters are recorded in the application baseline so a reviewer can see they were chosen rather than defaulted. No table, report, or export contains a password column. Automation secrets live in the vault, not in application configuration files or pipeline variables.

    Transit. Every authentication endpoint requires TLS 1.2 or higher; internal apps redirect to HTTPS and send HSTS. LDAP simple binds are disabled in favor of LDAPS/StartTLS with channel binding required. LM and NTLMv1 are disabled by policy, and the remaining NTLMv2 usage is scoped to one file service and monitored. SNMPv2 community strings on enclave gear were replaced with SNMPv3 authPriv.

    Development standard. Credentials must never be written to logs. A CI check fails the build on the known bad patterns (logging a request body on the auth route, printing a bind DN password, echoing environment secrets), which caught two real regressions before release.

    Maintenance. Quarterly scan of enclave VLANs for cleartext authentication protocols (telnet, FTP, HTTP logon forms, unencrypted LDAP binds), with findings ticketed. Annual review of hashing parameters against current guidance and current hardware.

    Accepted gap. One MES module posts credentials to a servlet that only supports basic authentication. It is reachable only inside the enclave VLAN and only through a TLS-terminating reverse proxy, so nothing crosses the wire in the clear; the vendor's native fix has a tracked review date.

    What the evidence looks like

    • Directory settings showing reversible encryption disabled and simple binds refused
    • Application baseline documenting the Argon2id parameters
    • NTLM restriction and SNMPv3 configuration exports
    • CI check definition plus the two blocked-build records
    • Quarterly cleartext-protocol scan output and the reverse-proxy configuration for the MES module

    Environment

    In-house line-of-business web apps plus a vendor MES. One internal tool historically used HTTP basic authentication on the shop LAN.

    Tools

Discussion(0)

No discussion on this control yet

Edge cases, scoping questions, and “would this pass?” scenarios belong here.

Sign in to start a thread.