⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

NIST SP 800-63-4: revisionsbevis for adgangskoder, MFA og passkeys

Igor Petreski
14 min read
Diagram over kortlægning af revisionsbevis for adgangskoder, MFA og passkeys i NIST SP 800-63-4

Kl. 08:10 en mandag modtager en CISO i en fintech-virksomhed den besked, som enhver sikkerhedsleder frygter: “Vi ser mistænkelige loginforsøg mod økonomifunktionens administrationsportal. MFA blev godkendt, men brugeren siger, at det ikke var vedkommende.”

Kl. 08:25 ser SOC’et mønstret. Angriberen brød ikke krypteringen, udnyttede ikke en zero-day-sårbarhed og omgik ikke en firewall. Angriberen phishede en adgangskode, udløste en push-anmodning og ventede på MFA-træthed. Én godkendelse var nok. Kontoen havde forhøjet adgang til eksport af kundefakturering, revisionslogfiler og et tredjepartsdashboard til afregning.

Kl. 09:00 spørger juridisk afdeling, om der er tale om et brud på persondatasikkerheden efter GDPR. Risikoteamet spørger, om hændelsen udløser DORA-rapportering. Bestyrelsen vil vide, om virksomhedens udsagn om “MFA overalt” faktisk var korrekt. ISO 27001-revisoren, som allerede er planlagt til næste måned, ønsker nu revisionsbevis for sikker autentifikation, adgangsstyring, logning og korrigerende handlinger.

Derfor er NIST SP 800-63-4 vigtig i 2026.

For CISO’er, complianceansvarlige og forretningsejere er NIST SP 800-63-4 ikke blot endnu et identitetsdokument. Den er ved at blive den praktiske reference for moderne adgangskodepolitik, phishing-resistent MFA, passkeys, adgangskodefri autentifikation og styring af autentifikatorers livscyklus. Den reelle udfordring er ikke at læse vejledningen. Udfordringen er at dokumentere implementeringen på tværs af ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 og interne revisionsforventninger.

Clarysecs position er enkel: identitetskontroller fejler, når de behandles som indstillinger og ikke som governance. Adgangskoder, MFA, passkeys, genopretningsprocesser, sessionstokens, privilegeret adgang, servicekonti og autentifikationslogfiler skal designes som ét samlet kontrolsystem, der producerer revisionsbevis.

Det er den tilgang, der anvendes i Zenith Blueprint: en 30-trins køreplan for revisorer, i Clarysecs politikbibliotek og i Zenith Controls: vejledningen til tværgående efterlevelse. Zenith Controls opretter ikke nye kontroller. Den kortlægger kontrolforventninger i ISO/IEC 27001:2022 og ISO/IEC 27002:2022 på tværs af andre standarder, regler og revisionsperspektiver, så organisationer kan undgå fragmenteret revisionsbevis og dobbeltarbejde med compliance.

“MFA aktiveret” er ikke et revisionssvar

Mange organisationer gik ind i de seneste år med den opfattelse, at udrulning af MFA afsluttede drøftelsen om identitetsrisiko. I 2026 er den antagelse usikker.

Revisorer og tilsynsmyndigheder stiller nu skarpere spørgsmål:

  • Håndhæves MFA for al privilegeret, ekstern og højrisikoadgang?
  • Er autentifikationen phishing-resistent, hvor risikoen kræver det?
  • Styres passkeys eller FIDO2-autentifikatorer gennem tilmelding, genopretning, tilbagekaldelse og enhedslivscyklus?
  • Screenes adgangskoder mod lister over kompromitterede og almindelige legitimationsoplysninger?
  • Udløses adgangskodeskift af kompromittering frem for vilkårlig kalenderbaseret rotation?
  • Kan brugere indsætte adgangskoder fra adgangskodeadministratorer?
  • Logges og gennemgås hændelser vedrørende autentifikatorer?
  • Er processer for kontogendannelse lige så stærke som loginprocesser?
  • Styres API-hemmeligheder, OAuth-tokens, SSH-nøgler og legitimationsoplysninger til servicekonti med samme disciplin?

NIST SP 800-63-4 flytter organisationer i retning af risikobaseret sikring af digital identitet, autentifikatorstyrke og livscyklusbaseret revisionsbevis. For modernisering af adgangskoder betyder det, at forældede vaner som tvungne periodiske adgangskodeskift uden tegn på kompromittering skal udfases, samtidig med at længde, screening mod kompromitterede adgangskoder, begrænsning af loginforsøg, sikker opbevaring og genopretningskontroller styrkes. For MFA og passkeys betyder det fokus på autentifikatorsikring, phishing-resistens, sikker tilmelding, kontobinding, tilbagekaldelse og revisionsbarhed.

