Third-Party and Vendor Access
External engineers with administrative rights, whose departure nobody tells you about. The category where controls fail most reliably.
Procedure
Vendor support access is granted during an implementation, needed occasionally afterwards, and revoked almost never.
Why it fails
Nobody tells you when their engineer leaves. The vendor's staffing is not visible to you.
Access was granted by a project team that has since dissolved.
The engagement ended and the access did not.
Shared vendor accounts, so several of their people use one credential.
Access granted through a route you do not monitor — a support tunnel, a remote access tool the vendor supplied.
No end date recorded anywhere.
The requirements at engagement
Named individuals, not a shared vendor account.
An end date, recorded in whatever system triggers your access processes.
An internal sponsor accountable for the engagement.
Defined scope: which systems, which rights, for what purpose.
An identifiable account convention so every third-party account can be listed in seconds. This costs nothing at creation and cannot be retrofitted cheaply.
Contractual terms covering notification of their staff changes, which is frequently absent and worth asking for.
The access model
On request, not standing. Vendor access should be the strongest case for just-in-time, because the population changes without your knowledge.
Time-boxed to the support window.
Brokered and recorded, always. Third-party sessions are the ones most worth having a record of.
Supervised for the highest tiers, meaning someone internal watching in real time, which is heavier than it sounds and appropriate for a small number of cases.
Approved per session where the tier justifies it.
Their own remote access tools
A specific and common problem.
Vendors frequently supply their own tool — a support agent, a tunnel, a remote desktop product.
It bypasses your controls entirely, and it is installed because it is easier.
Inventory these, which requires looking rather than asking.
Replace with your brokered path where possible.
Where it is not possible, treat the tool as a privileged access path: restrict when it can run, log it, and alert on use.
Reviewing it
Quarterly, list every third-party account, which the naming convention makes trivial.
Confirm each with its sponsor: still needed, still the right person, still the right scope.
Remove anything past its end date, which should be none.
Check for external email domains in administrative groups, which catches accounts the convention missed.
Expect the first review to find accounts from engagements that ended years ago, which is the normal result.
Offboarding a vendor
At contract end, a defined checklist: accounts disabled, credentials rotated, their tooling removed, network access revoked, certificates revoked, data returned or destroyed.
Rotate anything they knew, on the assumption that knowledge persists.
Confirm in writing with the vendor.
Record completion, because this is exactly what an auditor samples.
The naming convention
One decision at account creation that makes every subsequent control possible.
A prefix, an attribute, or a separate organisational unit — any works.
Applied at creation, because it cannot be retrofitted reliably.
Enables: listing all third-party access in seconds, applying different session and device policies, setting expiry by default, and auditing separately.
Agree it once with whoever creates accounts, and enforce it at the identity platform rather than by policy.
Without it, the quarterly review is a manual trawl through user lists guessing who is internal.
Their remote access tooling
Vendors supply their own tools, and those bypass everything.
Inventory them, which requires looking at what is installed rather than asking.
Common forms: support agents, tunnelling clients, remote desktop products, phone-home services.
Replace with your brokered path where the vendor will accept it, which is more often than expected if asked at contract time.
Where it cannot be replaced, treat the tool as a privileged path: restrict when it may run, log it, alert on use, and require it to be enabled per session rather than permanently.
Record each as residual risk with the reason.