How do security teams know whether inactivity controls are actually working?

Why This Matters for Security Teams

Inactivity controls are only meaningful if a team can prove they operate on real identifiers, not just in policy language. For NHIs, dormant service accounts, API keys, and OAuth grants often remain usable long after they should have been reviewed. That gap matters because inactive does not mean harmless: unused credentials can still be discovered, reused, or chained into a broader compromise.

Security teams often overestimate control maturity when the SSP says “disable dormant accounts after 90 days” but cannot show the detection logic, approval path, or disabling evidence. NIST SP 800-53 Rev 5 Security and Privacy Controls provides the broader expectation that access control must be implemented and auditable, while NHI-specific guidance from Ultimate Guide to NHIs — Standards frames lifecycle governance as a recurring operational task, not a one-time policy statement.

The practical question is whether the team can demonstrate review cadence, exception handling, and revocation records without hand assembly. In practice, many security teams discover inactivity failures only after an audit, an incident, or a long-dormant credential is used unexpectedly, rather than through intentional control testing.

How It Works in Practice

A working inactivity control has three parts: a documented threshold, a reliable detection method, and evidence that action happened on time. The threshold should define what “inactive” means for each identifier type, because a service account used monthly is different from a machine token used every few minutes. A single blanket rule often creates false positives or blind spots.

Teams usually need to correlate identity data with activity logs, authentication events, token issuance records, or secret usage telemetry. For NHIs, that may include API gateway logs, cloud audit trails, secrets manager access events, and directory changes. The control is strongest when the workflow is explicit: detect dormant identifiers, review ownership and business need, disable or rotate the credential, and retain evidence of each step. NIST guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it reinforces that control operation must be traceable, not assumed.

A practical implementation usually includes:

• Asset or identity inventory that distinguishes humans, service accounts, API keys, and OAuth apps
• Time-based rules for inactivity, with separate thresholds by system criticality
• Automated detection from logs and telemetry, not manual spot checks
• Workflow evidence showing review, approval, disablement, or exception acceptance
• Revalidation after disablement to confirm the identifier can no longer authenticate

NHIMG research shows why this matters: the Ultimate Guide to NHIs — Standards notes that only 20% of organisations have formal offboarding and revocation processes for API keys, which is exactly where inactivity controls usually fail in practice. These controls tend to break down in environments with shared service accounts, poor logging retention, or manually managed secrets because there is no trustworthy signal for whether the identifier is truly dormant.

Common Variations and Edge Cases

Tighter inactivity controls often increase operational overhead, requiring organisations to balance security gains against application continuity and support burden. That tradeoff is especially visible for batch jobs, vendor integrations, and legacy systems where “inactive” may simply mean “low frequency,” not unused. Best practice is evolving here, and there is no universal standard for one inactivity threshold across all NHIs.

Some environments need exception handling for break-glass accounts, shared automation identities, or externally managed OAuth grants. In those cases, the question is not whether the account had zero logins, but whether the team had a compensating review process, a named owner, and a documented reason for continued existence. If the control depends on human memory to explain why an account was left enabled, it is not defensible.

Another common edge case is hidden reactivation: a disabled account may still be reissued through CI/CD, secrets sprawl, or a partner system. That is why teams should verify both disablement and downstream propagation. For broader lifecycle governance, NHIMG’s State of Non-Human Identity Security shows that monitoring and logging gaps are a major contributor to NHI-related attacks, which makes inactivity checks far less trustworthy when telemetry is incomplete. The control is most reliable when identity, logging, and revocation all live in the same operating model.

Related resources from NHI Mgmt Group

• How do security teams know whether privacy controls are actually working?
• How do security teams know whether chatbot controls are actually working?
• How do security teams know whether password reset controls are actually working?
• How do security teams know whether their ISO 27001 controls are actually working?