Kritisk sårbarhed i Microsoft Entra ID

Du får overblik over, hvad det rettede Microsoft Entra ID-varsel betyder for danske virksomheder.
Artiklen forklarer forskellen på en kritisk sårbarhed, en mulig hændelse og et bekræftet brud.
Du får fem kontroller til leverandørstatus, lokale logs og dokumenteret opfølgning.
Til sidst viser artiklen, hvorfor cloudansvar fortsat ligger hos virksomheden.

En alvorlig sårbarhed i Microsoft Entra ID blev først meldt aktivt udnyttet. Få dage senere blev oplysningen rettet. Sagen viser, hvorfor virksomheder skal kunne revurdere en sikkerhedssag, uden at den enten overdrives eller lukkes for hurtigt.

Microsoft Entra ID er Microsofts cloudtjeneste til styring af brugere, login og adgang til systemer. En sårbarhed i tjenesten kan derfor have betydning for en stor del af virksomhedens digitale adgangsstyring.

Den 20. august 2026 offentliggjorde Microsoft CVE-2026-69836. CERT-FR beskrev først sårbarheden som aktivt udnyttet, men rettede varslet den 24. august: Microsoft oplyste nu, at den ikke var aktivt udnyttet. Rettelsen ændrede grundlaget for at vurdere, hvor akut situationen var, men den fjernede ikke behovet for kontrol og dokumentation.

Hvad ved vi om CVE-2026-69836?

CERT-FR angiver Microsoft Entra ID som berørt og beskriver risikoen som fjernkørsel af vilkårlig kode. Den europæiske sårbarhedstjeneste hos CIRCL gengiver CVE-oplysningerne med den højeste kritiske score, 10 ud af 10, og markerer tjenesten som hostet. Microsoft driver derfor den underliggende platform og står for den tekniske rettelse; kunden kan ikke selv installere en traditionel sikkerhedsopdatering på tjenesten.

Virksomheden har dog fortsat opgaver. Den skal følge leverandørens sikkerhedsbulletin, kontrollere om der kræves handling fra kunden og vurdere, om der er tegn på uautoriseret adgang i eget miljø. En ledelsesrapport eller risikovurdering, der alene gengiver det første varsel, vil fejlagtigt angive, at sårbarheden var aktivt udnyttet.

En nedjustering betyder ikke, at sagen kan lukkes

At sårbarheden ikke var aktivt udnyttet, er ikke i sig selv dokumentation for, at den enkelte virksomhed var uberørt. Omvendt dokumenterer en kritisk score heller ikke, at der er sket et angreb. Hold derfor tre spørgsmål adskilt: Anvender vi den berørte tjeneste? Har leverandøren udbedret sårbarheden? Har vi tegn på uautoriseret adgang eller ændringer i vores eget miljø?

Svarene afgør, om virksomheden står med en kendt sårbarhed, en mulig sikkerhedshændelse eller et bekræftet brud. Sondringen gør det muligt at nedjustere beredskabet, når risikoen viser sig mindre akut, uden at afslutte den nødvendige kontrol og dokumentation.

1. Frys fakta og versionshistorik. Registrér kilden, tidspunktet, CVE-nummeret, den berørte tjeneste og grundlaget for den første beslutning. Hvis varslet senere ændres, skal den nye version knyttes til samme sag. Dokumentér, hvad der er ændret, og hvilken betydning det har haft for prioriteringen.
2. Bekræft leverandørens afhjælpning. Kontrollér leverandørens sikkerhedsbulletin og relevante driftsmeddelelser. Afklar, om sårbarheden er udbedret centralt, om kunderne skal foretage sig noget, og hvilken dokumentation virksomheden kan gemme.
3. Bevar og gennemgå lokale spor. Fastlæg en relevant periode, så nødvendige login- og ændringslogs ikke bliver slettet, før de er undersøgt. Kontrollen kan omfatte usædvanlige login, ændringer i privilegerede roller, nye applikationer og ændrede autentifikationsmetoder.
4. Klassificér sagen på ny. Beslut, om sagen fortsat alene vedrører en sårbarhed, eller om der er tegn på en sikkerhedshændelse eller et bekræftet brud. Hvis personoplysninger kan være kompromitteret, skal virksomheden vurdere risikoen for de berørte personer. En CVE udløser ikke i sig selv en anmeldelsesfrist; det gør konstateringen af et konkret brud på persondatasikkerheden.
5. Luk med evidens og ejer. Sagen bør først lukkes, når en navngiven ansvarlig har samlet leverandørens oplysninger, resultatet af den lokale kontrol, eventuelle resterende risici og begrundelsen for at lukke eller eskalere sagen.

Leverandøren kan rette den tekniske sårbarhed i platformen, men virksomheden har fortsat ansvar for egne brugere, adgange, data og beslutninger. Det kræver leverandørstyring og et beredskab, der beskriver ansvar, eskalation og dokumentation. Nesp.ONEs indlæg om cloudsikkerhed og leverandørafhængighed uddyber leverandørrisikoen, mens en IT-beredskabsplan kan fastlægge, hvem der skal reagere, undersøge og træffe beslutninger.

Ledelsen kan følge indsatsen med få målepunkter: Hvor hurtigt får et kritisk varsel en ansvarlig? Hvor lang tid går der, før leverandørens status er bekræftet? Og hvor mange afsluttede sager har den nødvendige dokumentation? Dermed bliver Entra ID-varslet en konkret test af, om virksomheden kan håndtere kritiske sårbarheder, når oplysningerne ændrer sig.