Legacy insurance modernisation and identity governance in regulated change

At a glance

What this is: This is an insurance transformation case study showing how P&V Group is replacing legacy systems with modular software to improve speed, service, and product flexibility.

Why it matters: It matters because large-scale modernization changes how access, integration, and governance must be managed across business users, brokers, employees, and third-party delivery partners.

By the numbers:

• P&V Group distributes the P&V and Vivium brands through a network of 170 exclusive P&V agencies and more than 1,000 brokerages.

👉 Read Comarch’s case study on P&V Group’s insurance modernisation programme

Context

Legacy insurance platforms often slow down product changes, create brittle integration points, and make identity governance harder to maintain as the operating model changes. In a regulated environment, modernization is not just an application issue. It reshapes who needs access, who approves it, and how business accountability is preserved across brokers, agents, employees, and external implementation partners.

P&V Group’s transformation is therefore best read as a governance programme wrapped inside a technology programme. The article shows a business trying to regain speed without losing control, which is a familiar pattern in large IAM, IGA, and PAM transitions when old systems are phased out but operational dependencies remain.

Key questions

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

A: Insurers should treat modernisation as an access governance change, not only a technology change. Every new module, integration, and external delivery relationship should have a named owner, a defined entitlement scope, and an offboarding trigger. Without that discipline, temporary project access becomes standing access and auditability deteriorates.

Q: Why do legacy transformation programmes often create hidden identity risk?

A: Legacy transformation programmes often create hidden identity risk because teams focus on application replacement while access ownership, third-party credentials, and integration secrets remain distributed across the old operating model. The result is entitlement drift, overlapping permissions, and weak visibility into who can still reach critical business functions.

Q: What should security teams measure during an insurance platform transition?

A: Security teams should measure how many identities were created for the programme, how many were retired at each milestone, and how many integrations still rely on temporary access. Those figures show whether governance is keeping up with the transformation or whether exceptions are accumulating faster than review cycles can remove them.

Q: Who is accountable for access when a vendor supports a transformation programme?

A: Accountability should sit with the organisation that owns the business process, not with the vendor alone. External partners may administer systems or build components, but the enterprise must define approval, expiry, and revocation rules so access does not persist after the support relationship changes.

Technical breakdown

Modular architecture and legacy system retirement

Modular software reduces the need for a single monolithic core by breaking functions into separable components that can be replaced gradually. That matters in insurance because legacy policy, distribution, and servicing functions are tightly coupled, so full replacement is risky. A modular approach lets teams phase out old capability while keeping production stable, but it also increases the number of interfaces, service identities, and integration permissions that must be governed consistently.

Practical implication: map every new module to its service identities, trust boundaries, and approval path before decommissioning any legacy component.

Business-led transformation and access governance

When a transformation is business-led, the access model often changes faster than the underlying operating procedures. New user journeys, broker workflows, and internal support roles create fresh entitlement patterns, and those entitlements can outlive the temporary project structure that introduced them. The technical risk is not only provisioning error. It is the accumulation of stale access, unclear ownership, and duplicated integration credentials across teams that now share responsibility for the same customer journey.

Practical implication: tie each entitlement to a named business capability and review it at the same cadence as the programme roadmap.

Internal integrator model and third-party identity control

As IT shifts toward an internal integrator role, the organisation becomes responsible for orchestrating more vendor, consultant, and platform relationships than before. That changes identity control from a simple employee access problem into a wider lifecycle and trust problem. Third-party accounts, API credentials, and support access need clear ownership, expiry, and offboarding rules, especially when a delivery partner like Ensur is part of the implementation chain.

Practical implication: maintain a separate lifecycle register for every external identity and remove access when the delivery role ends.

NHI Mgmt Group analysis

Modular transformation creates an identity governance expansion, not just an architecture refresh. Each new module introduces service accounts, integration keys, delegated support access, and changed approval paths. In regulated insurance, the control problem shifts from system replacement to entitlement proliferation across the new operating model. Practitioners should treat every module cutover as an identity boundary change, not merely a technical release.

