OEM Remote Access Field Guide
Every OT network has vendor access it did not fully plan for. OEM and third-party automation vendors need remote access to service their equipment, and they have spent decades getting it the easiest way available: cellular modems, dual-homed laptops, always-on VPN tunnels installed during commissioning and never reviewed again. The result is a remote access layer that exists outside your security architecture, outside your change management process, and outside your visibility. This guide covers the full remediation arc: finding what is already in your environment, replacing uncontrolled access with a governed architecture, and building the operational procedures that keep it that way.
Why OEM remote access is structurally different
IT remote access is a solved problem. You control the endpoints, you own the identity infrastructure, and you define the access policy. OEM remote access inverts all three.
The vendor controls the endpoint. Their technician connects from a laptop you have never seen, running software you have not approved, with credentials you did not issue and cannot revoke. Your access policy applies at your perimeter, but the vendor's equipment may have its own path in, such as a cellular modem installed during commissioning, a serial-to-Ethernet converter with a public IP, or a maintenance port that predates your network segmentation by fifteen years.
The support model compounds the problem. OEM vendors structure their service agreements around access assumptions. Always-on connectivity is often framed as a technical requirement for remote diagnostics, predictive maintenance, or firmware update delivery. In practice, most of this traffic is periodic or triggered, not continuous. The "always-on" requirement is a support model preference rather than an engineering necessity.
The consequence is a class of access that is simultaneously necessary and uncontrolled. Cutting it off breaks vendor support agreements and leaves equipment without a service path. Leaving it in place creates persistent, unmonitored entry points into your OT network.
The architecture options in Section 3 resolve this. But first you need to know what you have. Start with the shadow access discovery in Section 2 before making any architecture decisions.
Shadow access discovery
Shadow access is remote access that exists in your OT environment without IT or security team knowledge or approval. It is more common than most organizations expect. This discovery process surfaces it without requiring vendor cooperation.
Run this as an internal audit before any architecture changes. The goal is a complete inventory of every remote access path into your OT network, sanctioned or not.
Run a passive network scan across all OT network segments. You are looking for:
- Devices with public IP addresses or cellular connectivity
- Devices that initiate outbound connections to external IP ranges
- Unrecognized devices on segments where the asset inventory is supposedly complete
- Traffic on ports associated with remote access protocols: RDP (3389), VNC (5900), SSH (22), and vendor-specific management ports
Document every finding, but do not remediate during discovery. The goal at this stage is solely to create an inventory.
Cellular modems are the hardest shadow access vector to find because they bypass your network entirely. Physical inspection is required.
Walk the plant floor and control rooms looking for:
- Small devices with antenna leads attached to control panels or relay racks
- Devices with SIM card slots
- Unfamiliar networking equipment near PLCs, RTUs, or HMIs
- Serial-to-cellular converters attached to legacy equipment
Cross-reference findings against your asset inventory. Anything not in the inventory is a candidate for further investigation.
Dual-homed laptops — machines with both corporate network and OT network connectivity — are a common shadow access path. Vendors leave them behind after commissioning or connect their own during service visits.
Audit every engineering workstation connected to OT segments:
- Is it in the asset inventory?
- Does it have wireless adapters that could connect to external networks?
- Does it have VPN clients installed?
- Does it have remote access software installed (TeamViewer, AnyDesk, LogMeIn)?
Pull your OT firewall rule sets and look for:
- Rules permitting inbound connections from external IP ranges
- Rules with "any source" or overly broad source definitions
- Rules that were created during vendor commissioning and never reviewed
- Expired or unused rules that were never removed
Map each permissive rule to a business justification. Rules that cannot be mapped to a current, approved access requirement are candidates for removal.
Pull every active service and maintenance contract for OT equipment. Note which vendors have contractual access provisions and what those provisions specify. Contracts that require "permanent remote access" or "unrestricted connectivity" without defining the technical parameters are a security problem as well as a negotiation problem.
The output of the discovery process is a complete shadow access inventory: every remote access path, the vendor or purpose associated with it, whether it is currently active, and its current governance status. This inventory is the baseline for your architecture decisions.
Architecture options
Four architectural patterns address OEM remote access. They are not mutually exclusive. Most mature environments use a combination.
A jump host (also called a bastion host or jump server) is a hardened, isolated system that vendors connect to before accessing OT equipment. The vendor never has direct network access to OT assets. All traffic flows through the jump host, which is monitored and logged.
| Element | Implementation |
|---|---|
| Placement | DMZ between IT/internet and OT network |
| Vendor access | MFA-required login to jump host only |
| OT access | Jump host connects to target equipment via approved protocols only |
| Session recording | Full session capture on jump host |
| Access duration | Time-limited sessions, manually approved or automatically expired |
Jump hosts are the baseline for any governed OEM access architecture. They do not require vendor equipment changes and work with legacy OT assets.
JIT access means vendor connectivity is off by default. The vendor requests access, the request is approved by a named internal contact, access is enabled for a defined window, and it is automatically revoked when the window closes.
JIT access can be implemented on top of a jump host using access management tooling, or with network-layer controls that enable and disable firewall rules on a timed basis. The key elements are:
- A request and approval workflow that creates an audit record
- Named internal approval authority, not a generic helpdesk queue
- Time-bounded sessions with automatic revocation
- Real-time notification when a session is active
- Session recording from session open to close
JIT access is the target state for most OEM remote access scenarios. Section 4 covers implementation in detail.
Dedicated OT remote access platforms — from vendors including Claroty, Tosibox, Secomea, and others — are purpose-built for industrial environments. They provide JIT access, session recording, and protocol-aware controls without requiring changes to OT assets.
CP-SRA platforms handle legacy protocols and constrained network environments that generic IT remote access tools do not accommodate. They are the right choice for complex environments with many vendors, many assets, and compliance recording requirements.
For the highest-consequence assets — safety instrumented systems, protection relays, critical control systems — the correct architecture is no bidirectional remote access at all. Diagnostic data is extracted via a unidirectional gateway (data diode). Vendor access for configuration changes requires a physical site visit.
This is operationally inconvenient and some vendors will resist it. It is also the only architecture that provides a hardware guarantee against remote exploitation of these assets. The inconvenience is the point.
Just-in-time access implementation
JIT access implementation follows a defined sequence. The steps below assume a jump host is in place or being deployed concurrently.
Step 1 — Define the access tiers
Not all vendor access requires the same controls. Define tiers before configuring anything.
| Tier | Criteria | Approval required | Session duration |
|---|---|---|---|
| Tier 1 — Read-only monitoring | Vendor reads diagnostic data only, no configuration changes | Single approver, 24-hour advance notice | Up to 4 hours |
| Tier 2 — Supervised configuration | Vendor makes configuration changes, internal engineer present | Two approvers including plant engineer | Duration of maintenance window only |
| Tier 3 — Emergency access | Unplanned access during active equipment failure | Single approver, notification to security team | Duration of incident only, extended by request |
Step 2 — Enroll vendors
Before any vendor receives access credentials:
- Verify the vendor contact's identity against a named contact in the service contract
- Issue credentials tied to the individual, not the vendor company
- Document the vendor contact, the equipment they are authorized to access, and the access tier
- Require vendors to acknowledge your access policy in writing
Individual credentials matter. Shared vendor accounts make session attribution impossible and survive personnel changes at the vendor indefinitely.
Step 3 — Configure the approval workflow
The workflow must produce an audit record. At minimum:
- Vendor submits access request with reason, target equipment, and requested duration
- Request routes to named internal approver
- Approver grants or denies with documented rationale
- Approval triggers time-limited credential activation
- Session open and close are logged with timestamps
- Credential automatically deactivates at session expiry
If your tooling cannot automate credential activation, a manual process with documented steps is acceptable. What is not acceptable is informal approval via email or phone with no written record.
Step 4 — Monitor active sessions
Assign someone to watch active vendor sessions, or configure alerts that notify a named contact when a session is open. Unmonitored sessions defeat the purpose of the access tier system.
At minimum, configure alerts for:
- Sessions that exceed their approved duration
- Access to assets outside the approved scope for that vendor
- Configuration changes during read-only sessions
- Failed authentication attempts
Step 5 — Conduct post-session review
Review session recordings for Tier 2 and Tier 3 sessions within 48 hours. You are looking for configuration changes that were not discussed during the approval, access to assets outside the approved scope, and anything that looks like reconnaissance rather than maintenance.
Post-session review is also how you catch credential sharing. A vendor technician who connects from two different locations during the same session, or from a location inconsistent with their stated role, is a flag worth investigating.
The break-glass protocol
Break-glass is the emergency access procedure for situations where normal JIT workflow cannot be followed, such as an active equipment failure, a safety system anomaly, or a situation where the cost of a 24-hour approval cycle is a production line shutdown or a safety incident.
The break-glass protocol exists to make emergency access fast without making it uncontrolled. Emergency access is pre-authorized, controlled, and produces an audit record.
| Element | Requirement |
|---|---|
| Pre-authorization | Break-glass credentials exist before the emergency. They are not created under pressure. |
| Named custodian | One named internal person holds break-glass credential activation authority per shift. This role rotates; the list is current. |
| Activation trigger | Written criteria for what constitutes a break-glass situation. "Vendor requested it" is not a trigger. |
| Notification | Security team is notified within 15 minutes of activation, not after the incident closes. |
| Session recording | Full session recording regardless of urgency. No exceptions. |
| Post-incident review | Mandatory review within 24 hours. Documents what was accessed, what changed, and whether the emergency justified the access tier. |
| Credential rotation | Break-glass credentials are rotated after every use. |
What break-glass does not authorize
Break-glass access is scoped to the equipment involved in the emergency. A vendor who receives break-glass access to a specific PLC does not have break-glass access to adjacent systems. Scope creep during emergency sessions is the most common break-glass abuse pattern.
The segmentation guarantee
Break-glass access through a jump host or CP-SRA platform preserves network segmentation. The vendor connects to the jump host; the jump host connects to the target equipment. If the jump host is compromised during the session, the blast radius is the jump host, not your OT network.
Break-glass that involves physically disabling firewall rules or temporarily connecting a cellular modem does not preserve segmentation and should not be permitted, regardless of the urgency claimed.
Vendor contract language
Access architecture only governs the vendors who agree to use it. Vendors with legacy contracts that specify permanent, unrestricted access have contractual cover for non-compliance. Fixing the architecture without fixing the contracts leaves the program incomplete.
What to require in new and renewed contracts
| Provision | Language approach |
|---|---|
| Access method | "Remote access shall be conducted exclusively through [organization]'s designated secure remote access infrastructure. Direct connections to OT assets via any other method, including cellular modems, are prohibited." |
| Just-in-time requirement | "Remote access sessions require advance notice of [X] hours except in cases of active equipment emergency as defined in the break-glass procedure." |
| Individual credentials | "Remote access credentials shall be issued to named individuals. Shared accounts are prohibited. Vendor shall notify [organization] within 24 hours of any personnel change affecting authorized individuals." |
| Session recording consent | "Vendor acknowledges that all remote access sessions are recorded and that recordings may be reviewed by [organization] for security and compliance purposes." |
| Cellular modem prohibition | "Installation of cellular modems, wireless gateways, or any device providing independent network connectivity on [organization]'s OT network is prohibited without written approval." |
| Right to audit | "[Organization] reserves the right to audit vendor remote access activity and revoke access for non-compliance with this policy." |
Handling vendor pushback
Always-on is a support model preference. JIT access with a short approval window, typically 30 minutes for standard requests, immediate for emergencies, satisfies the operational requirement without the persistent exposure. If the vendor refuses to support equipment without always-on access, that is a procurement risk factor, not a security concession.
This means their remote access tooling cannot route through a bastion host. In most cases, this is a configuration limitation, not a technical impossibility. Require them to test it before accepting the objection. If it is genuinely impossible, require physical on-site visits for that vendor's equipment.
Review the warranty terms. Warranty voiding provisions typically apply to unauthorized hardware modifications, not to network access controls implemented by the asset owner. If a vendor attempts to enforce a warranty void for implementing network segmentation, escalate to legal.