How should insurers govern identity during legacy platform modernization?

Why This Matters for Security Teams

Legacy platform modernization is often presented as a technology refresh, but for insurers it is also an identity transition with direct loss, fraud, and compliance implications. Old policy admin systems, claims platforms, and batch integrations often carry service accounts, embedded keys, and operator entitlements that were never designed for auditability. If those identities are not discovered early, they can survive the migration and quietly reconnect to the modern stack.

The risk is not limited to what is visible in the target platform. Hidden dependencies inside scripts, middleware, and third-party integrations can preserve access long after a business owner believes the old system is retired. NHI Mgmt Group’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which explains why modernization projects so often inherit unknown access paths.

For insurers, that matters because claims data, underwriting systems, and payment workflows are high-value targets, and legacy identity sprawl can defeat even a well-executed infrastructure migration. Current guidance from NIST Cybersecurity Framework 2.0 still applies here: asset and identity visibility must precede control enforcement. In practice, many security teams encounter unauthorized access only after the old platform is already decommissioned, rather than through intentional identity retirement.

How It Works in Practice

The safest approach is to treat every modernization wave as an identity inventory and remediation program. Before cutover, insurers should build a complete map of non-human identities, including service accounts, API keys, batch jobs, certificates, privileged operator accounts, and external partner connections. That inventory should identify owner, purpose, system dependency, privilege scope, rotation cadence, and retirement date. The goal is not just documentation. It is to make every identity accountable and removable.

In practice, that means establishing a migration checkpoint where no workload moves until its identity dependencies are classified. High-risk identities should be moved first into centrally managed secrets and workload identity systems, while low-value or unused identities are revoked. Where possible, replace static credentials with workload-bound identities and short-lived tokens, so the modern platform does not inherit long-term secrets. The Lifecycle Processes for Managing NHIs guidance is especially relevant here because modernization should include offboarding, not just onboarding.

Security teams should also validate how the new stack authenticates to downstream systems. A common failure mode is migrating the application but preserving the same broad privileges, which recreates the legacy risk in a cleaner interface. Best practice is evolving toward least privilege, time-bound access, and explicit ownership, with control checks aligned to CISA Zero Trust guidance. This reduces the chance that a forgotten key or orphaned integration becomes the easiest path into the modernized environment. Modernization programs that skip this step often create a new platform that is technically current but still anchored to old trust assumptions, and those controls tend to break down when batch windows, vendor bridges, and mainframe-to-cloud interfaces remain active because credentials are reused across both environments.

Common Variations and Edge Cases

Tighter identity control often increases migration overhead, requiring organisations to balance delivery speed against the risk of breaking critical policy, claims, or billing workflows. In insurance environments, that tradeoff is real because some legacy interfaces are poorly documented and only exercised during month-end, catastrophe response, or regulatory reporting.

One edge case is a phased modernization where the old and new platforms run in parallel for months. In that scenario, there is no universal standard for whether credentials should be duplicated, brokered, or replaced immediately, but current guidance suggests avoiding duplicated standing access wherever possible. Another common exception is third-party administrator connectivity, where the insurer may not fully control the partner’s identity hygiene. Those connections should be contractually bounded, logged, and revalidated during each migration milestone.

Insurers should also watch for “temporary” migration accounts that never get removed. NHI Mgmt Group’s Top 10 NHI Issues and 52 NHI Breaches Analysis both reinforce the same operational lesson: modernization failures often come from identities that were meant to be temporary, but were never revoked. The practical control is simple to state and hard to execute consistently, which is why identity retirement must be tracked as a workstream, not left as a post-migration cleanup task.

Related resources from NHI Mgmt Group

• How should insurers govern access during large core-system modernisation projects?
• How should security teams evaluate a rebranded identity platform after an acquisition?
• When does an all-in-one identity platform create more risk than it removes?
• How should security teams govern authentication in hybrid Active Directory and cloud identity environments?