Patching Without Stopping Production, and Keeping Safety and Security Together

Rules, standards and guidance described: NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security (September 2023, the current final version; Draft Rev. 4 open for comment through Nov. 30, 2026); CISA Known Exploited Vulnerabilities catalog version 2026.10.27; CISA SSVC Guide (November 2022); CISA, FBI, EPA and DOE "Primary Mitigations to Reduce Cyber Threats to Operational Technology" (May 6, 2025); OSHA Process Safety Management standard, 29 CFR 1910.119 (eCFR text current as read Oct. 28, 2026); EPA Risk Management Program, 40 CFR Part 68 (2024 rule in force; Feb. 24, 2026 proposal pending, no final rule as of Oct. 28, 2026); IEC 61511 (2016 edition, described, not quoted); ISA-TR84.00.09-2024 Part 1 (described); ISA-TR62443-2-3-2015 (described); DOE National Cyber-Informed Engineering Strategy (June 15, 2022). All checked Oct. 28, 2026. Rules and standards change; check the current text before you rely on any of it.

This lesson has two halves that belong together. The first half is about keeping plant-floor computers and controllers patched, or protected when they cannot be patched, without shutting down production. The second half is about process safety: the engineering discipline that keeps a chemical plant, a refinery, a dairy's ammonia refrigeration system or a water plant's chlorine room from hurting people. The two meet in the same place, the control system, and the same people often own both. A patch that crashes a controller is a safety event. An attacker who can change a safety system's logic has turned a cyber problem into a process safety problem. And the most reliable protection against the worst cyber attack is often a piece of plain mechanical engineering that has no software at all.

If you need the basics of patching office computers and websites, they are in Vulnerabilities, Patching and Your Website and, for home and small-office machines, Updates, Antivirus and Settings. Backup basics are in Computers, Local Data and Backups. This lesson does not repeat them. It covers what is different on the plant floor. The terms OT, ICS, PLC, HMI, SCADA and DCS are explained in IT, OT and the Purdue Model, and the standards behind this lesson (IEC 62443 and NIST SP 800-82) are explained in IEC 62443 and NIST SP 800-82.

Part 1. Why patching a plant is hard

On an office network, the patch routine is simple to describe even when it is hard to do: the vendor releases a fix, IT tests it on a few machines, then pushes it to everyone and reboots overnight. Almost every step of that routine breaks on a plant floor. NIST's OT guide spends a whole section on how OT differs from IT, and patching is where those differences bite hardest.¹

Equipment lives for decades

NIST says "typical IT components have a lifetime on the order of three to five years," while in OT "the lifetime of the deployed technology is often in the order of 10 to 15 years and sometimes longer."¹ The 2024 edition of IEC 62443-2-1, the international standard for an asset owner's industrial security program, goes further: its official abstract says the lifespan of an industrial automation and control system "can exceed twenty years" and that "many legacy systems contain hardware and software that are no longer supported."³ A packaging line installed in 2008 may still be running the operator workstation, the programming laptop and the controller firmware it shipped with. The company that built it may have been bought twice since. The person who wrote the controller program may have retired.

That lifetime is not carelessness. A production line is a capital investment that is paid off over many years. Replacing a working controller means re-engineering, re-testing and often re-certifying the line, and a working line makes money every hour it runs. The security problem is that the threat moves on a three-to-five-year IT clock while the equipment moves on a fifteen-to-twenty-year plant clock.

Uptime and planned outages

NIST puts it bluntly: "Many OT processes are continuous in nature. Unexpected outages of systems that control industrial processes are unacceptable. Outages must often be planned and scheduled days or weeks in advance." It adds that "typical IT strategies (e.g., rebooting a component) are usually not acceptable for OT."¹ A refinery may go years between full turnarounds. A food plant may run three shifts, six days a week, with a sanitation window on the seventh. A batch chemical process cannot be paused halfway through a reaction. A water plant must keep making safe water through the patch window. For many plants, the only time a controller or server can be touched is a scheduled maintenance outage, and the outage calendar is set by production, not by the security team.

The vendor must qualify the patch

Control system vendors test their software against specific operating system versions and specific patches. NIST says OT software updates "need to be thoroughly tested by both the vendor and the end user of the industrial control application before being implemented."¹ Many vendors publish a list of operating system patches they have qualified for their product, usually some weeks after the operating system maker releases them. A plant that installs an unqualified patch, or a third-party antivirus product the vendor never approved, can lose vendor support. NIST notes that some third-party security products "are not allowed due to OT vendor licensing and service agreements, and service support can be lost if third-party applications are installed without vendor acknowledgement or approval."¹ So the first question about any patch on the plant floor is not "is it critical?" but "has the control system vendor approved it for our version?"

Federal agencies have started pushing on this from the buyer side. The January 2025 Secure by Demand guide for OT owners, written by CISA with NSA, FBI, EPA, TSA, partner agencies in six other countries (Australia, Canada, Germany, the Netherlands, New Zealand and the United Kingdom) and the European Commission, lists "Upgrade and Patch Tooling" among twelve security elements buyers should demand. Its selection test: the product "has a well-documented and easy to follow process for patches and upgrades, and the manufacturer provides security patches at no extra cost," including porting software to a new operating system "free of charge if the original operating system is no longer supported." It also tells buyers to ask whether the vendor tests patches and reports the results, and whether the product supports "resilient patching features to reduce the risk of downtime from a bad patch (e.g., golden images)."⁴

Old operating systems that nobody patches

NIST warns that "many OT utilize older versions of OSs that are no longer supported by the vendor through patches," and repeats the point in its patch section: "Many OT systems utilize older versions of OSs that are no longer supported by the vendor, so patches may not be available."¹² An operator workstation may run a desktop operating system two or three generations old because the HMI software (the human-machine interface, the screens operators use to run the process) was never certified on anything newer. Upgrading the operating system means upgrading the HMI software, which may mean a new license, new controller firmware, and a re-test of every screen and alarm. For these machines the honest answer to "is it patched?" is "no patch exists." The only tools left are the compensating controls described later in this lesson.

Validated processes

Some plants cannot change software without proving the change did not affect the product. Drug, medical device and some food plants validate their computerized systems for quality and regulatory reasons: they document that the system does what it is supposed to do, every time, and they must show that any change keeps it in that validated state. NIST lists this as one reason OT changes take longer, noting that updates may require revalidation.¹ In practice a security patch on a validated system can trigger a documented impact assessment, a test protocol, a quality sign-off and a record of the result. That is not a reason to skip patching. It is a reason to build security patches into the validation plan in advance, so that a routine patch follows a routine, pre-approved path instead of a new project each time. The sector rules for medical device makers and other regulated manufacturers are in Sector Rules.

Equipment that cannot be rebooted

Many controllers, and some safety systems, are designed to run without stopping. Updating a programmable logic controller's firmware (a PLC is the rugged industrial computer that reads sensors and drives motors and valves) usually means stopping the controller, and stopping the controller usually means stopping the equipment it runs. Redundant systems, where a backup controller takes over while the primary is updated, make this easier, but many small plants do not have them. A single controller running a whole line, with no spare and no backup, is common in small manufacturing. For that controller, every firmware update is a production outage and a risk that the line does not come back.

Patches can break things

NIST's warning deserves to be read in full: "It is not uncommon for patches to have an adverse impact on other software. A patch may remove a vulnerability, but it can also introduce a greater risk from a production or safety perspective. Patching the vulnerability may also change the way the OS or application works with control applications, causing the control application to lose some of its functionality."² On an office laptop, a bad patch means a help-desk ticket. On a plant floor, it can mean an HMI that stops updating, an alarm that does not sound, or a controller that faults and trips the line. Plant engineers who resist patching are not always being stubborn. Many have watched a patch break something.

There is no government data on how long plants take to patch

Reporters and board members often ask, "How long does it take a typical plant to patch?" The honest answer is that no U.S. government agency publishes that number. CISA publishes advisories and the Known Exploited Vulnerabilities catalog, NIST publishes guidance, and the FBI publishes complaint data, but none of them measures how long manufacturers take to apply control system patches. This module's research team looked for such a dataset on Oct. 28, 2026, and found none. Security vendors publish survey and telemetry figures, and those can be useful, but each reflects that vendor's customers and methods. If you quote one, name the company, the year, and how it gathered the data, and do not present it as a national statistic.

What the public data does show is how much there is to triage. One analysis by the security firm SOCRadar counted more than 450 CISA industrial control system advisories in 2025, covering 2,065 CVEs (CVE numbers are the standard IDs for publicly known vulnerabilities), with technologies used in critical manufacturing the largest share of affected products at 45.8 percent. CISA itself does not publish an annual count, so treat that as one firm's tally.⁵ And the industrial security firm Dragos, reviewing 2025 advisories, judged that only 3 percent needed action "Now," 71 percent could be handled "Next" with compensating controls or at the next maintenance window, and 27 percent "Never" needed action in most plants. Dragos also found that 25 percent of advisories came with no patch or mitigation at all.⁶ Those are a vendor's judgments, but they match what plant engineers say: most advisories are not emergencies, a few are, and the job is telling them apart.

What NIST SP 800-82 Rev. 3 says to do

NIST SP 800-82 Rev. 3, published in September 2023, is the federal government's main guide to OT security. It is guidance, not a regulation: no agency fines a private manufacturer for ignoring it. But regulators, insurers, customers and courts treat it as the reference for what a reasonable OT security program looks like, and several sector rules borrow from it. Section 6.2.11, "Flaw Remediation and Patch Management," is two pages long and worth reading in full.²

"Systematic, accountable, and documented"