The internal integrator model only works when ownership of access is explicit. When IT becomes the orchestrator rather than the sole builder, accountability fragments across business, delivery partners, and platform teams. That fragmentation is where stale access and duplicate trust paths usually accumulate. The implication is that transformation programmes need a named owner for every identity type, every integration, and every offboarding trigger.

Business-led change exposes the gap between process speed and governance speed. The article shows a programme designed to improve responsiveness, but responsiveness without lifecycle discipline tends to create standing access and informal exceptions. That is a classic control drift pattern in large enterprises. The field lesson is that governance must be redesigned at the same pace as customer-facing change, or it becomes decorative.

Third-party transformation work is a persistent lifecycle risk, not a temporary project detail. External consultants and software partners routinely need elevated access during implementation, yet that access often survives the project milestone if it is not explicitly retired. In NHI and PAM terms, this is a lifecycle management issue, not a vendor-management footnote. Practitioners should assume the risk persists until revocation is proven.

Identity ownership should follow business capability, not system convenience. If access is organised around legacy application boundaries, modernisation will preserve old dependencies inside new tooling. That creates audit friction, slows recertification, and obscures accountability when multiple agencies and brokers touch the same workflow. Teams should realign governance to the business services being delivered, not the systems being replaced.

From our research:

• From our research: The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• For a broader identity governance lens, see Ultimate Guide to NHIs , Standards for the control frameworks that shape access, lifecycle, and trust.

What this signals

Modernisation programmes are increasingly exposing a control gap between application delivery speed and identity lifecycle discipline. With 43% of security professionals concerned about AI systems learning and reproducing sensitive information patterns from codebases, the pressure to govern integration credentials, support access, and engineering secrets will only increase.

Identity boundary drift: as platforms become more modular, the security team’s real task is to keep trust boundaries visible as they move. That means aligning IGA, PAM, and service-identity ownership around the programme roadmap, not the old application stack.

Teams that already manage multiple secrets stores should expect this kind of transformation to create more exceptions unless they centralise oversight. The governance model needs to survive the migration, not be rebuilt after access sprawl has already settled in.

For practitioners

• Map entitlements to business capabilities Rebuild the access model so each role, service account, and integration credential is tied to a specific business capability rather than a legacy application name.
• Create explicit offboarding triggers for third parties Define a removal event for every external consultant, implementation partner, and support provider so access is revoked when the delivery role ends, not when someone remembers to review it.
• Review integration access at every cutover Treat each module migration or release as an identity boundary change and verify that service credentials, API tokens, and delegated support rights still match the current operating model.
• Assign one owner per identity type Give clear accountability for employee access, broker access, partner access, and machine-to-machine credentials so governance does not fragment across programme teams.

Key takeaways

• P&V Group’s transformation illustrates that legacy replacement also changes the identity governance model behind the business.
• The main risk is not the new software itself, but the access drift, third-party exposure, and entitlement fragmentation that can follow large programme change.
• Modernisation stays controlled only when each identity, integration, and offboarding event is owned and reviewed as part of the transformation plan.

Key terms

• Identity Boundary: An identity boundary is the point where one system, team, or partner’s access stops and another begins. In modernised environments, these boundaries often shift as platforms, integrations, and support models change, so they must be explicitly defined and reviewed rather than assumed.
• Third-Party Access: Third-party access is any entitlement granted to an external consultant, supplier, integrator, or support partner. It is not temporary just because the project is temporary. The access must have an owner, an expiry condition, and a revocation path tied to the business relationship.
• Entitlement Drift: Entitlement drift is the gradual misalignment between granted access and current business need. It typically appears during change programmes when roles expand, exceptions accumulate, and old permissions remain in place after the operational reason for them has disappeared.

What's in the full article

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

• The programme structure behind the tripartite co-creation model with Comarch, P&V Group, and Ensur
• The business rationale for phasing out legacy software while keeping day-to-day operations running
• The specific product and experience changes delivered for customers, brokers, agents, and employees
• The implementation perspective on how IT shifted into an internal integrator role

👉 The full Comarch article covers the co-creation model, rollout approach, and business outcomes in more detail

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.