Sådan får du styr på Security Defaults vs. Conditional Access, hvornår du skal vælge hvad, og hvordan du skifter uden kaos
Mange SMV’er kører i dag på Microsoft 365, men sikkerheden halter ofte bagefter. Ikke fordi der mangler vilje, men fordi hverdagen er fuld af drift, brugersager og it-support. Sikkerhed ender som noget, man “lige gør senere”. Problemet er, at angreb ikke venter.
I Microsoft Entra ID (tidligere Azure AD) står valget tit mellem Security Defaults og Conditional Access. Begge dele handler om login-sikkerhed, men de passer til forskellige behov. Skiftet fra det ene til det andet kan også føles som at skifte låsesystem midt i åbningstiden.
Denne guide giver et nøgternt overblik, hvornår man vælger hvad, og hvordan man skifter uden at låse folk ude.
Først: forstå hvad Security Defaults gør (og ikke gør)
Illustration af forskellen mellem standard-sikkerhed og regelbaserede politikker, skabt med AI.
Security Defaults er Microsofts “standard-lås” til små miljøer. Den er lavet til at give en rimelig baseline uden designmøder og uden at man skal være Entra-specialist. Når den er slået til, tvinger den typisk:
MFA (Multi-Factor Authentication) for brugere og især administratorer.
Blokering af legacy authentication (gamle login-protokoller uden moderne sikkerhed).
Ekstra beskyttelse omkring admin-aktiviteter.
Det vigtige er begrænsningen: der er næsten ingen finjustering . Det er en pakke. På eller af. Har man en gammel mail-klient, en printer der sender via SMTP, eller en app med et service-login, kan defaults hurtigt give driftsproblemer, og man kan ikke “lige undtage den ene ting”.
Når man taler om Security Defaults Conditional Access som valg, er det ofte netop her forskellen står. Defaults er god til at komme hurtigt i gang. Conditional Access er til at drive et miljø med flere undtagelser og krav.
Microsofts egen gennemgang af, hvad defaults indeholder, ligger i deres dokumentation om konfiguration af Security Defaults.
Conditional Access: regler i stedet for standard
Conditional Access (CA) er “hvis-så” politikker. Hvis en bruger logger ind fra et ukendt land, så kræv MFA. Hvis en enhed ikke er compliant (opdateret, krypteret, med PIN), så blokér. Hvis en app bruger legacy auth, så stop den ved døren.
Til gengæld kræver CA licens. Typisk Microsoft Entra ID P1 (og P2 hvis man vil arbejde mere med risiko og identitetsbeskyttelse). Mange SMV’er har det allerede via fx Microsoft 365 Business Premium, men det skal tjekkes, før man planlægger skift.
En praktisk hjælp til SMV’er er Microsoft-managed policies, altså politikker Microsoft selv vedligeholder og ruller ud som anbefalet baseline. Det kan give en mere kontrolleret erstatning for defaults. Se oversigten over Microsoft-managed Conditional Access policies og Microsofts baggrund i deres deep dive om managed policies.
En kort sammenligning:
| Punkt | Security Defaults | Conditional Access |
|---|---|---|
| Tilpasning | Meget lav | Høj |
| Licens | Gratis | Kræver typisk P1/P2 |
| Drift | Nemt at holde | Kræver ejerskab og løbende tjek |
| Bedst når | Basal sikkerhed er nok | Der er undtagelser, compliance, mange enheder |
Valg for SMV i århus og lystrup: tre typiske scenarier
SMV-scenarie med adgangspolitikker, MFA og phishing-beskyttelse, skabt med AI.
I praksis handler valget mindre om “hvad er bedst”, og mere om “hvad kan vi styre uden friktion”. Mange mindre virksomheder i Århus-området ender med en løsning, der passer til drift og bemanding, ikke teori. Her er tre mønstre, der går igen i århus og lystrup.
1) Den lille organisation uden IT-team
Security Defaults giver mening, hvis man primært skal stoppe de klassiske angreb (phishing, password spray) og vil have en enkel baseline. Her er fokus ofte stabil drift og hurtig it-support, ikke policy-design.
2) Virksomheden med blandede behov
Når der kommer gæstebrugere, flere lokationer, hjemmearbejde, eller krav om at bestemte apps kun må bruges på firmatelefoner, bliver defaults for grov. Conditional Access giver de nødvendige undtagelser. Det er typisk her, at rådgivning betaler sig, fordi én forkert policy kan ramme hele organisationen.
3) Virksomheden med compliance eller høj risiko
Hvis der er krav om device compliance, streng kontrol med admin-adgang, eller et ønske om mere struktureret Zero Trust, peger pilen klart mod Conditional Access. Det kræver også løbende vedligehold. Ellers bliver politikkerne hurtigt forældede.
For mange SMV’er er det afgørende at få en plan, der også tager højde for hverdagen: onboarding, offboarding, supportvinduer og hvem der har nøglen, når noget går galt.
Skift uden kaos: en rolig migrering fra defaults til politikker
Trinvis migrering med pilot og overvågning, skabt med AI.
Den vigtigste regel: Security Defaults og Conditional Access kan ikke køre som “to lag”. Man planlægger derfor CA først, og slukker defaults, når man er klar til at overtage med politikker.
En sikker migrering kan holdes enkel, hvis man gør den i et fast forløb:
- Discovery (kortlægning)
Find hvad der logger ind i dag: brugere, admin-konti, gæster, og især legacy auth. Kig også efter “skjulte” flows som scannere, regnskabssystemer og integrationer. - Sørg for MFA-registrering før skiftet
Hvis folk ikke er registreret til MFA, kommer support-trykket med det samme. Planlæg en kort kampagne og få det lukket. - Lav mindst to “break-glass”-konti
Break-glass betyder nødadgang. Lange passwords, stærk beskyttelse, og kontrolleret opbevaring. De bruges kun ved fejl i politikker. - Start med baseline-politikker
Begin med det, defaults allerede gjorde: kræv MFA, blokér legacy auth, beskyt admin-adgang. Hold resten ude i første bølge. - Pilot og gradvis udrulning
Test på en lille gruppe. Udvid i intervaller. Brug logfiler til at se, hvad der rammes. Ret til, før næste gruppe får det. - Overvågning og rollback-plan
Aftal, hvem der kan slå en policy fra, og hvornår. Det er drift, ikke teori. Her giver en fast partner til it-support ro, især hvis man har deadlines og kundemøder i kalenderen.
Vil man have et ekstra perspektiv på faldgruber og valg, kan man også læse AdminDroids sammenligning af Security Defaults vs Conditional Access policies.
For SMV’er i lokalområdet er det ofte her, NetDK bliver relevant: plan, opsætning, test og efterfølgende drift. Ikke store slides, men styr på adgangen, så folk kan arbejde.
Konklusion
Security Defaults er et fornuftigt startpunkt, når målet er hurtig baseline-sikkerhed i Microsoft 365. Conditional Access er næste skridt, når virksomheden får flere krav, flere undtagelser og flere enheder. Skiftet skal tages som et driftprojekt, med pilot og tydelig fallback, ellers rammer det brugerne først.
En god tommelfingerregel er enkel: vælg det mindst komplekse , der stadig dækker jeres reelle behov. Og få en plan, der passer til hverdagen i århus og lystrup, ikke kun til en “best practice”-liste.




