ID-porten nede: stengt ute fra resepter, trygd og egen helse

ID-porten har vært utilgjengelig siden klokken 00.50 natt til mandag. Etter 24 timer og 40 minutter meldte Digdir om normal drift igjen, men innloggingen til NAV, Altinn, Skatteetaten, Helsenorge, nettapotek og en lang rekke andre tjenester fortsatt rammet. Årsaken er et tjenestenektangrep mot driftspartneren Vivicta — samme leverandør som ble angrepet i juni. Konsekvensene har nådd resepter, oppslag på pårørende i kjernejournalen, pass til nyfødte, innsynsretten og det europeiske nettverket for elektronisk faktura. Denne artikkelen dokumenterer det observerbare: hvor kjeden svikter, hvem som rammes, og hvorfor varigheten er den egentlige historien.

---

Oppdatert klokken 12.15 4. august 2026. Angrepet er over, men saken er ikke lukket.

Vi sjekker tilgjengeligheten fortløpende mot Digdirs status-API, Norsk helsenetts statusside og ved direkte måling av de berørte tjenestene. Sist sjekket klokken 12.15.

Denne saken er omfattende, fordi hendelsen er det. Den dokumenterer selve utfallet: hva som skjedde, hvem som rammes, og hvorfor det kunne ramme så bredt.

>

Digdirs egen kommunikasjon gjennom døgnet — meldingskjeden, den lovede oppdateringen som aldri kom, og et funn i trusseldata knyttet til ID-portens frontadresse — er skilt ut i en egen og kortere artikkel: Seksten timer før ordet «angrep» (8 minutter).

Klokken 00.50 natt til mandag startet problemene.

Utfallet varte fra klokken 00.50 mandag til normal drift ble meldt fra klokken 01.30 natt til tirsdag.

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.

Status klokken 12.15

Angrepet er over. Klokken 09.02 tirsdag meldte Digdir:

Alle løysingar er tilbake i normal drift frå ca. 01:30 i natt. Vi held denne saken open ei stund til, og vil komme med litt meir detaljar etter kvart.

— Digdir, statusoppdatering 09.02

Regnet fra utfallet startet klokken 00.50 mandag til normal drift ble meldt fra klokken 01.30 natt til tirsdag, varte hendelsen i 24 timer og 40 minutter.

Men saken er ikke lukket, og tre nye problemer har oppstått i kjølvannet.

Utenlandske datasentre kommer ikke inn

Klokken 09.45 satte Digdir flere løsninger tilbake til gul status:

Vi har mottatt meldinger fra flere som ikke får koblet seg opp mot tjenester fra datasenter i ulike land. Per nå vet vi om at følgende land kan oppleve problem med å koble til: Tyskland, Sveits, Nederland, Belgia. Vi jobber opp mot driftspartner for å løse dette.

— Digdir, statusoppdatering 09.45

Direktoratet har ikke opplyst hva som forårsaker dette, og det skal ikke gjettes på her.

Men konsekvensen er verdt å merke seg: tilgangen til norske fellesløsninger er nå begrenset avhengig av hvor i Europa trafikken kommer fra. Det rammer norske virksomheter som kjører i utenlandske skymiljøer, og utenlandske aktører som skal nå norske tjenester.

eSignering: dokumenter lar seg ikke signere

Klokken 10.10 opprettet Digdir en egen hendelse:

Det er for øyeblikket problemer med å signere dokumenter i eSignering. Dette skyldes problemene med oppkobling fra utenlandske datasentre i kjølvannet av tjenestenektangrepet mot Digdir.

— Digdir, statusoppdatering 10.10

Her knytter direktoratet selv de to sammen. Signering av dokumenter feiler fordi tilkoblingen fra utenlandske datasentre ikke virker.

eFormidling må startes på nytt manuelt

Klokken 10.44 kom en tredje hendelse. Digdir anbefaler alle som bruker meldingstypene DPO og DPV å restarte integrasjonspunktet, og viser til at det samme var nødvendig etter forrige gang.

Det er første gang direktoratet ber brukerne gjøre noe selv for å få tjenesten helt tilbake.

Statusbildet nå

