Insurance transformation is forcing legacy system replacement

At a glance

What this is: This is a Comarch commentary arguing that insurance transformation is no longer optional and that legacy systems, fragmented data, and overlay fixes are failing to keep pace.

Why it matters: It matters to IAM practitioners because large transformation programmes often expose identity, access, data, and integration gaps long before the business case is complete.

By the numbers:

• highly digital insurance agencies develop on average 70% faster than other agencies.

👉 Read Comarch's analysis of insurance transformation and legacy system replacement

Context

Insurance transformation is the shift from fragmented, legacy operating models to a more flexible digital environment. In this article, Comarch argues that the pressure to change has already arrived through digitised sales, customer self-service, cost reduction demands, and regulatory expectations.

For identity teams, the important question is not whether the business will modernise, but whether the supporting controls for access, integration, and data flow will be redesigned at the same pace. When insurers keep layering new services over old systems, identity governance, privilege management, and API trust usually become more brittle, not less.

That is why transformation programmes in regulated sectors often become identity programmes in practice, even when they are not framed that way at the start. The starting position described here is common rather than exceptional.

Key questions

Q: How should insurers govern access when replacing legacy systems with digital platforms?

A: They should tie every system replacement to an access review of the old and new estates. Legacy entitlements, service accounts, and integration permissions often survive migration unless they are explicitly retired. The safest approach is to define ownership, approval paths, and offboarding for each replaced capability before the cutover is complete.

Q: Why do overlay fixes create more security risk in transformation programmes?

A: Overlay fixes preserve old control assumptions while adding new interfaces, which makes it harder to know where access begins and ends. That increases entitlement sprawl, complicates audits, and leaves organisations with multiple places to enforce or miss policy. In practice, the longer overlays remain, the more governance debt accumulates.

Q: How can teams tell whether transformation is actually improving governance?

A: They should look for fewer unmanaged integrations, clearer system ownership, shorter access approval chains, and the ability to remove obsolete privileges as systems are retired. If a transformation only adds new channels without reducing control complexity, governance has not improved even if the user experience has.

Q: Who should own identity and access controls in a business transformation programme?

A: Ownership should sit with the programme, not only with security. Business leaders define the operating model, application teams implement the integrations, and IAM or PAM teams define control standards and review them. Without shared ownership, identity decisions become fragmented and controls lag behind the transformation schedule.

Technical breakdown

Why overlay transformations fail in legacy insurance estates

Overlay programmes add interfaces, adapters, and point fixes on top of systems that were never designed for modern digital workflows. That can deliver short-term progress, but it also multiplies integration paths, increases failure points, and makes governance harder because each layer introduces its own access, data, and support boundaries. In insurance, where customer servicing, underwriting, claims, and partner exchange all intersect, the resulting architecture becomes difficult to audit and even harder to change safely.

Practical implication: map every overlay dependency to an owner, an access model, and an offboarding path before extending the estate further.

Structured APIs and data models as transformation control points

The article points to structured data models and precisely described APIs as the mechanism that lets data move correctly through complicated architectures. That is not just an engineering preference. It is an identity and governance control point because every API becomes a trust boundary, every integration needs authentication and authorisation rules, and every data object needs a clear source of truth. Without that structure, insurers may digitise the front end while preserving fragmented control in the back end.

Practical implication: treat API inventory, entitlement scope, and service-to-service authentication as part of the transformation plan, not separate remediation work.

Cloud adoption changes the governance model, not only the infrastructure

Comarch frames cloud adoption as a range of deployment possibilities across public cloud providers such as AWS and Azure. For insurers, the technical issue is less where workloads run and more how identity, segmentation, and partner connectivity are governed across environments. When transformation expands into cloud and ecosystem integration, standing access, inconsistent policy enforcement, and poor lifecycle control become more visible. The architecture can scale faster, but only if the control model scales with it.

Practical implication: align cloud migration work with IAM, PAM, and lifecycle governance so new environments do not inherit old access debt.

NHI Mgmt Group analysis

Insurance transformation is an identity governance problem as much as an IT problem. The article describes digital change through customer service, APIs, cloud, and operational efficiency, but each of those shifts changes who or what is allowed to act inside the environment. Once that happens, access scope, approval flow, and accountability become programme-level risks rather than back-office details. Practitioners should treat transformation governance as identity governance with business consequences.

Overlay fixes create identity debt, not just technical debt. Ad hoc additions may appear to improve speed, but they also preserve old privilege models while adding new control surfaces. That is how insurers end up with duplicated entitlements, unclear system ownership, and inconsistent offboarding across platforms. The practical conclusion is that transformation work must remove obsolete access paths, not simply hide them behind new interfaces.

