The partnership ends on a Tuesday. The project wraps, the contract expires, or the vendor relationship simply stops — but nobody tells IT. Three months later, the partner account is still live in Active Directory. The VPN profile remains active. The shared service credentials persist across multiple cloud platforms. The business relationship has ended, but the digital relationship continues indefinitely.
This creates a gap where terminated partner access accumulates in identity systems. According to MITRE ATT&CK, adversaries who compromise trusted third-party relationships (T1199) exploit the access that organizations extend to vendors, partners, and managed service providers — access that, when left active after a relationship ends, provides a foothold that blends into normal traffic patterns because it was legitimately provisioned in the first place. Partner access outlives partnerships because provisioning responds to business events, but deprovisioning has no equivalent trigger.
The structural gap between business relationships and identity governance
Provisioning is event-driven — contract signatures, project kickoffs, and vendor onboarding create clear triggers for IT to establish access. Deprovisioning depends on manual notification because the business events that end relationships — contract expiration, project closure, vendor replacement — do not route to identity teams.
The consequence is structural access accumulation. Partner accounts remain active across multiple systems after the business relationship ends, creating a persistent attack surface that appears legitimate to detection systems. This is not primarily a training problem or a process discipline problem. It reflects an architectural gap between who owns the business relationship and who manages the digital identity — and closing that gap requires deliberate design, not just better reminders.
How the partner ecosystem outgrew the offboarding model
Three structural forces have made this problem more acute over the past decade, though the degree varies considerably by organization and industry. Partner ecosystems have expanded well beyond traditional vendor relationships — many organizations now manage API integration partners, short-term consultancies, project-based engagements, and federated identity relationships that never fit the contractor offboarding model designed for long-term employees.
Engagements have also become shorter and more transactional. A consulting firm working on a six-month digital transformation project receives access differently than a facilities management company with a multi-year contract. The consulting engagement was never onboarded through HR, so it cannot be offboarded through HR when the project ends. That path simply does not exist.
Cloud and SaaS proliferation compounds the problem. Partner access is now provisioned across dozens of systems rather than centralized in one directory. A partner may have accounts in the VPN, collaboration platforms, customer portals, shared API credentials, and cloud resource access — each provisioned separately through different teams and requiring separate deprovisioning with no single team holding visibility across all of them.
This creates a coordination problem with a predictable structure. The procurement team knows when contracts end. The project management office knows when engagements close. IT knows which accounts exist. None of these teams has complete visibility into the relationship between business events and identity state, and none has formal accountability for bridging them.
Three reasons the current approach breaks down
The current model fails in ways that are structural rather than incidental. First, there is no authoritative offboarding trigger for external identities. IT does not receive contract expiration notifications. Procurement teams do not have access to identity directories. HR does not manage external partner relationships. Offboarding becomes a manual process dependent on someone remembering to file a ticket — which means it frequently does not happen.
Second, there is no shared identity state across partner access points. A consulting partner may hold accounts across VPN, shared drives, customer portals, and API credentials, all provisioned separately by different teams. There is no central partner identity record tying these accounts together, so deprovisioning must happen system by system with no mechanism to confirm completeness.
Third, governance processes are built for employee identities managed through HR systems. Access review cycles, role certifications, and audit processes treat the HR record as the authoritative source for determining whether a person still has a legitimate relationship with the organization. External identities have no equivalent authoritative source. Review processes either exclude partner accounts entirely or treat them as a manual exercise with no enforcement mechanism to ensure follow-through.
These gaps produce predictable outcomes. Partner accounts persist after contract termination because no automated process removes them. Access reviews miss external accounts because they are not anchored to an authoritative identity record. Detection systems treat the resulting access as legitimate because the accounts were properly provisioned and never formally revoked.
Why lingering partner access is difficult to detect
The detection problem deserves particular attention, because it is not simply a matter of tuning alerts more carefully. MITRE ATT&CK describes trusted relationship compromise (T1199) as adversaries gaining access to a target organization by first compromising an entity that has legitimate access — a vendor, managed service provider, or business partner. When a partner account remains active after the relationship ends and an adversary obtains those credentials, the resulting access looks indistinguishable from legitimate partner activity. The account has a history of valid use, originates from known locations, and accesses systems the account was specifically designed to reach.
Security teams typically tune monitoring for patterns like unusual geographic access, off-hours activity, or privilege escalation. A terminated partner account used during business hours from known IP ranges using established access patterns may generate minimal alerting. The compromise looks like legitimate partner activity because the account retains exactly the access it had during the active relationship.
NIST SP 800-161r1, which addresses supply chain risk management practices, recognizes that partner and vendor identity management cannot be solved simply by extending employee identity processes — external identities operate under different governance conditions and require different architectural approaches to manage effectively.
The compliance dimension is real but often overstated
Partner accounts that outlive partnerships create exposure across every system where the partner had access — from file shares to API endpoints to administrative interfaces. The regulatory dimension adds pressure, though it is worth being precise about what that pressure actually is.
GDPR and CCPA establish obligations around data access and processing for personal data. A terminated partner that retains active access to systems containing personal data represents a potential control failure, since the organization can no longer verify that access is limited to legitimate purposes. This may complicate the organization's ability to respond to data subject requests, demonstrate access controls to auditors, or establish a defensible data inventory. Whether this constitutes a direct regulatory violation depends on the specific facts and jurisdiction — it is not automatically an enforcement action, but it is a documented control gap that regulators and auditors will flag.
Quarterly access certifications face a related problem. When managers certify access for partners whose contracts expired months earlier — either because they do not know the relationship ended or because the certification process does not surface that context — the certification provides no meaningful assurance. Audit findings accumulate around partner access because auditors can document accounts that exist without corresponding active business relationships.
The durable attack surface
Third-party and supply chain access represent a persistent challenge because the underlying dynamic — legitimate credentials retained beyond their intended scope — is not easily eliminated by improving perimeter defenses. As organizations expand partner ecosystems, the number of identity relationships that must be actively governed grows faster than the processes typically in place to manage them.
The attack surface is also durable in a second sense: it tends to grow silently. Unlike an unpatched vulnerability that security scanners can enumerate, stale partner accounts accumulate without generating alerts, because from the identity system's perspective, nothing has gone wrong. The account exists; it has access; it authenticates successfully. The business context that would render this anomalous lives in a contract database or a project management tool that identity governance systems do not consult.
Bridging the divide
The architectural question is straightforward to state and difficult to execute: when a partnership ends, who is responsible for the identity? Procurement owns contract termination. IT owns account deprovisioning. Project managers own engagement closure. Partner access sits in the gap between these responsibilities, accumulating until someone builds a bridge across the organizational divide.
Bridging that divide requires connecting the systems that record business relationship status to the systems that manage identity. That might mean integrating contract management platforms with identity governance tooling, establishing formal notification paths from procurement to IT on contract expiration, creating a central partner identity record that aggregates access across systems, or building time-limited access provisioning for project-based engagements that expires automatically when the engagement closes. The right combination depends on the organization's specific ecosystem, tooling, and risk tolerance — there is no single architectural solution that fits all cases.
What is clear is that the current default — manual notification, system-by-system deprovisioning, and access reviews that treat external identities as an afterthought — does not scale to the size and complexity of modern partner ecosystems. The gap will close deliberately, by design, or it will continue to accumulate exposure that detection systems are structurally unlikely to surface.
