Power management systems are the nervous system of a vessel's electrical plant. They control load sharing between generators, manage blackout prevention, handle automatic start/stop sequences, and coordinate power distribution across the vessel. A PMS failure can cause a blackout. A blackout at sea — particularly during a port entry, in heavy traffic, or in bad weather — can be catastrophic.
Yet in most maritime cybersecurity assessments, the PMS is treated as a low-risk system because it "isn't connected to the internet." That assumption hasn't been accurate for years, and the CVE history of PMS-adjacent products shows why it matters.
What Is a Maritime Power Management System?
A PMS is a SCADA/ICS system designed specifically for vessel electrical management. Major vendors include Kongsberg (K-Chief family), Wärtsilä (UNIC systems), ABB (Onboard DC and Azipod systems), Schneider Electric (marine variants of EcoStruxure), and Rockwell Automation (marine-grade ControlLogix controllers in various integrated systems).
At the hardware level, a PMS typically consists of:
- Industrial PLCs or proprietary controllers running the load management logic
- HMI workstations running Windows-based SCADA software
- A dedicated network (often Modbus, Profibus, or EtherNet/IP) connecting controllers to sensors, breakers, and actuators
- Increasingly: a connection to the vessel's LAN for remote monitoring by shore-based teams
That last point is where things get complicated.
The Remote Monitoring Problem
Modern fleet management has driven the installation of remote monitoring gateways on PMS systems. Vendors like Kongsberg (KDI), Wärtsilä (Expert Insight), and ABB (Ability Marine Advisory System) provide shore-based monitoring portals that collect real-time data from vessel PMS systems.
The data flows out via VSAT or LTE connections. In most installations, this is implemented as a one-way data diode or a VLAN-segmented link. In some installations, it's implemented as a direct internet-facing connection with remote access capabilities for troubleshooting.
Even in well-segmented installations, the HMI workstation running the PMS SCADA software is typically on a network that has some path to the vessel LAN — for maintenance access, for alarm notification, for integration with other vessel systems. That path can be exploited if the SCADA software has a known vulnerability.
The CVE Picture for Maritime OT Vendors
CISA has published hundreds of ICS advisories in the past five years covering PMS-relevant vendors. A sample of the types of vulnerabilities that appear:
Authentication bypass — Several Siemens SIMATIC products used in vessel automation have had authentication bypass vulnerabilities with CVSS scores above 9.0. An unauthenticated attacker on the local network could issue commands to the PLC without credentials.
Remote code execution in HMI software — SCADA HMI packages from multiple vendors have had RCE vulnerabilities in their OPC server components. These are commonly used for PMS integration. RCE on the HMI workstation gives an attacker full control of the SCADA interface.
Insecure firmware updates — Some older generation PLC firmware update mechanisms have lacked integrity verification, meaning a man-in-the-middle during an update could inject malicious firmware.
Denial of service in communications protocols — EtherNet/IP and Modbus TCP implementations in several industrial controllers have had DoS vulnerabilities exploitable by malformed packets. On a vessel PMS network, a DoS condition on a generator controller during a critical manoeuver is not an abstract risk.
None of these vulnerabilities are hypothetical. They are published CVEs with real CVSS scores, real exploitation vectors, and real remediation instructions. The information is publicly available on CISA's ICS advisory portal. What's missing is the process to get that information to the people who can act on it.
Why Maritime Engineers Miss PMS Vulnerabilities
There are several structural reasons why PMS vulnerabilities are systematically overlooked:
Vendor silo mentality — The engineer responsible for the PMS is a marine electrical engineer or automation engineer. They're not monitoring CISA advisories. The IT department, if there is one, doesn't know what a K-Chief is and doesn't have access to the vessel's OT documentation.
"Air gap" assumption — Even on vessels where the PMS has a remote monitoring connection, the people responsible for the system often believe it's air-gapped because the OT network doesn't have direct internet access. The remote monitoring gateway is treated as an exception rather than an attack surface.
No push notification from vendors — Kongsberg, Wärtsilä, ABB, and other maritime OT vendors do publish security advisories — sometimes via CISA, sometimes via their own portals. But they don't push notifications to operators. You have to actively check. Most operators don't.
Long patching cycles — Even when a vulnerability is identified, patching a PMS controller requires vendor involvement, scheduled maintenance, and often physical access. The barrier to patching is high, so there's a tendency to deprioritise assessment. If you're unlikely to patch it, why look for vulnerabilities?
The last point is a false economy. The purpose of vulnerability monitoring isn't just to patch immediately — it's to know your exposure, implement compensating controls, and have an evidence trail for audits. A documented decision to defer patching with compensating controls is defensible. An undiscovered vulnerability is not.
Compensating Controls When Patching Isn't Immediate
On a vessel that's underway, you often can't patch. Here's what you can do:
Network segmentation audit — Verify that the PMS network is not directly reachable from the vessel LAN, crew internet network, or any internet-facing system. Check VLAN configurations, firewall rules, and remote monitoring gateway settings.
Disable unused services — Many SCADA HMI workstations run with OPC, FTP, and remote desktop services enabled by default. If these services aren't needed, disable them. This reduces the attack surface for network-reachable vulnerabilities.
Monitor for anomalous traffic — A traffic baseline on the PMS network allows detection of unexpected communication patterns. Some modern PMS systems include built-in network monitoring; for older systems, a port-mirrored packet capture is better than nothing.
Document and flag — Create a defect item with the vulnerability details, your assessment (affected/not affected), and your compensating controls. Schedule remediation for the next port call with vendor access available. This is your ISM evidence trail.
Setting Up PMS Vulnerability Monitoring
The practical steps to establish monitoring for PMS vulnerabilities:
1. List your PMS vendors — Kongsberg, Wärtsilä, ABB, Rockwell Automation, Schneider Electric, Siemens — whatever's installed across your fleet.
2. Add them to an ICS vulnerability monitoring tool — OTWarden monitors CISA's full ICS advisory feed and sends email alerts filtered to your vendors. Add your fleet's vendors once; receive alerts for all of them automatically.
3. Record firmware versions — When you receive an alert, you need to know whether your installed firmware is in the affected range. The more complete your asset register, the faster the relevance assessment.
4. Create a simple triage process — When an alert arrives: check affected version ranges against your asset register, document your assessment outcome, raise a defect item if affected, schedule remediation at the next appropriate maintenance window.
5. Integrate into your SMS — Vulnerability monitoring should be a named procedure in your Safety Management System, with defined responsibilities and a record-keeping requirement. This is the evidence trail IMO 2021 and IACS E26 require.
A Note on the Windows Layer
Many PMS HMI workstations run on Windows — often older versions that the PMS vendor has certified against and is reluctant to move away from. Windows XP, Windows 7, and Windows 10 LTSC installations are all present in vessels currently operating.
These Windows instances receive standard Microsoft CVEs in addition to the PMS application vulnerabilities. A Windows RCE in an unpatched HMI workstation is a direct attack path to the SCADA interface. Windows patching for PMS systems requires vendor qualification testing before deployment — which takes time — but it can't be ignored indefinitely.
The patch lifecycle for a PMS Windows HMI is typically: Microsoft publishes patch → vendor tests compatibility → vendor releases certified patch bundle → operator deploys at next maintenance opportunity. This can take 3-12 months. The CISA ICS advisory monitoring process needs to account for this delay and ensure compensating controls are documented for the intervening period.
Conclusion
PMS vulnerabilities are real, they're published, and they affect vessels in your fleet right now. The gap isn't technical — it's process. A vulnerability monitoring process that covers your maritime OT vendors, feeds alerts to the people responsible for those systems, and generates a documented audit trail is the single most cost-effective cybersecurity improvement most maritime operators can make.
OTWarden provides this process out of the box. Add your PMS vendors to your watchlist — Kongsberg, Wärtsilä, ABB, or any others — and receive email alerts the moment CISA publishes a relevant advisory. Start a free trial.