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

Identifier Handling

Submit your own example

Practice statement

Disable identifiers after a defined period of inactivity.

Quoted verbatim from NIST SP 800-171 Rev. 2 §3.5.6.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]

    a period of inactivity after which an identifier is disabled is defined; and

    1 example covers this

  2. [b]

    identifiers are disabled after the defined period of inactivity.

    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.6Identifier Handling
    Disable identifiers after a defined period of inactivity.

    • [a]

      a period of inactivity after which an identifier is disabled is defined; and

    • [b]

      identifiers are disabled after the defined period of inactivity.

    35-day inactivity disable for people, 90 with owner sign-off for service identities

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

    Implementation

    AO coverage. Addresses both Identifier Handling objectives: the inactivity period is defined, and identifiers are disabled after it.

    Defined periods. Interactive human accounts: 35 days without a successful sign-in. Contractor and temporary accounts: 14 days, because their engagements are short and gaps are suspicious. Service identities: 90 days, and disabling one additionally requires the registered owner to confirm the automation is retired — some legitimately run quarterly.

    Enforcement. A nightly job reads sign-in activity, disables accounts past their threshold, notifies the manager, and opens a ticket. Disabled accounts are deleted at 90 days, which hands the identifier to the reservation hold described in the IA.L2-3.5.5 example. Re-enabling requires manager approval recorded in the ticket; the help desk cannot re-enable at its own discretion.

    Deliberate exclusions. Break-glass accounts are excluded from auto-disable on purpose — an inactive break-glass account is the normal state. They are instead reviewed quarterly with a live sign-in test that both proves the account works and resets the activity clock.

    Maintenance. Monthly report of disables versus re-enables, watched for a pattern that would mean the threshold is wrong for a team. Annual review of the thresholds against furlough patterns.

    Accepted gap. One SaaS app reports last login only as a date, exported weekly by CSV, so the effective detection window there stretches to as much as 42 days. Logged on the exception register with a note to switch to the vendor's activity API when it leaves preview.

    What the evidence looks like

    • Policy stating each inactivity threshold and the break-glass exclusion
    • Scheduled job configuration or script with its threshold logic
    • Sample disable ticket and a re-enable ticket showing manager approval
    • Quarterly break-glass live-test record
    • Exception register entry for the weekly-CSV SaaS app

    Environment

    Seasonal workforce with furloughs and burst contractors; enclave users sometimes go weeks between logins during proposal lulls.

    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.