Does UR E26/E27 Apply to Fire Detection?

It does, and at the highest consequence class. IACS UR E22 categorises computer-based systems by what their failure causes, and fire detection sits in Category III alongside propulsion and steering — systems whose failure could lead to loss of life or loss of the vessel. So a networked per-vehicle detection layer on a ship contracted for construction on or after 1 July 2024 is not only a fire system. It is a Category III CBS with a cyber approval path attached.

What E26 and E27 actually split between them

One governs the ship, the other governs the box. UR E26 covers cyber resilience of the vessel as a collective entity — the secure integration of OT and IT equipment into the ship's network across design, construction, commissioning and operational life — organised around five functional elements: identify, protect, detect, respond, recover. UR E27 covers the cyber resilience of individual on-board systems and equipment, setting the minimum security capabilities a computer-based system must have to be considered resilient, and it is written for third-party equipment suppliers. E27 also reaches into the user-to-system interface and into product design and development for new devices before they go aboard. Both were revised before entry into force — E27 Rev.1 in September 2023, E26 Rev.1 in November 2023 — and apply uniformly to ships contracted for construction on or after 1 July 2024.

Why a detection grid lands in the top category

Because the categorisation is by consequence, not by complexity. UR E22 sorts computer-based systems into Categories I, II and III according to the effect of failure on human safety, vessel safety and the environment. Category II is the alarm, monitoring and control band — CCTV and cargo management sit there, systems whose failure could eventually lead to a dangerous situation. Category III is the band whose failure could lead directly to loss of life, loss of the vessel or serious environmental damage, and fire detection is named in it. Category III carries the highest protection expectations, including network isolation. That produces an asymmetry worth designing around on a modern vehicle carrier: the detection system and the camera system arrive in the same SOLAS amendment but do not necessarily arrive in the same cyber category, and treating them as one commodity network is how the higher-category system inherits the weaker one's exposure.

The capability list is a design specification

E27 is not a policy document — it is a requirements list drawn from an industrial standard. Its system requirements are selected from IEC 62443-3-3, the cybersecurity standard for industrial automation and control systems, and they resolve to roughly 30 security capabilities required of every CBS plus a further 11 required of any CBS sharing an interface with untrusted networks. Read as engineering rather than paperwork, that covers identification and authentication, control of removable media and physical ports, hardening of the default configuration, protected configuration and software integrity, a workable patching and update route, event logging, backup and recovery, and a documented attack-surface analysis. The point of the second set is the one designers miss: the moment a detection layer reports ashore — a fleet console, a remote monitoring feed, a shore-based analytics link — it acquires an interface to an untrusted network and moves into the larger requirement bracket.

Two clocks now land on the same equipment

The fire rule and the cyber rule converge on one cabinet, on slightly offset timetables. Amended SOLAS II-2/20 under Resolution MSC.550(108) requires individually identifiable fixed detection and video monitoring in vehicle, special-category and ro-ro spaces for ships keel-laid on or after 1 January 2026, with existing ships following at the first survey after 1 January 2028. UR E26/E27 attach to the construction contract from 1 July 2024. A PCTC contracted in 2025 and keel-laid in 2026 therefore carries both: the detection system has to satisfy the fire-safety approval and the cyber-resilience requirements, and the vendor side of that is an E27 type approval obtained from a class society rather than a per-vessel argument. Suppliers without it become an integration risk to the yard, because the system cannot simply be installed and certified after the fact.

What this changes for detection architecture

It moves several decisions from late to early. Category III expectations around isolation mean the segmentation between the detection network, the ship's business network and any shore path is an approval-relevant design property, not an installation preference. Update capability becomes a requirement rather than a convenience, because a system with no safe patching route cannot satisfy a capability list that assumes one — and on a 25-year hull that route has to work in service, not only at commissioning. Logging and recovery stop being diagnostic extras and become evidence: the same record that reconstructs an alarm timeline for an investigator is what demonstrates the detect-and-recover elements of E26. None of this is exotic security engineering. It is ordinary industrial practice arriving in a marine fire system that historically was not networked at all.

What it means for owners, yards and class

• For owners: ask a detection vendor for its E27 type-approval status before the contract, not at commissioning — the requirement attaches to the construction contract date, and a non-approved system is a newbuild delay rather than a retrofit chore.
• For yards: the detection layer is Category III, so it should be scoped with propulsion and steering in the cyber design, not bundled with CCTV and cargo systems because it happens to be a sensor network.
• For class: the interesting question on a 2026-onward PCTC is not whether detection exists but whether the individually identifiable detection required by MSC.550(108) and the Category III cyber expectations were designed together or bolted together.
• For everyone: confirm whether a shore-reporting path is in scope. It is the single decision that determines which E27 requirement set applies, and it is usually made by someone thinking about fleet dashboards rather than about class approval.

Sources

• 1. IACS — UR E26 'Cyber resilience of ships' and UR E27 'Cyber resilience of on-board systems and equipment': E26 addresses secure integration of OT and IT equipment into the vessel's network across design, construction, commissioning and operational life, covering identification, protection, attack detection, response and recovery; E27 sets minimum security capabilities for computer-based systems and is directed at third-party equipment suppliers, including user-interface and product-development requirements. E27 Rev.1 adopted September 2023, E26 Rev.1 November 2023; both applied to ships contracted for construction on or after 1 July 2024 — iacs.org.uk. [VERIFY: the IACS press-release page 403s to the bot; confirm the rev dates and the exact applicability wording against the IACS resolution text before publish.]
• 2. IACS — UR E22 'On-board use and application of computer based systems': categorises CBS into Categories I, II and III by the consequence of failure for human safety, vessel safety and the environment; Category II covers alarm/monitoring and control functions (e.g. CCTV, cargo management), Category III covers systems whose failure could lead to loss of life, loss of the vessel or serious environmental damage, and names fire detection alongside propulsion and steering, with the highest protection expectations including isolated zones — iacs.org.uk. [VERIFY: confirm the Category III wording and the placement of fire detection against UR E22 Rev.3 before publish.]
• 3. IEC 62443-3-3 — system security requirements and security levels for industrial automation and control systems; UR E27's system requirements are a selected subset. Reported as roughly 30 security capabilities required of all CBS plus 11 additional for CBS interfacing untrusted networks — iec.ch. [VERIFY: the 30/11 split is from secondary class and industry summaries, not the UR text; confirm the counts before publish.]
• 4. DNV — 'Yards and vendors must act promptly to comply with upcoming IACS cyber security requirements': vendors should pursue type approval from a class society (portfolio assessment, modification analysis, testing and verification, hardening of login, USB/removable-media, network and patching), which reduces project risk and limits per-vessel documentation; non-approved systems cannot be installed on new vessels after the deadline — dnv.com. [VERIFY: this article states a 1 January 2024 contract date, which predates the agreed postponement to 1 July 2024 — use the IACS date and treat the DNV date as superseded.]
• 5. IMO — Resolution MSC.550(108), amendments to SOLAS Regulation II-2/20: individually identifiable fixed fire detection and effective video monitoring in vehicle, special-category and ro-ro spaces; ships keel-laid on or after 1 January 2026, existing ships by the first survey after 1 January 2028 — imo.org.
• 6. Companion RoRoSAFE analysis — 'SOLAS 2026: Individually Identifiable Detection' (the fire-side requirement), 'The Data Pipeline from Deck to Bridge' (where the untrusted-network boundary actually falls), and 'Building the Class Society Evidence Package' (what approval expects on paper).