Vendor Access Doesn’t Expire. It Just Goes Unmonitored
TL;DR
Most organizations have never designed their vendor remote access management. They’ve accumulated it, one exception at a time. Shared credentials, VPN profiles that outlast projects, service accounts with no offboarding trigger, and no named internal owner to catch any of it. The blast radius of a vendor compromise is insider-threat-sized, with a fraction of the visibility. The fix is not a tool. It’s a design decision followed by a governance discipline.
The IR call comes on a Thursday morning. The initial indicator is a successful authentication to an internal legacy portal from an IP in Romania. The portal hasn’t been touched in months. Nobody on staff has been to Romania.
The credential belongs to a service account created for a systems integrator that completed a deployment 14 months ago. The project closed. The integrator moved on. Nobody deprovisioned the account because nobody knew it needed deprovisioning. The project manager who owned the vendor relationship left the company six months after the project ended. The access request ticket from 14 months ago says the account was approved “for the duration of the project.” Nobody defined when the project ended. Nobody was responsible for checking.
The integrator’s employees probably have no idea either. The credential was stored in a shared password manager. Three people on their team had access to it. Two of them no longer work there.
This is not a sophisticated attack. It is a vendor remote access credential that outlived the relationship that created it, sitting unmonitored in a system that still trusts it. Vendor access doesn’t fail with a bang. It drifts, silently, for as long as nobody asks.
Vendor Access Is Not a Pattern. It’s an Accumulation.
A VPN account here, a shared login there, a temporary jump box that became permanent, a service account created to unblock a deployment and never removed. That is how vendor access looks in most organizations: not a designed approach, but a collection of individual decisions that outlasted the context that justified them.
The accumulation happens because vendor access requests are treated as one-off problems rather than a category of access with its own design requirements. A project team needs a vendor to reach a system. Security approves the request and moves on. Nobody asks what happens when the project ends, who owns offboarding, or whether the access path reflects the actual risk of what the vendor can reach.
Repeat that across every project, every acquisition, and every managed service relationship, and you end up with what most large organizations actually have: an uncharted collection of access paths, credentials, and trust relationships that nobody fully owns. Each one was approved for a reason that may or may not still be valid. Together they represent a substantial unmonitored attack surface.
The problem is not that individual decisions were wrong. Most made sense in context. The problem is that context expires and the access doesn’t.
Four Ways Vendor Access Becomes Permanent Standing Privilege
Shared credentials with no individual accountability. The vendor gets a shared account. Three people on their team know the password. When one leaves, nobody rotates the credential because nobody tracks who has it. The vendor relationship ends and the credential stays active because offboarding a shared account requires knowing it exists, knowing who has the password, and having someone responsible for revoking it. In practice, none of those conditions hold.
VPN profiles that outlast projects. Vendor VPN access is provisioned for a project and the profile gives them access to a network segment, not a specific application. The project closes. The profile stays active because removing it requires a change ticket, someone to initiate it, and someone to approve it. The path of least resistance is to leave it. Eighteen months later the profile is still valid and nobody is sure what it can reach.
Service accounts with no offboarding trigger. Some vendor access is non-human: an integration, a monitoring agent, a deployment pipeline with read access to production systems. These service accounts often have no expiry and no owner once the human relationship ends. When the managed service contract changes or the vendor is replaced, the old service account stays provisioned because the new team doesn’t know it exists and the old team no longer has reason to care.
Exceptions that become the standard. Vendor access frequently starts with an exception. The standard requires individual accounts, MFA, and a brokered session. The vendor can’t meet those requirements in the project timeline. An exception is approved. The exception doesn’t expire. The next vendor gets the same exception because precedent is easier to cite than the standard. Over time the exception is the standard, and the real standard exists only in the policy document.
The Blast Radius Is Insider-Threat-Sized, With Less Visibility
Vendor access is not equivalent to employee access in one critical way: you know far less about it.
When an employee account is compromised, you have a behavioral baseline. Normal working hours, usual location, typical systems accessed. Anomalies are detectable against that baseline. Your sign-in risk policies, your UEBA tooling, your SOC analysts all have something to work with.
When a vendor credential is compromised, your baseline is often empty. The account authenticates infrequently. Its normal behavior is undefined. When the compromised credential starts moving through systems at 2 AM from an unusual location, nothing flags it as anomalous because you have no definition of normal. The 2013 Target breach, one of the most studied supply chain compromises on record, entered through HVAC vendor credentials. Valid authentication, authorized access path, no behavioral signal to catch it until the data was already moving.
The blast radius is determined by what the account can reach. Vendor accounts frequently have more access than they need, not because anyone made a deliberate decision to over-privilege them, but because the path of least resistance at provisioning was to grant segment-level access rather than application-specific access. That over-provisioning, combined with no behavioral baseline and no session recording, is what makes a vendor compromise hard to detect and harder to contain.
The dynamic mirrors what makes workload identities so dangerous: a principal with broad permissions, infrequent and unpredictable access patterns, and no monitoring baseline is an attacker’s preferred lateral movement path. Vendor credentials have identical properties. They authenticate with valid credentials to authorized resources, and nothing in your telemetry recognizes it as a problem until the damage is done.
What Vendor Remote Access Management Should Actually Look Like
The design principles are not complicated. Applying them consistently is.
Individual accounts, not shared. Every person at the vendor who needs access gets their own credential, federated to their organization’s identity if possible via B2B trust. When someone leaves the vendor, their access is revoked at the identity level, not via a password rotation that may or may not reach every place the credential was stored. If individual federated identity is not achievable, named accounts with individual ownership inside your directory are the fallback.
Scoped to the resource, not the network. A vendor managing a specific system does not need VPN access to a network segment. They need access to that system. Application-specific access paths, a privileged remote access session brokered to the specific host or a ZTNA connector publishing the specific application, limit what a compromised credential can reach. This is what a mature remote access portfolio makes possible: matching the access pattern to the actual risk rather than defaulting to network-level access because it’s easier to provision.
Time-bounded with an explicit offboarding trigger. Every vendor access grant should have an expiry tied to a real event: project close, contract renewal, a named milestone. When that date arrives, access is suspended and requires active renewal. Renewal is not automatic. Someone has to confirm the relationship is still active and the access is still needed. This is the same exception management discipline that prevents governance drift in any other access category, and the same gap that creates vendor access sprawl when it’s absent.
Session recording for privileged paths. Any vendor with access to systems your own employees would need PAM controls to reach should have their sessions recorded. Not for surveillance: for containment and forensics. When an incident involves a vendor credential, session recording is the difference between knowing exactly what happened and reconstructing it from logs that may not have captured enough. It also changes vendor behavior in ways that matter during a security review.
A named internal owner for every vendor access path. Not the project team collectively. A named individual inside your organization responsible for reviewing the access, confirming it is still needed, and initiating offboarding when it isn’t. When that person leaves your organization, ownership transfers explicitly; it does not become orphaned. This is the same accountability structure that makes governance programs function: one throat to choke, one name on the renewal, one person the auditor calls.
Starting When Your Vendor Access Is Already a Mess
The inventory is always the first step and never a comfortable one.
Week 1: Pull every active vendor credential and access path. VPN accounts, service accounts, shared logins, PAM vault entries, SSO guest accounts. For each: name the vendor, name the internal owner, identify what it can reach, note the last authentication date. Any account that has not authenticated in 90 days is suspended immediately pending review.
Week 2: Identify the highest-risk paths. Any vendor credential with access to production systems, regulated data, or systems your own admins would need privileged access to reach. These get prioritized regardless of project status. Determine whether the scope is appropriate and whether session recording is in place. Anything that fails both checks is an immediate remediation item.
Week 3: Establish an offboarding trigger for every active relationship. For each vendor with active access, document the event that should terminate it: project completion, contract expiry, a specific milestone. Make that date visible to the named internal owner. Set a 30-day warning so offboarding doesn’t become a last-minute scramble.
Week 4: Define the standard for new vendor access requests. Individual accounts, named internal owner, expiry date, scope limited to what the vendor actually needs. New requests that don’t meet these requirements go back for redesign, not exception approval. This doesn’t fix the existing accumulation. It stops it from growing.
The existing mess is cleaned up path by path, prioritized by risk. That takes longer than a month. The governance loop is what prevents the new environment from looking like the old one in two years.
The Vendor Relationship Ended. The Access Didn’t.
Vendor remote access management is not a technically complex problem. The controls are well understood: individual accounts, scoped access, session recording, time-bounded grants, named internal owners. None of that is novel.
What makes it hard is that it requires discipline at the moment discipline is least convenient: when a project is under deadline pressure, when a vendor says their tooling doesn’t support MFA, when a contract renewal is running late and access needs to stay up for another 90 days just in case.
Every exception approved at that moment is a future IR finding. The vendor relationship will end. The access frequently won’t. And the attacker who finds that credential doesn’t care that the project closed 14 months ago.
