Entra ID, MFA og Conditional Access

Start med licenser, eksisterende beskyttelse og nødadgang

Et brugbart grundlag for adgangssikkerhed i Microsoft 365 er MFA, særskilte administratorkonti, kontrol med ældre login og en afprøvet vej tilbage, hvis en ændring spærrer de forkerte brugere. Conditional Access kræver Entra ID P1; politikker baseret på bruger- eller loginrisiko kræver P2. Security Defaults er et alternativ til organisationer uden disse licenser, men giver ikke samme mulighed for egne regler.

Før I ændrer noget, skal I vide, hvilken beskyttelse der allerede er aktiv, hvem der rammes, og hvem der kan gendanne adgangen. ALCO hjælper med MFA og adgangsstyring i Microsoft 365. Guiden her er en beslutnings- og testplan, ikke et færdigt sæt politikker til enhver virksomhed.

Hvad kan I med Security Defaults, P1 og P2?

Produktkravene er kontrolleret mod Microsofts dokumentation den 19. oktober 2026.

Valg	Hvad det giver	Hvad I skal afklare
Security Defaults med Entra ID Free	Foruddefineret beskyttelse, blandt andet MFA-registrering, MFA-krav og blokering af ældre godkendelse	Om standardreglerne passer til brugere, klienter og systemer; egne undtagelser kræver en anden model
Conditional Access med Entra ID P1	Egne adgangspolitikker, eksempelvis krav om MFA eller bestemte enhedsforhold	Licenser til de omfattede brugere, målgrupper, apps, undtagelser og test
Risikobaseret Conditional Access med Entra ID P2	Bruger- og loginrisiko fra Identity Protection som grundlag for politikker	Hvordan signalerne bruges, og hvem der følger op på hændelser
Krav om compliant enhed	Adgang kan afhænge af enhedens rapporterede overholdelse	Enhedsstyring og compliance-politikker skal være etableret; Intune og øvrige produkter har egne licenskrav

Business Premium indeholder Entra ID P1, men giver ikke i sig selv P2's risikobaserede politikker. Køb heller ikke én administratorlicens ud fra en antagelse om, at den dækker alle brugere. Kontrollér rettighederne for den konkrete udrulning i Microsofts Conditional Access-oversigt og sammenhold dem med indholdet i jeres Microsoft 365-abonnement.

Security Defaults er en samlet standardbeskyttelse, ikke en politikeditor. At MFA-registrering er gennemført, betyder heller ikke, at brugeren nødvendigvis bliver spurgt ved hvert login. Kontrollér den aktive model frem for kun at tælle registrerede telefoner.

Lav en oversigt over medarbejdere, gæster, administrative konti og systemer, som logger ind eller sender mail. Notér klient, formål, ejer og afhængigheder. Adskil administration fra daglig mail og surfing, og tildel kun de roller, opgaven kræver. Det gør også afløser- og fratrædelsesprocessen mere overskuelig.

Ved ældre godkendelse bør I undersøge faktiske loginforsøg, også de ikke-interaktive. Et mailprogram, en scanner og et økonomisystem kan bruge forskellige metoder, selv om alle sender mail. Se Microsofts vejledning til at finde og blokere legacy authentication. En nødvendig integration skal have en plan for en understøttet metode; en udokumenteret permanent undtagelse løser ikke afhængigheden.

2. Vælg MFA-metode og planlæg registreringen

“App-baseret” og “phishing-resistent” betyder ikke det samme. En almindelig godkendelsesbesked kan ikke sidestilles med en FIDO2-passkey eller sikkerhedsnøgle. For privilegerede konti anbefaler Microsoft phishing-resistent MFA. Metoderne skal være registreret og testet, før en politik kræver dem. Se Microsofts vejledning til phishing-resistent MFA for administratorer.

Aftal, hvordan brugeren får sin første adgang, hvem der hjælper ved mistet telefon eller nøgle, og hvordan support kontrollerer identiteten, før adgang gendannes. En registreringsplan skal omfatte ansatte uden firmatelefon og dem, der ikke er på kontoret under udrulningen.

3. Afprøv nødadgangen før nye blokeringer

Microsoft anbefaler mindst to cloud-only nødkonti på tenantens onmicrosoft.com-domæne, uafhængigt af lokal synkronisering og federation. Beskyt dem med phishing-resistent godkendelse, som ikke deler alle afhængigheder med den normale administratoradgang. Nødadgang betyder ikke adgang uden MFA.