The central sentence is this: "Organizations should implement a systematic, accountable, and documented OT patch management process for managing exposure to vulnerabilities." NIST says the process "should include guidance on how to monitor for patches, when to apply patches, how to test the patches (e.g., with vendors or on offline systems), and how to select compensating controls to limit exposure of the vulnerable system when patching is delayed."² Read those words as a checklist:

• Systematic: the same steps every time, for every asset, not a scramble after each headline.
• Accountable: a named person decides, and the decision can be traced to that person.
• Documented: there is a written record of what was found, what was decided, why, and what was done.
• Monitor: someone watches the advisories that apply to the plant's equipment.
• When: the plant decides timing based on risk and the outage calendar.
• Test: patches are tested with the vendor or on offline systems before they reach production.
• Compensating controls: when a patch waits, the plant does something else to limit exposure, and writes down what.

NIST also says "an organization is responsible for staying informed and determining when patches should be applied as part of their documented patch management process."² That responsibility does not transfer to the vendor or the integrator, even when they do the work.

Who decides, and when patches go in

NIST gives three short rules. First, "When and how to deploy patches should be determined by knowledgeable OT personnel." The IT department should not push patches to control systems on its own schedule. Second, "Consider separating the automated process for OT patch management from the automated process for non-OT applications." An office patch server that can reach the plant floor is a way for an IT mistake, or an attacker in IT, to reach the plant floor too. Third, "Patching should be deployed during planned OT outages."²

Testing gets its own warning: "Significant care should be exercised when applying patches to OS components. Patches should be adequately tested (e.g., offline system testing) to determine the acceptability of any performance impacts. Regression testing is also advised."² Regression testing means checking that things that worked before the patch still work after it: every screen, alarm, interlock, report and data link.

The standards NIST points to

For plants that are not under a sector rule, NIST says they "may develop patch management procedures based on existing standards," and it names three: NIST SP 800-40 Rev. 4, NERC CIP-007, and "ISA 62443-2-3, Patch Management in the IACS Environment."²

• NIST SP 800-40 Rev. 4 (April 2022), "Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology," frames patching as preventive maintenance, "a cost of doing business," and recommends an enterprise strategy that sorts assets into groups with their own maintenance plans. It is written for IT but its ideas carry over.⁷
• NERC CIP-007 is the mandatory patch and system security standard for the bulk electric grid, with its own fixed review cycle. It applies to grid operators, not to most manufacturers; Sector Rules covers it.
• ISA-TR62443-2-3-2015, "Patch management in the IACS environment," is a technical report in the ISA/IEC 62443 family. It describes how asset owners and product suppliers should exchange patch information and how owners should run a patch program. It is a paid document; this lesson describes it and does not quote it.⁸

What may change in Rev. 4

NIST released the initial public draft of SP 800-82 Rev. 4 on Sept. 21, 2026, with comments open through Nov. 30, 2026. NIST says the draft reorganizes the guide around the Cybersecurity Framework 2.0, puts risk management under the framework's Govern function, and expands guidance on asset management and network monitoring.⁹ Rev. 3 remains the final version as of Oct. 28, 2026. Plants writing a patch procedure now should follow Rev. 3 and watch for the final Rev. 4.

Deciding what to fix first

A plant with a few hundred devices can easily face dozens of new advisories a month and a backlog of hundreds of old ones. Nobody can patch all of that during a few outage windows a year. The plants that do this well do not try. They sort, using three questions: Is anyone actually exploiting this? Can an attacker reach the vulnerable device? And what happens to people, product and equipment if the device is taken over or knocked offline?

Where vulnerability news comes from

Before you can sort, you need a list of what you own and a feed of what is wrong with it. The asset inventory comes first; CISA's August 2025 joint guidance calls an asset inventory "an organized, regularly updated list of an organization's systems, hardware, and software" and lists fourteen high-priority attributes to collect for each OT asset, including manufacturer, model, operating system, IP address, ports and services, and asset criticality; its appendix adds others, such as firmware and software version, as medium priority.¹⁰ Without manufacturer, model and version, nobody can tell whether a new advisory applies. With them, the feeds below become useful:

• CISA ICS advisories. CISA publishes industrial control system advisories several times a week, each naming the vendor, the affected products and versions, the CVE numbers, a severity score and the vendor's fix or workaround.¹¹ They are free and anyone can subscribe by email.
• Vendor security notices. NIST cautions that "not all vendors report known vulnerabilities to CISA," and recommends "subscribing to vendor-specific notifications in addition to CISA alerts and advisories."² Most large automation vendors run a security notification page or portal. Sign up for every vendor in your inventory, including the small ones that built a single machine.
• The Known Exploited Vulnerabilities catalog (KEV). CISA's list of vulnerabilities it has reliable evidence are being used in real attacks, explained below.
• Integrators and service contracts. The system integrator or machine builder may learn of a problem first. Put a duty to tell you in the contract; CISA and the FBI's September 2026 fact sheet on working with third-party ICS integrators urges owners to write cybersecurity and supply chain requirements into those contracts.¹² Lesson 4, Remote Access, Vendors and Supply Chain, covers contract terms in detail.
• Sector groups. Information sharing and analysis centers (ISACs) for water, electricity, chemicals and other sectors pass along warnings with sector context.

The Known Exploited Vulnerabilities catalog

CISA launched the KEV catalog in November 2021 with Binding Operational Directive 22-01, which "requires federal civilian agencies to remediate such vulnerabilities within specific timeframes." The directive binds only federal civilian agencies, but CISA "strongly recommends" that private businesses and state and local governments "prioritize mitigation of vulnerabilities listed in CISA's public catalog."¹³ The catalog is a free list, also published as a data feed, and each entry names the product, the CVE, the date CISA added it, and the required action.

As of catalog version 2026.10.27, pulled Oct. 28, 2026, the KEV catalog listed 1,760 vulnerabilities, 361 of them flagged as known to be used in ransomware campaigns.¹⁴ The FBI's 2025 Internet Crime Report gives the same advice in eight words: "Prioritize patching known exploited vulnerabilities in internet-facing systems."¹⁵

Two things about KEV matter on the plant floor. First, very few KEV entries are control system products. In the October 2026 catalog, this module's search by vendor name found only a handful of entries for major automation vendors: two for Siemens, one each for Rockwell Automation, Schneider Electric, Unitronics and Delta Electronics (a name search can miss entries).¹⁴ Most KEV entries are for firewalls, VPN gateways, remote access tools, email servers, web software and Windows. That is not a reason to ignore KEV in OT. It is the reason to use it: attackers usually reach a plant through exactly those IT and edge devices. Colonial Pipeline's chief executive told a Senate committee in June 2021 that the attacker who forced the pipeline shutdown "exploited the legacy VPN profile that was not intended to be in use," and that the account had only single-factor authentication.¹⁶ Dragos reports that 73 percent of its all-time incident response cases "involved compromised VPN or jumphost credentials."⁶ The firewall between the business network and the plant, the VPN the vendor uses, the remote desktop gateway and the Windows servers in the plant's demilitarized zone (DMZ) are the devices most likely to appear on KEV, and they are the ones to patch first.

Second, a KEV listing is a fact, not a forecast. It tells you someone is exploiting the flaw now. If a KEV entry matches a device on your inventory that can be reached from the internet or from the business network, treat it as urgent and get it into the next possible window, or apply compensating controls today.

SSVC in plain terms

Most advisories come with a CVSS score (Common Vulnerability Scoring System), a number from 0 to 10 that measures how bad a flaw is in general. It does not know anything about your plant. A 9.8 on a device sitting in an isolated cell with no network path may matter less than a 6.5 on the remote access gateway. CISA's SSVC guide (SSVC is a vulnerability categorization method; its full name is in the note), published in November 2022, replaces the single score with a short decision tree that "any individual or organization can use."¹⁷

