Security teams should start by mapping where non-human identities exist, then remove or disable the ones that no longer support a business function. A cloud migration is a good time to reduce dormant access because old service accounts, API keys, and automation credentials often linger unnoticed. The aim is to shrink standing access, improve visibility, and make every remaining identity easier to govern.
Why Dormant Non-Human Identities Become Migration Debt
Dormant non-human identities are usually a sign that access was created for a project, pipeline, or vendor relationship that was never fully retired. In a cloud migration, that debt becomes more visible because teams discover old service accounts, API keys, OAuth grants, and automation tokens that still authenticate even though the workload behind them has moved or died. The security issue is not just clutter; every unused identity expands the audit surface and makes it harder to prove what should still exist.
Security teams should treat dormancy as a governance problem with operational consequences. If the identity still works, it can still be abused, and if no one can explain its business owner, its continued presence usually means the control environment is weaker than the inventory suggests. NHIMG research has found that lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, which shows how often stale access and poor lifecycle control sit behind broader exposure.
In practice, many security teams only discover dormant identities when a migration checkpoint, application outage, or audit exception forces a late cleanup.
How to Reduce Dormant Access Without Breaking Migration Work
The practical approach is to separate discovery, validation, and removal. First, build an inventory of machine identities across source environments, target cloud accounts, CI/CD systems, and third-party integrations. Then classify each identity by owner, workload, last use, privilege scope, and dependency. An identity is not ready for deletion simply because it looks old; it must be matched to a live business function, and the function must be confirmed by the team that operates it.
A useful migration pattern is to move from “does this secret exist?” to “does anything still depend on this secret?” That means checking logs, application references, workload schedules, and token issuance paths before decommissioning. Where possible, replace long-lived credentials with short-lived access so inactivity becomes easier to observe and the blast radius of a missed identity is smaller. Guidance from the OWASP Non-Human Identity Top 10 is especially useful here because dormant access often overlaps with weak inventory, excessive privilege, and poor lifecycle hygiene.
For higher-risk identities, reduce them in stages. Disable first, monitor for breakage, and only delete once you are confident no latent dependency remains. This is especially important for shared service accounts, third-party OAuth apps, and credentials embedded in automation, where a hidden dependency can surface weeks after the migration move.
NHIMG’s State of Non-Human Identity Security report is relevant because it shows that organisations are already struggling with confidence, visibility, and over-privilege in NHI programmes, which are the same conditions that make dormant access hard to retire cleanly. These controls tend to break down when migration teams copy legacy workloads into the cloud without re-issuing identities, because old permissions survive the move while ownership becomes ambiguous.
- Map identities by workload and owner before the migration cutover.
- Flag credentials with no recent use, no clear dependency, or no named business sponsor.
- Disable before deleting when the downstream dependency is uncertain.
- Replace any identity that must survive migration with a shorter-lived, more auditable pattern.
Where Dormancy Risk Changes in Real Migration Programmes
Tighter cleanup often increases operational friction, because migration programmes rarely have complete dependency knowledge on day one. The tradeoff is between reducing standing access and avoiding unnecessary outage risk. That means some teams will need a temporary exception process for identities that are still in use but not yet fully understood.
Best practice is evolving, but the pattern is clear: identities tied to legacy middleware, batch jobs, and vendor-to-cloud connections are the most likely to be missed. These are often dormant only from the perspective of the migration team, not from the application owner’s perspective. Temporary retention should therefore be time-bound, explicitly approved, and revalidated after each migration milestone.
Another common edge case is shared credentials. If one dormant-looking identity supports several workloads, the team should not treat it as a simple delete candidate. It needs dependency tracing first, then privilege reduction, then retirement planning. That is slower, but it is the safer path when the same credential has become embedded in multiple environments.
Risk and Threat Considerations
Dormant non-human identities create a durable attack surface because they often retain authentication ability without active monitoring, clear ownership, or recent review. In a cloud migration, that exposure can widen when old identities are copied forward, forgotten in parallel environments, or left behind in integration paths that no longer have a business reason to exist.
Failure mechanism: The risk materialises when a stale service account, token, or API key still has valid access but no one is actively watching its use. Attackers and insiders both benefit from that condition because unused credentials are less likely to trigger operational scrutiny, and over-privileged dormant access can be repurposed for unauthorised cloud actions, data access, or persistence.
Impact: The likely consequence is avoidable privilege accumulation across the migration estate, weaker attribution, and a larger blast radius if one forgotten identity is compromised. In the worst case, dormant access becomes the quiet path that undermines the migration’s intended security uplift.
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 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Inventory | Dormant NHIs are hard to remove without a complete inventory. |
| NHI-02 — Lifecycle and Ownership | Dormancy is a lifecycle and ownership failure in migration. | |
| NHI-04 — Least Privilege and Access Scope | Dormant identities often keep unnecessary privilege after migration. | |
| Recommendation — Inventory all machine identities before retiring dormant credentials. Assign an owner and retirement date to every surviving NHI. Reduce residual access to the minimum scope needed for each NHI. | ||
| CIS Controls v8 | 5 — Account Management | Reducing dormant identities depends on account review and removal discipline. |
| 6 — Access Control Management | Migration cleanup requires removing excess access and preserving only needed use. | |
| 8 — Audit Log Management | Use logs to confirm whether an identity is truly dormant before deletion. | |
| Recommendation — Review and disable unused accounts on a recurring schedule. Remove access that is no longer required for current business functions. Retain logs that prove whether a credential is still in active use. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | Dormant NHIs are an identity governance and access control issue. |
| DE.CM — Continuous Monitoring | Dormant identities require monitoring to detect residual or unexpected use. | |
| GV.OC — Organizational Context | Migration cleanup needs clear ownership and business justification for identities. | |
| Recommendation — Reassess identity lifecycle controls so only required access remains active. Monitor non-human access for unexpected activity before revoking it. Tie each remaining identity to a business function and accountable owner. | ||
Practitioner Guidance
What to prioritise: Start with identities that can still reach production data, cloud control planes, or cross-environment automation. Those are the ones where dormancy is most likely to turn into material exposure, and they should be reviewed before lower-impact internal utility accounts.
Decision rule: If the business owner cannot explain why the identity must remain active during migration, treat it as a retirement candidate. If the owner can explain it, require a specific end date or revalidation point rather than accepting open-ended retention.
What to verify: Confirm actual use through logs, dependency checks, and workload ownership, not just account age. An identity that has not authenticated recently may still be embedded in code, scheduled jobs, or third-party integrations, so deletion decisions should be based on dependency evidence, not assumptions.
Practitioner takeaway: The goal is not to delete every old credential immediately; it is to ensure that any identity kept alive for migration has a named owner, a current dependency, and a short path to retirement.
