Disabling SSO may leave a finance application session active

Disabling a person's company sign-in is an important offboarding step, but it does not automatically prove that every finance application has ended the person's access. An application may maintain its own active session or offer a separate local sign-in route. Coordinate the identity administrator and each application owner. The completion criterion is that the intended access is actually removed, not merely that one central account shows a disabled status.

Microsoft's Entra guidance explains that applications can issue their own session tokens and that Entra cannot directly revoke a session token issued by an application. It also notes that revocation timing depends on how access is granted. Use the current documentation for each deployed service to establish its behavior. Do not assume that every application using SSO responds to account disablement in the same way or on the same timetable.

List the ledger, payroll, bank, billing, expense, reporting and document systems the person used. Identify administrative rights, payment authority, exports, mobile access and any alternate account. Include accounts created directly with a vendor before centralized sign-in was introduced. Compare the access inventory with application records rather than relying exclusively on the identity provider's assigned-app list, which may not capture every independent account.

Separate the person's interactive access from integrations and shared business ownership. A scheduled connector may use credentials created by that person but serve the company. A subscription may also name them as billing contact or primary administrator. Transfer required ownership and service responsibility through the supported process while removing personal access. Do not preserve a departed employee's login as the permanent way to keep an automation running.

Identify unfinished finance work that needs a new owner: pending approvals, drafts, exceptions and recovery contacts. Reassign it without impersonating the departing user or rewriting the historical author of completed actions. Preserve the audit trail. The person taking over should be able to see which tasks remain outstanding and which decisions were already made, while the former user's permission to perform new work is removed at the required time.

Have the identity administrator perform the appropriate account and session actions under the company's procedure. Have application administrators remove or suspend the corresponding user, revoke application sessions where supported and review local sign-in methods. Record which controls were applied and any documented delay. If a vendor requires support assistance for a critical revocation, escalate through the established channel with the required account evidence.

Check recovery routes and delegated permissions that could restore access. An old recovery email, local password, additional administrator or delegated mailbox permission can create a path outside the usual SSO flow. Review them in the relevant system rather than assuming that changing the person's primary email resolves every dependency. Do not share another employee's credentials as a temporary workaround for unfinished tasks; use an authorized replacement role.

Where compromise is suspected, follow the incident-response process in addition to routine offboarding. The security owner may need to preserve evidence and take broader containment steps. Distinguish confirmed access from a possible exposure window, and avoid making unsupported claims about what the person or attacker did. The finance team should provide the transaction and approval context while qualified administrators investigate the technical activity.

Use an approved test account to understand how each service handles an existing session, a new sign-in and any local route. Do not obtain or use the departing person's password to test their account. An administrator can inspect account state and supported session controls, and the organization can maintain a repeatable test for future offboarding. Record the application configuration because behavior may depend on plan, integration and policy settings.

Test a harmless permitted action before revocation, apply the planned controls and verify that the same action is denied afterward. Include a session opened before the change and a fresh attempt afterward. A successful block on the new attempt does not establish that the old session ended. Keep the test narrow and synthetic, avoiding real payment instructions or sensitive records that the test account does not need.

If the service has a documented delay, identify the risk during that interval and any additional supported control the company can apply. Do not claim immediate termination without evidence. For a high-impact permission such as payment release, the responsible owner may need a specific containment step while technical revocation completes. Record the chosen measure and verify the final state rather than treating the delay as an unexplained exception that no one owns.

Reconcile the access inventory to completed actions and unresolved items. Confirm that the company still has authorized administrators and backup approvers for essential work. Check that integration jobs continue under approved ownership and that no personal credential was left active merely to avoid a failure. Review the next relevant processing run for exceptions caused by the transition, especially where the departing user had been the sole approver or connection owner.

Preserve historical transaction attribution and the records needed for later questions. Access removal should not delete accounting evidence or make completed approvals appear to belong to the replacement employee. Ask the application owner how archived users appear in reports and audit history. If a user deletion would remove important context, choose the supported suspension or archival approach that satisfies the company's access and retention requirements.

Maintain a service-by-service offboarding record showing what blocks new access, what ends existing sessions, what happens to local accounts and who verifies the result. Update it when a finance application or identity integration changes. The completed process gives the business a clear answer about both sides of the transition: the former user's authority has ended, and the authorized team can continue the work with intact records and controlled access.