Maritime cyber resilience: IACS UR E26/E27, the ISM Code, and the identities between ship and shore

Shipping companies got a new supervisory authority in December, and most haven't noticed

On 19 December 2025, the Norwegian Maritime Authority was designated sector supervisory authority for the Digital Security Act (digitalsikkerhetsloven) for shipping companies. The act and its regulations entered into force on 1 October 2025. Shipping companies that meet the threshold values — regular port calls with at least 5% of passenger or cargo volume at a port handling over 100,000 tonnes annually over five years, or at least 100,000 passengers annually — must register with the Norwegian National Security Authority (NSM) and the Norwegian Maritime Authority, and establish a management system, risk assessment and treatment, security measures, contingency arrangements and notification routines.

This comes in addition to, not instead of, the maritime cyber regime that already applied. The maritime regulatory landscape is now layered in a way that lets responsibility for identity management fall between several stools:

• IMO Resolution MSC.428(98), adopted 16 June 2017, which requires cyber risk to be addressed in the safety management system no later than the first annual verification of the shipping company's Document of Compliance after 1 January 2021. Guidance is given in MSC-FAL.1/Circ.3, where the current revision is Rev.3 of 4 April 2025 (the earlier Rev.2 is dated 7 June 2022 — check that internal documents don't still reference it).
• IACS UR E26 "Cyber resilience of ships" and UR E27 "Cyber resilience of on-board systems and equipment", Rev.1 from September 2023, applicable to ships with a newbuilding contract signed on or after 1 July 2024.
• The Norwegian Maritime Authority's guidance circular on maritime cyber security, supervised through ISM audits.
• The Digital Security Act (digitalsikkerhetsloven), with the Norwegian Maritime Authority as sector supervisory authority.

Four regulatory sets. One applies to newbuilds; three apply to the existing fleet and the shore organisation.

Where the identities actually sit

The common assumption is that maritime cyber security is about systems on board. That is half the picture, and not the more exposed half.

A modern shipping company's identity landscape consists of at least five populations:

1. The shore organisation. Technical department, operations, crewing, procurement, finance. Ordinary Entra ID accounts with the full M365 surface. This is where phishing lands, and where the administrative privileges sit.

2. Seagoing personnel. Captains, chief engineers and officers with accounts in the shipping company's tenant for access to the maintenance system, reporting, the certificate register and email. Characteristic traits: long absences, high rotation between vessels, a significant proportion of personnel employed through manning agents in other countries.

3. Manning agents and crewing agencies. External organisations that themselves administer who sails. Often with access to the shipping company's crewing system.

4. Technical vendor access. The engine manufacturer, the navigation vendor, the DP vendor, the classification society. Several of them have remote access to systems on board, routed through the shipping company's shore-based infrastructure and authenticated against the shipping company's identity platform.

5. Accounts on board. Local accounts in bridge equipment, engine room systems and cargo systems. These do not sit in Entra ID, and should not. That is UR E27's domain.

Populations 1 through 4 live in, or are federated with, the shipping company's Entra ID. Population 5 does not. Nearly all practical risk to population 5 nonetheless flows through populations 1 through 4, because that is where the remote access originates.

What UR E26/E27 requires of identity management

UR E26 and E27 set requirements that include, among other things, unique user identification, control of privileged accounts and secured remote access. The level of detail in the requirement text should be checked directly against the IACS publications or the classification society's rendering before being used as the basis for a gap analysis — secondary literature in this area is imprecise.

What matters to an IT security leader is not the detail of E27, which in practice is the shipyard's and equipment vendor's responsibility at newbuild. What matters is that E26 applies to the ship as a system, including the interface to shore. The remote-access path from a shore-based engineer or a vendor to an on-board system is therefore in scope, and that path starts at the identity platform on shore.

For fleet built before 1 July 2024 — that is, most of what is sailing — E26/E27 does not apply. There, MSC.428(98) and the ISM Code are the basis, and it is framed as a requirement that cyber risk be managed within the safety management system. A safety management system that does not describe how access to vessel systems is granted, changed and removed is not managing cyber risk in any meaningful sense.

The three failure modes that are specifically maritime

The account that keeps sailing. A second officer leaves the shipping company. The account is deactivated under the shore organisation's routine. But the same person was also registered as a user in the maintenance system on board three different vessels, with local accounts created by the previous chief engineer. None of these are linked to the shipping company's directory.

