Secure Remote Access for Cyber-Physical Systems (CPS)

What Counts as a Cyber-Physical System

A cyber-physical system is any system where software directly controls a physical process. In the building world that's the HVAC sequence running on a JACE, the lighting controller on a Niagara station, the chiller plant logic on a Distech AS, the access-control panel deciding which doors unlock at 6 a.m. In industrial settings it's the PLCs running a packaging line or the SCADA system monitoring a water treatment plant.

What unites them: a write to a register or a BACnet Present_Value moves something physical. That single property is why CPS remote access can't be modeled the same way as IT remote access. A compromised RDP session into a finance laptop is a data-loss event. A compromised session into a building's chilled-water plant can be a property-damage event, a comfort-complaint event, or in critical infrastructure a safety event.

Why Traditional Remote Access Falls Short

The tools most buildings and plants use today were not designed with CPS exposure in mind:

• Persistent site-to-site VPN. Once a vendor's laptop is on the BAS VLAN, the vendor has the same network reach as the BAS supervisor — every controller, every router, every gateway. There is no protocol restriction at the tunnel boundary.
• Port forwarding to a JACE, HMI, or web UI. Inbound TCP/443 (or worse, TCP/80) from the public internet to a controller exposes the device's entire web stack, including default credentials that often survive commissioning.
• Shared screen-sharing tools (TeamViewer, AnyDesk, RustDesk). The audit trail is whatever the tool vendor stores. Credentials are often shared across a contractor's technicians, so attribution after an incident is impossible.
• Open SSH or RDP jump host. Better than the above, but still grants flat IP reach once the user is in, and inherits all the credential-management problems of any shared bastion.

Industry guidance has converged on the same set of countermeasures. NIST SP 800-82 (Guide to Operational Technology Security) explicitly recommends layered remote access controls, brokered through dedicated access servers, with multi-factor authentication and session logging. IEC 62443 describes the same idea through its zone-and-conduit model: remote access is a conduit crossing the zone boundary, and the conduit itself has security requirements distinct from the zone it enters.

For a deeper walk through the 62443 framing, see IEC 62443 Security Zones for Building Automation.

Architecture Patterns That Work

1. Brokered Access Through a Hardened Intermediary

Vendors never connect directly to a CPS device. They authenticate to a broker (a managed access platform, a hardened jump host, or a ZTNA gateway), the broker authorizes the specific target, and the broker proxies the protocol traffic. The vendor's endpoint never sees the BAS network directly. NIST SP 800-207 (Zero Trust Architecture) generalizes this pattern: trust is evaluated per-request, not per-network-segment.

2. Identity-Bound, Not Credential-Bound

Each technician authenticates with their own identity, ideally federated through their employer's identity provider so account lifecycle (offboarding, role changes) flows automatically. Shared accounts — one set of credentials for everyone at a contractor — are the single most common gap in BAS remote access audits.

3. Time-Boxed Sessions With Explicit Approval

Access is granted per task, not permanently. A two- to twenty-four-hour window covers most field work; anything longer should require a fresh approval. When the window closes, the session terminates and the route disappears. There is no standing access for a contractor between visits.

4. Protocol Restriction at the Perimeter

The conduit carrying the remote session should only pass the protocols the technician actually needs — BACnet/IP on UDP 47808, Niagara Fox/Foxs, Modbus/TCP, the controller's HTTPS UI. Everything else (SMB, RDP to adjacent IT hosts, outbound east-west traffic from the vendor endpoint) is denied by default. For BACnet specifically, see BACnet Firewall Rules: Ports to Open and Block.

5. Full Audit Trail of Actions, Not Just Logins

A login record alone isn't enough. The audit trail should capture which device the technician reached, which writes they issued (the BACnet WriteProperty calls, the Modbus FC06/FC16 transactions), and ideally a session recording for tools that don't expose protocol-level logs. After an incident, the question is "what changed and who changed it," and that answer has to be reconstructable from logs the building owner controls.

