Why people can stay signed in to SaaS apps after you disable them in your identity provider

When someone leaves and you disable them in your identity provider, such as Okta or Microsoft Entra ID, they can’t sign in with their company account anymore. But the SaaS apps they already had open may keep them signed in, because disabling them doesn’t always end that. What is an identity provider (IdP)? covers the basics. The full list of what to close when someone leaves is in the account checklist for onboarding and offboarding.

What disabling ends, and what it doesn’t

When someone signs in to a browser app through single sign-on (SSO), they usually end up signed in twice. Microsoft describes this for Entra ID: one sign-in belongs to Entra ID, and the other is issued by the app itself. Each is kept in a cookie, a small file the browser stores so the site remembers you.

Disabling someone in the identity provider ends the first sign-in and blocks new ones. The second belongs to the app, so it lasts until it expires or the app ends it. Microsoft adds that how often an app sends people back to Entra ID to check depends on the app. While its own sign-in is valid, the app might never send them back at all.

What the identity providers’ documentation says

The difference between products is whether they can reach the app’s own sign-in, and in which apps.

Microsoft Entra ID

Microsoft’s guidance says, “Microsoft Entra ID can’t directly revoke a session token issued by an application.” If you disable the account and select “Revoke sessions,” the app’s sign-in still runs until it expires. The exception is an app that learns the account was disabled and is set up to end its own sign-ins.

Continuous access evaluation goes further. It lets Microsoft services act on Entra ID events after sign-in. When an account is disabled or deleted, or its password changes, Exchange Online, SharePoint Online, and Teams cut off Microsoft 365 apps such as Outlook within minutes. The event can take up to 15 minutes to arrive. Microsoft’s tables show that Word, Excel, and PowerPoint in a web browser aren’t covered, and the Teams apps only partly.

Okta

Okta’s help center says deactivating a user stops all their active sign-ins in Okta itself. Its developer guide adds that this “doesn’t affect a user’s existing sessions or tokens within an app.”

Universal Logout is Okta’s way to reach the app. Okta asks a supported app to sign the person out, and the app then tries to end their sign-ins, fully or partly depending on the app. Okta’s list gives full support to Box, Google Workspace, Salesforce, Slack (Enterprise), Zoom, and others. Microsoft 365 and other Microsoft apps get only partial support. There, people stay signed in until their current access expires or they sign out.

Apps that use a password, and shared accounts

Some apps don’t connect through SSO. For those, a tool types the password for the person. It can be an identity provider’s password fill-in, such as Okta’s Secure Web Authentication or Entra ID’s password-based SSO, or a password manager. In the pages we read for these features, we found nothing saying that disabling someone ends the sign-in they opened this way.

With these apps, knowing the password lasts longer than any sign-in. 1Password’s offboarding steps tell you to change the passwords the person could reach. If they were an owner or administrator, it says to assume they saw every password in the vaults they managed. A shared account, one login that several people use, can’t be disabled, because the people who stay still need it. So until its password changes, someone who left may sign in again from another browser.

What to do on the last day

Each step comes from the vendor’s own documentation.

1. In Okta, start Universal Logout for the person. It asks supported apps to end the person’s sign-in without waiting for it to expire, and each app has to be set up for it first. In orgs with Adaptive MFA only, the one way to start it is “Clear user sessions” with the option for apps with logout enabled. With Identity Threat Protection, you can also end their sign-in from the user’s risk profile.
2. Disable the person in the identity provider to end its own sign-in. In Entra ID, clear “Account enabled” and select “Revoke sessions.” In Okta, deactivate the user.
3. Use the forced sign-out in apps whose admin console has one. Microsoft 365’s steps for a departing employee are to reset the password and select “Sign out of all sessions.” The person is asked to sign in again within an hour. In Google Workspace, suspending a user resets their sign-in cookies. Google notes that resetting cookies doesn’t sign people out of apps such as Gmail and Google Drive for desktop.
4. Remove or disable the person’s account in each app. Microsoft calls removing people from apps an effective way to cut access. That holds especially for apps that keep their own sign-in or let people sign in directly.
5. Change the passwords the person knew. That covers shared accounts and password-based apps they could sign back in to. The limits of changing shared passwords every time someone leaves covers why this step gets heavy.

Gaps that remain after these steps

The first gap is apps that support neither Universal Logout nor continuous access evaluation, and that have no forced sign-out in their admin console. There, the sign-in lasts until the app’s own limit. If the person worked in company-managed Chrome, you can still clear those cookies. Okta’s Identity Threat Protection can do it for managed Chrome profiles only, and it needs that product set up. The Google Admin console’s “Clear cache and cookies” command for managed Chrome browsers skips cookies for Google services.

The second gap is shared accounts where nobody is sure who knows the password. Without a list of passwords to change, step 5 misses some. Anyone who left and still knows a missed password may sign back in. How to take inventory of shared accounts and what to record covers how to build it.