SSVC asks five questions. (The guide also has teams record a vulnerability's mitigation status, but CISA says that value "does not change the priority of the SSVC decision.")

The answers lead to one of four outcomes. CISA defines them this way: Track means the vulnerability "does not require action at this time"; Track* means it has characteristics "that may require closer monitoring"; Attend means it "requires attention from the organization's internal, supervisory-level individuals," with remediation "sooner than standard update timelines"; and Act means it needs supervisory and leadership attention and should be remediated "as soon as possible."¹⁷

The public well-being question is where SSVC fits a plant better than a CVSS score. CISA's guide says a vulnerability has a "Material" impact if it "introduces occupational safety hazards" or "reduces and/or results in failure of cyber-physical system safety margins," and an "Irreversible" impact if "multiple fatalities are likely" or the system "is likely lost or destroyed."¹⁷ That is the language of process safety, and it is a reason to have the plant's safety lead in the room when vulnerabilities are ranked.

Exposure and consequence: a simple matrix

Many small plants find a two-question matrix easier to use day to day than the full decision tree. One axis is exposure: how easily can an attacker reach the device? The other is consequence: what happens if it is taken over or stops? The matrix below is an original teaching tool built on the SSVC questions and NIST's guidance; it is not an official CISA product. Pair it with KEV: a known-exploited flaw moves the device one row up.

"Compensate today" does not mean "patch today." It means do something today to cut the exposure, such as closing a firewall rule, disabling a vendor account or unplugging a cellular modem, and then put the actual fix into the next safe window. The next section explains those compensating controls.

When you cannot patch: compensating controls

A compensating control is a protection you add because the direct fix is not available yet, or ever. NIST tells plants to decide in advance "how to select compensating controls to limit exposure of the vulnerable system when patching is delayed."² Dragos's review of 2025 advisories put 71 percent in its "Next" category, meaning compensating controls now and a patch at the next maintenance cycle if one exists.⁶ In other words, compensating controls are not a backup plan for a few odd devices. For most plants they are the main plan, and patching is what happens when the calendar allows.

Every control below changes how plant systems behave. Plan each one with the equipment vendor, your safety lead and qualified controls engineers, test it on a spare or a lab system first, and schedule it like any other change.

Get it off the internet

The first compensating control is the cheapest. CISA, the FBI, EPA and DOE put it first in their May 2025 fact sheet: "Remove OT connections to the public internet." The agencies explain that attackers find exposed devices "by searching for open ports on public IP ranges with search engine tools" and use "simple, repeatable, and scalable toolsets available to anyone with an internet browser."¹⁸ The 2026 attacks on programmable controllers by Iranian-affiliated actors, described in CISA advisory AA26-097A, hit controllers that were directly reachable from the internet; one of the advisory's key actions is "Remove PLCs from direct internet exposure via secure gateway and firewall."¹⁹ A vulnerable controller with no route from the internet and a tightly controlled route from the business network is a very different risk from the same controller with a public address. The full story of those attacks is in Threats and Real Cases.

Segment the network

Segmentation means dividing the network into zones, such as the business network, a plant DMZ, supervisory systems and individual production cells, and allowing only the traffic each zone needs to cross each boundary. CISA's fourth mitigation is "Segment IT and OT networks," including "introducing a demilitarized zone for passing control data to enterprise logistics."¹⁸ NIST's executive summary lists "Employing a DMZ network architecture (e.g., prevent direct traffic between the corporate and OT networks)."²⁰ For an unpatchable device, segmentation is the most important control: it shrinks the set of computers that can ever talk to it. Dragos found poor IT/OT segmentation in 81 percent of its 2025 assessments, so most plants have room to improve.⁶ The plan, step by step, is in A Plant-Floor Segmentation Plan.

Allow only approved programs

Application allow-listing (NIST calls it "allowlisting") lets a computer run only programs on an approved list. Anything else, including most malware, will not start. NIST says "the relatively static nature of OT environments presents an opportunity for organizations to include application allowlisting as part of their defense-in-depth strategy," and tells plants to "coordinate with their vendors" and test the configuration "thoroughly" before deploying it.²¹ An operator workstation that runs the same five programs every day for ten years is a much better fit for allow-listing than an office laptop. Many control system vendors have qualified specific allow-listing products for their platforms; ask before installing anything, because an unapproved product can void support.

Turn off what you do not use

NIST's "least functionality" guidance says OT devices "include many functions and services that are unnecessary for their proper operation, some of which may be enabled by default and without the organization's knowledge," and that "any functions or services that are not required for proper operation should be disabled to reduce exposure." It also gives the warning that belongs next to every hardening project: "Care should be taken when disabling these functions and services, as unintended impacts may result if a critical function or service is unknowingly disabled (e.g., disabling all external communications to a PLC may also disable the ability to communicate with associated HMIs)."²² A built-in web server on a controller that nobody uses, a file-sharing service on an HMI, an unused remote desktop service: each is a door. Close them after testing, with the vendor's guidance.

Watch the traffic

Control networks are predictable. The same devices talk to the same devices in the same way, all day. That makes unusual traffic stand out. NIST recommends network monitoring through SPAN ports or passive network taps, which copy traffic without sending anything onto the control network, and host-based monitoring on HMIs, servers and engineering workstations "provided that the addition of the tools does not adversely impact operational performance or safety."²³ Monitoring does not fix a vulnerability, but it tells you if someone is trying to use one. Dragos found adequate OT network monitoring in only 46 percent of its 2025 assessments, and said 30 percent of its incident response cases began as unexplained operational problems.⁶ Small plants can start with free tools: NIST's manufacturing extension program points to Malcolm, a network traffic analysis tool suite from Idaho National Laboratory and CISA with parsers for many industrial protocols.²⁴

Control USB drives and laptops

Many plant networks that are well separated from the internet are still reached the old way: on a USB stick or a contractor's laptop. NIST's media protection guidance says "the use of any unauthorized removable media or device on any node that is part of or connected to the OT should not be permitted," and that solutions can be "either procedural or technical."²⁵ In practice that means plant-owned, scanned media only; a scanning station at the door of the control room; disabled USB ports where the vendor allows it; and a rule that visiting laptops connect only to a designated port, if at all. Patches themselves usually arrive on removable media or by download, so the patch process needs its own clean path: download from the vendor's official site, check the file's published hash or signature, scan it, and carry it on a dedicated, controlled device.

Lock down remote access

Vendors often support plant equipment remotely. NIST says remote access "should be provided only if justified and limited to what is required for the business need," should "not circumvent or negate safety or security controls," and should use multifactor authentication; it lists practices such as "Removing access when no longer required," "Monitoring remote activities," and "Initiating the connection from the OT environment."²⁶ When a vulnerability affects a remote access tool, the fastest compensating control is often to turn the remote access path off until it is patched, and have the vendor call in. Remote Access, Vendors and Supply Chain covers this in depth.

Keep controllers in run mode

Many controllers have a physical key switch or mode switch with positions such as RUN, PROGRAM and REMOTE. In RUN, many controllers refuse program changes over the network. CISA's 2017 analysis of the malware aimed at Triconex safety controllers recommended keeping the controller's keyswitch out of PROGRAM mode except when changes are actually being made, and it relayed Schneider Electric's advice that safety systems be deployed on isolated networks.²⁷ The 2026 advisory on Iranian-affiliated PLC attacks gives the same advice for Rockwell devices: "place the physical mode switch on the controller into run position."¹⁹ It costs nothing. It does require a procedure, so that the key is kept by a named person and the switch is returned to RUN after every approved change.

Write down the compensating controls for each unpatched vulnerability, who approved them, and when the plant will look at the item again. That record is what NIST means by "accountable."

Backups and golden images of controller logic

Every patch plan needs a way back. On a plant floor that means more than a copy of a server's hard drive. It means a current, tested copy of the program inside every controller, the configuration of every network switch and firewall, the project files on the engineering workstation, the HMI screens and alarm settings, the license keys, and the installation media for software the vendor may no longer sell.

NIST's backup guidance for OT is specific. It says "a list of all maintained backups should be developed, including installation media, license keys, and configuration information," and it tells plants to verify backups for integrity, keep an on-site copy that the people who will do the recovery can reach, and keep a second copy somewhere the same incident cannot touch. Its example is plain: "store PLC logic and configuration files at an off-site, geographically diverse location that cannot be destroyed by the same [hurricane, wildfire, tornado] that may destroy the PLC." NIST also says to "test the restoration process from backup data as part of contingency plan testing" and to "ensure that backup procedures are included in configuration or change management processes."²⁸ In June 2026, NIST's National Cybersecurity Center of Excellence added a short OT Backup Quick Start Guide (NIST SP 1339) for owners who want a simple starting point.²⁹

Three ideas make OT backups work in practice:

• The golden image. A golden image is a known-good, complete copy of a computer (operating system, applications, settings and patches) captured after the system was tested and approved. If an HMI or engineering workstation is infected or a patch goes wrong, you restore the golden image instead of rebuilding by hand. Make a new golden image after every approved change, label it with the date and change number, and keep the previous one until the new one has proven itself. Secure by Demand asks buyers to look for products that support this kind of "resilient patching."⁴
• The logic baseline. For each controller, keep the approved program version and a way to compare the running program against it. Many controller platforms can show whether the running logic differs from a saved copy. A difference you did not approve is a reason to investigate, whether it came from an attacker or from a technician who made a quick fix on night shift and never saved it.
• The restore drill. A backup that has never been restored is a hope, not a backup. At least once a year, restore a controller program and a workstation image onto spare hardware and confirm they run. Write down how long it took; that number belongs in the plant's recovery plan.

Keep backups offline or on a separate, protected system. Ransomware that reaches a file server will encrypt every backup it can see, and some attackers look for backups first. The general backup rules, including the 3-2-1 rule, are in Computers, Local Data and Backups.

Change management and management of change

Plants already have a discipline for changing things safely, and a security patch should go through it. Two terms overlap here. Change management (or configuration management) is the IT and controls engineering practice of documenting the approved configuration of each system and controlling changes to it. Management of change (MOC) is the process safety practice, required in chemical plants by federal rule, of reviewing any change to a hazardous process before it is made.

Configuration change control under NIST

NIST says plants "should document the approved baseline configuration for their OT devices" and use a defined life cycle approach "to document, test, and approve changes before deploying them to the OT environment." It suggests centralizing the tracking of changes, because "such a process may help organizations to prevent accidental reconfiguration or identify the intentional reconfiguration of components to unapproved or untested versions." It also notes that "many changes to OT can be made only during scheduled maintenance downtimes to minimize impacts."³⁰ And in its comparison of IT and OT, NIST adds that "change management is also applicable to hardware and firmware."¹ A firmware update to a drive, a switch or a controller is a change, even though nobody touched the program.

Management of change under OSHA's process safety rule

OSHA's Process Safety Management standard, 29 CFR 1910.119, covers processes that involve listed highly hazardous chemicals at or above threshold quantities, along with large quantities of flammable liquids and gases, with some exceptions. Its management of change paragraph says: "The employer shall establish and implement written procedures to manage changes (except for 'replacements in kind') to process chemicals, technology, equipment, and procedures; and, changes to facilities that affect a covered process." Before any change, the procedures must address the technical basis for the change, its impact on safety and health, changes to operating procedures, the time needed, and the authorization required.³¹

The standard defines a replacement in kind as one that "satisfies the design specification." Plants differ on where security patches fall. A vendor-approved operating system patch on an HMI may be treated as a replacement in kind under a plant's own procedure. A firmware update that changes how a controller behaves, a change to the safety system, or a new security product on a control system host is much harder to call "in kind." The rule's own list of covered equipment for mechanical integrity includes "emergency shutdown systems" and "controls (including monitoring devices and sensors, alarms, and interlocks)."³¹ A sensible line, which many process plants draw in their own procedures, is that anything touching the safety instrumented system, an alarm or an interlock goes through full MOC with the process safety lead's sign-off. Whatever line your plant draws, write it down before the first patch, not during the outage.

Testing in a lab or on spares

NIST's patch guidance names two places to test: "with vendors or on offline systems."² Large companies keep test systems that mirror production. Small plants rarely can, but most have more options than they think:

• The vendor's lab. Ask whether the vendor has tested the patch against your product version, and ask for the results. Secure by Demand tells buyers to ask, "Does the manufacturer test patches and report the results to check for compatibility issues?"⁴
• Spare hardware. A spare controller or a spare HMI computer kept for breakdowns can host the patched software for a test run, using a copy of the production program, before the patch goes near the line.
• A twin line. Plants with several identical lines can patch one, run it for a period, and then patch the rest.
• Virtual machines. Many supervisory applications run in virtual machines, which can be copied into a test network and patched there first.
• A staged rollout. Patch the least critical system first, watch it through a full production cycle, then move on.

Whatever the method, write a short test plan: what will be checked (screens, alarms, interlocks, historian data, communications, timing), who checks it, and what result means "pass." Then keep the record.

The patch decision, start to finish

End-of-life equipment

Sooner or later every controller, workstation and network device reaches end of life: the vendor stops making it, then stops supporting it, then stops publishing patches for it. Plants deal with that in four ways, usually in combination.

1. Know the dates. Add vendor end-of-sale and end-of-support dates to the asset inventory. Secure by Demand tells buyers to ask, "Does the manufacturer publish end-of-life dates for their products?"⁴ A device whose support ends in 18 months should be in next year's capital plan, not discovered in an audit.
2. Wrap it. An unsupported device that must stay in service gets the strongest compensating controls the plant has: its own zone, no remote access, allow-listing on any Windows host, monitoring, and a locked cabinet.
3. Stock spares and backups. Keep spare modules and the installation media and licenses for old software. When the vendor no longer sells a part, a failed module can stop the line for weeks.
4. Plan the migration. Replacing a control system is an engineering project that can take years. Tie it to planned turnarounds and expansions, and write security requirements into the purchase: the Secure by Demand elements, the IEC 62443 product requirements described in IEC 62443 and NIST SP 800-82, and a commitment to patch support for a defined period.

Boards and owners should hear the honest version: running unsupported equipment is a business decision that accepts risk. It can be a reasonable one, but it should be made on purpose by someone with the authority to accept that risk, written down, and revisited.

Part 2. Safety and security together

Most of this module treats a cyber attack on a plant as a business problem: lost production, lost data, ransom demands. In a plant that handles hazardous energy or chemicals, it can be a life-safety problem. NIST's OT guide lists safety first among OT's primary concerns: "For OT, primary concerns include safety, fault tolerance to prevent the loss of life or endangerment of public health or confidence, regulatory compliance, loss of equipment, loss of intellectual property, or lost or damaged products."¹ This half of the lesson explains how process safety works, where cyber risk enters it, and what engineers have learned about protecting a plant even when the computers cannot be trusted. Other modules on this site take the same defense-in-depth approach in other industries; see Safety and Radiation for nuclear plants and Safety and Local Impacts for natural gas.

What process safety is

Process safety is the engineering and management work that prevents fires, explosions and toxic releases from processes that handle hazardous materials or energy. It is different from personal or occupational safety (hard hats, guardrails, slips and falls). A plant can have an excellent record on slips and falls and still have a process that could kill people beyond the fence line. Process safety asks: what are the hazards in this process, what could cause them to be released, and what stands in the way?

The answer to the last question is always more than one thing. Process safety engineers design layers, each meant to stop the event independently of the others, so that a single failure does not become a disaster.

Hazards and layers of protection

The layers are often drawn as an onion, with the process at the center. A widely used method called layer of protection analysis (LOPA), developed and documented by the Center for Chemical Process Safety (CCPS), checks whether a hazardous scenario has enough independent protection layers to bring its risk down to a level the company accepts. CCPS's 2015 guidelines on the method describe the layer types as inherent safety, preventive layers and mitigation layers, and explain why some scenarios need protection layers that are not safety instrumented systems.³² The key word is independent: a layer only counts if it would still work when the initiating cause and the other layers have failed.

Cyber risk attacks that independence. Several layers in a modern plant run on the same networks, the same kinds of computers and sometimes the same engineering workstation. An attacker who controls the basic process control system may also be able to silence its alarms, and in plants where control and safety are integrated, may be able to reach the safety system too. NIST warns that "combining control and safety could allow a sophisticated attacker access to both control and safety systems if the OT were compromised," and tells plants to "ensure the adequate separation of components consistent with the risk of compromise."³³

Safety instrumented systems

A safety instrumented system is the automated layer whose only job is to put the process into a safe state when something goes wrong. NIST's glossary defines an SIS as "a system that is composed of sensors, logic solvers, and final control elements whose purpose is to take the process to a safe state when predetermined conditions are violated," and notes other names for it: emergency shutdown system, safety shutdown system and safety interlock system.³⁴ An SIS is made of one or more safety instrumented functions (SIFs). A typical SIF watches one dangerous condition, such as high pressure in a reactor, and if the condition crosses a set point, it closes a valve, stops a pump or opens a vent, regardless of what the regular control system is doing.

NIST explains that an SIS "is often independent from all other control systems in such a manner that a failure of the basic process control system (BPCS) will not impact SIS functionality in a deleterious manner." Historically, NIST says, an SIS was "stand-alone, physically and logically separated, and air-gapped from the rest of the control system." Some modern designs, called integrated control and safety systems, allow the SIS to communicate with the control system, which gives operators better information but also creates a path between the two.³⁴

IEC 61511 and ISA-84

Safety instrumented systems in the process industries are designed under IEC 61511, the international functional safety standard for SIS in the process sector. In the United States ISA publishes it as ANSI/ISA-61511 (the 2018 U.S. parts adopt the 2016 IEC edition and its 2017 amendment), and engineers still call the family "ISA-84," after the earlier U.S. standard, ANSI/ISA-84.00.01-2004, which NIST cites in its glossary. ISA groups these standards and its related technical reports as the ISA-84 series.³⁵³⁴ NIST says the SIS "is specifically designed in accordance with [IEC61511]."³⁴ The standard is paid and is not quoted here. In plain terms, it sets a life cycle for safety systems: identify hazards, decide how much risk reduction each safety function must provide (expressed as a safety integrity level, or SIL, with higher numbers meaning more reliability is required), design and verify the function to meet that level, test it periodically, and manage every change.

The 2016 edition of IEC 61511 added a cybersecurity requirement. According to a summary by exida, a functional safety certification firm, clause 8.2.4 requires end users to carry out a security risk assessment of the SIS, covering the devices involved, the threats, the potential consequences and the risk reduction needed.³⁶ In other words, a plant that claims to follow IEC 61511 today should be able to show a written security risk assessment of its safety systems.

ISA TR84.00.09: cybersecurity across the safety life cycle

ISA's technical report TR84.00.09 explains how to tie the cybersecurity life cycle (from IEC 62443) to the safety life cycle (from IEC 61511). The 2017 edition ran 118 pages and covered safety controls, alarms and interlocks (SCAI), including SIS.³⁷ The current edition is ISA-TR84.00.09-2024, Part 1, "Cybersecurity Related to the Safety Lifecycle," which ISA describes as guidance on integrating cybersecurity with functional safety life cycles for safety controls, alarms and interlocks in the process industries.³⁸ It is a paid document. Its main practical message, which you will also hear from safety engineers, is that the safety team and the security team should work from the same hazard analysis and the same list of safety functions, and should review each other's changes.

Process hazard analysis and OSHA's PSM standard

The legal backbone of process safety in U.S. chemical plants, refineries and many other facilities is OSHA's Process Safety Management standard, 29 CFR 1910.119. It applies to processes with listed highly hazardous chemicals at or above threshold quantities, and to processes with large amounts of flammable liquids and gases, with exceptions.³¹ Idaho has no OSHA-approved State Plan; OSHA says Idaho "is under federal OSHA jurisdiction which covers most private sector workers within the state," so federal OSHA enforces PSM at Idaho's private plants. OSHA adds that in Idaho, "State and local government workers are not covered by federal OSHA," which leaves out most city and district water and wastewater staff.³⁹

PSM contains no cybersecurity requirement. Its words were written in 1992 and do not mention networks, malware or attackers. But two of its elements bear directly on cyber risk:

• Process hazard analysis (PHA). The employer must perform a PHA "appropriate to the complexity of the process," and the PHA must address, among other things, "the hazards of the process," "engineering and administrative controls applicable to the hazards and their interrelationships," "consequences of failure of engineering and administrative controls," and "a qualitative evaluation of a range of the possible safety and health effects of failure of controls on employees in the workplace." The PHA must be updated and revalidated "at least every five (5) years."³¹ A cyber attack is one way controls fail. A PHA team that assumes the control system will always behave as designed is leaving a cause out.
• Mechanical integrity. The equipment the employer must inspect, test and maintain includes "relief and vent systems and devices," "emergency shutdown systems," and "controls (including monitoring devices and sensors, alarms, and interlocks)."³¹ Keeping those systems working as designed now includes keeping them from being changed by someone who should not change them.

Management of change, discussed above, is the third connection. A security patch, a firewall rule that touches safety system traffic, or a new remote access path is a change to a covered process if it can affect how controls behave.

EPA's Risk Management Program

Facilities that hold listed toxic or flammable substances above threshold amounts also fall under EPA's Risk Management Program (RMP), issued under Clean Air Act section 112(r) at 40 CFR Part 68. RMP requires hazard assessments, prevention programs that for the highest-risk facilities closely mirror OSHA's PSM elements (including hazard analysis and management of change), and emergency response planning. Like PSM, RMP contains no explicit cybersecurity controls. EPA's 2024 rule, "Safer Communities by Chemical Accident Prevention," took effect May 10, 2024. On Feb. 24, 2026, EPA proposed changes it called a "Common Sense Approach to Chemical Accident Prevention," which would, among other things, drop the requirement to implement safer technology alternatives, narrow or rescind third-party audits, and limit the public RMP data tool to county-level search. As of Oct. 28, 2026, no final rule had been found.⁴⁰ The arguments on both sides of that proposal are covered in Sector Rules.

Cyber PHA: asking what a hacker could do

A "cyber PHA" (also called a security PHA review) takes the plant's existing hazard analysis and asks a new question of each scenario. Edward Marszal of the engineering firm Kenexis described one version in ISA's InTech magazine in 2016: start from the existing PHA results, which usually come from a HAZOP (hazard and operability study), and for each scenario ask whether its cause, and all of its safeguards, could be manipulated by someone who controls the industrial control system. If they can, the scenario is "hackable." Mechanical safeguards such as relief valves generally cannot be hacked, so a scenario protected by a properly sized relief valve is in a different class from one protected only by software. The severity of the consequence then sets how strong the cybersecurity protections around those systems must be, using the security levels in IEC 62443. Marszal wrote that the security PHA review "is an evolution of PHA."⁴¹

The value of this approach for a small plant is that it does not start from scratch. The PHA already exists, the team already knows the scenarios, and the result is a short list: the scenarios where every safeguard is digital and reachable. Those are the places to add a mechanical safeguard, separate the safety system, or put the strongest controls the plant has. The PHA team should include the controls engineer and whoever owns OT security, not only process and safety engineers.

Cyber-informed engineering: an Idaho idea with national reach

Much of the most useful public thinking on how to protect plants when the computers cannot be trusted came out of Idaho National Laboratory (INL) in Idaho Falls. INL runs the Department of Energy's long-standing control system security work, and it hosts CISA's free, in-person ICS301 training course in Idaho Falls.⁴² Two related methods from INL matter here: Consequence-driven Cyber-informed Engineering (CCE), a structured study for one facility, and Cyber-Informed Engineering (CIE), the broader set of principles for designing any digitally controlled physical system.

The National Cyber-Informed Engineering Strategy

The Department of Energy released its National Cyber-Informed Engineering Strategy on June 15, 2022, as directed by the National Defense Authorization Act for fiscal 2020. It is organized around five pillars: Awareness, Education, Development, Current Infrastructure and Future Infrastructure. Energy Secretary Jennifer Granholm said at its release, "Building a powerful and resilient grid that can withstand the full gamut of modern cyber threats begins at the design level."⁴³ The strategy was written for the energy sector, but its principles apply to any plant that relies on a digital control system.

The strategy lists twelve CIE principles in two groups.⁴⁴

DOE's own wording of "engineered controls" is the heart of this lesson's second half: "Identify engineering changes and process controls early in system design to eliminate or mitigate cyber risk, reducing the need to bolt on additive IT security controls during implementation."⁴⁴ And "planned resilience with no assumed security" says to "expect that any digital component or system may be compromised at some point during its lifecycle, and plan for continued operation during and after a cyber attack that degrades digital controls."⁴⁴ In September 2023 DOE added a CIE Implementation Guide, a set of questions engineering teams can ask at each stage of a system's life, and an online CIE resource library hosted by INL.⁴⁵

Consequence-driven Cyber-informed Engineering (CCE)

CCE turns those principles into a study of one organization or facility. INL says CCE assumes that a skilled, determined adversary "can and will" get into the network, and uses a "think like the adversary" approach; it describes CCE as a rigorous process for applying CIE to a specific organization, facility or mission.⁴⁶ The method is laid out in a 2021 book by INL's Andrew Bochman and Sarah Freeman, Countering Cyber Sabotage: Introducing Consequence-Driven, Cyber-Informed Engineering (CCE), and in a set of INL reference documents dated May 5, 2020.⁴⁷⁴⁸

INL's four phases are: (1) Consequence Prioritization, identifying the "high-consequence events" (HCEs) that would be intolerable; (2) System-of-Systems Analysis, mapping everything those events depend on; (3) Consequence-based Targeting, working out the path a capable adversary would most likely take to cause each event; and (4) Mitigations and Protections, removing the cyber path to each event where possible, or detecting and recovering where it is not.⁴⁸

CCE's useful twist is that it starts from the consequence, not the vulnerability. A patch-centered program asks, "What is wrong with our software?" and can never finish. CCE asks, "What is the worst thing that could happen here, and what would it take?" For most plants, the answer is a short list: a toxic release, an explosion, a fire, a contaminated product shipped to customers, or the destruction of a machine that cannot be replaced for a year. For each, the study looks for a way to make the event impossible through cyber means alone, which usually means an engineered control.

Engineering controls that cyber cannot defeat

Some protections have no software in them at all. They respond to physics, not to commands, and no attacker on the network can change them. Examples:

• Pressure relief valves and rupture disks. A spring-loaded relief valve opens at its set pressure whether or not any computer tells it to. A rupture disk bursts at its rated pressure. Both must be sized correctly, installed correctly and maintained, which PSM's mechanical integrity element requires.³¹
• Mechanical interlocks and limit stops. A trapped-key interlock that physically prevents a door from opening while a machine runs, or a mechanical stop that prevents a valve from opening past a set point, cannot be overridden from a keyboard.
• Hard-wired trips. A high-pressure switch wired directly to a motor contactor, with no controller in between, will stop the pump even if every PLC in the plant has been reprogrammed.
• Fail-safe design. Spring-return valves that move to their safe position when air or power is lost, and motors that stop when a signal is lost, turn many attacks into a safe shutdown.
• Physical limits on the process. A smaller tank, a lower-pressure design, or a pump that physically cannot exceed a safe flow rate removes the hazard instead of guarding it. This is what process safety engineers call inherently safer design.
• Manual operation. Hand valves, local gauges and trained people who know how to use them.

Engineered controls have limits. They protect against the specific physical event they were designed for, not against every harm. A relief valve stops a vessel from bursting, but the vented material still has to go somewhere safe. Engineered controls do nothing to stop an attacker from quietly changing a recipe so that bad product ships, or from stealing designs. And they can fail through neglect: a relief valve that was never tested, or a hard-wired trip that someone bypassed with a jumper to keep the line running, protects nothing. Engineered controls and cybersecurity controls are partners. The engineered control guards the worst outcome; the cybersecurity program keeps the attacker from getting close enough to test it.

Triton: the warning

The Triton attack, sometimes called Trisis or HatMan, is the case that turned the safety-security connection from theory into fact. Lesson 3, Threats and Real Cases, tells the full story. In brief: according to the Justice Department, between May and September 2017 hackers working for an institute affiliated with Russia's Ministry of Defense broke into a foreign refinery and installed malware on a Schneider Electric safety system (a Triconex controller, according to CISA's analysis of the malware).²⁷ The malware was designed to keep the safety system from working while the plant appeared normal, but it "caused a fault" that led the safety systems "to initiate two automatic emergency shutdowns," which exposed the operation. In 2018 the same group researched similar U.S. refineries and unsuccessfully tried to hack the computer systems of the U.S. company that owned them. In March 2022 DOJ unsealed an indictment of a Russian government programmer, Evgeny Viktorovich Gladkikh.⁴⁹