Step-by-Step: Designing CPS Remote Access

1. Inventory the access actually needed. List each external party (HVAC contractor, fire-alarm vendor, controls integrator, energy analytics platform) and the specific equipment each one touches. Most sites discover the list is longer than they expected.
2. Define zones and conduits. Group CPS equipment by criticality and protocol family. The chiller plant is one zone; the lighting network is another; the BBMD-bridged supervisory network is the conduit between them. Apply IEC 62443 zone thinking even if you're not pursuing certification.
3. Pick a brokered access mechanism. Options range from a self-built bastion + identity provider + protocol firewall, through managed remote access platforms designed for OT, to commercial ZTNA products extended to OT networks. The right choice depends on how many sites, how many technicians, and how much engineering capacity you have to maintain the system.
4. Enforce default-deny at the conduit. The broker should only allow the specific protocol and the specific destination required for the session. A technician requesting access to a JACE doesn't get a route to the MS/TP routers behind it unless that's the task.
5. Log every action centrally. Send audit data to a system the building owner controls — not just the vendor's own platform. The logs should survive a vendor relationship ending.
6. Test the off-ramp. When you offboard a contractor or rotate a credential, verify the access actually disappears. A surprising number of organizations discover months later that the offboarded vendor's VPN profile still works.

Common Pitfalls

• Treating the BAS VLAN as "the perimeter." A VLAN is a segmentation primitive, not an access control. Anything that reaches the VLAN reaches every device on it. The access boundary has to be at the conduit, not at the VLAN tag.
• Relying on the controller's own authentication. Many older field controllers ship with weak default credentials and no MFA. Authentication should happen at the broker, not at the device.
• Leaving an emergency "always-on" tunnel. The tunnel set up for a one-time troubleshooting session almost always becomes permanent. Set an explicit expiry and have the system enforce it.
• Auditing logins but not actions. Knowing a technician logged in at 14:03 doesn't tell you they wrote a 55°F setpoint to a heating loop at 14:11. Capture the protocol-level activity.
• Not separating engineering access from monitoring access. Read-only access (trend extraction, alarm review) and read-write access (configuration changes, point writes) are different risk profiles. They should be granted independently.

When to Escalate

Bring in dedicated OT security expertise — either internal or an outside firm — when any of the following are true:

• The building or plant has had a confirmed unauthorized access event, or a near-miss where a vendor's account was used in a way the vendor didn't expect.
• Insurance renewal, a tenant agreement, or a regulator is asking for documented OT remote access controls and you can't produce them.
• The IT security team is responsible for the BAS network but doesn't have BACnet, Modbus, or Niagara experience — their tooling will model the traffic incorrectly.
• You're moving from a single building to a portfolio and the current ad-hoc remote access process won't scale.

A practical next step before bringing in outside help is to walk through a structured self-assessment of the current setup. See How to Run a BAS Cybersecurity Audit for the checklist most building owners use as a starting point.

Source Attribution

The guidance in this entry draws on the following publicly available sources:

• NIST SP 800-82 — Guide to Operational Technology (OT) Security — National Institute of Standards and Technology. Covers remote access controls, network segmentation, and authentication recommendations for OT environments.
• NIST SP 800-207 — Zero Trust Architecture — The framework for per-request, identity-bound access decisions that underpins modern brokered access designs.
• IEC 62443 series — Security for industrial automation and control systems. The zone-and-conduit model and the security level requirements referenced throughout this article.
• CISA — Industrial Control Systems guidance — U.S. Cybersecurity and Infrastructure Security Agency advisories on remote access to control systems.
• ASHRAE Standard 135 (BACnet) — The normative reference for BACnet/IP and BACnet/SC protocol behavior, including the secure-connect mechanism designed to reduce reliance on network-layer protections.

Additional patterns and field guidance from SiteConduit's work with building owners and integrators.