TL;DR
An IGA platform can approve the right access but still can't change the account inside a legacy, third-party, or disconnected application used by an insurance company. The resulting gap shows up as files, tickets, local administration, and incomplete remediation. Closed-loop governance requires live access data, application-level execution, confirmation, and evidence returned to the IGA.
Why are critical applications at insurance companies still outside standard authentication and access review processes?
Many insurers have mature identity programs. The harder question is whether those programs can reach the applications the business relies on. When execution still depends on manual follow-through, the organization has a gap between the decision it made and the access it can verify.
Insurance organizations can have a mature identity program and still rely on people to complete access changes in applications that support underwriting, claims, policy servicing, finance, distribution, and other operations. The exact application mix and identity populations vary by carrier, broker, and business model.
The technical failure mode is consistent: the governance system can decide, but the target application cannot receive or execute the decision.
When that happens, teams export a file, open a ticket, send an email, run a script, or ask a local owner to sign in. Each workaround can complete a task. None automatically creates a continuous, closed loop between the approved identity state and the observed application state.
Governance coverage and application coverage are different
IAM and IGA platforms are designed to govern applications that can communicate through supported standards and interfaces. Disconnected applications lack one or more of those paths. Some have no SCIM support. Some expose no user-management API. Some are on-premises or vendor-managed.
Others provide only a user interface for account administration.
The identity platform isn't failing when it cannot cross an interface that doesn't exist. The gap appears after the policy decision: account creation, role assignment, deprovisioning, or remediation still has to occur inside the application. Treating that step as a permanent exception leaves governance dependent on human follow-through.
Flat files show access, but only at a point in time
CSV and spreadsheet exports remain common because nearly every application can produce or accept some form of file. That makes files useful for exchange and migration. It does not make them a durable governance control. A file is a snapshot. Accounts can change after export, identity matching can be ambiguous, and review decisions may still require manual remediation in the target application.
The key control question is not whether the review was completed in the IGA. It is whether the reviewed access was changed in the application and whether the IGA received reliable confirmation. Without that last step, the organization has a decision record and a separate execution process.
What closed-loop insurance governance looks like
A practical architecture keeps the IGA in command. The IGA owns the request, approval, certification, separation-of-duties decision, and remediation instruction. An execution layer supplies the connectivity and application-specific actions the IGA lacks.
- Pull users, accounts, roles, entitlements, and ownership data from the target application.
- Correlate application accounts to governed identities, with an exception path for uncertain matches.
- Present current access in the IGA for requests, certifications, and policy evaluation.
- Execute approved provisioning, deprovisioning, role changes, and remediation through an API or managed UI automation.
- Verify the new application state and return completion, failure, and exception data.
- Maintain a time-stamped audit trail that links the decision to the action and observed result.
Where credential and privileged access controls fit
Lifecycle governance is only part of the application edge. Disconnected apps may also depend on local passwords, shared credentials, or standing administrative access. Credential storage alone does not change the account lifecycle. Conversely, lifecycle automation is incomplete if an offboarded user still knows a shared password or can use an unchanged MFA factor.
For supported applications, Cerby documents controls for password rotation, credential non-disclosure, centrally managed MFA, just-in-time privileged access, and attribution of shared-account activity to an individual user. Evaluate these controls against the application's actual authentication model and the insurer's PAM architecture.
How Cerby augments the existing IGA
Cerby connects supported disconnected applications to platforms such as SailPoint and Okta Identity Governance. It can aggregate access data into the IGA, manage roles and entitlements, execute lifecycle and remediation actions through APIs or UI automation, and return logs and status. Cerby extends the governance platform's reach; it does not replace the governance decision or source of truth.
That division of responsibility is important for technical review. Policy remains where the identity team already manages it. Application execution becomes automated and observable. Exceptions remain visible instead of being buried in a ticket queue or file exchange.
Choose a pilot that tests the whole loop
A good pilot is not simply the easiest application to connect. Choose one with a meaningful access-review or lifecycle pain point, a known owner, a defined role model, and enough transaction volume to test steady-state operations. Confirm data ingestion, identity correlation, approval, execution, verification, evidence, and exception handling.
If the pilot ends with a successful account change but no proof returned to the IGA, the workflow is still open. Insurance identity governance becomes durable when the system of record and the application agree, and can show how they came t