Securing Vendor Access to Company Systems

What this addresses

A supplier may legitimately require temporary access for maintenance, but permanent broad permissions create unnecessary exposure after the engagement ends.

Practical implementation steps

• Document each supplier's approved business purpose
• Provide an individual named identity and least-privilege scope
• Require MFA and time-bounded access
• Record relevant administrative activity
• Revoke access and verify offboarding after the task

Acceptance test

Choose an expired maintenance request and confirm that the associated identity cannot access the environment or reuse old credentials.

Common failure mode

Avoid sharing permanent administrator passwords over email or using one service account for all vendors.

Buy an outcome, not permanent administrator access

A supplier may need to diagnose an application, maintain a firewall or operate a managed service. Translate that task into the systems, actions and duration required. Remote desktop administration is not the default answer to every support request. Ask whether a bounded diagnostic export or supervised session would meet the need with less exposure. Identify the internal owner who can authorize access and the supplier contact responsible for the named operator. A commercial relationship does not establish that every employee of the supplier should enter every customer system.

Separate the identity from the agreement

Use individual, attributable identities where the platform supports them, with suitable authentication and scoped permissions. Shared credentials make it difficult to distinguish authorized maintenance from an unrelated operator’s activity. If a legacy system forces a shared account, document the limitation and use a controlled access process rather than casually circulating the password. Revoke temporary grants when the task ends and review recurring grants against the current service scope. A contract end date should trigger an operational access review; it should not be the only time anyone checks the account.

Agree the data and connection boundaries

Specify which records may be accessed, whether information can leave the environment and how evidence will be returned. Avoid sending a full customer database when synthetic data or a minimal, approved extract can reproduce the issue. Check remote support software, file transfer features and unattended access separately. If a supplier proposes a new outbound integration, review the destination, credential storage and failure behavior through the normal security process. Do not open broad network access merely because a troubleshooting guide suggests it without reference to your actual environment.

Observe a real maintenance session

In a safe test, give the operator only the intended role and perform the approved task. Confirm a prohibited operation is denied and that the session or change leaves useful evidence. Exercise access expiry, credential rotation and emergency revocation. For recurring maintenance, agree how changes are proposed, tested, approved and reversed. Monitoring should be proportionate and protect privacy; logging every keystroke is not automatically necessary or lawful. What matters is sufficient accountability for the system and task, with evidence available to the authorized customer team.

Close the relationship cleanly

When work ends, remove accounts, delegated roles, tokens, support agents and network exceptions associated with the engagement. Confirm ownership of documentation and operational credentials has returned to the organization. Review whether the supplier still retains permitted data and follow the agreed retention and deletion process. Track exceptions where a dependency prevents immediate removal. The resulting record should show what was granted, what work occurred and how access was closed. Supplier assurance is stronger when it is tied to observable access boundaries than when it rests only on a generic questionnaire.