Sådan sætter du Passwordless login op i Entra ID med FIDO2-nøgler, krav, rollout-plan og typiske faldgruber
Passwords er som nøgler, der bliver kopieret igen og igen, til sidst passer de til for mange låse. Det er stadig en af de mest brugte indgange til phishing og konto-overtagelser.
Med passwordless login Entra ID og FIDO2-nøgler flytter man “hemmeligheden” over i en fysisk nøgle og en lokal PIN. Det giver en login-form, der er svær at stjæle på afstand og nem at bruge i hverdagen.
Guiden her er skrevet til danske SMV’er, der vil rulle det ud kontrolleret, uden at vælte drift, Microsoft 365-adgang eller eksisterende it-sikkerhed.
Krav og standardvalg, før man rører ved policies
Det vigtigste designvalg er simpelt: FIDO2 skal være en phishing-resistent metode, ikke bare “endnu en MFA”. Derfor bør man planlægge krav, målgrupper og fallback fra start. Microsofts overblik over forudsætninger er et godt udgangspunkt, især hvis man vil gøre det i faser: forudsætninger for phishing-resistent passwordless.
Minimumskrav (praktisk liste)
| Område | Standardvalg (anbefalet) | Alternativ / bemærkning |
|---|---|---|
| Enheder | Windows 10/11, Entra-joined eller hybrid-joined | Mac fungerer til web-login, men Windows-login kræver korrekt setup |
| Nøgler | FIDO2 certificerede nøgler med PIN | NFC er fint til mobil, USB-C giver færre dongles |
| Sikkerhed | Kræv attestation og tillad kun kendte modeller | Man kan starte uden attestation i pilot, men det øger risiko |
| Identitet | MFA er allerede rullet ud | Hvis MFA ikke er stabilt, stop og fix det først |
Kompatibilitet er typisk det, der bider SMV’er først. En “tilfældig” billig nøgle kan virke på én PC og fejle på en anden. Brug Microsofts liste som reference: FIDO2-kompatibilitet i Entra ID.
Fallback og nødkonti skal være besluttet nu
- Break-glass-konti : 1-2 konti med stærkt password, ekskluderet fra Conditional Access, overvåget, og kun brugt i nød.
- Onboarding uden password : planlæg Temporary Access Pass (TAP) eller en kontrolleret midlertidig metode, så nye brugere ikke ender i “password først”.
- Reserve-nøgle : beslut om alle brugere skal have to nøgler (primær + backup). For SMV’er er det ofte den billigste måde at undgå support-kaos.
Opsætning i Entra ID: FIDO2, registrering og Conditional Access
Illustration af autentificeringsflow med FIDO2-nøgle, Entra ID og betinget adgang, lavet med AI.
Start med en afgrænset gruppe og lad resten af organisationen være urørt. Det gør fejlfinding mulig, og man undgår at “låse alle ude” på én dag. Don’t slå krav til hele tenant til fra starten.
Trin 1: Aktivér FIDO2 (passkeys) i Authentication methods
- Gå i Entra admin center til Authentication methods og aktivér FIDO2 for en pilotgruppe.
- Slå self-service registration til, så brugere kan registrere uden IT-håndhold.
- Slå attestation til, når I har valgt godkendte nøglemodeller (det forhindrer “ukendte” nøgler).
Microsofts trin-for-trin er her: aktivér passkeys (FIDO2) i Entra ID.
Trin 2: Registreringsflow, som faktisk virker i praksis
Standardflowet er: bruger logger ind, bekræfter med eksisterende MFA, registrerer FIDO2-nøgle, sætter nøgle-PIN. Gør det nemt:
- Planlæg 10 minutter pr. bruger i pilot (inklusive “hvor sidder USB-C porten?”).
- Kræv registrering af to nøgler for nøglepersoner (IT, økonomi, ledelse).
Til Windows-login er det vigtigt at teste tidligt, især på hybrid-joined enheder: FIDO2 security key sign-in to Windows.
Trin 3: Eksempel-politikker for Conditional Access (sikker overgang)
Målet er en overgang, hvor passwords gradvist bliver mindre brugt, uden at stoppe drift.
| Politikkens formål | Tillad / kræv | Blokér | Udrulning |
|---|---|---|---|
| Admin-beskyttelse | Kræv phishing-resistent (FIDO2) til admin-roller | Ingen undtagelser, ud over break-glass | Start i Report-only, skift til On efter pilot |
| Microsoft 365 adgang | Kræv phishing-resistent for udvalgte apps (Exchange, SharePoint, Teams) | Blokér legacy authentication | Begrænset rollout afdeling for afdeling |
| Registrering og recovery | Tillad registrering fra compliant device eller “trusted location” | Blokér registrering fra ukendte net | On før bred rollout |
Tip: Kør først i Report-only og læs sign-in logs dagligt. Hvis en gammel app stadig bruger legacy auth, så bliver den afsløret her, før brugerne ringer.
Rollout-plan (4 til 6 uger), tjeklister og drift efter go-live
Oversigt over en trinvis rollout med pilot, udvidelse og stabil drift, lavet med AI.
En god rollout er kedelig på den gode måde. Den har klare kriterier og færre overraskelser. For en typisk SMV i århus eller lystrup giver en 4-6 ugers plan et realistisk tempo.
Tidslinje med pilotkriterier og succeskriterier
| Fase | Varighed | Pilotkriterier | Succeskriterier |
|---|---|---|---|
| Pilot | Uge 1-2 | 5-10 brugere, blandet roller, mindst 2 enhedstyper | 95% succesfulde logins, 0 kritiske lockouts |
| Begrænset rollout | Uge 3 | IT + 1 forretningsenhed | Supporttickets under aftalt niveau |
| Fuldt rollout | Uge 4-5 | Resten af brugere | Password-brug falder markant i logs |
| Stabilisering | Uge 6 | Driftsoverdragelse | Runbook på plads, reserve-nøgler registreret |
Kommunikationsplan (kort og effektiv):
- Mail 1: hvad ændrer sig, og hvorfor (it-sikkerhed, phishing).
- Mail 2: “sådan gør du” med 3 trin og forventet tidsforbrug.
- Onsite eller remote “registreringsvindue” med it-support på linjen. NetDK kører ofte faste tidsrum, så registrering ikke bliver ad hoc.
Tjeklister (kort, men komplette)
Før start
- Break-glass konti testet.
- Indkøb, lager og udleveringsproces for nøgler.
- Klar politik for mistet nøgle og ny udstedelse.
- Afklar sammenhæng med firewall, antivirus og backup (passwordless stopper phishing, men ikke ransomware).
Under pilot
- Kør CA i Report-only og gennemgå sign-in logs dagligt.
- Verificér Windows-login på mindst 2 PC-modeller.
- Test nøgle på mobil (NFC) hvis brugerne har behov.
Før go-live
- CA-politikker skiftes til On for næste gruppe.
- Support-runbook: “glemt PIN”, “ny PC”, “mistet nøgle”.
- Onboarding-flow med TAP eller kontrolleret alternativ er godkendt.
Drift
- Kræv reserve-nøgle for udvalgte roller.
- Offboarding: fjern registrerede nøgler, og revokér sessions.
- Rapportér månedligt på adoption og mislykkede logins.
Typiske faldgruber og konkrete løsninger
Visualisering af de mest almindelige fejlområder og en “løsning først” tilgang, lavet med AI.
- MFA og CA-konflikter : En gammel MFA-policy kan kollidere med “authentication strength”. Løsning: konsolidér policies, og hold én “sandhed” for krav pr. app/rolle.
- Enhedskrav : Pilot lykkes på IT’s nyere laptops, men fejler i produktionen. Løsning: test mindst én “ældste understøttede” device tidligt.
- Attestation og nøglemodeller : Attestation slår ukendte nøgler fra, hvilket er meningen, men det kan overraske. Løsning: vælg 1-2 godkendte modeller og kommuniker det.
- Registreringsflow : Brugere kan ikke registrere hjemmefra, fordi I kræver trusted location. Løsning: lav et tidsbegrænset registreringsvindue eller en midlertidig undtagelse for pilot.
- Mistet nøgle : It’s ikke et spørgsmål om hvis, men hvornår. Løsning: spær nøglen i Entra, udsted ny, og kræv reserve-nøgle for nøglepersoner.
- Shared accounts : FIDO2 er personligt. Løsning: stop delte konti, brug separate identiteter eller godkendte servicekonti med kontrolleret adgang.
Konklusion
FIDO2 i Entra ID giver en stærk og brugbar vej til passwordless login Entra ID , men kun hvis krav, Conditional Access og drift spiller sammen. Start med en stram pilot, mål alt i logs, og lav en plan for mistede nøgler og break-glass fra dag 1. Når det er på plads, bliver passwordless et stabilt fundament under Microsoft 365 og jeres samlede it-løsninger.
