Når driften svarer, at alle har MFA, bygger svaret ofte på en oversigt over, hvem der har registreret en ekstra loginmetode. Det er et andet spørgsmål end, om MFA faktisk bliver krævet ved hvert login. Dækningen påvises ved at læse de regler, der håndhæver MFA, og ved at finde dem, reglerne ikke rammer.
De typiske huller er undtagelser for enkelte brugere og grupper, servicekonti og gamle loginmetoder, der slet ikke kan bede om en ekstra faktor.
Hvad målestokkene siger
I passwordvejledningen fra SAMSIK (2026) står anbefalingen, at der “altid anvendes flerfaktor-autentifikation på konti med privilegerede rettigheder” og altid ved fjernadgang til interne systemer. Ud over det anbefaler SAMSIK MFA, hvor det er muligt, og overordnet på alle systemer, der vender mod internettet. Det er anbefalinger.
De statslige tekniske minimumskrav, som er bindende i staten, kræver i krav 11 MFA ved adgang til systemer, som myndighedens brugere kan logge på fra internettet med deres konti. Vejledningen til kravene præciserer, at software som tjeneste uden integreret login ikke er omfattet, mens tjenester med samme brugerkonti via fælles login er. For en privat virksomhed er kravet en dansk målestok.
I CISA’s baseline for Entra ID (SCuBA) står der i MS.AAD.3.2v2, at MFA skal håndhæves for alle brugere, og i MS.AAD.1.1v1, at gamle loginmetoder skal blokeres. SCuBA binder amerikanske civile føderale myndigheder. For alle andre er den til orientering.
Efter punkt 11.3.2, litra a), i bilaget til 2024/2690 skal privilegerede konti have stærk autentificering, såsom MFA, og punkt 11.7 kræver MFA, hvor det er relevant efter klassifikationen. Det gælder de virksomhedstyper, forordningen er rettet mod.
Registreret er ikke det samme som håndhævet
Microsoft har en rapport over godkendelsesmetoder, der viser, hvor mange brugere der kan bruge MFA, fordi de har registreret en metode. Rapporten siger ikke, om metoden bliver krævet. At registrering og håndhævelse er to forskellige ting, er vores tolkning af Microsofts dokumentation, men den følger af, at håndhævelsen sker i politikkerne for betinget adgang og ikke i registreringen.
Det betyder, at en høj procentdel i rapporten over registrerede metoder kan dække over brugere, der aldrig bliver bedt om at bruge dem. Beviset for dækningen skal derfor komme fra politikkerne og fra loginloggen.
Tre kilder til huller
Undtagelser i politikkerne. Microsoft anbefaler selv at undtage nødkonti og servicekonti fra politikker for betinget adgang. Undtagelser er derfor en kendt og ofte tilsigtet grund til, at dækningen er mindre end oversigten. Problemet opstår, når undtagelsen omfatter flere end tilsigtet, fx en gruppe, der med tiden har fået nye medlemmer.
Tjenesteidentiteter og servicekonti. Kald fra tjenesteidentiteter blokeres ikke af politikker, der er rettet mod brugere. De står derfor uden for MFA, og de skal have en anden begrænsning, som er beskrevet i servicekonti.
Gamle loginmetoder. Protokoller, der ikke kan bede om en ekstra faktor, går uden om MFA, hvis de ikke er blokeret. Derfor kræver SCuBA dem blokeret. Et udtræk fra loginloggen over, hvilke klienter og protokoller der bruges, viser, om de stadig er i brug.
Udtrækkene, der viser dækningen
Valget af udtræk er praksis og står ikke i kilderne. Disse fire giver tilsammen et billede:
- Politikkerne for betinget adgang med betingelser og undtagelser · hvilke brugere, grupper, programmer og loginsituationer der kræver MFA, og hvem der er undtaget.
- Medlemmerne af de undtagne grupper · navn for navn, med begrundelse.
- Loginloggen for en periode · login, der lykkedes uden en ekstra faktor, sorteret efter bruger, program og protokol.
- Fjernadgang og internetvendte systemer uden for lejeren · VPN, fjernskrivebord og forretningssystemer med eget login, hvor MFA skal påvises særskilt.
Det tredje udtræk er det stærkeste bevis, fordi det viser, hvad der faktisk skete. Et login uden ekstra faktor, som ingen kan forklare, er et fund, selv om politikkerne ser rigtige ud på papiret.
Privilegerede konti og fjernadgang først
Hvis dækningen ikke er fuld, er det naturligt at starte med de to områder, hvor SAMSIK skriver “altid”: privilegerede konti og fjernadgang til interne systemer. En gennemgang kan holde listen over administratorer op mod politikkerne og loginloggen og påvise, at hver administratorkonto har krævet MFA ved hvert login i perioden. Listen kommer fra opgørelsen over administratorrettigheder.
Fjernadgang ligger ofte uden for lejeren, fx i en VPN-løsning eller på en terminalserver, og MFA skal derfor påvises i den løsnings egen opsætning og log.
Hvad det kræver, og hvad det koster at lade være
Det kræver læseadgang til politikkerne og loginloggen, en liste over undtagne grupper med medlemmer og en oversigt over fjernadgang og internetvendte systemer uden for lejeren. Rettelserne er ofte små: en undtagelse, der strammes, eller en gammel loginmetode, der blokeres efter en periode med måling.
Uden kontrollen tror virksomheden, at et stjålet password ikke er nok, mens det i de huller, ingen har set, netop er nok.
Det skal I lade være med
- At læse rapporten over registrerede metoder som bevis for dækning · den viser kun, hvem der kan bruge MFA.
- At undtage hele grupper for at løse ét problem · gruppen vokser.
- At glemme fjernadgang uden for lejeren · den skal påvises særskilt.
Det skal gennemgangen kunne vise
- ☐ Politikkerne for betinget adgang med betingelser og undtagelser.
- ☐ Medlemmer af undtagne grupper med begrundelse.
- ☐ Udtræk af login uden ekstra faktor i en periode, forklaret linje for linje.
- ☐ Bevis for, at gamle loginmetoder er blokeret.
- ☐ MFA på fjernadgang og internetvendte systemer uden for lejeren.
Kilder
- SAMSIK, Passwordsikkerhed, oktober 2026, side 4 og 10, læst 13. november 2026.
- De tekniske minimumskrav for statslige myndigheder 2024, opdateret september 2025, krav 11, læst 13. november 2026.
- Styrelsen for Samfundssikkerhed, Vejledning til de tekniske minimumskrav, september 2025, afsnit 3.3, læst 13. november 2026.
- CISA, M365 Secure Configuration Baseline for Microsoft Entra ID, MS.AAD.1.1v1 og MS.AAD.3.2v2, læst 13. november 2026.
- Gennemførelsesforordning (EU) 2024/2690, bilaget, punkt 11.3.2 og 11.7, læst 13. november 2026.
- Microsoft Learn, Authentication methods activity, opdateret 22. oktober 2025, læst 13. november 2026.
- Microsoft Learn, Plan a Conditional Access deployment, opdateret 1. juni 2026, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Træk loginloggen for den seneste uge, og find de vellykkede login uden en ekstra faktor. Hver linje skal kunne forklares med en undtagelse, I kender.
Læs også: MFA-metoderne i udtrækket · VPN-opsætningen
→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang hos Nielco IT