Four lessons from Triton belong in every plant's safety and security program:

1. Attackers do target safety systems. The intent was not to steal data or demand ransom. Disabling a safety system makes sense only as a step toward physical harm.
2. The safety system failed safe. The malware's own fault tripped the plant into shutdown. A well-designed SIS that trips on errors is doing its job, and the right response to an unexplained safety trip is investigation, not a quick restart.
3. Isolation and key switches matter. CISA's 2017 analysis of the malware recommended keeping safety controller key switches out of PROGRAM mode except when changes are being made, isolating safety networks, and not connecting the safety system's engineering workstations to larger networks.²⁷
4. The last layers must not depend on the SIS. Relief systems, mechanical protections and trained operators are what stand between an attacker who controls both control and safety systems and a catastrophe.

Triton was not a one-time event. CISA's 2026 advisory on Iranian-affiliated attacks says the actors disrupted controllers "through malicious project file interactions and manipulation of data on human machine interface (HMI) and supervisory control and data acquisition (SCADA) displays," and TechCrunch, reporting CISA's confirmation that more than 100 water systems were targeted in July 2026, said some intrusions modified PLCs to disable shutdown processes and alarms.¹⁹⁵⁰ Those were not sophisticated attacks on certified safety systems, but they went after the same thing: the automated protections that are supposed to stop a process before it hurts someone.

