Cross-System Identity Propagation

A technology services vendor's IGA platform was configured to propagate identity lifecycle events , provisioning, role changes, and deprovisioning , to all connected applications through SCIM and directory sync connectors. The IGA's connected application list included seventeen systems. During an onboarding audit for a new client engagement, the vendor's security team found that a recently departed engineer still had active access to the client's shared project workspace in Confluence. Investigation found that the client had deployed a new self-hosted Confluence instance six weeks before the engineer's departure to support a specific project. The new instance had been added to the environment by the project team without notifying the IGA administrators, and without being added to the IGA's connector list. When the engineer was deprovisioned, the IGA correctly deprovisioned all seventeen connected systems. The eighteen-system , the new Confluence instance , remained unaffected because the IGA did not know it existed. The engineer's Confluence access persisted not because the deprovisioning process failed, but because the system was outside the process's scope.

What is Cross-System Identity Propagation Risk, Really?

Cross-system identity propagation is the process by which identity lifecycle events , user creation, role changes, and deprovisioning , are communicated from a central identity source (typically an IdP or IGA platform) to all connected systems, ensuring that identity state is consistent across the entire application landscape. When an employee joins, provisioning creates accounts in all relevant systems. When a role changes, access modifications are applied consistently. When an employee departs, deprovisioning removes access from all systems simultaneously. Propagation failures occur when some systems do not receive these lifecycle events , either because the propagation pathway is incomplete or because systems were added to the environment without being registered for lifecycle event receipt.

The connector inventory gap is the primary propagation failure mode. IGA platforms propagate to systems they know about , systems that have been onboarded as connectors and configured to receive lifecycle events. Systems added to the environment without being onboarded to the IGA are invisible to the propagation process. In dynamic enterprise environments where teams regularly deploy new applications, cloud services, and development tools, the gap between the IGA's connector list and the actual application inventory grows continuously unless there is an active process connecting new system deployment to IGA onboarding.

The shadowed system problem amplifies the connector gap. Applications deployed by individual teams for specific project purposes , a new collaboration tool for a client engagement, a development environment for a sprint, a monitoring dashboard for a system deployment , frequently bypass the IT provisioning process entirely. The team deploys the application, creates accounts, and uses it without notifying IT or the IGA team. When team members depart, the IGA deprovisioning does not reach the application because the application was never registered. The accounts persist indefinitely, sometimes discovered months later during an unrelated audit.

• New systems not registered in IGA connector list , applications deployed without notifying IGA administrators
• Team-deployed shadow applications , systems created outside IT provisioning process with no lifecycle event integration
• Connector list not maintained with current application inventory , IGA scope falling behind actual environment scope
• No discovery process for new applications , no mechanism for identifying systems not in IGA connector list
• Propagation completeness not verified , assumption that IGA deprovisioning covers all systems

Why this matters

Cross-system identity propagation matters for TPRM because vendors who access customer environments across multiple systems , project workspaces, client collaboration tools, shared development environments , may have IGA deprovisioning gaps for the customer-environment-adjacent systems that were deployed specifically for the engagement. These are precisely the systems most likely to be outside the standard IGA connector list: deployed quickly for a specific purpose, managed by a project team rather than IT, and not registered in the IGA before the engagement ends.

The post-departure access window is the most immediately consequential dimension. When a vendor employee who was managing a client engagement departs, the IGA deprovisioning removes their corporate access. But the collaboration tool deployed for the engagement, the shared development environment, and the client-specific project workspace may all be outside the IGA connector list , and access to all of them persists until someone specifically identifies and removes it.

Where most teams get this wrong

The most consistent failure is treating IGA automation as comprehensive deprovisioning without verifying that the IGA connector list matches the current application inventory. The IGA is comprehensive for the systems in its connector list. Verifying completeness requires comparing the connector list against the actual application inventory , a reconciliation that most organizations perform infrequently or not at all.

• Treating IGA automation as comprehensive without connector list verification
• No application inventory reconciliation against IGA connector list
• New application deployment not triggering IGA registration
• Shadow application discovery not performed
• Post-departure access verification not covering non-IGA systems

What good looks like

