Innovation & Technology

Are Cyber Threats Hiding in Your Sustainability Data?

Using sustainability insights to help strengthen IT security

By Jeremy Osborn | Published 10 hours ago | About a 6 minute read

Scope 3 sustainability accounting is operationally demanding work. Mapping environmental impacts across supplier tiers requires building visibility into manufacturing relationships, logistics networks, and embedded energy and material flows that many companies had never systematically documented before. The companies that do this well have produced something genuinely valuable: a detailed picture of where the stuff they use and distribute comes from, how it moves, and which supplier relationships carry the most operational significance.

The Map and What's On It

A mature Scope 3 program identifies your highest-impact suppliers. It also, necessarily, identifies your most operationally critical suppliers, your deepest dependencies, and the geographic and geopolitical contexts your supply chains run through. This information exists in the same dataset. Environmental impact accounting is often responsible for generating it, yet few companies are using it for anything else.

The supplier relationships that dominate conversations about Scope 3 calculations in manufacturing-intensive supply chains tend to share certain characteristics: high production volume, significant energy intensity, concentration in specific geographies, and in many cases limited alternatives. These are also the relationships that carry the most significant non-environmental risk.

Software Supply Chain Security Got Here First

The software industry spent the last two decades learning a version of this lesson. The SolarWinds compromise, the Log4j vulnerability, the cascading failures that followed both demonstrated that the attack surface in a software-dependent organization is not always its own code. It is every dependency, every library, every update mechanism in the stack. The response was a new discipline: software supply chain security. Rigorous dependency tracking, cryptographic attestation of build provenance, verification that the software artifact you're running is what it claims to be, includes the dependencies it says it does, and came from where it claims to have come from. These practices were built to answer the question: do you actually know what is running in your systems and where it came from?

The cyberphysical version of this problem is the same problem with, arguably, higher consequences. A malicious dependency in a software supply chain can exfiltrate data or enable unauthorized access; a compromised component in an operational technology stack can stop a production line, disable environmental controls, or manipulate physical processes in dangerous ways. The blast radius is physical, not just informational. T he Aurora Generator Test, conducted by Idaho National Laboratory for the Department of Homeland Security in March 2007, established the foundational proof of concept for this threat class, nearly two decades ago. Researchers used a laptop to rapidly open and close a diesel generator's circuit breakers out of phase with the rest of the grid. This was not novel malware, or a sophisticated software exploit, just manipulation of existing protective relay systems through accessible industrial protocols. T he 27-ton generator shook itself apart. The significance wasn't the specific technique; it was the demonstration that software commands could produce irreversible physical destruction, that the attack vector was the equipment itself, and that the legacy protocols running most grid infrastructure were designed without serious digital authentication or encryption and meant that anyone who could communicate with a device was assumed to be allowed to control it. Aurora, in this sense, wasn't just a grid problem. It was proof that cyberphysical risk is categorically different from information security risk, and that the consequences, once they move into physical systems, can be severe.

Where Cyberphysical Risk Lives in Your Supply Chain

Most corporate risk frameworks treat cyberphysical exposure as an infrastructure or utilities problem, something that affects power grids and water treatment facilities, and therefore managed by specialists in those sectors. This underestimates where the exposure actually sits.

Manufacturing facilities run SCADA-controlled production lines. Cold chain logistics depends on automated temperature and access control. Data centers rely on building management systems governing power and cooling. Food processing, pharmaceutical manufacturing, automated distribution all of this is operational technology, and all of it is cyberphysical in nature. A successful attack on any of these systems produces a physical outcome, not just a data breach.

One tier out in the supply chain, the problem compounds. Your contract manufacturers, logistics partners, and cold storage providers operate OT systems that directly affect your supply chain continuity. Their cyberphysical posture is your operational risk. Current supplier security questionnaires almost universally cover IT. They often do not always cover OT.

The Hardware Questions Your Procurement Team Might Not Be Asking

Software supply chain security developed tools for tracking what is in a software system and verifying its provenance. The cyberphysical equivalent requires asking the same questions about hardware: where was this manufactured and by whom; what does the firmware do and when and how is it updated; what does it communicate, when, and to whom, and what access does its manufacturer or its manufacturer's government retain.

These questions are not hypothetical. US and UK government advisories have identified undocumented communication capabilities in specific categories of connected equipment. Volt Typhoon, confirmed publicly by US intelligence agencies, demonstrated persistent nation-state access in operational technology environments, typically positioned for disruption, not espionage. The hardware running your suppliers' operations, and your own, carries provenance and security questions that procurement assessments do not currently ask.

The gap is structural. IT security teams ask software and network questions. Facilities teams buy operational equipment. Sustainability programs measure environmental impacts and see the whole system. The firmware question, what is this device actually doing, what does it connect to, what government has legal access to its manufacturer and potentially to operationally active devices in your critical systems, sits between all three functions and is answered by none of them.

What the Scope 3 Data Is Worth

The data that supplier visibility programs generate is valuable. In many organizations it represents the most complete map of supply chain relationships that exists anywhere. Yet it is often treated as a strictly environmental dataset, when its value extends much further. Non-carbon aspects of energy-focused systems in particular can carry some of the biggest supply chain risks: energy-intensive suppliers are often deeply embedded in critical production processes, operate in volatile or opaque geographies, or face significant regulatory exposure as governments become more hands-on in crafting industrial security policy. The practical opportunity is to treat that map as an input to a broader risk assessment: to use the relationships sustainability programs have already documented to surface gaps that a conventional risk program might not have seen.

The supplier relationships already identified as Scope 3 material can be the right place to start asking cyberphysical security questions, not because sustainability programs should own that assessment, but because they may have already done the mapping work that enables it. OT security frameworks exist. Hardware provenance questions can be embedded in procurement requirements. The software supply chain security community developed rigorous answers to the software version of this problem over the past decade, dependency tracking, provenance verification, attestation of what is actually running and where it came from. The cyberphysical version is, in many companies, waiting for the same attention.

Jeremy Osborn

Jeremy Osborn is a NYC-based entrepreneur and senior consultant with a background in tech, marketing and communications, strategy, governance and sustainability.

Tags:

Governance & Metrics