Federation is the authentication relationship that lets a user sign in through SAML or OIDC. Provisioning is the lifecycle process that creates, updates, and removes accounts and access, usually through SCIM or another lifecycle control. Teams need both if they want access to be both reachable and governable.
Why Federation and Provisioning Solve Different SSO Problems
Federation and provisioning often arrive as a pair, but they answer different operational questions. Federation is about how an identity proves itself at sign-in across systems. Provisioning is about whether the account, entitlements, and lifecycle state exist before, during, and after that sign-in. In enterprise sso, federation makes access possible, while provisioning makes access manageable.
That distinction matters because an SSO program can be technically “working” and still be incomplete. A user may authenticate successfully through a trusted identity provider, yet still lack the right account record, role assignment, or deprovisioning path in the target application. The result is a system that can admit users but cannot reliably govern them.
Federation also does not replace application-side identity lifecycle. If the downstream app keeps its own local accounts, you still need a way to create them, update them, and remove them in sync with joiner-mover-leaver events. That is why many enterprises treat federation and provisioning as complementary control layers rather than substitutes.
How the Two Work Together in Real SSO Architectures
In practice, federation handles the authentication trust relationship, usually through SAML or OIDC, so the service can accept an assertion or token from a trusted identity provider. Provisioning usually uses SCIM or a similar lifecycle integration to push account state and entitlement changes into the application. One manages the login transaction; the other manages the account record and access lifecycle.
That separation is useful because not every application supports the same depth of lifecycle integration. Some apps support federation without automated provisioning, some support provisioning without a strong federation story, and some support both. The design choice should reflect the access model of the application, the sensitivity of the data, and how quickly access must change when people move or leave.
For teams that are still defining the baseline, a practical reference point is the IAM and IGA Basics guide, which connects authentication, provisioning, access reviews, and entitlement governance into one operating model. For lifecycle-heavy environments, the Joiner-Mover-Leaver (JML) Guide is the more direct match because it focuses on user provisioning, deprovisioning, and cleanup of stale access.
What Breaks When You Have One Without the Other
If you deploy federation without provisioning, users may be able to sign in but still be blocked by missing accounts, stale entitlements, or manual onboarding delays. That creates shadow work for admins and often pushes teams into ad hoc local account creation, which weakens governance. If you deploy provisioning without federation, you can keep accounts current but still leave authentication fragmented, inconsistent, or harder to centralise.
The most common failure mode is assuming a federated login means the app is fully governed. It does not. Without lifecycle automation, leavers can retain access longer than intended, movers can keep old roles, and access reviews become inaccurate because the target system is out of sync with the source of truth. When the environment includes many applications, this gap becomes an operational control problem, not just an integration inconvenience.
The Workforce Identity Security Guide is useful here because it treats SSO, federation, provisioning, and recovery as one control surface rather than isolated features. For teams comparing architectures or vendors, the IAM and Identity Provider Buyer's Guide helps frame which capabilities belong in the identity provider and which belong in lifecycle management.
Risk and Threat Considerations
Federation concentrates trust in the identity provider, while provisioning concentrates lifecycle power in automation flows and administrative sources. If either is misconfigured, access can fail open, remain active too long, or be granted to the wrong principal. The practical risk is not just authentication failure, but stale, excessive, or unrevoked access that persists after a role change or offboarding event.
Failure mechanism: A valid federated login can still leave behind overbroad local entitlements, and a broken provisioning flow can silently prevent removal of access when the source record changes. Attackers and insider misuse both benefit from that gap because the organisation trusts a successful sign-in while the downstream account state is already wrong.
Impact: Users can retain access beyond their business need, leavers can keep active accounts, and auditors may see a misleading picture of control effectiveness. In higher-risk environments, the same gap can turn a single authentication trust relationship into persistent unauthorized access across multiple applications.
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 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Federation governs how workforce users authenticate into SSO. |
| IA-5 — Authenticator Management | Provisioning and federation both depend on lifecycle control of credentials and tokens. | |
| AC-2 — Account Management | Provisioning is the account lifecycle mechanism that creates, updates, and removes access. | |
| Recommendation — Apply IA-2 to ensure federated sign-in establishes organizational user identity. Use IA-5 to manage issuance, rotation, and revocation of authenticators and tokens. Use AC-2 to automate account lifecycle changes and disable access when roles change. | ||
Practitioner Guidance
What to verify: Check whether each critical application has both a federated sign-in path and a lifecycle path for create, update, disable, and delete. If provisioning is missing, document the compensating control for joiner, mover, and leaver events instead of assuming federation covers it.
Decision rule: If an application holds sensitive data or privileged workflows, treat federation alone as insufficient unless you can prove that account state and entitlements are removed quickly and consistently when access changes. If the application is low risk and lifecycle automation is not available, manual governance may be acceptable temporarily, but it should be explicit and time-bounded.
Practitioner takeaway: Federation answers “who can sign in,” while provisioning answers “what that person can keep, gain, or lose over time,” and mature SSO requires both to be wired into the same governance model.
Related resources from NHI Mgmt Group
- What is the difference between SAML federation and a standard single SAML connection in enterprise SSO design?
- What is the difference between SCIM provisioning and enterprise SSO in access management?
- What is the difference between SSO and workload identity federation?
- What is the difference between LDAP and SSO in enterprise identity architecture?
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 21, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org