Relying only on last login can misstate whether an account is truly active, especially in collaboration platforms where a user may interact with email without logging in frequently. A better approach is to combine login signals with usage evidence such as last email interaction. That gives security and IT teams a more accurate view of real account activity and reduces false assumptions about dormant users.
Why last login alone is a weak activity signal
Last login is a narrow authentication event, not a full measure of how a person or account is actually being used. It can look stale even when the user is active in the application, and it can also look current when an account has not been meaningfully used since the login event. That gap is common in collaboration tools, email, and other systems where work continues after authentication.
The core issue is that login telemetry answers only one question: when did the account last authenticate? It does not tell you whether the account sent mail, edited content, approved a workflow, accessed a file, or triggered an API call. If you use it as the sole indicator, you risk conflating “not logging in often” with “not being used.”
For teams managing access reviews or dormant-account cleanup, the right interpretation is that last login is a starting point, not a conclusion. A better activity view combines authentication evidence with account management and audit logging signals so the decision reflects real use rather than a single timestamp.
What this means for dormant-account decisions
Judging activity from one field can create both false positives and false negatives. A false positive occurs when an account appears dormant because the user rarely signs in, even though the account remains operational through background usage or delegated access. A false negative occurs when the last login is recent, but the account has no meaningful business use beyond that event.
That matters because dormant-account decisions often trigger disablement, recertification, or exception handling. If the signal is too weak, security teams may remove an account that still supports business processes, or leave in place an account that is no longer needed but still retains access. Either outcome increases friction and weakens trust in the review process.
The practical fix is to pair login data with usage evidence that reflects the application’s real workflow. In email and collaboration platforms, that often means checking last message interaction, document edits, calendar actions, or other product-specific evidence before deciding that an account is inactive. That aligns the review with how the service is actually used rather than how often the user reauthenticates.
How to build a more accurate activity picture
Use a layered view of activity. Start with last login, then validate it against one or more usage signals that are harder to misread in context. The exact signals depend on the platform, but the principle is consistent: activity should be confirmed by evidence that the account is doing work, not merely that it has a recent sign-in record.
In a collaboration environment, that may include email send or read events, file access or editing, chat participation, or administrative actions. In business systems, it may include record updates, workflow approvals, or API-driven transactions. The point is to choose the evidence that best represents normal use for that system.
This is also where identity and access control discipline matters. A recurring review should distinguish between authenticated but idle accounts, service-driven activity, and user-driven activity. Where the account can affect access decisions, NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST SP 800-63 Digital Identity Guidelines both support thinking in terms of authentication evidence plus lifecycle and assurance, not a single event.
Risk and Threat Considerations
Relying only on last login creates a control blind spot: it can make an account look inactive when it is still being used, or active when it is no longer needed. That can lead to inappropriate disablement, missed cleanup, and poor visibility into accounts that retain access without frequent sign-in.
Failure mechanism: the review process treats one authentication timestamp as proof of overall account activity, even though meaningful use may occur through email, delegated actions, API calls, or other non-login interactions.
Impact: teams may overestimate dormancy, under-detect stale access, and make access decisions that either disrupt business operations or leave unnecessary exposure in place.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Audit Events | Login timestamps need corroborating activity telemetry to judge account use. |
| IA-5 — Authenticator Management | Stale or misleading login data affects lifecycle decisions around credentials and account validity. | |
| Recommendation — Log platform-specific usage events that show real account activity, not only authentication. Review authenticator and account lifecycle evidence before treating an account as dormant. | ||
| NIST SP 800-63 | Authentication and Lifecycle Management — Authentication and Lifecycle Management | Activity assessment depends on authentication evidence plus ongoing account lifecycle context. |
| Recommendation — Combine authentication records with lifecycle and assurance signals before deciding an account is inactive. | ||
Practitioner Guidance
What to verify: Before marking an account dormant, confirm whether the platform exposes usage signals that better represent actual work, such as message activity, file events, or task actions. If those signals exist, use them alongside login data rather than as an afterthought.
Decision rule: If an account can perform business-relevant actions without frequent interactive login, treat last login as insufficient on its own and require an additional usage check before disablement or recertification.
Practitioner takeaway: The best control question is not “when did the account last log in?” but “is this account still performing real work, and can we prove it from the right telemetry?”
Related resources from NHI Mgmt Group
- What do teams get wrong about last login data?
- Who is accountable when a financial system accepts a compromised login and exposes sensitive account data?
- How should security teams investigate data activity across cloud, SaaS, and on-prem environments without relying on fragmented logs?
- Why do account takeovers and mule activity require different authentication controls than routine login protection?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
