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. Vulnerability & CVE Mapping
Why Version Accuracy Matters
A Software Master List (SML) isn’t just a list for the sake of Class; it is your Vulnerability Map. When a new CVE is announced (e.g., a critical flaw in a specific Linux Kernel), you must be able to instantly search your SML to identify which vessels and which onboard systems are exposed.
“Establish a systematic process to monitor and evaluate cyber security vulnerabilities (UR E26 §4.1.2.1).”
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. Management of Change (MoC) per UR E22 §6
After FAT, the system supplier and owner must manage all changes in accordance with UR E22 §6.2. This applies to hardware, software, and configurable parameters.
Before a change, you MUST determine criticality, impact on existing documentation, and whether Class/Owner approval is required up-front.
Every major update requires a documented Regression Test and a verified Roll-back procedure to return to a known stable state if the change fails.
Mandatory Change Records (§6.11)
Your registry (PMS or SML) must contain at least these 5 items for every change:
7. Ownership & Dependency Mapping
Per UR E27 and UR E22 §6.5, software must be uniquely identifiable and child-linked to its hardware parent.
Map the version to the Unique Asset ID of the hardware. This is mandatory for traceability during component swaps.
Define authorities (§6.6) for software master files: Shipowner, OEM, or 3rd Party.
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...
