Remote contractors as a second risk perimeter
External engineers and integrators require just as much access discipline as full-time staff - often more.
When a company brings in an outside developer or integrator, most of the attention goes to the task: what needs to be done, by when, for how much. The question of what access that person will have - and what happens to it after the work is done - tends to stay at the edge of the conversation.
That is an understandable way to set priorities. It is also a systemic vulnerability.
Why a contractor is a separate risk category
A full-time employee goes through onboarding, signs agreements, works inside corporate infrastructure, and generally has an interest in a long-term relationship. Their access is provisioned through HR, tied to a specific role, and has a clear lifecycle.
A contractor works differently. They may be physically in another city or country. They work from multiple machines, possibly personal hardware. Their motivation is bounded by the contract period. After the work ends, nobody automatically revokes their access unless that process was built on purpose. The principle that external access channels can become the attack vector - not just internal weaknesses - was demonstrated at an industrial scale.
Contractors also often work with several clients at the same time. That is not a problem in itself, but it means that corporate credentials may sit alongside data from other companies on the same devices.
Common mistakes with external access
From practice, the most frequent problems look like this.
Access is granted broadly - "so as not to slow them down." The contractor gets admin rights or production access where a test environment would have been sufficient.
Access has no expiry. The contract ends, the person stops working, but the account stays active. Sometimes this surfaces accidentally a year later.
Access is not documented. Who granted what, to whom, when - there is no record. Reconstructing the picture during an incident becomes impossible.
A single shared account is created for several contractors. No personalization, no audit trail.
What needs to be in place
Discipline around external access is not paranoia - it is basic hygiene. The minimum required:
- a separate account for each contractor with their name on it, not a shared one;
- access only to what is needed for the specific task - not "just in case";
- access duration tied explicitly to the contract term, not "we'll sort it out later";
- a list of active external accounts that is reviewed at least quarterly;
- when work ends, access is revoked explicitly - not left waiting for someone to remember.
A separate point: production access. If the task can be done in a test environment or with anonymised data, there is no reason to grant access to production. This rule gets broken more often for convenience than out of genuine necessity.
How this works with integration firms
With integrators the situation is more complex: a single vendor company may have several people working on the project, and the team composition can change mid-engagement. The thing to agree on upfront is: who specifically gets access, how you are informed when the team rotates, and who on the integrator's side is responsible for compliance.
The access scope and responsibility terms are better fixed in the contract or a formal addendum. Verbal agreements do not hold here.
A checklist before granting access
Before opening access to an outside contractor, I recommend answering five questions:
- What specific systems and data are needed - and why those?
- What is the minimum privilege level that is actually sufficient for the task?
- How long is the access valid?
- Who inside the company owns the revocation?
- Where is the grant recorded?
If there are no answers, the access should not be granted yet.