Conditional Access forklaret: fra loginregel til Zero Trust-policy engine

Conditional Access bliver ofte forklaret som funktionen, der kræver MFA, når en bruger logger ind. Det er en korrekt anvendelse, men en for snæver forståelse. Microsoft Entra Conditional Access er i praksis Microsofts policy engine for adgang: et kontrolpunkt, der samler signaler om identitet, ressource, enhed, netværk, autentificeringsflow og risiko og omsætter dem til en konkret beslutning om, hvilke krav der skal opfyldes for at få adgang.

Det gør Conditional Access til en af de mest sikkerhedskritiske komponenter i en moderne Microsoft 365-arkitektur. En fejlkonfigureret politik kan blokere hele organisationen. En for svag politik kan efterlade følsomme ressourcer tilgængelige fra kompromitterede eller uadministrerede enheder. En politik, der kun eksisterer for at "slå MFA til", udnytter kun en lille del af styringsmodellen.

Denne artikel er skrevet som et whitepaper om Conditional Access som adgangsarkitektur. Fokus er ikke på at gennemgå hvert felt i Microsoft Entra admin center. Fokus er på, hvordan signaler, assignments, conditions, grant controls og session controls hænger sammen, hvordan politikker evalueres, hvordan de udrulles uden lockout, og hvordan virksomheden bygger en dokumenterbar adgangsmodel, der kan udvikles i takt med risiko og modenhed.

Ledelsesresumé

Microsoft Entra Conditional Access er Microsofts Zero Trust-policy engine. Funktionen kombinerer signaler om identitet, målressource, enhed, netværk, klient, autentificeringsflow og i visse licensniveauer risiko. Når et adgangsforsøg matcher en politik, kan Conditional Access blandt andet blokere adgang, kræve multifaktorautentificering, kræve en bestemt authentication strength, kræve en compliant eller hybrid joined enhed, kræve app protection eller styre sessionen efter login.

Den vigtigste ledelsesmæssige pointe er, at Conditional Access ikke bør behandles som en samling enkeltstående sikkerhedsregler. Det er en arkitektur for adgang. Organisationen bør kunne forklare, hvilke identiteter der beskyttes, hvilke ressourcer der er omfattet, hvilke signaler der påvirker beslutningen, hvilke undtagelser der findes, og hvordan en fejlkonfiguration kan tilbageføres uden at låse administratorerne ude.

Conditional Access håndhæves som udgangspunkt efter første faktor i autentificeringen. Det betyder, at tjenesten ikke er en firewall foran Microsoft Entra ID og ikke bør betragtes som beskyttelse mod eksempelvis denial-of-service. Dens styrke ligger i at evaluere konteksten omkring en identificeret login- eller tokenanmodning og stille de korrekte krav, før ressourcen gives adgang.

En robust basisarkitektur omfatter normalt MFA for alle relevante brugere og ressourcer, stærkere authentication strengths for administratorer og særligt følsomme ressourcer, device- eller appkontrol hvor data kræver det, blokering eller kontrol af uønskede authentication flows og en eksplicit strategi for eksterne brugere. Risiko-baserede politikker kan supplere modellen, men kræver højere Entra-licensniveau end almindelig Conditional Access.

Den største operationelle risiko er administrativ lockout. Microsoft anbefaler derfor særskilte emergency access-konti, som er uafhængige af den normale administrative adgangsmodel og ekskluderes fra Conditional Access-politikker, der kan blokere eller begrænse login. Nye politikker bør desuden udrulles i report-only, analyseres i sign-in logs, testes med pilotgrupper og først derefter håndhæves bredt.

Conditional Access som adgangskontrolplan

I et traditionelt netværk var adgang ofte koblet til placering. En bruger på virksomhedens LAN blev i praksis behandlet anderledes end en bruger på internettet. I et cloudmiljø er det ikke længere en tilstrækkelig model. En bruger kan åbne Exchange Online fra en privat computer hjemmefra, Teams fra en telefon på mobilnettet og SharePoint fra en browser på en kundes gæstenetværk. Ressourcerne ligger heller ikke nødvendigvis på virksomhedens netværk.

Conditional Access flytter kontrollen fra netværksperimeteren til identitetslaget. Når en identitet forsøger at få adgang til en Entra-beskyttet ressource, kan policy engine vurdere den tilgængelige kontekst og beslutte, om der skal stilles yderligere krav.

