Intune compliance policy fejl: 5 fixes der virker i drift

Conditional Access blokerer en bruger, fordi enheden står som Not Compliant – og I kan ikke få adgang til at rette fejlen. Samtidig viser rapporten en “System Account”-fejl, der får jeres compliance-score til at se værre ud, end den er. Det her indlæg giver jer 5 konkrete fixes, der typisk får jer fra rød til grøn uden at slække på sikkerheden.

• Start rigtigt: Find præcis hvilken compliance-regel der fejler, og om status er “Not evaluated” vs. “Not compliant”.
• Stop falske alarmer: Håndtér “System Account”-støj, så I rapporterer på reelle bruger-enheder.
• Fix BitLocker-status: Skil “kryptering aktiv” fra “Intune kan verificere kryptering”, og ret de typiske årsager.
• Undgå lockout: Byg en break-glass tilgang til Intune conditional access block, så IT kan komme ind og løse problemer.
• Segmentér Windows 10/11: Windows 10 efter EoS (okt 2025) kræver særhåndtering (ESU/isolering), ellers drukner I i afvigelser.

Sådan finder I roden til en Intune compliance policy fejl

Fejlsøgning går galt, når man starter i “All devices” og gætter. Gå i stedet device-first og regel-for-regel:

1. Entra ID / Intune: Find enheden og tjek Device compliance → hvilken regel fejler?
2. Skeln mellem status:
   • Not evaluated: typisk sync/registrering/agent-problem (ses ofte på Hybrid Entra ID Join).
   • Not compliant: reglen er evalueret og fejler (fx kryptering, OS-version, kodekrav).
3. Brugerimpact: Bekræft at det er Conditional Access der blokerer, og at blokeringen er bundet til “Require compliant device”.

Før → Efter #1
Før: “Vi genstarter og håber, den bliver grøn.”
Efter: “Vi identificerer én fejlet regel, retter årsagen og tvinger en målrettet sync.” Resultat: mindre nedetid og færre gentagne sager pr. enhed.

Fejltype 1: “System Account” fejler – men brugeren er compliant

Den klassiske Intune compliance system account error skaber støj i rapporter og ledelses-KPI’er. I praksis handler det ofte om en “teknisk identitet” på enheden, der ikke giver mening at måle på som en bruger-enhed.

Hvad I gør (hurtigt og sikkert)

• Rapportér på rigtige objekter: Brug device-/user-baserede rapporter og filtrér på “Enrolled by”/primær bruger, så system-konti ikke driver jeres tal.
• Validér impact: Hvis brugeren kan få adgang fra samme enhed, er det ofte rapporteringsstøj – ikke en reel blokering.
• Frys ikke hele miljøet: Undgå at ændre compliance-regler for at “få grønt” på system-kontoen. Det flytter risikoen til rigtige enheder.

Fejltype 2: BitLocker er aktivt, men Intune siger Not Compliant

“Fix BitLocker compliance Intune” er et top-problem, fordi Intune kan markere enheden som ikke-compliant, selvom brugeren ser BitLocker slået til. Typiske årsager er, at enheden mangler en genstart efter kryptering, eller at attestation/validering ikke er på plads (Microsoft har beskrevet kendte udfordringer med BitLocker-rapportering i Tech Community).

Tjek de her 6 punkter på enheden

1. Afvent/forcér genstart: Hvis kryptering netop er aktiveret, kan status hænge til efter reboot.
2. Recovery key escrow: Bekræft at recovery key ligger i Entra ID/Intune (ellers får I drift- og audit-problemer).
3. TPM-status: Kryptering kan være aktiv, men TPM/attestation kan fejle, så compliance-check ikke “stoler” på signalet.
4. Policy-konflikt: Hvis I både har compliance-regel og konfigurationsprofil der rammer samme setting, kan I ende i konflikt (fx 65001 i Intune).
5. Hardware-betingelser: Nogle enheder kan rapportere ufuldstændig sikkerhedsattestation, hvis platform-krav ikke er opfyldt.
6. Synkronisering: Kør en manuel Sync fra Company Portal/Settings, og giv status tid til at opdatere.

