Contractor and vendor access: an underestimated risk point
Third parties with access to your systems are one of the least-controlled security perimeters. How to think about this from a management perspective.
Most serious security incidents happen somewhere other than where they are expected. The perimeter of a company's own infrastructure is reasonably understood today: there are firewalls, policies, and someone responsible for information security. But there is another risk point that is controlled far less carefully.
I am talking about the access that companies grant to third parties: contractors, integrators, software vendors, outsourced development teams. This access is often granted quickly, in the context of a specific project - and then not revoked for years.
What the typical picture looks like
A company hires an integrator to implement a CRM. The integrator is given database access, system access, possibly email access. The project ends. Some access is revoked, some is not, because "we might need support later". A year later the integrator's team has turned over, but the credentials are still live.
Or: a company works with an outsourced development team. The developers have access to the repository, the staging environment, sometimes production. The engagement ends. The access remains.
I ask about this with almost every client project, and the standard answer is: "we have some process for it, but honestly there is no precise registry." There is almost never a precise registry.
Why this is a real risk, not a theoretical one
In 2019, several publicly known incidents were tied specifically to access through third parties. Attackers increasingly prefer to compromise a less-protected supply chain link rather than attacking the target company directly. A contractor with privileged access to your infrastructure but without your level of protection is a direct route in.
This is not hypothetical. The Target breach in 2013 began through an HVAC contractor that had network access. The same pattern has been repeated regularly since.
What needs to be done
First - run an inventory. List all third parties that have or have had access to your systems. For each: exactly what access, since when, who granted it, is it still active.
Second - the principle of minimum access. A contractor should only have access to what is needed for the specific task. Not the entire database - a specific table. Not the entire repository - a specific project.
Third - expiry and revocation. Access for a temporary project should either have a defined expiry or be explicitly revoked on completion. This is an organisational procedure, not a technical question - someone must own that action.
Fourth - environment separation. A contractor who needs a production database to do their work is an exception requiring separate justification. The default should be staging, anonymised data, a restricted environment.
A quick check
Three questions that give a fast read on the situation:
- Can you right now name the complete list of active accounts that do not belong to your employees?
- When was the last third-party access audit conducted?
- Is there a procedure for revoking access when a project ends - and who is responsible for it?
If the answer to the first question is "no" or "I do not know", that is sufficient reason to make this a priority for the next quarter.