Det er vigtigt at forstå, at Conditional Access ikke alene bestemmer, om brugeren har autorisation til ressourcen. SharePoint-rettigheder, app roles, Entra-roller og andre autorisationsmekanismer gælder stadig. Conditional Access lægger et ekstra policy-lag oven på autentificering og autorisation: selv en bruger med korrekt rettighed kan blive afvist, hvis adgangsbetingelserne ikke er opfyldt.

Dermed bliver Conditional Access en del af virksomhedens Zero Trust-model. Tillid er ikke permanent. Adgang vurderes ud fra konkrete signaler og kan kræve stærkere bevis, en styret enhed eller en anden sessionstype afhængigt af ressourcen og risikoen.

Hvordan en Conditional Access-beslutning opstår

En politik kan læses som en kontrolleret if-then-sætning. Hvis en identitet og en målressource er i scope, og de valgte conditions matcher, skal de valgte access controls håndhæves.

Flere politikker kan ramme samme login. De erstatter ikke nødvendigvis hinanden. Deres krav kan akkumulere. Hvis én politik kræver MFA og en anden kræver compliant device, kan brugeren i praksis skulle opfylde begge. Hvis én relevant politik blokerer adgang, kan en anden politik ikke "tillade sig udenom" blokeringen.

Det er derfor farligt at designe Conditional Access som isolerede regler uden at analysere den samlede effekt. En politik kan se fornuftig ud alene, men skabe et uventet resultat sammen med eksisterende policies.

Conditional Access bør vurderes som et samlet policiesæt. Fejlfinding skal derfor se på alle politikker, der blev evalueret for det konkrete sign-in, ikke kun den politik administratoren forventede ville gælde.

Assignments: hvem og hvilke ressourcer politikken gælder for

En Conditional Access-politik begynder med scope. Før man diskuterer MFA, device compliance eller session controls, skal man definere, hvilke identiteter og hvilke target resources politikken gælder for.

Brugersiden kan omfatte alle brugere, specifikke brugere og grupper, guest/external user-typer eller directory roles. Separate muligheder findes for workload identities i de scenarier, hvor organisationen har den nødvendige licensering.

Target resources er Microsofts nuværende samlebetegnelse for det, der tidligere ofte blev kaldt cloud apps. En politik kan rette sig mod alle ressourcer, udvalgte applikationer og tjenester samt særlige scenarier som user actions eller authentication context.

Microsoft anbefaler som generelt baselineprincip en politik, der dækker alle brugere og alle ressourcer og kræver MFA, med nødvendige undtagelser såsom emergency access-konti. Det reducerer risikoen for, at nye apps opstår uden grundlæggende beskyttelse.

App-exclusions bør bruges sparsomt. Når en organisation ekskluderer en app fra en global baseline, skaber den et eksplicit hul i kontrollen. Det kan være legitimt, men bør have en ejer, teknisk begrundelse og reviewdato.

Conditions: signalerne der beskriver konteksten

Conditions afgør, hvornår en policy i scope faktisk skal gælde. Tilgængelige conditions afhænger af måltypen og licenseringen, men kan blandt andet omfatte network/location, device platform, client apps, device filters, sign-in risk, user risk og authentication flows.

Signalet skal forstås med sine begrænsninger. Device platform kan for eksempel afhænge af user agent-information og bør ikke alene bruges som stærkt bevis for enhedens sikkerhed. Named locations viser netværkskontekst, men en "trusted" IP-adresse gør ikke automatisk bruger eller device troværdig.

En god policy bruger derfor signaler efter deres sikkerhedsværdi. En compliant device-status fra Intune har en anden betydning end en IP-adresse fra hovedkontoret. Authentication strength har en anden betydning end blot at vide, at en tidligere MFA-session eksisterer.

Grant controls: hvad brugeren skal opfylde

Når en politik matcher, kan grant controls bestemme, om adgang skal blokeres eller gives under bestemte krav. Centrale grant controls omfatter MFA/authentication strength, compliant device, Microsoft Entra hybrid joined device, app protection policy og password change i relevante risikoscenarier.

Flere grant controls kan kombineres. Administratoren kan vælge, om alle valgte krav skal opfyldes, eller om ét af dem er tilstrækkeligt. Det gør policy design fleksibelt, men også potentielt komplekst.

