Should insurers re-evaluate IAM governance before or after modular transformation?

Why the governance decision belongs before the platform cutover

Modular transformation usually increases the number of components, integration paths, and parties that can create or approve access. That is why IAM governance has to be set before the legacy platform is retired, not after, because the new estate will inherit whatever ownership gaps already exist and distribute them more widely.

Identity ownership is not just a policy question. It determines who can approve provisioning, who can recertify access, who can revoke stale entitlements, and who is accountable when a service account or integration still works after the old platform is gone. NHIMG’s Identity Security Programme Guide and the IAM and Identity Provider Buyer's Guide both reinforce that programme ownership and platform selection only work when the operating model is already clear.

In practice, the sequence matters because modular delivery tends to fragment responsibilities across product teams, platform teams, and vendors. If those boundaries are not explicit up front, access requests, exception handling, and revocation decisions become inconsistent across modules, which makes governance weaker just as the environment becomes more distributed.

What changes when transformation multiplies identities and integrations

As modular architectures spread, the number of identities typically grows faster than the number of people who understand them. That includes human admin roles, service accounts, workload identities, API credentials, and cross-environment trust relationships. A governance model that worked in a monolith can fail in a modular estate because each new module adds another place where approval, review, and offboarding can drift.

The practical control change is that ownership must move from an implicit platform assumption to an explicit operating rule. The relevant question is no longer only “who has access?” but also “who is responsible for proving this access still belongs here, across every module, every dependency, and every change window?” That is why lifecycle, recertification, and decommissioning need to be decided before migration begins, not left to post-cutover cleanup.

NHIMG’s NHI Lifecycle Management Guide and Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs are useful here because they show the same lifecycle problem across provisioning, rotation, offboarding, and recertification. Even though the transformation question is broader than NHI alone, the lifecycle lesson is the same: unmanaged identity growth creates unmanaged operational risk.

For cloud and hybrid estates, the same governance gap appears in workload and machine access. Cloud Workload Identity Guide is a useful reference when modular change introduces keyless trust, federated access, or temporary credentials, because the governance decision has to include how those identities are created, reviewed, and retired.

How insurers should sequence ownership, review, and decommissioning

The safest sequence is to define ownership before decommissioning the old platform, then prove the operating model on a limited module set before scaling it. That gives teams a chance to test approval paths, recertification cadence, and offboarding responsibility while the legacy system still provides a fallback for reconciliation and exception handling.

What to verify: Confirm there is a named owner for approval, a separate owner for periodic recertification, and a clear party accountable for revocation when a module or integration is retired. If those roles are shared informally today, treat that as a migration blocker rather than an administrative detail.

Decision rule: If an identity can outlive the module that created it, then ownership must be established before the module goes live. If a team cannot explain who approves, reviews, and removes access for that identity, the transformation is not ready for scale.

What to measure: Track orphaned identities, overdue reviews, and offboarding lag across every module. Those three signals usually show whether governance is keeping pace with architectural fragmentation or merely being documented after the fact.

NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs, Regulatory and Audit Perspectives are relevant because they tie governance failures to auditability, access review, and offboarding discipline. For insurers, that matters because transformation programmes often move faster than control ownership, and the backlog becomes visible only when audit, incident response, or production support asks who owns a stale identity.

Risk and Threat Considerations

When IAM governance is deferred until after modular transformation, the main risk is not just administrative confusion. It is that stale privileges, unowned accounts, and weak recertification spread into multiple modules, making compromise or misuse harder to spot and harder to unwind.

Failure mechanism: Legacy ambiguity gets cloned into each new component, so the organisation accumulates identities that still authenticate or retain access even after the business owner, technical owner, or onboarding context has changed.

Impact: That increases the blast radius of a compromise, slows offboarding, weakens audit evidence, and can leave insurers with inconsistent access decisions across product lines, environments, and third parties.

Practitioner Guidance

What to prioritise: Lock down ownership for approval, recertification, and offboarding before the first legacy component is retired. If the transformation plan cannot name those owners, it should not progress to broad migration.

Common mistake: Treating IAM governance as a post-migration cleanup task. In modular programmes, that shortcut almost always becomes a permanent control gap because every new module creates one more place for ambiguity to persist.

What good looks like: Every identity has a named business or technical owner, a review cadence, and a documented retirement path that still works when the source system disappears.

Practitioner takeaway: The right order is to govern identities first, then modernise the platform. If ownership is still unclear at cutover, the transformation is scaling uncertainty rather than control.

Related resources from NHI Mgmt Group

• Should IAM teams re-evaluate browser governance before rolling out autonomous agents?
• What is the difference between human IAM controls and NHI governance?
• What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?
• Should IAM teams re-evaluate their NHI tooling choices after a major acquisition?