Når angriperen
ser legitim ut.

01 · Vår vurdering

Vi må beskytte beslutningen, ikke bare innloggingen.

Den viktigste endringen vi leser ut av IOCTA 2026, er kombinasjonen av ferdige kriminelle tjenester, gjenbrukte data, troverdig kommunikasjon og raskere arbeidsflyter. KI kan forsterke dette. Men virksomheten kan tape penger eller data uten at angriperen har en spesielt avansert KI-modell.

Vår hovedvurdering: Sikkerhet bør bygges slik at én vellykket imitasjon eller én kompromittert konto ikke er nok til å endre en bankkonto, overta identiteten eller hente ut de mest verdifulle dataene. Det er et krav til arbeidsprosessen og systemene, ikke bare til den ansattes årvåkenhet.

En korrekt innlogging er et bevis på en autentiseringshendelse. Den er ikke et løfte om at alle etterfølgende handlinger er riktige.

Vi ville derfor prioritert sterke innlogginger, kontrollert gjenoppretting og tydelige handlingsgrenser før en stor innkjøpsrunde med nye sikkerhetsprodukter. Samtidig må patching, enhetssikring, logging og gjenoppretting fortsette. En identitetsstrategi beskytter ikke en upatchet, internetteksponert tjeneste.

02 · Hva materialet tåler

En sterk trusselbeskrivelse er ikke en sannsynlighetsmodell.

IOCTA er et politifaglig situasjonsbilde. Metodedelen beskriver et hovedsakelig kvalitativt grunnlag fra større etterforskninger støttet av Europol i 2025, supplert med ekspertkunnskap og andre rapporter. Dette er verdifullt for å forstå metoder og sammenhenger, men ikke et representativt utvalg av alle norske virksomheter. [1, s. 38]

Den vedlagte norske syvsidersrapporten er et nyttig arbeidsnotat. Vi bruker den som et utgangspunkt som skal prøves mot primærkildene, ikke som en uavhengig bekreftelse av Europol. Rangeringer som «svært høy» i notatet videreføres derfor ikke som tallfestet eller kalibrert risiko.

Europol bruker sterkere fremtidsformuleringer på side 36 enn den mer nyanserte omtalen av dagens bruk på side 21. Vi behandler dette som en grunn til å være tydelige om usikkerhet, ikke til å velge den mest dramatiske formuleringen. NSMs Risiko 2026 gir et norsk korrektiv: sosial manipulering og mer avansert phishing er også observert her. Det er ikke det samme som at alle MFA-metoder har mistet verdi. [2, PDF s. 24]

03 · Identitet gjennom hele levetiden

Passnøkler er et viktig løft. Gjenoppretting er også en inngang.

Vi støtter en planlagt overgang fra SMS-koder til phishing-resistent autentisering for kritiske kontoer. NSM anbefaler robuste MFA-løsninger, strukturert utrulling og jevnlig revisjon. Ikke fjern eksisterende MFA før en fungerende erstatning og gjenoppretting er på plass. [3]

En SIM-farm som oppretter mange kontoer, SIM-bytte som overtar et telefonnummer og falsk avsender-ID er forskjellige mekanismer. Samlet viser de hvorfor telefonnummeret er et svakt, universelt tillitsanker. Men ingen av dem alene beviser at enhver SMS kan avlyttes. SMS kan fortsatt brukes til praktiske beskjeder; den bør ikke alene avgjøre en kritisk godkjenning.

Det oversette spørsmålet er hvem som får registrere neste passnøkkel. Hvis support kan fjerne den gamle faktoren etter en overbevisende telefonsamtale, kan en sterk innlogging få en svak bakdør gjennom rutinen. Vår anbefaling er at ny faktor, ny enhet og gjenoppretting behandles som egne sikkerhetshendelser: med kjent identitet, dokumentert kontroll, varsling og sporbarhet. Høyrisikoendringer bør ha separat godkjenning.

Synkroniserte passnøkler, enhetsbundne nøkler og fysiske sikkerhetsnøkler har ulike avhengigheter. En synkronisert løsning må også vurderes ut fra skykontoen og dens gjenoppretting. For administratorer kan enhetsbundet nøkkel, separat adminidentitet og en reservenøkkel i kontrollert oppbevaring være et godt valg. Dette er et rollebasert designvalg, ikke et argument mot passnøkler generelt.

Phishing-resistent innlogging fjerner heller ikke behovet for å beskytte enheten og sesjonen. Skadevare på en legitim PC eller misbruk av en allerede etablert sesjon må møtes med flere lag. Microsoft beskriver både forebygging, deteksjon og vern mot gjenbruk av stjålne tokens. Token Protection har konkrete plattform-, app- og klientbegrensninger som må kontrolleres før utrulling; det er ikke et universelt vern for alle nettleserøkter. [4]

