Registrerede enheder i Entra ID som vedvarende adgang

Forside › Microsoft 365 og Entra ID: logkilderne · Gennemgået oktober 2026 · Af John Nielsen

En enhed, der er registreret i Microsoft Entra ID, er mere end en post i en liste. Registreringen giver enheden en identitet, der kan bruges til at få langtlevende tokens og til at opfylde politikker, der kræver en kendt enhed. Har en angriber fået registreret sin egen enhed under en kompromitteret konto, kan adgangen derfor overleve både et skift af adgangskode og en tilbagekaldelse af sessioner, hvis enheden ikke også fjernes. For undersøgelsen er enhedsobjektet og dets historik et selvstændigt spor, der skal sikres, før der ryddes op.

Den generelle forklaring på, hvorfor adgang kan fortsætte efter et kodeskift, findes i Sessioner, tokens og loginlogs. Her går vi i dybden med enhederne.

Tre måder at knytte en enhed på

Registreret · Typisk brug: Private enheder og mobiltelefoner, der får adgang til arbejdsdata · Kendetegn i objektet: Tillidstype for arbejdspladstilknytning
Tilsluttet (joined) · Typisk brug: Firmaets computere, der logger ind med Entra-konti · Kendetegn i objektet: Tillidstype for Entra-tilslutning
Hybrid-tilsluttet · Typisk brug: Computere i et lokalt domæne, der også er kendt i Entra ID · Kendetegn i objektet: Tillidstype for serverbaseret tilslutning

I Graph hedder værdierne for egenskaben trustType Workplace, AzureAd og ServerAd, mens portalen viser dem som Microsoft Entra registered, Microsoft Entra joined og Microsoft Entra hybrid joined.

Angreb, der bruger enhedsregistrering, benytter typisk den første type, fordi en almindelig bruger som standard kan registrere enheder. Om det kræver totrinsgodkendelse, hvor mange enheder en bruger må have, og om registrering overhovedet er tilladt, styres af tenantens enhedsindstillinger og af politikker for betinget adgang. Indstillingerne i perioden skal dokumenteres, fordi de afgør, hvor let registreringen var.

Hvorfor en enhed giver vedvarende adgang

Når en enhed registreres, får den egne nøgler, og en bruger, der logger ind fra den, kan få et særligt opdateringstoken knyttet til enheden. Det bruges til at logge ind i andre tjenester uden ny godkendelse og fornyes løbende, så længe enheden er aktiv. Ifølge Microsoft bliver tokenet ugyldigt, når brugeren eller enheden slettes eller deaktiveres, og ved skift af adgangskode, hvis tokenet blev udstedt på grundlag af adgangskoden. Blev det udstedt på anden vis, fx med Windows Hello eller en sikkerhedsnøgle, er et skift af adgangskode ikke nok, og en enhed, der ikke er deaktiveret eller slettet, kan være en vej tilbage. Kræver politikkerne en registreret eller kendt enhed for adgang, kan angriberens enhed desuden opfylde kravet.

Spor i enhedsobjektet

Enhedsobjektet indeholder blandt andet visningsnavn, enheds-id, styresystem og version, tillidstype, registreringstidspunkt, omtrentligt tidspunkt for seneste login, ejere og registrerede brugere, og om enheden er administreret og compliant. Felterne sættes delvist af enheden selv, så et visningsnavn og en styresystemversion kan være vilkårlige. Registreringstidspunktet og koblingen til brugeren sættes derimod af tjenesten.

Mistænkelige kendetegn:

Registreringstidspunkt kort efter et mistænkeligt login.
Et styresystem, brugeren ikke bruger, fx en Windows-enhed hos en bruger med kun Mac og iPhone.
Et generisk eller standardagtigt navn.
Ikke administreret og ikke compliant, selv om virksomhedens øvrige enheder er det.
Flere enheder registreret samme dag.

Spor i auditloggen

Registrering, tilføjelse af ejere og brugere, opdatering og sletning af enheder registreres i auditloggen. Posten for registrering indeholder typisk den initierende bruger og oplysninger, der kan kobles til loginforløbet. Ved gennemgangen hed aktiviteterne bl.a. Register device, Add registered owner to device, Add registered users to device, Update device og Delete device. Opbevaringen er kort, så en enhed, der blev registreret for længe siden, kan stadig findes som objekt, men uden revisionspost.

Spor i loginloggen

