Skip to content
ControlVerdict
IA.L2-3.5.9CMMC Level 2Level 2

Temporary Passwords

Practice statement

Allow temporary password use for system logons with an immediate change to a permanent password.

Quoted verbatim from NIST SP 800-171 Rev. 2 §3.5.9.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(1)

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

  1. [a]

    an immediate change to a permanent password is required when a temporary password is used for system logon.

    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.9Temporary Passwords
    Allow temporary password use for system logons with an immediate change to a permanent password.
    • [a]

      an immediate change to a permanent password is required when a temporary password is used for system logon.

    Single-use 60-minute reset credential; the session cannot continue without a permanent one

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

    Implementation

    AO coverage. Addresses the single Temporary Passwords objective: an immediate change to a permanent credential is required when a temporary one is used to log on.

    Reset path. The help desk issues a one-time-use credential valid for 60 minutes. The account is simultaneously flagged for credential change at next sign-in, so the session stops at the change prompt and cannot reach enclave applications until a permanent credential exists. Where the user still has a working security key, the preferred path is re-registration of that key rather than issuing a password at all.

    Identity proofing before issuance. A scripted challenge covers items not visible in a phishing pretext; for anyone on the privileged inventory the technician additionally calls the manager on a number from the directory. The requester can never approve their own reset, and the proofing method used is recorded in the ticket.

    Onboarding. Day-one access uses the same one-time credential, consumed in person or on a video call during the security-key registration ceremony, so a new hire never holds a reusable temporary password.

    Maintenance. Monthly reconciliation of credentials issued versus consumed versus expired; anything unconsumed is invalidated automatically and the mismatch is reviewed. Quarterly review of the proofing script against current social-engineering patterns.

    Accepted gap. One legacy on-prem application cannot set a change-at-next-logon flag. There, the administrator sets the temporary value and watches the user change it within the same session, recording completion in the ticket. The application is scheduled for SSO integration.

    What the evidence looks like

    • IdP configuration showing one-time use and the 60-minute lifetime
    • Change-at-next-sign-in flag applied on a sample reset
    • Help-desk proofing script and a completed ticket recording the method used
    • Monthly issued/consumed/expired reconciliation report
    • Legacy application procedure and a completed witnessed-change ticket

    Environment

    Three-technician help desk supporting ~300 users, with a reset spike every Monday after weekend leave. Onboarding also runs through the same path.

    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.