Structured APIs are the foundation of transformation governance, not an integration afterthought. Precisely described APIs determine whether insurers can enforce reliable authentication, authorisation, and data lineage across systems and partners. When API contracts are vague, every downstream control becomes weaker because the organisation no longer knows what is being requested, by whom, and under what entitlement. Practitioners should treat API governance as part of the identity model from day one.

Cloud expansion only improves resilience when control boundaries are redesigned with it. Moving to AWS, Azure, or similar environments does not solve fragmentation by itself. It often widens the gap between rapid business change and slow governance unless lifecycle processes, privileged access, and service identity management are rebuilt around the new operating model. Security teams should expect transformation to expose old entitlement assumptions rather than erase them.

Flexibility is the business outcome, but governed access is the mechanism that makes it sustainable. The article’s emphasis on modular products and faster change points to a future where insurers need to reconfigure services continuously. That is only safe when identity, integration, and data policies can change without creating untracked privilege or uncontrolled partner access. Practitioners should plan for transformation to increase governance demand, not reduce it.

From our research:

• highly digital insurance agencies develop on average 70% faster than other agencies, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• For the lifecycle angle, read Ultimate Guide to NHIs - Lifecycle Processes for Managing NHIs for a deeper look at provisioning, rotation, and offboarding.

What this signals

Transformation programmes will keep exposing the same pattern: business teams want speed, but identity teams inherit the control debt created by years of overlays and exception handling. The practical signal is that access simplification has to be scheduled alongside system modernisation, not after it.

Identity debt: legacy entitlements, duplicated approvals, and orphaned integration access accumulate whenever new channels are added without removing the old ones. That means insurers need to measure not only delivery velocity, but also how quickly they can retire obsolete privileges and integration paths.

As insurers move more services into cloud and partner ecosystems, the governing question becomes whether access boundaries can be redefined as quickly as products are reconfigured. If not, the modernised front end will sit on top of the same fragile control model, just with more places to fail.

For practitioners

• Map legacy overlays to identity ownership Inventory every overlay, plugin, and integration layer, then assign a business owner, technical owner, and access lifecycle path for each one. If an overlay cannot be clearly governed, it should not become the foundation for the next transformation phase.
• Treat API design as governance design Require each exposed API to have documented authentication, authorisation, and data-scope rules before it is put into production. This prevents transformation teams from creating digital channels that function technically but cannot be governed consistently.
• Align cloud migration with privilege cleanup Do not move workloads into cloud platforms without removing obsolete accounts, shared admin paths, and environment-specific exceptions in the source estate. Transformation should reduce the number of standing access paths, not preserve them in a new location.
• Build modular product change around lifecycle controls If policy components can be activated and deactivated, the access model must support the same pace of change. Tie configuration, approvals, and entitlement updates together so product flexibility does not create hidden privilege drift.

Key takeaways

• Insurance transformation succeeds or fails on whether old control models are actually retired, not merely wrapped in new tooling.
• Legacy overlays and fragmented APIs increase governance complexity, which makes access ownership and entitlement cleanup central to delivery.
• Programmes that link modernisation to identity, API, and lifecycle controls are better positioned to turn digitisation into durable operating flexibility.

Key terms

• Digital Transformation Overlay: An overlay is a layer added on top of an existing system to extend capability without fully replacing the underlying platform. In identity terms, overlays often preserve old access patterns while introducing new integration points, which makes governance more complex and retirement of legacy privileges harder.
• Identity Debt: Identity debt is the accumulation of unmanaged entitlements, duplicate access paths, and outdated approval flows created when systems evolve faster than governance. It is the access-layer equivalent of technical debt, and it usually shows up when modernisation adds channels without removing old ones.
• API Trust Boundary: An API trust boundary is the point where one system must authenticate, authorise, and exchange data with another. When transformation depends on APIs, this boundary becomes a governance control point because weak contracts, unclear ownership, or inconsistent permissions can undermine the whole operating model.

What's in the full article

Comarch's full article covers the operational detail this post intentionally leaves for the source:

• Examples of how insurers sequence transformation from legacy process analysis to implementation planning
• The business cases behind modular insurance products and policy component activation
• Details on cloud adaptation choices across public platforms and ecosystem expansion
• A concrete transformation example showing policy amendment time reduced from nearly two weeks to 15 minutes

👉 Comarch's full article covers the insurance modernisation examples, efficiency claims, and transformation context behind the argument.

Deepen your knowledge

NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.