Protocol Converters: The 2023 SAR Just Got Validated (Again)
BY Patrick Miller
NERC Project 2021-03 Phase 2 asked, in February 2023, whether communication protocol converters between Control Centers and field devices should be classified as BES Cyber Assets. The Standards Authorization Request laid out a clean tension: leave the converters outside the Electronic Security Perimeter and accept the categorization gap, or pull them inside and accept that serial traffic now bypasses the Electronic Access Point. Three years later, Forescout Vedere Labs published BRIDGE:BREAK and delivered 22 new CVEs across Lantronix and Silex hardware, with pre-authentication remote code execution at CVSS 9.8. BRIDGE:BREAK is not a one-time research splash. It is the latest entry in a documented pattern of converter vulnerabilities going back to 2015. The 15-minute impact question the SAR raised is no longer theoretical. The drafting team now has the empirical record to settle it.
Overview
The 2023 SAR on communication protocol converters under Phase 2 of Project 2021-03, and Forescout Vedere Labs' BRIDGE:BREAK research summarized for the ICS/OT community in ICSAP-AL-26-04-001. The SAR describes a categorization gap. BRIDGE:BREAK is the most recent entry in a decade-long pattern of vulnerabilities in the same device class. Read together, they describe the same problem from two angles: a regulatory gap and a vulnerability surface measured in millions of devices and tens of thousands of internet-reachable units.
The headline: the SAR's hypothetical risk is documented in the CVE record going back to 2015. The categorization debate inside Phase 2 should be informed by what BRIDGE:BREAK and its predecessors demonstrate about exploitability, blast radius, and the embedded-module asset discovery problem. Whatever the drafting team writes next, asset owners have CIP-007 R2 patch evaluation obligations starting now and a CIP-013 supply chain question that does not wait for a standard revision.
The Question Phase 2 Asked
Section 4.2.3 of CIP-002-5.1a exempts "Cyber Assets associated with communication networks and data communication links between discrete Electronic Security Perimeters." That language was written for a world where both ends of a communication link sat inside a defined ESP. The protocol converter scenario breaks that assumption.
The 2023 SAR identified four problem geometries:
| Scenario | Why the Section 4.2.3 Exemption Fails |
|---|---|
| Medium-impact substation, serial-only | The substation has no ESP because no External Routable Connectivity exists. Two discrete ESPs do not exist on the link. |
| Low-impact substation | CIP-005 ESP requirements do not apply at low impact. Same gap. |
| Converter inside the Control Center | The Transmission Operator owns the converter, not the Transmission Owner whose facility it serves. Functional Entity assignment is unclear. |
| Converter inside a Wide Area Network | Neither the TO nor the TOP owns the converter. No Functional Entity in Appendix 5B cleanly applies. |
The SAR proposed two paths to clarity: enforce an authentication break on the system-to-system link, or place the converter inside a defined ESP. It also flagged the security tradeoff that makes this hard. Moving the converter inside the ESP means the serial traffic no longer traverses an Electronic Access Point. The categorization fix can lower the security posture if it is not carefully done.
A Decade of Disclosures in This Device Class
BRIDGE:BREAK is the most thorough analysis of the device class to date, but it is not the first finding. The vulnerability record across the major serial-to-Ethernet vendors stretches back at least to 2015 and tracks consistent failure modes: unauthenticated configuration change, weak or missing authentication on management interfaces, hard-coded credentials, and firmware updates that do not validate integrity. Phase 2 is not responding to a one-time research effort, but rather a category-wide pattern.
| Year | Vendor / Advisory | What It Was |
|---|---|---|
| 2015 | Moxa NPort (Ukraine attack) | Sandworm operators destroyed firmware on NPort converters at three Ukrainian distribution companies during BlackEnergy3 / KillDisk, severing operator-to-field communication after the breaker openings. |
| 2016 | Moxa NPort, ICSA-16-336-02a | Eight CVEs across NPort 5xxx and 6xxx series, including CVE-2016-9361 at CVSS 9.8 for unauthenticated firmware update over the network. |
| 2017 | Lantronix Port 30718 leak | Roughly 6,500 Lantronix devices on Shodan returning Telnet passwords in plaintext via a malformed UDP request. About 48 percent of the visible installed base. Metasploit module had been available since 2012. |
| 2017 | Moxa NPort (CVE-2017-16719 family) | Predictable TCP ISN, Etherleak-class information disclosure, SYN flood DoS. Censys scan at disclosure found 2,000-plus Moxa devices on the public internet, of which ~1,350 were affected NPort units. |
| 2020 | Moxa NPort IAW5000A-I/O, ICSA-20-287-01 | Session fixation, weak passwords, cleartext credential transmission, brute-force on SSH and Telnet. |
| 2023 | Digi RealPort, ICSA-23-243-04 (CVSS 9.0) | Replay attack against the RealPort Protocol, disclosed by Dragos. Affects PortServer TS, ConnectPort TS/LTS, Passport Console Server, Digi CM, Digi One IA/IAP/SP, plus several TransPort and Connect families. |
| 2025 | Lantronix XPort, ICSA-25-105-05 (CVSS v4 9.3) | Missing authentication on XPort web configuration. Unauthenticated POST to /cfg/network can disable TLS, modify SNMP community strings, deactivate firmware signature verification. |
| 2025 | Poland energy sector incident | CERT Polska attributed a cyber operation to a Russian state-aligned actor. Edge-device compromise enabled Moxa NPort configuration reset on the OT side. |
| 2026 | Lantronix and Silex, BRIDGE:BREAK (22 CVEs) | Pre-auth RCE at CVSS 9.8, hard-coded credentials, unauthenticated password change in the web interface. ~20,000 internet-exposed converters identified across major vendors. |
Three observations matter for the Phase 2 argument. The internet-exposed population has been consistently large and consistently ignored, with the same order of magnitude across nine years of advisories. The failure modes are repetitive enough to be considered a category design defect rather than a vendor-specific lapse. And real-world targeting predates BRIDGE:BREAK by a decade, with both Ukraine 2015 and Poland 2025 demonstrating that the device class has been in attacker scope and that the operational signature of a converter compromise is well understood by adversaries.
Where the SAR and the CVE Record Intersect
The SAR and the CVE record are arguing the same case from opposite directions.
| 2023 SAR Concern | What the CVE Record Demonstrates |
|---|---|
| Protocol converters may meet the BCA definition by virtue of 15-minute adverse impact on a connected BES Cyber System. | Pre-auth RCE at CVSS 9.8 plus weaponized firmware can cause loss of view in seconds. The 15-minute threshold is not the binding constraint. |
| Aggregation of serial system-to-system communications from substations creates a higher-value target. | A single compromised converter at a Control Center can bridge into multiple downstream serial endpoints. Aggregation is the design feature, and now it is the attack surface. |
| The exemption logic in Section 4.2.3 assumes two discrete ESPs. | Converters most often sit at exactly the asymmetric boundary the SAR described: ESP on one side, no ESP on the other. The exemption was never going to fit. |
| Moving the converter inside an ESP can lower the security posture by bypassing the EAP. | True, and zone-and-conduit segmentation plus management plane controls are the documented compensating controls. The categorization fix is the start of the work, not the end. |
| Other Cyber Assets in the path (routers, switches) and ownership ambiguity in WAN scenarios. | The Digi RealPort disclosure (CVE-2023-4299, Dragos, CVSS 9.0) is the worked example. The CIP-013 question gets harder when the affected device is owned by neither the TO nor the TOP. |
The SAR was a structural argument. The CVE record is historical proof of the issue. The drafting team can now argue the proposed revisions on evidence rather than principle.
The Embedded Module Problem
This is the practitioner finding asset owners are most likely to miss, and it is where CIP-002 categorization meets CIP-013 supply chain risk management head on.
Lantronix and Silex sell serial-to-Ethernet capability as standalone products and as embedded modules. Lantronix XPort, MatchPort, and PremierWave parts and the Silex SX module families are licensed into other vendors' hardware and end up inside PLCs, RTUs, IEDs, protection relays, automatic tank gauges, patient monitors, and CNC controllers. The host device shows up in the asset inventory as a relay, an RTAC, an RTU, or a substation gateway, with no surface indication that an affected converter chip lives inside.
For the BCA identification analysis Phase 2 is trying to clean up, this matters in three places. Your CIP-002 BCA list is almost certainly incomplete if the only search you ran was on the named vendors in your CMDB. Vendor-level discovery alone undercounts the affected population, and the substation relay panel is the highest-risk, lowest-visibility location for this exposure. Host-device firmware updates lag chip-level firmware, so confirm the chip firmware version, not just the host build number. And this is a CIP-013 R1 issue, not just a CIP-002 issue. The vendor written response to "does this product family contain an affected serial-to-Ethernet module" is the artifact your CIP-013 R1.2.5 process needs.
Implications for the Phase 2 Drafting Team
The Phase 2 work on protocol converters has been waiting for the right operational evidence to settle the categorization question. It now exists.
The "may have a 15-minute impact" framing in the SAR can be tightened. The vulnerability classes documented across the CVE record produce loss of view and loss of control in seconds, not minutes. The threshold debate is settled in favor of inclusion.
The "lower security posture" tradeoff the SAR flagged remains real, but it now has a documented set of compensating controls. IEC 62443-3-2 zone-and-conduit logic, NIST SP 800-82r3 architectural zones, and management-plane hardening are concrete enough to be referenced as expected practice rather than left as drafting team caveat language.
The Functional Entity ambiguity in WAN-owned converter scenarios is harder. The SAR correctly noted that no Appendix 5B Functional Entity cleanly applies when neither the TO nor the TOP owns the converter. A drafting team revision that pushes responsibility to the entity whose BES Cyber System the converter serves, regardless of ownership, would resolve this in a way the CVE record supports: the consequence travels with the connected BCS, not with the chassis.
The embedded-module problem is genuinely new ground. It connects CIP-002 BCA identification to CIP-013 R1 supply chain disclosure, and the language that ends up in CIP-002 should at minimum acknowledge that BCA identification cannot be completed without supplier disclosure of embedded communication components.
What Asset Owners Should Do Now
| Role | Action This Week |
|---|---|
| Compliance | Confirm affected devices are reflected in the CIP-002 BCA list at the correct impact rating. Document the patch evaluation under CIP-007 R2 within the 35-day window. Either deploy or document a dated mitigation plan per R2.3. |
| OT Security and Architecture | Inventory standalone converters first, then open vendor tickets for embedded modules in every PLC, RTU, IED, and protection relay product line in service. Place converters in a dedicated zone with explicit conduits to named endpoints. Disable HTTP, Telnet, SNMPv1/v2c, FTP, TFTP. |
| Supply Chain and Procurement | Treat this as a CIP-013 R1.2.5 event. Update the vendor risk file for every product family that returns a "yes, contains affected module" response. Add embedded-module disclosure to the next revision of supplier security questionnaires. |
| Incident Response | Stock a known-good spare for each in-service converter model. The default IR move on suspected compromise is pull-and-replace, ship the suspect unit, restore the spare from a backed-up baseline. Capture and checksum current configurations now, not after the call. |
Audit Prep Questions
If your auditor asked tomorrow:
Have you identified all communication protocol converters in service across your registered Functional Entity footprint, including embedded modules in host devices?
For each identified converter, what is your CIP-002 categorization, and what is the documented basis for that determination?
Where converters sit at the asymmetric ESP boundary the 2023 SAR described (ESP on one side, no ESP on the other), how is the security gap addressed?
Have the affected CVEs been evaluated under your CIP-007 R2 patch management process? Where is the evaluation evidence?
Have you opened CIP-013 R1.2.5 vendor disclosure requests for every PLC, RTU, IED, and protection relay product family that may contain affected serial-to-Ethernet modules? Where are the written responses?
Where are baselines documented for the converter (firmware version, enabled services, account list, ACL set), and how is configuration drift detected (CIP-010 R1 and R2)?
What detection content covers the relevant vulnerability classes at the conduit boundary into the converter zone (CIP-007 R4)?
Forward-Looking Questions
How will the Phase 2 drafting team handle the WAN-owned converter scenario? The Appendix 5B Functional Entity model does not have a clean home for a Cyber Asset that materially affects BES reliability but is owned by neither the TO nor the TOP. Phase 2 has an opportunity to close that gap or punt it to a future cycle.
Will FERC or NERC issue interim guidance ahead of the Phase 2 ballot? Given the active CISA advisories and the historical record of attacks against this device class, there is a credible argument for an Implementation Guidance document or an ERO Enterprise interpretation in advance of the standard revision.
How does the embedded-module problem land in CIP-013? Supplier disclosure of embedded communication components is not currently a named CIP-013 R1.2.5 expectation, but the case for adding it is strong. Whether that change rides on Phase 2, on a future CIP-013 revision, or on regional guidance is open.
Final Thought
The 2023 SAR did the structural work of describing why protocol converters do not fit cleanly into CIP-002's existing categorization geometry. A decade of advisories, capped by BRIDGE:BREAK, has delivered the threat evidence the drafting team can now reference instead of inferring. The case for treating these devices as in-scope is stronger this month than it was last month, and asset owners do not need to wait for the standard to start the work. The discovery, segmentation, hardening, and detection actions are the same regardless of how the categorization debate ends. The rule will catch up. The threat already has.
Sources and Further Reading
Phase 2 and CIP-002 Context
NERC Project 2021-03 CIP-002 Transmission Owner Control Centers: project page
2023 Communication Protocol Converters SAR: direct link
Ampyx Cyber: Policy Pulse: NERC CIP-002 SAR Project 2021-03
Ampyx Cyber: CIP-002-8, Decoded: Who's In, Who's Out Under the New 2.12
BRIDGE:BREAK and Recent Disclosure
Forescout Vedere Labs BRIDGE:BREAK research: research page
ICS Advisory Project Alert ICSAP-AL-26-04-001: icsadvisoryproject.com
CISA ICS Advisory ICSA-26-111-10 (Silex SD-330AC and AMC Manager)
CSO Online coverage: Riddled with flaws, serial-to-Ethernet converters endanger critical infrastructure
Historical Vulnerability Record
Moxa NPort: ICSA-16-336-02a, ICSA-20-287-01
Lantronix XPort: ICSA-24-023-05, ICSA-25-105-05
Digi RealPort: ICSA-23-243-04 (CVE-2023-4299)
Historical Incidents
2015 Ukraine: SANS / E-ISAC analysis of the December 2015 Ukrainian power grid attack
2025 Poland: CERT Polska energy sector incident reporting
