OT Security Vendor Access Session Governance

Remote Access into OT Environments: Vendor Governance Is Not Just VPN Logs

Vendors routinely need to enter our OT environments to repair and update our services. Yet the security responsibility and accountability for their access falls on our shoulders. Most OT organizations rely only on VPN logs or even manual tracking to manage vendor remote access and stay compliant. Here we explain why this approach leaves privileged sessions effectively ungoverned, and what continuous session attestation looks like.

The Liability of the Unreviewed Session

Six months ago, a controls engineer from a foreign SCADA vendor connected remotely to an OT system for routine maintenance. The work was completed and the invoice was paid. Nobody reviewed the session.

This is the most common scenario in OT environments we assess, and holds true across sectors. The vendor credential (or GSM backdoor) often remains active and sessions go unmonitored. When push comes to shove, the organization really has no record of what occurred inside the connection.

What VPN Logs Actually Tell You About Remote Access

VPN logs confirm a successful login. That is where their usefulness ends. Full stop.

They cannot tell you whether that credential has been used since the maintenance window closed. They cannot confirm whether the engineer who connected still works for the vendor. They cannot show whether someone else is now using those same credentials through RDP or SSH access. (More than 50% of cyberattacks exploited stolen credentials, according to CISA).

An untrusted session that nobody reviews is operationally indistinguishable from a persistent threat actor using legitimate credentials. The session authenticates with valid credentials, generates normal connection events, and terminates cleanly. The authentication events, access logs, and connection records look identical whether the session is authorized routine maintenance or an active intrusion.

The core question here is: do you intend to prevent an attack, or to document that it took place? VPN logs were not designed to capture any context needed for prevention. They were designed only to record connectivity events. So if the goal is to reduce the "blast radius" of an attack, can we somehow achieve session-level governance?

What is the difference between a routine vendor session and an active intrusion?

In environments without session-level governance, there is no technical difference visible in the logs. Both sessions authenticate with valid credentials, generate normal connection events, and terminate cleanly. The distinction requires session-level visibility that VPN-based remote access does not provide.

Alas, PAM and ZTNA Do Not Solve the Vendor Session Problem

Let's look at the options commonly provided by the marketplace. Privileged Access Management (PAM) controls credential checkout and vaults sensitive credentials. Zero Trust Network Access (ZTNA) enforces network-layer access policies based on identity and device posture.

Neither governs what happens inside the session once access is granted.

Instead, PAM confirms that the vendor used an approved credential through an approved workflow. ZTNA confirms that the connection met the required trust level at the point of authentication, the mere first 3% of a session. After that, the session is fully trusted. What the vendor does inside it is outside the scope of what these tools were designed to govern.

Wait, does PAM really not provide session governance?

PAM is a suite of tools that operate at the credential layer. Session governance is higher up in the stack, concerning the live connection itself. Ostensibly, some PAM tools offer just-in-time (JIT) authorizations to grant privileges just when they are needed, but these are so cumbersome to deploy and manage that they are rarely used in OT environments in practice. Instead, a vendor who checks out PAM credentials and opens an RDP or SSH session may execute any command their privileges permit. Without continuous attestation of what happens inside that session, the PAM record confirms the checkout. It cannot demonstrate what was done with the access.

Reprise: The Vendor Access Problem in OT Environments

Airgaps are a tantalizing way to sidestep this challenge. But remote vendor access is operationally necessary in almost every OT environment. SCADA vendors need to connect. DCS providers push updates remotely. System integrators troubleshoot over SSH and RDP.

The problem isn't with the vendor access itself. The problem is the absence of governance over what happens during those connections.

In reality, most organizations approach the problem with a combination of VPN access, shared or ephemeral accounts, and manual tracking. The vendor receives credentials. Those credentials remain active until someone revokes it. If you are lucky, someone risks putting in an expiry date. In practice, revocation depends on someone remembering to act. Often nobody does.

The result is an environment with active privileged credentials attached to individuals who may no longer be authorized, employed, or aware that their remote access still functions. These risks are ticking time bombs that every major compliance framework wants you to defuse.

What should privileged remote access governance look like in OT?

Effective privileged remote access governance in OT environments includes four capabilities:

85%
of lateral movement uses RDP/SSH
Palo Alto, Unit 42, 2026
30%
of breaches involve third parties
Verizon DBIR
90%
of attacks exploit identity
Palo Alto, Unit 42, 2026

Inside Continuous Session Attestation

Continuous attestation is the cryptographic verification of physical human presence throughout a privileged session. Unlike behavioral monitoring, which flags anomalies after commands execute, continuous attestation operates before execution. In other words, it's inherently preventative.

Every command inside a governed session requires a verified attestation signal confirming that a real person on an authorized device generated it. Automated scripts, lateral movement tools, and commands from compromised credentials fail attestation before they execute.

Wait, how is continuous attestation different from session recording?

Session recording captures what happened in a session. Continuous attestation controls what can happen. Recording is retroactive forensic evidence. Attestation is a proactive real-time enforcement control. In OT environments where a single unverified command can stop production, the distinction between recording and preventing is operationally significant.

Making It Practical with Keystrike

Keystrike delivers Continuous Remote Access Governance for OT environments. Every privileged remote session is governed from the moment it starts.

You cannot govern what you cannot see. At Keystrike, we make every vendor session visible, governed, and provable.

See What Your Current Tools Are Missing

Book a 30-minute session with the Keystrike team. We will show you exactly what is happening in your environment right now.

Book Your 30-Minute Session →

Frequently Asked Questions

What is the difference between PAM and continuous remote access governance?

PAM governs credential access and checkout workflows. Continuous remote access governance governs what happens inside the session after PAM grants the credential. They address adjacent layers of the same problem.

Does Keystrike replace ZTNA?

Keystrike completes ZTNA. ZTNA enforces access policy at the network boundary. Keystrike governs session activity after that boundary is crossed. Both are necessary for complete privileged session governance in OT environments.

Does Keystrike require agents on OT endpoints?

No, Keystrike lives on the jump boxes and bastion hosts in the IT/OT interface. It is deployed via a single-line GPO or Intune policy. No agents need to be put on the OT endpoints themselves (PLCs, RTUs, or HMIs).

Which compliance frameworks does Keystrike address?

Keystrike generates cryptographically attested session evidence that maps directly to IEC 62443 security zone requirements, NERC CIP requirements CIP-004, CIP-005, and CIP-007, and NIS2 continuous monitoring obligations.

What protocols does Keystrike secure?

Keystrike governs privileged sessions across RDP, SSH, and other remote access protocols regardless of the network pathway used to establish the connection.