En central designfejl er at bruge "Block" som standardreaktion på alt usikkert. En Zero Trust-model handler ikke om maksimal blokering; den handler om eksplicit verifikation. Hvis risikoen kan reduceres med stærkere autentificering eller en styret enhed, kan det være mere robust og brugbart end en geografisk blokregel.

Authentication strengths: MFA er ikke én sikkerhedsstyrke

MFA bliver ofte behandlet som en binær egenskab: enten har brugeren MFA eller ej. I praksis har autentificeringsmetoder forskellige egenskaber. SMS, push-baseret MFA, Windows Hello for Business, certificate-based authentication og FIDO2/passkeys giver ikke nødvendigvis samme modstandsdygtighed mod phishing og tokenangreb.

Authentication strengths gør det muligt at specificere, hvilke kombinationer af metoder der må opfylde kravet i en Conditional Access-politik. Microsoft stiller blandt andet indbyggede strengths til rådighed for almindelig multifaktor, passwordless MFA og phishing-resistant MFA. Organisationen kan også definere custom authentication strengths.

Det gør step-up authentication muligt. En almindelig medarbejder kan eksempelvis bruge organisationens normale MFA-model til Microsoft 365, mens administratoradgang eller et særligt følsomt system kræver phishing-resistent autentificering.

For administratorer er dette typisk mere robust end blot at oprette endnu en "Require MFA"-politik. Målet er ikke flere prompts, men stærkere bevis for identiteten der, hvor konsekvensen af kompromittering er størst.

Device compliance og Microsoft Intune

Microsoft Intune kan vurdere, om en enhed lever op til virksomhedens compliance policies. Conditional Access kan bruge denne status som adgangskrav.

Det er afgørende at skelne mellem Intune compliance og Conditional Access. Intune vurderer enheden. Conditional Access håndhæver konsekvensen ved adgang. En enhed kan derfor godt være markeret noncompliant uden automatisk at være blokeret fra Microsoft 365, hvis organisationen ikke har en Conditional Access-politik, der kræver compliance for den relevante ressource.

Denne kobling gør device posture til en del af identitetssikkerheden. Men den skal udrulles forsigtigt. Hvis virksomheden kræver compliant device, før enhederne er korrekt enrolled, eller før der findes en remediation-proces, kan legitime brugere blive låst ude uden en klar vej tilbage.

App protection og BYOD

På private mobile enheder er fuld device management ikke altid ønskelig. Her kan Intune app protection policies beskytte arbejdsdata i understøttede apps, mens Conditional Access kræver, at appen er omfattet af denne beskyttelse.

Det gør det muligt at bygge en BYOD-model, hvor virksomheden ikke nødvendigvis administrerer hele telefonen, men stadig kan begrænse dataflow mellem arbejds- og privatkontekst, kræve app-PIN og fjerne virksomhedens data ved offboarding.

Den tidligere Conditional Access-control Require approved client app blev pr. 30. juni 2026 flyttet til read-only. Nye designs bør baseres på Require app protection policy i de understøttede scenarier frem for at bygge videre på den udfasede approved-client-app-model.

App protection er ikke universelt understøttet på alle apps og platforme. Policy design skal derfor starte med den konkrete app- og device-portefølje. En regel der kræver app protection på en klient, som ikke kan opfylde kontrollen, er i praksis en blokregel.

Risk-based Conditional Access

Microsoft Entra ID Protection kan levere user risk og sign-in risk til Conditional Access. Sign-in risk handler om sandsynligheden for, at et konkret autentificeringsforsøg ikke udføres af den legitime bruger. User risk handler om sandsynligheden for, at identiteten som helhed er kompromitteret.

Risk-signaler gør det muligt at lade policy engine reagere mere dynamisk. Et login med lav risiko kan behandles normalt, mens et login med høj risiko kan kræve stærkere kontrol eller blokering. User risk kan indgå i remediation-flow, hvor brugeren for eksempel skal gennemføre en sikker passwordændring i understøttede scenarier.

Risk-based Conditional Access er ikke inkluderet i almindelig Entra ID P1 alene. Risk-baserede policies kræver Microsoft Entra ID Protection-funktionalitet, som Microsoft licenserer på P2-niveau eller via relevante suites.

Det er en vigtig licensmæssig skelnen: Business Premium giver Conditional Access via Entra ID P1, men det betyder ikke automatisk, at alle risk-based P2-funktioner er inkluderet.

