How identity tools reach applications without APIs or SCIM

Why is this the hard part?

Finding an application is the first step. Getting its account list out, and pushing a removal back in, is the second, and it decides whether a finding ever becomes a fix. Applications with a SCIM endpoint are the easy case. The routes below cover the rest, roughly from most to least automated.

1. SCIM

The standard provisioning protocol (RFC 7644). Where an application implements it, any IGA or IdP that speaks SCIM can create, update and remove accounts.

2. Directory and database connectors

Many on-prem applications keep users in LDAP or in a SQL database. Microsoft documents LDAP and SQL connectors for Entra provisioning, running through the ECMA connector host, and states on-prem provisioning works without opening firewalls.

3. Scripted API calls

Where an application has an API but no SCIM, a connector can call it directly. Microsoft lists REST, SOAP and PowerShell connectors.

4. Open-source connector kits

C1 publishes Baton, open-source connectors that teams can extend, and C1 Bridge for on-prem systems. The benefit is that you can write the missing connector; the cost is that you maintain it.

5. Custom integration APIs

Veza's Open Authorization API (OAA) lets custom systems send their permission data into the Access Graph, and OAA Write is listed for pushing changes back. SailPoint's Application Management add-on offers integration templates and a self-registration portal for app owners, and SailPoint states it reduced onboarding time by 45-70%, a vendor figure. Saviynt states it onboards connected, disconnected and custom-built applications in hours, not weeks.

6. Robotic process automation

Palo Alto Networks describes Idira Identity Governance as using robotic process automation to help automate connection to applications that lack APIs: a bot works the application's admin screens as a person would. It reaches applications nothing else can, and it breaks when the screens change.

7. The documented manual path

For applications that support none of the above, Microsoft documents a manual route: export the application's users to CSV, match them to Entra users, create role assignments, run an access review, and optionally raise a ServiceNow ticket for someone to remove access by hand. It is slow, but it is a process an auditor can follow.

How should you choose?

Ask each vendor which of these routes it uses for your five hardest applications, by name. The register shows what each vendor documents for on-prem and custom-built apps, and the No-API reach criterion in the rankings scores it.

Sources