Subscribe to the Non-Human & AI Identity Journal

How should organisations govern access during cloud migration?

Organisations should design access governance before migration cutover, not after systems move. That means defining target roles, segregation of duties, approval flows, and deprovisioning ownership as part of the transformation plan. If controls are added later, teams inherit stale privileges, inconsistent reviews, and audit gaps that are harder and more expensive to fix.

Why This Matters for Security Teams

Cloud migration changes access patterns before it changes technology. During cutover, organisations often preserve old entitlements to avoid disrupting delivery, but those temporary decisions become the new baseline. That is where stale permissions, orphaned service accounts, and overlapping admin roles emerge. NHI Management Group’s Ultimate Guide to NHIs treats lifecycle governance as a first-order control, not a cleanup task, because migration creates both human and non-human identity risk.

The challenge is not just adding controls later. It is that migration programs tend to move fast across cloud, SaaS, and platform layers, which makes access ownership unclear and review cadence inconsistent. Current guidance from the NIST Cybersecurity Framework 2.0 emphasizes governance, least privilege, and ongoing oversight, but those principles only work if they are translated into migration design decisions early. NHI Management Group notes that 88.5% of organisations say their non-human IAM practices lag behind or only match human IAM, which is a warning sign during cloud transition.

In practice, many security teams encounter access sprawl only after the first audit exception, not through intentional design of the migration program.

How It Works in Practice

Access governance during cloud migration should be built around the future-state operating model, not the source environment. That means defining target roles, approval paths, and deprovisioning ownership before workloads move. The question to answer is not simply who can log in, but who can do what, in which environment, under which conditions, and for how long. The OWASP Non-Human Identity Top 10 is useful here because migration frequently exposes weak secrets handling, excessive privilege, and missing lifecycle controls for service identities.

A practical migration control set usually includes:

  • Target-state RBAC or ABAC definitions mapped to cloud-native services before cutover.
  • Time-bound exception handling for legacy access, with named business owners and expiry dates.
  • Separate approval flows for human users, service accounts, and automation identities.
  • Inventory reconciliation to identify duplicate admins, dormant credentials, and unmanaged secrets.
  • Post-migration recertification focused on actual usage, not inherited entitlement history.

This is especially important for NHIs because secrets and workload identities often move through migration pipelines faster than human accounts do. NHI Management Group’s Lifecycle Processes for Managing NHIs is relevant because it frames creation, rotation, review, and revocation as a continuous process, which is exactly what migration disrupts if ownership is unclear. Organisations with hybrid estates should also treat cloud landing zones as policy enforcement points, not merely technical destinations.

These controls tend to break down when migration spans multiple clouds and the source estate has no reliable identity inventory because entitlement mapping becomes ambiguous and exceptions multiply faster than reviews.

Common Variations and Edge Cases

Tighter access governance often increases delivery overhead, requiring organisations to balance migration speed against control fidelity. That tradeoff becomes sharper when legacy applications cannot support modern identity federation or when shared admin accounts are embedded in operational processes. In those cases, current guidance suggests using temporary compensating controls rather than pretending the legacy model is acceptable indefinitely.

One common edge case is the “lift and shift” program that keeps source permissions intact on day one. That may reduce disruption, but it also preserves old trust boundaries and delays entitlement cleanup. Another is multi-cloud migration, where different platforms enforce different identity and policy primitives. NHI Management Group’s Top 10 NHI Issues highlights that inconsistent access management across environments is a recurring operational risk, not a one-time implementation flaw.

For regulated environments, migration governance should align with NIST Cybersecurity Framework 2.0 functions for governance and protection, while recognising that there is no universal standard for entitlement design during cloud cutover. Best practice is evolving toward shorter-lived access, explicit ownership, and more frequent post-migration reviews rather than permanent exception paths.

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 AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 PR.AC-4 Least privilege and access governance are central to migration cutover decisions.
OWASP Non-Human Identity Top 10 NHI-03 Migration often leaves stale secrets and overbroad non-human access in place.
NIST AI RMF Governance of autonomous or automated access decisions needs accountable oversight.

Inventory non-human identities, rotate secrets, and revoke unused access before and after migration.