Deaktivert er ikke fjernet

Anatomien i det som blir liggende igjen etter en offboarding

Tidsvinduet etter at kontoen er deaktivert

Å deaktivere en konto blokkerer nye innlogginger og hindrer utstedelse av nye tokens. Det tilbakekaller ikke tokens som allerede er utstedt. Microsofts egen dokumentasjon er eksplisitt: «For applications using access tokens, the user loses access when the access token expires», og «Access tokens might pose a security risk if they need to be revoked within a period shorter than their typical one-hour lifespan».

Standard levetid på et access token er variabel, tilfeldig fordelt mellom 60 og 90 minutter (gjennomsnitt 75 minutter). En bruker som logger av med et ferskt token klokken 15:59 kan i praksis fortsatt lese og skrive mot API-et til rundt 17:15, selv om kontoen ble deaktivert 16:00.

revokeSignInSessions (Revoke-MgUserSignInSession) hjelper delvis: den setter signInSessionsValidFromDateTime til nå, invaliderer alle refresh tokens og nettleserens sesjonsinformasjonskapsler. Den invaliderer ikke eksisterende access tokens, og Microsoft angir «a small delay of a few minutes before tokens are revoked». Entra ID kan heller ikke tilbakekalle et sesjonstoken applikasjonen selv har utstedt.

Motgiften finnes — Continuous Access Evaluation gir nær sanntids-invalidering mot CAE-kompatible ressurser, og forlenger til gjengjeld token-levetiden til 24–28 timer for de som ikke er det. Poenget er at dette er en arkitekturbeslutning noen må ha tatt bevisst, ikke noe som følger av at man huket av en boks.

Hva som overlever kontodeaktivering

Her ligger den reelle gjelden. Microsofts egen anbefalte prosedyre for å fjerne tilgang består av flere separate steg — og at de er separate, er beviset:

Update-MgUser -UserId $User.Id -AccountEnabled:$false
Revoke-MgUserSignInSession -UserId $User.Id
Get-MgUserRegisteredDevice -UserId $User.Id -All | ForEach-Object {
    Update-MgDevice -DeviceId $_.Id -AccountEnabled:$false
}

Enhetsdeaktivering er et eget steg fordi kontodeaktivering ikke gjør det. Tilsvarende har Microsofts Lifecycle Workflows egne, distinkte «leaver»-oppgaver: Disable user account, Remove users from all groups, Remove users from all teams, Remove all license assignments from user, Remove all access package assignments for user, Revoke all refresh tokens for user, Delete user. At disse er syv oppgaver og ikke én, forteller nøyaktig hva den første oppgaven ikke gjør.

Konkret blir følgende liggende etter at kontoen er deaktivert:

• Enhetsregistreringer i Entra ID (dokumentert — eget steg i Microsofts prosedyre)
• Gruppemedlemskap, inkludert medlemskap som gir tilgang til Teams, SharePoint og tredjepartsapper via SSO
• Lisenstildelinger — du betaler fortsatt
• Tildelinger i tilgangspakker
• Delegert postkassetilgang i Exchange. Delegering er en tillatelse på postkassen, ikke en egenskap ved kontoen. Microsofts dokumentasjon om delte postkasser viser prinsippet direkte: kontoen bak en delt postkasse skal alltid ha pålogging blokkert, samtidig som delegatene beholder full tilgang til innholdet.
• Gjestebrukere personen selv har invitert inn. B2B-gjesten er et selvstendig brukerobjekt i din tenant som autentiserer mot sin egen identitetsleverandør. Sponsor-attributtet peker på inviterende bruker, men er en sporingsegenskap — ikke en tilgangsavhengighet.

I hybridmiljø kommer i tillegg den lite kjente detaljen at Microsoft anbefaler å tilbakestille passordet to ganger i lokalt AD før man deaktiverer i Entra ID.

Lisensmatematikken

Lifecycle Workflows, som er Microsofts egen automatisering av dette, ligger i Microsoft Entra ID Governance — ikke i P2. Governance koster USD 7 per bruker/måned med årsbinding, oppå P1 (USD 7) eller P2 (USD 10). Stablet P2 + Governance = USD 17 per bruker per måned før implementering, og med et tak på 50 workflows per tenant.

Det juridiske gulvet

For virksomheter omfattet av digitalsikkerhetsloven — energi, transport, helse, vannforsyning, bank, finansmarkedsinfrastruktur og digital infrastruktur — er dette ikke lenger en beste praksis. Digitalsikkerhetsforskriften § 12, i kraft siden 1. oktober 2025, sier: «Når et arbeidsforhold eller en tjeneste avsluttes, skal en tilbyder av en samfunnsviktig tjeneste sikre at den som slutter ikke lenger har tilgang til virksomhetens nettverk og informasjonssystemer.» Bestemmelsen omfatter uttrykkelig også leverandører og oppdragstakere.

GDPR artikkel 32(4) treffer alle: den behandlingsansvarlige skal sikre at enhver som handler under dens myndighet og har tilgang til personopplysninger, ikke behandler dem uten instruks. En tidligere ansatt handler ikke lenger under din myndighet.

Hva dette betyr for Entra Logic

Problemet er ikke at IT-avdelingen ikke vet dette. Problemet er at riktig offboarding er en sekvens på seks til ti Graph-operasjoner som må utføres i riktig rekkefølge, hver gang, for hver avgang, i hver tenant — og at den i praksis utføres av mennesker under tidspress.

Entra Logic behandler en offboarding som én ordre: forespørselen kommer strukturert fra HR eller linjeleder, godkjenningen skjer én gang, og utførelsesmotoren kjører hele sekvensen mot Microsoft Graph nøyaktig slik den ble godkjent. Ingen deloppgave kan glemmes, fordi ingen deloppgave utføres manuelt. Den kontinuerlige synkroniseringen av boet gjør i tillegg at restene — foreldreløse enheter, ueide registreringer, gruppemedlemskap uten eier — dukker opp som en arbeidsliste i stedet for som et funn under neste revisjon.

Kilder

• Microsoft Learn — Revoke user access in Microsoft Entra ID
• Microsoft Learn — Configurable token lifetimes
• Microsoft Learn — user: revokeSignInSessions
• Microsoft Learn — Lifecycle Workflow tasks
• Microsoft Learn — About shared mailboxes
• Microsoft Learn — Properties of a B2B collaboration user
• Microsoft — Microsoft Entra pricing
• Lovdata — Digitalsikkerhetsforskriften (FOR-2025-06-20-1131)
• EUR-Lex — Forordning (EU) 2016/679 (GDPR)