What should identity teams verify before moving an insurer to cloud deployment?

Why This Matters for Security Teams

Cloud deployment is often the first realistic chance to reset identity assumptions before legacy access patterns become permanent again. For insurers, that matters because operational workloads, integration accounts, and administrative access tend to get mixed during migration, then persist long after the original business process changes. NHI Management Group research shows how often that gap remains hidden: The 2024 Non-Human Identity Security Report found that 88.5% of organisations say their non-human IAM practices lag behind or only match human IAM.

The practical risk is not just excess privilege. It is inherited trust that no one can clearly justify, especially when a credential was created for a legacy platform, copied into the cloud, and never re-attested. Identity teams should verify the business purpose of each non-human identity, who owns it, what system it serves, and whether it still needs to exist. That aligns with the zero trust direction in NIST SP 800-207 Zero Trust Architecture, where access must be continuously justified rather than presumed from network location or history. In practice, many security teams encounter credential sprawl only after a cloud cutover has already inherited the old estate.

How It Works in Practice

Before the insurer moves, identity teams should perform a pre-cutover inventory that separates operational identities from administrator identities, then maps each one to a named business or technical owner. The goal is to confirm whether the identity supports a workflow, a service integration, or a human operator function. If the answer is unclear, the identity is a migration risk, not a migration asset.

A practical review usually includes three checks:

• Confirm the identity is tied to a documented workload, application, or batch process.
• Verify the minimum permissions needed in the target cloud, not the broad permissions used on-premises.
• Remove credentials that only exist because they were needed by a legacy dependency, especially if the dependency is being retired.

This is also the right point to review whether static secrets are being carried into the cloud when ephemeral credentials would be more appropriate. NHIMG’s Ultimate Guide to NHIs frames the core issue clearly: non-human identities are valuable because they enable automation, but that same automation amplifies the damage when access is overbroad or poorly owned. For migration planning, the security baseline should be: no unowned identity, no unexplained secret, and no access path that lacks a current business purpose.

Teams should also validate the control model against the target cloud’s actual operating pattern. If the application uses CI/CD, scheduled jobs, service-to-service calls, or third-party claims exchange, the identity design should follow that flow instead of forcing a human-style login model onto a workload. The insurer’s cloud landing zone should only accept identities that can be traced to an approved use case, an owner, and a documented expiry or rotation process. These controls tend to break down when large estates are migrated in bulk because migration velocity outruns identity rationalisation.

Common Variations and Edge Cases

Tighter identity cleanup often increases migration effort, requiring organisations to balance speed against the operational cost of discovering every hidden dependency. That tradeoff is unavoidable in insurer environments with older policy platforms, external claims processors, or vendor-managed integrations.

Some identities will not fit a simple “remove or keep” decision. Shared service accounts, break-glass access, and regulated vendor connections may need to remain temporarily, but current guidance suggests they should be treated as exceptions with explicit expiry, logging, and review. In parallel, identity teams should watch for systems that appear administrative but actually perform production tasks, because those accounts are often over-permissioned and misclassified during migration.

This is where the evidence from NHIMG becomes useful. The Top 10 NHI Issues and the 52 NHI Breaches Analysis both reinforce a consistent pattern: the identity that causes trouble is rarely the one security teams remember creating. It is the one that stayed behind after the business need disappeared. For insurers, the safest cloud move is not a lift-and-shift of every credential, but a deliberate revalidation of which identities still deserve to exist at all.

Related resources from NHI Mgmt Group

• How should banks strengthen Active Directory security without moving to cloud identity?
• How should security teams protect legacy RD Web access without moving to a cloud IdP?
• How should security teams improve correlation across identity, endpoint, and cloud telemetry?
• How should teams secure non-human identities across cloud and SaaS?