← Return to topic

Is my manager being overly cautious about remote support, or am I missing something as a junior employee?

arttretyakov · 7 Sep 2026 at 01:10 · permalink

My company purchases a black-box, all-in-one appliance/service from a third-party vendor. The appliance is deployed in our data center. Under normal circumstances, it can only be accessed through designated production terminals.

However, when we are away from the office and need to respond to production alerts, there is also a way to connect to the production environment through a VPN using a non-production workstation.

The problem is that a non-production workstation can connect to both the production environment and the public Internet. This means that, in principle, a third-party support engineer could remotely connect to that workstation via a screen-sharing/remote-desktop session and troubleshoot the production issue.

We currently have a production issue that requires assistance from the vendor's support engineers. If we use the VPN route from a non-production workstation, the vendor's engineers could troubleshoot the problem remotely and probably resolve it much faster.

However, My manager has rejected this approach. He insist that the vendor's support engineers must come onsite and that our production environment must never be exposed to remote access.

Personally, I find this requirement somewhat unreasonable.

The remote desktop session would be initiated and shared by us. If we noticed any suspicious or unauthorized activity, we could immediately terminate the session. From my perspective, the security risk seems relatively low and controllable. We also already have a maintenance/support contract with the vendor, so it seems unlikely that their engineers would intentionally perform unauthorized actions.

As an front-line employee, my goal is to identify and resolve production issues as quickly as possible. In this case, remote support seems to offer significantly higher efficiency while still allowing us to maintain control over the connection and disconnect at any time.

So I'm wondering: Am I missing an important security or compliance consideration here? Is this simply a case of me not having enough experience to understand management's concerns, or is management's decision genuinely overly restrictive?

There is also an important practical problem:

The vendor's engineers who actually have the expertise to troubleshoot this system are not located in the same city as our company. The local support staff can come onsite, but they don't have the technical expertise to diagnose the problem themselves.

As a result, the current process is basically:

1. A local support engineer goes onsite.
2. They connect to the production environment.
3. They communicate with the remote vendor engineer online.
4. The vendor engineer tells them what command to run.
5. The local engineer runs the command and takes a screenshot/photo of the result.
6. They send it back to the remote engineer.
7. Repeat.

The efficiency is extremely poor compared with simply allowing the qualified vendor engineer to remotely view and troubleshoot the system.

I'd like to hear opinions from people who work in IT infrastructure, cybersecurity, or enterprise operations:

Is management's approach justified from a security/compliance perspective? What risks am I overlooking? Or is there a better way to design a controlled remote-support process that gives the vendor access without unnecessarily exposing the production environment?

huysk · 7 Sep 2026 at 19:08 · permalink

Something I’ve never understood is how you can purchase a product because you trust the vendor, but then not trust that same vendor to provide support for the product they sold you, especially when you’re probably relying on them for updates as well.

6texture2pack · 7 Sep 2026 at 19:16 · permalink

Well if you are in the eu, you might have some rules about remote access for example, so there might be some regulation thingie, or paperwork involved

wotfasedy · 7 Sep 2026 at 19:23 · permalink

Huge difference in trusting a product and their securing/patching of the product itself versus some level 1 tech remoting into it and your production environment.

kubNfYN · 7 Sep 2026 at 19:28 · permalink

Depending on the production environment, having the technician remote in may be a security breach as defined by some accredation or third party licensing (if you are a shop that makes parts for Amazon, but you need a oracle db fix. Amazon won't want Oracle to have access to a production machine). If your prod network is air gapped, look into why.

Blackcore98 · 7 Sep 2026 at 19:28 · permalink

Manager here. I am sure they have a reason. Personally, I never block or otherwise forbid a noncompliant service without also providing a compliant alternative. If none exists, I document and put the accountability on admin, since I for sure did not have any say in the original contract to begin with.

Not sure if that helps.

DIYJUD · 7 Sep 2026 at 19:28 · permalink

I agree that you are right, it is badly inefficient. However, your boss has final say. You can lay out the options to him but he makes the decision. Your job is to follow and implement his decisions. But get it in email if you can so if down the road someone above them asks why you are doing it like that, you have proof it wasn't your idea.

eljosealmeida69 · 7 Sep 2026 at 19:37 · permalink

That's not the scenario the OP describes though.

eljosealmeida69 · 7 Sep 2026 at 19:39 · permalink

These things are always down to a risk/benefit analysis. What's the risk and what's the benefit, and does the benefit outweigh the risk? The boss has made that evaluation and decided it's not worth it. It's possible the boss may be unaware of some factors which might change his mind, so you can try presenting more info and ask him to re-evaluate, but in the end it's down to whether executive leadership feels it's worth the trade-off.

FostGames · 7 Sep 2026 at 19:49 · permalink

They probably have some old, old, incredibly old school shit in their stack they can’t let be exposed to the internet. Not necessarily a problem with trust in a vendor but trust of the internet.

bahbahblacksheep9072 · 7 Sep 2026 at 19:58 · permalink

I don't understand how, if your production environment needs to be air gapped, how is it ok for you to VPN in from a random computer?

It's not abnormal to block access to a production machine from an external network. We have to isolate our machinery because they were running out of date operating systems when we bought them a decade ago plus. I actually had a system running DOS for quite some time into the year 2010.

So, really, you shouldn't be able to VPN into a machine like that. If your machine is compromised, it becomes trivial to do all sorts of things to an outdated host. You usually allow a single protocol through, like ftp, from select workstations.

younghaze2337 · 7 Sep 2026 at 20:46 · permalink

Some regulations will require access to certain systems to be strictly limited to named people who reside within a certain geographic jurisdiction. For example, only US employees allowed to access sensitive US-hosted resources. Letting a 3rd party vendor access those systems means if the vendor ever surreptitiously outsources that work to another country, you have committed a regulatory violation by allowing that access.

xDiamondHell · 7 Sep 2026 at 20:48 · permalink

One of the largest credit card breaches in history occurred by the attackers gaining initial access through a third-party HVAC contractor's remote access to the department store's environmental systems.