Maritim cyberresiliens: IACS UR E26/E27, ISM-koden og identitetene mellom skip og land

Sjøfartsdirektoratet ble 19. desember 2025 utpekt som sektortilsynsmyndighet for digitalsikkerhetsloven for rederier. Loven med forskrifter trådte i kraft 1. oktober 2025. Rederier som oppfyller terskelverdiene — faste anløp, minst 5 % av passasjer- eller godsvolum ved havn med over 100 000 tonn årlig over fem år, eller minst 100 000 passasjerer årlig — skal melde seg til NSM og Sjøfartsdirektoratet, og etablere styringssystem, risikovurdering og -håndtering, sikkerhetstiltak, beredskap og varslingsrutiner.

Dette kommer i tillegg til, ikke i stedet for, det maritime cyberregimet som allerede gjaldt. Det maritime regelverksbildet er nå lagdelt på en måte som gjør at ansvaret for identitetsstyring faller mellom flere stoler:

• IMO Resolution MSC.428(98), vedtatt 16. juni 2017, som pålegger at cyberrisiko håndteres i sikkerhetsstyringssystemet senest ved første årlige verifikasjon av rederiets Document of Compliance etter 1. januar 2021. Veiledning i MSC-FAL.1/Circ.3, der gjeldende revisjon er Rev.3 av 4. april 2025 (den tidligere Rev.2 er datert 7. juni 2022 — kontrollér at interne dokumenter ikke fortsatt viser til den).
• IACS UR E26 «Cyber resilience of ships» og UR E27 «Cyber resilience of on-board systems and equipment», Rev.1 fra september 2023, gjeldende for skip med byggekontrakt inngått fra og med 1. juli 2024.
• Sjøfartsdirektoratets veiledningsrundskriv om maritim cyber security, med tilsyn under ISM-revisjoner.
• Digitalsikkerhetsloven med Sjøfartsdirektoratet som sektortilsyn.

Fire regelsett. Ett av dem gjelder nybygg, tre gjelder eksisterende flåte og landorganisasjon.

Hvor identitetene faktisk ligger

Den utbredte antakelsen er at maritim cybersikkerhet handler om systemer om bord. Det er halvparten av bildet, og ikke den halvparten som er mest utsatt.

Et moderne rederis identitetslandskap består av minst fem populasjoner:

1. Landorganisasjonen. Teknisk avdeling, operations, crewing, innkjøp, økonomi. Vanlige Entra ID-kontoer med full M365-flate. Dette er der phishingen treffer, og der de administrative rettighetene ligger.

2. Seilende personell. Kapteiner, maskinsjefer og offiserer med kontoer i rederiets tenant for tilgang til vedlikeholdssystem, rapportering, sertifikatregister og e-post. Karakteristisk: lange fravær, høy rotasjon mellom fartøy, betydelig innslag av personell ansatt gjennom manningsagenter i andre land.

3. Manningsagenter og bemanningsselskaper. Eksterne organisasjoner som selv administrerer hvem som seiler. Ofte med tilgang til rederiets crewingsystem.

4. Teknisk leverandørtilgang. Motorleverandøren, navigasjonsleverandøren, DP-leverandøren, klasseselskapet. Flere av dem har fjerntilgang til systemer om bord, rutet gjennom rederiets landbaserte infrastruktur og autentisert mot rederiets identitetsplattform.

5. Kontoer om bord. Lokale kontoer i broutstyr, maskinromssystemer og lastesystemer. Disse ligger ikke i Entra ID, og skal ikke gjøre det. Det er UR E27s domene.

Populasjon 1 til 4 lever i eller er føderert med rederiets Entra ID. Populasjon 5 gjør det ikke. Nesten all praktisk risiko for populasjon 5 går likevel gjennom populasjon 1 til 4, fordi det er dit fjerntilgangen kommer fra.

Hva UR E26/E27 krever av identitetsstyring

UR E26 og E27 stiller krav som omfatter blant annet unik brukeridentifikasjon, kontroll med privilegerte kontoer og sikret fjerntilgang. Detaljnivået i kravteksten bør kontrolleres direkte mot IACS-publikasjonene eller klasseselskapets gjengivelse før det legges til grunn i en gap-analyse — sekundærlitteraturen på dette området er upresis.

Det avgjørende for en IT-sikkerhetsleder er ikke detaljene i E27, som i praksis er verftets og utstyrsleverandørens ansvar ved nybygg. Det avgjørende er at E26 gjelder skipet som system, inkludert grensesnittet mot land. Fjerntilgangsstien fra en landbasert ingeniør eller en leverandør til et system om bord er dermed i scope, og den stien starter i identitetsplattformen på land.

For flåte bygget før 1. juli 2024 — altså det meste av det som seiler — gjelder ikke E26/E27. Da er det MSC.428(98) og ISM-koden som er hjemmelen, og den er formulert som et krav om at cyberrisiko skal være håndtert i sikkerhetsstyringssystemet. Et sikkerhetsstyringssystem som ikke beskriver hvordan tilgang til fartøyssystemer gis, endres og fjernes, håndterer ikke cyberrisiko i noen meningsfull forstand.

De tre feilmodusene som er spesifikt maritime

