Identity Hygiene Guide: Finding and Fixing Hidden Identity Risks

Identity hygiene is the routine work of finding dormant, duplicate, and shadow identities and fixing them to reduce the chance an attacker can use them. It applies to employees, contractors, service accounts, and AI agents, and it treats the identity population as data that drifts unless someone maintains it. Ask an IAM team, "What is identity hygiene in practice?" and many will describe a cleanup that looked finished one quarter and had drifted back by the next.

That drift matters because attackers would rather sign in than break in. An account nobody remembers still accepts a password, and nobody watches its sign-ins. A forgotten identity can remain an open path into the environment, and whoever compromises it may inherit the access it kept.

Cleanups decay because the processes that create stale identities keep running after the project closes. The teams that hold their ground run hygiene as a standing routine, with a trigger, an owner for each finding, and a recorded decision.

Why Identity Hygiene Matters

After an audit flags a few hundred inactive accounts, the question that reaches the identity team is some version of "what is identity hygiene and how to maintain it?" The definition takes a sentence. Maintenance is where programs stall, and the cost of stalling tends to surface in incident reports.

Colonial Pipeline is the case most teams know. Charles Carmakal, then CTO of FireEye Mandiant, gave a statement to the House Committee on Homeland Security on June 9, 2021. He said the attacker "logged into a virtual private network (VPN) appliance using a legacy VPN profile and an employee's username and password." The profile "did not require a one-time passcode," so multi-factor authentication was not in the path. It "has since been disabled," which means it still worked on the day of the attack.

MITRE ATT&CK catalogs this behavior as Valid Accounts (T1078) and notes that "adversaries may abuse inactive accounts," such as those of people who have left. Identity hygiene works on the supply side of that technique by shortening how long a stale account stays usable. It narrows the exposure that identity attack surface management maps from the attacker's side.

The Hidden Risks of Dormant, Duplicate, and Shadow Identities

Each of the three categories forms in a different system and hides for a different reason, so one cleanup query rarely finds all of them.

Dormant identities still authenticate but show no recent legitimate use: a legacy VPN profile, a contractor account kept "just in case," or dormant service accounts left behind by a retired integration. When the person behind one leaves, the account joins the orphaned accounts the leaver process was meant to close. A new sign-in on a dormant account deserves scrutiny, yet no one may be assigned to notice it.

Duplicate identities spread one person across several directories. The pattern often follows an acquisition. An engineer keeps an account in the acquired company's Active Directory domain, a second in the parent's cloud IdP, and a local admin login in a SaaS console. Offboarding disables the account HR knows about. The other two stay live, each with its own password and MFA settings.

Shadow identities live in systems the identity team does not administer. A marketing team buys a SaaS tool, sets it up with local logins instead of single sign-on (SSO), and invites agency staff. Those accounts never reach the IdP, so disabling someone there does not touch them.

How Fragmented Identity Systems Create Security Gaps

Each system in that table does what it was configured to do. The HR-driven provisioning process disables the Active Directory accounts the HR feed names. The cloud IdP applies its own lifecycle rules, and the SaaS tool keeps local users until an admin removes them. Identity hygiene problems sit between those systems, where no process compares one record with another.

The comparison usually fails on the join. One system keys a person by employee ID, another by email, and a third by a username set during an acquisition years ago. Without a shared key, "jsmith" in one console and "john.smith@" in another look like two people, or like nobody. That is how identity sprawl across platforms builds up while each system passes its own audit.

Fragmentation weakens detection as well. CISA and NSA published an Enduring Security Framework guide to identity and access management in March 2023. It warns that "security event monitoring is ineffective on locally provisioned accounts." An identity outside central management is harder to find, and harder to watch once someone starts using it.

Building a Continuous Identity Hygiene Program

The practical answer to how to maintain identity hygiene is to handle each problem as a finding with three fields: the identity, an accountable owner, and a decision. A continuous program runs that loop on a schedule or an event instead of waiting for the next audit.

1. 1.Choose the signal for each identity type. Dormancy detection is only as reliable as the sign-in field the report reads. In Microsoft Entra ID, lastSignInDateTime records the last interactive attempt, "whether the attempt was successful or not," according to the Microsoft Graph signInActivity reference. lastSuccessfulSignInDateTime records the most recent successful interactive or non-interactive sign-in. Using the first field can make an account used by a nightly script look dormant. It can also make a password-spraying target look active.
2. 2.Correlate accounts to a person or an owner. Join accounts across directories and apps so duplicates can collapse into one record and service accounts or agents can be linked to a responsible human, or flagged when no owner exists.
3. 3.Route each finding to that owner. The ESF guide tells administrators to "remove unnecessary local identities and investigate to identify who or what process created the local identity." That investigation turns a list of accounts into decisions.
4. 4.Record a decision. Prioritize the finding if the identity holds privileged access or reaches production. Disable it if nobody claims it within the routing window. Accept it with an expiry if the owner can name a current use, so the exception comes back for review on its own.

Thresholds are policy choices. An inactivity window that suits workforce accounts may be wrong for a break-glass account or a quarterly batch job, so set one per account type and record why.