Fejltype 3: Windows 10-enheder trækker jer ned i 2026

Windows 10 compliance 2026 er ikke bare en “pæn rapport”. Windows 10 er End of Support (okt 2025). Enheder uden relevant forlænget support/plan (fx ESU) kan give jer både compliance-støj og en reel sikkerhedsrisiko – og i nogle rapporter kan de fremstå som højere risiko.

Beslutningsregel: isolér eller opgradér

• Hvis enheden kan opgraderes: Prioritér Windows 11, og brug separate compliance policies pr. OS-version, så I ikke straffer Win11 med Win10-undtagelser.
• Hvis enheden ikke kan opgraderes: Segmentér den i en “Legacy/Win10” gruppe og begræns adgang (fx kun VDI/kun web, ingen download), indtil udskiftning er gennemført.
• Hvis enheden er “glemt”: Identificér inaktive/ikke-synkroniserede enheder og ryd op. De skævvrider rapporter og øger angrebsfladen.

Før → Efter #2
Før: Én compliance policy til alle Windows-enheder, og Win10-undtagelser “smitter” Win11-kravene.
Efter: Separate policies og CA-regler pr. segment (Win11 standard, Win10 legacy). Resultat: færre falske “Not compliant” og klarere risikobillede til NIS2-dokumentation.

Fejltype 4: Grace period og “immediately non-compliant” skaber nedetid

Hvis I har sat “Mark device non-compliant immediately”, kan små driftshændelser (patch der afventer genstart, midlertidig Defender-signal-forsinkelse) blive til en hård blokering. Resultatet er, at brugeren mister adgang, før I kan nå at rette.

Praktisk opsætning der minimerer nedetid

• Sæt en realistisk grace period på regler, hvor brugerens handling (genstart) ofte er sidste step.
• Skærp for det kritiske: Brug “immediately” på signaler med høj sikkerhedsværdi (fx jailbreak/root, vedvarende manglende kryptering).
• Test med pilot: Udrul ændringer til en pilotgruppe og mål antal CA-blokeringer før/efter.

Tjekliste: 12-minutters triage når en bruger er blokeret

Brug den her tjekliste, når supporten får sagen “jeg kan ikke logge på”. Den er lavet til drift, ikke til projekt.

Trin	Hvad I tjekker	Hvad I leder efter	Næste handling
1	Conditional Access sign-in	Policy der blokerer: “Require compliant device”	Bekræft at blokering er compliance-baseret, ikke MFA/risk
2	Device compliance status	Not evaluated vs Not compliant	Ved “Not evaluated”: fokus på enrollment/sync
3	Compliance rule details	Præcis regel (kryptering, OS, password, firewall)	Ret kun den fejlede årsag
4	Conflict/fejlkoder	65001 (policy conflict) eller lignende	Fjern overlap mellem compliance og konfiguration
5	BitLocker/FileVault key escrow	Nøgle mangler / ikke roteret / ikke uploadet	Udbedr escrow og resync
6	Sync og timing	Status hænger efter ændring	Manuel sync + planlagt genstart, vent på evalueringsloop

Fejltype 5: Defender/MDE signal og tredjeparts AV giver forsinket status

Når compliance afhænger af trussels-/risikosignaler, kan der være forsinkelse mellem at Microsoft Defender for Endpoint (eller tredjeparts agent) opdager/afklarer en risiko, og at Intune opdaterer device compliance. I praksis ligner det “enheden er rask, men Intune blokerer stadig”.

Driftsregler der virker

• Byg en kort “karantæne-buffer” via grace period eller en separat CA-politik, så brugeren ikke rammes hårdt af midlertidige signal-forsinkelser.
• Undgå dobbelte AV-signaler uden plan: tredjeparts agenter kan forsinke “clean”-rapportering.
• Dokumentér jeres beslutning i jeres compliance-materiale: hvad udløser blokering, og hvad udløser kun overvågning.

