De flesta organisationer har en IAM-process på plats. Onboarding, offboarding, joiner-mover-leaver. Anställda kommer in via HR-systemet, passerar genom IAM-verktyget och hamnar i Entra ID. Allt känns under kontroll.

Men blinda fläckar i identitetsmiljön dyker ändå upp, även i välstyrda organisationer. Och de tenderar att följa samma mönster.

I den här artikeln:

• Hur blinda fläckar byggs upp över tid

• Inaktiva och föräldralösa konton

• För breda administratörsbehörigheter

• Ofullständig MFA-täckning

• Applikationer och tjänsteprincipal med för vida behörigheter

• Tillsammans utökar de attackytan

• Vad kan du göra åt det?

• Vanliga frågor

Hur blinda fläckar byggs upp över tid

Grundorsaken är enkel. De flesta organisationer har god kontroll över de identiteter som flödar genom deras formella IAM-processer: anställda som kommer in via HR-system, standardanvändarkonton som styrs av conditional access-policyer och kanske en handfull applikationer med utsedda ägare.

Men inte allt följer den processen.

Adminkonton hanteras ofta manuellt. Externa konsulter kanske inte är fullt kontrollerade. Testkonton blir kvar långt efter att projektet som skapade dem har avslutats. Agenter och tjänsteprincipal skapas för integrationer, migreringar och testning, och glöms sedan bort. Gamla konton som synkroniserades från lokalt Active Directory under en migrering till Entra ID rensas aldrig upp.

Alla dessa hamnar i din Entra-miljö, men utanför dina formella processer för identitetsstyrning. De täcks inte av din joiner-mover-leaver-cykel. De dyker inte upp i dina standardrapporter. Och över tid ackumuleras de.

Det är denna ackumulering som skapar de blinda fläckarna. Baserat på vad vi ser i hundratals identitetsmiljöer dyker fyra kategorier upp konsekvent.

1. Inaktiva och föräldralösa konton i Entra ID

Dessa är konton som är aktiverade, har åtkomst och inte har loggat in nyligen. Vi använder 90 dagar som tröskel för att kategorisera ett konto som inaktivt, men många har varit oanvända betydligt längre.

Siffrorna är konsekventa: någonstans mellan 20 och 40 procent av kontona i en typisk Entra ID-miljö är inaktiva. Det inkluderar medlemskonton, resurskonton och gästkonton som fick åtkomst till delar av era data och aldrig revokerades.

Varför spelar det roll? De flesta av dessa konton har ingen tydlig ägare. Det är precis därför de fortfarande existerar. Ingen ansvarar för dem och ingen övervakar dem. De dyker inte upp i den dagliga monitoreringen eftersom de lever utanför de processer du aktivt styr.

Om ett av dessa konton komprometteras kan det vara svårt att upptäcka. Det är bara ett befintligt konto i din miljö som plötsligt börjar användas. Inget i din standardövervakning fångar upp det, eftersom kontot aldrig var något du aktivt bevakade.

Det finns också en direkt kostnadspåverkan. Många inaktiva konton har fortfarande licenser du betalar för. Säkerhetsrisken och det ekonomiska slöseriet är två sidor av samma mynt.

Inaktiva konton är den enklaste blinda fläcken att kategorisera, och ofta det enklaste stället att börja. Läs mer om hur Bsure synliggör inaktiva identiteter.

2. För breda administratörsbehörigheter i Entra ID

Det handlar om adminkonton som har permanenta roller, ofta fler än de behöver, och ofta tilldelade på sätt som ökar risken.

Vanliga mönster inkluderar:

Global admin som används för daglig drift. Även när klientorganisationen är licensierad för Privileged Identity Management (PIM) och eligible roles ser vi regelbundet att permanenta global admin-tilldelningar används av bekvämlighet. Roller tilldelas "för säkerhets skull" snarare än baserat på faktiska driftsbehov.

