MDM og Intune som datakilde: inventar, compliance og fjernsletning

Forside › iPhone-forensik · Gennemgået oktober 2026 · Af John Nielsen

Et MDM-system som Microsoft Intune indeholder ikke telefonens beskeder eller filer. Men det indeholder noget, der ofte er lige så vigtigt i en sag: en præcis beskrivelse af enheden, dens tilstand over tid og en auditlog over de handlinger, administratorer har udført på den. Hvornår blev telefonen tilmeldt, hvem var primær bruger, hvornår tjekkede den sidst ind, og hvem sendte en sletningskommando? De spørgsmål kan MDM-data ofte besvare, hvis de sikres, før enheden fjernes fra systemet.

Haster det? Slettes enheden fra Intune, kan dens handlingshistorik forsvinde med den, så eksporten skal ske før oprydningen. Kontakt os via akut forensisk sikring; hastesager koster ekstra.

Hvad virksomheden kan og ikke kan bruge MDM til, står på bevissikring-digitalt.dk. Den juridiske side af en sletning, der allerede er sket, er behandlet på digital-bevissikring.dk. Her ser vi på dataene som teknisk kilde med Intune som eksempel; andre MDM-systemer har tilsvarende kategorier under andre navne.

Hvad der findes i systemet

• Enhedsinventar · Navn, model, producent, serienummer, IMEI, styresystem og version, ejerskab (firma eller privat)
• Tilmelding · Tidspunkt, tilmeldingsmetode, primær bruger, tilmeldingsprofil
• Seneste kontakt · Tidspunkt for seneste synkronisering med tjenesten
• Compliance · Om enheden opfyldte politikkerne, og hvilke krav der fejlede
• Konfiguration · Tildelte profiler, politikker og deres status
• Apps · Udrullede apps og deres installationsstatus; på firmaejede enheder ofte en liste over fundne apps
• App-beskyttelse · Status for beskyttede apps på private enheder uden fuld tilmelding
• Auditlog · Administratorers handlinger: hvem, hvad, hvornår og mod hvilken enhed

Hvad der faktisk er tilgængeligt, afhænger af platform, ejerskab og tilmeldingstype. En privat telefon med kun app-beskyttelse giver langt færre data end en firmaejet, fuldt administreret enhed. Microsofts egen oversigt over dataindsamling angiver fx, at en liste over installerede apps kun indsamles, når enheden er markeret som firmaejet eller en særlig app-funktion er slået til, og at ren app-beskyttelse ikke giver serienummer eller IMEI. Microsoft oplyser også, at Intune aldrig indsamler opkalds- og browserhistorik, private mails, sms, kontakter, kalender eller billeder.

Auditloggen over fjernhandlinger

Den vigtigste kilde i mange sager er auditloggen. Den registrerer administrative handlinger som sletning, tilbagetrækning (hvor kun firmadata fjernes), nulstilling af kode, låsning, ændring af primær bruger og sletning af enhedsobjektet. Hver post har tidspunkt, handlingstype, den konto, der udførte handlingen, målet og resultatet. Selve kommandoens udførelse på enheden er en separat status: en sletning kan være sendt, men ikke udført, fordi telefonen var slukket eller uden forbindelse.

Det skelner mellem tre ting, som ofte blandes sammen i en sag:

1. Kommandoen blev sendt: fremgår af auditloggen med initierende konto.
2. Kommandoen blev modtaget og udført: fremgår af enhedens handlingsstatus, hvis den stadig findes.
3. Enheden blev slettet af brugeren selv: fremgår ikke af MDM-auditloggen, men eventuelt af, at enheden holdt op med at tjekke ind, eller af en ny tilmelding.

Auditloggens opbevaring er begrænset. Ifølge Microsoft kan auditering ikke slås fra, og på tidspunktet for gennemgangen (oktober 2026) kan portalen filtrere op til et år tilbage, mens revisionshændelser kan hentes via Graph for en længere periode. Ældre poster kræver, at loggen løbende er sendt til et eget logarkiv. Når enheden slettes fra Intune, kan dens handlingshistorik forsvinde med den, så eksportér, før der ryddes op.

Sikring

1. Stop automatiske regler: Tjek, om der er oprydningsregler, der fjerner inaktive enheder efter et antal dage, og om fratrædelsesprocessen udløser sletning. Notér indstillingerne, og sæt dem i bero for de relevante enheder.
2. Eksportér enhedsoplysningerne: Hele enhedsposten med alle felter, ikke kun det, portalen viser i oversigten.
3. Eksportér auditloggen for den relevante periode, filtreret på enheden og brugeren, men gem også en bredere eksport for perioden.
4. Eksportér compliance- og konfigurationsstatus og listen over apps.
5. Hash eksportfilerne, og notér, hvem der eksporterede, med hvilken konto og hvornår.

Portalens eksportfunktioner er praktiske, men kan udelade felter eller forkorte værdier. Eksport via Microsoft Graph giver de fulde objekter i JSON og kan gentages med samme forespørgsel. Dokumentér kommandoerne og versionerne; se Eksport via Microsoft Graph og PowerShell.

Sammenhæng med Entra ID