Mature identity propagation programs maintain a current IGA connector list that matches the actual application inventory , through processes that connect new application deployment to IGA registration, periodic reconciliation of the connector list against the application landscape, and discovery scanning for systems not in the IGA scope.

• New application deployment triggers IGA registration , process requiring IGA onboarding before application deployment completes
• Periodic connector list reconciliation , comparison of IGA scope against current application inventory
• Shadow application discovery , scanning for applications not in IGA connector list
• Post-departure access verification , confirmation that deprovisioning covered all systems including non-IGA applications
• Application inventory as governance artifact , maintained list of all applications with IGA connection status

Tooling

SaaS Discovery , Grip Security, Nudge Security, BetterCloud

SaaS discovery platforms identify applications in use across an organization , including shadow applications deployed by teams without IT registration. These platforms detect application access through browser extension telemetry, network traffic analysis, or identity provider log analysis. For TPRM practitioners, asking whether the vendor uses SaaS discovery to identify applications not in their IGA scope provides a specific shadow application detection question.

IGA with Application Discovery , SailPoint, Saviynt

Modern IGA platforms provide application discovery capabilities , identifying applications where users have accounts that are not managed through the IGA. For TPRM practitioners, asking whether the vendor's IGA includes application discovery that identifies unregistered systems with user accounts provides a specific propagation gap detection question.

Governance challenges

The governance challenge with identity propagation completeness is the continuous environment change problem. Application inventories change constantly , new tools deployed, old ones decommissioned, scope changes to existing deployments. The IGA connector list that was accurate at the last reconciliation is progressively less accurate as the environment evolves. Maintaining completeness requires either automated discovery that continuously identifies new systems or a process that connects every new application deployment to IGA registration before the application goes into use.

• Require IGA registration before new application deployment , governance gate in deployment process
• Implement SaaS discovery for shadow application detection
• Periodic connector list reconciliation against current application inventory
• Post-departure access verification including non-IGA systems
• Include propagation completeness in access governance assessment

If you are a small team

After your next vendor staff departure, run one check that most organizations never perform: ask the vendor to confirm that deprovisioning covered every system where the departed staff member had access , not just the IGA-managed systems, but any project-specific tools, client collaboration platforms, and team-deployed applications. The answer will surface both the systems outside IGA scope and whether the vendor has a process for identifying them.

• Ask vendors to confirm deprovisioning covered all systems including non-IGA applications at each departure
• Ask whether the vendor has a process for identifying applications not in their IGA scope
• Ask how frequently the IGA connector list is reconciled against the actual application inventory
• Ask whether new application deployment triggers IGA registration

What to require

Ask directly:

"When you deprovision a staff member who had access to our environment, does that deprovisioning cover all systems they had access to , including project-specific tools, client collaboration platforms, and team-deployed applications not managed through your central IGA?"

"How frequently is your IGA connector list reconciled against your actual application inventory to identify systems where users have accounts that are not managed through the IGA lifecycle process?"

Expect as evidence

• IGA connector list with last reconciliation date
• Shadow application discovery capability or process
• Post-departure access verification process covering non-IGA systems
• New application deployment IGA registration process

A vendor who confirms automated IGA deprovisioning should be asked specifically whether that automation covers applications deployed for project-specific purposes that may not be in the IGA connector list. The automation covers what the IGA knows about. The question is what the IGA does not know about.

How to evidence it

• IGA connector list reconciliation records
• Shadow application discovery records
• Post-departure access verification including non-IGA systems
• New application deployment IGA registration process

Key Takeaway

The IGA deprovisioned the user from seventeen systems. The eighteenth system , the Confluence instance deployed six weeks ago by the project team , was never in the connector list. The automation worked. The scope was incomplete. Identity propagation completeness requires that the IGA knows about every system where users have accounts , not just the systems that were registered when the IGA was deployed, but every system added to the environment since. The connector list is the governance scope. The application inventory is the actual scope. The gap between them is where departed users retain access. Reconcile the lists. Register new deployments. Verify completeness after every departure. The automation is only as complete as what it knows about.

More on Security

• API Identity Misuse
• Access Certification Effectiveness
• Access Policy Misconfigurations