Nødkontiene skal undtages fra Conditional Access-politikker, der kan blokere eller begrænse login. Det er en kontrolleret beredskabsløsning: opbevar adgangsmidler sikkert, afgræns hvem der må bruge dem, overvåg brugen og test adgangen mindst hver 90. dag samt efter væsentlige ændringer. Følg Microsofts aktuelle nødadgangsvejledning.

4. Test nye politikker uden at fjerne den eksisterende beskyttelse

Hvis I allerede bruger Conditional Access, kan nye eller ændrede regler vurderes i report-only, mens de eksisterende aktive regler fortsætter. Report-only registrerer, hvad en politik ville gøre; den håndhæver ikke dens adgangskrav. Skift derfor ikke en virksom beskyttelsespolitik til report-only for at lave en test. Brug en separat testversion og gennemgå resultatet i sign-in-loggen. Politikker med enhedskrav kan stadig udløse certifikatprompter på visse platforme; se muligheder og begrænsninger i report-only.

Ved skift fra Security Defaults kræves en særskilt overgangsplan: de to beskyttelsesmodeller skal ikke kombineres. Forbered de politikker, der skal overtage beskyttelsen, brugerregistrering, nødadgang og ansvar for selve skiftet. Slå ikke Security Defaults fra og efterlad resten af virksomheden med kun en report-only-pilot. Brug Microsofts plan for Conditional Access til at planlægge overgangen og testomfanget.

En konkret testmatrix

Denne matrix er et eksempel på, hvad I kan kontrollere — ikke en beskrivelse af en ALCO-kundeløsning. Tilpas den til de apps og brugere, politikken faktisk omfatter.

Situation	Hvad skal være afklaret før bred aktivering?
Almindelig medarbejder på computer og mobil	Den tiltænkte MFA-metode virker, og nødvendige arbejdsapps kan åbnes
Enhed, der ikke opfylder et nyt compliance-krav	Den forventede begrænsning og supportvej er forstået; eksisterende enheder er undersøgt
Administrator og nødkonto	De normale admin-krav virker, og nødadgangen er testet særskilt
Gæst, rejse eller ekstern arbejdsplads	De relevante scenarier er dækket uden brede, uforklarede undtagelser
Systemafsender eller ældre klient	Ejer og erstatningsmetode er kendt; eventuelle afvigelser har ansvarlig og udløbsdato

What If-værktøjet hjælper med at se, hvilke politikker der matcher valgte forhold. Det erstatter ikke en virkelig test af arbejdsforløbet og medtager ikke alle afhængigheder mellem tjenester. Notér både forventet resultat og det faktiske login/logresultat.

5. Aktivér i afgrænsede trin, og aftal tilbageførsel

Aftal på forhånd, hvem der godkender næste trin, hvilke fejl der stopper udrulningen, og hvordan den seneste ændring kan tilbageføres uden at fjerne al beskyttelse. Informér de berørte brugere om tidspunkt, registrering og supportvej. Flere politikker virker sammen, så en vellykket enkeltregel er ikke bevis for, at alle kombinationer er gennemgået.

En nyttig afslutning er en kort driftsoversigt: aktive politikker, formål, omfattede brugere/apps, undtagelser, testdato, ansvarlig og næste review. Gennemgå den igen ved nye apps, ændrede roller, nye enhedstyper eller ændrede licenser. Aftal også, hvem der læser loginfejl og sikkerhedshændelser; automatiske signaler er ikke det samme som bemandet respons.

Hvad koster opsætningen?

Regn både licenser, registrering, implementering, brugerhjælp og efterfølgende opfølgning med. Behov for P2, Intune eller ekstra logopsamling afhænger af de valgte funktioner. Et tilbud bør skelne mellem produktlicenser og arbejdet med at få kontrollerne til at fungere; et universelt minimum kan ikke prissættes ud fra appnavnene alene.

Medbring fulde licensnavne, aktive politikker, klienter og integrationsafhængigheder til en gennemgang af MFA og adgangsstyring. Enhedernes rolle kan afklares under Intune og enhedsstyring; en bredere vurdering af virksomhedens risici hører under IT-sikkerhed.