IACS Unified Requirements E26/E27 - Cyber Resilience of Ships and On-Board Systems

UR E26 Goal 3 (Detect) requires monitoring + detection capabilities to identify cyber incidents. Logging: all CBS log security-relevant events (authentication + authorization + configuration change + privileged action + network connection + failure); log centralisation where feasible to dedicated log server / SIEM (on-board or hybrid with shore SOC); log retention per criticality + per applicable maritime regulations (typically 90 days online + 1 year archive minimum); log integrity protection (signed + write-only + tamper-evident); log review on routine basis. Network monitoring: passive network traffic analysis on OT segments (Dragos / Claroty / Nozomi class IDS + flow analysis); intrusion detection rules + signatures + behavioral; anomaly detection (baseline + deviation); alert generation for: failed auth + new device + unusual port + malware signature + lateral movement + data exfilt

• Logging configuration per CBS + event types + retention policy
• SIEM or centralised log server deployment + retention + integrity protection
• Network IDS deployment + rule set + maritime-specific signatures
• Alert workflow + on-board response + shore SOC handoff + IAS integration
• Audit trail review + periodic + configuration change tracking + emergency override review

• Logs only on individual CBS without centralisation
• Network monitoring active scanning prohibited on OT (passive required)
• Alerts not tied to vessel alarm system (overlooked by crew)
• Audit trail review absent (logs collected but not reviewed)
• Shore SOC integration impractical due to vessel connectivity