Practicing manual operation

The fifth of CISA's primary OT mitigations from May 2025 is the one most often skipped: "Practice and maintain the ability to operate OT systems manually." The agencies wrote that "the capability for organizations to revert to manual controls to quickly restore operations is vital in the immediate aftermath of an incident," and that "business continuity and disaster recovery plans, fail-safe mechanisms, islanding capabilities, software backups, and standby systems should all be routinely tested to ensure safe manual operations in the event of an incident."¹⁸

Real cases show why. In November 2023, when a booster station controller at the Municipal Water Authority of Aliquippa, Pennsylvania, was disabled by an Iranian-linked group, the authority switched to manual operation; its chairman said, "It sent an alarm and we took control manually," and "nobody was ever at risk."⁵¹ In July 2026, when coordinated attacks hit water utilities in Minnesota, Plymouth disconnected cellular-connected equipment at water towers and lift stations and ran them manually, and Braham's well and treatment plant were restored in about two hours; state officials said drinking water quality was not affected.⁵² Those utilities could fall back to manual operation because people there knew how.

Manual operation is a skill that fades. Plants that automated years ago may have few operators left who have run the process by hand, and the procedures may describe valves that have since been replaced. A useful program has four parts: written manual procedures for each critical system, kept current through MOC; local gauges and hand valves that are tested, not just installed; drills, scheduled during planned outages, in which crews actually run a unit by hand for a period; and a decision rule for when to switch to manual and when to shut down instead. Some processes cannot be run safely by hand at all. For those, the manual plan is a safe, controlled shutdown, and the drill is practicing that.