Network og named locations

Conditional Access kan bruge network/location-signaler. Organisationen kan definere named locations baseret på IP-ranges eller lande/regioner og anvende dem i policies.

Det er nyttigt, men netværkslokation bør ikke blive en ny form for implicit tillid. En IP-adresse fortæller primært, hvor trafikken ser ud til at komme fra. Den fortæller ikke, om brugeren er legitim, om endpointet er sikkert, eller om en session er kompromitteret.

Geografisk blokering kan være fornuftig, når virksomheden med høj sikkerhed ved, at legitime brugere ikke arbejder fra bestemte regioner. Men rejser, VPN-tjenester, cloudinfrastruktur og mobile netværk gør placering til et signal med fejlmuligheder.

Microsoft understøtter også nyere netværkskoncepter gennem Global Secure Access, hvor compliant network kan indgå i Conditional Access. Det er et eksempel på, at netværk fortsat kan være et signal — men nu som del af en identitetsdrevet beslutning frem for som eneste tillidsgrænse.

Authentication flows og device code flow

Conditional Access kan kontrollere bestemte authentication flows. Device code flow er særligt relevant, fordi det bruges på enheder med begrænset lokal input, men også kan misbruges i phishing- og social engineering-scenarier.

En organisation bør derfor ikke ukritisk blokere device code flow overalt uden at undersøge legitime afhængigheder. Møderumsudstyr, CLI-værktøjer eller specialiserede enheder kan anvende flowet. Microsoft anbefaler at bruge sign-in logs til at forstå eksisterende brug og derefter kontrollere flowet målrettet.

Denne type policy viser, hvorfor Conditional Access kræver telemetri før enforcement. En teoretisk sikker regel kan være operationelt forkert, hvis virksomheden ikke kender sine autentificeringsflows.

Session controls og Continuous Access Evaluation

Grant controls afgør, om adgang kan gives. Session controls påvirker, hvordan adgangen fungerer efter autentificeringen. Det kan blandt andet omfatte sign-in frequency, persistent browser session, app-enforced restrictions og andre understøttede kontroller.

Session management bør bruges med omtanke. Kort sign-in frequency er ikke automatisk høj sikkerhed. Hyppige prompts kan føre til brugerfrustration og dårlige arbejdsgange, mens moderne mekanismer som Continuous Access Evaluation kan reagere på kritiske hændelser uden blot at forkorte alle sessioner mekanisk.

Continuous Access Evaluation, CAE, gør det muligt for understøttede tjenester og klienter at reagere på visse kritiske events og policyændringer tættere på realtid frem for udelukkende at vente på token expiration. CAE er i dag automatisk en del af Conditional Access-modellen i understøttede scenarier, og Microsoft giver mulighed for at tilpasse den gennem session controls.

Det betyder ikke, at alle Microsoft- og tredjepartsapps kan afbryde alle sessioner øjeblikkeligt. Understøttelse afhænger af ressource og klient. Derfor bør offboarding og incident response stadig forstå token- og sessionadfærd konkret.

Workload identities og service principals

Conditional Access er ikke længere kun relevant for menneskelige brugere. Microsoft understøtter policies for udvalgte workload identities, særligt single-tenant service principals, når organisationen har de nødvendige Microsoft Entra Workload ID Premium-licenser.

Workload identities adskiller sig fra brugere. De kan ikke gennemføre MFA på samme måde, og de anvender ofte credentials, certifikater eller federated identity til at hente tokens. Derfor er de tilgængelige Conditional Access-kontroller også anderledes. For service principals er blokering baseret på eksempelvis lokation eller risk centrale scenarier.

Managed identities og multitenant SaaS-apps har andre begrænsninger og er ikke automatisk dækket af samme workload-identity-policyfunktionalitet.

Denne skelnen er vigtig, fordi en organisation ellers kan antage, at "all users" også beskytter alle appidentiteter. Det gør den ikke. Menneskeidentiteter og workload identities kræver hver deres governance.

Emergency access: beskyttelse mod administrativ lockout

Conditional Access kan låse hele organisationen ude, hvis policies designes forkert. Derfor skal resiliens designes før enforcement.

