When Your Vendor's Vendor Has the Keys: OT Supply Chain Risk and the Visibility Gap Nobody Talks About
Yesterday, Mary Rose Martinez — the CISO of Marathon Petroleum, a Fortune 50 company that runs refineries, pipelines, and terminals across the United States — sat down with Help Net Security and said something that every OT security practitioner should stop and think about.
She was asked which part of the dependency chain worries her most: vendor platforms, third-party models, or remote support tunnels. Her answer was not the one that makes headlines. It was not ransomware groups or nation-state actors. It was the part of the supply chain where companies have — in her words — “the least visibility and control.”
And then she added the sentence that should worry every operator reading this: “These risks extend past third party vendors to nth party vendors further in the supply chain.”
Nth-party. Not your vendor. Your vendor’s vendor. Possibly your vendor’s vendor’s vendor. A company you have never heard of, whose security practices you have never assessed, whose devices or software components or remote access credentials are already inside your industrial network — and you would not know if they started behaving differently tomorrow because you have never established what “normal” looks like for them.
The Supply Chain Visibility Gap
The OT supply chain problem is not new. What is new is the recognition — from a CISO operating at the scale of a Fortune 50 energy company — that the visibility gap is structural, not incidental. It is not that operators have not gotten around to auditing their vendors yet. It is that the dependency chain extends beyond what any audit program can reach.
Here is a concrete example. A refinery installs a vibration monitoring system from a well-known automation vendor. The vendor’s product includes an embedded Linux controller from a second-tier supplier. That supplier’s firmware incorporates an open-source networking stack maintained by a development team of three people in a country the refinery operator could not place on a map. The refinery’s security team audited the primary vendor thoroughly — contractual language, security questionnaires, the works. Nobody audited the firmware component. Nobody even knew it existed.
Now imagine that open-source networking stack has a vulnerability. Not a CVE — nobody has discovered it yet. But an attacker who understands the protocol finds a way to exploit it. They gain access to the embedded controller. From there, they can see the network traffic between vibration sensors, PLCs, and the HMI. They learn the timing of maintenance windows. They map the Modbus register layout. They have been inside the network for six months before the refinery’s security team even knows the controller exists.
This is not a hypothetical. It is a direct consequence of the nth-party problem that Martinez described. And the uncomfortable truth is that no amount of vendor questionnaires, no contract language, and no annual penetration test will catch it — because you cannot audit what you do not know exists.
Why Signatures Cannot Close This Gap
The standard security industry response to supply chain risk is vulnerability management. Scan your assets. Match them against CVE databases. Patch what you can. Accept the risk on everything else.
This approach breaks down in OT environments for reasons that are well understood — patching windows, legacy systems, the impossibility of rebooting a catalytic cracker on Patch Tuesday (as Martinez herself noted). But it breaks down for a deeper reason that gets less attention: the nth-party devices you did not know about will never appear in your vulnerability scan in the first place. They are invisible to signature-based tools because they are invisible to your asset inventory.
Even when the devices are known, signatures only catch what has been seen before. A vendor’s firmware update that introduces a subtle behavioral change — a new outbound connection, a protocol that was never used before, a device that suddenly starts writing to a register it has only ever read — will not trigger any signature. No CVE was published for it. No IoC exists for it. But from a detection standpoint, it is the single most important signal in your network at that moment.
The Purdue Model and the Illusion of Segmentation
Martinez highlighted the Purdue Enterprise Reference Architecture as the framework Marathon uses to balance security with operational continuity. This is sound engineering. The Purdue model gives operators a way to segment vendor access — keep the remote support tunnel at Level 3, restrict what it can reach at Level 2, and prevent it from touching Level 1 controllers and Level 0 field devices directly.
But segmentation is a policy, not a guarantee. It tells you what should happen. It does not tell you what is actually happening. A vendor’s remote access credential that was supposed to be restricted to a single engineering workstation at Level 3 can find its way to Level 1 if that workstation is bridged to the control network through a misconfigured switch — and the operator will not know until someone looks at the network traffic directly.
This is where Martinez’s nth-party concern collides with the detection gap. You can write all the segmentation policies you want in your cybersecurity program documentation. But if you cannot observe — passively, continuously — which devices are actually talking to which other devices, on which protocols, and whether that communication matches the historical pattern, you are operating on assumptions. And in OT security, assumptions are what attackers count on.
What Passive Behavioral Monitoring Actually Means Here
The alternative is not another scanner. It is not more signatures. It is passive observation of network behavior — the kind of monitoring that establishes a baseline of what every device normally does, then alerts when a device does something it has never done before.
For supply chain risk specifically, this means three things.
First, asset discovery is behavioral, not configurational. You discover devices by watching what communicates on the network — not by checking against a configuration management database that was last updated when the system was commissioned. If a vendor’s embedded controller starts talking Modbus on your Level 1 network, a passive NDR platform sees it the moment it sends its first packet — regardless of whether it appears in any inventory.
Second, vendor behavior is baselined per device. A vibration monitoring controller that has issued 50,000 Modbus read commands and zero write commands over six months should trigger an immediate alert the first time it issues a write — even if that write is perfectly valid at the protocol level. The anomaly is not the content of the write. It is the fact of the write, from a device whose entire operational history says “reads only.”
Third, supply chain compromise is detected at the behavioral level, not the signature level. When a vendor pushes a firmware update that changes a device’s communication pattern — new protocols, new destinations, new timing — the signature database will not notice. The baseline will. And the operator will have evidence they can take back to the vendor: “Your device started doing this on Thursday. It has never done this before. Explain.”
The Pragmatic Path Forward
Martinez’s interview is valuable not because it reveals a new problem, but because it reveals how a senior OT security leader at a Fortune 50 company thinks about an old problem. She framed supply chain risk in terms of visibility and control. She acknowledged that nth-party dependencies exceed what due diligence and contracts can reach. She described a defense architecture built on Purdue segmentation — and implicitly acknowledged that segmentation alone is not enough.
For operators who do not have Marathon’s resources, the lesson is simpler: you cannot out-contract supply chain risk. You cannot out-audit it. You can only observe it — continuously, passively, at the network level, for every device in every zone.
That means instrumenting your OT network with passive NDR that does not care whether a device appears in your CMDB, does not depend on a CVE being published before it can detect a threat, and does not require you to know your vendor’s vendor’s vendor exists in order to notice when their code starts behaving differently inside your industrial environment.
The supply chain visibility gap is not going to close itself. The dependencies are getting deeper, not shallower. The automation that Martinez described — pushing deeper into refineries, pipelines, and terminals — means more embedded controllers, more vendor platforms, more remote support tunnels, and more nth-party code running on devices that touch your physical process. The only answer that scales is behavioral detection that treats every device as something to be observed, not just something to be inventoried.
Maigadi — the OT/ICS network detection and response (NDR) platform that passively learns your network’s normal and detects the novel, signature-less attacks others miss. On-premise. Explainable. Sovereign by design.