Zenith Blueprint beskriver dette skifte i Kontroller i praksis, trin 19, Teknologiske kontroller I, i gennemgangen af sikker autentifikation:

Autentifikation er den første og mest kritiske forsvarslinje mellem en trusselsaktør og jeres systemer, data og tjenester. Hvis autentifikationen er svag, kan alt andet, kryptering, overvågning, segmentering, omgås. Kontrol 8.5 sikrer, at autentifikationsmekanismer er sikkert designet, konsekvent anvendt og modstandsdygtige over for kendte angrebsmetoder.

Den sætning er kernen i identitetsrevisionen i 2026. Spørgsmålet er ikke længere “Har I adgangskoder og MFA?” Spørgsmålet er: “Kan I dokumentere, at jeres autentifikationsarkitektur er risikobaseret, modstandsdygtig over for kendte angrebsmetoder, konsekvent håndhævet og overvåget?”

Opbyg kontrolsystemet omkring identitet, autentifikationsoplysninger og sikker autentifikation

Den mest anvendelige måde at omsætte NIST SP 800-63-4 til revisionsbevis for ISO/IEC 27001:2022 er at behandle identitet som et sammenhængende kontrolsystem.

Gennem Zenith Controls identificerer Clarysec tre centrale kontrolområder i ISO/IEC 27002:2022 for tilpasning til NIST SP 800-63-4: 5.16 Identitetsstyring, 5.17 Autentifikationsoplysninger og 8.5 Sikker autentifikation. I ISO/IEC 27001:2022 Anneks A er disse A.5.16, A.5.17 og A.8.5.

KontrolområdeHvad det styrerTema for revisionsbevis i NIST SP 800-63-4Typisk revisionsbevis
ISO/IEC 27002:2022 5.16 IdentitetsstyringIdentitetslivscyklus, unikhed, tiltrædelses-, omplacerings- og fratrædelsesprocesser, kontoejerskabDokumentation for, at identiteter er unikke, verificerede, tildelte, gennemgåede og fjernedeIdP-eksporter, HR-sager for tiltrædelser, omplaceringer og fratrædelser, gennemgang af adgangsrettigheder, workflow for identitetsverifikation
ISO/IEC 27002:2022 5.17 AutentifikationsoplysningerAdgangskoder, PIN-koder, nøgler, certifikater, tokens, API-hemmeligheder, gendannelseskoderAutentifikatorers livscyklus, opbevaring, transmission, rotation, tilbagekaldelse og genopretningAdgangskodepolitik, registreringer fra vault til hemmeligheder, logfiler for tilbagekaldelse af tokens, logfiler for tilmelding af passkeys, nulstillingsprocedurer
ISO/IEC 27002:2022 8.5 Sikker autentifikationAutentifikationsdesign, MFA, sessionsstyring, systemspecifikke kravRisikobaseret MFA, passkeys, phishing-resistens, håndhævelse af adgangskodefri adgang, sessionsbeskyttelsePolitikker for betinget adgang, rapporter om MFA-dækning, WebAuthn- og FIDO2-indstillinger, konfiguration af sessionstimeout

Skellet er vigtigt. A.5.16 spørger: “Hvem har en identitet?” A.5.17 spørger: “Hvordan beskyttes beviset for den identitet?” A.8.5 spørger: “Hvordan udføres autentifikation sikkert i systemer?”

Når organisationer ikke består revisioner, skyldes det ofte, at de implementerer ét lag uden de andre. De udruller passkeys, men kan ikke fremvise revisionsbevis for tilbagekaldelse. De håndhæver MFA, men ikke for en ældre administratorkonsol. De fastsætter adgangskoderegler, men screener ikke mod kompromitterede adgangskoder. De deaktiverer en brugerkonto, men glemmer aktive sessioner eller gendannelsestokens.

I Zenith Blueprint, Kontroller i praksis, trin 22, organisatoriske kontroller, forklarer Clarysec A.5.17 som et livscyklusspørgsmål:

Hvis identitet er spørgsmålet “Hvem er du?”, så er autentifikation beviset. Kontrol 5.17 er der, hvor teori møder tillid. Den kræver, at autentifikationsoplysninger håndteres sikkert gennem hele deres livscyklus, så de metoder og legitimationsoplysninger, der bruges til at verificere identitet, ikke selv bliver det svageste led.

En passkey er ikke compliant, blot fordi den findes. Den bliver forsvarlig, når I kan dokumentere, hvordan den tilmeldes, bindes, beskyttes, gendannes, tilbagekaldes, logges og gennemgås.

