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.
Why This Matters for Security Teams
Replacing a legacy insurer platform is not just a technology migration. It is an identity migration, because every policy admin connector, claims integration, batch job, and vendor feed can carry its own non-human identity. If those identities are not reviewed, old access often survives long after the old system is supposedly retired. That creates hidden reach into policy data, payment workflows, and downstream partner systems.
NHI Management Group’s Ultimate Guide to NHIs notes that only 20% of organisations have formal offboarding processes for API keys, and 97% of NHIs carry excessive privileges. In insurance, that matters because migrations are rarely a clean cutover. They are usually phased, with coexistence periods, temporary bridges, and integration exceptions that become permanent by accident. Security teams that focus only on application testing miss the access layer entirely. The right question is not whether the new platform is secure in isolation, but whether old machine access has been decisively removed from the operating model.
Current guidance in the NIST Cybersecurity Framework 2.0 supports this by tying system change to asset, access, and recovery discipline. In practice, many insurers discover surviving service accounts only after a legacy batch process has already been abused or a third party still has live connectivity into a retired environment.
How It Works in Practice
A safe replacement program starts with an access inventory for both estates: the legacy system and the digital target platform. That inventory should include human admins, service accounts, API keys, certificates, scheduler accounts, integration users, and any credentials embedded in scripts or CI/CD workflows. The objective is to define ownership before cutover, then decide what must be recreated, migrated, reduced, or revoked.
The operational pattern is straightforward:
- Map each business capability to the identities that support it, such as claims intake, billing, broker connectivity, or reporting.
- Assign a business owner and a technical owner for every non-human identity.
- Replace shared or long-lived credentials with named, task-specific access where possible.
- Set expiry dates for temporary bridge access and retire them on schedule.
- Validate that the old platform cannot be reached through forgotten integrations, dormant tokens, or stale certificates.
The OWASP Non-Human Identity Top 10 is useful here because migration work often exposes the same failure modes: over-privileged service accounts, poor secrets handling, and weak lifecycle control. NHIMG’s Lifecycle Processes for Managing NHIs emphasizes that lifecycle controls matter as much as provisioning. If a legacy connector is replaced but never formally decommissioned, it remains an active path into the environment. The safest implementation is to make access retirement a gate in the migration plan, not an after-action task.
These controls tend to break down when the insurer runs parallel platforms for claims or billing across multiple release cycles, because temporary exceptions become undocumented standing access.
Common Variations and Edge Cases
Tighter access cleanup often increases migration friction, requiring organisations to balance cutover speed against auditability and operational continuity. That tradeoff is real in insurance, especially where policy servicing depends on mainframe bridges, outsourced processing, or regulator-facing reporting jobs that cannot be stopped overnight.
Best practice is evolving for these cases. There is no universal standard for every coexistence pattern, but current guidance suggests treating each exception as time-bound, owned, and reviewable. That means temporary access should have a named approver, a clear expiry date, and a documented reason tied to a specific migration milestone. If a vendor still needs access after cutover, the access path should be re-approved against the new platform rather than carried forward by habit.
The most common edge cases are vaulted secrets that remain valid after the target system goes live, disabled accounts that still authenticate through cached tokens, and “break glass” credentials that are never retired. NHIMG’s Top 10 NHI Issues and the Regulatory and Audit Perspectives section both reinforce the same point: auditors will ask who owns the identity, why it still exists, and when it will be removed. In short, a successful platform replacement is measured by how completely access dies with the old system, not by how quickly the new one launches.
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 CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Migration often leaves stale NHI credentials unrotated or unrevoked. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be reviewed when replacing connected systems. |
| NIST CSF 2.0 | ID.AM-2 | System replacement requires complete asset and identity inventory. |
Revalidate least privilege for old and new platforms during migration and decommissioning.
Related resources from NHI Mgmt Group
- How should retail organisations govern access across stores, devices, and POS systems?
- Why do IAM platforms struggle to govern access across enterprise environments?
- How should security teams govern identity access across Entra and other platforms?
- How should insurers govern access during large core-system modernisation projects?