The July 2026 "CI Fortify" guidance from CISA, Australia's cyber agency, the FBI and international partners goes a step further. It urges operators to map dependencies, build separation points in advance, and test graduated plans for isolating OT from outside networks in a crisis, and it says "physical isolation remains the most risk-effective solution."⁵³ Isolation works only if the plant can run, or shut down safely, without the connections it cut. Practicing manual operation is how a plant finds out.

A sample OT patch and change management procedure

The sample below pulls the two halves of this lesson into one written procedure that a small or mid-size plant could adapt. It is deliberately plain. A procedure people follow beats a perfect one in a binder. Before you adopt anything like it, plan it with the equipment vendors, your safety lead and qualified controls and process safety engineers, and test the steps on a non-production system first.

Common mistakes

Each of these failures has shown up in a documented case or a government finding.

• Leaving controllers on the internet with factory passwords. The Iranian-linked "CyberAv3ngers" group defaced Unitronics controllers in several U.S. states in late 2023 by using default credentials, and the joint advisory told owners to "check PLCs for default passwords."⁵⁴ In 2026 the same kind of exposure let Iranian-affiliated actors disrupt controllers across several sectors.¹⁹ No patch was needed to prevent either: taking the devices off the internet and changing passwords would have done it.
• Forgetting the old remote access path. Colonial Pipeline's CEO testified that the attacker came in through a legacy VPN profile "that was not intended to be in use," protected by a single factor.¹⁶ Old vendor accounts, modems and remote tools rarely appear on anyone's patch list. Put them on the inventory and close what is not used.
• Weak basics at water systems. EPA said in May 2024 that over 70 percent of drinking water systems it had inspected since September 2023 were in violation of basic Safe Drinking Water Act section 1433 requirements, and its inspectors found systems that "failed to change default passwords, use single logins for all staff, or failed to curtail access by former employees."⁵⁵ Many manufacturers run their own water and wastewater treatment with the same kinds of controllers.
• Treating safety systems as untouchable, and therefore unexamined. Triton showed that safety controllers can be targeted, and CISA's analysis told owners to keep safety controller key switches out of PROGRAM mode when no change is being made and to keep safety engineering workstations off larger networks.²⁷ A safety system that nobody on the security team is allowed to look at is a safety system nobody has checked.
• Letting IT push patches to the plant. NIST says OT patch decisions belong to "knowledgeable OT personnel" and that OT patch automation should be kept separate from IT's.² NotPetya in 2017 showed how fast trouble moves across connected corporate networks: Merck reported the attack disrupted "its worldwide operations, including manufacturing."⁵⁶
• Having backups that cannot be restored. NIST tells plants to test restoration "as part of contingency plan testing."²⁸ The first restore attempt should not happen during an incident.
• Losing the ability to run by hand. CISA's 2025 fact sheet calls the ability to revert to manual controls "vital in the immediate aftermath of an incident."¹⁸ Norsk Hydro kept producing after its March 2019 ransomware attack by shifting many units to "work-intensive workarounds and manual procedures," while Aliquippa and Plymouth, Minnesota, ran water equipment manually after controller attacks.⁵⁷⁵¹⁵² Plants that have not practiced cannot count on doing the same.
• No monitoring, so problems look like equipment faults. Dragos reported that 30 percent of its incident response cases began as unexplained operational problems, and found adequate OT monitoring in only 46 percent of 2025 assessments.⁶
• Accepting unsupported equipment by default. Running end-of-life systems is sometimes necessary, but when nobody decided it on purpose, nobody added the compensating controls either.

Questions people ask

Why not just disconnect the plant from everything and stop worrying about patches?

For some systems, physical isolation is the right answer, and federal guidance agrees: the July 2026 CI Fortify guidance says "physical isolation remains the most risk-effective solution" for vital systems in a crisis.⁵³ But a fully isolated plant still gets software from somewhere: vendor laptops, USB drives, replacement parts with firmware, and engineering updates. Most plants also need production data to flow to the business. Isolation reduces risk a great deal, but it does not end the need to track vulnerabilities, control removable media and keep backups. Segmentation with tightly controlled paths, described in A Plant-Floor Segmentation Plan, is the practical middle ground for most plants.

How fast are we supposed to patch?

Outside regulated sectors, no federal rule sets a deadline for private manufacturers. The federal civilian deadlines under Binding Operational Directive 22-01 apply to federal agencies, not companies.¹³ Some sector rules and customer contracts set their own timelines; check the rule's current text in Sector Rules. For everyone else, NIST's answer is a documented process that decides timing by risk and uses compensating controls while a fix waits.² A good internal target is "compensating controls within days for anything known to be exploited and reachable; real fixes at the next safe outage."

The vendor says installing the patch will void our support. What now?

Ask the vendor three questions in writing: When will you qualify this patch for our version? What compensating controls do you recommend until then? Is there a supported upgrade path that includes the fix? NIST confirms that support can be lost when unapproved software is installed, so do not ignore the warning.¹ Apply compensating controls, record the vendor's answer, and use the experience in the next purchase: Secure by Demand tells buyers to require patches at no extra cost and a documented patch process.⁴

Is a security patch a "change" under OSHA's process safety rule?

The rule requires written procedures for changes to "process chemicals, technology, equipment, and procedures," except "replacements in kind," which it defines as replacements that satisfy the design specification.³¹ The rule does not mention software patches, so each plant has to decide in its own written procedures how they are handled. A conservative and common approach is to run anything that can affect safety systems, alarms or interlocks through full management of change. Ask your safety lead how your plant's procedure answers this, and get the answer in writing before the next outage.

We are a 40-person shop with one maintenance tech and no controls engineer. Where do we start?

Start with the cheapest, highest-value steps: make a list of every controller, HMI and network device with its make, model and version; make sure none is reachable from the internet; change default passwords; turn off vendor remote access when it is not in use; and back up every controller program to two places, one off site. Sign up for CISA ICS advisories and your vendors' notices. Then get help. Idaho's Manufacturing Extension Partnership center, TechHelp, is based at Boise State University with partners at Idaho State University and the University of Idaho; NIST's MEP program says its centers can help manufacturers "assess your business's current risk posture, identify any gaps, and implement solutions."⁵⁸⁵⁹ CISA offers free tools such as the Cyber Security Evaluation Tool (CSET), and free OT training, including the in-person ICS301 course in Idaho Falls.⁴² Verizon's 2025 breach report found that "more than 90% of breached organizations" in manufacturing were small and mid-size businesses with fewer than 1,000 employees, so size is not protection.⁶⁰

Does a cyber PHA replace our regular process hazard analysis?

No. It adds to it. The cyber PHA reuses the existing hazard scenarios and asks whether each cause and safeguard could be manipulated through the control system.⁴¹ The regular PHA, with its five-year revalidation under PSM, remains the legal requirement for covered processes.³¹ Many plants schedule the cyber review alongside the PHA revalidation so the same team, with a controls engineer added, does both.

Is CCE only for big utilities and defense plants?

The full CCE study is detailed and was built for critical infrastructure, and DOE's strategy was written for the energy sector.⁴³ But its first phase, naming the handful of events your plant can never allow, takes a few hours with the right people in a room, and it is useful to any plant. So is the habit of asking, for each of those events, whether a non-digital protection stands in the way.

Hard questions

Should the government set patch deadlines for private plants?

The case for deadlines: Voluntary guidance has existed for years, yet attackers in 2023 and 2026 still found controllers on the internet with default passwords. Federal agencies already work under KEV deadlines. A clear rule would give plant security teams something firm to point to when production resists an outage, push vendors to qualify patches faster, and protect neighbors who bear the risk of a release but have no say in the plant's decisions.

The case against: NIST itself warns that a patch can "introduce a greater risk from a production or safety perspective," and that OT patches must be tested and installed during planned outages.² A fixed deadline could force plants to install untested changes on safety-related systems or to shut down production on a regulator's clock. Many vulnerabilities have no patch at all; Dragos counted 25 percent of 2025 advisories with no patch or mitigation.⁶ Critics of deadlines argue that rules on outcomes (no internet exposure, documented risk decisions, tested backups) would protect more than rules on patch timing.

What the evidence shows: The documented attacks on U.S. controllers in 2023 and 2026 relied on exposure and default passwords, not on unpatched flaws that a deadline would have fixed.⁵⁴¹⁹ At the same time, the edge devices that lead into plants, such as VPNs and firewalls, are exactly the products that dominate KEV, and those can be patched on IT timelines.¹⁴ No public data measures how fast plants patch, so neither side can show what a deadline would change.

Who should pay to replace equipment the vendor no longer supports?

One view: Vendors sold products with long service lives and should keep them patchable or provide upgrade paths at little or no cost. The federal Secure by Demand guide takes this side in part, asking buyers to require that manufacturers port software to supported operating systems "free of charge."⁴ It also notes that "the burden of industrial cybersecurity costs falls disproportionally on OT owners and operators rather than manufacturers."⁴

