Industry Analysis

Critical Infrastructure Software Supply Chain

How the 16 critical infrastructure sectors are absorbing software supply chain obligations under PPD-21, NSM-22, and CISA's emerging frameworks.

Nayan Dey
Senior Security Engineer
7 min read

Every time a pipeline goes down or a water utility makes the evening news for the wrong reasons, a set of phones light up in Washington. CISA takes calls, the relevant Sector Risk Management Agency takes calls, the White House National Security Council takes calls, and somewhere in the mix a software supply chain question surfaces. It might be a compromised operational technology vendor, a managed service provider with privileged access, or a widely deployed open source library buried inside a plant historian. The pattern is familiar enough that critical infrastructure operators, long cautious about cybersecurity, are now visibly rethinking how software enters their environments.

The Sectors and the Frameworks Around Them

Presidential Policy Directive 21 set out the current lineup of 16 critical infrastructure sectors, ranging from energy and water to healthcare, financial services, communications, chemical, and others. National Security Memorandum 22, issued in 2024, updated the roles and responsibilities, designating Sector Risk Management Agencies and formalizing CISA's coordinating role. The cumulative effect is that each sector now has a clearer regulatory sponsor and a clearer set of cyber expectations.

The sector-specific frameworks that matter most are well known. NERC CIP in the bulk electric system. TSA Security Directives for pipelines and rail. the NRC's cybersecurity rule 10 CFR 73.54 for nuclear. the Coast Guard's cyber risk management provisions for maritime. HIPAA Security Rule for healthcare, with the HICP and 405(d) Program adding practical guidance. the FDIC, OCC, and Federal Reserve interagency guidance on third-party risk for banking. For water and wastewater, the EPA has struggled to impose direct cyber mandates but has relied on state primacy agencies and voluntary programs. CISA's Cyber Performance Goals, published in 2023, act as a cross-sector baseline, non-binding but increasingly referenced.

Why Software Supply Chain Is the Stress Point

Critical infrastructure has always been conservative about software. Control system vendors release firmware updates on multi-year cycles. Plant engineers resist anything that changes behavior in the middle of a production run. That conservatism created the illusion that supply chain risk was manageable, because change was slow. The reality is that even slow-changing environments accumulate third-party dependencies. A PLC runs firmware written by a vendor that uses open source libraries. A SCADA master runs on Windows Server, with historian software that uses commercial database drivers, analytics add-ons, and perhaps a web interface with a modern JavaScript front end. Each of those layers is a supply chain.

The Colonial Pipeline incident in 2021 did not start with an OT compromise, but it demonstrated how quickly IT-side issues cascade into operational disruption. The Kaseya VSA incident later that year hit managed service providers serving many critical infrastructure operators. More recently, incidents involving remote monitoring tools, identity providers, and cloud services have all touched sectors that historically saw themselves as insulated. What changed is not the sectors. It is the degree to which their operations now depend on enterprise and cloud software stacks that behave like any other commercial supply chain.

CISA's Role in Harmonization

CISA has been working to translate the post-EO 14028 federal software supply chain framework into something useful for critical infrastructure, even when the operators are private companies. The Secure by Design initiative has been framed for both vendors and operators. The Joint Cyber Defense Collaborative brings the major software vendors, cloud providers, and cybersecurity companies into a working relationship with federal agencies for response to significant incidents. The CISA Known Exploited Vulnerabilities catalog, updated continuously, is increasingly treated as an operational priority list by critical infrastructure security teams.

CISA's SBOM work is central here. The SBOM Community has produced guidance on format, distribution, and usage, and several sector-specific SBOM-sharing working groups operate with CISA as a convener. The energy sector, through the Electricity Information Sharing and Analysis Center, has been especially active, as has the healthcare sector through H-ISAC. These are not formal regulatory structures, but they carry weight because the sector expectations they produce shape procurement requirements, insurance underwriting, and audit findings.

Sector-Specific Texture

Each sector wears its supply chain concerns differently. In electricity, the concern focuses on inverters, protective relays, remote terminal units, and substation automation equipment. In oil and gas, it focuses on custody-transfer metering, pipeline SCADA, and upstream control systems. In healthcare, it is electronic health records, imaging systems, medical devices, and patient portals. In water, increasingly, it is the OT-lite environment of small and medium utilities with minimal staffing and commercial SCADA packages they cannot really maintain.

The common feature across sectors is that the vendors who serve them are themselves complex software supply chain actors. A major electric utility might have 300 distinct OT vendors. A regional hospital system might interact with more than 1,000 third-party applications. The operator cannot audit all of them, and the traditional approach, a vendor security questionnaire once per contract cycle, cannot keep up with the pace of change in the underlying software.

The Push Toward Attestation and Transparency

The response has been a slow shift toward continuous attestation. Rather than annual questionnaires, operators are beginning to ask for ongoing SBOM feeds, vulnerability disclosure commitments with specific SLAs, and evidence of secure development practices. The SSDF self-attestation work from OMB has influenced sector expectations even when the vendors are not selling to the federal government. Insurance carriers have added supply chain controls to their underwriting questionnaires, and several large operators have begun linking procurement approval to the results.

International frameworks also exert pressure. The EU's NIS2 Directive, which expanded coverage across sectors and added direct supply chain obligations under Article 21, has forced multinational operators to align their US and EU practices. The Cyber Resilience Act, entering enforcement in the second half of the decade, extends product-side obligations to hardware and software makers placing products on the EU market. Since many critical infrastructure vendors sell internationally, these obligations ripple into US procurement through the vendors themselves.

Operational Technology Has Its Own Rules

IEC 62443 is the dominant standard for OT security, and its parts 4-1 and 4-2 speak directly to secure development lifecycle and component requirements. Certification against 62443 has become a de facto expectation for new industrial control system products, and several operators require it in procurement. ISA Secure and CB Scheme certifications feed into procurement decisions in a way that parallels how SSDF attestations work in the federal IT space.

The practical challenge is that 62443 is not automatic, and many operators still accept vendor statements of conformance without probing. A more mature approach pairs vendor statements with SBOMs, independent verification against the actual code, and ongoing monitoring for newly disclosed vulnerabilities in the declared components. The operators doing this well are typically the ones with dedicated OT security teams and strong procurement partnerships with IT security.

The Long Tail of Shared Components

Perhaps the most important shift is the recognition that critical infrastructure sectors share far more software than they used to. The same logging library, the same web framework, the same embedded Linux distribution, the same cloud monitoring agent shows up across electricity, water, healthcare, and manufacturing. A vulnerability in one shared component can produce simultaneous exposure across sectors. Log4Shell drove this home in 2021, and subsequent events have reinforced the point. The operator community is slowly developing the muscle to respond to cross-sector library events as a coordinated exercise rather than as parallel scrambles.

How Safeguard Helps

Safeguard gives critical infrastructure operators and their vendors a common platform for software supply chain visibility. We ingest SBOMs across IT and OT environments, map findings to sector-specific frameworks including NERC CIP, TSA Security Directives, HIPAA, and IEC 62443, and produce reports that align with CISA's Cyber Performance Goals. When a zero-day surfaces in a widely used library, our customers see which of their assets and vendors are affected in minutes, and they can coordinate remediation with sector ISACs and vendor partners from a single dashboard. The outcome is measured in the time it takes to move from disclosure to containment, and that is where Safeguard delivers the most value.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.