Modernisér adgangskoder uden at miste revisionsmæssig sporbarhed

Mange virksomheder har stadig adgangskodepolitikker, der er skrevet til en anden trusselsmodel. “Tolv tegn, symboler, skift hver 90. dag” er velkendt, men genkendelighed er ikke det samme som robusthed.

NIST SP 800-63-4 styrker en mere moderne tilgang: længere adgangskoder og adgangsfraser, screening mod kompromitterede eller almindeligt anvendte adgangskoder, begrænsning af loginforsøg, sikker nulstilling, ingen vilkårlige periodiske skift, medmindre der er mistanke om kompromittering, og brugervenlige kontroller, der understøtter adgangskodeadministratorer. Det betyder ikke, at alle organisationer skal omskrive alle politikker fra den ene dag til den anden. Det betyder, at adgangskodekrav skal være risikobaserede, teknisk håndhævede og afstemt med revisionsbevis for ISO 27001.

Clarysecs politikbibliotek for SMV’er giver mindre organisationer en praktisk baseline, som kan forbedres i takt med modenheden. Politik for styring af brugerkonti og privilegier - SMV fastsætter:

Adgangskoder skal opfylde kompleksitetskrav (f.eks. mindst 12 tegn, alfanumeriske tegn med symboler) og ændres mindst hver 90. dag.

Dette er et nyttigt og håndhæveligt udgangspunkt for SMV’er. Et moderniseringsprojekt i 2026 baseret på NIST SP 800-63-4 bør dog gennemgå, om fast udløb efter 90 dage fortsat er passende for det enkelte system, især når MFA, screening mod kompromitterede adgangskoder, stærk adgangskodelængde og arbejdsgange for nulstilling udløst af kompromittering er på plads. I praksis bevarer mange organisationer baselinen i overgangsperioden og tilføjer derefter et tillæg om modernisering af adgangskoder, som godkendes gennem risikobehandling og anvendelighedserklæringen.

For større virksomhedsmiljøer giver Clarysecs Politik for styring af brugerkonti og privilegier et styringsmæssigt anker frem for at hardkode alle adgangskoderegler:

Alle brugerkonti skal håndhæve adgangskodekompleksitet og udløb i overensstemmelse med organisationens adgangskodepolitik.

Den formulering gør det muligt for CISO’en at opdatere adgangskodepolitikken, så den er tilpasset NIST SP 800-63-4, uden at omskrive hele rammeværket for adgangsstyring.

En praktisk pakke med revisionsbevis for modernisering af adgangskoder bør omfatte:

  • Gældende adgangskodepolitik og godkendt moderniseringstillæg.
  • IdP-konfiguration, der viser minimumslængde, maksimumslængde og tilladte tegn.
  • Revisionsbevis for, at adgangskodeadministratorer er tilladt, herunder indsætningsfunktionalitet hvor relevant.
  • Konfiguration for screening mod kompromitterede, svage og almindelige adgangskoder.
  • Politik for begrænsning af loginforsøg eller låsning ved online gætteangreb.
  • Workflow for nulstilling af adgangskode, der kræver tilstrækkelig identitetsverifikation.
  • Arkitektur for opbevaring af adgangskodehashes i applikationer, der opbevarer legitimationsoplysninger.
  • Undtagelsesregister for ældre systemer, der ikke kan understøtte moderne indstillinger.
  • Procedure for nulstilling udløst af kompromittering med kobling til hændelseshåndtering.
  • Revisionsbevis for brugerkommunikation og træning.

Målet er ikke at vinde en diskussion om én bestemt adgangskodelængde. Målet er at dokumentere, at adgangskodebaseret autentifikation er styret, målbar og integreret i ISMS’et.

Flyt MFA og passkeys fra “anden faktor” til sikring

Mandag morgen-hændelsen begyndte med MFA-træthed. Derfor spørger revisorer i stigende grad, om MFA er phishing-resistent, ikke blot om den findes.

Traditionelle MFA-metoder som SMS, e-mail-OTP, TOTP-apps og push-notifikationer kan reducere risiko, men de er ikke lige stærke. Passkeys og FIDO2/WebAuthn-autentifikatorer giver stærkere modstand mod phishing, fordi autentifikation bindes til den legitime origin og anvender public key-kryptografi. For højrisikobrugere, privilegerede administratorer, økonomigodkendere, udviklere med adgang til produktionsmiljøer og fjernadgangsveje bør phishing-resistent MFA behandles som måltilstanden, medmindre der foreligger en dokumenteret og godkendt undtagelse.

