Orphaned Vendor Accounts

A manufacturing company completed the termination of a three-year engagement with an ERP implementation vendor. The formal offboarding process was thorough: the project manager confirmed handover documentation was complete, the legal team confirmed the DPA termination, the finance team confirmed the final invoice was paid and the contract was closed. The IT team ran through their offboarding checklist , revoking the vendor's VPN access, closing the vendor's email forwarding alias, and archiving the shared project folders. Six months after termination, a routine access audit found four accounts still active in the company's ERP system itself: the vendor's integration service account, used to run automated data synchronization jobs during implementation, and three named user accounts belonging to vendor implementation consultants. These accounts had never appeared on the IT offboarding checklist because the ERP system's user management was handled by the ERP team , a different group from the IT infrastructure team that executed the formal offboarding. The ERP team had not been informed the relationship was ending. Nobody had ownership of ERP account cleanup in the offboarding process. The accounts had been active and credential-valid for six months after the relationship they supported had formally concluded.

What are Orphaned Vendor Accounts, Really?

Orphaned vendor accounts are active user accounts and service accounts in an organization's systems that belong to vendor employees, contractors, or service principals whose operational relationship with the organization has ended. They are not accounts that were forgotten during offboarding , they are accounts that were not included in the offboarding process because no one had explicit ownership of removing them, the system they lived in was not part of the offboarding workflow, or the offboarding process was not designed to reach that type of account.

The distributed system problem is the primary structural cause of orphaned vendor accounts. Modern enterprise environments span dozens of systems , ERPs, CRMs, analytics platforms, collaboration tools, cloud infrastructure consoles, monitoring systems, and application-specific platforms , each with its own user management. Vendor relationships that touch multiple systems create accounts across multiple platforms. Offboarding processes that are not explicitly designed to identify and include all vendor-created accounts across all affected systems will systematically leave orphaned accounts in the systems outside the offboarding workflow's scope.

The ownership ambiguity problem compounds the distributed system issue. Each application platform may have a different team responsible for user management , the ERP team manages ERP accounts, the Salesforce admin manages CRM accounts, the cloud team manages cloud console accounts. When a vendor relationship ends, there is no organizational event that automatically notifies every application team of the termination. Unless the offboarding process explicitly includes notification to all teams managing systems where the vendor had accounts, those teams do not know the relationship has ended and have no reason to remove the accounts.

The service account dimension adds a layer that even comprehensive offboarding processes frequently miss. User accounts are visible as named accounts associated with people. Service accounts are often visible only as technical principals with names like 'vendor-integration-svc' or 'eai-sync-account' that do not obviously indicate their vendor association. Application teams reviewing their user lists may not recognize that these technical accounts are associated with the concluded vendor relationship and should be deprovisioned.

• Offboarding process not reaching all affected systems , checklist scoped to IT-managed infrastructure while application-managed systems are not included
• No system inventory at relationship start , not documenting all systems where the vendor will have accounts during onboarding
• Service accounts without vendor attribution , technical accounts that do not obviously indicate their vendor association in access review
• Application team not notified of vendor termination , decentralized account management without cross-team termination notification
• No orphaned account detection process , no periodic scan identifying accounts belonging to ended relationships

Why this matters

Orphaned vendor accounts matter for TPRM because they represent attack surface that persists after the risk justification for it has ended. When a vendor relationship concludes, the due diligence, contractual controls, and monitoring that governed the relationship during its active period also conclude. The orphaned accounts remain in the environment , valid, credentialed, potentially accessible , but outside any active governance framework. They are the accounts most likely to appear in credential dumps without being noticed, most likely to be used by former vendor employees without triggering alerts, and least likely to be detected through behavioral monitoring because the behavioral baseline established during the active relationship may have already drifted.

The threat timeline is important to understand. A vendor employee who knows their organization's relationship with a customer platform has ended is unlikely to immediately misuse their access , the risk of discovery is highest immediately after termination. Six months to a year later, when the access has been forgotten by both parties and the detection probability has fallen, the risk window reopens. The dormant account that was created during an implementation engagement and never removed becomes the forgotten entry point with maximum deniability.

For TPRM practitioners, orphaned account risk is a post-relationship risk rather than an in-relationship risk , it persists and potentially grows after the formal governance relationship has ended. Assessing whether vendor offboarding is comprehensive enough to remove accounts across all affected systems is therefore as important as assessing whether onboarding creates appropriate access.

Where most teams get this wrong

The most consistent failure is treating offboarding as the mirror image of onboarding rather than as a comprehensive account removal exercise across all affected systems. Onboarding creates access in systems that are explicitly provisioned. Offboarding that focuses on reversing the explicitly provisioned access misses the accounts that accumulated in other systems during the relationship , the ERP accounts created for data synchronization testing, the monitoring system accounts created for integration troubleshooting, the analytics platform accounts created for reporting access.

