By Jeremy Wilson | Founder, VISO Group
Your vendor list may be current. Your vendor access list probably is not.
Mid-market companies depend on outside partners for payroll, infrastructure, software support, finance, security, marketing, managed services, and dozens of specialized business functions. Those relationships often require technical access: user accounts, administrator roles, VPN connections, remote-support tools, API keys, service identities, shared folders, cloud permissions, and credentials embedded in automated workflows.
The business relationship eventually changes or ends. The access does not always end with it.
That makes vendor access more than a procurement or contract-management issue. It is an identity-lifecycle problem that sits between procurement, IT, security, legal, and the business owner who originally sponsored the relationship.
The good news is that you do not need a six-month program to start reducing the risk. A focused 30-minute review of your highest-access vendors can uncover accounts and connections that no longer have a valid business purpose.
Why Vendor Access Drifts
Third-party access rarely becomes excessive because someone deliberately ignores security. It drifts because each team sees only part of the relationship.
Procurement knows which companies are under contract. Accounts payable knows which companies are still being paid. IT knows about many user accounts and remote connections. Security knows which access paths look risky. Application owners know which integrations keep a business process running.
No single list necessarily shows the whole picture.
Common examples include:
- A support engineer leaves the vendor, but the named account remains active.
- A temporary administrator role created for an implementation is never removed.
- An API key continues working after the integration has been replaced.
- A remote monitoring or support agent remains installed after the contract ends.
- A service account has no current internal owner because the employee who sponsored it changed roles.
- Several vendor employees share one credential, making individual accountability impossible.
- A vendor retains broad access when only one narrow function is still required.
These are not just administrative imperfections. They create paths into systems and data that your company may no longer be actively monitoring.
Start With the Ten Vendors That Have the Deepest Access
Do not begin by trying to inventory every supplier. Start with the vendors that could create the greatest operational or security impact.
Prioritize vendors that have one or more of the following:
- Privileged or administrator access
- Persistent remote access
- Production-system access
- Access to regulated, customer, employee, financial, or proprietary data
- Machine-to-machine credentials or API keys
- Ability to modify security controls, backups, identity systems, or cloud resources
- Access that is shared across multiple vendor personnel
The goal of the first review is not a perfect enterprise inventory. It is ten accurate records about the relationships that matter most.
The 30-Minute Vendor Access Audit
Create one row for each selected vendor and answer the following questions.
1. What can the vendor access today?
List the actual access paths, not just the application named in the contract.
Look for:
- Named user accounts
- Shared accounts
- Administrator or privileged roles
- VPN or zero-trust network access
- Remote desktop and support tools
- Cloud-console access
- SaaS administrator access
- API keys, tokens, certificates, and secrets
- Service accounts and non-human identities
- Shared mailboxes, file repositories, and collaboration spaces
- Vendor-installed agents or connectors
If nobody can explain what an account or connection does, that is a finding—not a reason to leave it untouched indefinitely.
2. Who owns the relationship internally?
Every vendor access path should have a named internal owner who can answer two questions:
- Does the business still need this access?
- Is the current level of access appropriate for that need?
“IT” or “the business” is not a useful owner. Assign a person or accountable role.
3. Is the access tied to an individual?
Named accounts make it possible to approve, monitor, and revoke access for a specific person. Shared credentials make those actions harder and weaken accountability.
Where shared access cannot be eliminated immediately, document why it exists, who is allowed to use it, how its use is logged, and when the exception will be reviewed.
4. Is the access broader or longer-lived than necessary?
Ask whether the vendor needs:
- Continuous access or access only during an approved support window
- Administrator rights or a narrower role
- Access to an entire environment or one system
- Production access or a controlled support environment
- A permanent credential or a short-lived credential issued when needed
The safest persistent access is the access you no longer need and remove.
5. When was it last reviewed?
Every retained access path should have a review or expiration date. High-impact access should be reviewed more frequently than low-risk access.
A review should confirm the vendor relationship, current personnel, business purpose, permission level, logging, and internal owner. It should not be a checkbox that simply extends the same access for another year.
What to Remove Immediately
The first pass should identify access that is clearly:
- Expired
- Unused
- Unexplained
- Orphaned
- Shared without a justified exception
- Associated with a former vendor employee
- Broader than the current business need
- Connected to a vendor relationship that has ended
For anything that cannot be removed immediately, assign an owner, document the reason, reduce privileges where possible, and set a firm resolution date.
Make Offboarding a Trigger, Not a Memory Test
The review will reduce today's exposure. A repeatable lifecycle prevents it from returning.
Vendor onboarding should record:
- The business sponsor
- Approved systems and data
- Named vendor users
- Required permission level
- Start date and expected end or review date
- Logging and monitoring requirements
- Offboarding owner
Vendor offboarding should revoke identities, keys, tokens, certificates, remote tools, data-sharing permissions, and physical access. It should also confirm whether the vendor created any secondary accounts or integrations during the engagement.
Role changes matter too. A vendor relationship may continue while the individuals supporting your account change. Your process should require the vendor to notify you when personnel with access leave or change roles.
The Governance Standard Is Straightforward
The NIST Cybersecurity Framework 2.0 places cybersecurity supply-chain risk within the Govern function, reinforcing that third-party risk requires ownership, policy, and oversight—not only technical controls. NIST SP 800-161 provides deeper guidance for managing cybersecurity risk across supplier relationships and the technology supply chain.
The practical translation for a mid-market company is simple:
- Know which third parties have access.
- Know why they have it.
- Give them only what they need.
- Monitor important access.
- Remove it when the need ends.
- Make one person accountable for each relationship.
Vendor access is only one part of what attackers can see and reach. For a broader view of unknown internet-facing systems and shadow infrastructure, read Why Mid-Market Companies Are the Easiest Targets on the Internet.
One Useful Question for This Week
Could your team produce an accurate list—today—of every vendor with privileged, remote, or persistent machine access?
If the answer is no, start with ten vendors and thirty minutes. The first useful version of the list is more valuable than a perfect version that never gets built.
VISO Group helps mid-market leaders turn security uncertainty into practical, prioritized action. If you want an independent review of your external exposure, third-party access, or broader security program, start a conversation with VISO Group.