Registreringen sker ved et login mod enhedsregistreringstjenesten, som optræder som en selvstændig app i loginloggen. Det login har IP-adresse, klient og godkendelsesdetaljer, som kan sammenholdes med det forudgående mistænkelige login. Efterfølgende logins fra den registrerede enhed bærer enhedens id i enhedsoplysningerne. Det gør det muligt at opgøre, hvilke tjenester enheden har haft adgang til, og hvornår; se Entra ID-loginlogs.

Sammenhæng med MDM og godkendelsesmetoder

Er automatisk tilmelding til MDM slået til, kan en registreret enhed også have forsøgt at tilmelde sig. MDM-systemets data kan derfor bekræfte eller afkræfte, at enheden er virksomhedens; se MDM og Intune som datakilde. En ny godkendelsesmetode, der er registreret i samme tidsrum, er et beslægtet spor og bør undersøges i samme omgang; se MFA-ændringer og betinget adgang i Entra ID-loggene.

Sikring før fjernelse

Eksportér alle enhedsobjekter for brugeren med alle egenskaber, ejere og registrerede brugere.
Eksportér auditloggens enhedshændelser for perioden, også for andre brugere, da angriberen kan have brugt flere konti.
Eksportér loginlogs for enhedsregistreringstjenesten og alle logins med de mistænkelige enheds-id’er.
Dokumentér tenantens enhedsindstillinger og relevante politikker for betinget adgang.
Hash eksporterne.
Deaktivér derefter enheden, og slet den først, når det er dokumenteret, at den ikke længere bruges. En deaktiveret enhed bevarer objektet til dokumentation, mens en slettet enhed fjerner det.

Ny eksport efter oprydningen viser, om der er forsøg fra enheden bagefter.

Typiske forløb

Enhedsregistrering ses typisk i to sammenhænge. Den første er efter phishing, hvor en angriber har fået fat i et gyldigt token eller en session og bruger den til at registrere en enhed, inden adgangen bliver opdaget. Registreringen følger da ofte kort efter det første mistænkelige login, fra samme IP-adresse eller samme infrastruktur. Kendetegnene ved den type login er beskrevet i AiTM-phishing: kendetegn på stjålne sessioner i loginloggen.

Den anden er ved fratræden. En medarbejder kan have registreret private enheder, som fortsat er knyttet til kontoen. Er kontoen ikke blokeret, eller er enhederne ikke fjernet, kan de stadig synkronisere mail og filer. Spørgsmålet er da ikke, om registreringen var legitim, men om adgangen efter fratrædelsen var det, og det viser loginloggen med enhedens id. Den praktiske side for virksomheden står på bevissikring-digitalt.dk.

Dokumentation

For hver relevant enhed gengives objektets egenskaber på sikringstidspunktet, revisionsposter for registrering og ændringer, registreringsloginnet med IP-adresse og godkendelsesdetaljer og en opgørelse over efterfølgende logins med tidspunkt, app og ressource. Angiv tenantens indstillinger for enhedsregistrering i perioden og de politikker for betinget adgang, der gjaldt enhederne. Alle eksporter hashes, og tidspunktet for deaktivering og sletning noteres, så det kan ses, hvornår adgangen faktisk blev lukket.

Typiske fejlkilder

Brugerens egen nye enhed: En ny privat telefon eller computer kan være registreret helt legitimt.
Visningsnavn tages for pålydende: Navnet er sat af enheden og kan være hvad som helst.
Seneste login er omtrentligt: Feltet opdateres ikke ved hvert login.
Gamle, glemte enheder: Mange tenants har mange forældede objekter. Ikke alle inaktive enheder er mistænkelige.

Hvad sporene kan og ikke kan bevise

Sporene kan vise, at en enhed blev registreret fra en bestemt session, og hvilke logins der siden er sket fra den. De kan ikke vise, hvor enheden fysisk står, eller hvem der betjener den. Konklusionen bygger på sammenhængen mellem registrering, logins og brugerens øvrige enheder.

Et fravær af mistænkelige enheder i dag udelukker heller ikke, at der har været en. En enhed kan være slettet, enten af angriberen for at skjule sporet eller af en administrator under oprydningen. Sletningen står i auditloggen, så længe den er inden for opbevaringen, og logins fra den slettede enheds id kan stadig findes i loginloggen. Søg derfor også efter enheds-id’er i loginloggen, der ikke længere findes som objekter. Hvert sådant id er en enhed, der har været knyttet til kontoen, og som skal kunne forklares.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Microsoft 365 og Entra ID: logkilderne

Læs også: MFA-ændringer og betinget adgang i Entra ID-loggene · Privilegerede roller: tildelinger og ændringshistorik i Entra ID

→ Microsoft 365-forensik · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-sikkerhed og SOC · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik