Skip to main content
Identity Authority
Category: Identity Lifecycle

Dormant Account

Also known as: Inactive Account
Simply put

A dormant account is an account that has had no activity for an extended period of time. The length of inactivity that qualifies an account as dormant varies depending on the governing rules or jurisdiction. In the financial contexts described in the evidence, this period can range from several months to over a year.

Formal definition

A dormant account is an account marked as inactive after a defined period elapses without qualifying activity. The evidence for this term derives from financial/banking contexts, where activity typically means transactions such as deposits or withdrawals, and the qualifying inactivity threshold is determined by external rules such as a member's state of residence or applicable regulatory requirements (the cited sources reference periods ranging from roughly six months to over a year). Note that the provided evidence describes dormant accounts in a banking and unclaimed-property sense rather than in the sense of dormant identity or access-management accounts; applying this concept to IAM account lifecycle management (for example, detecting unused user accounts as candidates for deprovisioning or access certification) is out of scope for the evidence supplied and would require additional, IAM-specific sources.

Why it matters

In the financial and banking contexts described in the evidence, dormant accounts carry regulatory and consumer-protection significance. When an account sees no qualifying activity such as deposits or withdrawals for a defined period, it may be reclassified as dormant, which can trigger specific rules around permitted service charges, fees, and practices. For example, the Georgia Department of Banking and Finance has enacted rules governing how banks and credit unions may treat dormant accounts, illustrating that the handling of these accounts is subject to external regulatory oversight rather than institutional discretion alone.

Because the inactivity threshold that qualifies an account as dormant varies by governing rule and jurisdiction, institutions must track activity carefully and apply the correct standard for each account holder. The evidence references periods ranging from roughly six months to over a year, and in several cases the threshold is determined by the member's state of residence. Misapplying these thresholds could result in improper fees, premature dormancy classification, or failure to meet unclaimed-property obligations.

It is important to note that the evidence supporting this term is drawn from banking and unclaimed-property contexts, not from identity and access management. Readers should not assume this material addresses IAM concerns such as detecting unused user accounts, deprovisioning, or access certification; applying the dormant-account concept to identity lifecycle management would require additional, IAM-specific sources that are out of scope here.

Who it's relevant to

Banking and Credit Union Operations Teams
Staff responsible for account maintenance must track qualifying activity and apply the correct inactivity threshold, which may be determined by the member's state of residence or applicable regulations. They also need to apply permitted service charges, fees, and practices for dormant accounts in accordance with governing rules.
Compliance and Regulatory Affairs Personnel
Because regulators such as a state banking department may enact rules governing dormant accounts and unclaimed property, compliance staff must ensure the institution's dormancy classification, fees, and handling align with the applicable jurisdictional requirements.
IAM Practitioners (Scope Caution)
Security architects and identity governance leads should be aware that the evidence for this term is banking-specific and does not address IAM account lifecycle concerns such as detecting unused user accounts for deprovisioning or access certification. Applying this concept to identity and access management would require additional, IAM-specific sources not present in this evidence.

Inside Dormant Account

Inactivity Threshold
The configured period of no observed authentication or access activity after which an account is classified as dormant. This threshold varies by deployment, typically ranging from 30 to 90 days depending on organizational policy, account type, and risk tolerance.
Last Activity Signal
The data point used to measure dormancy, commonly derived from last successful authentication timestamp, last token issuance, or last directory access event. The reliability of this signal depends on the completeness of logging and whether all access paths are instrumented.
Account Type Context
Dormancy criteria often differ across human user accounts, service accounts, and non-human identities. Service accounts may show infrequent but legitimate activity, so applying human-oriented thresholds to them can produce false positives.
Governance Disposition
The identity governance and administration (IGA) outcome applied once dormancy is detected, such as flagging for access review, suspension, disabling, or deprovisioning. This is a lifecycle management concern rather than a runtime enforcement action.
Detection Source
The systems that surface dormancy, typically directory queries (for example against an LDAP directory), authentication logs, and IGA analytics. Coverage depends on which systems feed activity data into the evaluation.

Common questions

Answers to the questions practitioners most commonly ask about Dormant Account.

