Styring af Microsoft Entra Conditional Access i 2026

Klokken er 09:12 en tirsdag, da Maria, CISO i en hurtigt voksende europæisk fintech-virksomhed, åbner en DORA-beredskabsrapport, der burde have været rutine. Hendes Microsoft Entra Conditional Access-kontrolpanel ser solidt ud. MFA håndhæves for administratorer. Ældre autentifikation er blokeret. Højrisiko-logins udfordres eller afvises. Følsomme finansapplikationer kræver kompatible enheder. Browseradgang fra ikke-administrerede endpoints er begrænset.

Så læser hun revisors konstatering.

“Jeres Conditional Access-regler er teknisk solide, men de står alene. Vis os den bestyrelsesgodkendte politik, der kræver disse indstillinger. Vis os ændringsregistreringen for den regel, der blev ændret i sidste måned. Vis os, hvordan politikken for højrisiko-login var aktiv under det formodede credential stuffing-angreb. Vis os, hvordan dette revisionsbevis understøtter ISO 27001, DORA, NIS2 og GDPR.”

Identitetsteamet kan eksportere konfigurationen. SOC kan vise loginlogfiler. Den complianceansvarlige kan henvise til en politikmappe. Men ingen kan fremlægge en samlet, styret dokumentationskæde, der forbinder risiko, politik, godkendelse, konfiguration, undtagelser, overvågning, hændelseshåndtering, databeskyttelsesforpligtelser og ledelsens gennemgang.

Det er styringsproblemet for Conditional Access i 2026.

Microsoft Entra Conditional Access er ikke længere blot en identitetsindstilling. Det er et kontrolsystem på ledelsesniveau, der afgør, hvem der kan få adgang til cloudtjenester, under hvilke betingelser, fra hvilke enheder, med hvilken autentifikationsstyrke og med hvilke sessionsbegrænsninger. For regulerede organisationer skal disse beslutninger kunne forklares, være juridisk forsvarlige og kortlægges til forpligtelser efter ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST og COBIT 2019.

Conditional Access er nu et revisionsklart kontrolsystem

Conditional Access befinder sig i krydsfeltet mellem identitet, enheders sikkerhedstilstand, applikationers følsomhed, placering, loginrisiko, brugerrisiko, sessionsadfærd og logning. En enkelt politik kan kræve MFA, kræve en kompatibel enhed, blokere adgang fra en risikabel placering, begrænse downloads fra ikke-administrerede browsere eller gennemtvinge genautentifikation, når risikoen ændrer sig.

Det gør det til et af de stærkeste håndhævelsespunkter for Zero Trust i Microsoft-cloudmiljøer. Det gør det også særdeles velegnet til revision.

Efter ISO/IEC 27001:2022 er en kontrol ikke moden, blot fordi den findes i en portal. Organisationen skal forstå sin kontekst, vurdere informationssikkerhedsrisici, vælge risikobehandlinger, dokumentere anvendelseserklæringen, drive kontroller, overvåge effektivitet og forbedre sig over tid. Relevante klausuler omfatter Clause 6.1.2 om risikovurdering, Clause 6.1.3 om risikobehandling, Clause 7.5 om dokumenteret information, Clause 8.1 om operationel planlægning og styring, Clause 9.1 om overvågning og Clause 9.3 om ledelsens gennemgang.

Annex A, der er tilpasset ISO/IEC 27002:2022, giver det praktiske kontrolsprog, som revisorer vil genkende. Conditional Access understøtter typisk:

• 5.15 adgangskontrol
• 5.16 identitetsstyring
• 5.17 autentifikationsoplysninger
• 5.18 adgangsrettigheder
• 8.1 brugernes endpoint-enheder
• 8.2 privilegerede adgangsrettigheder
• 8.3 begrænsning af adgang til information
• 8.5 sikker autentifikation
• 8.15 logning
• 8.16 overvågningsaktiviteter