Kontroller som bruker samme kompromitterte konto, enhet eller administrator kan svikte sammen. To meldinger i to apper er derfor ikke automatisk to uavhengige kontroller.

04 · Samhandling og data

Behold Teams. Gjør grensene forståelige og testbare.

Å erstatte Teams med en annen chat løser ikke tilliten til en kompromittert kollega eller en falsk supporthenvendelse. Vi ville heller skilt mellom ekstern chat, gjestemedlemskap og delte kanaler. De gir forskjellige typer tilgang og må ikke behandles som én bryter. Et godkjent eksternt domene reduserer eksponering, men gjør ikke alle kontoer på domenet trygge.

Her trenger arbeidsnotatet en teknisk presisering: Teams’ grunnleggende beskyttelse mot skadelige URL-er viser varsler. Microsoft skiller dette fra Safe Links, som kan kontrollere og blokkere ved klikk med riktig lisens og oppsett. Et advarselsbanner er ikke en teknisk sperre. [5]

Det er også forskjell på datatapssikring, DLP, for chatmeldinger og for filer. Filer delt gjennom Teams ligger i SharePoint eller OneDrive og må omfattes der. En etikett eller policy på ett sted gir ikke automatisk full dekning overalt. Test faktisk blokkering, varsling og eventuelle overstyringer med ufarlige testdata. [6]

For omfattende blokkering kan skyve arbeidet over i private apper, skjermbilder og uregistrerte unntak. Vår vurdering er derfor at hver begrensning må følges av en fungerende, enkel vei for legitimt arbeid. Det er en del av sikkerhetsdesignet, ikke bare et spørsmål om brukervennlighet.

05 · KI på begge sider

Den nye faren er også hva vår egen automatisering får gjøre.

IOCTA beskriver KI som en forsterker av kriminelle prosesser. Vår videre vurdering er at virksomhetens egen KI-utrulling kan forstørre konsekvensen av gamle tilgangsproblemer: enklere søk, sammenstilling og handling gjør brede rettigheter mer verdifulle å misbruke. Det betyr ikke at KI skaper rettighetene eller automatisk omgår dem.

Microsoft opplyser at Microsoft 365 Copilot bare henter organisasjonsinnhold brukeren har rett til å se. Agentutvidelser har egne tillatelser og vilkår som også må vurderes. Vår anbefaling er å rydde brede tilganger og gjøre dataeierskap tydelig før stor utrulling. Ikke forveksle et fravær av tilgangsbrudd med riktig tilgangsdesign. [7]

En assistent som bare oppsummerer et godkjent dokument har et annet skadepotensial enn en agent som kan sende e-post, dele filer eller godkjenne endringer. Vi ville startet med leseadgang til avgrensede data, eget formål og eier, små handlingsrammer og menneskelig godkjenning utenfor agentens egen kontroll for kritiske steg. Ubetrodd dokumentinnhold må ikke få bestemme verktøytilgang eller overstyre godkjenningsregler.

Kontrollen må også omfatte ikke-menneskelige identiteter: integrasjoner, tjenestekontoer og apper. En brukers passnøkkel hjelper lite mot en fortsatt gyldig integrasjon med for vide rettigheter. Kartlegg eier, formål, datatilgang og hvordan tilgangen trekkes tilbake. Dette er en IANS-anbefaling om styring, ikke et funn om at et bestemt Copilot-oppsett er sårbart.

06 · Prøv tankegangen

Tre forløp som avslører forskjellige hull.

Dette er konstruerte øvingsscenarioer, ikke rapporterte hendelser hos IANS eller en navngitt virksomhet. Åpne hvert forløp og se hvor en uavhengig kontroll bør ligge.

07 · To forskjellige tap

Backup løser tilgjengelighet. Ikke hele utpressingen.

Europol beskriver et økende press rundt offentliggjøring av stjålne data, i tillegg til kryptering og andre pressmidler. Det betyr ikke at kryptering har sluttet å være farlig. Vi må planlegge for både tapt drift og tapt kontroll over informasjon. [1, s. 23–25]

Vår anbefaling er å teste to spor separat: Kan vi gjenopprette tjenesten innen akseptabel tid, og kan vi håndtere at dokumenter allerede er kopiert? Det andre sporet krever kunnskap om hvilke data som finnes, hvem de gjelder og hvem som skal ta beslutninger og kommunisere. En slettepåstand fra en utpresser er ikke et teknisk bevis på at kopiene er borte.

