They often preserve the same workflows, trust boundaries, and administrative silos in a new hosting model. That means the organisation inherits the old complexity without eliminating the access friction or visibility gaps. A true modernization effort changes the operating model, not just the deployment location.
Why This Matters for Security Teams
Lift-and-shift cloud migrations often preserve the same identity assumptions that were already fragile on-premises: long-lived credentials, broad admin groups, and hand-built exceptions. The result is a cloud tenant that looks modern but still behaves like a legacy datacenter. NHI Management Group research shows how dangerous that is in practice: only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges in the environments studied in the Ultimate Guide to NHIs.
The mistake is not cloud adoption itself. The mistake is treating identity as a liftable asset instead of a control plane that must be redesigned for elastic infrastructure, ephemeral workloads, and delegated administration. That is why cloud programs often inherit old trust boundaries while expanding blast radius. Current guidance in the NIST Cybersecurity Framework 2.0 pushes organisations toward governed access, continuous monitoring, and risk-informed control selection rather than simply moving accounts to a new platform.
In practice, many security teams discover the identity problem only after a migration exposes dormant privileges, hidden service accounts, or a breach driven by credentials nobody had reviewed in years.
How It Works in Practice
A successful cloud identity redesign starts by separating human identity, machine identity, and administrative authority. On-premises directory habits often blur those distinctions, but cloud control planes reward precision. Teams should inventory every privileged account, API key, certificate, workload identity, and cross-account trust path, then decide which ones should exist at all. NHI Management Group’s Top 10 NHI Issues highlights a common failure mode: organisations keep legacy secrets alive because they are embedded in code, CI/CD, or automation scripts rather than centrally managed.
The practical pattern is to replace static credentials with ephemeral, workload-bound access where possible. That means short-lived tokens, just-in-time elevation, and workload identity that proves what the workload is rather than where it runs. Cloud-native identity should be evaluated at request time, with policy attached to the action and context, not just to a group membership created months earlier. For mature teams, that usually means moving toward least privilege, conditional access, and continuous verification under a Zero Trust model.
- Use workload identity for services and automation instead of shared secrets.
- Remove human admin paths from routine machine-to-machine operations.
- Map every legacy group to a cloud-native role, then delete unused entitlements.
- Rotate and revoke credentials automatically, especially after migration cutovers.
This aligns with the intent of the NIST Cybersecurity Framework 2.0 and the identity hygiene lessons surfaced across real-world compromises in the 52 NHI Breaches Analysis. These controls tend to break down in hybrid environments where legacy directories, cloud IAM, and CI/CD automation all grant access independently because no single team owns the full entitlement chain.
Common Variations and Edge Cases
Tighter cloud identity controls often increase operational overhead, requiring organisations to balance migration speed against the cost of redesigning workflows and approvals. That tradeoff is real, especially during phased migrations where old and new platforms must coexist. Current guidance suggests avoiding a hard cutover from legacy IAM to cloud IAM when critical apps still depend on static service accounts or shared credentials, because those dependencies can stall adoption if removed too early.
One common edge case is application modernisation without workload modernisation. A team may move a VM to the cloud but keep the same embedded secrets, same local admin model, and same backup account structure. Another is multi-account or multi-subscription sprawl, where identity governance fragments across platform teams and makes visibility worse than it was on-premises. NHI Management Group has shown that a large share of organisations still rely heavily on static credentials, even as cloud attack paths become more automated and less predictable, which makes “cloud-first” identity posture more of an aspiration than a control state.
There is no universal standard for every environment, but the consistent pattern is clear: if the cloud migration preserves old trust relationships, it also preserves old compromise paths. The identity model should be redesigned around the workload, the action, and the minimum time needed for access, not around the historical shape of the data centre.
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 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Cloud lift-and-shift often preserves weak NHI inventory and ownership. |
| NIST CSF 2.0 | PR.AC-4 | Migration failures often come from excessive, poorly governed access. |
| NIST Zero Trust (SP 800-207) | SC-4 | Lift-and-shift keeps old trust boundaries that Zero Trust is meant to remove. |
Inventory every service account, key, and certificate before migration and assign a clear owner.
Related resources from NHI Mgmt Group
- What do security teams get wrong about workload identity in cloud and CI/CD environments?
- What do teams get wrong when they treat identity verification as a one-time compliance task?
- What do IAM teams get wrong about AI and API security boundaries?
- What do security teams get wrong about role-based access control in SaaS products?