Tools in the identity security posture management category detect many of these weaknesses, and hygiene is the routine that acts on a subset of them. Hygiene is preventive, while identity threat detection and response handles active abuse. The two overlap when a dormant account suddenly signs in, which calls for an investigation before any cleanup.

Managing Human and AI Agent Identity Hygiene

People have an anchor that agents lack. An employee's accounts trace back to an HR record, so a leaver event at least starts the work. An AI agent has no HR record. Any developer with the right permissions can create one, and the person who sponsored it can change teams without anything changing on the agent.

Take a coding agent an engineer set up to open pull requests, authenticating with an API key stored in the CI system. Six months later the engineer moves teams, the project winds down, and the key still works. The engineer's move may reach the HR system, but no corresponding lifecycle event reaches the agent. Because the agent never signs in interactively, an interactive-only dormancy report misses it. The general rules for non-human identity ownership apply: a named owner, a parent service, and usage evidence as the retirement signal.

Agents add one complication. Their scope can shift from task to task, so an over-scoped agent is hard to spot from its configuration alone. That is a large part of why agents are not service accounts for hygiene purposes, even when they authenticate like one.

Route agent findings by the state of the sponsor. If the sponsor is still in role and the agent is in use, the sponsor confirms its scope or retires it. If the sponsor has left or moved, or nobody can explain the agent's credentials, route the finding to the security team and the service owner. The original context may already be incomplete.

Identity Hygiene Best Practices

The program steps describe the loop. These practices keep it running after the first wave of findings is closed.

• Measure decisions, not account counts. Track the share of identities with a named owner and the age of open findings. A falling count of stale accounts can mean progress, or a connector that stopped reporting.
• Give each accepted exception an end date. An exception without an expiry is a dormant account with paperwork attached.
• Automate detection and routing first. Identity hygiene automation pays off fastest on the repetitive steps: pulling sign-in data, correlating accounts, and opening a finding for the right owner. Automatic disablement suits low-risk workforce accounts where policy allows it. Service accounts and agents usually need owner confirmation or a holding period, because a wrong disable can break production.
• Disable before you delete. A holding period catches false positives, such as a year-end job that looks dormant for eleven months. Delete once the period passes with no reported break.
• Keep access reviews for what reviewers can judge. Scheduled access reviews ask a manager to attest to access they recognize. A duplicate account in an acquired domain, or a local login in a marketing tool, may have no manager who would recognize it. It needs detection rather than attestation. Review frequency should follow risk and the control framework the organization reports against.
• Fix the source along with the account. If one SaaS tool keeps producing local accounts, moving it behind SSO retires a recurring finding instead of closing the same ticket each cycle.

How NewCore Supports Identity Risk Detection and Mitigation

Agents compress the hygiene clock, and a quarterly cleanup is unlikely to keep up with their rate of creation. NewCore's view is that each agent needs its own identity, an owner, policy, and an audit trail from the moment it starts running, kept current at machine speed.

• Identity Discovery: resolves a person's accounts across identity providers, directories, and HR systems into one identity record, which pulls duplicate accounts together. Its insights include dormant accounts, offboarding gaps, over-privileged users, and high-risk access. Risk reduced: duplicates and dormant accounts scattered across consoles nobody reconciles.
• Agent Inventory: discovers agents where they run through read-only integrations ("found, not self-reported") and shows who owns each one, who can invoke it, and which tools it can reach. Risk reduced: shadow agents that never appear on a registration form.
• Ask NewCore: answers plain-language questions from the identity graph, such as "Which agents are still active for people who have left?" When an agent has no owner, the answer flags it for review and provides an option to assign one. Risk reduced: ownerless agents found only during an incident.
• Agentic Governance: gives each agent "an owner, a limit and a record," and lets the owner or an admin cut off a single session or the entire agent. Risk reduced: a finding nobody has the means to act on.

In this role, NewCore can run alongside the existing IdP and IGA platform without changing the existing employee sign-in flow. It adds detection and ownership across connected systems that may sit outside those platforms, so a hygiene finding reaches someone who can decide. Teams can begin with identity discovery for people and AI agents and act on what they find through agent governance with an owner and a record. A stale identity is easier to fix before it becomes incident work.

Your workforce now includes agents. Know who answers for each one. Request a Demo →

Frequently Asked Questions

How often should identity hygiene checks run?

There is no universal interval. Run checks frequently enough to match the rate at which the identity population changes. Event-driven checks suit hires, departures, owner changes, and new account creation. Scheduled checks still help catch dormant accounts and integrations whose source systems emit no useful lifecycle event.

How long should an account be inactive before it is considered dormant?

The threshold depends on the account type and what it reaches. A workforce account may become suspicious after weeks of inactivity, while a quarterly job can remain legitimate for months without signing in. Define separate windows for workforce, privileged, service, emergency, and agent identities, and document the reason for each.

Should dormant accounts be deleted immediately?

Usually not. Disable the account first and hold it for a defined period so an owner can report a legitimate dependency. Delete it once the holding period passes without a valid claim, while retaining the evidence required by the organization's audit and retention policies.

Is identity hygiene the same as an access review?

No. An access review asks an accountable person whether known access is still appropriate. Identity hygiene looks for identities, accounts, and ownership gaps that may never reach that reviewer. The two controls complement each other.