How to enforce deprovisioning across SaaS apps

SaaS deprovisioning is enforced through a central identity provider connected to the HR system, with SCIM 2.0 for supported apps, SSO-only access, API fallbacks and automated verification after each offboarding event.

Use this workflow:

HRIS status change -> disable identity in IdP -> revoke sessions and credentials -> remove app assignments -> deprovision through SCIM or API -> verify completion -> alert on failures

This approach removes the need for IT teams to manually update every application. Microsoft Entra ID, Okta and Google Cloud all document identity architectures that use a central source of workforce data and an identity provider to manage downstream applications.

SaaS Deprovisioning Controls at a Glance

Control	Purpose	Recommended approach
Authoritative identity source	Defines whether a person is active, terminated or changing roles	Use the HRIS or another approved employee system of record
Central identity provider	Controls authentication and application assignments	Use Microsoft Entra ID, Okta, Google Cloud Identity or another enterprise IdP
SCIM provisioning	Creates, updates and deactivates SaaS accounts	Use SCIM 2.0 for supported applications
SSO enforcement	Prevents users from bypassing central access controls	Require SAML or OIDC sign-in and disable direct login where supported
API automation	Handles applications without SCIM	Use vendor APIs, workflow automation or an integration gateway
Verification	Confirms that access was removed	Reconcile IdP records with SaaS account status and audit logs
Exception management	Covers applications that cannot be automated	Give every exception an owner, deadline and compensating control

1. Make One System Authoritative for Employee Status

Choose one system as the source of workforce identity data. In most organisations, this is the HRIS.

The HRIS should provide events such as:

• New hire
• Termination
• Contractor end date
• Department or manager change
• Leave of absence
• Return from leave
• Change in employment status

The HRIS should not normally connect directly to every SaaS application. It should update the central identity provider, which then manages authentication, groups and application assignments.

Google's reference architecture describes this model as an authoritative source that creates, manages and deletes identities, combined with a central identity provider for authentication across applications.

Why This Matters

Without one lifecycle source, applications can hold conflicting records:

• The HRIS marks an employee as terminated.
• The IdP account remains active.
• The employee retains a direct login to a finance application.
• A SaaS administrator forgets to remove a privileged role.

A central lifecycle decision gives every downstream system the same status to act on.

2. Disable the Identity Immediately

When a termination or high-risk access event occurs, disable the user in the identity provider before starting lower-priority cleanup.

The first response should normally include:

1. Disable the central identity.
2. Revoke active sessions and refresh tokens where supported.
3. Remove privileged roles and group memberships.
4. Remove application assignments.
5. Trigger downstream deprovisioning.
6. Rotate or revoke credentials controlled by the user.

CIS Control 6.2 recommends an automated process for revoking access by disabling accounts after termination, rights revocation or a role change. CIS also notes that disabling an account instead of deleting it can preserve the audit trail.

Do not delete the account first. A disabled account preserves evidence, supports investigation and may allow controlled restoration. Delete it later only when retention, legal hold and data ownership policies permit.

3. Use SCIM for Supported SaaS Applications

SCIM, or System for Cross-domain Identity Management, should be the default deprovisioning method for SaaS applications that support it.

A SCIM integration allows the identity provider to:

• Create user accounts
• Update names, email addresses and other attributes
• Add or remove group memberships
• Deactivate accounts
• Delete accounts where the application supports it
• Synchronise lifecycle changes with the SaaS application

Microsoft Entra ID documents SCIM as a standard method for provisioning and deprovisioning users and groups in SaaS applications. Okta uses SCIM-based provisioning to synchronise lifecycle data between its directory and external applications.

Configure the Deprovisioning Mapping Correctly

For each SCIM application, verify that:

• The user's unique identifier remains stable.
• The active attribute maps correctly.
• Removing an assignment sends a deactivation event.
• Removing group membership removes the related entitlement.
• Administrator accounts follow a separate control path.
• The application can reactivate an account without creating a duplicate.
• The connector records successful and failed responses.

Microsoft Entra describes a SCIM disable operation as setting the user's active property to false. The effect of disable and delete depends on the application. Some applications deactivate the account while retaining its data. Others support permanent deletion.

Do Not Confuse Deactivation With Deletion

Deprovisioning usually means that the user can no longer access the application. It does not necessarily remove the user record or the user's data.

Use this sequence:

• Deactivate immediately to stop access and preserve records.
• Transfer ownership of files, dashboards, repositories and workflows.
• Delete later when retention and legal requirements allow it.
• Document exceptions when the vendor does not support deletion.

Okta also distinguishes deprovisioning from deletion. In many integrations, removing an assignment deactivates the external account without deleting it.

4. Enforce SSO, but Do Not Rely on SSO Alone

SSO controls how a user signs in. It does not, by itself, remove the downstream SaaS account or revoke every credential.

Configure each workforce SaaS application to:

• Require SAML or OIDC authentication.
• Disable local password login where the vendor supports it.
• Prevent self-registration with corporate email addresses.
• Restrict application administrators.
• Remove direct assignments that bypass approved groups.
• Block or review personal OAuth applications.
• Require an application owner and approved business purpose.

