Teknisk Audit

MFA‑metoderne i udtrækket: SMS, godkendelse i app og nøgler, der modstår phishing

MFA-metoderne i udtrækket: SMS, godkendelse i app og nøgler, der modstår phishing

At MFA er slået til, siger ikke, hvilken slags anden faktor brugerne har. En kode sendt på SMS og en fysisk sikkerhedsnøgle tæller begge som MFA i en simpel oversigt, men de holder meget forskelligt. Metodernes styrke er derfor et selvstændigt kontrolpunkt ved siden af dækningen.

Udtrækket er en opgørelse over de registrerede metoder pr. bruger og over, hvilke metoder lejeren overhovedet tillader. Det holdes op mod fire målestokke, der er enige om SMS og uenige om, hvor langt man skal gå derfra.

Fire målestokke og det, de er enige om

De statslige tekniske minimumskrav er bindende for statslige myndigheder og en dansk målestok for andre. Krav 11 siger, at hvis der bruges engangskoder, “skal disse koder genereres lokalt (på enheden) og må ikke transmitteres til brugeren, f.eks. via SMS eller mail”. Vejledningen nævner som eksempler på tilladte metoder en kodeviser eller app med tidsbegrænset kode, et fysisk udleveret kodekort, en app med godkendelse, en fysisk sikkerhedsnøgle og biometri.

SAMSIK skriver i vejledningen om passwordsikkerhed fra 2026, at MFA med koder sendt via SMS “er usikre og bør derfor ikke benyttes”. Er SMS den eneste mulighed, er det dog bedre end et password alene. SAMSIK fraråder SMS, men kræver ikke metoder, der modstår phishing.

NIST SP 800-63B-4 skelner mellem metoder, der modstår phishing, og metoder, der ikke gør. Modstand mod phishing kræver kryptografisk autentificering. Metoder, hvor brugeren skriver en kode, regnes ikke som phishing-resistente, og SMS og opkald over telefonnettet er en begrænset metode. NIST er skrevet til amerikanske føderale systemer.

CISA’s baseline for Entra ID (SCuBA) går længst. MS.AAD.3.1v1 siger, at phishing-resistent MFA skal håndhæves for alle brugere, og MS.AAD.3.6v1, at den skal kræves for højt privilegerede roller. MS.AAD.3.5v2 siger, at SMS, opkald og engangskode på mail skal slås fra som metoder. MS.AAD.3.3v2 siger, at godkendelse i en app skal vise loginkonteksten. SCuBA nævner certifikatbaseret login, FIDO2-nøgler, Windows Hello for Business og passkeys bundet til enheden som phishing-resistente.

De fire er enige om, at SMS ikke bør bruges. Kun SCuBA kræver, at alle brugere har en metode, der modstår phishing. CISA og NSA har også manglende phishing-resistent MFA med blandt deres ti hyppige fejlopsætninger, som udtrykkeligt ikke er sat i rækkefølge.

Hvordan metoderne opgøres

En gennemgang bygger typisk på to udtræk. Hvordan de trækkes, er praksis.

  • Lejerens politik for godkendelsesmetoder · hvilke metoder der er slået til, og for hvem. Er SMS, opkald eller engangskode på mail slået til for alle, er det et fund mod både minimumskravene og SCuBA, uanset hvor mange der bruger dem.
  • Registrerede metoder pr. bruger · hvilke metoder hver bruger har registreret, sorteret efter den svageste. En bruger med både en sikkerhedsnøgle og SMS kan stadig logge på med SMS, hvis metoden er tilladt.

Microsofts rapport over godkendelsesmetoder viser registreringerne. Den svageste tilladte metode afgør, hvor stærk brugerens login er.

Hvad udtrækket typisk viser

Opgørelsen sorteres i tre lag, der svarer til målestokkene:

  1. Metoder, der sender koden til brugeren · SMS, opkald og mail. De falder igennem hos staten, SAMSIK og SCuBA.
  2. Metoder, hvor koden laves på enheden, eller brugeren godkender i en app · de opfylder minimumskravene og SAMSIK’s anbefaling, men er ikke phishing-resistente efter NIST og SCuBA.
  3. Kryptografiske metoder · sikkerhedsnøgler, passkeys bundet til enheden, certifikater og Windows Hello for Business. De opfylder alle fire.

Hvilket lag der er godt nok, afhænger af den målestok, I har valgt. For administratorer peger SCuBA på det tredje lag, og det er den del af overgangen, der ofte giver mest for indsatsen. Den vurdering er vores.

Godkendelse i app med kontekst

Godkendelse i en app er udbredt, og det er en af de metoder, minimumskravene tillader. SCuBA kræver, at appen viser loginkonteksten, fx hvilket program og hvorfra der logges på. Uden konteksten godkender brugeren et login uden at kunne se, hvad det gælder. Indstillingen kan læses i lejerens politik for metoden.

Når en bruger ikke kan bruge den stærke metode

Der vil ofte være brugere, der ikke kan bruge den metode, målestokken peger på, fx medarbejdere uden firmatelefon eller på delte maskiner i produktionen. Minimumskravenes liste over tilladte metoder rummer derfor også fysiske kodeviser og kodekort. Det er praksis at give de brugere en af de metoder og at skrive dem på undtagelseslisten med begrundelse, frem for at lade SMS stå åben for hele lejeren.

Hvad det kræver, og hvad det koster at lade være

Det kræver læseadgang til lejerens politik for godkendelsesmetoder og rapporten over registrerede metoder. Rettelsen er at slå de svage metoder fra, men først efter at brugerne har registreret en anden, så ingen bliver låst ude. Overgangen til metoder, der modstår phishing, kræver ofte nye nøgler eller nyere enheder og planlægges derfor som et projekt.

Uden kontrollen tæller en kode på SMS som fuld MFA i oversigten. En angriber, der kan omdirigere eller lokke en kode ud af brugeren, kommer ind på trods af den.

Det skal I lade være med

  • At slå SMS fra, før brugerne har en anden metode · så låses de ude.
  • At lade svage metoder stå tilladt som reserve · den svageste tilladte metode afgør styrken.
  • At skrive, at SAMSIK kræver phishing-resistent MFA · SAMSIK fraråder SMS, men kræver det ikke.

Det skal gennemgangen kunne vise

  • ☐ Lejerens tilladte godkendelsesmetoder med dato.
  • ☐ Registrerede metoder pr. bruger, sorteret efter den svageste.
  • ☐ Administratorer med phishing-resistent metode holdt op mod listen over administratorer.
  • ☐ Indstillingen for kontekst ved godkendelse i app.
  • ☐ Den valgte målestok for metodernes styrke.

Kilder

Senest gennemgået: november 2026.

Næste skridt

Se i lejerens politik for godkendelsesmetoder, om SMS, opkald og engangskode på mail er slået til, og tæl, hvor mange brugere der kun har dem.

Læs også: Nødkonti · CISA’s SCuBA-baselines som målestok

→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal jeres opsætning gennemgås?

Skriv kort, hvilke dele af miljøet det drejer sig om, og hvad der sætter det i gang. Så vender jeg tilbage. Gennemgangen er uvildig og uafhængig, og Nielco IT har ingen forhandleraftaler.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.