For EU-regulerede organisationer er styringsbyrden endnu tydeligere. NIS2 Article 20 placerer ansvaret hos ledelsesorganerne for at godkende og føre tilsyn med foranstaltninger til styring af cybersikkerhedsrisici. NIS2 Article 21 kræver passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger, herunder adgangsstyring, politik for aktivstyring, cyberhygiejne, hændelseshåndtering, forsyningskædesikkerhed, effektivitetsvurdering og multifaktorautentifikation eller løbende autentifikation, hvor det er relevant. NIS2 Article 23 indfører trinvis rapportering af væsentlige hændelser, herunder en tidlig varsling inden for 24 timer, en hændelsesunderretning inden for 72 timer og en endelig rapport inden for én måned.

DORA stiller tilsvarende forventninger til finansielle enheder. Article 5 kræver et internt ledelses- og kontrolrammeværk. Article 6 kræver et rammeværk for styring af IKT-risici. Article 9 omhandler beskyttelse og forebyggelse, herunder adgangsbegrænsninger og praksis for identitetsstyring. Articles 10, 11, 17, 18 og 19 forbinder detektion, respons, genopretning, IKT-hændelsesstyring, klassificering og rapportering. Da DORA finder anvendelse fra 17 January 2025, bør finansielle enheder behandle Conditional Access som en del af revisionsbeviset for operationel robusthed, ikke blot som identitetshærdning.

GDPR tilføjer databeskyttelsesperspektivet. Hvis Conditional Access beskytter systemer, der behandler personoplysninger, understøtter det ansvarlighedsprincippet i Article 5, den dataansvarliges ansvar i Article 24, databeskyttelse gennem design i Article 25 og behandlingssikkerhed i Article 32. Hvis der er mistanke om uautoriseret adgang, kan Conditional Access-logfiler indgå i vurderingen af brud og dokumentationen for underretning.

Fejlen er at behandle disse som adskilte revisionsanmodninger. Den modne tilgang er én styringsmodel for Conditional Access, som kan opdeles efter rammeværk, tilsynsmyndighed, kunde eller bestyrelsesmålgruppe.

Konfiguration er ikke styring

De fleste organisationer kan svare på spørgsmålet: “Hvad er konfigureret?” Færre kan svare på de vanskeligere spørgsmål:

• Hvorfor er denne Conditional Access-politik konfigureret på denne måde?
• Hvilket risikoscenarie behandler den?
• Hvilken politikklausul kræver den?
• Hvem godkendte ændringen?
• Hvilke brugere, applikationer og enheder er undtaget?
• Hvordan testes den?
• Hvilke logfiler dokumenterer, at den virkede?
• Hvor ofte gennemgås den?
• Hvad sker der, når den fejler?

Det er her, revisionskonstateringer typisk opstår. Politikker findes, men er ikke koblet til Microsoft Entra-indstillinger. Enhedsoverholdelse ejes af IT-drift, men er ikke kortlagt til adgangsstyringsrisiko. Politikker for loginrisiko er aktiveret uden dokumenterede tærskler eller eskalationsregler. Sessionsbegrænsninger er konfigureret, men aldrig testet fra ikke-administrerede enheder. Logfiler opbevares, men er ikke bearbejdet til revisionsbevis.

Clarysec behandler dette som et sporbarhedsproblem. Hver Conditional Access-beslutning bør forbinde politik, risiko, kontrol, konfiguration, revisionsbevis og gennemgang.

SME Cloud Usage Policy-sme Cloud Usage Policy-sme - SME fastslår:

Multifaktorgodkendelse (MFA) for administrator- og brugerkonti

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.2.2.

Denne klausul er mandatet. Conditional Access-reglen er håndhævelsen. Loginlogfilen er revisionsbeviset. Gennemgangsregistreringen dokumenterer tilsynet.

SME Network Security Policy-sme Network Security Policy-sme - SME tilføjer kravet til endpointets sikkerhedstilstand:

Systemer uden opdateret antivirus, patches eller en acceptabel enhedstilstand skal blokeres eller sættes i karantæne

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.4.3.

I Microsoft Entra-termer kan dette blive til “kræv kompatibel enhed”, “blokér ikke-understøttede platforme”, “begræns ikke-administrerede browsersessioner” eller “afvis adgang til højrisikoapplikationer fra ukendte enheder”. Men kontrollen er ikke komplet, før organisationen kan dokumentere omfang, godkendelse, test, undtagelser og overvågning.

Etabler styringsgrundlaget før regelsættet

Et stærkt Conditional Access-program starter uden for Entra-portalen. Det starter med ISMS, risikoregister, adgangskontrolpolitik, politik for brug af cloudtjenester, SoA og evidensmodel.

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint giver en praktisk rækkefølge. I risikostyringsfasen, Step 13, planlægning af risikobehandling og anvendelseserklæring, instruerer den organisationer i at forbinde kontroller med risici og regulatoriske drivere:

Krydsreferér regler: Hvis bestemte kontroller implementeres specifikt for at overholde GDPR, NIS2 eller DORA, kan du notere det enten i risikoregisteret (som en del af begrundelsen for risikokonsekvens) eller i SoA-noterne.

For Conditional Access ændrer det dokumentationsfortællingen. I stedet for at sige: “Vi har aktiveret MFA”, kan organisationen sige:

• Risikoscenarie: Kompromitterede brugerlegitimationsoplysninger giver uautoriseret adgang til kundedata i Microsoft 365 og finans-SaaS.
• Risikoejer: Leder af IT-sikkerhed.
• Behandling: Entra Conditional Access kræver stærk MFA for privilegerede roller, MFA for brugere, blokering baseret på loginrisiko, kompatible enheder for følsomme applikationer og sessionsbegrænsninger for ikke-administrerede endpoints.
• ISO/IEC 27002:2022-kortlægning: 5.15, 5.16, 5.17, 5.18, 8.1, 8.2, 8.3, 8.5, 8.15 og 8.16.
• Regulatorisk kortlægning: NIS2 Articles 20, 21 og 23, DORA Articles 5, 6, 9, 10, 17 og 18, GDPR Articles 24, 25, 32 og 33.
• Revisionsbevis: Politikgodkendelse, Conditional Access-eksport, ændringssag, testresultater, loginlogfiler, rapporter om enhedsoverholdelse, undtagelsesregister, SOC-sager og referater fra ledelsens gennemgang.

Zenith Blueprint forklarer også i fasen Controls in Action, Step 19, hvorfor endpointets sikkerhedstilstand hører hjemme i adgangsbeslutningen:

Adgang til information via endpoints skal være kontekstbevidst. Opfylder enheden for eksempel minimumskravene til sikkerhed, før den tilgår virksomhedens ressourcer? Har den for nylig gennemført en malwarescanning? Opretter den forbindelse fra en usædvanlig placering eller et usædvanligt netværk? Ved integration med Zero Trust-principper kan endpointets sikkerhedstilstand indgå i conditional access og nægte adgang, indtil enheden dokumenterer, at den er sikker.

Det er det centrale styringsprincip. Conditional Access bør være risikobaseret, kontekstbevidst og skabe revisionsbevis.

Kortlæg Conditional Access-beslutninger til kontrolmål

Et modent program definerer standardiserede adgangsbeslutninger og kortlægger derefter hver enkelt til styringsformål og revisionsbevis. Det forebygger ukontrolleret politikspredning og gør revisionsdialoger enklere.

Enterprise Cloud Usage Policy Cloud Usage Policy understøtter central identitetsintegration:

Single Sign-On (SSO)-integration med organisationens IdP kræves for at sikre ensartet autentifikation.

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.2.4.

Enterprise User Account and Privilege Management Policy User Account and Privilege Management Policy gør overvågning eksplicit:

Brugen af Single Sign-On (SSO)-systemer skal integreres med centrale identitetsudbydere (f.eks. Active Directory (AD), Azure AD) og overvåges for anormal loginaktivitet.

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.3.4.

