Contractor Implications of CISA’s OT Cybersecurity Guidance
Published: March 03, 2026
Federal Market AnalysisCritical Infrastructure ProtectionCybersecurityCISAInternet of ThingsPolicy and Legislation
Efforts to raise the cybersecurity of operational technology within critical infrastructure impacts both product manufacturers and service providers.
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) continues to push for greater cybersecurity of the operational technology (OT) employed within critical infrastructure (CI) sectors, both inside and outside of government contexts.
In February, CISA published Barriers to Secure OT Communication: Why Johnny Can't Authenticate, a “voice-of-customer” report examining why critical infrastructure asset owners and operators have failed to adopt secure OT communication protocols despite their increasing availability. Cost, complexity, interoperability, bandwidth and encryption are all major issues. This Barriers to Secure OT guidance builds on the security concepts in CISA’s January 2025 guidance, Secure by Demand: Priority Considerations for OT Owners and Operators When Selecting Digital Products, which sets out 12 priority security elements that OT owners and operators should require manufacturers to embed into their product design and development.
Contracting Areas Impacted by CISA’s OT Security Guidelines
Together, these guideline documents have implications for companies operating in critical infrastructure sectors or supplying OT and industrial control systems (ICS) to the government. Here are the major contractor categories that are most impacted.
OT Product Manufacturers and Vendors
This contractor category is the most directly and comprehensively affected by these documents. Secure by Demand establishes what U.S. government and regulated buyers will demand. Barriers to Secure OT explains why adoption has stalled and what manufacturers must do to remove the friction preventing it. The combined message is clear: manufacturers seeking to sell into U.S. federal and federally regulated markets are expected to close the gap between what secure-by-design requires and what operators can practically deploy.
On product design, manufacturers face clear expectations to ship products with secure communications enabled and configured by default, eliminate default passwords entirely, include all security features — logging, role-based access control (RBAC), multifactor authentication (MFA), etc. — in baseline product versions at no additional cost, disable legacy insecure protocols out of the box, and build crypto-agility into every product so that cryptographic algorithms can be updated without hardware replacement. Barriers to Secure OT adds the specific finding that manufacturers who charge licensing fees to enable secure communications servers are a documented barrier to adoption — a practice the combined guidance strongly signals will be disfavored in U.S. federal procurement evaluations.
On interoperability and standards, both documents converge on the same message: proprietary protocols and vendor lock-in are security liabilities. Manufacturers are expected to use open standards, participate in formal certification and interoperability testing programs, and publish parsers or otherwise actively support cross-vendor compatibility. Secure by Demand frames vendor lock-in as an ownership problem that impedes operator autonomy; Barriers to Secure OT documents a real-world case where an asset owner had to remove architecture entirely after a proprietary vendor went out of business — illustrating the supply chain risk that U.S. government buyers are working to eliminate.
On vulnerability management and transparency, Secure by Demand requires manufacturers to maintain CVE Program participation, publish software and hardware bills of materials with product delivery, provide security patches free of charge throughout the defined support lifecycle, publish CSAF-formatted machine-readable security advisories, and maintain publicly accessible coordinated vulnerability disclosure programs. These requirements align closely with existing U.S. federal software supply chain security expectations established through Executive Order 14028 and related OMB guidance, reinforcing that manufacturers whose current business models involve charging for patches, delaying disclosures, or tying support to end-of-life operating systems are directly at odds with both documents and the broader federal cybersecurity policy direction.
On post-quantum cryptography, Barriers to Secure OT adds a forward-looking obligation not explicitly addressed in Secure by Demand: manufacturers building OT products today must design for post-quantum cryptography (PQC) transition readiness, consistent with NIST's PQC standards, as the transition will likely need to occur within the operational lifespan of products currently being sold. This has direct implications for product roadmaps, key exchange mechanism design, and network utilization planning in bandwidth-constrained OT environments serving U.S. federal and regulated sector customers.
OT System Integrators
Both documents identify integrators as critical — and currently problematic — actors in the OT security ecosystem. Barriers to Secure OT documents that operators routinely require third-party integrator support for PKI deployment and ongoing maintenance, and that inadequate integrator contracts have contributed to insecurity. Secure by Demand explicitly calls out poor integrator contracts as a source of complexity that raises barriers to secure deployment.
The combined implications for U.S. integrators are substantial. Integrators working on federal or federally regulated OT systems will be expected to demonstrate PKI deployment experience for the specific OT protocols involved in each engagement, provide deployment guidance that enables secure communications by default, minimize the configuration gap between legacy brownfield environments and new greenfield installations through standardized interfaces and pre-configured templates, and actively guide clients toward secure-by-default states and away from risky operating models — including the specific examples cited in both documents such as connecting OT and IT to a shared central identity system or creating inflexible IT dependencies for critical engineering processes.
Integrators who offer PKI-as-a-service or key management automation will find growing demand as both documents highlight these capabilities as essential for U.S. operators who lack in-house expertise. Conversely, integrators who cannot demonstrate ISA/IEC 62443 familiarity — a standard explicitly referenced in Secure by Demand and recognized by U.S. federal sector risk management agencies — or who continue to deliver configurations that default to insecure legacy protocols risk being disqualified from procurements where these criteria are applied. Integrators should also anticipate that statements of work issued by federal agencies and federally regulated operators will increasingly incorporate the 12 Secure by Demand elements as explicit performance requirements.
Critical Infrastructure Operators Under Federal Contract or Regulation
Contractors who operate water, energy, transportation, chemical, or food and agriculture systems under federal agreements or sector regulation — including those overseen by EPA, TSA, and the Department of Energy — face the combined effect of both documents reshaping what constitutes an adequate OT cybersecurity posture under U.S. law and regulation.
From a procurement standpoint, Secure by Demand's 12 elements collectively define what these contractors should be demanding from their OT suppliers. Barriers to Secure OT adds operational nuance: operators should adopt a phased approach to secure communications, beginning with message signing without encryption and without packet dropping, then progressively tightening controls as confidence in the infrastructure grows. Operators should prioritize securing remote access paths, communications across functional or network boundaries, and firmware uploads and logic changes as the highest-value targets for initial deployment — consistent with CISA's broader guidance to U.S. critical infrastructure sectors.
From a risk management standpoint, Barriers to Secure OT documents that operators who chose network segmentation and continuous monitoring as alternatives to secure protocols did so primarily on cost grounds — but acknowledges this tradeoff is increasingly untenable as threat actors, including PRC state-sponsored actors explicitly cited in the document, have repeatedly demonstrated the ability to access supposedly segmented U.S. field networks. Operators under federal contract who continue to rely solely on segmentation without progressing toward authenticated OT communication face growing exposure as CISA and its U.S. agency partners explicitly question the adequacy of segmentation-only strategies.
The Secure by Demand guidance on operator autonomy and ownership has particular contracting implications for U.S. operators. Contractors should audit their existing vendor agreements for restrictions on third-party maintenance, security testing, or adding security products such as firewalls and continuous monitoring solutions — and should treat such restrictions as disqualifying factors in future procurements. U.S. operators with federal contracts should also anticipate that their sector risk management agencies, including EPA for water systems and TSA for transportation, will increasingly use the 12 elements as the basis for compliance assessments and sector-specific cybersecurity requirements as these agencies translate the guidance into enforceable standards.
OT Security Service Providers and Managed Security Providers
While not explicitly addressed as a separate category in either document, U.S. contractors providing OT-specific cybersecurity services — monitoring, incident response, vulnerability assessment, managed PKI — stand to benefit significantly from the combined effect of both documents. Barriers to Secure OT documents active demand for external support with PKI deployment and key management, with many U.S. operators citing the need to retain third-party services on an ongoing basis. Secure by Demand's emphasis on operators maintaining business continuity and incident recovery capabilities points toward sustained demand for managed OT security services within the U.S. federal and regulated sector market.
Service providers should, however, be aware that both documents envision a future where manufacturers assume more of the security burden through better product design — potentially reducing some of the remediation work that currently drives demand for managed services in U.S. markets. The long-term trend favors service providers who can differentiate on integration capability, protocol-specific expertise, and the ability to bridge the OT/IT security responsibility gray zone that Barriers to Secure OT specifically identifies as a source of operational friction in U.S. critical infrastructure environments.
Contractor Implications
Taken together, these two CISA documents constitute a coordinated U.S. government effort — with participation from NSA, FBI, EPA, and TSA — to restructure how cybersecurity responsibilities are distributed across the OT supply chain serving U.S. critical infrastructure. Secure by Demand defines the destination: 12 security elements that OT products must embody to be considered fit for procurement by U.S. federal and federally regulated operators. Barriers to Secure OT provides the implementation roadmap: specific, research-based findings about why adoption has stalled and what manufacturers and integrators must do differently to make secure communications practical rather than merely available.
For U.S. federal contractors, the combined message is that these documents are the leading edge of a procurement and regulatory wave already reshaping source selection criteria, contract performance expectations, and sector-specific compliance frameworks across every critical infrastructure sector in which U.S. contractors operate.
Contractors who treat these documents as voluntary guidance do so at increasing competitive and compliance risk. OT manufacturers who continue shipping insecure-by-default products, charging for baseline security features, or relying on proprietary protocols will find themselves systematically disadvantaged as U.S. government buyers and federally regulated operators apply these criteria in procurement decisions.
System integrators who cannot demonstrate PKI expertise and secure-by-default deployment capability face growing disqualification risk in federal procurements. And operators who have deferred investment in authenticated OT communications in favor of segmentation-only strategies should treat these documents as a clear signal from CISA and its U.S. agency partners that the segmentation-only posture is no longer considered sufficient — and that the path forward requires building toward the authenticated, crypto-agile, secure-by-default OT environment that both documents collectively and consistently describe.