How should insurers govern access during large core-system modernisation projects?

Why This Matters for Security Teams

Large core-system modernisation programs reshape who and what can touch policy, claims, billing, and customer data. In insurance, that usually means temporary project accounts, integration tokens, vendor service identities, and migration tooling all expanding at once. If access governance is treated as an afterthought, these short-term pathways become persistent exposure points long after cutover.

That is why the issue is not just identity provisioning, but lifecycle control. The Ultimate Guide to NHIs shows how unmanaged non-human identities quickly outgrow human access processes, while the NIST Cybersecurity Framework 2.0 emphasises governance, asset visibility, and continuous risk management as operational disciplines rather than one-time checks.

Security teams often underestimate how many project permissions are being created across migration factories, test environments, middleware bridges, and data conversion utilities. In practice, many insurers discover standing access only after the program has moved into steady state and no one can confidently name who still has it.

How It Works in Practice

Insurers should govern modernisation access as a time-bound control plane with explicit ownership, narrow scope, and automated retirement. Every project identity, whether human, service account, API key, or vendor credential, should map to a named business owner and a technical owner. That owner is accountable for the approved use case, the data domains involved, and the date or event that ends access.

Best practice is to treat access requests as temporary authorisations tied to delivery milestones. That means defining the system, environment, and transaction types the identity can reach, then enforcing expiry by default. Where possible, project access should be issued through privileged access management, secrets managers, or just-in-time workflows so credentials are short-lived and automatically revoked when the task completes. The OWASP Non-Human Identity Top 10 is useful here because it frames excessive privilege, secret sprawl, and weak lifecycle control as recurring failure modes rather than isolated mistakes.

• Use a single inventory for all project identities, integrations, and migration accounts.
• Assign an entitlement owner and an offboarding trigger at creation time.
• Separate test, migration, and production access so temporary broad access does not cross environments.
• Rotate credentials on a short schedule and revoke them automatically when the project stage changes.
• Review access after each release train, not only at the end of the program.

This aligns closely with the lifecycle discipline in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, which stresses that creation, use, rotation, and offboarding must all be controlled. These controls tend to break down when multiple system integrators, cloud platforms, and legacy mainframe bridges share one migration timeline because ownership becomes fragmented and no single team can revoke access with confidence.

Common Variations and Edge Cases

Tighter access control often increases delivery overhead, requiring insurers to balance transformation speed against auditability and operational safety. That tradeoff is real during core modernisation because data migrations, parallel runs, and temporary vendor support can create legitimate bursts of access demand.

Current guidance suggests handling those bursts with explicit exception management rather than informal approvals. For example, a vendor may need elevated access during cutover weekend, but that access should be pre-approved, time-boxed, logged, and tied to a named rollback plan. The same discipline applies to cloud-native components and mainframe wrappers: if an integration requires broad access to complete a migration task, the access should be split into the smallest feasible set of scopes and retired immediately after validation.

Insurers also need to watch for indirect access paths. A migration tool, CI/CD pipeline, or data replication job may not look privileged in a ticket, but it can still move laterally across records, environments, and trust boundaries. The 52 NHI Breaches Analysis and the Ultimate Guide to NHIs — Regulatory and Audit Perspectives both reinforce that offboarding evidence matters as much as provisioning evidence when auditors assess control effectiveness.

There is no universal standard for exactly how much temporary access is acceptable in every modernisation program. The practical test is whether the organisation can prove who approved it, what it could do, when it expired, and how it was revoked. If that answer depends on tribal knowledge, the project has already outgrown its access governance.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• How should retail organisations govern access across stores, devices, and POS systems?
• How should organisations govern privileged access in sovereign infrastructure programmes?