Remote Access to a BAS Without Opening the Building to the Internet

Every service contractor wants remote access, and they're right to. Half the calls I take could be diagnosed from a trend log in ten minutes. The problem is how that access usually gets set up: in a hurry, by whoever was on site, with whatever worked first. And what works first is almost always the worst option.

This article walks through the options from worst to best, what each one really exposes, and what to ask for when you're the one who needs to get in. None of it requires exotic technology. It requires deciding who owns the door.

The worst option: a port forward

The quick fix goes like this. Someone logs in to the building's internet router, forwards a port from the public address to the supervisor's web interface (or worse, straight to a controller), and hands the contractor the public IP. It works immediately. It also puts the building's control system on the open internet, where automated scanners find exposed services continuously. You don't have to be a target. You just have to be reachable.

Once the port is open, the only thing between the internet and the building is whatever login the supervisor has — which, on the sites where people do port forwards, is often a default or shared password. If the port goes straight to a BACnet/IP or Modbus TCP device, there's no login at all.

Changing the port number doesn't help, by the way. Scanners check all of them. And "we only open it when we need it" tends to become "we opened it in 2019".

The other bad option: an unmanaged remote-desktop tool

The second most common setup is a consumer or commercial remote-desktop program installed on the supervisor PC "just for support". It gets around the firewall because the PC connects outbound to the tool's cloud service, which feels safer than a port forward. It isn't much safer.

• Nobody on the owner's side knows it's there. IT doesn't see it in their inventory, so it isn't patched, monitored or removed.
• The credential is usually shared. One account, one password, known by everyone at the contractor who has ever worked the site — including the ones who've left.
• It's unattended. Set to accept connections without anyone on site clicking "allow", so nobody sees when it's used.
• It gives full desktop control. Whoever gets in has the supervisor's operating system, not just the BAS.

This is the remote support tool nobody remembers, and I find one on a good share of the older supervisors I audit. If the owner hasn't approved it and IT doesn't manage it, it should come off.

The good options

VPN into the owner's network, with MFA

The owner's IT team runs a VPN. The contractor gets a named account, protected by multi-factor authentication, and the VPN profile only allows that account to reach the BAS zone — not the whole corporate network. This is the most common good answer, and it's the one IT is usually most comfortable with because it's the same tool they already manage for staff.

The detail that matters is the scope. A VPN account that lands you on the corporate network with full reach is better than a port forward but still too broad. Ask for access limited to the supervisor, or to the BAS zone, through a firewall rule written the way the segmentation article describes.

An approved remote-access gateway

Some owners use a dedicated remote-access appliance or service designed for operational technology: the gateway sits on the BAS side, connects out to a managed service, and users authenticate to that service with MFA. Good ones give per-user accounts, per-session approval, session recording and access limited to specific devices. "Approved" is the important word. The owner's IT or security team chooses it, owns the admin account and can switch it off. A gateway the contractor brought and still controls is closer to the remote-desktop problem than to a solution.

A jump host

A jump host is a hardened machine, usually in a network zone between corporate and BAS, that remote users connect to first. Engineering tools live on it, and it's the only machine permitted through the firewall into the BAS zone. The advantage is that the laptop at the other end never touches the building network directly, and there's one place to log, patch and monitor. It's more work to set up, and it's common on campuses, hospitals and larger portfolios.

Time-limited vendor access

Whichever mechanism you use, the vendor's access should be off by default and switched on for a job. The owner enables the account, or approves the session, for a window: today, this afternoon, until Friday. When the window ends, the access ends. An always-on vendor VPN that stays connected for months is a door propped open, even if the door itself is a good one.

How they compare

Any of the good options can be undone by bad habits: a shared account, MFA disabled "temporarily", an access window nobody closes. The mechanism matters less than the discipline around it.

Logging: who got in, when, and what they did

Remote access you can't audit is remote access you can't trust. At minimum, the owner should be able to answer three questions for any session: which person connected, when they started and stopped, and what they changed. That means logs from two places:

• The access path — the VPN, gateway or jump host — which records the user and session times.
• The supervisor's audit log, which records which account made which change. This only works if everyone logs in with their own account; a shared "service" login makes the audit trail useless.

Both need correct clocks. If the supervisor's time is forty minutes off, you can't line the two logs up. Point it at the site's time source. Logs that are never looked at are only half a control, but they're the half you'll desperately want if something goes wrong — see the first hour of a suspected compromise.

What never to install

A short list, and I'd hold to it even when the customer is shouting about a hot building:

• No port forwards to supervisors, controllers, routers or gateways. Not temporarily, not on a different port.
• No remote-desktop tools the owner hasn't approved, and none set to unattended access with a shared password.
• No cellular modem or router bolted into a panel to get around the owner's firewall. It's a back door the owner can't see, and it's the same problem as a port forward with a different cable.
• No personal accounts reused across customers. One contractor login used on forty sites means one leaked password opens forty buildings.

What to ask for as the contractor

If you're setting up support for a new site, this is a request IT will generally be pleased to receive:

1. A named remote account for each technician who needs access, not one for the company.
2. MFA on every one of those accounts.
3. Access scoped to the BAS supervisor, or the BAS zone, not the corporate network.
4. Access enabled on request, or for scheduled windows, with a way to get it switched on out of hours for emergencies.
5. A named contact at the owner who approves access and gets told when a technician leaves your company.

That last point links to a wider problem — the accounts nobody owns — which gets its own treatment in default passwords, shared logins and the accounts nobody owns.

The takeaway

Good remote access isn't harder to use than bad remote access once it's set up. It's just harder to set up in a panic. Do it at handover, when nobody is cold, and the 2 a.m. call becomes a VPN login instead of a port forward somebody forgets to close.

Found a wrong number or a broken link? Tell me and I’ll fix it.