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.

• 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