None of that is optional, and none of it is the problem. The problem is what happens after the connection is made.
Once a vendor connects, do you know what they’re doing?
Authorization tells you who is allowed to connect. It does not establish that every action taken during the session is legitimate.
The 2025 SANS State of ICS/OT Security Report found that 50% of reported ICS/OT incidents began with unauthorized external access, while only 13% of organizations had fully implemented advanced ICS-aware controls.
That gap, between how common external access is and how little of it is genuinely monitored, is where the security challenge begins.
Access legitimacy and activity legitimacy are two different things.
A vendor can be authorized to enter without every action inside being authorized in turn.
The challenge is not to eliminate third-party access. It is to give security teams enough visibility and OT context to tell whether an authorized session is supporting production or creating risk.
If your team can tell you who connected but not what they touched, changed, or reached, you have access logging, not OT remote access monitoring. The two are not the same thing, and the difference is where most incidents hide
The Operational Case for Vendor and OEM Access
Manufacturing depends on external expertise. Equipment vendors understand the systems they built. Integrators understand how multiple control components interact. Some maintenance simply can’t be handled by internal teams alone. Vendor and OEM connections therefore require more scrutiny than authentication alone can provide. The risk doesn’t end when authentication succeeds.
This kind of access is one part of a much larger picture.
Analyzing the manufacturing OT attack surface maps where that exposure lives across controllers, supervisory systems, engineering workstations, manufacturing applications, and historians. Vendor and OEM connections are one of the access paths into that same environment, which is why they deserve the same level of scrutiny.
The National Cyber Security Centre notes that remote access by vendors, integrators, and other third parties is now common in OT maintenance contracts, and that organizations don’t always have effective monitoring in place to catch anomalous behavior through those access routes (NCSC, Principle 5).
The connection serves an operational need. Security needs visibility into what happens through it, while operations needs assurance that security monitoring will not interfere with legitimate work.
What Does OEM Remote Access Actually Support?
A vendor connection into manufacturing OT typically supports:
- Diagnosing a controller or HMI fault
- Updating firmware or software configurations
- Tuning industrial equipment for a specific process
- Validating a system after scheduled maintenance
- Supporting multiple plants through a single access path
- Maintaining specialized manufacturing applications an internal team can’t service
The same pathway can touch assets close to the production process. A connection that begins with an authorized vendor account may reach an engineering workstation, which can then communicate with controllers, HMIs, or historians. That relationship between the account, workstation, and everything reachable from it is what third-party access controls need to govern.
The question isn’t only whether the vendor should have access: what they should be able to reach, and what should happen the moment activity moves outside that pattern.
Remote connectivity should be centralized through controlled, monitored paths rather than managed through bespoke connections for every third party.
How OT Access Is Different From IT Access
| IT access | OT access |
|---|---|
| Primarily reaches applications, data, and enterprise systems | Can reach systems supporting physical production |
| Unusual activity may trigger an identity or endpoint investigation | Investigation must also weigh process and equipment impact |
| Isolation is often straightforward in many IT environments | Isolation can itself affect production or maintenance activity |
| Business impact may involve data or service availability | Impact can extend to uptime, equipment behavior, and safety |
| Focus is primarily on enterprise systems and business services | Focus must account for operational processes and physical outcomes |
An SOC may know a vendor authenticated successfully, which account was used, and when. But if it can’t determine which workstation was reached, which OT assets that workstation can touch, and what happened during the session, the part of the investigation that actually matters stays unclear.
The Real Risk Begins After Access Is Granted
Authentication answers who is connecting. It doesn’t answer what are they doing.
That gap becomes dangerous the moment an attacker holds legitimate credentials or a legitimate vendor endpoint. The session passes every authentication check. The connection comes through an approved route. The activity can still be a threat. Access control and continuous monitoring serve different purposes. 
Why Authorized Activity Still Needs Scrutiny
Consider a vendor account that normally connects to one engineering workstation during scheduled maintenance. The access is legitimate. The question is whether the activity that follows stays within the expected scope.
Before: authorized vendor → approved time → approved workstation → expected OT asset → expected maintenance activity → session ends.
After: the same authorized vendor → unusual time → unexpected workstation → unexpected OT asset → configuration change → activity continues past the window.
The identity hasn’t changed. The risk has.
Determining whether that change matters requires more than authentication records. Security operations need to correlate:
- Vendor identity and account
- Connection and access path
- Target workstation and OT asset
- Time and session duration
- Configuration or command activity
- Changes made during and after the session
Without that context, an analyst sees isolated events rather than the sequence connecting them. That makes it harder to distinguish expected maintenance from activity that warrants investigation.
Authorization Doesn’t Explain Vendor Activity
A vendor authorized to troubleshoot one production system isn’t automatically authorized for every system reachable from their workstation. Only 13% of organizations have the ICS-aware controls to catch that distinction, per SANS.
The problem isn’t necessarily the access policy itself. It’s understanding what happens after the policy has already allowed the connection through.
What a Recent Manufacturing Incident Reveals About Third-Party Access
A 2025 manufacturing incident shows how unauthorized access can become an operational problem.
The Reported Incident
In May 2025, steelmaker Nucor disclosed a cybersecurity incident involving unauthorized third-party access to some of its IT systems. The company temporarily halted certain production operations at multiple locations while it investigated. It was reported that Nucor took potentially compromised systems offline and brought in external experts for containment and recovery. (Source: Reuters)
Where Third-Party Access Enters the Picture
This incident does not establish that a vendor or OEM remote-access connection was the attack vector. Nucor’s disclosure describes unauthorized third-party access to IT systems, not a compromised vendor account or maintenance session. That distinction matters.
What This Means for Manufacturing OT
What it does show is the operational consequence once unauthorized access reaches systems that support manufacturing operations: Security teams end up balancing stopping the threat against keeping the operation running, and that balance gets harder without context connecting enterprise systems, engineering environments, and control systems.
The practical lesson is to identify when a connection moves from expected maintenance into activity that requires investigation. The earlier that transition is visible, the more options security and operations have to contain it without unnecessary disruption.
Distinguishing Legitimate and Suspicious Vendor Activity
Identifying that a session exists is easy. Determining whether the activity makes sense is the hard part.
A legitimate maintenance session can look unusual: an engineer touching a system they don’t normally use, a configuration change that’s fully expected. Treat every unusual action as malicious and you get noise. Treat every authorized action as trusted, and you get blind spots.
| Legitimate vendor activity | Suspicious vendor activity |
|---|---|
| Approved vendor identity | Valid credentials used unexpectedly |
| Approved maintenance window | Activity outside expected hours |
| Expected engineering workstation | Unexpected workstation or access path |
| Expected production asset | Unexpected OT asset |
| Activity matches maintenance scope | Activity exceeds expected scope |
| Session ends after task completion | Session continues or expands |
The question shifts from “Was this user authorized?” to “Does this activity fit the operational context?”
How OT Context Changes Detection
An OEM that normally connects to one workstation to diagnose a packaging line gives limited information from the login alone. But if that same account connects to a different workstation, talks to an unexpected controller, and changes a configuration outside the approved window, the sequence becomes meaningful.
For example, if a robotics-integrator account that normally touches one welding cell’s HMI during a Tuesday maintenance slot instead connects on a Saturday, reaches the HMI for an adjacent cell it has never touched, and pushes a parameter change with no ticket behind it. Nothing here fails authentication. Everything here should trigger a look.
Anomaly ≠ Compromise
Not every unusual vendor session is an attack, and not every authorized login is safe. Detecting suspicious vendor activity isn’t about flagging every deviation. It’s about reading identity, asset, timing, and activity together as one sequence, not as isolated alerts.
The Visibility Security Operations Need on Vendor Activity
Security teams should be able to reconstruct a session without chasing three other teams for pieces of it. NCSC recommends third-party access be controlled, monitored, and logged, with vendors limited to specified assets. That provides a stronger foundation for investigation than session recording alone.
The Five Questions Every OT Session Should Answer
Every third-party OT session should leave enough evidence to reconstruct what happened, not just confirm someone connected.
- Who is connecting? The vendor, the account, and the device the session originates from.
- Where can they reach? The workstation, site, OT zone, or asset the connection actually touches and not just where it’s supposed to go.
- How did they get there? The access path used, checked against the route that’s actually approved for that vendor.
- What did they do? The specific commands, configuration changes, or communications that occurred while access was active.
- Does it make sense? Whether the activity fits the asset’s role — a change to a production controller is a different risk than the same change on a test system.
These five form a chain: identity → access path → asset → activity → operational meaning
If one link is missing, the analyst has to reconstruct the session from separate systems and teams, and that costs time exactly when speed matters most.
From Monitoring to Third-Party Threat Detection
A recorded session is evidence, not a decision. Turning visibility into operational security takes five stages:
Monitor → Contextualize → Detect → Investigate → Contain
- Monitor captures third-party activity continuously rather than through periodic review.
- Contextualize ties the session to vendor, workstation, asset, and maintenance window.
- Detect flags activity that deviates from the expected pattern, especially when several signals appear together.
- Investigate reconstructs what happened and whether it’s maintenance, error, or compromise.
- Contain applies a response proportionate to confidence and operational impact.
Detection without context produces alerts. Context without investigation produces visibility with no action. The gap isn’t a lack of logs. It’s turning remote-access activity into information that security and operations can act on.
Containing Third-Party Threats Without Disrupting Production
The instinct after a suspected compromise is to disconnect immediately. In OT, the right response depends on what that connection supports.
A session involving a non-critical engineering environment may allow more immediate restriction. A session interacting with equipment behind an active production process requires engineering and operations to assess the impact before access is interrupted. The response should be proportionate to the threat and the production impact.
| Situation | Appropriate response |
|---|---|
| Activity matches approved maintenance | Continue monitoring, confirm completion |
| Minor deviation from expected behavior | Investigate, confirm with the responsible team |
| Suspicious activity, limited scope | Restrict affected access and investigate |
| Credible compromise affecting OT assets | Contain the account or path, coordinate with operations |
| Threat with potential production impact | Apply targeted isolation, preserve required connectivity |
Application- or service-specific isolation can revoke a compromised third party’s access while preserving required connectivity.
The response follows the evidence: contain the account if the threat is one account, restrict the path if it’s one path, isolate the segment if a workstation is compromised.
The security objective stays the same: contain activity that presents a credible threat. The method has to account for the environment being protected.
How Prudent Secures Vendor and OEM Access to Manufacturing OT
Vendor and OEM access isn’t the weakness in a manufacturing environment. Uncertainty around that access is.
Authorization establishes who can connect. Session recording establishes what happened during a connection. Production-aware security requires the next layer: whether that activity fits the asset, the access path, the maintenance scope, and the operational context around it.
Prudent helps manufacturing organizations close that gap by bringing together OT visibility, contextual detection, investigation, and production-aware response into a single security operating model.
Assess Your OT Security Visibility
One well-investigated session proves your team can do this once.
The real question is whether they can do it every time: for every vendor, at every plant, without waiting for something to go visibly wrong first.
If the answer is no, the gap isn’t in remote access control. It’s in your ability to understand and respond to activity inside the OT environment.
Take the OT Security Visibility Assessment
