Legacy privileges keep working after the environment has changed, so the old platform can remain an active entry point even when workloads have moved. That creates audit gaps, unwanted trust paths, and unclear accountability for changes. Migration should always include removal of obsolete access, not just workload relocation.
Why This Matters for Security Teams
When migration leaves old admin access in place, the security problem is not just duplication. The legacy path can stay fully trusted after the workload has moved, which means the retired platform may still accept changes, expose secrets, or allow privilege reuse. NHI governance breaks down here because access is often tracked by system, not by identity lifecycle or real operational need.
That is why NHI Management Group consistently treats offboarding as part of migration, not a separate cleanup task. In the Ultimate Guide to NHIs, the evidence shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and 71% of NHIs are not rotated within recommended time frames. The issue is not abstract. It is a live control failure that keeps stale admin paths available long after change windows close.
Standards guidance aligns with that concern. The OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls both emphasise least privilege, lifecycle control, and timely revocation. In practice, many security teams discover the old path only after a post-migration incident, rather than through intentional decommissioning.
How It Works in Practice
The practical failure mode is simple: the new environment goes live, but the old admin account, service principal, API key, or break-glass credential still has a valid trust relationship. If the legacy system is not fully decommissioned, that access can continue to authenticate, authorize, or call back into connected services. In migration programs, this often happens because teams validate workload cutover without validating identity cutover.
Security teams should treat migration as an identity lifecycle event. The control sequence should include:
- Inventory every non-human identity tied to the old platform, including admin accounts, service accounts, tokens, certificates, and automation keys.
- Map where each identity is used, then confirm whether the old platform still has network, IAM, or privileged tool access.
- Revoke or disable obsolete privileges before or at cutover, not weeks later.
- Rotate secrets that may have been exposed to the retired environment and invalidate any cached tokens.
- Verify that logging, ownership, and alerting follow the identity after migration, not the server name.
This is where the 52 NHI Breaches Analysis is useful: repeated compromise patterns show that attackers do not need a new foothold when an old admin path is still trusted. The point is reinforced by the Ultimate Guide to NHIs — Key Challenges and Risks, which highlights how excessive privilege and weak visibility combine into durable exposure.
These controls tend to break down when migration spans multiple clouds, shared CI/CD pipelines, or third-party integrations because no single team owns the full trust chain.
Common Variations and Edge Cases
Tighter migration controls often increase operational overhead, requiring organisations to balance rapid cutover against the risk of leaving a dormant admin path behind. There is no universal standard for every environment yet, but current guidance suggests the same principle: if the old access is still functional, the migration is not complete from a security perspective.
Edge cases usually involve shared services and emergency access. A legacy admin credential may appear harmless because it is only used for rollback, vendor support, or disaster recovery. That is exactly where governance gets sloppy. Best practice is to document explicit expiry conditions, require owner approval for any retained access, and place time limits on every exception. For sensitive transitions, short-lived credentials and just-in-time access are preferable to standing admin rights.
In regulated environments, the accountability issue becomes even sharper. If an obsolete admin path can still modify records, move data, or alter audit settings, then the organisation may have an unreviewed privilege path that outlives the migration itself. The Microsoft SAS Key Breach shows why persistent token access matters, while NIST-style control families expect privileged access to be both minimized and revocable. Migration teams should therefore include a post-cutover verification step that proves old admin access no longer works, rather than assuming decommissioning succeeded.
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 NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Old admin access is a lifecycle and revocation failure for non-human identities. |
| NIST CSF 2.0 | PR.AC-4 | Migration leftovers violate least privilege and access enforcement expectations. |
| NIST SP 800-53 Rev 5 | AC-2 | Account management requires timely removal of inactive or obsolete privileged accounts. |
| NIST Zero Trust (SP 800-207) | AC-6 | Zero Trust requires continuously minimizing trust, including post-migration admin paths. |
| NIST AI RMF | AI RMF supports governance and accountability for automated migration and admin workflows. |
Revalidate privileged access after migration and remove any obsolete entitlements immediately.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