Clarysecs enterprise-Politik for sikker kommunikation og multifaktorautentifikation (MFA) fastsætter baselinen:

Multifaktorautentifikation (MFA): Al adgang til organisationens netværk og informationssystemer, navnlig privilegeret adgang eller fjernadgang, skal kræve multifaktorautentifikation (MFA) (f.eks. adgangskode plus OTP-token eller biometrisk faktor). MFA-løsninger skal være tilpasset branchens bedste praksis (f.eks. tidsbaserede engangskoder eller hardwarenøgler) og skal konfigureres til at beskytte mod uautoriseret adgang.

For SMV’er fastsætter Politik for adgangsstyring - SMV:

Privilegerede konti skal anvende multifaktorautentifikation (MFA), hvor det understøttes.

Formuleringen “hvor det understøttes” giver SMV’er en realistisk implementeringsvej, men den skaber også en revisionsforpligtelse. Hvis et privilegeret system ikke understøtter MFA, skal organisationen dokumentere kompenserende kontroller som netværksrestriktioner, styring af privilegeret adgang (PAM), jumpserver, kortere sessioner, overvågning, vault-baseret opbevaring og en migreringsplan.

Zenith Blueprint, Kontroller i praksis, trin 19, er tydelig om retningen:

Hvor det er muligt, bør autentifikation alene med adgangskode undgås, især for administratorkonti, cloudkonsoller, fjernadgangsværktøjer og alle systemer, der er eksponeret mod internettet. MFA med en anden faktor som hardwarenøgle, mobilapp eller biometri er nu en baseline, ikke en luksus.

Passkeys passer naturligt ind i denne fortælling. En udrulning af passkeys bør ikke præsenteres alene som en teknologisk opgradering. Den bør dokumenteres som en risikobehandling for phishing, credential stuffing, MFA-træthed, genbrug af adgangskoder og kontoovertagelse.

Den passkey-model for revisionsbevis, som revisorer har brug for

Passkeys kan være synkroniserbare, enhedsbundne, hardwareunderstøttede, platformsbaserede eller roamingbaserede afhængigt af autentifikatoren og økosystemet. Sikring afhænger af tilmelding, enhedstillid, genopretning, kontobinding og tilbagekaldelse. Et passkey-projekt uden revisionsbevis kan skabe revisionsmæssig uklarhed, selv når teknologien er stærk.

Brug denne model til at forberede en revisionsklar udrulning af passkeys.

Spørgsmål til revisionsbevisHvad skal dokumenteresArtefakt
Hvem kan tilmelde passkeys?Tilmelding er begrænset til verificerede brugere og godkendte konteksterTilmeldingspolitik, IdP-regler, berettigelse for brugergrupper
Hvilken type passkey er tilladt?Autentifikatortypen matcher risikoniveauetStandard for autentifikatorsikring, tilladt AAGUID eller enhedspolitik hvor understøttet
Hvordan beskyttes tilmelding?Angribere kan ikke tilføje deres egen autentifikator efter at have stjålet en adgangskodeStep-up MFA, helpdesk-verifikation, tilmeldingsalarmer
Hvordan håndteres genopretning?Genopretning er ikke svagere end loginGenopretningsprocedure, supportscripts, logfiler for identitetsverifikation
Hvordan håndteres mistede enheder?Mistede autentifikatorer tilbagekaldes hurtigtSager om tilbagekaldelse, enhedsfortegnelse, IdP-hændelseslogfiler
Hvordan behandles privilegeret adgang?Administratorer anvender phishing-resistente metoder, hvor det krævesPolitikker for betinget adgang, rolletildelinger med privilegerede rettigheder
Hvordan logges brugeraktivitet?Autentifikationshændelser opbevares og gennemgåsAutentifikationslogfiler, SIEM-forespørgsler, alarmregler
Hvordan styres undtagelser?Ældre systemer og udelukkede brugere har godkendt risikobehandlingUndtagelsesregister, udløbsdatoer, kompenserende kontroller

Dette stemmer direkte overens med ISO/IEC 27001:2022. Pkt. 4.1 til 4.4 kræver, at organisationer forstår kontekst, interessenter, ISMS-omfang og driftsprocesser. Pkt. 5.1 til 5.3 kræver lederskab, politik, organisatoriske roller og ansvar. Pkt. 6.1.2 og 6.1.3 kræver en gentagelig risikovurdering af informationssikkerhed og en risikobehandlingsproces, herunder kontroludvælgelse, sammenligning med Anneks A, en anvendelighedserklæring og risikoejers godkendelse af restrisiko. Pkt. 6.2 kræver målbare informationssikkerhedsmål.