• Treating offboarding as the reverse of onboarding rather than comprehensive account removal
• No vendor account inventory maintained during relationship , no record of all systems where the vendor has accounts
• Offboarding checklist not including all application systems
• Service accounts not attributed to vendor relationships in access records
• No post-offboarding verification , no process confirming removal was complete

What good looks like

Mature vendor account governance programs maintain an inventory of all vendor-created accounts across all systems throughout the relationship , building the offboarding scope at onboarding rather than trying to reconstruct it at termination.

• Vendor account inventory maintained during relationship , all accounts across all systems documented with system, account type, and purpose
• Offboarding process driven by account inventory , removal scope defined by the documented accounts, not by the IT checklist
• Cross-team termination notification , all application teams with vendor accounts notified at relationship termination
• Post-offboarding verification , confirmation that accounts were removed across all documented systems
• Periodic orphaned account scan , dormant accounts reviewed for vendor association and removed if relationship has ended

Tooling

Identity Governance , SailPoint, Saviynt

IGA platforms that manage access across all connected systems provide comprehensive vendor account visibility and lifecycle management , tracking vendor accounts in all integrated applications and enabling centralized deprovisioning at relationship termination. For TPRM practitioners, asking whether the vendor uses IGA with cross-system account visibility provides a specific orphaned account prevention capability question.

Access Management Discovery , Varonis, BeyondTrust Privileged Identity

Access discovery platforms scan across systems to identify all accounts associated with specific identities or organizations , enabling identification of vendor-associated accounts that may not appear on the IT offboarding checklist. For TPRM practitioners, asking whether an access discovery scan was run at vendor offboarding provides a specific post-offboarding verification question.

Governance challenges

The governance challenge with orphaned vendor accounts is the inventory-at-onboarding requirement. The time to build the offboarding scope is when the relationship starts , documenting all systems where the vendor will have accounts as part of the onboarding process, so that the offboarding process has a comprehensive scope rather than depending on reconstruction from memory eighteen months later.

• Build vendor account inventory at onboarding , document all systems where the vendor will have accounts before access is provisioned
• Include all application teams in offboarding notification , cross-team notification at termination
• Run orphaned account scan at offboarding completion , confirm removal across all documented systems
• Run periodic dormant account scan , identify vendor-associated accounts unused 90+ days for review
• Add account removal verification to offboarding sign-off , completion not confirmed until removal is verified

If you are a small team

Pick your three most recently terminated vendor relationships and run a simple check: search each system in your environment that the vendor might have touched , ERPs, CRMs, analytics platforms, cloud consoles, monitoring tools , for any accounts with the vendor's domain or organization name. That search will surface the orphaned accounts that the formal offboarding missed, and the list of systems it covers will become the starting point for the vendor account inventory that future relationships need.

• Search all systems for vendor-associated accounts after recent relationship terminations
• Build vendor account inventory at next onboarding , document all systems before access is provisioned
• Add cross-team termination notification to offboarding process
• Add post-offboarding verification to offboarding sign-off requirements

What to require

Ask directly:

"At the end of our engagement, what is your process for ensuring all accounts your staff and systems hold in our environment are identified and removed , and does that process cover application-specific accounts beyond the primary IT-provisioned access?"

"Can you provide a current inventory of all accounts your organization holds in our environment , including service accounts and user accounts across all systems , so we can use it as the basis for comprehensive offboarding when the relationship concludes?"

Expect as evidence

• Vendor account inventory across all systems
• Offboarding process documentation covering all account types
• Post-offboarding verification process
• Service account attribution documentation

A vendor who confirms offboarding procedures should be asked to provide a current inventory of all accounts they hold in the customer's environment , not just the primary provisioned access but service accounts and application-specific accounts across all systems. That inventory becomes the offboarding scope. Without it, the offboarding scope is whatever is on the checklist.

How to evidence it

• Vendor account inventory records
• Offboarding scope documentation including all systems
• Post-offboarding account removal verification
• Periodic orphaned account scan records

Key Takeaway

Offboarding closes the relationship on paper. Orphaned accounts are the relationship's digital residue , accounts that were created during the engagement and outlasted it because no process reached the system they lived in. The service account in the ERP system, the user accounts on the analytics platform, the monitoring system credentials created for integration troubleshooting: none of these appeared on the IT offboarding checklist because none were IT-provisioned accounts. The inventory that enables comprehensive offboarding is built at onboarding , not reconstructed from memory fourteen months after the relationship concludes. Start the inventory when the accounts are created. The offboarding scope writes itself.

More on Security

• API Identity Misuse
• Access Certification Effectiveness
• Access Policy Misconfigurations