The shared account on the bridge. Because watch handovers happen around the clock and logging in takes time, a shared account is set up. Every action performed from that account is then impossible to tie to an individual. This breaches UR E26/E27's requirement for unique user identification and NSM's Basic Principle 2.6.1 on traceability to a responsible person, and it makes any investigation of an incident on board meaningless.

The manning agent's access. The agent has access to the crewing system to register personnel. The agent's own staff turn over without the shipping company being notified. The access remains. This is exactly the same pattern as the guest-account problem in shore-based business, but with an extra organisational distance between the shipping company and the people actually using the access.

What can be done from the shore side

Entra Logic manages Microsoft Entra ID. That means it reaches populations 1 through 4, not population 5. Within that scope:

One searchable overview across tenants. Shipping companies with several operating companies, joint ventures or management agreements typically have multiple tenants. Multi-tenant from the ground up — with tenant switching in the top menu and per-tenant configuration in each module — is the difference between being able to answer "who has access to what across the group" and having to ask four people.

Approved access for seagoing and external personnel. Crewing or the technical department can submit the request for a new officer to be granted access, without themselves holding administrator privileges. The decision is recorded. Execution happens automatically.

Self-service that actually works on board. A dedicated employee interface on the web and a true native iOS app for directory lookups and controlled requests are more relevant at sea than on shore, for a simple reason: personnel on board often have a mobile phone available and limited bandwidth, and an app that works under poor conditions is the difference between the routine being used and being bypassed.

One audit trail for the ISM audit. The Norwegian Maritime Authority supervises cyber risk management during ISM audits. Being able to show a complete, searchable history of who was granted which access, when, with what justification and who approved it, is qualitatively better than showing a procedure.

Nordic language support with per-tenant terminology. For an organisation with a mixed Norwegian, Swedish, Danish and English working language, this is not cosmetic — it determines whether the self-service interface gets used.

The boundaries, stated plainly: none of this touches systems on board that are not represented in Entra ID. UR E27 compliance for equipment is a matter between the shipping company, the shipyard, the equipment vendor and the classification society. And the product does not carry out attestation campaigns in which line managers periodically confirm access.

Four questions before the next ISM audit

1. Can you produce a list of all external identities — manning agents, technical vendors, the classification society — with access to the shipping company's systems, with an internal owner and last login?

2. Are there shared accounts in use on board, and are they documented as a deliberately accepted deviation with compensating measures?

3. When an officer leaves, which systems outside Entra ID must be handled manually, and who does it?

4. Has the shipping company assessed whether it meets the threshold values in the Digital Security Act (digitalsikkerhetsloven), and if so, registered with NSM and the Norwegian Maritime Authority?

Question four carries a deadline. The first three only carry consequences.

Sources

• Norwegian Maritime Authority designated sector supervisory authority for the Digital Security Act for shipping companies (19.12.2025) — https://www.sdir.no/nyheter/sjofartsdirektoratet-er-utpekt-myndighet-for-sektortilsyn-med-digitalsikkerhetsloven-for-rederier/
• Norwegian Maritime Authority, guidance on the Digital Security Act (PDF) — https://www.sdir.no/contentassets/1037d6bd47bc4c36b1781aa1ca37097c/digitalsikkerhetsloven-er-i-kraft—veiledning-fra-sjofartsdirektoratet.pdf
• Norwegian Maritime Authority, guidance circular on maritime cyber security — https://www.sdir.no/sjofart/regelverk/rundskriv/veiledningsrundskriv-om-maritim-cyber-security/
• IMO Resolution MSC.428(98) (16.06.2017) — https://wwwcdn.imo.org/localresources/en/OurWork/Security/Documents/Resolution%20MSC.428(98).pdf
• IMO MSC-FAL.1/Circ.3/Rev.3 (04.04.2025), current guidance — https://wwwcdn.imo.org/localresources/en/OurWork/Security/Documents/MSC-FAL.1-Circ.3-Rev.3.pdf
• IACS UR E27 Rev.1 (September 2023) — https://iacs.org.uk/resolutions/unified-requirements/ur-e/ur-e27-rev1
• IACS press release on E26/E27 — https://iacs.org.uk/news/iacs-ur-e26-and-e27-press-release
• NSM, Basic Principles for ICT Security v2.1, measure 2.6.1 — https://nsm.no/getfile.php/1313975-1717589722/NSM/Filer/Dokumenter/Veiledere/NSMs%20Grunnprinsipper%20for%20IKT-sikkerhet%20v2.1.pdf