En tilmeldt enhed findes også som enhedsobjekt i Entra ID, og loginloggen viser, hvilken enhed et login kom fra, og om den var compliant. Det giver mulighed for at koble en konkret telefon til konkrete logins. Omvendt kan en enhed, der er registreret i Entra ID uden at være tilmeldt MDM, være et tegn på adgang uden om virksomhedens kontrol; se Registrerede enheder i Entra ID som vedvarende adgang og Entra ID-loginlogs.

Arbejdsprofiler og brugertilmelding

På private telefoner bruges ofte en adskilt arbejdsdel: en arbejdsprofil på Android eller brugertilmelding på iPhone. Teknisk betyder det, at arbejdsapps og deres data ligger i en adskilt beholder med egen kryptering, og at MDM kun ser og styrer den del. Inventaret er tilsvarende begrænset. Microsoft angiver for brugertilmelding på iPhone, at Intune ikke kan se serienummer, IMEI eller private apps, og for en privatejet Android-telefon med arbejdsprofil ser Intune kun arbejdsprofilens apps.

For sikringen har det to konsekvenser. En tilbagetrækning fjerner kun arbejdsdelen, så private data bliver liggende, men det gør arbejdsdata også utilgængelige på telefonen bagefter. Og et eventuelt udtræk af telefonen skal afgrænses til arbejdsdelen, hvilket kræver et værktøj og en metode, der kan skelne. Det er beskrevet i Firmatelefonen i en ansættelsessag: afgrænset og selektivt udtræk.

Andre MDM-systemer

Jamf, Workspace ONE, Google Endpoint Management og andre systemer har de samme grundkategorier: inventar, tilmelding, seneste kontakt, compliance og en auditlog. Felternes navne, opbevaringstider og eksportformater er forskellige. Uanset system er fremgangsmåden den samme: Beskriv systemets version og indstillinger, eksportér de fulde objekter i det mest detaljerede format, systemet tilbyder, og hash dem. Hvis eksportfunktionen er begrænset, kan skærmbilleder supplere, men de skal tages systematisk med synlig dato og klokkeslæt og en beskrivelse af, hvor i systemet de er taget.

For MSP’er, der administrerer flere kunders MDM, er det også vigtigt at dokumentere, hvilken kunde og hvilken tenant eksporten kommer fra, og at leverandørens egne administratorhandlinger fremgår af samme auditlog. Rammer hændelsen flere kunder på én gang, se Hændelse hos flere kunder på én gang. Henvender MSP’en sig på kundens vegne, se Når MSP’en henvender sig på kundens vegne.

Typiske fejlkilder

• Seneste kontakt er ikke seneste brug: Tidspunktet viser synkronisering med tjenesten, ikke at nogen brugte telefonen.
• Primær bruger kan være forkert: Feltet sættes ved tilmelding og opdateres ikke altid, når en telefon skifter hænder.
• Fundne apps er et øjebliksbillede: Listen afspejler seneste indsamling og viser ikke, hvornår en app blev fjernet.
• Serviceprincipaler og automatisering: Handlinger kan være udført af et script eller en integration, ikke en person. Auditloggen viser kontoen, men det kræver opklaring at finde ud af, hvad der står bag.
• Tidszoner: Portalen viser lokal tid, eksporter typisk UTC.
• Gentilmelding: En nulstillet og gentilmeldt telefon kan få et nyt enhedsobjekt, så historikken ligger på det gamle. Det tilsvarende for computere er beskrevet i Nulstil denne pc og Autopilot.

Hvad MDM-data kan og ikke kan bevise

MDM-data kan vise enhedens identitet, hvem den var knyttet til, hvornår den var i kontakt med virksomhedens systemer, og hvilke administrative handlinger der blev udført på den. De kan vise, at en sletning blev sendt fra en bestemt konto. De kan ikke vise indholdet af telefonen, og de kan ikke alene vise, hvem der fysisk havde den. Er telefonen allerede slettet, er MDM-data ofte udgangspunktet for at finde andre kilder; se Den nulstillede firmatelefon.

Dokumentation

Rapporten bør indeholde tenantens MDM-indstillinger for oprydning og sletning på sikringstidspunktet, de eksporterede objekter med hashværdier, de auditposter, konklusionerne bygger på, og en forklaring af forskellen mellem sendt og udført kommando, hvor det er relevant. Er den konto, der sendte en kommando, en delt administratorkonto, skal det stå som en begrænsning for attributionen. Er der efter sikringen udført nye handlinger på enheden, fx en tilbagetrækning efter aftale med medarbejderen, eksporteres auditloggen igen, så hele forløbet fra sikring til afslutning er dokumenteret i samme kilde.

Kilder og versioner

• Microsoft Learn: Audit changes and events in Microsoft Intune
• Microsoft Learn: Data collection in Intune
• Microsoft Learn: Overview of Apple User Enrollment in Intune
• Microsoft Graph: List auditEvents (Intune)

Senest gennemgået: oktober 2026.

Næste skridt

• Slettede beskeder på telefonen: hvad kan realistisk gendannes?
• WhatsApp teknisk: lokal database, backup og hvad en chat-eksport mangler
• iCloud teknisk: datakategorier og lovlig eksport

Del af: iPhone-forensik

Læs også: Android-backup og Google-kontoens sikkerhedskopi · Firmatelefonen i en ansættelsessag: afgrænset og selektivt udtræk

→ Mobilforensik i civile sager · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT