Certified: The CompTIA SecOT+ Audio Course

When you are brand new to Operational Technology (O T) security, it can feel like threats come from everywhere at once, which is true in a sense, but not in a helpful way. The better approach is to learn the major threat vectors, meaning the pathways attackers most commonly use to get close enough to influence operations. A threat vector is not the same as a vulnerability, and that distinction matters because a vulnerability is a weakness in a specific system, while a vector is the route used to reach systems in the first place. If you understand vectors, you can anticipate where to focus attention even before you know the technical details of a particular exploit. In O T, the most important vectors tend to be the ones that bridge trust boundaries: remote access used for support and operations, removable media used for updates and file transfer, supply chain relationships that bring in software and equipment, and the pivot path from I T systems into O T networks. These are not niche edge cases; they are everyday realities of how industrial environments function, and attackers like them because they often look like normal business. The goal of this lesson is to help you recognize these vectors, understand why they exist, and see what makes them risky in a physical environment.

Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.

Remote access is one of the most common and most misunderstood vectors in O T, largely because it is also one of the most operationally valuable. Facilities use remote access for vendor support, engineering assistance, troubleshooting, monitoring, and sometimes for centralized operations across multiple sites. The risk is not that remote access exists, but that remote access creates a doorway, and every doorway needs strict rules, strong identity, and clear visibility. Beginners often imagine an attacker “breaking in” directly to a controller, but a more common pattern is an attacker obtaining credentials or access to the same remote pathway that legitimate people use. Once an attacker can establish a remote session into an environment, they can explore, escalate privileges, and move laterally in ways that are hard to distinguish from legitimate support activity unless governance is tight. Remote access also compresses distance, meaning a mistake or compromise can instantly affect a site without the physical friction of being on location. In O T, that speed matters because it reduces reaction time and can turn a small breach into a bigger problem before anyone notices.

The key to understanding remote access risk is to focus on the idea of mediated trust. If a vendor can remotely connect to troubleshoot an issue, the organization is trusting not only the vendor person but also the vendor’s own environment, their device hygiene, and the systems that manage that connection. If an attacker compromises the vendor’s credentials or device, the attacker may inherit the same access. Even within your own organization, remote access often relies on shared services like identity management, authentication, and remote session gateways, which can become indirect dependencies that attackers target. Another beginner pitfall is assuming that “remote access is secure because it has a password,” when the real questions are about how authentication is strengthened, how sessions are approved, and what exactly the remote user can reach once connected. A remote access solution that lands directly on an engineering workstation is a very different risk than one that lands on a controlled jump host with limited pathways. Visibility matters too: if you cannot tell who connected, from where, when, and what they did, remote access becomes a blind spot. In O T, blind spots are dangerous because they can hide changes that affect safety and reliability.

Removable media is another classic vector, and it remains relevant even in modern environments because O T networks are often constrained, segmented, or not connected to the broader internet. People still need to move files: firmware updates, configuration backups, engineering project files, logs, and vendor tools. That movement creates a physical bridge, and attackers can exploit it by using infected media, booby-trapped files, or compromised laptops that touch both worlds. Beginners sometimes assume that removable media is old-fashioned, but it is frequently part of day-to-day maintenance. The risk increases when processes are informal, such as using the same USB drive for multiple systems, sharing media across teams, or allowing personal devices into maintenance workflows. Even if a facility has strict network segmentation, removable media can bypass segmentation entirely, because the media carries the payload directly to a trusted workstation. The most important learning here is that physical handling practices are part of cybersecurity, and the security of a segmented network can be undermined by a casual file transfer habit.

To think clearly about removable media, it helps to consider the chain of custody, which means understanding where the media has been, who handled it, and what systems it touched. In enterprise I T, security often assumes continuous connectivity and centralized controls, but in O T, you may not have that luxury, so process discipline becomes the control. If a vendor provides an update on a drive, the organization must ask how that drive was prepared, how it was scanned, and how it will be introduced into the environment. If engineers move configuration files between a corporate laptop and an O T workstation, you have to consider whether the laptop might have been exposed to phishing or malware, and whether the O T workstation has protections suitable for that risk. Another concept beginners should learn is that malicious code does not need internet access to cause harm; it can target local systems, disrupt services, or alter files used in engineering workflows. Media-based compromise is also hard to investigate after the fact if logging is limited and if file provenance is unclear. That makes prevention and disciplined handling especially valuable.

Supply chain is a broader vector, and it can sound abstract until you break it down into what it means in an O T context. O T environments are built from vendor hardware, vendor firmware, vendor software, integrator services, maintenance contractors, and sometimes managed service providers. Each relationship can bring in components or access that you did not build yourself, and trust is often implicit because operations need these relationships to function. Attackers can exploit the supply chain by compromising software updates, tampering with distribution channels, targeting vendor credentials, or using third-party access pathways as a stepping stone. Beginners sometimes hear supply chain and think only of nation-state espionage, but supply chain risk also includes ordinary issues like counterfeit parts, misconfigured vendor defaults, and insecure remote support practices. The O T supply chain can be especially complex because equipment may have long lifecycles, and vendors may change ownership, discontinue products, or evolve their support models over time. That complexity creates gaps in visibility and governance, which attackers can use to hide or blend in. Supply chain risk is indirect by nature, but the impact can still be direct if compromised components affect control and safety.

A simple way to understand supply chain risk is to focus on two questions: what is being supplied, and what level of privilege or trust does it receive in your environment. A replacement controller module is being supplied, and it will likely be trusted to control a physical process. A software update is being supplied, and it might run with high privileges on a management server or engineering workstation. A contractor service is being supplied, and it might involve remote access to sensitive segments. When you see it this way, you realize supply chain security is about managing trust boundaries, not about distrusting every vendor. It is about verifying integrity where you can, limiting permissions where you can, and ensuring that third-party access is controlled, logged, and revocable. It also emphasizes the value of vendor management practices like knowing who your vendors are, knowing which systems they touch, and having clear rules about how updates and changes are introduced. Beginners often want a single technical fix, but supply chain risk is partly technical and partly procedural, because it spans organizations. If you treat it as only a technical problem, you miss critical control points.

The I T-to-O T pivot is one of the most important vectors to grasp because it explains how many O T incidents actually unfold in the real world. Organizations frequently connect enterprise networks to operational networks for data exchange, centralized monitoring, remote operations, patch distribution, identity services, and business analytics. Those connections can be necessary, but they create pathways that can be abused if an attacker gains a foothold in I T. A pivot means the attacker moves from a less sensitive area into a more sensitive one by leveraging connectivity, shared credentials, or shared systems. Beginners often imagine that O T is behind an unbreakable wall, but in practice there are doors, windows, and sometimes open hallways created by convenience, legacy design, or urgent operational needs. The pivot can occur through jump hosts, remote desktop gateways, shared file servers, misconfigured firewalls, or even through people who have access to both worlds. Once the attacker crosses into O T-adjacent systems, they may target engineering workstations, historians, and other systems that can influence control decisions. Understanding the pivot helps you see why enterprise security hygiene can be an O T safety issue.

A useful mental model for I T-to-O T pivoting is to think in layers of consequence rather than layers of technology. An attacker might begin with an email compromise, which seems like an I T problem, but then use that access to steal credentials, which becomes an identity problem, and then use those credentials to access remote support platforms, which becomes an access governance problem, and then reach an engineering workstation, which becomes an O T integrity problem. Each step may be individually ordinary, but the chain produces risk that is much greater than any single step. This is why defenders often emphasize segmentation and controlled conduits between I T and O T, because the goal is not to eliminate all data sharing but to prevent a compromise in one layer from freely spreading to the next. Another beginner lesson is that pivoting often uses legitimate tools and credentials, making it harder to detect if you rely only on signatures or known bad indicators. Detecting pivoting relies on baselines, unusual access patterns, and clear expectations about who should access what and when. That is as much about governance as it is about technology.

When you compare these vectors, you can see that they share a common theme: they are all about the movement of people, access, or artifacts across boundaries. Remote access moves a person’s reach into the environment. Removable media moves files and code into the environment. Supply chain relationships move trusted components and privileged software into the environment. I T-to-O T pivoting moves an attacker from one trust domain to another. Attackers prefer these vectors because they often involve legitimate activity that defenders cannot simply turn off without operational cost. That makes the defense strategy less about a single wall and more about layered controls that reduce risk while keeping operations possible. Beginners should also appreciate that these vectors interact: a supply chain compromise might show up as a remote access compromise, and a removable media incident might begin with an I T compromise of a laptop that prepares the media. Thinking in vectors helps you connect these dots rather than treating each event as random. It also helps you communicate risk to non-technical stakeholders, because you can explain that the biggest risk is often how work is done, not just which device is vulnerable.

The practical takeaway is that identifying vectors is about recognizing where the organization has chosen convenience, speed, or integration, and then ensuring those choices are governed with visibility and limits. Remote access should be treated like a controlled gate, not a casual doorway, with strong identity, clear approval, and auditing that creates accountability. Removable media should be treated like a carefully handled delivery mechanism, not a shared office supply, with disciplined processes that reduce uncertainty about what enters sensitive systems. Supply chain relationships should be treated as managed trust, with clear rules about updates, access, and integrity, rather than assumed safety. I T-to-O T connections should be treated as deliberate conduits with barriers, not as accidental bridges built over time. When you learn these vectors, you gain a way to look at an O T environment and ask smart questions about where risk enters, even before you know specific vulnerabilities or attacker groups. That ability to see pathways is one of the most valuable foundational skills in O T security, because it turns the threat landscape from a scary mystery into a set of understandable, defensible entry points.