Seksten komponenter står på redusert ytelse. Ingen står i fullt eller delvis utfall, men ingen av de rammede står i normal drift heller. Hovedhendelsen er fortsatt merket «monitoring», ikke «resolved».

Slik utviklet døgnet seg

Alle tidspunkter er hentet fra Digdirs egen statusside, Norsk helsenetts driftsmeldinger og publiserte nyhetsmeldinger.

Klokken 16.55, nesten seksten timer inn i hendelsen, oppga Digdir årsaken:

Det har siden kl. 01 mandag 3. august pågått et tjenestenektangrep (DDoS) som rammer ID-porten som driftes hos Digdirs driftspartner Vivicta. Dette påvirker flere av Digdirs løsninger og gjør at brukere opplever problemer med å logge inn til offentlige tjenester. Vi jobber med Vivicta om tiltak for å løse saken.

— Digdir, statusoppdatering 16.55

Meldingen svarer på det denne artikkelen hadde latt være å gjette på gjennom hele dagen.

Angrepet er ikke rettet mot ID-porten direkte, men mot infrastrukturen hos driftspartneren Vivicta — samme leverandør som ble angrepet i juni. Det forklarer hvorfor så mange ulike tjenester falt samtidig, og hvorfor BankID, Buypass og Commfides sto som operative gjennom hele hendelsen. Det som ble rammet, lå under dem alle.

Digdir oppgir i denne meldingen at angrepet har pågått «siden kl. 01», mens direktoratets egen melding klokken 03.20 anga starten til «ca 00:50». Forskjellen er ti minutter og uten praktisk betydning. Denne artikkelen holder seg til det første tallet.

Deretter snudde bildet tre ganger. Ved 16.55 ble alle komponenter oppgradert fra fullt utfall, og en time senere var problemene tilbake. Klokken 21.05 skjedde det samme på nytt, før ID-porten og MinID falt tilbake i fullt utfall klokken 22.46.

Ingen av gjenopprettingene holdt i to timer.

Egne målinger bekreftet samtidig at «de fleste løsningene fungerer» ikke dekket alle. Altinn, Helsenorge og Statens vegvesens Din side svarte raskt og med fullt innhold gjennom hele kvelden. eInnsyn gjorde det aldri — målingene ga enten det tomme applikasjonsskallet på 1110 byte eller ingen forbindelse i det hele tatt.

«Avbøtende tiltak», nevnt i meldingen klokken 22.52, er den første konkrete handlingen direktoratet har omtalt gjennom hele hendelsen. Hva tiltakene består i, er ikke opplyst.

En lege forteller

Denne artikkelen bygger ellers på offentlige driftsmeldinger, publiserte statusdata og egne målinger. Det følgende er av en annen type.

En lege som denne artikkelen har vært i kontakt med, ble mandag spurt om vedkommende hadde hatt problemer med resepter i løpet av dagen. Svaret var kort:

Ja, ved 3 anledninger, hvilket er uvanlig.

— Lege, anonymisert. Svar på direkte spørsmål om reseptproblemer mandag 3. august

Tre ganger på én arbeidsdag, og legen markerer selv at det skiller seg fra det normale.

Kilden er anonymisert av hensyn til arbeidsforholdet, og opplysningen er ikke uavhengig verifisert. Den gjengis fordi den er den eneste beskrivelsen i denne saken fra noen som selv sto i situasjonen, og fordi den sammenfaller med det Norsk helsenett samme dag meldte om redusert ytelse i Reseptformidleren.

Statussider måler komponenter. Dette er en av dem som skulle bruke dem.

For pasienten er skillet mellom at systemet er tregt og at resepten ikke ble skrevet ut, ikke teknisk.

Hvem rammes

Utfallet forplanter seg ulikt gjennom sektorene. Her er det som er dokumentert.

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.

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.

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 gjennom dagen bekrefter statusen. Målingene er gjort mot tjenestens IPv4-adresse direkte — se rettelsen nederst i artikkelen.

Klokken 22.31 ga ti forsøk mot einnsyn.no null svar. TCP-forbindelsen ble ikke etablert i noen av dem. En halvtime tidligere, klokken 21.58, svarte den samme adressen på 37 millisekunder i tre av tre forsøk — men bare med et tomt applikasjonsskall på 1110 byte, uten innhold bak.

