Time-Limited Sessions: The Missing Control in OT Remote Access

Ask a building owner how many active remote access connections exist to their BAS network right now, and the honest answer is usually: "I have no idea." VPN tunnels established months ago may still be live. TeamViewer sessions opened for a one-hour troubleshooting call may still be available. SSH keys distributed to a contractor who left the company last year may still grant access.

Standing access — remote connections that remain active indefinitely — is the single most common security gap in building automation. And it is the easiest to fix. Time-limited sessions that auto-expire after a defined window (2 to 24 hours) eliminate standing access without adding friction to the technician's workflow.

The standing access problem

Standing access means a remote connection that exists whether or not anyone is actively using it. In building automation, this typically looks like:

• Persistent VPN tunnels: The integrator has a site-to-site or client VPN that was configured during commissioning and never turned off. The tunnel reconnects automatically after reboots. There is no expiry date.
• Always-on remote desktop: A PC on the BAS network runs TeamViewer or AnyDesk with an always-available session ID. Anyone with the password can connect at any time.
• SSH keys without rotation: SSH access was configured with key-based authentication. The keys were never rotated. Former employees of the integrator firm may still have valid keys.

Each standing connection is an open door. It does not require an attacker to breach a firewall or exploit a vulnerability. The door is already open. They just have to walk through it.

Why standing access is dangerous: the numbers

According to Dragos, 70% of OT security incidents involve third-party access. Not sophisticated zero-day exploits. Not nation-state attacks. Third-party access — the same VPN tunnels and remote desktop sessions that BAS integrators use every day.

The Gartner CPS Secure Remote Access Market Guide (2026) is explicit: "VPNs, jump servers, and IT-centric access tools create unacceptable risk because they lack asset-level, protocol-aware, and operational controls." Standing access is the operational control gap they are describing.

Consider the attack timeline. If a VPN credential is compromised, the attacker has access for as long as the VPN tunnel stays up — which is indefinitely. If a time-limited session credential is compromised, the attacker has access for the duration of the session window — hours, not months.

Time limits do not prevent every attack. But they constrain the window of exposure from unlimited to bounded. A 4-hour window is not zero risk, but it is dramatically less risk than a 4-month standing connection.

What time-limited sessions mean in practice

A time-limited session works like this:

• Session request: A technician requests access to a specific building site through the management platform. The request specifies a time window: 2, 4, 8, or 24 hours.
• Authentication: The technician authenticates individually (not with shared credentials) and opens the session using a lightweight desktop app.
• Active session: For the duration of the window, the technician has Layer 2 access to the building's BAS network, restricted to allowed protocols by a default-deny bridge filter.
• Auto-expiry: When the time window closes, the session terminates automatically. The encrypted tunnel is torn down. The network connection ceases to exist. No action is required from the technician or the building owner.
• Re-authentication: If the technician needs more time, they request a new session and re-authenticate. There is no "extend" button that silently adds hours without verification.

Between sessions, there is zero standing access. No tunnel, no connection, no pathway from the internet to the building network. The next session requires fresh authentication and a new time window.

The compliance case

Session management is a specific requirement in every major OT security framework:

IEC 62443

IEC 62443-3-3 SR 2.6 requires "remote session termination after a period of inactivity" and SR 1.11 requires "session lock after a defined period." The standard explicitly addresses the risk of sessions that remain active beyond their intended purpose.

NIST 800-82

NIST SP 800-82 Rev. 3 recommends "time-based access control mechanisms" for OT remote access and warns against "persistent remote connections that provide continuous access to the OT network." The guidance is clear: OT remote access should not be always-on.

Cyber insurance

Insurers are increasingly asking specific questions about OT remote access controls in their underwriting questionnaires. "Do you require time-limited remote access sessions with automatic termination?" is appearing on renewal forms. If your answer is no, your premium goes up — or your coverage gets restricted.

Gartner CPS SRA

The 2026 Gartner CPS Secure Remote Access Market Guide identifies session management as a core capability. Vendors that provide only persistent connections — without time-limited, auto-expiring sessions — do not meet Gartner's framework for CPS secure remote access.

Do time limits slow technicians down?

The most common objection to time-limited sessions: "My technicians need access when they need it. Time limits will get in the way."

In practice, the vast majority of BAS maintenance sessions are short. Based on typical building automation service patterns:

• BACnet troubleshooting: 1-3 hours. The technician runs WHO-IS, checks controller properties, adjusts setpoints, and verifies operation.
• Modbus register reading: 30 minutes to 2 hours. Polling energy meters, reading VFD parameters, or verifying sensor calibration.
• Niagara programming: 2-6 hours. Connecting Workbench to a JACE, modifying control logic, deploying changes, and testing.
• Firmware updates: 1-4 hours. Uploading firmware to controllers and verifying operation after the update.
• Commissioning: 4-8 hours. The longest sessions, typically during initial setup or major system changes.

An 8-hour session window covers the vast majority of maintenance tasks. A 24-hour window covers everything including commissioning. If a technician needs more time, they request a new session — which takes seconds, not hours.

The time-limited model adds one step (selecting a session duration) and removes one risk (standing access to the building network). For integrators managing multiple client sites, it also provides clear documentation of exactly when each technician accessed each building — a benefit for both the integrator and their clients.

What auto-expiry looks like from the technician's perspective

A well-designed time-limited session should be frictionless:

• The technician opens the desktop app, selects the building site, chooses a session duration, and authenticates.
• The connection establishes in seconds. Their workstation is on the building's BAS network at Layer 2.
• They work normally — BACnet discovery, Modbus polling, Niagara Workbench, controller web interfaces — with no workflow changes.
• A notification appears 15 minutes before the session expires, giving the technician time to save their work.
• The session terminates automatically. If more time is needed, the technician requests a new session.

The technician's workflow is virtually identical to a persistent VPN — except the session has a defined end. There is no ongoing VPN management, no credential rotation anxiety, and no IT department involvement. The session lifecycle is handled automatically.

Beyond time limits: combining session expiry with protocol controls

Time-limited sessions are most effective when combined with other security controls:

• Protocol firewalling: Time limits constrain the window of exposure. Protocol firewalling constrains what can happen during that window. Together, they reduce the attack surface on two dimensions simultaneously.
• Per-protocol traffic monitoring: Within a time-limited session, traffic monitoring provides visibility into what the technician actually did. If the session was supposed to be BACnet maintenance but generated 200 MB of HTTP traffic, that anomaly is recorded and visible.
• Bandwidth limiting: Even with a short session window, an attacker could attempt bulk data exfiltration. A 10 Mbps bandwidth cap makes this impractical within a 2-4 hour window for the data volumes that typical BAS networks contain.
• One-click kill switch: If anomalous behavior is detected during a session, the building owner can terminate the session instantly — without waiting for the time limit to expire.

Each control addresses a different risk. Time limits address standing access. Protocol firewalling addresses unauthorized protocol usage. Traffic monitoring addresses visibility. Bandwidth limiting addresses exfiltration. Together, they implement the defense-in-depth approach that every OT security framework recommends.

SiteConduit provides time-limited, auto-expiring remote access sessions for building automation. Sessions from 2 to 24 hours, with protocol firewalling, per-protocol traffic monitoring, and instant termination. No standing access. No forgotten VPN tunnels. No compliance gaps.

Join the waitlist for early access, or visit our FAQ for more details.