
CISA’s advisory for critical infrastructure operators to enhance secure communications

Prayukth K V
11 فبراير 2026
Today’s blog post presents a summary of CISA’s recent advisory paper titled “Barriers to Secure OT Communication: Why Johnny Can’t Authenticate. This paper can be downloaded from this link.
No matter how you look at it, this is more than just another CISA advisory. Instead, it is a fundamental shift in how the federal government views the "human element" of cybersecurity. For years, the industry narrative has been "Johnny just needs more training." CISA’s February 2026 report, "Barriers to Secure OT Communication: Why Johnny Can’t Authenticate," essentially flips the script and brings to the fore more aspects that need to be plugged into an overall secure communications plan.
The report articulates that Johnny (the operator) isn't failing the system. Instead it looks like the system is failing Johnny. By focusing on the "unusable" nature of current security implementations in Operational Technology (OT), CISA has provided a roadmap for moving from theoretical security to functional resilience.
Before we move forward, don’t forget to check our previous blog post on “How a side-hustle paralyzed Romania’s national oil pipeline” here.
The core "Johnny" Problem: A legacy of usability failure
Some of us may remember this title and its context. The title is a hard-to-miss reference to the 1999 seminal paper "Why Johnny Can't Encrypt," that proved that if security tools are too hard to use, people simply won't use them. In the context of 2026, CISA applies the same logic to the technicians and engineers managing our power grids, water treatment plants, and manufacturing lines.
We all know that in an OT environment, the primary goal is availability and safety. If an authentication gate delays a command to a cooling pump by just a few milliseconds, or blocks it entirely because of an expired certificate, the result isn't just a "denied access" log; it’s a physical catastrophe. This is an easy to imagine scenario for all OT operators.
Beyond the plaintext
For too long, IT-centric security professionals have looked down on OT operators for using plaintext protocols like Modbus or DNP3. CISA’s report validates the operator's perspective. Insecurity is often a conscious choice made to ensure reliability.
Technical barriers: The CPU and memory tax
Modern cryptography is fairly "expensive" in terms of computing power. The CISA document details a harsh reality: many of the devices currently controlling critical infrastructure were built before many of us started our careers or were still earning our degrees.
The resource gap: Implementing Transport Layer Security (TLS) or even something as simple Message Authentication Codes (MACs) requires CPU cycles and memory that legacy PLCs (Programmable Logic Controllers) simply cannot afford.
The latency challenge: In high-speed processes (like electrical grid protection), the time it takes to perform a "handshake" to authenticate a message can exceed the time allowed for the command itself to execute.
The "Headless" problem: Many OT devices do not come with a screen or a keyboard. Configuring a complex 20-character password or a multi-factor authentication (MFA) token is therefore physically impossible on a device that lives inside a DIN-rail enclosure in a remote substation.
The certificate management nightmare
If there is a "villain" in this report, it is the current state of Public Key Infrastructure (PKI) in the field. CISA highlights that managing identities for thousands of remote, often disconnected devices is the single greatest operational barrier to security.
The "fail-closed" trap or something similar
In IT, if a certificate expires, your browser blocks the site. That’s "failing closed," and it’s secure. In OT, if a certificate expires on a valve controller, and that controller "fails closed" by refusing to take commands, the pipe might burst.
The result: Operators frequently disable certificate checking entirely to avoid self-inflicted downtime, rendering the entire encryption layer moot.
The connectivity gap
Many OT environments are "air-gapped" or have limited connectivity. How do you check a Certificate Revocation List (CRL) or reach an Online Certificate Status Protocol (OCSP) responder if you aren't allowed to connect to the internet? The report highlights that we lack a "standardized, offline-friendly" way to manage trust at scale.
The visibility paradox: Security vs. observability
CISA introduces a critical conflict: Encryption blinds the defenders.
Modern OT security relies heavily on Network Detection and Response (NDR) tools that "sniff" traffic to find anomalies. When you encrypt that traffic (e.g., using secure OPC UA or SIP), those tools can no longer see what’s inside the packet.
The CISA Recommendation: The report leans heavily toward Message Signing (Integrity) over Encryption (Privacy).
"It is often more important for an operator to know that a command definitely came from the authorized controller (Integrity) than it is to hide the command from a passive eavesdropper (Privacy)."
By signing messages, we ensure authenticity without losing the ability to monitor the network for safety.
Economic barriers and market failure
Why hasn't the market fixed this? CISA points to a "market failure" in the OT vendor ecosystem:
Security as a premium: Many vendors treat security features (like logging or encrypted protocols) as "add-on" licenses rather than core safety features.
Long lifecycles: A water utility might replace its pumps once every 25 years. This means that we are currently living with the security decisions made in 2005.
Vendor Lock-in: If Vendor A’s "secure" version of a protocol doesn't talk to Vendor B’s "secure" gateway, the operator is stuck with the lowest common denominator: the insecure legacy protocol.
The "Secure by Design" mandate
CISA concludes that the burden of authentication must shift from the user to the manufacturer. This is the core of their 2026 "Secure by Design" initiative.
No more default passwords: Devices must ship with unique credentials or require a change upon first boot.
Hardware-Based Trust: Manufacturers must include Secure Elements (TPMs) in hardware so that identity is baked into the silicon, not managed in a spreadsheet by a stressed-out technician.
Interoperability: Authentication methods must be standardized across vendors, so that "Johnny" only has to learn (and be proficient in) just one system, not five.
The comprehensive "Secure Johnny" checklist
This checklist is designed for OT Managers and CISOs to evaluate their current posture against the barriers identified in the 2026 CISA report.
Strategic and procurement
[ ] Inventory Legacy Constraints: Have you identified which devices lack the CPU/RAM to handle modern encryption?
[ ] Secure-by-Design RFP: Do your procurement contracts mandate unique initial passwords and support for signed protocols?
[ ] Safety-Security Alignment: Have you defined which systems must "fail open" (prioritize uptime) vs "fail closed" (prioritize security)?
[ ] License Audit: Are you being charged extra for security logs or encrypted protocol versions? (Demand these be included as safety features).
Operational authentication
[ ] Credential Uniqueness: Are there any shared "admin/admin" or "operator/operator" accounts still in use on the shop floor?
[ ] MFA for Access: Is MFA required for the human accessing the HMI, even if the device-to-device comms are still plaintext?
[ ] Key Rotation Schedule: Do you have a documented plan for certificate rotation that does not require an internet connection?
[ ] Physical Security: Since "Johnny" can't always authenticate digitally, are the physical ports on your PLCs locked or tamper-evident?
Technical and monitoring
[ ] Integrity vs. Privacy: Have you explored using "Signed Only" modes for protocols to maintain visibility for your IDS/NDR tools?
[ ] Latency Benchmarking: Have you measured the millisecond delay added by your security stack to ensure it doesn't break control loops?
[ ] Logging Centralization: Are your OT devices sending logs to a central, immutable repository, or are they overwritten every 24 hours?
[ ] Network Zoning: Are insecure "Johnny" devices isolated in a restricted zone (ISA/IEC 62443 style) with a stateful firewall?
CISA’s report is a telling admission that we cannot "patch" our way out of the OT security crisis. Authentication fails because it is treated as a technical bolt-on rather than an operational necessity. To help "Johnny," we must stop asking him to be a security expert and start giving him tools that are secure by default, resilient by design, and, above all, usable in the middle of a crisis.
More about our NIS2 compliance services.
Learn a bit more about Shieldworkz’ Incident response services
Talk to a vacation security expert (yes we have a dedicated security pro who knows more about fine tuning your security measures during lean times).
Test drive our OT security platform here.
Downloadable assets:
OT cybersecurity for on-site maintenance checklist
Insider threat protection checklist
Cyber risk management checklist
Strategic IEC 62443 checklist to protect your IACS operations
احصل على تحديثات أسبوعية
الموارد والأخبار
You may also like
09/02/2026
How a side-hustle paralyzed Romania’s national oil pipeline

Prayukth K V
05/02/2026
A deep dive into 2025's most devastating cyberattacks as per Tokio Marine HCC International

Prayukth K V
03/02/2026
Achieving NIS2 compliance via the IEC 62443 framework

Prayukth K V
03/02/2026
NERC CIP Roadmap for 2026: Practical Steps for Power Generation to Protect PLCs and RTUs

Team Shieldworkz
28/01/2026
Observed reduction in Chinese APT Operations amid 2026 PLA purge

Prayukth K V
26/01/2026
NIST Seeks Industry Input on Major SP 800-82 Revision for Operational Technology Security

Prayukth K V








