My company runs a third-party, all-in-one appliance in our data center. Under normal conditions, it is accessed only through designated production terminals. When employees are away from the office, however, they can connect to the production environment through a VPN from a non-production workstation. That workstation also has access to the public internet.
We currently need help from the vendor. The engineers with the necessary expertise are in another city, while the local support staff can only follow their instructions. The current process involves a local technician connecting onsite, speaking with the remote expert, running commands, taking screenshots or photos of the results, and repeating the process. This is much slower than allowing the qualified engineer to view the session remotely.
I suggested that we initiate a controlled screen-sharing or remote-desktop session from the non-production workstation. We would start and monitor the session, could revoke access immediately, and already have a support contract with the vendor. My manager rejected this and insists that vendor engineers must work onsite because production must never be exposed to remote access.
I understand that remote access introduces risks, but I am unsure which specific security or compliance concerns make this unacceptable. Could the vendor's access violate geographic or regulatory restrictions, weaken network isolation, create auditing problems, or allow a compromised workstation to reach production? Is my manager being appropriately cautious, or is there a safer remote-support design—such as monitored screen sharing, temporary brokered access, or having our staff operate the system while the vendor observes—that would provide better efficiency without granting unrestricted control?
5 Answers
This is ultimately a documented risk decision, not something a junior employee should decide informally during an outage. Ask your manager what specific policy, contract term, regulatory requirement, or threat model prohibits remote vendor access. Then present the operational cost and a proposed controlled design to the security or compliance owner. If no approved alternative exists, follow the current process and make sure the delay and business impact are documented rather than bypassing the decision.
The vendor's physical presence is not automatically safer, but it may make accountability, identity verification, jurisdiction, and supervision easier. Third-party remote access has caused major breaches in the past, including cases where attackers entered through a contractor's remote connection. Your proposed process might be reasonable, but it needs formal approval, least-privilege access, strong authentication, monitoring, and an emergency revocation procedure—not just the assumption that a trusted vendor will behave properly.
The bigger issue is that the VPN arrangement may already undermine the isolation you are trying to protect. A non-production workstation that can reach both production and the public internet can become a bridge if it is compromised, especially if the production appliance uses old or difficult-to-patch software. Remote-desktop access adds another party, another endpoint, another account, and another activity stream to secure and audit. Disconnecting the session after noticing suspicious behavior is not a preventive control—an unauthorized action may already have occurred by then.
If the environment is genuinely air-gapped, remote access would not be possible at all. It sounds more accurate to describe this as a restricted or segmented environment, so the precise network design and policy matter.
Your manager may be responding to a real security or compliance requirement, not simply being overly cautious. Some environments require production systems to be isolated, prohibit third-party administrative access, or restrict access to employees in particular countries or jurisdictions. A vendor employee, contractor, or outsourced support team could unintentionally violate those requirements even if your company trusts the vendor. There is also a major difference between trusting a product vendor to develop and patch a system and allowing an individual support technician to interact directly with your production environment.
There are controlled alternatives between unrestricted vendor access and making a local technician act as a human relay. For example, your employee could connect through the approved VPN, start a recorded screen-sharing session, and let the vendor observe while your employee runs every command. A privileged-access or remote-support gateway could provide temporary, named, approval-based access with multifactor authentication, command logging, session recording, time limits, and a clear scope of permissions. Even a vendor session where your staff retains control may be acceptable if security and compliance formally approve the tool and process.
Screen sharing is generally safer than handing over control, but it still needs to be reviewed. The meeting platform, recording location, credentials, screenshots, and data visible on screen can all create separate security or privacy concerns.
That makes sense. I was focusing on how inefficient the current process is, but I should ask which requirement is driving the restriction and whether security can approve a more controlled option.