Microsoft anbefaler to eller flere emergency access-konti med Global Administrator-rettigheder til nødsituationer. De skal være adskilt fra normal daglig administration og beskyttet med stærke, robuste autentificeringsmetoder. De bør ekskluderes fra policies, der kan blokere eller begrænse deres login.

Emergency access-konti er ikke en undskyldning for svag autentificering. Formålet med exclusion er at undgå afhængighed af den samme policy-stack, som kontoen skal kunne reparere. Microsoft anbefaler phishing-resistente metoder som passkeys/FIDO2 eller certificate-based authentication, afhængigt af organisationens model.

Kontiene bør overvåges, testes regelmæssigt og kun bruges ved nødsituationer. Et sign-in på en emergency access-konto bør i en moden organisation udløse alarm og efterfølgende review.

Security defaults og Conditional Access

Security defaults giver en grundlæggende sikkerhedsbaseline til tenants, der ikke bruger mere detaljeret Conditional Access. Når virksomheden begynder at bygge egne Conditional Access-policies, bør den forstå, at security defaults og Conditional Access ikke er tænkt som to parallelle policy-systemer.

Microsoft beskriver Conditional Access som den mere granulære model, der kan levere tilsvarende grundbeskyttelse med langt mere kontrol. Oprettelse af Conditional Access-politikker forhindrer i praksis brugen af security defaults som den aktive parallelle baseline.

Overgangen bør derfor være planlagt. Det er ikke nok at deaktivere security defaults og derefter begynde at eksperimentere. Før skiftet bør virksomheden have mindst en dokumenteret MFA-baseline, emergency access og en udrulningsplan.

Report-only, What If og policy impact

Report-only er et af de vigtigste værktøjer i Conditional Access. En politik i report-only bliver evalueret under sign-ins, men dens controls håndhæves ikke. Resultatet fremgår af sign-in logs, så administratoren kan se, hvem der ville være blevet ramt, og om kravene ville være opfyldt.

Report-only understøtter de fleste almindelige Conditional Access-scenarier, men ikke alle scopes og user actions opfører sig identisk. Derfor bør report-only ses som en stærk simulationsmekanisme, ikke som et matematisk bevis på alle fremtidige udfald.

What If-værktøjet gør det muligt at simulere et sæt betingelser og se, hvilke politikker der vil blive anvendt. Det er nyttigt i design og fejlfinding, men den virkelige sign-in telemetry er stadig vigtig, fordi den viser de faktiske resources, audiences, clients og signaler.

Microsofts nyere Conditional Access-overblik indeholder desuden coverage- og policy impact-visninger, der kan hjælpe med at identificere ressourcer uden forventet policydækning. Disse funktioner bør bruges som supplement til den organisationsejede policyinventar og reviewproces.

Policyarkitektur: få klare politikker frem for én stor regel

En enkelt mega-policy med mange conditions, exclusions og OR-kombinationer bliver hurtigt vanskelig at forstå. Det samme gælder den modsatte ekstrem: dusinvis af næsten identiske policies uden navnestandard eller ejerskab.

En mere robust model opdeler sikkerhedsmålene i få, tydelige policies. Eksempelvis én baseline for MFA, én stærkere administratorpolitik, én device-control-policy til følsomme ressourcer, én BYOD/app protection-policy og enkelte målrettede blokpolitikker.

Navngivning bør gøre policyens effekt læsbar uden at åbne den. Eksempelvis CA-BASE-AllUsers-AllResources-MFA er mere driftsvenligt end New policy 14.

Undtagelser skal behandles som sikkerhedsgæld. Hver exclusion bør have en ejer, årsag, scope og reviewdato. Ellers vokser policies over tid til en historik over problemer, ingen længere tør rydde op i.

Logs og fejlfinding

Sign-in logs er den primære sandhedskilde ved Conditional Access-fejlfinding. De viser, hvilke policies der blev evalueret, om de gjaldt, og hvilke controls der blev opfyldt eller fejlede.

Det er vigtigt at se på både application og resource/audience. En bruger kan opleve, at vedkommende "logger ind i Teams", mens klienten samtidig anmoder om adgang til Exchange Online, SharePoint og andre ressourcer. En policy rettet mod en af disse ressourcer kan derfor påvirke oplevelsen, selvom brugeren kun tænker på Teams.

What If kan bruges til reproduktion, men sign-in logs bør være første stop ved konkrete brugerfejl.

Licensering og funktionsgrænser

