Part of the PROTECT Playbook ← Return to Hub

Software & Firmware Patch Management

Regulatory Context: IACS UR E27 (Section 4.4) requires a documented process for identifying, testing, and deploying security patches. This module defines the “Safety-First” approach to patching critical maritime assets without risking operational downtime.

In a maritime environment, “Patch Tuesday” does not exist. We cannot allow automated updates to run on a vessel mid-voyage. However, leaving systems unpatched for years creates a massive security debt. The solution is a Risk-Based Patching Cycle that prioritizes stability over speed.

The OT Patching Hierarchy

On a ship, patching is not just an IT task; it is a maintenance event similar to overhauling a generator. Because OT systems are interconnected, a single OS update can break the communication drivers between the HMI and the PLC, leading to a loss of control. We use a tiered hierarchy to ensure that we only touch the most critical vulnerabilities during scheduled maintenance windows, ensuring the “Digital Seaworthiness” of the vessel remains intact while we close security gaps.

Tier 1: OS Security Patches

Critical Windows/Linux vulnerabilities. These should be deployed via a local WSUS server or offline media during port stays.

Tier 2: OT Firmware

PLC and Controller updates. These are High Risk and should only be performed under OEM supervision or after a full system backup.

The “Safe-to-Patch” Protocol

Before any update is applied to a Category II or III system (UR E26 definition), the ETO must verify the following protocol to satisfy class surveyors:

Step Requirement Proof for Surveyor
1. Vendor Approval OEM must certify patch compatibility with AMS/ECDIS. Email or Technical Bulletin.
2. Pre-Patch Backup A full “Golden Image” backup must be taken. Verified backup file on Ship’s Vault.
3. Deployment Window Patching only in “Safe State” (Port/Anchor). Entry in Cyber Security Logbook.

Post-Update Validation

The moment an update finishes is the highest point of risk. To prevent “Dark Ship” scenarios, the ETO must verify the system before handing it back to the Bridge.

1. Verification of Function

Does the AMS still receive sensor data? We verify “Live Data” flow, not just the login screen.

2. Resource Monitoring

Monitor CPU/RAM for 30 minutes. Ensure no “memory leaks” are caused by the new patch.

3. Rollback Capability

The ETO must be able to restore the Pre-Update Image within 15 minutes if failure is detected.

ETO Change Management Strategy
Vulnerability Scanning (Passive)

Use OT monitoring tools to identify outdated firmware without actively disrupting system traffic.

Offline Update Media

Download patches on a secure shore PC and transfer via a scanned, encrypted USB drive.

Advisor Tip: The 15-Day Rule. For non-critical security patches, wait 15 days after release before deploying. This allows the global community to find bugs before they reach your ship.

Next Section

Supply Chain & Vendor Security

Supply Chain & Vendor Security Regulatory Context: IACS UR E27 (Section 4.5) mandates the management of third-party risk...

Scroll to Top