The other view: No vendor can support every product forever, and buyers chose the equipment and enjoyed years of use. Owners, not vendors, decide how long to run old systems, and should budget for replacement as they do for any capital asset. Public money for upgrades, where it exists, should go to public systems such as water utilities, not to private manufacturers.

What the evidence shows: NIST and IEC both document that OT commonly runs 10 to 20 years or more, often past vendor support.¹³ Secure by Demand is guidance for buyers, not a rule for vendors. In practice the cost lands wherever the purchase contract puts it, which is why the contract terms at purchase matter so much.

Should OSHA's and EPA's chemical safety rules add explicit cybersecurity requirements?

For: PSM and RMP already govern the plants where a cyber attack could hurt the most people, and their hazard analysis, mechanical integrity and management of change elements are natural homes for cyber review. CFATS, the chemical security program that once covered cyber at high-risk chemical facilities, lapsed in July 2023, and CISA says it "cannot enforce compliance" with those rules.⁶¹ Adding cyber to PSM and RMP would fill that gap with agencies that already inspect these plants.

Against: OSHA and EPA inspectors are process safety and environmental experts, not cybersecurity specialists, and adding cyber requirements could produce paperwork without real protection. IEC 61511 already requires a security risk assessment of safety systems, and plants that follow it are covered.³⁶ EPA's 2026 proposal moves in the opposite direction, toward fewer RMP requirements, reflecting a view that the 2024 rule's burdens outweighed its benefits.⁴⁰

What the evidence shows: The current PSM text already requires hazard analysis to consider the "consequences of failure of engineering and administrative controls," which a careful team can read to include cyber failure.³¹ Whether that reading is applied in practice varies by plant, and no public OSHA or EPA data measures how many covered facilities include cyber scenarios in their PHAs.

Should plants spend on engineered controls or on cybersecurity tools?

For engineered controls first: DOE's CIE strategy favors engineering changes that "eliminate or mitigate cyber risk" over bolted-on IT controls.⁴⁴ A relief valve costs less than many security products and works no matter what the attacker knows.

For cybersecurity tools: Engineered controls protect only against specific physical events. They do nothing for ransomware that stops production, theft of designs, or quietly altered product quality, which are the attacks most manufacturers actually face. Dragos counted about 3,300 industrial organizations hit by ransomware in 2025.⁶

What the evidence shows: Both camps describe real risks, and the CCE method gives a way to divide the budget: engineered controls for the few high-consequence events, and the cybersecurity program for everything else.⁴⁸

Where to go next

• CISA Known Exploited Vulnerabilities Catalog: Free list and data feed of vulnerabilities CISA knows are exploited. For anyone who keeps an asset inventory: compare it against your list weekly, starting with firewalls, VPNs and remote access tools.
• CISA Cybersecurity Alerts and Advisories (ICS advisories): Free industrial control system advisories naming vendors, affected versions and fixes. Subscribe by email and filter for the vendors in your plant.
• CISA SSVC Guide and calculator page: Free decision tree for ranking vulnerabilities by exploitation, impact and public well-being. Useful for plant teams that want a written, repeatable way to decide what to fix first.
• NIST SP 800-82 Rev. 3: Free federal OT security guide. Read Sec. 6.2.4 (backups, configuration control, least functionality) and 6.2.11 (patch management) before writing a patch procedure.
• INL Cyber-Informed Engineering resources: Free INL material on CCE and CIE from Idaho National Laboratory, for engineers and plant leaders who want to find and design out high-consequence events.
• CISA ICS training (ICS301 in Idaho Falls): Free, no-tuition, four-day in-person course in Idaho Falls for OT and IT staff, after the free online ICS300 prerequisite.
• NIST MEP cybersecurity resources for manufacturers: Free guides and a path to low-cost help from MEP centers; in Idaho the MEP center is TechHelp at Boise State University.

Still being checked (5 items)

These points could not be fully confirmed against a primary source when this lesson was written and fact checked in October 2026. The text above states each one as uncertain.

• No U.S. government dataset on OT time-to-patch was found; vendor figures exist but were not used.
• IEC 61511 clause 8.2.4 security risk assessment requirement is described from exida's summary; the paid standard was not read.
• ISA-TR84.00.09-2024 Part 1 contents are described from ISA's product description only; its publication month and page count were not confirmed.
• The CCPS 2015 LOPA guidelines are described from the publisher's description; the book was not read.
• The KEV vendor-name counts (Siemens 2, Rockwell 1, Schneider Electric 1, Unitronics 1, Delta Electronics 1) come from a name filter and may be incomplete.

Last verified October 28, 2026. General education, not legal, engineering, safety or compliance advice; rule versions and dates are stated in the text, and the sources used are listed in the Notes and Sources below. Check the regulator's current text before relying on any point.

Notes

