Zero Trust har vore eit moteord så lenge at mange har slutta å høyre kva det faktisk seier: aldri stol på noko, verifiser alt, kvar gong! Men prinsippet blir ikkje politikk før nokon skriv det ned som reglar, og i Microsoft-skya er det Conditional Access som er den regelboka. Kvar einaste innlogging i Entra ID går gjennom policy-motoren, og det du ikkje har definert der, har du i praksis tillate. Denne guiden handlar om tre ting: kvifor CA er sjølve grunnmuren for informasjonsvern, korleis du finn ut kvar du faktisk står i dag, og kva baseline du bør ha på plass – spesielt om Insider Risk Management, datatap og NIS2 står på agendaen din.
Kvifor Conditional Access er grunnmuren – ikkje ein detalj
Alt informasjonsvern i Microsoft 365 kviler på éin føresetnad: at det er rett person, på ein trygg eining, som får tilgang. Sensitivity labels, DLP-reglar og Insider Risk Management er verktøy som verkar etter at nokon er inne. Sviktar tilgangskontrollen, jobbar alle dei andre laga i motbakke – ein stolen identitet med gyldig sesjon ser ut som ein lojal tilsett for heile resten av stacken.
Det er difor datatap og identitet ikkje kan skiljast: dei fleste reelle datatap-hendingar startar ikkje med avansert skadevare, men med ein konto som logga inn heilt «normalt» – frå feil stad, på feil eining, utan at nokon policy stoppa det. Conditional Access er staden du avgjer at sesjonen frå ei uforvalta eining ikkje får laste ned, at høgrisiko-innloggingar møter sterkare krav, og at legacy-protokollar utan MFA-støtte ikkje slepp inn i det heile.
Microsoft har sjølv stramma grepet det siste året: obligatorisk MFA for Azure-administrasjon er no fullt handheva (siste frist for utsetjing var 1. juli 2026), og våren 2026 tetta Microsoft eit smotthol der førespørnader med berre OIDC-scopes kunne gli forbi policyar med ressurs-unntak. Retninga er tydeleg: Microsoft flyttar grunnsikringa frå valfri til pålagd. Spørsmålet er om di verksemd ligg føre eller etter den kurva.
Kvar står du i dag? Analyser før du byggjer
Det farlegaste utgangspunktet er «vi har vel nokre policyar frå den gong». CA-miljø som har vakse organisk over år har gjerne overlappande reglar, gløymde unntak og grupper som ingen lenger veit kvifor er ekskluderte. Kvart unntak er eit hòl i gjerdet.
Eg har laga eit PowerShell-script – Export-CAAnalysisPrompt – som hentar ut CA-statusen i tenanten (rein lesetilgang, ingenting blir endra) – policyar, named locations, unntak og report-only-status – og genererer ein ferdig prompt du kan lime inn i ein LLM. Så slepp du å lese 40 policyar manuelt: språkmodellen får heile biletet og peikar på overlapp, hòl og unntak som ikkje heng saman. Men ver medviten på kvar du limer: CA-konfigurasjonen er eit kart over forsvarsverket ditt. Bruk Microsoft 365 Copilot med enterprise data protection, eller ein annan LLM du har databehandlaravtale med og stoler på – aldri ein vilkårleg gratis chatbot.
Uavhengig av verktøy bør gjennomgangen svare på desse spørsmåla:
- Dekning: Finst det brukarar som ikkje er omfatta av nokon MFA-policy? (Service-kontoar og gjestekontoar er klassikarane.)
- Unntak: Kven står på unntakslister, og kan nokon grunngje kvifor – i dag, ikkje i 2022?
- Legacy authentication: Er den blokkert, eller berre «nesten ikkje brukt»?
- Report-only-køen: Ligg det policyar i report-only som aldri vart sette i drift?
- Break-glass: Har du nødkontoar som er ekskluderte frå policyane, sikra med phishing-resistent MFA, og faktisk testa?
Sign-in-loggane og What if-verktøyet i Entra-portalen er undervurderte her: dei viser deg kva policy som faktisk slår inn for ein gitt brukar i ein gitt situasjon – ikkje kva du trur slår inn.
Baseline: minimum du bør ha på plass
Ein fornuftig CA-baseline i 2026 ser om lag slik ut – ikkje som ferdig fasit, men som golvet du ikkje bør ligge under:
- MFA for alle brukarar, alle appar. Ikkje berre administratorar, ikkje berre «viktige» appar. Sesjonen blir på eininga, så friksjonen er mindre enn frykta.
- Phishing-resistent MFA for administratorroller. Passkeys/FIDO2 eller sertifikatbasert autentisering for alt som har ståande privilegium.
- Blokker legacy authentication. Protokollar utan MFA-støtte er den opne bakdøra som gjer resten av policyane irrelevante.
- Krav om samsvarande/kompatibel eining for full tilgang. Uforvalta einingar skal ikkje kome til med same rettar som ei forvalta bedriftseining.
- Appbeskyttelse for mobil (iOS/Android). Office-appar krev godkjend eller kompatibel app sjølv på einingar som aldri blir MDM-registrerte – dette gløymer mange.
- MFA ved einingsregistrering, ikkje berre ved vanleg innlogging. Elles kan ein stolen sesjon registrere ei ny, tillitsfull eining på vegne av offeret.
- Sesjonskontroll for uforvalta einingar som mjukare alternativ til full blokk: nettlesartilgang utan nedlasting, kortare sign-in-frekvens – for tilfella der full blokk er for strengt, men ope er for slapt.
- Risikobaserte policyar (krev P2): høg innloggingsrisiko møter blokk eller sterk MFA, høg brukarrisiko krev passordbyte.
- Break-glass-kontoar dokumentert og ekskludert – med sterk autentisering og jamleg test.
- Ingen policy rett i drift: alt nytt går via report-only først, med gjennomgang av sign-in-loggane før handheving.
Microsoft sine Microsoft-managed policies er eit greitt sikkerheitsnett for dei som ikkje har kome i gang – men dei er nettopp det: eit nett, ikkje ein strategi. Dei veit ingenting om dine data, dine roller eller din risikoprofil.
Dette er, punkt for punkt, akkurat det baseline-oppsettet eg har bygd som eit ope PowerShell-script – Setup-ConditionalAccess-Full – det oppretter geo-sonene, unntaksgruppene og alle policyane over i éin køyring, alltid i report-only. Meir om korleis sonemodellen er bygd i neste avsnitt.
Geoblokkering i soner – og unntak som lukkar seg sjølv
Ei vidareutvikling av baselinen som gjev overraskande mykje governance på kjøpet: del verda inn i soner med named locations, og lag éin CA-policy per sone. I mitt eige oppsett ser det slik ut: Norden/EU/EØS, Storbritannia og Sveits som heimesone (open), tre eigne blokkerte soner for Amerika, Asia-Stillehavsregionen og Midtausten/Afrika – kvar med si eiga unntaksgruppe – ei liste med eit fåtal høgrisikostatar som er permanent blokkerte utan unntaksmoglegheit i det heile, og til slutt eit fangst-alt-nivå som blokkerer alt anna som ikkje er eksplisitt nemnt i sonene over. Kvar sone-policy får si eiga unntaksgruppe – slik at eit unntak for Asia ikkje samstundes opnar Sør-Amerika.
Scriptet oppretter desse unntaksgruppene ferdige, men fyller dei bevisst ikkje sjølv med medlemmer – det er ei avgjerd, ikkje ein mangel. Neste steg, som eg ikkje har automatisert enno, er å kople kvar unntaksgruppe til ei tidsavgrensa tilgangspakke i entitlement management (krev Entra ID Governance/P2), med utløp etter til dømes 4 veker. Den tilsette som skal på jobbreise, ferie eller kundeoppdrag utanfor normalsona ber sjølv om tilgangspakka, næraste leiar godkjenner, og unntaket opnar seg. Fire veker seinare lukkar det seg av seg sjølv – ingen treng hugse å rydde, og ingen blir ståande i unntakslista i tre år fordi nokon gløymde ei Jira-sak.
Dette svarer på det klassiske revisjonsspørsmålet «kven har unntak frå geoblokkeringa, og kvifor?» med ein rapport i staden for ei skuldertrekning: kvart unntak har ein forespørjar, ein godkjennar, ei forretningsgrunngjeving og ein utløpsdato. Det er nettopp den dokumenterte, risikobaserte tilgangsstyringa NIS2 spør etter – og unntakshandteringa som elles er det svakaste punktet i eitkvart CA-oppsett, blir ein styrke i staden.
Og for å vere heilt ærleg: geoblokkering stoppar ikkje ein angripar som leiger seg eit VPN-endepunkt i normalsona di. IP-adressa fortel kvar trafikken kjem frå, ikkje kven som sit bak. Sjå på geoblokkeringa som eit hygienetiltak og støyfilter – den fjernar den breie, automatiserte skanninga og gjer sign-in-loggane leselege – ikkje som ein garanti. Det er kombinasjonen med MFA, einingskrav og risikopolicyane over som ber lasta.
Koplinga til IRM, datatap og NIS2
Her heng det saman: Insider Risk Management og DLP føreset at identiteten og eininga er verifisert – elles analyserer du åtferda til nokon du ikkje veit kven er. CA leverer signala og handhevinga som gjer resten av Purview-stacken truverdig.
Og koplinga går no begge vegar: insider risk er ein eigen condition i Conditional Access. Med Adaptive Protection aktivert i Purview kan du byggje ein policy som blokkerer tilgang for brukarar med forhøgd insider-risikonivå – alle brukarar, alle ressursar, condition Insider risk = Elevated, Block access. Break-glass-kontoar, servicekontoar og eksterne brukarar skal ekskluderast, og policyen skal alltid innom report-only før handheving. Microsoft har oppskrifta klar: policy-risk-based-insider-block – og for lågare risikonivå kan du bruke mjukare kontrollar, som krav om å godta terms of use. Dette er Zero Trust i praksis: åtferdssignal frå Purview endrar tilgangen i sanntid, i staden for at nokon les ein rapport tre veker etterpå.
Og så var det NIS2. Direktivet (artikkel 21) krev mellom anna fleirfaktorautentisering, tilgangsstyring og risikobasert sikkerheitsstyring som dokumenterte minimumstiltak, med personleg leiingsansvar og gebyr som bit. I Noreg trådde digitalsikkerhetslova (NIS1) i kraft 1. oktober 2025, og dei NIS2-tilpassa endringane er på veg inn, sjølv om eksakt ikraftsetting for desse endringane enno ikkje er endeleg fastsett per juli 2026. Registreringsfrist for omfatta verksemder er venta hausten 2026, og talet på norske verksemder med lovpålagde krav veks frå om lag 600 til rundt 5 000.
For deg som skal svare på eit NIS2-tilsyn er poenget dette: ein dokumentert, gjennomgått CA-baseline er dokumentasjonen på at tilgangsstyring og MFA-kravet er operasjonalisert. Analysen av dagens status er ikkje berre god praksis – den er beviset du kjem til å trenge.
Heilt ærleg?
Conditional Access er ikkje spennande. Det finst ingen demo som imponerer leiargruppa, ingen KI-magi. Men eg har enno ikkje sett ei verksemd med god kontroll på datatap og innsiderisiko som hadde rotete CA-oppsett – og eg har sett mange med dyre Purview-lisensar som gløymde at grunnmuren står i Entra. Om du berre gjer éin ting etter å ha lese dette: køyr analysen. Ikkje fordi rapporten er kjekk å ha, men fordi du sannsynlegvis finn minst eitt unntak du ikkje visste om. Det gjorde eg.