Det betyder, at en udrulning af passkeys bør fremgå af ISMS’et som:

  • En risikobehandling for tyveri af legitimationsoplysninger og phishing.
  • Et mål, f.eks. “90 procent af privilegeret adgang migreret til phishing-resistent MFA inden Q3.”
  • En begrundelse i anvendelighedserklæringen knyttet til A.5.16, A.5.17 og A.8.5.
  • En opdatering af politik for adgangsstyring.
  • Et anvendelsesscenarie for logning og overvågning.
  • En pakke med revisionsbevis.

I Zenith Blueprint, risikostyringsfasen, trin 13, planlægning af risikobehandling og anvendelighedserklæring, beskriver Clarysec SoA’en som en bro:

SoA’en er reelt et brodokument: den forbinder jeres risikovurdering/-behandling med de faktiske kontroller, I har. Ved at udfylde den dobbelttjekker I også, om I har overset kontroller.

For NIST SP 800-63-4 er denne bro dér, hvor beslutninger om adgangskoder, MFA og passkeys bliver revisionsbare.

Tværgående compliance-kortlægning for ISO 27001, NIS2, DORA, GDPR, NIST CSF og COBIT

Revisionsbevis for identitet bliver stærkt, når ét sæt kontroller opfylder flere forpligtelser.

NIS2 Article 21 kræver, at væsentlige og vigtige enheder implementerer passende og forholdsmæssige tekniske, driftsmæssige og organisatoriske foranstaltninger, der afspejler risiko, det aktuelle tekniske niveau, implementeringsomkostninger, størrelse og hændelsespåvirkning. Article 21(2) omfatter risikoanalyse, politikker, håndtering af hændelser, forretningskontinuitet, sikkerhed i forsyningskæden, sikker udvikling, vurdering af kontroleffektivitet, cyberhygiejne og træning, kryptografi, HR-sikkerhed, adgangsstyring, styring af aktiver og, hvor relevant, multifaktorautentifikation eller løbende autentifikation. Article 20 gør ledelsens godkendelse, tilsyn og cybersikkerhedstræning til en styringsforpligtelse.

DORA bringer samme identitetstema ind i finansiel operationel robusthed. Omfattede finansielle enheder skal opretholde en dokumenteret ramme for styring af IKT-risiko med ledelsesorganets ansvar, beskyttelses- og forebyggelseskontroller, adgangsstyring, autentifikation, overvågning, anomalidetektion, kontinuitet, respons, genopretning og træning. Articles 8 til 10 er særligt relevante for identifikation af IKT-aktiver og afhængigheder, beskyttelse af IKT-systemer, adgangsstyring, stærk autentifikation, overvågning og detektion. Articles 17 til 19 forbinder det samme revisionsbevis med IKT-relateret hændelsesstyring og rapportering.

GDPR gælder, hvor personoplysninger behandles inden for forordningens territoriale og materielle anvendelsesområde. Article 5(1)(f) kræver, at personoplysninger behandles med passende sikkerhed. Article 5(2) kræver ansvarlighed. Article 32 kræver passende tekniske og organisatoriske foranstaltninger for at sikre et sikkerhedsniveau, der passer til risikoen. En stjålet adgangskode eller kompromitteret autentifikator kan blive et brud på persondatasikkerheden, hvis det medfører uautoriseret adgang til personoplysninger.

NIST CSF 2.0 tilføjer et nyttigt ledelseslag. GOVERN Function kræver, at juridiske, regulatoriske og kontraktlige cybersikkerhedskrav, herunder forpligtelser vedrørende privatliv, forstås og styres. CSF Profiles hjælper organisationer med at sammenligne nuværende og ønskede tilstande og udarbejde prioriterede handlingsplaner.

COBIT 2019 og ISACA-revisionstilgange spørger, om identitets- og adgangskontroller understøtter governance-mål, om ledelsespraksisser er defineret, om autentifikationsstyrke matcher risiko, og om kontroludførelse er dokumenteret.

