WebParam perspective | October 2026
Imagine a supplier needing remote access to fix a business-critical system. The work takes a day, but the account, VPN route or API token stays active for months. Later, the supplier has a security incident. The first question is not only whether the supplier has contained it. It is also: what could that supplier still reach inside your business?
Suppliers can be essential partners. Managed service providers, software vendors, payroll processors and consultants may need access to systems or information to do their jobs. The risk becomes harder to manage when that access is broader or longer-lived than the work requires. The UK National Cyber Security Centre (NCSC) notes that a supplier may need privileged and remote access to a customer’s systems. [1]
Map the connection, not just the contract
Start with the suppliers that could interrupt a critical service or reach sensitive data. For each one, record the business owner, the service provided, the systems and data involved, and every route into your environment. Include named user accounts, shared accounts, remote access tools, API keys, service accounts, cloud integrations and network connections.
Ask the owner to verify the list with a real access report. A contract may say “support access,” while the actual account can administer a whole tenant. A supplier may have finished a project but kept a token for an integration nobody has reviewed. The NCSC advises organisations to monitor privileged supplier access and keep track of approved third-party connections. [2]
The map also reveals concentration risk. If one provider manages your identity system, backups and incident response, its availability matters to all three. Write down what you would do if that provider could not help during an incident.
Match each permission to a task
Give a supplier the access needed for a defined job, for a defined period. Use named accounts where practical so actions can be traced to a person. Protect remote and privileged access with multifactor authentication, and avoid permanent administrator rights when a narrower role or a temporary grant will work.
For integrations, ask whether a token can be limited to one application, dataset or action. Record who owns it, how it is stored and when it expires or will be rotated. The same review should cover subcontractors: if another company carries out the work, know whether it uses its own accounts or the original supplier’s credentials.
CISA recommends least privilege and separation of duties for third parties and managed service providers. Their access should be confined to the devices and systems within their responsibilities. [3] That is a practical test: could the supplier complete its task with less reach?
Agree what happens when something goes wrong
A supplier security questionnaire is useful only if the answers change how you work together. Decide who contacts whom when an incident may affect your systems, what evidence the supplier can provide, and how quickly you can suspend its access without losing your own ability to operate.
Put those decisions into the relationship while it is calm. Agree on incident notification routes, support contacts, access reviews and a way to retrieve your data or configurations if the service ends. The NCSC recommends monitoring supplier security performance through regular reviews and checking the accounts suppliers use to reach your environment. [2]
Your response plan should include a supplier scenario. If the supplier reports a compromise, who checks its accounts and tokens? Who can disable its remote connection? Which logs would show what it accessed? Which business process needs a temporary workaround? A short tabletop exercise can expose gaps before an urgent call does.
Rehearse the end of the relationship
Offboarding is where old access often survives. When a contract or project ends, disable named accounts, revoke API tokens and remote routes, recover devices or credentials, and confirm any shared secrets have been changed. Check that a legitimate integration will still work before removing a service account.
Ask the business owner to sign off on both sides of the handover: the supplier has returned or transferred the information you need, and your team has removed access that is no longer justified. Repeat the check when a supplier changes subcontractors or the person assigned to your account.
This is related to our AI tool access audit: the same principle applies to people and integrations behind an AI service. Every route into your systems needs an owner, a limited purpose and a clear end.
One useful action this October
Choose one supplier with privileged access or responsibility for a critical service. Ask its business owner and your technical lead to show the real accounts, tokens and connections it uses. Remove what is no longer needed, narrow what remains and agree on a response contact and an offboarding trigger.
A good supplier relationship should survive a clear question about access. When you know exactly what a partner can reach, you can work together with more confidence and respond faster if something changes.
