Identity federation lets one system trust another system’s authentication event, while user provisioning creates, updates, or removes the account itself in downstream applications. SAML is a federation protocol. SCIM is a provisioning protocol. Teams need both when they want central login plus consistent account lifecycle management across SaaS tools.
How federation and provisioning split the job
identity federation is about trust across boundaries: one system accepts an external identity provider’s authentication result instead of making the user sign in again. user provisioning is about account state in the target app: creating the account, updating attributes, or disabling it when the source of truth changes. The two solve different problems, even though they are often deployed together.
That distinction matters operationally. Federation answers, “Can this person prove who they are here?” Provisioning answers, “Should this person have an account here at all, and with what attributes or entitlements?” A clean SSO experience can still leave stale accounts behind if provisioning is missing, while perfect provisioning does not replace the need for trusted login.
For account lifecycle work, the best mental model is joiner, mover, leaver. Federation mostly affects the authentication path, while provisioning governs whether downstream SaaS tools have the right account state as people change roles or leave. NHIMG’s Joiner-Mover-Leaver (JML) Guide and IAM and IGA Basics both frame that separation clearly in lifecycle terms.
Where each control sits in the stack
Federation usually sits in the login flow and relies on trust between an identity provider and a service provider, commonly through standards such as SAML or OpenID Connect. Provisioning usually sits in the admin or sync path and pushes account data through a protocol such as SCIM. In practice, federation is about assertions and session establishment, while provisioning is about account creation and deactivation.
That stack placement changes implementation choices. If a SaaS app supports federation but not provisioning, users may get seamless sign-in yet remain overprovisioned after a role change. If it supports provisioning but not federation, admins can keep accounts aligned but users may still rely on local credentials or repeated password management. The common enterprise pattern is to use federation for access and provisioning for lifecycle control.
When teams want a concrete SCIM reference, NHIMG’s SCIM and Automated Provisioning Guide explains what automated provisioning covers and what it does not. For the authentication side of the house, OpenID Connect Core 1.0 is the relevant external specification for layered authentication and single sign-on.
Why teams usually need both
Most organisations need both capabilities because central login and account lifecycle are different control objectives. Federation reduces password sprawl and helps standardise authentication. Provisioning keeps downstream applications synchronized with authoritative source data, which is how organisations prevent orphaned accounts, stale entitlements, and delayed deprovisioning.
That is especially important in multi-SaaS environments. A federated login may still succeed long after someone should have lost access if the app keeps a local account active. Conversely, a user may be provisioned correctly but still authenticate through an old, unmanaged path if federation is not configured consistently. The strongest posture comes from pairing federation with automated joiner-mover-leaver workflows and regular reconciliation of app accounts against the source of truth.
For practitioner navigation, NHIMG’s Workforce Identity Security Guide ties federation and provisioning together in the employee access lifecycle, while Identity Provider and SSO Security Guide shows why IdP trust, token handling, and recovery controls still matter even when provisioning is automated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Federation governs how workforce users authenticate to downstream apps. |
| IA-5 — Authenticator Management | Provisioning and federation depend on safe handling of tokens, assertions, and credentials. | |
| AC-2 — Account Management | User provisioning creates, updates, and removes downstream accounts. | |
| Recommendation — Use IA-2 to require strong authentication for federated workforce access. Use IA-5 to manage credential and token lifecycle for SSO integrations. Use AC-2 to automate account creation, change, review, and disablement. | ||
| OWASP ASVS | V10 — OAuth and OpenID Connect | Federation commonly uses OpenID Connect for authentication and SSO. |
| V8 — Authorization | Provisioning determines what account state and entitlements the app should enforce. | |
| Recommendation — Verify OIDC flows, token validation, and redirect handling in federated login. Verify authorization logic matches the provisioned account state and roles. | ||
Practitioner Guidance
What to verify: Check whether the app supports just-in-time account creation, full SCIM lifecycle actions, or only login federation. Those are materially different capabilities, and confusing them is a common design mistake during SaaS rollouts.
Decision rule: If the business risk is stale access after role changes or departures, prioritise provisioning and deprovisioning controls first. If the risk is fragmented authentication or duplicated passwords, prioritise federation first, then add provisioning to close lifecycle gaps.
What good looks like: A user can sign in once through the trusted IdP, while the target app automatically creates, updates, and disables the account based on authoritative HR or identity data. The two control planes should be linked, not treated as substitutes.
Practitioner takeaway: Federation controls how the user authenticates; provisioning controls whether the app should still recognise that user at all. Treat them as complementary controls, because SSO without lifecycle automation leaves residual access behind.
Related resources from NHI Mgmt Group
- What is the difference between user access and approval authority in AI-assisted processes?
- What is the difference between a framework that handles login and one that supports enterprise identity governance?
- What is the difference between managed authentication and self-hosted identity infrastructure?
- What is the difference between OAuth/OIDC support and enterprise identity governance?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org