De fleste organisasjoner har en IAM-prosess på plass. Onboarding, offboarding, joiner-mover-leaver. Ansatte kommer inn via HR-systemet, går gjennom IAM-verktøyet og ender opp i Entra ID. Alt føles under kontroll.

Men blindsoner i identitetsmiljøet dukker likevel opp, selv i velstyrte organisasjoner. Og de følger de samme mønstrene.

I denne artikkelen:

• Hvordan blindsonene bygger seg opp over tid

• Inaktive og foreldreløse kontoer

• For brede administratorrettigheter

• Ufullstendig MFA-dekning

• Applikasjoner og tjenesteprinsipper med for vide rettigheter

• Sammen utvider de angrepsflaten

• Hva kan du gjøre med det?

• Ofte stilte spørsmål

Hvordan blindsonene bygger seg opp over tid

Årsaken er enkel. De fleste organisasjoner har god kontroll over identitetene som følger de formelle IAM-prosessene: ansatte som kommer inn via HR-systemer, standard brukerkontoer som styres av conditional access-policyer, og kanskje en håndfull applikasjoner med utpekte eiere.

Men ikke alt følger den prosessen.

Adminkontoer håndteres ofte manuelt. Eksterne konsulenter er kanskje ikke fullstendig kontrollert. Testkontoer blir hengende igjen lenge etter at prosjektet som opprettet dem er avsluttet. Agenter og tjenesteprinsipper opprettes for integrasjoner, migrasjoner og testing, og blir deretter glemt. Gamle kontoer som ble synkronisert fra lokalt Active Directory under en migrering til Entra ID blir aldri ryddet opp.

Alle disse ender opp i Entra-miljøet ditt, men utenfor de formelle prosessene for identitetsstyring. De dekkes ikke av joiner-mover-leaver-syklusen. De dukker ikke opp i standardrapportene dine. Og over tid hoper de seg opp.

Det er denne opphopningen som skaper blindsonene. Basert på det vi ser på tvers av hundrevis av identitetsmiljøer, dukker fire kategorier opp konsekvent.

1. Inaktive og foreldreløse kontoer i Entra ID

Dette er kontoer som er aktivert, har tilgang, og ikke har logget inn i nyere tid. Vi bruker 90 dager som terskel for å kategorisere en konto som inaktiv, men mange har vært ubrukt langt lenger enn det.

Tallene er konsistente: et sted mellom 20 og 40 prosent av kontoene i et typisk Entra ID-miljø er inaktive. Det inkluderer medlemskontoer, ressurskontoer og gjestekontoer som ble gitt tilgang til deler av dataene dine og aldri ble trukket tilbake.

Hvorfor betyr det noe? De fleste av disse kontoene har ingen tydelig eier. Det er nettopp derfor de fortsatt eksisterer. Ingen er ansvarlig for dem, og ingen overvåker dem. De dukker ikke opp i den daglige monitoreringen fordi de lever utenfor prosessene du aktivt styrer.

Hvis en av disse kontoene blir kompromittert, kan det være vanskelig å oppdage. Det er bare en eksisterende konto i miljøet ditt som plutselig begynner å bli brukt. Ingenting i standardovervåkingen din fanger det opp, fordi kontoen aldri var flagget som noe å følge med på.

Det er også en direkte kostnadspåvirkning. Mange inaktive kontoer holder fortsatt lisenser du betaler for. Sikkerhetsrisikoen og det økonomiske svinnet er to sider av samme sak.

Inaktive kontoer er den enkleste blindsonen å kategorisere, og ofte det enkleste stedet å begynne. Les mer om hvordan Bsure synliggjør inaktive identiteter.

2. For brede administratorrettigheter i Entra ID

Dette handler om adminkontoer som har permanente roller, ofte flere enn de trenger, og ofte tildelt på måter som øker risikoen.

Vanlige mønstre inkluderer:

Global admin brukt til daglig drift. Selv når tenanten er lisensiert for Privileged Identity Management (PIM) og eligible roles, ser vi jevnlig at permanente global admin-tildelinger brukes av bekvemmelighet. Roller tildeles «for sikkerhets skyld» i stedet for basert på faktiske driftsbehov.