SAML just-in-time provisioning is not enough for deprovisioning. Microsoft states that SAML JIT can create and update application users, but cannot delete or deactivate them.

The control split is straightforward:

Use SSO to control sign-in, SCIM or APIs to control the downstream account, and monitoring to confirm that both controls worked.

5. Build API Fallbacks for Applications Without SCIM

Some SaaS applications do not support SCIM. For those applications, use a documented fallback based on:

• Vendor REST APIs
• Admin APIs
• Identity-provider workflows
• IT service management automation
• Integration platforms
• A partner provisioning gateway
• Manual tasks with enforced deadlines

Microsoft Entra documents alternatives for applications without standard SCIM support, including Microsoft Graph, REST or SOAP interfaces, PowerShell, custom connectors and partner gateways.

Match the control to the application's risk:

Application type	Required control
Identity, finance, source code or production systems	Automated deprovisioning through a tested API or SCIM integration
Systems containing sensitive data	Automated deactivation, ownership transfer and verification
Low-risk collaboration tools	SCIM where available, otherwise scheduled API or manual removal
Applications with no administrative API	SSO restriction, named owner, short manual SLA and recurring access review
Personal or shadow SaaS accounts	Discovery, ownership review and corporate-domain controls

A manual exception is not complete because someone created a ticket. The ticket should close only after the application owner confirms that the account was disabled or removed.

6. Revoke More Than the User Account

Disabling a SaaS user may not invalidate every credential associated with that user. Include these objects in the offboarding runbook:

• Active browser sessions
• Refresh tokens
• Personal access tokens
• API keys
• SSH keys
• OAuth grants
• Mobile sessions
• Connected integrations
• Webhooks created by the user
• Service accounts owned by the user
• Shared credentials
• Application-specific passwords

The revocation method depends on the vendor. If the vendor cannot revoke a credential automatically, transfer ownership and rotate the credential manually.

This control matters most for developers, administrators, sales engineers and other users who may create long-lived tokens outside the normal SSO flow.

7. Verify That Deprovisioning Succeeded

A successful provisioning log does not prove that the user lost access. Check the resulting state in the target application.

For each deprovisioning event, record:

• User identifier
• HR event timestamp
• IdP disable timestamp
• SCIM or API request timestamp
• Target application response
• Final account status
• Remaining groups or roles
• Token and session status
• Exception reason
• Remediation owner

Useful checks include:

1. Confirm that the user is disabled in the IdP.
2. Confirm that the user is no longer assigned to the SaaS application.
3. Confirm that the SaaS account is inactive.
4. Confirm that privileged roles and groups were removed.
5. Confirm that active sessions and tokens were revoked.
6. Check for a second account under an alias.
7. Confirm that ownership of business data was transferred.

Microsoft's generic SCIM guidance states that its provisioning cycle runs every 40 minutes. A correctly configured connector can therefore still leave a delay before the target application reflects the change. Define a separate emergency process for immediate access termination.

8. Monitor Failures and Drift Continuously

SaaS applications change, connectors fail and administrators can create accounts outside the approved workflow. Monitor for:

• Failed SCIM or API deprovisioning requests
• Accounts still active after the offboarding SLA
• Direct user assignments instead of approved group assignments
• SaaS accounts with no matching IdP identity
• Dormant accounts
• Local-password logins in SSO-managed applications
• Former employees with active API tokens
• Applications with no tested deprovisioning method
• Changes to application administrators
• Repeated connector errors or rate-limit failures

Maintain a SaaS application inventory with:

• Application name
• Business owner
• Technical owner
• Data classification
• Authentication method
• Provisioning method
• Deprovisioning method
• Admin account
• Contract owner
• Data retention requirements
• Last successful deprovisioning test
• Exception status

9. Test the Process Before Relying on It

Run a controlled test for each important application:

1. Create a test user.
2. Assign the user through the normal group or role.
3. Confirm that provisioning succeeds.
4. Remove the user from the group or disable the identity.
5. Confirm that the target account becomes inactive.
6. Attempt access through an existing browser session.
7. Test token and API-key behaviour.
8. Confirm ownership transfer and audit logging.
9. Restore the test user only if the application supports safe reactivation.

Test termination, role change and application removal separately. A system may handle employee termination correctly while leaving an application entitlement in place after a department change.

The Recommended Operating Model

Use three control layers:

1. Decide status: The HRIS records employment changes and sends them to the IdP.
2. Remove access: The IdP disables the identity, removes assignments and triggers SCIM or API actions. SSO blocks unmanaged sign-in paths, while token and credential controls close other access routes.
3. Prove the result: Verification checks the target SaaS account, roles, sessions, tokens and ownership. Alerts and exception owners handle failures.

Review the application inventory at least quarterly to find orphaned, dormant and directly assigned accounts.

Measure completion by the state of the target SaaS systems, not by whether the HR ticket closed. Every account, entitlement, session and credential associated with the user should be disabled, revoked or transferred.