AC.L2-3.5.9[a]

AC.L2-3.5.9[a] — Identification & Authentication (Temporary Passwords)

Domain: Identification & Authentication (IA) | Practice: IA.L2-3.5.9 | Objective ID: 3.5.9[a] | Source: NIST SP 800-171 Rev. 2 / CMMC 2.0 Level 2

Assessment Objective:

Temporary passwords are required to be changed at the next system access.

Executive Summary (For Leadership and the Board)

CMMC objective AC.L2-3.5.9[a] sits inside the Identification & Authentication domain (IA.L2-3.5.9 — Temporary Passwords) and reads: Temporary passwords are required to be changed at the next system access.. Issue temporary/initial passwords that the system forces the user to change upon first login. Temporary passwords that persist become shared knowledge and a vulnerability. For organizations that handle Controlled Unclassified Information (CUI), this objective is part of the foundation that every downstream control depends on.

Under DFARS 252.204-7012, AC.L2-3.5.9[a] will be evaluated during a full third-party CMMC Level 2 assessment, Joint Surveillance Voluntary Assessment, or formal certification gating DoD CUI contract awards. Leadership and the board should be asking: Who owns this objective? When was it last reviewed? Where is the evidence stored? And what is our remediation plan if a C3PAO flags a gap? Failing this objective in isolation may be POA&M-able under CMMC 2.0; failing it in conjunction with related objectives in the same practice is typically not.

Business Question	What Leadership Must Confirm
Do we have a documented, owned, and current implementation for the requirement that temporary passwords are required to be changed at the next system access?	A named control owner exists, the implementation is documented in the SSP, and a defined review cadence is in force.
Can we produce evidence that this objective is operating effectively across every CUI-bearing system in scope?	Artifacts (logs, tickets, config exports, attestations) are collected on a defined cadence and tied back to AC.L2-3.5.9[a].
What happens if this control fails or drifts out of compliance?	A documented detection, escalation, and remediation path exists, with the vCSO as the executive backstop.
Can we prove this objective to a C3PAO?	The evidence package — policy, configuration, monitoring output, and recertification records — is pre-built and mapped directly to AC.L2-3.5.9[a].

Executive Risk Lens: Failures against this objective routinely surface in Verizon DBIR and Mandiant M-Trends data as contributors to CUI exfiltration, ITAR-relevant data exposure, and engineering CUI loss to nation-state adversaries. A single weak point in Temporary Passwords can undermine every other access-control and integrity control in the CUI boundary.

How Authorization Should Flow

AC.L2-3.5.9[a] — Temporary Passwords Lifecycle (Request → Authorize → Provision → Recertify → Deprovision)

Technical Deep Dive (For Engineers, IAM Admins, and ISSOs)

What the Objective Requires

NIST SP 800-171 derives IA.L2-3.5.9 from controls in the NIST SP 800-53 IA family. CMMC 2.0 splits the parent practice into discrete assessment objectives; AC.L2-3.5.9[a] is the specific objective requiring that Temporary passwords are required to be changed at the next system access. To pass — with artifacts — the implementation must demonstrate:

A documented control implementation specifically addressing the requirement that temporary passwords are required to be changed at the next system access, recorded in the System Security Plan (SSP) section for IA.L2-3.5.9.
A named control owner accountable for AC.L2-3.5.9[a], identified in the SSP and the RACI for Identification & Authentication.
Configuration of the supporting technology (where applicable) such that the control is enforced by default and cannot be silently bypassed by a user with normal privileges.
A monitoring and detection mechanism (log, alert, ticket, or recertification campaign) that produces evidence the objective is operating across all CUI-bearing systems in scope.
A documented review cadence — at minimum annual, ideally quarterly for high-risk objectives — with signed evidence of each review.
A defined remediation path (ticket, POA&M entry, or change request) when drift, failure, or exception is detected.
Mapping of AC.L2-3.5.9[a] to the corresponding NIST SP 800-53 Rev. 5 control(s) in the IA family, including any control enhancements adopted by the organization.
Cross-references to related Identification & Authentication objectives in the same practice so the C3PAO sees a coherent story rather than 14 disconnected artifacts.

Evidence Package the Assessor Will Request

Artifact	Where It Typically Lives	Common Gotchas
Identification & Authentication Policy section covering IA.L2-3.5.9	GRC platform / policy library	Policy is generic and does not name AC.L2-3.5.9[a]; no review date in the last 12 months.
SSP narrative for IA.L2-3.5.9 — implementation paragraph for objective [a]	SSP master document (controlled copy)	Narrative says 'will be implemented' instead of describing the current implementation.
Operational evidence (logs, configs, tickets, reports) for AC.L2-3.5.9[a]	Log aggregator / SIEM / ITSM / configuration management tool	Evidence covers a single point in time instead of a time-series; reviewer cannot show continuous operation.
Most-recent review or recertification record for AC.L2-3.5.9[a]	GRC platform or signed manager attestation	Review was rubber-stamped (100% approve, no changes) or older than the policy review cadence.
Remediation / POA&M entries tied to AC.L2-3.5.9[a] (if any)	POA&M tracker (Compliance-as-a-Service or spreadsheet)	Open POA&M items past their target date with no executive sponsor — first thing a C3PAO will dig into.

Reference Architecture