En backup som styres av samme høyt privilegerte identitet som resten av miljøet kan gi en felles feilårsak. Uforanderlig eller offline backup, separate administrative grenser og prøvd restore er derfor en bedre test enn bare en grønn «backup OK»-status. Leverandørens tilgang og gjenopprettingsmulighet må inngå i øvelsen.

For leverandøravhengige virksomheter ville vi dessuten avklart hva som skjer hvis identitetsleverandøren, driftspartneren eller samhandlingsplattformen er utilgjengelig. En beredskapskontaktliste som bare ligger i den rammede e-posten, er et svakt utgangspunkt. Dette er et argument for øvd reservekommunikasjon og avgrensede avhengigheter, ikke for å avskaffe skytjenester.

08 · Utviklingsbaner, ikke spådommer

Hva kan endre prioriteringene frem mot 2030?

Vi har ikke grunnlag for presise prosenter eller et årstall der én teknologi «vinner». Følgende er betingede hypoteser for planlegging. Alle bygger på at økonomi, teknisk kvalitet, tilgang til ofre og mottiltak kan endre utviklingen.

Vi ville brukt 2030 som retning for arkitektur, ikke som frist for grunnsikring. Tiltakene under er nyttige også i en verden der KI utvikler seg saktere enn ventet. Det gjør dem mindre avhengige av at den mest dramatiske prognosen slår til.

09 · Fra vurdering til gjennomføring

Start med grensene som stopper et reelt tap.

Dette er et forslag til rekkefølge for en vanlig norsk virksomhet, ikke en bestilling på en bestemt Microsoft-lisens. Velg tilsvarende funksjoner i det miljøet dere faktisk bruker. Kartlegging, kapasitet og virksomhetskritiske tjenester må styre tempoet.

For den mindre virksomheten

Begynn med et kort, gjennomførbart minimum: sterk innlogging for sentrale kontoer, en trygg support-/recovery-rutine, uavhengig betalingsgodkjenning, vedlikeholdte enheter, begrenset deling og testet backup. Avtal med driftspartneren hvem som oppdager og stopper en hendelse. Ikke kjøp overvåking uten en avtale om hvem som faktisk følger opp varslet.

Mål effekt fremfor antall produkter

• Andel kritiske kontoer med både phishing-resistent innlogging og kontrollert recovery. Oppgi teller og nevner, ikke bare «MFA aktivert».
• Antall kritiske unntak uten eier eller sluttdato; antall integrasjoner uten ansvarlig.
• Tid fra testhendelse til oppdagelse, beslutning og verifisert stans. Skill øvingsresultater fra reelle hendelser.
• Resultat av restore og av forsøk på uautorisert åpning/deling av testdata. Et avvik skal ikke kunne skjules i et samlet modenhetstall.

Vi setter ikke universelle minuttmål eller «100 % sikker»-mål her. Den enkelte tjenestens tålegrense og observerte grunnlinje må bestemme akseptkriteriene. Øvelser med personopplysninger og sikkerhetslogger må avgrenses etter formål, tilgang og oppbevaring; mer overvåking er ikke automatisk bedre sikkerhet.

10 · Det vi ikke ville gjort

Unngå å gjøre tillitsproblemet til et produktproblem.

Vi ville ikke avviklet telefon eller Teams generelt, slått av all ekstern samhandling, behandlet enhver ansatt som mistenkt eller lovet at en passnøkkel løser hele problemet. Vi ville heller ikke ventet på et perfekt KI-basert forsvar før grunnleggende feil ble rettet.

Europol beskriver hvordan kryptering og anonymisering vanskeliggjør etterforskning. Det er et reelt politifaglig perspektiv, men ikke i seg selv et bevis på at svakere kryptering gir bedre samlet sikkerhet. Virksomheter og innbyggere trenger også beskyttelse mot avlytting og datatyveri. Vår vurdering er å bevare sterk kryptering og samtidig sikre relevant, forholdsmessig sporbarhet og lovlig håndtering av hendelser. [1, s. 6–9]

Rapportens kapittel om overgrep og utpressing mot barn viser dessuten at cyberkriminalitet ikke bare er en virksomhetsrisiko. Denne analysen avgrenser seg til organisasjoners identitet, samhandling og data. Den dekker ikke hele Europols mandat eller alle konsekvenser for barn og privatpersoner.

Det avgjørende spørsmålet er ikke bare: «Stoler vi på denne brukeren?» Det er også: «Hvilken skade kan denne brukeren, sesjonen eller agenten gjøre uten at noen andre griper inn?»

Vårt råd er å teste svaret før det haster. Et godt design gjør det mulig å samarbeide og bruke KI, samtidig som det setter en praktisk grense for hva én feil kan koste.