Adminroller tilldelade vanliga användarkonton. Det innebär att samma konto som används för e-post, Teams och dagligt arbete också har adminbehörigheter. Om det kontot komprometteras får angriparen inte bara åtkomst till användarens data. De får admin-åtkomst till hela miljön.

Adminkonton synkroniserade från lokalt Active Directory. Detta är ett särskilt riskabelt mönster. Om on-prem-kontot komprometteras har angriparen en direkt väg att pivotera in i molnet som admin. Microsofts egen zero trust-vägledning avråder uttryckligen från detta.

Föräldralösa adminroller. Gamla partners, tidigare konsulter, tidigare anställda vars separata adminkonton helt enkelt glömdes bort. Även äldre Entra Connect sync-tjänstkonton som fick roller för flera år sedan och inte längre behöver dem.

Ett komprometterat adminkonto räcker. Blast radius är hela din miljö. Det här är den blinda fläck vi skulle prioritera att åtgärda först.

3. Ofullständig MFA-täckning

MFA behandlas ofta som binärt: antingen har du det eller inte. Verkligheten kring MFA-tillämpning i de flesta Entra ID-miljöer är mer nyanserad.

Luckor i conditional access-policyer. Policyerna som tillämpar MFA har ofta undantag som var vettiga för några år sedan men som inte längre överensstämmer med zero trust-principer. Ett vanligt exempel: att undanta kontorsnätverket från MFA-krav. Det var standardpraxis för några år sedan. Idag skapar det en lucka som angripare kan utnyttja.

Okontrollerad MFA-registrering. Användare måste registrera sina MFA-metoder innan de kan använda dem. Om din miljö tillåter MFA-registrering var som helst med bara användarnamn och lösenord har du ett problem. Du vet inte om personen som registrerar sig är den riktiga användaren eller någon som fått tag på inloggningsuppgifterna genom en lösenordsläcka. En conditional access-policy för registrering av säkerhetsinformation, i kombination med tillfälliga åtkomstkoder (temporary access pass), stänger denna lucka.

Svaga MFA-metoder. Inte alla metoder är lika starka. Push-notiser, SMS och röst är phishbara. FIDO2-nycklar och passkeys är phishing-resistenta. För adminkonton bör phishing-resistent MFA vara minimum.

Enligt Microsofts Digital Defense Report 2025 riktar sig 97 % av identitetsattackerna mot inloggningsuppgifter, konton och åtkomst. Utan en MFA-utmaning behöver en angripare bara en password spray-attack eller ett läckt lösenord för att logga in. Med svagare MFA-metoder kan adversary-in-the-middle-tekniker kapa sessionen och ge angriparen bestående åtkomst.

4. Applikationer och tjänsteprincipal med för vida behörigheter

Det här är sannolikt den snabbast växande blinda fläcken, och den där många organisationer har minst kontroll.

Tjänsteprincipal och enterprise-applikationer samlar på sig breda behörigheter över tid genom Microsoft Graph, SharePoint Online och Exchange Online. De skapas för migreringar, integrationer, backup och testning. När projektet avslutas blir applikationen kvar, ofta med samma behörigheter den fick dag ett.

Tänk dig ett vanligt scenario: en organisation migrerar från SharePoint on-premises till SharePoint Online. Migreringsverktyget får fulla behörigheter på SharePoint Online. Flera år senare existerar applikationen fortfarande i Entra ID med samma behörigheter, eftersom ingen äger livscykeln för den typen av applikation.

Leverantörer använder ofta secrets istället för certifikat för att autentisera sina applikationer. Ett secret är i praktiken ett lösenord. Mellan leverantören och era data sitter en enda textsträng. Organisationer bör utmana sina leverantörer att stödja certifikatbaserad autentisering istället.

Ägarskapsfrågan är betydande. Enterprise-applikationer som används för single sign-on har mycket ofta ingen tydlig ägare. När en applikation dyker upp utan ägare bör den undersökas. Applikationer är en allt vanligare väg för angripare att skaffa sig bestående åtkomst och eskalera behörigheter i molnmiljöer.