Sådan undgår I “Conditional Access loopet” (lockout når I skal rette)

Hvis alle admins også rammes af “Require compliant device”, kan I låse jer selv ude af portaler og supportværktøjer, netop når compliance fejler.

Minimums-sikring

• Break-glass konto: En nød-adminkonto med stærk beskyttelse og kontrolleret undtagelse fra den mest aggressive CA-regel.
• Admin-access fra “kendt ren” platform: Dedikér en administrativ enhed/VDI, der altid holdes compliant.
• Scope CA korrekt: Undtag Intune/Entra administrationsapps fra de mest drifts-følsomme krav, eller brug separate policies pr. rolle.

FAQ: Intune compliance policy fejl i praksis

Hvorfor får vi en Intune compliance policy fejl, når intet er ændret?

Det sker typisk ved timing: opdateringer afventer genstart, status er ikke synkroniseret, eller et sikkerhedssignal (fx Defender) er midlertidigt forsinket. Tjek først om status er “Not evaluated” (sync/enrollment) eller “Not compliant” (en konkret regel).

Hvad betyder fejlkode 65001 i Intune compliance?

65001 ses ofte ved konflikt mellem politikker, hvor to policies forsøger at håndhæve samme krav (fx password-krav i både compliance policy og et konfigurationsprofil). Løs ved at samle ansvaret ét sted: enten compliance måler, mens konfigurationen sætter – men undgå overlap på samme parameter.

Hvordan håndterer vi “System Account” compliance error uden at ignorere sikkerhed?

Filtrér rapportering og opfølgning, så I måler på bruger-relevante enheder og primære brugere. Ændr ikke compliance-krav bare for at gøre system-kontoen grøn. Brug i stedet device-level fejldetaljer til at vurdere, om der er reel adgangsrisiko.

Hvordan tjekker vi compliance status på en PC hurtigt?

Start med brugerens sign-in log (hvilken Conditional Access politik blokerer), gå derefter til enheden i Intune og se hvilke compliance rules der fejler. Afslut med manuel sync fra enheden. Det er hurtigere end at lede i “All policies”.

BitLocker er slået til – hvorfor står den stadig som Not Compliant?

De typiske årsager er: en genstart mangler efter aktivering, recovery key er ikke escrowned korrekt, TPM/attestation kan ikke verificeres, eller der er policy-konflikt. Ret årsagen, sync, og vent på næste evalueringsloop før I ændrer CA.

Skal vi blokere Windows 10-enheder i 2026?

Som tommelfingerregel: ja, begræns dem kraftigt, medmindre I har en dokumenteret plan (fx ESU og tidsplan for udfasning). Segmentér Win10 i en legacy-gruppe med strammere adgang og tydelig udfasningsdato, så Win11 ikke “arver” Win10-undtagelser.

Hvordan undgår vi at Conditional Access blokerer os, mens vi fejlsøger?

Opsæt break-glass konto, hold mindst én administrativ enhed permanent compliant, og del CA-politikker op efter roller og apps. Målet er, at IT altid kan komme ind i Intune/Entra og rette compliance-fejl uden at slække på brugernes adgangskrav.

Afslutning: 7 konkrete skridt I kan tage i dag

1. Kortlæg jeres top-3 compliance-regler, der oftest fejler (kryptering, OS, password/lock).
2. Segmentér enheder i Windows 11, Windows 10 legacy og macOS/Linux – og giv dem separate compliance policies.
3. Ryd op i policy-overlap, især hvor I ser konflikt (fx 65001).
4. Indfør grace period på regler, der typisk kræver genstart eller har signal-forsinkelse.
5. Byg break-glass og en dedikeret admin-platform for at undgå lockout.
6. Validér BitLocker/FileVault key escrow på et udsnit af enheder, og ret de enheder der mangler nøgler.
7. Lav en drifts-playbook: “Triage på 12 minutter” + hvem gør hvad ved Intune not compliant incidents.