Mange virksomheder siger, at de har Microsoft Intune på plads. I praksis betyder det ofte, at nogle Windows-enheder er enrollet, et par compliance policies findes, og at der måske ligger en håndfuld konfigurationsprofiler, som ingen helt er sikre på, hvem der ejer. Det er ikke det samme som moden endpoint management.
Et velfungerende Intune-setup er ikke bare en samling policies. Det er en driftsmodel, hvor enheder bliver onboardet ensartet, vurderet mod en tydelig sikkerhedsbaseline, koblet til adgangskontrollen og håndteret ordentligt gennem hele deres levetid. Når den model er på plads, bliver Intune en reel sikkerheds- og driftsplatform. Når den ikke er det, bliver Intune let endnu et administrationslag, der kun delvist leverer.
Microsoft beskriver Intune som en cloudbaseret endpoint management-tjeneste i den officielle introduktion på Microsoft Learn. Det er korrekt, men for de fleste organisationer er det vigtigere at forstå, hvad Intune skal binde sammen: enhedsidentitet, sikkerhedskrav, brugeroplevelse og adgang til data.
Intune er mest værdifuld, når den bliver en del af adgangsmodellen
Det mest modne Intune-setup er sjældent det med flest policies. Det er det setup, hvor der er en tydelig kobling mellem enhedens tilstand og det, brugeren må tilgå. Hvis en bærbar computer er korrekt enrollet, krypteret, opdateret og beskyttet, kan den bruges til at tilgå Microsoft 365, interne SaaS-løsninger og administrative funktioner. Hvis den ikke lever op til kravene, bliver adgangen begrænset eller afvist.
Det er derfor, endpoint management ikke bør behandles som et isoleret infrastrukturspor. Intune giver først fuld forretningsværdi, når det spiller sammen med Microsoft Entra Conditional Access. Microsofts dokumentation om Conditional Access og Intune beskriver netop den sammenhæng: enhedens compliance-status bliver et signal i adgangsbeslutningen.
Det er også her, forskellen mellem et delvist og et modent setup bliver tydelig. I et delvist setup bruges Intune til at skubbe lidt konfiguration ud. I et modent setup bruges Intune til at afgøre, hvilke enheder organisationen faktisk har tillid til.
Compliance er ikke det samme som konfiguration
En af de mest almindelige misforståelser er, at compliance policies og konfigurationsprofiler er det samme. Det er de ikke.
Konfiguration handler om, hvad en enhed skal have sat op. Det kan være BitLocker, firewall, password-krav, Defender-indstillinger eller browserkonfiguration. Compliance handler derimod om, hvilke minimumskrav enheden skal leve op til for at blive betragtet som acceptabel. Microsoft gennemgår principperne i Get started with compliance policies.
Den skelnen er vigtig. Hvis en organisation kun deployer konfiguration, men ikke definerer tydelige compliance-krav, bliver det svært at bruge enhedstilstanden operationelt. Så ved man måske, hvad man forsøgte at konfigurere, men ikke om enheden reelt lever op til et minimumsniveau, der kan bruges i adgangsmodellen.
En god compliance-baseline er normalt enkel og håndhævelig:
- Kryptering skal være aktiv.
- Operativsystemet skal være understøttet og over en minimumsversion.
- Enheden må ikke være rooted eller jailbroken.
- Antivirus og centrale sikkerhedsfunktioner skal være aktive.
- Password- eller PIN-krav skal være opfyldt.
Det lyder banalt, men det er netop pointen. Compliance skal være tydelig nok til at kunne bruges i Conditional Access og stabil nok til, at driftsteamet kan forklare brugerne, hvorfor en enhed blev markeret som ikke-kompatibel.
Sikkerhedsbaselines er der, hvor standarden bliver konkret
Mange Intune-miljøer lider under det samme problem: politikker er vokset frem over tid, ofte som svar på enkeltkrav, audits eller specifikke incidents. Resultatet er en uens policy-portefølje, hvor overlap, modstridende indstillinger og gamle profiler skaber større kompleksitet end sikkerhed.
Microsofts security baselines i Intune er ikke perfekte facitlister, men de er et stærkt udgangspunkt. De giver et samlet, dokumenteret minimum for blandt andet Windows, Microsoft Edge og Defender, så organisationen ikke starter fra nul eller bygger hele sin sikkerhedsmodel på enkeltstående profiler.
Et modent setup bruger baselines som fundament og tilpasser kun der, hvor der er en konkret grund. Det kan være en applikation, der kræver en specifik browserindstilling, eller et driftskrav, der nødvendiggør en undtagelse. Men udgangspunktet er stadig en samlet baseline, ikke en akkumulering af historiske enkeltbeslutninger.
I praksis bør en baseline for Windows-enheder typisk omfatte:
- BitLocker med dokumenteret key escrow.
- Defender Antivirus og relevante endpoint security-indstillinger.
- Firewall aktiveret.
- Kontrol med lokale administratorrettigheder.
- Browser-hærdning og standarder for phishing-beskyttelse.
- Opdateringsstyring via update rings og en tydelig supporteret version.
Det er ikke nødvendigvis avanceret. Det modne ligger i konsistensen. Hvis 90 procent af enhederne ligner hinanden sikkerhedsmæssigt, bliver support lettere, risikovurdering mere troværdig og fejlsøgning hurtigere.
Enrollment skal passe til ejerskab og platform
Enrollment er ofte der, hvor Intune-projekter mister fart. Ikke fordi teknologien er svær, men fordi organisationen ikke har afgjort, hvilke enhedstyper den faktisk vil understøtte, og hvordan forskellige ejerskabsmodeller skal håndteres.
For Windows er Windows Autopilot normalt den rigtige retning for virksomhedsejede enheder. Det giver en mere standardiseret klargøring, mindre manuel indsats og en bedre kobling mellem indkøb, levering og onboarding. Hvis en ny medarbejder skal kunne modtage en pc direkte fra leverandøren og gennemføre en kontrolleret førstegangsopsætning, er det et klart modenhedstegn.
For mobile enheder er billedet mere nuanceret. Virksomhedsejede telefoner bør typisk enrols fuldt og styres som managed devices. Personlige enheder bør ikke automatisk behandles på samme måde. Her er App Protection Policies ofte et bedre svar end fuld device enrollment, fordi de beskytter virksomhedsdata i apps som Outlook og Teams uden at lægge hele den private enhed ind under samme styringsmodel.
Det centrale er ikke at tvinge alt ind i samme skabelon. Det centrale er at have en bevidst model:
- Hvilke platforme understøttes?
- Hvilke enheder er virksomhedsejede?
- Hvilke scenarier accepteres som BYOD?
- Hvornår kræver vi fuld enrollment, og hvornår er app-beskyttelse tilstrækkelig?
Organisationer, der ikke tager de beslutninger tidligt, ender ofte med et Intune-miljø, hvor policies er teknisk mulige, men operationelt svage.
Device lifecycle er der, hvor modenheden bliver synlig
Et af de klareste tegn på et umodent setup er, at Intune kun tænkes ind ved onboarding. Enheder enrols, får nogle profiler og bliver derefter mere eller mindre overladt til sig selv. Det er utilstrækkeligt.
En moden endpoint-model beskriver hele livscyklussen:
- Indkøb og registrering af virksomhedsejede enheder.
- Standardiseret klargøring og enrollment.
- Løbende patching, compliance-opfølgning og support.
- Rolle- eller afdelingsskift, hvor tildeling og politikker justeres.
- Reassignment, retirement eller wipe ved exit eller udskiftning.
Microsoft dokumenterer de vigtigste handlinger for retire, wipe og andre device actions. De funktioner er ikke bare tekniske knapper. De er en del af den driftsdisciplin, der afgør, om gamle enheder fortsat står som aktive, om data bliver fjernet korrekt, og om lagerførte maskiner kan genbruges uden at bringe sikkerhed eller supportabilitet i fare.
Mange virksomheder undervurderer også betydningen af ownership-data, gruppetildeling og navngivningsstandarder. Men uden de elementer bliver det svært at svare på simple driftsmæssige spørgsmål: Hvem ejer enheden, hvilken baseline skal den have, og hvorfor ligger den i den forkerte policy-ring?
Koblingen til Conditional Access er ikke valgfri
Hvis Intune ikke er koblet til Conditional Access, bliver meget af den strategiske værdi ikke realiseret. Så har man måske bedre styring af enheder, men ikke en reel mekanisme til at bruge den styring i adgangsbeslutninger.
Den mest almindelige og fornuftige model er, at udvalgte ressourcer kræver en compliant enhed. Det gælder typisk Microsoft 365, administrative portaler og applikationer med følsomme data. For BYOD-scenarier kan kravene være anderledes, så brugeren eksempelvis må tilgå data gennem beskyttede mobilapps, men ikke via en fuldt åben browser-session.
Det vigtige er at designe adgangsmodellen i lag. Ikke alle workloads behøver samme krav, og ikke alle brugere skal behandles ens. Men der skal være en tydelig sammenhæng mellem risikoniveau og enhedskrav. Ellers bliver compliance i praksis kun et rapporteringsfelt.
Et andet modenhedstegn er, at Conditional Access indføres kontrolleret. Report-only, pilotgrupper og tydelige break-glass-undtagelser er ikke bureaukrati. Det er det, der forhindrer, at en ellers god sikkerhedsintention udvikler sig til et selvskabt driftsproblem.
De typiske fejl vi ser igen og igen
Der er et mønster i de Intune-miljøer, der kun delvist leverer.
Fejl 1: For mange policies for tidligt. Teams starter med at løse alle tænkelige krav på én gang. Resultatet bliver overlap, uklare precedensregler og et miljø, som ingen trygt kan ændre senere.
Fejl 2: Ingen tydelig baseline. Der findes mange profiler, men ingen kan sige, hvad organisationens minimumsstandard faktisk er.
Fejl 3: Enrollment uden driftsmodel. Enheder kommer ind i Intune, men der er ingen fast proces for patching, review af non-compliant devices, offboarding eller genudlevering.
Fejl 4: Ingen reel kobling til adgang. Compliance bliver målt, men bruges ikke til noget. Dermed forsvinder en stor del af den sikkerhedsmæssige effekt.
Fejl 5: BYOD behandles som et irritationsmoment i stedet for et designvalg. Så ender organisationen enten med at acceptere for lidt kontrol eller med at skubbe brugerne over i modstand og workarounds.
Det væsentlige er, at ingen af disse fejl skyldes, at Intune er det forkerte værktøj. De skyldes, at der mangler en operationel model omkring værktøjet.
En praktisk modenhedsvej for de fleste organisationer
For langt de fleste mellemstore virksomheder giver det mening at arbejde i fire trin.
Trin 1: Få styr på platform, ejerskab og inventory
Først skal I vide, hvilke enheder I faktisk har, hvilke platforme I vil understøtte, og hvilke enheder der er corporate versus personal. Uden det bliver resten upræcist.
Trin 2: Etabler baseline og compliance
Definér en fælles minimumsstandard, ryd op i gamle profiler og gør compliance tydelig nok til at kunne bruges aktivt. Det er her, Intune går fra administration til styring.
Trin 3: Knyt enhedstilstand til adgang
Indfør Conditional Access-kontroller, der afspejler risiko og dataværdi. Start med de vigtigste workloads og byg ud derfra.
Trin 4: Drift, måling og løbende forbedring
Når fundamentet virker, flytter fokus til operating model: review af fejlende enheder, patch-compliance, hardwarefornyelse, onboarding-kvalitet og styring af undtagelser.
Det er en mere realistisk vej end at forsøge at bygge et perfekt enterprise-setup fra dag ét. Modenhed i endpoint management kommer normalt fra disciplin og iteration, ikke fra en enkelt stor implementering.
En realistisk operating model ser mere jordnær ud, end mange tror
Der er en tendens til at tale om endpoint management som et rent teknisk projekt. I virkeligheden virker det bedst som et fast driftsområde med klare roller og en enkel rytme.
En realistisk model i en mellemstor organisation kan se sådan ud:
- En platformejer har ansvar for Intune-design, baselines og policy-styring.
- Service desk eller drift håndterer daglig opfølgning på enrollment-fejl, non-compliant enheder og standardsupport.
- Sikkerhedsansvarlig eller sikkerhedsfunktion godkender baseline, adgangskrav og undtagelser.
- HR og IT er koblet sammen omkring joiner-mover-leaver-processen.
Derudover bør der være en fast kadence, eksempelvis månedligt, hvor man gennemgår:
- Enheder uden for compliance.
- Enheder der ikke har checket ind i længere tid.
- Nye undtagelser og om de stadig er gyldige.
- Patching-status og versionsspredning.
- Enheder på vej ud af support eller hardwareliv.
Det lyder ikke dramatisk, og det er netop styrken. God endpoint management er ofte kedelig på den rigtige måde. Den reducerer variation, overraskelser og tvivl i det daglige.
Hvad det betyder for jeres virksomhed
Det afgørende spørgsmål er ikke, om I har Intune. Det er, om Intune faktisk bruges til at skabe et mere sikkert og mere driftsstabilt endpoint-miljø. Hvis compliance ikke er tydelig, hvis baseline er uklar, hvis enrollment er usammenhængende, og hvis Conditional Access ikke bruger enhedssignalet aktivt, så fås kun en del af gevinsten.
Et modent Intune-setup giver noget meget konkret tilbage: hurtigere onboarding, mere ens enheder, færre lokale særtilfælde, bedre databeskyttelse og en adgangsmodel, der i højere grad skelner mellem betroede og ikke-betroede enheder. Det er den forskel, der kan mærkes i både sikkerhed og drift.
Hos inciro hjælper vi med at definere baseline, rydde op i policy-landskabet, designe enrollmentmodellen og koble Intune ordentligt til Conditional Access, så endpoint management bliver en del af jeres samlede sikkerhedsarkitektur og ikke bare et administrationsværktøj.
Book en strategisk samtale - vi gennemgår jeres nuværende Intune-setup og viser, hvad der skal til for at løfte det fra delvis styring til en moden endpoint-model.