IACS UR E26 and E27 for Yachts: Applicability and Good Practice

For a yacht project, cyber resilience often becomes visible too late: after the bridge suite is specified, the AV-over-IP design is installed, the SatCom router is commissioned, the automation vendor has its own remote access, and the owner dashboard suddenly wants data from half the vessel.

IACS UR E26 and UR E27 are now central references because they push cyber thinking into the design, integration and evidence stage. UR E26 addresses cyber resilience of ships at ship level. UR E27 addresses cyber resilience of onboard systems and equipment. IACS has stated that revised requirements apply to new ships contracted for construction on and after 1 July 2024, with applicability depending on vessel type, size and scope.

For YachtByte, the editorial point is not that every yacht article should claim these requirements apply. The point is that E26 and E27 show where classed vessel cyber expectations are heading: documented systems, controlled interfaces, supplier evidence, lifecycle support, secure integration and surveyable records.

UR E26 is ship-level. It is concerned with the vessel as an integrated cyber-resilient system. Think networks, zones, interfaces, system dependencies, integration evidence, response and recovery.

UR E27 is system and equipment level. It is concerned with onboard systems and equipment that may be supplied by manufacturers, integrators or vendors. Think secure development, access control, interfaces, hardening, update capability, documentation and lifecycle support.

On a yacht, the practical split is:

• E26 thinking: how the yacht's systems are connected and governed.
• E27 thinking: whether the products installed onboard support cyber-resilient operation.

The distinction matters during procurement. A beautifully designed vessel network can still be weakened by one product with shared admin accounts, no logging, unclear update process and a permanent cloud tunnel. Equally, cyber-capable products can still be installed into a poor vessel architecture.

Applicability depends on class, build contract date, vessel type, size, notation and rules adopted by the relevant class society. A private yacht, commercial yacht, passenger yacht, support vessel or expedition vessel may not be treated the same.

For existing yachts, UR E26/E27 may not be directly mandatory. But they are still useful as a good-practice lens during major refit, bridge replacement, automation upgrade, network redesign, cyber notation, insurance review or newbuild specification.

Treat applicability as a question for flag, class and the project team. Treat the good-practice logic as useful far beyond mandatory scope.

Even when not mandatory, yacht projects can borrow several principles.

First, define system scope. A cyber-resilient design begins by identifying which systems matter: navigation, radio, automation, power, propulsion-related systems, PMS, VMS, AMS, CCTV, access control, SatCom, IT networks, cloud portals and remote support.

Second, map interfaces. Many cyber risks live at boundaries: bridge to owner dashboard, AV to IT, SatCom to firewall, vendor laptop to OT, CCTV to cloud, PMS to shore portal.

Third, require supplier evidence. A supplier should be able to explain authentication, remote access, update process, hardening, logging, backup, vulnerability handling and support lifecycle.

Fourth, preserve commissioning evidence. A yacht should not only receive a working system; it should receive diagrams, account lists, software baselines, configuration backups, access rules and recovery procedures.

Fifth, avoid late cyber retrofits. It is much cheaper to specify network zones, supplier evidence, remote-access controls and data-flow boundaries before the rack is built than to retrofit them after the owner dashboard, AV system, monitoring platform and SatCom services have already been interconnected.

• Which onboard systems are in cyber scope?
• Which systems are safety, navigation, machinery, security or privacy relevant?
• Where are the network zones and conduits?
• Which suppliers need remote access?
• Which products have hardening guidance?
• How are default passwords removed?
• How are software versions and firmware baselines recorded?
• How are vulnerabilities reported and handled?
• Which logs are retained?
• What backups and recovery files are handed over?
• What evidence will class, flag, owner or insurer expect?

These questions should appear in project meetings, not only after a cyber review. The earlier they are asked, the less likely the yacht is to inherit expensive architecture mistakes.

For higher consequence systems, request:

• Product cyber-security manual or hardening guide.
• Network interface description.
• Account and role model.
• Default credential removal process.
• Remote-support method.
• Software and firmware bill or baseline.
• Vulnerability disclosure route.
• Patch/update procedure.
• Backup and restore procedure.
• Commissioning test records.
• Known limitations or dependencies.

This evidence is especially important for integrated bridge systems, automation, PMS, VMS, SatCom, CCTV, access control and cloud-connected platforms.

The weak point is usually not one bad product. It is unmanaged integration. A bridge data feed is copied to an owner display. A CCTV recorder is exposed through a cloud portal. An AV processor needs a route to a lighting processor. A vendor support account is reused across several systems. A shipyard temporary network becomes permanent because nobody has time to close it.

UR E26/E27 thinking helps project teams slow down at those boundaries. It asks what the system is, what it connects to, who supports it, how it is updated, how it is recovered, and what evidence proves the design is under control.

Existing yachts often contain mixed-generation systems installed over many refits. Documentation may be incomplete, vendor access may be unclear, and network segmentation may have grown around convenience. UR E26/E27 thinking helps identify gaps before the next major upgrade.

It also helps management avoid weak procurement. The cheapest connected product may become expensive if it lacks secure updates, access logs, support lifecycle or proper documentation.

• Treating IACS cyber rules as only a newbuild issue.
• Failing to include AV, SatCom, CCTV or access control in cyber scope.
• Asking suppliers for brochures instead of cyber evidence.
• Missing interfaces between bridge, OT, IT and owner dashboards.
• Accepting handover without software baselines and backup files.