Third-party vendors rarely get the same scrutiny as internal infrastructure, yet a payment processor’s staging server or a helpdesk contractor’s VPN gateway can sit on the same attack path as your own production stack. This article covers third-party vendor access and inherited exposure — what happens when a supplier’s open ports, misconfigured services, or forgotten test environments become your organization’s problem too.
The premise is simple and uncomfortable: your attack surface doesn’t end at your own IP ranges. It extends into every vendor with a VPN tunnel, an API integration, a shared database connection, or standing remote access to your environment. A logistics company in 2023 lost customer data not because its own servers were breached, but because a freight-forwarding partner ran an exposed Elasticsearch instance with no authentication — the same instance that synced shipment records from the logistics company’s ERP. The breach notification named the logistics company, not the partner.
How vendor access creates exposure you don’t control
Vendor relationships typically introduce three kinds of network exposure. First, direct connectivity — site-to-site VPNs, SFTP drops, or API gateways that accept traffic from the vendor’s IP space. Second, credential reuse — a vendor’s compromised laptop or exposed RDP port (see RDP port security) becomes a pivot point into systems that trust that vendor’s session. Third, shared infrastructure — SaaS platforms, managed hosting, or outsourced dev shops that run your workloads on servers you never provisioned and can’t scan without contractual permission.
The Target breach in December 2013 is the reference case everyone cites, and for good reason: attackers got in through an HVAC contractor’s stolen credentials, not through Target’s own perimeter. Fazio Mechanical had network access for billing purposes. That access path had nothing to do with refrigeration systems and everything to do with a vendor onboarding process that granted broader network reach than the relationship required.
Why standard security reviews miss this
Most vendor risk assessments are paperwork exercises — SOC 2 reports, security questionnaires, SIG Lite forms. These are useful for governance but tell you almost nothing about what’s actually listening on a vendor’s servers right now. A vendor can hold a clean SOC 2 Type II report and still be running Redis on port 6379 with no authentication (a configuration problem covered in Redis port exposure), because the audit sampled a control period eight months ago and nobody rescanned after the last infrastructure change.
An experienced GRC lead treats the questionnaire as a starting point, not a conclusion. The real question isn’t “does the vendor have a security policy” — it’s “what is actually reachable on the internet from their environment today, and does any of it touch data or systems that belong to us.” Those are different questions, and only the second one catches drift.
Mapping where vendor exposure actually lives
Start by inventorying every external connection point, not every vendor relationship. A vendor with API access authenticated over HTTPS with rotating tokens carries different risk than one with a standing site-to-site VPN and a flat network route into your VLAN. Group vendors by connection type:
Actually, the useful grouping here isn’t a bullet list — it’s a question asked per vendor: what protocol, what port, what’s on the other end, and who owns the credential. A payment gateway integration over port 443 with mutual TLS is low-risk by design. A “temporary” FTP drop set up for a one-time data migration in 2022 that’s still open in 2026 is a completely different risk category, and these accumulate exactly the way covered in legacy systems and open ports.
Where you have scanning rights — your own IP ranges, jump hosts, VPN concentrators — run continuous external scans against the infrastructure vendors connect to, not just your production app servers. A vendor’s compromised credential is only dangerous if it lands on a network segment with something worth reaching. Segmentation reviews (see ports and network segmentation) matter more for vendor access than for almost any other risk category, because you can’t control the vendor’s hygiene, only the blast radius when it fails.
Contractual and technical controls that actually reduce risk
Contracts alone don’t close ports. But contract language that mandates specific technical controls — time-boxed access, IP allowlisting, MFA on remote sessions, and a right-to-scan clause — gives you leverage when a vendor’s environment needs to change. Time-boxing matters especially for one-off engagements: an auditor, a migration contractor, or a pen tester should get access that expires automatically, not access that someone remembers to revoke six months later. This overlaps directly with change-window discipline — see temporary port openings during change windows for how that discipline should work operationally.
On the technical side, the highest-leverage control is usually the simplest: put vendor connections behind a jump host or bastion rather than routing them directly into internal segments. If the vendor’s endpoint is compromised, the attacker inherits access to one hardened, monitored chokepoint instead of a flat network. Pair that with an allowlist model — permitting known vendor IP ranges on specific ports rather than opening broad ranges — a design pattern worth comparing against allowlists versus blocklists in firewall design.
Common mistakes in vendor access management
The most frequent failure is treating vendor onboarding as a one-time gate. Access gets provisioned during contract signing, reviewed once, and then left alone for the life of the relationship — sometimes years. Nobody revisits whether the original scope of access still matches current need.
The second mistake is scanning your own infrastructure quarterly while never asking what’s exposed on the vendor side of the connection, because “that’s their responsibility.” It is their responsibility, contractually. It’s still your incident when it fails.
The third is conflating vendor tier with access scope. A marketing analytics vendor that only receives anonymized CSV exports via SFTP doesn’t need the same access review cadence as a managed database provider with a live connection to production. Treating every vendor identically either wastes review cycles on low-risk suppliers or under-scrutinizes the ones that matter.
FAQ
Can we scan a vendor’s infrastructure without their permission?
No. Unauthorized scanning of systems you don’t own or control can violate computer misuse laws regardless of intent. Scanning rights need to be written into the vendor contract or security addendum, typically as a right-to-audit or right-to-scan clause, before any external testing happens.
Does a vendor’s SOC 2 report mean their ports and services are secure?
Not directly. SOC 2 evaluates controls and processes over an audit period, not real-time infrastructure state. A vendor can pass SOC 2 and still have configuration drift months later. Treat the report as evidence of process maturity, not as a live exposure assessment.
How often should vendor access be reviewed?
Match the cadence to the access tier: vendors with standing network connectivity or database access warrant quarterly reviews at minimum, while low-scope vendors (read-only API tokens, batch file transfers) can be reviewed annually. Any vendor contract change, especially scope expansion, should trigger an off-cycle review.
Inherited exposure from vendors doesn’t show up in your own change logs, which is exactly what makes it dangerous — nobody on your team gets an alert when a supplier opens a new port. Building vendor connection points into your own continuous monitoring program, rather than treating them as someone else’s problem, is the only way to catch the drift before an incident does.