Tilsammen kræver disse klausuler mere end SSO. De kræver central identitetsarkitektur, ensartet autentifikation, overvågning af loginanomalier og revisionsbevis for, at adgangsbeslutninger gennemgås.

Enhedsoverholdelse: kontrollen revisorer kan teste

Enhedsoverholdelse er et af de områder, der lettest overvurderes. Et kontrolpanel kan vise 92 procent kompatible enheder, men en revisor vil spørge, om reglen gælder for de applikationer, der betyder noget, om private enheder er tilladt, om ikke-understøttede platforme er blokeret, og om undtagelser er godkendt.

Enterprise Remote Work Policy Remote Work Policy fastsætter godkendelsesgrundlaget:

BYOD-enheder skal være eksplicit godkendt og:

Fra afsnittet “Styringskrav”, politikklausul 5.2.2.

Denne korte sætning er væsentlig. BYOD er ikke blot en teknisk tilstand. Det er en styringsbeslutning. I Conditional Access bør den omsættes til regler for enhedsejerskab, minimumsbaselines for overholdelse, krypteringskrav, kontroller af patchning og malwarebeskyttelse, mobil appbeskyttelse, håndtering af kontrahenter og gennemgang af undtagelser.

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls kortlægger ISO/IEC 27002:2022-kontrol 5.15 adgangskontrol som forebyggende, med beskyttelse af fortrolighed, integritet og tilgængelighed i den operationelle kapacitet for identitets- og adgangsstyring. Den forbinder også adgangsstyring med brugerendpoints, fordi ikke-administrerede bærbare computere, mobiltelefoner og stationære computere kan underminere centraliseret adgangshåndhævelse.

En praktisk kvartalsvis evidenspakke for Conditional Access og enheder bør omfatte:

• Godkendt baseline for enhedsoverholdelse.
• Conditional Access-politikker, der kræver kompatible enheder.
• Applikationer, der er beskyttet af disse politikker.
• Eksport af undtagne brugere, grupper, applikationer og platforme.
• Trendrapport for ikke-kompatible enheder.
• Eksempler på blokerede loginlogfiler for ikke-kompatible enheder.
• Undtagelsesregister med ejer, begrundelse, udløbsdato og risikoaccept.
• Registrering fra ledelsens gennemgang.

Denne evidenspakke understøtter operationel kontrol efter ISO/IEC 27001:2022, NIS2-cyberhygiejne, DORA-beskyttelse og forebyggelse samt GDPR-ansvarlighed.

Loginrisiko: detektion skal blive beslutningsbevis

Risikobaseret Conditional Access er det punkt, hvor identitetsdetektion bliver til adgangsstyring. Microsoft Entra kan evaluere signaler som ukendte loginegenskaber, anonyme IP-adresser, umulig rejse og lækkede legitimationsoplysninger. Men revisorer accepterer ikke “risikopolitik aktiveret” som endeligt svar. De vil spørge, hvorfor tærsklerne blev valgt, hvem der gennemgår risikofyldte hændelser, og hvornår et højrisiko-login bliver til en hændelse.

SME Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME definerer et minimumskrav til logning:

Autentifikationslogfiler: Vellykkede og mislykkede loginforsøg, sessionsvarighed, brug af MFA

Fra afsnittet “Styringskrav”, politikklausul 5.4.2.

Enterprise Logging and Monitoring Policy Logging and Monitoring Policy udvider det forventede hændelsessæt:

Hændelsestyper, der skal registreres (f.eks. login, adgangsfejl, konfigurationsændringer, administrative kommandoer, malwaredetektion)

Fra afsnittet “Styringskrav”, politikklausul 5.1.1.

For Conditional Access bør nyttigt revisionsbevis omfatte vellykkede login, mislykkede login, resultat af Conditional Access-politik, MFA-metode, loginrisiko, brugerrisiko, enhedens overholdelsesstatus, tilgået applikation, placering, klientapplikation, resultat af sessionskontrol, politikændringshistorik og administrative handlinger.