Adminroller tildelt vanlige brukerkontoer. Det betyr at samme konto som brukes til e-post, Teams og daglig arbeid også har admin-rettigheter. Hvis den kontoen blir kompromittert, får angriperen ikke bare tilgang til brukerens data. De får admin-tilgang til hele miljøet.

Adminkontoer synkronisert fra lokalt Active Directory. Dette er et spesielt risikabelt mønster. Hvis on-prem-kontoen blir kompromittert, har angriperen en direkte vei til å pivotere inn i skyen som admin. Microsofts egen zero trust-veiledning fraråder dette eksplisitt.

Foreldreløse adminroller. Gamle partnere, tidligere konsulenter, tidligere ansatte der de separate adminkontene rett og slett ble glemt. Selv gamle Entra Connect sync-tjenestekontoer som fikk roller for flere år siden og ikke lenger trenger dem.

Én kompromittert adminkonto er nok. Blast radius er hele miljøet ditt. Dette er blindsonen vi ville prioritert å adressere først.

3. Ufullstendig MFA-dekning

MFA behandles ofte som et binært valg: enten har du det eller ikke. Virkeligheten rundt MFA-håndhevelse i de fleste Entra ID-miljøer er mer nyansert.

Hull i conditional access-policyer. Policyene som håndhever MFA har ofte unntak som ga mening for noen år siden, men som ikke lenger er i tråd med zero trust-prinsipper. Et vanlig eksempel: å ekskludere kontornettverket fra MFA-krav. Det var standard praksis for noen år tilbake. I dag skaper det en åpning som angripere kan utnytte.

Ukontrollert MFA-registrering. Brukere må registrere MFA-metodene sine før de kan bruke dem. Hvis miljøet ditt tillater MFA-registrering fra hvor som helst ved bare bruk av brukernavn og passord, har du et problem. Du vet ikke om personen som registrerer seg er den virkelige brukeren eller noen som har fått tak i påloggingsinformasjonen gjennom en passordlekkasje. En conditional access-policy for registrering av sikkerhetsinformasjon, kombinert med midlertidige tilgangskoder (temporary access pass), lukker dette hullet.

Svake MFA-metoder. Ikke alle metoder er like sterke. Push-varsler, SMS og tale er phishbare. FIDO2-nøkler og passkeys er phishing-resistente. For adminkontoer bør phishing-resistent MFA være minimum.

Ifølge Microsofts Digital Defense Report 2025 retter 97 % av identitetsangrep seg mot påloggingsinformasjon, kontoer og tilganger. Uten en MFA-utfordring trenger en angriper bare et passordspray-angrep eller en lekket påloggingsinformasjon for å logge inn. Med svakere MFA-metoder kan adversary-in-the-middle-teknikker kapre sesjonen og gi angriperen vedvarende tilgang.

4. Applikasjoner og tjenesteprinsipper med for vide rettigheter

Dette er trolig den raskest voksende blindsonen, og den der mange organisasjoner har minst kontroll.

Tjenesteprinsipper og enterprise-applikasjoner samler opp brede tilganger over tid på tvers av Microsoft Graph, SharePoint Online og Exchange Online. De opprettes for migrasjoner, integrasjoner, backup og testing. Når prosjektet er ferdig, blir applikasjonen værende, ofte med de samme tilgangene den fikk på dag én.

Tenk deg et vanlig scenario: en organisasjon migrerer fra SharePoint on-premises til SharePoint Online. Migreringsverktøyet får fulle rettigheter på SharePoint Online. Flere år senere eksisterer applikasjonen fortsatt i Entra ID med de samme rettighetene, fordi ingen eier livssyklusen til den typen applikasjon.

Leverandører bruker ofte secrets i stedet for sertifikater for å autentisere applikasjonene sine. Et secret er i praksis et passord. Mellom leverandøren og dataene dine sitter én enkelt tekststreng. Organisasjoner bør utfordre leverandørene sine til å støtte sertifikatbasert autentisering i stedet.

Eierproblemet er betydelig. Enterprise-applikasjoner som brukes til single sign-on har svært ofte ingen tydelig eier. Når en applikasjon dukker opp uten eier, bør den undersøkes. Applikasjoner er en stadig vanligere vei for angripere til å skaffe seg vedvarende tilgang og eskalere rettigheter i skymiljøer.

