Users can be created or updated at login, but the model breaks down for ongoing lifecycle events. Revocations, offboarding, and permission changes may not propagate in real time, so the app can drift from the identity provider. That leaves security teams with stale access data and a higher chance of unauthorized use.
Why SAML Login Flows Can Create User Lifecycle Drift
saml is built to authenticate users at sign-in, so it can create or refresh an application account when a person logs in. That makes it useful for access initiation, but it is not a lifecycle synchronization protocol. If an organisation relies on SAML alone for provisioning, the app often learns about the user only at login, which leaves gaps between identity changes and the app’s current state.
That distinction matters because provisioning is not just about first-time creation. Real identity administration includes updates, revocation, offboarding, and permission removal, and those events need to propagate without waiting for a future interactive login. In practice, SAML can carry assertions that a user is valid right now, but it does not continuously reconcile account state or entitlement drift.
The result is a control model that looks functional on day one and becomes fragile over time. A user may keep access after a role change, termination, or group update if the application only refreshes state when the person authenticates again. For organisations trying to keep access current across many applications, that means SAML can be a source of stale records rather than a complete provisioning mechanism.
What Breaks When Revocation and Role Changes Depend on Login
When account changes are tied to the next SAML login, the system becomes dependent on user behaviour and session timing. A terminated user who does not return to the app may still exist there with active or semi-active access data, and a transferred employee may retain permissions that no longer match their job. The control failure is not the login itself, but the delay in propagating lifecycle events.
That delay also affects operational confidence. Security teams may believe the identity provider is the source of truth while the application still contains older entitlements, group membership, or account status. This creates a split-brain view of access, where the directory and the application no longer agree on who should be able to do what.
For a clearer lifecycle model, see the NHI Lifecycle Management Guide and the Workforce Identity Security Guide, both of which emphasise provisioning, offboarding, and access review as continuous controls rather than one-time events.
Why SCIM Solves the Gap More Cleanly
SCIM is designed for lifecycle synchronization, not just authentication. It gives the identity system a structured way to create, update, and deactivate accounts independently of whether the user logs in again. That means joiner, mover, and leaver events can flow into the application as administrative changes, which is the part SAML alone does not handle well.
In a mature setup, SAML and SCIM are complementary, not interchangeable. SAML establishes the session and proves the user’s identity at sign-in, while SCIM keeps the application’s user object, attributes, and group state aligned with the directory over time. If SCIM is missing, the organisation often falls back to manual cleanup, batch jobs, or login-triggered updates, all of which widen the window for stale access.
This is why lifecycle controls belong in the provisioning design, not as an afterthought. When identity state is updated only at login, the system is biased toward access persistence. When SCIM is present, revocation and attribute change can happen even if the person never returns to the application.
Risk and Threat Considerations
The main risk is lingering access after revocation, which increases the chance of unauthorized use, especially for former employees, contractors, and users whose roles have changed. The same gap can also mask excessive permissions because the application may keep outdated entitlements long after the identity provider has been corrected.
Failure mechanism: SAML login flows update identity state only when a user authenticates, so revocation and entitlement changes can stall until the next interactive session, leaving the app out of sync with the identity source.
Impact: Stale accounts, delayed offboarding, and incorrect permissions increase exposure to misuse, audit findings, and avoidable blast radius if a compromised account remains usable longer than intended.
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 NIST CSF 2.0 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) | SAML login flows authenticate users and establish access at sign-in. |
| IA-5 — Authenticator Management | Lifecycle drift often leaves credentials or access paths active after role changes or offboarding. | |
| AC-2 — Account Management | The issue is stale account state when provisioning and deprovisioning are not synchronized. | |
| Recommendation — Use IA-2 to ensure login authentication is enforced at account creation and access use. Apply IA-5 to manage credential issuance, renewal, and revocation alongside account changes. Use AC-2 to ensure accounts are created, modified, disabled, and removed through a governed lifecycle. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | This subject is about keeping authentication and access state aligned across systems. |
| Recommendation — Implement PR.AA-05 to synchronize identity changes and access removal across connected apps. | ||
Practitioner Guidance
What to verify: Confirm whether the application supports non-login lifecycle updates for create, update, disable, and group change events. If it does not, treat SAML as authentication only and assume access state will drift unless you add another reconciliation path.
Decision rule: If a system can grant meaningful access, it should also be able to remove that access without waiting for the user to sign in again. If revocation depends on login, that is a lifecycle weakness, not a provisioning strategy.
Practitioner takeaway: Use SAML for sign-in and SCIM for lifecycle state, because the security difference is whether access can be withdrawn immediately or only when the user eventually comes back.
Related resources from NHI Mgmt Group
- What happens when WordPress authentication is tied to legacy login and logout flows instead of a central identity layer?
- What breaks when OAuth consent phishing happens inside the browser instead of at login?
- How should teams migrate users from Azure AD B2C to Entra External ID without breaking login flows?
- What breaks when organisations use OAuth for login instead of OIDC or SAML?