1. NIST, Guide to Operational Technology (OT) Security, SP 800-82 Rev. 3, September 2023, Sec. 2.4, "Comparing OT and IT System Security," pp. 29 to 30 (read Oct. 28, 2026). Read it online. ↩
2. NIST, Guide to Operational Technology (OT) Security, SP 800-82 Rev. 3, September 2023, Sec. 6.2.11, "Flaw Remediation and Patch Management," pp. 124 to 125 (read Oct. 28, 2026). Read it online. ↩
3. IEC 62443-2-1:2024, Security for industrial automation and control systems, Part 2-1: Security program requirements for IACS asset owners, IEC Webstore publication abstract, publication date Aug. 7, 2024 (paid standard; only the public abstract is quoted) (read Oct. 28, 2026). Read it online. ↩
4. CISA, NSA, FBI, EPA, TSA and international partners, Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products, Jan. 13, 2025, pp. 1, 6, 7 and 20 ("Upgrade and Patch Tooling") (read Oct. 28, 2026). Read it online. ↩
5. SOCRadar, "CISA Industrial Control Systems (ICS) Advisories Recap for 2025" (a security vendor's count; CISA does not publish an annual total) (read Oct. 28, 2026). Read it online. ↩
6. Dragos, "Dragos 2026 OT Cybersecurity Year in Review" (covering 2025), blog and press release, Feb. 17, 2026 (vendor analysis; figures attributed to Dragos) (read Oct. 28, 2026). Read it online. ↩
7. NIST, Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology, SP 800-40 Rev. 4, April 2022; summarized in NIST SP 800-82 Rev. 3, Sec. 6.2.11 (read Oct. 28, 2026). Read it online. ↩
8. ISA, "ISA/IEC 62443 Series of Standards," list of published parts including ISA-TR62443-2-3-2015, "Patch management in the IACS environment" (paid document; described, not quoted) (read Oct. 28, 2026). Read it online. ↩
9. NIST, "Guide to Operational Technology (OT) Security: NIST Requests Comments on Draft SP 800-82r4," Sept. 21, 2026 (comments through Nov. 30, 2026) (read Oct. 28, 2026). Read it online. ↩
10. CISA, EPA, NSA, FBI and international partners, "Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators," Aug. 13, 2025 (read Oct. 28, 2026). Read it online. ↩
11. CISA, Cybersecurity Alerts and Advisories (includes ICS advisories, filterable by type) (read Oct. 28, 2026). Read it online. ↩
12. CISA and FBI, "Considerations for Critical Infrastructure Operators Working With Third-Party ICS Integrators," fact sheet, Sept. 23, 2026 (read Oct. 28, 2026). Read it online. ↩
13. CISA, "CISA Releases Directive Reducing the Significant Risk of Known Exploited Vulnerabilities" (Binding Operational Directive 22-01), press release, Nov. 3, 2021 (read Oct. 28, 2026). Read it online. ↩
14. CISA, Known Exploited Vulnerabilities Catalog, JSON feed, catalog version 2026.10.27 (1,760 entries; 361 flagged "Known" for ransomware use; additions by year and vendor-name counts computed by this module's research team from the feed) (read Oct. 28, 2026). Read it online. ↩
15. FBI Internet Crime Complaint Center, Internet Crime Report 2025, p. 15 (read Oct. 28, 2026). Read it online. ↩
16. U.S. Senate Committee on Homeland Security and Governmental Affairs, "Threats to Critical Infrastructure: Examining the Colonial Pipeline Cyber Attack," hearing, June 8, 2021, S. Hrg. 117-429, testimony of Joseph Blount (read Oct. 28, 2026). Read it online. ↩
17. CISA, CISA Stakeholder-Specific Vulnerability Categorization Guide, November 2022, pp. 3 to 9, Tables 1 to 7 (read Oct. 28, 2026). Read it online. ↩
18. CISA, FBI, EPA and DOE, "Primary Mitigations to Reduce Cyber Threats to Operational Technology," fact sheet, May 6, 2025 (read Oct. 28, 2026). Read it online. ↩
19. FBI, CISA, NSA, EPA, DOE, U.S. Cyber Command Cyber National Mission Force and partners, "Iranian-Affiliated Cyber Actors Exploit Programmable Logic Controllers Across US Critical Infrastructure," advisory AA26-097A, April 7, 2026, updated July 22, 2026 (read Oct. 28, 2026). Read it online. ↩
20. NIST, Guide to Operational Technology (OT) Security, SP 800-82 Rev. 3, September 2023, Executive Summary, p. 4 (read Oct. 28, 2026). Read it online. ↩
21. NIST, Guide to Operational Technology (OT) Security, SP 800-82 Rev. 3, September 2023, Sec. 5.2.5.1, "Application Allowlisting," p. 77 (read Oct. 28, 2026). Read it online. ↩
22. NIST, Guide to Operational Technology (OT) Security, SP 800-82 Rev. 3, September 2023, Sec. 6.2.4.1, "Least Functionality (PR.IP-1)," p. 111 (read Oct. 28, 2026). Read it online. ↩
23. NIST, Guide to Operational Technology (OT) Security, SP 800-82 Rev. 3, September 2023, Sec. 5.2.3, "Layer 3, Network Security," p. 75 (network and host monitoring) (read Oct. 28, 2026). Read it online. ↩
24. NIST Manufacturing Extension Partnership, "Where to Start" (cybersecurity resources by CSF function, including INL and CISA's Malcolm tool and CISA's CSET) (read Oct. 28, 2026). Read it online. ↩
25. NIST, Guide to Operational Technology (OT) Security, SP 800-82 Rev. 3, September 2023, Sec. 6.2.7, "Media Protection (PR.PT-2)," p. 119 (read Oct. 28, 2026). Read it online. ↩
26. NIST, Guide to Operational Technology (OT) Security, SP 800-82 Rev. 3, September 2023, Sec. 6.2.10, "Remote Access," pp. 122 to 124 (read Oct. 28, 2026). Read it online. ↩
27. CISA (NCCIC), "HatMan: Safety System Targeted Malware," Malware Analysis Report MAR-17-352-01, Dec. 18, 2017, pp. 7 to 8 (mitigations, including Schneider Electric security notification SEVD-2017-347-01) (read Oct. 28, 2026). Read it online. ↩
28. NIST, Guide to Operational Technology (OT) Security, SP 800-82 Rev. 3, September 2023, Sec. 6.2.4.3, "Backups (PR.IP-4)," pp. 112 to 113 (read Oct. 28, 2026). Read it online. ↩
29. NIST Computer Security Resource Center, Operational Technology Security project news (NIST SP 1339, "OT Backup Quick Start Guide," June 17, 2026) (read Oct. 28, 2026). Read it online. ↩
30. NIST, Guide to Operational Technology (OT) Security, SP 800-82 Rev. 3, September 2023, Sec. 6.2.4.2, "Configuration Change Control (Configuration Management) (PR.IP-3)," pp. 111 to 112 (read Oct. 28, 2026). Read it online. ↩
31. OSHA, Process Safety Management of Highly Hazardous Chemicals, 29 CFR 1910.119, paragraphs (a)(1), (b) (definition of "replacement in kind"), (e)(1), (e)(3), (e)(6), (j)(1) and (l)(1) to (l)(2), eCFR current text (read Oct. 28, 2026). Read it online. ↩
32. Center for Chemical Process Safety (CCPS), Guidelines for Initiating Events and Independent Protection Layers in Layer of Protection Analysis, Wiley, February 2015, publisher description (read Oct. 28, 2026). Read it online. ↩
33. NIST, Guide to Operational Technology (OT) Security, SP 800-82 Rev. 3, September 2023, Sec. 4.2.2, "Safety Systems," p. 55 (read Oct. 28, 2026). Read it online. ↩
34. NIST, Guide to Operational Technology (OT) Security, SP 800-82 Rev. 3, September 2023, Sec. 2.3.7, "Safety Systems," p. 25, and Appendix B, Glossary, "safety instrumented system" (citing ANSI/ISA-84.00.01-2004) (read Oct. 28, 2026). Read it online. ↩
35. ISA, "ISA-84 Standards" (lists ANSI/ISA-61511-1-2018/IEC 61511-1:2016+AMD1:2017, Parts 2 and 3, and ISA-TR84.00.09-2024 Part 1) (read Oct. 28, 2026). Read it online. ↩
36. Steve Gandy, "How Secure Is Your Safety Instrumented System (SIS)?," exida blog, Sept. 8, 2016 (summary of IEC 61511-1:2016 clause 8.2.4; the paid standard was not read) (read Oct. 28, 2026). Read it online. ↩
37. GlobalSpec Engineering360, listing for ISA-TR84.00.09, "Cybersecurity Related to the Functional Safety Lifecycle," April 10, 2017 edition, 118 pages (read Oct. 28, 2026). Read it online. ↩
38. ISA, product page, "ISA-TR84.00.09-2024, Part 1, Cybersecurity Related to the Safety Lifecycle" (read Oct. 28, 2026). Read it online. ↩
39. OSHA, "State Plans" (Idaho: "not an OSHA-approved State Plan, and is under federal OSHA jurisdiction which covers most private sector workers within the state. State and local government workers are not covered by federal OSHA.") (read Oct. 28, 2026). Read it online. ↩
40. EPA, "Accidental Release Prevention Requirements: Risk Management Programs Under the Clean Air Act; Common Sense Approach to Chemical Accident Prevention," proposed rule, 91 FR 8970, Feb. 24, 2026 (comment period extended April 2, 2026, 91 FR 16621); the 2024 SCCAP rule is 89 FR 17622, March 11, 2024, effective May 10, 2024. No final rule found in the Federal Register as of Oct. 28, 2026. Program 3 prevention program elements, including process hazard analysis (40 CFR 68.67), mechanical integrity (68.73) and management of change (68.75), are in 40 CFR Part 68, Subpart D, eCFR (read Oct. 28, 2026). Read it online. ↩
41. Edward Marszal, "Security process hazard analysis review," InTech (ISA), March/April 2016 (read Oct. 28, 2026). Read it online. ↩
42. CISA, "Advanced Cybersecurity for Industrial Control Systems (ICS301)," course page (in person in Idaho Falls, Idaho; no tuition) (read Oct. 28, 2026). Read it online. ↩
43. U.S. Department of Energy, "DOE Releases Strategy for Building Cyber-Resilient Energy Systems," June 15, 2022 (read Oct. 28, 2026). Read it online. ↩
44. U.S. Department of Energy, National Cyber-Informed Engineering Strategy, June 2022, pp. 13 to 14 ("Principles of CIE") (read Oct. 28, 2026). Read it online. ↩
45. U.S. Department of Energy, "DOE Releases Resources to Advance Cybersecurity by Design for the U.S. Energy Sector," Sept. 6, 2023 (CIE Implementation Guide and INL CIE Resource Library) (read Oct. 28, 2026). Read it online. ↩
46. Idaho National Laboratory, "Consequence-Driven Cyber-Informed Engineering" (read Oct. 28, 2026). Read it online. ↩
47. Andrew A. Bochman and Sarah Freeman, Countering Cyber Sabotage: Introducing Consequence-Driven, Cyber-Informed Engineering (CCE), Routledge/CRC Press, 2021 (read Oct. 28, 2026). Read it online. ↩
48. Idaho National Laboratory, "CCE Phase 1-4 Reference Document" (Phase 1, INL-EXT-20-58089; Phase 2, INL-EXT-20-58093; Phase 3, INL-EXT-20-58090; Phase 4, INL-EXT-20-58091; reports dated May 5, 2020) (read Oct. 28, 2026). Read it online. ↩
49. U.S. Department of Justice, "Four Russian Government Employees Charged in Two Historical Hacking Campaigns Targeting Critical Infrastructure Worldwide," press release, March 24, 2022 (read Oct. 28, 2026). Read it online. ↩
50. TechCrunch, "CISA confirms hackers targeted over 100 US water systems during July," Aug. 26, 2026 (press report) (read Oct. 28, 2026). Read it online. ↩
51. WaterWorld, "Aliquippa, Pennsylvania suffers cyberattack on booster station PLC," November 2023 (press report) (read Oct. 28, 2026). Read it online. ↩
52. Tenable, "Coordinated cyberattack on Minnesota water utilities: what you need to know," 2026 (press report) (read Oct. 28, 2026). Read it online. ↩
53. CISA, bulletin announcing "CI Fortify: Advice for isolating vital systems" (with Australia's ASD ACSC, FBI and international partners), July 28, 2026 (read Oct. 28, 2026). Read it online. ↩
54. FBI, CISA, NSA, EPA and Israel National Cyber Directorate, "IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors, Including U.S. Water and Wastewater Systems Facilities," advisory AA23-335A, Dec. 1, 2023 (read Oct. 28, 2026). Read it online. ↩
55. EPA, "Enforcement Alert: Drinking Water Systems to Address Cybersecurity Vulnerabilities," issued May 2024 (page last updated July 10, 2026) (read Oct. 28, 2026). Read it online. ↩
56. Merck and Co., Inc., Form 10-K for fiscal year 2017, filed with the SEC (NotPetya disclosure) (read Oct. 28, 2026). Read it online. ↩
57. Norsk Hydro, "Cyber attack" (company account of the March 19, 2019 attack) (read Oct. 28, 2026). Read it online. ↩
58. Boise State University, "TechHelp receives federal award to continue supporting Idaho manufacturers," March 25, 2026 (read Oct. 28, 2026). Read it online. ↩
59. NIST Manufacturing Extension Partnership, "Cybersecurity Resources for Manufacturers," last updated Sept. 30, 2025 (read Oct. 28, 2026). Read it online. ↩
60. Verizon, 2025 Data Breach Investigations Report, Manufacturing (NAICS 31 to 33), pp. 79 to 80 (read Oct. 28, 2026). Read it online. ↩
61. CISA, "Chemical Facility Anti-Terrorism Standards (CFATS)," program page (authority expired July 28, 2023) (read Oct. 28, 2026). Read it online. ↩
62. U.S. Bureau of Labor Statistics, Current Employment Statistics, Idaho manufacturing (SMS16000003000000001) and total nonfarm (SMS16000000000000001), seasonally adjusted, September 2026 preliminary; percentage calculated by this module (read Oct. 28, 2026). Read it online. ↩
63. Idaho Statesman, reprinted by East Idaho News, Sept. 8, 2026, on Idaho's state cyber operations center and the summer 2026 water attacks (press report; quotes state Rep. Ted Hill) (read Oct. 28, 2026). Read it online. ↩