By NHI Mgmt Group Editorial TeamPublished 2025-10-23Domain: Governance & RiskSource: Comarch

TL;DR: elipsLife Netherlands modernized its employee benefits platform with Comarch to replace legacy systems, improve user experience, automate end-to-end processing, and support data migration, cloud deployment, and integration with more than 12 external platforms. The deeper lesson is that modernization programmes now reshape identity, access, and operational governance at the same time, so control design must keep pace with platform change.


At a glance

What this is: This is a Comarch case study on how elipsLife modernized a legacy insurance platform into a cloud-deployed, integrated operating model.

Why it matters: It matters because insurance modernization changes access paths, integration surfaces, and operational control points across NHI, autonomous, and human identity programmes.

By the numbers:

👉 Read Comarch's case study on elipsLife's insurance platform modernization


Context

Insurance platform modernization is not just a technology refresh. It changes how identity, data, and workflow controls are enforced across policy administration, claims handling, finance, document generation, and external integrations.

For IAM and governance teams, the real issue is continuity: legacy systems often hide access dependencies, brittle integration points, and manual controls that no longer scale. When an insurer moves to a modern platform and cloud deployment, the identity model has to be revalidated alongside the application stack.


Key questions

Q: How should insurers govern identity during legacy platform modernization?

A: Insurers should treat modernization as an identity inventory exercise as much as a systems migration. Every service account, API key, operator privilege, and external integration should be mapped, owned, and retired where possible before the new platform goes live. That prevents hidden access from surviving the cutover and reduces the chance that old trust relationships reappear in the modern stack.

Q: Why do insurance modernisation projects increase access risk?

A: Modernisation increases access risk because it compresses more policy, claims, and finance activity into fewer platforms and more connected workflows. If identities are broad, reused, or poorly owned, a single compromise or stale entitlement can affect multiple business processes. The risk is not the cloud itself, but the larger blast radius created by integration and automation.

Q: What do teams get wrong about automation in insurance operations?

A: Teams often assume automation reduces governance needs, when it usually raises the stakes for identity control. Faster workflow execution means mistakes, stale permissions, and broken integrations can spread before a person notices. Governance has to move closer to the process boundary, especially where one action can trigger multiple downstream changes.

Q: What should identity teams verify before moving an insurer to cloud deployment?

A: They should verify that operational identities and administrative identities are separated, that each integration has a named owner, and that no credential is carrying forward only because it was needed in the legacy system. Cloud deployment is the right moment to remove inherited access paths that no longer match the business process.


Technical breakdown

Why legacy insurance platforms create hidden access dependencies

Legacy insurance systems tend to accumulate implicit trust relationships over time. Service accounts, batch jobs, integration keys, and operator privileges are often created to keep the business running, then left in place because the original workflow is never fully retired. In insurance environments, that creates a control gap between what the platform appears to do and what identities actually have permission to do. Modernization exposes those dependencies because processes are replatformed, integrated, and automated at the same time. The technical challenge is not just migration, but re-establishing authoritative ownership for every credential, account, and interface.

Practical implication: Map every legacy integration and credential before migration so hidden access does not survive the cutover.

Cloud-deployed insurance workflows and identity blast radius

When an insurance core platform moves into a cloud environment, the blast radius of a single mis-scoped identity expands quickly. Administrative interfaces, claims workflows, reporting pipelines, and document generation all depend on connected systems and API-facing access. If privileges are broad or identities are reused across functions, a compromise in one workflow can affect many others. Cloud deployment does not create the risk, but it makes weak segregation more consequential because connectivity becomes continuous rather than episodic. Governance has to follow the runtime path of the business process, not just the org chart.

Practical implication: Separate administrative, operational, and integration identities before cloud deployment to reduce cross-process impact.

Automation in policy and claims processing needs stronger controls than manual operations

End-to-end automation changes the control surface because decisions, triggers, and outputs happen faster than human review cycles. In policy administration and claims handling, the system may register, generate, and propagate changes across multiple downstream services without a person validating each step. That improves throughput, but it also means that a bad input, stale entitlement, or broken integration can propagate much further before detection. The architectural question is whether the process still has effective checkpoints after automation compresses the workflow.

Practical implication: Insert validation and approval checkpoints at high-impact process boundaries, not only at the start or end of the workflow.


NHI Mgmt Group analysis

Legacy insurance modernization is an identity governance project, not just an application project. The article is framed as operational transformation, but the underlying change is that access, workflows, and external integrations are being reconstituted at the same time. That makes identity continuity the hidden risk surface. Practitioners should treat modernization as a revalidation of every machine, service, and human entitlement that supports policy and claims operations.

