The Real Cost of Lingering Access: Why an IdP Is Not the Whole Offboarding Process

Offboarding is a distributed process

An employee rarely has one identity and one account. Over time they collect access to customer systems, finance tools, vendor portals, local applications, shared credentials, physical spaces, and company equipment. Some of those resources are centrally managed. Others belong to a department or to the one person who administers that system.

That is why a successful offboarding is not a single click. It is a coordinated set of approved changes, carried out by different responsible people, with a way to see which changes are still pending and which were completed.

What an identity provider covers—and what it may not

An identity provider is often the best place to disable the company identity and the applications connected to it. But it can only control what has been connected, inventoried, and configured correctly.

• Applications with their own usernames or local accounts
• Vendor and partner portals owned by individual departments
• Shared credentials that must be rotated
• Legacy systems that are not connected to single sign-on
• Physical keys, badges, tokens, laptops, and other equipment
• Accounts created outside the formal IT purchasing process

The risk is not theoretical

In May 2021, a New York credit union asked its IT support firm to disable a terminated employee’s access. The access was not disabled. Two days later, the former employee used the same credentials to enter the file server and delete more than 20,000 files and almost 3,500 directories—about 21.3 gigabytes—including mortgage application files and material related to anti-ransomware protection.

A different failure occurred in March 2020. A former executive at a medical device packaging company used a fake account he had created while still employed to alter or delete more than 117,000 shipping records. The intrusion delayed shipments of personal protective equipment during the pandemic and resulted in a federal prison sentence and $221,200 in restitution.

The two cases are different, but the operational lesson is the same: revocation intent is not revocation completion. A request can be valid, approved, and urgent—and still remain unfinished or miss an access path nobody recorded.

Approval and completion are different facts

The person who creates an access change should already have the authority to request it under the organization’s own policies. Permission Report does not decide whether an employee deserves access. It accepts the request as approved work and routes it to the person responsible for carrying it out.

That responsible manager then records a written sign-off after completing the change in the real system. The sign-off connects the approved request to a named responder and a completion time. Until that happens, the work remains visible as pending or overdue.

What a defensible completion record should preserve

Permission Report keeps those facts together and makes the resulting history reviewable by employee, by permission, or across the organization. It does not reach into every external system to perform the change itself. Its role is to make the work visible, assign accountability, and retain the sign-off.

• The employee affected by the change
• The permission or equipment involved
• Whether the approved action was an addition, removal, assignment, return, or verification
• Who originated the request and when it was meant to take effect
• Who completed or cancelled the work
• The responder’s written sign-off or cancellation reason
• When the response was recorded

A better offboarding outcome

Good offboarding combines multiple controls: disable the central identity, revoke accounts in the systems that sit outside it, recover physical assets, rotate shared credentials, and verify that each responsible person completed their part. The goal is not simply to produce a checklist. It is to close every item on it.