Standard Conditional Access kræver Microsoft Entra ID P1. Entra ID P1 er blandt andet inkluderet i Microsoft 365 Business Premium, hvilket er grunden til, at Business Premium kan bruges til Conditional Access uden et separat P1-add-on.

Risk-based Conditional Access med user risk og sign-in risk kræver Microsoft Entra ID Protection, som er en P2-funktion. Conditional Access for workload identities har sin egen licensmodel gennem Microsoft Entra Workload ID Premium. Integrationer med Intune, Purview og andre produkter kræver naturligvis også de relevante produktlicenser.

Hvis Conditional Access-licenser udløber, bliver eksisterende policies ikke automatisk slettet eller slået fra. Microsoft beskriver en grace-lignende tilstand, hvor policies fortsætter, men ikke kan redigeres på normal vis. Det er endnu en grund til at behandle licensering som en del af sikkerhedsarkitekturen og ikke som et separat økonomispørgsmål.

Implementeringsmodel

En moden Conditional Access-implementering bør ske i faser.

Fase 1: Identitet og forudsætninger. Sørg for korrekt bruger- og gruppelifecycle, registrerede autentificeringsmetoder, emergency access-konti og passende licenser.

Fase 2: Baseline. Design en bred MFA-policy for brugere og ressourcer. Undgå unødvendige app-exclusions.

Fase 3: Privileged access. Beskyt administratorer med stærkere authentication strengths og separate administrative arbejdsformer.

Fase 4: Device og app. Kobl Microsoft Intune til adgangsmodellen, når enrollment, compliance og app protection faktisk fungerer.

Fase 5: Specialiserede scenarier. Tilføj risk, network, authentication flow, session og andre kontroller efter dokumenteret behov.

Fase 6: Drift. Review sign-in logs, coverage, exclusions, policyændringer og brugerimpact løbende.

Hver fase bør følge samme udrulningsmønster: design, report-only, analyse, pilot, enforcement og efterfølgende monitorering.

Governance og change management

Conditional Access er konfiguration, men bør behandles som sikkerhedskritisk kode. En lille ændring i en exclusion, target resource eller grant control kan påvirke tusindvis af logins.

Derfor bør virksomheden have en change-proces. Hver policy skal have ejer, formål og forventet effekt. Væsentlige ændringer skal peer-reviewes. Report-only bør bruges ved nye eller fundamentalt ændrede policies. Emergency access skal være testet. Rollback skal være beskrevet før enforcement.

Policyændringer bør kunne spores i audit logs og i organisationens change management-system. Hvis en administrator ændrer en policy fredag eftermiddag, bør virksomheden efterfølgende kunne afgøre præcis hvad der blev ændret og hvorfor.

Almindelige fejl og begrænsninger

Den første fejl er at slå en bred blokpolitik til direkte uden report-only. Det kan skabe lockout. Den anden er at kræve compliant device, før enhederne er enrolled og kan blive compliant. Den tredje er at ekskludere store grupper eller applikationer permanent for at løse supportproblemer.

En anden almindelig fejl er at gøre corporate network "trusted" i en grad, hvor MFA eller andre kontroller fjernes bredt. Et kompromitteret endpoint på kontoret er stadig kompromitteret. Netværksplacering bør være signal, ikke identitetsbevis.

Conditional Access har også platform- og klientafhængigheder. Ikke alle apps understøtter alle session- eller app protection-controls. Device-signaler kan være utilgængelige i bestemte flows. Politikdesign skal derfor baseres på den faktiske tekniske portefølje, ikke kun på en idealmodel.

Eksempel: Nordic Legal A/S

Nordic Legal A/S har 95 medarbejdere, fire Global Administrators, eksterne advokater og medarbejdere, der arbejder både fra firmalaptops og private mobile enheder. Virksomheden har Microsoft 365 Business Premium og Intune, men Conditional Access er historisk vokset gennem enkeltstående regler.

Miljøet har 23 policies. Flere overlapper. En gammel regel undtager hovedkontorets IP-adresse fra MFA. To apps er ekskluderet fra baselinepolitikken på grund af tidligere supportproblemer. Administratorer bruger samme MFA-krav som almindelige brugere. Ingen kan forklare, hvorfor en gruppe kaldet CA-Exclude-Temp stadig har 17 medlemmer.

Virksomheden vælger at redesigne modellen omkring seks kontrollerede policies:

Emergency access-kontiene flyttes til en dedikeret gruppe og ekskluderes fra blokerende eller begrænsende policies. De beskyttes med FIDO2/passkeys og testes kvartalsvist.

Alle nye policies oprettes i report-only. IT analyserer fire ugers sign-in data og opdager blandt andet, at et møderumssystem bruger device code flow. I stedet for at slå en global blokregel til og skabe driftsstop dokumenterer virksomheden scenariet og målretter politikken korrekt.

Administratorpolitikken afslører også, at én administrator ikke har registreret en phishing-resistent metode. Det bliver løst før enforcement. Device-policyen viser, at 11 laptops endnu ikke er korrekt compliant i Intune. De bliver remediated i stedet for at blive blokeret på første dag.

Resultatet er ikke blot færre policies. Virksomheden har en adgangsarkitektur, hvor hvert kontrolmål kan forklares. En ny medarbejder rammes automatisk af baseline. En administrator får stærkere krav. En firmalaptop skal opfylde defineret compliance, når følsomme ressourcer tilgås. Private mobile enheder kan bruge en appbeskyttet model. Undtagelser har ejer og reviewdato.

Best practices

Design Conditional Access som arkitektur og ikke som en samling supportfixes. Hver policy bør have ét tydeligt sikkerhedsmål.

Start bredt med baselinebeskyttelse. Microsoft anbefaler all users og all resources som udgangspunkt for MFA-baseline, med nødvendige emergency access-undtagelser.

Opret og test emergency access før de første håndhævede policies. Recovery skal være mulig, før policy engine får magt til at blokere administratorer.

Brug report-only systematisk. Analysér reelle sign-ins før enforcement.

Brug authentication strengths til privilegeret og følsom adgang. MFA er et minimumsbegreb, ikke én ensartet sikkerhedsstyrke.

Kobl compliant device til ressourcer, hvor endpointtilstand er sikkerhedskritisk, men først når Intune-lifecycle og remediation fungerer.

Brug app protection til relevante BYOD-scenarier og undgå nye designs baseret på den nu read-only Require approved client app-control.

Behandl exclusions som tidsbegrænset sikkerhedsgæld. Hver exclusion skal have ejer og begrundelse.

Vurder network/location som ét signal blandt flere. Et corporate netværk er ikke automatisk et sikkert endpoint.

Brug sign-in logs som sandhedskilde ved fejlfinding. What If er et supplement, ikke en erstatning for den faktiske sign-in telemetry.

Review policies, emergency access, exclusions og licenser mindst kvartalsvist i miljøer med aktiv ændring.

FAQ

1. Hvad er Microsoft Entra Conditional Access?

Conditional Access er Microsoft Entras policy engine, der evaluerer identitet, ressource og kontekst og håndhæver krav før eller under adgang til beskyttede ressourcer.

2. Er Conditional Access det samme som MFA?

Nej. MFA er én mulig access control. Conditional Access bestemmer, hvornår MFA eller andre krav skal gælde.

3. Hvornår evalueres Conditional Access?

For almindelige bruger-scenarier håndhæves Conditional Access efter første faktor er gennemført og i forbindelse med adgangs- og tokenflowet til den beskyttede ressource.

4. Hvilken licens kræver Conditional Access?

Standard Conditional Access kræver Microsoft Entra ID P1. P1 er blandt andet inkluderet i Microsoft 365 Business Premium.

5. Er risk-based Conditional Access inkluderet i Business Premium?

Ikke alene via den almindelige Entra ID P1-del. User risk og sign-in risk policies kræver Entra ID Protection-funktionalitet på P2-niveau eller via en relevant suite.

6. Hvad er en authentication strength?

Det er et Conditional Access-control, der specificerer hvilke kombinationer af autentificeringsmetoder der må opfylde adgangskravet.

7. Hvad betyder phishing-resistant authentication strength?

Det betyder, at kun metoder i Microsofts phishing-resistente strength kan opfylde kontrollen, eksempelvis relevante FIDO2/passkey- eller certifikatbaserede scenarier.

8. Skal alle brugere have MFA?

Microsoft anbefaler en bred baseline med MFA for alle relevante brugere og ressourcer, mens emergency access håndteres særskilt.

9. Hvad er report-only?

En policytilstand hvor Conditional Access evaluerer politikken og logger resultatet uden at håndhæve dens access controls.