Identity blast radius: legacy insurance platforms often hide the full scope of privileged access until the system is replaced. When a core platform is retired, undocumented service accounts, integration keys, and operator permissions are forced into view. That is not merely a migration issue. It shows that access governance was never fully observable in the first place, and the implication is that insurers need a migration inventory that includes identities, not just data and functions.

Automation changes the control model for policy administration and claims handling. The article’s emphasis on faster processing and end-to-end automation means decision points are moving into the system runtime. That reduces manual friction, but it also narrows the window for human oversight. The implication is that identity governance must account for process speed, because controls built around slower human-paced operations will not reliably catch a bad entitlement or malformed integration once the workflow is automated.

Cloud deployment increases the need for explicit separation between operational identities and administrative identities. The platform’s move to Comarch Infrastructure Cloud and its integration with more than 12 external systems means access paths are no longer isolated within one legacy perimeter. That increases the importance of scoping, segmentation, and lifecycle ownership for every connected identity. Practitioners should re-evaluate whether their current access model still reflects the way business processes actually execute.

Modernization only looks complete when governance can keep pace with the platform. The strategic promise here is flexibility and scalability, but those outcomes depend on whether identity, data integrity, and compliance controls are embedded into the new operating model. Insurance teams should use modernization programmes to close the gap between business transformation and access governance, or they will simply recreate legacy risk on newer infrastructure.

From our research:

  • 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
  • 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
  • See Ultimate Guide to NHIs , Key Challenges and Risks for the visibility and rotation issues that often persist through modernization programmes.

What this signals

Identity blast radius: modernization programmes often expose the difference between presumed and actual control. When an insurer replaces a legacy platform, hidden access paths, stale integration credentials, and informal operational privileges become visible all at once, which means the migration plan has to include identity remediation, not just application cutover.

With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, the broader lesson is that platform transformation will inherit secret sprawl unless teams inventory credentials at the same pace they move data and workloads. That is why the migration backlog should include identity cleanup alongside technical testing.

For teams aligning modernization with control maturity, the most useful reference point is the NIST Cybersecurity Framework 2.0. Its govern and protect functions are the right place to anchor ownership, segmentation, and lifecycle review before the new insurance platform becomes the new source of inherited risk.


For practitioners

  • Build an identity inventory into the migration plan Catalogue every service account, API key, batch job, and operator credential tied to the legacy platform before cutover, then assign an owner and retirement date for each one.
  • Re-segment privileged access across core workflows Separate administrative, operational, and integration identities so claims, policy, finance, and document generation do not share the same permissions or recovery paths.
  • Validate automation checkpoints at process boundaries Add validation and approval steps where one system action can trigger downstream policy, claims, or document changes, especially in high-impact business flows.
  • Review external integration ownership before migration Confirm who owns each connection to the more than 12 external industry or national platforms and remove or rotate credentials that no longer have a current business need.

Key takeaways

  • Legacy insurance modernization exposes identity dependencies that were easy to overlook in the old platform.
  • The operational gain is real, but the governance burden shifts to credentials, integrations, and workflow boundaries.
  • Migrating the application without revalidating access will preserve inherited risk in a newer environment.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-03Legacy migration often leaves stale credentials and excessive privileges in place.
NIST CSF 2.0PR.AC-4The case is driven by access scope across platforms and workflows.
NIST Zero Trust (SP 800-207)Cloud-deployed insurance workflows need explicit trust boundaries and segmentation.

Inventory and rotate every NHI credential before cutover, then retire unused identities immediately.


Key terms

  • Identity blast radius: The amount of business process exposure created when one identity or credential is over-permissioned. In modern insurance platforms, a single account can touch policy, claims, finance, and document flows, so poor scoping turns one access mistake into a broad operational problem.
  • Operational identity: A non-human identity that supports day-to-day business execution, such as a service account, batch job, or integration credential. In modernization projects, these identities often carry hidden dependencies because they were created to keep legacy processes running, not to satisfy current governance standards.
  • Access lineage: The history of how a privilege, account, or integration came to exist and who owns it now. Access lineage matters during migration because inherited permissions often outlive the business function that created them, making cleanup and accountability difficult unless it is tracked explicitly.

What's in the full article

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

  • The full migration scope across product administration, claims handling, finance, and document management.
  • The integration pattern used to connect with more than 12 external industry or national platforms.
  • The performance and deployment details behind the cloud-hosted insurance platform.
  • The business context for why elipsLife prioritised modernization and ecosystem alignment.

👉 Comarch's full case study covers the migration scope, integration model, and deployment context in more detail.

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 responsible for identity security strategy or IAM programme maturity, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on 2025-10-23.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org