CMMC Level 2 Practice 3.5.6: Disable identifiers after a defined period of inactivity

CMMC Level 2 Practice 3.5.6 is a straightforward requirement that often fails in execution because “accounts” exist in more places than the identity team expects. You may have Active Directory accounts, cloud identities, local machine accounts, application-native users, privileged admin IDs, break-glass accounts, and non-human service accounts. Assessors will test whether your defined inactivity rule is real, consistently implemented, and verifiable in evidence.

This requirement sits in the Identification and Authentication family and maps directly to NIST SP 800-171 Rev. 2. The security objective is practical: reduce the attack surface created by stale accounts that can be guessed, reused, or abused without attracting attention. Your job as the Compliance Officer, CCO, or GRC lead is to translate the practice into (1) a clear standard the business can follow, (2) technical enforcement that covers all identity stores in scope, and (3) routine evidence capture so you are not scrambling at assessment time.

If you run a mixed environment, treat 3.5.6 as an identity coverage problem, not a single directory setting. The fastest path is to map every account type to an owner and an automated disabling mechanism, then prove it with repeatable reporting.

Regulatory text

Excerpt (as provided): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.5.6 (Disable identifiers after a defined period of inactivity).” (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170)

What the operator must do:

1. Define what “period of inactivity” means for your environment (for example, no interactive logon, no IdP authentication events, no VPN login).
2. Set a rule that user identifiers are disabled after that defined period.
3. Implement the rule across the environment in scope for CMMC Level 2 (systems that store, process, or transmit CUI).
4. Retain evidence that shows the rule is configured and operating consistently over time. (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance)

Plain-English interpretation

Disable accounts that have not been used for a defined amount of time, so old or orphaned accounts cannot be abused. “Disable identifiers” means the account should no longer permit authentication, even if the password remains unchanged or the account still exists for recordkeeping.

This is not the same as session lock or automatic logoff. Session controls handle an active session on a workstation. Practice 3.5.6 targets the identity itself after prolonged non-use.

Who it applies to

Entities

• Defense contractors and subcontractors that must achieve CMMC Level 2 for contracts involving CUI. (32 CFR Part 170; DoD CMMC Program Guidance)

Operational context (what’s in scope)

• Identity sources: Active Directory, Entra ID/Azure AD, Okta/other IdPs, LDAP directories.
• Systems with local identities: standalone servers, network devices, appliances, endpoints where local accounts exist.
• Applications with native users: ticketing tools, engineering tools, ERP, CM tools, file transfer portals.
• Privileged identities: admin accounts, domain admins, device enable accounts.
• Non-human accounts: service accounts, API accounts, robotic process accounts (these require special handling but still need an inactivity decision).

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

Step 1: Define the inactivity standard (policy + technical definition)

Create a written standard that answers:

• Which identifiers are covered: interactive users, privileged users, local accounts, application accounts, service accounts.
• What counts as activity: successful authentication to the domain/IdP, VPN login, cloud SSO event, PAM check-out event, etc.
• The disabling action: disable account, remove group memberships, block sign-in at IdP, or equivalent “cannot authenticate” state.
• Exceptions: break-glass accounts, emergency vendor accounts, shared device accounts (exceptions must still have compensating controls and periodic validation). Record the standard in your access control / identity management policy set and map it explicitly to 3.5.6. (NIST SP 800-171 Rev. 2)

Step 2: Build the inventory of identity stores and account populations

You cannot enforce what you cannot enumerate. Build a simple matrix:

Account population	System of record	Disable method	Owner	Evidence source
Workforce users	AD / IdP	Automated disable based on last sign-in	IAM	AD/IdP report + change log
Privileged admins	AD + PAM	Disable in AD and revoke PAM access	Security	PAM logs + AD status
Local server accounts	Windows/Linux	Scripted checks + disable	IT Ops	Script output + config
App-native users	App admin console	Scheduled job / admin review workflow	App owner	App export + ticket
Service accounts	AD / vault	“No interactive logon,” owner attestation, monitored usage	App owner	Vault record + usage logs

This matrix becomes your scope control and your audit script.

Step 3: Implement automated disabling in your primary identity platform

Most environments should make the directory/IdP the enforcement point for workforce identities:

• Configure directory rules or identity governance workflows that disable accounts based on last authentication.
• Ensure the rule applies to all OUs/groups that represent in-scope users and privileged accounts.
• Where contractors/third parties get accounts, ensure the same inactivity rule applies unless you have a documented exception. “Third party” accounts are frequently the oldest and least maintained.

Step 4: Close the gaps: local accounts, application-native users, and edge systems

Assessors often find gaps here:

• Local accounts on endpoints/servers: enforce via configuration management and periodic scans that flag inactive local users and disable them.
• Network devices/appliances: ensure named admin accounts are disabled after inactivity using device AAA integrations where possible; otherwise, create a device account review-and-disable procedure with evidence.
• Application-native users: if the app cannot automatically disable on inactivity, implement a compensating process: periodic user export, match against HR/IdP activity, disable stale accounts, retain tickets and exports.

Step 5: Handle service accounts explicitly (don’t pretend they are “users”)

Service accounts may not log in interactively, so “inactivity” must be defined differently:

• Decide whether “inactivity” is no service authentication events or no observed application use.
• If the account must persist, restrict it: no interactive login, strong secret management, ownership, and monitoring. Document why disabling after inactivity is not feasible and how you control the risk.