Zenith Controls kortlægger ISO/IEC 27002:2022-kontrol 8.16 overvågningsaktiviteter som opdagende og korrigerende, knyttet til Detect- og Respond-begreber. Den forbinder overvågning med logning, hændelsesvurdering, trusselsintelligens, leverandørovervågning og hændelsesstyring. Den kortlægger også overvågningsaktiviteter til GDPR Articles 32 og 33, NIS2-hændelsesovervågning og -rapportering, DORA-sporing af IKT-hændelser, NIST-løbende overvågning og COBIT-sikkerhedsovervågning.

Et højrisiko-login, der blokeres af Conditional Access, er derfor ikke kun en sikkerhedsmæssig gevinst. Det er revisionsbevis for, at forebyggende, opdagende og responderende processer hænger sammen.

Sessionskontroller: forbindelsen mellem adgang og databeskyttelse

Beslutninger før adgang er ikke nok. Når en bruger er autentificeret, afgør sessionskontroller, hvor stor den resterende eksponering er. Det er særligt vigtigt for ikke-administrerede enheder, kontrahenter, fjernarbejde, delte terminaler, risikable placeringer og applikationer, der behandler personoplysninger.

SME Application Security Requirements Policy-sme Application Security Requirements Policy-sme - SME fastslår:

Sessionsstyring: Sessionsdata skal udløbe efter 15 minutters inaktivitet og omfatte timeout-advarsler, hvor det er relevant.

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.1.1.3.

I Microsoft Entra-styring kan dette kortlægges til loginfrekvens, begrænsninger for vedvarende browsersessioner, Conditional Access App Control, apphåndhævede begrænsninger, blokering af download, genautentifikation efter risikoændringer og følsomhedsbaserede sessionsbegrænsninger.

Sessionskontroller understøtter ISO/IEC 27002:2022-kontrol 8.3 begrænsning af adgang til information og 8.5 sikker autentifikation. De understøtter også GDPR Article 32 ved at reducere uautoriseret visning, download eller vedvarende adgang til personoplysninger. For DORA hjælper sessionsbegrænsninger med at begrænse eksponering i IKT-systemer og understøtter detektion og respons. For NIS2 er de forholdsmæssige foranstaltninger for adgangsstyring og cyberhygiejne.

Revisionsbeviset bør forklare, hvorfor sessionskontrollen findes. For eksempel bør “blokér download fra ikke-administrerede enheder for HR- og finansapplikationer” kortlægges til datalækage af personoplysninger, endpoint-kompromittering og tab af fortrolighed. Revisionsbevis bør omfatte konfiguration, applikationsomfang, testlogin fra administrerede og ikke-administrerede enheder, logfiler, der viser begrænsninger, og godkendelsesregistreringer.

Opret et Conditional Access-kontrolregister

Et Conditional Access-kontrolregister er den operationelle bro mellem risikoregisteret, anvendelseserklæringen og Microsoft Entra-konfigurationen. Det erstatter ikke disse dokumenter. Det gør dem anvendelige.

Brug en femtrins gennemgangscyklus:

1. Bekræft omfang: Identificér cloudapplikationer, der behandler regulerede, finansielle, operationelle eller personlige data.
2. Kortlæg politikker til risici: Knyt hver Conditional Access-politik til mindst ét risikoscenarie og én risikoejer.
3. Valider undtagelser: Eksportér undtagne brugere, roller, apps, grupper, placeringer og enheder. Hver undtagelse skal have en ejer, begrundelse, godkendelse og udløbsdato.
4. Test håndhævelse: Brug testkonti til at verificere MFA, enhedsoverholdelse, risikoblokering, blokering af ældre autentifikation og sessionsbegrænsninger.
5. Pak revisionsbevis: Opbevar eksporter, skærmbilleder, logfiler og godkendelser med metadata.

SME Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy-sme - SME er afgørende for bevisets integritet:

Metadata (f.eks. hvem der indsamlede det, hvornår og fra hvilket system) skal dokumenteres.

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.2.3.

Skærmbilleder uden kilde, dato, indsamler og systemkontekst er svagt revisionsbevis. Conditional Access-eksporter, loginlogfiler og gennemgangsrapporter bør behandles som kontrollerede revisionsoptegnelser.

Kortlægning af Conditional Access-revisionsbevis på tværs af compliance

Værdien af Conditional Access er, at ét kontrolsæt kan opfylde flere revisionsperspektiver, når det styres korrekt.

Zenith Controls kortlægger også 5.15 adgangskontrol til GDPR Article 32, NIS2 Article 21(2)(i), DORA-begreber for adgangsstyring, NIST SP 800-53-adgangskontrolfamilier og COBIT 2019 DSS06.04. Den kortlægger 8.5 sikker autentifikation til GDPR Articles 5, 24, 25 og 32, NIS2-styring af cybersikkerhedsrisici, DORA IKT-risikostyring, NIST-identifikation og -autentifikation samt COBIT-identitet og logisk adgang.

Læringen er enkel. Rammeværker bruger forskelligt sprog, men de forventer det samme assurance-mønster: de rette brugere, fra acceptable kontekster, med stærk autentifikation, gennem styrede sessioner og med logfiler, der dokumenterer, hvad der skete.

Sådan vil revisorer undersøge Conditional Access

En ISO/IEC 27001:2022-revisor vil starte med ISMS. Revisoren vil spørge, om Conditional Access er omfattet, hvilke risici det behandler, hvordan det fremgår af SoA, hvordan politikker godkendes, hvordan ændringer styres, og om revisionsbevis dokumenterer driftseffektivitet. Forvent stikprøver af privilegerede brugere, følsomme applikationer, undtagelser og nylige politikændringer.

En DORA- eller NIS2-revisor vil fokusere på operationel robusthed, ledelsesansvarlighed og risiko. Revisoren kan spørge, hvordan adgangskontroller beskytter kritiske eller vigtige funktioner, hvordan bestyrelsen fører tilsyn med identitetsrisiko, hvordan højrisiko-logins triageres, og om adgangsfejl indgår i beslutninger om hændelsesklassificering eller rapportering.

En GDPR-fokuseret revisor vil fokusere på personoplysninger. Revisoren kan spørge, hvordan HR-, finans- eller kundedata beskyttes mod ikke-administrerede enheder, hvordan sessionskontroller reducerer uautoriseret visning, hvordan adgang begrænses til autoriserede brugere, og hvordan logfiler understøtter vurdering af brud.

En COBIT 2019-gennemgang vil se efter styringspraksis, ejerskab, målinger, gentagelighed, performanceovervågning og forbedring. En NIST-orienteret assessor vil sammenligne resultater for identitet, autentifikation, autorisation, overvågning og respons med teknisk revisionsbevis.

Enterprise Access Control Policy Access Control Policy sætter retningen for privilegeret adgang:

Administrativ adgang skal kontrolleres stramt gennem:

Fra afsnittet “Styringskrav”, politikklausul 5.4.1.

Jeres Microsoft Entra-revisionsbevis skal fuldføre den sætning operationelt. Hvilke roller er privilegerede? Hvilke kræver phishing-resistent eller stærk MFA? Hvilke er berettigede via styring af privilegeret identitet? Hvilke konti er break glass-konti? Hvilke er undtaget fra politikker? Hvem gennemgår dem? Hvor sendes alarmer hen?

Bestyrelsesmetrikker for styring af Conditional Access

Fordi NIS2 og DORA lægger vægt på ledelsesansvarlighed, bør rapportering om Conditional Access kunne læses af bestyrelsen. Undgå kun at rapportere politiknavne. Rapportér risikobillede og kontroludførelse.

Nyttige metrikker omfatter:

