Digdir brukte seksten timer på å si ordet «tjenestenektangrep». I mellomtiden publiserte statussiden åtte meldinger som ikke oppga noen årsak, hvorav fem var ordrett like bortsett fra klokkeslettet på slutten.
Denne artikkelen går gjennom hva direktoratet faktisk kommuniserte gjennom døgnet – og et funn i eksterne trusselkilder som knytter ID-portens frontadresse til datoen for det forrige angrepet.
Publisert 4. august 2026. Dette er en oppfølger til den løpende dekningen av ID-porten-utfallet 3.–4. august, som dokumenterer hendelsen og konsekvensene. Denne artikkelen handler om kommunikasjonen og om hva som lar seg etterprøve.
Alle statusmeldinger er hentet fra Digdirs eget JSON-API, fanget mens hendelsen pågikk.
Hva Digdir selv bekrefter
Digitaliseringsdirektoratets driftsmeldinger bekrefter at dette rammer bredt. Ifølge NTBs dekning melder Digdir om problemer i ID-porten, MinID, eFormidling, selvbetjeningsløsningene, Altinn, Kontakt- og reservasjonsregisteret, eInnsyn, Maskinporten, ELMA og Ansattporten. Også Helsenorge er rammet.
Merk at Maskinporten står på listen. Det bekrefter at hendelsen ikke bare rammer innbyggere som skal logge inn, men også maskin-til-maskin-autentiseringen mellom virksomheter og offentlige API-er.
Digdir hadde lenge ikke sagt noe om årsaken. Til NTB sa en kommunikasjonsrådgiver i direktoratet:
Driftspartner jobber med å løse problemet, men vi har ikke noe klart anslag for når problemene vil bli løst.
— Kommunikasjonsrådgiver i Digdir, via NTB
Ingen forklaring. Ingen prognose. Slik sto det gjennom hele natten og hele arbeidsdagen – helt til klokken 16.55.
Til VG sa pressevakten i Digdir:
Det er problemer med flere løsninger. Vi jobber med å finne ut hva problemet er og finne løsninger.
— Digdirs pressevakt, til VG
Digdirs egne nettsider var samtidig upåvirket. Målinger klokken 18.50 viste at digdir.no, samarbeid.digdir.no, docs.digdir.no og statussiden alle svarte på under et halvt sekund med fullt innhold.
Det er ikke en anklage. Informasjonssidene ligger et annet sted enn fellesløsningene, og slik skal det være. Men det gir et presist bilde av hva slags hendelse dette er.
Direktoratets egen stemme fungerer utmerket. Det er infrastrukturen alle andre er avhengige av, som ikke gjør det.
Seksten meldinger, og en årsak etter seksten timer
Digdirs statusside publiserte seksten meldinger fra hendelsen ble opprettet og frem til tirsdag formiddag. Samlet så de slik ut:
| Klokken | Hva meldingen sa | Neste lovet |
|---|---|---|
| 02.25 | «Det oppleves problemer med flere løsninger. Vi undersøker problemene.» | – |
| 03.20 | «Problema ser ut til å ha starta ca 00:50. Driftspartner jobbar med å løyse saka, vi oppdaterer når vi har noko nytt å melde.» | – |
| 07.20 | «Det pågår fortsatt feilsøking.» | – |
| 09.28, 10.30, 11.43, 12.41, 13.36 | «Vi jobber fortsatt med å løse problemet.» – fem meldinger, ordrett like | 10.30, 11.30, 12.30, 13.30, 14.30 |
| 13.53 | «Fra ca. klokken 13:40 ser det ut som trafikken er på vei oppover igjen på de rammede løsningene.» | – |
| 16.55 | Tjenestenektangrep mot ID-porten hos driftspartner Vivicta, pågående siden kl. 01 | – |
| 18.34 | «Vi opplever problemer igjen fra ca. 17:55.» | – |
| 21.05 | «De fleste løsningene fungerer, men det kan fortsatt oppleves ustabilitet og varierende responstider.» | – |
| 22.52 | «Stor økning i antall feil i ID-porten. Det jobbes med avbøtende tiltak.» | – |
| 00.11 | «Fortsatt stor andel feil i ID-porten. Det jobbes fortsatt med å løse det.» | 07.30 |
| 07.51 | «Fra ca. 01:26 i natt så har fellesløsningene vært stabile.» | 08.30 |
| 09.02 | «Alle løysingar er tilbake i normal drift frå ca. 01:30 i natt.» | – |
| 09.45 | Tilbake til gul status: datasentre i fire land får ikke koblet seg til | – |
Den første meldingen kom klokken 02.25. Problemet startet ifølge Digdirs egen melding rundt 00.50. Det gikk altså én time og 35 minutter fra utfallet begynte til statussiden sa noe om det.
De fem siste meldingene før trafikkoppdateringen var ordrett identiske bortsett fra klokkeslettet på slutten.
To av dem kom for sent målt mot sin egen lovnad. Meldingen som var varslet til 11.30, kom 11.43. Den som var varslet til 12.30, kom 12.41.
Det direktoratet setter et klokkeslett på, er ikke når feilen er rettet. Det er når de neste gang skal si noe. Og det eneste som utvikler seg gjennom dagen, er nettopp det klokkeslettet.
De første åtte meldingene oppgir ingen årsak, og ingen av dem antyder når feilen kan være rettet. Den mest konkrete opplysningen på nesten seksten timer kom klokken 03.20, da direktoratet slo fast når problemet startet – en opplysning om fortiden.
Først klokken 16.55 kom ordet «tjenestenektangrep».
Det er ikke et rimelig krav at Digdir skal spekulere offentlig i uavklarte tekniske forhold mens feilsøkingen pågår. Men et angrep som ifølge direktoratet selv hadde pågått siden klokken 01, ble først omtalt offentlig klokken 16.55.
Den lovede oppdateringen kom aldri
Klokken 13.36 lovet Digdir at neste statusoppdatering ville komme klokken 14.30.
Den kom ikke. Klokken 14.45 var siste melding på hendelsen fortsatt den fra 13.53 – publisert før fristen den skulle avløse.
Det som kom i stedet, var dette:
Fra ca. klokken 13:40 ser det ut som trafikken er på vei oppover igjen på de rammede løsningene.
— Digdir, statusoppdatering 13.53
Samtidig endret direktoratet hendelsens tilstand.
Hva «monitoring» betyr
Statussider av denne typen opererer vanligvis med fire faste tilstander for en hendelse:
| Tilstand | Hva den normalt betyr |
|---|---|
investigating | Feilen undersøkes. Årsaken er ikke funnet. |
identified | Årsaken er funnet. |
monitoring | Et tiltak er iverksatt, og man følger med på om det virker. |
resolved | Problemet er løst. |
Klokken 13.53 gikk hendelsen fra investigating til monitoring. Den hoppet altså over identified, og havnet i tilstanden som normalt betyr at noe er gjort.
Plattformen tvinger ikke frem den betydningen, og virksomheter kan bruke feltene ulikt. Men konvensjonen er etablert – og meldingsteksten ved siden av nevner ikke noe tiltak.
Det samsvarer ikke med oversikten
Direktoratets egen komponentoversikt viste ingen bevegelse. En sammenlikning av statussidens data klokken 13.52, 14.30 og 14.45 ga samme svar hver gang: ikke én komponent hadde endret status. 19 av 47 sto fortsatt utenfor normal drift.
Tjenestene svarte heller ikke nødvendigvis. Gjentatte målinger mot einnsyn.no gjennom ettermiddagen og kvelden ga i beste fall det tomme applikasjonsskallet, aldri innhold.
Trafikken kan godt være på vei oppover. Men trafikk måler hvor mange som forsøker, ikke hvor mange som kommer inn.
Tavla lå seks timer bak
Meldingen som var varslet til klokken 07.30, kom 07.51 – 21 minutter på overtid, og den tredje av direktoratets egne frister som glapp.
Innholdet er mer interessant enn forsinkelsen:
Fra ca. 01:26 i natt så har fellesløsningene vært stabile. Vi kommer tilbake med mer informasjon ca. 08:30
— Digdir, statusoppdatering 07.51
Digdir oppgir altså at løsningene hadde vært stabile siden klokken 01.26. Statussidens egne komponenter viste samtidig ID-porten og MinID i fullt utfall, uendret siden klokken 22.46 kvelden før, helt frem til 07.51.
Det er seks timer og 25 minutter der komponentoversikten fortalte noe annet enn det direktoratet i ettertid oppgir som situasjonen. For en innbygger som sjekket statussiden klokken fem om morgenen, sto ID-porten som fullstendig nede.
Frontadressen dukket opp i trusseldata — samme dag som juni-angrepet
Et oppslag mot eksterne trusselkilder ga et uventet funn.
ID-portens innloggingsverter deler én offentlig adresse. login.idporten.no, bankid-integration.idporten.no, buypass-integration.idporten.no, commfides-integration.idporten.no og idporten.no peker alle på 139.105.36.167.
minid.no ligger på nabo-adressen 139.105.36.166, og einnsyn.no på .175 i samme nett.
Nettet er AS5619, registrert i RIPE på Tieto Norway AS. Det er selskapet som i dag heter Vivicta: Tietoevry Tech Services ble skilt ut i 2025 og fikk nytt navn samme høst. Vivicta er driftspartneren Digdir navnga i meldingen klokken 16.55.
I WAYSClouds trusseloversikt for AS5619 skiller 139.105.36.167 seg ut som den mest rapporterte adressen i nettet. Første observasjon er 20. juni 2026, siste 2. juli.
Men tallene må leses nøyaktig, og de er svakere enn de ser ut. Oversikten viser 47 rapportrader — 42 av dem er re-import av én og samme Data-Shield-oppføring. Det reelle antallet unike observasjoner er rundt fem. Og av de fem kildene er fire aggregerte blocklister som sannsynligvis leser fra hverandre. I praksis står vi igjen med i realiteten én primærkilde.
Det er altså ikke femdobbel uavhengig bekreftelse. Det er én observasjon, gjengitt mange ganger.
Opplysning: Trusseloversikten drives av denne artikkelforfatterens eget selskap, WAYSCloud. Dataene er aggregert fra offentlig tilgjengelige kilder og kan etterprøves i tjenesten.
Datoen er vanskelig å overse. Digdir opplyser at det forrige målrettede DDoS-angrepet mot ID-porten startet nettopp 20. juni, klokken 13.16, gjennom Vivictas nettverksinfrastruktur.
Her må man være nøyaktig om hva rapportene faktisk sier.
De handler ikke om tjenestenekt. Kategoriene omfatter RDP-angrepsforsøk, rekognosering, aggregert trusselaktivitet, lav omdømme-score og svartelisting på tvers av flere eksterne kilder.
Adressen er altså rapportert som kilde til uønsket trafikk mot andre – ikke som mål for et angrep. Rapportene fortsetter dessuten til 2. juli, ti dager etter at juni-hendelsen var avsluttet.
Det er derfor ikke grunnlag for å hevde at rapportene beskriver selve DDoS-angrepet, og enda mindre for å hevde at ID-portens systemer var kompromittert.
Det finnes flere mulige forklaringer som ikke innebærer at tjenesten selv initierte angrep. En offentlig adresse kan bli feilklassifisert på grunn av returtrafikk, aktivitet fra andre systemer bak samme NAT- eller lastbalanseringsmiljø, feil i den opprinnelige rapporteringen eller periodisk gjenpublisering av en eldre indikator.
For forbindelsesløs eller refleksjonsbasert DDoS-trafikk kan også forfalskede kildeadresser føre til at et offers adresse senere fremstår som avsender hos tredjeparter.
Og forfalskning passer godt på det som faktisk er registrert. IPThreat-rapporten stammer fra Windows Filtering Platform, hendelses-ID 5152 — én enkelt blokkert pakke, altså før noe TCP-håndtrykk er etablert. En enkeltpakke krever ingen toveis forbindelse, og kildeadressen kan derfor godt være forfalsket.
Forfalskning kan ikke utelukkes. Den er tvert imot en nærliggende forklaring.
Threat intelligence registrerer at en adresse er observert eller klassifisert som kilde til trafikk. Den forklarer ikke nødvendigvis hvem som kontrollerte trafikken, om kategoriseringen var riktig, eller om flere rapporter bygger på den samme opprinnelige observasjonen.
Likevel fortjener funnet oppmerksomhet.
Den offentlige adressen som fronter ID-porten og integrasjonene mot alle fire norske eID-leverandørene, ble registrert i eksterne trusselkilder for første gang samme dag som det forrige DDoS-angrepet mot ID-porten startet.
Den mest nærliggende forklaringen er ikke at noe stammer fra ID-porten, men at adressen dukker opp i trusseldata nettopp fordi den er mål for angrepet — enten ved at avsenderadressen forfalskes, eller som gjenklang av selve trafikkfloden.
Det er ikke en konklusjon.
Men det er et spørsmål Digdirs hendelsesrapport bør kunne avklare: om noe faktisk gikk ut fra adressen, eller om den bare ble utgitt for det.
Kilder
- Digdir – status for nasjonale fellesløsninger
- WAYSCloud – trusseloversikt for AS5619
- WAYSCloud – IP-oppslag for 139.105.36.167
- Vivicta – Tietoevry Tech Services blir Vivicta (2025)
- Digdir – redegjørelse etter DDoS-angrepet 20.–22. juni 2026
- VG – Digdir opplever problemer med flere løsninger
- NTB via Romsdals Budstikke – innloggingsproblemer for en rekke offentlige tjenester
- Egne DNS-oppslag mot ID-portens innloggingsverter og ASN-oppslag mot AS5619, 3.–4. august 2026.
- Snapshots av Digdirs status-API fanget hvert femte minutt gjennom hendelsen.
Rettelser
4. august 2026, klokken 12.23 — trusseldataene nyansert. Artikkelen oppga først «47 registrerte rapportobjekter fra fem kilder». Nærmere gjennomgang viser at 42 av radene er re-import av én og samme Data-Shield-oppføring, og at fire av de fem kildene er aggregerte blocklister som sannsynligvis leser fra hverandre. Det reelle antallet unike observasjoner er rundt fem, i praksis fra én primærkilde. Tallene er rettet, og formuleringen «brå oppsving» er erstattet, fordi datagrunnlaget ikke bærer den.
4. august 2026, klokken 12.23 — vurderingen av kildeadresseforfalskning snudd. Artikkelen hevdet først at et TCP-basert RDP-angrepsforsøk krever en toveis forbindelse, og derfor ikke uten videre lar seg forklare med forfalsket kildeadresse. Det er feil. Rapporten stammer fra Windows Filtering Platform, hendelses-ID 5152 — én blokkert enkeltpakke, logget før noe håndtrykk er etablert. Forfalskning er dermed en nærliggende forklaring, ikke en usannsynlig en. Avsnittet er skrevet om, og konklusjonen peker nå mot at adressen opptrer i trusseldata fordi den var mål for angrepet.