Tjenesten veksler altså mellom å levere en tom ramme og ikke svare i det hele tatt.

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.

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.

Én feil, seksten tjenester

Det mest talende i hele hendelsen er ikke hvor mange tjenester som falt, men hvordan de falt.

Seksten komponenter har vært utenfor normal drift siden natt til mandag. Ingen ny har kommet til, ingen har falt fra. Det eneste som endrer seg er alvorlighetsgraden — og den endrer seg for nesten alle samtidig:

\* Ansattporten, ELMA, ELMA (web, REST), Kontakt- og reservasjonsregisteret, PEPPOL eDelivery Network, Selvbetjening, Selvbetjening – API, Selvbetjening – Samarbeidsportalen og eFormidling.

Tolv tjenester skifter alvorlighetsgrad i samme sekund, tre ganger på rad. Det er ikke seksten systemer som feiler hver for seg. Det er én ting som feiler, og seksten systemer som viser det.

Tre komponenter skiller seg ut ved aldri å ha vært i fullt utfall: Altinn, DPO og Events. De har en annen avhengighetsprofil enn resten.

To går konsekvent dypest: ID-porten og MinID.

BankID, Buypass og Commfides har stått som operative gjennom hele hendelsen. MinID har ikke det — den ble satt til fullt utfall klokken 02.25, samtidig med de øvrige, og er den eneste av de fire som Digdir drifter selv.

Leverandørene utenfor er oppe. Det som er nede, er det Digdir selv har ansvaret for — og det angrepet rettet seg mot.

Tallene er hentet fra Digdirs egen statusside, fanget mens hendelsen pågikk.

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, og brukeren kunne velge mellom blant annet BankID, MinID, Buypass og Commfides. Problemet oppsto først 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 med forskjellige tekniske flyter, og 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.

Da artikkelen først ble skrevet, var rotårsaken ukjent, og disse observasjonene sa ingenting om hvorvidt leverandørene hadde samme interne problem. Det de likevel viste, var vanskelig å forklare som en isolert feil hos én identitetsleverandør: flere uavhengige innloggingsmetoder kunne ikke 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 ingen av dem kunne fullføre den samme sentrale innloggingsreisen.

Den felles komponenten er nå kjent: angrepet gikk mot nettverksinfrastrukturen hos Vivicta, laget alle løsningene hviler på. Leverandørmangfoldet ga altså ikke den redundansen en bruker naturlig kunne forvente, fordi mangfoldet aldri strakte seg ned dit feilen traff.

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 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.

Varigheten må forklares

Den viktigste observasjonen er ikke en HTTP-kode.

Det er klokken.

Problemene startet klokken 00.50. Over ett døgn senere var normal drift fortsatt ikke gjenopprettet.

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.

Et døgns 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.

Ikke første gang

Årsaken er kjent. 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 er av samme type, mot samme driftspartner, seks uker senere.

Forløpet er også påfallende likt. Digdirs egne statusmeldinger fra begge hendelsene viser samme mønster: timer med utilgjengelighet, deretter et vindu der trafikken normaliserer seg og tjenestene meldes tilbake – og så et tilbakefall.

Tilbakefallet inntraff til samme klokkeslett begge ganger, selv om utfallene startet tolv timer fra hverandre i døgnet og gjenopprettingen kom på ulike tidspunkt.

Presisjonen er ikke lik i de to tilfellene. I juni oppga Digdir «fra kl 17:55», gjentatt i tre påfølgende meldinger. I august står det «fra ca. 17:55», i én melding. Klokkeslettet er det samme; nøyaktigheten er anslått i det ene tilfellet.

Dette er en observasjon fra Digdirs publiserte statusdata, ikke en påstand om hvorfor. Hva likheten skyldes – om den i det hele tatt betyr noe – er blant det en hendelsesrapport må besvare.

To andre forskjeller er verdt å merke seg, og de går i motsatt retning av hva man skulle vente etter en øvelse.

Varslingen gikk saktere andre gang. I juni ble hendelsen opprettet på statussiden 13 minutter etter at utfallet startet. I august gikk det én time og 35 minutter.