Det finns två huvudsakliga attackvektorer. Den första är att lura en användare eller admin att godkänna en skadlig applikation som har tillräckliga behörigheter för att ge angriparen åtkomst. Den andra är att kompromettera en användare som råkar vara ägare av en applikation med förhöjda behörigheter, och sedan använda den applikationen som en väg till bredare åtkomst.

Tillsammans skapar de en onödigt stor attackyta

Var för sig representerar var och en av dessa blinda fläckar en hanterbar risk. Tillsammans skapar de en attackyta som är större än den behöver vara.

Föräldralösa konton med kvarvarande åtkomst. Adminroller som ingen övervakar. MFA-luckor som lämnar dörren öppen. Applikationer med breda behörigheter och ingen livscykelhantering. Det här är inte exotiska sårbarheter. Det är de vardagliga luckorna som ackumuleras i alla identitetsmiljöer över tid, särskilt de som faller utanför de formella IAM-processerna.

Den gemensamma nämnaren är synlighet. Dessa blinda fläckar kvarstår eftersom de ligger utanför vad de flesta verktyg för identitetsstyrning är byggda att fånga upp. Kontona, rollerna och applikationerna finns tekniskt sett i din Entra ID-klientorganisation. Men de är inte synliga för de personer och processer som borde hantera dem.

Vad kan du göra åt det?

Att se problemet är första steget. Men synlighet ensamt löser det inte, för i de flesta organisationer är IT det enda teamet som kan se dessa luckor. Cheferna, affärsområdesledarna och applikationsägarna som ansvarar för användare, budgetar och drift har inte tillgång till den data de behöver för att agera.

Det är ämnet för vår nästa session: hur man distribuerar identitetsstyrning över organisationen så att de ansvariga faktiskt kan se vad de ansvarar för.

Nästa webinar: 13 maj 2026, kl. 15:00 CEST. Anmäl dig här.

Läs mer om hur Bsure hjälper organisationer att få synlighet i sin identitetsmiljö.

Vanliga frågor

• Vad är blinda fläckar i identitetsmiljön?
  Blinda fläckar i identitetsmiljön är luckor i din Entra ID-miljö som ligger utanför dina formella IAM-processer. De inkluderar inaktiva konton, för breda adminbehörigheter, ofullständig MFA-täckning och applikationer med för vida behörigheter. De kallas blinda fläckar eftersom de existerar i din miljö men inte är synliga genom din standardövervakning och dina styrningsrutiner.

• Hur många inaktiva konton är normalt i en Entra ID-miljö?
  Baserat på vad vi ser i hundratals miljöer är någonstans mellan 20 och 40 procent av kontona typiskt inaktiva (definierat som att de inte har loggat in på 90 dagar eller mer). Det inkluderar medlemskonton, resurskonton och gästkonton.

• Varför räcker inte MFA för att förhindra identitetsattacker?
  MFA minskar risken avsevärt, men effektiviteten beror på hur det tillämpas. Luckor i conditional access-policyer, okontrollerad MFA-registrering och användning av phishbara metoder (som SMS eller push-notiser) skapar alla öppningar. Phishing-resistenta metoder som FIDO2 och passkeys ger starkare skydd, särskilt för privilegierade konton.

• Vad är risken med tjänsteprincipal med för vida behörigheter?
  Tjänsteprincipal med breda behörigheter kan utnyttjas av angripare för att skaffa bestående åtkomst och eskalera privilegier. Om en applikation har åtkomst till Microsoft Graph, SharePoint eller Exchange med breda behörigheter och ingen tydlig ägare representerar den en betydande och ofta oövervakad attackvektor.

Den här artikeln är baserad på en livesession med Olav Helland, medgrundare och Cloud Architect på Bsure. Med 25 års erfarenhet inom Microsoft-miljöer arbetar Olav med identitetsstyrning i hundratals M365-klientorganisationer, från identitet och åtkomst till de operativa realiteterna av att driva Entra ID i stor skala. Kontakta Olav på LinkedIn.