10. Hvad er What If-værktøjet?

Et simulationsværktøj der viser, hvilke Conditional Access-policies der forventes at gælde for et specificeret scenarie.

11. Hvad er en emergency access-konto?

En særskilt administrativ konto, der kun bruges til at gendanne adgang, hvis den normale administrative adgangsmodel fejler.

12. Hvor mange emergency access-konti bør man have?

Microsoft anbefaler to eller flere, så recovery ikke afhænger af én enkelt konto eller autentificeringsvej.

13. Skal emergency access være ekskluderet fra Conditional Access?

Ja, fra policies der kan blokere eller begrænse den adgang, kontoen skal kunne bruge under en nødsituation. Kontiene skal samtidig beskyttes stærkt og overvåges.

14. Hvad betyder require compliant device?

At Conditional Access kræver en enhed, som Intune har vurderet compliant efter virksomhedens definerede policies.

15. Blokerer Intune automatisk noncompliant devices?

Ikke nødvendigvis. Intune leverer compliance-status. Conditional Access kan håndhæve konsekvensen ved at kræve compliant device for relevante ressourcer.

16. Hvad er Require app protection policy?

Et grant control til understøttede app- og mobile scenarier, hvor adgang kræver, at arbejdsdata er beskyttet gennem Intune app protection.

17. Kan man stadig bruge Require approved client app?

Den control blev flyttet til read-only den 30. juni 2026. Nye designs bør bruge app protection policy i understøttede scenarier.

18. Kan Conditional Access blokere lande?

Ja. Named locations og network/location-conditions kan bruges til geografiske og IP-baserede policies, men placering bør ikke være eneste sikkerhedssignal.

19. Hvad er device code flow?

Et authentication flow til enheder med begrænset input. Det er legitimt i nogle scenarier, men kan også misbruges og kan derfor kontrolleres med Conditional Access.

20. Hvad er Continuous Access Evaluation?

CAE gør det muligt for understøttede ressourcer og klienter at reagere på visse kritiske events og policyændringer uden udelukkende at vente på normal tokenudløb.

21. Kan Conditional Access beskytte service principals?

Ja, i bestemte workload identity-scenarier. Det kræver særskilt Microsoft Entra Workload ID Premium-licensering og har andre controls og begrænsninger end brugerpolicies.

22. Er managed identities omfattet af Conditional Access for workload identities?

Ikke på samme måde som de understøttede single-tenant service principals. Workload identity-funktionaliteten har eksplicitte scopebegrænsninger.

23. Kan security defaults og Conditional Access bruges parallelt?

De er ikke designet som parallelle policy-modeller. Conditional Access er den granulære efterfølger til security-defaults-baseline i organisationer, der har de nødvendige licenser.

24. Hvor mange Conditional Access-policies bør man have?

Der findes ikke ét korrekt antal. Målet bør være et lille, forståeligt policiesæt med klare sikkerhedsmål frem for enten én kompleks mega-policy eller mange næsten identiske regler.

Konklusion

Conditional Access er ikke bare en MFA-funktion. Det er Microsoft Entras policy engine for adgang og dermed et af de vigtigste kontrolpunkter i moderne Microsoft 365-sikkerhed.

En moden implementation starter med scope og risiko, ikke med tilfældige grant controls. Organisationen definerer, hvem der beskyttes, hvilke ressourcer der er kritiske, hvilke signaler der er troværdige, og hvilke adgangskrav der reducerer risiko uden unødvendig friktion. MFA bliver baseline. Authentication strengths giver stærkere beskyttelse til privilegeret adgang. Intune compliance og app protection gør endpoint- og appstatus til en del af beslutningen. Risk-signaler, authentication flows, network og session controls bruges efter konkret behov.

Samtidig kræver Conditional Access disciplin. En policyfejl kan påvirke hele organisationen. Derfor er emergency access, report-only, sign-in logs, pilotgrupper, peer review og dokumenterede exclusions ikke administrative detaljer. De er en del af sikkerhedsdesignet.

Når Conditional Access drives på denne måde, bevæger virksomheden sig fra statisk adgang til eksplicit verifikation. Brugeren får ikke adgang alene fordi passwordet er korrekt eller fordi computeren står på kontoret. Adgang gives, fordi identitet, kontekst og nødvendige kontroller tilsammen opfylder virksomhedens policy.