UR E26 Goal 1 (Identify) requires the shipyard + ship owner to maintain a comprehensive inventory of Computer Based Systems (CBS) onboard the ship. CBS are defined as: programmable electronic systems essential or important to ship safety, security, ship operation, propulsion, navigation, communication, cargo, or hull integrity. Requirements: asset inventory listing CBS with type + function + criticality + interfaces + network connections + suppliers + version + patch level; network architecture diagram showing ship network zones + segmentation + boundary devices + interconnections + remote access paths + wireless networks + external interfaces (satellite + 4G/5G + port + shore + supplier remote support); identification of safety-critical + operationally-critical CBS for risk assessment prioritisation; mapping of CBS to OT (Operational Technology) + IT (Information Technology) + IMS (Inte

• CBS asset register with criticality + interfaces + suppliers + versions + patch level
• Network architecture diagram with zones + segmentation + boundary + remote + wireless + external
• Criticality ranking (safety / operational / business) of each CBS
• OT vs IT vs IMS/DP/AMS/ECS classification matrix
• Periodic survey verification log + modification update audit trail
• Class society approval documentation of inventory + architecture

• Incomplete CBS inventory missing legacy + retrofit + integrated systems
• Network architecture stale (not reflecting current connectivity)
• Missing satellite + 4G/5G + shore + supplier remote interconnects
• No criticality ranking driving risk prioritisation
• Lifecycle maintenance not enforced (architecture diverges from reality)

UR E26 Goal 1 (Identify) also requires a Ship Cyber Resilience Plan (SCRP) covering scope + assumptions + roles + responsibilities + risk assessment methodology + control measures + maintenance procedures + incident response + recovery + training. The SCRP is reviewed and approved by the classification society (Member Society) as part of new ship construction + periodic class survey. Risk assessment for each CBS evaluates: threats (external cyber threats + insider + supply chain + accidental + environmental); vulnerabilities (technical + procedural + physical); likelihood + consequence + risk score; treatment decisions (accept + mitigate + transfer + avoid); residual risk + monitoring. Risk methodology may be derived from ISO/IEC 27005 + NIST SP 800-30 + IEC 62443-3-2 + maritime-specific (BIMCO + IUMI). The SCRP plus risk assessment forms the foundation for control measures under Protect

• Ship Cyber Resilience Plan (SCRP) document + approval by Member Society + version control
• Risk assessment register per CBS with threats + vulnerabilities + likelihood + consequence + treatment
• Risk methodology selection rationale (ISO/IEC 27005 / NIST SP 800-30 / IEC 62443-3-2 / maritime-specific)
• Class society initial construction + periodic + post-modification survey records
• Change management log + post-modification re-assessment
• Training records tied to SCRP roles + responsibilities

• SCRP missing or not approved by Member Society
• Risk assessment generic + not CBS-specific
• Class society survey only at delivery (no periodic + post-modification)
• SCRP not updated after retrofit or modification
• Risk register stale (treatment decisions not tracked)

UR E26 implementation requirements cover training + supplier management. Crew training: cyber awareness for all crew (phishing + social engineering + USB hygiene + password + reporting); role-based training for Captain + Officers + IT/ETO + Engineer + Bridge watch; refresher annually + post-incident + post-update; class society training requirements + STCW (Standards of Training Certification and Watchkeeping) cyber competency integration; vendor / OEM training for technicians installing or maintaining CBS. Cyber hygiene: USB / removable media policy + drills + safe use of crew internet + safe use of personal devices + safe use of email + browser hygiene; bring-your-own-device (BYOD) policy + segregation. Supplier + OEM management: vendor cyber maturity assessment + due diligence + contract clauses (security requirements + audit right + breach notification + patch obligations + end-of-li

• Annual cyber awareness training records + attendance + assessment
• Role-based modules for Captain + Officer + ETO + Engineer + Bridge + STCW certificate addition
• USB + BYOD + crew internet + email + browser policies + drill logs
• Vendor / OEM cyber maturity assessment + contract clauses + SBOM disclosure
• Supply chain risk assessment per CBS lifecycle (acquisition / install / maintain / dispose)

• Training generic (not maritime-specific)
• STCW cyber competency not integrated into crew certification
• Vendor contracts silent on cyber + SBOM + breach notification
• Bring-your-own-device unrestricted in safety-critical zones
• Supply chain risk only at acquisition (not maintenance / disposal)

UR E26 Goal 2 (Protect) requires access control + authentication + authorization mechanisms for all CBS. Unique user identification (no shared accounts where feasible); strong password policy (per NIST SP 800-63B + IEC 62443 + ship operational reality); multi-factor authentication (MFA) for privileged access + remote access + safety-critical CBS access; role-based access control (RBAC) tied to job function (Captain + Chief Engineer + Officer + Crew + Vendor + Service Technician); least privilege; separation of duties; account lifecycle management (provisioning at hire / posting + de-provisioning at end of contract + rotation at periodic intervals); session management + timeout + lock + termination; privileged access management (PAM) with logging + approval workflow + just-in-time access; vendor / service technician access with prior authorisation + supervision + time-limited credentials.

• User account inventory per CBS + role + lifecycle status
• MFA enrolment evidence for privileged + remote + safety-critical access
• RBAC matrix tying role (Captain/CE/Officer/Crew/Vendor) to CBS permissions
• Account provisioning + de-provisioning audit trail + crew rotation procedure
• Privileged access management (PAM) logs + approval workflow + JIT access
• Vendor access pre-authorisation + supervision + time-limited credentials log

• Shared bridge or engine room workstation accounts (no individual accountability)
• MFA absent on safety-critical CBS access
• Vendor permanent credentials still active + unsupervised remote access
• RBAC over-permissive (everyone admin)
• Account lifecycle not tied to crew rotation

UR E26 Goal 2 (Protect) requires malware defence + patch management + vulnerability management + system hardening. Malware defence: anti-malware (signature + heuristic + behavioral) deployed on CBS where supported; application whitelisting (allow-listing) for safety-critical CBS where anti-malware not feasible (DP + navigation + propulsion) per IEC 62443 + USB / removable media controls (block + scan + approve + log); email + web content filtering; supply chain malware checks (vendor patches + firmware + updates verified before installation). Patch management: patch identification per CBS + version + criticality; vendor + OEM patch lifecycle tracking; risk-based patch testing on shadow / staging environment before production; emergency patch procedure with vessel availability constraints; patch survey class society notification for safety-critical CBS patches; patch deferral risk accepta

• Anti-malware deployment register per CBS + application whitelisting for safety-critical
• USB / removable media control register + scan + approval workflow
• Patch management per CBS + vendor lifecycle + testing + class society notification
• Vulnerability scan / CVE tracking + ICS-CERT subscription + MUST advisories
• Hardening baseline per CBS + STIG/CIS adaptation + secure boot + TPM evidence
• Supply chain malware check + vendor patch signature verification

• Anti-malware not feasible on safety-critical CBS without compensating whitelisting
• USB controls absent allowing unverified media insertion
• Patches deferred indefinitely without risk acceptance documentation
• No vulnerability scanning or CVE tracking on OT
• Hardening baseline absent (default vendor configuration in production)

UR E26 Goal 2 (Protect) requires network segmentation following IEC 62443 zones and conduits model. Ship networks must be segmented into zones based on criticality + function: Untrusted (internet + crew internet + guest networks); Business / Administrative (crew + shore administrative); Operational (navigation + cargo + ballast); Safety-Critical (propulsion + steering + DP + fire/safety systems); Equipment vendor networks. Each zone has documented security requirements + perimeter. Conduits between zones use firewalls + data diodes (unidirectional gateways) + access control + monitoring + logging. Direct connections between Untrusted and Safety-Critical zones are prohibited. DMZ patterns used for required interconnects. Industrial firewalls + Industrial DMZ + air-gap where feasible. Wireless networks isolated from safety-critical zones. External interfaces (satellite + 4G/5G + remote sup

• Zone and conduit diagram per IEC 62443 zones (Untrusted + Business + Operational + Safety-Critical + Vendor)
• Firewall + diode + DMZ + VPN configuration register + rule baseline
• Wireless network isolation evidence from safety-critical zones
• External interface (satellite + 4G/5G + remote + port) boundary security architecture
• Class society architecture approval + periodic survey re-review
• Direct connectivity ban evidence (Untrusted to Safety-Critical air-gap)

• Flat network without IEC 62443 zoning
• Crew internet directly connected to operational network
• Vendor remote support bypassing boundary controls (direct VPN to OT)
• Wireless networks not isolated from safety-critical zones
• Firewall rules permissive (any-any) between zones

UR E26 Goal 2 (Protect) requires controls for remote access + wireless + physical security. Remote access: required for vendor / OEM / shore support during voyage; principles: prior authorisation per session + MFA + jump host / bastion + time-limited + recorded session + supervised + scoped to specific CBS; VPN with strong cryptography (AES-256 + IPsec/TLS 1.3); split-tunnel prohibited; remote access logging + alert on connection + termination on timeout. Wireless networks: required for crew internet + sensor + IoT + integrated bridge wireless updates; segregation from safety-critical networks; WPA3-Enterprise + RADIUS authentication where feasible; rogue access point detection + monitoring; guest networks isolated; cellular (4G/5G) modems for shore connectivity with cellular firewall + APN segmentation; Wi-Fi calling vulnerabilities considered. Physical security: CBS equipment in locked

• Remote access procedure + per-session authorisation + MFA + recording + termination log
• Wireless network inventory + segregation evidence + WPA3 + RADIUS + rogue AP detection
• Physical security access controls + tamper seals + USB locks + KVM controls
• VPN configuration + AES-256 + IPsec/TLS 1.3 + no split-tunnel evidence
• Visitor / technician log + escort procedure + bridge / engine room access tracking

• Remote vendor support permanent always-on connection (no per-session auth)
• Crew Wi-Fi on same network as navigation / OT
• USB ports unlocked + no physical compartment protection on bridge
• No rogue AP detection (employee personal hotspot in vicinity)
• Visitor / technician access not logged or escorted

UR E26 Goals 4 (Respond) + 5 (Recover) require incident response + recovery capabilities. Incident Response Plan (IRP) covers: detection triggers + classification (safety-impact + business-impact); response team roles + responsibilities (Captain + Officer + IT + shore support + class society); response procedures per incident category (malware + ransomware + unauthorised access + physical tampering + denial-of-service + supply chain); containment + eradication procedures; escalation + reporting (Captain + shore + flag administration + class society + cyber insurer + national CSIRT + IMO if required); incident communication internal + external + media + stakeholders. Recovery: backup strategy per CBS (frequency + location + retention + offline copies + air-gapped); restoration procedures + recovery time objective (RTO) per CBS criticality + recovery point objective (RPO); recovery testing

• Incident Response Plan + categories + escalation + communication
• Response team appointment + roles (Captain / Officer / IT / shore / class / insurer)
• Backup strategy per CBS + RTO + RPO + offline + air-gapped copies
• Recovery testing + tabletop exercise + degraded mode operation log
• Post-incident review + root cause + corrective action + sharing with Member Society

• IRP exists on paper but no tabletop exercise (crew unfamiliar)
• Backup strategy lacks offline / air-gapped copies (encrypted by ransomware)
• Recovery time objective unrealistic for safety-critical CBS
• No degraded mode operation procedures (full shutdown vs voyage continuation unclear)
• Lessons learned not shared with Member Society or industry

IACS Unified Requirement E26 Cyber Resilience of Ships adopted April 2022 by International Association of Classification Societies (IACS). Applies as a mandatory class requirement to new ships contracted for construction from 1 July 2024 (originally 1 January 2024, delayed by IACS at Board level). Adopted by all 12 IACS Member Societies (ABS American Bureau of Shipping + BV Bureau Veritas + CCS China Classification Society + ClassNK Nippon Kaiji Kyokai + CRS Croatian Register of Shipping + DNV Det Norske Veritas + IRS Indian Register of Shipping + KR Korean Register + LR Lloyds Register + PRS Polish Register of Shipping + RINA Registro Italiano Navale + RS Russian Register) and incorporated into their respective Rules. Applies to: all new ships above 500 GT under SOLAS or otherwise contracted under IACS Member Society class. Scope: ship-level cyber resilience covering Computer Based Syst

• UR E26 + E27 applicability register per new ship contract date
• Member Society class society identification + UR adoption evidence
• IMO MSC.428(98) SMS audit integration documentation + cyber risk management in SMS
• Goal-based 5-function (Identify/Protect/Detect/Respond/Recover) mapping evidence
• BIMCO Guidelines + IEC 62443 + NIST CSF + ISO 27001 coordination matrix

• UR E26 ignored on ships contracted before 1 July 2024 (retrofitting risk + voluntary uptake)
• SMS-cyber integration (MSC.428(98)) separate from UR E26 (should be unified)
• Goal-based approach treated as prescriptive checklist
• Member Society Rule variations not tracked
• Missing IACS Rec 166 transition documentation

UR E26 requires class society survey and approval at initial construction + periodic + post-modification. Initial construction survey: class society reviews + approves Ship Cyber Resilience Plan (SCRP) + CBS inventory + network architecture + risk assessment + control implementations + IRP + recovery procedures + training + supplier management; certifies vessel meets UR E26 requirements at delivery. Periodic survey: typically annual or per Member Society Rules; verifies continued compliance + tests representative controls + reviews changes + lessons learned + training updates + incident history. Post-modification survey: re-assessment after major CBS modification + retrofit + network changes + new supplier; updated documentation + reapproval. Owner documentation handover: complete documentation package received from shipyard + suppliers + OEMs + class society approval + survey reports; o

• Initial construction survey report + class society approval of SCRP + CBS + architecture + IRP
• Periodic survey report + representative control testing + review of changes + incidents + training
• Post-modification survey + re-assessment + documentation update + reapproval
• Owner documentation handover + ongoing maintenance + access for crew + shore + insurer + auditor
• Class society surveyor competency + IACS training + accreditation

• Initial survey only paper review without technical testing
• Periodic survey skipped or perfunctory (no representative testing)
• Post-modification not triggered for incremental retrofit
• Documentation handover incomplete (some supplier documents missing)
• Class society surveyor lacks cyber competency

UR E27 requires equipment manufacturers to provide comprehensive documentation package to ship owner at delivery covering: SBOM (per UR E27 SBOM control); security capabilities mapping to IEC 62443-4-2 CRs + SL profile + Category; hardening guide + secure configuration baseline; secure update procedure + rollback + emergency reverse; user authentication setup + RBAC role definitions + default credential change procedure; logging configuration + event types + retention; backup + recovery procedure; vendor remote support agreement (per UR E26); vulnerability disclosure policy + CVE notification + advisories; lifecycle support commitment + EOL planning; type approval certificate + class society approval reference. Coordination with international maritime cyber framework: IMO Resolution MSC.428(98) Maritime Cyber Risk Management in SMS (effective 1 January 2021 SMS audits); IMO MSC-FAL.1/Cir

• UR E27 documentation package per CBS + SBOM + capabilities + hardening + auth + logging + backup + lifecycle
• IMO MSC.428(98) SMS cyber risk integration + audit evidence + ISM Code
• IEC 62443 + NIST CSF + ISO 27001 + BIMCO mapping matrix per CBS
• Vendor coordination matrix + lifecycle commitment + EOL planning + replacement
• 2024-2025 readiness: IACS Rev 2 + NIS2 + USCG + IUMI + MASS + quantum crypto

• Documentation package incomplete (vendor refuses or omits SBOM or hardening guide)
• SMS-cyber integration only after class society survey, not continuous
• Mapping matrix to IEC 62443 / NIST / ISO absent for compliance audits
• Vendor EOL commitment shorter than ship operational life
• No NIS2 maritime applicability assessment for EU-flagged vessels

UR E27 requires equipment manufacturers to deliver hardened CBS with secure default configuration + secure communications. Hardening: minimum services + disabled debug + locked BIOS + secure boot + Trusted Platform Module (TPM) or equivalent root of trust + signed boot loader + secure firmware update + tamper detection; vendor-provided hardening guide + secure configuration baseline; default credentials changed mandatorily before delivery + no shared default credentials across deployments. Secure communications: cryptographically protected communications between CBS components (TLS 1.2/1.3 + IPsec + WireGuard + maritime-specific); strong cryptographic algorithms (AES-256 + RSA-2048+ / ECDSA / EdDSA + SHA-256+); key management + lifecycle + rotation; certificate management (X.509 + Public Key Infrastructure or pre-shared keys for constrained CBS); integrity protection of communications (H

• Hardening baseline per CBS + vendor-provided + secure config evidence
• Secure boot + TPM + signed firmware + tamper detection per equipment
• Communications cryptography matrix + TLS/IPsec config + algorithm/key size + rotation
• Key + certificate management + lifecycle + PKI or PSK selection rationale
• Maritime-specific compensating controls for NMEA / Modbus / legacy bus protocols

• Default credentials still active post-delivery (vendor delivery skipped change)
• Secure boot disabled for vendor convenience
• Communications over plain TCP without TLS in safety-critical loops
• Key management absent (static keys deployed once, never rotated)
• Legacy bus protocols (Modbus + NMEA 0183) without compensating controls

UR E27 requires equipment manufacturers to deliver CBS with logging + forensic readiness capabilities aligned with IEC 62443-4-2 CR 2.8-2.12 (Auditable events) + FR 6 (Timely Response to Events). Logging requirements: security-relevant events captured (authentication success/failure + authorization decisions + privilege escalation + configuration change + system start/stop + safety events + tamper detection + integrity check failure + control disablement + emergency override); event log format standardised (timestamp + source + event type + user + outcome + detail per RFC 5424 or vendor format with documented schema); event log storage on equipment (local) + forwarded to centralised log server per UR E26 where supported; log integrity protection (signed + write-once + tamper-evident); log retention per maritime regulation + class society + insurer minimum (typically 90 days online + 1 ye

• Event type matrix per CBS (auth + authz + privilege + config + system + safety + tamper)
• Log format documentation + RFC 5424 alignment + schema for vendor format
• Log integrity protection + retention policy + class society requirement alignment
• NTP / GPS time synchronisation + accurate timestamp evidence
• Forensic image acquisition procedure + chain of custody + vendor cooperation

• Insufficient event types (no privilege escalation or config change logged)
• Log format vendor-specific without schema (forensic correlation impossible)
• Logs stored on equipment only without forwarding (lost on equipment failure)
• Time drift on equipment (no NTP) breaking forensic correlation
• Vendor refuses forensic cooperation citing proprietary protection

UR E27 requires equipment manufacturers to provide Software Bill of Materials (SBOM) and demonstrate secure development. SBOM contents per CISA SBOM Minimum Elements + SPDX or CycloneDX format: component name + version + supplier + license + dependency relationships + hash; coverage of: operating system + libraries + frameworks + open source + commercial components + firmware. SBOM provided to ship owner at delivery + updated on patch / firmware update; supports vulnerability matching (CVE feeds + open source advisories) by owner over equipment lifecycle. Secure Software Development Lifecycle (SDLC) per IEC 62443-4-1: governance + roles + security requirements + threat modeling + secure design + secure coding + code review + static analysis + dynamic analysis (SAST + DAST + IAST) + dependency scanning + penetration testing + verification + documentation. Type approval process: class soci

• SBOM per CBS in SPDX / CycloneDX format + delivered to owner at install + updated on patch
• Secure SDLC documentation per IEC 62443-4-1 + threat model + secure coding + testing
• Type approval evidence package + class society review + certification per Member Society
• Code signing + secure boot + integrity verification + signed firmware update + rollback protection
• Vendor vulnerability disclosure policy + CVE tracking + advisories + owner notification

• SBOM absent or stale (delivered once, never updated)
• Secure SDLC not implemented or evidence missing (no threat model + no SAST)
• Type approval paper review only without testing
• Firmware update unsigned or no rollback protection (brick risk)
• Vendor vulnerability disclosure silent (CVEs not announced to owner)

IACS Unified Requirement E27 Cyber Resilience of On-Board Systems and Equipment adopted April 2022 by IACS. Complements UR E26 (ship-level) by addressing equipment / system level. Applies to: third-party equipment + OEM systems installed on ships subject to UR E26. Effective: new ships contracted from 1 July 2024. System categorization by impact on ship safety + operation: Category I (essential for ship safety + propulsion + steering + DP + navigation + alarm + safety systems); Category II (essential to ship operation + cargo + ballast + bilge + emission); Category III (administrative / convenience / crew). Higher category = stricter security capability requirements. Security capability profiles map to IEC 62443-3-3 Security Levels (SL 1 / SL 2 / SL 3 / SL 4): Category I typically SL 2-3; Category II typically SL 1-2; Category III typically SL 1. UR E27 requires equipment manufacturers /

• UR E27 applicability matrix per equipment + supplier + installation date
• Category I/II/III classification register per CBS + criticality justification
• IEC 62443 Security Level (SL) profile per equipment per category
• Type approval certificate + class society approval per Member Society + UR E27
• Documentation package received from supplier for each piece of equipment

• Equipment without UR E27 classification (legacy or pre-2024)
• Category I/II/III classification absent or inconsistent across CBS
• IEC 62443 SL profile not specified by supplier or owner
• Type approval certificate missing for safety-critical CBS
• Documentation package incomplete (no SBOM + no patch lifecycle commitment)

UR E27 specifies security capabilities required by equipment vendors / OEMs per system category. Capabilities organised by IEC 62443-4-2 Component Requirements (CR) covering 7 Foundational Requirements (FR): FR 1 Identification and Authentication Control (CR 1.1-1.13); FR 2 Use Control (CR 2.1-2.12); FR 3 System Integrity (CR 3.1-3.9); FR 4 Data Confidentiality (CR 4.1-4.3); FR 5 Restricted Data Flow (CR 5.1-5.4); FR 6 Timely Response to Events (CR 6.1-6.2); FR 7 Resource Availability (CR 7.1-7.8). UR E27 specifies which CRs apply per Category I/II/III at which Security Level (SL): Category III SL 1 basic; Category II SL 1-2; Category I SL 2-3 (high resilience to advanced threats). Each capability has detailed requirements: e.g. CR 1.1 Human user identification + authentication; CR 1.2 Software process + device identification; CR 1.5 Authenticator management (password + key + token lifec

• Capability mapping per CBS + IEC 62443-4-2 CR + Category + SL profile
• Implementation evidence per CR (FR 1 Auth / FR 2 Use Control / FR 3 Integrity / FR 4 Confidentiality / FR 5 Restricted Data / FR 6 Response / FR 7 Availability)
• Security Level validation testing + class society witness
• Type approval certificate per CBS + Member Society + UR E27 reference
• Vendor / OEM capability documentation provided to owner

• Capability mapping incomplete or wrong SL claimed
• FR 6 (timely response) often weak in OT equipment
• FR 7 (resource availability) under-tested (DoS resilience)
• Type approval testing scope narrow (paper review only)
• Owner does not receive capability documentation from vendor

UR E27 requires equipment manufacturers to provide secure update + patch mechanisms supporting ship lifecycle (typically 20-25 years). Update mechanisms: secure update procedure (signed packages + verification + rollback protection + atomic apply + emergency reverse); update verification + integrity check + rollback on failure; update delivery methods (USB + network + over-the-air OTA via satellite for shore-managed CBS + crew-installed) per CBS criticality; vendor lifecycle support commitment in contract (minimum years + security patches + critical patches + EOL planning); coordination with class society survey timing + dry-dock maintenance windows; patch testing on shadow / staging where feasible; emergency patch procedure for actively exploited vulnerabilities. Maintenance: vendor support contract + remote support agreement per UR E26 + on-site maintenance procedures + spare parts + c

• Secure update procedure + signed package + rollback per CBS
• Patch lifecycle commitment in vendor contract + minimum years + critical patch SLA
• Update delivery method per CBS + USB + network + OTA + crew-installed
• Class society survey + dry-dock maintenance window coordination + patch deferral risk acceptance
• End-of-life planning + migration path + replacement equipment same SL

• Updates manual via USB without signing or verification
• Vendor lifecycle commitment short (10 years for 25-year ship)
• OTA updates over insecure channel without signing
• Patches deferred indefinitely without risk acceptance
• EOL equipment kept in service without migration plan

UR E27 requires equipment-level user authentication and authorization mechanisms aligned with IEC 62443-4-2 FR 1 (Identification and Authentication Control) and FR 2 (Use Control). Each CBS must support: unique user identification (no shared accounts where possible + emergency shared accounts logged); strong authentication (password + multi-factor where feasible + smartcard + biometric for high-criticality + key-based for machine accounts); authorization enforcement per RBAC role with least privilege; authenticator management (initial provisioning + change + lifecycle + recovery + revocation); session lock + timeout + termination + concurrent session control; privileged access logging + escalation procedure; emergency access (bridge override) logged + reviewed. Considerations specific to maritime: bridge crew rotation (every 4 hours); single-handed watches; emergency manual override requ

• User account model per CBS + unique ID + shared account justification + logging
• Authentication mechanism per CBS + MFA + smartcard + biometric + key-based per role
• RBAC role definition + least privilege matrix per CBS
• Session management + timeout + lock + concurrent session control evidence
• Emergency bridge override procedure + offline authentication for safety-critical

• Shared bridge crew account without individual accountability
• MFA infeasible on bridge under heavy weather without alternative
• Authorization too permissive (everyone admin)
• Session never timeout on bridge consoles (24/7 operation)
• Emergency override not logged or reviewed