Kontoen som seiler videre. En andrestyrmann slutter i rederiet. Kontoen deaktiveres i landorganisasjonens rutine. Men vedkommende var også registrert som bruker i vedlikeholdssystemet om bord på tre ulike fartøy, med lokale kontoer opprettet av forrige maskinsjef. Ingen av disse er koblet til rederiets katalog.

Felleskontoen på broen. Fordi vaktskifter skjer døgnet rundt og pålogging tar tid, opprettes en delt konto. Alle handlinger utført fra den kontoen er dermed umulige å knytte til et menneske. Dette bryter med UR E26/E27s krav om unik brukeridentifikasjon og med NSMs grunnprinsipp 2.6.1 om sporbarhet til ansvarlig person, og det gjør enhver etterforskning av en hendelse om bord meningsløs.

Manningsagentens tilgang. Agenten har tilgang til crewingsystemet for å registrere personell. Agentens egne ansatte skiftes ut uten at rederiet varsles. Tilgangen består. Dette er nøyaktig samme mønster som gjestekontoproblematikken i landbasert virksomhet, men med en ekstra organisatorisk avstand mellom rederiet og menneskene som faktisk bruker tilgangen.

Hva som lar seg gjøre fra landsiden

Entra Logic styrer Microsoft Entra ID. Det betyr at det treffer populasjon 1 til 4, ikke populasjon 5. Innenfor det omfanget:

Én søkbar oversikt på tvers av tenanter. Rederier med flere driftsselskaper, joint ventures eller managementavtaler har som regel flere tenanter. Multi-tenant fra grunnen — med tenantbytte i toppmenyen og per-tenant-konfigurasjon i hver modul — er forskjellen på å kunne svare på «hvem har tilgang til hva i konsernet» og å måtte spørre fire personer.

Godkjent tilgang for seilende og eksterne. Crewing eller teknisk avdeling kan sende forespørselen om at en ny offiser skal få tilgang, uten selv å ha administratorrettigheter. Beslutningen registreres. Utførelsen skjer maskinelt.

Selvbetjening som faktisk fungerer om bord. En egen ansattflate på web og en ekte native iOS-app for oppslag i katalogen og styrte forespørsler er mer relevant til sjøs enn på land, av en enkel grunn: personell om bord har ofte mobil tilgjengelig og begrenset båndbredde, og en app som fungerer under dårlige forhold er forskjellen på at rutinen brukes og at den omgås.

Ett revisjonsspor for ISM-revisjonen. Sjøfartsdirektoratet fører tilsyn med cyberrisikohåndtering under ISM-revisjoner. Å kunne vise en fullstendig, søkbar historikk over hvem som fikk hvilken tilgang, når, med hvilken begrunnelse og hvem som godkjente, er kvalitativt bedre enn å vise en prosedyre.

Nordisk språkstøtte med per-tenant ordvalg. For en organisasjon med blandet norsk, svensk, dansk og engelsk arbeidsspråk er det ikke kosmetikk — det avgjør om selvbetjeningsflaten brukes.

Grensene, uttrykt tydelig: ingenting av dette berører systemer om bord som ikke er representert i Entra ID. UR E27-etterlevelse for utstyr er en sak mellom rederi, verft, utstyrsleverandør og klasseselskap. Og produktet gjennomfører ikke attesteringskampanjer der linjeledere periodisk bekrefter tilganger.

Fire spørsmål før neste ISM-revisjon

1. Kan dere produsere en liste over alle eksterne identiteter — manningsagenter, tekniske leverandører, klasseselskap — med tilgang til rederiets systemer, med intern eier og siste innlogging?

2. Finnes det delte kontoer i bruk om bord, og er de dokumentert som et bevisst akseptert avvik med kompenserende tiltak?

3. Når en offiser slutter, hvilke systemer utenfor Entra ID må håndteres manuelt, og hvem gjør det?

4. Har rederiet vurdert om det oppfyller terskelverdiene i digitalsikkerhetsloven, og i så fall meldt seg til NSM og Sjøfartsdirektoratet?

Spørsmål fire har en frist knyttet til seg. De tre første har bare konsekvenser.

Kilder

• Sjøfartsdirektoratet utpekt som sektortilsyn for digitalsikkerhetsloven for rederier (19.12.2025) — https://www.sdir.no/nyheter/sjofartsdirektoratet-er-utpekt-myndighet-for-sektortilsyn-med-digitalsikkerhetsloven-for-rederier/
• Sjøfartsdirektoratet, veiledning om digitalsikkerhetsloven (PDF) — https://www.sdir.no/contentassets/1037d6bd47bc4c36b1781aa1ca37097c/digitalsikkerhetsloven-er-i-kraft---veiledning-fra-sjofartsdirektoratet.pdf
• Sjøfartsdirektoratet, veiledningsrundskriv om maritim 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), gjeldende veiledning — 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 pressemelding om E26/E27 — https://iacs.org.uk/news/iacs-ur-e26-and-e27-press-release
• NSM, Grunnprinsipper for IKT-sikkerhet v2.1, tiltak 2.6.1 — https://nsm.no/getfile.php/1313975-1717589722/NSM/Filer/Dokumenter/Veiledere/NSMs%20Grunnprinsipper%20for%20IKT-sikkerhet%20v2.1.pdf