Identifier Handling

Define the inactivity window and make something actually enforce it.

Objective [a] is a number in your policy. The assessment guide's worked example uses 45 days. Objective [b] is the mechanism: a scheduled report of last sign-in dates with a documented disable step, or an automation that disables at the threshold.

Disabled is not deleted, and this requirement is why.

Disabling ends the risk of an unwatched active account while preserving the object, which also carries the identifier reuse prevention in IA.L2-3.5.5. Disable at the inactivity threshold. Delete on your own schedule or never.

Scope it to user accounts.

Computer objects, key cards, and every other identifier-bearing thing invite scope creep. Define the requirement's reach as user identifiers, and handle service accounts by deliberate review rather than automatic disabling, because an auto-disabled backup account is an outage. Write the definition into the procedure.

Plan the leave-of-absence path before it happens.

Extended leave trips any inactivity threshold. Suspend the account, keep the device on inventory, and re-enable through a defined step when the person returns. A documented exception process keeps [b] enforced without punishing parental leave.