
Författare
David Lindin @ Asurgent
Read time
3 min
26 mars 2026
Jag möter ganska ofta organisationer som har investerat i Microsoft Defender XDR, konfigurerat det noggrant vid driftsättning och sedan i stort sett lämnat det att sköta sig självt. Det är förståeligt. Plattformen är kraftfull, den känns solid och det finns alltid andra bränder att släcka. Men det är just i det lugnet som problemen brukar gro.

Defender XDR är idag en av de mest sammanhållna plattformarna för att skydda en organisation mot moderna cyberhot. Det är inte ett enskilt verktyg utan snarare ett ekosystem, en sammanslagen vy över endpoints, identiteter, e-post och molnapplikationer. Istället för att hantera fem separata konsoler med fem separata larm får säkerhetsteamet en korrelerad bild av vad som faktiskt händer. Attacker som annars skulle ha sett ut som orelaterade händelser knyts ihop automatiskt till en sammanhängande incident. För ett företag som vill ta säkerhetsarbetet på allvar är det ett genuint starkt erbjudande och licensieringen är dessutom ofta redan inkluderad i de Microsoft 365-abonnemang många organisationer redan betalar för.
Dock finns en fallgrop som jag återkommande ser, vilket är att tro att man är klar när man väl har konfigurerat det.
Configuration drift är ett begrepp som beskriver hur en teknisk miljö gradvis förändras från sitt avsedda läge, ofta utan att någon aktivt beslutat om det. En undantagspolicy skapas för att lösa ett akut problem och glöms sedan bort. En detektionsregel stängs av tillfälligt och aktiveras aldrig igen. En onboarding-policy täcker inte längre alla enheter eftersom organisationen har vuxit sedan den skapades. Var och en av dessa förändringar är liten, men sammantaget kan de göra att Defender XDR inte längre skyddar det den är tänkt att skydda.
Det som gör det extra svårt att hantera är att det sker tyst. Inget larm går. Miljön ser fortfarande ut att fungera, men det finns luckor som bara syns om man aktivt letar efter dem. Det är den typen av exponering som sällan dyker upp i en statusrapport, men som kan göra stor skillnad om och framför allt när något väl händer.
Av den anledningen är löpande granskning av konfigurationen inte en lyx utan en nödvändighet. Det handlar om att regelbundet stämma av att detektionsregler är aktiva och relevanta, att enheter verkligen är onboardade och rapporterar som förväntat och att policyer återspeglar hur organisationen faktiskt ser ut idag, inte hur den såg ut för arton månader sedan.
Besläktat med configuration drift är något jag brukar kalla "stale configurations", konfigurationer som inte förändrats för att de drivits iväg, utan för att de helt enkelt inte hängt med i Microsofts egen utveckling. Och här är det värt att poängtera: Defender XDR är ingen statisk produkt. Microsoft expanderar plattformen kontinuerligt, och ett tydligt exempel är hur Defender for Cloud numera integrerats i XDR-upplevelsen, något som förändrar både synlighet och hantering av molnmiljöer på ett sätt som många organisationer ännu inte fullt ut utnyttjar.
En organisation som konfigurerade sin miljö för två år sedan och sedan inte rört den har tekniskt sett en fungerande lösning, men den nyttjar sannolikt inte det som faktiskt finns tillgängligt idag.
Jag ser regelbundet miljöer där man fortfarande förlitar sig på äldre metoder för att hantera något som numera finns inbyggt och bättre i plattformen. Det är inte ett tecken på slarv, det är ett tecken på att man inte haft strukturen för att hänga med. Det går att åtgärda, men det kräver att man tar det på allvar.
En del av det arbetet handlar om att följa upp bredare än vad många gör idag. Microsoft Secure Score är ett bra utgångspunkt, men det ger bara en del av bilden. Exposure Management-mätvärden, critical asset summaries, attack path scenarios och liknande ger en betydligt mer nyanserad förståelse för hur exponerad organisationen faktiskt är och var de verkliga riskerna sitter. Att regelbundet gå igenom dessa, inte bara bocka av Secure Score, är det som skiljer en välskött miljö från en som ser bra ut på ytan.
En sak jag alltid lyfter med kunder är hur djupt Defender XDR är integrerat i det bredare Microsoft-ekosystemet. Konfigurationer och säkerhetsstatus samspelar med Entra ID, Intune, Purview, Sentinel och Azure-miljön. Det innebär att en förändring på ett ställe kan få konsekvenser på ett annat och att drift i en del av miljön kan skapa exponeringar i en annan. Det är en styrka när allt fungerar och hänger ihop, men det ställer också krav på en helhetsbild och ett tydligt ägarskap.
Att managera Defender XDR väl handlar i slutändan om att behandla det som vad det faktiskt är: en central, levande och ständigt växande del av organisationens säkerhetsarkitektur. Det kräver regelbunden uppmärksamhet och en kultur där konfigurationer granskas med samma allvar som de en gång sattes upp med. Asurgents tjänst XDR Governance hjälper kunden sätta ramarna för att på ett strukturerat sätt hålla koll på miljön och använda plattformen som den är tänkt.
Lösningen är sällan komplicerad. Det handlar mest om att inte glömma bort att titta.
Prenumerera på vårt nyhetsbrev för att ha koll på senaste nytt inom cybersäkerhetssfären.