Integrating IAM With Existing and Legacy Applications (2026)

Integrating an identity and access management platform with the applications you already run is, at its core, a connector problem before it is a strategy problem. Every application in your estate can speak some set of integration protocols and cannot speak the rest, and the single most useful question you can ask about each one is not "how should this fit into our IAM strategy" but "which protocol can this application actually speak" — SCIM, LDAP or Active Directory, SAML or OIDC, or nothing standard at all. The answer to that question determines how the application gets connected, how much of the work is automated versus manual, and how long the integration takes. Get the connector mapping right and the strategy mostly follows; get it wrong and you end up with a modern IAM platform managing your newest applications flawlessly while the systems that actually hold your sensitive data stay outside it.

This is the 2026 update to our original guide on integrating IAM with existing applications and systems, rewritten around the integration mechanics practitioners have to evaluate rather than the general case for why integration is worthwhile. The case for centralizing identity is well settled. What still trips up real projects is the connective tissue — which pattern fits which application, how authentication and provisioning are actually separate integrations, and what to do about the legacy and mainframe systems that speak none of the modern standards and yet cannot be left out.

Integration is a connector problem first

An IAM platform is only as valuable as the applications it actually reaches. A platform that manages identities for your identity-provider-native SaaS applications and nothing else has centralized the easy 60% of the estate and left the hard, high-risk 40% exactly where it was — managed locally, with its own user store, its own passwords, and its own offboarding process that depends on someone remembering to run it. The whole return on an IAM investment comes from closing that gap, and closing it means connecting each application through whatever protocol it supports, not through the protocol you wish it supported.

That reframing matters because it changes how you scope the project. Instead of a monolithic "integrate IAM" initiative, you get a per-application decision that follows a clear hierarchy: does it support SCIM for provisioning, can it federate authentication over SAML or OIDC, can it at least bind to a directory over LDAP or Active Directory, and if none of those apply, what connector or agent can bridge the gap. Every application lands somewhere on that hierarchy, and where it lands tells you both the effort involved and the degree of automation you'll achieve.

Four patterns cover most enterprise estates — the deciding factor is which one each application can actually speak.

The four patterns below are not competing choices you pick between once. They coexist across an estate and frequently combine on a single application — SAML for login and SCIM for provisioning is the most common pairing — because authentication and account lifecycle are genuinely separate problems that happen to be solved by the same platform.

SCIM: provisioning as a repeatable API call

SCIM, the System for Cross-domain Identity Management, is the modern standard for the provisioning half of integration. It defines a REST API through which an identity provider tells an application to create a user, update that user's attributes or group memberships, and deactivate or delete the account. Its value is that it turns provisioning from a per-application custom build into a repeatable, standardized call — an IAM platform that speaks SCIM can provision to any application that also speaks SCIM through the same mechanism, so one lifecycle event fans out to every SCIM-enabled target consistently instead of requiring a bespoke script per application.

That consistency is the entire point. A hire event should create the right accounts across a dozen applications in one motion; a termination should deactivate them all in the same operational window. SCIM makes that fan-out reliable for the applications that support it, which is a growing share of modern SaaS. Our deep dive on the SCIM provisioning standard covers the protocol mechanics — the schema, the endpoints, the create-update-deactivate operations — in more detail than is worth repeating here.

The honest limit is coverage. SCIM is common among newer cloud applications and rare among older or on-premises ones, so a SCIM-only integration strategy quietly excludes exactly the legacy systems that most need governing. SCIM is the right first choice wherever it exists, and it is not a substitute for the directory-sync and connector patterns that reach everything else.

LDAP and Active Directory synchronization

A large share of enterprise applications — including many that will never support SCIM — authenticate against a directory. LDAP and Active Directory synchronization integrates those applications by keeping directory identities aligned between the authoritative source and the systems that read from it, so a change made once propagates to every directory-bound application rather than being re-entered in each. For applications that can be pointed at a directory for authentication, this is often the most pragmatic path to centralization: the application keeps doing what it already does, and the directory becomes the single place identities are managed.

Directory sync is also the fallback that rescues integrations where a modern API isn't available. An older application that can't do SAML can frequently still authenticate against Active Directory or an LDAP directory, which centralizes at least the login even when full federation isn't possible. The directory layer has proven remarkably durable precisely because it sits underneath so much of the estate — it is the connective tissue that lets otherwise-isolated applications share a common identity without each one needing to speak a modern protocol directly.