Authoritative Authorization Architecture for CMMC Level 2 (Users, Processes, Devices)
HRIS / Asset Mgmt / Vault / Contractor → Identity & Asset Authorization Plane (Entra ID / Okta / CyberSecureID, CMDB, ITSM) → CUI File Shares / GCC High / Engineering / VPN-ZTNA.
Every CUI-bearing system MUST consume identity, asset, and authorization data from the authorization plane. No local accounts. No shadow IT. No exceptions.

Real-World Examples — What Goes Wrong

Example 1 — The Drift That Was Never Caught

During a Cyberwatch engagement, a mid-tier defense supplier discovered that the authentication control supporting IA.L2-3.5.9 had quietly drifted out of compliance over six months. The team assumed the control still operated as documented in the SSP, but spot-checks showed MFA gaps across three production systems handling CUI. The C3PAO was scheduled in 90 days; remediation became an all-hands fire drill.

Lesson: The SSP is not the implementation — the implementation is the implementation. AC.L2-3.5.9[a] requires evidence of the control as it operates today, not as it was designed two SSP revisions ago.

Example 2 — The Evidence That Did Not Match the Policy

a defense prime contractor produced its policy binder for IA.L2-3.5.9 during a Joint Surveillance Voluntary Assessment. The policy said the control was reviewed quarterly. Operational evidence showed the most recent identifier-management review was 14 months old. The assessor flagged it immediately because the discrepancy is a hallmark sign of paper-only compliance.

Lesson: If the policy says quarterly, the evidence binder must show four reviews per year. This is the simplest, fastest test an assessor performs against AC.L2-3.5.9[a].

Example 3 — The Acquisition That Inherited the Gap

After a Tier 2 aerospace subcontractor acquired a small competitor, leadership assumed the new entity inherited the parent's compliance program. In reality, the acquired environment had its own authentication stack, no documented control owner for AC.L2-3.5.9[a], and no evidence trail. When the CUI boundary was redrawn to include the acquired environment, the entire IA.L2-3.5.9 package failed to map cleanly.

Lesson: Mergers, acquisitions, and even significant infrastructure changes reset the clock. Compliance with AC.L2-3.5.9[a] must be re-established for any new system or environment that touches CUI.

How Northern Data Solutions Helps You Pass AC.L2-3.5.9[a]

Service Offering	What It Does for AC.L2-3.5.9[a]
Cyberwatch — Risk Identification	Independent third-party penetration testing, validation, and vulnerability identification surfaces temporary passwords weaknesses tied to AC.L2-3.5.9[a] before a C3PAO does. Cyberwatch produces an external attestation that the control as deployed actually meets the assessment objective.
Cyberwatch Advanced	Operationalizes the control: Identity & Access Management with adaptive MFA (CyberSecureID), Principle of Least Privilege enforcement, Zero Trust Architecture, attack-surface visibility, password management & rotation, and the cybersecurity training platform with employee attestation. Together these produce the continuous evidence stream AC.L2-3.5.9[a] requires.
Compliance-as-a-Service	Manages your SSP, POA&Ms, control evidence, and recertification campaigns inside a single platform. Maps every artifact directly to AC.L2-3.5.9[a] and the surrounding Identification & Authentication objectives so you walk into your CMMC Level 2 assessment with the binder pre-built and the gap report already burned down.
vCSO (Virtual CSO)	Executive-level guidance for boards and leadership on scope decisions (CUI boundary), C3PAO selection, control-design trade-offs across CMMC, FTC Safeguards, and PCI, and remediation prioritization aligned with contract-award timelines.

Engagement model: Most clients begin with a Cyberwatch baseline assessment (1–2 weeks), then move into Cyberwatch Advanced and Compliance-as-a-Service to remediate and harvest evidence ahead of their CMMC Joint Surveillance or full L2 assessment.

External References & Authoritative Sources

Are You Ready for the C3PAO? — 10-Point Readiness Check

We can produce, on demand, the documented implementation of AC.L2-3.5.9[a] from the SSP.
A named owner is accountable for AC.L2-3.5.9[a] and is reachable by the C3PAO during the assessment.
The control supporting AC.L2-3.5.9[a] is in fact configured and operating today (not just documented).
Operational evidence covers at minimum the last 12 months and shows the control operating continuously, not as a point-in-time snapshot.
The most recent review or recertification of AC.L2-3.5.9[a] is within the cadence stated in policy.
All open POA&M items related to AC.L2-3.5.9[a] have an executive sponsor and a credible target date.
Cross-references to sibling Identification & Authentication objectives are present in the SSP and consistent.
For every CUI-bearing system in scope, the implementation of AC.L2-3.5.9[a] is the same — no special-cases hiding non-compliance.
The Cyberwatch baseline assessment for Identification & Authentication has been run within the last 12 months and any findings are remediated or POA&M'd.
A vCSO has reviewed the package against the CMMC Assessment Guide Level 2 v2.13 for AC.L2-3.5.9[a].

Next Step: If you cannot confidently check all 10 boxes above, contact your Northern Data Solutions vCSO to schedule a Cyberwatch assessment. We will deliver a gap report mapped directly to AC.L2-3.5.9[a] and the surrounding Identification & Authentication objectives.

Tags: AC.L2-3.5.9[a], cmmc, level-2, domain-ia

Documentation Index