Step 6: Operationalize: ownership, cadence, and recurring evidence capture

Make the control run without heroics:

• Assign an IAM control owner responsible for the standard and enterprise enforcement.
• Assign system owners for apps and platforms not governed by the directory.
• Set recurring evidence capture in a GRC workflow so every assessment cycle you can show continuous operation.

Daydream can help here by converting 3.5.6 into a repeatable evidence request schedule (directory configuration snapshots, monthly inactive-account reports, exception register updates) and tying each artifact back to the practice for assessor-ready packaging. (DoD CMMC Program Guidance)

Required evidence and artifacts to retain

Keep evidence that proves design and operation:

Design evidence (what you intended)

• Access control / IAM standard that defines inactivity and disablement for identifiers, mapped to 3.5.6. (NIST SP 800-171 Rev. 2)
• System scope list for CUI environments and the identity stores used by those systems. (DoD CMMC Program Guidance)

Operating evidence (what actually happened)

• Directory/IdP configuration screenshots or exports showing the inactivity-disable rule.
• Periodic “inactive accounts” reports with disable actions recorded (account status before/after).
• Change tickets or audit logs that show accounts were disabled due to inactivity (not just during offboarding).
• Exception register for accounts exempted from automated disablement, with owner, justification, and compensating controls.

Common exam/audit questions and hangups

Expect these lines of inquiry:

• “What is your defined inactivity period, and where is it documented?” (NIST SP 800-171 Rev. 2)
• “Show me accounts disabled due to inactivity, and the logs that prove the disablement.”
• “Which systems are in scope for CUI, and do they all rely on the same identity store?”
• “How do you treat service accounts and shared accounts under 3.5.6?”
• “How do you ensure contractors/third parties follow the same rule?”

Hangup to avoid: answering with HR offboarding. Offboarding is necessary, but 3.5.6 is specifically about inactivity, not termination.

Frequent implementation mistakes (and how to avoid them)

1. Only covering AD users. Fix: build the identity-store matrix and assign owners for app-native and local accounts.
2. No written definition of inactivity. Fix: define the activity signal (IdP auth, VPN auth, PAM events) and make it consistent.
3. Relying on manual reviews with weak evidence. Fix: automate disabling where possible; where not possible, require exports + tickets + timestamps.
4. Service accounts left unmanaged. Fix: document service-account rules, ownership, secret management, and monitoring; justify any non-disabling approach.
5. Exceptions without governance. Fix: keep an exception register with approvals and periodic revalidation.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions. Practically, stale accounts are a common path to unauthorized access because they are less monitored and sometimes retain legacy permissions. In CMMC assessments, weak evidence or partial coverage creates a high likelihood of a finding because assessors can test inactive accounts directly by sampling and tracing last-logon data to disablement actions. (DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2)

Practical execution plan (30/60/90-day)

Day 0–30: Stabilize and define

• Publish the inactivity-disable standard for all identifier types, including exceptions.
• Inventory identity stores and in-scope systems; complete the coverage matrix.
• Implement the directory/IdP rule for workforce accounts where technically feasible.
• Create the evidence pack template (what report, who exports it, where it’s stored).

Day 31–60: Close coverage gaps

• Implement controls for local accounts (scripts, configuration baselines, or centralized management).
• Implement app-native account disable workflows for top in-scope applications.
• Formalize the exception register and approvals for service/break-glass accounts.
• Run an internal sample test: pick accounts from each population and verify disablement logic.

Day 61–90: Prove operation and make it repeatable

• Run recurring reporting and capture evidence in a central repository.
• Add monitoring/alerting for policy drift (rule disabled, OU excluded, app owner not producing reports).
• Conduct an assessor-style tabletop: show definition, configuration, sample disables, and exceptions end-to-end.
• Use Daydream (or your GRC system) to schedule recurring evidence tasks and keep an audit-ready trail aligned to 3.5.6. (DoD CMMC Program Guidance)

Frequently Asked Questions

Does disabling identifiers after inactivity mean logging users out or locking the screen?

No. Screen lock and session timeout address active sessions. Practice 3.5.6 focuses on disabling the account identifier itself after a defined period with no activity. (NIST SP 800-171 Rev. 2)

What counts as “inactivity” for 3.5.6?

You define it. Most teams use authentication evidence such as directory or IdP sign-in events, VPN logins, or PAM access events, then document that definition in policy and procedures. (NIST SP 800-171 Rev. 2)

Are service accounts required to be disabled after inactivity?

They are identifiers, so you need a documented rule for them. If disabling is not feasible for a critical service, document an exception with compensating controls and keep ownership and monitoring evidence.

We have an application with local users that can’t auto-disable. Can we still comply?

Yes, if you implement a compensating process that reliably disables inactive users and produces strong evidence (user exports, review results, disable tickets, and timestamps). Assessors will focus on consistency and traceability. (DoD CMMC Program Guidance)

How do we handle third-party (contractor) accounts?

Apply the same inactivity rule unless there is a documented exception. Make the sponsor responsible for access reviews and ensure disablement happens through your standard identity workflow.

What evidence is most persuasive to an assessor?

Configuration proof of the rule plus operating evidence that shows accounts were actually disabled due to inactivity. Pair a current inactive-account report with the underlying logs or change records that show the disable action. (NIST SP 800-171 Rev. 2)