Vendor Identity Lifecycle Management

A supply chain management platform provider had three hundred and twelve vendor-side user accounts , accounts belonging to employees of the suppliers, logistics partners, and service providers who used the platform to process orders and manage shipments. When a security operations team conducted a reconciliation of active accounts against current vendor employee rosters , an exercise triggered by a threat intelligence alert about credential compromise , they discovered that forty-seven of the three hundred and twelve accounts belonged to individuals who were no longer employed by the vendor organizations they were associated with. The accounts had been created during onboarding of the respective vendor relationships and had never been deactivated. The platform's access review process asked vendor organization contacts to confirm which accounts their employees needed , but the contacts were account managers and operations leads who had reviewed the list and confirmed the accounts they knew about. They had not flagged former employees because the contacts did not always know who had left, and the review process did not specifically ask about employee departures. Forty-seven former employees of vendor organizations had active, valid credentials to the supply chain platform. Some had not used their accounts since departing. Three had been used within the last thirty days , whether by the former employees themselves, by others using the credentials, or by neither , could not be determined from available logs.

What is the Vendor Identity Lifecycle Problem, Really?

Identity lifecycle management is the set of processes that govern the creation, maintenance, and deactivation of user accounts throughout their operational life , ensuring that accounts are created when access is needed, maintained proportionately as needs change, and deactivated when access is no longer needed. The lifecycle management challenge at the vendor boundary arises from the information asymmetry between the platform organization (which manages the accounts) and the vendor organization (which employs the users). The platform organization cannot directly observe vendor employee departures. The vendor organization may not proactively notify the platform organization when employees leave.

The notification gap is the structural root of vendor identity lifecycle failures. For internal employees, identity lifecycle is governed through HR system integration , when an employee is terminated, their HR record triggers account deactivation through automated provisioning workflows. No such direct integration exists for vendor-side users on a customer-managed platform. The customer cannot connect their account management system to the vendor's HR system. The customer depends on the vendor to notify them of departures , and that notification depends on the vendor having a process to do so, the vendor knowing which platform accounts are affected by each departure, and the vendor prioritizing that notification alongside all the other offboarding tasks that accompany an employee departure.

The vendor organization offboarding gap is the specific operational failure that produces former employee accounts. When an employee departs a vendor organization, their offboarding process typically covers the vendor organization's own systems: corporate email, internal applications, SSO-connected platforms, VPN access. Customer platform accounts , accounts on the platforms of the organizations the vendor serves , may not be systematically included in the offboarding checklist. The vendor's former employee retains access to customer platforms because the vendor's offboarding process did not include customer platform deprovisioning, and the customer's platform has no mechanism to detect the departure.

• Vendor-side offboarding not triggering customer platform deprovisioning , vendor employee departures not consistently communicated to customer platform
• Access review confirming accounts reviewers know about , reviews that depend on vendor contacts having complete knowledge of their organization's current employment status
• No independent verification of account holder employment status , customer platform accepting vendor confirmation without cross-referencing against current employment verification
• Dormant account persistence , former employee accounts remaining active and unused but valid
• No vendor offboarding obligation in contract , no contractual requirement for vendor to notify customer of employee departures affecting platform access

Why this matters

Vendor identity lifecycle matters for TPRM because platform accounts belonging to former vendor employees represent a specific and well-documented credential compromise risk. Former employees who retain access to customer platforms may access those platforms after departure , intentionally for data theft or competitive intelligence gathering, or unintentionally if they forget they still have access. Former employee credentials that persist are also more likely to appear in credential dumps and breach data because they may have been reused across personal services, making them higher-probability targets for credential stuffing.

The accountability gap compounds the risk. When a former vendor employee's account is used after their departure , whether by the former employee or by someone using their credentials , the customer platform has no way to know the account holder has departed. Access events appear normal: valid credential, valid account, no anomaly in authentication. The behavioral anomaly that behavioral analytics might detect , unusual access patterns for an employee who has left , is invisible if the customer platform does not know the departure occurred.

For TPRM practitioners, vendor identity lifecycle assessment requires asking specifically about the notification and deprovisioning process for vendor-side user departures , not assuming that periodic access reviews will catch former employee accounts if the review process depends on vendor contacts who may not know about all departures.

Where most teams get this wrong

The most consistent failure is relying on vendor-side access reviews to catch former employee accounts. Reviews that ask vendor contacts to confirm user lists catch accounts the reviewer knows about. They do not reliably catch departures that the reviewer , typically an account manager or operations contact , does not have visibility into, particularly for large vendor organizations or for employees who left teams the contact does not manage.

• Relying on vendor-side access review to detect former employee accounts
• No vendor offboarding notification requirement in contract
• No independent employment verification for high-risk vendor platform accounts
• Dormant account detection not applied to vendor accounts , last-login monitoring
• No vendor account reconciliation process , periodic cross-reference against current vendor employee roster

