Every seller login left open is a way back in.

Section 01

The access risk everyone underestimates

When a TSA ends, attention goes to the systems and the data. Identity, who can still log in to what, gets far less, and that is the gap that bites later. Through the TSA the seller's people and systems held legitimate access to your environment to deliver the services. The question at exit is whether all of that access actually goes away, and the honest answer is often no.

Orphaned access is the result: accounts, credentials, and connections that the seller no longer needs but that still work. They are dangerous precisely because they are forgotten. No one is watching them, no one remembers granting them, and they sit as a standing path into your systems held by a party that is no longer your service provider and no longer your responsibility to trust.

Deprovisioning is the discipline of closing every one of those paths deliberately. It is not exciting and it does not show up in a demo, but it is the difference between an exit that genuinely separates the two companies and one that leaves the seller with quiet, unmonitored access to a business it has sold. Treat it as a named workstream with an owner, not as cleanup someone will get to.

Section 02

Inventorying every identity the seller holds

You cannot remove what you have not found, so deprovisioning begins with a complete inventory of seller access. That means every named user account belonging to seller staff, every shared or generic account used to deliver services, every administrative and privileged account, and every external connection from the seller's environment into yours. The goal is a single list of every way the seller can reach your systems.

Building that list is harder than it sounds because access accumulates quietly. Accounts get created for a one off task and never removed, permissions get widened during an incident and never narrowed, and integrations get stood up between the environments and forgotten. The inventory has to dig past the obvious user directory into the integrations, the service accounts, and the access granted directly on individual systems.

Pull from multiple sources to make the inventory honest. The identity platform shows named users, but firewalls, application logs, and configuration reveal connections and embedded credentials the directory never sees. Cross checking these sources is how you find the access that a single view would miss, and the access a single view misses is exactly the access that becomes an orphan after exit.

Section 03

Sequencing deprovisioning against the cutover

Deprovisioning has to be sequenced against the exit, not done in a single sweep, because the seller still needs access until each service is actually cut. Remove it too early and you break the very services the TSA is still providing. Remove it too late, or never, and you leave the orphaned access the whole exercise exists to prevent. Timing is everything.

Tie each access removal to the milestone that makes it safe. When a service migrates and the seller stops providing it, the access that supported it should be revoked at that point, not left until a general tidy up that may never come. Mapping access to the services it supports lets you withdraw it in step with the exit, so coverage holds while a service is live and ends the moment it is not.

Treat the final cut as a hard boundary. At full exit, every remaining seller account and connection should be revoked on a defined date, with nothing left running on the assumption it might still be needed. A residual access that is kept just in case is the classic source of the orphan. If something turns out to be needed after the cut, it should be requested and granted afresh, not left open by default.

Section 04

Service accounts and machine identities

Human accounts are the easy part. The access that gets missed is non human: the service accounts, integration credentials, embedded passwords, certificates, and keys that connect systems to each other. These have no person attached to prompt their removal, they are buried in configuration, and they often hold high privilege precisely because they run automated processes.

These machine identities are both the easiest to forget and the most dangerous to leave. A service account with broad access and a password set years ago, still valid after exit, is an ideal foothold: powerful, unmonitored, and unattached to anyone who would notice it being used. Carve-out environments are full of them because integrations multiply over the life of a business and rarely get cleaned up.

Hunt them deliberately. Inventory every integration between the seller and your environment, every embedded credential in your applications, and every certificate or key the seller issued or holds. Rotate or revoke each as its service is cut, and confirm that nothing breaks because something still depended on it. The work is tedious and it is exactly the work that separates a clean exit from a lingering exposure.

Section 05

Evidence and audit at close

Deprovisioning is only finished when you can prove it, not when you believe it is done. The close of the workstream produces evidence: a record that each identified account is disabled, each credential rotated, each connection severed, and each key revoked, with the date and the confirmation for each. Belief is not a control. Verified evidence is.

That record serves more than your own assurance. After a carve-out, the clean separation of access is something auditors, security reviewers, and your own board may ask about, especially if an incident ever touches the boundary between the two companies. Being able to show exactly when and how every seller path was closed is the difference between a confident answer and an uncomfortable investigation.

Schedule a check after the cut as well. A short review some weeks post-close, confirming that no seller access has reappeared and nothing was missed, catches the account that slipped through and closes the loop for good. A buyer that inventories thoroughly, sequences carefully, and verifies the close holds the rare thing in a carve-out: certainty that the door is shut. Building that certainty into the exit is part of our TSA Exit Acceleration work.

FAQ

Questions buyers ask.

What is TSA identity deprovisioning?

It is finding and removing every account, credential, and access path the seller holds into your environment as the TSA ends. That includes named user accounts, shared and privileged accounts, and non human identities such as service accounts, embedded credentials, certificates, and keys. The aim is to leave the seller with no way to reach your systems after exit.

What is orphaned access?

Access that the seller no longer needs but that still works: forgotten accounts, credentials, and connections left active after a service is cut or after full exit. It is dangerous because no one is watching it and no one remembers it, leaving a standing path into your systems held by a party that is no longer your service provider. Preventing it is the point of deprovisioning.

Why are service accounts the biggest risk?

Because they are non human, so nothing prompts their removal, they are buried in configuration, and they often hold high privilege to run automated processes. A service account with broad access and a stale password, still valid after exit, is an ideal unmonitored foothold. Carve-out environments accumulate many of them, so they must be hunted deliberately and rotated or revoked as each service is cut.

How do I prove deprovisioning is complete?

With evidence, not belief. Record that each identified account is disabled, each credential rotated, each connection severed, and each key revoked, with a date and confirmation for each. Run a check some weeks after the cut to confirm no seller access has reappeared. That record answers the questions auditors, security reviewers, and your board may ask about the separation.

Related Reading

More for the modern operator.