Before. If identity ownership is not defined up front, the transformation will inherit the old ambiguity and multiply it across more components, more parties, and more integration points. The right sequence is to establish approval, recertification, and offboarding ownership before decommissioning the legacy platform.
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.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Modular transformation hinges on identity ownership and access governance across cloud services. |
| Recommendation — Define IAM ownership, review cadence, and revocation paths before migrating modules. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Transformation changes how credentials and authenticators are issued, rotated, and retired. |
| AC-2 — Account Management | The question is about who owns account approval, recertification, and offboarding during change. | |
| Recommendation — Establish lifecycle controls for authenticators before decommissioning the legacy platform. Assign explicit account ownership and review responsibilities before cutover. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Identity ownership and governance must be defined before architecture changes fragment control. |
| A.5.18 — Access rights | Access rights must be reviewed and removed as systems are decomissioned and re-platformed. | |
| Recommendation — Document identity owners and approval authority before modular migration begins. Revalidate and remove access rights as part of the pre-cutover governance plan. | ||
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?