Det er to hovedangrepsveier. Den første er å lure en bruker eller admin til å godkjenne en ondsinnet applikasjon som har tilstrekkelige rettigheter til å gi angriperen tilgang. Den andre er å kompromittere en bruker som tilfeldigvis er eier av en applikasjon med eleverte rettigheter, og deretter bruke den applikasjonen som en vei til bredere tilgang.

Sammen skaper de en unødvendig stor angrepsflate

Hver for seg representerer hver av disse blindsonene en håndterbar risiko. Sammen skaper de en angrepsflate som er større enn den trenger å være.

Foreldreløse kontoer med gjenværende tilgang. Adminroller ingen overvåker. MFA-hull som lar døren stå åpen. Applikasjoner med brede rettigheter og ingen livssyklusstyring. Dette er ikke eksotiske sårbarheter. Det er de hverdagslige hullene som hoper seg opp i ethvert identitetsmiljø over tid, spesielt de som faller utenfor de formelle IAM-prosessene.

Fellesnevneren er synlighet. Disse blindsonene vedvarer fordi de ligger utenfor det de fleste verktøy for identitetsstyring er bygget for å fange opp. Kontoene, rollene og applikasjonene er teknisk sett til stede i Entra ID-tenanten din. Men de er ikke synlige for menneskene og prosessene som burde forvalte dem.

Hva kan du gjøre med det?

Å se problemet er første steg. Men synlighet alene løser det ikke, fordi i de fleste organisasjoner er IT det eneste teamet som kan se disse hullene. Lederne, forretningsområdelederne og applikasjonseierne som er ansvarlige for brukere, budsjetter og drift har ikke tilgang til dataene de trenger for å handle.

Det er temaet for neste sesjon: hvordan distribuere identitetsstyring på tvers av organisasjonen, slik at de som er ansvarlige faktisk kan se hva de er ansvarlige for.

Neste webinar: 13. mai 2026, kl. 15:00 CEST. Meld deg på her.

Les mer om hvordan Bsure hjelper organisasjoner med å få synlighet i identitetsmiljøet sitt.

Ofte stilte spørsmål

• Hva er blindsoner i identitetsmiljøet?
  Blindsoner i identitetsmiljøet er hull i Entra ID-miljøet ditt som ligger utenfor de formelle IAM-prosessene. De inkluderer inaktive kontoer, for brede adminrettigheter, ufullstendig MFA-dekning og applikasjoner med for vide rettigheter. De kalles blindsoner fordi de eksisterer i miljøet ditt, men ikke er synlige gjennom standard overvåking og styringsrutiner.

• Hvor mange inaktive kontoer er normalt i et Entra ID-miljø?
  Basert på det vi ser på tvers av hundrevis av miljøer, er et sted mellom 20 og 40 prosent av kontoene typisk inaktive (definert som at de ikke har logget inn på 90 dager eller mer). Dette inkluderer medlemskontoer, ressurskontoer og gjestekontoer.

• Hvorfor er ikke MFA nok til å forhindre identitetsangrep?
  MFA reduserer risikoen betydelig, men effektiviteten avhenger av hvordan det håndheves. Hull i conditional access-policyer, ukontrollert MFA-registrering og bruk av phishbare metoder (som SMS eller push-varsler) skaper alle åpninger. Phishing-resistente metoder som FIDO2 og passkeys gir sterkere beskyttelse, spesielt for privilegerte kontoer.

• Hva er risikoen ved tjenesteprinsipper med for vide rettigheter?
  Tjenesteprinsipper med brede rettigheter kan utnyttes av angripere til å skaffe seg vedvarende tilgang og eskalere privilegier. Hvis en applikasjon har tilgang til Microsoft Graph, SharePoint eller Exchange med brede rettigheter og ingen tydelig eier, representerer den en betydelig og ofte uovervåket angrepsvektor.
  
  

Denne artikkelen er basert på en live-sesjon holdt av Olav Helland, medgrunnlegger og Cloud Architect i Bsure. Med 25 års erfaring på tvers av Microsoft-miljøer jobber Olav med identitetsstyring i hundrevis av M365-tenanter, fra identitet og tilgang til de operasjonelle realitetene ved å kjøre Entra ID i stor skala. Ta kontakt med Olav på LinkedIn.