ID-porten har vært utilgjengelig siden klokken 00.50 natt til mandag. Over fjorten timer senere er innloggingen til NAV, Altinn, Skatteetaten, Helsenorge, nettapotek og en lang rekke andre tjenester fortsatt rammet. Digdir bekrefter problemer i de fleste nasjonale fellesløsningene – inkludert Maskinporten, som virksomheter og offentlige API-er bruker til å autentisere seg mot hverandre – og har ingen prognose for når de er løst. Denne artikkelen dokumenterer det observerbare: hvor innloggingen svikter, hvem som rammes, og hvorfor varigheten er den egentlige historien. Den spekulerer ikke i rotårsaken.
Oppdatert klokken 14.55, 3. august 2026. Hendelsen pågår fortsatt. Artikkelen bygger på offentlige driftsmeldinger, nyhetsmeldinger fra NTB og egne observasjoner av innloggingsflytene. Den konkluderer ikke om teknisk årsak.
Klokken 00.50 natt til mandag startet problemene.
Da denne artikkelen ble oppdatert klokken 14.55, hadde hendelsen vart i 14 timer og 5 minutter.
Det er lenge for en nettside.
Men dette er ikke en nettside.
Det er inngangen til NAV, Altinn, skatt, helse og resepter. Samtidig er også Maskinporten rammet – løsningen som brukes når virksomheter og offentlige systemer autentiserer seg mot hverandre.
Dermed handler hendelsen ikke bare om mennesker som ikke får logget inn.
Den kan også ramme maskinene som snakker med staten på våre vegne.
ID-porten håndterte over 317 millioner innlogginger i 2021 – i snitt nesten én million i døgnet – og trafikken har vokst siden. På de travleste enkeltdagene, som da skattekortet ble sendt ut i desember, har løsningen håndtert over 3,25 millioner innlogginger på ett døgn.
Det betyr ikke at én million mennesker nødvendigvis ble rammet denne mandagen. Trafikken varierer gjennom døgnet, og mange brukere forsøker flere ganger.
Men tallene sier noe om størrelsesordenen.
Dette er ikke en nisjetjeneste som tilfeldigvis er utilgjengelig.
Det er en av de mest brukte digitale byggeklossene i Norge.
NAV kan fortsatt vise forsiden sin. Skatteetaten kan fortsatt publisere informasjon. Et nettapotek kan fortsatt vise varer.
Men dersom systemene ikke kan autentisere deg, kommer du ikke inn til dine egne opplysninger, søknader, meldinger, resepter eller tjenester.
Systemene er teknisk sett oppe. Tjenestene er i praksis utilgjengelige.
Dette er større enn BankID
Det er lett å omtale en slik hendelse som «BankID-problemer».
Observasjonene fra mandag morgen viser noe annet.
ID-portens side for valg av elektronisk identitet var tilgjengelig. Brukeren kunne velge mellom blant annet BankID, MinID, Buypass og Commfides.
Problemet oppsto etter at en innloggingsmetode var valgt.
Ved valg av BankID svarte integrasjonen:
400 - invalid_request
Invalid parameter request_uri.
request_uri does not exist.
Ved valg av Buypass svarte integrasjonen:
500 - server_error
Internal server error.
Ved valg av MinID svarte oppstarten av autentiseringen med 503 Service Unavailable, og brukeren ble møtt med meldingen:
Vi opplever høy trafikk.
Dette er forskjellige identitetsleverandører og forskjellige tekniske flyter. De returnerte forskjellige feilkoder.
Men de sviktet omtrent på samme sted: etter at ID-porten hadde vist innloggingsalternativene, og autentiseringen skulle opprettes eller videreføres hos den valgte løsningen.
Det betyr ikke at vi kjenner rotårsaken. Det betyr heller ikke at alle leverandørene hadde samme interne problem.
Men det gjør det vanskelig å forklare hendelsen som en isolert feil hos én identitetsleverandør.
Det observerbare mønsteret er at flere uavhengige innloggingsmetoder ikke kunne fullføres gjennom den samme sentrale autentiseringskjeden.
Fire knapper kan fortsatt være én avhengighet
For brukeren ser innloggingssiden redundant ut.
BankID.
MinID.
Buypass.
Commfides.
Fire valg burde intuitivt bety fire veier inn.
Men fire knapper er ikke nødvendigvis fire uavhengige feildomener.
Dersom alle alternativene er avhengige av den samme selector-tjenesten, den samme autorisasjonsflyten, det samme tilstandslageret eller den samme underliggende infrastrukturen, hjelper det lite at identitetsleverandørene i seg selv er forskjellige.
Det er nettopp dette som gjør hendelsen interessant.
BankID, Buypass og MinID svarte ulikt. Men de kunne ikke fullføre den samme sentrale innloggingsreisen.
Vi vet ikke hvilken felles komponent som sviktet. Det er et av spørsmålene en senere hendelsesrapport må besvare.
Men vi kan observere at leverandørmangfoldet ikke ga den redundansen en bruker naturlig kunne forvente.
Det er forskjell på å ha flere leverandører og å ha flere uavhengige systemer. Tre identitetsleverandører kan gi konkurranse, valgfrihet og ulike sikkerhetsmekanismer. Men dersom de alle må gjennom den samme sentrale inngangen, deler de fortsatt en kritisk avhengighet.
Redundans må måles i feildomener, ikke i logoer.
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 har ikke sagt noe om årsaken. Til NTB sier 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. Det er alt vi har fått, mer enn fjorten timer inn i hendelsen.
Til VG sier 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

