{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"cs/conditional-access","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/cs/conditional-access/","da":"https://cmaintz.github.io/tech-atlas/da/terms/cs/conditional-access/"},"term":{"en":"Conditional access","da":"Betinget adgang (conditional access)"},"aka":{"en":["conditional access policy"],"da":["conditional access"]},"domain":["cs","security"],"cluster":"identity","layer":"identity","status":"current","era":2016,"summary":{"en":"Rules that decide at each login whether to let someone in, ask for more proof or block them, based on who, where and what device.","da":"Regler, der ved hvert login afgør, om en person lukkes ind, skal bevise mere eller afvises - ud fra hvem, hvor og hvilken enhed."},"body":{"formal":{"en":"A policy engine, usually part of the identity provider, that weighs signals about each sign-in - user and group, device health, location, the app being opened and a risk score - and then allows, blocks or adds a demand such as MFA before a session is issued.","da":"En regelmotor, som regel en del af identitetsudbyderen, der vurderer signaler ved hvert login - bruger og gruppe, enhedens tilstand, placering, den app, der åbnes, og en risikovurdering - og derefter tillader, blokerer eller stiller et ekstra krav som MFA, før der udstedes en session."},"plain":{"en":"Like a doorman who knows the regulars - a familiar face at the usual time walks straight in, but the same name turning up at 3 a.m. from abroad has to show ID.","da":"Som en dørmand, der kender sine faste gæster - et kendt ansigt på det sædvanlige tidspunkt går direkte ind, men det samme navn, der dukker op kl. 3 om natten fra udlandet, skal vise legitimation."},"inPractice":{"en":"A municipality's IT operations manager sets rules so staff can open Microsoft 365 from a managed work laptop with a password alone, must pass MFA on a private phone, and are blocked when signing in from abroad.","da":"En kommunes IT-driftsansvarlige sætter regler op, så medarbejderne kan åbne Microsoft 365 fra en administreret arbejdscomputer med adgangskode alene, skal igennem MFA på en privat telefon og afvises ved login fra udlandet."},"whyItMatters":{"en":"When staff reach cloud apps from anywhere, there is no office wall to hide behind; judging each login in context turns many stolen-password logins away without slowing normal work.","da":"Når medarbejderne bruger cloudapps hvor som helst fra, er der ingen kontormur at gemme sig bag; ved at vurdere hvert login i sin sammenhæng afvises mange login med stjålne adgangskoder, uden at det daglige arbejde sinkes."}},"deepDive":{"en":"Conditional access is the policy decision point of an identity provider applied at token issuance. In NIST SP 800-207 terms the IdP's policy engine evaluates signals and the token service acts as enforcement point: if a request fails policy, no token is issued, or the token is issued only after an additional step. The term is Microsoft's product name in Entra ID, but equivalents exist elsewhere, such as Okta's authentication policies and Google's context-aware access. In Entra ID each policy is an if-then rule made of assignments (users, groups, workload or agent identities, target resources) plus conditions (sign-in and user risk, device platform, named locations and countries, client app type, device filters) and access controls. Grant controls block, or require MFA, an authentication strength, a compliant or hybrid-joined device, an approved client app or an app protection policy; session controls set sign-in frequency, persistent browser behaviour and app-enforced restrictions.\n\nEvaluation details matter. Microsoft documents that policies are enforced after first-factor authentication, so conditional access does not stop password spraying or lockout attacks; it decides what happens after the password is right. All policies that match a sign-in are combined: every grant requirement must be satisfied and any block wins. Because the decision is taken when the token is issued, an already-issued access token remains usable until it expires unless the application supports Continuous Access Evaluation, which lets resource providers such as Exchange Online reject tokens promptly after critical events such as account disablement or password reset.\n\nTypical baseline policies are MFA for all users, phishing-resistant authentication strength for administrator roles, blocking legacy authentication protocols (which cannot perform MFA and so bypass the rule), requiring managed devices for sensitive apps, and risk-based step-up. Licensing shapes design: conditional access requires Entra ID P1, while sign-in and user risk conditions depend on Entra ID Protection, a P2 feature.\n\nFailure modes are mostly configuration gaps. Exclusions accumulate, whether for service accounts, a VIP or a legacy app, and each one is a hole; emergency break-glass accounts must be excluded to avoid lock-out, which makes their monitoring essential. IP location is weak evidence because VPNs and cloud hosting mask origin. Device-compliance checks rely on the MDM's view of the device. Stolen session cookies from adversary-in-the-middle phishing replay a token that already passed policy, which is why token binding and short sign-in frequency complement it. Microsoft recommends running new policies in report-only mode first and using the What If tool; changes should be versioned and reviewed like code, since one mistaken policy can lock out an entire tenant.","da":"Betinget adgang er identitetsudbyderens policy decision point, anvendt i det øjeblik, der udstedes et token. I NIST SP 800-207's begreber vurderer IdP'ens regelmotor signalerne, mens tokentjenesten fungerer som håndhævelsespunkt: Opfylder forespørgslen ikke politikken, udstedes der intet token, eller først efter et ekstra trin. Betegnelsen er Microsofts produktnavn i Entra ID, men andre har tilsvarende funktioner, fx Oktas authentication policies og Googles context-aware access. I Entra ID er hver politik en hvis-så-regel bestående af tildelinger (brugere, grupper, workload- eller agentidentiteter, målressourcer), betingelser (login- og brugerrisiko, enhedsplatform, navngivne placeringer og lande, klientapptype, enhedsfiltre) og adgangskontroller. Grant-kontroller blokerer eller kræver MFA, en bestemt autentificeringsstyrke, en kompatibel eller hybrid-joined enhed, en godkendt klientapp eller en appbeskyttelsespolitik; sessionskontroller styrer loginhyppighed, vedvarende browsersessioner og app-håndhævede begrænsninger.\n\nDetaljerne i evalueringen er vigtige. Microsoft dokumenterer, at politikkerne håndhæves efter autentificeringen med første faktor, så betinget adgang stopper ikke password spraying eller spærringsangreb; den afgør, hvad der sker, når adgangskoden er korrekt. Alle politikker, der matcher et login, kombineres: Hvert grant-krav skal være opfyldt, og en blokering vinder altid. Da beslutningen træffes ved udstedelsen af tokenet, kan et allerede udstedt adgangstoken bruges, til det udløber, medmindre applikationen understøtter Continuous Access Evaluation, som lader ressourceudbydere som Exchange Online afvise tokens hurtigt efter kritiske hændelser som deaktivering af kontoen eller nulstilling af adgangskoden.\n\nTypiske basispolitikker er MFA for alle brugere, phishing-resistent autentificeringsstyrke for administratorroller, blokering af ældre autentificeringsprotokoller (legacy authentication, der ikke kan håndtere MFA og derfor omgår reglen), krav om administrerede enheder til følsomme apps og risikobaseret step-up. Licenserne påvirker designet: Betinget adgang kræver Entra ID P1, mens betingelser om login- og brugerrisiko afhænger af Entra ID Protection, der er en P2-funktion.\n\nFejlene er oftest huller i konfigurationen. Undtagelser hober sig op, hvad enten det er servicekonti, en VIP eller en gammel app, og hver af dem er et hul; nødkonti (break-glass) skal undtages for at undgå at låse sig selv ude, og derfor er overvågning af dem afgørende. IP-placering er et svagt bevis, fordi VPN og cloudhosting skjuler oprindelsen. Kontrol af enhedens overholdelse bygger på MDM-systemets billede af enheden. Stjålne sessionscookies fra adversary-in-the-middle-phishing genbruger et token, der allerede har bestået politikken, og derfor suppleres betinget adgang med tokenbinding og kort loginhyppighed. Microsoft anbefaler at køre nye politikker i report-only-tilstand først og bruge What If-værktøjet; ændringer bør versionsstyres og gennemgås som kode, fordi én fejlagtig politik kan låse en hel tenant ude."},"edges":[{"type":"requires","to":"cs/access-control","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/authentication","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/identity-provider","confidence":"high","strength":"normal"},{"type":"implements","to":"security/zero-trust","confidence":"high","strength":"normal"},{"type":"used-with","to":"security/mfa","why":{"en":"MFA is the most common extra demand the rules add when a login looks unusual.","da":"MFA er det mest almindelige ekstra krav, reglerne stiller, når et login ser usædvanligt ud."},"confidence":"high","strength":"primary"},{"type":"used-with","to":"platform/saas","why":{"en":"Cloud apps are reached from anywhere, so the login check becomes the main gate in front of them.","da":"Cloudapps kan nås fra hvor som helst, så kontrollen ved login bliver den vigtigste port foran dem."},"confidence":"high","strength":"normal"}],"depth":4,"sources":[{"title":"Microsoft Learn - What is Conditional Access in Microsoft Entra ID?","url":"https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview","tier":"official-doc","publisher":"Microsoft"},{"title":"NIST SP 800-207 - Zero Trust Architecture","url":"https://doi.org/10.6028/NIST.SP.800-207","tier":"standard","publisher":"NIST"}],"draft":true}