TL;DR
Removing a user from the IdP does not necessarily disable a local account in a non-federated store application. It may also leave roles, shared credentials, or active sessions untouched. Retailers with high-volume or seasonal workforce changes need offboarding that treats authentication, account state, entitlements, credentials, and sessions as separate controls, then verifies each required application action.
Why are critical applications at retail companies still outside standard authentication and access review processes?
For retailers managing constant workforce change, this is an everyday operating question. Central access can be removed correctly while local accounts, roles, credentials, or sessions remain untouched in applications outside the standard workflow.
For retailers with frequent workforce changes, access removal is not an occasional exception. It is a recurring identity workflow. The central process may work exactly as designed: HR records the departure, the identity provider disables the user, and group membership changes. Yet a local account can remain active inside a store, workforce, vendor, or operational application that does not participate in that workflow.
The mismatch is easy to miss because the IdP shows the person as removed. That proves the central identity changed. It does not prove that every application account, role, credential, token, and session changed with it.
Offboarding is a state problem
A single user can have several access states at once. The workforce identity can be inactive. The IdP assignment can be removed. A local application account can still be enabled. A shared credential can remain unchanged. An active browser or mobile session can continue until it expires or is explicitly terminated.
That does not mean every offboarding requires every action. It means the workflow should define which states must change for each application. A federated app may need assignment removal and session revocation. A non-federated app may require an account disable, role removal, password rotation, MFA-factor change, or a combination of those actions.
Why store and operational applications fall outside the IdP
Some applications don't support SAML or OIDC, so users sign in with a local username and password.
Some support authentication but not SCIM, leaving account creation and deprovisioning manual. Some are vendor, mobile, legacy, or on-premises applications with limited administrative interfaces. Others make SSO or lifecycle features available only through a higher licensing tier.
These are application constraints, not proof of a weak retail identity program. The architecture should make the boundary explicit and provide a controlled path for the actions the IdP cannot perform directly.
Account disable and session logout are not interchangeable
Account deprovisioning changes whether the account can be used in the future. Session termination addresses access that is already active. For supported applications, Okta Universal Logout can trigger Cerby to extend logout and access-revocation actions to apps Okta cannot reach on its own. Cerby's integration material describes a deterministic, policy-triggered response with audit data returned to central systems.
That capability is specific to Okta, configured policies, and supported applications. It should not be generalized as a universal feature for every IdP or every retail app. It is also one part of offboarding. The account, entitlement, shared-credential, and MFA states still need their own required actions.
What a complete retail offboarding workflow does
A closed-loop workflow begins with an authoritative departure or role-change event and ends only when the target application state is known. The workflow should:
- Identify every application account and shared-access path assigned to the user.
- Remove or update IdP assignments and groups according to policy.
- Disable or delete the local account where the application requires a direct action.
- Remove roles and entitlements that can survive a central identity change.
- Rotate shared credentials or transfer organization-owned factors where applicable.
- Terminate active sessions when the application and integration support it.
- Verify each action and return completion, failure, and exception data to the central workflow.
How Cerby extends the retail identity perimeter
Cerby integrates with existing identity providers and governance systems, then executes approved actions inside supported disconnected applications. It can use APIs or managed UI automation to create accounts, update permissions, disable access, rotate credentials, support MFA workflows, and record the result. Users can launch supported disconnected apps from an existing IdP dashboard without seeing the underlying credentials.
For shared accounts, Cerby's current materials describe organization-owned MFA factors, credential non-disclosure, individual attribution, and automated rotation or revocation. These controls are relevant where a retail workflow actually uses shared access. Don't add them to scope by assumption.
Test the busiest path, not the cleanest demo
Choose store and operational applications with meaningful joiner, mover, or leaver volume. Map the identity event to the exact application states that must change. Then test normal operation, app unavailability, UI change, duplicate accounts, shared access, active sessions, and exceptions that require a local owner.
The relevant outcome is simple: when the identity program says access is gone, the organization can show which application states changed, which did not, and who owns the next action. That turns retail offboarding from an assumption into an observable control.