Åtte meldinger, ingen årsak
Digdirs statusside har publisert åtte meldinger siden hendelsen ble opprettet. Samlet ser 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 | «Vi jobber fortsatt med å løse problemet.» | 10.30 |
| 10.30 | «Vi jobber fortsatt med å løse problemet.» | 11.30 |
| 11.43 | «Vi jobber fortsatt med å løse problemet.» | 12.30 |
| 12.41 | «Vi jobber fortsatt med å løse problemet.» | 13.30 |
| 13.36 | «Vi jobber fortsatt med å løse problemet.» | 14.30 |
| 13.53 | «Fra ca. klokken 13:40 ser det ut som trafikken er på vei oppover igjen på de rammede løsningene.» | – |
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 er 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.
Ingen av de åtte meldingene oppgir en årsak. Ingen antyder når feilen kan være rettet. Den mest konkrete opplysningen kom klokken 03.20, da direktoratet slo fast når problemet startet – en opplysning om fortiden.
Det er ikke et rimelig krav at Digdir skal spekulere offentlig i uavklarte tekniske forhold mens feilsøkingen pågår. Men fjorten timer inn i et utfall av denne typen er avstanden mellom «vi jobber med saken» og faktisk informasjon blitt påfallende stor.
Statusbildet klokken 14.45
Digdirs egen statusside gir et øyeblikksbilde som er verdt å lese nøye. Klokken 14.45 sto 19 av 47 komponenter utenfor normal drift:
| Tjeneste | Status |
|---|---|
| ID-porten | Fullt utfall |
| MinID | Fullt utfall |
| Maskinporten | Fullt utfall |
| Kontakt- og reservasjonsregisteret | Fullt utfall |
| eFormidling | Fullt utfall |
| eInnsyn | Fullt utfall |
| ELMA (web, REST) | Fullt utfall |
| PEPPOL eDelivery Network | Fullt utfall |
| Selvbetjening – API | Fullt utfall |
| Selvbetjening – Samarbeidsportalen | Fullt utfall |
| Ansattporten | Fullt utfall |
| Altinn | Redusert ytelse |
| DPO | Redusert ytelse |
| Events | Redusert ytelse |
| BankID | I drift |
| Buypass | I drift |
| Commfides | I drift |
De tre nederste radene er verdt å stoppe ved. BankID, Buypass og Commfides – tre av de fire logoene brukeren velger mellom på innloggingssiden – har stått som operative gjennom hele hendelsen.
MinID har ikke det. Statussidens egne tidsstempler viser at MinID ble satt til fullt utfall klokken 02.25, samtidig med de øvrige, og har stått slik siden. Og MinID er den eneste av de fire som Digdir drifter selv.
Her må man lese tabellen riktig. At BankID står som operativ betyr at BankID som tjeneste virker, ikke at du kommer inn med den – morgenens observasjoner viser det motsatte. Statussiden måler leverandørene, ikke reisen gjennom ID-porten.
Nettopp derfor er kontrasten interessant. Leverandørene utenfor er oppe. Det som er nede, er det Digdir selv har ansvaret for.
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 med fire faste tilstander for en hendelse:
| Tilstand | Hva den 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 den tilstanden som normalt betyr at noe er gjort.
Plattformen tvinger ikke frem den betydningen, og virksomheter bruker feltene ulikt. Men konvensjonen er etablert – og meldingsteksten ved siden av nevner ikke noe tiltak.
Det samsvarer ikke med oversikten
Direktoratets egen komponentoversikt viser ingen bevegelse. En sammenlikning av statussidens data klokken 13.52, 14.30 og 14.45 gir samme svar hver gang: ikke én komponent har endret status. 19 av 47 sto fortsatt utenfor normal drift.
Tjenestene svarer heller ikke. Fire nye forsøk mot einnsyn.no klokken 14.45 ga samme bilde som to timer tidligere – to returnerte det tomme applikasjonsskallet på 1110 byte, to ble hengende uten svar.
Trafikken kan godt være på vei oppover. Men trafikk måler hvor mange som forsøker, ikke hvor mange som kommer inn.
NAV, Altinn og skatt er bare begynnelsen
ID-porten er den felles innloggingsløsningen for et stort antall offentlige tjenester.
Når den ikke fungerer, merkes konsekvensene blant annet hos:
- NAV
- Altinn
- Skatteetaten
- Husbanken
- Helsenorge
- statlige og kommunale selvbetjeningsløsninger
- søknads- og tilskuddsordninger
- innsynstjenester
- digitale post- og skjemaløsninger
- nettapotek og digitale resepttjenester
Det betyr ikke at absolutt alle offentlige IT-systemer er nede. Åpne informasjonssider fungerer fortsatt, og mange interne fagsystemer kan være operative.
Men fra innbyggerens perspektiv rammes svært mye samtidig.
Når du ikke kommer inn på NAV, Altinn, Skatteetaten, Helsenorge, Husbanken eller kommunale tjenester, er forskjellen mellom «systemet er oppe» og «innloggingen er nede» først og fremst teknisk.
Tjenesten er ikke tilgjengelig for deg.
Også tilgang til resepter rammes
Konsekvensene stopper ikke ved skattemeldinger og offentlige skjemaer.
Under hendelsen viste Vitusapotek følgende melding til kundene:
ID-porten er utilgjengelig for øyeblikket, derfor får du dessverre ikke tilgang til reseptene dine akkurat nå. Vennligst prøv igjen litt senere.
— Driftsmelding hos Vitusapotek, 3. august 2026
Brukere får altså ikke åpnet reseptoversikten eller bestilt reseptbelagte varer gjennom nettapotekets digitale løsning.
Her er det viktig å være presis: Dette betyr ikke nødvendigvis at fysiske apotek har mistet evnen til å ekspedere resepter. Apotekenes interne systemer og andre deler av reseptkjeden kan fortsatt fungere.
Men innbyggernes digitale tilgang er rammet. Reseptfornyelse gjennom Helsenorge kan også bli utilgjengelig når brukeren ikke kommer gjennom innloggingen – selv om fastlegens journalsystem fortsatt fungerer.
Dette gjør hendelsen til mer enn et administrativt tilgjengelighetsproblem.
Den påvirker innbyggernes tilgang til helse- og legemiddeltjenester.
Norsk helsenett melder om bredere konsekvenser
Norsk helsenett registrerte problemer med innlogging til Helsenorge klokken 02.53.
I en oppdatering klokken 09.59 opplyste de at problemene hos Digitaliseringsdirektoratet fortsatt vedvarte. Statussiden viste samtidig delvis utfall for Helsenorge, redusert ytelse for HelseID og redusert ytelse for Reseptformidleren.
Norsk helsenett skrev også at brukere kunne oppleve problemer ved bruk av nettapotek og ved autentisering mot Reseptformidleren, samt med innlogging med HelseID via ID-porten og med å utføre delegeringer gjennom Altinn.
Dette er en viktig nyanse. HelseID er ikke det samme som ID-porten, og Norsk helsenett opplyste at alternative identitetsleverandører kunne fungere normalt i enkelte HelseID-flyter. Det er derfor ikke grunnlag for å si at hele helsesektoren var nede.
Men hendelsen viser hvordan en svikt i én nasjonal identitetsinfrastruktur forplanter seg til andre sektorer og autentiseringsplattformer.
Når HelseID, Helsenorge, nettapotek og deler av reseptkjeden blir påvirket samtidig, er dette ikke lenger en feil på en offentlig innloggingsside.
Det rammer digitale arbeidsprosesser i store deler av samfunnet.
Og helsekonsekvensene vokste utover morgenen.
Klokken 11.14 opplyste Norsk helsenett at pasientskjemaer i ePROM som skulle sendes til Digipost, ville bli forsinket og måtte sendes på nytt når feilen var rettet.
Klokken 12.47 kom den alvorligste meldingen så langt. Norsk helsenett opplyste at oppslag på kontaktinformasjon til pårørende i kjernejournalen var utilgjengelig.
Pressevakt Vegar Herstrøm forklarte til Digi hva det betyr i praksis:
Dette betyr at hvis du blir akutt innlagt og ikke kan svare for deg på sykehuset, så kan ikke helsepersonell slå opp i kjernejournalen for å finne kontaktinformasjon til dine pårørende.
— Vegar Herstrøm, pressevakt i Norsk helsenett, til Digi
Her forlater hendelsen kategorien administrativ ulempe.
En pasient som kommer inn bevisstløs, kan ikke selv oppgi hvem som skal varsles. Kjernejournalen er nettopp systemet som skal svare på det spørsmålet når pasienten ikke kan. Når oppslaget ikke virker, står helsepersonellet uten opplysningen i den situasjonen der den betyr mest.
Dette må sies presist. Norsk helsenett har opplyst at oppslaget er utilgjengelig, ikke at noen har blitt skadelidende. Sykehus har også andre veier til pårørende, og hvor alvorlig det slår ut vil variere med situasjonen. Men beredskapsmessig er dette et annet slags tap enn en forsinket skattemelding.
Det illustrerer hvordan en identitetshendelse sprer seg videre enn selve innloggingen.
Først får innbyggeren ikke åpnet reseptene sine. Deretter får helsepersonell problemer med delegeringer. Så forsinkes skjemaer og meldingsflyt mellom andre systemer. Og til slutt faller oppslaget som skal fortelle hvem som er dine nærmeste.
Den opprinnelige feilen kan ligge ett sted.
Konsekvensene gjør det ikke.
Utfallet stopper ikke ved grensen
Ett punkt på Digdirs egen statusliste peker ut av Norge. ELMA står som nede – både registeret og oppslagsgrensesnittet «ELMA (web, REST)». ELMA er Norges største SMP, en Service Metadata Publisher, og forvaltes av Digdir. Registeret forteller hvilke norske virksomheter som kan ta imot dokumenter i EHF-format, hvilke dokumenttyper de håndterer, og hvilket aksesspunkt de skal nås på. Det er oppslaget som må gjøres før en elektronisk faktura kan sendes.
På samme liste står «PEPPOL eDelivery Network» oppført med fullt utfall. PEPPOL er ikke en norsk løsning. Det er det europeiske nettverket for utveksling av handelsdokumenter, og ELMA er Norges knutepunkt i det. Når oppslaget mot ELMA ikke svarer, er det ikke bare norske avsendere som møter veggen – en leverandør i et annet land som skal fakturere en norsk virksomhet, gjør det samme oppslaget.
Her må man være presis. Mange aksesspunkter mellomlagrer oppslagene sine og vil kunne fortsette å levere til mottakere de allerede kjenner. PEPPOL har på sin side ingen automatisk omruting når en SMP ikke svarer – nettverket er desentralisert ved design, ikke feiltolerant på dette punktet. Konsekvensen blir ujevn: kjente ruter kan gå gjennom, nye oppslag feiler.
Men retningen er tydelig nok. En hendelse som startet som innloggingsproblemer for norske innbyggere, står nå oppført hos Digdir selv som fullt utfall i et europeisk nettverk for fakturautveksling.
Innsynsretten er også utilgjengelig
eInnsyn står oppført med fullt utfall. Tjenesten er den offentlige journalen – der journalister, forskere og innbyggere søker opp saksdokumenter og sender innsynskrav.
Egne målinger klokken 12.45 bekreftet statusen. Av seks forsøk mot einnsyn.no svarte ett, og da bare med det tomme applikasjonsskallet på 1110 byte. De øvrige fem gikk i tidsavbrudd. Også JavaScript-fila som utgjør selve applikasjonen, ga tidsavbrudd. Det som svarer, er en tom ramme uten innhold bak.
Dette fortjener en presisering av bildet lenger oppe.
Søk i eInnsyn krever ingen innlogging. Tjenesten er åpen. Når den likevel er utilgjengelig, er ikke dette utelukkende en identitetshendelse. Da rammes også noe som ligger under eller ved siden av innloggingen.
Det svekker ikke poenget om at innloggingskjeden er den mest synlige konsekvensen. Men det utvider bildet. Dette er ikke bare en dør som har låst seg. Deler av bygget bak døren svarer heller ikke.
Og konsekvensen er av en annen type enn de øvrige. NAV, skatt og resepter handler om den enkeltes tilgang til egne tjenester. eInnsyn handler om offentlighetens tilgang til forvaltningens dokumenter. Når den ligger nede, er det innsynsretten som er utilgjengelig.
Politiet: pass til nyfødte stopper opp
Klokken 13.05 bekreftet Politidirektoratet overfor VG at hendelsen også treffer politiets systemer og tjenester. Blant det som rammes er utstedelse av pass til personer som ikke har hatt pass tidligere – for eksempel nyfødte.
Skillet direktoratet selv trekker, er verdt å merke seg. Det er ikke pass generelt som stopper opp, men pass til førstegangssøkere.
En som fornyer passet sitt, kan identifiseres mot et dokument staten allerede har utstedt. En nyfødt har ikke noe slikt å bli målt mot. Identiteten må etableres for første gang, gjennom oppslag mot registre.
Politidirektoratet har ikke opplyst hvilken komponent som svikter i den kjeden, og det skal ikke gjettes på her. Men skillet peker mot at det er selve identifiseringen som er problemet, ikke produksjonen av passet.
Da er dette en hendelse der staten ikke får utstedt dokumentet som beviser hvem du er, fordi den ikke når fram til systemene som vet hvem du er.
Også politiets øvrige innbyggertjenester går gjennom den samme døren. Anmeldelsesportalen – der man kan anmelde tyveri, skadeverk, innbrudd og bedrageri digitalt, se sine innsendte anmeldelser eller fortsette på en påbegynt anmeldelse – krever innlogging med ID-porten.
Ved forsøk på innlogging mandag ettermiddag svarte tjenesten ikke. Portalen viste samtidig ingen egen driftsmelding om hvorfor. Brukeren møter bare en innlogging som ikke fullfører, uten forklaring på hva som er galt.
Statens vegvesen sier det rett ut
Der de fleste etatene viser til «tekniske problemer», navngir Statens vegvesen årsaken. Din side viste mandag ettermiddag denne meldingen:
Feil i ID-porten kan gjøre at du ikke får logget inn på Din side og andre tjenester.
— Driftsmelding på Din side, Statens vegvesen, 3. august 2026
Din side er Vegvesenets selvbetjeningsløsning for kjøretøy og førerkort – der man sjekker kjøretøyopplysninger, melder salg og eierskifte, bestiller skilt og håndterer førerkortsaker. Innlogging skjer gjennom ID-porten med MinID, BankID, Buypass eller Commfides.
Meldingen er verdt å merke seg av en annen grunn enn innholdet. Den er blant de få stedene der en etat sier til innbyggeren hva som faktisk er galt, i stedet for at feilen bare fremstår som deres egen.
Og listen fortsetter å vokse. NAV, Altinn, Skatteetaten, Helsenorge, Husbanken, nettapotek, reseptformidling, kommunale tjenester, eInnsyn, passutstedelse, politiets anmeldelsesportal, kjøretøy- og førerkorttjenester, e-fakturaoppslag og maskin-til-maskin-integrasjoner. Ikke fordi hver av dem har sin egen feil, men fordi de deler den samme inngangen.
Hva feilmeldingene forteller – og hva de ikke forteller
Den teknisk mest interessante feilmeldingen var kanskje denne:
Invalid parameter request_uri.
request_uri does not exist.
Den kan se banal ut. I virkeligheten forteller den noe konkret om hvor i innloggingsreisen svikten skjer.
ID-porten bygger på standarder som OAuth 2.0 og OpenID Connect, og bruker Pushed Authorization Requests (PAR, RFC 9126). I stedet for å sende hele autorisasjonsforespørselen gjennom nettleseren, sender klienten den direkte til autorisasjonsserveren. Serveren lagrer den midlertidig og returnerer en kortlivet referanse – en request_uri – som nettleseren tar med seg videre til valgt eID.
Enkelt forklart: Innloggingen legger igjen en midlertidig «billett» hos serveren, og nettleseren får et referansenummer. Feilmeldingen sier at billetten ikke fantes da neste ledd skulle hente den. Den sier ikke hvorfor.
Dette er et symptom, ikke en årsak.
En gammel, kopiert eller allerede brukt innloggingslenke vil normalt kunne gi samme feil, og én slik melding er ikke dokumentasjon på noe som helst. Men når den oppstår i en fersk innloggingsreise, samtidig som andre identitetsalternativer svarer med 500 og 503, er den del av et større feilbilde.
Distribuerte systemer feiler sjelden på én pen og enhetlig måte. Ulike komponenter kan reagere ulikt på det samme underliggende problemet – én melder at nødvendig tilstand mangler, en annen kaster en intern serverfeil, en tredje avviser nye forespørsler.
Feilkodene forteller hvordan hver komponent reagerte. De avslører ikke hva som utløste hendelsen. Rotårsaken kan ligge flere ledd unna det brukeren ser i nettleseren.
Det finnes flere kjente feilklasser som kan gi akkurat dette bildet. Denne artikkelen skal ikke spekulere i dem. Det er Digdirs hendelsesrapport som må besvare det – med logger, ikke hypoteser.
Fjorten timer er den virkelige historien
Den viktigste observasjonen er ikke en HTTP-kode.
Det er klokken.
Problemene startet klokken 00.50. Over fjorten timer senere var normal drift fortsatt ikke gjenopprettet, og Digdir hadde ingen prognose.
For en privat nettjeneste ville det vært en alvorlig hendelse. For en plattform som autentiserer innbyggere mot store deler av offentlig sektor, er det noe mer.
Da rammes ikke bare bekvemmelighet. Det kan påvirke:
- søknader og frister
- rapportering fra virksomheter
- utbetalinger og velferdstjenester
- tilgang til offentlige brev og vedtak
- kontakt med helsevesenet
- digitale resepter og nettapotek
- kommunale tjenester
- delegeringer og fullmakter
- automatiserte dataflyter via Maskinporten
Ikke alle rammes like hardt. Ikke alle tjenester er fullstendig utilgjengelige. Det finnes manuelle alternativer enkelte steder.
Men hendelsen traff natt til mandag – og har nå vart gjennom hele mandag morgen, inn i arbeidsdagen, når trykket mot tjenestene er størst. Jo lenger den varer, desto større blir de praktiske konsekvensene.
Fjorten timers bortfall av en nasjonal identitetstjeneste er ikke et teknisk avvik.
Det er en samfunnshendelse.
Er «hele det offentlige Norge» nede?
Teknisk sett er formuleringen for vid.
Ikke alle offentlige systemer bruker ID-porten. Åpne nettsider fungerer. Mange interne systemer er operative.
Men fra innbyggernes perspektiv er beskrivelsen forståelig. Når du ikke får tilgang til NAV, Altinn, Skatteetaten, Helsenorge, Husbanken, kommunale løsninger eller egne resepter, oppleves det som om det digitale offentlige Norge er nede.
Den mer presise formuleringen er:
Store deler av det digitale offentlige Norge er utilgjengelig for innloggede brukere.
Det er alvorlig nok.
Varigheten må forklares
Vi kjenner ikke rotårsaken. Men varigheten er et selvstendig spørsmål.
Dette er heller ikke første gang. I januar 2024 opplevde ID-porten en omfattende hendelse, og Digdir publiserte i etterkant en redegjørelse som viste hvordan en opprinnelig feil i én del av infrastrukturen ga forskjellige følgefeil i flere andre komponenter. Så sent som i juni ble flere av Digdirs fellesløsninger rammet av et tjenestenektangrep mot nettverksinfrastrukturen til driftsleverandøren Vivicta. Angrepet varte fra lørdag 20. juni klokken 13.16 til mandag 22. juni klokken 07.30. Tjenestene var helt eller delvis utilgjengelige og ustabile gjennom helgen, før Digdir meldte full normalisering mandag morgen. Direktoratet slo fast at angrepet ikke førte til sikkerhetsbrudd, og at ingen personopplysninger kom på avveie.
Dagens hendelse trenger ikke ha noen sammenheng med den. Men to omfattende tilgjengelighetshendelser med stor samfunnsmessig radius på få uker gjør behovet for en grundig, offentlig redegjørelse enda tydeligere.
Når en hendelse i en så sentral plattform varer fra klokken 00.50 og gjennom store deler av den påfølgende arbeidsdagen, bør den etterfølgende redegjørelsen være mer omfattende enn en kort statusmelding om at problemet er løst.
En hendelsesrapport bør blant annet svare på:
- Hva var den utløsende hendelsen, og når ble den oppdaget internt?
- Hvorfor tok det mer enn fjorten timer å gjenopprette stabil drift?
- Hvorfor feilet flere identitetsalternativer samtidig?
- Fungerte redundans og failover som planlagt?
- Var «høy trafikk» en årsak eller en følgeeffekt?
- Hvor mange offentlige og private tjenester ble påvirket – og hvor mange innloggingsforsøk ble avvist?
- Hvilke konsekvenser fikk hendelsen for helse- og resepttjenester, og fantes det operative reserveprosedyrer for tidskritiske tjenester?
- Hvilke tiltak skal hindre at en tilsvarende hendelse får samme varighet og radius?
- Digdir konkluderte i juni med at beredskapen fungerte godt etter DDoS-angrepet. Hvilke tiltak ble iverksatt etter den hendelsen, og ville noen av dem hatt effekt i dag?
Dette er ikke spørsmål om å plassere skyld.
Det er spørsmål om motstandsdyktighet i kritisk nasjonal infrastruktur.
Dette vet vi
Da denne artikkelen ble oppdatert, visste vi følgende:
- Problemene startet rundt klokken 00.50 natt til mandag 3. august.
- Hendelsen pågikk fortsatt klokken 14.55, og Digdir hadde ingen prognose for løsning.
- Politidirektoratet bekreftet klokken 13.05 overfor VG at politiets systemer også var rammet, blant annet utstedelse av pass til førstegangssøkere, som nyfødte.
- Digdir publiserte åtte statusmeldinger mellom 02.25 og 13.36. Den første kom 1 time og 35 minutter etter at problemet ifølge direktoratet selv startet. Ingen av dem oppga årsak eller anslag for løsning; de fem siste var ordrett like bortsett fra tidspunktet for neste melding. Sist varslet oppdatering var klokken 14.30.
- Klokken 14.30 sto 19 av 47 komponenter utenfor normal drift, uendret siden 13.52. MinID hadde stått som fullt utfall siden 02.25; BankID, Buypass og Commfides sto som operative.
- Klokken 13.53 satte Digdir hendelsen til «monitoring» og opplyste at trafikken så ut til å være på vei oppover fra ca. 13.40.
- Statusoppdateringen som var lovet klokken 14.30, kom ikke. Klokken 14.45 var siste melding fortsatt den fra 13.53, og ingen komponent var gjenopprettet.
- eInnsyn svarte i praksis ikke: fem av seks forsøk mot einnsyn.no gikk i tidsavbrudd, og det sjette returnerte kun et tomt applikasjonsskall.
- Digdir meldte om problemer i ID-porten, MinID, eFormidling, selvbetjeningsløsningene, Altinn, Kontakt- og reservasjonsregisteret, eInnsyn, Maskinporten, ELMA og Ansattporten.
- Brukerne kunne nå ID-portens side for valg av elektronisk identitet, men flere innloggingsalternativer feilet etter at de ble valgt.
- BankID-integrasjonen returnerte blant annet en manglende
request_uri, Buypass-integrasjonen intern serverfeil, og MinID503 Service Unavailablemed melding om høy trafikk. - Helsenorge var delvis utilgjengelig, og HelseID og Reseptformidleren var registrert med redusert ytelse.
- Norsk helsenett meldte om problemer med nettapotek, autentisering mot Reseptformidleren og delegeringer gjennom Altinn.
- Klokken 11.14 meldte Norsk helsenett at pasientskjemaer i ePROM til Digipost ville bli forsinket og måtte sendes på nytt.
- Klokken 12.47 opplyste Norsk helsenett at oppslag på pårørendes kontaktinformasjon i kjernejournalen var utilgjengelig.
- Vitusapotek opplyste at kunder ikke fikk tilgang til reseptene sine.
- Statens vegvesen opplyste på Din side at feil i ID-porten kunne hindre innlogging på Din side og andre tjenester.
- Politiets anmeldelsesportal, som krever innlogging med ID-porten, svarte ikke ved forsøk på innlogging.
Dette vet vi ikke
Vi vet foreløpig ikke:
- hvilken komponent som først feilet
- om hendelsen skyldtes programvare, nettverk, lagring, kapasitet eller konfigurasjon
- om en endring, en ekstern leverandør eller et angrep var involvert
- om høy trafikk startet hendelsen eller oppsto som følge av den
- om den manglende autorisasjonstilstanden var rotårsak eller bare et symptom
Det ville være uforsvarlig å fastslå noen av disse forklaringene uten logger og en teknisk redegjørelse fra Digdir og de involverte leverandørene.
Én ting er allerede tydelig.
Dette var ikke bare en isolert feil hos BankID. Flere elektroniske identitetsalternativer sviktet i samme sentrale innloggingsreise, og konsekvensene spredte seg til NAV, Altinn, Skatteetaten, Helsenorge, Husbanken, nettapotek, resepttjenester og maskin-til-maskin-integrasjoner.
Systemene bak kan fortsatt ha vært operative. Men uten en fungerende identitetskjede kunne innbyggerne ikke nå dem.
Det er den egentlige historien.
Dette er prisen for ekstremt effektive fellesløsninger.
Når de virker, slipper hvert sykehus, apotek, direktorat og kommune å bygge sin egen identitetsinfrastruktur.
Når de ikke virker, blir den samme effektiviteten til konsentrasjonsrisiko.
Det betyr ikke at Norge bør gå tilbake til hundrevis av separate innlogginger.
Det betyr at de felles løsningene må bygges, testes og overvåkes som det de faktisk er: kritisk nasjonal infrastruktur.
Den moderne staten trenger ikke miste dataene sine for å bli utilgjengelig.
Det holder at den mister evnen til å vite hvem du er.
Kilder
- VG – Digdir opplever problemer med flere løsninger
- NTB via Adressa – Ennå innloggingsproblemer for en rekke offentlige tjenester
- NTB via Romsdals Budstikke – Ennå innloggingsproblemer for en rekke offentlige tjenester
- Digdir – status for nasjonale fellesløsninger
- Digdir – over 300 millioner innlogginger i ID-porten
- Digdir – rekordhøy trafikk i ID-porten ved utsending av skattekort
- Digdir – ID-porten
- Digdir – teknisk dokumentasjon for Pushed Authorization Requests
- RFC 9126 – OAuth 2.0 Pushed Authorization Requests
- Norsk helsenett – status for Helsenorge, HelseID og Reseptformidleren
- Digi.no – innloggingsproblemer for en rekke offentlige tjenester
- Digdir – redegjørelse etter hendelsen i ID-porten 8. januar 2024
- Digdir – fellesløsningene tilbake i normal drift etter DDoS-angrepet 20.–22. juni 2026
- Digdir – dokumentasjon for ELMA, den norske SMP-en i PEPPOL
- Egne observasjoner av innloggingsflytene og HTTP-responsene fra BankID-, Buypass- og MinID-integrasjonene 3. august 2026, og av tilgjengeligheten til einnsyn.no klokken 12.45.
- Skjermbilde og driftsmelding fra Vitusapotek 3. august 2026.
Artikkelen ble skrevet mens hendelsen fortsatt pågikk. Opplysninger om varighet, omfang og teknisk årsak vil bli oppdatert når Digdir publiserer mer informasjon.