Prioritise the functions that can safely move first, then keep the control-sensitive parts where sovereignty, compliance, or resilience demand it. The right answer is often a phased hybrid design rather than a full migration or a permanent holdback. Decision-making should follow operational risk, not cloud ideology.
How to think about migration versus retention in IAM
Use a function-by-function lens, not a platform-by-platform one. IAM capabilities are not equally easy to move, because identity proofing, authentication, privileged access, policy enforcement, logging, and lifecycle governance have different blast radii. A phased hybrid model is usually safer than forcing a single answer across the entire stack.
The key question is whether moving a function changes who can authenticate, what can be authorised, or how quickly you can revoke access when something breaks. If the answer is yes, treat that function as control-sensitive and examine whether cloud delivery preserves governance, latency, auditability, and recovery.
For planning, separate user-facing convenience from control-plane sensitivity. Federation, SSO, and lower-risk directory services are often easier to migrate first, while highly privileged administration, break-glass paths, key custody, and tightly regulated workflows may need to remain anchored until equivalent control maturity exists. That is why internal capability assessment matters more than an abstract cloud target. A practical starting point is the IAM and Identity Provider Buyer’s Guide, which helps distinguish platform features from migration readiness.
Where cloud migration usually works first, and where retention still makes sense
Cloud migration usually works first for standardised identity services that benefit from elasticity, managed resilience, or easier integration, such as workforce SSO, directory synchronisation, and lower-risk lifecycle workflows. It is less attractive where the control objective depends on local sovereignty, strict segregation, custom approval chains, or rapid recovery from provider outage. The decision is less about whether the workload is “IAM” and more about whether the function is control-plane or convenience-plane.
Retention still makes sense when the identity function is itself a risk barrier. Privileged administration, access policy enforcement, credential custody, and high-assurance workflows are often kept closer to the systems they govern until there is clear evidence that the cloud version can match the same control depth. NHIMG’s Identity Security Programme Guide is useful here because it frames the operating model around ownership, governance, and roadmap choices rather than one-off migrations.
For machine and workload access, a hybrid pattern is often best because the decision hinges on whether temporary credentials, federation, and keyless access are actually available. When cloud-native IAM can remove static secrets and preserve least privilege, migration becomes easier to justify. Where long-lived keys or brittle trust chains remain, the operational burden may outweigh the platform benefit. The Cloud Workload Identity Guide is a strong reference point for those trade-offs.
What the decision should measure before you move anything
The right decision comes from measuring control parity, not from assuming cloud will be better. Compare the cloud option against on-prem or retained control on four dimensions: enforcement strength, evidence quality, recovery speed, and failure containment. If a cloud option weakens any of those materially, it should not be the first function to move.
Decision rule: if the migration removes a hard control, such as local approval, vault isolation, or emergency revocation authority, pause and redesign before you migrate. If the cloud version preserves the same control outcome with better operability, move that function first and keep the residual high-risk parts retained until their dependencies are also ready.
What to verify: confirm where authority actually lives, who can override it, how quickly credentials can be revoked, and whether logs are complete enough for audit and incident response. For governance-heavy decisions, the distinction between “cloud-hosted” and “cloud-controlled” matters more than the deployment label.
What practitioners underestimate: migration risk often comes from hidden dependencies, such as delegated admin paths, certificate services, secrets stores, and emergency break-glass accounts. Those components can turn a simple move into a control loss if they are not assessed as part of the same design.
Risk and Threat Considerations
Cloud migration can increase exposure if IAM functions are moved before privilege boundaries, logging, and revocation processes are ready. The most common failure mode is not a catastrophic cloud event, but a gradual loss of control, where permissions become harder to inspect, secrets live longer than intended, or administrative paths become more concentrated than they were on premises.
Failure mechanism: a poorly phased migration can create oversized trust relationships, duplicated roles, stale credentials, or weak isolation between environments. That makes it easier for compromise in one place to spread through identity paths, especially when privileged access or workload credentials are reused across systems.
Impact: the result is slower containment, weaker auditability, and a higher chance that a single access failure becomes a wider incident. In a hybrid model, the real goal is to move low-risk identity functions first while preserving strong control over the parts that protect privilege, secrets, and recovery.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | IAM migration changes how workforce identities authenticate and are governed. |
| IA-9 — Service Identification and Authentication | Workload and service identity decisions hinge on how non-human actors authenticate. | |
| AC-6 — Least Privilege | The migration choice should protect privileged access boundaries and limit blast radius. | |
| Recommendation — Preserve equivalent authentication assurance before moving workforce identity services. Retain or redesign service-to-service authentication so cloud migration does not weaken trust. Move only when least-privilege enforcement remains intact after migration. | ||
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | The question is directly about cloud IAM control placement and operating model. |
| Recommendation — Map each IAM function to cloud controls only when governance and enforcement stay equivalent. | ||
Practitioner Guidance
What to prioritise: move the identity functions with the lowest privilege and the clearest rollback path first, then keep high-impact control points where governance is strongest. In most programmes, that means separating user convenience services from privileged control functions instead of trying to migrate them together.
Implementation sequence: start with a control inventory, classify each IAM function by privilege, regulatory sensitivity, and dependency on local trust anchors, then decide whether the cloud version preserves equal or better control outcomes. Use that classification to build a phased roadmap rather than a binary migration plan.
Trade-off: cloud often improves standardisation and resilience, but it can also centralise failure if identity control, logging, or recovery are not designed carefully. The practical aim is not “cloud first” or “retain forever”, it is to place each IAM function where its risk can be governed best.
Practitioner takeaway: treat IAM migration as a control-assurance decision, not an infrastructure preference, and keep the most sensitive identity functions where you can still prove enforcement, revocation, and recovery.
Related resources from NHI Mgmt Group
- How should organisations decide whether to move IAM to cloud when they need both scale and control?
- How should security teams prioritise NHI remediation in cloud environments?
- How do IAM teams decide whether to use cloud-native identity or an external auth layer?
- How should organisations decide whether appsec, IAM, or platform teams own a control failure?