The trade-off relative to SCIM is timing and granularity. Synchronization is often scheduled or event-driven rather than real-time, and it manages directory attributes rather than the richer application-level entitlements a native connector can reach. For many applications that is entirely sufficient; for some it is a bridge to a better connector later.

SAML and OIDC: federating authentication for SSO

SAML 2.0 and OpenID Connect (OIDC) solve the authentication half of integration. They let an application delegate login to your IAM platform so a user proves who they are once and reaches many applications without a separate password for each — the mechanism behind single sign-on. SAML remains the workhorse for enterprise web applications, while OIDC, built on OAuth 2.0, is the more modern choice for newer applications and native mobile clients. Most estates run both, and the practical question per application is simply which one it supports; if it supports either, you can federate its login.

The critical thing to understand is what SSO does not do. Federating authentication gets a user logged in; it does not create, update, or revoke the underlying account. An application connected by SAML alone still has a user record that exists independently of whether the person can log in, and if that record isn't provisioned and deprovisioned by a separate integration, it lingers after the person leaves — reachable again the moment SSO is bypassed or the account is used directly. Whether SAML is still the right foundation for that federation, given the newer alternatives, is a question we take up honestly in our assessment of SAML 2.0's continued relevance.

The before-and-after that justifies the project: many separate logins and user stores collapse into one identity hub — but only when both authentication and provisioning are connected.

API and agent connectors: everything else, including legacy

The applications that speak none of the standards are where integration projects actually live or die. Proprietary line-of-business systems with their own APIs, applications whose users live in a database table, on-premises systems unreachable from the public internet, and mainframe environments a generation removed from REST — these can't be waved off, because they frequently hold the most sensitive data and the most privileged access in the enterprise. They get integrated through purpose-built connectors and on-premises agents.

A connector translates standard provisioning actions — create this user, adjust these entitlements, deactivate this account — into whatever the target system actually understands, whether that's a proprietary API, a database write, or a mainframe security-manager command. Mature IAM platforms ship connectors for common targets so you're not building the translation layer from scratch. An on-premises agent extends that reach behind the firewall, executing provisioning against systems that can't be exposed to a cloud service directly.

Mainframe is the sharpest version of this problem, and it's more tractable than its reputation suggests. A mainframe security manager like RACF can be automated from HR-driven events through a connector that issues the right commands, so joiner-mover-leaver processing reaches the mainframe on the same automated path as the rest of the estate rather than staying a manual carve-out; we walk through exactly that in our guide to automating RACF provisioning from HR events. The general principle holds for any hard target: the goal is to bring it onto the automated path through the best available connector, not to accept it as the permanent manual exception that hollows out the program's coverage.

Authentication and provisioning are separate integrations

The single most consequential thing to internalize about IAM integration is that connecting authentication and connecting provisioning are two different jobs, and doing one does not do the other. This is worth stating flatly because conflating them is both common and expensive.

Authentication integration (SAML, OIDC, or directory-bound login) controls whether a user can get in. Provisioning integration (SCIM, directory sync, or a connector) controls whether the account exists, what it can reach, and whether it's revoked when the person leaves. An application with SSO but no provisioning gives you clean, password-free login and leaves orphaned accounts live after departures — the account still exists, and SSO can be circumvented. An application with provisioning but no SSO gives you correct account lifecycle and still forces users onto a separate password. Neither half is complete on its own.

The practical consequence is that your application inventory needs two columns, not one: how login is federated, and how the account lifecycle is managed. Many applications will use different protocols for each — SAML for authentication and SCIM for provisioning is the canonical pairing — and some legacy systems will need each wired through a different mechanism entirely, directory-bound login alongside a connector-driven lifecycle. Treating the two as one integration is how organizations end up with fast, polished onboarding and slow, incomplete offboarding, which is the exact asymmetry that leaves access live longer than it should.

Sequencing the rollout

Integration effort has a natural order, and skipping steps is where projects stall. The sequence below is deliberately front-loaded on discovery and mapping, because the failures that surface late are almost always the ones seeded by skipping the early work.

Front-load discovery and identity mapping — the failures that surface late are usually the ones seeded by skipping the early steps.