• Procentdel af privilegerede konti beskyttet af stærk MFA.
• Antal Conditional Access-undtagelser efter risikoniveau.
• Antal højrisiko-logins, der er blokeret, udfordret eller tilladt.
• Procentdel af adgang til følsomme applikationer, der kræver kompatible enheder.
• Antal sessioner fra ikke-administrerede enheder til regulerede applikationer.
• Tid til triage af højrisiko-loginhændelser.
• Antal Conditional Access-politikændringer i kvartalet.
• Antal udløbne, fornyede og forsinkede undtagelser.
• Dækning af logning af autentifikation, sessioner og politikændringer.
• Fejlede testcases fra kvartalsvis Conditional Access-validering.

Disse metrikker omsætter identitetskonfiguration til revisionsbevis for tilsyn. De hjælper også ledelsesorganer med at dokumentere godkendelse, gennemgang, ressourcetildeling og løbende forbedring.

Almindelige konstateringer, der skal elimineres før revisionen

Conditional Access-konstateringer skyldes typisk svag styring, ikke teknologisvigt. De mest almindelige forhold omfatter:

• Break glass-konti er undtaget, men overvåges ikke.
• Politikker navngives inkonsistent og mangler ejere.
• Følsomme applikationer mangler i regler for enhedsoverholdelse.
• Gæstebrugere og eksterne samarbejdspartnere omgår standardkontroller.
• Servicekonti og workload-identiteter styres ikke særskilt.
• Detektioner af loginrisiko triageres ikke eller kobles ikke til hændelser.
• Sessionskontroller testes aldrig fra ikke-administrerede enheder.
• Politikændringer foretages direkte i produktionsmiljø uden ændringsregistreringer.
• Undtagelser er permanente, udokumenterede eller mundtligt godkendte.
• Logfiler opbevares, men gennemgås ikke.
• Revisionsbevis mangler metadata, kildekontekst eller chain of custody.

En 2026-klar måltilstand har ledelsesgodkendt adgangsstyring, risikobaseret Conditional Access-design, eksplicit kortlægning til ISO/IEC 27001:2022 og ISO/IEC 27002:2022, dokumenteret understøttelse af NIS2, DORA og GDPR, stærk MFA efter rolle og risiko, enhedsoverholdelse for følsom adgang, sessionsbegrænsninger for ikke-administrerede kontekster, overvåget autentifikation og politikændringer, en livscyklus for undtagelser, kvartalsvis test og ledelsesrapportering.

Gør Microsoft Entra til revisionsklart bevismateriale

Jeres Conditional Access-politikker træffer allerede sikkerhedsbeslutninger hvert minut. Spørgsmålet er, om disse beslutninger er styrede, risikobaserede, overvågede og kortlagt til de forpligtelser, som jeres revisorer og tilsynsmyndigheder fokuserer på.

Start med Zenith Blueprint Zenith Blueprint, især Step 13, for at forbinde Conditional Access-politikker med risici, behandlinger, anvendelseserklæring og regulatoriske noter. Brug Zenith Controls Zenith Controls til at kortlægge adgangsstyring, sikker autentifikation, endpointets sikkerhedstilstand, logning og overvågning på tværs af ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST og COBIT 2019.

Tilpas derefter jeres interne krav til Clarysec-politikker, herunder Cloud Usage Policy-sme, Network Security Policy-sme, Logging and Monitoring Policy-sme, Audit and Compliance Monitoring Policy-sme, Application Security Requirements Policy-sme, Cloud Usage Policy, User Account and Privilege Management Policy, Remote Work Policy, Access Control Policy og Logging and Monitoring Policy.

Clarysec hjælper jer med at omdanne Microsoft Entra Conditional Access fra en samling indstillinger til et håndhæveligt, målbart og revisionsklart kontrolsystem. Download de relevante Clarysec-toolkits, anmod om en gennemgang af politikkortlægning, eller book en vurdering for at se, om jeres Conditional Access-revisionsbevis kan modstå kontrol efter ISO 27001, NIS2, DORA og GDPR.