Protect America's Critical Infrastucture From Cyberattacks
The Issue
PROTECT AMERICA’S CRITICAL INFRASTRUCTURE FROM CYBERATTACKS
Make Cyber-Informed Engineering the legal minimum for systems Americans depend on every day.
TL;DR:
America increasingly runs the physical world through computers. Drinking-water systems, power infrastructure, airports, transportation networks, pipelines, communications systems, government facilities, factories, and other essential services depend on software, industrial controllers, remote access, sensors, and network-connected equipment.
But too much of that infrastructure is still secured around assumptions that amount to “trust me, bro.” Trust that nobody finds the device. Trust that credentials are never stolen. Trust that the vendor is never compromised. Trust that a private network stays private. Trust that nobody changes the controller logic. Trust that operators can always believe what the computer tells them.
Recent attacks show why that is unacceptable. In July 2026, a joint federal advisory from the FBI, CISA, NSA, EPA, Department of Energy, U.S. Cyber Command, and Department of the Treasury documented Iranian-affiliated attackers targeting programmable logic controllers across U.S. critical infrastructure. Investigators found malicious changes capable of overriding instructions that maintained safe operating parameters and disabling critical alarm and shutdown logic.
That means a cyberattack can move beyond stealing data and begin affecting the physical world. An attacker may be able to manipulate pumps, valves, machinery, electrical equipment, safety controls, alarms, or the information operators rely on to make decisions.
At the same time, the Government Accountability Office has documented critical federal systems approximately 23 to 60 years old. Of 11 systems GAO identified as most urgently needing modernization, seven had known cybersecurity vulnerabilities, four contained unsupported hardware or software, and eight could not implement the federal government’s zero-trust strategy without modernization. One agency said standards governing its system were more than two decades old and incompatible with modern zero-trust capabilities.
We already know how to engineer systems around physical failure. We use circuit breakers because electrical faults happen. We use pressure relief because equipment can exceed safe limits. We use emergency stops, interlocks, redundancy, alarms, and independent safety systems because engineers do not assume everything will always work perfectly.
Cybersecurity needs the same philosophy.
The Department of Energy already calls this Cyber-Informed Engineering, or CIE. Instead of treating cybersecurity as something added after a system has already been designed, CIE asks engineers to consider cyber threats and their physical consequences during design, procurement, operation, modernization, and eventual replacement.
Congress should make Cyber-Informed Engineering, secure-by-design principles, and consequence-based cyber resilience a legal minimum for critical infrastructure and other high-consequence cyber-physical systems.
This should include secure procurement, stronger vendor responsibility, meaningful network segmentation, controlled remote access, protection against unauthorized controller changes, independent safety mechanisms where appropriate, trusted backups, manual and degraded operating capability, lifecycle security planning, modernization requirements for systems that cannot reasonably be secured, and funding to help small and rural operators meet those requirements.
This is not about forcing every rural water utility to build an NSA-level security operation. Requirements should be proportional to consequence, and Congress should fund the technical assistance and modernization needed to help smaller operators comply.
The goal is simple:
If the computer is compromised, the physical system should still be engineered to remain as safe and resilient as reasonably possible.
Because “trust me, bro” is not a security architecture.
And it definitely is not a safety system.
WHY I CARE ABOUT THIS:
I work professionally as a Senior Cybersecurity Engineer. Before moving professionally into cybersecurity, I also worked as an electrician.
Those two backgrounds greatly influence how I look at this issue.
Cybersecurity teaches you to think about adversaries.
How could somebody gain access?
What happens if credentials are stolen?
What if an employee clicks the wrong link?
What if a vendor is compromised?
What if a zero-day vulnerability appears?
What if an attacker gets inside something we assumed was protected?
Electrical work and engineering teach a different but complementary lesson:
Failure happens, so systems must be designed around what happens when it does.
Circuit breakers exist because we do not simply trust that a short circuit will never happen.
Ground-fault protection exists because we do not assume electricity will always remain where it was intended to remain.
Emergency stops exist because machines can malfunction.
Pressure relief exists because equipment can exceed safe limits.
Safety interlocks exist because humans and machines make mistakes.
Redundancy exists because components fail.
Engineers do not normally design a physical safety system by saying:
“Nobody will ever do the wrong thing, so we do not need to account for it.”
Yet when software enters the equation, that philosophy too often disappears.
Suddenly we hear:
“The network is private.”
“Only employees know the password.”
“That system is not supposed to be accessible from the internet.”
“The vendor handles that.”
“Nobody knows how the old system works, so we do not touch it.”
“We will replace it eventually.”
“It has always worked.”
“We have a firewall.”
“We have never been attacked before.”
In cybersecurity terms, this amounts to:
Trust me, bro.
And “trust me, bro” is not an engineering control.
WHEN SOFTWARE CONTROLS THE PHYSICAL WORLD, CYBERSECURITY BECOMES PUBLIC SAFETY:
There is an enormous difference between compromising an ordinary computer and compromising operational technology.
A compromised laptop may result in stolen data, ransomware, fraud, downtime, or privacy violations.
Those consequences can be severe.
But when software controls physical equipment, cyber compromise can become a physical event.
Operational Technology, commonly called OT, includes programmable systems and devices that interact with the physical environment.
NIST identifies industrial control systems, transportation systems, building automation systems, physical-access systems, monitoring systems, and similar technologies as examples.
These systems can control water pumps, chemical dosing equipment, valves, motors, electrical equipment, generating equipment, industrial machinery, transportation infrastructure, building controls, compressors, pipeline equipment, sensors, alarms, emergency shutdown systems, and countless other physical processes.
An attacker who compromises the wrong system may therefore be able to do more than steal information.
They may be able to change what a machine does.
That distinction should fundamentally change the way America approaches cybersecurity regulation.
THIS IS NOT A HYPOTHETICAL THREAT:
We do not have to imagine what an attack against industrial control equipment might look like.
Federal investigators have already documented it.
A joint federal cybersecurity advisory updated on July 22, 2026 warned about Iranian-affiliated cyber actors targeting internet-connected operational technology across multiple U.S. critical infrastructure sectors.
Affected sectors included water and wastewater, energy, and government services and facilities.
The attackers targeted programmable logic controllers, commonly called PLCs.
A PLC is essentially an industrial computer designed to control physical processes.
Factories use them.
Water facilities use them.
Energy systems use them.
Building systems use them.
Transportation systems use them.
They are one of the basic building blocks of modern automation.
Federal investigators observed malicious modifications and deletion of PLC logic as well as manipulation of information displayed through Human Machine Interfaces and SCADA systems.
At one U.S. victim, investigators found attackers downloading a malicious project file to a PLC.
The attackers added logic capable of overriding instructions responsible for maintaining safe operating parameters.
Investigators also identified modifications capable of disabling critical shutdown and alarm logic.
That meant equipment could potentially enter an unsafe condition without providing the expected warning to the operators responsible for keeping it safe.
SOURCE:
https://www.ic3.gov/CSA/2026/260722.pdf
Think about the significance of that.
An operator may look at a computer screen and believe a process is functioning normally.
The computer may say everything is fine.
The alarms may remain silent.
But the physical process could be moving toward an unsafe condition because the software responsible for reporting reality has been manipulated.
This is exactly why cybersecurity cannot be separated from engineering.
WATER INFRASTRUCTURE HAS ALREADY BEEN TARGETED:
Water is perhaps the easiest example to understand because nobody can opt out of needing it.
Communities rely on automated systems to move, treat, monitor, and distribute drinking water and wastewater.
The Government Accountability Office has reported that the United States has nearly 170,000 drinking-water and wastewater systems and that those systems are increasingly automated.
GAO warned that a successful cyberattack could potentially result in drinking water containing unsafe levels of bacteria or chemicals.
SOURCE:
https://www.gao.gov/products/gao-24-106744
Foreign governments, cybercriminals, and other actors have already targeted American water infrastructure.
Iran-linked actors previously compromised industrial controllers used by U.S. water and wastewater organizations.
Federal agencies have also warned about exploitation and disruption of operational technology, including configuration wiping, manipulation of industrial systems, disruption of Human Machine Interfaces, operational disruption, and financial losses.
The July 2026 advisory made the danger even clearer by documenting malicious changes to PLC logic governing safe operating parameters and shutdown functions.
These are not movie scenarios.
These attacks are happening.
AND YET FEDERAL CYBERSECURITY REQUIREMENTS REMAIN INCONSISTENT:
This is perhaps the most frustrating part.
The technical community knows these risks exist.
CISA knows.
NIST knows.
DOE knows.
EPA knows.
The FBI knows.
Manufacturers know.
Infrastructure operators know.
Congress knows.
There are frameworks.
There are advisories.
There are implementation guides.
There are webinars.
There are best-practice documents.
There are checklists.
There are voluntary assessments.
There are recommendations.
But a recommendation is not the same thing as an engineering requirement.
GAO has found that water-sector organizations face significant cybersecurity challenges, including limited financial resources, workforce shortages, older technologies, and regulatory gaps.
In May 2026, GAO reported that EPA itself had identified gaps in federal law, including a lack of cybersecurity risk-assessment requirements for wastewater systems and certain drinking-water systems.
EPA also identified limitations in its authority under existing environmental laws to address those gaps.
SOURCE:
https://www.gao.gov/products/gao-26-109159
Pause on that for a moment.
In 2026, after years of ransomware, nation-state targeting, attacks on industrial systems, and repeated federal warnings, we still have portions of critical water infrastructure where basic cybersecurity risk-assessment requirements are not clearly established under federal law.
That is unacceptable.
SOME CRITICAL SYSTEMS ARE DECADES OLD:
There is a common misconception that infrastructure cybersecurity problems happen because somebody forgot to install antivirus software.
Critical-infrastructure security is much more complicated than that.
Industrial environments frequently contain equipment designed to operate for decades.
That is not inherently bad.
Infrastructure should be durable.
The problem arises when the physical lifespan of equipment dramatically exceeds the cybersecurity assumptions under which it was designed.
A piece of equipment may have been designed in a time when remote connectivity was uncommon.
Internet access may never have been expected.
Cloud monitoring did not exist.
Cellular modems were not attached to field equipment.
Ransomware was not a global criminal industry.
Nation-state cyber operations were not targeting municipal infrastructure at today’s scale.
Third-party remote maintenance was far less common.
Multi-factor authentication was not expected.
Zero trust did not exist as a widespread security model.
Modern encrypted management protocols may not have been expected.
Continuous monitoring may never have been part of the design.
Then we connect that equipment to modern networks.
We add remote maintenance.
We add cellular connectivity.
We add cloud dashboards.
We connect vendors.
We connect integrators.
We connect corporate networks.
We connect monitoring platforms.
But the underlying equipment may still operate under assumptions created decades ago.
GAO’s examination of critical federal legacy systems demonstrates just how extreme that lifecycle mismatch can become.
GAO identified 11 federal systems most urgently needing modernization that ranged from approximately 23 to 60 years old.
Eight used legacy programming languages.
Four contained unsupported hardware, software, or operating systems.
Seven had known cybersecurity vulnerabilities.
Eight could not implement the federal government’s zero-trust strategy without modernization.
One agency told GAO that organizational standards governing its system had been created more than two decades earlier and were incompatible with current zero-trust capabilities.
SOURCE:
https://files.gao.gov/reports/GAO-25-107795/index.html
The problem is not that every old system is automatically insecure.
The problem is that age, supportability, cybersecurity architecture, connectivity, and physical consequence are often badly mismatched.
“JUST PATCH IT” IS NOT A SERIOUS INFRASTRUCTURE POLICY:
Anyone who works around operational technology understands that patching is not as simple as updating a home computer.
A control system may need to operate continuously.
A water utility cannot casually shut down treatment because a software vendor released an update Tuesday afternoon.
An electrical system cannot simply reboot whenever convenient.
A manufacturing process may have safety and production implications.
A controller may require vendor certification.
A patch may affect deterministic operation.
Replacement hardware may no longer exist.
A vendor may no longer support the product.
The organization may lack engineers who still understand the system.
Replacing one component may require a substantial outage.
A modern replacement may behave differently when interacting with twenty other legacy systems.
That is exactly why security needs to be designed into the lifecycle of infrastructure.
It cannot be something we discover twenty years after installation.
WHAT CYBER-INFORMED ENGINEERING ACTUALLY MEANS:
Fortunately, the United States government has already developed a framework for addressing this problem.
It is called Cyber-Informed Engineering, or CIE.
The Department of Energy describes Cyber-Informed Engineering as an approach for integrating cybersecurity into the conception, design, development, and operation of physical systems.
Instead of waiting until the system is complete and asking a cybersecurity team to protect whatever engineers already built, CIE considers cyber threats during the engineering process itself.
DOE emphasizes using engineering decisions and controls to reduce the consequences of cyberattacks.
SOURCE:
https://www.energy.gov/ceser/cyber-informed-engineering
Congress previously directed DOE to develop a National Cyber-Informed Engineering Strategy.
NIST has developed a similar philosophy through Systems Security Engineering and its guidance for operational technology.
NIST emphasizes engineering-based approaches for building defensible and survivable systems and addressing security throughout the system lifecycle.
SOURCE:
https://csrc.nist.gov/pubs/sp/800/160/v1/upd2/final
The federal government already understands the engineering philosophy.
The problem is that too much of it remains guidance instead of a legal floor.
THE MOST IMPORTANT QUESTION IS NOT “CAN THEY GET IN?”:
Traditional cybersecurity frequently begins with:
How do we stop the attacker from getting in?
That is an important question.
But Cyber-Informed Engineering forces us to ask another one:
What happens if they do?
That is the question critical infrastructure desperately needs.
Imagine an attacker compromises an operator workstation.
What physical consequences can they cause?
Imagine an attacker obtains administrator credentials.
Can they change safety-critical PLC logic?
Imagine a malicious vendor update reaches the environment.
Can it propagate across multiple facilities?
Imagine remote access is compromised.
Can somebody thousands of miles away directly control field equipment?
Imagine an attacker manipulates the monitoring system.
Would the operator know the values on the screen were false?
Imagine a controller stops functioning.
Does the physical process fail safely?
Imagine ransomware disables the corporate network.
Can operators still run the facility?
Imagine automated systems become completely unavailable.
Is there a safe manual or degraded operating mode?
Imagine the attacker is already inside.
What prevents that cyber incident from becoming a physical disaster?
Those are engineering questions.
WE SHOULD DESIGN AROUND CONSEQUENCES, NOT PERFECT PREVENTION:
Nobody can guarantee that a sophisticated attacker will never compromise a computer.
Passwords get stolen.
Zero-day vulnerabilities exist.
Employees make mistakes.
Vendors get compromised.
Hardware fails.
Software contains bugs.
Insiders exist.
Misconfigurations happen.
Networks change.
The goal of critical-infrastructure security therefore cannot simply be:
“Nobody will ever get in.”
That is not realistic.
The goal should be:
“Even if somebody gets in, we have engineered the system so catastrophic physical consequences remain extremely difficult to cause.”
That means combining cybersecurity with physical engineering.
A compromised workstation should not automatically mean compromised safety systems.
A compromised HMI should not automatically mean unrestricted control of industrial equipment.
A stolen vendor credential should not automatically provide access to every facility.
A malicious PLC program should not automatically defeat every independent protection.
A ransomware infection should not automatically mean an entire community loses essential services.
A cyberattack should not be capable of silently disabling every alarm protecting a physical process.
That is defense in depth applied to the real world.
IF THE COMPUTER LIES, WHAT PROTECTS THE PHYSICAL PROCESS?
This may be the most important question in this entire petition.
Industrial operators make decisions based on information.
Temperature.
Pressure.
Flow.
Level.
Speed.
Voltage.
Current.
Chemical concentration.
Valve state.
Motor state.
Alarm conditions.
Equipment status.
If an attacker can manipulate those readings, an operator can make perfectly reasonable decisions based on false information.
The July 2026 federal advisory documented manipulation of HMI and SCADA information.
That means cyber resilience needs to consider whether operators have independent ways to recognize when digital information conflicts with physical reality.
Depending on the system, that might mean independent instrumentation.
Physical indicators.
Diverse sensors.
Separate alarm systems.
Hardwired safety protections.
Local controls.
Mechanical safeguards.
Independent protective relays.
Fail-safe valve positions.
Pressure-relief systems.
Physical mode switches.
Manual verification.
The exact solution will vary enormously between a water facility, power plant, airport, pipeline, manufacturing plant, and transportation system.
That is why this needs to be an engineering requirement instead of a generic IT checklist.
If the computer lies, something still needs to protect the physical process.
AVIATION DESERVES THE SAME LEVEL OF ATTENTION:
Water is not the only sector where digital systems and physical safety increasingly intersect.
Modern aviation relies on interconnected aircraft systems, ground infrastructure, communications, navigation, airport systems, operational networks, and federal systems.
GAO reported in July 2026 that increasing interconnection between aircraft and ground systems creates additional cybersecurity risk.
GAO also identified shortcomings in federal aviation cybersecurity governance and implementation involving FAA and TSA.
SOURCE:
https://www.gao.gov/products/gao-26-107693
This does not mean America’s aviation system is unsafe.
It means cybersecurity has become inseparable from aviation safety and resilience.
Our regulatory structure needs to treat cybersecurity with the seriousness we already apply to mechanical, electrical, operational, and maintenance safety.
An airline cannot simply decide that airworthiness requirements are optional.
Cyber resilience for systems capable of affecting aviation safety should not be treated as an optional best practice either.
THE VENDOR PROBLEM MUST ALSO BE FIXED:
Infrastructure operators cannot secure equipment if the equipment itself was not designed to be secured.
The July 2026 federal advisory explicitly emphasized manufacturer responsibility for building products that are secure by design and secure by default.
That principle needs teeth.
Basic cybersecurity should not be a premium subscription.
Logging should not be an expensive add-on.
Strong authentication should not require purchasing a special “enterprise security” license.
Security updates should not disappear while equipment remains operational for decades.
Before a utility buys equipment expected to operate for twenty or thirty years, it should know how long the manufacturer intends to support it.
Vendors should provide secure deployment guidance.
They should document remote-access functionality.
They should disclose support lifecycles.
They should maintain reasonable vulnerability-reporting processes.
They should provide secure firmware and software updates.
They should provide ways to verify software and configuration integrity.
Critical-infrastructure buyers should be able to compare products based on cybersecurity and lifecycle support, not simply initial purchase price.
PROCUREMENT IS WHERE WE PREVENT TOMORROW’S LEGACY PROBLEM:
One of the best opportunities to improve security happens before equipment is ever installed.
Procurement.
When an organization purchases equipment expected to operate for decades, cybersecurity requirements should be written into the contract.
Purchasers should know:
How long will the equipment receive security updates?
Does it support modern authentication?
Can administrative access be disabled?
Can unnecessary services be turned off?
Can it operate without direct internet access?
Can logs be exported?
Can configuration changes be detected?
Can firmware integrity be verified?
Can backups be created and restored?
Does the vendor have a vulnerability-disclosure process?
Does the vendor issue security advisories?
What happens when the product reaches end of support?
Can the equipment be securely segmented?
Can remote access be brokered through a secure gateway?
Can the system operate safely when communications fail?
Can critical safety functions remain independent from general network access?
If we do not ask those questions during procurement, we may spend the next thirty years compensating for the answers.
DIRECT INTERNET EXPOSURE OF CRITICAL OT SHOULD BE AN EXTRAORDINARY EXCEPTION:
The 2026 attacks revealed another serious problem.
Industrial controllers managing physical processes were accessible from the public internet.
Federal agencies recommended removing PLCs from direct public internet exposure and placing secure gateways, firewalls, and controlled remote-access systems in front of them.
There may be legitimate operational reasons for remote access.
That is different from directly exposing industrial equipment to the public internet.
Critical operational technology should not be publicly reachable simply because doing so is convenient.
Remote access should be authenticated.
Remote access should be authorized.
Remote access should be logged.
Remote access should be monitored.
Remote access should be segmented.
Remote access should be revocable.
And remote access should be designed around the assumption that credentials may eventually be compromised.
“It is hidden on the internet” is not security.
“Only the vendor knows the IP address” is not security.
“Attackers probably will not find it” is not security.
Internet scanning is automated.
Attackers do not need to know your organization exists before finding an exposed device.
SEGMENTATION SHOULD BE EXPECTED, NOT ASPIRATIONAL:
A compromised email account should not provide a straight path to industrial equipment.
A compromised office laptop should not have unrestricted communication with PLCs.
A guest wireless network should not share unrestricted access with operational technology.
A vendor should not have persistent access to everything simply because that vendor services one component.
An accounting system should not communicate directly with a safety controller without a legitimate engineering reason.
Segmentation is not about creating a diagram with colorful boxes separated by firewall icons.
It means actually controlling which systems can communicate, why they can communicate, and what happens when one part of the network becomes untrusted.
SAFETY SYSTEMS SHOULD NOT DEPEND ENTIRELY ON CYBERSECURITY WORKING PERFECTLY:
If a cyber compromise can create a dangerous physical condition, independent protections should exist where technically and economically reasonable.
Depending on the system, that may include mechanical limits, independent protective relays, hardwired emergency shutdowns, independent process alarms, local physical controls, separate safety systems, physical mode switches, fail-safe valve positions, pressure-relief equipment, manual operating capability, independent sensors, or other safeguards.
The exact solution will vary by sector.
That is precisely why Cyber-Informed Engineering matters.
Security decisions should be informed by the physical consequences of failure.
MANUAL OPERATION IS NOT OBSOLETE:
Automation is valuable.
Automation improves efficiency, safety, consistency, and reliability.
But critical services also need to understand what happens when automation disappears.
GAO has documented ransomware incidents that forced affected water systems to temporarily operate manually.
SOURCE:
https://www.gao.gov/products/gao-26-109159
That raises important questions.
Can operators still control the process manually?
Do they know how?
Are procedures available offline?
Can they communicate without the primary IT network?
Can they determine actual physical conditions?
Do they have enough staffing?
Can they restore known-good configurations?
Are backups actually available offline?
Have those backups ever been tested?
When was the last time the organization practiced operating without its normal systems?
A manual fallback that exists only in a binder nobody has opened for ten years is not resilience.
BACKUPS MUST INCLUDE INDUSTRIAL LOGIC AND CONFIGURATION:
When people hear “backup,” they often think about documents and databases.
Critical infrastructure also needs recoverable copies of PLC logic, device configurations, HMI configurations, SCADA configurations, network-device configurations, firmware, engineering workstation data, critical documentation, and other information required to rebuild operational systems.
The July 2026 federal advisory specifically recommended maintaining backups of PLC logic and configurations, storing those backups offline, and verifying that restored backups do not contain malicious logic.
SOURCE:
https://www.ic3.gov/CSA/2026/260722.pdf
That last part is critical.
Restoring a compromised backup simply restores the attack.
Resilience requires trusted recovery.
WE NEED TO STOP CONFUSING COMPLIANCE WITH SECURITY:
A company can pass an audit and still be insecure.
A utility can complete a questionnaire and still have an internet-facing PLC.
An organization can possess an incident-response plan nobody has ever practiced.
A vendor can claim its product is secure while shipping unnecessary services enabled.
A network diagram can show segmentation that does not exist in practice.
A backup policy can exist while nobody knows whether the backups actually restore.
Cyber-Informed Engineering must not become another binder.
The goal should be measurable engineering outcomes.
Can an attacker manipulate the physical process?
Can an attacker defeat safety controls?
Can an attacker conceal what they are doing?
Can compromise of one system spread to another?
Can the organization safely operate when systems fail?
Can operators detect abnormal physical conditions independently?
Can the organization recover a trusted configuration?
Can remote access be immediately revoked?
Are critical protections sufficiently independent that one compromise does not defeat everything?
Those questions matter more than whether somebody checked a box.
THIS PETITION IS NOT ASKING EVERY SMALL UTILITY TO BECOME THE NSA:
Small water utilities, rural electric organizations, municipalities, public institutions, and other infrastructure operators frequently have limited budgets.
Some may have only a handful of employees.
They may not have dedicated cybersecurity staff.
They may already struggle to hire electricians, engineers, mechanics, and plant operators.
Cybersecurity mandates without funding could therefore create an impossible situation.
That would be bad policy.
Congress should pair meaningful cybersecurity requirements with grants, technical assistance, shared cybersecurity services, modernization funding, affordable training, workforce-development programs, regional assistance, testing resources, procurement support, and dedicated funding to replace equipment that cannot reasonably be secured.
GAO has repeatedly identified limited financial resources, workforce shortages, and older technologies as challenges in water-sector cybersecurity.
SOURCE:
https://www.gao.gov/products/gao-26-109159
The answer should not be to lower the safety standard.
The answer should be to help communities reach it.
REQUIREMENTS SHOULD BE BASED ON CONSEQUENCE:
A Cyber-Informed Engineering mandate should not treat every device identically.
A computer controlling decorative landscaping lights does not carry the same consequence as a controller regulating chemical treatment at a drinking-water facility.
A network printer does not carry the same risk as an emergency shutdown system.
Requirements should therefore be risk-informed and consequence-based.
The more severe the potential physical consequence, the stronger the required engineering protections should become.
That is already how mature safety engineering works.
Cybersecurity should follow the same logic.
LEGACY EQUIPMENT NEEDS A PATH FORWARD, NOT AN OVERNIGHT BAN:
America cannot replace every legacy PLC, relay, industrial computer, transportation system, and government application tomorrow.
Attempting to do so could itself create unacceptable operational risk.
But there is an enormous difference between:
“We cannot replace this today.”
and:
“We have no plan to replace this.”
Organizations operating high-consequence legacy systems should know what equipment they have.
They should know how old it is.
They should know whether it remains supported.
They should know what vulnerabilities affect it.
They should know whether those vulnerabilities can be mitigated.
They should understand how the equipment is connected.
They should understand what physical consequences compromise could create.
They should know what compensating controls exist.
They should know when replacement is expected.
They should know what replacement will cost.
And they should understand what happens if the equipment fails before then.
Modernization should be planned, risk-based, funded, and measurable.
GAO found that even among 11 critical federal legacy systems considered among those most urgently needing modernization, only three had modernization plans containing all key elements reviewed by GAO.
Six had incomplete plans.
Two had no modernization plans.
SOURCE:
https://files.gao.gov/reports/GAO-25-107795/index.html
If we cannot consistently create modernization plans for some of the government’s most critical legacy systems, we should not pretend this problem will fix itself.
WHAT WE ARE ASKING CONGRESS TO DO:
We call on Congress to establish Cyber-Informed Engineering, secure-by-design principles, and consequence-based cyber resilience as legal minimums for federally regulated critical infrastructure and other high-consequence cyber-physical systems.
Legislation should direct CISA, NIST, the Department of Energy, EPA, Department of Transportation, TSA, FAA, and other appropriate regulators and sector agencies to establish enforceable, sector-specific requirements.
At minimum, legislation should include the following:
DEMAND 01: REQUIRE CYBER-INFORMED ENGINEERING FOR NEW CRITICAL INFRASTRUCTURE.
Cybersecurity should be incorporated during concept development, engineering, design, procurement, construction, commissioning, operation, maintenance, modernization, and eventual decommissioning.
New infrastructure should not become tomorrow’s legacy-security crisis.
DEMAND 02: REQUIRE CONSEQUENCE-BASED CYBER RISK ANALYSIS.
Operators of high-consequence systems should identify the worst credible physical outcomes of cyber compromise and demonstrate reasonable engineering safeguards intended to prevent, limit, detect, or safely recover from those outcomes.
The purpose should not be predicting every possible attacker.
The purpose should be limiting what attackers can physically accomplish.
DEMAND 03: REQUIRE SECURE-BY-DESIGN AND SECURE-BY-DEFAULT PROCUREMENT.
Equipment used in critical infrastructure should support reasonable modern security capabilities appropriate to its use.
Essential security features should not be disabled by default or hidden behind premium licensing tiers.
Purchasers should know the expected security-support lifecycle before buying equipment expected to remain operational for decades.
DEMAND 04: ESTABLISH LIFECYCLE SECURITY REQUIREMENTS.
Manufacturers and purchasers should plan for security updates, vulnerability disclosure, support periods, replacement components, configuration integrity, authentication, logging, secure updates, end-of-support notifications, migration, and eventual decommissioning.
DEMAND 05: REQUIRE ACCURATE INVENTORIES OF CRITICAL DIGITAL ASSETS.
Organizations cannot protect systems they do not know exist.
Operators should maintain accurate inventories of high-consequence operational technology, including hardware, software, firmware, ownership, support status, connectivity, and critical dependencies.
DEMAND 06: RESTRICT DIRECT INTERNET EXPOSURE OF OPERATIONAL TECHNOLOGY.
Direct public internet access to safety-critical PLCs, HMIs, SCADA systems, and similar equipment should be prohibited except where a documented engineering justification exists and equivalent protective controls are implemented.
Remote access should normally be mediated through controlled infrastructure and protected with strong authentication, authorization, logging, monitoring, and segmentation.
DEMAND 07: REQUIRE MEANINGFUL NETWORK SEGMENTATION.
Critical operational systems should be separated from ordinary corporate networks and unrelated operational systems according to risk and function.
Access between zones should be explicitly authorized and technically enforced.
DEMAND 08: REQUIRE STRONG AUTHENTICATION FOR REMOTE ACCESS.
Default passwords should be prohibited.
Shared credentials should be minimized.
Remote administrative access should use strong authentication and multi-factor authentication where technically feasible.
Legacy devices unable to support modern authentication should be protected through compensating controls.
DEMAND 09: PROTECT SAFETY FUNCTIONS FROM ORDINARY CYBER COMPROMISE.
Where a cyberattack could create dangerous physical consequences, independent or diverse protections should be used where reasonably practical.
Safety-critical shutdowns and protective functions should not unnecessarily depend entirely upon the same systems an attacker is attempting to manipulate.
DEMAND 10: REQUIRE TRUSTED RECOVERY CAPABILITY.
Critical operators should maintain secure, tested, and appropriately isolated backups of configurations, operational logic, critical software, and documentation.
Recovery exercises should demonstrate the ability to restore known-good systems.
DEMAND 11: REQUIRE DEGRADED AND MANUAL OPERATING PLANS.
Critical services should identify which functions must continue during loss of normal digital systems and establish safe alternatives where technically possible.
Employees expected to perform those procedures should periodically practice them.
DEMAND 12: REQUIRE CYBERSECURITY EXERCISES INVOLVING ENGINEERS AND OPERATORS.
Cybersecurity should not live entirely inside the IT department.
Exercises should involve cybersecurity teams, control engineers, operators, electricians, maintenance personnel, emergency managers, leadership, vendors where appropriate, and safety personnel.
A cyberattack against operational technology is a multidisciplinary engineering emergency.
DEMAND 13: REQUIRE CONFIGURATION-INTEGRITY MONITORING FOR HIGH-CONSEQUENCE CONTROLLERS.
Organizations should have a reasonable means of identifying unauthorized modifications to critical PLC logic, device configurations, and safety settings.
Recent attacks demonstrate exactly why this matters.
DEMAND 14: ESTABLISH MINIMUM LOGGING REQUIREMENTS.
Organizations should retain the information necessary to investigate unauthorized access and changes to critical systems.
Basic cybersecurity logging should not be treated as an optional luxury.
DEMAND 15: REQUIRE VULNERABILITY-MANAGEMENT PROGRAMS APPROPRIATE TO OPERATIONAL TECHNOLOGY.
This does not mean blindly installing every patch the moment it appears.
OT patching must consider safety and availability.
But organizations should know which vulnerabilities exist, determine their risk, apply patches when appropriate, implement compensating controls when patches are not possible, and document unresolved high-risk conditions.
DEMAND 16: REQUIRE FUNDED MODERNIZATION PLANS FOR UNSUPPORTABLE LEGACY SYSTEMS.
High-consequence systems that cannot reasonably meet minimum cybersecurity requirements should have documented replacement or modernization plans.
Exceptions should be time-limited, documented, reviewed, and accompanied by appropriate compensating controls.
DEMAND 17: TIE FEDERAL INFRASTRUCTURE FUNDING TO SECURE ENGINEERING.
Federal taxpayers should not finance new infrastructure that ignores well-established cybersecurity principles.
Projects receiving substantial federal infrastructure funding should demonstrate compliance with applicable Cyber-Informed Engineering requirements.
DEMAND 18: PROVIDE SUBSTANTIAL ASSISTANCE FOR SMALL AND RURAL OPERATORS.
Congress should establish dedicated grants, shared services, technical assistance, modernization programs, and cybersecurity support so minimum standards do not disproportionately punish small communities.
DEMAND 19: ESTABLISH MEANINGFUL VENDOR RESPONSIBILITY.
Manufacturers selling long-lived equipment into critical-infrastructure environments should bear reasonable responsibility for the cybersecurity of their products.
Manufacturers should clearly disclose support lifecycles and known security limitations.
Basic security capabilities should not be optional luxury features.
DEMAND 20: HARMONIZE REQUIREMENTS ACROSS FEDERAL REGULATORS.
Organizations should not have to satisfy a maze of contradictory cybersecurity frameworks.
Congress should require federal agencies to coordinate baseline expectations while allowing sector-specific requirements where physical risks differ.
The goal should be one coherent minimum adapted intelligently to each sector.
THIS SHOULD BE A FLOOR, NOT A CEILING:
These requirements should represent the minimum acceptable level of care.
Organizations facing greater risks should do more.
Companies should remain free to exceed the minimum.
Engineers should remain free to develop better solutions.
Standards should evolve as technology and threats change.
The law should establish the basic principle that organizations operating systems capable of causing large-scale physical or societal harm have a responsibility to engineer cyber risk into those systems from the beginning.
WE ALREADY REGULATE PHYSICAL SAFETY:
None of this should be considered radical.
Electrical installations have codes.
Boilers have safety requirements.
Aircraft have airworthiness requirements.
Workplaces have safety rules.
Pressure vessels have engineering standards.
Buildings have fire codes.
Vehicles have safety requirements.
Industrial equipment has protective systems.
Drinking water has quality requirements.
Nobody seriously argues that every individual company should simply decide for itself whether electrical grounding is worthwhile.
We learned through experience that when failures can kill people or harm entire communities, society establishes minimum engineering standards.
Software now participates in controlling those same physical systems.
Cybersecurity should not be fundamentally different.
CYBERSECURITY IS NOW PART OF ENGINEERING:
For years, many organizations treated cybersecurity primarily as an IT function.
That made sense when the primary concern was protecting email, documents, business applications, and databases.
But the world changed.
Computers regulate physical processes.
Networks connect buildings.
Software controls industrial machinery.
Digital systems coordinate transportation.
Cloud services interact with infrastructure.
Cellular modems connect remote equipment.
Vendors remotely service machinery.
Sensors feed automated decisions.
The boundary between cybersecurity and physical engineering is disappearing.
The law needs to recognize that reality.
WE SHOULD NOT NEED A CATASTROPHE BEFORE ACTING:
Cybersecurity regulation has a bad habit of arriving after disaster.
A massive incident happens.
Congress holds hearings.
Officials ask why nobody acted.
Reports are written.
Recommendations are issued.
Organizations promise improvement.
Everyone moves on.
Then another incident happens.
We do not need to repeat that cycle with cyber-physical infrastructure.
Federal investigators have already documented attackers targeting American industrial controllers.
They have documented operational disruption.
They have documented altered industrial logic.
They have documented manipulation of operator displays.
They have documented modifications affecting safe operating parameters.
They have documented disabled shutdown and alarm logic.
What exactly are we waiting for?
A major municipal water outage?
Contaminated drinking water?
A widespread electrical disruption?
Damaged industrial equipment?
A pipeline failure?
A transportation emergency?
Loss of life?
At some point, saying “we need more study” becomes an excuse for accepting risks we already understand.
THIS IS NOT ABOUT FEAR:
This petition is not claiming that America’s infrastructure is about to collapse.
It is not claiming every water utility is insecure.
It is not claiming every airline has dangerous systems.
It is not claiming every old PLC is vulnerable.
It is not claiming cybersecurity can eliminate every risk.
Engineering rarely eliminates risk entirely.
The goal is to understand risk and design systems so failure does not become catastrophe.
That is what engineers already do with fire, electricity, pressure, mechanical failure, structural loads, chemical hazards, weather, human error, and countless other threats.
Cyber threats now belong on that list.
THIS IS A NATIONAL-SECURITY ISSUE:
Critical infrastructure does not need to be physically destroyed for an adversary to achieve its objectives.
Disruption itself can have enormous consequences.
Interrupt water.
Interrupt power.
Interrupt transportation.
Interrupt communications.
Interrupt fuel distribution.
Interrupt government services.
Force operators into emergency procedures.
Create uncertainty about whether digital systems can be trusted.
Then multiply those effects across communities.
Cyber-Informed Engineering makes those attacks more difficult by limiting the physical consequences an attacker can create even after achieving some level of digital access.
THIS IS ALSO AN ECONOMIC-SECURITY ISSUE:
Critical-infrastructure outages cascade.
A water outage affects hospitals, restaurants, schools, factories, homes, fire departments, data centers, businesses, agriculture, and countless other services.
A transportation disruption affects supply chains.
An energy disruption affects almost everything.
A communications disruption affects emergency response.
The cybersecurity of infrastructure cannot therefore be measured only by the cost of protecting the individual operator.
We need to consider the potential cost imposed on everyone who depends on that infrastructure.
WE ALREADY KNOW WHAT TO DO:
This is not a situation where Congress needs to invent cybersecurity from scratch.
DOE already has Cyber-Informed Engineering.
NIST already publishes operational-technology cybersecurity guidance.
CISA already publishes cross-sector cybersecurity performance goals.
EPA already maintains water-sector cybersecurity resources.
Federal agencies already issue detailed industrial-control-system advisories.
Engineers already know how to conduct hazard and consequence analysis.
Cybersecurity professionals already know how to segment networks, manage identity, monitor systems, manage vulnerabilities, and respond to incidents.
Manufacturers already know how to build more secure products.
What is missing is a consistent expectation that these principles must be applied where cyber compromise can create serious physical consequences.
MAKE SECURE ENGINEERING THE LEGAL BARE MINIMUM:
The question should no longer be:
“Should this utility voluntarily consider cybersecurity?”
The question should be:
“What cybersecurity and engineering controls are necessary given the physical consequences of this system?”
The question should no longer be:
“Does the vendor offer security features?”
It should be:
“Why would critical-infrastructure equipment be sold without basic security features?”
The question should no longer be:
“Can we afford cybersecurity?”
It should be:
“Can the country afford infrastructure whose safety depends on attackers never gaining access?”
The question should no longer be:
“Has anyone attacked this specific system before?”
It should be:
“What happens when somebody eventually tries?”
Because attackers are trying.
We have the advisories.
We have the investigations.
We have the GAO reports.
We have the frameworks.
We have the engineering knowledge.
Now we need enforceable minimum standards.
OUR REQUEST TO CONGRESS:
We call on the United States Congress to pass legislation establishing Cyber-Informed Engineering and consequence-based cyber resilience as mandatory minimum principles for U.S. critical infrastructure and other high-consequence cyber-physical systems.
Congress should provide sector regulators with the authority necessary to implement enforceable cybersecurity requirements.
Congress should require federal agencies to harmonize those requirements.
Congress should provide funding and technical assistance for small and rural infrastructure operators.
Congress should establish secure-by-design expectations for critical-infrastructure vendors.
Congress should require lifecycle planning for equipment expected to remain in service for decades.
Congress should require modernization plans for systems that cannot reasonably meet modern security requirements.
Congress should tie substantial federal infrastructure spending to secure engineering practices.
And Congress should ensure that infrastructure built with taxpayer money today does not become the preventable cybersecurity crisis Americans inherit twenty or thirty years from now.
“TRUST ME, BRO” IS NOT A SAFETY SYSTEM:
If I wired a building and told an inspector:
“Do not worry, nothing should ever short circuit,”
they would rightfully reject that logic.
If an engineer designed a pressure system and said:
“We do not need relief protection because the pressure should never exceed the limit,”
nobody would accept it.
If an airline said:
“We do not need redundant systems because the primary one probably will not fail,”
we would never tolerate that.
But somehow when software controls physical infrastructure, organizations are still too often allowed to rely on assumptions that amount to:
Nobody will find it.
Nobody will compromise it.
Nobody will steal the password.
Nobody will change the configuration.
Nobody will compromise the vendor.
Nobody will reach the OT network.
Nobody will manipulate the PLC.
Nobody will spoof the sensor.
Nobody will disable the alarm.
Nobody will compromise the HMI.
Nobody will exploit the legacy system.
Nobody will attack us because we are too small.
Trust me, bro.
That is not cybersecurity.
That is not engineering.
And when the systems involved provide water, electricity, transportation, communications, government services, or other infrastructure millions of Americans depend upon, it is not an acceptable national policy.
America knows how to engineer resilient systems.
It is time to require that we do it.
Protect America’s critical infrastructure from cyberattacks.
Make Cyber-Informed Engineering the legal minimum before the next cyberattack becomes a physical disaster.
SOURCES:
SOURCE 01: FBI, CISA, NSA, EPA, Department of Energy, U.S. Cyber Command, and Department of the Treasury joint cybersecurity advisory regarding Iranian-affiliated actors targeting programmable logic controllers across U.S. critical infrastructure, updated July 22, 2026.
https://www.ic3.gov/CSA/2026/260722.pdf
SOURCE 02: U.S. Government Accountability Office, “Critical Infrastructure Protection: Actions Needed to Address Persistent Cybersecurity Threats to the Water and Wastewater Sector,” May 21, 2026.
https://www.gao.gov/products/gao-26-109159
SOURCE 03: U.S. Government Accountability Office, “Critical Infrastructure Protection: EPA Urgently Needs a Strategy to Address Cybersecurity Risks to Water and Wastewater Systems,” August 1, 2024.
https://www.gao.gov/products/gao-24-106744
SOURCE 04: U.S. Environmental Protection Agency, FBI, CISA, and NSA cybersecurity advisory regarding Iranian-affiliated attacks affecting water systems and other U.S. critical infrastructure, April 2026.
SOURCE 05: U.S. Government Accountability Office, “Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems,” July 2025.
https://files.gao.gov/reports/GAO-25-107795/index.html
SOURCE 06: U.S. Government Accountability Office, “Aviation Cybersecurity: FAA and TSA Are Collaborating on Cybersecurity but Need to Address Key Shortfalls,” July 16, 2026.
https://www.gao.gov/products/gao-26-107693
SOURCE 07: U.S. Department of Energy, Cyber-Informed Engineering.
https://www.energy.gov/ceser/cyber-informed-engineering
SOURCE 08: National Institute of Standards and Technology, Guide to Operational Technology Security.
SOURCE 09: National Institute of Standards and Technology, Systems Security Engineering, SP 800-160.
13
The Issue
PROTECT AMERICA’S CRITICAL INFRASTRUCTURE FROM CYBERATTACKS
Make Cyber-Informed Engineering the legal minimum for systems Americans depend on every day.
TL;DR:
America increasingly runs the physical world through computers. Drinking-water systems, power infrastructure, airports, transportation networks, pipelines, communications systems, government facilities, factories, and other essential services depend on software, industrial controllers, remote access, sensors, and network-connected equipment.
But too much of that infrastructure is still secured around assumptions that amount to “trust me, bro.” Trust that nobody finds the device. Trust that credentials are never stolen. Trust that the vendor is never compromised. Trust that a private network stays private. Trust that nobody changes the controller logic. Trust that operators can always believe what the computer tells them.
Recent attacks show why that is unacceptable. In July 2026, a joint federal advisory from the FBI, CISA, NSA, EPA, Department of Energy, U.S. Cyber Command, and Department of the Treasury documented Iranian-affiliated attackers targeting programmable logic controllers across U.S. critical infrastructure. Investigators found malicious changes capable of overriding instructions that maintained safe operating parameters and disabling critical alarm and shutdown logic.
That means a cyberattack can move beyond stealing data and begin affecting the physical world. An attacker may be able to manipulate pumps, valves, machinery, electrical equipment, safety controls, alarms, or the information operators rely on to make decisions.
At the same time, the Government Accountability Office has documented critical federal systems approximately 23 to 60 years old. Of 11 systems GAO identified as most urgently needing modernization, seven had known cybersecurity vulnerabilities, four contained unsupported hardware or software, and eight could not implement the federal government’s zero-trust strategy without modernization. One agency said standards governing its system were more than two decades old and incompatible with modern zero-trust capabilities.
We already know how to engineer systems around physical failure. We use circuit breakers because electrical faults happen. We use pressure relief because equipment can exceed safe limits. We use emergency stops, interlocks, redundancy, alarms, and independent safety systems because engineers do not assume everything will always work perfectly.
Cybersecurity needs the same philosophy.
The Department of Energy already calls this Cyber-Informed Engineering, or CIE. Instead of treating cybersecurity as something added after a system has already been designed, CIE asks engineers to consider cyber threats and their physical consequences during design, procurement, operation, modernization, and eventual replacement.
Congress should make Cyber-Informed Engineering, secure-by-design principles, and consequence-based cyber resilience a legal minimum for critical infrastructure and other high-consequence cyber-physical systems.
This should include secure procurement, stronger vendor responsibility, meaningful network segmentation, controlled remote access, protection against unauthorized controller changes, independent safety mechanisms where appropriate, trusted backups, manual and degraded operating capability, lifecycle security planning, modernization requirements for systems that cannot reasonably be secured, and funding to help small and rural operators meet those requirements.
This is not about forcing every rural water utility to build an NSA-level security operation. Requirements should be proportional to consequence, and Congress should fund the technical assistance and modernization needed to help smaller operators comply.
The goal is simple:
If the computer is compromised, the physical system should still be engineered to remain as safe and resilient as reasonably possible.
Because “trust me, bro” is not a security architecture.
And it definitely is not a safety system.
WHY I CARE ABOUT THIS:
I work professionally as a Senior Cybersecurity Engineer. Before moving professionally into cybersecurity, I also worked as an electrician.
Those two backgrounds greatly influence how I look at this issue.
Cybersecurity teaches you to think about adversaries.
How could somebody gain access?
What happens if credentials are stolen?
What if an employee clicks the wrong link?
What if a vendor is compromised?
What if a zero-day vulnerability appears?
What if an attacker gets inside something we assumed was protected?
Electrical work and engineering teach a different but complementary lesson:
Failure happens, so systems must be designed around what happens when it does.
Circuit breakers exist because we do not simply trust that a short circuit will never happen.
Ground-fault protection exists because we do not assume electricity will always remain where it was intended to remain.
Emergency stops exist because machines can malfunction.
Pressure relief exists because equipment can exceed safe limits.
Safety interlocks exist because humans and machines make mistakes.
Redundancy exists because components fail.
Engineers do not normally design a physical safety system by saying:
“Nobody will ever do the wrong thing, so we do not need to account for it.”
Yet when software enters the equation, that philosophy too often disappears.
Suddenly we hear:
“The network is private.”
“Only employees know the password.”
“That system is not supposed to be accessible from the internet.”
“The vendor handles that.”
“Nobody knows how the old system works, so we do not touch it.”
“We will replace it eventually.”
“It has always worked.”
“We have a firewall.”
“We have never been attacked before.”
In cybersecurity terms, this amounts to:
Trust me, bro.
And “trust me, bro” is not an engineering control.
WHEN SOFTWARE CONTROLS THE PHYSICAL WORLD, CYBERSECURITY BECOMES PUBLIC SAFETY:
There is an enormous difference between compromising an ordinary computer and compromising operational technology.
A compromised laptop may result in stolen data, ransomware, fraud, downtime, or privacy violations.
Those consequences can be severe.
But when software controls physical equipment, cyber compromise can become a physical event.
Operational Technology, commonly called OT, includes programmable systems and devices that interact with the physical environment.
NIST identifies industrial control systems, transportation systems, building automation systems, physical-access systems, monitoring systems, and similar technologies as examples.
These systems can control water pumps, chemical dosing equipment, valves, motors, electrical equipment, generating equipment, industrial machinery, transportation infrastructure, building controls, compressors, pipeline equipment, sensors, alarms, emergency shutdown systems, and countless other physical processes.
An attacker who compromises the wrong system may therefore be able to do more than steal information.
They may be able to change what a machine does.
That distinction should fundamentally change the way America approaches cybersecurity regulation.
THIS IS NOT A HYPOTHETICAL THREAT:
We do not have to imagine what an attack against industrial control equipment might look like.
Federal investigators have already documented it.
A joint federal cybersecurity advisory updated on July 22, 2026 warned about Iranian-affiliated cyber actors targeting internet-connected operational technology across multiple U.S. critical infrastructure sectors.
Affected sectors included water and wastewater, energy, and government services and facilities.
The attackers targeted programmable logic controllers, commonly called PLCs.
A PLC is essentially an industrial computer designed to control physical processes.
Factories use them.
Water facilities use them.
Energy systems use them.
Building systems use them.
Transportation systems use them.
They are one of the basic building blocks of modern automation.
Federal investigators observed malicious modifications and deletion of PLC logic as well as manipulation of information displayed through Human Machine Interfaces and SCADA systems.
At one U.S. victim, investigators found attackers downloading a malicious project file to a PLC.
The attackers added logic capable of overriding instructions responsible for maintaining safe operating parameters.
Investigators also identified modifications capable of disabling critical shutdown and alarm logic.
That meant equipment could potentially enter an unsafe condition without providing the expected warning to the operators responsible for keeping it safe.
SOURCE:
https://www.ic3.gov/CSA/2026/260722.pdf
Think about the significance of that.
An operator may look at a computer screen and believe a process is functioning normally.
The computer may say everything is fine.
The alarms may remain silent.
But the physical process could be moving toward an unsafe condition because the software responsible for reporting reality has been manipulated.
This is exactly why cybersecurity cannot be separated from engineering.
WATER INFRASTRUCTURE HAS ALREADY BEEN TARGETED:
Water is perhaps the easiest example to understand because nobody can opt out of needing it.
Communities rely on automated systems to move, treat, monitor, and distribute drinking water and wastewater.
The Government Accountability Office has reported that the United States has nearly 170,000 drinking-water and wastewater systems and that those systems are increasingly automated.
GAO warned that a successful cyberattack could potentially result in drinking water containing unsafe levels of bacteria or chemicals.
SOURCE:
https://www.gao.gov/products/gao-24-106744
Foreign governments, cybercriminals, and other actors have already targeted American water infrastructure.
Iran-linked actors previously compromised industrial controllers used by U.S. water and wastewater organizations.
Federal agencies have also warned about exploitation and disruption of operational technology, including configuration wiping, manipulation of industrial systems, disruption of Human Machine Interfaces, operational disruption, and financial losses.
The July 2026 advisory made the danger even clearer by documenting malicious changes to PLC logic governing safe operating parameters and shutdown functions.
These are not movie scenarios.
These attacks are happening.
AND YET FEDERAL CYBERSECURITY REQUIREMENTS REMAIN INCONSISTENT:
This is perhaps the most frustrating part.
The technical community knows these risks exist.
CISA knows.
NIST knows.
DOE knows.
EPA knows.
The FBI knows.
Manufacturers know.
Infrastructure operators know.
Congress knows.
There are frameworks.
There are advisories.
There are implementation guides.
There are webinars.
There are best-practice documents.
There are checklists.
There are voluntary assessments.
There are recommendations.
But a recommendation is not the same thing as an engineering requirement.
GAO has found that water-sector organizations face significant cybersecurity challenges, including limited financial resources, workforce shortages, older technologies, and regulatory gaps.
In May 2026, GAO reported that EPA itself had identified gaps in federal law, including a lack of cybersecurity risk-assessment requirements for wastewater systems and certain drinking-water systems.
EPA also identified limitations in its authority under existing environmental laws to address those gaps.
SOURCE:
https://www.gao.gov/products/gao-26-109159
Pause on that for a moment.
In 2026, after years of ransomware, nation-state targeting, attacks on industrial systems, and repeated federal warnings, we still have portions of critical water infrastructure where basic cybersecurity risk-assessment requirements are not clearly established under federal law.
That is unacceptable.
SOME CRITICAL SYSTEMS ARE DECADES OLD:
There is a common misconception that infrastructure cybersecurity problems happen because somebody forgot to install antivirus software.
Critical-infrastructure security is much more complicated than that.
Industrial environments frequently contain equipment designed to operate for decades.
That is not inherently bad.
Infrastructure should be durable.
The problem arises when the physical lifespan of equipment dramatically exceeds the cybersecurity assumptions under which it was designed.
A piece of equipment may have been designed in a time when remote connectivity was uncommon.
Internet access may never have been expected.
Cloud monitoring did not exist.
Cellular modems were not attached to field equipment.
Ransomware was not a global criminal industry.
Nation-state cyber operations were not targeting municipal infrastructure at today’s scale.
Third-party remote maintenance was far less common.
Multi-factor authentication was not expected.
Zero trust did not exist as a widespread security model.
Modern encrypted management protocols may not have been expected.
Continuous monitoring may never have been part of the design.
Then we connect that equipment to modern networks.
We add remote maintenance.
We add cellular connectivity.
We add cloud dashboards.
We connect vendors.
We connect integrators.
We connect corporate networks.
We connect monitoring platforms.
But the underlying equipment may still operate under assumptions created decades ago.
GAO’s examination of critical federal legacy systems demonstrates just how extreme that lifecycle mismatch can become.
GAO identified 11 federal systems most urgently needing modernization that ranged from approximately 23 to 60 years old.
Eight used legacy programming languages.
Four contained unsupported hardware, software, or operating systems.
Seven had known cybersecurity vulnerabilities.
Eight could not implement the federal government’s zero-trust strategy without modernization.
One agency told GAO that organizational standards governing its system had been created more than two decades earlier and were incompatible with current zero-trust capabilities.
SOURCE:
https://files.gao.gov/reports/GAO-25-107795/index.html
The problem is not that every old system is automatically insecure.
The problem is that age, supportability, cybersecurity architecture, connectivity, and physical consequence are often badly mismatched.
“JUST PATCH IT” IS NOT A SERIOUS INFRASTRUCTURE POLICY:
Anyone who works around operational technology understands that patching is not as simple as updating a home computer.
A control system may need to operate continuously.
A water utility cannot casually shut down treatment because a software vendor released an update Tuesday afternoon.
An electrical system cannot simply reboot whenever convenient.
A manufacturing process may have safety and production implications.
A controller may require vendor certification.
A patch may affect deterministic operation.
Replacement hardware may no longer exist.
A vendor may no longer support the product.
The organization may lack engineers who still understand the system.
Replacing one component may require a substantial outage.
A modern replacement may behave differently when interacting with twenty other legacy systems.
That is exactly why security needs to be designed into the lifecycle of infrastructure.
It cannot be something we discover twenty years after installation.
WHAT CYBER-INFORMED ENGINEERING ACTUALLY MEANS:
Fortunately, the United States government has already developed a framework for addressing this problem.
It is called Cyber-Informed Engineering, or CIE.
The Department of Energy describes Cyber-Informed Engineering as an approach for integrating cybersecurity into the conception, design, development, and operation of physical systems.
Instead of waiting until the system is complete and asking a cybersecurity team to protect whatever engineers already built, CIE considers cyber threats during the engineering process itself.
DOE emphasizes using engineering decisions and controls to reduce the consequences of cyberattacks.
SOURCE:
https://www.energy.gov/ceser/cyber-informed-engineering
Congress previously directed DOE to develop a National Cyber-Informed Engineering Strategy.
NIST has developed a similar philosophy through Systems Security Engineering and its guidance for operational technology.
NIST emphasizes engineering-based approaches for building defensible and survivable systems and addressing security throughout the system lifecycle.
SOURCE:
https://csrc.nist.gov/pubs/sp/800/160/v1/upd2/final
The federal government already understands the engineering philosophy.
The problem is that too much of it remains guidance instead of a legal floor.
THE MOST IMPORTANT QUESTION IS NOT “CAN THEY GET IN?”:
Traditional cybersecurity frequently begins with:
How do we stop the attacker from getting in?
That is an important question.
But Cyber-Informed Engineering forces us to ask another one:
What happens if they do?
That is the question critical infrastructure desperately needs.
Imagine an attacker compromises an operator workstation.
What physical consequences can they cause?
Imagine an attacker obtains administrator credentials.
Can they change safety-critical PLC logic?
Imagine a malicious vendor update reaches the environment.
Can it propagate across multiple facilities?
Imagine remote access is compromised.
Can somebody thousands of miles away directly control field equipment?
Imagine an attacker manipulates the monitoring system.
Would the operator know the values on the screen were false?
Imagine a controller stops functioning.
Does the physical process fail safely?
Imagine ransomware disables the corporate network.
Can operators still run the facility?
Imagine automated systems become completely unavailable.
Is there a safe manual or degraded operating mode?
Imagine the attacker is already inside.
What prevents that cyber incident from becoming a physical disaster?
Those are engineering questions.
WE SHOULD DESIGN AROUND CONSEQUENCES, NOT PERFECT PREVENTION:
Nobody can guarantee that a sophisticated attacker will never compromise a computer.
Passwords get stolen.
Zero-day vulnerabilities exist.
Employees make mistakes.
Vendors get compromised.
Hardware fails.
Software contains bugs.
Insiders exist.
Misconfigurations happen.
Networks change.
The goal of critical-infrastructure security therefore cannot simply be:
“Nobody will ever get in.”
That is not realistic.
The goal should be:
“Even if somebody gets in, we have engineered the system so catastrophic physical consequences remain extremely difficult to cause.”
That means combining cybersecurity with physical engineering.
A compromised workstation should not automatically mean compromised safety systems.
A compromised HMI should not automatically mean unrestricted control of industrial equipment.
A stolen vendor credential should not automatically provide access to every facility.
A malicious PLC program should not automatically defeat every independent protection.
A ransomware infection should not automatically mean an entire community loses essential services.
A cyberattack should not be capable of silently disabling every alarm protecting a physical process.
That is defense in depth applied to the real world.
IF THE COMPUTER LIES, WHAT PROTECTS THE PHYSICAL PROCESS?
This may be the most important question in this entire petition.
Industrial operators make decisions based on information.
Temperature.
Pressure.
Flow.
Level.
Speed.
Voltage.
Current.
Chemical concentration.
Valve state.
Motor state.
Alarm conditions.
Equipment status.
If an attacker can manipulate those readings, an operator can make perfectly reasonable decisions based on false information.
The July 2026 federal advisory documented manipulation of HMI and SCADA information.
That means cyber resilience needs to consider whether operators have independent ways to recognize when digital information conflicts with physical reality.
Depending on the system, that might mean independent instrumentation.
Physical indicators.
Diverse sensors.
Separate alarm systems.
Hardwired safety protections.
Local controls.
Mechanical safeguards.
Independent protective relays.
Fail-safe valve positions.
Pressure-relief systems.
Physical mode switches.
Manual verification.
The exact solution will vary enormously between a water facility, power plant, airport, pipeline, manufacturing plant, and transportation system.
That is why this needs to be an engineering requirement instead of a generic IT checklist.
If the computer lies, something still needs to protect the physical process.
AVIATION DESERVES THE SAME LEVEL OF ATTENTION:
Water is not the only sector where digital systems and physical safety increasingly intersect.
Modern aviation relies on interconnected aircraft systems, ground infrastructure, communications, navigation, airport systems, operational networks, and federal systems.
GAO reported in July 2026 that increasing interconnection between aircraft and ground systems creates additional cybersecurity risk.
GAO also identified shortcomings in federal aviation cybersecurity governance and implementation involving FAA and TSA.
SOURCE:
https://www.gao.gov/products/gao-26-107693
This does not mean America’s aviation system is unsafe.
It means cybersecurity has become inseparable from aviation safety and resilience.
Our regulatory structure needs to treat cybersecurity with the seriousness we already apply to mechanical, electrical, operational, and maintenance safety.
An airline cannot simply decide that airworthiness requirements are optional.
Cyber resilience for systems capable of affecting aviation safety should not be treated as an optional best practice either.
THE VENDOR PROBLEM MUST ALSO BE FIXED:
Infrastructure operators cannot secure equipment if the equipment itself was not designed to be secured.
The July 2026 federal advisory explicitly emphasized manufacturer responsibility for building products that are secure by design and secure by default.
That principle needs teeth.
Basic cybersecurity should not be a premium subscription.
Logging should not be an expensive add-on.
Strong authentication should not require purchasing a special “enterprise security” license.
Security updates should not disappear while equipment remains operational for decades.
Before a utility buys equipment expected to operate for twenty or thirty years, it should know how long the manufacturer intends to support it.
Vendors should provide secure deployment guidance.
They should document remote-access functionality.
They should disclose support lifecycles.
They should maintain reasonable vulnerability-reporting processes.
They should provide secure firmware and software updates.
They should provide ways to verify software and configuration integrity.
Critical-infrastructure buyers should be able to compare products based on cybersecurity and lifecycle support, not simply initial purchase price.
PROCUREMENT IS WHERE WE PREVENT TOMORROW’S LEGACY PROBLEM:
One of the best opportunities to improve security happens before equipment is ever installed.
Procurement.
When an organization purchases equipment expected to operate for decades, cybersecurity requirements should be written into the contract.
Purchasers should know:
How long will the equipment receive security updates?
Does it support modern authentication?
Can administrative access be disabled?
Can unnecessary services be turned off?
Can it operate without direct internet access?
Can logs be exported?
Can configuration changes be detected?
Can firmware integrity be verified?
Can backups be created and restored?
Does the vendor have a vulnerability-disclosure process?
Does the vendor issue security advisories?
What happens when the product reaches end of support?
Can the equipment be securely segmented?
Can remote access be brokered through a secure gateway?
Can the system operate safely when communications fail?
Can critical safety functions remain independent from general network access?
If we do not ask those questions during procurement, we may spend the next thirty years compensating for the answers.
DIRECT INTERNET EXPOSURE OF CRITICAL OT SHOULD BE AN EXTRAORDINARY EXCEPTION:
The 2026 attacks revealed another serious problem.
Industrial controllers managing physical processes were accessible from the public internet.
Federal agencies recommended removing PLCs from direct public internet exposure and placing secure gateways, firewalls, and controlled remote-access systems in front of them.
There may be legitimate operational reasons for remote access.
That is different from directly exposing industrial equipment to the public internet.
Critical operational technology should not be publicly reachable simply because doing so is convenient.
Remote access should be authenticated.
Remote access should be authorized.
Remote access should be logged.
Remote access should be monitored.
Remote access should be segmented.
Remote access should be revocable.
And remote access should be designed around the assumption that credentials may eventually be compromised.
“It is hidden on the internet” is not security.
“Only the vendor knows the IP address” is not security.
“Attackers probably will not find it” is not security.
Internet scanning is automated.
Attackers do not need to know your organization exists before finding an exposed device.
SEGMENTATION SHOULD BE EXPECTED, NOT ASPIRATIONAL:
A compromised email account should not provide a straight path to industrial equipment.
A compromised office laptop should not have unrestricted communication with PLCs.
A guest wireless network should not share unrestricted access with operational technology.
A vendor should not have persistent access to everything simply because that vendor services one component.
An accounting system should not communicate directly with a safety controller without a legitimate engineering reason.
Segmentation is not about creating a diagram with colorful boxes separated by firewall icons.
It means actually controlling which systems can communicate, why they can communicate, and what happens when one part of the network becomes untrusted.
SAFETY SYSTEMS SHOULD NOT DEPEND ENTIRELY ON CYBERSECURITY WORKING PERFECTLY:
If a cyber compromise can create a dangerous physical condition, independent protections should exist where technically and economically reasonable.
Depending on the system, that may include mechanical limits, independent protective relays, hardwired emergency shutdowns, independent process alarms, local physical controls, separate safety systems, physical mode switches, fail-safe valve positions, pressure-relief equipment, manual operating capability, independent sensors, or other safeguards.
The exact solution will vary by sector.
That is precisely why Cyber-Informed Engineering matters.
Security decisions should be informed by the physical consequences of failure.
MANUAL OPERATION IS NOT OBSOLETE:
Automation is valuable.
Automation improves efficiency, safety, consistency, and reliability.
But critical services also need to understand what happens when automation disappears.
GAO has documented ransomware incidents that forced affected water systems to temporarily operate manually.
SOURCE:
https://www.gao.gov/products/gao-26-109159
That raises important questions.
Can operators still control the process manually?
Do they know how?
Are procedures available offline?
Can they communicate without the primary IT network?
Can they determine actual physical conditions?
Do they have enough staffing?
Can they restore known-good configurations?
Are backups actually available offline?
Have those backups ever been tested?
When was the last time the organization practiced operating without its normal systems?
A manual fallback that exists only in a binder nobody has opened for ten years is not resilience.
BACKUPS MUST INCLUDE INDUSTRIAL LOGIC AND CONFIGURATION:
When people hear “backup,” they often think about documents and databases.
Critical infrastructure also needs recoverable copies of PLC logic, device configurations, HMI configurations, SCADA configurations, network-device configurations, firmware, engineering workstation data, critical documentation, and other information required to rebuild operational systems.
The July 2026 federal advisory specifically recommended maintaining backups of PLC logic and configurations, storing those backups offline, and verifying that restored backups do not contain malicious logic.
SOURCE:
https://www.ic3.gov/CSA/2026/260722.pdf
That last part is critical.
Restoring a compromised backup simply restores the attack.
Resilience requires trusted recovery.
WE NEED TO STOP CONFUSING COMPLIANCE WITH SECURITY:
A company can pass an audit and still be insecure.
A utility can complete a questionnaire and still have an internet-facing PLC.
An organization can possess an incident-response plan nobody has ever practiced.
A vendor can claim its product is secure while shipping unnecessary services enabled.
A network diagram can show segmentation that does not exist in practice.
A backup policy can exist while nobody knows whether the backups actually restore.
Cyber-Informed Engineering must not become another binder.
The goal should be measurable engineering outcomes.
Can an attacker manipulate the physical process?
Can an attacker defeat safety controls?
Can an attacker conceal what they are doing?
Can compromise of one system spread to another?
Can the organization safely operate when systems fail?
Can operators detect abnormal physical conditions independently?
Can the organization recover a trusted configuration?
Can remote access be immediately revoked?
Are critical protections sufficiently independent that one compromise does not defeat everything?
Those questions matter more than whether somebody checked a box.
THIS PETITION IS NOT ASKING EVERY SMALL UTILITY TO BECOME THE NSA:
Small water utilities, rural electric organizations, municipalities, public institutions, and other infrastructure operators frequently have limited budgets.
Some may have only a handful of employees.
They may not have dedicated cybersecurity staff.
They may already struggle to hire electricians, engineers, mechanics, and plant operators.
Cybersecurity mandates without funding could therefore create an impossible situation.
That would be bad policy.
Congress should pair meaningful cybersecurity requirements with grants, technical assistance, shared cybersecurity services, modernization funding, affordable training, workforce-development programs, regional assistance, testing resources, procurement support, and dedicated funding to replace equipment that cannot reasonably be secured.
GAO has repeatedly identified limited financial resources, workforce shortages, and older technologies as challenges in water-sector cybersecurity.
SOURCE:
https://www.gao.gov/products/gao-26-109159
The answer should not be to lower the safety standard.
The answer should be to help communities reach it.
REQUIREMENTS SHOULD BE BASED ON CONSEQUENCE:
A Cyber-Informed Engineering mandate should not treat every device identically.
A computer controlling decorative landscaping lights does not carry the same consequence as a controller regulating chemical treatment at a drinking-water facility.
A network printer does not carry the same risk as an emergency shutdown system.
Requirements should therefore be risk-informed and consequence-based.
The more severe the potential physical consequence, the stronger the required engineering protections should become.
That is already how mature safety engineering works.
Cybersecurity should follow the same logic.
LEGACY EQUIPMENT NEEDS A PATH FORWARD, NOT AN OVERNIGHT BAN:
America cannot replace every legacy PLC, relay, industrial computer, transportation system, and government application tomorrow.
Attempting to do so could itself create unacceptable operational risk.
But there is an enormous difference between:
“We cannot replace this today.”
and:
“We have no plan to replace this.”
Organizations operating high-consequence legacy systems should know what equipment they have.
They should know how old it is.
They should know whether it remains supported.
They should know what vulnerabilities affect it.
They should know whether those vulnerabilities can be mitigated.
They should understand how the equipment is connected.
They should understand what physical consequences compromise could create.
They should know what compensating controls exist.
They should know when replacement is expected.
They should know what replacement will cost.
And they should understand what happens if the equipment fails before then.
Modernization should be planned, risk-based, funded, and measurable.
GAO found that even among 11 critical federal legacy systems considered among those most urgently needing modernization, only three had modernization plans containing all key elements reviewed by GAO.
Six had incomplete plans.
Two had no modernization plans.
SOURCE:
https://files.gao.gov/reports/GAO-25-107795/index.html
If we cannot consistently create modernization plans for some of the government’s most critical legacy systems, we should not pretend this problem will fix itself.
WHAT WE ARE ASKING CONGRESS TO DO:
We call on Congress to establish Cyber-Informed Engineering, secure-by-design principles, and consequence-based cyber resilience as legal minimums for federally regulated critical infrastructure and other high-consequence cyber-physical systems.
Legislation should direct CISA, NIST, the Department of Energy, EPA, Department of Transportation, TSA, FAA, and other appropriate regulators and sector agencies to establish enforceable, sector-specific requirements.
At minimum, legislation should include the following:
DEMAND 01: REQUIRE CYBER-INFORMED ENGINEERING FOR NEW CRITICAL INFRASTRUCTURE.
Cybersecurity should be incorporated during concept development, engineering, design, procurement, construction, commissioning, operation, maintenance, modernization, and eventual decommissioning.
New infrastructure should not become tomorrow’s legacy-security crisis.
DEMAND 02: REQUIRE CONSEQUENCE-BASED CYBER RISK ANALYSIS.
Operators of high-consequence systems should identify the worst credible physical outcomes of cyber compromise and demonstrate reasonable engineering safeguards intended to prevent, limit, detect, or safely recover from those outcomes.
The purpose should not be predicting every possible attacker.
The purpose should be limiting what attackers can physically accomplish.
DEMAND 03: REQUIRE SECURE-BY-DESIGN AND SECURE-BY-DEFAULT PROCUREMENT.
Equipment used in critical infrastructure should support reasonable modern security capabilities appropriate to its use.
Essential security features should not be disabled by default or hidden behind premium licensing tiers.
Purchasers should know the expected security-support lifecycle before buying equipment expected to remain operational for decades.
DEMAND 04: ESTABLISH LIFECYCLE SECURITY REQUIREMENTS.
Manufacturers and purchasers should plan for security updates, vulnerability disclosure, support periods, replacement components, configuration integrity, authentication, logging, secure updates, end-of-support notifications, migration, and eventual decommissioning.
DEMAND 05: REQUIRE ACCURATE INVENTORIES OF CRITICAL DIGITAL ASSETS.
Organizations cannot protect systems they do not know exist.
Operators should maintain accurate inventories of high-consequence operational technology, including hardware, software, firmware, ownership, support status, connectivity, and critical dependencies.
DEMAND 06: RESTRICT DIRECT INTERNET EXPOSURE OF OPERATIONAL TECHNOLOGY.
Direct public internet access to safety-critical PLCs, HMIs, SCADA systems, and similar equipment should be prohibited except where a documented engineering justification exists and equivalent protective controls are implemented.
Remote access should normally be mediated through controlled infrastructure and protected with strong authentication, authorization, logging, monitoring, and segmentation.
DEMAND 07: REQUIRE MEANINGFUL NETWORK SEGMENTATION.
Critical operational systems should be separated from ordinary corporate networks and unrelated operational systems according to risk and function.
Access between zones should be explicitly authorized and technically enforced.
DEMAND 08: REQUIRE STRONG AUTHENTICATION FOR REMOTE ACCESS.
Default passwords should be prohibited.
Shared credentials should be minimized.
Remote administrative access should use strong authentication and multi-factor authentication where technically feasible.
Legacy devices unable to support modern authentication should be protected through compensating controls.
DEMAND 09: PROTECT SAFETY FUNCTIONS FROM ORDINARY CYBER COMPROMISE.
Where a cyberattack could create dangerous physical consequences, independent or diverse protections should be used where reasonably practical.
Safety-critical shutdowns and protective functions should not unnecessarily depend entirely upon the same systems an attacker is attempting to manipulate.
DEMAND 10: REQUIRE TRUSTED RECOVERY CAPABILITY.
Critical operators should maintain secure, tested, and appropriately isolated backups of configurations, operational logic, critical software, and documentation.
Recovery exercises should demonstrate the ability to restore known-good systems.
DEMAND 11: REQUIRE DEGRADED AND MANUAL OPERATING PLANS.
Critical services should identify which functions must continue during loss of normal digital systems and establish safe alternatives where technically possible.
Employees expected to perform those procedures should periodically practice them.
DEMAND 12: REQUIRE CYBERSECURITY EXERCISES INVOLVING ENGINEERS AND OPERATORS.
Cybersecurity should not live entirely inside the IT department.
Exercises should involve cybersecurity teams, control engineers, operators, electricians, maintenance personnel, emergency managers, leadership, vendors where appropriate, and safety personnel.
A cyberattack against operational technology is a multidisciplinary engineering emergency.
DEMAND 13: REQUIRE CONFIGURATION-INTEGRITY MONITORING FOR HIGH-CONSEQUENCE CONTROLLERS.
Organizations should have a reasonable means of identifying unauthorized modifications to critical PLC logic, device configurations, and safety settings.
Recent attacks demonstrate exactly why this matters.
DEMAND 14: ESTABLISH MINIMUM LOGGING REQUIREMENTS.
Organizations should retain the information necessary to investigate unauthorized access and changes to critical systems.
Basic cybersecurity logging should not be treated as an optional luxury.
DEMAND 15: REQUIRE VULNERABILITY-MANAGEMENT PROGRAMS APPROPRIATE TO OPERATIONAL TECHNOLOGY.
This does not mean blindly installing every patch the moment it appears.
OT patching must consider safety and availability.
But organizations should know which vulnerabilities exist, determine their risk, apply patches when appropriate, implement compensating controls when patches are not possible, and document unresolved high-risk conditions.
DEMAND 16: REQUIRE FUNDED MODERNIZATION PLANS FOR UNSUPPORTABLE LEGACY SYSTEMS.
High-consequence systems that cannot reasonably meet minimum cybersecurity requirements should have documented replacement or modernization plans.
Exceptions should be time-limited, documented, reviewed, and accompanied by appropriate compensating controls.
DEMAND 17: TIE FEDERAL INFRASTRUCTURE FUNDING TO SECURE ENGINEERING.
Federal taxpayers should not finance new infrastructure that ignores well-established cybersecurity principles.
Projects receiving substantial federal infrastructure funding should demonstrate compliance with applicable Cyber-Informed Engineering requirements.
DEMAND 18: PROVIDE SUBSTANTIAL ASSISTANCE FOR SMALL AND RURAL OPERATORS.
Congress should establish dedicated grants, shared services, technical assistance, modernization programs, and cybersecurity support so minimum standards do not disproportionately punish small communities.
DEMAND 19: ESTABLISH MEANINGFUL VENDOR RESPONSIBILITY.
Manufacturers selling long-lived equipment into critical-infrastructure environments should bear reasonable responsibility for the cybersecurity of their products.
Manufacturers should clearly disclose support lifecycles and known security limitations.
Basic security capabilities should not be optional luxury features.
DEMAND 20: HARMONIZE REQUIREMENTS ACROSS FEDERAL REGULATORS.
Organizations should not have to satisfy a maze of contradictory cybersecurity frameworks.
Congress should require federal agencies to coordinate baseline expectations while allowing sector-specific requirements where physical risks differ.
The goal should be one coherent minimum adapted intelligently to each sector.
THIS SHOULD BE A FLOOR, NOT A CEILING:
These requirements should represent the minimum acceptable level of care.
Organizations facing greater risks should do more.
Companies should remain free to exceed the minimum.
Engineers should remain free to develop better solutions.
Standards should evolve as technology and threats change.
The law should establish the basic principle that organizations operating systems capable of causing large-scale physical or societal harm have a responsibility to engineer cyber risk into those systems from the beginning.
WE ALREADY REGULATE PHYSICAL SAFETY:
None of this should be considered radical.
Electrical installations have codes.
Boilers have safety requirements.
Aircraft have airworthiness requirements.
Workplaces have safety rules.
Pressure vessels have engineering standards.
Buildings have fire codes.
Vehicles have safety requirements.
Industrial equipment has protective systems.
Drinking water has quality requirements.
Nobody seriously argues that every individual company should simply decide for itself whether electrical grounding is worthwhile.
We learned through experience that when failures can kill people or harm entire communities, society establishes minimum engineering standards.
Software now participates in controlling those same physical systems.
Cybersecurity should not be fundamentally different.
CYBERSECURITY IS NOW PART OF ENGINEERING:
For years, many organizations treated cybersecurity primarily as an IT function.
That made sense when the primary concern was protecting email, documents, business applications, and databases.
But the world changed.
Computers regulate physical processes.
Networks connect buildings.
Software controls industrial machinery.
Digital systems coordinate transportation.
Cloud services interact with infrastructure.
Cellular modems connect remote equipment.
Vendors remotely service machinery.
Sensors feed automated decisions.
The boundary between cybersecurity and physical engineering is disappearing.
The law needs to recognize that reality.
WE SHOULD NOT NEED A CATASTROPHE BEFORE ACTING:
Cybersecurity regulation has a bad habit of arriving after disaster.
A massive incident happens.
Congress holds hearings.
Officials ask why nobody acted.
Reports are written.
Recommendations are issued.
Organizations promise improvement.
Everyone moves on.
Then another incident happens.
We do not need to repeat that cycle with cyber-physical infrastructure.
Federal investigators have already documented attackers targeting American industrial controllers.
They have documented operational disruption.
They have documented altered industrial logic.
They have documented manipulation of operator displays.
They have documented modifications affecting safe operating parameters.
They have documented disabled shutdown and alarm logic.
What exactly are we waiting for?
A major municipal water outage?
Contaminated drinking water?
A widespread electrical disruption?
Damaged industrial equipment?
A pipeline failure?
A transportation emergency?
Loss of life?
At some point, saying “we need more study” becomes an excuse for accepting risks we already understand.
THIS IS NOT ABOUT FEAR:
This petition is not claiming that America’s infrastructure is about to collapse.
It is not claiming every water utility is insecure.
It is not claiming every airline has dangerous systems.
It is not claiming every old PLC is vulnerable.
It is not claiming cybersecurity can eliminate every risk.
Engineering rarely eliminates risk entirely.
The goal is to understand risk and design systems so failure does not become catastrophe.
That is what engineers already do with fire, electricity, pressure, mechanical failure, structural loads, chemical hazards, weather, human error, and countless other threats.
Cyber threats now belong on that list.
THIS IS A NATIONAL-SECURITY ISSUE:
Critical infrastructure does not need to be physically destroyed for an adversary to achieve its objectives.
Disruption itself can have enormous consequences.
Interrupt water.
Interrupt power.
Interrupt transportation.
Interrupt communications.
Interrupt fuel distribution.
Interrupt government services.
Force operators into emergency procedures.
Create uncertainty about whether digital systems can be trusted.
Then multiply those effects across communities.
Cyber-Informed Engineering makes those attacks more difficult by limiting the physical consequences an attacker can create even after achieving some level of digital access.
THIS IS ALSO AN ECONOMIC-SECURITY ISSUE:
Critical-infrastructure outages cascade.
A water outage affects hospitals, restaurants, schools, factories, homes, fire departments, data centers, businesses, agriculture, and countless other services.
A transportation disruption affects supply chains.
An energy disruption affects almost everything.
A communications disruption affects emergency response.
The cybersecurity of infrastructure cannot therefore be measured only by the cost of protecting the individual operator.
We need to consider the potential cost imposed on everyone who depends on that infrastructure.
WE ALREADY KNOW WHAT TO DO:
This is not a situation where Congress needs to invent cybersecurity from scratch.
DOE already has Cyber-Informed Engineering.
NIST already publishes operational-technology cybersecurity guidance.
CISA already publishes cross-sector cybersecurity performance goals.
EPA already maintains water-sector cybersecurity resources.
Federal agencies already issue detailed industrial-control-system advisories.
Engineers already know how to conduct hazard and consequence analysis.
Cybersecurity professionals already know how to segment networks, manage identity, monitor systems, manage vulnerabilities, and respond to incidents.
Manufacturers already know how to build more secure products.
What is missing is a consistent expectation that these principles must be applied where cyber compromise can create serious physical consequences.
MAKE SECURE ENGINEERING THE LEGAL BARE MINIMUM:
The question should no longer be:
“Should this utility voluntarily consider cybersecurity?”
The question should be:
“What cybersecurity and engineering controls are necessary given the physical consequences of this system?”
The question should no longer be:
“Does the vendor offer security features?”
It should be:
“Why would critical-infrastructure equipment be sold without basic security features?”
The question should no longer be:
“Can we afford cybersecurity?”
It should be:
“Can the country afford infrastructure whose safety depends on attackers never gaining access?”
The question should no longer be:
“Has anyone attacked this specific system before?”
It should be:
“What happens when somebody eventually tries?”
Because attackers are trying.
We have the advisories.
We have the investigations.
We have the GAO reports.
We have the frameworks.
We have the engineering knowledge.
Now we need enforceable minimum standards.
OUR REQUEST TO CONGRESS:
We call on the United States Congress to pass legislation establishing Cyber-Informed Engineering and consequence-based cyber resilience as mandatory minimum principles for U.S. critical infrastructure and other high-consequence cyber-physical systems.
Congress should provide sector regulators with the authority necessary to implement enforceable cybersecurity requirements.
Congress should require federal agencies to harmonize those requirements.
Congress should provide funding and technical assistance for small and rural infrastructure operators.
Congress should establish secure-by-design expectations for critical-infrastructure vendors.
Congress should require lifecycle planning for equipment expected to remain in service for decades.
Congress should require modernization plans for systems that cannot reasonably meet modern security requirements.
Congress should tie substantial federal infrastructure spending to secure engineering practices.
And Congress should ensure that infrastructure built with taxpayer money today does not become the preventable cybersecurity crisis Americans inherit twenty or thirty years from now.
“TRUST ME, BRO” IS NOT A SAFETY SYSTEM:
If I wired a building and told an inspector:
“Do not worry, nothing should ever short circuit,”
they would rightfully reject that logic.
If an engineer designed a pressure system and said:
“We do not need relief protection because the pressure should never exceed the limit,”
nobody would accept it.
If an airline said:
“We do not need redundant systems because the primary one probably will not fail,”
we would never tolerate that.
But somehow when software controls physical infrastructure, organizations are still too often allowed to rely on assumptions that amount to:
Nobody will find it.
Nobody will compromise it.
Nobody will steal the password.
Nobody will change the configuration.
Nobody will compromise the vendor.
Nobody will reach the OT network.
Nobody will manipulate the PLC.
Nobody will spoof the sensor.
Nobody will disable the alarm.
Nobody will compromise the HMI.
Nobody will exploit the legacy system.
Nobody will attack us because we are too small.
Trust me, bro.
That is not cybersecurity.
That is not engineering.
And when the systems involved provide water, electricity, transportation, communications, government services, or other infrastructure millions of Americans depend upon, it is not an acceptable national policy.
America knows how to engineer resilient systems.
It is time to require that we do it.
Protect America’s critical infrastructure from cyberattacks.
Make Cyber-Informed Engineering the legal minimum before the next cyberattack becomes a physical disaster.
SOURCES:
SOURCE 01: FBI, CISA, NSA, EPA, Department of Energy, U.S. Cyber Command, and Department of the Treasury joint cybersecurity advisory regarding Iranian-affiliated actors targeting programmable logic controllers across U.S. critical infrastructure, updated July 22, 2026.
https://www.ic3.gov/CSA/2026/260722.pdf
SOURCE 02: U.S. Government Accountability Office, “Critical Infrastructure Protection: Actions Needed to Address Persistent Cybersecurity Threats to the Water and Wastewater Sector,” May 21, 2026.
https://www.gao.gov/products/gao-26-109159
SOURCE 03: U.S. Government Accountability Office, “Critical Infrastructure Protection: EPA Urgently Needs a Strategy to Address Cybersecurity Risks to Water and Wastewater Systems,” August 1, 2024.
https://www.gao.gov/products/gao-24-106744
SOURCE 04: U.S. Environmental Protection Agency, FBI, CISA, and NSA cybersecurity advisory regarding Iranian-affiliated attacks affecting water systems and other U.S. critical infrastructure, April 2026.
SOURCE 05: U.S. Government Accountability Office, “Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems,” July 2025.
https://files.gao.gov/reports/GAO-25-107795/index.html
SOURCE 06: U.S. Government Accountability Office, “Aviation Cybersecurity: FAA and TSA Are Collaborating on Cybersecurity but Need to Address Key Shortfalls,” July 16, 2026.
https://www.gao.gov/products/gao-26-107693
SOURCE 07: U.S. Department of Energy, Cyber-Informed Engineering.
https://www.energy.gov/ceser/cyber-informed-engineering
SOURCE 08: National Institute of Standards and Technology, Guide to Operational Technology Security.
SOURCE 09: National Institute of Standards and Technology, Systems Security Engineering, SP 800-160.
The Decision Makers
Petition Updates
Share this petition
Petition created on August 16, 2026