Identity Orchestration, Plainly Explained

Large organisations didn’t design their identity estate; they accumulated it. A cloud identity provider arrived with the SaaS programme, a second came with an acquisition, the on-prem directory never left, and a web access manager still guards the applications that pay the bills. Every application was wired to one of these by hand. That wiring is why anything in identity — a new provider, MFA on an old app, a plan for when the cloud IdP is down — takes years. And it is about to get harder, because AI agents now need identities too.

Identity orchestration is a layer that sits in the request path between your applications and your identity systems. When someone — or something — signs in or calls an application, the layer decides which identity provider to use, translates between protocols (SAML, OIDC, OAuth, LDAP, HTTP headers), maps attributes so every application sees what it expects, manages the session and enforces policy.

It stores no identities of its own. It replaces none of your identity products. It coordinates them.

Analysts describe the goal as an identity fabric: identity services that behave as one system even though they come from many vendors. Gartner told security leaders in February 2024 to strengthen their identity fabric, and KuppingerCole publishes a Leadership Compass on identity fabrics. Orchestration is how you build a fabric from what you already own.

A word on naming. Some identity vendors use “orchestration” for no-code login-journey designers inside their own product. That is useful, but different. This guide means cross-vendor orchestration at runtime: one layer in front of many providers and many applications.

• More than one identity provider is normal. In a 2024 Cloud Security Alliance survey of 950 professionals, 75% of organisations ran two or more identity providers and 11% ran five or more; 65% struggled to apply consistent policy across them.
• Legacy applications block stronger authentication. In the same survey, 71% said legacy-application incompatibility stopped them adopting stronger authentication, and 54% named technical debt as the top hurdle to modernising identity.
• Identity outages are a resilience problem. Only 28% said they could recover from an identity outage within an hour, while 45% said they needed to.
• Agents are arriving faster than controls. In a 2026 Cloud Security Alliance survey of 285 professionals, 84% doubted they would pass an audit of AI-agent access, and 44% were using or planning static API keys for agents.

All four surveys were sponsored by an identity orchestration vendor. The figures are consistent with what we see in practice; treat them as indicative, not definitive.

Three flows explain almost everything. First, a person signs in to a legacy application: the request reaches the layer, the layer sends the person to the right identity provider, and on the way back it hands the application the session or headers it already understands.

Second, the cloud identity provider fails. The layer notices, routes sign-in to a backup provider or on-prem directory, and maps attributes so the application cannot tell the difference.

Third, an AI agent calls a tool on a person’s behalf. Under OAuth 2.0 Token Exchange (RFC 8693), the agent’s token is exchanged for a short-lived one scoped to a single tool, recording both who the agent is and on whose behalf it acts. The Model Context Protocol’s authorisation rules forbid passing a user’s token straight through to upstream services — exactly the gap a token-exchange layer fills. The IETF’s WIMSE working group adopted an “AI Identity Management System” draft in September 2026 that reuses OAuth and workload identity for agents; it is still a draft.

InterpretationOur reading of the guidance. Regulators do not endorse products or approaches.

• OSFI B-13. MFA on legacy applications closes §3.2.7 gaps without rewrites. Retiring an out-of-support access manager answers §2.2.5. Identity-provider failover gives Principle 12 a continuity control you can test, including for a critical third-party dependency (§2.9.3).
• OSFI E-23 (effective 1 May 2027). E-23 governs models, not identity. But an agent access layer produces evidence an E-23 programme needs: who invoked a model-backed agent, on whose behalf, and which tools and data it touched.
• Federal: ITSP.10.033. The Cyber Centre’s ITSP.10.033 replaced ITSG-33 Annex 3A on 31 March 2026. Orchestration supports IA-02 (MFA for organisational users) on legacy applications, IA-08 (external credentials), and IA-09 and IA-13 (service and token authentication) for agents and workloads. Air-gapped deployment suits disconnected or Protected B environments, subject to the usual assessment.

1. Map the estate. Providers, directories, access managers and the top 50 applications by business criticality — and the protocol each one speaks.
2. Pick one painful application. A legacy app with an audit finding or a looming end-of-support date.
3. Prove it in weeks. Put the layer in front of that application, add MFA, measure sign-in latency, and show the same application working against a second provider.
4. Run the outage drill. Switch off the primary provider in a test window, time the recovery, and keep the record.
5. Scale by batch. Move applications in groups, with rollback, until the old platform can be retired.
6. Add agents deliberately. Bring agent traffic through the same layer with per-tool policy before agents touch sensitive systems.

• Which protocols do you translate, and which legacy patterns (headers, Kerberos, form-fill) are supported today — not on the roadmap?
• Is there any runtime dependency on your cloud? Can it run air-gapped?
• How do you remove your own single point of failure?
• What happens to our configuration if we leave?
• How are agent tokens scoped, how long do they live, and what does the audit record contain?
• What latency did a reference customer measure, and can we reproduce it in a proof of concept?