What Is a Dormant Account?
An account can look harmless simply because no one has used it recently, but inactivity does not remove access. The practical problem is that an unused account may still be able to sign in, reach systems, retrieve data, or perform administrative actions long after its original purpose has faded. Security teams therefore need to distinguish an account that is quiet from an account that is safely closed. That distinction affects whether the organization monitors the account, disables it, removes its permissions, or investigates why it still exists. In this episode, we will answer what makes an account dormant, why employee, administrator, vendor, and service accounts become dormant in different ways, and how to decide what should happen next. By the end, you should be able to explain why no recent activity is not the same as no remaining risk. A dormant account is an account that remains active even though it has not been used for an extended period. Active means the account can still authenticate or otherwise exercise access that has not been formally removed. Dormant describes inactivity, not safety, ownership, or intent. A disabled account is different because it has been deliberately prevented from authenticating. An expired account has reached a configured end date, while an orphaned account is one that no longer has a clear responsible owner. These conditions can overlap. An orphaned account may also be dormant, and a dormant account may later be disabled, but the words describe different facts. They are often confused because people treat absence of use as evidence that the account has already been retired. The main distinction to remember is simple: dormancy tells you that access has been quiet, not that access has been removed. Employee accounts often become dormant when employment ends, a worker changes roles, a contractor completes an assignment, or someone takes an extended leave. The account may remain in a directory, cloud service, application, or remote access system even after daily use stops. Inactivity can be especially misleading when access is spread across several systems, because disabling one central account may not automatically close separate application accounts or locally managed credentials. A former employee account may also retain group memberships, shared-resource permissions, application roles, or access tokens that were never revisited. The risk does not depend on whether the original user intends to return. It comes from the fact that a valid path remains available to anyone who can obtain or reuse the associated credentials. Effective offboarding must therefore remove access across the full account environment rather than assuming that silence means completion. Dormant administrator accounts deserve greater attention because their permissions can change systems, create users, alter logs, or bypass ordinary restrictions. Privileged accounts are sometimes created for migrations, emergency maintenance, testing, or temporary projects and then left in place after the work ends. They may be overlooked because administrators use a different daily account, because the account name does not clearly reveal its purpose, or because no one wants to remove access that might be needed later. That caution can preserve unnecessary power indefinitely. A privileged account should have a named owner, a documented purpose, an approved method of use, and evidence that its continued existence is required. If it is rarely needed, stronger safeguards may include disabling it between approved uses, requiring multi-factor authentication (M F A), monitoring every activation, and reviewing its permissions separately from ordinary user accounts. Dormant privilege is still privilege. Vendor and third-party accounts become dormant for similar reasons, but they introduce an additional ownership problem. The external person may no longer be assigned to the work, while the internal sponsor assumes the vendor is managing the account. The vendor may assume the customer will close it, leaving responsibility unclear on both sides. Remote support accounts, portal accounts, and temporary access created for implementation work can remain active after a contract changes or a project closes. Because these accounts may be used infrequently even when legitimate, a long period without activity does not automatically prove that they are unnecessary. The organization still needs a current sponsor, a defined business purpose, a review date, and an expiration decision. Third-party access should not survive solely because no one has asked for its removal. Continued access requires active confirmation from someone inside the organization who is accountable for the relationship. Service accounts require a different interpretation because they are used by applications, scheduled tasks, devices, and automated processes rather than by a person signing in interactively. Some service accounts authenticate continuously, while others may run only during monthly processing, maintenance, backup restoration, certificate renewal, or another infrequent operation. A lack of interactive logins therefore does not prove that the account is dormant, and a quiet service account may still support an important dependency. The correct question is whether the account is performing a current, documented function. Each service account should have an owner, a defined workload, an approved credential-management method, and a record of the systems that depend on it. Before disabling one, defenders should check application logs, scheduled jobs, secrets stores, and configuration references. Dormant service accounts are dangerous, but careless removal can also interrupt operations, so verification matters. Dormant accounts can become quiet paths into an organization because they attract less attention than accounts used every day. Monitoring rules may focus on high-volume activity, while a forgotten account has no normal pattern that users or managers recognize. The credentials may be old, reused, shared, stored in outdated documentation, or excluded from newer authentication requirements. The account may also retain permissions that no longer match current business needs. An attacker who gains control of such an account may appear to be using a valid identity rather than exploiting a visible software flaw. Dormancy does not make compromise inevitable, but it can reduce the chance that unusual use is challenged quickly. The defensive goal is to make every active identity explainable. Someone should know why it exists, who owns it, what it can reach, how it is authenticated, and when it should be reviewed or closed. Before we continue, this episode is brought to you by the Bare Metal Cyber Academy. The Academy is a place for people who want to keep developing practical cybersecurity knowledge through clear, structured education. It is designed to help learners and working professionals strengthen their understanding of security concepts without turning every topic into jargon or exam preparation. You can visit Bare Metal Cyber dot com to explore the Academy and see the learning opportunities currently available. Careful account management depends on understanding how identity, access, ownership, and risk fit together, and those connections become easier to apply when they are taught directly. Now, let’s return to dormant accounts and the decisions that keep forgotten access from remaining available indefinitely. Dormancy should not be confused with password age, credential expiration, or proof of compromise. An account can be used every day with an old password, so the password is stale even though the account is not dormant. Another account may have a recently changed password but remain unused for months, which means its credential is newer while the account is still dormant. Inactivity also does not show that an attacker has used the account. It is a condition that deserves review because the account remains available without a demonstrated current need. Organizations often choose an inactivity threshold, such as a defined number of days, to identify candidates for review. That threshold is a trigger for investigation, not a universal definition of danger. The account type, privilege, business cycle, owner, and authentication method determine what the inactivity actually means. Finding dormant accounts requires more than checking a single last-login field. Different systems record activity differently, and some fields are updated only by certain types of authentication. Useful evidence may include successful sign-ins, failed sign-ins, application sessions, token use, remote access records, directory activity, scheduled task execution, and recent use of assigned privileges. The available evidence also depends on how long logs are retained. An account may appear unused simply because older records are no longer available. Federated applications and cloud services can create another gap when the central identity system shows authentication but not the actions performed after access was granted. A reliable review therefore compares several sources and considers the account’s expected behavior. The objective is not to produce a perfect timestamp. It is to determine whether there is credible evidence of a current purpose and legitimate recent use. Account lifecycle management is the broader process that prevents dormancy from becoming neglect. Access should begin with a documented request, a responsible owner, a defined level of permission, and an expected duration when the need is temporary. Role changes should trigger a review because accounts often become partially dormant rather than completely unused. A person may stop using one application while continuing to use others, leaving old permissions behind. Departures should trigger coordinated closure across directories, cloud platforms, applications, remote access tools, and locally managed systems. Disabling an account first can preserve evidence and allow recovery if a mistake is discovered, while later deletion can remove the identity after retention and dependency requirements are satisfied. The important point is that account closure should be a managed decision, not an accidental result of someone eventually noticing inactivity. A single inactivity rule should not be applied blindly to every account. Daily employee accounts, emergency administrator accounts, seasonal worker accounts, vendor support accounts, and service accounts have different expected patterns. A short threshold may create false alarms for legitimate low-frequency access, while a long threshold may leave unnecessary privileged access active for too long. Risk-based thresholds begin with account classification. Privilege, exposure, authentication strength, data access, business purpose, and ownership all affect how quickly inactivity should trigger action. High-impact accounts may require review after a shorter quiet period even when ordinary accounts do not. Some accounts should have an explicit expiration date rather than waiting for inactivity detection. A threshold is useful because it creates consistency, but judgment is still required to determine whether the account should remain active, be restricted, be disabled, or be removed. When a dormant account is confirmed, the response should reduce access without creating avoidable operational damage. Disabling the account is often safer than deleting it immediately because it stops normal authentication while preserving records and allowing dependencies to be checked. Active sessions, refresh tokens, application passwords, access keys, and stored secrets may also need to be revoked or rotated because disabling a directory identity does not always invalidate every other credential. Group memberships and privileged roles should be removed when they are no longer justified. For service accounts, the owner should verify dependent applications before credentials are changed. M F A is valuable, but it does not make an unnecessary account acceptable. Least privilege, periodic access reviews, expiration dates, and clear ownership work together so that dormant accounts are identified before they become permanent exceptions. A useful way to evaluate any suspected dormant account is to ask a connected set of practical questions. Who is accountable for the account today, and can that person explain its current purpose? What evidence shows legitimate recent use, and does that evidence match how the account is supposed to operate? What systems, data, permissions, tokens, or automated processes can the account reach? Would disabling it interrupt a required function, and has that dependency been verified rather than assumed? If the account must remain, what expiration date, monitoring, authentication, and review conditions should apply? If no owner, purpose, or dependency can be confirmed, continued access is difficult to justify. This method turns inactivity from a vague warning into a decision based on ownership, evidence, privilege, and business need. A dormant account is an active account that has gone unused long enough to raise a legitimate question about whether its access is still needed. It is dangerous not because inactivity itself causes harm, but because forgotten access can preserve credentials, permissions, and trusted paths after normal oversight has faded. Employee, administrator, vendor, and service accounts can all become dormant, yet each type requires evidence appropriate to the way it is supposed to operate. The correct response is neither to ignore quiet accounts nor to delete them without checking dependencies. Organizations should identify them, confirm ownership and purpose, evaluate their privileges, disable or restrict unnecessary access, and document why any exception remains. The practice that follows from this episode is specific: every active account should have a current owner, a current purpose, and a current reason to remain usable.
