Software & Firmware Tracking
UR E26 §4.1.1.1 & §4.1.1.3.2: The vessel asset inventory shall identify the software name and version (including application programs, operating systems, and firmware). Additionally, per §4.1.1.3.2 and §4.1.1.4.4, a ‘Ship cyber security and resilience program’ must be established to manage the lifecycle of these digital assets through a software maintenance and update policy.
1. The Software Master List (SML)
Every Computer Based System (CBS) identified in your hardware inventory must have its software “DNA” documented. This is critical for Vulnerability Management; you cannot protect a system if you do not know which version of code is running its core functions.
Essential Documentation Points:
- Application Software: Specific program versions (e.g., PMS v4.2).
- Manufacturer & Type: The original developer of the software component (e.g., Kongsberg, ABB).
- Functionality Purpose: A short description of what the software actually does (e.g., “Main Engine Governor Logic”).
- Operating Systems: Windows Builds, Linux Kernels, or RTOS versions.
- Firmware: Hard-coded software in PLCs, Sensors, and Controllers.
- Patch Level: The latest security update applied (e.g., KB number).
2. How to Extract Version Data
Most Bridge/Engine HMIs have a “System Info” or “About” page. Audit Tip: Take a photo of this screen during physical surveys as evidence for the Class Surveyor.
For “headless” PLCs, use OEM software (e.g., TIA Portal) to pull the firmware build number and checksum for verification.
3. Maintenance & Patch Tracking
4. Criticality & Categorization (E22/E26)
Surveyor Tip: Justifying Category I
In your Asset Inventory, you should justify why a system is designated as Category I. If you cannot provide technical evidence (e.g., an architectural diagram proving no safety impact), Class will default the asset to Category II or III, triggering mandatory vulnerability testing and more frequent update cycles.
“CAT I – Asset provides non-essential data logging only; no control interface to PMS or Propulsion.”
5. The Update Lifecycle (§5.3.1)
Tracking is only half the battle. UR E26 requires a formal Software Maintenance Policy to ensure updates don’t introduce new risks to vessel stability.
Updates for Category II/III systems must be verified by the manufacturer or tested in a non-production environment before deployment to the ship’s OT network.
For every major firmware update, a “Restore to Baseline” procedure must be documented. If the update fails, the vessel must be able to return to its previous safe state immediately.
6. Ownership & Responsibility Mapping
Per UR E27, software cannot exist as a standalone entry; it must be mapped to a specific hardware host. Furthermore, UR E26 requires clear ownership of the update lifecycle.
Your inventory must record the Unique Asset ID of the hardware where the software is installed. This is mandatory for traceability during a hardware swap.
Specify who is authorized to update: Shipowner, OEM, or Third-Party. This prevents unauthorized “freelance” patching by crew or uncertified technicians.
Surveyor Verification & Audit Readiness
During surveys, Class may verify software versions by vulnerability scanning or manually inspecting HMIs to ensure they match the “As-Approved” baseline. Have the following ready:
- SML: E27-compliant inventory.
- Agreements: OEM update contracts.
- Change Logs: Last 3 update records.
- HMI Screenshots: “About” page photos.
- Test Evidence: Pre-deployment records.
Next Section
Marine Protocol Guides
Deep Dive: Protocol Intelligence Looking for detailed risk analysis and hardening guides for NMEA, Modbus, and AIS? VIEW...