KravtemaISO/IEC 27001:2022 og ISO/IEC 27002:2022NIS2DORAGDPRNIST CSF 2.0
Styringsmæssigt ansvarPkt. 5.1 til 5.3, 6.1.3, Anneks A-kontroller for adgang og overvågningArticle 20 ledelsesgodkendelse og tilsynArticles 5 og 6 ledelsesorganets ansvar og IKT-risikostyringsrammeArticle 5(2) ansvarlighedGV.OC, GV.RM, GV.RR, GV.PO, GV.OV
Stærk autentifikationA.5.16, A.5.17, A.8.5Article 21 adgangsstyring og MFA hvor relevantArticle 9 beskyttelse, forebyggelse og stærk autentifikationArticle 32 behandlingssikkerhedPR.AA identitetsstyring, autentifikation og adgangsstyring
AutentifikatorlivscyklusA.5.17 autentifikationsoplysningerArticle 21 risikobaserede foranstaltningerArticle 9 sikkerhedsforanstaltninger for adgangsstyring og autentifikationArticles 5 og 32 beskyttelse mod uautoriseret adgangGV.RM, PR.AA
Logning og detektionA.8.15 Logning, A.8.16 OvervågningsaktiviteterArticle 21 håndtering af hændelser og kontroleffektivitetArticles 10, 17 og 18 detektion og hændelsesklassificeringDetektion af brud understøtter beslutninger efter Articles 33 og 34DE.CM, RS.MA
HændelsesrapporteringA.5.24 til A.5.28 håndtering af informationssikkerhedshændelserArticle 23 tidlig advarsel, hændelsesunderretning og kadence for slutrapportArticles 17 til 19 proces og rapporter for IKT-relaterede hændelserArticles 33 og 34 underretning om brud på persondatasikkerhedenRS.CO, RC.RP
Tredjepartsafhængigheder for identitetA.5.19 til A.5.23 leverandørrelationer og cloudtjenesterArticle 21 sikkerhed i forsyningskædenArticles 28 til 30 IKT-tredjepartsrisikoDataansvarliges og databehandleres ansvarlighedGV.SC

Den samme IdP-rapport om betinget adgang kan understøtte ISO 27001-adgangsstyring, NIS2-MFA, DORA-autentifikation, GDPR-sikkerhedsansvarlighed og fremdrift mod en NIST CSF-målprofil.

Opbyg en pakke med revisionsbevis for autentifikatorer på én eftermiddag

En CISO, complianceansvarlig eller IT-ansvarlig kan hurtigt opbygge en værdifuld pakke med revisionsbevis ved at fokusere på ét højrisikosystem, f.eks. en cloudkonsol, en økonomiplatform, en kundeadministrationsportal eller et produktionsmiljø til udrulning.

Definér først omfanget. Identificér forretningsejeren, dataklassificering, brugergrupper, privilegerede roller, fjernadgangsveje, aktuelle autentifikatorer, involverede personoplysninger og tredjepartsafhængigheder. Dette understøtter ISO/IEC 27001:2022 pkt. 4.1 til 4.4, fordi omfang, krav fra interessenter og afhængigheder skal være forstået.

Indsaml derefter de aktuelle autentifikationsindstillinger. Eksportér eller tag skærmbilleder af adgangskodepolitikken, MFA-håndhævelsen, passkey- eller FIDO2-konfigurationen, regler for betinget adgang, sessionstimeout, genopretningsmetoder, nødkonti og status for ældre autentifikationsmetoder. Hvis systemet anvender lokal autentifikation, skal årsagen dokumenteres, og en migreringsvej defineres.

Sammenlign derefter med en klar måltilstand:

  • Adgangskoder screenes for svage, almindelige og kompromitterede legitimationsoplysninger.
  • Ingen adgang alene med adgangskode for privilegerede, eksterne eller interneteksponerede systemer.
  • Phishing-resistent MFA for administratorer og højrisikobrugere.
  • Sikker tilmelding og genopretning.
  • Tilbagekaldelse af autentifikatorer ved fratrædelse eller tab af enhed.
  • Logning af vellykket og mislykket autentifikation, MFA-brug og ændringer af autentifikatorer.
  • Alarmer for geografisk umulige login, gentagne fejl, ny autentifikatortilmelding og risikofyldte login.

Vedhæft derefter politikbevis. SMV-Politik for adgangsstyring - SMV kræver:

Unikke brugernavne er påkrævet; delte konti er forbudt.

For revisionsbevis vedrørende kontolivscyklus fastsætter SMV-Politik for styring af brugerkonti og privilegier - SMV:

Logfiler over oprettelse af konti, deaktivering af konti og ændringer af privilegier skal opbevares sikkert i mindst 12 måneder.

For autentifikationslogning specificerer Clarysecs Lognings- og overvågningspolitik - SMV:

Autentifikationslogfiler: vellykkede og mislykkede loginforsøg, sessionsvarighed, MFA-brug

For enterprise-implementeringer kræver Lognings- og overvågningspolitik logning af:

Brugerautentifikation og adgangsforsøg