Og den konkrete årsaksbeskrivelsen kom senere. I juni omtalte Digdir «nettverksproblem» etter knapt ti timer. I august kom ordet «tjenestenektangrep» etter nesten seksten.

Begge tallene er hentet fra direktoratets egne publiserte meldinger.

To omfattende tilgjengelighetshendelser med stor samfunnsmessig radius på seks uker, mot samme leverandør og av samme type, gjør behovet for en grundig og offentlig redegjørelse desto tydeligere.

Og det var ikke bare seks uker. Det var også dagen før.

Natt til søndag 2. august, drøyt et døgn før dette angrepet startet, gikk Digdirs Digital postkasse og eSignering ned fordi Digipost var utilgjengelig. Utfallet varte fra klokken 03.32 til normal drift ble meldt 07.46, og hendelsen ble formelt lukket klokken 13.23. Digdir klassifiserte den som «major».

Her må man skille. Digipost driftes av Posten, ikke av Vivicta. Søndagens hendelse har ingen kjent sammenheng med mandagens angrep, og det er to forskjellige feildomener.

Nettopp derfor er de verdt å se sammen. To dager på rad falt sentrale fellesløsninger ut fordi en ekstern operatør sviktet — først Digipost, så Vivicta. Det er ikke en påstand om at noen har gjort noe galt. Det er en illustrasjon av hvor mange andres driftsstabilitet den norske fellesinfrastrukturen faktisk hviler på.

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.

Spørsmål en hendelsesrapport bør besvare

Den bør blant annet svare på:

1. Hva var den utløsende hendelsen, og når ble den oppdaget internt?
2. Hvorfor tok det mer enn ett døgn å gjenopprette stabil drift?
3. Hvorfor feilet flere identitetsalternativer samtidig?
4. Fungerte redundans og failover som planlagt?
5. Var «høy trafikk» en årsak eller en følgeeffekt?
6. Hvor mange offentlige og private tjenester ble påvirket – og hvor mange innloggingsforsøk ble avvist?
7. Hvilke konsekvenser fikk hendelsen for helse- og resepttjenester, og fantes det operative reserveprosedyrer for tidskritiske tjenester?
8. Hvilke tiltak skal hindre at en tilsvarende hendelse får samme varighet og radius?
9. 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 ikke

Vi vet foreløpig ikke:

• hvilken komponent som først feilet
• hvordan angrepet teknisk slo ut, og hvorfor det rammet så bredt
• hvorfor tjenestene falt igjen fra 17.55 etter å ha vært delvis tilbake
• om det er en sammenheng mellom juni-angrepet og dagens, ut over at de rammet samme leverandør
• 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
• WAYSCloud – trusseloversikt for AS5619 og IP-oppslag for 139.105.36.167
• Vivicta – Tietoevry Tech Services blir Vivicta (2025)
• Egne DNS-oppslag mot ID-portens innloggingsverter og RIPE/Team Cymru-oppslag mot AS5619, 3. august 2026.
• 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.
• Egen kontakt med lege 3. august 2026, anonymisert etter avtale.

Rettelser

3. august, kl. 22.35 — eInnsyn-målinger. Tidligere versjoner av denne artikkelen oppga at flere måleforsøk mot einnsyn.no gikk i tidsavbrudd. Målingene ble gjort gjennom vanlig navneoppslag fra en server uten IPv6-rute, mens einnsyn.no har både A- og AAAA-record. En del av de rapporterte tidsavbruddene skyldtes derfor måleoppsettet, ikke tjenesten. Tallene er erstattet med målinger gjort direkte mot tjenestens IPv4-adresse. Konklusjonen står: eInnsyn leverte ikke innhold på noe tidspunkt gjennom dagen.

3. august — tilbakefallstidspunkt. Sammenlikningen med juni-hendelsen oppga først 17.55 som eksakt tidspunkt for begge tilbakefall. Digdir oppgir «kl 17:55» for juni og «ca. 17:55» for august. Tabellen er rettet.

Artikkelen ble skrevet mens hendelsen fortsatt pågikk. Opplysninger om varighet, omfang og teknisk årsak vil bli oppdatert når Digdir publiserer mer informasjon.