They often treat recent activity as proof that access is still appropriate. In reality, last login only shows whether an account was used, not whether its permissions are still justified. It is best used as a triage signal to prioritise review, especially for external and temporary identities.
Why This Matters for Security Teams
Last login data is often treated as a shortcut for entitlement review, but that framing misses the real risk: an account can be active and still be overprivileged, mis-scoped, or no longer tied to a valid business need. NHI Management Group’s Ultimate Guide to NHIs – Key Research and Survey Results shows how common it is for non-human identities to remain poorly governed, with excessive privilege and weak visibility appearing far more often than teams expect. That is why recent activity should be treated as a signal for review, not as evidence of appropriate access.
This matters because stale access and active misuse can look identical in basic logs. A service account may log in daily for an automated job, a temporary identity may still be used after a contract has ended, or an API key may remain valid long after the original workflow changed. The NIST Cybersecurity Framework 2.0 puts emphasis on governance, asset visibility, and access management for exactly this reason: security teams need to know what an identity is allowed to do, not just whether it was used recently. In practice, many teams discover the problem only after an audit finding, a privilege escalation, or an unexpected third-party access review has already exposed it.
How It Works in Practice
The practical mistake is using last login as a proxy for entitlement validity. That works poorly for NHIs because usage patterns are often automated, inherited from pipelines, or triggered by external systems rather than by a person deciding to sign in. The right approach is to pair activity data with ownership, purpose, scope, and lifecycle data so reviewers can ask: who approved this identity, what workload uses it, what permissions are still required, and when should it be removed?
Teams usually get better results when they combine last login with the following checks:
- Confirm the identity type: human, service account, API key, workload identity, or temporary external access.
- Compare recent activity with an approved purpose and ticket, not just with a date stamp.
- Check whether the identity is bound to a current workload, integration, or vendor contract.
- Review privilege level, rotation status, and offboarding state alongside activity history.
- Use last login as a triage signal to rank review queues, especially where visibility is limited.
This is aligned with NHI governance guidance that prioritises lifecycle control, rotation, and revocation. NHIMG’s research summary highlights how often organisations miss basic NHI hygiene, while standards such as NIST CSF 2.0 and access governance expectations point toward continuous review rather than one-time certification. For operational teams, the key is to automate enrichment around the login event so reviewers see context, not a raw timestamp. These controls tend to break down in environments with shared service accounts and opaque CI/CD tooling because one login can represent many workloads, owners, or privilege paths.
Common Variations and Edge Cases
Tighter review of last login data often increases operational overhead, requiring organisations to balance faster triage against the cost of investigating legitimate automation. That tradeoff is real, especially where identities are reused across environments or where vendor access is bursty and hard to classify.
There is no universal standard for how much weight to give last login in a recertification workflow. Current guidance suggests it should matter more for temporary, external, and high-privilege identities, and less for stable machine-to-machine accounts with strong lifecycle controls. The strongest pattern is to treat a recent login as one input among several, not as a green light. If the account is active but its owner, purpose, or permissions cannot be justified, it still needs remediation.
Edge cases include disaster recovery accounts, break-glass access, and long-lived integration tokens that may not log in frequently but remain highly sensitive. In those situations, the review question is not “Was it used?” but “Is it still authorised, bounded, and monitored?” That is also why NHI visibility work remains important: NHIMG notes that only a small share of organisations have full visibility into service accounts, which makes activity-only decisions especially unreliable. In practice, teams get this wrong when they equate recent use with legitimacy and only later discover that an account was still active long after the business need had ended.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Last login should not replace full NHI inventory and ownership context. |
| NIST CSF 2.0 | PR.AC-4 | Access reviews must validate entitlements, not only recent use. |
| NIST AI RMF | GOVERN | Governance requires context-aware oversight of automated identity behavior. |
| OWASP Agentic AI Top 10 | A2 | Autonomous or tool-using agents can appear active while holding unjustified access. |
| CSA MAESTRO | IAM-02 | Agent and workload identities need lifecycle controls beyond simple activity checks. |
Tie recertification to least-privilege entitlement checks instead of treating activity as approval.