Opdatér derefter anvendelighedserklæringen. Markér A.5.16, A.5.17 og A.8.5 som anvendelige, og tilføj noter såsom:

  • Understøtter forventningerne i NIST SP 800-63-4 til autentifikatorers livscyklus.
  • Understøtter forventningerne i NIS2 Article 21 til adgangsstyring og MFA.
  • Understøtter DORA-krav til autentifikation og overvågning i styring af IKT-risiko.
  • Understøtter GDPR Article 32-sikkerhed og ansvarlighed for adgang til personoplysninger.
  • Undtagelse: ældre afregningsportal mangler FIDO2-understøttelse. Kompenserende kontroller omfatter VPN-begrænsning, overvågning af privilegerede sessioner, leverandørens afhjælpningsplan og månedlig gennemgang af adgangsrettigheder.

Forbered til sidst en mappe kaldet “Revisionsbevis for autentifikation - Q2 2026” med uddrag af politikker, risikovurdering, behandlingsregistrering, SoA-uddrag, IdP-konfiguration, rapport om MFA- og passkey-dækning, liste over privilegerede brugere, undtagelsesregister, logfiler for tilmelding og tilbagekaldelse, testeksempel fra fratrædelsesproces, SIEM-forespørgsler, skærmbilleder af alarmer, uddrag af playbook for hændelseshåndtering og brugerkommunikation om sikkerhedsbevidsthed.

Det er forskellen mellem “vi bruger MFA” og “vi kan dokumentere styring af sikker autentifikation.”

Hvordan forskellige revisorer vil teste de samme identitetskontroller

Et modent identitetsprogram forudser forskellige revisionsperspektiver.

ISO 27001-revisoren starter med ledelsessystemet. Vedkommende vil spørge, hvordan identitetsrisici er vurderet, hvorfor kontroller er valgt, hvordan de fremgår af SoA’en, om politikker er godkendt, om ansvar er tildelt, og om revisionsbevis viser drift over tid. Revisoren vil teste sammenhængen mellem risikoregisteret, politik for adgangsstyring, IdP-indstillinger og logfiler.

Zenith Blueprint, fasen Kontroller i praksis, trin 19, revisionstjekliste for kontroller 8.1 til 8.5, beskriver den praktiske revisionsanmodning:

Revisorer vil spørge ind til indstillinger for adgangskodekompleksitet, og hvordan de håndhæves (Active Directory GPO’er, IdP-politikker osv.). Vis dokumentation for MFA-udrulning, hvem den gælder for, hvor den håndhæves, og hvilke systemer der er beskyttet.

En DORA- eller NIS2-revisor vil fokusere på styring, robusthed og systemisk risiko. Vedkommende kan bede om tilsyn fra bestyrelse eller ledelsesorgan, dækning af kritiske systemer, tredjepartsforpligtelser vedrørende autentifikation, kontinuitetstest og revisionsbevis for, at genopretningsprocedurer kun kan iværksættes af autentificeret personale.

En GDPR-gennemgang vil fokusere på personoplysninger. Den vil undersøge, om autentifikation beskytter personoplysninger mod uautoriseret adgang, om adgangen er begrænset til det nødvendige, om logfiler understøtter vurdering af brud, og om organisationen kan dokumentere ansvarlighed.

En NIST-orienteret vurderingspart kan bruge NIST CSF 2.0 Profiles til at sammenligne nuværende og ønskede tilstande. Vedkommende vil forvente en prioriteret handlingsplan, der dækker governance, politik, adgangsstyring, detektion og responsresultater.

En COBIT 2019- eller ISACA-revisor vil evaluere, om praksis for identitet og autentifikation understøtter governance-mål, kontroldesign, kontroludførelse, funktionsadskillelse, privilegeret adgang og overvågning. Vedkommende er måske ligeglad med, hvilket brand af passkey I bruger. Det afgørende er, om kontrollen styres, måles, ejes og forbedres.

Glem ikke fratrædelse, genopretning og ikke-menneskelige identiteter

Mange autentifikationsprogrammer ser stærke ud ved login og svage alle andre steder.

Fratrædelse er et almindeligt svigtpunkt. Clarysecs Politik for onboarding og fratrædelse omfatter specifikt:

tilbagekaldelse af MFA/SSO-tokens, smartcards eller certifikater

Den klausul skal testes. Vælg tre fratrådte brugere, og dokumentér, at konti, sessioner, MFA-enheder, passkeys, certifikater og genopretningsmetoder blev tilbagekaldt rettidigt. Hvis I ikke kan dokumentere tilbagekaldelse af tokens, er jeres fratrædelseskontrol ufuldstændig.