Inventory every application. You cannot integrate what you haven't enumerated, and discovery reliably turns up applications with their own local user stores that no central team was tracking. This step doubles as a shadow-IT audit: the provisioning that happens outside the sanctioned process is exactly the access that never gets governed, a risk we examine in our piece on shadow-IT provisioning and ticket-driven access. Every application you miss here becomes an integration gap later, so err toward over-enumerating.

Map identities to an authoritative source. Before connecting anything, tie each application's accounts back to a source of truth — typically the HR system for who works there and the corporate directory for their identity. This is where you resolve the duplicate accounts, the shared logins, and the mismatched usernames that would otherwise get faithfully propagated by the automation. Integrating against a messy identity source doesn't clean it up; it multiplies the mess at machine speed, which is why this mapping step precedes any connector work.

Connect each application via its best protocol. Now the connector mapping pays off. Start with high-value, standards-friendly targets — the applications that support SCIM and SAML — because they prove the model quickly and deliver visible wins that sustain the project. Work down the hierarchy from there toward the harder targets, choosing SCIM where it exists, directory sync where it fits, federation for login, and connectors or agents for everything else.

Pilot on a representative subset. A pilot that only touches easy applications proves nothing you didn't already know. Deliberately include at least one genuinely difficult system — a legacy application, an on-premises target, ideally a mainframe — so the plan meets reality while the blast radius is still small. The hard integrations are where assumptions break, and you want them to break in the pilot.

Enforce everywhere, closing the legacy gaps. The final step is enforcing SSO and automated provisioning across the estate, and the discipline that matters here is refusing to leave the difficult systems as standing exceptions. Every application left outside the platform is an account that onboards and offboards by hand, and the sum of those exceptions is the coverage gap that undermines the entire investment. Bringing the legacy systems in — through whatever connector, agent, or directory sync fits — is the difference between an IAM platform that governs the estate and one that governs the easy part of it.

Pitfalls worth planning around

A few failure modes recur often enough to name directly. The first is treating SSO as if it also handled provisioning, so accounts are never deprovisioned and access outlives employment. The second is leaving legacy and mainframe systems as permanent manual exceptions until one of them becomes the audit finding that defines the program — the exception you meant to close temporarily has a way of becoming the norm. The third is integrating against an unclean identity source, so the automation propagates duplicate, stale, and mismatched records confidently and fast, which is worse than the manual process it replaced because no human is in the loop to notice.

The fourth is skipping or under-scoping the application inventory, so unmanaged user stores are discovered during an incident rather than during planning. The fifth is a pilot that never touches a hard system, giving false confidence that collapses at scale. And the sixth, underlying several of the others, is building for onboarding and forgetting offboarding — investing in fast, clean account creation while revocation stays slow and partial. The same discipline that makes provisioning trustworthy at the moment of hire has to apply, symmetrically, at the moment of departure, a point we develop further in our piece on what AI-driven provisioning actually automates.

What Avatier ships toward this pattern

Avatier Identity Anywhere connects to applications through the standards where they exist — SCIM for provisioning, SAML and OIDC for single sign-on, and LDAP or Active Directory synchronization for directory-bound applications — and through purpose-built connectors and on-premises agents where they don't, including mainframe security managers such as RACF. That mixed approach is deliberate: a real enterprise estate is a blend of modern SaaS and older on-premises and mainframe systems, and an integration strategy earns its return only when it reaches all of it rather than the newest and easiest tier.

The platform treats authentication and provisioning as the separate integrations they are, so an application can federate login and have its account lifecycle automated through the mechanism that actually fits it, rather than being forced onto a single protocol it may not fully support. A single HR-driven event can create accounts across SCIM-enabled SaaS, directory-bound applications, and connector-reached legacy systems in one motion — and, just as importantly, revoke them the same way when someone leaves. The Avatier Trust Center publishes the compliance posture behind the platform for teams that need to verify it before a deployment decision rather than take a vendor's word for it.

Integration isn't the glamorous part of an identity program, but it is the part that determines whether the program governs the whole estate or only the applications that were easy to connect. Map each application to the protocol it can speak, keep authentication and provisioning as distinct integrations, and refuse to let the legacy systems settle into permanent-exception status. Do that, and the strategy you built the platform around actually reaches the applications it was meant to protect.