IAM teams should treat activity data as a decision support signal, not an automatic approval or denial rule. Use last-use dates, login frequency, and peer comparisons to validate whether access is still needed, then document the business reason when an entitlement remains despite low use. That makes certifications more defensible and less dependent on assumption.
Why This Matters for Security Teams
Activity data can make access reviews more evidence-based, but it can also mislead reviewers if it is treated as a proxy for entitlement necessity. A service account may be quiet because it runs only on month-end, or because logging is incomplete. The right question is not “has this account been active?” but “does this access still support a current business function?” That distinction matters across human and non-human identities alike.
For NHI-heavy environments, inactivity is especially risky as a signal because many identities are intentionally intermittent, automated, or event-driven. The Ultimate Guide to NHIs — Key Research and Survey Results notes that 97% of NHIs carry excessive privileges, which means a low-usage entitlement can still represent broad blast radius. Activity data should therefore support reviewer judgement, not replace it. The same caution appears in the OWASP Non-Human Identity Top 10, which emphasizes that secrets, service accounts, and tokens often outlive the real operational need.
In practice, many security teams discover overentitlement only after a review is challenged, rather than through intentional entitlement design.
How It Works in Practice
Use activity data as one input in a review workflow that tests whether the entitlement is still justified. Start with signals such as last-use date, authentication frequency, API call patterns, and peer comparison within the same job family or application tier. Then validate the context: scheduled jobs, disaster recovery paths, integration dependencies, and seasonal processing can all create legitimate “quiet” access.
A defensible review process usually combines three checks:
- Was the entitlement used in the review period, and if not, is there a documented operational reason?
- Does the access align with the identity’s role, workload, or application function?
- Can the entitlement be reduced, time-bound, or moved to NHI Lifecycle Management Guide-style offboarding and rotation controls?
For human identities, peer comparison can help surface outliers, but it should not become a popularity contest. A finance approver may use an entitlement less often than a support engineer and still genuinely need it. For NHIs, activity data should be paired with workload ownership, change records, and secret inventory. The Ultimate Guide to NHIs shows how common it is for secrets to persist long after their intended use, so review evidence should include whether the secret or account is still wired into production dependencies.
Current guidance suggests reviewers should document the business rationale whenever low activity does not lead to removal, and that rationale should be specific enough to survive audit. These controls tend to break down in environments with weak logging, shared service accounts, or automated jobs that generate little observable user-like activity.
Common Variations and Edge Cases
Tighter use of activity data often increases review time and analyst workload, requiring organisations to balance stronger evidence against operational friction. That tradeoff is real in hybrid estates, where different platforms expose different telemetry and some identities have no meaningful “login” event at all.
Best practice is evolving for machine identities, because current guidance suggests that “last used” is often a poor standalone control for API keys, workload identities, and event-driven service accounts. A token may be active only during deployment windows, or a workload may authenticate through short-lived credentials that rotate before a human reviewer ever sees a pattern. In those cases, reviewers should look for orchestration logs, job schedules, and ownership records rather than expecting human-like session history.
There is also no universal standard for how much inactivity is enough to justify removal. Some teams use 30, 60, or 90 days depending on risk, but the threshold should reflect the business cadence, not an arbitrary default. The more defensible approach is to pair activity with entitlement criticality, then require explicit sign-off when an exception remains. That mindset aligns with the broader NHI risk picture in the Ultimate Guide to NHIs — Key Challenges and Risks, where access often remains excessive long after its original purpose has faded.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Access reviews must validate whether NHI privileges still match actual use. |
| NIST CSF 2.0 | PR.AC-1 | Reviews should verify that access is approved and aligned to business need. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege review depends on comparing actual usage to assigned access. |
Use activity data to confirm entitlement necessity, then remove or time-box unused NHI access.
Related resources from NHI Mgmt Group
- How should security teams run access reviews for non-human identities?
- What do healthcare IAM programmes often get wrong about access reviews?
- How should teams reduce manual access request workload without weakening IAM governance?
- How should IAM teams govern access as organisations expand across regions?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