Genopretning er et andet svagt punkt. Hvis en helpdesk kan nulstille MFA efter svar på to enkle spørgsmål, vil angriberen målrette helpdesk-genopretning i stedet for login. Genopretningsprocedurer skal kræve stærk verifikation, logning i sagssystem, godkendelse for privilegerede brugere, brugerunderretning og overvågning af aktivitet efter genopretning.

Ikke-menneskelige identiteter er det tredje blinde punkt. Zenith Blueprint trin 22 gør det klart, at autentifikationsoplysninger omfatter “adgangskoder, PIN-koder, kryptografiske nøgler, biometriske skabeloner, smartcards, tokens, certifikater, OAuth-tokens, SSH-nøgler, API-hemmeligheder.” Angribere bruger ofte API-tokens, nøgler til servicekonti og OAuth-tildelinger til at opretholde adgang. Behandl disse legitimationsoplysninger under A.5.17 med vault-baseret opbevaring, ejerskab, rotation, tilbagekaldelse og logning.

Sådan ser god praksis ud i 2026

Et modent identitetskontrolmiljø i 2026 har disse kendetegn:

  • Bestyrelsen eller ledelsesorganet forstår identitetsrisikoen og godkender retningen.
  • Adgangskodepolitikken er moderniseret, brugervenlig og teknisk håndhævet.
  • Adgang alene med adgangskode er fjernet for privilegerede, eksterne og interneteksponerede systemer.
  • Passkeys eller FIDO2-autentifikatorer prioriteres for højrisikoadgang.
  • MFA-undtagelser er dokumenterede, godkendte, tidsbegrænsede og kompenserede.
  • Tilmelding, genopretning og tilbagekaldelse af autentifikatorer er kontrolleret.
  • Fratrædelse omfatter tilbagekaldelse af konti, tokens, certifikater, sessioner og passkeys.
  • Autentifikationslogfiler omfatter succeser, fejl, MFA-brug, sessionsvarighed og autentifikatorændringer.
  • SIEM-anvendelsesscenarier detekterer credential stuffing, geografisk umulige login, mistænkelig tilmelding og MFA-træthed.
  • SoA’en forklarer, hvorfor A.5.16, A.5.17 og A.8.5 er anvendelige.
  • NIS2-, DORA-, GDPR- og NIST CSF-kortlægninger registreres én gang og genbruges.
  • Revisionsbevis indsamles løbende og samles ikke i panik før revisionen.

Sådan bliver NIST SP 800-63-4 mere end et referencedokument. Den bliver et levende kontrolsystem, der understøtter sikkerhed, privatliv, robusthed og revisionsberedskab.

Omsæt identitetskontroller til revisionsklart revisionsbevis

Hvis jeres organisation opdaterer adgangskoderegler, udruller phishing-resistent MFA, indfører passkeys eller forbereder sig på revisionsspørgsmål om ISO 27001, NIS2, DORA eller GDPR, skal I ikke begynde med værktøjskonfiguration alene.

Begynd med modellen for revisionsbevis.

Clarysec kan hjælpe jer med at:

  • Kortlægge forventningerne i NIST SP 800-63-4 til adgangskoder, MFA og passkeys til ISO/IEC 27001:2022.
  • Opbygge en politik for autentifikatorers livscyklus og en pakke med revisionsbevis.
  • Opdatere politikker for adgangsstyring, MFA, logning, onboarding og fratrædelse.
  • Forberede en anvendelighedserklæring, der kobler identitetsrisiko til kontroller.
  • Bruge Zenith Blueprint til at strukturere implementeringstrin og revisionsberedskab.
  • Bruge Zenith Controls til at krydskortlægge identitetskontroller på tværs af NIS2, DORA, GDPR, NIST CSF 2.0 og COBIT 2019.

Det bedste tidspunkt at opdage svag genopretning, manglende tilbagekaldelse af passkeys eller ufuldstændig MFA-håndhævelse er før hændelsen, før tilsynsmyndigheden og før revisoren spørger.

Gør jeres næste gennemgang af adgangsrettigheder til en gennemgang af revisionsbevis efter NIST SP 800-63-4. Download de relevante Clarysec-politikker, udforsk Zenith Blueprint, og brug Zenith Controls til at omsætte implementeringen af adgangskoder, MFA og passkeys til ét praktisk, forholdsmæssigt og revisionsklart grundlag for compliance.

Frequently Asked Questions

About the Author

Igor Petreski

Igor Petreski

Compliance Systems Architect, Clarysec LLC

Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council

Share this article

Related Articles