What good looks like

Mature vendor identity lifecycle programs combine contractual notification obligations with independent verification mechanisms and dormant account detection , not relying solely on vendor reviews that depend on reviewer knowledge that may be incomplete.

• Contractual departure notification obligation , vendor required to notify customer within defined timeframe when employees with platform access depart
• Dormant account detection and review , platform accounts unused beyond defined threshold flagged for verification
• Independent employment verification for high-risk accounts , periodic cross-reference against vendor employee roster or LinkedIn verification
• SCIM provisioning integration , vendor directory integration that automatically deactivates platform accounts when vendor HR records are updated
• Offboarding checklist requirement , vendor required to include customer platform deprovisioning in their employee offboarding process

Tooling

SCIM Automated Provisioning , Okta SCIM, Azure AD SCIM, OneLogin

SCIM integration between the vendor's identity provider and the customer platform enables automated account deactivation when the vendor's HR or IdP records are updated for a departure. When the vendor marks an employee as terminated in their IdP, the SCIM integration automatically deactivates the corresponding customer platform account. For TPRM practitioners, asking whether the vendor platform supports SCIM provisioning and whether the vendor organization uses their IdP for SCIM provides the most direct vendor identity lifecycle automation question.

Identity Governance , SailPoint, Saviynt

IGA platforms with external user governance capabilities manage vendor-side user lifecycle , providing dormant account detection, departure notification workflows, and periodic verification of external user employment status. For TPRM practitioners, asking whether external (vendor-side) user accounts are governed through the IGA platform provides a specific external identity lifecycle governance question.

Governance challenges

The governance challenge with vendor identity lifecycle is the organizational boundary problem. The events that should trigger account deactivation , vendor employee departures , occur inside the vendor organization and must be communicated across the organizational boundary to the platform organization. That communication requires the vendor to have a process for identifying platform accounts held by departing employees, a mechanism for communicating departures to the platform, and a cultural expectation that customer platform offboarding is part of the departure process.

• Add departure notification requirement to vendor contracts , obligation to notify within 24-48 hours of departure for employees with platform access
• Implement dormant account detection , accounts unused beyond 60-90 days flagged for employment verification
• Pursue SCIM integration with vendor IdP where supported
• Include customer platform deprovisioning in vendor onboarding , communicate the expectation at relationship start, not after an incident
• Periodic roster reconciliation for highest-risk vendor relationships , cross-referencing platform accounts against current vendor employee roster

If you are a small team

Run a dormant account check on your highest-risk vendor platform accounts immediately: identify any vendor-side accounts that have not been used in more than ninety days and request employment verification from the vendor contact for each. That check will surface former employee accounts that the access review did not catch and provide the basis for adding a departure notification requirement to the next contract renewal. The dormant account check costs thirty minutes. The former employee accounts it finds cost significantly more to remediate after an incident.

• Run dormant account check on vendor-side users , flag accounts unused 90+ days
• Request employment verification from vendor for dormant account holders
• Add departure notification requirement to next contract renewal
• Pursue SCIM integration for highest-risk vendor relationships

What to require

Ask directly:

"What is your process for notifying us when an employee who has access to our platform departs your organization , specifically, is customer platform account deprovisioning included in your employee offboarding checklist, and what is the timeline for notification?"

"Can you confirm that all currently active accounts on our platform belong to individuals who are currently employed by your organization , and when was the last time you cross-referenced active platform accounts against your current employee roster?"

Expect as evidence

• Departure notification process documentation , platform offboarding included in employee offboarding checklist
• Current employment verification for all active platform accounts
• Last roster reconciliation date and findings
• SCIM or equivalent integration capability

A vendor who confirms their access reviews catch departures should be asked how the review process identifies former employees whose departure the reviewer may not have known about. The review catches what the reviewer knows. The dormant account check catches what the review missed. Both are needed.

How to evidence it

• Departure notification requirement documentation in vendor contracts
• Dormant account review records
• Employment verification records for vendor-side platform accounts
• SCIM integration or equivalent lifecycle automation

Key Takeaway

Vendor-side user accounts outlive the employees who hold them when the organization managing the platform has no direct visibility into vendor employee departures and no contractual mechanism requiring notification. The access review confirmed one hundred accounts as valid. Forty-two former employees passed that review because the reviewer confirmed what they knew about and did not know about what they did not know. The dormant account check finds what the review misses. The departure notification requirement creates the notification channel that makes lifecycle management at the vendor boundary possible. The SCIM integration automates what the notification process depends on people to do. Identity lifecycle at the vendor boundary requires more than reviews that depend on reviewer knowledge , it requires the information flows and automation that make departure detection reliable.

More on Security

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