Is a dormant account the same as a disabled or deprovisioned account?
No. A dormant account is one that remains active and capable of authenticating but has shown no login or usage activity for a defined period. A disabled account has been explicitly deactivated so it can no longer authenticate, and a deprovisioned account has had its access and typically its identity record removed. Dormancy is a state of inactivity, not a state of enforcement; the account is still a live attack surface until an IGA or administrative process acts on it.
Does detecting a dormant account require runtime access enforcement components like a PDP or PEP?
Typically no. Identifying dormant accounts is generally an identity governance and administration (IGA) concern that relies on lifecycle data such as last-login timestamps, last authentication events, or usage logs rather than on real-time policy decision points or enforcement points. Runtime components such as a PDP or PEP evaluate and enforce access at the moment of a request, whereas dormancy detection is an after-the-fact analysis of historical activity. The two can complement each other, but detecting dormancy does not depend on the enforcement path.
What data sources are typically used to identify dormant accounts?
In most deployments, dormancy is derived from activity signals such as last successful authentication time, last interactive login, last token issuance, or application-level usage records. These signals may originate from directory attributes (for example, a last-logon-type attribute in an LDAP or directory service), authentication logs, or SIEM data. Accuracy depends on how completely activity is captured; service accounts, API-only accounts, and federated logins may not update the same signals, so the chosen source should match the account type being evaluated.
How should the inactivity threshold for dormancy be set?
The threshold depends on organizational risk tolerance, account type, and any applicable compliance requirements, so there is no universal value. Higher-privilege accounts often warrant shorter thresholds than standard user accounts, and seasonal, contractor, or infrequently used accounts may require adjusted windows to avoid false positives. Thresholds are commonly defined in governance policy and validated during access reviews. Because behavior varies by environment, the threshold should be documented and periodically reassessed rather than treated as fixed.
What actions are typically taken once an account is flagged as dormant?
Common responses, depending on policy, include flagging the account for review, disabling it to remove its ability to authenticate, requiring recertification of the associated access, or fully deprovisioning it. Many organizations stage these actions, for example disabling first and deprovisioning after an additional grace period, to allow legitimate reactivation. These steps are governance and lifecycle actions and should be tied to certification or access review workflows so decisions are attributable and auditable.
How should service accounts and non-interactive accounts be handled in dormancy analysis?
Service accounts, API clients, and other non-interactive identities often do not generate interactive login events, so applying user-oriented inactivity signals to them can produce misleading results. In most deployments these accounts are evaluated using different activity indicators, such as token issuance, API call logs, or last credential use, and are frequently governed under separate policies with distinct thresholds and owners. Treating them with the same criteria as human user accounts can cause either false dormancy flags or missed truly unused accounts.

Common misconceptions

A dormant account is inherently a disabled or blocked account.
Dormancy is a classification based on inactivity, not an enforcement state. A dormant account typically remains fully enabled and usable until an IGA process suspends, disables, or deprovisions it. The classification and the disposition are separate steps.
Zero recorded activity always means the account is genuinely unused and safe to remove.
Absence of activity in a given log may reflect incomplete instrumentation rather than true disuse. Some access paths may not be captured, and certain service or break-glass accounts are intentionally rarely used, so disposition generally warrants review rather than automatic deletion.
Detecting dormant accounts is a real-time access enforcement function.
Dormant account detection is primarily an IGA and access review concern operating over historical activity data. It is distinct from runtime enforcement components such as a PDP, PEP, or token validation, which evaluate individual access requests as they occur.

Best practices

Define distinct inactivity thresholds for different identity types, keeping human user accounts, service accounts, and other non-human identities on separate criteria to reduce false positives.
Base dormancy determinations on multiple activity signals where available, such as last authentication and last token issuance, rather than a single log source that may have incomplete coverage.
Route detected dormant accounts through an access review or certification workflow before disabling or deprovisioning, so that a responsible owner confirms the disposition.
Validate that all relevant access paths are instrumented and feeding activity data into the evaluation, since gaps in logging can cause active accounts to appear dormant.
Treat dormancy handling as an identity lifecycle process integrated with joiner-mover-leaver and segregation-of-duties controls, keeping it separate from runtime enforcement components.
Document the threshold, data sources, and disposition steps so that dormant account handling is auditable and consistent with compliance and access certification requirements.
Application Security Isn’t Optional Anymore.